La sicurezza del software o del sistema dipende enormemente dal tipo di sistema che si sta progettando, dai dati memorizzati e dall'ambiente normativo / contrattuale in cui viene utilizzato. La maggior parte delle organizzazioni spesso non è in grado di articolare il livello di sicurezza richiesto nei sistemi che produce.
Personalmente, penso alla sicurezza su tre livelli. Il primo è il livello più alto: il livello aziendale in cui la direzione decide i rischi per l'azienda, di solito indicato come Enterprise Risk Management (ERM) utilizzo di framework come COSO o IT governance, utilizzando framework come CoBIT o TOGAF . Le organizzazioni non devono utilizzare un framework riconosciuto ma possono contribuire a garantire che i problemi non vengano dimenticati e aiutano a stabilire le priorità altrimenti è facile eliminare i requisiti non funzionali come la sicurezza.
Ciò include anche la conformità, ad esempio una legge specifica del settore come Norme sulla sicurezza dell'HIPAA per informazioni sanitarie, obblighi contrattuali come PCI-DSS o specifiche dell'acquirente come FIPS 140-2 o Common Criteria ). Ciascuno è verificato in diversi modi.
Il secondo è il livello di organizzazione dello sviluppo: quali pratiche deve intraprendere l'organizzazione durante lo sviluppo di un sistema. Esistono diversi standard o framework, come ad esempio:
- Building Security In Model (BSIMM)
- Safecode
- Ciclo di vita dello sviluppo della sicurezza di Microsoft
Questi raccomandano pratiche diverse da utilizzare in diverse fasi dello sviluppo del software. Ad esempio, molti framework raccomandano modellazione delle minacce per individuare precocemente i difetti di progettazione (dove sono più economici da riparare), aderendo alle linee guida di codifica sicure e usando gli analisi statica strumenti per trovare difetti come il codice scritto quindi test di penetrazione in seguito, utilizzando strumenti che emulano metodi di attacco comuni.
Il terzo è una guida per ciascuna delle pratiche specifiche. Concentrandosi sulle pratiche di codifica di Microsoft, come menzionato dall'OP, la sfida con la documentazione online di Microsoft è, mentre ce ne sono molte, in gran parte obsolete. Concentrati invece su OWASP per il lato web. OWASP affronta ogni vulnerabilità da una prospettiva neutrale rispetto al venditore, quindi collega alle mitigazioni specifiche del fornitore.
Sebbene si concentri molto sul C ++, considera Coding sicuro (il link è alla pagina di Amazon) se per il lato desktop e il libro di follow up su codifica protetta per Vista . Microsoft Centro sicurezza MSDN raccoglie informazioni su strumenti e librerie Microsoft.
Se desideri una formazione o certificazione indipendente dal fornitore sulla codifica sicura, considera i corsi SANS o (ISC) 2 CSSLP . Ricorda che la sicurezza non riguarda solo il codice: assicurati che le tue operazioni e il personale IT abbiano anche considerato la sicurezza nella progettazione dell'infrastruttura, che il tuo QA sappia come testare le funzionalità di sicurezza e i tuoi architetti considerino la sicurezza (anzi, IASA considera la sicurezza uno dei quattro principali raggruppamenti di attributi di qualità ).