Gli esperti di Palo Alto Networks analizzano le criticità della cosiddetta “Shift-Left Security” e consigliano dove, su che cosa e come agire per evitare falle nei sistemi di sicurezza.
Il termine “Shift-Left” si riferisce al ciclo di vita dello sviluppo del software (SDLC) che descrive le fasi del processo seguito dagli sviluppatori per creare un’applicazione. Spesso è rappresentato come una linea temporale orizzontale, caratterizzata da momenti concettuali e di codifica che “avviano” il ciclo sul lato sinistro. Quindi, spostare un processo all’inizio significa spostarlo a sinistra. La “Shift-Left Security” è il concetto secondo cui misure di sicurezza, aree di interesse e implicazioni dovrebbero avvenire più a sinistra, o prima, rispetto a quanto si fa abitualmente.
Perché la sicurezza Shift-Left è importante nella cybersecurity?
Se da un lato le nuove architetture delle applicazioni offrono a programmatori e team di prodotto incredibile velocità di sviluppo, dall’altro hanno aumentato le sfide in termini di normativa e controllo. La sicurezza deve tenere il passo con la rapida crescita e l’agilità dei cicli di sviluppo ed essere sufficientemente flessibile da supportare un’ampia gamma di soluzioni cloud. L’unico denominatore comune di questi nuovi flussi è il codice alla base di tutto, dall’applicazione all’infrastruttura, che è aperto e riutilizzato dagli sviluppatori. Per questo motivo, portare la sicurezza “a sinistra”, nella fase di codifica, significa prevedere la sicurezza sin dall’inizio, riducendo così il rischio di exploit da parte dei cybercriminali e gli impatti su migliaia di applicazioni.
L’importanza di questa definizione
Come molte parole della cybersecurity, numerosi vendor trattano la sicurezza shift-left come “l’unico elemento necessario per essere protetti”, come se fosse una panacea per tutti i problemi. In realtà, questo concetto ostacola l’approccio Zero Trust, poiché presume fiducia implicita nei confronti dello sviluppatore e delle sue capacità di codifica.
Le criticità della “Shift-Left Security”
Inoltre, mancano comprensione e pratiche standard per lo sviluppo delle applicazioni in un moderno reparto DevOps. In particolare per quanto riguarda la catena di fornitura del codice (pacchetti open source e drift) o gli strumenti di integrazione (Git, CI/CD, ecc.) e questo crea dei rischi. Ad esempio, se l’archivio dati di un’azienda è liberamente accessibile su Internet, e ritiene non sia un problema perché le informazioni sono crittografate, dovrà essere consapevole del fatto che i criminali informatici potranno farne una copia. E, successivamente, lavorare per decifrarle.
I fattori da considerare quando si adottala sicurezza Shift-Left
Introdurre la Shift-Left Security all’interno di un programma SDLC è una priorità a cui i dirigenti dovrebbero prestare attenzione. La portata pervasiva dei team di sviluppo, che non solo creano applicazioni business-critical, ma ne gestiscono ogni fase, dalla codifica alla compilazione, ai test fino alle esigenze infrastrutturali con codice aggiuntivo, rappresenta un livello di controllo e influenza straordinari.
Sicurezza per tutti
Estendere la sicurezza a tutti i flussi di lavoro dei team di sviluppo è il concetto della sicurezza Shift-Left. Tuttavia sarebbe estremamente rischioso abbandonare o screditare le misure di protezione delle fasi successive o “lato destro”. La sicurezza deve essere presente lungo l’intero ciclo di vita, dalla creazione del codice allo staging della distribuzione circostante, fino all’applicazione e all’ambiente che la gestisce.
Le criticità della “Shift-Left Security”. I consigli di Palo Alto
Ecco alcune domande da porsi per un’adozione della sicurezza Shift-Left di successo:
- Come inserire tutte le fasi SDLC nel programma di sicurezza, senza creare un sovraccarico di nuovi strumenti da imparare per ogni livello? Come consentire al team di sviluppo di correggere semplici errori di sicurezza senza ritardare o bloccare la loro capacità di rilasciare applicazioni e aggiornamenti critici?
- È necessario integrarsi negli strumenti e nei flussi di lavoro utilizzati dal team di sviluppo per codificare, aggregare, testare e distribuire. Come raggiungere questo risultato rispondendo alle esigenze sopra elencate?
- Supponendo che qualcosa venga distribuito in modo non sicuro, come inviare la richiesta di correzione nel flusso di lavoro, includendo automaticamente le modifiche alla codifica?
- Esistono piattaforme in grado di gestire la sicurezza Shift-Left, di proteggere l’ambiente di runtime e di alimentare operazioni di security, governance e conformità? I flussi di lavoro degli infrastructure architect sono in grado di fornire visibilità, protezione e livelli di auditing per l’intero panorama applicativo?