Recomendações para testes de segurança
Aplica-se a esta recomendação da 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 deteção de ameaças. |
|---|
Testes rigorosos são a base de um bom design de segurança. Os testes são uma forma tática de validação para garantir que os controlos estão a funcionar conforme pretendido. Os testes também são uma forma proativa de detetar vulnerabilidades no sistema.
Estabeleça o rigor de teste através da cadência e verificação de múltiplas perspetivas. Deve incluir pontos de vista internos que testam a plataforma e a infraestrutura e avaliações externas que testam o sistema como um atacante externo.
Este guia fornece recomendações para testar a postura de segurança da sua carga de trabalho. Implemente estes métodos de teste para melhorar a resistência da carga de trabalho a ataques e manter a confidencialidade, integridade e disponibilidade dos recursos.
Definições
| Termo | Definição |
|---|---|
| Testes de segurança de aplicações (AST) | Uma técnica de Ciclo de Vida de Desenvolvimento de Segurança (SDL) da Microsoft que utiliza metodologias de teste de caixa branca e caixa preta para verificar a existência de vulnerabilidades de segurança no código. |
| Teste de caixa preta | Uma metodologia de teste que valida o comportamento da aplicação visível externamente sem ter conhecimento dos internos do sistema. |
| Equipa azul | Uma equipa que 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 éticas de hacking para validar as defesas de segurança de um sistema. |
| Equipa vermelha | Uma equipa que desempenha o papel de um adversário e tenta invadir o sistema num 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 suporta requisitos de segurança e conformidade. |
| Ciclo de vida de desenvolvimento de software (SDLC) | Um processo sistemático e multifator para o desenvolvimento de sistemas de software. |
| Teste de caixa branca | Uma metodologia de teste em que a estrutura do código é conhecida pelo praticante. |
Principais estratégias de conceção
Os testes são uma estratégia não negociável, especialmente para a segurança. Permite-lhe detetar e resolver proativamente problemas de segurança antes de poderem ser explorados e verificar se os controlos de segurança que implementou estão a funcionar conforme concebido.
O âmbito dos testes tem de incluir a aplicação, a infraestrutura e os processos automatizados e humanos.
Nota
Esta orientação faz uma distinção entre teste e resposta a incidentes. Embora o teste seja um mecanismo de deteção que, idealmente, corrige problemas antes da produção, não deve ser confundido com a remediação ou investigação que é feita como parte da resposta a incidentes. O aspeto da recuperação de incidentes de segurança está 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 runtime e utilizam hacking ético para testar a resiliência de segurança do sistema. O SDL é uma atividade chave shift-left. Deve executar testes como a análise de código estático e a análise automatizada da infraestrutura como código (IaC) o mais cedo possível no processo de desenvolvimento.
Participe no planeamento de testes. A equipa de carga de trabalho pode não criar os casos de teste. Essa tarefa é, muitas vezes, centralizada na empresa ou concluída por peritos de segurança externos. A equipa de carga de trabalho deve estar envolvida nesse processo de conceção para garantir que as garantias de segurança se integram com a funcionalidade da aplicação.
Pense como um atacante. Crie os seus casos de teste com o pressuposto de que o sistema foi atacado. Dessa forma, pode descobrir as potenciais vulnerabilidades e priorizar os testes em conformidade.
Executar testes de forma estruturada e com um processo repetível. Crie o rigor de teste em torno da cadência, dos tipos de testes, dos fatores de condução e dos resultados pretendidos.
Utilize a ferramenta certa para a tarefa. Utilize ferramentas configuradas para trabalhar com a carga de trabalho. Se não tiver uma ferramenta, compre a ferramenta. Não o crie. As ferramentas de segurança são altamente especializadas e a criação da sua própria ferramenta pode apresentar riscos. Tire partido dos conhecimentos e ferramentas oferecidos pelas equipas centrais do SecOps ou por meios externos se a equipa 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. Indicam que existe um problema, mas não alteram a funcionalidade para remediar o problema. Os testes destrutivos são invasivos e podem danificar a funcionalidade ao eliminar dados de uma base de dados.
Os testes em ambientes de produção dão-lhe as melhores informações, mas causam mais interrupções. Tende a fazer apenas testes não estruturativos em ambientes de produção. Os testes em ambientes de não produção são normalmente menos disruptivos, mas podem não representar com precisão a configuração do ambiente de produção de formas importantes para a segurança.
Se implementar com IaC e automatização, considere se pode criar um clone isolado do seu ambiente de produção para teste. Se tiver um processo contínuo para testes de rotina, recomendamos que utilize um ambiente dedicado.
Avalie sempre os resultados do teste. Os testes são um esforço desperdiçado se os resultados não forem utilizados para priorizar ações e fazer melhorias a montante. Documente as diretrizes de segurança, incluindo as melhores práticas, que descobrir. A documentação que captura resultados e planos de remediação informa a equipa sobre as várias formas como os atacantes podem tentar violar a segurança. Realize formação de segurança regular para programadores, administradores e técnicos de teste.
Quando estruturar os seus planos de teste, pense nas seguintes perguntas:
Com que frequência espera que o teste seja executado e como é que afeta o seu ambiente?
Quais são os diferentes tipos de teste que deve executar?
Com que frequência espera que os testes são executados?
Teste a carga de trabalho regularmente para garantir que as alterações não introduzem riscos de segurança e que não existem regressões. A equipa também tem de estar pronta para responder a validações de segurança organizacional que possam ser realizadas em qualquer altura. Também existem testes que pode executar em resposta a um incidente de segurança. As secções seguintes fornecem recomendações sobre a frequência dos testes.
Testes de rotina
Os testes de rotina são realizados numa cadência regular, como parte dos seus procedimentos operacionais padrão e para cumprir os requisitos de conformidade. Vários testes podem ser executados em cadências diferentes, mas a chave é que são realizados periodicamente e com base numa agenda.
Deve integrar estes testes no SDLC porque fornecem defesa em profundidade em cada fase. Diversificar 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 existem regressões. Os testes de rotina ajudam a estabelecer uma referência inicial. No entanto, este é apenas um ponto de partida. À medida que revela novos problemas nos mesmos pontos do ciclo de vida, adiciona novos casos de teste. Os testes também melhoram com a repetição.
Em cada fase, estes testes devem validar o código adicionado ou removido ou as definições de configuração que foram alteradas para detetar o impacto de segurança dessas alterações. Deve melhorar a eficácia dos testes com a automatização, equilibrada com as revisões ponto a ponto.
Considere executar testes de segurança como parte de um pipeline automatizado ou de uma execução de teste agendada. Quanto mais cedo detetar 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. Utilize testes manuais para detetar vulnerabilidades que apenas os conhecimentos humanos podem detetar. Os testes manuais servem para casos de utilização exploratórios e para encontrar riscos desconhecidos.
Testes improvisados
Os testes improvisados fornecem uma validação para um ponto anterior no tempo das defesas de segurança. Os alertas de segurança que podem afetar a carga de trabalho nessa altura acionam estes 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. Estes testes podem ser uma função que força a realizar testes de aceitação de utilizadores (UAT).
A equipa de segurança pode auditar todas as cargas de trabalho e executar estes testes conforme necessário. Como proprietário da carga de trabalho, tem de facilitar e colaborar com equipas de segurança. Negoceie tempo suficiente com as equipas de segurança para que possa preparar-se. Confirme e comunique à sua equipa e aos intervenientes que estas interrupções são necessárias.
Noutros casos, poderá ser necessário executar testes e comunicar o estado de segurança do sistema contra a potencial ameaça.
Troca: uma vez que os testes improvisados são eventos disruptivos, espere reriorizar tarefas, o que pode atrasar outros trabalhos planeados.
Risco: existe o risco do desconhecido. Os testes improvisados podem ser esforços únicos sem processos ou ferramentas estabelecidos. Mas o risco predominante é a potencial interrupção do ritmo do negócio. Tem de 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 respetiva origem. Estas falhas de segurança têm de ser resolvidas para garantir que o incidente não se repete.
Os incidentes também melhoram os casos de teste ao longo do tempo ao descobrir lacunas existentes. A equipa deve aplicar as lições aprendidas com o incidente e incorporar rotineiramente melhoramentos.
Quais são os diferentes tipos de testes?
Os testes podem ser categorizados pela tecnologia e pelas metodologias de teste. Combine essas categorias e abordagens nessas categorias para obter cobertura completa.
Ao adicionar vários testes e tipos de testes, pode descobrir:
Lacunas nos controlos de segurança ou controlos de compensação.
Configurações incorretas.
Lacunas nos métodos de observabilidade e deteção.
Um bom exercício de modelação de ameaças pode apontar para áreas-chave para garantir a cobertura e a frequência dos testes. Para obter recomendações sobre modelação de ameaças, veja Recomendações para proteger um ciclo de vida de desenvolvimento.
A maioria dos testes descritos nestas secções pode ser executada como testes de rotina. No entanto, a repetibilidade pode incorrer em custos em alguns casos e causar interrupções. Considere estas trocas cuidadosamente.
Testes que validam a pilha de tecnologia
Seguem-se alguns exemplos de tipos de testes e as respetivas áreas de concentração. Esta lista não é exaustiva. Teste toda a pilha, incluindo a pilha de aplicações, front-end, back-end, APIs, bases de dados e quaisquer integrações externas.
Segurança de dados: teste a eficácia da encriptação de dados e dos controlos de acesso para garantir que os dados estão devidamente protegidos contra acesso e adulteração não autorizados.
Rede e conectividade: teste as firewalls para garantir que apenas permitem tráfego esperado, permitido e seguro para a carga de trabalho.
Aplicação: teste o código fonte através de técnicas de teste de segurança de aplicações (AST) para se certificar de que segue práticas de codificação seguras e detetar erros de tempo de execução, como danos na memória e problemas de privilégios. Para obter detalhes, veja estas ligações da comunidade.
Identidade: avalie se as atribuições de funções e as verificações condicionais funcionam conforme pretendido.
Metodologia de teste
Existem muitas perspetivas sobre metodologias de teste. Recomendamos testes que permitam a investigação de ameaças simulando ataques do mundo real. Podem identificar potenciais atores de ameaças, as suas técnicas e as suas façanhas que representam uma ameaça para a carga de trabalho. Torne os ataques o mais realistas possível. Utilize todos os vetores de ameaças potenciais que identificar durante a modelação de ameaças.
Eis algumas vantagens dos testes através de ataques do mundo real:
Quando faz destes ataques uma parte dos testes de rotina, utiliza uma perspetiva externa para verificar a carga de trabalho e certificar-se de que a defesa consegue resistir a um ataque.
Com base nas lições que aprenderam, a equipa atualiza os seus conhecimentos e nível de competência. A equipa melhora a consciencialização sobre a situação e pode autoavaliá-lo 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 de caixa branca
Estes tipos de teste oferecem duas perspetivas diferentes. Nos testes de caixa preta, os internos do sistema não são visíveis. Nos testes de caixa branca, o testador tem uma boa compreensão da aplicação e até tem acesso a código, registos, topologia de recursos e configurações para realizar a experimentação.
Testes que simulam ataques através de testes de penetração
Especialistas em segurança que não fazem parte das equipas de TI ou aplicações da organização realizam testes de penetração ou pentesting. Olham para o sistema da forma como os actores maliciosos aprovisionam uma superfície de ataque. O objetivo é encontrar lacunas de segurança ao recolher informações, analisar vulnerabilidades e comunicar os resultados.
Os profissionais podem precisar de acesso a dados confidenciais em toda a organização. Siga as regras de compromisso para garantir que o acesso não é utilizado indevidamente. Veja os recursos listados em Ligações relacionadas.
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 está a tentar modelar ataques do mundo real. Se forem bem-sucedidos, encontrará lacunas na estrutura de segurança e avalia a contenção do raio de explosão das respetivas falhas.
A equipa azul é a equipa de carga de trabalho que se defende contra os ataques. Testam a capacidade de detetar, responder e remediar os ataques. Validam as defesas que foram implementadas para proteger os recursos da carga de trabalho.
Se forem realizados como testes de rotina, os exercícios de jogos de guerra podem fornecer visibilidade e garantia contínuas de que as suas defesas funcionam como concebidas. Os exercícios de jogos de guerra podem potencialmente testar entre níveis nas suas cargas de trabalho.
Uma escolha popular para simular cenários de ataque realistas é o Microsoft Defender para Office 365 Formação em simulação de ataques.
Para obter mais informações, veja Informações e relatórios para Formação em simulação de ataques.
Para obter informações sobre a configuração da equipa vermelha e da equipa azul, consulte Agrupamento Vermelho do Microsoft Cloud.
Facilitação do Azure
O Microsoft Sentinel é um controlo nativo que combina a gestão de eventos de informações de segurança (SIEM) e as capacidades de resposta automatizada de orquestração de segurança (SOAR). Analisa eventos e registos de várias origens ligadas. Com base nas origens de dados e nos respetivos 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 existir um incidente, pode automatizar fluxos de trabalho. Além disso, com os modelos de livros, pode obter rapidamente informações através da visualização.
Para obter a documentação do produto, veja Capacidades de investigação no Microsoft Sentinel.
Microsoft Defender para a Cloud oferece análise de vulnerabilidades para várias áreas de tecnologia. Para obter detalhes, veja Ativar a análise de vulnerabilidades com Gestão de vulnerabilidades do Microsoft Defender - Microsoft Defender para a Cloud.
A prática do DevSecOps integra os 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 no ritmo dos negócios na Microsoft. Para obter mais informações, veja Segurança no DevOps (DevSecOps).
O Azure DevOps suporta ferramentas de terceiros que podem ser automatizadas como parte dos pipelines de integração contínua/implementação contínua. Para obter detalhes, veja Enable DevSecOps with Azure and GitHub - Azure DevOps (Ativar o DevSecOps com o Azure e o GitHub – Azure DevOps).
Ligações relacionadas
Siga as regras de cativação para garantir que o acesso não é utilizado indevidamente. Para obter orientações sobre como planear e executar ataques simulados, veja os seguintes artigos:
Pode simular ataques denial of service (DoS) no Azure. Certifique-se de que segue as políticas definidas nos testes de simulação do Azure DDoS Protection.
Ligações da comunidade
Testes de segurança de aplicações: ferramentas, tipos e melhores práticas – o GitHub Resources descreve os tipos de metodologias de teste que podem testar as defesas de tempo de compilação e runtime da aplicação.
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.
Dez Principais Dez OWASP | O OWASP Foundation fornece melhores práticas de segurança para aplicações e casos de teste que abrangem ameaças comuns.
Lista de verificação de segurança
Veja o conjunto completo de recomendações.
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários