Pré-requisitos

Spoke: Instalar Spoke das Operações de segurança (sn_sec_spoke)

Capacidades-chave

O playbook de login com falha cobre os seguintes recursos para investigar incidentes de segurança:

1. Verifica se o usuário afetado é um usuário ativo/inativo
2. Filtra observáveis da lista de permitidos
3. Aprimora os observáveis
4. Executa a pesquisa automatizada de ameaças.
5. Envia e-mail automatizado ao usuário para confirmar a falha na tentativa de login.
6. Atribui tarefas ao analista para investigar o acesso do usuário
7. Identifica observáveis maliciosos e bloqueia IPs e URLs.
8. Redefine a senha do usuário.
9. Atualiza o status do incidente de segurança
10. Atribui tarefas a um analista de segurança para lidar com a revisão pós-incidente.

Capacidades necessárias

Para obter mais informações, consulte a ServiceNow Store.

Experiência do analista de segurança

Para entender como resolver ameaças à segurança passo a passo, consulte Resolver ameaças à segurança com o playbook.

Como usar o playbook de login com falha com capacidades do Flow Designer

A imagem a seguir mostra uma cópia do playbook de login manual com falha. Revise as etapas abaixo para entender as várias ações no playbook.

Este playbook é acionado e associado ao incidente de segurança quando as seguintes condições são atendidas:

• Categoria é login com falha
• Tem um ou mais usuários afetados
• O incidente de segurança não foi encerrado ou cancelado

As etapas a seguir orientam você nas ações, tarefas e subfluxos que estão disponíveis no playbook de login manual com falha.

1. Quando o playbook começa a ser executado, na Etapa 1, ele é atualizado automaticamente com uma anotação de trabalho mostrando que o incidente de segurança com a categoria de login com falha foi atribuído.
   
   
2. Na Etapa 2, o playbook é atualizado e movido para o estado Análise.
3. Na Etapa 3, o playbook verifica se o usuário afetado é um usuário ativo ou inativo. Se o usuário estiver inativo, uma anotação de trabalho será adicionada ao incidente de segurança informando que a conta do usuário está inativa.
   
   
   Nota:

   Na etapa 3 do fluxo, o fluxo verifica os usuários inativos na tabela sn_si_incident disponível em ServiceNow. Esta etapa é fornecida como uma diretriz e deve ser modificada para seu ambiente específico. Se você quiser usar essa funcionalidade, recomendamos que tenha uma integração do Active Directory configurada em seu ambiente. Você pode verificar com a integração do Active Directory para encontrar o status do usuário e, dependendo da resposta, você pode projetar as próximas etapas para o seu playbook.

   Se você não tiver uma integração do Active Directory, substitua esta etapa por uma tarefa manual para o analista de segurança trabalhar com a equipe de TI para bloquear o usuário e seguir em frente com o restante das etapas do playbook.

4. Na Etapa 4, os observáveis do incidente de segurança são recuperados.
5. Na Etapa 5, os observáveis são identificados.
6. Se nenhum observável for encontrado, uma tarefa de resposta manual será criada na Etapa 6 e o fluxo será encerrado.
   
   
7. Se observáveis forem encontrados na Etapa 7, os observáveis que não são permitidos na lista serão identificados.
8. Se pelo menos um dos observáveis estiver na lista de não permitidos, as seguintes etapas serão executadas:
   1. As etapas 8.1 e 8.2 são executadas. Os observáveis são recuperados e uma tarefa de resposta automatizada é iniciada.
      
      
   2. Depois que a tarefa automatizada for criada, a Etapa 8.3 (8.3.1.1 e 8.3.2.1) será executada e as integrações Aprimorar observáveis e Pesquisa de ameaças serão executadas. Observe que esses são subfluxos que foram incluídos no playbook.
      
      
   3. Na Etapa 8.4, após a conclusão das integrações, o registro de incidente de segurança é atualizado.
   4. Na Etapa 8.5, uma nova tarefa de resposta é criada para indicar a próxima tarefa automatizada que ocorrerá.
   5. Na Etapa 8.6, a integração da Pesquisa de detecções será executada nos observáveis.
      
      
   6. Depois que o subfluxo Pesquisa de detecções for concluído, na Etapa 8.7, o incidente de segurança será atualizado.
   7. Na Etapa 8.8, os observáveis são verificados para ver se são mal-intencionados.
   8. Se os observáveis não forem mal-intencionados e se a conta do usuário estiver ativa, um e-mail automatizado será enviado ao usuário para confirmar novamente as tentativas de login malsucedidas. Uma tarefa de resposta manual é criada para identificar os observáveis e adicioná-los ao incidente de segurança. O playbook termina nesta fase.
   9. Se os observáveis forem mal-intencionados, três tarefas de resposta serão criadas:
      1. Um e-mail automatizado é enviado ao usuário para confirmar (sim ou não) as tentativas de login malsucedidas. Se o usuário responder Sim:
         1. O status do incidente de segurança é atualizado para Conter.
         2. Um e-mail automatizado é enviado ao usuário para redefinir a senha.
         3. O subfluxo de redefinição de senha é iniciado e um e-mail é enviado ao usuário quando a tarefa é concluída.
         Nota:

         A etapa Redefinir senha é fornecida como uma diretriz. As etapas no fluxo redefinem a senha da conta do usuário no sistema ServiceNow. Mas o processo para redefinir a senha pode ser diferente dependendo do seu ambiente. Você pode verificar com a integração do Active Directory para redefinir a senha dos usuários automaticamente. Se você não tiver uma integração do Active Directory, substitua esta etapa por uma tarefa manual para o analista de segurança trabalhar com a respectiva equipe de TI para redefinir a senha dos usuários e prosseguir com o restante das etapas do playbook após concluir as respectivas tarefa.
      2. Se o usuário responder Não, um e-mail automatizado será enviado ao usuário para confirmar novamente a resposta. O analista de segurança precisa executar manualmente as ações apropriadas.
      3. Se o usuário não responder ao e-mail automatizado, o analista de segurança deverá atualizar o incidente de segurança manualmente e fornecer uma resposta. Uma tarefa manual é criada para validar se a conta do usuário foi comprometida.
      
      
      
9. Na Etapa 8.10.3, o estado do incidente de segurança é atualizado.
10. Na Etapa 8.10.4, uma tarefa automatizada é criada para verificar se a implementação da capacidade Criar solicitações de bloqueio para IPs e URLs maliciosos está disponível. Se a implementação da capacidade estiver disponível, o subfluxo Criar solicitações de bloqueio será executado. Se não estiver disponível, o incidente de segurança será atualizado e uma anotação de trabalho será publicada para indicar que a implementação da capacidade não está disponível.
11. Na Etapa 9, o incidente de segurança é atualizado e o estado é definido como Revisar.
12. Na Etapa 10, uma tarefa de resposta é criada para que o usuário conclua a revisão pós-incidente antes de fechar a tarefa.