Controles de DevSecOps

  • Artigo

Este artigo descreve como aplicar controles de segurança para dar suporte às práticas de segurança do SDL contínuo. 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 aplicá-los a três perfis de segurança. Esses perfis atendem aos requisitos de segurança típicos de 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 níveis de perfis de controle mencionados neste artigo.

Mínimo temporário – perfil de segurança abreviado para um estado de exceção temporário para dar 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 atualizados rapidamente 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 alto impacto potencial nos negócios e na segurança humana.

Controles de segurança do DevSecOps

Esta seção fornece uma referência de controles de segurança recomendados para cada tipo de carga de trabalho. Essa referência pode ser adotada do jeito que está ou pode ser adaptada aos seus processos existentes de desenvolvimento 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, implementar e assim por diante. A maioria das organizações deve priorizar primeiro as bases essenciais.

Para obter mais informações, confira 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 foi criada para detectar e corrigir problemas o mais cedo possível, para que você possa corrigi-los quando for mais fácil e barato (às vezes chamado de mudança de direção), mas também para presumir falhas e incluir uma verificação dupla mais tarde no processo. Sempre verifique novamente todos os controles de segurança no processo de CI/CD, garanta que problemas que possam ser evitados não passem para os sistemas de produção. Este 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 ter sido escrito por humano ou IA generativa
    • Use ambos para segurança – aplique controles clássicos e de IA conforme disponíveis 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 (bases essenciais) que se aplicam a todos os estágios de desenvolvimento e perfis de controle:

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

Estabelecer bases essenciais

Esse controle dá suporte à Prática 1 do SDL Contínuo – estabelecer padrões, métricas e governança de segurança, Prática 2 – exigir o uso de recursos, linguagens e estruturas de segurança comprovados, e 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.

Fornecer treinamento de segurança

Esse controle se concentra em fornecer aos desenvolvedores e às equipes de segurança treinamento para reconhecer e resolver problemas de segurança durante o ciclo de vida do desenvolvimento. Sem treinamento de segurança, suas equipes podem deixar passar 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 produtos, testadores e muito mais). Cada função deve ser instruída sobre os riscos de segurança e seu papel em manter os aplicativos seguros. Este treinamento pode assumir a forma de: treinamento formal ou sob demanda, exercícios de simulação, modelagem de ameaças, orientação/consultores, defensores de segurança, equipes de suporte de segurança de aplicativos, atividades da equipe roxa, podcasts, vídeos ou quaisquer outros métodos de aprendizagem.

Em última análise, cada função precisa entender:

  • Por que é importante lidar com os riscos de segurança
  • O que eles precisam fazer para garantir a segurança em sua função
  • Como tornar a segurança parte de seu função diária

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 aliadas de segurança em vez de tentar evitar a segurança.

Segurança é um jogo sem fim, onde as ameaças, a tecnologia e os ativos de negócios a serem protegidos 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 do 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 recursos técnicos 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. É essencial garantir que todos entendam os fundamentos da segurança e como aplicá-los à sua função de integrar a segurança ao software e aos serviços. Esse treinamento deve incluir o uso seguro de estações de trabalho, aplicativos, identidade e contas.

Em particular, os desenvolvedores e os engenheiros que criam 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 eficazes para que possam criar sistemas seguros por definição. Esse treinamento é vital para que o processo de modelagem de ameaças funcione em escala em organizações onde os desenvolvedores superam em muito os profissionais de segurança. A modelagem de ameaças deve ser considerada uma habilidade fundamental de engenharia 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-mortem sem culpa

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 desencadear a defensiva dos membros da equipe, onde procuram alguém para culpar. Os aprendizados de segurança devem ser explicitamente incluídos no processo post-mortem sem culpa para garantir que as equipes também maximizem os aprendizados de segurança.

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

As organizações devem estabelecer esses padrões, métricas e governança de segurança porque eles sustentam a capacidade de inovar. Isso viabiliza um forte programa de segurança que não só 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 básicos e as práticas recomendadas para manter os sistemas, dados e 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 das ameaças atuais, ferramentas e outros fatores. Esse processo deve abranger todo o ciclo de vida, desde a concepção inicial até o descomissionamento do aplicativo e de quaisquer ambientes de desenvolvimento de suporte.

Métricas são as medidas usadas para ver a eficácia dos controles e processos de segurança. Uma métrica importante é o MTTR (tempo médio de correção) para monitorar por quanto tempo um aplicativo permanece vulnerável. Essa medida 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 a segurança de suas informações. Essas diretrizes incluem Políticas, Procedimentos, Controles e Gerenciamento de Riscos. As métricas ajudam a quantificar a exposição ao risco. Sem elas, 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 comprovados

Defina e publique uma lista de ferramentas aprovadas e suas verificações de segurança associadas. O uso de soluções de segurança bem estabelecidas e comprovadas é importante para evitar erros comuns, pois a criação de soluções seguras é muito desafiadora. A tentativa de reinventar as soluções de segurança quase sempre resulta em maior risco de segurança e desperdício de tempo e esforço.

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

As organizações devem implementar um processo de revisão e aprovação para validar a segurança de todos os componentes integrados. Elas 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

Certifique-se de 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 captura isso: "os invasores não invadem, eles 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 forte no 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 a identidades/aplicativos.
  • 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 nestes recursos:

Padrões criptográficos

Aplique práticas criptográficas sólidas a todo o uso de criptografia. Siga todas as diretrizes descritas na Prática 4 do SDL Contínuo – Definir e usar padrões criptográficos.

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

Proteger seu ambiente de desenvolvimento

Esse controle dá suporte à Prática 6 do SDL Contínuo – Proteger seu ambiente de engenharia.

Esse controle foca em proteger seu ambiente de desenvolvimento usando estações de trabalho seguras e IDEs (ambientes de desenvolvimento integrado). Esse controle destaca o benefício de usar uma abordagem Confiança Zero 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 importante desse ataque foi o sofrido pela SolarWinds, em que 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 Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect customers.

É essencial fortalecer as estações de trabalho, criar ambientes, identidades e outros sistemas de desenvolvimento para garantir a integridade dos aplicativos desenvolvidos. Não fazer isso abre um caminho para os invasores comprometerem seu aplicativo por meio do sistema de gerenciamento de código-fonte (SCM) ou da estação de trabalho do desenvolvedor.

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

Ao longo dessa prática, você deve adotar a abordagem Confiança Zero. Em essência, o modelo de Confiança Zero 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 vem a solicitação ou qual recurso ela acessa. Baseie essa política "sempre autenticar e autorizar" em todos os pontos de dados disponíveis. Você deve limitar o acesso dos usuários, especialmente usuários privilegiados, por meio de políticas JIT/JEA (Just-In-Time e Just-Enough-Access) e segmentar o acesso para minimizar os possíveis danos se houver uma violação.

É possível fortalecer seu ambiente de desenvolvimento por meio de vários métodos, porém um bom ponto de partida é considerar a estação de trabalho do desenvolvedor. Ao utilizar tecnologias como GitHub Codespaces ou Microsoft DevBox, você muda 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 políticas organizacionais.

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

Design seguro

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

Esse controle dá suporte à Prática 3 do SDL Contínuo – Executar a modelagem de ameaças.

Esse controle identifica pontos fracos de segurança no design que podem resultar em incidentes de segurança e danos aos negócios. Os pontos fracos de segurança no design podem ser difíceis de mitigar após a implementação do design. 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 possíveis ameaças e vulnerabilidades 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 um reconhecimento profundo 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 os riscos. Embora esse processo possa começar informalmente, ele deve evoluir rapidamente para um processo estruturado que discuta cada aspecto do serviço que está sendo criado, como ele é usado e as interfaces do sistema.

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

  • 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 comercial potencial de qualquer comprometimento do sistema e informar as discussões a seguir.
  • 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.
  • 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.
  • Identificar e rastrear mitigações – monitore e rastreie falhas de design descobertas usando processos e ferramentas de desenvolvimento existentes para garantir que as correções sejam implementadas e documentadas. Esse processo deve incluir a priorização de quais mitigações fazer primeiro para que as equipes dediquem tempo nos esforços mais importantes primeiro. Esse processo é baseado em riscos e você pode não ter recursos para mitigar totalmente todos os riscos no primeiro ciclo. Considere criteriosamente quais mitigações, incluindo mitigações parciais, aumentam o custo para um invasor com o menor custo defensivo e recursos. O objetivo da segurança é a falha do invasor, que pode assumir a forma de bloquear completamente uma técnica de ataque, detectá-la para permitir uma resposta, desacelerá-la para dar tempo à segurança de responder, limitar o escopo do dano e muito mais.

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

Aplicativos 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 dos aplicativos clássicos.

Crie e analise modelos de ameaças por meio de: comunicação sobre o design de segurança de seus sistemas, análise desses designs em busca de possíveis problemas de segurança usando uma metodologia comprovada e sugestão e gerenciamento de mitigações para problemas de segurança.

Código seguro

Análise de código

Esse controle dá suporte à Prática 7 do SDL Contínuo – 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 verificam o código. Esse controle é a base das práticas de DevSecOps, pois aborda diretamente as vulnerabilidades que os invasores exploram regularmente.

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

Esse controle é fundamental para obter os benefícios de produtividade e segurança de uma abordagem de mudança de direção, integrando ferramentas diretamente ao IDE. Esse processo permite a descoberta e correção rápidas de vulnerabilidades na primeira e mais econômica oportunidade. Esse processo pode ser aplicado retroativamente a aplicativos já desenvolvidos, identificando pontos fracos de segurança e corrigindo-os posteriormente (embora com maior custo e dificuldade).

Esse processo normalmente assume a forma de plug-ins IDE ou ferramentas de varredura dedicadas que examinam o código usando conjuntos de ferramentas de teste de segurança de análise estática (SAST) e teste de segurança de análise dinâmica (DAST).

As ferramentas SAST examinam a base de código existente e têm acesso total ao código. As ferramentas SAST podem identificar os principais pontos fracos do 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 pontos fracos de segurança no tempo de execução.

Observação

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

Controle de qualidade é importante! Uma consideração importante para executar essas ferramentas é garantir que você as esteja ajustando para reduzir o ruído e o esforço desperdiçado com falsos positivos. O ajuste dessas ferramentas normalmente requer um profissional de segurança com experiência de desenvolvedor que entenda os processos de desenvolvimento de 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 a fornecer treinamento de segurança, como por meio de programas de defensores, 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 implementar um nível mínimo de verificação 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" de quais falhas devem ser corrigidas seja limitado até que o aplicativo atinja os perfis de segurança balanceados padrão ou de alto nível.

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

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

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

Proteger um pipeline de CI/CD

Gerenciamento da cadeia de suprimentos/dependências

Esse controle dá suporte à Prática 5 do SDL Contínuo – Proteger a cadeia de suprimentos de software.

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

Não controlar sua cadeia de suprimentos de software expõe você a vulnerabilidades significativas introduzidas por código 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 esse pacote. Essas vulnerabilidades podem surgir acidental ou maliciosamente.

Proteger sua cadeia de suprimentos é uma parte essencial para garantir um ciclo de vida de desenvolvimento seguro e deve ser considerado em todos os estados 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 de 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 ajudar você 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 o Dependabot e o grafo/revisão de dependência do GitHub.

Alta segurança – bloqueie ativamente todos os pacotes não seguros com vulnerabilidades exploráveis sendo usadas no aplicativo.

Para saber mais sobre esse controle e medir a maturidade da segurança OSS, examine 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 especialista em segurança revisar o código para identificar possíveis falhas de segurança. Isso ajuda a encontrar problemas de segurança para os quais é difícil 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 defensor da 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 deve ser sempre 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 – esse controle é recomendado para esse perfil.

Padrão – esse controle é recomendado para esse perfil.

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

Verificação de credenciais e segredos

Esse controle dá suporte à Prática 7 do SDL Contínuo – 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 deve sempre ser a autenticação baseada em identidade para recursos devido ao aumento das habilidades de gerenciamento de segurança e ciclo de vida. A implementação desse controle assume a forma de uso de identidades gerenciadas, como identidades gerenciadas para recursos do Azure.

Se o uso de segredos for necessário, você deverá protegê-los durante todo o 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 de chave/segredo seguro, como o Azure Key Vault ou um HSM (Módulo de Segurança de Hardware), se necessário. Sob nenhuma circunstância as chaves e segredos em texto simples devem ser armazenados no código, mesmo que temporariamente! Os invasores encontram e exploram esses segredos.

Importante

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

Os repositórios internos devem estar sujeitos aos mesmos requisitos dos repositórios públicos, pois os agentes de ameaças frequentemente buscam segredos e chaves em repositórios após obterem acesso a um ambiente por meio de phishing ou outros meios. Isso é necessário para a abordagem Confiança Zero que pressupõe violação e projeta controles de segurança adequadamente.

Padrão – uma boa higiene de segredos é essencial e necessária em todos os perfis.

Observação

Como esses segredos são descobertos 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 de segredos, como o Azure Key Vault.

Pipeline seguro

Esse controle dá suporte à Prática 5 do SDL Contínuo – Proteger 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 aplicativo.

Os pipelines são uma parte essencial da automação das principais atividades que podem ser repetidas no ciclo de vida do DevSecOps. Na CI/CD, a equipe mescla o código do desenvolvedor em uma base de código central regularmente e executa automaticamente as compilações e os processos de teste padrão, que incluem conjuntos de ferramentas de segurança.

O uso de pipelines para executar scripts ou implantar código nos ambientes de produção pode apresentar desafios de segurança exclusivos. Certifique-se de que os pipelines de CI/CD não se tornem locais para executar códigos mal-intencionados, permitir que as credenciais sejam roubadas ou fornecer aos invasores qualquer área de superfície para acesso. Também convém garantir que apenas o código que a equipe pretende liberar seja implantado. Esse processo inclui artefatos de seus pipelines de CI/CD, especialmente artefatos compartilhados entre diferentes tarefas que podem ser usadas como parte de um ataque.

A geração da SBOM (lista de materiais de software) 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 ao assegurar 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ódigos 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 Proteger seu ambiente de desenvolvimento e Controles de operações seguras (Controles de acesso a identidades/aplicativos, controles de host/contêiner, controles de acesso à rede)

Padrão – esse controle deve ser avaliado em um nível de acesso a todos os recursos no projeto; é um controle necessário em todos os níveis de perfil do DevSecOps.

Para saber mais sobre a segurança do pipeline, consulte Como proteger o Azure Pipelines.

Operações seguras

Teste de penetração de site ativo

Esse controle dá suporte à Prática 7 do SDL Contínuo – Executar testes de segurança.

Peça para testadores profissionais de penetração de aplicativos tentarem comprometer uma instância ativa 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 o negócio. 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 de DevSecOps.

Mínimo temporário – recomendamos que você faça um teste de penetração em todos os aplicativos. 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 rapidamente esse valor 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 fazer 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 a identidades/aplicativos

Esse controle dá suporte à Prática 8 do SDL Contínuo – Garantir a segurança da plataforma operacional, e à Prática 6 – Proteger seu ambiente de engenharia.

Certifique-se de 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 Confiança Zero que a Microsoft recomenda.

Certifique-se de 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 – certifique-se de que todos usem autenticação multifator e só possam acessar os sistemas necessários para realizarem suas tarefas diárias.

Padrão – verifique se os componentes de infraestrutura que hospedam a carga de trabalho (como VMs, contêineres, rede e sistemas de identidade) atendem à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 de Confiança Zero completa que incorpore MFA, Detecção e Resposta a Ameaças de Identidade e Gerenciamento de Direitos de Infraestrutura na Nuvem (CIEM). Execute o modelo de ameaça específico da carga de trabalho de sistemas e componentes de identidade que suportam cada carga de trabalho de alta segurança.

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

Mais detalhes e recursos incluem:

Controles de host/contêiner/ambiente

Esse controle dá suporte à Prática 8 do SDL Contínuo – Garantir a segurança da plataforma operacional, e à Prática 6 – Proteger 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 ponto de extremidade de usuário que usam com frequência contra sistemas de produção e processos de desenvolvimento. A segurança da infraestrutura é um pilar fundamental do modelo de Confiança Zero 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 gerais de TI/operacionais
  • Estações de trabalho e ambientes de desenvolvimento dedicados
  • Infraestrutura de pipeline de CI/CD
  • Ambientes de hospedagem de cargas de trabalho
  • Quaisquer outros sistemas de desenvolvimento

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

  • Hosts de máquina virtual (VM) e VMs
  • Contêineres e infraestrutura de contêineres
  • Plataformas de hospedagem de aplicativos, scripts e códigos
  • Assinaturas/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 da 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 – verifique se a infraestrutura atende à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 de infraestrutura que suporta cada carga de trabalho de alta segurança.

Mais detalhes e recursos incluem:

Controles de acesso à rede

Esse controle dá suporte à Prática 8 do SDL Contínuo – Garantir a segurança da plataforma operacional, e à Prática 6 – Proteger 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 da rede é um pilar fundamental do modelo de Confiança Zero 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 normalmente assume a forma de firewall da Internet, firewall do 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 à proteção de rede externa e pode ser granular para a carga de trabalho ou para componentes individuais e endereços IP específicos.
  • Mitigações de negação de serviço – proteções contra negação de serviço distribuída (DDoS) e outros ataques de negação de serviço.
  • Security Service Edge (SSE) – uso de microssegmentação no cliente para fornecer acesso seguro diretamente aos recursos, incluindo a aplicação de políticas de Confiança Zero.

Certifique-se de 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 – verifique se todos os sistemas têm 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, tunelamento forçado do tráfego do servidor de saída por meio de mecanismos de proteção de rede externa e um modelo de ameaça específico da carga de trabalho da infraestrutura de rede que suporta cada carga de trabalho de alta segurança.

Mais detalhes e recursos incluem:

Monitoramento, resposta e recuperação

Esse controle dá suporte à Prática 9 do SDL Contínuo – 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. Certifique-se de que os processos e ferramentas entre as equipes de SecOps e Infraestrutura/Carga de Trabalho permitam uma recuperação rápida após um ataque.

Esse controle mantém 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 de detecção e resposta estendidas (XDR) 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 aprimorados com insights de inteligência contra ameaças em tempo real para identificar padrões de comportamento anômalo que podem indicar possíveis tentativas de se infiltrar na rede. Uma vez agregada, correlacionada e normalizada, a plataforma de XDR e Gerenciamento de Eventos e Informações de Segurança (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 comportamento anômalo 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 a 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, na qual você cria continuamente visando o estado ideal.

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

Você deve priorizar as bases essenciais primeiro devido ao seu amplo impacto positivo e a verificação de credenciais e segredos devido ao seu alto impacto e uso frequente por invasores.