Ottima domanda.
Innanzitutto, il "minimo" che hai citato si riferisce alla politica di requisiti minimi di Microsoft , non necessariamente al minimo delle "best practice del settore". Non che io stia dicendo che è sbagliato, ma lo stesso MS-SDL continua dicendo che il loro SDL non è necessariamente adatto a qualsiasi organizzazione al di fuori di Microsoft ... Infatti gli architetti MS-SDL, come Michael Howard, sono spesso -questo quotato:
Don't do what we do, do what we did.
Vale a dire, non tanto i requisiti prescritti che appaiono nel documento (sebbene potrebbero essere per lo più molto buoni), ma hanno ripetutamente eseguito studi, tra cui analisi basate sul rischio, confronti di metriche storiche, analisi delle tendenze , analisi delle cause principali, prove in diversi team per vedere cosa "prende", ecc.
Non esiste un SDL semplice e ben definito che puoi semplicemente scaricare installare ed essere sicuro. Questo punto della SM è azzeccato: devi davvero adattare il tuo SDL in base alla tua organizzazione specifica, ai tuoi team, alle loro competenze, ai tipi di prodotti che stanno costruendo, al processo di sviluppo attuale, al profilo di rischio, ecc. Ecc. questa è davvero la soluzione migliore per "provare" ...
Inoltre, SDL non è una cosa da fare una sola volta, o anche una questione di definizione e implementazione della politica corretta. Costruire un SDL è di per sé un processo continuo, che può richiedere diversi anni per essere implementato completamente. Microsoft ha fatto parecchie iterazioni fino a quando il loro SDL non ha raggiunto qualcosa di esemplare ... E ci sono voluti un altro paio d'anni per farlo diventare davvero radicato nella maggior parte dei loro sviluppatori. Non si può realmente "provare" un SDL, perché in genere il vantaggio non viene mostrato entro il primo mese o due: è davvero un investimento a lungo termine.
Quindi, per le organizzazioni appena agli inizi e cercando di definire il loro SDL, suggerirei di prenderlo con calma, far sì che qualcuno con esperienza li guidi nel processo:
- Inizia mappando la situazione attuale, il processo, i team, l'esperienza, la flessibilità, ecc.
-
Se i team + gestione non sono convinti al 100% della necessità di SDL e, in generale, della sicurezza, prendi in considerazione una revisione della sicurezza iniziale solo per portare a casa i problemi ... Un pentest è spesso molto utile qui, semplicemente perché può essere abbastanza visivo (NON perché è necessario per l'SDL stesso a questo punto).
- Assicurati a questo punto di avere un buy-in - sia da uno sponsor esecutivo, sia dai team stessi. Senza entrambi, la SDL è destinata al fallimento.
- Formazione! Gli sviluppatori amano fare le cose bene, se sanno come .
- Aggiungete lentamente minimo attività di sicurezza aggiuntive, in base ai vantaggi che riceverete per loro, rispetto allo sforzo investito e all'interruzione dei team di sviluppo. Ricorda, il punto dell'esercitazione è di coinvolgere TUTTI i componenti della sicurezza e non disattivarli immediatamente.
- Configura la tua esperienza di sicurezza, sia nel tuo team (come campione della sicurezza) o in un team centrale con cui tutti possono parlare e farli parlare . Meglio ancora, è un modello ibrido di entrambi (come nel modello MS).
- In base alla tua capacità di investimento aggiuntivo per la sicurezza, in ogni ciclo aggiungi minimo attività aggiuntive, in aggiunta a quelle precedenti. Il punto è di farli così abituati a fare una-due piccole cose, che diventa una seconda natura (quasi) e che non richiede più "tanto tempo per fare questo genere di sicurezza". Quindi avrai larghezza di banda per altri ...
- Raccogli le metriche lungo il percorso, così puoi dire cosa funziona e cosa no, e anche per mostrare il beneficio dall'investimento SDL alla gestione.
- Più allenamento!
Ora, il vero problema è che la lista sopra, sembra molto.
Ma in realtà non lo è, dal momento che la maggior parte di questi proiettili sono "meta-attività". Alcuni di essi dovrebbero probabilmente essere eseguiti da un esperto / ragazzo / consulente di sicurezza, con esperienza nell'implementazione di SDL in un tipo di ambiente simile al tuo . Certo, non è ancora così semplice, ma quando lo faccio metto l'enfasi su interruzioni minime e investimenti costanti. può essere fatto leggero.