Estratégias de arquitetura para testes de segurança

Aplica-se a esta recomendação de lista de verificação do Azure Well-Architected Framework Security:

Testes rigorosos são a base de um bom design de segurança. O teste também é uma maneira proativa de detectar vulnerabilidades no sistema.

Estabeleça a rigorosidade do teste por meio da cadência e da verificação a partir de múltiplas perspectivas. Inclua perspectivas de dentro para fora que testam a plataforma e a infraestrutura e avaliações de fora para dentro que testam o sistema como se fosse um invasor externo.

As principais estratégias neste artigo baseiam-se nas práticas de teste fundamentais descritas nas estratégias de arquitetura OE:09 para teste. Examine esse artigo primeiro. Este guia fornece recomendações para testar a postura de segurança da carga de trabalho. Implemente esses métodos de teste para melhorar a resistência da carga de trabalho a ataques e manter a confidencialidade, a integridade e a disponibilidade dos recursos.

Terminologia

Colaborar com especialistas em segurança para criar testes

Esteja envolvido no planejamento de teste. Geralmente, uma organização centraliza essa tarefa. Verifique se sua equipe está envolvida nesse processo de design para que as garantias de segurança se alinhem com a funcionalidade do aplicativo.

Adote uma mentalidade de presumir violação. Projete seus casos de teste com a suposição de que o sistema está sob ataque e que o invasor está operando dentro do ambiente. Simule seus testes para refletir cenários de ataque realistas, como a validação da contenção de movimento lateral dentro de uma VM de aplicativo comprometida. Dessa forma, você pode descobrir possíveis vulnerabilidades e priorizar os testes adequadamente.

Compartilhe os diagramas de arquitetura, o modelo de ameaça e outra documentação relevante para testar a carga de trabalho significativamente.

Priorizar testes com base na modelagem de ameaças e fluxos críticos

A modelagem de ameaças é uma prática fundamental para identificar possíveis ameaças e vulnerabilidades em sua carga de trabalho. Use as classificações de severidade do seu modelo de ameaça para priorizar e definir o escopo dos esforços de teste. As ameaças de severidade mais altas contra seus fluxos mais críticos merecem a maior cobertura.

Cubra toda a superfície de ataque da carga de trabalho. Avalie identidade, código do aplicativo, controles de infraestrutura, componentes de terceiros, bibliotecas e serviços e os processos automatizados e humanos, como fluxos de trabalho de aprovação e revisões de acesso.

Comece com controles de identidade e acesso porque uma identidade comprometida ignora a maioria das defesas downstream. Em seguida, valide os limites de rede e, por fim, as defesas de camada de aplicativo.

Priorize fluxos que lidam com autenticação, dados confidenciais ou transações financeiras. Para cada fluxo crítico, identifique as ameaças com a classificação de severidade mais alta em seu modelo de ameaça. Crie casos de teste controlados por risco que mapeiem cada ameaça para o controle destinado a atenuá-la.

Um bom exercício de modelagem de ameaças aponta para áreas-chave para cobertura e frequência de teste. Para obter recomendações sobre modelagem de ameaças, consulte Recomendações para proteger um ciclo de vida de desenvolvimento.

Risco: modelos de ameaça obsoletos podem levar a esforços de teste desalinhados. Atualize regularmente seu modelo de ameaça para refletir as alterações na carga de trabalho e no cenário de ameaças em evolução.

Aproveitar a experiência de terceiros

As equipes internas podem ter pontos cegos. Especialistas externos e pesquisadores colaborativos veem sua carga de trabalho da mesma forma que um invasor. Traga especialistas especializados para testar sua carga de trabalho da perspectiva de um adversário e fornecer insights sobre as técnicas e tendências de ataque mais recentes.

Evite conceder acesso excessivamente permissivo à sua carga de trabalho. Dê aos testadores externos apenas o acesso necessário para seu envolvimento específico. Um teste de penetração de caixa preta não precisa de código ou acesso interno, enquanto uma revisão de caixa branca precisa de código-fonte, documentos de design ou logs.

Avalie se sua equipe tem a capacidade de fazer triagem de relatórios externos antes de iniciar um programa. Em seguida, estabeleça um programa de recompensa de bugs ou um mecanismo para a comunidade relatar problemas de segurança. Faça a triagem de cada achado relatado, retroalimente seu modelo de ameaças com as vulnerabilidades confirmadas e adicione um caso de teste para detectar qualquer regressão.

Testar controles de conformidade e gerar evidências prontas para auditoria

A conformidade não é uma revisão única. Trate cada controle regulatório como um requisito testável para que você sempre tenha novas evidências para auditores.

Identifique os regulamentos que sua carga de trabalho deve satisfazer. Mapeie cada controle regulatório para um caso de teste específico. Agende os testes para serem executados periodicamente e antes de cada entrada em produção. Armazene a saída de teste em um local auditável para que você possa produzir evidências sob demanda.

Trade-off: Os testes para controles regulatórios podem desacelerar as operações. Por exemplo, testes de pré-implementação aumentam a latência do pipeline. Há também um custo adicional de execução dessas operações. Priorize os testes para controles com o maior impacto de auditoria e risco.

Risco: a evidência de auditoria é sensível. Sem a proteção de integridade e o registro em log de acesso, o repositório de evidências se torna um alvo de ataque e uma possível violação de conformidade.

Proteger ativos de teste

Os ativos de teste constituem uma superfície de ataque. Proteja sua confidencialidade, integridade e disponibilidade para que seus testes não exponham informações confidenciais ou abram novos vetores de ataque.

• Use dados sanitizados ou sintéticos que não contêm informações de identificação pessoal (PII) ou dados de produção.
• Retenha os dados de teste apenas o tempo necessário e exclua-os com segurança.
• Confirme se as regras de residência de dados transfronteiriços são impostas em ambientes de teste que abrangem regiões.
• Gere credenciais de teste dedicadas, chaves de API e certificados. Armazene-os em uma instância separada do cofre de chaves com suas próprias políticas de acesso.
• Configure ambientes de teste isolados que espelham controles de segurança de produção, como NSGs (grupos de segurança de rede), políticas de RBAC (controle de acesso baseado em função), firewall e regras de prevenção contra perda de dados (DLP). Aplique as mesmas diretrizes de segmentação que a produção. Para obter mais informações, consulte Recomendações para estratégia de segmentação.

Realizar verificações de vulnerabilidade regulares em ativos de teste

Examine os ativos de teste em busca de vulnerabilidades na mesma cadência que os ativos de produção, incluindo código de teste, iac (infraestrutura como código), imagens de contêiner e VM, repositórios e pipelines. Use ferramentas que se integram aos fluxos de trabalho de desenvolvimento e implantação para automatizar essas verificações.

Estabelecer um ritmo de teste contínuo para a carga de trabalho

Trate o teste de segurança como uma atividade contínua que mantém a postura de segurança da carga de trabalho atual como ameaças, código e configurações evoluem. Execute testes em um agendamento para que as alterações não introduzam riscos ou regressões de segurança. Esteja pronto para validações de segurança organizacional que podem acontecer a qualquer momento e para testes disparados por um incidente de segurança. As seções a seguir descrevem as cadências para as quais planejar.

Testes de rotina

Testes de rotina estabelecem a base de referência para a postura de segurança da sua carga de trabalho. Conduza-os em uma cadência regular, como parte de seus procedimentos operacionais padrão e para atender aos requisitos de conformidade. Você pode executar vários testes em intervalos diferentes, mas o importante é realizá-los periodicamente e de acordo com um cronograma.

Diversifique o conjunto de testes para verificar garantias de identidade, armazenamento e transmissão de dados e canais de comunicação. À medida que você descobre novos problemas nos mesmos pontos do ciclo de vida, adicione novos casos de teste.

Não confie apenas em testes automatizados. Use testes manuais para encontrar vulnerabilidades que somente a experiência humana pode capturar e para um trabalho exploratório sobre riscos desconhecidos.

Testes improvisados

Testes improvisados fornecem validação pontual de defesas de segurança. Alertas de segurança que podem afetar a carga de trabalho nesse momento disparam esses testes. Os mandatos organizacionais podem exigir uma mentalidade de pausa e teste para verificar a eficácia das estratégias de defesa se o alerta for escalado para uma emergência.

O benefício dos testes improvisados é a preparação para um incidente real. Esses testes podem ser um mecanismo de indução para realizar o teste de aceitação do usuário (UAT).

A equipe de segurança pode auditar todas as cargas de trabalho e executar esses testes conforme necessário. Como proprietário de uma carga de trabalho, você precisa facilitar e colaborar com as equipes de segurança. Negocie tempo de entrega suficiente com as equipes de segurança para que você possa se preparar. Reconheça e comunique à sua equipe e aos stakeholders que essas interrupções são necessárias.

Em outros casos, você pode ser obrigado a executar testes e relatar o estado de segurança do sistema contra a ameaça potencial.

Desvantagem: Como os testes improvisados são eventos disruptivos, espere ter de repriorizar tarefas, o que pode atrasar outras atividades planejadas.

Risco: Há risco do desconhecido. Testes improvisados podem ser esforços únicos sem processos ou ferramentas estabelecidos. Mas o risco predominante é a possível interrupção do ritmo dos negócios. Avalie esses riscos em relação aos benefícios.

Testes de incidentes de segurança

Use testes que detectam a causa de um incidente de segurança em sua origem. Resolva essas lacunas de segurança para evitar que o incidente seja recorrente.

Os incidentes também melhoram os casos de teste ao longo do tempo, descobrindo lacunas existentes. A equipe deve aplicar as lições aprendidas com o incidente e incorporar melhorias rotineiramente.

Validar controles de segurança na superfície de ataque

Use uma variedade de metodologias de teste para obter cobertura completa e descobrir lacunas em controles de segurança, configurações incorretas e fraquezas na observabilidade e detecção. A maioria dos testes descritos nesta seção pode ser executada como testes de rotina. No entanto, a repetibilidade pode incorrer em custos e causar interrupções. Considere essas compensações com cuidado.

Testar controles de criptografia. Falhas de criptografia são silenciosas. Os dados parecem protegidos até que uma violação revele o contrário.

• Valide se a criptografia é imposta, não apenas configurada.
• Teste novamente após cada rotação de chaves, renovação de certificado e alteração de infraestrutura.

Testar controles de rede. Os limites de rede são onde a segmentação é imposta.

• Teste-os após qualquer alteração de topologia de rede.
• Verifique se as regras de bloqueio por padrão estão em vigor e se os caminhos de tráfego permitidos correspondem ao que foi definido na sua arquitetura.

Testar o código do aplicativo. As defesas de camada de aplicativo são o último limite antes que um invasor atinja os dados.

• Valide se os aplicativos implantados resistem a padrões de ataque comuns em vez de apenas verificar o código-fonte no tempo de build.
• Execute técnicas de teste de segurança de aplicativo (AST) no código-fonte para confirmar práticas de codificação seguras e capturar erros de runtime, como problemas de corrupção de memória e privilégios. Para obter detalhes, consulte links da comunidade.

Simular ataques baseados em identidade e verificar a detecção

Ataques baseados em identidade são o vetor de ataque inicial mais comum. Simule esses ataques para validar se os controles de identidade funcionam e que o monitoramento captura os eventos.

Os controles de acesso são a primeira linha de defesa. Teste-os após cada alteração de função ou política e em um agendamento automatizado. Simule padrões de ataque comuns e confirme se seus controles impõem privilégios mínimos e resistem a tentativas de bypass.

Considere esses padrões de ataque ao projetar testes:

• Bypass de autorização
• Roubo e reutilização de token
• Movimentação lateral entre contas ou serviços
• Escalonamento de privilégios

Valide ambos os lados de cada controle:

• Casos positivos: usuários autorizados têm êxito.
• Casos negativos: tentativas não autorizadas são bloqueadas e registradas.

Testar detecção e alertas de ameaças

A detecção que não dispara um alerta fornece pouco valor. Teste seu monitoramento e alertas como parte de cada validação de controle de segurança e verifique se os mecanismos projetados para detectar ataques funcionam conforme o esperado.

Execute simulações de ponta a ponta dos ataques e confirme cada estágio do pipeline de detecção:

• Valide se eventos de segurança, como tentativas de entrada, alterações de permissão e operações de token, são registrados com detalhes suficientes.
• Verifique se a plataforma siem (gerenciamento de eventos e informações de segurança) ou o painel de operações de segurança correlaciona eventos relacionados.
• Estabeleça um SLA (contrato de nível de serviço) de alerta e teste se os alertas são acionáveis e são exibidos dentro desse período.
• Verifique se os logs não podem ser adulterados ou excluídos por contas não administrativas.
• Confirme se o mecanismo de detecção de cada ataque simulado é acionado. Por exemplo, se você simular um ataque de negação de serviço distribuído (DDoS) com padrões de tráfego válidos, confirme se a limitação de taxa de requisições o detecta e o mitiga.

Para cargas de trabalho maduras, valide os controles de governança por meio de testes de rotina. Introduza configurações inseguras intencionalmente e verifique se o pipeline detecta e responde. Confirme se Azure Policy ou restrições de zona de destino impõem as proteções esperadas. A plataforma ou a equipe de segurança normalmente executa esse teste, não a equipe de carga de trabalho.

Fortalecer as defesas com testes baseados em adversários

Use testes que permitem a busca de ameaças simulando ataques do mundo real. Esses testes podem identificar potenciais atores de ameaça, suas técnicas e suas explorações que representam uma ameaça para a carga de trabalho. Torne os ataques o mais realistas possível. Use todos os possíveis vetores de ameaça que você identificar durante a modelagem de ameaças.

Aqui estão algumas vantagens de testar através de ataques do mundo real:

• Quando você faz desses ataques uma parte do teste de rotina, você usa uma perspectiva externa para verificar a carga de trabalho e garantir que a defesa possa suportar um ataque.
• Com base nas lições que aprendem, a equipe atualiza seu conhecimento e nível de habilidade. A equipe melhora a conscientização situacional e pode avaliar sua prontidão para responder a incidentes.

Risco: o teste em geral pode afetar o desempenho. Testes destrutivos podem excluir ou corromper dados e causar problemas de continuidade dos negócios. Também há riscos associados à exposição de informações. Mantenha a confidencialidade dos dados. Verifique a integridade dos dados após concluir o teste.

Alguns exemplos de testes simulados incluem testes de caixa preta e caixa branca, testes de penetração e exercícios de jogo de guerra.

Teste de caixa preta e caixa branca

Esses tipos de teste oferecem duas perspectivas diferentes. Em testes de caixa preta, os internos do sistema não estão visíveis. Em testes de caixa branca, o testador tem uma boa compreensão do aplicativo e até tem acesso ao código, logs, topologia de recursos e configurações para conduzir o experimento.

Risco: a diferença entre os dois tipos é o custo inicial. O teste em caixa branca pode ser caro em termos de tempo necessário para entender o sistema. Em alguns casos, o teste em caixa branca exige que você compre ferramentas especializadas. O teste de caixa preta não precisa de tempo de preparação, mas pode não ser tão efetivo. Talvez seja necessário fazer um esforço extra para descobrir problemas. É uma compensação de investimento temporal.

Testes que simulam ataques por meio de testes de penetração

Especialistas em segurança que não fazem parte das equipes de TI ou de aplicações da organização executam testes de penetração ou pentesting. Eles olham para o sistema da maneira como atores mal-intencionados miram uma superfície de ataque. Seu objetivo é encontrar lacunas de segurança coletando informações, analisando vulnerabilidades e relatando os resultados.

Compensação: os testes de penetração são improvisados e podem ser dispendiosos em termos de interrupções e investimento monetário, porque o teste de penetração é normalmente uma oferta paga realizada por profissionais terceirizados.

Risco: um exercício de teste de penetração pode afetar o ambiente de runtime e pode interromper a disponibilidade do tráfego normal.

Os profissionais podem precisar de acesso a dados confidenciais em toda a organização. Siga as regras de participação para garantir que o acesso não seja mal utilizado. Consulte os recursos listados em links relacionados.

Testes que simulam ataques por meio de exercícios de jogo de guerra

Nesta metodologia de ataques simulados, duas equipes participam:

• A equipe vermelha atua como o adversário e tenta modelar ataques do mundo real. Se eles forem bem-sucedidos, você encontrará lacunas no design de segurança e avaliará a contenção do raio de explosão de suas violações.

• A equipe azul é a equipe de carga de trabalho que se defende contra os ataques. Eles testam sua capacidade de detectar, responder e corrigir os ataques. Eles validam as defesas que protegem os recursos de carga de trabalho.

Se você realizar esses testes rotineiramente, os exercícios de jogo de guerra poderão fornecer visibilidade contínua e garantia de que suas defesas funcionam conforme projetado. Exercícios de guerra simulados têm o potencial de testar nos diferentes níveis dentro de suas cargas de trabalho.

Uma opção popular para simular cenários de ataque realista é o treinamento de simulação de ataque do Microsoft Defender para Office 365.

Para obter mais informações, consulte Insights e relatórios sobre simulação de ataque.

Para obter informações sobre a configuração da equipe vermelha e da equipe azul, consulte o Microsoft Cloud Red Teaming.

Facilitação do Azure

O Microsoft Sentinel é um controle nativo que combina recursos de SIEM (gerenciamento de eventos de informações de segurança) e SOAR (resposta automatizada de orquestração de segurança). Ele analisa eventos e logs de várias fontes conectadas. Com base em fontes de dados e seus alertas, o Microsoft Sentinel cria incidentes e executa a análise de ameaças para detecção precoce. Por meio de análises e consultas inteligentes, você pode procurar proativamente problemas de segurança. Se houver um incidente, você poderá automatizar fluxos de trabalho. Além disso, usando modelos de pasta de trabalho, você pode rapidamente obter insights por meio da visualização.

Para obter a documentação do produto, consulte os recursos de busca no Microsoft Sentinel.

O Microsoft Defender para Nuvem oferece verificação de vulnerabilidade para várias áreas de tecnologia. Para obter detalhes, consulte Habilitar a verificação de vulnerabilidades com o Gerenciamento de Vulnerabilidades do Microsoft Defender – Microsoft Defender para Nuvem.

A prática de DevSecOps integra o teste de segurança como parte de uma mentalidade de melhoria contínua e contínua. Exercícios de jogo de guerra são uma prática comum integrada ao ritmo dos negócios na Microsoft. Para obter mais informações, consulte Segurança em DevOps (DevSecOps).

Azure DevOps dá suporte a ferramentas de terceiros que você pode automatizar como parte dos pipelines de integração contínua/implantação contínua. Para obter detalhes, consulte Habilitar DevSecOps com o Azure e o GitHub – Azure DevOps.

Links relacionados

Siga as regras de participação para garantir que o acesso não seja usado incorretamente. Para obter diretrizes sobre como planejar e executar ataques simulados, consulte os seguintes artigos:

• Regras de Engajamento para Testes de Penetração

• Teste de penetração

Você pode simular ataques de DoS (negação de serviço) no Azure. Siga as políticas estabelecidas no teste de simulação da Proteção contra DDoS do Azure.

Links da comunidade

Teste de segurança do aplicativo: ferramentas, tipos e práticas recomendadas – o GitHub Resources descreve os tipos de metodologias de teste que podem testar o tempo de build e as defesas de tempo de execução do aplicativo.

O PTES (Padrão de Execução de Teste de Penetração) fornece diretrizes sobre cenários comuns e as atividades necessárias para estabelecer uma linha de base.

Top 10 do OWASP | O OWASP Foundation fornece práticas recomendadas de segurança para aplicativos e casos de teste que abrangem ameaças comuns.

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.