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 de 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 dos testes por meio de cadência e verificação de várias perspectivas. Você deve incluir pontos de vista de dentro para fora que testam a plataforma e a infraestrutura e avaliações de fora para dentro que testam o sistema como um invasor externo.
Este guia fornece recomendações para testar a postura de segurança de sua 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
| Prazo | Definição |
|---|---|
| Teste de segurança de aplicativos (AST) | Uma técnica do SDL (Ciclo de Vida de Desenvolvimento de Segurança) da Microsoft que usa metodologias de teste de caixa branca e caixa preta para verificar 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 componentes internos do sistema. |
| Equipe azul | Uma equipe que se 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 hackear 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 à garantia de segurança e aos requisitos de conformidade. |
| Ciclo de vida de desenvolvimento de software (SDLC) | Um processo sistemático de vários estágios 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 inegociável, especialmente para segurança. Ele permite que você descubra e resolva problemas de segurança de forma proativa 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
Esta orientação faz uma distinção entre teste e resposta a incidentes. Embora o teste seja um mecanismo de detecção que, idealmente, 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 nas recomendações de Resposta a Incidentes.
O SDL inclui vários tipos de testes que detectam vulnerabilidades no código, verificam componentes de runtime e usam hacking ético para testar a resiliência de segurança do sistema. O SDL é uma atividade chave de shift left. Você deve executar testes como análise de código estático e verificação automatizada de infraestrutura como código (IaC) o mais cedo possível no processo de desenvolvimento.
Envolva-se no planejamento do 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 externos em segurança. 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 de acordo.
Execute testes de maneira estruturada e com um processo repetível. Construa seu rigor de teste em torno da cadência, tipos de testes, fatores determinantes 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 criar sua própria ferramenta pode apresentar 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.
Configure ambientes separados. Os testes podem ser classificados como destrutivos ou não destrutivos. Testes não destrutivos não são invasivos. Eles indicam que há um problema, mas não alteram a funcionalidade para corrigir o problema. Os testes destrutivos são invasivos e podem danificar a funcionalidade ao excluir dados de um banco de dados.
O teste em ambientes de produção fornece as melhores informações, mas causa mais interrupções. Você tende a fazer apenas testes não destrutivos em ambientes de produção. O teste em ambientes de não produção geralmente causa menos interrupções, mas pode 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 pode criar um clone isolado do ambiente de produção para teste. Se você tiver um processo contínuo para testes de rotina, recomendamos o uso de um ambiente dedicado.
Sempre avalie os resultados do teste. O teste é 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ê descobrir. A documentação que captura resultados e planos de correção educa a equipe sobre as várias maneiras pelas quais os invasores podem tentar violar a segurança. Realize treinamentos regulares de segurança 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 isso afeta seu ambiente?
Quais são os diferentes tipos de teste que você deve executar?
Teste a carga de trabalho regularmente
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 existem 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.
Exames 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 cadências diferentes, mas a chave é que eles são conduzidos periodicamente e de acordo com um cronograma.
Você deve integrar esses testes ao seu SDLC porque eles fornecem defesa em profundidade em cada estágio. Diversifique 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. Os testes de rotina ajudam a estabelecer uma referência 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 as definições de configuração que foram alteradas para detectar o impacto dessas alterações na segurança. Você deve melhorar a eficácia dos testes com automação, equilibrada com revisões por 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 apenas a experiência humana pode detectar. O teste manual é bom para casos de uso exploratórios e para encontrar riscos desconhecidos.
Testes improvisados
Os testes improvisados fornecem validação pontual das defesas de segurança. Os alertas de segurança que podem afetar a carga de trabalho naquele tempo 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 escalar 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 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 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 em relação à ameaça potencial.
Compensação: como os testes improvisados são eventos disruptivos, espere repriorizar as tarefas, o que pode atrasar outros trabalhos planejados.
Risco: Há 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. Você precisa avaliar esses riscos em relação aos benefícios.
Testes de incidentes de segurança
Existem 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 as lacunas existentes. A equipe deve aplicar as lições aprendidas com o incidente e incorporar melhorias rotineiramente.
Empregue uma variedade de testes
Os testes podem ser categorizados por tecnologia e por metodologias de teste. Combine essas categorias e abordagens dentro dessas categorias para obter cobertura completa.
Ao adicionar vários testes e tipos de testes, você pode descobrir:
Lacunas nos controles de segurança ou controles de compensação.
Configurações incorretas.
Lacunas nos métodos de observabilidade e detecção.
Um bom exercício de modelagem de ameaças pode apontar á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 da criptografia de dados e dos controles de acesso para garantir que os dados sejam devidamente protegidos contra acesso não autorizado e adulteração.
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 de aplicativos (AST) para garantir que você siga as práticas de codificação seguras e detecte erros de tempo de execução, como corrupção de memória e problemas de privilégio. Para obter detalhes, consulte estes links da comunidade.
Identidade: avalie se as atribuições de função e as verificações condicionais funcionam conforme o esperado.
Metodologia de teste
Existem muitas perspectivas sobre metodologias de teste. Recomendamos testes que habilitem a busca de ameaças simulando ataques do mundo real. Eles podem identificar possíveis agentes de ameaças, suas técnicas e suas explorações que representam uma ameaç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 por meio de ataques do mundo real:
Ao tornar esses ataques parte dos testes de rotina, você usa uma perspectiva 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 aprendidas, a equipe atualiza seu nível de conhecimento e habilidade. A equipe melhora a consciência situacional e pode autoavaliar sua prontidã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 jogos de guerra.
Teste de caixa preta e caixa branca
Esses tipos de teste oferecem duas perspectivas 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 ao código, logs, topologia de recursos e configurações para conduzir 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 aplicativos da organização realizam testes de penetração ou pentesting. Eles analisam o sistema da mesma forma que os agentes mal-intencionados analisam 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 engajamento 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 jogos de guerra
Nesta metodologia de ataques simulados, existem 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 projeto 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 remediar os ataques. Eles validam as defesas que foram implementadas para proteger os recursos de carga de trabalho.
Se forem conduzidos como testes de rotina, os exercícios de jogos de guerra podem fornecer visibilidade contínua e garantia de que suas defesas funcionem conforme projetado. Os exercícios de jogos de guerra podem ser testados em todos os níveis de suas cargas de trabalho.
Uma opção 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 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 nas fontes de dados e seus alertas, o Microsoft Sentinel cria incidentes e executa análises 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 os 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, consulte Recursos de busca no Microsoft Sentinel.
O Microsoft Defender para Nuvem 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 Nuvem.
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 integrada ao ritmo dos negócios da 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, consulte Habilitar DevSecOps com o Azure e o GitHub – Azure DevOps.
Links relacionados
Siga as regras de engajamento 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 negação de serviço (DoS) 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 de aplicativos: ferramentas, tipos e práticas recomendadas - GitHub Resources 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 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.
OWASP Top Ten | O OWASP Foundation fornece as melhores práticas 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.