Compartilhar via

Segurança DevOps

A segurança do DevOps integra as práticas de segurança em todo o SDLC (ciclo de vida de desenvolvimento de software) desde o design e a codificação iniciais por meio de build, teste e implantação em produção. Ao contrário das abordagens de segurança tradicionais que tratam a segurança como um portão final, a segurança do DevOps inscreve 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 moderna 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 princípios de Confiança Zero (assumir violação, verificar explicitamente) e estratégias de defesa detalhada, 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 resistentes a violações do design por meio da produção. Sem a segurança abrangente do 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-intencionada, imagens de contêiner vulneráveis e alterações de infraestrutura não autorizadas 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 de Segurança do DevOps.

Proteja o design e a cadeia de suprimentos: Execute a modelagem de ameaças estruturada antecipadamente. Proteja a cadeia de suprimentos com verificação de dependência e licença, gerenciamento de vulnerabilidades e geração de SBOM. Verifique a procedência e a integridade de todos os componentes.

Controles relacionados:

Antecipe o controle de segurança: Antecipe o controle de segurança integrando SAST, verificação de segredos, verificação de IaC e DAST ao pipeline de CI/CD. Centralize o gerenciamento de segredos (por exemplo, Key Vault), restrinja a autoridade de alteração de pipeline e examine e proteja continuamente os artefatos (como contêiner e imagens de VM) antes da implantação.

Controles relacionados:

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

Controles relacionados:

DS-1: Realizar modelagem de ameaças

Princípio de segurança

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

Risco a mitigar

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

  • Falhas de arquitetura tardias: As vulnerabilidades de design embutido exigem refatoração cara na produção, com custos de correção significativamente maiores do que resolver 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 indocumentados, permitindo que os invasores explorem pontos fracos conhecidos que os defensores não reconhecem.
  • Controles de segurança insuficientes: Controles de segurança ausentes ou inadequados (criptografia, autenticação, autorização, log de auditoria) resultam da análise de ameaças incompleta, criando lacunas exploráveis na estratégia de defesa em profundidade.
  • Pontos cegos de conformidade: Os requisitos regulatórios (PCI-DSS, HIPAA, SOX) que exigem validação de design seguro não podem ser atendidos sem modelos de ameaça documentados e evidências de mitigação.
  • Acúmulo de dívida de segurança: Adições contínuas de recursos sem modelagem de ameaças criam uma dívida técnica de segurança composta, 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 vida e gera um custo de correção muito maior em comparação com a mitigação da fase de design precoce.

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.
  • Escalonamento de privilégios (TA0004): mecanismo de controle de elevação de abuso (T1548) explorando separação de privilégio insuficiente ou verificações de autorização ausentes na arquitetura do sistema.
  • Evasão de Defesa (TA0005): comprometer as defesas (T1562) explorando a falta de registro de auditoria, as lacunas de monitoramento do sistema ou a telemetria de segurança inadequada do sistema.

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

A modelagem sistemática de ameaças durante a fase de design fornece a base para uma arquitetura de software segura identificando vulnerabilidades antes do início do desenvolvimento. Resolver problemas de segurança no estágio de design reduz drasticamente os custos de correção e impede que falhas arquitetônicas sejam inseridas em sistemas de produção. A identificação antecipada de ameaças garante que os controles de segurança sejam integrados à arquitetura em vez de adaptados posteriormente.

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

  • Estabelecer metodologia de STRIDE sistemática: Estabeleça a modelagem sistemática de ameaças como uma atividade de fase de design obrigatória usando a metodologia STRIDE (Falsificação, Adulteração, Repúdio, Divulgação de Informações, Negação de Serviço, Elevação de Privilégio). Comece criando DFDs (diagramas de fluxo de dados) 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 possíveis ameaças 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 estruturadas de modelagem de ameaças, como a Ferramenta de Modelagem contra Ameaças da Microsoft , para manter a consistência e aproveitar modelos predefinidos para padrões comuns de arquitetura (aplicativos Web, APIs, microsserviços, soluções de IoT). A ferramenta facilita a criação do 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ças como artefatos versionados no controle de versão junto com a documentação da arquitetura.

  • Integre-se aos fluxos de trabalho de desenvolvimento: Integre as 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 portões de revisão de arquitetura que exijam análises de ameaça concluídas antes da aprovação do design, e estabeleça verificações de solicitação de pull que disparem a revisão do modelo de ameaça quando forem detectadas alterações arquitetônicas. Isso garante que a análise de ameaças permaneça sincronizada com a evolução do sistema durante todo o ciclo de vida de desenvolvimento.

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

O dimensionamento da modelagem de ameaças em grandes organizações requer automação e capacidade distribuída para impedir que as revisões de segurança se tornem gargalos de desenvolvimento. Os fluxos de trabalho automatizados de identificação de ameaças inseridos nos processos de solicitação de pull e iniciação de projeto garantem uma análise de segurança consistente sem intervenção manual para cada projeto. A criação de conhecimentos de segurança em equipes de desenvolvimento por meio de programas de habilitação cria práticas de modelagem de ameaças sustentáveis e escalonáveis.

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

  • Dimensionar por meio da automação e habilitação: Dimensionar a modelagem de ameaças em toda a organização por meio da automação e da habilitação. Insira 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 segurança apropriados com base na classificação de dados, exposição externa e escopo regulatório. Automatizar gatilhos de revisão de arquitetura em fluxos de trabalho de pedidos de pull que detectam alterações nos limites do sistema, fluxos de autenticação ou lógica de manipulação de dados, enviando tais alterações para arquitetos de segurança para validação do modelo de ameaça.

  • Criar funcionalidade distribuída com campeões de segurança: Estabeleça um programa de Campeões de Segurança para criar a capacidade 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, enquanto permitem que a maior parte da modelagem de ameaças ocorra sem gargalos.

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

  • Avaliação baseada em questionário: Questionários de segurança padronizados integrados aos modelos do Azure DevOps 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 treinada em facilitação de modelagem de ameaças
  • Automação de revisão de arquitetura: Verificações automatizadas em solicitações de pull para atualizações de diagrama de arquitetura que exigem revisões de modelo de ameaça
  • Modelo de ameaça como código: Definições de modelo de ameaça controladas por versão usando formatos estruturados (JSON/YAML) habilitando a análise automatizada

Exemplo de implementação

Uma organização de serviços financeiros sofreu violação de dados quando os invasores exploraram a 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: Implementou a Ferramenta de Modelagem de Ameaças da Microsoft 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 defensores de segurança: Facilitadores treinados em modelagem de ameaças em cada equipe de desenvolvimento, permitindo a segurança por design sem criar gargalos para a equipe de segurança central.
  • Integração automatizada de fluxo de trabalho: Revisões integradas do modelo de ameaças nos fluxos de trabalho de solicitação de pull do Azure DevOps que exigem aprovação de segurança para alterações arquitetônicas.

Resultado: Identificamos vários problemas de segurança na pré-implantação, evitando possíveis violações. Vulnerabilidades de segurança significativamente reduzidas 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 de segurança

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

Risco a mitigar

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

  • Dependências mal-intencionadas: Os adversários injetam backdoors em bibliotecas populares de software livre (ataques no estilo SolarWinds) ou criam pacotes maliciosos que imitam nomes conhecidos e que executam código malicioso durante a instalação ou o tempo de execução.
  • Bibliotecas de terceiros vulneráveis: CVEs conhecidos em dependências (vulnerabilidades Log4Shell, Heartbleed, Struts) permanecem não corrigidos por semanas ou meses devido à falta de visibilidade e gerenciamento automatizado de vulnerabilidades.
  • Artefatos de construção comprometidos: Os invasores comprometem binários compilados, imagens de contêineres e pacotes de implantação durante o armazenamento ou trânsito, injetando malware que esses ignoram a revisão do código-fonte.
  • Ataques de confusão de dependência: Atores mal-intencionados carregam pacotes em repositórios públicos com nomes que correspondem a pacotes privados internos, explorando a lógica de resolução do gerenciador de pacotes para substituir o código mal-intencionado.
  • Riscos de dependência transitiva: Vulnerabilidades em dependências indiretas (dependências de dependências) permanecem invisíveis sem análise de árvore de dependência profunda e geração de SBOM.
  • Falta de verificação de procedência: A ausência de verificação criptográfica permite ataques de substituição de pacote em que pacotes legítimos são substituídos por versões mal-intencionadas.

O comprometimento da cadeia de suprimentos permite um impacto amplo, portas traseiras persistentes em bibliotecas confiáveis e elevada capacidade de 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 obter a base inicial em ambientes de destino, e relação de confiança (T1199) aproveitando a confiança entre organizações e fornecedores de software de terceiros para entregar atualizações mal-intencionadas.
  • Execução (TA0002): interpretador de comando e script (T1059) executando código mal-intencionado inserido em scripts de instalação de dependência ou ganchos pós-instalação.
  • Persistência (TA0003): comprometer o binário de software cliente (T1554) inserindo backdoors em bibliotecas compiladas que persistem nas atualizações do aplicativo.

DS-2.1: implementar a verificação e o gerenciamento de dependências

O gerenciamento abrangente de segurança de dependência impede ataques da cadeia de suprimentos mantendo a visibilidade de todos os componentes de terceiros, monitorando continuamente as vulnerabilidades e automatizando processos de correção. Os aplicativos modernos dependem de centenas ou milhares de dependências (diretas e transitivas), impossibilitar a avaliação de segurança manual e criar uma ampla superfície de ataque por meio de bibliotecas vulneráveis. A verificação automatizada de dependências com monitoramento contínuo garante que as organizações detectem e corrijam vulnerabilidades antes da exploração.

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

  • Estabelecer visibilidade abrangente e geração de SBOM: Estabeleça o gerenciamento contínuo de segurança de dependência com três recursos principais: visibilidade abrangente, detecçã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 SBOM (Declaração de Software de Materiais) em formatos padrão do setor (SPDX, CycloneDX) para conformidade regulatória e preparação para resposta a incidentes.

  • Implemente a verificação e a correção de vulnerabilidades automatizadas: Implemente a verificação automatizada de vulnerabilidades que monitora continuamente as dependências em relação ao NVD (Banco de Dados de Vulnerabilidade Nacional), ao Banco de Dados consultivo do GitHub e aos avisos de segurança específicos do idioma. Configure alertas em tempo real sempre que novos CVEs forem divulgados que afetem sua pilha de dependências, com roteamento para equipes apropriadas baseado na severidade. Habilite os recursos de atualização de segurança automatizados que geram solicitações de 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 aos fluxos de trabalho de desenvolvimento: Integre a validação de segurança de dependência diretamente aos fluxos de trabalho de desenvolvimento por meio de revisões de solicitação de pull que avaliam automaticamente o impacto na segurança das alterações de dependência que sinalizam novas dependências com vulnerabilidades conhecidas, problemas de conformidade de licença ou características suspeitas (tiposquatação, falta de reputação do mantenedor). Estabeleça barreiras de aprovação para alterações de dependência de alto risco e imponha políticas que proíbem dependências com vulnerabilidades críticas de serem mescladas a branches protegidos.

  • Estender a visibilidade aos ambientes de produção: Estenda a visibilidade além do código-fonte para ambientes implantados usando ferramentas como o Microsoft Defender para 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 risco teórico. Ferramentas como a Segurança Avançada do GitHub fornecem visualização abrangente do grafo de dependência, atualizações automatizadas controladas por Dependabot e suporte a padrões de vulnerabilidade personalizados para ecossistemas de pacotes proprietários.

Exemplo de implementação

Uma organização de saúde descobriu um pacote npm mal-intencionado no aplicativo de produção que exfiltrava dados de pacientes por meses. A investigação revelou dependências amplamente vulneráveis com CVEs conhecidos, incluindo a vulnerabilidade crítica do Log4Shell.

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

Abordagem da solução:

  • Gerenciamento automatizado de vulnerabilidades: Habilitado a Segurança Avançada do GitHub com dependências de verificação do Dependabot e a criação automática de solicitações de pull para atualizações de segurança.
  • Transparência da cadeia de suprimentos: Implementação da ferramenta Microsoft SBOM gerando a Fatura de Software de Materiais no formato SPDX para conformidade regulatória e resposta a incidentes.
  • Verificação de pacote: O Azure Artifacts está configurado com verificação de assinatura e fixação de dependências, evitando ataques de confusão e substituição não autorizada de pacotes.
  • Monitoramento de segurança do DevOps: Implantado o Microsoft Defender para Cloud DevOps Security para rastreamento de código para nuvem.

Resultado: Detectou e corrigiu dependências vulneráveis extensas rapidamente. Impediu vários incidentes de pacote mal-intencionado por meio da verificação automatizada. Atingiu a conformidade regulatória com a documentação abrangente do 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: proteger a infraestrutura de DevOps

Princípio de segurança

Implemente a defesa em profundidade para a infraestrutura de build por meio de gerenciamento abrangente de segredos, controles de acesso ao pipeline com barreiras de aprovação, configuração segura do agente de build e monitoramento contínuo. Elimine as credenciais codificadas e imponha o 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 entrega de software. Sem segurança de infraestrutura abrangente:

  • Pipelines de CI/CD comprometidos: Os invasores obtêm acesso para criar pipelines por meio de credenciais roubadas, vulnerabilidades exploradas ou acesso interno, permitindo injeção de código, adulteração de artefato ou manipulação de implantação que afeta todos os consumidores downstream.
  • Segredos expostos em logs de build e artefatos: Credenciais codificadas, chaves de API, certificados e strings de conexão são vazadas por meio de logs de pipeline, mensagens de erro ou artefatos compilados, permitindo aos invasores acesso direto a ambientes de produção.
  • Modificações de pipeline não autorizadas: A falta de fluxos de trabalho de controle de alteração e aprovação permite que atores mal-intencionados modifiquem definições de pipeline, insiram etapas de build mal-intencionadas ou alterem as configurações de implantação sem detecção.
  • Controles de acesso insuficientes: Atribuições de função excessivamente permissivas e a falta de separação de tarefas permitem a movimentação lateral, o escalonamento de privilégios e o estabelecimento de acesso persistente dentro da infraestrutura de DevOps.
  • Agentes de build inseguros: Agentes de build não corrigidos, configurados incorretamente ou comprometidos fornecem aos invasores acesso persistente ao ambiente de build e possíveis pontos de pivô em redes de produção.
  • Trilhas de auditoria ausentes: O registro em log inadequado e o monitoramento de atividades de DevOps impedem a detecção de acesso não autorizado, modificações suspeitas ou ameaças internas.

O comprometimento da infraestrutura permite que os invasores insiram 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 do principal de serviço para acessar plataformas e pipelines de DevOps.
  • Persistência (TA0003): manipulação de conta (T1098) criando principais de serviço de backdoor, tokens de acesso pessoal ou chaves SSH para acesso contínuo.
  • Acesso à Credencial (TA0006): credenciais não seguras (T1552.001) extraindo segredos de logs de pipeline, variáveis de ambiente ou arquivos de configuração.
  • Evasão de Defesa (TA0005): prejudica as defesas (T1562) desabilitando etapas de verificação de segurança, registro em log de auditoria ou portões 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ódigos, arquivos de configuração e definições de pipeline. As credenciais inseridas no YAML do pipeline, variáveis de ambiente ou repositórios de origem representam o vetor de ataque primário para o comprometimento do pipeline, permitindo que os invasores que obtêm acesso a repositórios ou logs extraam credenciais de produção. Implementar o armazenamento secreto protegido criptograficamente com padrões de acesso just-in-time e recuperação dinâmica impede o roubo de credenciais, mantendo a eficiência operacional.

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

  • Eliminar credenciais codificadas com armazenamento centralizado: Elimine as credenciais codificadas das definições de pipeline e do código-fonte centralizando todos os segredos na infraestrutura de gerenciamento de segredos dedicado com controles de acesso criptográfico 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.

  • Configurar a recuperação de segredo dinâmico com identidades gerenciadas: Implemente o armazenamento de segredo centralizado usando soluções como o Azure Key Vault que fornecem armazenamento secreto criptografado, políticas de acesso granular, rotação automática de segredo e log de auditoria abrangente. Configure os pipelines para recuperar os segredos dinamicamente em tempo de execução por meio de conexões de serviço seguras, ao invés de incorporá-los nas definições de pipeline. Use identidades gerenciadas ou federação de identidade 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 portões de aprovação: Estabeleça padrões de acesso secreto just-in-time em que os segredos são recuperados somente quando necessário, e revogação automática ocorre após a conclusão do pipeline para minimizar a exposição ao tempo de vida da credencial. Implemente restrições de acesso com limite de tempo e exija autorização de várias pessoas (portões 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.

  • Estabelecer 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 à equipe revisada pela segurança, imponha permissões específicas do ambiente que exigem 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 os pipelines acessem segredos fora do escopo pretendido e implantem agentes de build 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 impedir a implantação de recursos configurados incorretamente que possam expor segredos ou criar caminhos de acesso não autorizados.

Exemplo de implementação

Uma organização de varejo sofreu uma violação quando invasores usaram credenciais de entidade de serviço roubadas encontradas em registros 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 permitiram que qualquer desenvolvedor implantasse em produção. O comprometimento do agente responsável pela compilação forneceu acesso persistente à infraestrutura.

Abordagem da solução:

  • Gerenciamento centralizado de segredos: Integração com o Azure Key Vault eliminando segredos codificados nos pipelines. Configuração de autenticação com identidade gerenciada, removendo o risco de exposição de credenciais.
  • Controles de acesso de pipeline: Barreiras de aprovação estabelecidas e permissões específicas de ambiente utilizando os ambientes do Azure DevOps, que requerem aprovação da equipe de segurança para implantações de produção.
  • Agentes de build protegidos: Agentes auto-hospedados implantados com proteção de segurança e isolamento de rede para cargas de trabalho confidenciais que processam dados regulamentados.
  • Verificação de segurança de infraestrutura: Validação de segurança integrada para modelos do ARM e configurações do Terraform impedindo a implantação de configuração incorreta.

Resultado: Eliminação de segredos dos logs de pipeline, impedindo o roubo de credenciais. Implantações de produção não autorizadas eliminadas. Configurações incorretas de infraestrutura detectadas e bloqueadas 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 o SAST (Teste de Segurança de Aplicativo Estático)

Princípio de segurança

Implemente testes de segurança automatizados abrangentes por meio de vários scanners SAST (Teste de Segurança de Aplicativo Estático) especializados integrados a cada processo de compilação. Use a cobertura de vários scanners para detecção abrangente, implemente a verificação secreta com proteção por push e implante a análise de código semântico para identificar e bloquear vulnerabilidades antes que elas cheguem à produção.

Risco a mitigar

Vulnerabilidades no nível de código que escapam à detecção durante o desenvolvimento criam pontos fracos de segurança persistentes que os adversários exploram sistematicamente. Sem integração SAST abrangente:

  • Vulnerabilidades de injeção: A injeção de SQL, o XSS (script entre sites), a injeção de comando e as falhas de injeção LDAP permitem que os invasores manipulem a lógica do aplicativo, extraam 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 a dados e sistemas 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.
  • Estouros de buffer e corrupção de memória: Operações de memória não seguras em aplicativos C/C++ permitem 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: Desvios de autenticação, lacunas de autorização, condições de corrida e validação de entrada insuficiente permitem escalonamento de privilégios, fraude e acesso não autorizado.
  • Configurações incorretas de IaC (infraestrutura como código): Os manifestos do Terraform, do ARM ou do Kubernetes não seguros implantam uma infraestrutura vulnerável com acesso excessivamente permissivo, criptografia ausente ou pontos de extremidade de gerenciamento expostos.

Sem SAST automatizado, as vulnerabilidades se acumulam como dívida técnica, estendem o tempo de vida e tornam-se dispendiosas para serem corrigidas na produção.

MITRE ATT&CK

  • Acesso Inicial (TA0001): explore o aplicativo voltado para o público (T1190) aproveitando vulnerabilidades de injeção ou bypasses de autenticação no código do aplicativo.
  • Execução (TA0002): exploração para execução no cliente (T1203), explorando vulnerabilidades do lado do cliente, como XSS ou desserialização insegura.
  • Acesso à Credencial (TA0006): credenciais de repositórios de senha (T1555) extraindo credenciais codificadas do código-fonte, arquivos de configuração ou binários compilados.
  • Escalonamento de privilégios (TA0004): exploração para escalonamento de privilégios (T1068) explorando estouros de buffer ou corrupção de memória para acesso elevado.

DS-4.1: implementar o pipeline SAST de vários scanners

Testes abrangentes de segurança de aplicativos estáticos integrados a cada build fornecem detecção antecipada de vulnerabilidades no nível de código antes de chegarem aos ambientes de produção. Os aplicativos modernos usam linguagens, estruturas e infraestrutura como código diversos que exigem analisadores especializados. Nenhum scanner único detecta todas as classes de vulnerabilidade. Estratégias de SAST de várias camadas, combinando ferramentas especializadas com execução automática e portões de qualidade, garantem uma cobertura abrangente e fornecem aos desenvolvedores feedback imediato quando problemas de segurança são detectados.

Implemente testes de segurança automatizados com estes componentes:

  • Implementar estratégia de verificação em várias camadas: Insira testes automatizados de segurança de aplicativos estáticos em cada build para detectar vulnerabilidades antes que o código chegue à produção. Implementar uma estratégia SAST de várias camadas que combina vários scanners especializados- nenhuma única ferramenta detecta todas as classes de vulnerabilidade, de modo que uma cobertura abrangente requer analisadores específicos da linguagem (Python, JavaScript, C/C++), scanners de infraestrutura como código (Terraform, modelos do ARM, manifestos do Kubernetes), detecção de segredo e análise de código semântico para vulnerabilidades complexas de fluxo de dados.

  • Configurar a execução automática com portões de qualidade: Configure a verificação SAST para ser executada automaticamente em cada solicitação de confirmação e pull, fornecendo aos desenvolvedores comentários imediatos sobre problemas de segurança enquanto o contexto de código é novo. Estabeleça portões de qualidade baseados em severidade que bloqueiam mesclagens ou implantações quando vulnerabilidades críticas ou de alta gravidade são detectadas, impedindo que o código vulnerável avance pelo pipeline. Configure os scanners para gerar resultados de saída em formatos padronizados (SARIF), permitindo um acompanhamento consistente de vulnerabilidades, eliminação de duplicações entre ferramentas e integração com painéis de segurança centralizados.

  • Implantar a varredura de segredos com proteção por push: Implemente uma varredura de segredos especializada com proteção por push que impede os desenvolvedores de confirmarem credenciais, chaves de API, certificados ou tokens, capturando os segredos no momento da confirmação em repositórios, ao invés de serem descobertos semanas depois em revisões de auditoria. Suporte a padrões de segredo padrão (chaves 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 os segredos são detectados, forneça diretrizes imediatas de correção, incluindo procedimentos de rotação de credenciais e alternativas seguras.

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

  • Orquestrar com plataformas unificadas: Plataformas SAST unificadas, como a Extensão de DevOps de Segurança da Microsoft , 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 entre ecossistemas de ferramentas heterogêneas.

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 vulnerabilidades extensas 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 detectaram apenas uma pequena fração de 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 de produção.

Abordagem da solução:

  • SAST com vários scanners:Extensão de DevOps de Segurança da Microsoft implantada com CodeQL, ESLint e Bandit, fornecendo cobertura abrangente para diversos idiomas e tipos de vulnerabilidade.
  • Proteção secreta: Implementou a Segurança Avançada do GitHub com verificação secreta e proteção por push impedindo a exposição de credenciais em confirmações.
  • Análise semântica: Configurou 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: Portões de pipeline estabelecidos no Azure Pipelines bloqueando a implantação de descobertas de alta gravidade.

Resultado: Vulnerabilidades extensas identificadas e corrigidas rapidamente. Impediu que falhas críticas de segurança atingissem a produção. Redução substancial da dívida de segurança.

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 o Teste Dinâmico de Segurança de Aplicações (DAST)

Princípio de segurança

Implemente testes de segurança dinâmica abrangentes em ambientes de pré-produção por meio da verificação de segurança de contêiner para cargas de trabalho em contêineres, testes de penetração automatizados para aplicativos Web e APIs (Interfaces de Programação de Aplicativo) e testes especializados para autenticação, autorização e gerenciamento de sessão. A validação de runtime identifica pontos fracos de configuração e vulnerabilidades de integração que a análise estática não pode detectar.

Risco a mitigar

Vulnerabilidades de runtime invisíveis à 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 de configuração de implantação: Provedores de autenticação configurados incorretamente, CORS permissivo, configurações de TLS fracas ou cabeçalhos de segurança ausentes (CSP, HSTS, X-Frame-Options) permitem que a revisão de código fonte não detecte ataques.
  • Lacunas de segurança de API: APIs REST e GraphQL com bypass de autenticação, falhas de autorização, exposição excessiva de dados, ausência de limitação de taxa ou referências de objeto direto não seguras (IDOR) permitem acesso não autorizado e extração de dados.
  • Falhas na autenticação e autorização: Falhas no gerenciamento de sessão, 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 o sequestro de conta.
  • Vulnerabilidades de gerenciamento de sessão: Tokens de sessão previsíveis, imposição insuficiente de tempo limite, vulnerabilidades de fixação de sessão ou falta de revogação de token permitem o sequestro de sessão e o roubo de credenciais.
  • Problemas de segurança específicos do ambiente: Os pontos de integração com bancos de dados, filas de mensagens, APIs externas ou serviços de terceiros introduzem vulnerabilidades de runtime invisíveis no desenvolvimento ou em testes isolados.
  • Falhas de lógica de negócios: Condições de concorrência, vulnerabilidades na manipulação de estado, validação de entrada insuficiente em fluxos de trabalho complexos ou problemas de integridade de transação permitem fraudes e manipulação de dados.

O DAST valida o comportamento em tempo de execução, a configuração do ambiente e a segurança de integração, fornecendo cobertura que a análise estática não pode oferecer.

MITRE ATT&CK

  • Acesso Inicial (TA0001): explore o aplicativo voltado para o público (T1190) aproveitando bypasses de autenticação, falhas de injeção ou pontos de extremidade de API inseguros descobertos por meio de testes de runtime.
  • Acesso a Credenciais (TA0006): ataque de força bruta (T1110) explorando a 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) que abusam de bypasses de autorização ou de vulnerabilidades de manipulação de funções em aplicativos implantados.
  • Coleção (TA0009): dados de repositórios de informações (T1213) extraindo dados confidenciais por meio de respostas excessivas de API, passagem de diretório ou vulnerabilidades de referência de objeto direto não seguro.
  • Exfiltração (TA0010): exfiltração pelo serviço Web (T1567) explorando lacunas de segurança de API para extrair dados em escala sem detecção.

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

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

Implemente a validação de segurança de runtime por meio desses recursos:

  • Complemente o SAST com a validação de runtime: Complemente a análise estática com testes dinâmicos de segurança de aplicativo que validam a segurança na execução de aplicativos com configurações semelhantes à produção. Embora o SAST identifique vulnerabilidades no código-fonte, o DAST descobre problemas de runtime invisíveis à análise estática: pontos fracos de configuração de implantação (provedores de autenticação configurados incorretamente, políticas de 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.

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

  • Implementar o monitoramento durante o tempo de execução para contêineres: Para cargas de trabalho em contêineres, implemente o monitoramento contínuo de segurança durante o tempo de execução que combina varredura de imagens antes da implantação com análise comportamental após a implantação. Verifique as imagens de contêiner em busca de vulnerabilidades conhecidas antes da implantação e monitore contêineres em execução para conexões de rede anômalas, execução de processo não autorizado, modificações do sistema de arquivos e tentativas de escalonamento de privilégios. Perfilize o comportamento normal da carga de trabalho do Kubernetes para detectar desvios que indicam comprometimento e avalie continuamente as configurações de contêiner em relação aos parâmetros de comparação de CIS e às práticas recomendadas de segurança.

  • Concentre-se em superfícies de ataque de alto risco: Concentre os esforços especializados do DAST em superfícies de ataque de alto risco: APIs REST e GraphQL (testar bypasses de autenticação, falhas de autorização, vulnerabilidades de injeção, exposição excessiva de dados, referências de objetos diretos inseguros), gerenciamento de autenticação e sessão (validar a segurança dos tokens, cumprimento de tempo limite, funcionalidade de logout, fluxos de redefinição de senha, 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 da transação). Estabeleça fluxos de trabalho de correlação SAST/DAST que combinam descobertas de ambas as abordagens, priorizando vulnerabilidades confirmadas por meio da análise estática e dinâmica como de maior risco.

  • Aproveite as plataformas integradas: Para ambientes em contêineres, o Microsoft Defender para Contêineres fornece avaliação integrada de vulnerabilidade de runtime, criação de perfil de carga de trabalho e recursos de detecção de ameaças em todo o ciclo de vida do contêiner.

Exemplo de implementação

Uma organização de comércio eletrônico descobriu o bypass de autenticação na API de pagamento, permitindo descontos não autorizados. O SAST perdeu a falha de configuração de runtime que se manifestou apenas em ambientes implantados com provedores de autenticação externos.

Desafio: O SAST detectou vulnerabilidades de código, mas não identificou problemas de configuração de tempo de execução e falhas de autorização de API. A configuração de implantação de produção difere do desenvolvimento, criando lacunas de segurança invisíveis à análise estática.

Abordagem da solução:

  • Verificação automatizada do DAST: Implantado o OWASP ZAP em ambientes de pré-produção testando aplicativos implantados com configurações semelhantes à produção.
  • Proteção de runtime de contêiner: Implementação do Microsoft Defender para Contêineres para monitoramento de segurança de runtime e avaliação de vulnerabilidades.
  • Teste de segurança de API: Configurou testes de API especializados validando autenticação, autorização e validação de dados em pontos de extremidade REST e GraphQL implantados.
  • Correlação SAST/DAST: Criaram fluxos de trabalho de correlação de vulnerabilidade combinando descobertas estáticas e dinâmicas para validação de segurança abrangente.

Resultado: Vulnerabilidades de ambiente de execução descobertas que passaram despercebidas pelo SAST, incluindo bypass de autenticação e problemas de autorização de API. Incidentes de segurança foram evitados através de detecção na pré-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: proteger o ciclo de vida da carga de trabalho

Azure Policy: Confira as definições de política internas do Azure: DS-6.

Princípio de segurança

Implemente uma infraestrutura imutável com segurança abrangente de imagem por meio de registros de contêiner e verificação de segurança para cargas de trabalho de contêiner, gerenciamento de imagens padrão e construção automatizada para cargas de trabalho de máquinas virtuais (VM), além de verificação contínua de vulnerabilidades com quarentena automatizada. Verifique as assinaturas criptográficas, mantenha imagens base mínimas e implemente padrões de segurança em todo o ciclo de vida operacional.

Risco a mitigar

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

  • Imagens de VM de produção vulneráveis: Linhas de base do sistema operacional não corrigidas ou imagens padrão configuradas incorretamente disseminam vulnerabilidades em todas as VMs implantadas.
  • Imagens base vulneráveis não corrigidas: Contêineres criados em bases afetadas por CVE (Log4Shell, Heartbleed, OpenSSL) expõem cargas de trabalho à exploração e ao escape.
  • Artefatos vulneráveis obsoletos: Imagens e pacotes deixados não verificados acumulam CVEs, expandindo a superfície de ataque.
  • Verificação de imagem insuficiente: A falta de assinatura criptográfica e validação de procedência permite que os adversários substituam imagens legítimas por versões comprometidas que contêm backdoors ou malware.
  • Superfície de ataque inchada: As imagens de contêiner que contêm pacotes desnecessários, ferramentas de desenvolvimento ou utilitários de depuração aumentam a exposição a vulnerabilidades e fornecem aos invasores ferramentas de exploração adicionais.
  • Linhas de base de segurança ausentes: Imagens de VM e contêiner implantadas sem conformidade com o benchmark CIS, endurecimento de segurança ou configuração de privilégio mínimo criam lacunas exploráveis nas estratégias de 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): explorar o aplicativo voltado para o público (T1190) aproveitando vulnerabilidades não corrigidas em contêineres de aplicação 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): fuga para o anfitrião (T1611) explorando vulnerabilidades de contêiner para romper o isolamento do contêiner e comprometer o sistema anfitrião.
  • Movimento Lateral (TA0008): exploração de serviços remotos (T1210) pivotando entre VMs vulneráveis ou contêineres implantados a partir de imagens comprometidas.

DS-6.1: implementar a segurança da imagem do 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 ciclo de vida. Imagens base vulneráveis propagam falhas para todas as instâncias implantadas, ampliando o impacto em toda a infraestrutura de TI. Tratar artefatos de carga de trabalho com o mesmo rigor de segurança que o código-fonte, incluindo verificação, assinatura e armazenamento seguro, garante que as organizações implantem apenas imagens verificadas e confiáveis, impedindo que os invasores explorem vulnerabilidades conhecidas ou substituam imagens mal-intencionadas.

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

  • Estabelecer princípios de infraestrutura imutáveis: Trate as imagens de contêiner e de VM como artefatos críticos, exigindo o mesmo rigor de segurança que se aplica ao código-fonte, pois imagens base vulneráveis podem propagar fraquezas para todas as instâncias implantadas. Estabeleça princípios de infraestrutura imutáveis em que artefatos de carga de trabalho são criados uma vez, verificados de forma abrangente, assinados criptograficamente e implantados sem modificação para garantir a consistência e a rastreabilidade durante todo o ciclo de vida.

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

  • Integrar a verificação automatizada com políticas de quarentena: Integre a verificação automatizada de vulnerabilidades no pipeline de construção de imagens, que inspeciona todas as imagens antes do armazenamento no registro, conferindo os bancos de dados CVE abrangentes e realizando a verificação contínua das imagens armazenadas à medida que novas vulnerabilidades são divulgadas. Implemente políticas de quarentena automatizadas que impedem 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 risco documentada. Estabeleça políticas de atualização de imagem base com gatilhos de pipeline automatizados quando os patches de segurança são liberados, garantindo que as imagens não acumulem CVEs ao longo do tempo.

  • Imponha a assinatura e a verificação criptográficas: Garanta a integridade das imagens por meio da assinatura e verificação criptográficas em todas as etapas — assine as imagens no momento da criação, verifique as assinaturas antes da implantação, e rejeite automaticamente imagens não assinadas ou adulteradas. Isso impede ataques de substituição de imagem em que os adversários substituem imagens legítimas por versões comprometidas que contêm backdoors. Armazene imagens em registros de contêiner protegidos 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/baixar imagens e log de auditoria abrangente de todas as operações dos registros.

  • Manter imagens golden endurecidas para VMs: Para cargas de trabalho de VM, mantenha repositórios centralizados de imagens golden com imagens base endurecidas que sejam compatíveis com a benchmark CIS, e que passem por atualizações regulares de segurança e validação de conformidade. Implemente pipelines de construção de imagens automatizadas que incorporam atualizações de segurança, removem serviços desnecessários, imponham configurações de menor privilégio e gerem novas imagens em agendas definidas em vez de fazer patch em sistemas em execução.

  • Aproveite as plataformas de segurança integradas: Soluções como o Registro de Contêiner do Azure com a integração do Microsoft Defender para Contêineres fornecem verificação automatizada, fluxos de trabalho de quarentena, confiança de conteúdo e replicação de várias regiões com políticas de segurança consistentes.

Exemplo de implementação

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

Desafio: Várias imagens de contêiner sem verificação de vulnerabilidade. Imagens criadas há meses acumularam muitos CVEs, incluindo vulnerabilidades críticas. Nenhuma verificação impediu a substituição de imagem mal-intencionada.

Abordagem da solução:

  • Segurança do registro de contêiner: Implementou o Registro de Contêiner do Azure com verificação de vulnerabilidades, colocando em quarentena as imagens com CVEs de alta gravidade antes da implantação.
  • Imagens de VM protegidas: Galeria de Imagens Compartilhadas do Azure implantada com imagens de VM compatíveis com as diretrizes do CIS para cargas de trabalho regulamentadas.
  • Proteção de tempo de execução: Configurou o Microsoft Defender para Contêineres para detecção contínua de ameaças e monitoramento de desvio.
  • Integridade do artefato: Assinatura e verificação criptográfica estabelecidas garantindo a autenticidade da imagem ao longo do ciclo de vida.

Resultado: Imagens vulneráveis bloqueadas antes da implantação em produção. Redução significativa dos CVEs de contêiner por imagem. Ataques de substituição de imagem impedidos por meio 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 o registro em log e o monitoramento do DevOps

Princípio de segurança

Implemente o log de atividades abrangentes do DevOps por meio do streaming de auditoria com integração às plataformas centralizadas de Gerenciamento de Eventos e Informações de Segurança (SIEM) para análise de segurança, detecção de ameaças em tempo real e resposta automatizada. Estabeleça análise comportamental, detecção de anomalias e métricas de segurança para habilitar a resposta rápida a incidentes e manter trilhas de auditoria de conformidade.

Risco a mitigar

O registro e monitoramento insuficientes do DevOps cria pontos cegos críticos que os adversários exploram para operar sem detecção, estabelecer persistência e exfiltrar código ou credenciais confidenciais. Sem visibilidade abrangente:

  • Comprometimentos de pipeline não detectados: Os invasores modificam pipelines de CI/CD para injetar código malicioso, exfiltrar segredos ou estabelecer backdoors sem disparar alertas devido à ausência ou insuficiência de registros de auditoria.
  • 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 detecção.
  • Falta de trilhas de auditoria abrangentes: A ausência de logs de atividades detalhados impede a investigação forense, a avaliação de impacto e a análise da causa raiz quando ocorrem incidentes de segurança, prolongando o tempo de detecção e aumentando o impacto da brecha.
  • Resposta de incidente atrasada: O MTTD (Tempo Médio de Detecção) se estende de horas a semanas em que as equipes de segurança não têm alertas em tempo real, detecção de anomalias e correlação automatizada de eventos de segurança de DevOps.
  • Falhas de 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 em log de acesso não podem ser atendidos sem monitoramento centralizado do DevOps.
  • Cegueira de escalonamento de privilégios: A elevação não autorizada de permissões, a criação de contas de backdoor ou a modificação dos controles de acesso não são detectadas sem análise comportamental e monitoramento de privilégios.

As lacunas de registro ocultam alterações mal-intencionadas em pipelines, escalada de privilégios e tentativas de acesso persistente em caminhos de desenvolvimento de alto privilégio.

MITRE ATT&CK

  • Evasão de Defesa (TA0005): prejudica as defesas (T1562) desabilitando o registro em log de auditoria, etapas de verificação de segurança ou agentes de monitoramento para operar em pontos cegos e remoção de indicadores (T1070) desmarcando logs de auditoria ou histórico de execução de pipeline para ocultar atividades mal-intencionadas.
  • Persistência (TA0003): manipulação de conta (T1098) criando entidades de serviço adicionais, tokens de acesso pessoal ou chaves SSH sem detecção.
  • Coleção (TA0009): dados de repositórios de informações (T1213) exfiltrando código-fonte, segredos ou propriedade intelectual por meio do acesso ao pipeline.
  • Acesso à Credencial (TA0006): credenciais não seguras (T1552) coletando segredos expostos de logs de pipeline ou histórico de execução.

DS-7.1: Implementar log de auditoria para plataformas DevOps

As plataformas DevOps com acesso privilegiado à infraestrutura de produção e ao código-fonte confidencial exigem um monitoramento de segurança abrangente para detectar a atividade adversária e ameaças internas. As lacunas de log de auditoria permitem que atores mal-intencionados operem sem serem detectados por longos períodos, enquanto a agregação de log centralizada permite a correlação com a telemetria de segurança mais ampla, revelando cadeias de ataque sofisticadas. 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 abrangente de segurança do DevOps por meio desses recursos:

  • Capturar atividades abrangentes relevantes à segurança: Estabeleça um log de auditoria abrangente que captura todas as atividades de DevOps relevantes à segurança: eventos de autenticação e autorização do usuário, confirmações de código-fonte e operações de branch, 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 DevOps têm acesso privilegiado à infraestrutura de produção e lacunas confidenciais de registro em log de código permitem que adversários e insiders mal-intencionados operem sem serem detectados por longos períodos.

  • Encaminhar logs para o 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), habilitando análise forense 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álises, análises e alertas automatizados sem revisão manual de log.

  • Implantar análise comportamental e detecção de anomalias: Implemente a análise comportamental e a detecção de anomalias nos dados de auditoria do 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, escalonamentos rápidos 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 podem indicar comprometimento ou ameaças internas.

  • Configurar alertas automatizados para atividades de alto risco: Configurar 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 branches protegidos, criação de novo principal 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 o escalonamento baseado em severidade, garantindo que os alertas críticos atinjam as operações de segurança imediatamente enquanto os eventos rotineiros são carregados em lote para análise.

  • Integre-se com telemetria de segurança de alcance mais amplo: Integre logs de auditoria do DevOps com telemetria de segurança de alcance mais amplo em plataformas SIEM para correlação com detecção de endpoint, segurança de rede, eventos de identidade e feeds de inteligência contra ameaças. Isso permite a detecção de cadeias de ataques sofisticados em que o comprometimento do DevOps é um estágio em operações multifásicas, por exemplo, correlacionando credenciais obtidas por phishing com modificações subsequentes no pipeline e provisionamento incomum de recursos na nuvem.

  • Aproveite as plataformas SIEM integradas: Plataformas como o Streaming de Auditoria do Azure DevOps com a integração do Microsoft Sentinel fornecem transmissão de registros em tempo real, regras de detecção pré-configuradas para ameaças de DevOps, pastas de trabalho de segurança para investigação e orquestração de respostas automatizadas.

Exemplo de implementação

Uma organização de fabricação descobriu uma ameaça interna quando o ex-empreiteiro modificou o pipeline de CI/CD injetando código backdoor no aplicativo de produção. O incidente permaneceu indetectado por meses devido ao registro em log de auditoria insuficiente.

Desafio: Nenhum registro em log centralizado de atividades de DevOps. As modificações no pipeline e as alterações de acesso privilegiado não foram monitoradas. Investigação forense dificultada pela falta de registros de auditoria. Falha na auditoria de conformidade devido ao controle de alterações insuficiente.

Abordagem da solução:

  • Registro em log de auditoria centralizado: Habilitado o envio de eventos de streaming de auditoria do Azure DevOps para Microsoft Sentinel para análise de segurança e retenção de longo prazo.
  • Análise comportamental: Detecção de anomalias implementada identificando padrões de acesso incomuns, modificações de pipeline após o expediente e escalonamentos de privilégios que indicam 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: Criou uma geração automatizada de trilha de auditoria que atende aos requisitos regulatórios, com controle abrangente de alterações.

Resultado: Detectou e impediu modificações de pipeline não autorizadas subsequentes rapidamente. Reduziu drasticamente o tempo de investigação de incidentes com trilhas de auditoria abrangentes. Conformidade obtida com o gerenciamento de alterações documentado.

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