Casos de segurança e playbooks (SOAR)

O Security Events transforma o que as suas regras de detecção, a inteligência de ameaças e os produtos de segurança conectados encontram em casos: um caso para cada coisa que vale a pena investigar, com todas as detecções sobre o mesmo usuário, host ou endereço agrupadas nele. Os analistas tratam os casos em uma fila, e os playbooks respondem a eles, sozinhos ou com um clique.

Como funciona#

Abra Produtos → Security Events → Casos de segurança → Casos abertos para a fila. Atribuídos a mim, Não atribuído, Casos fechados e Todos os casos são páginas próprias ao lado, cada uma listando os casos que o nome diz.

Antes de começar#

Os casos e os playbooks seguem os três papéis de segurança. Project Owner e Project Admin podem fazer tudo.

Cada uma dessas ações também pode ser concedida separadamente, de criar um caso a aprovar as etapas de um playbook; veja Referência de permissões.

De onde vêm os casos#

Todas as origens vêm ativadas por padrão. Uma conexão abre casos para Alta e acima, a menos que você escolha outro nível; os alertas abaixo dele continuam sendo importados como eventos.

Como as detecções são agrupadas#

Uma detecção é sobre uma entidade: o valor pelo qual a regra dela agrupa, como o endereço IP de uma regra de força bruta, ou o indicador que uma correspondência de inteligência de ameaças cita. Uma detecção sem entidade fica sozinha.

• Quando um caso aberto já é sobre essa entidade, a detecção entra nele. As entidades do caso e o mapeamento ATT&CK dele crescem, e a prioridade dele sobe até a da detecção, nunca desce.
• Quando nenhum caso aberto é sobre ela, um novo caso é aberto, com o nome e a prioridade da detecção.
• Uma detecção que dispara de novo aumenta a contagem na própria linha em vez de acrescentar outra.

A prioridade de um caso vem da gravidade da detecção:

Tratar um caso#

Um caso passa por quatro status. Ele pode pular um, como um falso positivo fechado direto de Novo, e pode ser reaberto.

A página do caso tem tudo para tratá-lo:

• No topo: Assign to Me, Run Playbook, Declarar incidente e Close Case, as etapas de status e, no menu ao lado, a prioridade.
• Status200 AI: o que o Status200 AI concluiu do caso, a prioridade e o playbook que ele sugere, e as evidências por trás. Veja Status200 AI na segurança.
• Detections: o que disparou para abrir o caso ou entrar nele, com que frequência, e o último evento correspondente.
• Entidades: os usuários, hosts e endereços de que o caso trata, com a atividade deles em todos os seus eventos de segurança dos últimos 7 dias. Cada um abre em Correlacionar.
• MITRE ATT&CK: as táticas e técnicas às quais as detecções dele correspondem, cada uma com um link para a própria página em attack.mitre.org.
• Execuções de playbooks: o que cada playbook fez no caso, etapa por etapa, e as etapas aguardando aprovação.
• Notas e Linha do tempo: o que a equipe escreveu, e tudo o que aconteceu, com quem fez.

Para tratar vários casos de uma vez, selecione-os na fila e use Assign to Me, Change Status ou Change Priority.

Fechar um caso#

Close Case pede um veredito e uma nota de fechamento opcional:

Os vereditos são contados na visão geral. Uma regra cujos casos continuam sendo fechados como False Positive é uma regra a ajustar.

Um caso aberto a partir de alertas do Google SecOps também os fecha no Google SecOps, com o veredito e a nota de fechamento, quando a conexão dele tem Fechar os alertas quando o caso deles for fechado ativado: veja Google SecOps.

Declarar um incidente#

Declarar incidente abre um incidente do Status200 para o caso, com a severidade que você escolher, e liga os dois nos dois sentidos: a descrição do incidente cita o caso, e o cabeçalho do caso tem um link para o incidente. A partir daí, o plantão, as páginas de status e o postmortem assumem. É preciso um papel que possa tanto tratar casos quanto criar incidentes.

Notificações#

O Status200 avisa as pessoas sobre três coisas em um caso. Ninguém precisa configurar nada: um projeto que só clicou em Ativar o recomendado fica sabendo dos seus casos High e Crítico por e-mail e push.

• Só são avisadas sobre um caso as pessoas que podem vê-lo: Project Owners, Project Admins e os papéis Security Admin, Security Member e Security Viewer. Um papel limitado a alguns rótulos só é avisado sobre os casos com esses rótulos.
• Ninguém é avisado sobre o que fez: a pessoa que abre um caso manualmente, o atribui ou inicia uma execução não é notificada disso.
• Cada pessoa fica sabendo de um caso uma vez só. Um caso que abre como Medium e depois sobe para Crítico chega, quando sobe, às pessoas que escolheram High ou Crítico, e não de novo às que escolheram Medium, que já souberam dele quando ele abriu.
• O ataque de teste de Enviar um ataque de teste abre um caso que não notifica ninguém.
• Um caso Crítico e uma etapa aguardando aprovação são enviados na hora, nunca retidos em um resumo de e-mails.
• A Linha do tempo do caso diz quem foi avisado, e quando.

Escolha sobre o que você é avisado#

Cada pessoa escolhe por si mesma, em Configurações do usuário → Configurações de notificação → Segurança: os canais de cada notificação (e-mail, SMS, chamada, push, Telegram, Slack, Microsoft Teams ou webhook) e, em Novo caso de segurança, a prioridade que a notifica:

Mensagens de WhatsApp não são enviadas para casos de segurança. Uma notificação push abre o app do Status200, e o link dela abre o caso no navegador.

Publique em canais do Slack e do Microsoft Teams#

Para publicar em um canal, adicione uma regra em Produtos → Security Events → Espaço de trabalho → Slack (ou Microsoft Teams). Sem nenhum dos dois conectado, a única entrada da seção é Conectar Slack ou Teams. Uma regra indica os canais em que publicar (e, no Microsoft Teams, os chats) e, se você quiser, os casos a que ela se aplica:

Cada uma das três notificações é publicada nos canais de todas as regras a que o caso corresponde naquele momento. Uma regra em que Prioridade do caso de segurança contém qualquer um de Crítico e High publica os casos High e Crítico assim que abrem, e um caso Medium quando ele sobe para High. Um caso de segurança nunca ganha um canal próprio.

Playbooks#

Um playbook é uma lista de etapas que rodam em um caso. Crie um em Produtos → Security Events → Playbooks, a partir de um modelo ou em branco, e adicione as etapas na página dele.

Quando um playbook roda#

Qualquer playbook habilitado também pode ser executado manualmente, com Run Playbook em um caso. Um playbook que roda sozinho pode ser restringido:

• For Cases At Least: só casos desta prioridade ou maior.
• Only For Detections From: só quando a detecção por trás do caso veio desta origem.
• Only For These Detection Rules: só quando ela veio de uma destas regras.

Um playbook desabilitado não roda nem sozinho nem manualmente.

Etapas#

Um playbook tem no máximo 25 etapas. Elas rodam em ordem, cada uma depois que a anterior termina. Cada etapa também pode:

• Needs Approval: parar a execução antes da etapa até que alguém a aprove no caso. As quatro etapas que cortam o acesso de alguém sempre param a execução, a menos que um Security Admin desative essa opção.
• Only If Threat Intel Matched: pular a etapa, a menos que uma etapa Check entities against threat intel anterior da mesma execução tenha encontrado um indicador conhecido.
• Carry On If It Fails: rodar a próxima etapa mesmo que esta falhe. Desativado, uma etapa com falha interrompe a execução.

Contenção#

As etapas de contenção agem por meio de uma conexão de eventos de segurança com o produto, que precisa de mais do que acesso de leitura:

Uma etapa de contenção age só nos usuários ou hosts de que o caso trata, nunca em todos os que ele cita:

• O valor pelo qual uma detecção do caso é agrupada, como a conta pela qual uma regra de viagem impossível agrupa, ou o host que o alerta de um produto conectado cita.
• Um usuário ou host do caso que a sua inteligência de ameaças conhece como indicador.

Um caso agrupado por um endereço, como um ataque de força bruta contra a sua VPN, não trata de nenhum dos dois: as etapas de contenção dele são puladas, e a conta tentada e o gateway atingido ficam intactos. Uma etapa age em no máximo 10 usuários ou hosts. Ela encontra cada um no produto pelo nome, e informa na execução o que fez com cada um: feito, já feito, não encontrado, recusado ou protegido.

Entidades protegidas#

Protected Entities, em Playbooks no menu, lista os usuários e hosts aos quais nenhum playbook aplica contenção, como contas de acesso de emergência, controladores de domínio e gateways de VPN. Um valor corresponde sem diferenciar maiúsculas de minúsculas, e * representa qualquer sequência de caracteres: svc-* protege todas as contas de serviço. Uma etapa informa um usuário ou host protegido como protegido e o deixa intacto. Os Security Admins mantêm a lista.

Aprovação#

As quatro etapas que cortam o acesso de alguém aguardam aprovação. Só um Security Admin pode desativar Needs Approval em uma delas, e o Status200 registra quem fez isso. A aprovação lista em Act On os usuários ou hosts em que a etapa agiria, todos marcados: desmarque os que ela deve deixar intactos. Os protegidos não são oferecidos. Quem iniciou uma execução não pode aprovar as etapas dela: outra pessoa faz isso, mas quem a iniciou ainda pode rejeitá-las.

Desfazer#

As etapas de reversão agem nos usuários ou hosts de que o caso trata, como as etapas que elas revertem. Depois que a execução parar, um usuário ou host contido também tem um botão próprio na etapa dele: Unsuspend, Lift Containment ou Liberar. Uma sessão do Okta encerrada não pode ser desfeita. Cada reversão fica guardada na linha do tempo do caso e no registro de auditoria do projeto.

Mensagens#

Uma nota, um e-mail, uma publicação no Slack e uma publicação no Teams podem usar os valores do caso:

Um e-mail ou uma publicação sem mensagem própria envia um resumo do caso.

Execuções e aprovações#

Cada execução aparece no caso dela e em Produtos → Security Events → Playbooks → Execuções de playbooks, etapa por etapa:

Uma etapa aguardando aprovação mostra Approve e Reject na execução, com um comentário opcional. Aprovar faz a execução seguir a partir dessa etapa; rejeitar a encerra. A decisão, quem a tomou e o comentário que deixou ficam guardados na etapa, na linha do tempo do caso e no registro de auditoria do projeto. Aguardando aprovação, em Playbooks no menu, lista as execuções que aguardam uma decisão e as conta; Execuções de playbooks lista todas as execuções.

Uma execução que deixa de receber sinais do worker dela, depois de uma reinicialização, por exemplo, é retomada: uma execução na fila volta para a fila depois de 2 minutos, e uma execução que não dá sinal por 30 minutos é marcada como falha.

A visão geral#

Produtos → Security Events → Visão geral é onde o produto abre:

• Os casos abertos atribuídos a você, os casos abertos que ninguém assumiu, e as etapas de playbooks aguardando aprovação, cada um abrindo a página que os lista.
• Tempo médio para reconhecer, Tempo médio para conter e Tempo médio para fechar, sobre os casos abertos nos últimos 30 dias: da abertura de um caso até alguém assumi-lo (atribuindo-o a uma pessoa, ou tirando-o de Novo), até Contained e até Fechado. Um caso que ainda está esperando não entra na média.
• Os casos abertos a cada dia, nos últimos 30 dias, por prioridade, e as detecções geradas a cada dia, nos últimos 14 dias, por origem.
• Os casos abertos por prioridade e por status, os vereditos dos últimos 30 dias, as táticas ATT&CK por trás dos casos, as detecções que mais dispararam e as entidades citadas pelo maior número de achados.

Acima, uma faixa mostra como a segurança está configurada: suas origens, detecções, casos e playbooks, cada um com seus números. Um projeto que ainda não a configurou vê ali Ativar o recomendado e Enviar um ataque de teste; consulte Primeiros passos com a segurança. Quando nada precisa de ninguém, a página diz Tudo tranquilo, e os gráficos aparecem assim que há algo para mostrar.

Encontrar ameaças#

• Entidades classifica os usuários, hosts, endereços e hashes que os seus achados mais citam, no último dia, semana ou mês, e procura qualquer valor em 30 dias de eventos.
• Rule Library tem regras de detecção prontas, para ameaças de identidade, endpoint, nuvem, rede, web e Kubernetes. Cada uma é uma regra Sigma escrita para os campos para os quais toda origem conectada é normalizada. Adicionar regra a cria como uma regra de detecção sua, ativada e abrindo casos em vez de alertas; altere-a em Detection Rules como qualquer outra. As regras marcadas como Recomendados encontram ameaças em dados que o Status200 já tem, e um botão adiciona as que você ainda não tem.
• ATT&CK Coverage desenha a matriz MITRE ATT&CK com as técnicas cobertas pelas suas regras habilitadas em destaque, e contorna as que uma regra da biblioteca cobriria.

Automatizar#

• Fluxos de trabalho: criar, atualizar ou excluir um caso ou uma nota pode iniciar um fluxo de trabalho. Uma etapa Run a workflow inicia um fluxo de trabalho cujo gatilho é um webhook.
• API: casos, notas, detecções, playbooks, execuções e entidades protegidas têm a mesma API REST que o resto do Status200, em /security-case, /security-case-note, /security-detection, /security-playbook, /security-playbook-run e /security-protected-entity. Veja Referência da API.
• Agentes de IA: o servidor MCP tem ferramentas para casos, notas, detecções e playbooks. Veja Servidor MCP.

Solução de problemas#

Próximos passos#