Bloquear atacantes automaticamente a partir de detecções do SIEM

Uma equipe de SOC detecta ameaças no seu SIEM mas aplica bloqueios à mão, então um atacante continua alcançando as aplicações entre a detecção e a mitigação. O firewall já roda WAF, e os seus eventos já chegam ao SIEM, mas nada leva uma decisão de volta. Esta página configura uma network list que uma regra de firewall nega, a chamada que um playbook de SIEM ou SOAR envia para adicionar um endereço a ela com uma expiração e o job que remove os itens expirados. O resultado é medido pelo tempo entre a detecção e o bloqueio e pela parcela de incidentes mitigados sem passos manuais.

Este caso de uso não cobre a lógica de detecção em si, que fica no SIEM da equipe.

Pré-requisitos

• Um firewall vinculado ao workload de cada aplicação a proteger, com WAF aplicado por uma regra. Para montar um, consulte Primeiros passos com WAF.
• Um stream dos eventos do WAF para o SIEM. Para criá-lo, consulte Envie eventos do WAF para um SIEM.
• Um personal token para o playbook, criado por um usuário cuja equipe tem a permissão Edit Network Lists. Para criar um, consulte Gerencie personal tokens, e para a permissão, consulte Permissões.
• Uma plataforma de SIEM ou SOAR que consiga enviar uma requisição HTTPS a partir de um playbook e executar um job de forma agendada.
• Os valores do seu ambiente. Esta página usa siem-blocklist como lista, 192.0.2.10 como um endereço que a sua equipe bloqueia permanentemente, 198.51.100.23 como um endereço que uma detecção sinaliza, DET-4471 como o ID da detecção e www.example.com como domínio. Substitua cada valor pelo seu em todos os passos.

Produtos necessários

Arquitetura de referência

Esta página constrói o loop de mitigação no firewall orientado pelo SIEM: os eventos saem do firewall para o SIEM, e uma detecção volta como um item em uma network list que uma regra de firewall já aplica.

Leia o diagrama como um loop que começa e termina no firewall. Os eventos saem dele pelo Data Stream, a decisão é tomada no SIEM, e a decisão volta como dado, um item em siem-blocklist, nunca como uma regra nova. A regra que lê a lista existe antes de qualquer detecção, então o loop altera o que o firewall corresponde sem alterar a sua configuração. O job de expiração fecha o loop pelo outro lado, encerrando cada bloqueio quando o seu prazo passa.

Fluxo de dados

1. As requisições do atacante chegam ao firewall. O WAF as pontua, e o Data Stream envia os eventos do WAF ao SIEM.
2. Uma detecção no SIEM inicia um playbook de SOAR, que lê siem-blocklist, adiciona o endereço do atacante com uma data de vencimento e grava a lista de volta pela API.
3. A regra de negação já lê siem-blocklist, então as próximas requisições desse endereço recebem 403 assim que a alteração chega ao tráfego, em cerca de 100 segundos.
4. Uma lista pode ser lida por regras em vários firewalls, então uma gravação bloqueia o endereço em toda aplicação que esses firewalls protegem.
5. Um job agendado grava os itens da lista de volta, e a plataforma descarta todo item cuja data de vencimento passou, o que encerra esse bloqueio.

Componentes

• Data Stream: exporta os eventos do WAF do firewall para o endpoint que o SIEM lê, que é onde o loop começa.
• SIEM ou SOAR: a integração que guarda a lógica de detecção e executa o playbook que transforma uma detecção em uma atualização da lista.
• API e Terraform Provider: os Platform Resources pelos quais o playbook atualiza a lista. A API substitui os itens da lista a cada gravação, e o Terraform Provider gerencia a lista como um recurso.
• Network Shield: adiciona o critério Network que compara cada endereço de cliente com a lista, e guarda a lista com uma data de vencimento e um comentário em cada item.
• firewall: o Platform Resource que aplica o bloqueio. A sua regra de negação na lista roda antes do WAF, então um endereço listado é recusado antes de ser pontuado.
• WAF: a fonte dos eventos. Os seus scores, as regras correspondidas e as actions são o que as detecções do SIEM leem.

Configure a lista e a regra que a aplica

A regra existe antes de qualquer detecção, então um playbook nunca cria nem altera uma regra. Uma alteração nos itens de uma lista chega ao tráfego em cerca de 100 segundos, enquanto uma regra nova leva de 6 a 10 minutos, e uma lista não soma nada às regras que o seu plano inclui por firewall. A regra ocupa a primeira posição no firewall, então um endereço listado é recusado antes que o WAF o pontue.

A lista começa com um item sem data de vencimento, 192.0.2.10. Uma gravação em que todos os itens estão vencidos é recusada com 22019, então um item sem data mantém a lista gravável depois que todas as detecções expiraram.

Todo endereço em siem-blocklist recebe 403 assim que a regra se propaga, de 6 a 10 minutos depois de salva. Para proteger várias aplicações, adicione a mesma regra a cada um dos seus firewalls: toda regra lê a mesma lista, então uma gravação bloqueia o endereço em todos eles.

Configure a gravação do playbook na lista

O playbook envia duas chamadas para cada detecção: ele lê a lista e depois a grava de volta com o item novo. Um PATCH que envia items substitui o array inteiro, então um playbook que enviasse só o endereço novo removeria todos os outros itens, inclusive o permanente.

Cada item novo carrega duas anotações. A data de vencimento, --LT seguido de uma data e hora UTC em segundos inteiros, marca quando o bloqueio termina, e esta página usa 24 horas depois da detecção. O comentário, # seguido do ID da detecção, diz a um analista por que o endereço está ali.

1. O SIEM gera uma detecção para 198.51.100.23 e inicia o playbook.
2. O playbook lê os itens atuais de siem-blocklist.
3. O playbook adiciona 198.51.100.23 --LT<due-date> #DET-4471 a esses itens e grava o array inteiro de volta.
4. A API responde 200 e armazena os itens. O firewall nega o endereço assim que a alteração chega ao tráfego.

O playbook envia a leitura e a gravação que Atualize uma network list a partir de uma automação descreve para adicionar um item, com estes valores:

• Lista: siem-blocklist, que guarda o item permanente 192.0.2.10 #permanent block.

• Item novo: o endereço detectado, uma data de vencimento 24 horas depois da detecção e o ID da detecção como comentário.

• Gravação: para DET-4471, com 2030-01-01T00:00:00Z no lugar do horário da detecção mais 24 horas, o corpo de PATCH /v4/workspace/network_lists/<network-list-id> é:

  {"items":["192.0.2.10 #permanent block","198.51.100.23 --LT2030-01-01T00:00:00Z #DET-4471"]}

A API responde 200 e armazena os itens exatamente como foram enviados. O playbook valida cada item antes de enviar o array, porque uma gravação recusada nomeia só o primeiro item inválido.

O Azion Terraform Provider também gerencia uma network list, como o recurso azion_network_list. Para os seus argumentos, consulte Recursos de segurança.

Configure o job de expiração

Uma data de vencimento nunca remove um item sozinha. A plataforma lê as datas de vencimento só quando os itens de uma lista são gravados: cada gravação descarta os itens já vencidos, e um item cuja data passa depois da gravação continua correspondendo. O job de expiração é essa gravação, enviada de forma agendada. Ele lê os itens e envia os mesmos itens de volta, e a plataforma descarta os expirados.

O agendamento define por quanto tempo um item expirado continua bloqueando. Esta página executa o job a cada hora, então um bloqueio termina no máximo uma hora depois da sua data de vencimento. Uma detecção que dispara de novo antes de o job rodar mantém o endereço listado: a gravação do playbook carrega uma nova data de vencimento para ele.

O job envia a leitura e a gravação sem alterações que Atualize uma network list a partir de uma automação descreve, com estes valores:

• Lista: siem-blocklist. O item permanente 192.0.2.10 #permanent block não carrega data de vencimento, então a gravação do job nunca é recusada por ter só itens expirados.

• Agendamento: a cada hora, pelo agendador da plataforma de SIEM ou SOAR.

• Gravação: depois da data de vencimento de DET-4471, escrita abaixo como <past-due-date>, o corpo do PATCH é:

  {"items":["192.0.2.10 #permanent block","198.51.100.23 --LT<past-due-date> #DET-4471"]}

A API responde 200 e armazena só 192.0.2.10 #permanent block. O endereço volta a receber as respostas da aplicação assim que a alteração chega ao tráfego.

Verifique a configuração

Uma alteração nos itens de uma lista chega ao tráfego de 46 a cerca de 100 segundos depois da gravação, e as respostas se alternam até ela se estabilizar. Repita cada requisição até a resposta se manter.

• Uma detecção vira um bloqueio. Execute o playbook para uma detecção de teste em um endereço que você controla e depois requisite a aplicação a partir desse endereço:

  curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/

  O comando imprime 403 em até cerca de 100 segundos depois da gravação do playbook.

• A gravação manteve todos os outros itens. Leia a lista com o GET da gravação do playbook. Os seus items guardam o item permanente, toda detecção anterior ainda em vigor e o item novo.

• Um bloqueio expirado termina. Dê a um item de teste uma data de vencimento alguns minutos à frente, espere ela passar e execute o job de expiração. A gravação do job retorna os itens sem esse item, e o mesmo curl a partir desse endereço volta a imprimir o status da aplicação.

• Os eventos chegam ao SIEM. No Real-Time Events, a fonte de dados Data Stream lista cada envio do stream do WAF, e um Status Code 200 significa que o endpoint do SIEM aceitou o lote.

Medindo resultados

Boas práticas

• Dê um único dono à lista. Cada gravação substitui o array inteiro e sobrescreve todos os outros editores, então a edição de um analista no Azion Console entre a leitura e a gravação do playbook se perde. Mantenha os bloqueios manuais em uma lista própria, com a sua própria regra.
• Dê ao playbook o seu próprio usuário e token. Last Editor nomeia o usuário cujo token gravou a lista, então as gravações do playbook e as de pessoas ficam separadas, e o token pode ser revogado sem mexer no acesso de ninguém.
• Coloque uma data de vencimento em todo item automatizado. Um item sem data de vencimento bloqueia até alguém removê-lo, e uma lista que um playbook preenche cresce a cada detecção. A data de vencimento faz cada bloqueio automatizado terminar sozinho, na próxima execução do job de expiração.
• Escreva o ID da detecção no comentário. O comentário é armazenado com o item e exibido na lista, então um analista que recebe uma reclamação de um cliente bloqueado encontra a detecção por trás dela.
• Nunca grave as listas mantidas pela Azion. Qualquer gravação em Azion IP Tor Exit Nodes é recusada com 22004. Referencie-a a partir de uma regra própria e mantenha os endereços do playbook em siem-blocklist.

Guias deste caso de uso