Avevamo 2 analizzatori di codice, 4 strumenti di test dinamici, le nostre creazioni e 250 script. Non è che tutto questo sia necessario nel processo attuale, ma una volta che inizi a implementare DevSecOps, devi arrivare fino alla fine.
. Creatori dei personaggi: Justin Roiland e Dan Harmon.
Cos'è SecDevOps? E che dire di DevSecOps? Quali sono le differenze? Sicurezza delle applicazioni: di cosa si tratta? Perché l’approccio classico non funziona più? Conosce la risposta a tutte queste domande Yuri Shabalin di Sicurezza del pesce spada. Yuri risponderà a tutto in dettaglio e analizzerà i problemi della transizione dal classico modello di Application Security al processo DevSecOps: come affrontare correttamente l'integrazione del processo di sviluppo sicuro nel processo DevOps senza interrompere nulla, come attraversare le fasi principali dei test di sicurezza, quali strumenti possono essere utilizzati, in cosa differiscono e come configurarli correttamente per evitare insidie.
Informazioni sull'oratore: Yuri Shabalin- Capo Architetto della Sicurezza in azienda Sicurezza del pesce spada. Responsabile dell'implementazione di SSDL, per l'integrazione complessiva degli strumenti di analisi delle applicazioni in un ecosistema di sviluppo e test unificato. 7 anni di esperienza nella sicurezza informatica. Ha lavorato presso Alfa-Bank, Sberbank e Positive Technologies, che sviluppa software e fornisce servizi. Relatore a convegni internazionali ZerONights, PHDays, RISSPA, OWASP.
Sicurezza delle applicazioni: di cosa si tratta?
Application Security - Questa è la sezione di sicurezza responsabile della sicurezza dell'applicazione. Ciò non si applica all'infrastruttura o alla sicurezza della rete, ma piuttosto a ciò che scriviamo e su cui lavorano gli sviluppatori: queste sono le carenze e le vulnerabilità dell'applicazione stessa.
Direzione - Ciclo di vita dello sviluppo della sicurezza - sviluppato da Microsoft. Il diagramma mostra il modello SDLC canonico, il cui compito principale è la partecipazione della sicurezza in ogni fase dello sviluppo, dai requisiti al rilascio e alla produzione. Microsoft si rese conto che c'erano troppi bug nel settore, ce n'erano di più e bisognava fare qualcosa al riguardo, e propose questo approccio, che è diventato canonico.
Application Security e SSDL non hanno lo scopo di rilevare le vulnerabilità, come comunemente si crede, ma di prevenirne il verificarsi. Nel corso del tempo, l'approccio canonico di Microsoft è stato migliorato, sviluppato e introdotto in un'analisi più approfondita e dettagliata.
L'SDLC canonico è altamente dettagliato in varie metodologie: OpenSAMM, BSIMM, OWASP. Le metodologie sono diverse, ma generalmente simili.
Costruire la sicurezza nel modello di maturità
Mi piace di più BSIMM - . Alla base della metodologia c’è la suddivisione del processo di Application Security in 4 domini: Governance, Intelligence, Touchpoint SSDL e Deployment. Ogni dominio ha 12 pratiche, rappresentate come 112 attività.
Ognuna delle 112 attività ha 3 livelli di maturità: principiante, intermedio e avanzato. Puoi studiare tutte le 12 pratiche sezione per sezione, selezionare le cose che sono importanti per te, capire come implementarle e aggiungere gradualmente elementi, ad esempio analisi del codice statico e dinamico o revisione del codice. Scrivi un piano e lavori con calma secondo esso come parte dell'implementazione delle attività selezionate.
Perché DevSecOps
DevOps è un processo generale e ampio in cui è necessario tenere conto della sicurezza.
Inizialmente prevedevano controlli di sicurezza. In pratica, il numero dei team di sicurezza era molto inferiore rispetto ad adesso, e non agivano come partecipanti al processo, ma come un organismo di controllo e supervisione che gli impone dei requisiti e verifica la qualità del prodotto al termine del rilascio. Questo è un approccio classico in cui i team di sicurezza erano dietro il muro dello sviluppo e non partecipavano al processo.
Il problema principale è che la sicurezza delle informazioni è separata dallo sviluppo. Di solito si tratta di una sorta di circuito di sicurezza delle informazioni e contiene 2-3 strumenti grandi e costosi. Una volta ogni sei mesi arriva il codice sorgente o l'applicazione da controllare e una volta all'anno vengono prodotti . Tutto ciò porta al fatto che la data di rilascio per il settore viene ritardata e lo sviluppatore è esposto a un numero enorme di vulnerabilità derivanti dagli strumenti automatizzati. È impossibile smontare e riparare tutto questo, perché i risultati dei sei mesi precedenti non sono stati risolti, ma ecco un nuovo lotto.
Nel corso del lavoro della nostra azienda, vediamo che la sicurezza in tutte le aree e settori comprende che è tempo di recuperare il ritardo e girare con lo sviluppo sulla stessa ruota - in . Il paradigma DevSecOps si adatta perfettamente alla metodologia di sviluppo agile, all'implementazione, al supporto e alla partecipazione in ogni rilascio e iterazione.
Transizione a DevSecOps
La parola più importante nel ciclo di vita dello sviluppo della sicurezza è "processi". Devi capirlo prima di pensare all'acquisto di strumenti.
Integrare semplicemente gli strumenti nel processo DevOps non è sufficiente: è importante la comunicazione e la comprensione tra i partecipanti al processo.
Sono più importanti le persone, non gli strumenti.
Spesso, la pianificazione di un processo di sviluppo sicuro inizia con la scelta e l'acquisto di uno strumento e termina con i tentativi di integrare lo strumento nel processo attuale, che rimangono tentativi. Ciò porta a conseguenze spiacevoli, perché tutti gli strumenti hanno le proprie caratteristiche e limiti.
Un caso comune è quando il dipartimento di sicurezza sceglie uno strumento valido e costoso con ampie funzionalità e si rivolge agli sviluppatori per integrarlo nel processo. Ma non funziona: il processo è strutturato in modo tale che i limiti dello strumento già acquistato non si adattano al paradigma attuale.
Innanzitutto, descrivi quale risultato desideri e come sarà il processo. Ciò aiuterà a comprendere i ruoli dello strumento e della sicurezza nel processo.
Inizia con ciò che è già in uso
Prima di acquistare strumenti costosi, guarda cosa hai già. Ogni azienda ha requisiti di sicurezza per lo sviluppo, ci sono controlli, pentest: perché non trasformare tutto questo in una forma comprensibile e conveniente per tutti?
Di solito i requisiti sono un Talmud cartaceo che giace su uno scaffale. C'è stato un caso in cui siamo andati in un'azienda per esaminare i processi e abbiamo chiesto di vedere i requisiti di sicurezza per il software. Lo specialista che si è occupato di questo ha dedicato molto tempo alla ricerca di:
- Ora, da qualche parte negli appunti c'era un percorso dove si trova questo documento.
Di conseguenza, abbiamo ricevuto il documento una settimana dopo.
Per requisiti, controlli e altro, crea una pagina ad es. Confluenza - conviene a tutti.
È più semplice riformattare ciò che hai già e utilizzarlo per iniziare.
Utilizza campioni di sicurezza
Di solito, in un'azienda media con 100-200 sviluppatori, c'è uno specialista della sicurezza che svolge diverse funzioni e non ha fisicamente il tempo di controllare tutto. Anche se fa del suo meglio, da solo non controllerà tutto il codice generato dallo sviluppo. Per questi casi è stato sviluppato un concetto: .
I Security Champions sono persone all'interno del team di sviluppo interessate alla sicurezza del tuo prodotto.
Security Champion è un punto di ingresso nel team di sviluppo e allo stesso tempo un evangelista della sicurezza.
Di solito, quando uno specialista della sicurezza si presenta al team di sviluppo e segnala un errore nel codice, riceve una risposta sorpresa:
- E chi sei tu? Ti vedo per la prima volta. Per me va tutto bene: il mio amico senior mi ha dato "applica" per la revisione del codice, andiamo avanti!
Questa è una situazione tipica, perché c'è molta più fiducia nei senior o semplicemente nei compagni di squadra con cui lo sviluppatore interagisce costantemente nel lavoro e nella revisione del codice. Se invece del responsabile della sicurezza, il Campione della Sicurezza segnala l’errore e le conseguenze, allora la sua parola avrà più peso.
Inoltre, gli sviluppatori conoscono il loro codice meglio di qualsiasi specialista della sicurezza. Per una persona che ha almeno 5 progetti in uno strumento di analisi statica, di solito è difficile ricordarne tutte le sfumature. I campioni della sicurezza conoscono il loro prodotto: cosa interagisce con cosa e cosa guardare per primo: sono più efficaci.
Considera quindi l'implementazione di Security Champions e l'espansione dell'influenza del tuo team di sicurezza. Questo è utile anche per il campione stesso: sviluppo professionale in un nuovo campo, ampliando i propri orizzonti tecnici, migliorando le capacità tecniche, manageriali e di leadership, aumentando il valore di mercato. Questo è un elemento di ingegneria sociale, i tuoi "occhi" nel team di sviluppo.
Fasi di test
dice che il 20% dell'impegno produce l'80% dei risultati. Questo 20% è costituito da pratiche di analisi delle applicazioni che possono e devono essere automatizzate. Esempi di tali attività sono l'analisi statica - SAST, analisi dinamica - DAST и Controllo Open Source. Ti parlerò più in dettaglio delle attività, degli strumenti, delle caratteristiche che di solito incontriamo quando le introduciamo nel processo e come farlo correttamente.
Principali problemi degli strumenti
Evidenzierò i problemi che sono rilevanti per tutti gli strumenti e richiedono attenzione. Li analizzerò più in dettaglio per non ripeterli ulteriormente.
Tempo di analisi lungo. Se dal commit al rilascio sono necessari 30 minuti per tutti i test e l'assemblaggio, i controlli di sicurezza delle informazioni richiederanno un giorno. Quindi nessuno rallenterà il processo. Prendi in considerazione questa caratteristica e trai le conclusioni.
Falso negativo o falso positivo di alto livello. Tutti i prodotti sono diversi, tutti utilizzano framework diversi e il proprio stile di codifica. Su diverse basi di codice e tecnologie, gli strumenti possono mostrare diversi livelli di falso negativo e falso positivo. Quindi guarda cosa c'è esattamente dentro il tuo aziende e per la tua le applicazioni mostreranno risultati buoni e affidabili.
Nessuna integrazione con gli strumenti esistenti. Guarda gli strumenti in termini di integrazioni con ciò che già usi. Ad esempio, se hai Jenkins o TeamCity, controlla l'integrazione degli strumenti con questo software e non con GitLab CI, che non usi.
Mancanza o eccessiva complessità di personalizzazione. Se uno strumento non dispone di un'API, perché è necessaria? Tutto ciò che può essere fatto nell'interfaccia dovrebbe essere disponibile tramite l'API. Idealmente, lo strumento dovrebbe avere la capacità di personalizzare i controlli.
Nessuna tabella di marcia per lo sviluppo del prodotto. Lo sviluppo non si ferma, utilizziamo sempre nuovi framework e funzioni, riscrivendo il vecchio codice in nuovi linguaggi. Vogliamo essere sicuri che lo strumento che acquistiamo supporti nuovi framework e tecnologie. Pertanto, è importante sapere che il prodotto è reale e corretto sviluppo.
Funzionalità di processo
Oltre alle caratteristiche degli strumenti, prendere in considerazione le caratteristiche del processo di sviluppo. Ad esempio, ostacolare lo sviluppo è un errore comune. Diamo un'occhiata a quali altre funzionalità dovrebbero essere prese in considerazione e a cosa dovrebbe prestare attenzione il team di sicurezza.
Per non perdere le scadenze di sviluppo e rilascio, crea regole diverse e diverso mostrare i tappi — criteri per interrompere il processo di compilazione in presenza di vulnerabilità — per ambienti diversi. Ad esempio, comprendiamo che il ramo attuale va allo stand di sviluppo o UAT, il che significa che non ci fermiamo a dire:
"Hai delle vulnerabilità qui, non andrai da nessuna parte!"
A questo punto è importante dire agli sviluppatori che ci sono problemi di sicurezza che richiedono attenzione.
La presenza di vulnerabilità non è un ostacolo a ulteriori test: manuale, integrazione o manuale. D'altra parte, dobbiamo in qualche modo aumentare la sicurezza del prodotto e fare in modo che gli sviluppatori non trascurino ciò che ritengono sicuro. Pertanto, a volte lo facciamo: allo stand, quando viene implementato nell'ambiente di sviluppo, avvisiamo semplicemente lo sviluppo:
- Ragazzi, avete dei problemi, per favore prestate loro attenzione.
Nella fase UAT mostriamo nuovamente avvisi sulle vulnerabilità e nella fase di rilascio diciamo:
- Ragazzi, vi abbiamo avvertito più volte, non avete fatto nulla - non vi lasceremo uscire con questo.
Se parliamo di codice e dinamiche, è necessario mostrare e avvisare delle vulnerabilità solo di quelle funzionalità e del codice che è stato appena scritto in questa funzionalità. Se uno sviluppatore sposta un pulsante di 3 pixel e gli diciamo che lì ha un'iniezione SQL e quindi deve essere riparata urgentemente, questo è sbagliato. Guarda solo ciò che è scritto ora e il cambiamento che arriva all'applicazione.
Diciamo che abbiamo un certo difetto funzionale: il modo in cui l'applicazione non dovrebbe funzionare: il denaro non viene trasferito, quando si fa clic su un pulsante non si passa alla pagina successiva o il prodotto non viene caricato. Difetti di sicurezza - questi sono gli stessi difetti, ma non in termini di funzionamento dell'applicazione, ma di 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. Sceriffo Mansour, Expedia.
Poiché tutte le vulnerabilità sono gli stessi difetti, dovrebbero essere localizzate nello stesso posto di tutti i difetti di sviluppo. Quindi dimentica i report e i PDF spaventosi che nessuno legge.
Quando lavoravo presso una società di sviluppo, ho ricevuto un report dagli strumenti di analisi statica. L'ho aperto, sono rimasto inorridito, ho preparato il caffè, ho sfogliato 350 pagine, l'ho chiuso e ho continuato a lavorare. I grandi rapporti sono rapporti morti. Di solito non vanno da nessuna parte, le lettere vengono cancellate, dimenticate, perse oppure l'azienda afferma di accettare i rischi.
Cosa fare? Convertiamo semplicemente i difetti confermati che abbiamo riscontrato in una forma conveniente per lo sviluppo, ad esempio li inseriamo in un backlog in Jira. Diamo la priorità ai difetti e li eliminiamo in ordine di priorità, insieme ai difetti funzionali e ai difetti di test.
Analisi Statica - SAST
Questa è un'analisi del codice per le vulnerabilità., ma non è la stessa cosa di SonarQube. Non controlliamo solo modelli o stile. Nell'analisi vengono utilizzati numerosi approcci: secondo l'albero delle vulnerabilità, secondo , analizzando i file di configurazione. Questo è tutto ciò che riguarda il codice stesso.
Pro dell'approccio: identificare le vulnerabilità nel codice in una fase iniziale di sviluppoquando non ci sono ancora supporti o strumenti già pronti, e capacità di scansione incrementale: scansione di una sezione di codice che è cambiata e solo della funzionalità che stiamo attualmente eseguendo, riducendo i tempi di scansione.
Contro - questa è la mancanza di supporto per le lingue necessarie.
Integrazioni necessarie, che dovrebbe essere negli strumenti, secondo la mia opinione soggettiva:
- Strumento di integrazione: Jenkins, TeamCity e Gitlab CI.
- Ambiente di sviluppo: Intellij IDEA, Visual Studio. È più conveniente per uno sviluppatore non navigare in un'interfaccia incomprensibile che deve ancora essere memorizzata, ma vedere tutte le integrazioni e le vulnerabilità necessarie che ha trovato direttamente sul posto di lavoro nel proprio ambiente di sviluppo.
- Revisione del codice: SonarQube e revisione manuale.
- Tracker dei difetti: Jira e Bugzilla.
L'immagine mostra alcuni dei migliori rappresentanti dell'analisi statica.
Non sono gli strumenti ad essere importanti, ma il processo, quindi esistono soluzioni Open Source che sono utili anche per testare il processo.
SAST Open Source non troverà un numero enorme di vulnerabilità o flussi di dati complessi, ma possono e devono essere utilizzati durante la creazione di un processo. Aiutano a capire come verrà costruito il processo, chi risponderà ai bug, chi segnalerà e chi segnalerà. Se vuoi realizzare la fase iniziale di costruzione della sicurezza del tuo codice, utilizza soluzioni Open Source.
Come può essere integrato questo se sei all'inizio del tuo viaggio e non hai nulla: niente CI, niente Jenkins, niente TeamCity? Consideriamo l'integrazione nel processo.
Integrazione a livello CVS
Se hai Bitbucket o GitLab, puoi integrarli a livello .
Per evento - richiesta pull, commit. Esegui la scansione del codice e lo stato della build mostra se il controllo di sicurezza è stato superato o meno.
Contattaci. Naturalmente il feedback è sempre necessario. Se ti limitassi a occuparti della sicurezza, lo mettessi in una scatola senza dirlo a nessuno, e poi alla fine del mese scaricassi un mucchio di bug - questo non è corretto e non va bene.
Integrazione con il sistema di revisione del codice
Una volta, abbiamo agito come revisore predefinito per un utente tecnico di AppSec in una serie di progetti importanti. A seconda che siano identificati errori nel nuovo codice o che non siano presenti errori, il revisore imposta lo stato della richiesta pull su "accetta" o "è necessario lavorare": è tutto a posto oppure i collegamenti a ciò che esattamente deve essere migliorato devono essere migliorati. Per l'integrazione con la versione che sta andando in produzione, abbiamo abilitato il divieto di fusione se non viene superato il test di sicurezza informatica. Lo abbiamo incluso nella revisione manuale del codice e gli altri partecipanti al processo hanno visto gli stati di sicurezza per questo particolare processo.
Integrazione con SonarQube
Molti lo hanno fatto in termini di qualità del codice. È lo stesso qui: puoi creare le stesse porte solo per gli strumenti SAST. Ci sarà la stessa interfaccia, lo stesso cancello di qualità, solo che verrà chiamato cancello di sicurezza. Inoltre, se disponi di un processo che utilizza SonarQube, puoi facilmente integrare tutto lì.
Integrazione a livello di CI
Anche qui tutto è abbastanza semplice:
- Alla pari degli autotest, test unitari.
- Divisione per fasi di sviluppo: sviluppo, test, produzione. Possono essere inclusi diversi insiemi di regole o diverse condizioni di fallimento: fermare l’assemblaggio, non fermare l’assemblaggio.
- Lancio sincrono/asincrono. Aspettiamo o meno la fine dei test di sicurezza. Cioè, li abbiamo appena lanciati e andiamo avanti, e poi otteniamo lo status che tutto è buono o cattivo.
È tutto in un perfetto mondo rosa. Non esiste una cosa del genere nella vita reale, ma ci sforziamo. Il risultato dell'esecuzione dei controlli di sicurezza dovrebbe essere simile ai risultati dei test unitari.
Ad esempio, abbiamo preso un progetto di grandi dimensioni e abbiamo deciso che ora lo scannerizzeremo con SAST - OK. Abbiamo spinto questo progetto nel SAST, ci ha dato 20 vulnerabilità e con una decisione volitiva abbiamo deciso che andava tutto bene. 000 vulnerabilità sono il nostro debito tecnico. Metteremo il debito in una scatola, lo chiariremo lentamente e aggiungeremo bug ai tracker dei difetti. Assumiamo un'azienda, facciamo tutto da soli o facciamoci aiutare dai campioni della sicurezza: il debito tecnico diminuirà.
E tutte le nuove vulnerabilità emergenti nel nuovo codice devono essere eliminate allo stesso modo degli errori in un'unità o negli autotest. Relativamente parlando, l'assemblaggio è iniziato, l'abbiamo eseguito, due test e due test di sicurezza sono falliti. OK, siamo andati, abbiamo guardato cosa è successo, abbiamo risolto una cosa, ne abbiamo corretto un'altra, l'abbiamo eseguito la volta successiva: tutto andava bene, non sono apparse nuove vulnerabilità, nessun test ha fallito. Se questo compito è più profondo e devi capirlo bene, o la correzione delle vulnerabilità influisce su ampi strati di ciò che si nasconde sotto il cofano: un bug è stato aggiunto al tracker dei difetti, gli viene data la priorità e corretto. Sfortunatamente, il mondo non è perfetto e i test a volte falliscono.
Un esempio di cancello di sicurezza è un analogo di un cancello di qualità, in termini di presenza e numero di vulnerabilità nel codice.
Ci integriamo con SonarQube: il plugin è installato, tutto è molto comodo e interessante.
Integrazione con l'ambiente di sviluppo
Opzioni di integrazione:
- Esecuzione di una scansione dall'ambiente di sviluppo prima del commit.
- Vedi i risultati.
- Analisi dei risultati.
- Sincronizzazione con il server.
Questo è come appare ricevere risultati dal server.
Nel nostro ambiente di sviluppo appare semplicemente un elemento aggiuntivo che informa che tali vulnerabilità sono state rilevate durante la scansione. Puoi modificare immediatamente il codice, consultare i consigli e . Tutto questo si trova sul posto di lavoro dello sviluppatore, il che è molto comodo: non è necessario seguire altri collegamenti e guardare qualcosa in più.
Open Source
Questo è il mio argomento preferito. Tutti utilizzano librerie Open Source: perché scrivere un mucchio di stampelle e biciclette quando puoi prendere una libreria già pronta in cui tutto è già implementato?
Naturalmente questo è vero, ma anche le biblioteche sono scritte da persone, comportano anche alcuni rischi e ci sono anche vulnerabilità che vengono segnalate periodicamente, o costantemente. Pertanto, c'è il passo successivo nella sicurezza delle applicazioni: questa è l'analisi dei componenti Open Source.
Analisi Open Source - OSA
Lo strumento comprende tre grandi fasi.
Ricerca di vulnerabilità nelle biblioteche. Ad esempio, lo strumento sa che stiamo utilizzando una libreria e che in oppure ci sono alcune vulnerabilità nei bug tracker che riguardano questa versione della libreria. Quando provi a utilizzarlo, lo strumento emetterà un avviso che la libreria è vulnerabile e ti consiglierà di utilizzare un'altra versione che non presenta vulnerabilità.
Analisi della purezza della licenza. Questo non è ancora particolarmente popolare qui, ma se lavori all'estero, di tanto in tanto puoi ricevere una tassa lì per l'utilizzo di un componente open source che non può essere utilizzato o modificato. Secondo la politica della biblioteca autorizzata, non possiamo farlo. Oppure, se lo modificassimo e lo utilizzassimo, dovremmo pubblicare il nostro codice. Naturalmente nessuno vuole pubblicare il codice dei propri prodotti, ma puoi proteggerti anche da questo.
Analisi dei componenti che vengono utilizzati in un ambiente industriale. Immaginiamo una situazione ipotetica in cui abbiamo finalmente completato lo sviluppo e rilasciato l'ultima versione del nostro microservizio. Vive lì meravigliosamente: una settimana, un mese, un anno. Non lo raccogliamo, non effettuiamo controlli di sicurezza, sembra tutto a posto. Ma all'improvviso, due settimane dopo il rilascio, è apparsa una vulnerabilità critica nel componente Open Source, che utilizziamo in questa particolare build, in ambiente industriale. Se non registriamo cosa e dove utilizziamo, semplicemente non vedremo questa vulnerabilità. Alcuni strumenti hanno la capacità di monitorare le vulnerabilità nelle librerie attualmente utilizzate nel settore. E 'molto utile.
Возможности:
- Politiche diverse per diverse fasi di sviluppo.
- Monitoraggio di componenti in ambiente industriale.
- Controllo delle biblioteche all'interno dell'organizzazione.
- Supporto per vari sistemi e linguaggi di build.
- Analisi delle immagini Docker.
Alcuni esempi di leader del settore impegnati nell'analisi Open Source.
L'unico gratuito è questo da OWASP. Puoi accenderlo nelle prime fasi, vedere come funziona e cosa supporta. Fondamentalmente si tratta di tutti prodotti cloud, ovvero on-premise, ma dietro la loro base vengono comunque inviati su Internet. Non inviano le tue librerie, ma hash o i propri valori, che calcolano, e impronte digitali al loro server per ricevere informazioni sulla presenza di vulnerabilità.
Integrazione dei processi
Controllo perimetrale delle biblioteche, che vengono scaricati da fonti esterne. Abbiamo repository esterni ed interni. Ad esempio, Event Central esegue Nexus e vogliamo garantire che non vi siano vulnerabilità nel nostro repository con stato "critico" o "alto". È possibile configurare il proxy utilizzando lo strumento Nexus Firewall Lifecycle in modo che tali vulnerabilità vengano eliminate e non finiscano nel repository interno.
Integrazione in CI. Allo stesso livello con gli autotest, gli unit test e la suddivisione in fasi di sviluppo: dev, test, prod. In ogni fase, puoi scaricare qualsiasi libreria, utilizzare qualsiasi cosa, ma se c'è qualcosa di difficile con lo stato "critico", forse vale la pena attirare l'attenzione degli sviluppatori su questo nella fase di rilascio in produzione.
Integrazione con artefatti: Nexus e JFrog.
Integrazione nell'ambiente di sviluppo. Gli strumenti scelti dovrebbero avere l'integrazione con gli ambienti di sviluppo. Lo sviluppatore deve avere accesso ai risultati della scansione dal suo posto di lavoro o la capacità di scansionare e controllare lui stesso le vulnerabilità del codice prima di impegnarsi in CVS.
Integrazione del CD. Questa è una funzionalità interessante che mi piace molto e di cui ho già parlato: monitorare l'emergere di nuove vulnerabilità in un ambiente industriale. Funziona più o meno così.
Abbiamo Repository di componenti pubblici - alcuni strumenti esterni e il nostro repository interno. Vogliamo che contenga solo componenti attendibili. Quando inoltriamo una richiesta, controlliamo che la libreria scaricata non presenti vulnerabilità. Se rientra in determinate politiche che impostiamo e necessariamente coordiniamo con lo sviluppo, non lo carichiamo e ci viene richiesto di utilizzare un'altra versione. Di conseguenza, se nella libreria c'è qualcosa di veramente critico e difettoso, lo sviluppatore non riceverà la libreria in fase di installazione: lascia che utilizzi una versione superiore o inferiore.
- Durante la costruzione controlliamo che nessuno abbia fatto scivolare qualcosa di brutto, che tutti i componenti siano sicuri e nessuno abbia portato nulla di pericoloso sulla chiavetta.
- Nel repository sono presenti solo componenti attendibili.
- Durante la distribuzione, controlliamo ancora una volta il pacchetto stesso: immagine war, jar, DL o Docker per garantire che sia conforme alla politica.
- Quando entriamo nel settore, monitoriamo ciò che sta accadendo nell'ambiente industriale: le vulnerabilità critiche compaiono o non compaiono.
Analisi dinamica - DAST
Gli strumenti di analisi dinamica sono fondamentalmente diversi da tutto ciò che è stato detto prima. Questa è una sorta di imitazione del lavoro dell'utente con l'applicazione. Se si tratta di un'applicazione web, inviamo richieste, simulando il lavoro del cliente, facciamo clic sui pulsanti sulla parte anteriore, inviamo dati artificiali dal modulo: virgolette, parentesi, caratteri in diverse codifiche, per vedere come funziona ed elabora l'applicazione dati esterni.
Lo stesso sistema permette di verificare le vulnerabilità dei template in Open Source. Poiché DAST non sa quale Open Source stiamo utilizzando, genera semplicemente modelli “dannosi” e analizza le risposte del server:
- Sì, c'è un problema di deserializzazione qui, ma non qui.
I rischi sono grossi, perché se si esegue questo test di sicurezza sullo stesso banco su cui lavorano i tester, possono accadere cose spiacevoli.
- Carico elevato sulla rete del server delle applicazioni.
- Nessuna integrazione.
- Possibilità di modificare le impostazioni dell'applicazione analizzata.
- Non c'è supporto per le tecnologie necessarie.
- Difficoltà di configurazione.
Quando abbiamo finalmente lanciato AppScan abbiamo avuto un problema: abbiamo passato molto tempo cercando di accedere all'applicazione, abbiamo ottenuto 3 account e siamo rimasti soddisfatti: finalmente controlleremo tutto! Abbiamo avviato una scansione e la prima cosa che ha fatto AppScan è stata entrare nel pannello di amministrazione, forare tutti i pulsanti, modificare metà dei dati e quindi uccidere completamente il server con il suo -richieste. Sviluppo con test ha detto:
- Ragazzi, state scherzando?! Noi vi abbiamo reso conto e voi avete allestito uno stand!
Considera i possibili rischi. Idealmente, preparare uno stand separato per testare la sicurezza delle informazioni, che sarà almeno in qualche modo isolato dal resto dell'ambiente, e controllare condizionatamente il pannello di amministrazione, preferibilmente in modalità manuale. Questo è un pentest: quelle percentuali rimanenti di impegno che non stiamo considerando ora.
Vale la pena considerare che è possibile utilizzarlo come analogo al test di carico. Nella prima fase, puoi accendere uno scanner dinamico con 10-15 thread e vedere cosa succede, ma di solito, come dimostra la pratica, niente di buono.
Alcune risorse che usiamo abitualmente.
Vale la pena evidenziare è un “coltellino svizzero” per qualsiasi professionista della sicurezza. Lo usano tutti ed è comodissimo. È stata ora rilasciata una nuova versione demo dell'edizione aziendale. Se prima si trattava solo di un'utilità autonoma con plug-in, ora gli sviluppatori stanno finalmente realizzando un server di grandi dimensioni da cui sarà possibile gestire diversi agenti. È fantastico, ti consiglio di provarlo.
Integrazione dei processi
L'integrazione avviene abbastanza bene e semplicemente: avviare la scansione al termine dell'installazione domande per lo stand e scansione dopo aver eseguito con successo il test di integrazione.
Se le integrazioni non funzionano o ci sono stub e funzioni fittizie, è inutile e inutile: non importa quale modello inviamo, il server risponderà comunque allo stesso modo.
- Idealmente, un banco di prova separato.
- Prima del test, annotare la sequenza di accesso.
- Il test del sistema di amministrazione è esclusivamente manuale.
Процесс
Un po' di generalizzazione sul processo in generale e sul lavoro di ciascuno strumento in particolare. Tutte le applicazioni sono diverse: una funziona meglio con l'analisi dinamica, un'altra con l'analisi statica, una terza con l'analisi OpenSource, pentest o qualcos'altro, ad esempio eventi con .
Ogni processo ha bisogno di controllo.
Per capire come funziona un processo e dove può essere migliorato, è necessario raccogliere parametri da tutto ciò su cui puoi mettere le mani, inclusi parametri di produzione, parametri degli strumenti e tracciatori dei difetti.
Qualsiasi informazione è utile. È necessario guardare da diverse angolazioni dove è meglio utilizzare questo o quello strumento, dove il processo si indebolisce specificamente. Potrebbe valere la pena esaminare i tempi di risposta dello sviluppo per vedere dove migliorare il processo in base al tempo. Maggiore è la quantità di dati, maggiore è il numero di sezioni che è possibile creare dal livello superiore ai dettagli di ciascun processo.
Poiché tutti gli analizzatori statici e dinamici hanno le proprie API, i propri metodi di avvio, principi, alcuni hanno pianificatori, altri no, stiamo scrivendo uno strumento Orchestratore AppSec, che consente di creare un unico punto di ingresso nell'intero processo dal prodotto e gestirlo da un unico punto.
Manager, sviluppatori e ingegneri della sicurezza hanno un punto di ingresso da cui possono vedere cosa è in esecuzione, configurare ed eseguire una scansione, ricevere risultati di scansione e inviare requisiti. Stiamo cercando di allontanarci dalle pratiche burocratiche, di tradurre tutto in qualcosa di umano, che viene utilizzato dallo sviluppo: pagine su Confluence con stato e metriche, difetti in Jira o in vari tracker di difetti o integrazione in un processo sincrono/asincrono in CI /CD.
Punti chiave
Gli strumenti non sono la cosa principale. Per prima cosa pensa al processo, quindi implementa gli strumenti. Gli strumenti sono validi ma costosi, quindi puoi iniziare con il processo e creare comunicazione e comprensione tra sviluppo e sicurezza. Dal punto di vista della sicurezza non è necessario "fermare" tutto, dal punto di vista dello sviluppo se c'è qualcosa di mega super critico allora bisogna eliminarlo e non chiudere un occhio sul problema.
Qualità del prodotto - obiettivo comune sia della sicurezza che dello sviluppo. Facciamo una cosa, cerchiamo di garantire che tutto funzioni correttamente e che non ci siano rischi reputazionali o perdite finanziarie. Per questo promuoviamo un approccio DevSecOps, SecDevOps per migliorare la comunicazione e migliorare la qualità del prodotto.
Inizia con quello che hai già: requisiti, architettura, verifiche parziali, corsi di formazione, linee guida. Non è necessario applicare immediatamente tutte le pratiche a tutti i progetti: muoversi in modo iterativo. Non esiste uno standard unico - sperimentare e provare diversi approcci e soluzioni.
Esiste un segno uguale tra difetti di sicurezza informatica e difetti funzionali.
Automatizza tuttoche si muove. Ciò che non si muove, spostalo e automatizzalo. Se qualcosa viene fatto a mano, non è una buona parte del processo. Forse vale la pena rivederlo e automatizzarlo.
Se le dimensioni della squadra IS sono piccole... utilizzare Campioni di sicurezza.
Forse quello di cui ho parlato non ti andrà bene e ti verrà in mente qualcosa di tuo - e va bene. Ma scegli gli strumenti in base ai requisiti del tuo processo. Non guardare quello che dice la comunità, che questo strumento è cattivo e questo è buono. Forse per il tuo prodotto sarà vero il contrario.
Requisiti per gli strumenti.
- Falso positivo di basso livello.
- Tempo di analisi adeguato.
- Facilità d'uso
- Disponibilità di integrazioni.
- Comprendere la roadmap di sviluppo del prodotto.
- Possibilità di personalizzazione degli strumenti.
Il rapporto di Yuri è stato scelto come uno dei migliori alla DevOpsConf 2018. Per conoscere idee e casi pratici ancora più interessanti, vieni a Skolkovo il 27 e 28 maggio entro . Meglio ancora, se sei pronto a condividere la tua esperienza, allora per il rapporto fino al 21 aprile.
Fonte: habr.com