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, Automação e Resposta de Segurança (SOAR), aumentando a eficácia do SOC e economizando tempo e recursos.
Importante
O Microsoft Sentinel está disponível como parte da versão prévia pública da plataforma unificada de operações de segurança no portal do Microsoft Defender. Para obter mais informações, veja Microsoft Sentinel no portal 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 alertanã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, sujeita a...
- Condições que determinarão as circunstâncias exatas sob as quais a regra será executada e executar...
- Ações para alterar o incidente de alguma forma ou chamar um guia estratégico.
Gatilhos
As regras de automação são disparadas quando um incidente é criado ou atualizado ou quando um alerta é criado. Lembre-se de que esses incidentes incluem alertas e que alertas e incidentes podem ser criados por regras de análise, das quais há vários tipos, conforme explicado em Detectar ameaças com regras de análise internas no Microsoft Sentinel.
A tabela a seguir mostra as diferentes cenários possíveis que farão 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: Microsoft Sentinel não integrado à plataforma unificada: |
| Quando o incidente é atualizado | |
| Quando o alerta é criado |
Automação baseada em incidentes ou baseada em alertas?
Agora que a automação de incidentes e a automação de alertas são tratadas centralmente por regras de automação, bem como guias estratégicos, como você deve escolher quando usar qual?
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 seu workspace do Microsoft Sentinel está integrado à plataforma de operações de segurança unificada, pois toda a criação de incidentes acontece no Microsoft Defender XDR e, portanto, as regras de criação de incidentes do Microsoft Sentinel precisam ser desabilitadas.
Mesmo sem ser integrado ao portal unificado, você poderá ainda optar por usar a automação disparada por alerta se quiser usar outra lógica externa para determinar se e como os incidentes são criados com base nos alertas, além de indicar a possibilidade e a maneira de agrupar os alertas em incidentes. Por exemplo:
Um guia estratégico pode ser disparado por um alerta que não tem um incidente associado, 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 pode ser disparado por um alerta e, em vez de criar um incidente, procure um incidente existente apropriado para adicionar o alerta. Saiba mais sobre expansão de incidentes.
Um guia estratégico pode ser disparado por um alerta e 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 pode ser disparado por um alerta e enviar o alerta para um sistema de tíquete externo para criação e gerenciamento de incidentes, criando um novo tíquete para cada alerta.
Observação
A automação disparada por alertas está disponível apenas para alertas criados por regras de análise Agendadas, NRT e de Segurança da Microsoft.
A automação disparada por alertas para alertas criados pelo Microsoft Defender XDR não está disponível na plataforma de operações de segurança unificada. Para obter mais informações, confira Automação com a plataforma de operações de segurança unificada.
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:
Um valor da propriedade de incidente
- é 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.
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.
Gatilho de criação de alerta
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 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 versão dos Aplicativos Lógicos do Azure (Padrão 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 será desabilitada após essa data. Isso é útil para tratar (ou seja, fechar) incidentes de "ruído" causados por atividades planejadas e limitadas por tempo, como testes de penetração.
Ordem
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" alterasse a severidade de um incidente de médio para baixo e a "segunda regra de automação" estivesse definida para ser executada somente em incidentes com severidade média ou mais alta, ela não seria 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 forem executadas.
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 de ordem será preenchido automaticamente com o número seguindo o 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, 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 pedido) e, somente após isso, as regras com o tipo de gatilho de atualização de incidente (de acordo com os números de pedido 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 outras times quando forem feitas alterações em incidentes, para que elas 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 indisponí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:
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 aos 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 regra de automação vai mostrar a condição da regra de análise como indisponí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".
Você observará que ao criar uma regra de automação aqui, o painel Criar regra de automação preenche todos os campos 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.
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.
- 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 de automação avançadas, veja Automatizar a resposta a ameaças com guias estratégicos no Microsoft Sentinel.
- Para obter ajuda ao implementar guias estratégicos, confira Tutorial: Usar guias estratégicos para automatizar respostas a ameaças no Microsoft Sentinel.