Insegnamento "Protetto dal design"

La risorsa canonica per il concetto di sicurezza per design è "Protezione delle informazioni nei sistemi informatici " di Saltzer e Schroeder. L'essenza è distillata nei loro 8 principi del design sicuro:

1. Economia del meccanismo
2. Valori predefiniti fail-safe
3. Completa mediazione
4. Apri progetto
5. Separazione dei privilegi
6. Minimo privilegio
7. Minimo meccanismo comune
8. Accettabilità psicologica

Questi principi, stabiliti nel 1974, sono ancora pienamente applicabili oggi.

Sarà difficile insegnare i principi di progettazione in 30 minuti. Sono d'accordo con gli altri che dicono che devi farli eccitare in qualche modo. Ho sviluppato il gioco di carte "Elevazione dei privilegi" per rendere le persone entusiaste della modellazione delle minacce, potrebbe essere utile. ( link )

Insegnare alle persone come pensare come un utente malintenzionato è molto difficile, è più facile insegnarle su alcuni attacchi come l'SQL injection o lo scripting cross-site.

Infine, se vuoi provare a insegnare principi, ho fatto una serie di post sul blog che illustrano Saltzer e Schroeder con scene di Star Wars: link

Piuttosto che concentrarsi sulle regole e "seguire queste 5 regole e sei sicuro", mi concentrerei sull'insegnare agli sviluppatori gli attaccanti e il loro modo di pensare. Non puoi davvero coprire 5 cose diverse, ognuna delle quali richiede una conoscenza approfondita per implementare veramente correttamente, quindi perché provare?

Gli sviluppatori con cui ho parlato sembrano pensare che l'hacking sia "davvero difficile" e non capisco davvero quanto possa essere facile. Quindi, spiegare che cosa fanno veramente le persone per contrastare la sicurezza può essere un'apertura agli occhi.

Un esempio:

Alcuni anni fa stavo rivedendo un prodotto di reporting basato sul web di terze parti e avevamo uno sviluppatore del fornitore per creare alcuni rapporti usando il prodotto. Ho chiesto informazioni sulla sicurezza e su come ha funzionato nel loro prodotto. Ha proceduto a fare una "vista sorgente" sulla pagina Web del report e mi ha mostrato come tutto fosse HTML dinamico, e quindi era irrintracciabile. Rimasi sbalordito per un minuto, ma gli dissi che non era una sicurezza davvero praticabile, che non ti puoi fidare della fine del cliente, bla bla bla.

Non mi ha creduto, e ha chiesto come qualcuno potrebbe hackerare questo prodotto. Ho pensato per un minuto, ho detto che avrei collegato il browser a un server proxy ed esaminato quale fosse la richiesta / risposta. (Oggi userei solo il plug-in tamper-data). Ha poi detto che questo sarebbe "L'hack del secolo!" A questo punto ho appena gettato le mani nella sconfitta, dal momento che aveva già deciso che il suo prodotto era "sicuro". L'unico modo per convincerlo sarebbe quello di hackerare il suo prodotto, il che non valeva veramente il mio tempo dato che non avrei comunque acquistato il prodotto.

Il punto è che è necessario iniziare con la necessità di sicurezza e con cosa ci troviamo di fronte. Se non lo capiscono, è finita. Per lo meno infonderai un po 'di paura in loro, che è un buon motivatore. Da quello che ho visto, molti sviluppatori non "capiscono" e hanno bisogno di capire in primo luogo cosa stanno affrontando. Principalmente per essere in grado di capire PERCHÉ hanno bisogno di sviluppare applicazioni sicure.

Fai in modo che le persone siano realmente interessate alla sicurezza e potresti ottenere qualcosa da esso. Altrimenti temo che qualunque cosa tu presenti in 35 minuti cada nel vuoto.

Puoi prima attirare la loro attenzione. Una demo di un attacco SQL injection è semplice, comprensibile e potrebbe sottolineare l'importanza dell'argomento. Puoi fare riferimento ad esso durante la conversazione mentre crei punti.

Mi piace che entri nei confini della fiducia. Con la convalida dell'input, l'avrei colpito in modo più dettagliato. Prima convalida della lunghezza, quindi menziona la whitelist e la lista nera. Raccomandi che provino a correggere automaticamente i dati non validi o che l'input errato debba essere rifiutato? Tocca le strategie che consiglieresti.

Per quanto riguarda il privilegio minimo, questa potrebbe essere un'opportunità per presentare le idee del controllo degli accessi basato sui ruoli e i vantaggi rispetto a un sistema basato sull'utente.

Penso che ci sia l'opportunità di menzionare il principio della difesa in profondità. La sanitizzazione dell'input è fondamentale, ma seguirla nel codice richiedendo l'SQL parametrizzato sarebbe di aiuto anche se qualcuno salta la barca sull'input.

Per quanto riguarda la registrazione, assicurati che capiscano il delta tra un messaggio di errore visualizzato all'utente e il contenuto dei file di registro. E assicurati che non registrino nulla di sensibile.

Considera anche di discutere di un processo di sviluppo che aiuti a garantire che rimangano su una pista sicura. Assicurati che le recensioni dei peer code, l'uso di analizzatori di codici statici e analizzatori dinamici facciano parte del loro processo di sviluppo. Questo potrebbe essere al di fuori dello scopo della formazione, ma potresti insegnare loro come le recensioni e gli strumenti aiutano a migliorare il loro codice.

30-45 minuti ... ahi. Potresti tornare all'organizzatore e richiedere due o tre giorni, vedere che tipo di reazione ottiene. O forse un programma di 10 semestri ... Comunque, buona fortuna!

Hai un compito difficile, ovviamente, e tutte le considerazioni di cui parli hai menzionato ti daranno un piatto molto completo. Ma penso che qualche menzione o legame alla parola d'ordine più favorita di tutti, una strategia di difesa approfondita meno frequentemente implementata sarebbe molto utile per lavorare, se poteste. Oppure, forse lo si esprime in un altro modo: "La necessità di valutare e creare ridondanza delle misure di sicurezza contro qualsiasi vettore di minaccia maggiore in qualsiasi progetto di sicurezza decente".

Stai creando un'app Web e sei abbastanza sicuro di avere un meccanismo robusto per disinfettare qualsiasi & tutti gli sforzi di iniezione del codice dal tuo input? Bello. Ora supponiamo che un aggressore creativo trovi un difetto di implementazione a cui non hai mai nemmeno pensato, un difetto che consente ad alcuni codici veramente sgradevoli e potenti di ottenere di fronte alla tua applicazione reale. Stai progettando e amp; rafforzando la logica delle tue app con l'idea che potrebbe essere necessario affrontare lo scenario, o semplicemente assumerai che, poiché hai un meccanismo di difesa singolo strong e affidabile contro il codice davanti all'applicazione, puoi spostare il tuo concentrarsi su altre cose? Perché la differenza tra queste due scelte è spesso la differenza tra l'arrivare a qualcosa che potrebbe essere un solido design di sicurezza rispetto a quello che sarà quasi sicuramente un design di sicurezza intrinsecamente fragile.

(Nota: mentre sto scrivendo sto realizzando l'esempio di fare affidamento sulla disinfezione degli input come una difesa perfetta non è la migliore, perché nel mondo reale viviamo oggi, si spera che pochi sviluppatori competenti possano cadere la tentazione di prendere qualcosa di molto conosciuto come imperfetto come sanitizzazione dell'input come una linea di difesa solida, impenetrabile, speriamo, ma tu prendi il mio punto di vista più ampio ...)