Recomendações para testes de segurança
Aplica-se a esta recomendação de lista de verificação do Azure Well-Architected Framework Security:
| SE:11 | Estabeleça um regime de teste abrangente que combine abordagens para evitar problemas de segurança, validar implementações de prevenção contra ameaças e testar mecanismos de detecção de ameaças. |
|---|
Testes rigorosos são a base de um bom design de segurança. O teste é uma forma tática de validação para garantir que os controles estejam funcionando conforme o esperado. O teste também é uma maneira proativa de detectar vulnerabilidades no sistema.
Estabeleça o rigor de teste por meio da cadência e da verificação de várias perspectivas. Você deve incluir pontos de vista internos que testam a plataforma e a infraestrutura e avaliações externas que testam o sistema como um invasor externo.
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.
Definições
| Termo | Definição |
|---|---|
| Teste de segurança do aplicativo (AST) | Uma técnica do SDL (Security Development Lifecycle) da Microsoft que usa metodologias de teste de caixa branca e caixa preta para marcar para vulnerabilidades de segurança no código. |
| Teste de caixa preta | Uma metodologia de teste que valida o comportamento do aplicativo visível externamente sem conhecimento dos internos do sistema. |
| Equipe azul | Uma equipe que defende contra os ataques da equipe vermelha em um exercício de jogo de guerra. |
| Teste de penetração | Uma metodologia de teste que usa técnicas de hacking ético para validar as defesas de segurança de um sistema. |
| Equipe vermelha | Uma equipe que desempenha o papel de um adversário e tenta invadir o sistema em um exercício de jogo de guerra. |
| SDL (Security Development Lifecycle) | Um conjunto de práticas fornecidas pela Microsoft que dá suporte a requisitos de conformidade e garantia de segurança. |
| SDLC (ciclo de vida de desenvolvimento de software) | Um processo sistemático de várias fases para o desenvolvimento de sistemas de software. |
| Teste de caixa branca | Uma metodologia de teste em que a estrutura do código é conhecida pelo profissional. |
Principais estratégias de design
O teste é uma estratégia não acessível, especialmente para segurança. Ele permite que você descubra e resolva proativamente problemas de segurança antes que eles possam ser explorados e verifique se os controles de segurança implementados estão funcionando conforme projetado.
O escopo do teste deve incluir o aplicativo, a infraestrutura e os processos automatizados e humanos.
Observação
Essas diretrizes fazem uma distinção entre teste e resposta a incidentes. Embora o teste seja um mecanismo de detecção que corrige problemas antes da produção, ele não deve ser confundido com a correção ou investigação feita como parte da resposta a incidentes. O aspecto da recuperação de incidentes de segurança é descrito em Recomendações de Resposta a Incidentes.
O SDL inclui vários tipos de testes que capturam vulnerabilidades no código, verificam componentes de runtime e usam hacking ético para testar a resiliência de segurança do sistema. SDL é uma atividade de deslocamento chave para a esquerda. Você deve executar testes como análise de código estático e verificação automatizada de IaC (infraestrutura como código) o mais cedo possível no processo de desenvolvimento.
Esteja envolvido no planejamento de teste. A equipe de carga de trabalho pode não projetar os casos de teste. Essa tarefa geralmente é centralizada na empresa ou concluída por especialistas em segurança externos. A equipe de carga de trabalho deve estar envolvida nesse processo de design para garantir que as garantias de segurança se integrem à funcionalidade do aplicativo.
Pense como um invasor. Projete seus casos de teste com a suposição de que o sistema foi atacado. Dessa forma, você pode descobrir as possíveis vulnerabilidades e priorizar os testes adequadamente.
Execute testes de maneira estruturada e com um processo repetível. Crie seu rigor de teste em torno da cadência, tipos de testes, fatores de condução e resultados pretendidos.
Use a ferramenta certa para o trabalho. Use ferramentas configuradas para trabalhar com a carga de trabalho. Se você não tiver uma ferramenta, compre a ferramenta. Não construa. As ferramentas de segurança são altamente especializadas e a criação de sua própria ferramenta pode introduzir riscos. Aproveite a experiência e as ferramentas oferecidas pelas equipes centrais de SecOps ou por meios externos se a equipe de carga de trabalho não tiver essa experiência.
Configurar ambientes separados. Os testes podem ser classificados como destrutivos ou não estruturativos. Testes não estruturativos não são invasivos. Eles indicam que há um problema, mas não alteram a funcionalidade para corrigir o problema. Testes destrutivos são invasivos e podem danificar a funcionalidade excluindo dados de um banco de dados.
O teste em ambientes de produção fornece as melhores informações, mas causa a maior interrupção. Você tende a fazer apenas testes não estruturativos em ambientes de produção. Os testes em ambientes de não produção normalmente são menos disruptivos, mas podem não representar com precisão a configuração do ambiente de produção de maneiras importantes para a segurança.
Se você implantar usando IaC e automação, considere se você pode criar um clone isolado do seu ambiente de produção para teste. Se você tiver um processo contínuo para testes de rotina, recomendamos usar um ambiente dedicado.
Sempre avalie os resultados do teste. O teste será um esforço desperdiçado se os resultados não forem usados para priorizar ações e fazer melhorias upstream. Documente as diretrizes de segurança, incluindo as práticas recomendadas, que você descobre. A documentação que captura os resultados e os planos de correção instrui a equipe sobre as várias maneiras pelas quais os invasores podem tentar violar a segurança. Realize treinamento de segurança regular para desenvolvedores, administradores e testadores.
Ao projetar seus planos de teste, pense nas seguintes perguntas:
Com que frequência você espera que o teste seja executado e como ele afeta seu ambiente?
Quais são os diferentes tipos de teste que você deve executar?
Com que frequência você espera que os testes sejam executados?
Teste a carga de trabalho regularmente para garantir que as alterações não introduzam riscos de segurança e que não haja regressões. A equipe também deve estar pronta para responder às validações de segurança organizacional que podem ser realizadas a qualquer momento. Também há testes que você pode executar em resposta a um incidente de segurança. As seções a seguir fornecem recomendações sobre a frequência dos testes.
Testes de rotina
Os testes de rotina são realizados em uma cadência regular, como parte de seus procedimentos operacionais padrão e para atender aos requisitos de conformidade. Vários testes podem ser executados em diferentes cadências, mas a chave é que eles são realizados periodicamente e em um agendamento.
Você deve integrar esses testes ao SDLC porque eles fornecem defesa em profundidade em cada estágio. Diversificar o conjunto de testes para verificar garantias de identidade, armazenamento e transmissão de dados e canais de comunicação. Realize os mesmos testes em diferentes pontos do ciclo de vida para garantir que não haja regressões. Testes de rotina ajudam a estabelecer um parâmetro de comparação inicial. No entanto, isso é apenas um ponto de partida. À medida que você descobre novos problemas nos mesmos pontos do ciclo de vida, você adiciona novos casos de teste. Os testes também melhoram com a repetição.
Em cada estágio, esses testes devem validar o código adicionado ou removido ou definições de configuração que foram alteradas para detectar o impacto de segurança dessas alterações. Você deve melhorar a eficácia dos testes com automação, balanceada com revisões de pares.
Considere a execução de testes de segurança como parte de um pipeline automatizado ou execução de teste agendada. Quanto mais cedo você descobrir problemas de segurança, mais fácil será encontrar o código ou a alteração de configuração que os causa.
Não confie apenas em testes automatizados. Use testes manuais para detectar vulnerabilidades que somente a experiência humana pode detectar. O teste manual é bom para casos de uso exploratórios e para encontrar 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 escalonado para uma emergência.
O benefício dos testes improvisados é a preparação para um incidente real. Esses testes podem ser uma função forçada para fazer 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 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.
Compensação: como os testes improvisados são eventos disruptivos, espere rerioritizar tarefas, o que pode atrasar outros trabalhos planejados.
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. Você precisa avaliar esses riscos em relação aos benefícios.
Testes de incidentes de segurança
Há testes que detectam a causa de um incidente de segurança em sua origem. Essas lacunas de segurança devem ser resolvidas para garantir que o incidente não se repita.
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.
Quais são os diferentes tipos de testes?
Os testes podem ser categorizados por tecnologia e por metodologias de teste. Combine essas categorias e abordagens nessas categorias para obter cobertura completa.
Ao adicionar vários testes e tipos de testes, você pode descobrir:
Lacunas em controles de segurança ou controles de compensação.
Configurações.
Lacunas nos métodos de observabilidade e detecção.
Um bom exercício de modelagem de ameaças pode apontar para áreas-chave para garantir a cobertura e a frequência do teste. Para obter recomendações sobre modelagem de ameaças, consulte Recomendações para proteger um ciclo de vida de desenvolvimento.
A maioria dos testes descritos nestas seções pode ser executada como testes de rotina. No entanto, a repetibilidade pode incorrer em custos em alguns casos e causar interrupções. Considere essas compensações com cuidado.
Testes que validam a pilha de tecnologia
Aqui estão alguns exemplos de tipos de testes e suas áreas de foco. Essa lista não é completa. Teste toda a pilha, incluindo a pilha de aplicativos, front-end, back-end, APIs, bancos de dados e quaisquer integrações externas.
Segurança de dados: teste a eficácia dos controles de criptografia e acesso de dados para garantir que os dados estejam corretamente protegidos contra acesso e violação não autorizados.
Rede e conectividade: teste seus firewalls para garantir que eles permitam apenas o tráfego esperado, permitido e seguro para a carga de trabalho.
Aplicativo: teste o código-fonte por meio de técnicas de teste de segurança do aplicativo (AST) para garantir que você siga as práticas de codificação seguras e capture erros de runtime, como problemas de corrupção de memória e privilégios. Para obter detalhes, consulte esses links da comunidade.
Identidade: avalie se as atribuições de função e as verificações condicionais funcionam conforme o esperado.
Metodologia de teste
Há muitas perspectivas sobre metodologias de teste. Recomendamos testes que permitem a busca de ameaças simulando ataques do mundo real. Eles podem identificar potenciais atores de ameaça, suas técnicas e suas façanhas 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 marcar a carga de trabalho e garantir que a defesa possa resistir a um ataque.
Com base nas lições que aprendeu, a equipe atualiza seus conhecimentos e nível de habilidade. A equipe melhora a conscientização situacional e pode auto-avaliar sua preparação para responder a incidentes.
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 são visíveis. Em testes de caixa branca, o testador tem uma boa compreensão do aplicativo e até tem acesso a código, logs, topologia de recursos e configurações para realizar o experimento.
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 aplicativos da organização realizam 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.
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 usado incorretamente. 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, há duas equipes:
A equipe vermelha é o adversário que tenta modelar ataques do mundo real. Se eles forem bem-sucedidos, você encontrará lacunas em seu 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 foram implementadas para proteger os recursos de carga de trabalho.
Se forem realizados como testes de rotina, os exercícios de jogo de guerra podem fornecer visibilidade contínua e garantia de que suas defesas funcionam conforme projetado. Exercícios de jogo de guerra podem potencialmente testar entre níveis dentro de suas cargas de trabalho.
Uma opção popular para simular cenários de ataque realistas é o Microsoft Defender para Office 365 Treinamento de simulação de ataque.
Para obter mais informações, consulte Insights e relatórios para Treinamento de simulação de ataque.
Para obter informações sobre a configuração da equipe vermelha e da equipe azul, consulte 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 antecipada. Por meio de análises e consultas inteligentes, você pode buscar proativamente problemas de segurança. Se houver um incidente, você poderá automatizar fluxos de trabalho. Além disso, com modelos de pasta de trabalho, você pode obter insights rapidamente por meio da visualização.
Para obter a documentação do produto, confira Recursos de busca no Microsoft Sentinel.
Microsoft Defender for Cloud oferece verificação de vulnerabilidades para várias áreas de tecnologia. Para obter detalhes, consulte Habilitar a verificação de vulnerabilidades com Gerenciamento de Vulnerabilidades do Microsoft Defender – Microsoft Defender para Nuvem.
A prática do 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 no DevOps (DevSecOps).
O Azure DevOps dá suporte a ferramentas de terceiros que podem ser automatizadas como parte dos pipelines de integração contínua/implantação contínua. Para obter detalhes, confira Habilitar o DevSecOps com o Azure e o GitHub – Azure DevOps.
Links relacionados
Siga as regras de envolvimento para garantir que o acesso não seja mal utilizado. Para obter diretrizes sobre como planejar e executar ataques simulados, consulte os seguintes artigos:
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 as defesas de tempo de build e de runtime do aplicativo.
O PTES (Padrão de Execução de Teste de Penetração) oferece diretrizes sobre cenários comuns e atividades necessárias para estabelecer uma linha de base.
Top Ten 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.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de