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 é 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

O teste é uma estratégia inegociá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.

O SDL inclui vários tipos de testes que capturam vulnerabilidades no código, verificam componentes de runtime e usam o hacking ético para testar a resiliência de segurança do sistema. O SDL é uma atividade de deslocamento de chave para a esquerda. Você deve executar testes como análise de código estático e verificação automatizada da 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 externa. 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. Crie 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 crie isso. 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 do 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. O teste em ambientes de não produção normalmente é menos disruptivo, 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 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?

Testar 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 há testes que podem ser executados 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 cadências diferentes, mas a chave é que eles são realizados periodicamente e em um agendamento.

Você deve integrar esses testes ao SDLC porque eles fornecem defesa detalhada 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. 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 as configurações que foram alteradas para detectar o impacto na segurança dessas alterações. Você deve melhorar a eficácia dos testes com a automação, balanceada com revisões par.

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 dependa apenas de testes automatizados. Use testes manuais para detectar vulnerabilidades que somente a experiência humana pode capturar. O teste manual é bom para casos de uso exploratório 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 escalado 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 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 de interrupção, 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 seja repetido.

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 meio de metodologias de teste. Combine essas categorias e abordagens nessas categorias para obter cobertura completa.

Adicionando vários testes e tipos de testes, você pode descobrir:

• Lacunas em controles de segurança ou controles compensadores.

• Configurações incorretas.

• Lacunas nos métodos de observação 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. Esta não é uma lista 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 estejam devidamente protegidos contra acesso e adulteraçã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 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 aprenderam, 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. Pode haver problemas de continuidade de negócios se testes destrutivos excluirem ou corrompê-los. Também há riscos associados à exposição de informações; certifique-se de manter 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 ramp-up, mas pode não ser tão eficaz. 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 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.

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 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, há duas equipes:

• A equipe vermelha é o adversário que tenta modelar ataques do mundo real. Se elas forem bem-sucedidas, 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 foram implementadas para proteger os recursos de carga de trabalho.

Se eles 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 como projetadas. Exercícios de jogo de guerra podem potencialmente testar em todos os 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 para treinamento de 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, com modelos de pasta de trabalho, você pode obter insights rapidamente 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).

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 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 participação de teste 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.