Recomendações para testes de segurança
Aplica-se a esta recomendação da lista de verificação de segurança bem arquitetada: Power Platform
| SE:09 | Estabeleça um regime de testes abrangente que combine abordagens para prevenir 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 forma proativa de detectar vulnerabilidades no sistema.
Estabeleça rigor de teste por meio de cadência e verificação de múltiplas 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 de sua carga de trabalho a ataques e manter a confidencialidade, a integridade e a disponibilidade de recursos.
Definições
| Termo | Definição |
|---|---|
| AST (Teste de segurança do aplicativo) | Uma técnica de ciclo de vida de desenvolvimento de segurança (SDL) que usa metodologias de teste de caixa branca e caixa preta para verificar vulnerabilidades de segurança no código. Microsoft |
| Teste de caixa preta | Uma metodologia de teste que valida o comportamento do aplicativo visível externamente sem o conhecimento dos aspectos internos do sistema. |
| Equipe azul | Um time que se defende dos ataques do time vermelho em um exercício de jogo de guerra. |
| Testes 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. |
| Security Development Lifecycle (SDL) | Um conjunto de práticas fornecidas por Microsoft que oferecem suporte à garantia de segurança e aos requisitos de conformidade. |
| Ciclo de vida de desenvolvimento de software (SDLC) | Um processo sistemático e de várias etapas para o desenvolvimento de sistemas de software. |
| Teste de caixa branca | Uma metodologia de teste na qual a estrutura do código é conhecida pelo praticante. |
Estratégias-chave de design
O teste é uma estratégia inegociável, principalmente por 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
Essa 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 em Recomendações para resposta a incidentes de segurança.
Envolva-se no planejamento 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 certificar-se de 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 forma estruturada e com um processo repetitivo. 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 tem uma ferramenta, compre-a. Não crie-a. 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.
Configurar ambientes separados. Os ensaios podem ser classificados em 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 corrigir o problema. Os 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 mais interrupções. Você tende a fazer apenas ensaios 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.
Você pode criar um clone isolado do ambiente de produção usando o recurso de cópia do ambiente. Se você tiver pipelines de implantação configurados, também poderá implantar suas soluções em um ambiente de teste 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 melhores práticas, que você descobrir. A documentação que captura resultados e planos de correção instrui 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 criar 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?
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 apresentem 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 fazem 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 o importante é que eles sejam 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 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 um parâmetro de comparação. No entanto, esse é apenas um ponto de partida. À medida que 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 que foi adicionado ou removido ou as definições de configuração que foram alteradas para detectar o impacto na segurança dessas alterações. Você deve melhorar a eficácia dos testes com automação, balanceada com revisões por pares.
Execute 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 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
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 disparam esses testes. As determinações 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: o risco do desconhecido de There. 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. É preciso 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 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 classificados 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:
- Falhas nos controles de segurança ou controles de compensação.
- Configurações incorretas.
- Falhas 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 vantagens e desvantagens cuidadosamente.
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 não autorizado e adulteração.
- Rede e conectividade: teste seus firewalls para garantir que eles permitam apenas tráfego esperado, autorizado e seguro para a carga de trabalho.
- Aplicação: 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 seguras e para detectar erros de tempo de execução, como corrupção de memória e problemas de privilégio.
- 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 as metodologias de teste. Recomendamos testes que permitem a busca de ameaças, simulando ataques do mundo real. Eles podem identificar potenciais 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ê identifica 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 de 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 aprimora 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.
Testes de caixa preta e caixa branca
Esses tipos de teste oferecem duas perspectivas diferentes. Nos testes de caixa preta, os elementos internos do sistema não ficam visíveis. Em testes de caixa branca, o testador tem um bom entendimento do aplicativo e ainda 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 maneira como os atores mal-intencionados alcançam uma superfície de ataque. Seu objetivo é encontrar lacunas de segurança coletando informações, analisando vulnerabilidades e relatando os resultados.
Os profissionais talvez precisem acessar dados confidenciais em toda a organização. Siga as regras de compromisso para garantir que o acesso não seja usado indevidamente. Veja os recursos listados em Informações relacionadas.
Testes que simulam ataques através de exercícios de jogos de guerra
Nessa 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 da carga de trabalho que se defende dos ataques. Eles testam sua capacidade de detectar, 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, conforme projetado. Exercícios de jogos de guerra podem potencialmente testar todos os níveis dentro de suas cargas de trabalho.
Uma escolha 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 Power Platform
Microsoft A solução Sentinel permite que os clientes detectem diversas atividades suspeitas, como: Microsoft Power Platform
- Execução do Power Apps em geografias não autorizadas
- Destruição de dados suspeitos por Power Apps
- Exclusão em massa do Power Apps
- Ataques de phishing feitos por meio do Power Apps
- Atividade de fluxos do Power Automate por funcionários de saída
- Conectores do Microsoft Power Platform adicionados a um ambiente
- Atualização ou remoção das políticas de prevenção contra perdas de dados do Microsoft Power Platform
Para obter mais informações, consulte Microsoft Visão geral da solução Sentinel Microsoft Power Platform .
Para obter a documentação do produto, consulte Recursos de caça no Microsoft Sentinel.
Microsoft O Defender for Cloud oferece varredura de vulnerabilidades para diversas áreas de tecnologia. Para obter mais informações, consulte Habilitar verificação de vulnerabilidades com o Microsoft Defender Vulnerability Management.
A prática do DevSecOps integra testes de segurança como parte de uma mentalidade de melhoria em andamento e contínua. Exercícios de jogos de guerra são uma prática comum integrada ao ritmo dos negócios em Microsoft. Para obter mais informações, consulte Segurança no DevOps (DevSecOps).
O Azure DevOps oferece suporte a ferramentas de terceiros que podem ser automatizadas como parte dos pipelines de integração/implantação contínua (CI/CD). Para obter mais informações, consulte Habilitar o DevSecOps com o Azure e o GitHub.
Informações relacionadas
Os testes de penetração e avaliações de segurança mais recentes podem ser encontrados no Service Trust Portal Microsoft .
Microsoft realiza testes extensivos dos serviços de nuvem. Microsoft Esse teste inclui testes de penetração, com resultados publicados no Portal de Confiança do Serviço da sua organização. Sua organização pode realizar seu próprio teste de penetração em serviços do Microsoft Power Platform e do Microsoft Dynamics 365. Todos os testes de penetração devem seguir as Microsoft Regras de engajamento para testes de penetração na nuvem. É importante lembrar que, em muitos casos, a Microsoft Nuvem usa infraestrutura compartilhada para hospedar seus ativos e ativos pertencentes a outros clientes. Você deve limitar todos os testes de penetração aos seus ativos e evitar consequências não intencionais para outros clientes ao seu redor.
Siga as regras de compromisso para certificar-se de que o acesso não seja usado indevidamente. Para obter orientação sobre como planejar e executar ataques simulados, consulte:
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.
Lista de verificação de segurança
Consulte o conjunto completo de recomendações.