In che modo i controlli di sicurezza possono essere integrati in un progetto agile?

Le linee guida Microsoft per il ciclo di vita dello sviluppo della protezione (SDL) per Agile raccomandano pratiche di sicurezza durante progettazione, implementazione e rilascio del progetto. Indipendentemente dalla metodologia di sviluppo in uso, nessuna riga di codice dovrebbe essere messa in produzione fino a quando non è stata sottoposta a una revisione della sicurezza. Se i vincoli finanziari impediscono questo livello di revisione della sicurezza da parte di un professionista, una revisione della sicurezza deve essere condotta dai colleghi prima che un rilascio possa essere finalizzato. La finalizzazione di una versione può essere trasformata in un processo divertente, ho visto le aziende ospitare hacker-a-thons a livello aziendale e distribuire premi per bug interessanti.

Microsoft ha lavorato molto su SDL e la sicurezza di Microsoft è migliorata.

La risposta breve è: integrare la sicurezza nel ciclo di vita dello sviluppo del software. Dovrebbe essere integrato in ogni fase: progettazione, implementazione e test.

Ci sono molte risorse su come creare sicurezza nel ciclo di vita dello sviluppo del software. Vedi, ad esempio, SDLC di Cigital (i 7 punti di tocco)], < a href="http://www.microsoft.com/security/sdl/default.aspx"> SDLC di Microsoft , SDLC di OpenSAMM , BSIMM , CERT's Build Security In o domande qui come Sviluppo sicuro del software , Creazione di ambienti di sviluppo software sicuri , Ciò che è considerato il il ciclo di vita di sviluppo sicuro più semplice (o più leggero)? , Quale modello di sviluppo del ciclo di vita sicuro scegliere? .

Una "recensione di sicurezza" non è una cosa singola. Esistono diverse forme di revisione della sicurezza. L'integrazione della sicurezza nel ciclo di vita dello sviluppo del software richiede di tenere conto della sicurezza in ogni fase del percorso e tali diversi tipi di revisione della sicurezza avranno implicazioni diverse. Questi elementi potrebbero includere:

• Dovresti avere una revisione del design della sicurezza, per rivedere il tuo design per comprendere i rischi di sicurezza a livello di architettura associati al design e il potenziale per difetti di progettazione (questo è ciò che Microsoft chiama "modellazione delle minacce"). Non è necessario riesaminarlo ogni volta che cambi l'implementazione, solo quando cambi il design.

• Dovresti anche avere una revisione del codice di sicurezza, per rivedere il tuo codice per identificare potenziali difetti del codice a livello di implementazione che potrebbero compromettere la sicurezza. Ogni volta che scrivi un nuovo codice o cambi il codice esistente, devi rivedere quel codice per i bug di implementazione.

• Dovresti anche integrare la sicurezza nei tuoi sforzi di test. Prima di rilasciare una nuova versione, potresti testarne la sicurezza, concentrandoti in particolare sulle funzionalità che sono state cambiate.

Se il tuo modello di sicurezza si basa sul concetto di un controllo esterno point-in-time dell'intera base di codice, allora stai sbagliando la sicurezza.

... Probabilmente stai anche usando l'audit sbagliato. Ma ci arriveremo.

Al di là della domanda, tutto il codice deve essere controllato per sicurezza. In molti casi, questo è in realtà un requisito legale: nessun codice viene spedito senza un audit, periodo. La saggezza tradizionale suggerisce che tale verifica sia un evento ad un certo punto del ciclo di vita, ma un modo più ragionevole per farlo è quello di verificare il codice mentre si procede. Cioè, tutto il codice ottiene un controllo di sicurezza prima può essere archiviato nella tua base di codice.

La teoria è semplice; il repository è già stato controllato, quindi non è necessario rivedere i suoi componenti come una procedura standard. Ma quando viene proposta una nuova funzionalità o patch o bugfix, il diff deve essere firmato dal / i manutentore / i appropriato / i. Puoi ottenere l'approvazione per tutto ciò che è importante per te. Ad esempio, il kernel Linux ha un processo di approvazione piuttosto complesso che richiede diverse approvazioni lungo la strada per qualità, semplicità, coerenza, prestazioni, ecc. I requisiti possono variare, ma un controllo di sicurezza dovrebbe far parte di tale processo di approvazione.

In questo caso non stai verificando il prodotto end-to-end, stai solo controllando il diff. Ma migliaia di piccoli audit nel corso del ciclo di sviluppo del prodotto saranno molto più approfonditi e completi di quanto qualsiasi sperimentazione end-to-end possa sperare di essere.

Una verifica end-to-end completa del prodotto è certamente utile e non dovrebbe essere evitata. Questo audit dovrebbe concentrarsi sul prodotto nel suo insieme in un modo che non è facile da fare durante i controlli a livello di patch che hai fatto. Volete guardare l'intera foresta di tanto in tanto, non solo i singoli alberi. La tempistica di questi audit su larga scala dovrebbe probabilmente corrispondere a rilasci importanti, modifiche importanti o verifiche di certificazione di conformità.

Mantenendo sempre aggiornato il controllo a livello di patch, puoi garantire che il codice sia sempre mantenuto in uno stato verificabile, così puoi continuare a spedirlo regolarmente con fiducia.

Informazioni sulle approvazioni in tempo di commit Se la tua azienda non sta facendo questo, allora stai facendo tutto sbagliato. Ci sono dozzine, forse centinaia, di problemi che vengono risolti richiedendo che ogni modifica del codice sia approvata da almeno un'altra persona, incluso (e soprattutto) durante lo sviluppo iniziale. Devi sempre avere almeno due persone che capiscano come funziona ogni riga di codice e che sono d'accordo sul fatto che il codice sia corretto.

Questo è importante almeno quanto i test unitari. Se non lo fai, interrompi tutto e rivedi le tue politiche in merito a qualità e sicurezza.

Sì, questo processo è in scala. Come notato sopra, il più grande progetto software al mondo lo usa, così come alcune delle società di software più agili e di successo del mondo.

Come altri hanno suggerito, puoi costruire storie sulla sicurezza. E certamente ti incoraggerei a farlo.

Ma se parli di un team esterno che entra e spende diverse settimane a fare un audit ... che, a mio avviso, è più agile che sicuro.

So che agile pone un strong accento sulla spedizione di frequente - dopo tutto, come ridurrai il ciclo di feedback se il tuo software non è nelle mani dei clienti? Ma per molte organizzazioni, rilasciare ogni 2/3/4 settimane semplicemente non è un'opzione. Oppure hanno un lungo processo di revisione QA / QC e l'organizzazione QA non è pronta ad andare agile. Oppure hanno altri requisiti di certificazione (ad es. ISO) che non rientrano nel ciclo di vita agile.

Di conseguenza, molti team agili hanno scoperto subito che avevano bisogno di disaccoppiare le loro versioni dalle iterazioni o dagli sprint.
Cioè, invece di promuovere la produzione, promuovi i cambiamenti in un ambiente dedicato alla sicurezza / QA / qualunque. Quando il codice è stato certificato lì, lo si promuove alla produzione (o al prossimo cancello).

Se hai creato storie di "abuso", presumibilmente il tuo elenco di difetti / problemi dovrebbe essere breve.

Se viene rilevato un difetto, può essere inserito nel backlog o con priorità per una correzione immediata, a seconda della gravità.

Ovviamente l'ambiente extra non è gratuito ... ma secondo la mia esperienza è più economico delle alternative (che in genere portano i team a pestarsi l'un l'altro).

Aggiungi casi di abuso.

Se esiste una funzionalità che il sistema deve mostrare, si utilizza un caso d'uso. Se esiste una funzionalità che il sistema non deve mostrare, utilizzare un caso di uso improprio.

"Come concorrente, voglio interrogare il database sul back-end per i dati sensibili dell'azienda, questo non deve accadere."

"Come attivista hacktivist, voglio usare la DMZ per riflettere gli attacchi al governo, questo non deve accadere".

Il proprietario del prodotto può dare la priorità a queste storie insieme alle altre, ma sono testabili come qualsiasi altra storia utente.

(Ammetto liberamente che non sono un iniziato dei misteri segreti dell'agile: Agile è diventato qualcosa come il 77 ° ordine dei massoni, pieno di misteri e comandamenti che NON DEVONO ESSERE ROTTI, per paura di orrori ineffabili).

Puoi fare audit per ogni versione come un progetto a cascata. Sebbene abbia notato alcuni problemi nel farlo, molte società di sicurezza possono lavorare in modo molto efficace con progetti agili. Tuttavia, se rilasci frequentemente, il costo potrebbe essere proibitivo.

Un altro approccio è spostare i test internamente. Se acquisti uno strumento di scansione, puoi eseguire i tuoi controlli. Potrebbero non essere così approfonditi come una società di sicurezza specializzata, ma puoi eseguirli tutte le volte che vuoi. Forse li si integra con un sistema di generazione notturno, o addirittura li si esegue in un hook pre-commit usando l'integrazione continua. Esistono due tipi principali di questi strumenti: Dynamic Application Security Testing (DAST) che è un test di penetrazione automatizzato e Static Application Security Testing (SAST) che è la revisione automatica del codice sorgente. Un vantaggio di SAST è che i risultati vengono riportati nei termini dello sviluppatore: il file del codice sorgente e il numero di riga. Penso che gli strumenti di test DAST / SAST si adattino molto bene al modello agile; in un certo senso sono unit test per la sicurezza.

Un team di sviluppo con processi di sicurezza maturi utilizzerà test interni e di terze parti. SAST / DAST viene utilizzato per garantire che tutto il codice ottenga almeno una revisione di sicurezza di base e per rilevare i problemi in anticipo. I test di penetrazione vengono eseguiti periodicamente per cercare di rilevare problemi complessi che i test automatizzati non sono in grado di identificare. Questo può essere su un programma fisso, o può essere basato sul rischio, guardando le modifiche in ogni rilascio.

La tua domanda riguardava gli audit di sicurezza. Naturalmente, ci sono altri aspetti della sicurezza di un'applicazione. La modellazione delle minacce per garantire la sicurezza si riflette nel design. Seleziona gli strumenti di sviluppo e i framework che incoraggiano la sicurezza e dai agli sviluppatori la formazione per utilizzare questi strumenti in modo sicuro. Questo è lo stesso dello sviluppo di waterfall, ma con agilità è più importante incorporare queste competenze all'interno del team di sviluppo, piuttosto che far entrare periodicamente il team di sicurezza.