Recomendações para testes de segurança
Aplica-se a esta recomendação de lista de verificação de segurança do Azure Well-Architected Framework:
| 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 deteçã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 como pretendido. O teste também é uma maneira proativa de detetar vulnerabilidades no sistema.
Estabelecer rigor de teste através de cadência e verificação a partir de múltiplas perspetivas. Você deve incluir pontos de vista de dentro para fora que testam plataforma e 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 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.
Definições
| Vigência | Definição |
|---|---|
| Testes de segurança de aplicativos (AST) | Uma técnica de SDL (Security Development Lifecycle da Microsoft) que usa metodologias de teste de caixa branca e caixa preta para verificar vulnerabilidades de segurança no código. |
| Testes de caixa preta | Uma metodologia de teste que valida o comportamento do aplicativo visível externamente sem conhecimento dos internos do sistema. |
| Equipa azul | Uma equipa que se defende contra os ataques da equipa vermelha num exercício de jogo de guerra. |
| Testes de penetração | Uma metodologia de teste que utiliza técnicas de hacking ético para validar as defesas de segurança de um sistema. |
| Equipa vermelha | Uma equipe que desempenha o papel de um adversário e tenta hackear o sistema em um exercício de jogo de guerra. |
| Ciclo de Vida de Desenvolvimento Centrado na Segurança (CVDCS) | Um conjunto de práticas fornecidas pela Microsoft que oferece suporte a requisitos de garantia de segurança e conformidade. |
| Ciclo de vida de desenvolvimento de software (SDLC) | Um processo sistemático e em várias etapas para o desenvolvimento de sistemas de software. |
| Teste de caixa branca | Uma metodologia de teste onde a estrutura do código é conhecida pelo profissional. |
Principais estratégias de design
Testar é uma estratégia inegociável, especialmente para a 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 âmbito dos ensaios deve incluir a aplicação, a infraestrutura e os processos automatizados e humanos.
Nota
Estas orientações estabelecem uma distinção entre testes e resposta a incidentes. Embora o teste seja um mecanismo de deteçã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 aspeto 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 detetam vulnerabilidades no código, verificam componentes de tempo de execução 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 varredura automatizada de infraestrutura como código (IaC) o mais cedo possível no processo de desenvolvimento.
Envolva-se no planeamento de testes. 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 atacante. Projete seus casos de teste com a suposição de que o sistema foi atacado. Dessa forma, você pode descobrir as vulnerabilidades potenciais e priorizar os testes de acordo.
Execute testes de forma estruturada e com um processo repetível. Construa 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 a construa. As ferramentas de segurança são altamente especializadas, e construir 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 ensaios podem ser classificados como destrutivos ou não destrutivos. Os testes não destrutivos não são invasivos. Eles indicam que há um problema, mas não alteram a funcionalidade para remediar o problema. Os testes destrutivos são invasivos e podem danificar a funcionalidade ao excluir dados de um banco de dados.
Os testes em ambientes de produção fornecem as melhores informações, mas causam mais interrupções. Você tende a fazer apenas testes não destrutivos em ambientes de produção. Os testes em ambientes que não são de produção geralmente causam menos interrupções, 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 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 o uso de um ambiente dedicado.
Avalie sempre os resultados dos testes. Os testes são um esforço desperdiçado se os resultados não forem usados para priorizar ações e fazer melhorias a montante. Documente as diretrizes de segurança, incluindo as práticas recomendadas, que você descobrir. A documentação que captura os resultados e os 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 ele 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. Há também testes que você pode executar em resposta a um incidente de segurança. As secções seguintes 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 diferentes cadências, mas a chave é que eles são realizados periodicamente e em um cronograma.
Você deve integrar esses testes em seu SDLC porque eles fornecem defesa em profundidade em cada estágio. Diversifique o conjunto de testes para verificar as 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 alteradas para detetar 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 de uma 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 detetar vulnerabilidades que apenas a perícia humana pode detetar. O teste manual é bom para casos de uso exploratórios e para encontrar riscos desconhecidos.
Testes improvisados
Testes improvisados fornecem validação point-in-time de 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 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 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.
Compensação: Como os testes improvisados são eventos disruptivos, espere repriorizar 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 detetam a causa de um incidente de segurança na sua origem. Essas falhas 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.
Empregar 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 uma cobertura completa.
Ao adicionar vários testes e tipos de testes, você pode descobrir:
Lacunas nos controlos de segurança ou nos controlos de compensação.
Erros de configuração.
Lacunas na observabilidade e nos métodos de deteção.
Um bom exercício de modelagem de ameaças pode apontar para áreas-chave para garantir a cobertura e a frequência dos testes. 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 perturbações. Considere essas compensações cuidadosamente.
Testes que validam a pilha de tecnologia
Aqui estão alguns exemplos de tipos de testes e suas áreas de foco. Esta lista não é exaustiva. 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 estejam devidamente protegidos contra acesso não autorizado e adulteração.
Rede e conectividade: teste seus firewalls para garantir que eles permitam apenas 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 aplicativo (AST) para garantir que você siga práticas de codificação segura e para detetar 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 como pretendido.
Metodologia de ensaio
Existem muitas perspetivas sobre metodologias de teste. Recomendamos testes que permitam a caça a ameaças simulando ataques do mundo real. Eles podem identificar potenciais agentes de ameaça, 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 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 aprendidas, a equipe atualiza seus conhecimentos e nível de habilidade. A equipa melhora a consciência situacional e pode autoavaliar a 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.
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.
Testes que simulam ataques através de testes de penetração
Os 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 mesma forma que os agentes mal-intencionados ampliam 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 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, existem duas equipas:
A equipa 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 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 foram implementadas para proteger os recursos da 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 funcionam como projetado. Os exercícios de jogos de guerra podem ser testados em todos os níveis dentro de suas cargas 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 Insights e relatórios para treinamento de simulação de ataque.
Para obter informações sobre a configuração de equipe vermelha e equipe azul, consulte Microsoft Cloud Red Teaming.
Facilitaçã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, com modelos de pasta de trabalho, você pode obter informações rapidamente por meio da visualização.
Para obter a documentação do produto, consulte Recursos de caça no Microsoft Sentinel.
O 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 o Gerenciamento de Vulnerabilidades do Microsoft Defender - Microsoft Defender for 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 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 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:
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.