Informazioni sulla sicurezza e sulla privacy da progettazione
Microsoft SDL sottolinea l'importanza della sicurezza e della privacy da progettazione. Le funzionalità di sicurezza e privacy non devono essere componenti aggiuntivi, ma componenti centrali dei prodotti e dei servizi Microsoft. La sicurezza viene incorporata nei prodotti definendo i requisiti di sicurezza all'inizio del ciclo di vita delle funzionalità, mantenendo modelli di minacce aggiornati per tutti i principali componenti e funzionalità del servizio e richiedendo una revisione manuale del codice per tutto il codice sorgente.
I requisiti di sicurezza e privacy
I requisiti di sicurezza e privacy devono influire sulla progettazione di tutte le applicazioni e dei sistemi a sicurezza elevata. In Microsoft, ogni prodotto, servizio e funzionalità che sviluppiamo inizia con requisiti di sicurezza e privacy chiaramente definiti. Poiché lo sviluppo software è un processo continuativo, aggiorniamo continuamente questi requisiti durante l'intero ciclo di vita di un prodotto per riflettere i cambiamenti nelle funzionalità richieste e nel panorama delle minacce. I fattori che influenzano i requisiti di sicurezza e privacy includono la natura del software sviluppato, le minacce note alla sicurezza, le lezioni apprese dagli incidenti di sicurezza, i requisiti legali e di settore e gli standard interni e le procedure di codifica.
Il momento ottimale per definire i requisiti di sicurezza e privacy è durante le fasi iniziali di progettazione e pianificazione di un prodotto o di una funzionalità. Ciò consente ai team di sviluppo di integrare funzionalità di sicurezza in una funzionalità core del prodotto. Ad esempio, una domanda che viene posta su ogni prodotto durante la fase di progettazione è se il prodotto gestirà informazioni sensibili, ad esempio i dati dei clienti. Microsoft SDL include requisiti di sicurezza e privacy per aiutare gli sviluppatori a implementare le procedure consigliate per la gestione dei dati sensibili e garantire che il software raccolga, elabori e archivi i dati sensibili in modo sicuro in conformità ai requisiti pertinenti. I requisiti SDL per la gestione dei dati sensibili includono la crittografia, la registrazione e la preparazione alla risposta agli eventi imprevisti per proteggere i dati sensibili e fornire ai team di risposta alla sicurezza Microsoft le funzionalità di controllo necessarie per analizzare e rispondere a potenziali incidenti di sicurezza.
Modelli di minaccia e diagrammi di flusso dei dati (DFD)
Una volta che la progettazione di un prodotto include requisiti di sicurezza e privacy chiaramente definiti, i team di sviluppo creano modelli di minaccia per visualizzare le minacce per la sicurezza e la privacy che con maggiore probabilità potrebbero interessare il prodotto. La modellazione delle minacce consente di identificare, classificare e valutare le potenziali minacce in base al rischio, in modo che gli sviluppatori possano proporre e implementare misure di mitigazione appropriate. SDL richiede ai team di sviluppo di Microsoft di mantenere aggiornati i modelli di minaccia e i diagrammi dei flussi di dati (DDF) per tutti i principali componenti e funzionalità del servizio.
La modellazione delle minacce inizia con la definizione dei componenti di un prodotto o di una funzionalità e con il diagramma delle relazioni tra loro per scenari funzionali chiave, ad esempio l'autenticazione o la gestione dei dati sensibili. I diagrammi di modellazione delle minacce includono flussi di dati, funzioni e processi pertinenti per facilitare la visualizzazione delle minacce per il servizio. Come parte del processo di modellazione delle minacce, i team del servizio creano e gestiscono DDF che documentano tutti i flussi di dati, le porte e i protocolli usati da un componente o una funzionalità del servizio.
I diagrammi completati vengono usati per identificare le minacce al sistema e classificare in ordine di priorità le minacce per la mitigazione. I team di sviluppo suggeriscono e implementano mitigazioni per i rischi esposti dai modelli di minaccia. Nuove mitigazioni vengono aggiunte ai requisiti di sicurezza del prodotto, convalidate nel codice durante la revisione manuale del codice e i test automatizzati e vengono esaminate come parte del processo di approvazione prima del rilascio.
Poiché lo sviluppo di software moderno con Agile enfatizza la rapida distribuzione di funzionalità ai clienti, la modellazione delle minacce è un processo continuativo. Per garantire la coerenza tra i team di sviluppo e mantenere aggiornati i modelli di minaccia, Microsoft richiede agli sviluppatori di usare il Threat Modeling Tool di Microsoft per tutti i modelli di minaccia. Il Threat Modeling Tool consente a qualsiasi sviluppatore o progettista software di Microsoft di:
- Comunicare la progettazione della sicurezza dei sistemi.
- Analizzare le progettazioni di sicurezza per individuare potenziali problemi di sicurezza usando una metodologia collaudata.
- Suggerire e gestire le mitigazioni per i problemi di sicurezza.
Durante la verifica della sicurezza prima del rilascio, tutti i modelli di minaccia vengono esaminati per verificarne l'accuratezza e la completezza, incluse le mitigazioni per rischi inaccettabili. Queste revisioni garantiscono la responsabilità e incoraggiano la progettazione orientata alla sicurezza.
Revisione del codice manuale
I team di sviluppo usano Azure DevOps Git per il controllo della versione in tutti i nuovi repository di codice. Per verificare che tutto il codice sviluppato in Microsoft sia conforme ai requisiti di progettazione e SDL, SDL richiede una revisione manuale del codice da parte di un revisore separato prima che le modifiche al codice possano essere archiviate in un ramo di rilascio. I revisori del codice verificano la presenza di errori di codifica e verificano che le modifiche al codice soddisfino i requisiti di progettazione e SDL, superino i test funzionali e di sicurezza e abbiano prestazioni affidabili. Esaminano anche la documentazione, le configurazioni e le dipendenze associate per garantire che le modifiche al codice siano documentate in modo appropriato e non provochino effetti collaterali imprevisti.
Se un revisore rileva problemi durante la revisione del codice, può chiedere al mittente di inviare di nuovo il codice con modifiche suggerite e test aggiuntivi. I revisori del codice possono anche decidere di bloccare completamente l'archiviazione per il codice che non soddisfa i requisiti. Tutte le modifiche al codice inviato per il rilascio devono essere chiaramente dimostrate a un singolo sviluppatore ed esaminate da un revisore separato per garantire la responsabilità. Inoltre, tutte le modifiche al codice di rilascio devono essere registrate e conservate per almeno 18 mesi per fornire un record controllabile di tutte le modifiche al codice, insieme all'autore, alla motivazione aziendale, ai risultati dei test e al revisore che ha approvato la modifica.