Controles de DevSecOps

  • Artigo

Este artigo descreve como aplicar controles de segurança para oferecer suporte às práticas de segurança SDL contínua. Esses controles de segurança são parte integrante de uma estratégia de DevSecOps que abrange pessoas, processos e tecnologia. Esta documentação descreve cada controle e mostra como aplicar esses controles a três perfis de segurança. Esses perfis atendem aos requisitos de segurança típicos para cenários de negócios comuns na maioria das organizações:

Diagrama de controles de segurança versus tempo e impacto.

Perfis de controle de segurança

Há três camadas de perfis de controle referenciados neste artigo.

Mínimo temporário – Perfil de segurança abreviado para um estado de exceção temporário para oferecer suporte à prototipagem rápida de cargas de trabalho de baixo risco. Esse perfil deve ser usado apenas para exceções temporárias que precisam ser liberadas em um cronograma acelerado para atender às necessidades críticas dos negócios. Os itens que usam esse perfil devem ser rapidamente trazidos para o perfil padrão.

Padrão - Abordagem equilibrada para a maioria das cargas de trabalho, na maioria das vezes.

Alta segurança – Segurança rigorosa para cargas de trabalho com um potencial alto impacto nos negócios e na segurança humana.

Controles de segurança DevSecOps

Esta seção fornece uma referência dos controles de segurança recomendados para cada tipo de carga de trabalho. Essa referência pode ser adotada como está ou pode ser adaptada aos seus processos existentes de desenvolvimento de software e segurança de software. A maioria das organizações não pode implementar todos esses controles imediatamente se ainda não estiver fazendo alguns deles. Adotar uma abordagem de melhoria contínua geralmente é a melhor abordagem: priorizar controles, implementar o primeiro controle, passar para o próximo controle, implementá-lo e assim por diante. A maioria das organizações deve priorizar os fundamentos críticos primeiro.

Para obter mais informações, consulte A jornada DevSecOps.

Este diagrama resume os controles de segurança e como aplicá-los a cada perfil de segurança de carga de trabalho.

As principais considerações de planejamento incluem:

  • Shift esquerdo mas verifique duas vezes - Esta referência é projetada para detectar e corrigir problemas o mais cedo possível para permitir que você os corrija quando for mais fácil e barato corrigir os problemas (às vezes chamado de shift left), mas também para assumir falhas e incluir a verificação dupla mais tarde no processo. Sempre verifique novamente todos os controles de segurança no processo de CI/CD, certifique-se de que problemas evitáveis não cheguem aos sistemas de produção. Esse conceito segue os princípios de "defesa em profundidade" e "à prova de falhas".
  • Inteligência Artificial (IA) – As duas principais implicações da inteligência artificial são:
    • Proteja todo o código , independentemente de ser escrito por IA humana ou generativa
    • Use ambos para segurança - Aplique controles clássicos e de IA conforme disponível para aumentar a visibilidade e o contexto de quaisquer problemas de segurança (como ferramentas de análise de código)

Controles de segurança

Os controles são agrupados nos estágios de desenvolvimento aos quais se aplicam e nos controles comuns (fundamentos críticos) que se aplicam em todos os estágios de desenvolvimento e perfis de controle:

Cada um desses itens é definido nas seguintes seções:

Estabelecer bases críticas

Esse controle suporta a Prática SDL Contínua 1 – Estabelecer padrões, métricas e governança de segurança, a Prática 2 – Exigir o uso de recursos, linguagens e estruturas de segurança comprovadas e a Prática 10 – Fornecer treinamento de segurança.

Padrão - Esses controles se aplicam a todos os estágios de desenvolvimento e perfis de controle.

Fornecendo treinamento de segurança

Esse controle se concentra em fornecer aos desenvolvedores e equipes de segurança treinamento para reconhecer e resolver problemas de segurança durante o ciclo de vida de desenvolvimento. Sem o treinamento de segurança, suas equipes podem perder os principais pontos fracos de segurança que levam ao comprometimento durante a vida útil dos aplicativos.

Como resultado, é imperativo que você implemente o treinamento de segurança em todas as funções (incluindo usuários, desenvolvedores, gerentes de linha de produto, testadores e muito mais). Cada função deve ter educação sobre os riscos de segurança e seu papel em manter os aplicativos seguros. Esse treinamento pode assumir a forma de: treinamento formal ou sob demanda, exercícios de simulação, modelagem de ameaças, mentoring/conselheiros, campeões de segurança, equipes de suporte de segurança de aplicativos, atividades roxas da equipe, podcasts, vídeos ou quaisquer outros métodos de aprendizado.

Em última análise, cada papel precisa entender:

  • Por que é importante abordar os riscos de segurança
  • O que eles precisam fazer pela segurança em seu papel
  • Como tornar a segurança parte de seu papel diário

As pessoas que entendem a perspectiva do invasor, seus objetivos e como isso aparece em incidentes de segurança do mundo real rapidamente se tornam aliados de segurança em vez de tentar evitar a segurança.

A segurança é um jogo sem fim, onde as ameaças, a tecnologia e os ativos de negócios a proteger estão sempre mudando e os agentes de ameaças nunca desistem. A abordagem de treinamento de segurança deve ser contínua e evoluir continuamente. O treinamento eficaz se alinha e reforça as políticas de segurança, as práticas de ciclo de vida de desenvolvimento de software (SDL), os padrões e os requisitos de segurança de software. O material de treinamento deve vir de insights derivados de dados e capacidades técnicas recém-disponíveis.

Embora a segurança seja um trabalho de todos, é importante lembrar que nem todo mundo precisa ser especialista em segurança nem buscar se tornar um testador de penetração proficiente. Garantir que todos entendam os conceitos básicos de segurança e como aplicá-los ao seu papel de criar segurança em software e serviços é essencial. Esse treinamento deve incluir o uso seguro de estações de trabalho, aplicativos, identidade e contas.

Em particular, os desenvolvedores e os engenheiros que constroem sistemas geralmente não são especialistas em segurança. O treinamento nos aspectos técnicos e conceituais da modelagem de ameaças é necessário para que eles se tornem efetivos para que possam construir sistemas seguros por design. Esse treinamento é vital para que o processo de modelagem de ameaças funcione em escala em organizações onde os desenvolvedores superam em muito o número de profissionais de segurança. A modelagem de ameaças deve ser pensada como uma habilidade de engenharia fundamental na qual todos os desenvolvedores e engenheiros devem ter pelo menos proficiência básica. Portanto, as equipes de desenvolvimento e engenharia devem ser treinadas para serem competentes na modelagem de ameaças como parte da integração e com atualizações periódicas.

Incluir segurança em post-mortems irrepreensíveis

A análise post-mortem sem culpa é um método extremamente importante para as equipes aprenderem com os erros de forma eficaz e eficiente, sem acionar a defensividade dos membros da equipe buscando alguém para culpar. Os aprendizados de segurança devem ser explicitamente incluídos no processo post-mortem irrepreensível para garantir que as equipes também estejam maximizando os aprendizados de segurança.

Estabeleça padrões de segurança, métricas e governança

As organizações devem estabelecer esses padrões de segurança, métricas e governança porque eles sustentam a capacidade de inovar. Ele permite um forte programa de segurança que não apenas protege os ativos da organização, mas também se alinha com seus objetivos de negócios. Os padrões de segurança são os requisitos de linha de base e as práticas recomendadas para manter os sistemas, os dados e os processos de uma organização seguros.

Esses padrões devem ser medidos e governados, incluindo o monitoramento da conformidade e a revisão e atualização regulares em relação a ameaças, ferramentas e outros fatores atuais. Esse processo deve abranger todo o ciclo de vida, desde a ideação inicial até o descomissionamento do aplicativo e de quaisquer ambientes de desenvolvimento de suporte.

As métricas são medidas usadas para ver a eficácia dos controles e processos de segurança. Uma métrica importante é o Tempo Médio de Correção (MTTR) para rastrear por quanto tempo um aplicativo permanece vulnerável. Essa medição nos permite investir estrategicamente na emissão de correções de segurança com mais rapidez.

Observação

Esse conceito difere do MTTR em operações de segurança focadas no tempo para remover o acesso do adversário aos ativos da organização.

A governança de segurança atua como uma mão orientadora para as equipes de segurança e geralmente é construída sobre estruturas e processos que as organizações usam para gerenciar e controlar sua segurança da informação. Isso inclui Políticas, Procedimentos, Controles e Gerenciamento de Riscos. As métricas ajudam a quantificar a exposição ao risco. Sem eles, a organização pode não entender completamente suas vulnerabilidades e impacto potencial.

Como os requisitos de segurança podem ser novos, você tem a oportunidade de adotar uma abordagem progressiva que aumenta gradualmente os padrões de codificação para o estado ideal. Essa abordagem dá às equipes tempo para aprender e automatizar o monitoramento e os controles.

Exigir o uso de recursos, linguagens e estruturas de segurança comprovadas

Defina e publique uma lista de ferramentas aprovadas e suas verificações de segurança associadas. Usar soluções de segurança bem estabelecidas e comprovadas é importante para evitar erros comuns, pois criar soluções seguras é muito desafiador. Tentar reinventar soluções de segurança quase sempre resulta em maior risco de segurança e perda de tempo e esforço.

Garanta que os desenvolvedores e engenheiros estejam aproveitando as novas funcionalidades e proteções de análise de segurança. Eles devem sempre usar o compilador, o vinculador, as bibliotecas e os sinalizadores apropriados do compilador e do vinculador para gerar executáveis seguros.

As organizações devem implementar um processo de revisão e aprovação para validar a segurança de quaisquer componentes integrados. Eles devem estabelecer uma política para usar apenas componentes aprovados em processos de compilação e implantação que são impostos e monitorados.

Segurança de identidade fundamental

Garantir que o uso e a integração da identidade sigam as práticas recomendadas de segurança bem estabelecidas. Os agentes de ameaças usam técnicas de ataque de identidade com frequência contra sistemas de produção e processos de desenvolvimento. Um ditado popular capta isso: "os atacantes não invadem, apenas fazem login".

A segurança de identidade assume duas formas de desenvolvimento:

  • Segurança de identidade para o processo de desenvolvimento - Certifique-se de que todos os participantes do processo de desenvolvimento usem métodos de autenticação fortes para seu trabalho diário e tenham apenas os privilégios necessários para executar suas tarefas de trabalho. Para obter mais informações, consulte a seção Controles de acesso de identidade/aplicativo.
  • Segurança de identidade para sistemas e aplicativos - Certifique-se de que os sistemas que eles estão projetando e criando sigam as práticas recomendadas para métodos de autenticação e autorização (e não estejam criando suas próprias imitações fracas de sistemas de identidade comprovados e mantidos).

Aplique a segurança de identidade para sistemas e aplicativos seguindo as orientações destes recursos:

Padrões criptográficos

Aplicar boas práticas criptográficas a todo o uso de criptografia. Siga todas as diretrizes descritas na Prática Contínua de SDL 4 – Definir e Usar Padrões Criptográficos.

Para obter mais informações, consulte Recomendações criptográficas do Microsoft SDL.

Protegendo seu ambiente de desenvolvimento

Esse controle suporta a Prática Contínua de SDL 6 – Protegendo seu ambiente de engenharia.

Esse controle se concentra em proteger seu ambiente de desenvolvimento usando estações de trabalho seguras e ambientes de desenvolvimento integrado (IDEs). Esse controle destaca o benefício de usar uma abordagem Zero Trust em seu ciclo de vida de desenvolvimento de software.

No cenário atual, os invasores expandem suas operações para atingir as máquinas de seus desenvolvedores e adulterar os processos de compilação. Um exemplo crucial desse ataque foi o experimentado pela SolarWinds, onde o invasor inseriu uma DLL maliciosa antes dos estágios finais da compilação do software. Efetivamente, isso fez backdoor do aplicativo e resultou em um ataque direcionado que foi distribuído para milhares de clientes em todo o mundo por meio da cadeia de suprimentos. Para obter mais informações sobre o ataque SolarWinds, consulte o Blog da Microsoft Analisando o Solorigate, o arquivo DLL comprometido que iniciou um ataque cibernético sofisticado e como o Microsoft Defender ajuda a proteger os clientes.

É essencial fortalecer estações de trabalho, criar ambientes, identidades e outros sistemas de desenvolvimento para garantir a integridade dos aplicativos desenvolvidos. Se isso não for feito, os invasores comprometerão seu aplicativo por meio do sistema SCM (Gerenciamento de Código Fonte) ou da estação de trabalho do desenvolvedor.

Essa prática é uma base crítica do ciclo de vida de desenvolvimento e deve ser estabelecida em todos os perfis.

Ao longo dessa prática, você deve adotar uma abordagem de Confiança Zero. Em sua essência, o modelo Zero Trust exige que cada solicitação de acesso (usuário, serviço ou dispositivo) seja verificada como se tivesse se originado de uma rede não confiável, independentemente de onde a solicitação se origina ou qual recurso ela acessa. Baseie essa política de "sempre autenticar e autorizar" em todos os pontos de dados disponíveis. Você deve limitar o acesso de usuários, especialmente usuários privilegiados, por meio de políticas Just-In-Time e Just-Enough-Access (JIT/JEA) e segmentar o acesso para minimizar os possíveis danos se houver uma violação.

Fortalecer seu ambiente de desenvolvimento pode ser alcançado por meio de vários métodos, no entanto, um bom ponto de partida é considerar a estação de trabalho do desenvolvedor. Ao utilizar tecnologias como GitHub Codespaces ou Microsoft DevBox, você desloca o ambiente de desenvolvimento para aplicativos SaaS, que podem ser gerenciados por meio de configurações de segurança e rede ou por meio de diretivas organizacionais.

Para bloquear ainda mais as estações de trabalho do desenvolvedor, você pode emiti-las estações de trabalho de acesso privilegiado/estações de trabalho de acesso seguro (PAW/SAW). Essas estações de trabalho ajudam a reduzir vetores de ameaças e garantem um dispositivo de desenvolvedor padronizado e controlado.

Design seguro

Executar modelagem de ameaças (revisão do design de segurança)

Esse controle oferece suporte à Prática SDL Contínua 3 – Executar modelagem de ameaças.

Esse controle identifica pontos fracos de segurança no projeto que podem resultar em incidentes de segurança e danos aos negócios. Os pontos fracos de segurança no projeto podem ser difíceis de mitigar depois que o projeto é implementado, portanto, encontrar e corrigir esses pontos fracos no início do ciclo de vida é extremamente importante.

A modelagem de ameaças serve como o processo de revisão do design de segurança, que integra a segurança ao design de um sistema ou aplicativo.

A modelagem de ameaças identifica, avalia, prioriza e mitiga sistematicamente os riscos de segurança em um sistema de software. Essa abordagem estruturada para analisar o design e a arquitetura de um aplicativo de software identifica ameaças e vulnerabilidades potenciais no início do processo de desenvolvimento.

O objetivo final é entender o sistema e o que pode dar errado. A modelagem de ameaças ajuda a atingir esse objetivo aplicando uma compreensão profunda do próprio sistema e de como um invasor em potencial o vê.

Esse processo normalmente assume a forma de workshops de descoberta de ameaças, onde uma equipe de especialistas no sistema e especialistas em segurança trabalham juntos para descobrir e documentar riscos. Embora esse processo possa começar informalmente, ele deve evoluir rapidamente para um processo estruturado que discute cada aspecto do serviço que está sendo criado, como ele é usado e interfaces do sistema.

Os estágios da modelagem de ameaças são:

  1. Identificar casos de uso, cenários e ativos – Comece entendendo quais funções de negócios e casos de uso o sistema permite para ajudar a avaliar o impacto potencial nos negócios de qualquer comprometimento do sistema e informar as discussões a seguir.
  2. Criar uma visão geral da arquitetura – Crie um resumo visual do aplicativo (ou use um existente) para fornecer uma compreensão clara do sistema e como ele funciona. Essa visão geral deve incluir: um mapa de processos de negócios, componentes e subsistemas, limites de confiança, mecanismos de autenticação e autorização, interfaces externas e internas e fluxos de dados entre atores e componentes.
  3. Identificar as ameaças - Use uma metodologia comum para enumerar possíveis ameaças à segurança, como o modelo STRIDE ou a modelagem de ameaças OWASP.
  4. Identificar e rastrear mitigações - Monitore e rastreie falhas de projeto descobertas usando processos e ferramentas de desenvolvimento existentes para garantir que as correções sejam implementadas e documentadas. Esse processo deve incluir, priorizando quais mitigações fazer primeiro para que as equipes gastem seu tempo nos esforços mais importantes primeiro. Esse processo é orientado por riscos e talvez você não tenha recursos para mitigar totalmente todos os riscos no primeiro ciclo. Considere cuidadosamente quais mitigações, incluindo mitigações parciais, aumentam o custo para um invasor pelo menor custo e recursos defensivos. O objetivo da segurança é a falha do atacante, que pode assumir a forma de bloquear totalmente uma técnica de ataque, detectá-los para permitir uma resposta do defensor, retardá-los para dar tempo aos defensores para responder, limitar o escopo do dano e muito mais.

Um modelo de ameaça geralmente serve como um processo de educação para todos os envolvidos, além de fornecer um contexto importante para outros planejamentos, implementação e testes de segurança.

As aplicações que incluem o uso de componentes de Inteligência Artificial (IA) devem avaliar os tipos de risco específicos associados à IA, que são diferentes das aplicações clássicas.

Crie e analise modelos de ameaças: comunicando sobre o design de segurança de seus sistemas, analisando esses projetos para possíveis problemas de segurança usando uma metodologia comprovada e sugerindo e gerenciando mitigações para problemas de segurança.

Código seguro

Análise de código

Esse controle suporta a Prática SDL Contínua 7 – Executar Testes de Segurança.

Esse controle se concentra em aumentar a segurança do código à medida que os desenvolvedores o escrevem/inserem em um ambiente de desenvolvimento integrado (IDE) ou quando fazem check-in do código. Esse controle é a pedra angular das práticas de DevSecOps, pois aborda diretamente vulnerabilidades que os invasores exploram regularmente.

Sem esse controle, você pode estar perdendo vulnerabilidades que são codificadas diretamente em seu aplicativo por seus desenvolvedores. Seus desenvolvedores não estão sendo mal-intencionados, mas podem não ter a qualificação necessária para identificar por que o que eles codificaram é inseguro.

Esse controle é fundamental para obter os benefícios de produtividade e segurança de uma abordagem de deslocamento para a esquerda, integrando ferramentas diretamente no IDE. Esse processo permite a rápida descoberta e correção de vulnerabilidades na oportunidade mais rápida e econômica. Esse processo pode ser aplicado retroativamente a aplicativos já desenvolvidos, identificando fraquezas de segurança e corrigindo-as posteriormente (embora com maiores custos e dificuldades).

Esse processo geralmente assume a forma de plug-ins do IDE ou ferramentas de varredura dedicadas que verificam o código usando conjuntos de ferramentas SAST (Static Analysis Security Testing) e DAST (Dynamic Analysis Security Testing).

As ferramentas SAST verificam a base de código existente e têm acesso total ao código. As ferramentas SAST podem identificar os principais pontos fracos no próprio código. O DAST, por outro lado, é executado no aplicativo implantado. Como resultado, ele não tem acesso ao código e é executado para simular e identificar fraquezas de segurança em tempo de execução.

Observação

Os aplicativos de IA têm diferentes tipos de vulnerabilidades (como vieses e alucinações) do que os aplicativos clássicos e exigem ferramentas que se concentram neles.

O controle de qualidade é importante! Uma consideração fundamental para executar essas ferramentas é garantir que você as esteja ajustando para reduzir o ruído e o esforço desperdiçado de falsos positivos. O ajuste dessas ferramentas normalmente requer um profissional de segurança com experiência em desenvolvedores que compreenda os processos de desenvolvimento da sua organização. Os mesmos profissionais também podem fornecer orientação de triagem e experiência em detecções individuais para desenvolvedores. Eles podem ajudar a distinguir verdadeiros e falsos positivos, problemas reais versus alarmes falsos. Os processos para os desenvolvedores acessarem esses especialistas geralmente estão intimamente relacionados ao Fornecimento de Treinamento de Segurança, como por meio de programas campeões, equipes de suporte de segurança de aplicativos, etc.

Mínimo temporário – Certifique-se de habilitar os recursos de segurança internos do IDE e implemente um nível mínimo de varredura SAST em seu repositório para identificar vulnerabilidades em todo o aplicativo. Deve haver um processo documentado para corrigir problemas descobertos em um tempo razoável, embora o padrão de "barra de bugs" cujas falhas devem ser corrigidas seja limitado até que o aplicativo atinja os perfis de segurança balanceados ou altos padrão.

Padrão - Certifique-se de verificar completamente todos os componentes com todas as ferramentas SAST/DAST aplicáveis e identifique pontos fracos. Garanta a cobertura de segurança total sobre o código do aplicativo. Verifique se você está seguindo o processo documentado para correção e se tem um padrão de "barra de bugs" que corresponda à tolerância ao risco da sua organização.

Alta segurança – Garanta que todos os aplicativos aplicáveis apliquem um processo detalhado e documentado que aborde todas as vulnerabilidades de segurança. Aplique correções antes de qualquer atividade de compilação ou lançamento. Verifique se você está seguindo o processo documentado de correção e se tem uma "barra de bugs" altamente restritiva que corresponda à tolerância ao risco da sua organização para cargas de trabalho críticas de negócios de alta segurança.

Existem muitas ferramentas disponíveis para análise estática. Consulte a lista em Microsoft Security Development Lifecycle para encontrar mais informações.

Proteger o pipeline de CI/CD

Gestão da cadeia de suprimentos/dependência

Este controle suporta a Prática SDL Contínua 5 - Protegendo a Cadeia de Suprimentos de Software.

Esse controle se concentra em proteger sua cadeia de suprimentos de desenvolvimento usando ferramentas e estruturas de Análise de Composição de Software (SCA), como o Secure Supply Chain Consumption Framework (S2C2F). Esses processos ajudam a reduzir o risco de comprometimento por código que não seja da Microsoft.

No cenário atual, a maioria dos aplicativos depende de software de código aberto (OSS) com pouca supervisão ou controle dos consumidores desses componentes. Esse controle destaca as principais estratégias, técnicas e tecnologias para ingerir, consumir, usar e manter o OSS com segurança. Ele também enfatiza a proteção de dependências internas, garantindo um ciclo de vida completo de ponta a ponta, independentemente de quem codificou o software.

A falha em controlar sua cadeia de suprimentos de software expõe você a vulnerabilidades significativas introduzidas por códigos que você não controla. Um exemplo notório é a vulnerabilidade log4J/Log4Shell, que permitia a execução remota de código em qualquer sistema ou aplicativo usando este pacote. Tais vulnerabilidades podem surgir acidentalmente ou maliciosamente.

Proteger sua cadeia de suprimentos é uma parte essencial para garantir um ciclo de vida de desenvolvimento seguro e deve ser considerado em cada estado de perfil, embora cada estado deva seguir o mesmo processo padronizado de ingestão de dependências.

Mínimo temporário – Faça um inventário de todas as suas dependências para entender o impacto que uma vulnerabilidade OSS tem em seu aplicativo. Esse inventário pode ser obtido usando o Dependabot ou outras ferramentas de Análise de Composição de Software (SCA). Essas ferramentas também podem ajudá-lo a gerar uma lista de materiais de software (SBOM).

Padrão - Analise todas as vulnerabilidades do OSS e corrija-as automaticamente com solicitações pull automáticas. Esse controle também pode ser obtido usando Dependabot e o gráfico/revisão de dependência do GitHub.

Alta segurança – Bloqueie ativamente todos os pacotes inseguros com vulnerabilidades exploráveis sendo usadas no aplicativo.

Para saber mais sobre esse controle e medir sua maturidade de segurança OSS, consulte o OSS Supply Chain Framework e a documentação de práticas recomendadas do GitHub sobre como proteger seu ciclo de vida de desenvolvimento.

Revisão do código de segurança

Esse controle se concentra em ter um código de revisão de especialista em segurança para identificar possíveis falhas de segurança. Isso ajuda a encontrar problemas de segurança que são difíceis de automatizar as detecções.

Essa revisão pode ser realizada por: um colega da mesma equipe com experiência em segurança de aplicativos, um campeão de segurança dentro da organização, um especialista em segurança de aplicativos da equipe central de segurança de aplicativos ou uma parte externa.

Essa revisão sempre deve ser uma pessoa separada do desenvolvedor que escreveu o código. Essa revisão deve ser feita como uma atividade separada após a conclusão da análise automatizada de código.

Mínimo temporário – Este controle é recomendado para este perfil.

Padrão - Este controle é recomendado para este perfil.

Alta segurança – Esse controle é necessário para todos os aplicativos de alta segurança e geralmente envolve vários especialistas individuais.

Varredura de credenciais e segredos

Esse controle suporta a Prática SDL Contínua 7 – Executar Testes de Segurança.

Esse controle se concentra na redução do risco de chaves de autenticação e outros segredos expostos no código. Os agentes de ameaças têm experiência e automação para encontrar e explorar segredos incorporados no código.

A melhor abordagem é usar identidades gerenciadas e protocolos de autenticação modernos em vez de chaves e segredos, quando possível. Embora o uso de chaves e segredos de API tenha sido tradicionalmente uma prática de codificação e teste, o método preferido sempre deve ser a autenticação baseada em identidade para recursos devido ao aumento das habilidades de segurança e gerenciamento do ciclo de vida. A implementação desse controle assume a forma de usar identidades gerenciadas, como identidades gerenciadas para recursos do Azure.

Se o uso de segredos for necessário, você deverá protegê-los durante todo o seu ciclo de vida, incluindo sua criação, uso, rotação regular e revogação. Evite usar segredos diretamente no código e armazene-os apenas em um sistema de armazenamento seguro/secreto, como o Cofre de Chaves do Azure ou um HSM (Hardware Security Module), se necessário. Sob nenhuma circunstância chaves de texto simples e segredos devem ser armazenados em código, mesmo que temporariamente! Os atacantes encontrarão e explorarão esses segredos.

Importante

Repositórios internos de código-fonte não são seguros!

Os repositórios internos devem estar sujeitos aos mesmos requisitos que os repositórios voltados para o público, pois os agentes de ameaças frequentemente procuram segredos e chaves em repositórios depois de obter acesso a um ambiente por meio de phishing ou outros meios. Isso é necessário para uma abordagem Zero Trust que assume a violação e projeta controles de segurança de acordo.

Padrão - Uma boa higiene secreta é essencial e é exigida em todos os perfis.

Observação

Como esses segredos são encontrados por suas equipes ou por invasores, você deve garantir que a chave não possa ser usada para acessar recursos (varia de acordo com o tipo de recurso), além de modificar o mecanismo para um método de acesso mais seguro, como identidades gerenciadas.

Mais detalhes e recursos incluem:

Observação

É altamente recomendável usar chaves por carga de trabalho com soluções de armazenamento secreto, como o Cofre de Chaves do Azure.

Pipeline seguro

Este controle suporta a Prática SDL Contínua 5 - Protegendo a Cadeia de Suprimentos de Software.

Esse controle se concentra em proteger o pipeline de DevOps e todos os artefatos criados durante os processos de compilação do seu aplicativo.

Os pipelines são uma parte essencial da automação das principais atividades repetíveis dentro do ciclo de vida do DevSecOps. No CI/CD, sua equipe mescla o código do desenvolvedor em uma base de código central em um cronograma regular e executa automaticamente compilações padrão e processos de teste, que incluem conjuntos de ferramentas de segurança.

O uso de pipelines para executar scripts ou implantar código em ambientes de produção pode apresentar desafios de segurança exclusivos. Certifique-se de que seus pipelines de CI/CD não se tornem caminhos para executar código mal-intencionado, permitir que credenciais sejam roubadas ou dar aos invasores qualquer área de superfície para acesso. Você também deve garantir que apenas o código que sua equipe pretende liberar seja implantado. Esse processo inclui artefatos de seus pipelines de CI/CD, especialmente artefatos que são compartilhados entre diferentes tarefas que podem ser usadas como parte de um ataque.

A geração de lista de materiais de software (SBOM) deve ser automatizada no processo de compilação para criar esse artefato de proveniência de código criticamente importante sem exigir ações manuais do desenvolvedor.

A segurança do pipeline pode ser garantida garantindo um bom controle de acesso aos recursos usados no pipeline e validando/atualizando dependências/scripts principais regularmente. É importante observar que os scripts usados em pipelines de CI/CD também são código e devem ser tratados da mesma forma que você trata outros códigos em seu projeto.

Observação

A segurança do pipeline depende da segurança da infraestrutura subjacente e das contas/identidades usadas para o processo. Para obter mais informações, consulte a proteção do ambiente de desenvolvimento e os controles de operações seguras (Identidade de identidade/controles de acesso de aplicativo, controles de host/contêiner, controles de acesso à rede)

Padrão - Esse controle deve ser avaliado em um nível de acesso a cada recurso no projeto, é um controle necessário em todos os níveis de perfil do DevSecOps.

Para saber mais sobre segurança de pipeline, consulte Protegendo pipelines do Azure.

Operações seguras

Teste de penetração no local ao vivo

Esse controle suporta a Prática SDL Contínua 7 – Executar Testes de Segurança.

Faça com que testadores profissionais de penetração de aplicativos tentem comprometer uma instância em tempo real da carga de trabalho completa. Esse teste valida se os controles de segurança da carga de trabalho são eficazes e consistentes. O teste de penetração ajuda a encontrar e destacar o caminho de menor resistência que um invasor pode usar para explorar seu aplicativo e comprometer os negócios. Os testes de penetração podem ser incrivelmente valiosos quando feitos no momento certo. Use-os depois de mitigar as vulnerabilidades baratas e fáceis de explorar encontradas em verificações anteriores.

Recomendamos que você faça esse teste em todos os níveis dos perfis de segurança do DevSecOps.

Mínimo temporário – Recomendamos que você faça um teste de penetração em todas as aplicações. Devido a restrições de tempo, talvez você só consiga identificar métodos mais fáceis no aplicativo que um invasor pode explorar. Planeje trazer isso rapidamente para o nível padrão no mínimo.

Padrão - Em um perfil padrão, recomendamos que você faça um teste de penetração. Nesse caso, você pode descobrir vulnerabilidades mais complexas devido ao cuidado extra que é tomado no início do processo de desenvolvimento.

Alta segurança – Para aplicativos de linha de negócios e cargas de trabalho críticas, é um requisito concluir um teste de penetração. Qualquer vulnerabilidade nesses aplicativos deve ser tratada com atenção e cuidado redobrados.

Integre as descobertas e o feedback dessas atividades para melhorar seus processos e ferramentas de segurança.

Controles de acesso de identidade/aplicativo

Esse controle suporta a Prática SDL Contínua 8 – Garanta a segurança da plataforma operacional e a Prática 6 – Protegendo seu ambiente de engenharia.

Garantir que as práticas recomendadas de segurança para gerenciamento de identidade e acesso, incluindo a proteção de acesso privilegiado, sejam seguidas para todos os elementos técnicos do ambiente de desenvolvimento, pipeline de CI/CD, carga de trabalho operacional e outros sistemas de desenvolvimento. Os agentes de ameaças têm métodos sofisticados e automação para ataques de identidade que usam com frequência contra sistemas de produção e processos de desenvolvimento. O gerenciamento de identidade e acesso é um pilar fundamental do modelo Zero Trust que a Microsoft recomenda.

Garanta que as práticas recomendadas de segurança sejam seguidas para todos os sistemas de desenvolvimento e a infraestrutura que os hospeda (VMs, contêineres, dispositivos de rede e muito mais).

Mínimo temporário – Garanta que todos usem a autenticação multifator e só possam acessar os sistemas necessários para executar suas tarefas diárias.

Padrão - Garantir que os componentes de infraestrutura que hospedam a carga de trabalho (como VMs, contêineres, rede e sistemas de identidade) atendam às práticas recomendadas de segurança para gerenciamento de identidade e acesso, incluindo a proteção de acesso privilegiado.

Alta segurança – Implemente uma estratégia completa de Zero Trust que incorpore MFA, Detecção e Resposta a Ameaças de Identidade e CIEM (Cloud Infrastructure Entitlement Management, gerenciamento de direitos de infraestrutura de nuvem). Executar um modelo de ameaça específico da carga de trabalho de sistemas de identidade e componentes que oferecem suporte a cada carga de trabalho de alta segurança.

As identidades gerenciadas são o método de autenticação mais seguro e preferido sempre que possível. O uso de tokens e segredos é menos seguro devido à necessidade de armazená-los e recuperá-los na camada de aplicação. Além disso, as identidades gerenciadas são automaticamente substituídas sem a necessidade de intervenção manual.

Mais detalhes e recursos incluem:

Controles de host/contêiner/ambiente

Esse controle suporta a Prática SDL Contínua 8 – Garanta a segurança da plataforma operacional e a Prática 6 – Protegendo seu ambiente de engenharia.

Certifique-se de que as práticas recomendadas de segurança sejam seguidas para todos os recursos de computação e ambientes de hospedagem para todos os elementos técnicos do ciclo de vida de desenvolvimento. Os agentes de ameaças têm métodos sofisticados e automação para ataques de infraestrutura e endpoint de usuário que eles usam com frequência contra sistemas de produção e processos de desenvolvimento. A segurança da infraestrutura é um pilar fundamental do modelo Zero Trust que a Microsoft recomenda.

Esse controle deve incluir todos os elementos do ciclo de vida operacional e de desenvolvimento, incluindo, mas não se limitando a:

  • Estações de trabalho e ambientes operacionais e de TI em geral
  • Estações de trabalho e ambientes de desenvolvimento dedicados
  • Infraestrutura de pipeline de CI/CD
  • Ambientes de hospedagem de carga de trabalho
  • Quaisquer outros sistemas de desenvolvimento.

Esse controle inclui qualquer recurso que possa executar qualquer código, incluindo, mas não limitado a:

  • Hosts e VMs de máquina virtual (VM)
  • Contêineres e infraestrutura de contêineres
  • Plataformas de hospedagem de aplicativos, scripts e códigos
  • Subscrições/contas e inscrições na nuvem
  • Estações de trabalho de desenvolvedor, usuário e administrador de TI

Certifique-se de aplicar as práticas recomendadas de segurança aos componentes de infraestrutura, incluindo atualizações de segurança (patches), configurações de segurança de linha de base e muito mais.

Mínimo temporário – Aplique configurações corporativas padrão para hosts e assinaturas.

Padrão - Certifique-se de que a infraestrutura atenda às práticas recomendadas de segurança descritas no Microsoft Cloud Security Benchmark (MCSB).

Alta segurança – aplique rigorosamente os padrões MCSB e execute o modelo de ameaça específico da carga de trabalho da infraestrutura que oferece suporte a cada carga de trabalho de alta segurança.

Mais detalhes e recursos incluem:

Controles de acesso à rede

Esse controle suporta a Prática SDL Contínua 8 – Garanta a segurança da plataforma operacional e a Prática 6 – Protegendo seu ambiente de engenharia.

Certifique-se de que as práticas recomendadas de segurança para gerenciamento de acesso à rede sejam seguidas para todos os elementos técnicos do ambiente de desenvolvimento, pipeline de CI/CD, ambiente de carga de trabalho operacional e outros sistemas de desenvolvimento. Os agentes de ameaças têm métodos sofisticados e automação para ataques de identidade que usam com frequência contra sistemas de produção e processos de desenvolvimento. A segurança de rede é um pilar fundamental do modelo Zero Trust que a Microsoft recomenda.

A segurança da rede deve incluir:

  • Proteção de rede externa – Isolamento de tráfego externo/internet não solicitado e mitigação de tipos de ataque conhecidos. Esse isolamento geralmente assume a forma de firewall da Internet, firewall de aplicativo Web (WAF) e soluções de segurança de API.
  • Proteção de rede interna – Isolamento de tráfego interno não solicitado (de outros locais de rede corporativa). Esse isolamento pode usar controles semelhantes como proteção de rede externa e pode ser granular para a carga de trabalho ou para componentes individuais específicos e endereços IP.
  • Mitigações de negação de serviço – Proteções contra DDoS (Distributed Denial of Service) e outros ataques de negação de serviço.
  • Security Service Edge (SSE) – Uso de microssegmentação do lado do cliente para fornecer acesso seguro diretamente aos recursos, incluindo a aplicação de políticas de Zero Trust.

Garanta que as práticas recomendadas de segurança sejam seguidas para todos os sistemas de desenvolvimento e a infraestrutura que os hospeda (VMs, contêineres, dispositivos de rede e muito mais).

Mínimo temporário – Aplique configurações corporativas padrão para carga de trabalho.

Padrão - Certifique-se de que todos os sistemas tenham proteção de rede externa, proteção contra DDoS e um mínimo de proteção de rede interna por carga de trabalho.

Alta segurança – todas as proteções padrão, além de alta granularidade de proteções de rede interna, encapsulamento forçado do tráfego de servidor de saída por meio de mecanismos de proteção de rede externos e um modelo de ameaça específico de carga de trabalho de infraestrutura de rede que oferece suporte a cada carga de trabalho de alta segurança.

Mais detalhes e recursos incluem:

Monitoramento, resposta e recuperação

Esse controle suporta a Prática Contínua de SDL 9 – Implementar Monitoramento e Resposta de Segurança.

Certifique-se de que as equipes de operações de segurança (SecOps/SOC) tenham visibilidade, detecção de ameaças e procedimentos de resposta para cargas de trabalho (APIs e aplicativos), bem como a infraestrutura que as hospeda. Garantir que os processos e as ferramentas entre equipes entre SecOps e Infraestrutura/Carga de Trabalho permitam uma recuperação rápida após um ataque.

Esse controle sustenta a segurança da carga de trabalho quando ela está em produção e em execução ativa em sua organização. Esse processo deve ser integrado ao recurso de operações de segurança existente que detecta e responde a incidentes de segurança.

O monitoramento de segurança para cargas de trabalho personalizadas combina soluções XDR (extended detection and response) para componentes comuns, analisando logs e outros dados de aplicativos para detectar e investigar possíveis ameaças à segurança. Os dados personalizados do aplicativo geralmente incluem: informações sobre solicitações do usuário, atividade do aplicativo, códigos de erro, tráfego de rede, outros detalhes relevantes do aplicativo, bancos de dados, pontos de extremidade de rede e outros componentes do sistema.

Esses dados são então aprimorados com insights de inteligência de ameaças em tempo real para identificar padrões de comportamento anômalo que podem indicar possíveis tentativas de infiltração na rede. Uma vez agregada, correlacionada e normalizada, a plataforma XDR e Security Information and Event Management (SIEM) oferece ações de correção.

Mínimo temporário – Implante recursos XDR em seu ambiente para monitorar o tráfego de seus dispositivos de usuário final.

Padrão - Implante detecções XDR e SIEM personalizadas que identificam comportamentos anômalos em relação ao ambiente geral. Esse perfil pode incluir detecções personalizadas para cargas de trabalho individuais.

Alta segurança – controles padrão e detecções personalizadas por carga de trabalho com base em insights da modelagem de ameaças da carga de trabalho. Combine esse perfil com IA para fornecer consciência contextual às recomendações de correção.

Próximas etapas

Adote esses controles de segurança e adapte-os aos requisitos de tolerância a riscos e produtividade da sua organização. Você deve usar uma abordagem de melhoria contínua onde você constrói continuamente em direção ao estado ideal.

Comece priorizando os controles e os níveis mínimos ideais de meta. Certifique-se de ter impacto positivo na segurança e alterações de baixo atrito primeiro. Priorize, implemente e integre o primeiro controle e, em seguida, repita o processo com o próximo controle.

Você deve priorizar os fundamentos críticos primeiro por causa de seu amplo impacto positivo e varredura de credenciais e segredos devido ao seu alto impacto e uso frequente de invasores.