Become a partner   | Request Support  | Contact Sales

Diventa Autore per CoreTech | Scopri di più





DevSecOps: come arrivarci da DevOps

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.

Perché DevOps e non DevSecOps?

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:

  1. Fornire un ambiente preconfigurato (ad esempio un contenitore Docker)
  2. Costruire l'applicazione
  3. Distribuzione dell'applicazione nell'ambiente preconfigurato
  4. Esecuzione di test automatizzati sull'applicazione compilata per assicurarsi che soddisfi i requisiti (ad esempio, test dell'interfaccia utente Selenium)

Sembra logico aggiungere un ulteriore passaggio a quella pipeline:

  1. Esecuzione di test di sicurezza automatizzati sull'applicazione compilata per assicurarsi che soddisfi i requisiti di sicurezza.

Ma questo non è il caso nella maggior parte degli ambienti DevOps - ecco perché non sono processi DevSecOps.

Ragioni per non perdere DevSecOps

Esaminiamo i motivi per cui le organizzazioni che implementano con successo DevOps spesso non includono pratiche di sicurezza nei loro processi DevOps.

Motivo 1. Mancanza di consapevolezza della sicurezza

È 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.

Motivo 2. Mancanza di comprensione della sicurezza

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.

Motivo 3. Mancanza di conoscenza dell'automazione della sicurezza

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.

Banner

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.

Motivo 4. Mancanza di fiducia negli strumenti di sicurezza

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.

Motivo 5. Mancanza di comprensione degli strumenti

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.

Banner

La via da seguire per la sicurezza delle applicazioni

Come è possibile superare le difficoltà di introduzione dei test di sicurezza direttamente nello sviluppo delle applicazioni?

  • Informare tutti nella propria organizzazione sull'importanza della sicurezza delle applicazioni. Assicurati che si rendano conto che deve ricevere la stessa attenzione di minacce più diffuse come ransomware e phishing.
  • Informare tutti nella propria organizzazione che la sicurezza della rete e della sicurezza delle applicazioni sono due cose completamente diverse e mentre la sicurezza della rete non ha spazio come parte di DevOps, la sicurezza delle applicazioni deve far parte di DevOps affinché la vostra organizzazione sia veramente agile.
  • Informare tutti nella propria organizzazione che gli strumenti DAST non sono più i semplici scanner di sicurezza che erano solo un paio di anni fa. Assicurarsi che si rendano conto che gli strumenti DAST sono attualmente progettati per essere inclusi nelle pipeline CI / CD e possono svolgere un lavoro molto migliore rispetto agli strumenti SAST in quel ruolo.

Articoli su Acunetix

Trovare le vulnerabilità dei siti web prima degli HackerL'importanza della convalida delle correzioni: lezioni da GoogleSDLC agile e sicuro - Best practiceIn che misura le aziende gestiscono la sicurezza delle applicazioni Web?Cross-Origin Resource Sharing (CORS) e intestazione Access-Control-Allow-OriginCosa sono i reindirizzamenti aperti?DevSecOps: come arrivarci da DevOpsIl bigino su SQL Injection per sviluppatoriSfruttare SSTI in ThymeleafSicurezza nginx: come proteggere la configurazione del serverRafforzamento del sistema Web in 5 semplici passaggiCos'è la sicurezza del sito Web - Come proteggere il tuo sito Web dall'hackingRapporto sulle vulnerabilità delle applicazioni Web Acunetix 2020Perché l'elenco delle directory è pericoloso?Cosa sono gli hack di Google?Cosa è l'attacco BEASTWeb Shells in Action - Rilevazione e prevenzione - parte 5Web Shells in Action - parte 4Mantenere le Web Shells sotto copertura - parte 3Introduzione alle web shell - parte 2: 101 Uso di PHPIntroduzione alle web shell - parte 1Debunking 5 miti sulla postura della sicurezza informaticaIniezioni di NoSQL e come evitarleConfigurazione passo passo di Acunetix con JenkinsCosa sono i riferimenti a oggetti diretti non sicuriAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallAcunetix rilascia Business Logic RecorderCome recuperare un sito Web compromessoCome difendersi dagli hacker Black Hat durante la pandemia COVID-19Che cos'è l'inclusione remota dei file (RFI)?Apache Security - 10 consigli per un'installazione sicuraUn nuovo sguardo sugli attacchi correlati al proxy inversoVulnerabilità delle password comuni e come evitarleTutto quello che devi sapere sugli attacchi Man-in-the-MiddleChe cosa sono le iniezioni HTMLRed Teaming – 5 consigli su come farlo in modo sicuroTesta le tue competenze XSS utilizzando siti vulnerabiliPerché hacker malintenzionati hanno messo gli occhi sugli ospedaliPratiche di codifica sicura – I tre principi chiaveLa maledizione delle vecchie librerie JavaMutation XSS nella ricerca GoogleIgnorare SOP utilizzando la cache del browserCome e perché evitare reindirizzamenti e inoltri non convalidati?Dirottamento di sessione e altri attacchi di sessioneCome abbiamo trovato un altro XSS in Google con AcunetixChe cos'è un buffer overflowChe cos'è l'overflow di IntegerChe cos'è HSTS e perché dovrei usarlo?Che cosa è OS Command InjectionVulnerabilità delle entità esterne XML in Internet ExplorerCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!