Playbook para falha de login manual

Quando um usuário faz determinadas tentativas de login malsucedidas (de acordo com a configuração do SIM), um incidente de segurança é criado.

Essas tentativas de login malsucedidas podem ser falsos positivos ou tentativas feitas por invasores para obter acesso às contas de e-mail do usuário. Nesses cenários, o playbook Manual de login com falha pode fornecer orientação e ajudar a otimizar a investigação de incidentes de segurança de login com falha.

Pré-requisitos

Função necessária:

• sn_si.admin
• flow_designer

Spoke: Instalar o spoke de operações de segurança (sn_sec_spoke)

Capacidades-chave

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

1. Verifica se o usuário afetado é um usuário ativo/inativo
2. Observáveis da lista de filtros permitidos
3. Enriquece os observáveis
4. Executa 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 mal-intencionados 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

• Pesquisa de ameaças (total de vírus, análise híbrida)
• Aprimoramento observável (Whois, ReverseWhois)
• Pesquisa de vistas (Splunk, QRadar)
• Bloqueio de observável (ponto de verificação, Palo Alto)

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

Experiência do analista de segurança

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

Uso do playbook de login com falha com recursos do Flow Designer

Introdução

1. Faça login como um usuário com as funções sn_si.user e flow_designer.
2. Navegar até Flow Designer > Designer e clique em Login com falha playbook.
3. Faça uma cópia dos seguintes fluxos para copiar o Playbook de login com falha e fazer as modificações necessárias. (Esta é uma etapa opcional. Siga esta etapa somente se você planeja personalizar ou fazer mudanças específicas no fluxo).
   • Playbook V1 manual com falha de login
   • Falha no login - Analisar a resposta do usuário e atualizar a tarefa de resposta V1
4. Faça as modificações necessárias de acordo com sua exigência. (Esta é uma etapa opcional. Siga esta etapa somente se você planeja personalizar ou fazer mudanças específicas no fluxo).
5. Ative os playbooks.
   • Ative o fluxo principal para usar o playbook disponível com o sistema de base.
   • Ative os fluxos copiados depois de fazer modificações de acordo com seus requisitos.

A imagem a seguir mostra uma cópia do playbook Manual de login 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:

• A categoria é Falha no login
• Tem um ou mais usuários afetados
• O incidente de segurança não foi encerrado ou cancelado

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

1. Quando o playbook começa a ser executado, na Etapa 1, o playbook é 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 em que a conta do usuário está inativa.
   
   
   Nota:

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

   Se você não tiver uma integração do Active Directory, substitua esta etapa por uma tarefa manual para que o analista de segurança trabalhe com a equipe DE TI para bloquear o usuário e prosseguir com o restante das etapas no 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, a lista de observáveis que não são permitidos será identificada.
8. Se pelo menos um dos observáveis da lista não for permitido, 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 é criada, a Etapa 8,3 (8.3.1.1 e 8,3.2,1) é executada e as integrações Enrich observables e Pesquisa de ameaças são executadas. Observe que esses são subfluxos que foram incluídos no playbook.
      
      
   3. Na Etapa 8,4, depois que as integrações foram concluídas, 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 vistas será executada nos observáveis.
      
      
   6. Após a conclusão do subfluxo de Pesquisa de vistas, na Etapa 8,7, o incidente de segurança é 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 a conta do usuário estiver ativa, um e-mail automatizado será enviado ao usuário para reconfirmar 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) 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 Redefinir 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 sua 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 que o analista de segurança trabalhe com a respectiva equipe de TI para redefinir a senha dos usuários e prosseguir com o restante das etapas no playbook, após concluir a respectiva tarefa.
      2. Se o usuário responder Não, um e-mail automatizado será enviado ao usuário para reconfirmar 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 do recurso Criar solicitações de bloqueio para IPs e URLs mal-intencionados está disponível. Se a implementação de capacidade estiver disponível, o subfluxo Criar solicitações de bloco será executado. Se isso 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 Revisão .
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.