Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La sicurezza e la privacy non dovrebbero mai essere un ripensamento quando si sviluppa software sicuro. È necessario un processo formale per garantire che il team di sviluppo consideri la sicurezza e la privacy 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. Questa conformità comporta un software più sicuro con un numero sempre minore di vulnerabilità gravi a un costo di sviluppo ridotto.
Microsoft SDL è costituito da sette componenti, tra cui cinque fasi principali e due attività di supporto per la 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 sicurezza e sulla privacy, nonché una formazione specifica relativa al loro ruolo. I nuovi dipendenti ricevono una formazione iniziale su assunzione e la formazione annuale per l'aggiornamento è necessaria per tutta la durata del loro impiego presso 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. Questi requisiti costituiscono la 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 gestiti dal prodotto, le minacce note, le procedure consigliate, le normative e i requisiti del settore e le lezioni apprese dagli eventi imprevisti precedenti. Una volta definito, il team di sviluppo documenta e tiene traccia chiaramente dei requisiti.
Lo sviluppo software è un processo continuo, il che significa che i requisiti di sicurezza e privacy associati cambiano durante tutto il ciclo di vita del prodotto in modo da riflettere i cambiamenti nelle funzionalità e nel panorama delle minacce.
Design
Dopo aver definito i requisiti di sicurezza, privacy e funzionalità, è possibile iniziare a progettare il software. Come parte del processo di progettazione, creare modelli di minaccia per identificare, classificare e valutare le potenziali minacce in base al rischio. Gestire e aggiornare i modelli di minaccia durante tutto il ciclo di vita di ogni prodotto quando si apportano 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. Creare diagrammi di Flusso di dati (DDFD) per rappresentare visivamente le interazioni dei flussi di dati chiave, i tipi di dati, le porte e i protocolli usati. Usare i DDF per identificare e assegnare priorità alle minacce per la mitigazione aggiunte ai requisiti di sicurezza del prodotto.
I team di servizio usano le Threat Modeling Tool di Microsoft per creare modelli di minaccia, che consentono 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 di rilasciare qualsiasi prodotto, esaminare tutti i modelli di minaccia per verificarne 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 di rilasciare codice scritto, è necessario completare diversi controlli e approvazioni per verificare che il codice sia conforme a SDL, soddisfi i requisiti di progettazione ed è privo di errori di codifica. Una revisione manuale viene eseguita da un revisore che non è il tecnico che ha sviluppato il codice. La separazione dei compiti è un controllo importante in questo passaggio per ridurre al minimo il rischio di scrittura e rilascio del codice che causa danni accidentali o dannosi.
È anche necessario eseguire vari controlli automatizzati incorporati nella pipeline per analizzare il codice durante l'archiviazione e la compilazione delle 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: identifica 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: usa 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 con il codice, inviano una notifica all'autore dell'invio. Il richiedente deve apportare le modifiche necessarie prima di inviare di nuovo il codice per la revisione.
Inoltre, sia i provider interni che esterni eseguono regolarmente test di penetrazione su Microsoft Servizi online. I test di penetrazione forniscono un altro mezzo per individuare i difetti di sicurezza che altri metodi non hanno rilevato. 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. Il processo di rilascio rilascia sistematicamente e gradualmente le compilazioni a gruppi più grandi e più grandi, definiti anelli, in quello che viene chiamato processo di distribuzione sicura (SDP). Gli anelli SDP possono in genere essere definiti come:
- Anello 0: il team di sviluppo responsabile del servizio o della funzionalità
- 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 è testata in modo appropriato per la stabilità negli anelli precedenti.
Risposta
Dopo il rilascio, tutti i servizi Microsoft vengono ampiamente registrati e monitorati. Un sistema di monitoraggio proprietario centralizzato quasi in tempo reale identifica potenziali eventi imprevisti di sicurezza. 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.