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 una volta iniziato a implementare il DevSecOps, bisogna andare fino in fondo.
. Autori dei personaggi: Justin Roiland e Dan Harmon.
Cosa è SecDevOps? E DevSecOps? Quali sono le differenze? Sicurezza delle applicazioni: di cosa si tratta? Perché l'approccio classico non funziona più? Queste sono tutte domande a cui Yuri Shabalin di Swordfish Security. Yuri risponderà a tutto e analizzerà le problematiche della transizione 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 fondamentali di 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. Si occupa dell'implementazione di 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 come ZerONights, PHDays, RISSPA, OWASP.
Sicurezza delle Applicazioni: di cosa si tratta?
Sicurezza delle Applicazioni è una branca della sicurezza che si occupa della sicurezza delle applicazioni. Non si riferisce all'infrastruttura o alla sicurezza di rete, ma specificamente a ciò che scriviamo e su cui lavorano gli sviluppatori, cioè ai difetti e alle vulnerabilità dell'applicazione stessa.
Direzione — Ciclo di vita dello sviluppo della sicurezza è stato sviluppato da Microsoft. Nello schema si vede il modello canonico del SDLC, il cui obiettivo principale è garantire che la sicurezza sia integrata in ogni fase dello sviluppo, dai requisiti al rilascio e all'entrata in produzione. Microsoft ha riconosciuto che ci sono troppi bug nel mercato, che stanno aumentando e che è necessario intervenire, e ha proposto questo approccio che è diventato canonico.
La sicurezza delle applicazioni e SSDL non sono rivolte alla rilevazione delle vulnerabilità, come comunemente si pensa, ma alla prevenzione della loro comparsa. Nel tempo, l'approccio canonico di Microsoft è stato migliorato e sviluppato, con un'approfondita immersione nei dettagli.
Il SDLC canonico è molto dettagliato in varie metodologie — OpenSAMM, BSIMM, OWASP. Le metodologie differiscono, ma, in generale, sono simili.
Building Security In Maturity Model
Mi sta più a cuore BSIMM — . La base della metodologia consiste nella suddivisione del processo di sicurezza delle applicazioni in 4 domini: Governance, Intelligence, SSDL Touchpoints e Deployment. In ogni dominio ci sono 12 pratiche, presentate in 112 attività.
Ogni una delle 112 attività ha 3 livelli di maturità: iniziale, medio e avanzato. Tutte e 12 le pratiche possono essere studiate per sezioni, selezionando gli aspetti importanti per voi, approfondendo come implementarli e aggiungendo gradualmente elementi come l'analisi statica e dinamica del codice o la code review. Definite un piano e lavorate serenamente con l'implementazione delle attività selezionate.
Perché DevSecOps
DevOps è un grande processo integrato in cui è necessario prendersi cura della sicurezza.
Originariamente Si prevedevano controlli di sicurezza. In pratica, il numero dei team di sicurezza era molto inferiore rispetto a oggi, e agivano più come un ente di controllo e vigilanza, che stabilisce i requisiti e verifica la qualità del prodotto alla fine del rilascio. Questo è un approccio classico, in cui i team di sicurezza si trovavano dietro le quinte dello sviluppo e non partecipavano al processo.
Il problema principale risiede nel fatto che la sicurezza informatica è separata dallo sviluppo. Di solito esiste un certo contorno di sicurezza informatica con 2-3 grandi e costosi strumenti. Ogni sei mesi si riceve il codice sorgente o l'applicazione da controllare, e una volta all'anno si effettuano . Questo porta al fatto che i tempi di rilascio vengono posticipati, e agli sviluppatori si accumulano un'enorme quantità di vulnerabilità da strumenti automatizzati. È tutto impossibile da analizzare e correggere, poiché non si sono ancora esaminati i risultati dei sei mesi precedenti, e ora arriva un nuovo carico.
Nel corso dell'attività della nostra azienda, osserviamo che la sicurezza in tutti i settori e le industrie riconosce che è arrivato il momento di unirsi e lavorare insieme nello sviluppo - nel . Il paradigma DevSecOps si integra perfettamente con la metodologia di sviluppo agile, nella sua implementazione, supporto e partecipazione ad ogni rilascio e iterazione.
Transizione a DevSecOps
La parola più importante nel Security Development Lifecycle è «processo». Devi capirlo prima di pensare di acquistare strumenti.
È semplicemente insufficiente inserire strumenti nel processo DevOps - è fondamentale la collaborazione e la comprensione tra i partecipanti al processo.
Le persone sono più importanti degli strumenti
Spesso la pianificazione del processo di sviluppo sicuro inizia con la scelta e l'acquisto di uno strumento, ma termina con tentativi di integrare lo strumento nel processo attuale, che rimangono tentativi. Questo porta a conseguenze negative, poiché ogni strumento ha le proprie peculiarità e limitazioni.
Un caso comune è quando il dipartimento di sicurezza sceglie uno strumento costoso e di alta qualità con ampie funzionalità e si rivolge agli sviluppatori per integrarlo nel processo. Ma non funziona: il processo è strutturato in modo tale che le restrizioni dello strumento già acquistato non si adattano all'attuale paradigma.
Inizia descrivendo quale risultato desideri e come dovrebbe apparire il processo. Questo aiuterà a comprendere i ruoli dello strumento e della sicurezza nel processo.
Comincia con ciò che è già in uso.
Prima di acquistare strumenti costosi, guarda a ciò che hai già. Ogni azienda ha requisiti di sicurezza per lo 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 documento cartaceo che viene lasciato sullo scaffale. C'è stata una volta in cui siamo stati in un'azienda per esaminare i processi e abbiamo chiesto di mostrare i requisiti di sicurezza per il software. Il specialista responsabile ha cercato a lungo:
— Adesso, c'era da qualche parte nelle note il percorso per trovare questo documento.
Alla fine abbiamo ottenuto il documento dopo una settimana.
Per requisiti, controlli e altro, crea una pagina, ad esempio, su Confluence — è comodo per tutti.
È più semplice riformattare ciò che è già disponibile e utilizzarlo come punto di partenza.
Utilizza i Security Champions
Di solito, in un'azienda media con 100-200 sviluppatori lavora un esperto di sicurezza, che svolge diverse funzioni e fisicamente non riesce a controllare tutto. Anche se si impegna al massimo, non può verificare da solo tutto il codice generato dallo sviluppo. Per questi casi è stato sviluppato il concetto di .
I Security Champions sono persone all'interno del team di sviluppo, interessate alla sicurezza del tuo prodotto.
Il Security Champion è un punto di ingresso nel team di sviluppo e un evangelista della sicurezza in una sola persona.
Di solito, quando un esperto di sicurezza entra nel team di sviluppo e segnala un errore nel codice, riceve una risposta sorpresa:
— Chi sei? Ti vedo per la prima volta. Per me va tutto bene — il mio senior mi ha dato un 'apply' durante il code review, andiamo avanti!
Questa è una situazione tipica, poiché c'è molta più fiducia nei confronti dei senior o semplicemente dei colleghi del team con cui il sviluppatore interagisce costantemente nel lavoro e nelle revisioni del codice. Se il Security Champion indica un errore e le conseguenze invece del responsabile della sicurezza, la sua parola avrà più peso.
Inoltre, gli sviluppatori conoscono meglio il proprio codice rispetto a qualsiasi esperto di sicurezza. Per una persona che ha almeno 5 progetti nello strumento di analisi statica, è solitamente difficile ricordare tutte le sfumature. I Security Champions conoscono il proprio prodotto: come interagisce con cosa e a cosa prestare attenzione in primo luogo — sono più efficaci.
Quindi riflettete sull'introduzione di Security Champions e sull'ampliamento dell'influenza del team di sicurezza. Per il campione stesso è anche vantaggioso: sviluppo professionale in un nuovo campo, ampliamento delle competenze tecniche, potenziamento delle abilità tecniche, gestionali e di leadership, aumento del valore sul mercato. Questo è un elemento di ingegneria sociale, i vostri «occhi» nel team di sviluppo.
Fasi di test
afferma che il 20% degli sforzi produce l'80% dei risultati. Questo 20% comprende le pratiche di analisi delle applicazioni che possono e devono essere automatizzate. Esempi di tali attività includono l'analisi statica — SAST, l'analisi dinamica — DAST, e il controllo delle risorse Open Source. Spiegherò più nel dettaglio le attività, così come gli strumenti e le peculiarità che incontriamo di solito nel loro implemento nel processo, e come farlo correttamente.
Principali problemi degli strumenti
Evidenzierò i problemi attuali comuni a tutti gli strumenti che richiedono attenzione. Analizzerò questi problemi più a fondo per evitare ripetizioni.
Lunghe tempistiche di analisi. Se dal commit al rilascio in produzione passano 30 minuti per tutti i test e la compilazione, i controlli di sicurezza informatica richiederanno giorni. Nessuno vorrà rallentare il processo. Tenete presente questa peculiarità e fate le dovute considerazioni.
Alto livello di False Negative o False Positive. Tutti i prodotti sono diversi, utilizzano framework diversi e il proprio stile di scrittura del codice. Su basi di codice e tecnologie diverse, gli strumenti possono mostrare differenti livelli di False Negative e False Positive. Pertanto, osservate ciò che è specifico nella vostra azienda e per i vostri le applicazioni mostreranno risultati buoni e affidabili.
Nessuna integrazione con strumenti esistenti.. Esamina gli strumenti dal punto di vista delle integrazioni, considerando ciò che già utilizzi. Ad esempio, se hai Jenkins o TeamCity, controlla l'integrazione degli strumenti con questo software specifico, non con GitLab CI, che non stai usando.
Mancanza o eccessiva complessità nella personalizzazione. Se uno strumento non ha API, a cosa serve? Tutto ciò che può essere fatto nell'interfaccia deve essere accessibile tramite API. Idealmente, lo strumento dovrebbe avere la possibilità di personalizzare i controlli.
Nessun Roadmap per lo sviluppo del prodotto. Lo sviluppo non si ferma mai; 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. Pertanto, è importante sapere che il prodotto ha un reale e valido di sviluppo.
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 dovremmo considerare e su cosa prestare attenzione per il team di sicurezza.
Per non compromettere le scadenze di sviluppo e rilascio, crea regole diverse e differenti show stoppers — criteri di interruzione del processo di build in presenza di vulnerabilità — per diversi ambienti. Ad esempio, comprendiamo che l'attuale ramo è destinato a un ambiente di sviluppo o UAT, quindi non ci fermiamo e non diciamo:
— Avete qui delle vulnerabilità, non andrete oltre!
In questa fase, è importante segnalare agli sviluppatori che ci sono problematiche di sicurezza a cui prestare attenzione.
La presenza di vulnerabilità non è un ostacolo per i test successivi: manuali, di integrazione o manuali. D'altra parte, dobbiamo trovare un modo per aumentare la sicurezza del prodotto, affinché gli sviluppatori non trascurino ciò che rileva la sicurezza. Quindi, a volte procediamo in questo modo: nell'ambiente, quando viene distribuito sull'ambiente di sviluppo, informiamo semplicemente lo sviluppo:
— Ragazzi, se avete problemi, vi preghiamo di prestarvi attenzione.
Nella fase UAT mostriamo di nuovo avvisi sulle vulnerabilità, e nella fase di uscita in produzione diciamo:
— Ragazzi, vi abbiamo avvisato più volte, non avete fatto nulla — con questo non vi lasceremo andare.
Se parliamo di codice e di dinamica, dobbiamo 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 gli diciamo che ha un'iniezione SQL e quindi deve correggere urgentemente — non è corretto. Guardate solo a ciò che è stato scritto ora e al cambiamento che arriva nell'applicazione.
Supponiamo di avere un difetto funzionale — come non dovrebbe funzionare l'applicazione: i soldi non vengono trasferiti, al clic su un pulsante non si passa alla pagina successiva o il prodotto non viene caricato. Difetti di sicurezza — sono difetti uguali, ma non in termini di funzionamento dell'applicazione, bensì 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. Sherif Mansour, Expedia.
Poiché tutte le vulnerabilità sono difetti, devono trovarsi nello stesso luogo in cui si trovano tutti i difetti di sviluppo. Quindi dimenticatevi di report e dei terribili PDF che nessuno legge.
Quando lavoravo in una società di sviluppo, ricevetti un report dagli strumenti di analisi statici. L'ho aperto, mi sono spaventato, ho fatto un caffè, ho sfogliato 350 pagine, l'ho chiuso e sono tornato a lavorare. I grandi report sono report morti. Di solito non vanno da nessuna parte, le e-mail vengono eliminate, dimenticate, perse, o il business dice che si assume i rischi.
Cosa fare? I difetti confermati che sono stati trovati vengono semplicemente trasformati in un formato utile per lo sviluppo, ad esempio accumulandoli nel backlog in Jira. Prioritizziamo e risolviamo i difetti in base all'ordine di priorità, insieme ai difetti funzionali e ai difetti di test.
Analisi statica - SAST
È un'analisi del codice per la presenza di vulnerabilità, ma non è la stessa cosa di SonarQube. Non controlliamo solo i pattern o lo stile. Durante l'analisi vengono applicati diversi approcci: 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 nelle fasi iniziali dello sviluppo, quando non ci sono ancora ambienti e strumenti pronti, e possibilità di scansione incrementale: scansione della parte di codice che è cambiata e solo della funzionalità su cui stiamo lavorando, il che riduce il tempo di scansione.
Svantaggi — è la mancanza di supporto per i linguaggi necessari.
Integrazioni necessarie, che dovrebbero esistere negli strumenti, secondo la mia opinione soggettiva:
- Strumento di integrazione: Jenkins, TeamCity e Gitlab CI.
- Ambiente di sviluppo: Intellij IDEA, Visual Studio. È più comodo per lo sviluppatore non dover cercare in un'interfaccia confusa che deve ancora essere memorizzata, ma vedere direttamente nel proprio ambiente di sviluppo tutti i necessari integrazioni e vulnerabilità che ha trovato.
- Code review: SonarQube e revisione manuale.
- Tracker di difetti: Jira e Bugzilla.
Nell'immagine ci sono alcuni dei migliori rappresentanti dell'analisi statica.
Non sono gli strumenti che contano, ma il processo; per questo esistono soluzioni Open Source che sono ugualmente valide per testare il processo.
SAST Open Source non trova un'enorme quantità di vulnerabilità o complessi DataFlow, ma nella costruzione del processo possono e devono essere utilizzati. Aiutano a comprendere come sarà strutturato il processo, chi sarà responsabile dei bug, chi deve fare i report e chi deve riferire. Se desiderate intraprendere la fase iniziale della sicurezza del vostro codice, utilizzate soluzioni Open Source.
Come può essere integrato 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, è possibile fare integrazione a livelli .
Su evento — pull request, commit. Scansionate il codice e nello stato di build mostrate se il controllo della sicurezza è stato superato o meno.
Feedback. Senza dubbio, il feedback è sempre necessario. Se semplicemente avete eseguito il lavoro lì, per il security, l'avete messo in una scatola e non avete detto nulla a nessuno, e poi alla fine del mese fate emergere un sacco di bug, ciò non è corretto e non va bene.
Integrazione con il sistema di code review
Una volta, abbiamo impostato come revisore predefinito per l'utente tecnico AppSec in una serie di progetti importanti. A seconda che vengano trovati errori nel nuovo codice o meno, il revisore del pull request assegna uno stato di "accept" o "need work" — o tutto è OK, oppure è necessario rivedere e ci saranno collegamenti su ciò che deve essere modificato. Per l'integrazione con la versione che va in produzione, avevamo abilitato il divieto di merge se il test di sicurezza non veniva superato. Questo lo abbiamo incluso nella revisione manuale del codice, e gli altri membri del processo vedevano gli stati di sicurezza relativi a questo specifico processo.
Integrazione con SonarQube
Molti hanno per la qualità del codice. Qui vale lo stesso principio: è possibile creare gli stessi gates solo per gli strumenti SAST. Ci sarà la stessa interfaccia, lo stesso quality gate, solo che si chiamerà security gate. E anche, se hai impostato un processo utilizzando SonarQube, puoi facilmente integrare tutto lì.
Integrazione a livello CI
Qui è tutto piuttosto semplice:
- A un livello con i test automatici, i test unitari.
- Divisione per fasi di sviluppo: dev, test, prod. Possono essere attivati set di regole diversi o condizioni di errore diverse: fermiamo la build, non fermiamo la build.
- Esecuzione sincrona/asincrona. Stiamo aspettando il completamento dei test di sicurezza o non lo facciamo. In altre parole, li abbiamo semplicemente avviati e andiamo avanti, e poi riceviamo lo stato che tutto va bene o male.
Questo è tutto in un mondo ideale e roseo. Nella vita reale non esiste, ma miriamo a questo. Il risultato delle verifiche di sicurezza deve essere analogo ai risultati dei test unitari.
Ad esempio, abbiamo preso un grande progetto e deciso di scannerizzarlo con SAST — OK. Abbiamo inserito questo progetto in SAST, ci ha restituito 20.000 vulnerabilità e, con decisione, abbiamo accettato che andasse tutto bene. 20.000 vulnerabilità rappresentano il nostro debito tecnico. Metteremo il debito in una scatola, lo smistiamo pian piano e registriamo i bug nei tracker dei difetti. Assumeremo un'azienda, faremo tutto noi stessi o ci aiuteranno i Security Champions — e il debito tecnico diminuirà.
Tutte le vulnerabilità emergenti nel nuovo codice devono essere affrontate come gli errori nei test unitari o nei test automatici. In altre parole, se una build è stata lanciata, sono stati eseguiti e sono falliti due test e due test di sicurezza. OK - abbiamo controllato cosa è successo, corretto il primo, corretto il secondo, e la prossima volta eseguiamo di nuovo - tutto va bene, non sono emerse nuove vulnerabilità e i test non sono falliti. Se la questione è più complessa e richiede una comprensione più approfondita, o se la correzione delle vulnerabilità implica componenti significativi del backend: viene aperto un bug nel tracker dei difetti, viene prioritizzato e corretto. Sfortunatamente, il mondo non è perfetto e a volte i test falliscono.
Esempio di security gate – simile al quality gate, basato sulla presenza e sul numero di vulnerabilità nel codice.
Integriamo con SonarQube – il plugin viene installato, è tutto molto comodo e fantastico.
Integrazione con l'ambiente di sviluppo
Opzioni di integrazione:
- Avvio della scansione dall'ambiente di sviluppo 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 appare semplicemente un'ulteriore voce che indica che durante la scansione sono state rilevate vulnerabilità. È possibile correggere immediatamente il codice, consultare le raccomandazioni e . Tutto questo è situato nell'area di lavoro dello sviluppatore, il che è molto comodo: non è necessario navigare tra altri link e cercare qualcosa di aggiuntivo.
Open Source
Questo è il mio argomento preferito. Tutti usano librerie Open Source: perché scrivere tonnellate di workaround e reinventare la ruota quando si può semplicemente usare una libreria pronta in cui è già tutto implementato?
Certo, è vero, ma le librerie sono anche scritte da persone, includono quindi certi rischi e presentano vulnerabilità di cui si parla periodicamente o costantemente. Pertanto, c'è un ulteriore passo nella Sicurezza delle Applicazioni: l'analisi dei componenti Open Source.
Analisi Open Source - OSA
Lo strumento comprende tre fasi principali.
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 vulnerabilità relative a questa versione della libreria. Quando si tenta di utilizzarla, lo strumento emetterà un avviso che indica che la libreria è vulnerabile e consiglia di utilizzare un'altra versione priva di vulnerabilità.
Analisi della conformità alle licenze. Da noi non è ancora molto popolare, ma se si lavora con l'estero, si potrebbe ricevere una reprimenda per l'uso di componenti con codice sorgente aperto che non possono essere utilizzati o modificati. Secondo la politica di licenza della libreria, non possiamo farlo. Oppure, se l'abbiamo modificata e la utilizziamo, dobbiamo rendere il nostro codice pubblico. Naturalmente, nessuno vuole condividere il codice dei propri prodotti, ma ci sono anche modi per proteggersi da questo.
Analisi dei componenti utilizzati in ambiente industriale. Immaginiamo una situazione ipotetica in cui abbiamo finalmente completato lo sviluppo e rilasciato in produzione l'ultima versione del nostro microservizio. Lì funziona meravigliosamente—una settimana, un mese, un anno. Non lo raccogliamo, non eseguiamo controlli di sicurezza, sembra che tutto vada bene. Ma improvvisamente, due settimane dopo il rilascio, emerge una vulnerabilità critica in un componente Open Source che utilizziamo in questa build, nell'ambiente di produzione. Se non registriamo cosa e dove utilizziamo, non riusciremo a vedere questa vulnerabilità. Alcuni strumenti offrono la possibilità di monitorare le vulnerabilità delle librerie attualmente in uso in produzione. Questo è molto utile.
Funzionalità:
- Politiche diverse per fasi di sviluppo diverse.
- Monitoraggio dei componenti nell'ambiente industriale.
- Controllo delle librerie nell'ambito dell'organizzazione.
- Supporto per vari sistemi di build e linguaggi.
- Analisi delle immagini Docker.
Alcuni esempi di leader del settore che si occupano di analisi Open Source.
L'unico gratuito tra di loro è da OWASP. Può essere attivato nelle prime fasi per vedere come funziona e cosa supporta. Fondamentalmente, si tratta di tutti i prodotti cloud, oppure on-premise, ma con la loro base vengono comunque inviati su Internet. Non inviano le vostre librerie, ma hash o valori calcolati, insieme a fingerprint, ai loro server per ricevere notizie 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 abbiamo Nexus, e vogliamo che nel nostro repository non ci siano vulnerabilità con stato ‘critico’ o ‘alto’. È possibile configurare il proxy utilizzando lo strumento Nexus Firewall Lifecycle in modo che tali vulnerabilità vengano bloccate e non entrino nel repository interno.
Integrazione nel CI. Su un livello con i test automatici, i test unitari e la divisione per fasi di sviluppo: dev, test, prod. In ogni fase è possibile scaricare qualsiasi libreria, utilizzare ciò che si desidera, ma se c'è qualcosa di rigido con lo stato "critical", forse è il caso di attirare l'attenzione degli sviluppatori in fase di produzione.
Integrazione con gli artefatti: Nexus e JFrog.
Integrazione nell'ambiente di sviluppo. Strumenti che scegliete devono avere integrazione con gli ambienti di sviluppo. Lo sviluppatore deve avere accesso dai propri strumenti di lavoro ai risultati della scansione, oppure la possibilità di scansionare e verificare il codice per la presenza di vulnerabilità prima di effettuare il commit in CVS.
Integrazione nel CD. Questa è una funzionalità davvero interessante che mi piace molto e della quale ho già parlato: il monitoraggio dell'emergere di nuove vulnerabilità nell'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 affidabili. Durante il proxy della richiesta, verifichiamo che la libreria scaricata non presenti vulnerabilità. Se rientra in determinate politiche che impostiamo e che dobbiamo necessariamente concordare con il team di sviluppo, non la scarichiamo e riceviamo una segnalazione per utilizzare una versione diversa. Di conseguenza, se nella libreria c'è qualcosa di realmente critico e dannoso, il sviluppatore non riceverà la libreria già in fase di installazione — sarà tenuto a utilizzare una versione superiore o inferiore.
- Durante la build, verifichiamo che nessuno abbia sneakyato nulla di dannoso, che tutti i componenti siano sicuri e che nessuno abbia portato nulla di pericoloso su una chiavetta USB.
- Nel nostro repository ci sono solo componenti affidabili.
- Durante il deployment, verifichiamo ancora una volta il pacchetto stesso: war, jar, DL o immagine Docker, per assicurarci che rispetti le politiche.
- All'uscita in produzione monitoriamo ciò che accade nell'ambiente di produzione: se compaiono o meno vulnerabilità critiche.
Analisi dinamica — DAST
Gli strumenti di analisi dinamica si differenziano notevolmente da tutto ciò che è stato detto finora. Rappresentano una sorta di simulazione del lavoro dell'utente con l'applicazione. Se si tratta di un'app web, inviamo richieste simulando l'operato del cliente, clicchiamo sui pulsanti dell'interfaccia, inviamo dati artificiali dai moduli: virgolette, parentesi, simboli in diverse codifiche, per osservare come l'applicazione gestisce e processa i dati esterni.
Questo stesso sistema consente di controllare le vulnerabilità di tipo template nell'Open Source. Poiché il DAST non sa quale Open Source stiamo utilizzando, semplicemente lancia patter di "malware" e analizza le risposte del server:
— Ah, qui c'è un problema di deserializzazione, e qui no.
Ci sono grandi rischi, perché se esegui questo test di sicurezza sulla stessa infrastruttura utilizzata dai tester, potrebbero verificarsi problemi imprevisti.
- Elevato carico sulla rete del server applicativo.
- Nessuna integrazione.
- Possibilità di modificare le impostazioni dell'applicazione analizzata.
- Nessun supporto per le tecnologie necessarie.
- Difficoltà di configurazione.
Abbiamo avuto una situazione in cui finalmente abbiamo lanciato AppScan: abbiamo faticato a ottenere accesso all'applicazione, abbiamo ottenuto 3 account e ci siamo rallegrati — finalmente controlliamo tutto! Abbiamo avviato la scansione e la prima cosa che ha fatto AppScan è stata entrare nel pannello di amministrazione, cliccare su tutti i pulsanti, cambiare metà dei dati e poi ha anche bloccato il server con le sue -richieste. Lo sviluppo con i test ha detto:
— Ragazzi, state scherzando?! Vi abbiamo dato gli account e voi avete bloccato il banco!
Tenete conto dei potenziali rischi. Idealmente, preparate un banco di prova separato per il test della sicurezza informatica, che sarà isolato dal resto dell'ambiente, e sarebbe consigliabile controllare il pannello di amministrazione manualmente. Questo è un pentest — i restanti percentuali di sforzo che non stiamo considerando ora.
Vale la pena considerare che si può utilizzare questo come analogia ai test di carico. Nella prima fase si può attivare lo scanner dinamico con 10-15 flussi e vedere cosa succede, ma di solito, come dimostra la pratica, non c'è nulla di buono.
Alcune risorse che di solito utilizziamo.
Vale la pena evidenziare è un "coltellino svizzero" per ogni esperto di sicurezza. Lo usano tutti ed è molto pratico. Ora è disponibile una nuova versione dimostrativa dell'enterprise edition. In precedenza era solo un'utilità stand alone con plugin, ma ora finalmente gli sviluppatori stanno creando un grande server da cui sarà possibile gestire più agenti. È fantastico, consiglio di provarlo.
Integrazione nel processo
L'integrazione avviene in modo abbastanza buono e semplice: avvio della scansione dopo un'installazione riuscita applicazione su stand e scansione dopo il completamento con successo del test di integrazione.
Se le integrazioni non funzionano o ci sono dei segnaposto e funzioni mock, è senza senso e inutile — qualunque pattern inviamo, il server risponderà comunque in modo identico.
- Ideale è un ambiente dedicato per i test.
- Prima dell'inizio dei test, annota la sequenza di login.
- Il test del sistema di amministrazione è solo manuale.
Processo
Una panoramica generale sul processo e sul funzionamento di ciascun strumento in particolare. Ogni applicazione è diversa: una può avere un'analisi dinamica più efficace, un'altra può eccellere in quella statica, un'altra ancora nell'analisi OpenSource, nei pentest o in qualcos'altro, ad esempio eventi con .
Ogni processo ha bisogno di controllo.
Per comprendere come funziona un processo e dove può essere migliorato, è necessario raccogliere metriche da tutto ciò che è accessibile, comprese le metriche di produzione, quelle degli strumenti e quelle dei tracker di difetti.
Qualsiasi dato è utile. È importante guardare attraverso diverse angolazioni per capire dove viene applicato meglio ciascuno strumento e dove il processo ha specifiche difficoltà. Potrebbe essere utile esaminare il tempo di risposta dello sviluppo per capire dove migliorare il processo in base al tempo. Più dati ci sono, più angolazioni si possono costruire, da quelle di alto livello fino ai dettagli di ciascun processo.
Poiché tutti gli analizzatori statici e dinamici hanno proprie API, modi di avvio e principi, alcuni hanno scheduler e altri no, stiamo creando uno strumento AppSec Orchestrator, che consente di creare un unico punto di accesso a tutto il processo del prodotto e gestirlo da un'unica posizione.
Per i manager, gli sviluppatori e gli ingegneri della sicurezza c'è un punto di accesso da cui si può osservare cosa è attivo, configurare e avviare la scansione, ottenere i risultati della scansione e presentare requisiti. Ci sforziamo di allontanarci dai documenti cartacei, traducendo tutto in formati comprensibili utilizzati nello sviluppo: pagine su Confluence con stato e metriche, difetti in Jira o in diversi tracker di difetti, oppure integrando nel processo sincrono/asincrono in CI/CD.
Punti Chiave
Gli strumenti non sono l'aspetto principale. Prima di tutto, bisogna pensare al processo—poi implementare gli strumenti. Gli strumenti sono utili, ma costosi, quindi si può partire dal processo e impostare l'interazione e la comprensione tra sviluppo e sicurezza. Dal punto di vista della sicurezza, non bisogna 'bloccarsi' su tutto, dal punto di vista dello sviluppo—se c'è qualcosa di high mega super critico, allora bisogna risolverlo, non chiudere gli occhi sul problema.
Qualità del prodotto — obiettivo comune sia per la sicurezza che per lo sviluppo. Ci impegniamo a far sì che tutto funzioni correttamente, evitando rischi reputazionali e perdite finanziarie. È proprio per questo motivo che promuoviamo un approccio DevSecOps e SecDevOps, al fine di instaurare una comunicazione efficace e migliorare la qualità del prodotto.
Iniziate con ciò che già esiste: requisiti, architettura, controlli parziali, formazione, linee guida. Non è necessario applicare subito tutte le pratiche a tutti i progetti — procedete in modo iterativo. Non esiste uno standard unico — sperimentate e provate approcci e soluzioni diversi.
Tra i difetti della sicurezza informatica e i difetti funzionali c'è un segno di uguaglianza..
Automatizzate tutto, ciò che si muove. Tutto ciò che non si muove — movimentatelo e automatizzatelo. Se qualcosa viene fatto manualmente, non è un buon segmento del processo. Potrebbe valere la pena rivederlo e automatizzarlo anche.
Se la dimensione del team di sicurezza è ridotta — utilizzate i Security Champions..
È possibile che ciò di cui ho parlato non sia adatto a voi e che troviate qualcosa di vostro — ed è una cosa positiva. Ma scegliete gli strumenti in base ai requisiti specifici del vostro processo.. Non dare ascolto a ciò che dice la community riguardo a questo strumento, e a questo altro che è migliore. Potrebbe essere che il tuo prodotto si dimostri completamente diverso.
Requisiti per gli strumenti.
- Basso livello di falsi positivi.
- Tempo di analisi adeguato.
- Facilità d'uso.
- Disponibilità di integrazioni.
- Comprensione della roadmap di sviluppo del prodotto.
- Possibilità di personalizzazione degli strumenti.
La presentazione di Yuri è stata scelta come una delle migliori al DevOpsConf 2018. Per scoprire ulteriori idee interessanti e casi pratici, vieni il 27 e 28 maggio a Skolkovo per nell'ambito di . E ancor meglio, se sei disposto a condividere la tua esperienza, allora per la presentazione entro il 21 aprile.
Fonte: habr.com
