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

Este artigo explica o que são regras de automação do Microsoft Sentinel e como usá-las para implementar suas operações SOAR (Security Orchestration, Automation and Response). As regras de automação aumentam a eficácia do seu SOC e poupam-lhe tempo e recursos.

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 podem ser aplicadas em diferentes cenários.

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

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

  • Adicione tarefas de incidentes para os analistas seguirem.
  • Reprima incidentes barulhentos.
  • Faça a triagem de novos incidentes alterando seu status de Novo para Ativo e atribuindo um proprietário.
  • Marque incidentes para classificá-los.
  • Escale um incidente atribuindo um novo proprietário.
  • Feche incidentes resolvidos, especificando um motivo e adicionando comentários.

• Automatize respostas para várias regras de análise ao mesmo tempo.

• Controle a ordem das ações que são executadas.

• Inspecione o conteúdo de um incidente (alertas, entidades e outras propriedades) e tome outras medidas chamando um manual.

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

Em resumo, as regras de automação simplificam o uso da automação no Microsoft Sentinel, permitindo que você simplifique fluxos de trabalho complexos para seus processos de orquestração de resposta a ameaças.

Componentes

As regras de automação são compostas por vários componentes:

• Gatilhos que definem que tipo de evento de incidente faz com que a regra seja executada, sujeito a condições.
• Condições que determinam as circunstâncias exatas sob as quais a regra é executada e executa ações.
• Ações para alterar o incidente de alguma forma ou chamar um playbook, que realiza ações mais complexas e interage com outros serviços.

Acionadores

As regras de automação são acionadas 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 Deteção de ameaças no Microsoft Sentinel.

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

Automação baseada em incidentes ou alertas?

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

Para a maioria dos casos de uso, a automação acionada 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 provas únicas, os incidentes são modificáveis, têm o status mais atualizado e podem ser enriquecidos com comentários, tags e marcadores. O incidente permite que você acompanhe a história de ataque que continua evoluindo com a adição de novos alertas.

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

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

Esse motivo é especialmente relevante quando seu espaço de trabalho do Microsoft Sentinel está integrado à plataforma unificada de operações de segurança. Nesse cenário, toda a criação de incidentes acontece 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ê pode, de qualquer forma, decidir usar a automação acionada por alertas se quiser usar outra lógica externa para decidir se e quando criar incidentes a partir de alertas e como os alertas são agrupados. Por exemplo:

• Um playbook, acionado por um alerta que não tem um incidente associado, pode enriquecer o alerta com informações de outras fontes e, com base em alguma lógica externa, decidir se deve criar um incidente ou não.

• Um playbook, acionado por um alerta, pode, em vez de criar um incidente, procurar um incidente existente apropriado para adicionar o alerta. Saiba mais sobre a expansão de incidentes.

• Um playbook, acionado por um alerta, pode notificar o pessoal do SOC sobre o alerta para que a equipe possa decidir se deve ou não criar um incidente.

• Um playbook, acionado por um alerta, pode enviar o alerta para um sistema de tíquete externo para criação e gerenciamento de incidentes, e esse sistema cria um novo tíquete para cada alerta.

Condições

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

Quando uma regra de automação é acionada, ela verifica o incidente ou alerta de acionamento em relação às condições definidas na regra. Para incidentes, as condições baseadas na 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 mudanças no estado da propriedade (veja detalhes abaixo). Como um único evento de criação ou atualização de incidente pode acionar várias regras de automação, a ordem em que elas são executadas (veja abaixo) faz diferença na determinação do resultado da avaliação das condições. As ações definidas na regra são executadas somente se todas as condições forem satisfeitas.

Incidente criar gatilho

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 incidente, 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, se você definir Nome da regra analítica como Contém == Ataque de força bruta contra um Cloud PC, uma regra analítica com o ataque de força bruta contra o portal do Azure não atende à condição. No entanto, se você definir o nome da regra analítica como Não contém == Credenciais de usuário, tanto o ataque de força bruta contra um Cloud PC quanto o ataque de força bruta contra as regras de análise do portal do Azure atendem à condição.

Gatilho de atualização de incidente

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

Uma dessas propriedades é Atualizada por. Esta propriedade permite rastrear o tipo de fonte que fez a alteração no incidente. Você pode criar uma condição avaliando se o incidente foi atualizado por um dos seguintes valores, dependendo se você integrou seu espaço de trabalho à plataforma unificada de operações de segurança:

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 tiver sido feita por outra regra de automação.

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

O valor de uma propriedade incidente foi

• alterado (independentemente do valor real antes ou depois).
• alterado a partir do valor definido na condição.
• alterado para o valor definido na condição.
• adicionado a (isto aplica-se a propriedades com uma lista de valores).

Propriedade da tag : individual vs. coleção

A propriedade de incidente Tag é uma coleção de itens individuais — um único incidente pode ter várias tags aplicadas a ele. Você pode definir condições que verificam cada tag na coleção individualmente e condições que verificam a coleção de tags como uma unidade.

• Qualquer operador de tag individual verifica a condição em relação a cada tag na coleção. A avaliação é verdadeira quando pelo menos uma tag satisfaz a condição.
• Os operadores de coleta de todas as tags verificam a condição em relação à coleta de tags como uma única unidade. A avaliação só é verdadeira se a coleção no seu conjunto satisfizer a condição.

Esta distinção é importante quando a sua condição é negativa (não contém), e algumas etiquetas na coleção satisfazem a condição e outras não.

Vejamos um exemplo em que sua condição está, a tag não contém "2024" e você tem dois incidentes, cada um com duas tags:

Neste exemplo, no Incidente 1:

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

No Incidente 2, o resultado é o mesmo, independentemente do tipo de condição definida.

Propriedades de entidade suportadas

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

Alerta criar gatilho

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

Ações

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

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

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

  • Ao mudar para "fechado", especifique o motivo de fechamento e adicione um comentário. Isso ajuda você a acompanhar seu desempenho e eficácia, além de ajustar para reduzir falsos positivos.

• Alterar a gravidade de um incidente – você pode reavaliar e repriorizar com base na presença, ausência, valores ou atributos das entidades envolvidas no incidente.

• Atribuir um incidente a um proprietário – ajuda-o a direcionar os tipos de incidentes para o pessoal mais adequado para lidar com eles ou para o pessoal mais disponível.

• Adicionar uma tag a um incidente – isso é útil para classificar incidentes por assunto, por atacante ou por qualquer outro denominador comum.

Além disso, você pode definir uma ação para executar um playbook, a fim de tomar ações de resposta mais complexas, incluindo qualquer que envolva sistemas externos. Os playbooks disponíveis para serem usados em uma regra de automação dependem do gatilho no qual os playbooks e a regra de automação são baseados: somente playbooks de acionamento de incidente podem ser executados a partir de regras de automação de gatilho de incidente, e somente playbooks 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 playbooks ou combinações de playbooks e outras ações. As ações são executadas na ordem em que são listadas na regra.

Os playbooks que utilizam qualquer versão das Aplicações Lógicas do Azure (Padrão ou de Consumo) estão disponíveis para execução a partir de regras de automação.

Data de validade

Você pode definir uma data de expiração em uma regra de automação. A regra é desativada após essa data. Isso é útil para lidar (ou seja, fechar) incidentes de "ruído" causados por atividades planejadas e limitadas no tempo, como testes de penetração.

Ordenar

Você pode definir a ordem em que as regras de automação são executadas. Regras de automação posteriores avaliam as condições do incidente de acordo com seu estado depois de serem acionadas por regras de automação anteriores.

Por exemplo, se a "Primeira Regra de Automação" alterou a gravidade de um incidente de Média para Baixa e a "Segunda Regra de Automação" for definida para ser executada apenas em incidentes com gravidade Média ou Superior, ela não será executada nesse incidente.

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

As regras baseadas no gatilho de atualização têm sua própria fila de pedidos separada. Se essas regras forem acionadas para serem executadas em um incidente recém-criado (por uma alteração feita por outra regra de automação), elas serão executadas somente depois que todas as regras aplicáveis baseadas no gatilho de criação terminarem de ser executadas.

Notas sobre a ordem de execução e a prioridade

• A definição do 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 de ordem é preenchido automaticamente com o número que segue o maior número usado por regras existentes do mesmo tipo de gatilho.
• No entanto, para regras criadas de outras maneiras (linha de comando, API, etc.), o número do pedido deve ser atribuído manualmente.
• Não há nenhum mecanismo de validação que impeça que várias regras tenham o mesmo número de ordem, 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 em qual ordem 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 sã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 são executadas primeiro (de acordo com seus números de ordem) e, só em seguida, as regras com o tipo de gatilho de atualização de incidente (de acordo com seus números de ordem).
• As regras são sempre executadas sequencialmente, nunca em paralelo.

Casos e cenários de utilização comuns

Tarefas de incidentes

As regras de automação permitem padronizar e formalizar as etapas necessárias para a triagem, investigação e remediaçã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 deteção de ameaças nas regras de análise subjacentes. As tarefas aplicadas a um incidente aparecem na página do incidente, para que seus analistas tenham toda a lista de ações que precisam tomar, bem na frente deles, e não percam nenhuma etapa crítica.

Automação acionada por incidentes e alertas

As regras de automação podem ser acionadas pela criação ou atualização de incidentes e também pela criação de alertas. Todas essas ocorrências podem acionar cadeias de resposta automatizadas, que podem incluir playbooks (permissões especiais são necessárias).

Acionar playbooks para provedores da Microsoft

As regras de automação fornecem uma maneira de automatizar o tratamento de alertas de segurança da Microsoft aplicando essas regras a incidentes criados a partir dos alertas. As regras de automação podem chamar playbooks (permissões especiais são necessárias) e passar os incidentes para eles com todos os seus detalhes, incluindo alertas e entidades. Em geral, as práticas recomendadas do Microsoft Sentinel ditam o uso da fila de incidentes como o 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 a Cloud
• Microsoft Defender for Cloud Apps
• Microsoft Defender para Office 365
• Microsoft Defender para Ponto Final
• Microsoft Defender para Identidade
• Microsoft Defender para a IoT

Vários playbooks/ações sequenciados em uma única regra

Agora você pode ter controle quase completo sobre a ordem de execução de ações e playbooks em uma única regra de automação. Você também controla a ordem de execução das próprias regras de automação. Isso permite que você simplifique muito seus playbooks, reduzindo-os a uma única tarefa ou a uma pequena e direta sequência de tarefas, e combine esses pequenos playbooks em diferentes combinações em diferentes regras de automação.

Atribua um manual a várias regras de análise de uma só vez

Se você tiver uma tarefa que deseja automatizar em todas as suas regras de análise – por exemplo, a criação de um tíquete de suporte em um sistema de tíquete externo – você pode aplicar um único manual a qualquer uma ou todas as suas regras de análise – incluindo quaisquer regras futuras – de uma só vez. Isso torna as tarefas de manutenção e limpeza simples, mas repetitivas, muito menos trabalhosas.

Atribuição automática de incidentes

Você pode atribuir incidentes ao proprietário certo automaticamente. Se o seu SOC tiver um analista especializado em uma plataforma específica, quaisquer incidentes relacionados a essa plataforma podem ser atribuídos automaticamente a esse analista.

Supressão de incidentes

Você pode usar regras para resolver automaticamente incidentes que são positivos falsos/benignos conhecidos sem o uso de playbooks. Por exemplo, ao executar testes de penetração, fazer manutenção ou atualizações programadas ou testar procedimentos de automação, muitos incidentes falso-positivos podem ser criados que o SOC deseja ignorar. Uma regra de automação por tempo limitado pode fechar automaticamente esses incidentes à medida que são criados, marcando-os com um descritor da causa de sua geração.

Automação por tempo limitado

Você pode adicionar datas de expiração para suas regras de automação. Pode haver outros casos, além da supressão de incidentes, que justifiquem uma automação limitada no tempo. Você pode querer atribuir um tipo específico de incidente a um usuário específico (por exemplo, um estagiário ou um consultor) por um período de tempo específico. Se o prazo for conhecido com antecedência, você pode efetivamente fazer com que a regra seja desativada no final de sua relevância, sem ter que se lembrar de fazê-lo.

Marcar incidentes automaticamente

Você pode adicionar automaticamente tags de texto livre a incidentes para agrupá-los ou classificá-los de acordo com qualquer critério de sua escolha.

Casos de uso adicionados pelo gatilho de atualização

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

Estenda 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 a investigação progride e os analistas adicionam alertas, comentários e tags. Controle o agrupamento de alertas em incidentes.

Orquestração e notificação de atualizações

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. Escale os incidentes atribuindo-os a novos proprietários e informando-os de suas atribuições. Controle quando e como os incidentes são reabertos.

Manter a sincronização com sistemas externos

Se você usou playbooks para criar tíquetes em sistemas externos quando incidentes são criados, você pode usar uma regra de automação de gatilho de atualização para chamar um playbook que atualiza esses tíquetes.

Execução de regras de automação

As regras de automação são executadas sequencialmente, de acordo com a ordem determinada. Cada regra de automação é executada após a anterior ter terminado sua execução. Dentro de uma regra de automação, todas as ações são executadas sequencialmente na ordem em que são definidas.

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

Permissões para regras de automação para executar playbooks

Quando uma regra de automação do Microsoft Sentinel executa um playbook, ela usa uma conta de serviço especial do Microsoft Sentinel especificamente autorizada para essa ação. A utilização desta conta (por oposição à sua conta de utilizador) aumenta o nível de segurança do serviço.

Para que uma regra de automatização execute um manual de procedimentos, esta conta tem de ter permissões explícitas para o grupo de recursos no qual o manual de procedimentos reside. Nesse ponto, qualquer regra de automação pode executar qualquer manual nesse grupo de recursos.

Quando você estiver configurando uma regra de automação e adicionando uma ação de playbook de execução, uma lista suspensa de playbooks será exibida. Os playbooks para os quais o Microsoft Sentinel não tem permissões são exibidos como indisponíveis ("acinzentados"). Você pode conceder permissão ao Microsoft Sentinel para os grupos de recursos dos playbooks no local, selecionando o link Gerenciar permissões do playbook. Para conceder essas permissões, você precisa de permissões de Proprietário nesses grupos de recursos. Consulte os requisitos de permissões completos.

Permissões em uma arquitetura multilocatária

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

Portanto, se sua implantação do Microsoft Sentinel usar uma arquitetura multilocatário, você poderá fazer com que uma regra de automação em um locatário execute um playbook que mora em um locatário diferente, mas as permissões para o Sentinel executar os playbooks devem ser definidas no locatário onde os playbooks residem, não no locatário onde as regras de automação estão definidas.

No caso específico de um MSSP (Managed Security Service Provider), em que um locatário do provedor de serviços gerencia um espaço de trabalho do Microsoft Sentinel em um locatário cliente, há dois cenários específicos que merecem sua atenção:

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

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

• Uma regra de automação criada no espaço de trabalho do cliente (enquanto estiver conectado ao locatário do provedor de serviços) é configurada para executar um manual localizado no locatário do cliente.

  Esta configuração é usada quando não há necessidade de proteger a propriedade intelectual. Para que esse cenário funcione, as permissões para executar o manual precisam ser concedidas ao Microsoft Sentinel em ambos os locatários. No locatário do cliente, você concede a eles no painel Gerenciar permissões do playbook, 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 adicional do Azure Lighthouse que conceda direitos de acesso ao aplicativo Azure Security Insights, com a função de Colaborador de Automação do Microsoft Sentinel, no grupo de recursos onde o manual reside.

  O cenário tem a seguinte aparência:

  

  Consulte as nossas instruções para configurar esta configuração.

Criação e gerenciamento de regras de automação

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

• 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. A partir daí, você pode criar novas regras de automação e editar as existentes. Você também pode arrastar 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 espaço de trabalho, juntamente com seu status (Habilitado/Desabilitado) e a quais regras de análise elas são aplicadas.

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

• Assistente de regras do Google Analytics

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

  Quando você cria uma regra de automação a partir daqui, o painel Criar nova regra de automação mostra a condição da regra de análise como indisponível, porque essa regra já está definida para se aplicar somente à regra de análise que você está editando no assistente. Todas as outras opções de configuração ainda estão disponíveis para você.

• Página de 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 "barulhentos".

  Quando você cria uma regra de automação a partir daqui, o painel Criar nova regra de automação preenche todos os campos com valores do incidente. Ele nomeia a regra com o mesmo nome do 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 expiração para a regra. Você pode adicionar ou remover condições e ações, e alterar a data de validade, como desejar.

Regras de automação de exportação e importação

Exporte suas regras de automação para arquivos de modelo do Azure Resource Manager (ARM) e importe regras desses arquivos como parte do gerenciamento e 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 você pode renomear, mover e manipular como qualquer outro arquivo.

O arquivo JSON exportado é independente do espaço de trabalho, portanto, pode ser importado para outros espaços de trabalho e até mesmo para outros locatários. Como código, ele também pode ser controlado por versão, atualizado e implantado em uma estrutura de CI/CD gerenciada.

O arquivo inclui todos os parâmetros definidos na regra de automação. 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óximos passos

Neste documento, você aprendeu sobre como as regras de automação podem ajudá-lo a gerenciar centralmente a automação de resposta para incidentes e alertas do Microsoft Sentinel.

• Crie e use regras de automação do Microsoft Sentinel para gerenciar incidentes.
• Use regras de automação para criar listas de tarefas para analistas.
• Para saber mais sobre opções avançadas de automação, consulte Automatizar a resposta a ameaças com playbooks no Microsoft Sentinel.
• Para obter ajuda com a implementação de playbooks, consulte Tutorial: Usar playbooks para automatizar respostas a ameaças no Microsoft Sentinel.