Quali pratiche di sviluppo del software sicuro impiegate?

Lavoro su un progetto noto come progetto SDL (Security Development Lifecycle) in Microsoft (http://microsoft.com/sdl). In breve, è un insieme di pratiche che devono essere utilizzate dai gruppi di prodotti prima che vengano spediti prodotti per migliorare la sicurezza.Quali pratiche di sviluppo del software sicuro impiegate?

Negli ultimi due anni, abbiamo pubblicato una grande quantità di documentazione SDL, in quanto i clienti chiedono maggiori informazioni su ciò che stiamo facendo.

Ma quello che vorrei sapere è:

Cosa stai facendo all'interno dell'organizzazione per contribuire a migliorare la sicurezza del vostro prodotto?
Cosa funziona? Cosa non funziona?
Come hai ottenuto la gestione di accettare questo lavoro?

Grazie.

fonte

2010-03-31 Michael Howard-MSFT

Penso che questa sia una buona domanda da un bravo ragazzo. Il software di Microsoft viene distribuito a una grande quantità di utenti e ha migliorato la sicurezza in termini di sicurezza (ad esempio, confronta IIS 4 con IIS 7). Penso che il recente attacco focalizzato su Adobe Reader ultimamente sia in qualche modo un riconoscimento che l'attacco ai prodotti Microsoft sta diventando più difficile. Non è assolutamente perfetto Microsoft, ma hanno imparato alcune lezioni e stanno migliorando. –

@Jeff Moser Allora che ne dici di quel nuovo IE 8 0-day su Windows 7 in pwn2own? Quello che Microsoft dice è privo di significato quando il loro software è costantemente rotto. Tutto quello che vedo è Exploit after Exploit, assolutamente nulla è cambiato. – rook

@TheRook: ogni volta che il tuo prodotto viene utilizzato da centinaia di milioni di utenti, diventerai un bersaglio. La sicurezza è difficile e richiede molte strategie di difesa in profondità. È una battaglia molto asimmetrica in cui devi difendere da tutto e l'attaccante deve solo trovare una debolezza. Inoltre, con una comunità di utenti così diffusa, è necessario eseguire molti test di regressione per verificare una correzione. È difficile e raccomando persone come Michael che stanno provando onestamente. Mettiamo da parte le tendenze alla guerra di fiamma e affrontiamo questa domanda in modo equo indicando le buone pratiche e aiutando la comunità. –

Pensiamo prima di codificare. Stranamente, evita molti bug, compresi quelli che sono sfruttabili da parti avverse e che sono ormai noti come "buchi di sicurezza".

Parte del trucco non è di far avvicinare nessuno a una tastiera se non ha una solida esperienza e competenza.

fonte

2010-03-31 21:08:15

Più esperienza non è sempre meglio. Ad esempio, gli attacchi puntatori penzolanti non hanno nemmeno 5 anni, ma vengono utilizzati per sfruttare IE su Windows 7. Un programmatore esperto che conosce il buffer trabocca molto bene, probabilmente mancherà delle nuove tecniche di sfruttamento. – rook

e questo è il motivo per cui le difese sono di fondamentale importanza: non otterrai mai il 100% del tuo codice al 100% man mano che vengono costantemente create nuove tecniche di exploit. –

Onestamente, leggere your book è stato un buon inizio. :-)

rispondere alle vostre domande:

Crypto è un mio hobby che a volte mi blog su (ad esempio su TLS e AES). Dopo aver scritto la mia implementazione di AES, ho imparato abbastanza da sapere oltre ogni ragionevole dubbio che non dovrei mai usare la mia implementazione, ma piuttosto usare quelli scritti dai ragazzi CryptoAPI e OpenSSL.
- Code reviews dove le persone che hanno problemi di sicurezza sono contrassegnate come richiesto.
- Avere una lezione sul posto con laboratori per aumentare la consapevolezza dei problemi menzionati nel tuo libro e mailing list interne che parlano di nuovi problemi.
- Diverse persone ascoltano il numero Security Now podcast per rimanere aggiornati su quali tipi di problemi sono disponibili e su cosa viene attaccato. Questo influenza indirettamente il design.
Fatta eccezione per un corso sul posto e l'acquisto dello strumento di revisione del codice, nessuno di questi richiede l'approvazione della direzione.

fonte

2010-03-31 21:43:34

Qual è la tua opinione sulla sicurezza ora? Trovo che usano la frase "sicurezza migliore" abbastanza da farmi pensare che Gibson si concentri sull'assolutismo piuttosto che sulla gestione del rischio. –

Vorrei che andasse più in profondità, ma è facile da ascoltare in viaggio. Steve è un po 'più paranoico di me, ma immagino sia ok. –

Sono uno sviluppatore Mac indie, ma anche un evangelista di sicurezza della piattaforma: Sono l'autore di Pro Cocoa Application Security pubblicato da Wrox. In quel libro io difendo la tecnica di sicurezza sicura che uso io: si basa sulla modellazione di minacce Swiderski e Snyder, ma con due modifiche. Rendo più leggero considerando i punti di ingresso che accedono alle risorse senza utilizzare DFD. Inoltre, mi concentro maggiormente sull'identificazione degli utenti e dei malfunzionamenti, che a mio parere rendono più applicabile il software shrinkwrap.

Per quanto riguarda il supporto degli strumenti, utilizzo l'analizzatore statico Xcode (basato su clang), ma ho rilevato che non rileva alcune vulnerabilità comuni.Ho fatto dei bug però :-). Uso sempre anche la macro gcc _FORTIFY_SOURCE. Non ci sono buoni strumenti per l'analisi del rischio Mac, ma ci sto lavorando ... ;-)

Ho parlato di sicurezza agli sviluppatori Mac durante conferenze e podcast e ottenuto molti feedback, se mi vuoi per chiarire qualsiasi cosa abbia detto o sia interessato al feedback della comunità, per favore chiedi nei commenti. Le domande private sono benvenute (anche se preferirei rimanere sul forum): iamleeg al punto di riferimento di securemac com.

fonte

2010-03-31 22:10:55

Quali pratiche di sviluppo del software sicuro impiegate?

risposta

Problemi correlati