Partilhar via

Segurança DevOps

A segurança de DevOps integra práticas de segurança em todo o ciclo de vida de desenvolvimento de software (SDLC), desde o projeto inicial e a codificação, passando pela compilação, teste e implantação até a produção. Ao contrário das abordagens de segurança tradicionais que tratam a segurança como uma porta final, a segurança de DevOps incorpora controles de segurança, testes automatizados e monitoramento contínuo em cada estágio do pipeline de desenvolvimento. Essa abordagem reconhece que a entrega de software moderno depende de pipelines complexos de CI/CD, dependências de terceiros, infraestrutura como código e implantações automatizadas, cada uma introduzindo potenciais vetores de ataque que os adversários exploram ativamente. Ao aplicar os princípios do Zero Trust (assumir violação, verificar explicitamente) e estratégias de defesa profunda, a segurança do DevOps garante que o código, as dependências, as configurações de infraestrutura e os processos de pipeline permaneçam confiáveis e invioláveis desde o projeto até a produção. Sem uma segurança abrangente de DevOps, as organizações enfrentam riscos críticos, incluindo ataques à cadeia de suprimentos, exposição de credenciais em pipelines, injeção de código mal-intencionado, imagens de contêineres vulneráveis e alterações não autorizadas na infraestrutura que podem estabelecer backdoors persistentes que afetam todos os consumidores downstream.

Aqui estão os três pilares principais do domínio de segurança DevOps Security.

Proteger o design e a cadeia de abastecimento: Execute a modelagem estruturada de ameaças com antecedência. Proteja a cadeia de abastecimento com análise de dependências e licenças, gestão de vulnerabilidades e geração de SBOM. Verificar a proveniência e integridade de todos os componentes.

Controlos relacionados:

Vire para a esquerda os controlos de segurança: Vire para a esquerda os controles de segurança integrando SAST, varredura secreta, varredura IaC e DAST no pipeline de CI/CD. Centralize o gerenciamento de segredos (por exemplo, Cofre de Chaves), restrinja a autoridade de alteração de pipeline e analise e proteja continuamente os artefatos (como imagens de contêiner e VM) antes da implantação.

Controlos relacionados:

Monitorar e auditar as atividades de DevOps: Colete e encaminhe logs de auditoria e segurança de DevOps para uma plataforma de análise central para correlação e resposta. Detete alterações não autorizadas no pipeline, escalonamentos de privilégios, confirmações anômalas e execução fora do horário comercial.

Controlos relacionados:

DS-1: Conduzir modelagem de ameaças

Princípio da segurança

Implemente a modelagem sistemática de ameaças usando a metodologia STRIDE durante a fase de projeto para identificar possíveis ameaças à segurança, priorizar riscos e implementar mitigações apropriadas antes do início do desenvolvimento do código. Essa abordagem de deslocamento para a esquerda reduz os custos de remediação e melhora a postura geral de segurança.

Risco a mitigar

As organizações que não conseguem conduzir a modelagem de ameaças durante a fase de projeto operam com pontos cegos críticos que os adversários exploram sistematicamente. Sem análise sistemática das ameaças:

  • Falhas arquitetônicas tardias: As vulnerabilidades de projeto incorporadas exigem refatoração dispendiosa na produção, com custos de remediação dramaticamente mais altos do que a resolução de problemas durante a fase de projeto.
  • Superfícies de ataque não identificadas: Vetores de ameaça, como limites de confiança inseguros, requisitos de autenticação ausentes ou proteções inadequadas de fluxo de dados, permanecem não documentados, permitindo que os invasores explorem fraquezas conhecidas que os defensores não reconhecem.
  • Controlos de segurança insuficientes: Controles de segurança ausentes ou inadequados (criptografia, autenticação, autorização, registro de auditoria) resultam de uma análise de ameaças incompleta, criando lacunas exploráveis na estratégia de defesa profunda.
  • Pontos cegos de conformidade: Os requisitos regulatórios (PCI-DSS, HIPAA, SOX) que exigem validação segura do projeto não podem ser satisfeitos sem modelos de ameaças documentados e evidências de mitigação.
  • Acumulação de dívida de garantia: Adições contínuas de recursos sem modelagem de ameaças criam uma dívida técnica de segurança crescente, tornando os sistemas progressivamente mais vulneráveis e difíceis de proteger retroativamente.

A falta de modelagem de ameaças aumenta a probabilidade de violação, estende o tempo de permanência e gera custos de remediação muito mais altos em comparação com a mitigação da fase inicial do projeto.

MITRE ATT&CK

  • Acesso Inicial (TA0001): explore o aplicativo voltado para o público (T1190) aproveitando falhas arquitetônicas na autenticação, gerenciamento de sessão ou validação de entrada que a modelagem de ameaças identificaria.
  • Escalada de Privilégios (TA0004): abuso do mecanismo de controle de elevação (T1548) explorando a separação insuficiente de privilégios ou a ausência de verificações de autorização na arquitetura do sistema.
  • Evasão de Defesa (TA0005): comprometer as defesas (T1562) explorando a ausência de registros de auditoria, lacunas de monitorização ou telemetria de segurança insuficiente integrados no sistema.

DS-1.1: Implementar modelagem de ameaças baseada em STRIDE

A modelagem sistemática de ameaças durante a fase de projeto fornece a base para a arquitetura segura de software, identificando vulnerabilidades antes do início do desenvolvimento. A resolução de problemas de segurança na fase de projeto reduz drasticamente os custos de remediação e evita que falhas arquitetônicas sejam incorporadas nos sistemas de produção. A identificação precoce de ameaças garante que os controles de segurança sejam incorporados à arquitetura, em vez de adaptados posteriormente.

Implemente a seguinte abordagem estruturada para estabelecer a modelagem de ameaças:

  • Estabelecer uma metodologia STRIDE sistemática: Estabelecer a modelagem sistemática de ameaças como uma atividade obrigatória em fase de projeto usando a metodologia STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Comece criando diagramas de fluxo de dados (DFDs) que mapeiam componentes do sistema, fluxos de dados, limites de confiança e dependências externas. Para cada componente e fluxo de dados, avalie sistematicamente ameaças potenciais em todas as seis categorias STRIDE, priorize os riscos com base na probabilidade e no impacto e documente mitigações específicas antes do início do desenvolvimento.

  • Use ferramentas estruturadas de modelagem de ameaças: Use ferramentas de modelagem de ameaças estruturadas, como a Microsoft Threat Modeling Tool , para manter a consistência e aproveitar modelos pré-criados para padrões de arquitetura comuns (aplicativos Web, APIs, microsserviços, soluções de IoT). A ferramenta facilita a criação de DFD, a identificação automatizada de ameaças com base em tipos de componentes e fluxos de dados e gera recomendações de mitigação acionáveis com controles de segurança associados. Armazene modelos de ameaça como artefatos versionados no controle do código-fonte juntamente com a documentação da arquitetura.

  • Integre em fluxos de trabalho de desenvolvimento: Integre saídas de modelagem de ameaças diretamente em fluxos de trabalho de desenvolvimento exportando ameaças identificadas para itens de trabalho do Azure DevOps com critérios claros de propriedade, prioridade e aceitação. Implemente portas de revisão de arquitetura que exijam modelos de ameaça concluídos antes da aprovação do projeto e estabeleça verificações de solicitação pull que acionam revisões de modelos de ameaças quando alterações na arquitetura são detetadas. Isso garante que a análise de ameaças permaneça sincronizada com a evolução do sistema durante todo o ciclo de vida do desenvolvimento.

DS-1.2: Automatize a integração da análise de ameaças

Dimensionar a modelagem de ameaças em grandes organizações requer automação e capacidade distribuída para evitar que as revisões de segurança se tornem gargalos de desenvolvimento. Fluxos de trabalho automatizados de identificação de ameaças incorporados nos processos de início de projeto e solicitação pull garantem uma análise de segurança consistente sem intervenção manual para cada projeto. O desenvolvimento de experiência em segurança dentro das equipes de desenvolvimento por meio de programas de capacitação cria práticas sustentáveis e escaláveis de modelagem de ameaças.

Implemente estes recursos de automação e habilitação:

  • Dimensione por meio de automação e habilitação: Dimensione a modelagem de ameaças em toda a organização por meio de automação e habilitação. Incorpore questionários de segurança em modelos de iniciação de projeto que avaliam automaticamente o nível de risco, determinam os requisitos de modelagem de ameaças e atribuem pontos de verificação de revisão de segurança apropriados com base na classificação de dados, exposição externa e escopo regulatório. Automatize os gatilhos de revisão de arquitetura nos fluxos de trabalho de pull request que detetam alterações nos limites do sistema, fluxos de autenticação ou encaminhamento lógico de manipulação de dados, encaminhando tais alterações para arquitetos de segurança para a validação de modelos de ameaça.

  • Crie recursos distribuídos com campeões de segurança: Estabeleça um programa Security Champions para criar recursos de modelagem de ameaças distribuídas dentro das equipes de desenvolvimento. Treine os campeões na metodologia STRIDE, forneça-lhes ferramentas e modelos de modelagem de ameaças e capacite-os para facilitar sessões de modelagem de ameaças para suas equipes. Os campeões de segurança servem como a primeira linha de revisão, escalando cenários complexos para equipes de segurança centralizadas e, ao mesmo tempo, permitindo que a maioria da modelagem de ameaças ocorra sem gargalos.

Implementação automatizada de análise de ameaças:

  • Avaliação baseada em questionários: Questionários de segurança padronizados integrados em modelos de DevOps do Azure para identificação consistente de ameaças
  • Programa de campeões de segurança: Campeões de segurança designados em cada equipe de desenvolvimento treinados na facilitação da modelagem de ameaças
  • Automação de revisão de arquitetura: Verificações automatizadas em solicitações pull para atualizações de diagramas de arquitetura que exigem revisões de modelos de ameaças
  • Modelo de ameaça como código: Definições de modelo de ameaça controladas por versão usando formatos estruturados (JSON/YAML) permitindo análise automatizada

Exemplo de implementação

Uma organização de serviços financeiros sofreu violação de dados quando invasores exploraram uma falha de autorização na API de pagamento que nunca foi identificada durante o desenvolvimento, resultando em transações fraudulentas significativas e multas regulatórias.

Desafio: Arquitetura de microsserviços com várias APIs implantadas sem revisão de segurança. As equipes de desenvolvimento não tinham experiência em segurança para identificar ameaças. Problemas de segurança arquitetônica descobertos somente após incidentes de produção.

Abordagem da solução:

  • Modelagem de ameaças STRIDE:Implementei a Microsoft Threat Modeling Tool para todos os microsserviços e pontos de extremidade de API com diagramas de fluxo de dados mostrando arquitetura e fluxos de dados confidenciais.
  • Programa de campeões de segurança: Facilitadores treinados de modelagem de ameaças em cada equipe de desenvolvimento, permitindo segurança por projeto sem estrangulamento da equipe central de segurança.
  • Integração automatizada de fluxo de trabalho: Revisões de modelos de ameaças integradas em fluxos de trabalho de solicitação pull do Azure DevOps que exigem aprovação de segurança para alterações de arquitetura.

Resultado: Identificou vários problemas de segurança antes da implantação, prevenindo possíveis violações. Reduziu substancialmente as vulnerabilidades de segurança na produção. As revisões de segurança adicionaram tempo mínimo ao ciclo de desenvolvimento.

Nível de criticidade

Deve ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: SA-11, SA-15, PL-8, RA-3, RA-5
  • PCI-DSS v4: 6.3.1, 6.3.2, 12.3.1
  • Controles CIS v8.1: 14.2, 14.3
  • NIST CSF v2.0: ID.RA-3, PR. IP-2
  • ISO 27001:2022: A.5.12, A.8.25
  • SOC 2: CC3.2, CC7.1

DS-2: Proteger a cadeia de fornecimento de software

Princípio da segurança

Implemente confiança zero para dependências verificando a procedência, integridade e postura de segurança de todos os componentes de terceiros antes da integração. Analise continuamente as dependências em busca de vulnerabilidades, mantenha uma lista de materiais de software (SBOM) abrangente e aplique atualizações de segurança automatizadas para minimizar a superfície de ataque à cadeia de suprimentos.

Risco a mitigar

Os ataques à cadeia de suprimentos de software representam ameaças críticas porque os adversários exploram as relações de confiança entre organizações e componentes de terceiros para alcançar um impacto generalizado com o mínimo de esforço. Sem uma segurança abrangente da cadeia de abastecimento:

  • Dependências maliciosas: Os adversários injetam backdoors em bibliotecas populares de código aberto (ataques no estilo SolarWinds) ou criam pacotes com erros de digitação que executam código malicioso durante a instalação ou na execução.
  • Bibliotecas de terceiros vulneráveis: CVEs conhecidas em dependências (vulnerabilidades Log4Shell, Heartbleed, Struts) permanecem sem correção por semanas ou meses devido à falta de visibilidade e gerenciamento automatizado de vulnerabilidades.
  • Artefatos de construção comprometidos: Os invasores adulteram binários compilados, imagens de contêiner ou pacotes de implantação durante o armazenamento ou trânsito, injetando malware que ignora a revisão do código-fonte.
  • Ataques de confusão de dependência: Agentes mal-intencionados carregam pacotes em repositórios públicos com nomes correspondentes a pacotes privados internos, explorando a lógica de resolução do gerenciador de pacotes para substituir códigos mal-intencionados.
  • Riscos de dependência transitiva: As vulnerabilidades nas dependências indiretas (dependências de dependências) permanecem invisíveis sem análise profunda da árvore de dependência e geração de SBOM.
  • Falta de verificação da proveniência: A ausência de verificação criptográfica permite ataques de substituição de pacotes em que pacotes legítimos são substituídos por versões maliciosas.

O comprometimento da cadeia de suprimentos permite amplo impacto, backdoors persistentes em bibliotecas confiáveis e alta evasão devido à aparência legítima.

MITRE ATT&CK

  • Acesso inicial (TA0001): comprometimento da cadeia de suprimentos (T1195.001) por meio do comprometimento de dependências de software e ferramentas de desenvolvimento para ganhar posição inicial em ambientes de destino e relacionamento confiável (T1199) explorando a confiança entre organizações e fornecedores de software de terceiros para fornecer atualizações maliciosas.
  • Execução (TA0002): interpretador de comandos e scripts (T1059) executando código malicioso incorporado em scripts de instalação de dependências ou ganchos pós-instalação.
  • Persistência (TA0003): compromete o binário do software cliente (T1554) incorporando backdoors em bibliotecas compiladas que persistem nas atualizações do aplicativo.

DS-2.1: Implementar verificação e gerenciamento de dependência

O gerenciamento abrangente de segurança de dependência evita ataques à cadeia de suprimentos mantendo a visibilidade de todos os componentes de terceiros, monitorando continuamente vulnerabilidades e automatizando os processos de correção. As aplicações modernas dependem de centenas ou milhares de dependências (diretas e transitivas), impossibilitando a avaliação manual de segurança e criando uma extensa superfície de ataque através de bibliotecas vulneráveis. A verificação automatizada de dependências com monitoramento contínuo garante que as organizações detetem e corrijam vulnerabilidades antes da exploração.

Estabeleça segurança de dependência contínua por meio destes recursos principais:

  • Estabeleça visibilidade abrangente e geração de SBOM: Estabeleça um gerenciamento contínuo de segurança de dependência com três recursos principais: visibilidade abrangente, deteção automatizada de vulnerabilidades e correção proativa. Comece gerando inventários de dependência completos que mapeiam dependências diretas (explicitamente declaradas em manifestos de pacote) e dependências transitivas (dependências de dependências) em todos os repositórios. Mantenha a lista de materiais de software (SBOM) em formatos padrão do setor (SPDX, CycloneDX) para conformidade regulatória e prontidão para resposta a incidentes.

  • Implemente a verificação e correção automatizadas de vulnerabilidades: Implemente a verificação automatizada de vulnerabilidades que monitora continuamente as dependências em relação ao National Vulnerability Database (NVD), ao GitHub Advisory Database e aos avisos de segurança específicos do idioma. Configure alertas em tempo real quando novas CVEs forem divulgadas, afetando sua pilha de dependências, com roteamento baseado em gravidade para equipes apropriadas. Habilite recursos automatizados de atualização de segurança que geram solicitações pull com atualizações de versão de dependência, incluindo testes de compatibilidade e resolução inteligente de conflitos de mesclagem para reduzir a carga de correção manual.

  • Integre a validação de segurança em fluxos de trabalho de desenvolvimento: Integre a validação de segurança de dependência diretamente nos fluxos de trabalho de desenvolvimento por meio de revisões de solicitação pull que avaliam automaticamente o impacto na segurança das alterações de dependência, sinalizando novas dependências com vulnerabilidades conhecidas, problemas de conformidade de licença ou características suspeitas (typosquatting, falta de reputação do mantenedor). Estabeleça portas de aprovação para alterações de dependência de alto risco e aplique políticas que proíbam a fusão de dependências com vulnerabilidades críticas em ramificações protegidas.

  • Estenda a visibilidade para ambientes de produção: Estenda a visibilidade além do código-fonte para ambientes implantados usando ferramentas como o Microsoft Defender for Cloud DevOps Security para correlacionar dependências de código com cargas de trabalho em execução, identificar caminhos de ataque por meio de cadeias de dependência e priorizar a correção com base na exposição real da produção, em vez de apenas no risco teórico. Ferramentas como o GitHub Advanced Security fornecem visualização abrangente de gráficos de dependência, atualizações automatizadas orientadas pelo Dependabot e suporte personalizado a padrões de vulnerabilidade para ecossistemas de pacotes proprietários.

Exemplo de implementação

Uma organização de saúde descobriu um pacote npm malicioso em um aplicativo de produção que exfiltrou dados de pacientes por meses. A investigação revelou extensas dependências vulneráveis com CVEs conhecidas, incluindo a vulnerabilidade crítica do Log4Shell.

Desafio: Milhares de dependências em centenas de repositórios sem visibilidade de vulnerabilidades ou pacotes maliciosos. As revisões manuais de dependências consumiram semanas por aplicação. A auditoria regulatória identificou lacunas críticas na cadeia de suprimentos.

Abordagem da solução:

  • Gestão automatizada de vulnerabilidades:Ativada a Segurança Avançada do GitHub com a verificação de dependências do Dependabot e a criação automática de solicitações pull para atualizações de segurança.
  • Transparência da cadeia de abastecimento: Implementei a ferramenta Microsoft SBOM gerando listas de materiais de software no formato SPDX para conformidade regulatória e resposta a incidentes.
  • Verificação do pacote:Artefatos do Azure configurados com verificação de assinatura e fixação de dependência, evitando ataques de confusão e substituição não autorizada de pacotes.
  • Monitoramento de segurança de DevOps: Implantou o Microsoft Defender for Cloud DevOps Security para rastreabilidade de código para nuvem.

Resultado: Detetou e remediou rapidamente dependências vulneráveis extensas. Impediu vários incidentes com pacotes maliciosos através da verificação automatizada. Atingi a conformidade regulatória com documentação abrangente de SBOM.

Nível de criticidade

Deve ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: SR-3, SR-4, SR-6, SA-12, SA-15(9), RA-5
  • PCI-DSS v4: 6.2.4, 6.3.2, 6.3.3
  • Controles CIS v8.1: 16.1, 16.2, 16.11
  • NIST CSF v2.0: ID.SC-2, ID.SC-4, DE.CM-8
  • ISO 27001:2022: A.5.19, A.5.22, A.5.23
  • SOC 2: CC3.2, CC8.1

DS-3: Proteja a infraestrutura de DevOps

Princípio da segurança

Implemente a defesa em profundidade para construir a infraestrutura por meio de gerenciamento abrangente de segredos, controles de acesso ao pipeline com portas de aprovação, configuração segura do agente de compilação e monitoramento contínuo. Elimine credenciais codificadas e imponha acesso de privilégios mínimos para proteger a integridade do processo de desenvolvimento e implantação de software.

Risco a mitigar

A infraestrutura de DevOps insegura cria vulnerabilidades críticas que os adversários exploram para comprometer toda a cadeia de fornecimento de software. Sem uma segurança de infraestrutura abrangente:

  • Pipelines de CI/CD comprometidos: Os invasores obtêm acesso para construir pipelines por meio de credenciais roubadas, vulnerabilidades exploradas ou acesso interno, permitindo injeção de código, adulteração de artefatos ou manipulação de implantação que afeta todos os consumidores downstream.
  • Segredos expostos em logs de construção e artefatos: Credenciais codificadas, chaves de API, certificados e cadeias de conexão vazam através de logs de pipeline, mensagens de erro ou artefatos compilados, fornecendo aos invasores acesso direto aos ambientes de produção.
  • Modificações não autorizadas na tubulação: A falta de fluxos de trabalho de controle e aprovação de alterações permite que agentes mal-intencionados modifiquem definições de pipeline, injetem etapas de compilação mal-intencionadas ou alterem configurações de implantação sem deteção.
  • Controlos de acesso insuficientes: Atribuições de função excessivamente permissivas e falta de separação de funções permitem movimento lateral, escalonamento de privilégios e estabelecimento de acesso persistente dentro da infraestrutura de DevOps.
  • Agentes de compilação inseguros: Agentes de compilação não corrigidos, mal configurados ou comprometidos fornecem aos invasores acesso persistente ao ambiente de compilação e potenciais pontos de pivô em redes de produção.
  • Pistas de auditoria em falta: O registro e o monitoramento inadequados das atividades de DevOps impedem a deteção de acesso não autorizado, modificações suspeitas ou ameaças internas.

O comprometimento da infraestrutura permite que os invasores injetem código na origem, ignorem pipelines confiáveis e afetem todos os aplicativos downstream.

MITRE ATT&CK

  • Acesso Inicial (TA0001): contas válidas (T1078) usando credenciais roubadas ou segredos da entidade de serviço para acessar plataformas e pipelines de DevOps.
  • Persistência (TA0003): manipulação de conta (T1098) criando entidades de serviço backdoor, tokens de acesso pessoal ou chaves SSH para acesso mantido.
  • Acesso a credenciais (TA0006): credenciais não seguras (T1552.001) que coletam segredos de logs de pipeline, variáveis de ambiente ou arquivos de configuração.
  • Evasão de defesa (TA0005): prejudicar defesas (T1562) desativando etapas de varredura de segurança, registro de auditoria ou portas de aprovação em definições de pipeline.

DS-3.1: Implementar o gerenciamento de segredos para pipelines

O gerenciamento centralizado de segredos elimina a exposição de credenciais em pipelines de DevOps, removendo segredos codificados de código, arquivos de configuração e definições de pipeline. As credenciais incorporadas no YAML do pipeline, variáveis de ambiente ou repositórios de origem representam o principal vetor de ataque para o comprometimento do pipeline, permitindo que os invasores que obtêm acesso a repositórios ou logs extraiam credenciais de produção. A implementação de armazenamento secreto protegido criptograficamente com recuperação dinâmica e padrões de acesso just-in-time evita o roubo de credenciais enquanto mantém a eficiência operacional.

Configure o gerenciamento de segredos com estes controles de segurança:

  • Elimine credenciais codificadas com armazenamento centralizado: Elimine credenciais codificadas de definições de pipeline e código-fonte centralizando todos os segredos em uma infraestrutura de gerenciamento de segredos dedicada com controles de acesso criptográficos e trilhas de auditoria abrangentes. Estabeleça o princípio de que os segredos nunca devem ser armazenados em arquivos YAML de pipeline, variáveis de ambiente visíveis em logs ou arquivos de configuração em repositórios - esses são os principais vetores para exposição de credenciais em ambientes de DevOps.

  • Configure a recuperação dinâmica de segredos com identidades gerenciadas: Implemente o armazenamento secreto centralizado usando soluções como o Azure Key Vault que fornecem armazenamento secreto criptografado, políticas de acesso granular, rotação automática de segredos e log de auditoria abrangente. Configure pipelines para recuperar segredos de forma dinâmica durante a execução, através de ligações de serviço seguras, em vez de os incorporar em definições de pipelines. Use identidades gerenciadas ou federação de identidades de carga de trabalho para autenticar o acesso de pipeline a repositórios secretos, eliminando a necessidade de credenciais de entidade de serviço de longa duração que se tornam alvos de roubo.

  • Imponha o acesso just-in-time com portas de aprovação: Imponha padrões de acesso secreto just-in-time em que os segredos são recuperados apenas quando necessário, com revogação automática após a conclusão do pipeline para minimizar a exposição do tempo de vida das credenciais. Implemente restrições de acesso com limite de tempo e exija autorização de várias pessoas (portas de aprovação) para acesso de pipeline a segredos de produção, garantindo que nenhuma conta comprometida possa acessar credenciais confidenciais sem verificação adicional.

  • Estabeleça controles de acesso à infraestrutura em camadas: Estabeleça controles de acesso em camadas para a infraestrutura de DevOps: restrinja os direitos de modificação de pipeline para pessoal revisado pela segurança, imponha permissões específicas do ambiente que exijam aprovação para implantações de produção, implemente restrições de conexão de serviço no nível do repositório impedindo que pipelines acessem segredos fora do escopo pretendido e implante agentes de compilação auto-hospedados protegidos com isolamento de rede para cargas de trabalho confidenciais. Integre a verificação de segurança de infraestrutura como código em pipelines para evitar a implantação de recursos mal configurados que possam expor segredos ou criar caminhos de acesso não autorizados.

Exemplo de implementação

Uma organização de varejo sofreu violação quando invasores usaram credenciais de entidade de serviço roubadas encontradas em logs de pipeline para acessar bancos de dados de produção, expondo milhões de registros de clientes.

Desafio: Cadeias de conexão de banco de dados e chaves de API codificadas em variáveis de pipeline. Permissões de pipeline excessivamente permissivas permitiam que qualquer desenvolvedor implantasse na produção. O comprometimento do agente de compilação forneceu acesso persistente à infraestrutura.

Abordagem da solução:

  • Gestão centralizada de segredos: Implementou a integração do Azure Key Vault eliminando segredos codificados de pipelines. Configuração de autenticação usando identidade gerida, removendo o risco de exposição de credenciais.
  • Controles de acesso ao gasoduto: Estabeleceu portas de aprovação e permissões específicas do ambiente usando os Ambientes de DevOps do Azure que exigem aprovação da equipe de segurança para implantações de produção.
  • Agentes de construção reforçados: Implantou agentes auto-hospedados com proteção de segurança e isolamento de rede para cargas de trabalho confidenciais que processam dados regulamentados.
  • Verificação de segurança da infraestrutura: Validação de segurança integrada para modelos ARM e configurações Terraform, evitando a implantação de configurações incorretas.

Resultado: Segredos foram eliminados dos registos de pipeline, impedindo o roubo de credenciais. Eliminadas implantações de produção não autorizadas. Detetou e bloqueou erros de configuração de infraestrutura antes da implantação.

Nível de criticidade

Deve ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: AC-2, AC-3, AC-6, SC-12, SC-13, AU-2, AU-6
  • PCI-DSS v4: 8.3.2, 8.6.1, 8.6.3, 12.3.3
  • Controles CIS v8.1: 4.1, 4.7, 6.1, 6.5
  • NIST CSF v2.0: PR. AC-4, PR. DS-5, DE. CM-7
  • ISO 27001:2022: A.5.15, A.5.16, A.8.3
  • SOC 2: CC6.1, CC6.6, CC6.7

DS-4: Integrar testes estáticos de segurança de aplicativos (SAST)

Princípio da segurança

Implemente testes de segurança automatizados abrangentes por meio de vários scanners SAST (Static Application Security Testing) especializados integrados em cada processo de compilação. Use a cobertura de vários scanners para uma deteção abrangente, implemente a varredura secreta com proteção por push e implante a análise semântica de código para identificar e bloquear vulnerabilidades antes que elas cheguem à produção.

Risco a mitigar

As vulnerabilidades de nível de código que escapam da deteção durante o desenvolvimento criam fraquezas de segurança persistentes que os adversários exploram sistematicamente. Sem integração SAST abrangente:

  • Vulnerabilidades da injeção: A injeção de SQL, o script entre sites (XSS), a injeção de comandos e as falhas de injeção LDAP permitem que os invasores manipulem a lógica do aplicativo, extraiam dados confidenciais ou executem código arbitrário.
  • Credenciais codificadas: Os desenvolvedores confirmam inadvertidamente senhas, chaves de API, certificados e cadeias de conexão em repositórios de código-fonte, fornecendo aos invasores acesso direto aos sistemas e dados de produção.
  • Implementações criptográficas inseguras: Algoritmos de criptografia fracos (DES, MD5), chaves de criptografia codificadas, vetores de inicialização inadequados ou comprimentos de chave insuficientes comprometem a confidencialidade e a integridade dos dados.
  • Estouro de buffer e corrupção de memória: Operações de memória inseguras em aplicativos C/C++ permitem a execução arbitrária de código, escalonamento de privilégios e ataques de negação de serviço.
  • Falhas de lógica de negócios: Falhas de autenticação, lacunas de autorização, condições de competição e validação de entrada insuficiente permitem fraude, escalonamento de privilégios e acesso não autorizado.
  • Infraestrutura como Código (IaC) problemas de configuração: Configurações inseguras do Terraform, modelos ARM ou manifestos do Kubernetes resultam em implementação de infraestrutura vulnerável, com acesso excessivo e permissivo, falta de criptografia ou pontos de extremidade de gestão expostos.

Na ausência de SAST automatizado, as vulnerabilidades acumulam-se como dívida técnica, prolongam o tempo de permanência e tornam-se dispendiosas para remediar na produção.

MITRE ATT&CK

  • Acesso Inicial (TA0001): explora aplicativos voltados para o público (T1190) aproveitando vulnerabilidades de injeção ou desvios de autenticação no código do aplicativo.
  • Execução (TA0002): exploração para execução de cliente (T1203) explorando vulnerabilidades do lado do cliente como XSS ou desserialização insegura.
  • Acesso a credenciais (TA0006): credenciais de armazenamentos de senhas (T1555) extraindo credenciais codificadas do código-fonte, arquivos de configuração ou binários compilados.
  • Elevação de privilégios (TA0004): exploração para elevação de privilégios (T1068) explorando estouros de buffer ou corrupção de memória para acesso elevado.

DS-4.1: Implementar pipeline SAST com Multi-Scanner

Testes abrangentes de segurança de aplicativos estáticos integrados em cada compilação fornecem deteção antecipada de vulnerabilidades no nível de código antes que elas cheguem aos ambientes de produção. Os aplicativos modernos usam diversas linguagens, estruturas e infraestrutura como código que exigem analisadores especializados - nenhum scanner único deteta todas as classes de vulnerabilidade. Estratégias SAST multicamadas, combinando ferramentas especializadas com execução automática e portões de qualidade, garantem uma cobertura abrangente, fornecendo aos desenvolvedores feedback imediato quando problemas de segurança são detetados.

Implemente testes de segurança automatizados com estes componentes:

  • Implemente uma estratégia de varredura em várias camadas: Incorpore testes automatizados de segurança de aplicativos estáticos em cada compilação para detetar vulnerabilidades antes que o código chegue à produção. Implemente uma estratégia SAST em várias camadas que combine vários scanners especializados - nenhuma ferramenta deteta todas as classes de vulnerabilidade, portanto, uma cobertura abrangente requer analisadores específicos de linguagem (Python, JavaScript, C/C++), scanners de infraestrutura como código (Terraform, modelos ARM, manifestos do Kubernetes), deteção de segredos e análise semântica de código para vulnerabilidades complexas de fluxo de dados.

  • Configure a execução automática com portas de qualidade: Configure a verificação SAST para ser executada automaticamente em cada solicitação commit e pull, fornecendo aos desenvolvedores feedback imediato sobre problemas de segurança enquanto o contexto do código é atualizado. Estabeleça portas de qualidade baseadas em gravidade que bloqueiem mesclagens ou implantações quando vulnerabilidades críticas ou de alta gravidade forem detetadas, impedindo que códigos vulneráveis avancem pelo pipeline. Configurar scanners para produzir resultados em formatos padronizados (SARIF), permitindo o rastreamento consistente de vulnerabilidades, a desduplicação entre ferramentas e a integração com painéis de segurança centralizados.

  • Implante a análise de segredos com proteção contra push: Implemente uma análise de segredos especializada com proteção contra push que impede que os desenvolvedores façam commit de credenciais, chaves de API, certificados ou tokens, capturando segredos nos repositórios no momento do commit, em vez de descobri-los em revisões de auditoria semanas depois. Ofereça suporte a padrões secretos padrão (chaves da AWS, tokens do Azure, cadeias de conexão de banco de dados) e padrões personalizados específicos da organização para mecanismos de autenticação proprietários. Quando segredos forem detetados, forneça orientação de correção imediata, incluindo procedimentos de rotação de credenciais e alternativas seguras.

  • Use a análise semântica de código para vulnerabilidades complexas: Implante ferramentas de análise de código semântico, como o GitHub CodeQL , que executam análises profundas de fluxo de dados para identificar vulnerabilidades complexas invisíveis para scanners de correspondência de padrões, como injeção de SQL por meio de várias chamadas de função, desvios de autenticação na lógica de negócios ou cadeias de desserialização inseguras. Crie consultas de segurança personalizadas adaptadas às estruturas, requisitos de segurança e padrões de vulnerabilidade comuns da sua organização identificados em retrospetivas de incidentes. Integre as descobertas de SAST diretamente nos fluxos de trabalho do desenvolvedor por meio de comentários de solicitação pull com números de linha específicos, explicações de vulnerabilidade e recomendações de correção.

  • Orquestre com plataformas unificadas: Plataformas SAST unificadas como o Microsoft Security DevOps Extension podem orquestrar vários scanners especializados (AntiMalware, Bandit, BinSkim, Checkov, ESLint, Template Analyzer, Terrascan, Trivy) por meio de uma única tarefa de pipeline, padronizando o gerenciamento de configuração e a agregação de resultados em ecossistemas de ferramentas heterogêneos.

Exemplo de implementação

Um provedor de SaaS sofreu um ataque de injeção de SQL expondo centenas de milhares de registros de clientes. A análise pós-incidente revelou extensas vulnerabilidades no nível do código, incluindo credenciais codificadas e falhas de injeção que existiam há meses.

Desafio: As revisões manuais de código detetaram apenas uma pequena fração das vulnerabilidades. Os desenvolvedores não tinham treinamento de segurança para identificar falhas de injeção e fraquezas criptográficas. Nenhuma verificação automatizada antes da implantação da produção.

Abordagem da solução:

  • SAST multi-scanner:Implantou a extensão Microsoft Security DevOps com CodeQL, ESLint e Bandit, fornecendo cobertura abrangente entre idiomas e tipos de vulnerabilidade.
  • Proteção secreta: Implementei a Segurança Avançada do GitHub com verificação secreta e proteção push, evitando a exposição de credenciais em confirmações.
  • Análise semântica: Configurado o GitHub CodeQL com consultas personalizadas para vulnerabilidades de lógica de negócios e padrões de segurança específicos da estrutura.
  • Portões de segurança: Portas de pipeline estabelecidas no Azure Pipelines bloqueando a implantação de descobertas de alta gravidade.

Resultado: Identificou e corrigiu rapidamente extensas vulnerabilidades. Impediu que falhas críticas de segurança atingissem a produção. Redução substancial da dívida de garantia.

Nível de criticidade

Deve ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: SA-11, RA-5, SI-2
  • PCI-DSS v4: 6.3.2, 6.4.1, 11.3.1
  • Controles CIS v8.1: 16.3, 16.6
  • NIST CSF v2.0: PR.IP-2, DE.CM-4
  • ISO 27001:2022: A.8.25, A.8.29
  • SOC 2: CC7.1, CC7.2

DS-5: Integrar testes dinâmicos de segurança de aplicativos (DAST)

Princípio da segurança

Implemente testes de segurança dinâmicos abrangentes em ambientes de pré-produção por meio da verificação de segurança de contêineres para cargas de trabalho em contêineres, testes de penetração automatizados para aplicativos Web e interfaces de programação de aplicativos (APIs) e testes especializados para autenticação, autorização e gerenciamento de sessão. A validação do tempo de execução identifica fraquezas de configuração e vulnerabilidades de integração que a análise estática não pode detetar.

Risco a mitigar

As vulnerabilidades de tempo de execução que são invisíveis para a análise estática criam lacunas de segurança críticas que os adversários exploram depois que os aplicativos são implantados. Sem DAST abrangente:

  • Pontos fracos da configuração de implantação: Provedores de autenticação mal configurados, CORS permissivos, configurações TLS fracas ou cabeçalhos de segurança ausentes (CSP, HSTS, X-Frame-Options) permitem ataques que a revisão da fonte não pode detetar.
  • Lacunas de segurança da API: APIs REST e GraphQL com desvios de autenticação, falhas de autorização, exposição excessiva de dados, limitação de taxa ausente ou referências diretas inseguras de objetos (IDOR) permitem acesso não autorizado e extração de dados.
  • Desvios de autenticação e autorização: Falhas no gerenciamento de sessões, fluxos de redefinição de senha, implementação de autenticação multifator ou lógica de controle de acesso baseada em função permitem o escalonamento de privilégios e a tomada de controle de contas.
  • Vulnerabilidades de gestão de sessão: Tokens de sessão previsíveis, aplicação inadequada de limite de tempo, vulnerabilidades de fixação da sessão ou a ausência de revogação de tokens permitem sequestro de sessão e roubo de credenciais.
  • Questões de segurança específicas do ambiente: Pontos de integração com bancos de dados, filas de mensagens, APIs externas ou serviços de terceiros introduzem vulnerabilidades de tempo de execução invisíveis no desenvolvimento ou em testes isolados.
  • Falhas de lógica de negócios: Condições de corrida, vulnerabilidades de manipulação de estado, validação de entrada insuficiente em fluxos de trabalho complexos ou problemas de integridade de transação permitem fraude e manipulação de dados.

O DAST valida o comportamento de execução em tempo real, a configuração do ambiente e a segurança de integração oferecida pela cobertura que a análise estática não consegue proporcionar.

MITRE ATT&CK

  • Acesso Inicial (TA0001): explorar a aplicação de acesso público (T1190) aproveitando desvios de autenticação, falhas de injeção ou pontos de extremidade de API inseguros descobertos por meio de testes em tempo de execução.
  • Acesso a credenciais (TA0006): força bruta (T1110) explorando ausência de limitação de taxa, políticas de senha fracas ou tokens de sessão previsíveis detectados durante o DAST.
  • Escalonamento de privilégios (TA0004): contas válidas (T1078) abusando de desvios de autorização ou vulnerabilidades de manipulação de funções em aplicativos implantados.
  • Coleta (TA0009): dados de repositórios de informações (T1213) extraindo dados confidenciais por meio de respostas excessivas de API, travessia de diretório ou vulnerabilidades inseguras de referência direta de objetos.
  • Exfiltração (TA0010): exfiltração sobre serviço Web (T1567) explorando lacunas de segurança da API para extrair dados em escala sem deteção.

DS-5.1: Implementar DAST automatizado na pré-produção

O teste dinâmico de segurança de aplicativos valida controles de segurança em aplicativos em execução, descobrindo vulnerabilidades de tempo de execução que a análise estática não pode detetar. Enquanto o SAST examina o código-fonte, o DAST testa aplicativos implantados com configurações semelhantes às de produção para identificar problemas específicos da implantação, incluindo configurações incorretas de autenticação, falhas de autorização e lacunas de segurança de integração que só se manifestam em ambientes operacionais. O DAST automatizado em pré-produção garante a validação de segurança antes da exposição do cliente enquanto testa cenários de ataque realistas contra sistemas integrados.

Implemente a validação de segurança em tempo de execução por meio destes recursos:

  • Complemente o SAST com validação de tempo de execução: Complemente a análise estática com testes dinâmicos de segurança de aplicativos que validam a segurança em aplicativos em execução com configurações semelhantes às de produção. Enquanto o SAST identifica vulnerabilidades no código-fonte, o DAST descobre problemas de tempo de execução invisíveis para a análise estática: fraquezas na configuração da implantação (provedores de autenticação mal configurados, políticas CORS permissivas, cabeçalhos de segurança ausentes), falhas de integração específicas do ambiente (segurança de conexão de banco de dados, autorização de API em contextos implantados) e vulnerabilidades de lógica de negócios que só se manifestam em condições operacionais realistas.

  • Implante em ambientes de preparação semelhantes aos de produção: Implante a verificação de DAST em ambientes de preparação de pré-produção que espelhem a arquitetura de produção, a topologia de rede, as dependências externas e os parâmetros de configuração. A execução automatizada do DAST deve ser acionada na implantação para preparação, testando sistematicamente fluxos de autenticação, limites de autorização, gerenciamento de sessão, validação de entrada, segurança de API e tratamento de erros sob padrões realistas de carga e uso. Isso valida que os controles de segurança funcionam corretamente quando integrados com sistemas externos semelhantes aos de produção (provedores de identidade, bancos de dados, filas de mensagens, APIs de terceiros).

  • Implemente o monitoramento de tempo de execução para contêineres: Para cargas de trabalho em contêineres, implemente o monitoramento de segurança em tempo de execução contínuo que combina a verificação de imagem pré-implantação com a análise comportamental pós-implantação. Analise imagens de contêiner em busca de vulnerabilidades conhecidas antes da implantação e, em seguida, monitore contêineres em execução em busca de conexões de rede anômalas, execução de processos não autorizados, modificações no sistema de arquivos e tentativas de escalonamento de privilégios. Crie o perfil do comportamento normal da carga de trabalho do Kubernetes para detetar desvios que indiquem comprometimento e avalie continuamente as configurações do contêiner em relação aos benchmarks do CIS e às práticas recomendadas de segurança.

  • Foco em superfícies de ataque de alto risco: Concentre esforços especializados de DAST em superfícies de ataque de alto risco: APIs REST e GraphQL (testar desvios de autenticação, falhas de autorização, vulnerabilidades de injeção, exposição excessiva de dados, referências diretas de objetos inseguras), autenticação e gestão de sessão (validar a segurança dos tokens, imposição de limites de tempo, funcionalidade de saída, fluxos de redefinição de palavras-passe, autenticação multifator) e fluxos de trabalho de lógica de negócios (testar condições de corrida, manipulação de estado, problemas de integridade de transação). Estabeleça fluxos de trabalho de correlação SAST/DAST que combinem descobertas de ambas as abordagens, priorizando vulnerabilidades confirmadas por meio de análises estáticas e dinâmicas como de maior risco.

  • Aproveite as plataformas integradas: Para ambientes em contêineres, o Microsoft Defender for Containers fornece avaliação integrada de vulnerabilidades em tempo de execução, perfil de carga de trabalho e recursos de deteção de ameaças durante todo o ciclo de vida do contêiner.

Exemplo de implementação

Uma organização de comércio eletrônico descobriu desvio de autenticação na API de pagamento permitindo descontos não autorizados. O SAST perdeu a falha de configuração de tempo de execução que só se manifestava em ambientes implantados com provedores de autenticação externos.

Desafio: O SAST detetou vulnerabilidades de código, mas não detetou problemas na configuração em tempo de execução nem falhas na autorização de API. A configuração de implantação de produção diferia do desenvolvimento, criando lacunas de segurança invisíveis para a análise estática.

Abordagem da solução:

  • Verificação DAST automatizada: Implantei o OWASP ZAP em ambientes de pré-produção, testando aplicativos implantados com configurações semelhantes às de produção.
  • Proteção de tempo de execução do contêiner: Implementou o Microsoft Defender for Containers para monitoramento de segurança em tempo de execução e avaliação de vulnerabilidades.
  • Testes de segurança da API: Testes de API especializados configurados validando autenticação, autorização e validação de dados em endpoints REST e GraphQL implantados.
  • Correlação SAST/DAST: Criou fluxos de trabalho de correlação de vulnerabilidades combinando descobertas estáticas e dinâmicas para validação de segurança abrangente.

Resultado: Vulnerabilidades em tempo de execução descobertas que foram ignoradas pelo SAST, incluindo desvios de autenticação e falhas de autorização em APIs. Preveniram incidentes de segurança através da deteção antes da produção.

Nível de criticidade

Deve ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: SA-11, CA-8, RA-5
  • PCI-DSS v4: 6.4.2, 11.3.2
  • Controles CIS v8.1: 16.7, 16.8
  • NIST CSF v2.0: DE.CM-4, PR.IP-12
  • ISO 27001:2022: A.8.29, A.8.30
  • SOC 2: CC7.1, CC7.3

DS-6: Proteja o ciclo de vida da carga de trabalho

Azure Policy: Consulte definições de políticas incorporadas no Azure: DS-6.

Princípio da segurança

Implemente uma infraestrutura imutável com segurança de imagem abrangente por meio de registros de contêiner e verificação de segurança para cargas de trabalho de contêiner, gerenciamento de imagens douradas e criação automatizada para cargas de trabalho de máquina virtual (VM) e verificação contínua de vulnerabilidades com quarentena automatizada. Verifique as assinaturas criptográficas, mantenha imagens básicas mínimas e imponha linhas de base de segurança durante todo o ciclo de vida da carga de trabalho.

Risco a mitigar

O gerenciamento inseguro do ciclo de vida da carga de trabalho permite que artefatos vulneráveis ou comprometidos alcancem a produção, criando vetores de ataque persistentes que os adversários exploram sistematicamente. Sem proteção abrangente da carga de trabalho:

  • Imagens de VM de produção vulneráveis: Linhas de base do sistema operacional sem patches ou imagens douradas mal configuradas propagam fraquezas em todas as VMs implantadas.
  • Imagens de base vulneráveis sem patch: Contêineres criados em bases afetadas por CVE (Log4Shell, Heartbleed, OpenSSL) expõem cargas de trabalho à exploração e escape.
  • Artefatos vulneráveis obsoletos: Imagens e pacotes não digitalizados acumulam CVEs, expandindo a superfície de ataque.
  • Verificação de imagem insuficiente: A falta de assinatura criptográfica e validação de proveniência permite que os adversários substituam imagens legítimas por versões comprometidas contendo backdoors ou malware.
  • Superfície de ataque inchada: Imagens de contêiner contendo pacotes desnecessários, ferramentas de desenvolvimento ou utilitários de depuração aumentam a exposição à vulnerabilidade e fornecem aos invasores ferramentas de exploração adicionais.
  • Linhas de base de segurança em falta: As imagens de VM e contêiner implantadas sem conformidade de benchmark do CIS, proteção de segurança ou configuração de privilégios mínimos criam lacunas exploráveis na defesa em profundidade.

Artefatos comprometidos tornam-se vetores de ataque persistentes, auxiliam o movimento lateral e parecem legítimos para os defensores.

MITRE ATT&CK

  • Acesso Inicial (TA0001): explore aplicativos voltados para o público (T1190) aproveitando vulnerabilidades não corrigidas em contêineres de aplicativos ou serviços Web.
  • Execução (TA0002): implantar contêiner (T1610) implantando contêineres mal-intencionados que parecem legítimos devido à verificação de imagem insuficiente.
  • Escalonamento de privilégios (TA0004): escape para o anfitrião (T1611) explorando vulnerabilidades de contentor para sair do isolamento de contentor e comprometer o sistema anfitrião.
  • Movimento Lateral (TA0008): exploração de serviços remotos (T1210) pivotando entre VMs ou contêineres vulneráveis implantados a partir de imagens comprometidas.

DS-6.1: Implementar segurança de imagem de contêiner

As imagens de contêiner e VM representam superfícies de ataque críticas que exigem controles de segurança abrangentes durante todo o seu ciclo de vida. As imagens de base vulneráveis propagam pontos fracos para cada instância implantada, ampliando o impacto em toda a infraestrutura. Tratar os artefatos de carga de trabalho com o mesmo rigor de segurança do código-fonte, incluindo verificação, assinatura e armazenamento seguro, garante que as organizações implantem apenas imagens verificadas e confiáveis, evitando que invasores explorem vulnerabilidades conhecidas ou substituam imagens maliciosas.

Proteja artefatos de carga de trabalho por meio destas práticas:

  • Estabeleça princípios de infraestrutura imutáveis: Tratar imagens de contentores e imagens de VM como artefatos críticos que exigem o mesmo rigor de segurança que o código-fonte — imagens base vulneráveis propagam fraquezas em cada instância implantada. Estabeleça princípios de infraestrutura imutáveis em que os artefatos de carga de trabalho são criados uma vez, digitalizados de forma abrangente, assinados criptograficamente e implantados sem modificações para garantir consistência e rastreabilidade durante todo o ciclo de vida.

  • Use imagens de base mínimas com compilações de vários estágios: Para cargas de trabalho de contêiner, implemente a segurança de imagem em camadas, começando com imagens básicas mínimas que contenham apenas componentes essenciais de tempo de execução, reduzindo drasticamente a superfície de ataque em comparação com imagens completas do sistema operacional. Use compilações de vários estágios para separar dependências de tempo de compilação de imagens de tempo de execução - compile e crie imagens ricas em recursos e, em seguida, copie apenas os artefatos finais para imagens de tempo de execução mínimas, eliminando ferramentas de desenvolvimento, gerenciadores de pacotes e dependências de compilação que aumentam a exposição à vulnerabilidade e fornecem aos invasores ferramentas de exploração.

  • Integre a verificação automatizada com políticas de quarentena: Integre a verificação automatizada de vulnerabilidades no pipeline de construção de imagens que verifica todas as imagens antes do armazenamento do Registro, verificando bancos de dados CVE abrangentes e reexaminando continuamente as imagens armazenadas à medida que novas vulnerabilidades são divulgadas. Implemente políticas de quarentena automatizadas que impeçam a implantação de imagens com vulnerabilidades críticas ou de alta gravidade, com fluxos de trabalho de exceção que exigem aprovação da equipe de segurança e aceitação de riscos documentados. Estabeleça políticas de atualização de imagens de base com ativadores automatizados de pipeline quando forem lançadas atualizações de segurança, garantindo que as imagens não acumulem CVEs ao longo do tempo.

  • Impor assinatura e verificação criptográficas: Imponha a integridade da imagem por meio de assinatura criptográfica e verificação em todas as imagens de assinatura de estágio no momento da compilação, verifique as assinaturas antes da implantação e rejeite imagens não assinadas ou adulteradas automaticamente. Isso evita ataques de substituição de imagem em que adversários substituem imagens legítimas por versões comprometidas contendo backdoors. Armazene imagens em registros de contêiner seguros com controles de acesso à rede (pontos de extremidade privados, integração de rede virtual), políticas de acesso baseadas em função que limitam quem pode enviar imagens por push/pull e registro de auditoria abrangente de todas as operações do Registro.

  • Mantenha imagens douradas reforçadas para VMs: Para cargas de trabalho de VM, mantenha repositórios de imagens dourados centralizados com imagens base reforçadas e compatíveis com o CIS que passam por patches de segurança regulares e validação de conformidade. Implemente pipelines automatizados de criação de imagens que incorporem atualizações de segurança, remova serviços desnecessários, imponha configurações de privilégios mínimos e gere novas imagens em agendas definidas, em vez de aplicar patches em sistemas em execução.

  • Aproveite as plataformas de segurança integradas: Soluções como o Azure Container Registry com a integração do Microsoft Defender for Containers fornecem verificação automatizada, fluxos de trabalho de quarentena, confiança de conteúdo e replicação em várias regiões com políticas de segurança consistentes.

Exemplo de implementação

Uma organização de logística implantou um aplicativo de contêiner com imagem base não corrigida contendo vulnerabilidade crítica de execução remota de código. Os atacantes exploraram a vulnerabilidade logo após a implantação, comprometendo os dados de envio.

Desafio: Várias imagens de contentor sem análise de vulnerabilidades. As imagens construídas há meses acumularam muitos CVEs, incluindo vulnerabilidades críticas. Nenhuma verificação impediu a substituição maliciosa de imagens.

Abordagem da solução:

  • Segurança do registo do contentor: Implementado o Registo de Contentores do Azure com verificação de vulnerabilidades que coloca em quarentena imagens com CVEs de alta gravidade antes da implementação.
  • Imagens de VM reforçadas: Desplegou a Galeria de Imagens Partilhadas do Azure, com imagens de VM que estão em conformidade com o benchmark CIS para cargas de trabalho reguladas.
  • Proteção de tempo de execução: Configurado o Microsoft Defender for Containers para deteção contínua de ameaças e monitoramento de desvios.
  • Integridade do artefato: Assinatura e verificação criptográficas estabelecidas garantindo a autenticidade da imagem durante todo o ciclo de vida.

Resultado: Imagens vulneráveis bloqueadas de implantação em produção. CVEs de contêiner drasticamente reduzidas por imagem. Impediu ataques de substituição de imagem através da verificação de assinatura.

Nível de criticidade

Deve ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: CM-2, CM-3, SI-2, SI-7, RA-5
  • PCI-DSS v4: 6.2.4, 6.3.3, 11.3.1
  • Controles CIS v8.1: 4.1, 7.3, 7.4
  • NIST CSF v2.0: PR.IP-1, PR.IP-3, DE.CM-8
  • ISO 27001:2022: A.8.9, A.8.31, A.8.32
  • SOC 2: CC7.2, CC8.1

DS-7: Implementar registro e monitoramento de DevOps

Princípio da segurança

Implemente o registro abrangente de atividades de DevOps por meio de streaming de auditoria com integração a plataformas centralizadas de Gerenciamento de Informações e Eventos de Segurança (SIEM) para análise de segurança, deteção de ameaças em tempo real e resposta automatizada. Estabeleça análises comportamentais, deteção de anomalias e métricas de segurança para permitir uma resposta rápida a incidentes e manter trilhas de auditoria de conformidade.

Risco a mitigar

O registro e o monitoramento insuficientes de DevOps criam pontos cegos críticos que os adversários exploram para operar sem serem detetados, estabelecer persistência e exfiltrar códigos ou credenciais confidenciais. Sem visibilidade abrangente:

  • Comprometimentos de pipeline não detetados: Os atacantes modificam pipelines de CI/CD para injetar código malicioso, exfiltrar segredos ou estabelecer backdoors sem gerar alertas devido a registo de auditoria ausente ou insuficiente.
  • Ameaças internas modificando código ou infraestrutura: Insiders mal-intencionados ou contas comprometidas fazem alterações não autorizadas no código-fonte, definições de infraestrutura ou configurações de implantação sem deteção.
  • Falta de pistas de auditoria abrangentes: A ausência de registros de atividades detalhados impede a investigação forense, a avaliação de impacto e a análise de causa raiz quando ocorrem incidentes de segurança, prolongando o tempo de permanência e aumentando o impacto da violação.
  • Resposta atrasada a incidentes: O Tempo Médio de Deteção (MTTD) se estende de horas a semanas quando as equipes de segurança não têm alertas em tempo real, deteção de anomalias e correlação automatizada de eventos de segurança de DevOps.
  • Falhas na auditoria de conformidade: Os requisitos regulatórios (SOX, PCI-DSS, HIPAA, ISO 27001) que exigem trilhas de auditoria abrangentes, controle de alterações e registro de acesso não podem ser satisfeitos sem monitoramento centralizado de DevOps.
  • Cegueira de escalonamento de privilégios: A elevação não autorizada de permissões, a criação de contas backdoor ou a modificação de controles de acesso não são detetadas sem análise comportamental e monitoramento de privilégios.

As lacunas de registro ocultam alterações maliciosas no pipeline, escalonamento de privilégios e tentativas de acesso persistentes em caminhos de desenvolvimento de alto privilégio.

MITRE ATT&CK

  • Evasão de Defesa (TA0005): prejudicar defesas (T1562) desativando registos de auditoria, etapas de análise de segurança ou agentes de monitoramento para operarem em pontos cegos, e remoção de indicadores (T1070) limpando registos de auditoria ou histórico de execução de pipeline para ocultar atividades maliciosas.
  • Persistência (TA0003): manipulação de conta (T1098) criando entidades de serviço adicionais, tokens de acesso pessoal ou chaves SSH sem deteção.
  • Recolha (TA0009): dados provenientes de repositórios de informação (T1213) com exfiltração de código-fonte, segredos ou propriedade intelectual através de acesso a pipelines.
  • Acesso a credenciais (TA0006): credenciais não seguras (T1552) que coletam segredos expostos de logs de pipeline ou histórico de execução.

DS-7.1: Implementar log de auditoria para plataformas de DevOps

As plataformas de DevOps com acesso privilegiado à infraestrutura de produção e ao código-fonte sensível exigem um monitoramento de segurança abrangente para detetar atividades adversárias e ameaças internas. As lacunas nos registos de auditoria permitem que agentes mal-intencionados operem sem serem detetados por longos períodos, enquanto a agregação centralizada de registos permite a correlação com uma telemetria de segurança mais ampla, revelando cadeias sofisticadas de ataque. A análise comportamental em tempo real identifica padrões suspeitos invisíveis em eventos isolados, transformando dados brutos de auditoria em inteligência de segurança acionável.

Estabeleça um monitoramento de segurança abrangente de DevOps por meio destes recursos:

  • Capture atividades abrangentes relevantes para a segurança: Estabeleça um log de auditoria abrangente que capture todas as atividades de DevOps relevantes para a segurança: eventos de autenticação e autorização do usuário, confirmações de código-fonte e operações de ramificação, criação e modificação de pipeline, execuções de implantação, acesso secreto, alterações de permissão, criação de entidade de serviço e ações administrativas. As plataformas de DevOps possuem acesso privilegiado à infraestrutura de produção e lacunas confidenciais de registro de código permitem que adversários e insiders mal-intencionados operem sem serem detetados por longos períodos.

  • Encaminhe logs para SIEM centralizado em tempo real: Encaminhe logs de auditoria em tempo real para plataformas SIEM centralizadas, em vez de depender da retenção nativa da plataforma DevOps (normalmente 90 dias), permitindo análises forenses de longo prazo, relatórios de conformidade e correlação com eventos de segurança de outros sistemas. Transmita logs para centros de operações de segurança por meio de protocolos padronizados (/azure Event Hubs, syslog) em formatos estruturados (JSON) que permitem análise, análise e alertas automatizados sem revisão manual de logs.

  • Implante análises comportamentais e deteção de anomalias: Implemente análises comportamentais e deteção de anomalias em dados de auditoria de DevOps para identificar padrões suspeitos invisíveis em eventos individuais: modificações de pipeline após o expediente, acesso incomum a repositórios confidenciais, escalonamento rápido de privilégios, criação de entidade de serviço seguida de implantações suspeitas, execuções de pipeline de locais inesperados ou padrões anormais de acesso secreto. Estabeleça perfis de comportamento de linha de base para usuários e serviços, alertando sobre desvios estatisticamente significativos que possam indicar comprometimento ou ameaças internas.

  • Configure alertas automatizados para atividades de alto risco: Configure alertas automatizados para atividades de alto risco com notificação imediata às equipes de segurança: falhas de implantação de produção, modificações de pipeline em ramificações protegidas, criação de nova entidade de serviço, eventos de elevação de permissão, etapas de verificação de segurança desabilitadas, alterações de configuração de encaminhamento de log de auditoria ou tentativas de acessar segredos de pipelines não autorizados. Implemente escalonamento baseado em gravidade, garantindo que alertas críticos cheguem às operações de segurança imediatamente, enquanto os eventos de rotina são agrupados para análise.

  • Integre com telemetria de segurança mais ampla: Integre logs de auditoria de DevOps com telemetria de segurança mais ampla em plataformas SIEM para correlação com deteção de pontos finais, segurança de rede, eventos de identidade e feeds de inteligência de ameaças. Isso permite a deteção de cadeias de ataque sofisticadas em que o comprometimento do DevOps é um estágio em operações multifásicas - por exemplo, correlacionando credenciais phishing com modificações subsequentes de pipeline e provisionamento incomum de recursos em nuvem.

  • Aproveite as plataformas SIEM integradas: Plataformas como o Azure DevOps Audit Streaming com integração com o Microsoft Sentinel fornecem encaminhamento de logs em tempo real, regras de deteção pré-criadas para ameaças de DevOps, pastas de trabalho de segurança para investigação e orquestração de resposta automatizada.

Exemplo de implementação

Uma organização de manufatura descobriu uma ameaça interna quando um antigo prestador de serviços modificou o pipeline de CI/CD, injetando código de acesso não autorizado no aplicativo de produção. O incidente permaneceu sem ser detetado por meses devido ao registro insuficiente de auditoria.

Desafio: Nenhum registro centralizado de atividades de DevOps. Modificações de pipeline e alterações de acesso privilegiado não foram devidamente monitoradas. Investigação forense dificultada pela falta de pistas de auditoria. Falha na auditoria de conformidade devido ao controle insuficiente de alterações.

Abordagem da solução:

  • Registo de auditoria centralizado: Encaminhamento de eventos de Azure DevOps Audit Streaming ativado para o Microsoft Sentinel para análise de segurança e retenção de longo prazo.
  • Análise comportamental: Implementou a deteção de anomalias identificando padrões de acesso incomuns, modificações de pipeline após o expediente e escalonamentos de privilégios indicando ameaças internas.
  • Alertas automatizados: Alertas configurados para atividades suspeitas, incluindo implantações de produção não autorizadas e roteamento de criação de entidade de serviço para operações de segurança.
  • Relatórios de conformidade: Criação de trilhas de auditoria automatizadas atendendo aos requisitos normativos com controle abrangente de alterações.

Resultado: Detetou e impediu modificações subsequentes de tubulações não autorizadas rapidamente. Redução drástica do tempo de investigação de incidentes com trilhas de auditoria abrangentes. Alcançou conformidade com a gestão das alterações documentada.

Nível de criticidade

Deveria ter.

Mapeamento de controle

  • NIST SP 800-53 Rev.5: AU-2, AU-3, AU-6, AU-12, SI-4
  • PCI-DSS v4: 10.2.1, 10.2.2, 10.3.4
  • Controles CIS v8.1: 8.2, 8.5, 8.11
  • NIST CSF v2.0: DE.CM-1, DE.CM-7, RS.AN-1
  • ISO 27001:2022: A.8.15, A.8.16
  • SOC 2: CC7.2, CC7.3
  • Last updated on