Saiba mais sobre segurança e privacidade por design
O Microsoft SDL enfatiza a importância da segurança e privacidade desde o design. Os recursos de segurança e privacidade não devem ser complementos, mas sim componentes centrais de nossos produtos e serviços. Construímos segurança em nossos produtos definindo os requisitos de segurança no início do ciclo de vida do recurso, mantendo modelos de ameaças atualizados para todos os principais componentes e recursos de serviço e exigindo revisão manual do código para todo o código-fonte.
Requisitos de segurança e privacidade
Os requisitos de segurança e privacidade devem informar o design de todos os aplicativos e sistemas altamente seguros. Na Microsoft, cada produto, serviço e recurso que desenvolvemos começa com requisitos de segurança e privacidade claramente definidos. Como o desenvolvimento de software é um processo contínuo, atualizamos continuamente esses requisitos ao longo do ciclo de vida de um produto para refletir as mudanças na funcionalidade necessária e no cenário de ameaças. Os fatores que influenciam os requisitos de segurança e privacidade incluem a natureza do software que está sendo desenvolvido, ameaças de segurança conhecidas, lições aprendidas com incidentes de segurança, requisitos legais e do setor e padrões internos e práticas de codificação.
O momento ideal para definir os requisitos de segurança e privacidade é durante os estágios iniciais de design e planejamento de um produto ou recurso. Isso permite que as equipes de desenvolvimento integrem recursos de segurança à funcionalidade central de um produto. Por exemplo, uma pergunta que fazemos sobre cada produto durante a fase de design é se o produto irá lidar com informações confidenciais, como dados do cliente. O SDL da Microsoft inclui requisitos de segurança e privacidade para ajudar os desenvolvedores a implementar as melhores práticas para o manuseio de dados confidenciais e garantir que nosso software coleta, processa e armazena dados confidenciais com segurança em conformidade com os requisitos relevantes. Os requisitos de SDL para tratamento de dados confidenciais incluem criptografia, registro em log e preparação de resposta a incidentes para proteger dados confidenciais e fornecer às equipes de resposta de segurança da Microsoft os recursos de auditoria necessários para investigar e responder a possíveis incidentes de segurança.
Modelos de ameaças e diagramas de fluxo de dados (DFDs)
Uma vez que o design de um produto inclui requisitos de segurança e privacidade claramente definidos, as equipes de desenvolvimento criam modelos de ameaças para visualizar as ameaças de segurança e privacidade com maior probabilidade de afetar o produto. A modelagem de ameaças ajuda a identificar, categorizar e classificar as ameaças potenciais de acordo com o risco, para que os desenvolvedores possam propor e implementar as mitigações apropriadas. O SDL exige que as equipes de desenvolvimento da Microsoft mantenham modelos de ameaças atualizados e DFDs (diagramas de fluxo de dados) para todos os principais componentes e recursos de serviço.
A modelagem de ameaças começa com a definição de um produto ou componentes de recursos e diagramação de seus relacionamentos entre si para cenários funcionais importantes, como autenticação ou tratamento de dados confidenciais. Os diagramas de modelagem de ameaças incluem fluxos de dados, funções e processos relevantes para ajudar a visualizar as ameaças ao serviço. Como parte do processo de modelagem de ameaças, as equipes de serviço criam e mantêm DFDs que documentam todos os fluxos de dados, portas e protocolos usados por um componente ou recurso de serviço.
Os diagramas concluídos são usados para identificar ameaças ao sistema e priorizar as ameaças para mitigação. As equipes de desenvolvimento propõem e implementam mitigações para riscos expostos por seus modelos de ameaças. Novas atenuações são adicionadas aos requisitos de segurança do produto, validados no código durante a revisão manual do código e o teste automatizado, e revisados como parte do processo de aprovação antes do lançamento.
Como o desenvolvimento de software moderno usando o Agile enfatiza a entrega rápida de recursos aos clientes, a modelagem de ameaças é um processo contínuo. Para garantir a consistência entre as equipes de desenvolvimento e ajudar a manter os modelos de ameaças atualizados, a Microsoft exige que seus desenvolvedores usem a Ferramenta de Modelagem de Ameaças da Microsoft para todos os modelos de ameaças. A Ferramenta de Modelagem de Ameaças permite que qualquer desenvolvedor ou arquiteto de software na Microsoft:
- Comunique-se sobre o projeto de segurança de seus sistemas.
- Analise projetos de segurança para possíveis problemas de segurança usando uma metodologia comprovada.
- Sugira e gerencie atenuações para problemas de segurança.
Durante a análise de segurança antes do lançamento, todos os modelos de ameaça são analisados quanto à precisão e integridade, incluindo atenuações para riscos inaceitáveis. Essas análises mantêm a responsabilidade e incentivam o design orientado para a segurança.
Análise de código manual
Nossas equipes de desenvolvimento usam o Azure DevOps Git para controle de versão em todos os novos repositórios de código. Para verificar se todo o código desenvolvido na Microsoft está em conformidade com o SDL e os requisitos de design, o SDL requer a análise manual do código por um revisor separado antes que as alterações do código possam ser verificadas em um branch de lançamento. 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. Todas as alterações no código submetido para liberação devem ser claramente atribuíveis a um único desenvolvedor e revisadas por um revisor separado para manter a responsabilidade. Além disso, todas as mudanças no código de liberação devem ser registradas e retidas por pelo menos 18 meses para fornecer um registro auditável de todas as alterações no código, junto com seu autor, justificativa comercial, resultados de teste e o revisor que aprovou a alteração.