Diventa Autore per CoreTech | Scopri di più
31/07/20 CoreTech Blog
DevSecOps è una pratica che unisce il lavoro svolto dai team di sviluppo (Dev), sicurezza (Sec) e IT Operations (Ops) per fornire le pratiche di sviluppo software più efficienti ed efficaci. Ma perché è ancora così raro? Diamo un'occhiata alle difficoltà di implementazione di DevSecOps e ai modi per eliminarle.
DevOps è una pratica che si intende principalmente accompagnata da pratiche agili per il ciclo di vita dello sviluppo del software (SDLC). L'obiettivo principale è fornire software in cicli brevi ed efficienti e automatizzare il più possibile il processo di sviluppo e il processo di consegna del software. È difficile immaginare uno sviluppo software agile senza un'automazione estesa dei processi di costruzione e test, ovvero senza le pipeline di integrazione continua / consegna continua (CI / CD) che costituiscono la base di DevSecOps.
Non sarebbe possibile avere DevOps se i processi di compilazione e test che fanno parte del ciclo di sviluppo sono rimasti manuali. Tuttavia, nell'approccio originale a DevOps, nessuno sembra aver pensato di verificare automaticamente la sicurezza delle applicazioni come parte del test. Quale potrebbe essere la ragione?
Una tipica pipeline CI / CD DevOps include i seguenti passaggi:
Sembra logico aggiungere un ulteriore passaggio a quella pipeline:
Ma questo non è il caso nella maggior parte degli ambienti DevOps - ecco perché non sono processi DevSecOps.
Esaminiamo i motivi per cui le organizzazioni che implementano con successo DevOps spesso non includono pratiche di sicurezza nei loro processi DevOps.
È un pensiero spaventoso, ma crediamo che molte organizzazioni non includano i controlli di sicurezza nei loro processi DevOps semplicemente perché non pensano che la sicurezza delle applicazioni sia abbastanza importante.
Molte organizzazioni hanno una consapevolezza limitata della sicurezza informatica e la percepiscono attraverso la prospettiva dell'hype mediatico su ransomware e phishing. Mentre è vero che ransomware e phishing sono le principali minacce alla sicurezza e non c'è nulla che tu possa fare nelle pipeline di sviluppo per mitigare tali rischi per la sicurezza, non è tutto ciò che riguarda la sicurezza.
Le organizzazioni a volte non si rendono conto che oltre all'ingegneria sociale, gli hacker black hat possono facilmente sfruttare una vulnerabilità in un'applicazione per accedere a dati sensibili o persino assumere il controllo dell'applicazione o dell'intero server. Questo può portare a ulteriori attacchi, incluso il temuto ransomware. Se un hacker black-hat è in grado, ad esempio, di eseguire codice remoto utilizzando l'applicazione e installare una shell inversa, è in grado di eseguire comandi su un server e, diciamo, distribuire ransomware che si diffonderà in tutto l'ambiente e si diffonderà il caos totale. E in tal caso, la causa principale è la mancanza di sicurezza delle applicazioni e nessun ransomware e protezione dal phishing ti aiuteranno.
Pertanto, il primo e più importante passo verso DevSecOps è coinvolgere tutti e promuovere la responsabilità condivisa, in particolare tra i decisori. Devono rendersi conto che il codice sicuro è della massima importanza. Devono supportarti nel tuo viaggio DevSecOps.
I team di sicurezza lavorano spesso in silos semplicemente perché il loro lavoro non è compreso affatto. Il termine sicurezza comprende un ambito incredibilmente ampio. Proteggere la tua organizzazione implementando procedure di monitoraggio della conformità e diffondendo la consapevolezza è molto diverso dal proteggere le tue applicazioni attraverso test approfonditi di penetrazione. Richiede competenze completamente diverse. E anche aree apparentemente correlate come la sicurezza della rete e della sicurezza delle applicazioni sono completamente diverse, richiedono competenze, strumenti e un approccio diverso nelle politiche di sicurezza.
La mancanza di comprensione porta a percepire le attività di sicurezza come "quella cosa che controlliamo alla fine" invece di "quella cosa che controlliamo mentre sviluppiamo e consegniamo". Molti professionisti della sicurezza delle organizzazioni attuali provengono da un background di sicurezza della rete e non comprendono veramente il concetto di sicurezza delle applicazioni. Non vedono DevSecOps come realizzabili semplicemente perché pensano principalmente alla sicurezza della rete, non a qualcosa che devi considerare durante lo sviluppo dell'applicazione.
Ancora una volta, è un pensiero spaventoso che molte organizzazioni preferiscano stare all'oscuro della sicurezza, senza pensare alla causa principale di così tante violazioni della sicurezza. Prendi solo il famoso hack di Capital One del 2019 come esempio.
La sicurezza delle informazioni è ancora spesso percepita come un processo manuale. Molte organizzazioni ritengono che la parte fondamentale del test della sicurezza di un'applicazione sia il test di penetrazione manuale. Il lavoro dei penetration tester è spesso associato a strumenti puramente manuali che li aiutano, ad esempio, richieste di cache e invio di payload.
Tuttavia, i servizi di sicurezza del software sono andati ben oltre i test manuali. Proprio come i tecnici della sicurezza della rete non inviano comandi manuali tramite Telnet ma utilizzano scanner automatici, i moderni tecnici della sicurezza delle applicazioni utilizzano strumenti automatizzati per scoprire i problemi più comuni. È la scelta logica per loro, perché poi possono concentrarsi sullo scavare più a fondo in vulnerabilità avanzate - che per la maggior parte degli ingegneri della sicurezza è anche molto più soddisfacente che verificare l'ennesima iniezione SQL di base.
Proprio come i test automatizzati dell'interfaccia utente hanno quasi completamente sostituito i test manuali, ad eccezione di casi speciali, così la scansione automatica delle vulnerabilità ha sostituito la maggior parte dei test di penetrazione manuale, ma i test di penetrazione vengono comunque eseguiti per problemi che non possono essere scoperti automaticamente. Testare manualmente la sicurezza in un silo è moderno quanto fare clic manualmente sull'interfaccia utente dell'applicazione anziché utilizzare Selenium.
Anche se un'organizzazione apprezza l'importanza della sicurezza delle applicazioni e i decisori sono pienamente coinvolti, c'è ancora un problema che ostacola DevSecOps: le capacità limitate di molti strumenti.
Immagina una pipeline DevOps con test automatici che spesso falliscono anche se l'applicazione testata è effettivamente corretta. Immagina quanto tempo occorrerebbe agli sviluppatori per tornare al codice dell'applicazione, rivederlo, assicurarsi che tutto sia a posto, quindi contattare il team di sviluppo del test per correggere i test automatici in modo che non falliscano (o semplicemente, se possibile, , contrassegnare i test manualmente come superati). E immagina la frustrazione se continua a succedere.
Per i test di unità automatizzati, questa non è una situazione comune. Tuttavia, nel mondo della sicurezza delle applicazioni, dove i test vengono spesso eseguiti utilizzando strumenti di analisi del codice (SAST - test di sicurezza delle applicazioni statiche), questo genere di cose accade ogni giorno. E lo sviluppatore alle prese con un falso positivo non può semplicemente chiedere che lo strumento venga corretto dal team di sviluppo del test perché lo strumento è generalmente un'applicazione di terze parti.
Ecco perché i tentativi di introdurre le pratiche DevSecOps tendono a fallire così spesso. I membri del team DevOps potrebbero inizialmente essere entusiasti di introdurre test di sicurezza automatizzati nelle pipeline, ma poi lo implementano utilizzando uno dei molti strumenti di analisi statica commercializzati come la migliore scelta per DevSecOps e scoprono che non funziona perché il numero di false i positivi non sono semplicemente tollerabili. E più grande è l'organizzazione, più grande è la delusione - e maggiore è il rischio che DevSecOps non venga più preso in considerazione.
In parte per mancanza di consapevolezza (vedi motivo 3), i team DevOps spesso si concentrano su SAST come strumento preferito da DevSecOps e non considerano nemmeno DAST come qualcosa che può essere incluso nelle pipeline CI / CD. E la ragione è semplice: la maggior parte degli strumenti DAST non è adatta a DevSecOps semplicemente perché non offre automazione sufficiente.
Gli strumenti DAST sono ancora percepiti come i semplici scanner run-once che erano solo un paio di anni fa. L'uso tradizionale di uno strumento DAST era quello di eseguire una scansione di sicurezza su un'applicazione che è stata distribuita in un ambiente di gestione temporanea e che, ovviamente, non è affatto agile. Immagina cosa succede quando la scansione rileva una vulnerabilità di sicurezza critica: l'applicazione deve tornare al tavolo da disegno e l'intero ciclo agile che ha attraversato deve essere ripetuto.
Tuttavia, non tutti gli strumenti DAST sono semplici scanner. Diversi, come Acunetix , sono ora realizzati per essere integrati direttamente nelle tubazioni CI / CD. Possono lavorare direttamente con strumenti come Jenkins , è possibile impostarli per passare o fallire a seconda del tipo di vulnerabilità rilevata e, soprattutto, superano di gran lunga SAST in termini di accuratezza, prestazioni e portata delle vulnerabilità rilevate.
C'è un piccolo inconveniente di DAST rispetto a SAST: gli strumenti di analisi del codice possono individuare la riga di codice in cui è stato rilevato un problema di sicurezza, mentre DAST non può farlo. Tuttavia, in un tipico ambiente agile, le modifiche al codice e le aggiunte in ogni build sono molto piccole e quindi è molto facile per uno sviluppatore identificare dove si trova il problema nel codice sorgente. Molto spesso, lo sviluppatore che ottiene un rapporto in cui una build ha fallito una scansione di sicurezza DAST è lo stesso sviluppatore che ha introdotto le modifiche in primo luogo. E se ciò non bastasse, alcuni strumenti DAST come Acunetix hanno un'opzione IAST ( AcuSensor ) che combina il meglio dei due mondi al costo di una distribuzione leggermente più complessa.
Come è possibile superare le difficoltà di introduzione dei test di sicurezza direttamente nello sviluppo delle applicazioni?
