Partilhar via


Passo 5. Desenvolver e testar casos de utilização

Aplica-se a:

  • Microsoft Defender XDR

Os métodos recomendados para implementar Microsoft Defender XDR no Centro de Operações de Segurança (SOC) dependem do conjunto atual de ferramentas, processos e conjunto de competências da equipa SOC. Manter a higiene cibernética entre plataformas pode ser um desafio devido à grande quantidade de dados provenientes de dezenas, se não centenas de fontes de segurança.

As ferramentas de segurança estão interligadas. Ativar uma funcionalidade numa tecnologia de segurança ou alterar um processo pode, por sua vez, quebrar outra. Por este motivo, a Microsoft recomenda que a sua equipa do SOC formalize um método para definir e atribuir prioridades a casos de utilização. Os casos de utilização ajudam a definir requisitos e processos de teste para operações SOC em várias equipas. Cria uma metodologia para capturar métricas para determinar se as funções certas e a combinação de tarefas estão alinhadas com a equipa certa com o conjunto de competências certo.

Desenvolver e formalizar o processo de caso de utilização

O SOC deve definir um padrão e um processo de alto nível para desenvolver casos de utilização, que seriam regulados pela equipa de Supervisão do SOC. A equipa de Supervisão do SOC deve trabalhar com a sua empresa, TI, legal, RH e outros grupos para priorizar casos de utilização para o SOC que, eventualmente, entrarão nos runbooks e manuais de procedimentos da equipa do SOC. A prioridade dos casos de utilização baseia-se em objetivos, como a conformidade ou a privacidade.

As atividades de Supervisão do SOC relacionadas com o desenvolvimento de casos de utilização incluem:

  • Requisitos
  • Necessidades de pessoal ou formação
  • Licenças de software
  • Contratação do fornecedor
  • Gerir plano
  • Manter o registo de casos de utilização
  • Manter/atualizar modelos

Para facilitar os processos de criação de runbooks e manuais de procedimentos, crie uma árvore de decisões de casos de utilização. Esta figura mostra um exemplo.

O processo de decisão de caso de utilização

Uma vez definido e aprovado um padrão de caso de utilização de alto nível, o passo seguinte é criar e testar um caso de utilização real. As secções seguintes utilizam cenários de análise de vulnerabilidades e ameaças e anti phishing como exemplos.

Exemplo de caso de utilização 1: Nova variante de phishing

O primeiro passo na criação de um caso de utilização consiste em destacar o fluxo de trabalho através de um story board. Eis um exemplo de um quadro de história de alto nível para uma nova notificação de exploração de phishing para uma equipa de Informações sobre Ameaças.

O fluxo de trabalho de um caso de utilização para uma campanha anti-phishing

Invocar o fluxo de trabalho de caso de utilização, por exemplo, 1

Assim que o quadro de blocos tiver sido aprovado, o próximo passo é invocar o fluxo de trabalho do caso de utilização. Eis um processo de exemplo para uma campanha anti-phishing.

Um fluxo de trabalho de caso de utilização detalhado para uma campanha anti-phishing

Exemplo de caso de utilização 2: Análise de ameaças e vulnerabilidades

Outro cenário em que poderia ser utilizado um caso de utilização é a análise de ameaças e vulnerabilidades. Neste exemplo, o SOC requer que as ameaças e as vulnerabilidades sejam remediadas em relação aos recursos através de processos aprovados que incluem a análise de recursos.

Eis um exemplo de guião gráfico de alto nível para a Gestão de vulnerabilidades do Microsoft Defender de recursos.

Um fluxo de trabalho de caso de utilização para Gestão de Vulnerabilidades e Ameaças

Invocar o fluxo de trabalho do caso de utilização, por exemplo, 2

Eis um processo de exemplo de análise de ameaças e vulnerabilidades.

Um fluxo de trabalho de caso de utilização detalhado para Gestão de Vulnerabilidades e Ameaças

Analisar a saída do caso de utilização e as lições aprendidas

Depois de um caso de utilização ter sido aprovado e testado, devem ser identificadas lacunas entre as suas equipas de segurança, juntamente com pessoas, processos e as tecnologias de Microsoft Defender XDR envolvidas. Microsoft Defender XDR tecnologias devem ser analisadas para determinar se são capazes de alcançar os resultados pretendidos. Estes podem ser controlados através de uma lista de verificação ou de uma matriz.

Por exemplo, no exemplo de cenário anti-phishing, as equipas do SOC poderiam ter feito as descobertas nesta tabela.

Equipa SOC Requisito Pessoas para cumprir os requisitos Processo para cumprir os requisitos Tecnologia relevante Lacuna identificada Registo de alterações de casos de utilização Excluído (Y/N)
Equipa de Análise e Informações sobre Ameaças As origens de dados estão a alimentar corretamente os motores de informações sobre ameaças. Analista/Engenheiro do Threat Intelligence Requisitos do feed de dados estabelecidos, acionadores de informações sobre ameaças de origens aprovadas Microsoft Defender para Identidade, Microsoft Defender para Endpoint A equipa do Threat Intelligence não utilizou o script de automatização para ligar Microsoft Defender XDR API aos motores de informações sobre ameaças Adicionar Microsoft Defender XDR como origens de dados a motores de ameaças

Atualizar o livro de execução de casos de utilização

N
Equipa de monitorização As origens de dados estão a alimentar corretamente os dashboards de monitorização Alertas de & de Monitorização soc de camada 1,2 Fluxo de trabalho para comunicar a Classificação de Segurança do Centro de Conformidade do & Investigar alertas no Microsoft Defender XDR

Monitorização da Classificação de Segurança

Nenhum mecanismo para os analistas do SOC reportarem com êxito a deteção de novas variantes de phishing para melhorar a Classificação de Segurança

Ver relatórios de segurança de e-mail no portal do Microsoft Defender

Adicionar um processo para controlar a melhoria da Classificação de Segurança aos fluxos de trabalho de Relatórios N
Equipa de Engenharia e SecOps As atualizações de controlo de alteração são efetuadas nos runbooks da equipa do SOC Engenheiro SOC de Camada 2 Procedimento de notificação de Controlo de Alteração para runbooks de equipa do SOC Alterações aprovadas aos dispositivos de segurança As alterações à conectividade Microsoft Defender XDR à tecnologia de segurança SOC requerem aprovação Adicionar Microsoft Defender for Cloud Apps, Defender para Identidade, Defender para Ponto Final, Centro de Conformidade & de Segurança a runbooks SOC Y

Além disso, as equipas soc poderiam ter feito as descobertas descritas na tabela abaixo no que diz respeito ao cenário de Gestão de Vulnerabilidades do Defender descrito acima:

Equipa SOC Requisito Pessoas para cumprir os requisitos Processo para cumprir os requisitos Tecnologia relevante Lacuna identificada Registo de alterações de casos de utilização Excluído (Y/N)
Supervisão do SOC Todos os recursos ligados a redes aprovadas são identificados e categorizados SoC Oversight, proprietários de BU, proprietários de aplicações, proprietários de ativos de TI, etc. Sistema de gestão de recursos centralizado para detetar e listar categorias de recursos e atributos com base no risco. ServiceNow ou outros recursos.

Inventário de Dispositivos do Microsoft 365
Apenas 70% dos recursos foram detetados. Microsoft Defender XDR controlo de remediação apenas eficaz para recursos conhecidos Serviços de gestão do ciclo de vida de ativos maduros para garantir Microsoft Defender XDR tem 100% de cobertura N
Equipas secOps & de Engenharia O impacto elevado e as vulnerabilidades críticas nos recursos são remediadas de acordo com a política Engenheiros secOps, analistas SOC: Conformidade do & de Vulnerabilidades, Engenharia de Segurança Processo definido para categorizar Vulnerabilidades Críticas e de Alto Risco Dashboards do Gestão de vulnerabilidades do Microsoft Defender O Defender para Endpoint identificou um elevado impacto, dispositivos de alerta elevado sem plano de remediação ou implementação da atividade recomendada da Microsoft Adicionar um fluxo de trabalho para notificar os proprietários de recursos quando a atividade de remediação é necessária no prazo de 30 dias por política; Implemente um sistema de permissão para notificar os proprietários de recursos dos passos de remediação. N
Monitorizar o Teams O estado de ameaça e vulnerabilidade é comunicado através do portal da intranet da empresa Analista soc de camada 2 Relatórios gerados automaticamente a partir de Microsoft Defender XDR a mostrar o progresso da remediação dos recursos Investigar alertas no Microsoft Defender XDR

Monitorização da Classificação de Segurança

Não existem vistas ou relatórios de dashboard a serem comunicados aos proprietários de recursos relativamente ao estado de ameaças e vulnerabilidades dos recursos. Create script de automatização para preencher o estado de remediação de vulnerabilidades de ativos críticos e de alto risco para a organização. N

Nestes casos de utilização de exemplo, o teste revelou várias lacunas nos requisitos da equipa SOC que foram estabelecidos como linhas de base para as responsabilidades de cada equipa. A lista de verificação de casos de utilização pode ser tão abrangente quanto necessário para garantir que a equipa do SOC está preparada para a integração Microsoft Defender XDR com os requisitos do SOC novos ou existentes. Uma vez que se trata de um processo iterativo, o processo de desenvolvimento de casos de utilização e o conteúdo de saída do caso de utilização servem naturalmente para atualizar e amadurecer os runbooks do SOC com lições aprendidas.

Atualizar runbooks e manuais de procedimentos de produção

Depois de os testes de casos de utilização terem sido remediados para todas as lacunas, as lições aprendidas e as métricas recolhidas nos mesmos podem ser incorporadas nos runbooks de produção (processos operacionais) e manuais de procedimentos (respostas a incidentes e procedimentos de escalamento) da sua equipa do SOC.

A manutenção dos runbooks e manuais de procedimentos da equipa do SOC pode ser organizada de várias formas. Cada equipa do SOC pode ser responsável por si própria ou pode haver uma única versão centralizada para todas as equipas partilharem num repositório central. A gestão de runbooks e manuais de procedimentos para organizações individuais baseia-se no tamanho, no conjunto de competências, nas funções e na segregação de deveres. Assim que um runbook tiver sido atualizado, o processo de atualização do manual de procedimentos deverá seguir-se.

Utilizar uma estrutura padrão para escalamento

Os manuais de procedimentos são os passos que as equipas SOC têm de seguir quando ocorre um evento real, com base na integração e teste bem-sucedidos do caso de utilização. Por conseguinte, é imperativo que o SOC siga uma abordagem formalizada à resposta a incidentes, como o NIST Incident Response Standard que se tornou um dos principais padrões da indústria para a resposta a incidentes.

O processo de resposta a incidentes de quatro passos do NIST inclui quatro fases:

  1. Preparação
  2. Deteção e análise
  3. Contenção, erradicação e recuperação
  4. Atividade pós-incidente

Exemplo: Controlar a atividade da fase de preparação

Uma das principais bases de um manual de procedimentos de escalamento é garantir que há pouca ambiguidade quanto ao que cada equipa do SOC deve fazer antes, durante e depois de um evento ou incidente. Por conseguinte, é uma boa prática indicar instruções passo a passo.

Por exemplo, a fase de Preparação pode incluir uma matriz de tarefas if/then ou XoR. No caso do novo caso de utilização do exemplo de variante de phishing, tal matriz pode ter o seguinte aspeto:

Por que motivo o Escalamento é Justificado? Passo Seguinte
Alerta na Monitorização do SOC classificado como crítico acionado >500/hora Aceda ao Manual de Procedimentos A, Secção 2, Atividade 5 (com uma ligação para a secção do manual de procedimentos)
ECommerce reportou potencial ataque DDoS Invocar Manual de Procedimentos da Secção B, Atividade 19 (com uma ligação para a secção do manual de procedimentos)
Executivo comunicou um e-mail suspeito como tentativa de phishing de spear Aceda ao Manual de Procedimentos 5, Secção 2, Atividade 5 (com uma ligação para a secção do manual de procedimentos)

Depois de executar a fase de Preparação, as organizações devem invocar as fases restantes, conforme descrito pelo NIST:

  • Deteção e análise
  • Contenção, erradicação e recuperação
  • Atividade pós-incidente

Passo seguinte

Passo 6. Identificar tarefas de manutenção do SOC

Sugestão

Quer saber mais? Interaja com a comunidade do Microsoft Security na nossa Tech Community: Microsoft Defender XDR Tech Community.