Etapa 5. Desenvolver e testar casos de uso

Artigo
11/16/2023

Observação

Quer experimentar Microsoft Defender XDR? Saiba mais sobre como você pode avaliar e pilotar Microsoft Defender XDR.

Aplica-se a:

Microsoft Defender XDR

Os métodos recomendados para implantar Microsoft Defender XDR no SOC (Centro de Operações de Segurança) dependem do conjunto atual de ferramentas, processos e conjunto de habilidades da equipe 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 inter-relacionadas. Ativar um recurso em uma tecnologia de segurança ou alterar um processo pode, por sua vez, interromper outro. Por esse motivo, a Microsoft recomenda que sua equipe do SOC formalize um método para definir e priorizar casos de uso. Casos de uso ajudam a definir requisitos e processos de teste para operações SOC em várias equipes. Ele cria uma metodologia para capturar métricas para determinar se as funções corretas e a combinação de tarefas estão alinhadas à equipe certa com o conjunto de habilidades certo.

Desenvolver e formalizar o processo de caso de uso

O SOC deve definir um padrão e um processo de alto nível para desenvolver casos de uso, que seriam regulados pela equipe de Supervisão do SOC. A equipe de Supervisão do SOC deve trabalhar com seus negócios, TI, jurídico, RH e outros grupos para priorizar casos de uso para o SOC que eventualmente entrarão nos runbooks e guias estratégicos da equipe SOC. A prioridade dos casos de uso baseia-se em objetivos, como conformidade ou privacidade.

As atividades de Supervisão do SOC relacionadas ao desenvolvimento de casos de uso incluem:

Requisitos
Necessidades de pessoal ou treinamento
Licenças de software
Contratação de fornecedor
Gerenciando plano
Manter o registro de caso de uso
Manter/atualizar modelos

Para facilitar os processos de criação de runbook e de guias estratégicos, crie uma árvore de decisão de caso de uso. Essa figura mostra um exemplo.

Depois que um padrão de caso de uso de alto nível for definido e aprovado, a próxima etapa é criar e testar um caso de uso real. As seções a seguir usam cenários de verificação de ameaças e vulnerabilidades e anti-phishing como exemplos.

Exemplo de caso de uso 1: nova variante de phishing

A primeira etapa na criação de um caso de uso é descrever o fluxo de trabalho usando um quadro de histórias. Aqui está um exemplo de um quadro de histórias de alto nível para uma nova notificação de exploração de phishing para uma equipe de Inteligência contra Ameaças.

Invocar o fluxo de trabalho de caso de uso, por exemplo, 1

Depois que o quadro de histórias for aprovado, a próxima etapa é invocar o fluxo de trabalho do caso de uso. Aqui está um processo de exemplo para uma campanha anti-phishing.

Exemplo de caso de uso 2: verificação de ameaças e vulnerabilidades

Outro cenário em que um caso de uso pode ser usado é para verificação de ameaças e vulnerabilidades. Neste exemplo, o SOC exige que ameaças e vulnerabilidades sejam corrigidas em relação aos ativos por meio de processos aprovados que incluem a verificação de ativos.

Aqui está um exemplo de storyboard de alto nível para o Gerenciamento de Vulnerabilidades do Microsoft Defender de ativos.

Invocar o fluxo de trabalho de caso de uso, por exemplo, 2

Aqui está um processo de exemplo para verificação de ameaças e vulnerabilidades.

Analisar a saída do caso de uso e as lições aprendidas

Depois que um caso de uso for aprovado e testado, as lacunas entre suas equipes de segurança devem ser identificadas, juntamente com pessoas, processos e as Microsoft Defender XDR tecnologias envolvidas. Microsoft Defender XDR tecnologias devem ser analisadas para determinar se são capazes de alcançar resultados desejados. Elas podem ser rastreadas por meio de uma lista de verificação ou de uma matriz.

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

Equipe SOC	Requisito	Pessoas atender aos requisitos	Processo para atender aos requisitos	Tecnologia relevante	Lacuna identificada	Usar log de alteração de caso	Isento (Y/N)
Equipe de Inteligência contra Ameaças e Análise	As fontes de dados estão alimentando corretamente os mecanismos de inteligência contra ameaças.	Analista/Engenheiro de Inteligência contra Ameaças	Requisitos de feed de dados estabelecidos, gatilhos de inteligência contra ameaças de fontes aprovadas	Microsoft Defender para Identidade, Microsoft Defender para Ponto de Extremidade	A equipe do Threat Intelligence não usou o script de automação para vincular Microsoft Defender XDR API com mecanismos intel de ameaças	Adicionar Microsoft Defender XDR como fontes de dados a mecanismos de ameaça Atualizar o livro de execução de casos de uso	N
Equipe de monitoramento	As fontes de dados estão alimentando corretamente os painéis de monitoramento	Alertas de & de analistas soc de 1,2 nível 1,2	Fluxo de trabalho para a pontuação segura da Central de Conformidade do & de Segurança de Relatórios	Investigar alertas no Microsoft Defender XDR Monitoramento de Pontuação Segura	Nenhum mecanismo para os analistas do SOC relatarem a detecção bem-sucedida de nova variante de phishing para melhorar a Pontuação Segura Exibir relatórios de segurança de email no portal do Microsoft Defender	Adicionar um processo para acompanhar o aprimoramento da Pontuação Segura aos fluxos de trabalho do Reporting	N
Equipe de Engenharia e SecOps	As atualizações de controle de alteração são feitas nos runbooks de equipe do SOC	Engenheiro SOC de nível 2	Alterar o procedimento de notificação de controle para runbooks de equipe do SOC	Alterações aprovadas em dispositivos de segurança	Alterações na conectividade Microsoft Defender XDR com a tecnologia de segurança SOC exigem aprovação	Adicionar Microsoft Defender para Aplicativos de Nuvem, Defender para Identidade, Defender para Ponto de Extremidade, Central de Conformidade do & de Segurança aos runbooks SOC	S

Além disso, as equipes do SOC poderiam ter feito as descobertas descritas na tabela abaixo em relação ao cenário de Gerenciamento de Vulnerabilidades do Defender descrito acima:

Equipe SOC	Requisito	Pessoas atender aos requisitos	Processo para atender aos requisitos	Tecnologia relevante	Lacuna identificada	Usar log de alteração de caso	Isento (Y/N)
Supervisão do SOC	Todos os ativos conectados a redes aprovadas são identificados e categorizados	Supervisão SOC, proprietários de BU, proprietários de aplicativos, proprietários de ativos de TI etc.	Sistema de gerenciamento de ativos centralizado para descobrir e listar categoria de ativos e atributos com base no risco.	ServiceNow ou outros ativos. Inventário de dispositivos do Microsoft 365	Apenas 70% dos ativos foram descobertos. Microsoft Defender XDR controle de correção apenas eficaz para ativos conhecidos	Serviços de gerenciamento de ciclo de vida de ativos maduros para garantir que Microsoft Defender XDR tenha 100% de cobertura	N
Equipes de & secops de engenharia	Vulnerabilidades de alto impacto e críticas em ativos são corrigidas de acordo com a política	Engenheiros do SecOps, analistas do SOC: Conformidade & vulnerabilidade, Engenharia de Segurança	Processo definido para categorizar vulnerabilidades de alto risco e críticas	Painéis Gerenciamento de Vulnerabilidades do Microsoft Defender	O Defender para Ponto de Extremidade identificou dispositivos de alerta alto e de alto impacto sem nenhum plano de correção ou implementação da atividade recomendada pela Microsoft	Adicione um fluxo de trabalho para notificar os proprietários de ativos quando a atividade de correção for necessária dentro de 30 dias por política; Implemente um sistema de bilhetagem para notificar os proprietários de ativos das etapas de correção.	N
Equipes de Monitoramento	O status de ameaças e vulnerabilidades é relatado por meio do portal de intranet da empresa	Analista soc de nível 2	Relatórios gerados automaticamente de Microsoft Defender XDR mostrando o progresso da correção dos ativos	Investigar alertas no Microsoft Defender XDR Monitoramento de Pontuação Segura	Não há exibições ou relatórios dashboard sendo comunicados aos proprietários de ativos sobre ameaças e status de vulnerabilidade de ativos.	Crie um script de automação para preencher status de correção de vulnerabilidade de ativos de alto risco e crítica para a organização.	N

Nesses casos de uso de exemplo, o teste revelou várias lacunas nos requisitos da equipe SOC que foram estabelecidas como linhas de base para as responsabilidades de cada equipe. A lista de verificação de caso de uso pode ser tão abrangente quanto necessário para garantir que a equipe do SOC esteja preparada para a integração Microsoft Defender XDR com requisitos soc novos ou existentes. Como esse é um processo iterativo, o processo de desenvolvimento de casos de uso e o conteúdo de saída de caso de uso naturalmente servem para atualizar e amadurecer os runbooks do SOC com lições aprendidas.

Atualizar runbooks e guias estratégicos de produção

Depois que o teste de caso de uso tiver sido corrigido para todas as lacunas, as lições aprendidas e as métricas coletadas nelas podem ser incorporadas aos runbooks de produção (processos operacionais) e guias estratégicos da equipe SOC (respostas a incidentes e procedimentos de escalonamento).

A manutenção dos runbooks e guias estratégicos da equipe SOC pode ser organizada de várias maneiras. Cada equipe SOC pode ser responsável por sua própria, ou pode haver uma única versão centralizada para todas as equipes compartilharem em um repositório central. O gerenciamento de runbook e de guias estratégicos para organizações individuais baseia-se no tamanho, conjunto de habilidades, funções e segregação de tarefas. Depois que um runbook for atualizado, o processo de atualização de guias estratégicos deverá seguir.

Usar uma estrutura padrão para escalonamento

Os guias estratégicos são as etapas que as equipes do SOC precisam seguir quando ocorre um evento real, com base na integração bem-sucedida e no teste do caso de uso. Portanto, é imperativo que o SOC siga uma abordagem formalizada para a resposta a incidentes, como o NIST Incident Response Standard que se tornou um dos principais padrões do setor para resposta a incidentes.

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

Preparação
Detecção e análise
Contenção, eliminação e recuperação
Atividade pós-incidente

Exemplo: Atividade de fase de preparação de acompanhamento

Um dos principais fundamentos de uma cartilha de escalonamento é garantir que haja pouca ambiguidade quanto ao que cada equipe SOC deve fazer antes, durante e depois de um evento ou incidente. Portanto, é uma boa prática listar instruções passo a passo.

Por exemplo, a fase preparação pode incluir uma matriz de tarefas if/then ou XoR. No caso do caso de uso do novo exemplo de variante de phishing, essa matriz pode ser semelhante a esta:

Por que o escalonamento é garantido?	Próxima etapa
Alerta no Monitoramento do SOC classificado como crítico disparado >500/hora	Vá para Playbook A, Seção 2, Atividade 5 (com um link para a seção de guias estratégicos)
O eCommerce relatou um possível ataque DDoS	Invocar a Seção B do Playbook C, Atividade 19 (com um link para a seção de guias estratégicos)
Executivo relatou um email suspeito como tentativa de phishing de lança	Vá para Playbook 5, Seção 2, Atividade 5 (com um link para a seção de guias estratégicos)

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

Detecção e análise
Contenção, eliminação e recuperação
Atividade pós-incidente

Próxima etapa

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

Dica

Você deseja aprender mais? Engage com a comunidade de Segurança da Microsoft em nossa Comunidade Tecnológica: Microsoft Defender XDR Tech Community.