Automatizar a resposta a ameaças no Microsoft Sentinel com regras de automação

Este artigo explica o que são as regras de automação do Microsoft Sentinel e como usá-las para implementar suas operações de Orquestração, Automatização e Resposta de Segurança (SOAR). As regras de automação aumentam a eficácia do SOC e economizam tempo e recursos.

Importante

O Microsoft Sentinel agora está disponível em geral na plataforma de operações de segurança unificada da Microsoft no portal do Microsoft Defender. Para saber mais, confira Microsoft Sentinel no portal do Microsoft Defender.

O que são regras de automação?

As regras de automação são uma maneira de gerenciar centralmente a automação no Microsoft Sentinel, permitindo que você defina e coordene um pequeno conjunto de regras que pode ser aplicado em diferentes cenários.

As regras de automação se aplicam às seguintes categorias de casos de uso:

  • Execute tarefas básicas de automação para tratamento de incidentes sem usar guias estratégicos. Por exemplo:

    • Adicione tarefas de incidentes para os analistas seguirem.
    • Suprimir incidentes barulhentos.
    • Fazer a triagem de novos incidentes alterando seu status de Novo para Ativo e atribuindo um proprietário.
    • Marcar incidentes para classificá-los.
    • Escalonar um incidente atribuindo um novo proprietário.
    • Fechar incidentes resolvidos, especificando um motivo e adicionando comentários.
  • Automatizar as respostas para várias regras de análise ao mesmo tempo.

  • Controlar a ordem das ações executadas.

  • Inspecione o conteúdo do incidente (alertas, entidades e outras propriedades) e execute outras ações chamando um guia estratégico.

  • As regras de automação também podem ser o mecanismo pelo qual você executa um guia estratégico em resposta a um alerta não associado a um incidente.

Em resumo, as regras de automação facilitam o uso da automação no Microsoft Sentinel, permitindo simplificar fluxos de trabalho complexos para processos de orquestração de resposta a ameaças.

Componentes

As regras de automação são constituídas por diversos componentes:

  • Gatilhos que definem que tipo de evento de incidente fará com que a regra seja executada, sujeitos a condições.
  • Condições que determinarão as circunstâncias exatas sob as quais a regra será executada e executará as ações.
  • Ações para alterar o incidente de alguma forma ou chamar um guia estratégico, que executa ações mais complexas e interage com outros serviços.

Gatilhos

As regras de automação são disparadas quando um incidente é criado ou atualizado ou quando um alerta é criado. Lembre-se de que os incidentes incluem alertas e que alertas e incidentes podem ser criados por regras de análise, conforme explicado em Detecção de ameaças no Microsoft Sentinel.

A tabela a seguir mostra as diferentes cenários possíveis que fazem com que uma regra de automação seja executada.

Tipo de gatilho Eventos que fazem com que a regra seja executada
Quando o incidente é criado Plataforma unificada de operações de segurança no Microsoft Defender:
  • Um novo incidente é criado no portal do Microsoft Defender.

    Microsoft Sentinel não integrado à plataforma unificada:
  • Um novo incidente é criado por uma regra de análise.
  • Um incidente é ingerido por meio do Microsoft Defender XDR.
  • Um incidente é criado manualmente.
  • Quando o incidente é atualizado
  • O status do incidente é alterado (fechado/reaberto/selecionado).
  • O proprietário do incidente é atribuído ou alterado.
  • A gravidade de um incidente é aumentada ou reduzida.
  • Alertas são adicionados ao incidente.
  • Comentários, marcas ou táticas são adicionados ao incidente.
  • Quando o alerta é criado
  • Um alerta é criado por uma regra de análise do Microsoft Sentinel Agendada ou NRT.
  • Automação baseada em incidentes ou baseada em alertas?

    Com as regras de automação lidando centralmente com a resposta a incidentes e alertas, como você deve escolher quais automatizar e em quais circunstâncias?

    Para a maioria dos casos de uso, a automação disparada por incidentes é a abordagem preferível. No Microsoft Sentinel, um incidente é um "arquivo de caso" – uma agregação de todas as evidências relevantes para uma investigação específica. É um contêiner para alertas, entidades, comentários, colaboração e outros artefatos. Ao contrário dos alertas, que são evidências simples, os incidentes são modificáveis, têm o status mais atualizado e podem ser enriquecidos com comentários, marcas e indicadores. O incidente permite que você acompanhe o histórico do ataque, que continua evoluindo com a adição de novos alertas.

    Por esses motivos, faz mais sentido criar sua automação em torno de incidentes. Portanto, a maneira mais apropriada de criar guias estratégicos é baseá-los no gatilho de incidentes do Microsoft Sentinel nos Aplicativos Lógicos do Azure.

    O principal motivo para usar a automação disparada por alertas é responder a alertas gerados por regras de análise que não criam incidentes (ou seja, onde a criação de incidentes foi desabilitada na guia Configurações de incidente do assistente de regra de análise).

    Esse motivo é especialmente relevante quando o workspace do Microsoft Sentinel é integrado à plataforma de operações de segurança unificada. Nesse cenário, toda a criação de incidentes ocorre no Microsoft Defender XDR e, portanto, as regras de criação de incidentes no Microsoft Sentinel devem ser desabilitadas.

    Mesmo sem estar integrado ao portal unificado, você poderá mesmo assim optar por usar a automação disparada por alertas se quiser usar outra lógica externa para determinar se incidentes serão criados com base nos alertas, quando devem ser criados e como os alertas serão agrupados. Por exemplo:

    • Um guia estratégico, ao ser disparado por um alerta que não tenha um incidente associado, pode enriquecer o alerta com informações de outras fontes e, com base em alguma lógica externa, decidir se deseja ou não criar um incidente.

    • Um guia estratégico, ao ser disparado por um alerta, pode, em vez de criar um incidente, procurar um incidente existente apropriado para o qual adicionar o alerta. Saiba mais sobre expansão de incidentes.

    • Um guia estratégico, ao ser disparado por um alerta, pode notificar a equipe do SOC sobre o alerta, para que a equipe possa decidir se deseja ou não criar um incidente.

    • Um guia estratégico, ao ser disparado por um alerta, pode enviar o alerta para um sistema de tíquetes externo para criação e gerenciamento de incidentes, criando um novo tíquete para cada alerta.

    Observação

    Condições

    Conjuntos complexos de condições podem ser definidos para controlar quando as ações (veja abaixo) devem ser executadas. Essas condições incluem o evento que dispara a regra (incidente criado ou atualizado ou alerta criado), os estados ou valores das propriedades do incidente e das propriedades da entidade (somente para disparo de incidentes), além da regra de análise ou as regras que geraram o incidente ou alerta.

    Quando uma regra de automação é disparada, ela verifica o incidente ou alerta de gatilho em relação às condições definidas na regra. Para incidentes, as condições baseadas em propriedade são avaliadas de acordo com o estado atual da propriedade no momento em que a avaliação ocorre ou de acordo com as alterações no estado da propriedade (consulte abaixo para obter detalhes). Como um único incidente de criação ou nuvem de evento de atualização pode disparar várias regras de automação, a ordem na qual elas são executadas (consulte abaixo) faz a diferença ao determinar o resultado da avaliação das condições. As ações definidas na regra serão executadas somente se todas as condições forem atendidas.

    Gatilho de criação de incidentes

    Para regras definidas usando o gatilho Quando um incidente é criado, você pode definir condições que verificam o estado atual dos valores de uma determinada lista de propriedades de incidentes, usando um ou mais dos seguintes operadores:

    • é igual ou não é igual ao valor definido na condição.
    • contém ou não contém o valor definido na condição.
    • começa com ou não começa com o valor definido na condição.
    • termina com ou não termina com o valor definido na condição.

    Por exemplo, caso defina o Nome da regra analítica como Contains == Ataque de força bruta contra um PC na nuvem, uma regra analítica com o Ataque de força bruta contra o portal do Azure não atenderá à condição. No entanto, caso defina o Nome da regra analítica como Não contém == Credenciais de usuário, o Ataque de força bruta contra um PC na nuvem e a Força bruta contra as regras de análise do portal do Azure atenderão à condição.

    Observação

    O estado atual nesse contexto refere-se ao momento em que a condição é avaliada – ou seja, o momento em que a regra de automação é executada. Se mais de uma regra de automação for definida para ser executada em resposta à criação desse incidente, as alterações feitas no incidente por uma regra de automação de execução anterior são consideradas o estado atual para regras de execução posteriores.

    Gatilho de atualização de incidentes

    As condições avaliadas nas regras definidas usando o gatilho Quando um incidente é atualizado incluem todas as listadas para o gatilho de criação de incidentes. Mas o gatilho de atualização inclui mais propriedades que podem ser avaliadas.

    Uma dessas propriedades é Atualizada por. Essa propriedade permite que você acompanhe o tipo de origem que fez a alteração no incidente. Você pode criar uma condição avaliando se o incidente foi atualizado por um dos valores a seguir, dependendo de ter ou não integrado o workspace à plataforma unificada de operações de segurança:

    • Um aplicativo, incluindo aplicativos nos portais do Azure e do Defender.
    • Um usuário, incluindo alterações feitas por usuários nos portais do Azure e do Defender.
    • AIR, para atualizações por investigação e resposta automatizadas no Microsoft Defender para Office 365
    • Um agrupamento de alertas (que adicionou alertas ao incidente), incluindo agrupamentos de alertas que foram feitos por regras de análise e lógica de correlação interna do Microsoft Defender XDR
    • Um guia estratégico
    • Uma regra de automação
    • Outros, se nenhum dos valores acima se aplicar

    Usando essa condição, por exemplo, você pode instruir essa regra de automação a ser executada em qualquer alteração feita em um incidente, exceto se ela foi feita por outra regra de automação.

    Objetivamente, o gatilho de atualização também usa outros operadores que verificam as alterações de estado nos valores das propriedades de incidente, bem como seu estado atual. Uma condição de alteração de estado seria atendida se:

    Um valor da propriedade de incidente fosse

    • alterado (independentemente do valor real anterior ou posterior).
    • alterado do valor definido na condição.
    • alterado para o valor definido na condição.
    • adicionado ao (isso se aplica a propriedades com uma lista de valores).

    Propriedade Tag: individual x coleção

    A propriedade de incidente Tag é uma coleção de itens individuais (único incidente pode ter várias marcas aplicadas). Você pode definir condições que verifiquem cada marca na coleção individualmente e condições que verifiquem a coleção de marcas como uma unidade.

    • Qualquer operador de marca individual verifica a condição em relação a cada marca na coleção. A avaliação é verdadeira quando pelo menos uma marca atende à condição.
    • Os operadores de coleção de todas as marcas verificam a condição em relação à coleção de marcas como uma única unidade. A avaliação será verdadeira somente se a coleção como um todo atender à condição.

    Essa distinção é importante quando a condição é negativa (não contém) e algumas marcas na coleção atendem à condição e outras não.

    Vejamos um exemplo em que a condição é A marca não contém "2024" e você tem dois incidentes, cada um com duas marcas:

    \ Incidentes ▶
    Condição ▼ \
    Incidente 1
    Marca 1: 2024
    Marca 2: 2023
    Incidente 2
    Marca 1: 2023
    Marca 2: 2022
    Qualquer marca individual
    não contém "2024"
    TRUE TRUE
    A coleção de todas as marcas
    não contém "2024"
    FALSE TRUE

    Neste exemplo, no Incidente 1:

    • Se a condição verificar cada marca individualmente, como há pelo menos uma marca que satisfaz a condição (que não contém "2024"), a condição geral é verdadeira.
    • Se a condição verificar todas as marcas no incidente como uma única unidade, como há pelo menos uma marca que não satisfaz a condição (que contêm "2024"), a condição geral é falso.

    No Incidente 2, o resultado será o mesmo, independentemente do tipo de condição definido.

    Propriedades de entidade com suporte

    Para obter a lista de propriedades de entidade com suporte como condições para regras de automação, consulte Referência de regras de automação do Microsoft Sentinel.

    Gatilho de criação de alerta

    Atualmente, a única condição que pode ser configurada para o gatilho de criação de alertas é o conjunto de regras de análise para as quais a regra de automação será executada.

    Ações

    As ações podem ser definidas para serem executadas quando as condições (veja acima) forem atendidas. Você pode definir muitas ações em uma regra e pode escolher a ordem na qual elas serão executadas (veja abaixo). As ações a seguir podem ser definidas usando regras de automação, sem a necessidade da funcionalidade avançada de um guia estratégico:

    • Adicionar uma tarefa a um incidente – você pode criar uma lista de verificação de tarefas para os analistas acompanharem todos os processos de triagem, investigação e correção do incidente, para garantir que nenhuma etapa crítica seja perdida.

    • Alterar o status de um incidente, mantendo o fluxo de trabalho atualizado.

      • Ao alterar para "fechado", especificar o motivo do fechamento e adicionar um comentário. Isso ajuda você a acompanhar o desempenho e a eficácia, bem como a ajustar para reduzir falsos positivos.
    • Alterar a severidade de um incidente: você pode reavaliar e alterar a prioridade com base na presença, na ausência, nos valores ou nos atributos das entidades envolvidas no incidente.

    • Atribuir um incidente a um proprietário: ajuda você a direcionar os tipos de incidentes à equipe mais adequada para lidar com eles ou à equipe mais disponível.

    • Adicionar uma marca a um incidente: é útil para classificar incidentes segundo o assunto, o invasor ou qualquer outro denominador comum.

    Além disso, você pode definir uma ação para executar um guia estratégico, a fim de realizar ações de resposta mais complexas, incluindo qualquer uma que envolva sistemas externos. Os guias estratégicos disponíveis para serem usados em uma regra de automação dependem do gatilho no qual os guias estratégicos e a regra de automação se baseiam: somente guias estratégicos de gatilho de incidentes podem ser executados a partir de regras de automação de gatilho de incidentes e somente guias estratégicos de gatilho de alerta podem ser executados a partir de regras de automação de gatilho de alerta. Você pode definir várias ações que chamam guias estratégicos ou combinações de guias estratégicos e outras ações. As ações serão executadas na ordem em que estão listadas na regra.

    Os guias estratégicos que usam qualquer uma das versões dos Aplicativos Lógicos do Azure (Standard ou Consumo) estarão disponíveis para execução por meio de regras de automação.

    Data de validade

    Você pode definir uma data de validade em uma regra de automação. A regra é desabilitada depois que essa data passar. Isso é útil para tratar (ou seja, fechar) incidentes de "ruído" causados por atividades planejadas e limitadas por tempo, como testes de penetração.

    Pedido

    Você pode definir a ordem na qual as regras de automação serão executadas. Regras de automação posteriores avaliarão as condições do incidente de acordo com o estado dele após ter sido tratado pelas regras de automação anteriores.

    Por exemplo, se a "primeira regra de automação" alterou a severidade de um incidente de média para baixa e a "segunda regra de automação" estiver definida para ser executada somente em incidentes com severidade média ou mais alta, ela não será executada nesse incidente.

    A ordem das regras de automação que adicionam tarefas de incidente determina a ordem na qual as tarefas aparecerão em um determinado incidente.

    As regras com base em gatilho de atualização têm sua fila de pedidos separada. Se essas regras forem disparadas para serem executadas em um incidente que acabou de ser criado (por uma alteração feita por outra regra de automação), elas serão executadas somente depois que todas as regras aplicáveis com base no gatilho de criação tiverem sua execução concluída.

    Anotações sobre a ordem e a prioridade de execução

    • Definir o número da ordem nas regras de automação determina sua ordem de execução.
    • Cada tipo de gatilho mantém sua própria fila.
    • Para regras criadas no portal do Azure, o campo ordemserá preenchido automaticamente com o número seguinte ao número mais alto usado pelas regras existentes do mesmo tipo de gatilho.
    • No entanto, para regras criadas de outras maneiras (linha de comando, API, etc.), o número da ordem deve ser atribuído manualmente.
    • Não há nenhum mecanismo de validação impedindo que várias regras tenham o mesmo número de ordem de execução, mesmo dentro do mesmo tipo de gatilho.
    • Você pode permitir que duas ou mais regras do mesmo tipo de gatilho tenham o mesmo número de ordem, se você não se importar com a ordem na qual elas são executadas.
    • Para regras do mesmo tipo de gatilho com o mesmo número de ordem, o mecanismo de execução seleciona aleatoriamente quais regras serão executadas em qual ordem.
    • Para regras de diferentes tipos de gatilho de incidente, todas as regras aplicáveis com o tipo de gatilho de criação de incidente serão executadas primeiro (de acordo com seus números de ordem) e, somente após isso, as regras com o tipo de gatilho de atualização de incidente (de acordo com os números de ordem delas).
    • As regras sempre são executadas sequencialmente, nunca em paralelo.

    Observação

    Após a integração com a plataforma unificada de operações de segurança, se várias alterações forem feitas no mesmo incidente em um período de 5 a 10 minutos, uma única atualização será enviada ao Microsoft Sentinel, com apenas a alteração mais recente.

    Cenários e casos de uso comuns

    Tarefas de incidentes

    As regras de automação permitem padronizar e formalizar as etapas necessárias para a triagem, investigação e correção de incidentes, criando tarefas que podem ser aplicadas a um único incidente, entre grupos de incidentes ou a todos os incidentes, de acordo com as condições definidas na regra de automação e a lógica de detecção de ameaças nas regras de análise subjacentes. As tarefas aplicadas a um incidente aparecem na página do incidente, portanto, seus analistas têm toda a lista de ações que precisam executar, bem na frente deles, e não perderão nenhuma etapa crítica.

    Automação disparada por incidentes e alertas

    As regras de automação podem ser disparadas pela criação ou atualização de incidentes e também pela criação de alertas. Essas ocorrências podem disparar cadeias de resposta automatizadas, que podem incluir guias estratégicos (permissões especiais são necessárias).

    Disparar guias estratégicos para provedores da Microsoft

    As regras de automação são uma forma de automatizar o tratamento de alertas de segurança da Microsoft por meio da aplicação dessas regras a incidentes criados com base nos alertas. As regras de automação podem chamar guias estratégicos (permissões especiais são necessárias) e passar os incidentes para eles com todos os seus detalhes, incluindo alertas e entidades. De modo geral, as melhores práticas do Microsoft Sentinel ditam o uso da fila de incidentes como ponto focal das operações de segurança.

    Os alertas de segurança da Microsoft incluem o seguinte:

    • Proteção do Microsoft Entra ID
    • Microsoft Defender para Nuvem
    • Microsoft Defender for Cloud Apps
    • Microsoft Defender para Office 365
    • Microsoft Defender para ponto de extremidade
    • Microsoft Defender para Identidade
    • Microsoft Defender para IoT

    Vários guias estratégicos/ações sequenciais em uma só regra

    Agora, você pode ter controle quase total sobre a ordem de execução de ações e guias estratégicos em uma só regra de automação. Você também controla a ordem de execução das regras de automação. Isso permite simplificar bastante os guias estratégicos, reduzindo-os a uma só tarefa ou a uma sequência pequena e simples de tarefas, e combinar esses pequenos guias estratégicos em diferentes regras de automação.

    Atribuir um guia estratégico a várias regras de análise de uma só vez

    Se você tem uma tarefa que deseja automatizar em todas as regras de análise – digamos, a criação de um tíquete de suporte em um sistema de emissão de tíquetes externo –, pode aplicar um só guia estratégico a qualquer uma ou a todas as suas regras de análise, incluindo regras futuras, de uma só vez. Isso torna tarefas de manutenção simples, mas repetitivas, muito menos cansativas.

    Atribuição automática de incidentes

    Você pode atribuir incidentes ao proprietário correto automaticamente. Se o SOC tiver um analista especializado em uma determinada plataforma, os incidentes relacionados a essa plataforma poderão ser atribuídos automaticamente a esse analista.

    Supressão de incidentes

    Você pode usar regras para resolver automaticamente incidentes que são falsos positivos/benignos conhecidos sem usar guias estratégicos. Por exemplo, ao executar testes de penetração, fazer atualizações ou manutenção agendada ou testar procedimentos de automação, podem ser criados muitos incidentes falsos positivos que o SOC deseja ignorar. Uma regra de automação com limitação de tempo pode fechar automaticamente esses incidentes conforme eles são criados, enquanto os marca com um descritor da causa de sua geração.

    Automação com limitação de tempo

    Você pode adicionar datas de validade para as regras de automação. Pode haver casos diferentes da supressão de incidentes que demandam automação com limitação de tempo. Talvez você queira atribuir um determinado tipo de incidente a um usuário específico (digamos, um estagiário ou um consultor) por um período específico. Se o período for conhecido, você poderá fazer com que a regra seja desabilitada quando deixar de ser relevante sem precisar se lembrar de fazer isso.

    Marcar incidentes automaticamente

    Você pode adicionar automaticamente marcas livres de texto a incidentes para agrupá-los ou classificá-los de acordo com os critérios de sua escolha.

    Casos de uso adicionados pelo gatilho de atualização

    Agora que as alterações feitas em incidentes podem disparar regras de automação, mais cenários estão abertos à automação.

    Estender a automação quando o incidente evoluir

    Você pode usar o gatilho de atualização para aplicar muitos dos casos de uso acima a incidentes à medida que sua investigação progride e os analistas adicionam alertas, comentários e marcas. Controlar o agrupamento de alertas em incidentes.

    Atualizar orquestração e notificação

    Notifique suas várias equipes e outros funcionários quando forem feitas alterações em incidentes, para que eles não percam nenhuma atualização crítica. Escalone incidentes atribuindo-os a novos proprietários e informando os novos proprietários de suas atribuições. Controlar quando e como os incidentes são reabertos.

    Manter a sincronização com sistemas externos

    Se você usou guias estratégicos para criar tíquetes em sistemas externos quando os incidentes foram criados, você pode usar uma regra de automação de gatilho de atualização para chamar um guia estratégico que atualize esses tíquetes.

    Execução das regras de automação

    As regras de automação são executadas em sequência, de acordo com a ordem que você determina. Cada regra de automação é executada após a conclusão da execução da anterior. Em uma regra de automação, todas as ações são executadas sequencialmente na ordem em que são definidas.

    As ações do guia estratégico em uma regra de automação podem ser tratadas de forma diferente em algumas circunstâncias, de acordo com os seguintes critérios:

    Tempo de execução do guia estratégico A regra de automação avança para a próxima ação…
    Menos de um segundo Imediatamente após a conclusão do guia estratégico
    Menos de dois minutos Até dois minutos após o guia estratégico começar a ser executado,
    Mas não mais do que 10 segundos após a conclusão do guia estratégico
    Mais de dois minutos Dois minutos após o guia estratégico começar a ser executado,
    independentemente de estar ou não concluído

    Permissões para regras de automação executarem guias estratégicos

    Quando uma regra de automação do Microsoft Sentinel executa um guia estratégico, ela usa uma conta de serviço especial do Microsoft Sentinel autorizada especificamente para essa ação. O uso dessa conta (em vez da conta de usuário) aumenta o nível de segurança do serviço.

    Para que uma regra de automação execute um guia estratégico, essa conta deve receber permissões explícitas para o grupo de recursos em que o guia estratégico reside. Nesse ponto, qualquer regra de automação poderá executar qualquer guia estratégico nesse grupo de recursos.

    Quando você estiver configurando uma regra de automação e adicionando uma ação executar guia estratégico, uma lista suspensa de guias estratégicos será exibida. Os guias estratégicos para os quais o Microsoft Sentinel não tem permissões são mostrados como não disponíveis ("esmaecidos"). Você pode conceder ao Microsoft Sentinel permissão aos grupos de recursos dos guias estratégicos no local selecionando o link Gerenciar permissões de guias estratégicos. Para conceder essas permissões, você precisará de permissões de Proprietário nesses grupos de recursos. Consulte os requisitos completos de permissões.

    Permissões em uma arquitetura multilocatário

    As regras de automação dão suporte total a implantações multilocatário e entre espaços (no caso de multilocatário, usando o Azure Lighthouse).

    Portanto, se a sua implantação do Microsoft Sentinel usar uma arquitetura multilocatário, você poderá ter uma regra de automação em um locatário para executar um guia estratégico que reside em um locatário diferente, mas as permissões para o Sentinel executar os guias estratégicos devem ser definidas no locatário onde residem os guias estratégicos, não no locatário em que as regras de automação são definidas.

    No caso específico de um MSSP (Provedor de Serviços de Segurança Gerenciado), em que um locatário do provedor de serviços gerencia um espaço de trabalho do Microsoft Sentinel em um locatário do cliente, há dois cenários específicos que garantem sua atenção:

    • Uma regra de automação criada no locatário do cliente é configurada para executar um guia estratégico localizado no locatário do provedor de serviço.

      Essa abordagem normalmente é usada para proteger a propriedade intelectual no guia estratégico. Nada de especial é necessário para que esse cenário funcione. Ao definir uma ação do guia estratégico em sua regra de automação e chegar ao estágio em que você concede permissões do Microsoft Sentinel no grupo de recursos relevante onde o guia estratégico está localizado (usando o painel Gerenciar permissões do guia estratégico), você verá os grupos de recursos pertencentes ao locatário do provedor de serviços dentre os quais você pode escolher. Veja todo o processo descrito aqui.

    • Uma regra de automação criada no workspace do cliente (enquanto conectado no locatário do provedor de serviços) é configurada para executar um guia estratégico localizado no locatário do cliente.

      Essa configuração é usada quando não há necessidade de proteger a propriedade intelectual. Para que esse cenário funcione, é necessário conceder permissões para executar o guia estratégico ao Microsoft Sentinel em ambos os locatários. No locatário do cliente, conceda-as no painel Gerenciar permissões de guia estratégico, assim como no cenário acima. Para conceder as permissões relevantes no locatário do provedor de serviços, você precisa adicionar uma delegação do Azure Lighthouse adicional que concede direitos de acesso ao aplicativo do Azure Security Insights, com a função Colaborador de Automação do Microsoft Sentinel, no grupo de recursos onde o guia estratégico está localizado.

      Esse cenário se assemelha a:

      Arquitetura de regra de automação multilocatário

      Consulte nossas instruções para configurar isso.

    Criando e gerenciando regras de automação

    Você pode criar e gerenciar regras de automação de áreas diferentes no Microsoft Sentinel ou na plataforma unificada de operações de segurança, dependendo da necessidade e do caso de uso específicos.

    • Página de automação

      As regras de automação podem ser gerenciadas centralmente na página Automação, na guia Regras de automação. Nela, você pode criar outras regras de automação e editar as existentes. Você também pode arrastar as regras de automação para alterar a ordem de execução e habilitá-las ou desabilitá-las.

      Na página Automação, você vê todas as regras definidas no workspace, bem como o status delas (habilitado/desabilitado) e a quais regras de análise elas se aplicam.

      Quando você precisar de uma regra de automação que se aplique a incidentes do Microsoft Defender XDR ou de muitas regras de análise do Microsoft Sentinel, crie-a diretamente na página Automação.

    • Assistente de regra de análise

      Na guia Resposta automatizada do assistente de regra de análise do Microsoft Sentinel, em Regras de automação, você pode visualizar, editar e criar regras de automação que se aplicam à regra de análise específica que está sendo criada ou editada no assistente.

      Você observará que, ao criar uma regra de automação aqui, o painel Criar nova regra de automação vai mostrar a condição regra de análise como não disponível, pois essa regra já estará definida para ser aplicada somente à regra de análise que você estiver editando no assistente. Todas as outras opções de configuração ainda estão disponíveis para você.

    • Página Incidentes

      Você também pode criar uma regra de automação na página Incidentes para responder a um único incidente recorrente. Isso é útil ao criar uma regra de supressão para fechar automaticamente incidentes "com ruído".

      Ao criar uma regra de automação aqui, o painel Criar nova regra de automação terá todos os campos preenchidos com valores do incidente. Ele dá à regra o mesmo nome que o incidente, aplica-a à regra de análise que gerou o incidente e usa todas as entidades disponíveis no incidente como condições da regra. Ele também sugere uma ação de supressão (fechamento) por padrão e sugere uma data de validade para a regra. Você pode adicionar ou remover condições e ações e alterar a data de validade conforme desejar.

    Exportar e importar regras de automação

    Agora você pode exportar suas regras de análise para arquivos de modelo do Azure Resource Manager (ARM) e importar regras desses arquivos como parte do gerenciamento e do controle de suas implantações do Microsoft Sentinel como código. A ação de exportação cria um arquivo JSON no local de downloads do navegador, que pode ser renomeado, movido e manipulado como qualquer outro arquivo.

    O arquivo JSON exportado pode ser importado para outros espaços de trabalho, pois é independente deles, e até mesmo para outros locatários. Como código, ele também pode passar por controle do código-fonte, atualização e implantação em uma estrutura de CI/CD gerenciada.

    O arquivo inclui todos os parâmetros definidos na regra de automação. As regras de qualquer tipo de gatilho podem ser exportadas para um arquivo JSON.

    Para obter instruções sobre como exportar e importar regras de automação, consulte Exportar e importar regras de automação do Microsoft Sentinel.

    Próximas etapas

    Neste documento, você aprendeu sobre como as regras de automação podem ajudar a gerenciar a automação de resposta de maneira centralizada para incidentes e alertas do Microsoft Sentinel.