Automatize 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 SOAR (Security Orchestration, Automation and Response), aumentando a eficácia do SOC e economizando tempo e recursos.
Importante
O Microsoft Sentinel está disponível como parte da visualização pública da plataforma unificada de operações de segurança no portal Microsoft Defender. Para obter mais informações, consulte 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 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 alertanã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 fará com que a regra seja executada, sujeito a...
- Condições que determinarão as circunstâncias exatas sob as quais a regra será executada e executada...
- Ações para alterar o incidente de alguma forma ou chamar um playbook.
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, das quais existem vários tipos, conforme explicado em Detetar ameaças com regras de análise internas no Microsoft Sentinel.
A tabela a seguir mostra os diferentes cenários possíveis que farão com que uma regra de automação seja executada.
| Tipo de acionador | 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 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 playbooks, como você deve escolher quando usar quais?
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 foi desativada 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, pois 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 determinar se e como os incidentes são criados a partir de alertas, bem como se e como os alertas são agrupados em incidentes. Por exemplo:
Um manual pode ser acionado 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 deve criar um incidente ou não.
Um manual pode ser acionado por um alerta e, em vez de criar um incidente, procure um incidente existente apropriado para adicionar o alerta. Saiba mais sobre a expansão de incidentes.
Um manual pode ser acionado por um alerta e notificar o pessoal do SOC sobre o alerta, para que a equipe possa decidir se cria ou não um incidente.
Um playbook pode ser acionado por um alerta e enviar o alerta para um sistema de tickets externo para criação e gerenciamento de incidentes, criando um novo ticket para cada alerta.
Nota
A automação acionada por alertas está disponível apenas para alertas criados por regras de análise de segurança agendadas, NRT e da Microsoft.
A automação acionada por alertas para alertas criados pelo Microsoft Defender XDR não está disponível na plataforma unificada de operações de segurança. Para obter mais informações, consulte Automação com a plataforma unificada de operações de segurança.
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 serã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:
Valor de uma propriedade 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 neste 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 executada anteriormente serão consideradas o estado atual para regras de execução posterior.
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:
- 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 manual
- 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 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:
| \ Incidentes ▶ Condição ▼ \ |
Incidente 1 Tag 1: 2024 Etiqueta 2: 2023 |
Incidente 2 Etiqueta 1: 2023 Tag 2: 2022 |
|---|---|---|
| Qualquer tag individual não contém "2024" |
VERDADEIRO | TRUE |
| Coleção de todas as tags não contém "2024" |
FALSO | TRUE |
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 (quecontém "2024"), a condição geral é falsa.
No Incidente 2, o resultado será o mesmo, independentemente do tipo de condição definida.
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 será 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 serã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 serão executadas na ordem em que estão listadas na regra.
Os Playbooks que utilizam qualquer versão das Aplicações Lógicas do Azure (Standard ou Consumo) estarã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 será 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 serão executadas. Regras de automação posteriores avaliarão 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" alterar 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 aparecerão 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 create tiverem sido 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 será 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 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 só então 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.
Nota
Após a integração à plataforma unificada de operações de segurança, se várias alterações forem feitas no mesmo incidente em um período de cinco a dez minutos, uma única atualização será enviada para o Microsoft Sentinel, com apenas a alteração mais recente.
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 atualizará esses tíquetes.
Execução de regras de automação
As regras de automação são executadas sequencialmente, de acordo com a ordemdeterminada. 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:
| Tempo de execução do playbook | A regra de automação avança para a próxima ação... |
|---|---|
| Menos de um segundo | Imediatamente após a conclusão do playbook |
| Menos de dois minutos | Até dois minutos depois de o playbook ter começado a ser executado, mas não mais de 10 segundos após a conclusão do playbook |
| Mais de dois minutos | Dois minutos depois de a cartilha começar a funcionar, independentemente de ter sido ou não concluída |
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. Nessa altura, qualquer regra de automatização poderá executar qualquer manual de procedimentos 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 serã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ê precisará 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ê 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.
Você notará que, ao criar 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".
Você notará que, ao criar uma regra de automação a partir daqui, o painel Criar nova regra de automação preencheu 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.
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 na implementação de playbooks, consulte Tutorial: Usar playbooks para automatizar respostas a ameaças no Microsoft Sentinel.