Microsoft Security Development Lifecycle (SDL)

Sicurezza e privacy non dovrebbero mai essere un ripensamento quando si sviluppa software sicuro, deve essere in atto un processo formale per garantire che siano considerati in tutti i punti del ciclo di vita del prodotto. Microsoft Security Development Lifecycle (SDL) incorpora requisiti di sicurezza completi, strumenti specifici della tecnologia e processi obbligatori nello sviluppo e nel funzionamento di tutti i prodotti software. Tutti i team di sviluppo di Microsoft devono rispettare i processi e i requisiti SDL, con conseguente aumento della sicurezza del software con un numero sempre minore di vulnerabilità a un costo di sviluppo ridotto.

Microsoft SDL è costituito da sette componenti, tra cui cinque fasi principali e due che supportano le attività di sicurezza. Le cinque fasi principali sono i requisiti, la progettazione, l'implementazione, la verifica e il rilascio. Ognuna di queste fasi contiene controlli e approvazioni obbligatori per garantire che tutti i requisiti di sicurezza e privacy e le procedure consigliate siano risolti correttamente. Le due attività di sicurezza di supporto, training e risposta, vengono condotte rispettivamente prima e dopo le fasi principali per garantire che siano implementate correttamente e il software rimane sicuro dopo la distribuzione.

Formazione

Tutti i dipendenti Microsoft sono tenuti a completare la formazione generale sulla consapevolezza della sicurezza e una formazione specifica appropriata per il proprio ruolo. La formazione iniziale di sensibilizzazione sulla sicurezza viene fornita ai nuovi dipendenti su assunzione e la formazione annuale per l'aggiornamento è necessaria per tutta la durata del loro impiego in Microsoft.

Gli sviluppatori e i tecnici devono anche partecipare alla formazione specifica del ruolo per mantenerli informati sulle nozioni di base sulla sicurezza e sulle tendenze recenti nello sviluppo sicuro. Anche tutti i dipendenti a tempo pieno, gli stazionari, il personale contingente, i subappaltatori e le terze parti sono incoraggiati e hanno la possibilità di richiedere una formazione avanzata sulla sicurezza e sulla privacy.

Requisiti

Ogni prodotto, servizio e funzionalità sviluppato da Microsoft inizia con requisiti di sicurezza e privacy chiaramente definiti; sono alla base di applicazioni sicure e ne informano la progettazione. I team di sviluppo definiscono questi requisiti in base a fattori quali il tipo di dati che il prodotto gestirà, le minacce note, le procedure consigliate, le normative e i requisiti del settore e le lezioni apprese dagli eventi imprevisti precedenti. Una volta definiti, i requisiti sono chiaramente definiti, documentati e monitorati.

Lo sviluppo software è un processo continuo, il che significa che i requisiti di sicurezza e privacy associati cambiano per tutto il ciclo di vita del prodotto in modo da riflettere i cambiamenti nelle funzionalità e nel panorama delle minacce.

Struttura

Dopo aver definito i requisiti di sicurezza, privacy e funzionalità, può iniziare la progettazione del software. Come parte del processo di progettazione, vengono creati modelli di minaccia per identificare, classificare e valutare le potenziali minacce in base al rischio. I modelli di minaccia devono essere mantenuti e aggiornati per tutto il ciclo di vita di ogni prodotto man mano che vengono apportate modifiche al software.

Il processo di modellazione delle minacce inizia definendo i diversi componenti di un prodotto e il modo in cui interagiscono tra loro in scenari funzionali chiave, ad esempio l'autenticazione. Flusso di dati diagrammi (DDFD) vengono creati per rappresentare visivamente le interazioni dei flussi di dati chiave, i tipi di dati, le porte e i protocolli usati. I DDF vengono usati per identificare e assegnare priorità alle minacce per la mitigazione aggiunte ai requisiti di sicurezza del prodotto.

Gli sviluppatori devono usare i Threat Modeling Tool Microsoft per tutti i modelli di minaccia, che consente al team 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 la mitigazione per i problemi di sicurezza

Prima del rilascio di qualsiasi prodotto, tutti i modelli di minaccia vengono esaminati per verificare l'accuratezza e la completezza, inclusa la mitigazione per rischi inaccettabili.

Implementazione

L'implementazione inizia con gli sviluppatori che scrivono codice in base al piano creato nelle due fasi precedenti. Microsoft offre agli sviluppatori una suite di strumenti di sviluppo sicuri per implementare in modo efficace tutti i requisiti di sicurezza, privacy e funzione del software che progettano. Questi strumenti includono compilatori, ambienti di sviluppo sicuri e controlli di sicurezza predefiniti.

Verifica

Prima che qualsiasi codice scritto possa essere rilasciato, sono necessari diversi controlli e approvazioni per verificare che il codice sia conforme a SDL, soddisfi i requisiti di progettazione ed è privo di errori di codifica. SDL richiede che le revisioni manuali vengano eseguite da un revisore separato dal personale che ha sviluppato il codice. La separazione dei compiti è un controllo importante in questo passaggio per garantire che nessun codice possa essere scritto e rilasciato dalla stessa persona causando potenziali danni accidentali o dannosi.

Sono inoltre necessari diversi controlli automatizzati e vengono incorporati nella pipeline di commit per analizzare il codice durante l'archiviazione e quando vengono compilate le compilazioni. I controlli di sicurezza usati in Microsoft rientrano nelle categorie seguenti:

• Analisi del codice statico: analizza il codice sorgente per individuare potenziali difetti di sicurezza, inclusa la presenza di credenziali nel codice.
• Analisi binaria: valuta le vulnerabilità a livello di codice binario per verificare che il codice sia pronto per la produzione.
• Scanner di credenziali e segreti: identificare le possibili istanze di esposizione di credenziali e segreti nel codice sorgente e nei file di configurazione.
• Analisi della crittografia: convalida le procedure consigliate per la crittografia nell'esecuzione del codice sorgente e del codice.
• Test fuzz: usare dati non valido e imprevisto per esercitare API e parser per verificare la presenza di vulnerabilità e convalidare la gestione degli errori.
• Convalida della configurazione: analizza la configurazione dei sistemi di produzione in base agli standard di sicurezza e alle procedure consigliate.
• Governance dei componenti (CG): rilevamento e controllo di versione, vulnerabilità e obblighi legali del software open source.

Se il revisore manuale o gli strumenti automatizzati riscontrano problemi nel codice, il richiedente riceverà una notifica e dovrà apportare le modifiche necessarie prima di inviarlo nuovamente per la revisione.

Inoltre, i test di penetrazione vengono condotti regolarmente su Microsoft Servizi online da provider interni ed esterni. I test di penetrazione forniscono un altro mezzo per individuare i difetti di sicurezza non rilevati da altri metodi. Per altre informazioni sui test di penetrazione in Microsoft, vedere Simulazione degli attacchi in Microsoft 365.

Rilascio

Dopo aver superato tutti i test e le verifiche di sicurezza necessari, le compilazioni non vengono rilasciate immediatamente a tutti i clienti. Le compilazioni vengono rilasciate sistematicamente e gradualmente a gruppi più grandi, detti anelli, in quello che viene chiamato processo di distribuzione sicura (SDP). Gli anelli SDP sono definiti come segue:

• Anello 0: Il team di sviluppo responsabile del servizio
• Anello 1: Tutti i dipendenti Microsoft
• Anello 2: Utenti esterni a Microsoft che hanno configurato l'organizzazione o utenti specifici per il canale di rilascio di destinazione
• Anello 3: Versione standard mondiale in sottofase

Le build rimangono in ognuno di questi anelli per un numero appropriato di giorni con periodi di carico elevato, ad eccezione dell'anello 3 poiché la build è stata testata in modo appropriato per la stabilità negli anelli precedenti.

Risposta

Tutti i servizi Microsoft vengono ampiamente registrati e monitorati dopo il rilascio, identificando potenziali eventi imprevisti di sicurezza usando un sistema di monitoraggio proprietario centralizzato quasi in tempo reale. Per altre informazioni sul monitoraggio della sicurezza e sulla gestione degli eventi imprevisti di sicurezza in Microsoft, vedere Panoramica del monitoraggio della sicurezza e Gestione degli eventi imprevisti di sicurezza Microsoft.