Avevamo 2 analizzatori di codice, 4 strumenti per test dinamici, le nostre creazioni e 250 script. Non è che tutto questo fosse necessario nel processo attuale, ma dato che ho iniziato a implementare il DevSecOps, bisogna andare fino in fondo.
. Gli autori dei personaggi: Justin Roiland e Dan Harmon.
Che cos'è il SecDevOps? E il DevSecOps? Quali sono le differenze? Sicurezza delle applicazioni: di cosa si tratta? Perché l'approccio classico non funziona più? A tutte queste domande risponde Yuri Shabalin da Swordfish Security. Yuri risponderà dettagliatamente a tutto e analizzerà i problemi del passaggio dal modello classico di Sicurezza delle Applicazioni al processo DevSecOps: come affrontare correttamente l'integrazione del processo di sviluppo sicuro nel processo DevOps senza rompere nulla, come superare le fasi principali dei test di sicurezza, quali strumenti possono essere utilizzati, in cosa si differenziano e come configurarli correttamente per evitare insidie.
Sul relatore: Yuri Shabalin è Chief Security Architect presso Swordfish Security. Responsabile dell'implementazione dell'SSDL, dell'integrazione generale degli strumenti di analisi delle applicazioni in un'unica ecosistema di sviluppo e test. 7 anni di esperienza nella sicurezza informatica. Ha lavorato in Alfa-Bank, Sberbank e in Positive Technologies, che sviluppa software e fornisce servizi. Relatore a conferenze internazionali ZerONights, PHDays, RISSPA, OWASP.
Sicurezza delle applicazioni: di cosa si tratta?
Sicurezza delle applicazioni — è un ramo della sicurezza che si occupa della sicurezza delle applicazioni. Non riguarda l'infrastruttura o la sicurezza di rete, ma specificamente ciò che scriviamo e su cui lavorano gli sviluppatori: si tratta dei difetti e delle vulnerabilità dell'applicazione stessa.
Direzione — Ciclo di vita dello sviluppo della sicurezza — sviluppato dalla Microsoft. Nello schema, c'è il modello canonico dell'SDLC, il cui obiettivo principale è coinvolgere la sicurezza in ogni fase dello sviluppo, dai requisiti al rilascio e al go-live. Microsoft ha capito che ci sono troppi bug nel mercato, in aumento, e c'era bisogno di fare qualcosa, e ha proposto questo approccio, che è diventato canonico.
La Sicurezza delle Applicazioni e l'SSDL non mirano a scoprire vulnerabilità, come comunemente si pensa, ma a prevenire la loro comparsa. Con il tempo, l'approccio canonico di Microsoft è stato migliorato e sviluppato, con un'immersione più profonda e dettagliata.
Il SDLC canonico è fortemente dettagliato in diverse metodologie: OpenSAMM, BSIMM, OWASP. Le metodologie sono diverse, ma, in generale, simili.
Modello di Maturità per la Sicurezza Integrata
Mi piace di più BSIMM — . La base della metodologia è la suddivisione del processo di Sicurezza delle Applicazioni in 4 domini: Governance, Intelligence, SSDL Touchpoints e Deployment. In ogni dominio ci sono 12 pratiche, presentate sotto forma di 112 attività.
Ogni attività delle 112 ha 3 livelli di maturità: iniziale, intermedio e avanzato. Tutte le 12 pratiche possono essere studiate per sezioni, selezionando gli aspetti più importanti per te, approfondendo come implementarli e aggiungendo gradualmente elementi, ad esempio, analisi statica e dinamica del codice o code review. Redigi un piano e lavora tranquillamente nell'ambito dell'implementazione delle attività selezionate.
Perché DevSecOps
DevOps è un grande processo globale in cui è necessario prendersi cura della sicurezza.
Inizialmente si prevedeva il controllo della sicurezza. Nella pratica, il numero di team di sicurezza era molto inferiore rispetto ad oggi, e agivano non come partecipanti al processo, ma come organo di controllo e supervisione che impone requisiti e verifica la qualità del prodotto alla fine del rilascio. Questo è un approccio classico, in cui i team di sicurezza erano separati dallo sviluppo e non partecipavano al processo.
Il problema principale risiede proprio nel fatto che la sicurezza informatica è separata dallo sviluppo. Di solito, si tratta di un certo contorno di sicurezza informatica con 2-3 strumenti grandi e costosi. Ogni sei mesi arriva il codice sorgente o un'applicazione da controllare, e una volta all'anno vengono eseguiti . Questo porta al risultato che le tempistiche di rilascio si allungano, e agli sviluppatori vengono scaricate una quantità enorme di vulnerabilità dagli strumenti automatizzati. È impossibile gestirle e risolverle, perché i risultati dei precedenti sei mesi non sono stati analizzati, e ora ci sono nuovi problemi.
Nel processo di lavoro della nostra azienda vediamo che la sicurezza in tutti i settori e industrie comprende che è giunto il momento di allinearsi e operare con lo sviluppo come un unico meccanismo - in . La paradigma DevSecOps si adatta perfettamente alla metodologia di sviluppo agile, all'implementazione, supporto e partecipazione in ogni rilascio e iterazione.
Transizione a DevSecOps
La parola più importante nel Ciclo di Vita dello Sviluppo della Sicurezza è «processo». Devi capire questo prima di pensare di acquistare strumenti.
È insufficiente semplicemente integrare gli strumenti nel processo DevOps; è fondamentale l'interazione e la comprensione tra i partecipanti al processo.
Le persone sono più importanti degli strumenti
Spesso la pianificazione di un processo di sviluppo sicuro inizia con la selezione e l'acquisto di uno strumento, e termina con tentativi di integrare lo strumento nel processo corrente, che rimangono tali. Questo porta a conseguenze sfortunate, poiché ogni strumento ha le proprie peculiarità e limitazioni.
Un caso comune è quando il dipartimento di sicurezza sceglie uno strumento buono e costoso, con ampie funzionalità, e si presenta agli sviluppatori per integrarlo nel processo. Ma non funziona: il processo è strutturato in modo tale che le limitazioni dello strumento già acquistato non si adattano all'attuale paradigma.
Inizia descrivendo quale risultato desideri e come dovrebbe apparire il processo. Questo aiuta a comprendere i ruoli dello strumento e della sicurezza nel processo.
Comincia con ciò che è già in uso
Prima di acquistare strumenti costosi, dai un'occhiata a ciò che hai già. Ogni azienda ha requisiti di sicurezza che devono essere rispettati nello sviluppo, ci sono controlli, penetration test - perché non trasformare tutto questo in una forma comprensibile e utile per tutti?
Di solito i requisiti sono un grosso documento cartaceo che giace su uno scaffale. C'era un caso in cui ci siamo recati in un'azienda per esaminare i processi e abbiamo chiesto di mostrare i requisiti di sicurezza per il software. Il professionista che se ne occupava ha cercato a lungo:
— Ora, da qualche parte nelle note c'era il percorso dove si trova questo documento.
Alla fine abbiamo ricevuto il documento dopo una settimana.
Per requisiti, controlli e altro, crea una pagina, ad esempio su Confluence — è comodo per tutti.
È più facile riformattare ciò che già esiste e usarlo come punto di partenza.
Utilizza i Security Champions
Di solito, in una media azienda con 100-200 sviluppatori lavora un esperto di sicurezza che svolge diverse funzioni e non riesce fisicamente a controllare tutto. Anche se si impegna al massimo, da solo non può controllare tutto il codice generato dallo sviluppo. Per tali casi è stato sviluppato un concetto - .
I Security Champions sono persone all'interno del team di sviluppo che sono interessate alla sicurezza del vostro prodotto.
Il Security Champion è un punto di accesso nel team di sviluppo e un evangelista della sicurezza in un'unica persona.
Di solito, quando un esperto di sicurezza entra in un team di sviluppo e indica un errore nel codice, riceve una risposta stupita:
— E lei chi è? La vedo per la prima volta. Va tutto bene per me— il mio Senior ha approvato durante il code review, possiamo andare avanti!
Questa è una situazione tipica, perché c'è molta più fiducia nei confronti dei Senior o semplicemente dei colleghi con cui uno sviluppatore interagisce costantemente nel lavoro e nel code review. Se invece dell'esperto di sicurezza è il Security Champion a segnalare un errore e le sue conseguenze, la sua parola avrà più peso.
Inoltre, gli sviluppatori conoscono meglio il loro codice rispetto a qualsiasi esperto di sicurezza. Per una persona che ha almeno 5 progetti nello strumento di analisi statica, di solito è difficile ricordare tutte le sfumature. I Security Champions conoscono il loro prodotto: come interagisce e cosa guardare per prima cosa— sono più efficaci.
Quindi, prendete in considerazione l'idea di implementare i Security Champions e ampliare l'influenza del team di sicurezza. Anche per il champion stesso è utile: sviluppo professionale in un nuovo campo, ampliamento della visione tecnica, potenziamento delle abilità tecniche, di gestione e di leadership, aumento del valore di mercato. È un elemento di ingegneria sociale, i vostri "occhi" nel team di sviluppo.
Fasi di testing
afferma che il 20% degli sforzi produce l'80% del risultato. Questo 20% sono le pratiche di analisi delle applicazioni che possono e devono essere automatizzate. Esempi di tali attività sono l'analisi statica— SAST, l'analisi dinamica— DAST, e controllo Open Source. Spiegherò in dettaglio le attività e gli strumenti, quali peculiarità incontriamo di solito durante la loro implementazione nel processo e come fare le cose nel modo giusto.
Problemi principali degli strumenti
Metterò in evidenza i problemi attuali per tutti gli strumenti che richiedono attenzione. Li analizzerò in dettaglio, in modo da non ripetermi ulteriormente.
Tempo lungo di analisi. Se dalla commit al rilascio in produzione ci vogliono 30 minuti per tutti i test e la compilazione, allora i controlli sulla sicurezza informatica richiederanno un giorno. Quindi, nessuno rallenterà il processo. Tieni presente questa caratteristica e trai le conclusioni.
Alto livello di False Negative o False Positive. Tutti i prodotti sono diversi, tutti utilizzano framework diversi e il proprio stile di scrittura del codice. Su diverse basi di codice e tecnologie, gli strumenti possono mostrare diversi livelli di False Negative e False Positive. Pertanto, guarda cosa mostra precisamente la vostra azienda e per le vostre
applicazioni un buon e affidabile risultato.Nessuna integrazione con gli strumenti esistenti.
Guarda gli strumenti dal punto di vista delle integrazioni, rispetto a ciò che già utilizzi. Ad esempio, se hai Jenkins o TeamCity, controlla l'integrazione degli strumenti proprio con questo software, e non con GitLab CI, che non usi. Mancanza o eccessiva complessità di personalizzazione.
Se lo strumento non ha API, a cosa serve? Tutto ciò che è possibile fare nell'interfaccia dovrebbe essere accessibile tramite API. Idealmente, lo strumento dovrebbe avere la possibilità di personalizzare i controlli. Nessuna Roadmap per lo sviluppo del prodotto. Lo sviluppo non sta fermo, utilizziamo sempre nuovi framework e funzionalità, riscriviamo il vecchio codice in nuovi linguaggi. Vogliamo essere certi che lo strumento che acquisteremo supporterà nuovi framework e tecnologie. Quindi è importante sapere che il prodotto ha uno sviluppo reale e corretto.
Caratteristiche del processo
Oltre alle caratteristiche degli strumenti, considera anche le peculiarità del processo di sviluppo. Ad esempio, ostacolare lo sviluppo è un errore comune. Vediamo quali altre caratteristiche dovrebbero essere considerate e su cosa deve prestare attenzione il team di sicurezza.
Per non ritardare i tempi di sviluppo e di rilascio, crea diverse regole e diversi show stoppers — criteri di arresto del processo di compilazione in presenza di vulnerabilità — per diversi ambienti.Ad esempio, comprendiamo che il ramo attuale va in ambiente di sviluppo o UAT, quindi non ci fermiamo e non diciamo:
— Avete delle vulnerabilità qui, non potrete andare avanti!
In questa fase è importante informare gli sviluppatori che ci sono problemi di sicurezza a cui vale la pena prestare attenzione.
La presenza di vulnerabilità non è un ostacolo per i test successivi: manuali, di integrazione o manuali. D'altra parte, dobbiamo in qualche modo migliorare la sicurezza del prodotto e fare in modo che gli sviluppatori non trascurino ciò che la sicurezza trova. Quindi, a volte procediamo in questo modo: nella demo, quando viene rilasciato nell'ambiente di sviluppo, informiamo semplicemente lo sviluppo:
— Ragazzi, avete dei problemi, per favore fateci caso.
Nella fase UAT mostriamo nuovamente gli avvisi sulle vulnerabilità, e nella fase di uscita in produzione diciamo:
— Ragazzi, abbiamo avvertito più volte, non avete fatto nulla — non vi lasceremo uscire con questo.
Parlando di codice e dinamica, è necessario mostrare e avvisare sulle vulnerabilità solo delle funzionalità e del codice che sono stati appena scritti in questa funzionalità. Se lo sviluppatore ha spostato un pulsante di 3 pixel e noi gli diciamo che ha un’iniezione SQL e che deve correggerlo urgentemente, non è corretto. Guardate solo ciò che è scritto ora e il cambiamento che arriva nell'applicazione.
Supponiamo che abbiamo un certo difetto funzionale: ovvero come l'applicazione non dovrebbe funzionare: il denaro non viene trasferito, non c'è transizione alla pagina successiva cliccando sul pulsante o il prodotto non viene caricato. I difetti di sicurezza — sono difetti simili, ma non in relazione al funzionamento dell'applicazione, ma alla sicurezza.
Non tutti i problemi di qualità del software sono problemi di sicurezza. Ma tutti i problemi di sicurezza sono legati alla qualità del software. Sherif Mansour, Expedia.
Poiché tutte le vulnerabilità sono difetti simili, devono trovarsi là dove si trovano tutti i difetti di sviluppo. Quindi dimenticate i report e i terribili PDF che nessuno legge.
Quando lavoravo in un'azienda che si occupava di sviluppo, ho ricevuto un report dagli strumenti di analisi statica. L'ho aperto, sono rimasto scioccato, ho fatto un caffè, ho sfogliato 350 pagine, l'ho chiuso e sono tornato a lavorare. Grandi report sono report morti. Di solito non vanno da nessuna parte, le email vengono eliminate, dimenticate, perse o il business dice che accetta i rischi.
Cosa fare? I difetti confermati che abbiamo trovato vengono semplicemente trasformati in una forma utile per lo sviluppo, ad esempio, li accumuliamo nel backlog di Jira. I difetti vengono prioritizzati e risolti in base all'ordine di priorità insieme ai difetti funzionali e ai difetti dei test.
Analisi statica - SAST
È l'analisi del codice per identificare vulnerabilità, ma non è la stessa cosa di SonarQube. Non controlliamo solo in base a modelli o stili. Durante l'analisi vengono applicati vari approcci: basati sull'albero delle vulnerabilità, su , sull'analisi dei file di configurazione. Questo è tutto ciò che riguarda direttamente il codice.
Vantaggi dell'approccio: identificazione delle vulnerabilità nel codice in una fase iniziale dello sviluppo, quando non ci sono ancora ambienti e strumenti pronti, e possibilità di scansione incrementale: scansione della porzione di codice che è cambiata, e solo della funzionalità che stiamo attualmente sviluppando, il che riduce il tempo di scansione.
Contro — è l'assenza di supporto per i linguaggi necessari.
Integrazioni necessarie, che dovrebbero esserci negli strumenti, secondo il mio parere soggettivo:
- Strumenti di integrazione: Jenkins, TeamCity e Gitlab CI.
- Ambiente di sviluppo: Intellij IDEA, Visual Studio. È più comodo per lo sviluppatore non dover navigare in un'interfaccia poco chiara da memorizzare, ma vedere direttamente nel proprio ambiente di sviluppo tutto il necessario, comprese le integrazioni e le vulnerabilità che ha trovato.
- Revisione del codice: SonarQube e revisione manuale.
- Tracker dei difetti: Jira e Bugzilla.
Nell'immagine ci sono alcuni dei migliori rappresentanti dell'analisi statica.
Non sono gli strumenti a essere importanti, ma il processo, quindi esistono soluzioni Open Source che sono altrettanto buone per testare il processo.
SAST Open Source non troverà un'enorme quantità di vulnerabilità o flussi di dati complessi, ma nella costruzione del processo possono e devono essere utilizzate. Aiutano a capire come sarà costruito il processo, chi risponderà ai bug, chi farà report, chi dovrà rendere conto. Se volete avviare la fase iniziale della sicurezza del vostro codice, utilizzate soluzioni Open Source.
Come si può integrare, se siete all'inizio del percorso, e non avete nulla: né CI, né Jenkins, né TeamCity? Esaminiamo le integrazioni nel processo.
Integrazione a livello CVS
Se avete Bitbucket o GitLab, potete fare un'integrazione a livello .
In base all'evento — pull request, commit. Scansionate il codice e nel status del build indicate se il controllo di sicurezza è andato a buon fine o meno.
Feedback. Assolutamente, il feedback è sempre necessario. Se eseguite semplicemente l'analisi da parte della sicurezza, lo mettete in una scatola e non ne parlate con nessuno, e poi alla fine del mese esce un sacco di bug - non è corretto e non è buono.
Integrazione con il sistema di code review
Una volta, abbiamo impostato come revisore predefinito un utente tecnico AppSec in una serie di progetti importanti. A seconda che vengano rilevati errori nel nuovo codice o meno, il revisore del pull request assegna lo stato su 'accettare' o 'necessita di lavoro' - o tutto è OK, o è necessario fare delle modifiche e link a cosa esattamente modificare. Per l'integrazione con la versione in produzione, avevamo impostato il divieto di merge, se il test di sicurezza non era stato superato. Questo veniva incluso nella revisione manuale del codice, e gli altri partecipanti al processo vedevano gli stati di sicurezza specificamente per questo processo.
Integrazione con SonarQube
Molti hanno per la qualità del codice. Qui è lo stesso - è possibile fare le stesse gates solo per gli strumenti SAST. Avrà lo stesso interfaccia, lo stesso quality gate, solo che si chiamerà security gate. E anche qui, se avete impostato un processo utilizzando SonarQube, potete integrare tutto senza problemi.
Integrazione a livello di CI
Qui è tutto abbastanza semplice:
- A un livello con i test automatici, test unitari.
- Divisione nelle fasi dello sviluppo: dev, test, prod. Possono essere inclusi diversi set di regole, oppure diverse condizioni di fallimento: fermiamo la compilazione, non fermiamo la compilazione.
- Esecuzione sincrona/asincrona. Attendiamo il completamento del controllo dei test di sicurezza o non lo facciamo. Cioè, li abbiamo avviati e andiamo avanti, e poi riceviamo lo stato che tutto è buono o cattivo.
Questo è tutto in un ideale mondo rosa. Nella vita reale non esiste, ma ci stiamo provando. Il risultato delle verifiche di sicurezza dovrebbe essere analogo ai risultati dei test unitari.
Ad esempio, abbiamo preso un grande progetto e abbiamo deciso che ora utilizzeremo SAST per analizzarlo - va bene. Abbiamo inserito questo progetto in SAST, e ci ha restituito 20.000 vulnerabilità, e con una decisione ferma abbiamo accettato che andasse tutto bene. 20.000 vulnerabilità rappresentano il nostro debito tecnico. Metteremo il debito in una scatola, lo gestiremo progressivamente e registreremo bug nei tracker dei difetti. Assumeremo una società, faremo tutto noi stessi o ci aiuteranno i Security Champions - e il debito tecnico si ridurrà.
Tutte le nuove vulnerabilità nel codice devono essere corrette come gli errori nei test unitari o nei test automatici. In altre parole, una volta avviata la build, si eseguono i test e se due test falliscono, ed anche due test di sicurezza. Va bene - andiamo a vedere cosa è successo, correggiamo il primo, correggiamo il secondo, la prossima volta ricontrolliamo - tutto bene, non ci sono nuove vulnerabilità, i test non sono falliti. Se il problema è più profondo e necessita di un'analisi accurata, o la correzione delle vulnerabilità coinvolge parti significative di ciò che sta sotto il cofano: registriamo un bug nel tracker dei difetti, viene prioritizzato e corretto. Sfortunatamente, il mondo non è perfetto e i test a volte falliscono.
Esempio di security gate - analogo al quality gate, relativo alla presenza e al numero di vulnerabilità nel codice.
Integriamo con SonarQube - il plugin si installa, tutto molto comodo e fantastico.
Integrazione con l'ambiente di sviluppo
Possibilità di integrazione:
- Avvio della scansione dall'ambiente di sviluppo ancora prima del commit.
- Visualizzazione dei risultati.
- Analisi dei risultati.
- Sincronizzazione con il server.
Ecco come appare l'ottenimento dei risultati dal server.
Nel nostro ambiente di sviluppo compare semplicemente un'opzione aggiuntiva che informa che durante la scansione sono state rilevate tali vulnerabilità. È possibile modificare il codice immediatamente, guardare le raccomandazioni e . Tutto ciò è situato nella postazione di lavoro dello sviluppatore, il che è molto comodo - non è necessario navigare tra ulteriori collegamenti per cercare qualcosa di aggiuntivo.
Open Source
Questo è il mio argomento preferito. Tutti usano librerie Open Source - perché scrivere un sacco di soluzioni artigianali quando puoi semplicemente utilizzare una libreria già pronta in cui è tutto già implementato?
Certo, è così, ma anche le biblioteche sono scritte da persone, comportano determinati rischi e presentano vulnerabilità di cui viene riferito periodicamente, o costantemente. Pertanto, il passo successivo nella Sicurezza delle Applicazioni è l'analisi dei componenti Open Source.
Analisi Open Source - OSA
Lo strumento comprende tre grandi fasi.
Ricerca di vulnerabilità nelle librerie. Ad esempio, lo strumento sa che stiamo utilizzando una certa libreria e che in o nei bug tracker ci sono delle vulnerabilità relative a questa versione della libreria. Quando si tenta di utilizzarla, lo strumento emetterà un avviso che informa della vulnerabilità della libreria e consiglia di usare un'altra versione priva di vulnerabilità.
Analisi della conformità delle licenze. Per ora non è molto popolare da noi, ma se si lavora con l'estero, può capitare di ricevere una reprimenda per l'uso di un componente open source che non può essere utilizzato o modificato. Secondo la politica di licenza della libreria, non possiamo farlo. Oppure, se l'abbiamo modificata e la usiamo, dobbiamo pubblicare il nostro codice. Naturalmente, nessuno vuole pubblicare il codice dei propri prodotti, ma ci sono modi per tutelarsi da questo.
Analisi dei componenti utilizzati in ambito industriale. Immaginiamo una situazione ipotetica in cui abbiamo finalmente completato lo sviluppo e rilasciato l'ultima versione del nostro microservizio. Vive lì magnificamente - una settimana, un mese, un anno. Non lo raccogliamo, non facciamo controlli di sicurezza, sembra che tutto vada bene. Ma improvvisamente, dopo due settimane dal rilascio, viene scoperta una vulnerabilità critica in un componente open source che stiamo utilizzando proprio in questa build, nell'ambiente industriale. Se non stiamo registrando ciò che utilizziamo e dove lo utilizziamo, non vedremo semplicemente questa vulnerabilità. Alcuni strumenti offrono la possibilità di monitorare le vulnerabilità nelle librerie attualmente utilizzate nell'ambiente industriale. È molto utile.
Funzionalità:
- Diverse politiche per diverse fasi dello sviluppo.
- Monitoraggio dei componenti nell'ambiente industriale.
- Controllo delle librerie all'interno della rete dell'organizzazione.
- Supporto per diversi sistemi di build e linguaggi.
- Analisi delle immagini Docker.
Alcuni esempi di leader nel settore che si occupano di analisi Open Source.
L'unico gratuito tra questi è da OWASP. Può essere attivato nelle prime fasi per vedere come funziona e cosa supporta. Fondamentalmente, sono tutti prodotti cloud, oppure on-premise, ma i dati vengono comunque inviati su internet. Non vengono inviati le vostre librerie, ma hash o i propri valori calcolati, e le fingerprint al proprio server, per ricevere notifiche sulla presenza di vulnerabilità.
Integrazione nel processo
Controllo delle librerie nel perimetro, che vengono scaricate da fonti esterne. Abbiamo repository esterni e interni. Ad esempio, all'interno di Event Central c'è Nexus, e vogliamo assicurarci che nel nostro repository interno non ci siano vulnerabilità con stato "critico" o "alto". È possibile configurare il proxying utilizzando lo strumento Nexus Firewall Lifecycle in modo che tali vulnerabilità vengano bloccate e non entrino nel repository interno.
Integrazione nel CI. A un livello con test automatici, test unitari e separazione per fasi di sviluppo: dev, test, prod. In ogni fase è possibile scaricare qualsiasi libreria, utilizzare ciò che si desidera, ma se ci sono elementi critici con stato "critical" - potrebbe essere utile portare l'attenzione degli sviluppatori su questo al momento del rilascio in produzione.
Integrazione con artefatti: Nexus e JFrog.
Integrazione nell'ambiente di sviluppo. Gli strumenti che scegliete devono avere integrazione con gli ambienti di sviluppo. Lo sviluppatore deve avere accesso ai risultati della scansione dal proprio posto di lavoro, oppure la possibilità di eseguire autonomamente una scansione e controllare il codice per la presenza di vulnerabilità prima del commit in CVS.
Integrazione nel CD. Questa è una funzionalità interessante che mi piace molto e di cui ho già parlato - il monitoraggio dell'emergere di nuove vulnerabilità nell'ambiente produttivo. Funziona più o meno così.
Abbiamo Public Component Repositories — alcuni strumenti esterni e il nostro repository interno. Vogliamo che contenga solo componenti trusted. Durante il proxying della richiesta verifichiamo che la libreria scaricata non abbia vulnerabilità. Se rientra in determinate politiche che stabilisco e che necessariamente concordiamo con gli sviluppatori, non la scarichiamo e arriva una notifica per utilizzare una versione diversa. Di conseguenza, se nella libreria c'è qualcosa di realmente critico e problematico, l'autore non riceverà la libreria già in fase di installazione - dovrà usare una versione superiore o inferiore.
- Durante il build controlliamo che nessuno abbia infilato qualcosa di male, che tutti i componenti siano sicuri e che nessuno porti sul dispositivo USB qualcosa di pericoloso.
- Nel repository abbiamo solo componenti trusted.
- Durante il deploy verifichiamo ancora una volta il pacchetto stesso: war, jar, DL o un'immagine Docker per assicurarci che sia conforme alla politica.
- All'uscita in produzione monitoriamo ciò che accade nell'ambiente di produzione: se emergono o meno vulnerabilità critiche.
Analisi dinamica - DAST
Gli strumenti di analisi dinamica sono radicalmente diversi da tutto ciò che è stato detto finora. È una simulazione del lavoro dell'utente con l'applicazione. Se si tratta di un'applicazione web, inviamo richieste simulando l'operato del cliente, facciamo clic su pulsanti nel front-end, inviamo dati artificiali dai moduli: virgolette, parentesi, simboli in varie codifiche, per osservare come l'applicazione funziona e gestisce dati esterni.
Questo sistema consente anche di controllare vulnerabilità tipiche nell'Open Source. Poiché DAST non conosce quali Open Source utilizziamo, invia semplicemente modelli "maligni" e analizza le risposte del server:
— Aha, qui c'è un problema di deserializzazione, e qui no.
Ci sono grossi rischi, perché se esegui questo test di sicurezza sulla stessa piattaforma utilizzata dai tester - possono verificarsi cose indesiderate.
- Alto carico sulla rete del server dell'applicazione.
- Nessuna integrazione.
- Possibilità di modificare le impostazioni dell'applicazione in analisi.
- Nessun supporto per le tecnologie necessarie.
- Difficoltà di configurazione.
Abbiamo avuto una situazione in cui finalmente abbiamo avviato AppScan: abbiamo faticato a ottenere accesso all'applicazione, abbiamo ricevuto 3 credenziali e ci siamo felici - finalmente possiamo controllare tutto! Abbiamo avviato la scansione e la prima cosa che ha fatto AppScan è stata entrare nel pannello di amministrazione, ha cliccato su tutti i pulsanti, ha cambiato metà dei dati e poi ha addirittura bloccato il server con le sue -richieste. Sviluppo con test hanno detto:
— Ragazzi, state scherzando?! Vi abbiamo dato le credenziali e voi avete bloccato il server!
Tenete presente i rischi potenziali. Idealmente, preparate un ambiente di test separato per la sicurezza delle informazioni, che sarà isolato dal resto dell'ambiente in qualche modo, e sarebbe preferibile controllare il pannello di controllo manualmente. Questo è un pentest - quei rimanenti percentuali di sforzi che attualmente non stiamo considerando.
Vale la pena considerare che si può usare questo come un'analogia per i test di carico. Nella prima fase, si può attivare uno scanner dinamico in 10-15 flussi e vedere cosa succede, ma di solito, come mostra la pratica, non viene fuori nulla di buono.
Qualche risorsa che di solito usiamo.
Vale la pena menzionare — è il "coltello svizzero" per qualsiasi specialista della sicurezza. Viene usato da tutti ed è molto comodo. È uscita una nuova versione demo della enterprise edition. Se prima era solo un'utilità stand alone con plugin, ora finalmente gli sviluppatori stanno realizzando un grande server da cui si potranno gestire più agenti. È fantastico, consiglio di provarlo.
Integrazione nel processo
L'integrazione avviene in modo abbastanza semplice: avvio della scansione dopo l'installazione riuscita dell'applicazione sul server e scansione dopo aver completato con successo i test di integrazione.
Se le integrazioni non funzionano o ci sono dei mock e funzioni fittizie, questo è inutile e non ha senso: qualsiasi modello inviamo, il server risponderà sempre allo stesso modo.
- Ideale sarebbe avere un ambiente di test separato.
- Prima di iniziare i test, registrate la sequenza di login.
- Il test del sistema di amministrazione è solo manuale.
Processo
Un po' in generale sul processo e sul funzionamento di ciascun strumento, in particolare. Tutte le applicazioni sono diverse: in una, l'analisi dinamica funziona meglio, in un'altra quella statica, in un'altra ancora l'analisi OpenSource, i pentest o davvero qualcosa di diverso, ad esempio, eventi di .
Ogni processo ha bisogno di controllo.
Per capire come funziona il processo e dove può essere migliorato, è necessario raccogliere metriche da tutto ciò che è raggiungibile, comprese le metriche di produzione, le metriche degli strumenti e dai defect tracker.
Qualsiasi dato è utile. È importante esaminare da diverse prospettive dove ciascuno strumento è meglio utilizzato e dove il processo presenta dei punti deboli. Potrebbe essere utile osservare i tempi di risposta dello sviluppo per capire dove migliorare il processo basandosi sui tempi. Più dati si raccolgono, più prospettive possono essere costruite, dai livelli più alti fino ai dettagli di ogni processo.
Poiché ogni analizzatore statico e dinamico ha le proprie API, i propri metodi di avvio e principi, alcuni hanno scheduler mentre altri no, stiamo scrivendo uno strumento AppSec Orchestrator, che consente di creare un'unica interfaccia per l'intero processo del prodotto e gestirlo da un unico punto.
I manager, gli sviluppatori e gli ingegneri della sicurezza hanno un unico punto di accesso da cui possono vedere cosa è stato avviato, configurare e avviare la scansione, ottenere i risultati della scansione e presentare requisiti. Ci sforziamo di allontanarci dalla carta, traducendo tutto in un linguaggio umano, quello utilizzato dagli sviluppatori: pagine su Confluence con stati e metriche, difetti in Jira o in vari defect tracker, oppure incorporare nel processo sincrono/asincrono in CI/CD.
Key Takeaways
Gli strumenti non sono la cosa principale. Prima si deve pensare al processo, poi implementare gli strumenti. Gli strumenti sono utili, ma costosi, quindi si può iniziare con il processo e impostare l'interazione e la comprensione tra sviluppo e sicurezza. Dal punto di vista della sicurezza, non è necessario 'fermare' tutto indiscriminatamente, mentre dal punto di vista dello sviluppo, se c'è qualcosa di altamente critico, è necessario affrontarlo e non ignorare il problema.
Qualità del prodotto — è l'obiettivo comune sia per la sicurezza che per lo sviluppo. Facciamo lo stesso lavoro, cercando di garantire che tutto funzioni correttamente e che non ci siano rischi reputazionali o perdite finanziarie. È per questo che promuoviamo l'approccio DevSecOps, SecDevOps, per migliorare la comunicazione e rendere il prodotto di qualità superiore.
Iniziate da ciò che è già presente: requisiti, architettura, controlli parziali, formazione, linee guida. Non è necessario applicare subito tutte le pratiche a tutti i progetti — procedi in modo iterativo. Non esiste uno standard unico — sperimenta e prova diversi approcci e soluzioni.
Tra i difetti di sicurezza informatica e i difetti funzionali c'è un segno di uguaglianza.
Automatizza tutto, ciò che si muove. Tutto ciò che non si muove — fai in modo che si muova e automatizzalo. Se qualcosa viene fatto manualmente, non è una buona parte del processo. Potrebbe valere la pena riesaminarlo e automatizzarlo anche.
Se la dimensione del team di sicurezza informatica è piccola — usa i Security Champions.
È possibile che ciò di cui ti ho parlato non sia adatto a te e che tu ne inventi uno tuo — ed è tutto corretto. Ma scegli gli strumenti in base ai requisiti del tuo processo specifico. Non guardare a cosa dice la community, riguardo a quali strumenti sono scadenti e quali sono buoni. Potrebbe darsi che proprio nel tuo prodotto sia il contrario.
Requisiti per gli strumenti.
- Basso tasso di falsi positivi.
- Tempo di analisi adeguato.
- Usabilità.
- Disponibilità di integrazioni.
- Comprensione del piano di sviluppo del prodotto.
- Possibilità di personalizzazione degli strumenti.
La presentazione di Yuri è stata scelta tra le migliori al DevOpsConf 2018. Per scoprire un numero ancora maggiore di idee interessanti e casi pratici, vieni il 27 e 28 maggio a Skolkovo per nell'ambito di . E ancora meglio, se sei pronto a condividere la tua esperienza, allora per una presentazione entro il 21 aprile.
Fonte: habr.com
