Sviluppa la sicurezza prima o come fase successiva?

Al lavoro abbiamo una lista di cose semplici / standard che non dovremmo fare. Come query non parametrizzate e simili. Dobbiamo rivedere il nostro codice e dovremmo chiedere a qualcun altro di revisionarlo per accertarci che nessuno dei no-nos sia implementato. Dopo averlo passato un paio di volte, non puoi fare a meno di pensare alla sicurezza mentre fai il codice. Secondo me, dovresti codificare per sicurezza mentre codi per funzionalità. Tutto il tempo. Poche eccezioni.

In primo luogo con qualsiasi applicazione che sarà disponibile al pubblico o in esecuzione su macchine rivolte al pubblico, cerco di progettare per sicurezza all'inizio. Quali rischi può potenzialmente esporre questa applicazione? Come possono essere mitigati? Qual è l'esito peggiore che potrebbe derivare da un compromesso di sicurezza di questa applicazione e cosa si può fare per minimizzare il dolore di quel risultato?

Se si progetta di essere sicuro fin dall'inizio, è necessario pensarci meno quando si sta effettivamente digitando. Naturalmente ci sono delle pratiche che devi seguire per prevenire gli attacchi più comuni, ma se l'applicazione è strutturata per comportarsi in un modo più sicuro fin dall'inizio, sarà molto più facile mantenere la sicurezza del codice più tardi.

Esistono due tipi di problemi di sicurezza:

• Problemi localizzati, come l'overflow del buffer derivante da una mancanza di controllo dei limiti dell'array o di iniezioni SQL derivanti da query confuse con stringhe. Questi possono essere risolti usando buoni strumenti di programmazione (i sistemi di tipo buono ne cattureranno molti). Una volta trovati, possono essere riparati facilmente; ma quando ce n'è uno di solito ce ne sono molti simili.
• Problemi di progettazione profondi, come non segregare abbastanza le autorizzazioni o impegnarsi in protocolli che perdono. Ottenere questi giusti richiede una pianificazione intelligente. Una volta trovati, sono spesso un incubo da risolvere, perché è necessario riscrivere grandi quantità di codice o introdurre incompatibilità maggiori.

Non progettare per la sicurezza è come costruire una casa di paglia. Funziona fino a quando arriva il grande lupo cattivo, e poi perdi. Ciò non significa che tu debba sempre progettare per la sicurezza, non è sempre richiesto il wolfproofness. Ma non trasformi una casa di paglia in una casa di mattoni fissando la sicurezza; è una casa completamente diversa. Allo stesso modo, se non si progetta per la sicurezza dal primo giorno, la protezione sarà più una riprogettazione completa di un'evoluzione della luce.