Panoramica dello sviluppo e delle operazioni di sicurezza

In che modo Microsoft implementa procedure di sviluppo sicure?

Microsoft Security Development Lifecycle (SDL) è un processo di garanzia di sicurezza incentrato sullo sviluppo e sul funzionamento di un software sicuro. SDL offre requisiti di sicurezza dettagliati e misurabili affinché sviluppatori e ingegneri di Microsoft possano ridurre il numero e la gravità delle vulnerabilità nei nostri prodotti e servizi. Tutti i team di sviluppo software Microsoft devono seguire i requisiti SDL e microsoft aggiorna continuamente SDL in modo da riflettere il panorama delle minacce, le procedure consigliate del settore e gli standard normativi per la conformità.

In che modo SDL di Microsoft migliora la sicurezza delle applicazioni?

Il processo SDL di Microsoft può essere considerato in cinque fasi di sviluppo: requisiti, progettazione, implementazione, verifica e rilascio. Inizia dalla definizione dei requisiti software tenendo conto della sicurezza. Per raggiungere questo obiettivo, vengono poste domande rilevanti per la sicurezza su ciò che l'applicazione deve eseguire. L'applicazione deve raccogliere dati sensibili? L'applicazione eseguirà attività importanti o sensibili? L'applicazione deve accettare l'input di origini non attendibili?

Una volta identificati i requisiti di sicurezza pertinenti, progettiamo il nostro software affinché incorpori le funzionalità di sicurezza adatte a soddisfare questi requisiti. I nostri sviluppatori implementano l'SDL e i requisiti di progettazione nel codice, che poi noi verifichiamo tramite analisi manuale del codice, strumenti di sicurezza automatici e test di penetrazione. Infine, prima che il codice possa essere rilasciato, le nuove funzionalità e le modifiche materiali vengono sottoposte alla revisione finale della sicurezza e della privacy per garantire che tutti i requisiti siano soddisfatti.

In che modo Microsoft testa il codice sorgente per individuare vulnerabilità comuni?

Per supportare gli sviluppatori nell'implementazione dei requisiti di sicurezza durante lo sviluppo del codice e dopo il rilascio, Microsoft offre una suite di strumenti di sviluppo sicuri per controllare automaticamente il codice sorgente e rilevare eventuali difetti e vulnerabilità della sicurezza. Microsoft definisce e pubblica un elenco di strumenti approvati da usare per gli sviluppatori, ad esempio compilatori e ambienti di sviluppo, insieme ai controlli di sicurezza predefiniti eseguiti automaticamente all'interno delle pipeline di compilazione Microsoft. I nostri sviluppatori usano le versioni più recenti degli strumenti approvati per sfruttare le nuove funzionalità di sicurezza.

Prima che il codice possa essere archiviato in un ramo di rilascio, SDL richiede la revisione manuale del codice da parte di un revisore separato. 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. Dopo che il codice è stato considerato soddisfacente dal revisore, il revisore fornisce l'approvazione, necessaria prima che il codice possa procedere alla fase di distribuzione successiva.

Oltre a proteggere gli strumenti di sviluppo e la revisione manuale del codice, Microsoft applica i requisiti SDL usando strumenti di sicurezza automatizzati. Molti di questi strumenti sono integrati nella pipeline di commit e analizzano automaticamente il codice per individuare eventuali difetti di sicurezza durante l'archiviazione e la compilazione di nuove compilazioni. Gli esempi includono l'analisi statica del codice per individuare errori di sicurezza comuni e scanner di credenziali che analizzano il codice per individuare i segreti incorporati. I problemi rilevati dagli strumenti di sicurezza automatizzati devono essere risolti prima che le nuove build possano superare la revisione della sicurezza e essere approvate per il rilascio.

In che modo Microsoft gestisce il software open source?

Microsoft ha adottato una strategia di alto livello per la gestione della sicurezza open source, che usa strumenti e flussi di lavoro progettati per:

• Conoscere i componenti open source usati nei prodotti e nei servizi Microsoft.
• Tenere traccia della posizione e del modo in cui vengono usati tali componenti.
• Determinare se tali componenti presentano vulnerabilità.
• Rispondere correttamente quando vengono individuate vulnerabilità che interessano tali componenti.

I team di progettazione Microsoft sono responsabili della sicurezza di tutto il software open source incluso in un prodotto o servizio. Per ottenere questa sicurezza su larga scala, Microsoft ha integrato funzionalità essenziali nei sistemi di progettazione tramite La governance dei componenti (CG), che automatizza il rilevamento open source, i flussi di lavoro dei requisiti legali e gli avvisi per i componenti vulnerabili. Gli strumenti CG automatizzati analizzano le build in Microsoft per individuare i componenti open source e le vulnerabilità di sicurezza associate o gli obblighi legali. I componenti individuati vengono registrati e inviati ai team appropriati per le verifiche aziendali e di sicurezza. Queste verifiche sono progettate per valutare eventuali obblighi legali o vulnerabilità di sicurezza associati ai componenti open source e risolverli prima di approvare la distribuzione dei componenti.

Normative esterne correlate & certificazioni

I Servizi online Microsoft vengono controllati regolarmente per verificare la conformità alle normative e alle certificazioni esterne. Per la convalida dei controlli correlati allo sviluppo e all'operazione di sicurezza, vedere la tabella seguente.

Azure e Dynamics 365

Controlli esterni	Sezione	Data report più recente
ISO 27001/27002 Dichiarazione di applicabilità Certificato	A.12.1.2: Controlli di gestione delle modifiche A.14.2: Sicurezza nei processi di sviluppo e supporto	6 novembre 2023
ISO 27017 Dichiarazione di applicabilità Certificato	A.12.1.2: Controlli di gestione delle modifiche A.14.2: Sicurezza nei processi di sviluppo e supporto	6 novembre 2023
SOC 1 SOC 2 SOC 3	SDL-1: metodologia del ciclo di vita dello sviluppo della sicurezza (SDL) SDL-2: requisiti di controllo di sicurezza documentati nelle versioni SDL-4: Separazione degli ambienti di test e produzione SDL-6: analisi malware nelle compilazioni di codice sorgente SDL7: revisione semestrale di SDL	17 novembre 2023

Microsoft 365

Controlli esterni	Sezione	Data report più recente
FedRAMP (Office 365)	SA-3: Ciclo di vita dello sviluppo del sistema	31 luglio 2023
ISO 27001/27002/27017 Dichiarazione di applicabilità Certificazione (27001/27002) Certificazione (27017)	A.12.1.2: Controlli di gestione delle modifiche A.14.2: Sicurezza nei processi di sviluppo e supporto	Marzo 2024
SOC 1 SOC 2	CA-03: Gestione dei rischi CA-18: Gestione delle modifiche CA-19: Monitoraggio delle modifiche CA-21: Test delle modifiche CA-38: Configurazioni di base CA-46: Revisione della sicurezza	23 gennaio 2024

Risorse

• Video: Sviluppo e funzionamento della sicurezza di Microsoft 365
• Ciclo di vita dello sviluppo della sicurezza di Microsoft