Estratégias de arquitetura para testes de segurança

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

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

Estabelecer rigor nos testes através de uma cadência consistente e verificação sob múltiplas perspetivas. Inclua perspetivas de dentro para fora que testem a plataforma e infraestrutura e avaliações externas que testem o sistema como um atacante externo.

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

Terminology

Colaborar com especialistas em segurança para desenhar testes

Envolva-se no planeamento de testes. Muitas vezes, uma organização centraliza esta tarefa. Certifique-se de que a sua equipa está envolvida nesse processo de design para que as garantias de segurança estejam alinhadas com a funcionalidade da aplicação.

Constrói uma mentalidade de presumir e violar. Desenhe os seus casos de teste assumindo que o sistema está sob ataque e que o atacante está a operar dentro do ambiente. Simule os seus testes para refletir cenários realistas de ataque, como a validação da contenção de movimentos laterais dentro de uma VM de aplicação comprometida. Assim, pode descobrir potenciais vulnerabilidades e priorizar os testes em conformidade.

Partilhe os diagramas arquitetónicos, o modelo de ameaças e outra documentação relevante para testar a carga de trabalho de forma significativa.

Priorizar testes com base na modelação de ameaças e fluxos críticos

A modelação de ameaças é uma prática fundamental para identificar potenciais ameaças e vulnerabilidades na sua carga de trabalho. Use as classificações de gravidade do seu modelo de ameaça para priorizar e definir os seus esforços de teste. As ameaças de maior gravidade contra os seus fluxos mais críticos merecem a maior cobertura.

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

Comece pelos controlos de identidade e acesso, porque uma identidade comprometida contorna a maioria das defesas a jusante. Depois validar os limites da rede e, finalmente, as defesas da camada de aplicação.

Priorize fluxos que tratem de autenticação, dados sensíveis ou transações financeiras. Para cada fluxo crítico, identifique as ameaças com a maior classificação de gravidade no seu modelo de ameaça. Crie casos de teste orientados pelo risco que mapeem cada ameaça ao controlo pretendido para a mitigar.

Um bom exercício de modelação de ameaças aponta para áreas-chave para a cobertura e frequência dos testes. 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 mal orientados. Atualize regularmente o seu modelo de ameaças para refletir as mudanças na carga de trabalho e o panorama de ameaças em evolução.

Aproveite a experiência de terceiros

As equipas internas podem ter pontos cegos. Especialistas externos e investigadores colaborativos veem a sua carga de trabalho da mesma forma que um atacante. Envolva especialistas especializados para testar a sua carga de trabalho a partir da perspetiva do adversário e fornecer informações sobre as técnicas e tendências de ataque mais recentes.

Evite conceder acesso demasiado permissivo à sua carga de trabalho. Dê aos testadores externos apenas o acesso que o seu envolvimento específico exige. Um teste de penetração de caixa-preta não requer código nem acesso interno, enquanto uma análise de caixa-branca requer código-fonte, documentação de conceção ou registos.

Avalie se a sua equipa tem capacidade para triar relatórios externos antes de lançar um programa. Depois, estabeleça um programa de recompensa por bugs ou um mecanismo para a comunidade reportar problemas de segurança. Triagem de todas as descobertas reportadas, devolve as vulnerabilidades confirmadas ao seu modelo de ameaça e adiciona um caso de teste para detetar qualquer regressão.

Testar os controlos de conformidade e gerar provas prontas para auditoria

A conformidade não é uma revisão única. Trate cada controlo regulatório como um requisito testável para ter sempre provas frescas para os auditores.

Identifique os regulamentos que a sua carga de trabalho deve cumprir. Mapeie cada controlo 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 do teste num local auditável para que possa produzir provas a pedido.

Compromisso: Testes para controlos regulatórios podem abrandar as operações. Por exemplo, os testes pré-implementação adicionam latência ao pipeline. Há também um custo adicional para a gestão dessas operações. Dê prioridade aos testes dos controlos com maior impacto de auditoria e de risco.

Risco: A evidência de auditoria é, em si mesma, sensível. Sem proteção de integridade e registo de acessos, o armazenamento de provas torna-se simultaneamente um alvo de ataque e uma potencial violação de conformidade.

Proteger os ativos de teste

Os ativos de teste são eles próprios uma superfície de ataque. Proteja a sua confidencialidade, integridade e disponibilidade para que os seus testes não exponham informações sensíveis nem abram novos vetores de ataque.

• Utilize dados higienizados ou sintéticos que não contenham qualquer informação pessoal identificável (PII) ou dados de produção.
• Retenha os dados de teste apenas o tempo necessário e elimine-os de forma segura.
• Confirme que as regras de residência de dados transfronteiriços são aplicadas em ambientes de teste que abrangem regiões.
• Gerar credenciais de teste dedicadas, chaves API e certificados. Guarde-as numa instância separada do cofre de chaves com as suas próprias políticas de acesso.
• Configure ambientes de teste isolados que espelhem os controlos de segurança em produção, como grupos de segurança de rede (NSGs), políticas de controlo de acesso baseado em funções (RBAC), firewall e regras de prevenção de perda de dados (DLP). Aplique as mesmas orientações de segmentação da produção. Para mais informações, consulte Recomendações para estratégia de segmentação.

Realizar análises regulares de vulnerabilidades nos ativos de teste

Analise ativos de teste para vulnerabilidades na mesma cadência que ativos de produção, incluindo código de teste, infraestrutura como código (IaC), imagens de contentores e VMs, repositórios e pipelines. Use ferramentas que se integrem com os seus fluxos de trabalho de desenvolvimento e implementação para automatizar estas verificações.

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

Trate os testes de segurança como uma atividade contínua que mantém a postura de segurança da carga de trabalho atualizada à medida que ameaças, código e configurações evoluem. Execute testes num calendário para que as alterações não introduzam riscos de segurança ou regressões. Esteja preparado para validações de segurança organizacionais que podem acontecer a qualquer momento e para testes desencadeados por um incidente de segurança. As secções seguintes descrevem as cadências a considerar no planeamento.

Exames de rotina

Os testes de rotina estabelecem a referência de base para o nível de segurança da sua carga de trabalho. Realize-as com um ritmo regular, como parte dos seus procedimentos operacionais padrão e para cumprir os requisitos de conformidade. Podes fazer vários testes em cadências diferentes, mas o importante é que os realizes periodicamente e com um calendário.

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

Não confie apenas em testes automáticos. Use testes manuais para encontrar vulnerabilidades que só a perícia humana pode detetar e para trabalhos exploratórios em riscos desconhecidos.

Testes improvisados

Os testes improvisados fornecem uma validação pontual das defesas de segurança. Os alertas de segurança que podem afetar a carga de trabalho naquele momento acionam 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 escalar para uma emergência.

O benefício dos testes improvisados é a preparação para um incidente real. Esses testes podem servir como um mecanismo para promover a realização de testes 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 da carga de trabalho, você precisa facilitar e colaborar com as equipes de segurança. Negocie tempo de espera suficiente com as equipes de segurança para que você possa se preparar. Reconheça e comunique à sua equipe e às partes interessadas que essas interrupções são necessárias.

Em outros casos, pode ser necessário executar testes e relatar o estado de segurança do sistema contra a ameaça potencial.

Contrapartida: Como os testes improvisados são eventos perturbadores, conte com a necessidade de repriorizar tarefas, o que pode atrasar outro trabalho planeado.

Risco: Existe o risco do desconhecido. Testes improvisados podem ser esforços únicos sem processos ou ferramentas estabelecidas. Mas o risco predominante é a potencial 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 detetem a causa de um incidente de segurança na sua origem. Resolva estas falhas de segurança para evitar que o incidente volte a acontecer.

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 os controlos de segurança em toda a superfície de ataque

Utilize uma variedade de metodologias de teste para obter cobertura completa e descobrir lacunas nos controlos de segurança, configurações incorretas e fraquezas na observabilidade e deteção. A maioria dos testes descritos nesta secção pode ser executada como testes de rotina. No entanto, a repetibilidade pode gerar custos e causar perturbações. Considere essas compensações cuidadosamente.

Testa os controlos de encriptação. Falhas de encriptação são silenciosas. Os dados parecem protegidos até que uma violação revele o contrário.

• Valida que a encriptação é imposta, não apenas configurada.
• Volte a testar após cada rotação de chaves, renovação de certificados e alteração de infraestrutura.

Testar os controlos da rede. Os limites de rede são onde a segmentação é aplicada.

• Teste-as após qualquer alteração da topologia da rede.
• Verifica se as regras de negação por defeito são válidas e que os caminhos de tráfego permitidos correspondem à intenção da tua arquitetura.

Testar o código da aplicação. As defesas da camada de aplicação são o último limite antes de um atacante chegar aos dados.

• Valide que as aplicações implementadas resistem a padrões comuns de ataque em vez de apenas analisar o código-fonte durante a compilação.
• Execute técnicas de teste de segurança de aplicações (AST) no código-fonte para confirmar práticas de codificação segura e detetar erros em tempo de execução, como corrupção de memória e questões de privilégios. Para mais detalhes, consulte Links da Comunidade.

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

Os ataques baseados em identidade são o vetor de ataque inicial mais comum. Simule estes ataques para validar que os seus controlos de identidade funcionam e que a sua monitorização capta os eventos.

Os controlos de acesso são a primeira linha de defesa. Teste-os após cada mudança de função ou política e num horário automatizado. Simule padrões de ataque comuns e confirme que os seus controlos aplicam o privilégio mínimo e resistem a tentativas de contornar esses controlos.

Considere estes padrões de ataque ao desenhar testes:

• Desvio de autorização
• Roubo e reutilização de tokens
• Movimentação lateral entre contas ou serviços
• Escalada de privilégios

Valide ambos os lados de cada controlo:

• Casos positivos: utilizadores autorizados têm sucesso.
• Casos negativos: tentativas não autorizadas são bloqueadas e registadas.

Teste a deteção e a emissão de alertas de ameaças

A deteção que não aciona um alerta tem pouco valor. Teste a sua monitorização e alertas como parte de cada validação de controlos de segurança, e verifique se os mecanismos concebidos para detetar ataques funcionam como esperado.

Execute as simulações de ponta a ponta dos ataques e, em seguida, confirme cada etapa da cadeia de deteção:

• Valide que eventos de segurança, como tentativas de iniciação de sessão, alterações de permissões e operações de token, sejam registados com detalhe suficiente.
• Verifique se a sua plataforma de gestão de informação e eventos de segurança (SIEM) ou o painel de operações de segurança correlaciona eventos relacionados.
• Estabeleça um acordo de nível de serviço (SLA) de alerta e teste se os alertas são acionáveis e surgem dentro desse prazo.
• Verifique se os registos não podem ser adulterados ou eliminados por contas não administrativas.
• Confirme que o mecanismo de deteção para cada ataque simulado é acionado. Por exemplo, se simular um ataque de negação de serviço distribuído (DDoS) com padrões de tráfego válidos, confirme que limitar a taxa o deteta e mitiga.

Para cargas de trabalho maduras, valide os limites de governação como testes de rotina. Introduza intencionalmente configurações inseguras e verifique se o pipeline deteta e responde. Confirme que a Azure Policy ou as restrições da zona de aterragem aplicam as proteções esperadas. Normalmente é a equipa da plataforma ou de segurança que realiza estes testes, não a equipa de carga de trabalho.

Reforçar as defesas com testes baseados em adversários

Use testes que permitam a caça de ameaças simulando ataques do mundo real. Estes testes podem identificar potenciais agentes de ameaça, as suas técnicas e os seus exploits que representam uma ameaça para a carga de trabalho. Torne os ataques o mais realistas possível. Use todos os vetores de ameaças potenciais 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 dos testes de rotina, você usa uma perspetiva de fora para dentro para verificar a carga de trabalho e garantir que a defesa possa resistir a um ataque.
• Com base nas lições que aprendem, a equipa melhora o seu conhecimento e nível de competência. A equipa melhora a consciência situacional e pode autoavaliar a sua prontidão para responder a incidentes.

Risco: Os testes em geral podem afetar o desempenho. Testes destrutivos podem apagar ou corromper dados e causar problemas de continuidade de negócios. Existem também riscos associados à exposição à informação. Mantenha a confidencialidade dos dados. Garanta a integridade dos dados depois de concluir os testes.

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

Testes de caixa preta e caixa branca

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

Risco: A diferença entre os dois tipos é o custo inicial. Os testes de caixa branca podem ser caros em termos de tempo necessário para entender o sistema. Em alguns casos, o teste de caixa branca requer 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 eficaz quanto outros métodos. Poderá ter de fazer um esforço extra para descobrir problemas. É uma troca de investimento de tempo.

Testes que simulam ataques através de testes de penetração

Os especialistas em segurança que não pertencem às equipas de TI ou de aplicações da organização realizam testes de penetração ou pentesting. Eles olham para o sistema da mesma forma que agentes maliciosos avaliam 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 caros em termos de interrupções e investimento monetário, porque o pentesting é normalmente uma oferta paga por profissionais terceirizados.

Risco: um exercício de pentesting pode afetar o ambiente de execução e pode interromper a disponibilidade para o tráfego normal.

Os profissionais podem precisar de acesso a dados confidenciais em toda a organização. Siga as regras de engajamento para garantir que o acesso não seja usado indevidamente. Consulte os recursos listados em Links relacionados.

Testes que simulam ataques através de exercícios de jogos de guerra

Nesta metodologia de ataques simulados, participam duas equipas:

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

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

Se realizar estes testes rotineiramente, os exercícios de guerra podem proporcionar visibilidade contínua e garantia de que as suas defesas funcionam conforme projetado. Os exercícios de simulação de guerra podem potencialmente avaliar vários níveis dentro dos seus processos de carga de trabalho.

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

Para obter mais informações, consulte Perspetivas e relatórios sobre formação em simulação de ataques.

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

Gestão do Azure

O Microsoft Sentinel é um controle nativo que combina recursos de gerenciamento de eventos de informações de segurança (SIEM) 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 realiza análises de ameaças para deteção precoce. Através de análises e consultas inteligentes, pode procurar proativamente problemas de segurança. Se houver um incidente, você pode automatizar fluxos de trabalho. Além disso, ao usar modelos de cadernos de exercícios, pode obter rapidamente insights através da visualização.

Para obter a documentação do produto, consulte Funcionalidades de pesquisa no Microsoft Sentinel.

O Microsoft Defender para a Cloud oferece verificação de vulnerabilidades 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 a Cloud.

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

O Azure DevOps suporta ferramentas de terceiros que pode automatizar como parte dos pipelines de integração contínua/implementação contínua. Para obter detalhes, consulte Habilitar DevSecOps com Azure e GitHub - Azure DevOps.

Ligações relacionadas

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

• Regras de Acordo para Testes de Penetração

• Testes de penetração

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

Ligações da comunidade

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

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

OWASP Top dez | A OWASP Foundation fornece práticas recomendadas de segurança para aplicativos e casos de teste que cobrem ameaças comuns.

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.