Separação de domínios e Security Incident Response

  • Versão de lançamento: Washingtondc
  • Atualizado 1 de fev. de 2024
  • 9 min. de leitura

    • Separação de domínios é compatível com Security Incident Response. O Domain Separation permite separar dados, processos e tarefas administrativas em agrupamentos lógicos chamados de domínios. Você pode controlar vários aspectos dessa separação, incluindo quais usuários podem ver e acessar os dados.

    Nível de suporte: Padrão

    • Inclui nível de suporte Básico.
    • Lógica de negócios: o provedor de serviço (SP) cria ou modifica processos por cliente. Os casos de uso refletem o uso adequado do aplicativo por vários clientes de SP em uma única instância.
    • O proprietário da instância deve configurar a lógica de negócios do produto minimamente viável (MVP) e os parâmetros de dados por locatário conforme esperado para o aplicativo específico.

    Exemplo de caso de uso: um administrador deve ser capaz de fazer os comentários necessários quando um registro é encerrado para um locatário, mas não para outro.

    Para obter mais informações sobre os níveis de suporte, consulte Suporte de aplicação para separação de domínio.

    Visão geral

    Na aplicação Security Incident Response, a separação de domínio permite que os provedores de serviço (SPs) padronizem os procedimentos SOC (Security Operations Center) e Security Incident Response (SIR) em toda a base de clientes que atendem com custos operacionais reduzidos e uma qualidade de serviço superior. Separar espaços do cliente para fluxos de trabalho, painéis, relatórios e assim por diante garante que os dados do cliente sejam separados e nunca expostos a outros clientes.

    Tabela 1. Suporte à separação de domínio no Security Incident Response por versões
    Liberação Nível de suporte Anotações
    Genebra, Helsinki Sem suporte Início da separação de domínios no nível de dados
    Istambul Somente dados
    Jakarta Nível 2 (Dados, Solicitante, Executante) Novos recursos: suporte a integrações de terceiros com separação de domínio de nível 2 em uma única instância de integração, incluindo integrações de Inteligência contra ameaças
    Kingston Nível 2 (Dados, Solicitante, Executante) Novos recursos: a integração do Sighting Search para SIR é habilitada com várias instâncias, mas todas as instâncias ainda estão em um único domínio. Exemplo: se houver duas instâncias de uma integração Splunk configurada (SplunkCLOUD e SplunkCORP), ambas ainda serão aproveitadas para atividades de resposta do incidente em um único domínio, onde a implementação foi configurada originalmente.
    Londres Nível 2 (Dados, Solicitante, Executante) Novos recursos: todas as integrações residem em vários domínios
    Madri Nível 2 (Dados, Solicitante, Executante) Todas as integrações agora podem residir em vários domínios. No exemplo acima, SplunkCloud pode ser domain1 e SplunkCORP domain2.
    Nova York Nível 2 (Dados, Solicitante, Executante) Todas as integrações residem em vários domínios.
    Orlando Padrão Todas as integrações residem em vários domínios.
    Paris Padrão Todas as integrações residem em vários domínios.

    A separação de domínio para a aplicação Security Incident Response abrange a seguinte funcionalidade do produto:

    • Os alertas de segurança são direcionados para o domínio apropriado do usuário cujo ID/credencial/escopo gera o incidente e é registrado como um incidente de segurança.
    • Os alertas geram "observáveis", que representam propriedades com estado ou eventos mensuráveis: fluxos de trabalho de segurança no domínio do incidente de segurança são usados para orquestrar a resposta.
    • As integrações são configuradas no domínio do incidente de segurança para automação de resposta.
    • As capacidades são configuradas no domínio do incidente de segurança para automação de resposta. Esses recursos (a partir da versão Kingston) incluem:
      • Pesquisa de ameaças
      • Aprimorar Observável
      • Aprimorar item de configuração
      • Obter processo em execução
      • Obter Estatísticas de Rede
      • Bloquear Solicitação
      • Isolar Host
      • Pesquisa de Vistas
      • Pesquisa e Exclusão de E-mails
      • Publicar na Watchlist
    • Os resultados da automação de resposta (como Pesquisa de ameaças ou Pesquisa de detecções) são armazenados no domínio do incidente de segurança.
    • Outros incidentes de segurança são referenciados cruzadamente no mesmo domínio do incidente de segurança com base em um conjunto compartilhado de observáveis.
    • Outros usuários têm referência cruzada no domínio do incidente de segurança.
    • Os itens de configuração são referenciados cruzadamente no mesmo domínio do incidente de segurança.
    • Tarefas de resposta manuais são adicionadas ao domínio do incidente de segurança.
    • Os artigos da base de conhecimento e os livros de execução são referenciados no domínio do incidente de segurança.
    • As métricas do Security Incident Response pertinentes aos incidentes no domínio são exibidas em painéis, bem como em relatórios.
    Nota:
    Nos casos anteriores, os princípios abrangentes de visibilidade em domínios separados na NOW Platform se aplicam. Como sempre, um incidente no domínio primário pode fazer referência a artefatos no domínio secundário, mas não o contrário.

    Como a separação de domínio funciona no Security Incident Response

    A aplicação Security Incident Response gerencia o ciclo de vida de um incidente de segurança de ponta a ponta. Os casos de uso a seguir reconhecem a separação de domínio:

    • Ingestão de eventos e alertas para criar incidentes de segurança para o analista no SOC do cliente ou no MSP responder:
      • Analisadores de e-mail (baseado em plataforma, phishing relatado pelo usuário, personalizado)
      • Eventos/alertas de desduplicação antes da criação do incidente
      • Extração automática de observáveis
      • Aplicações na loja SIEM de terceiros
    • Aprimoramento de artefatos envolvidos nos incidentes (IP, URLs, domínios, hashes de arquivo):
      • Aprimoramento de ativos (CMDB)
      • Usuários (plataforma)
      • Automação: aprimoramento de observável (por exemplo: WhoIs)
    • Investigar os incidentes com a ajuda dos artefatos e sua reputação ou associação com ameaças conhecidas
      • Orchestrate: Playbooks e artigos da base de conhecimento
      • Automação: pesquisa de ameaças (por exemplo: VirusTotal), pesquisa de detecções (por exemplo: Splunk), obter processos em execução (por exemplo: Carbon Black)
    • Erradicar os artefatos relacionados à ameaça envolvidos no incidente com base na investigação realizada
      • Orchestrate: Playbooks e artigos da base de conhecimento
      • Automação: pesquisa e exclusão de e-mail (por exemplo: Microsoft Exchange), Bloqueio de IP (por exemplo: firewall da Palo Alto)
    • Medir a eficiência ou as operações de resposta a incidentes
      • Painéis de Performance Analytics: produtividade e tendências de incidentes
      • Reconstrução de etapas de investigação de incidentes a partir de anotações de trabalho
      • Revisão pós-incidente

    Configuração do Domain Separation

    Configurar o Domain Separation para Security Incident Response não requer etapas adicionais. Todas as tabelas Security Incident Response adquirem a coluna Domínio depois que a instância é separada por domínio.

    Dados separados por domínio

    Os dados podem ser separados por domínio, o que significa:

    • Os incidentes de segurança em um domínio não podem ser exibidos em outros domínios.
    • Os observáveis extraídos do incidente de segurança são colocados no mesmo domínio e não podem ser exibidos em outros domínios.
    • Até a versão Kingston, as integrações de terceiros configuradas existem no domínio global e podem ser acessadas por todos os outros domínios na instância.
    • Na versão Madrid, as integrações de terceiros podem ser configuradas e ativadas por domínio. Isso significa que a integração ativada e configurada em um domínio não pode ser aproveitada em outro domínio.
    • As automações executadas nos observáveis usando integrações de terceiros (para investigação de ameaças, contenção ou erradicação) localizam seus resultados no domínio do incidente de segurança e não podem ser exibidos em outro domínio.
    • Fluxos de trabalho de orquestração criados em um domínio não são visíveis em outro domínio.
    • As capacidades (conforme delineadas na lista de funções de capacidades anteriores) que são invocadas permanecem genéricas em domínios com implementação específica de domínio da capacidade que está sendo chamada. Por exemplo, uma pesquisa de detecções em um IP pode invocar uma implementação Splunk em um domínio e uma implementação QRadar em outro.

    Configuração

    Todos os aspectos da configuração do produto são autônomos em um ambiente separado por domínio. A configuração pode ser personalizada para domínios individuais.
    Nota:
    A lógica de negócios e os processos nos itens 2 a 5 abaixo podem ser administrados no domínio do locatário.

    As seguintes tarefas devem ser configuradas:

    1. Administração do Sistema
    2. Security Incident Response Administration
    3. Configurações de e-mail de incidente de segurança
    4. Configurações do playbook de incidente de segurança
    5. Configurações de capacidade

    Como os domínios de locatário gerenciam seus dados de aplicação próprios

    • Os proprietários de domínio de locatário criam suas próprias regras de análise de e-mail para ingerir incidentes de segurança.
    • Os proprietários de domínio de locatário podem configurar integrações específicas exclusivamente para uso no domínio.
    • Os proprietários de domínio de locatário podem criar seus próprios fluxos de trabalho de resposta do incidente.
    • Os proprietários de domínio de locatário podem criar suas próprias categorias de incidentes, artigos da base de conhecimento de resposta do incidente e runbooks a serem associados aos fluxos de trabalho de resposta do incidente.
    • Os usuários do domínio de locatário criam e fecham seus próprios incidentes de segurança.

    Lógica de negócios e processos que podem ser separados por domínio pelo proprietário da instância

    • Security Incident Response usuários e grupos
    • Security Incident Response integrações (começando com a versão Madrid)
    • Regras de análise de e-mail para criação de incidente
    • Regras de negócios para consolidar vários eventos ou alertas em um incidente de segurança
    • Fluxos de trabalho para orquestração de resposta do incidente
    • Calculadoras de pontuação de risco de incidente de segurança
    • Caminho de escalação de incidente de segurança
    • ANS de incidente de segurança
    • Definições de processo de incidente de segurança
    • Processos de análise pós-incidente de segurança