Checklist per lo sviluppo del software sicuro [chiuso]

Questo è un po 'come una raccomandazione di prodotto, quindi potrebbe finire chiuso comunque. Devi anche fare attenzione a distinguere tra una checklist e uno standard.

Se stai cercando alcuni elenchi di controllo di alto livello da utilizzare per il tuo processo di sviluppo, potresti voler controllare SANS SWAT , che copre più considerazioni logiche piuttosto che problemi specifici a livello di codice. Potresti anche essere interessato alla serie ISO 27000 (ie, ISO / IEC 27034 ) (non solo 27001 o 27002 ). Altre metodologie includono STRIDE (non lo consigliamo) e DREAD di Microsoft

Non è chiaro se questo è per un linguaggio di programmazione specifico, ma il JPL della NASA ha delle linee guida per C e JAVA che possono essere utili da considerare come parte degli standard di sicurezza. Oracle ha le proprie linee guida sulla sicurezza JAVA . Le linee guida CERT già presenti nella risposta Jaques si trovano nello stesso reame.

Dovrai chiarire i tuoi obiettivi e costruire su questi strumenti per creare:

1. Standard di codifica sicura (il codice verrà formattato in questo modo)
2. Standard specifici di libreria / piattaforma (i token CSRF useranno questa funzione comune)
3. Pratiche di sviluppo sicuro / SDLC (il codice verrà inserito in questi scanner, strumenti o processi prima di essere commesso; pen test prima della promozione in produzione)
4. Test e revisioni in corso (ricertificazioni delle applicazioni che si verificano regolarmente, procedure di divulgazione responsabili)

Una checklist può essere un buon modo per iniziare in quanto è chiara, ma i processi sbagliati possono essere altrettanto dannosi - ad esempio, promuovi il ramo sbagliato con il codice buggy).

È impossibile ottenere un codice sicuro definendo un insieme di regole con cui conformarsi. Lo standard CERT a cui Jacques si collega è un buon esempio di questo. Elenca "cose cattive da fare", e guardandole attraverso non ho trovato nulla di particolarmente in disaccordo. Ma la lista è così lunga e molti degli articoli così esoterici e generalizzati sono relativamente inutili se non come materiale di riferimento come un dizionario.

Probabilmente non esiste una buona metodologia che ti garantisca sicurezza. La sicurezza arriva attraverso la conoscenza degli sviluppatori sulla sicurezza e il lavoro in un'organizzazione in cui la sicurezza è valutata. Se la tua organizzazione non comprende la sicurezza, non ne otterrai nessuna.

Il meglio che puoi fare è incoraggiare lo sviluppo sicuro con l'esempio e attraverso le revisioni del codice. Avete bisogno di persone esperte per leggere il codice prima che entri nel vostro prodotto e fornire critiche costruttive. Incoraggia i tuoi sviluppatori a comprendere almeno l'Owasp top 10. Alcuni saranno migliori di altri.

La sicurezza riguarda la cultura, non i cicli di vita o le regole che seguono. Non puoi definire la sicurezza, poiché è sempre un obiettivo in movimento e diverso per ogni situazione.

Dai un'occhiata a SDLC di Microsoft. Raccomandano l'uso di strumenti di analisi del codice statici per catturare le cose semplici, come gli array fuori limite, ecc., E utilizzare il test fuzz dinamico per aiutare a trovare le cose più difficili. Ma si affidano anche ai loro programmatori che portano un alto livello di competenza al loro compito.

Se stai cercando consigli e indicazioni in testo semplice, guarda "Codifica sicura in C e C ++" di Robert C. Seacord. Il terzo medio del libro è dedicato a un elenco dettagliato di problemi e soluzioni e sembra essere la "lista di controllo" degli articoli a cui sei interessato.

Il team CERT dell'istituto di ingegneria del software presso l'università carnegie mellon ha uno standard di codifica sicuro per C, C ++, Java, Perl:

link

Ti dice esattamente ciò che i programmatori dovrebbero fare o meno, come hai detto. Ad esempio:

Do not apply the sizeof operator to a pointer when taking the size of an array

Per ogni regola, fornisce esempi di codice validi e negativi e una spiegazione dei rischi.

Gunnar Peterson ha fatto un prezo (disponibile tramite YouTube) che ha elaborato ulteriormente tramite il suo post sul blog Processo non risultati . Mi è piaciuto questo approccio e anche i commenti.

I OWASP Proactive Controls e OWASP Periodic Table of Vulnerabilties sono approcci di checklist che funzionano alla perfezione nella creazione di sicurezza. Jim Manico ha fatto un'ottima presentazione sui controlli proattivi OWASP, disponibili a questa posizione YouTube .

Ecco alcuni mapping dalle categorie di checklist SANS SWAT a Principi di AppSec, OWASP Conucopia e progetti Proactive Controls.