Visão geral de desenvolvimento e operações de segurança

Como a Microsoft implementa práticas de desenvolvimento seguro?

O SDL (Security Development Lifecycle) da Microsoft é um processo de garantia de segurança focado no desenvolvimento e operação de software seguro. O SDL fornece requisitos de segurança detalhados e mensuráveis para desenvolvedores e engenheiros da Microsoft reduzirem o número e a gravidade das vulnerabilidades em nossos produtos e serviços. Todas as equipes de desenvolvimento de software da Microsoft devem seguir os requisitos do SDL e atualizamos continuamente o SDL para refletir o cenário de ameaças, as práticas recomendadas do setor e os padrões regulatórios para conformidade.

Como o SDL da Microsoft melhora a segurança do aplicativo?

O processo SDL na Microsoft pode ser pensado em termos de cinco fases de desenvolvimento: requisitos, design, implementação, verificação e versão. Ele começa definindo requisitos de software com a segurança em mente. Para cumprir essa meta, fazemos perguntas relevantes para a segurança sobre o que o aplicativo deve realizar. O aplicativo precisa coletar dados confidenciais? O aplicativo executará tarefas confidenciais ou importantes? O aplicativo precisa aceitar a entrada de fontes não confiáveis?

Depois que os requisitos de segurança relevantes forem identificados, projetamos nosso software para incorporar recursos de segurança que atendam a esses requisitos. Nossos desenvolvedores implementam requisitos de SDL e design no código, que verificamos por meio de revisão manual de código, ferramentas de segurança automatizadas e testes de penetração. Por fim, antes que o código possa ser lançado, novos recursos e alterações materiais passam pela revisão final de segurança e privacidade para garantir que todos os requisitos sejam atendidos.

Como a Microsoft testa o código-fonte para vulnerabilidades comuns?

Para dar suporte aos nossos desenvolvedores na implementação de requisitos de segurança durante o desenvolvimento de código e após o lançamento, a Microsoft fornece um pacote de ferramentas de desenvolvimento seguro para verificar automaticamente o código-fonte em caso de falhas e vulnerabilidades de segurança. A Microsoft define e publica uma lista de ferramentas aprovadas para nossos desenvolvedores usarem, como compiladores e ambientes de desenvolvimento, juntamente com as verificações de segurança internas executadas automaticamente em pipelines de compilação da Microsoft. Nossos desenvolvedores usam as versões mais recentes das ferramentas aprovadas para aproveitar os novos recursos de segurança.

Antes que o código possa ser verificado em um branch de versão, o SDL requer a revisão manual de código por um revistor separado. Os revisores de código verificam se há erros de codificação e se as alterações no código atendem aos requisitos de SDL e de design, passam nos testes funcionais e de segurança e têm um desempenho confiável. Eles também analisam a documentação, configurações e dependências associadas para garantir que as alterações no código sejam documentadas de forma adequada e não causem efeitos colaterais indesejados. Se um revisor encontrar problemas durante a revisão do código, ele pode pedir ao remetente para reenviar o código com as alterações sugeridas e testes adicionais. Os revisores de código também podem decidir bloquear totalmente o check-in de código que não atenda aos requisitos. Depois que o código for considerado satisfatório pelo revistor, o revistor fornece aprovação, o que é necessário para que o código possa prosseguir para a próxima fase de implantação.

Além de ferramentas de desenvolvimento seguras e revisão manual de código, a Microsoft impõe requisitos de SDL usando ferramentas de segurança automatizadas. Muitas dessas ferramentas são internas no pipeline de confirmação e analisam automaticamente o código para falhas de segurança à medida que são verificadas e conforme novas compilações são compiladas. Exemplos incluem a análise de código estático para falhas comuns de segurança e scanners de credenciais que analisam o código para segredos incorporados. Os problemas descobertos por ferramentas de segurança automatizadas devem ser corrigidos antes que novas versões possam passar na revisão de segurança e serem aprovadas para lançamento.

Como a Microsoft gerencia software de código aberto?

A Microsoft adotou uma estratégia de alto nível para gerenciar a segurança de código aberto, que usa ferramentas e fluxos de trabalho projetados para:

  • Entender quais componentes de software livre estão sendo usados em nossos produtos e serviços.
  • Acompanhar onde e como esses componentes são usados.
  • Determinar se esses componentes têm vulnerabilidades.
  • Responder corretamente quando forem descobertas vulnerabilidades que afetam esses componentes.

As equipes de engenharia da Microsoft mantêm a responsabilidade pela segurança de todos os softwares livres incluídos em um produto ou serviço. Para atingir essa segurança em escala, a Microsoft criou recursos essenciais em sistemas de engenharia por meio da CG (Governança de Componentes), que automatiza a detecção de código aberto, fluxos de trabalho de requisitos legais e alertas para componentes vulneráveis. As ferramentas CG automatizadas digitalizem builds na Microsoft para componentes de código aberto e vulnerabilidades de segurança associadas ou obrigações legais. Os componentes descobertos são registrados e enviados para as equipes apropriadas para revisões de negócios e segurança. Essas revisões foram projetadas para avaliar quaisquer obrigações legais ou vulnerabilidades de segurança associadas a componentes de software livre e resolvê-las antes de aprovar componentes para implantação.

Os serviços online da Microsoft são regularmente auditados para conformidade com regulamentações e certificações externas. Consulte a tabela a seguir para validação de controles relacionados ao desenvolvimento e operação de segurança.

Azure e Dynamics 365

Auditorias externas Section Data do relatório mais recente
ISO 27001/27002

Instrução of Applicability
Certificação
A.12.1.2: Alterar controles de gerenciamento
A.14.2: Segurança nos processos de desenvolvimento e suporte
2 de dezembro de 2020
ISO 27017

Instrução of Applicability
Certificação
A.12.1.2: Alterar controles de gerenciamento
A.14.2: Segurança nos processos de desenvolvimento e suporte
2 de dezembro de 2020
SOC 1
SOC 2
SOC 3
SDL-1: metodologia SDL (Ciclo de Vida do Desenvolvimento de Segurança)
SDL-2: Requisitos de controle de segurança documentados em versões
SDL-4: Segregação de ambientes de teste e produção
SDL-6: Verificações de malware em builds de código-fonte
SDL7: revisão SDL semesanuais
31 de março de 2021

Office 365

Auditorias externas Section Data do relatório mais recente
FedRAMP SA-3: Ciclo de Vida do Desenvolvimento do Sistema 24 de setembro de 2020
ISO 27001/27002/27017

Instrução of Applicability
Certificação
A.12.1.2: Alterar controles de gerenciamento
A.14.2: Segurança nos processos de desenvolvimento e suporte
Abril de 20, 2021
SOC 1
SOC 2
CA-03: Gerenciamento de riscos
CA-18: Gerenciamento de alterações
CA-19: Alterar monitoramento
CA-21: Alterar teste
CA-38: Configurações de linha de base
CA-46: Revisão de segurança
24 de dezembro de 2020

Recursos