Eventos de segurança (SIEM)

O Status200 guarda os eventos de segurança ao lado dos seus logs, traces e métricas, e dá a cada um a mesma forma, OCSF (o Open Cybersecurity Schema Framework), seja qual for o formato em que chegou. Envie eventos de qualquer origem, pesquise-os e encontre os que importam com regras de detecção Sigma, inteligência de ameaças e monitores. O que eles encontram vira casos a tratar, e os playbooks respondem a eles.

Como funciona#

Abra Produtos → Security Events, em Observabilidade. O menu dele tem uma seção para cada parte da segurança, e uma página própria para cada coisa nela:

Detections, IA e Connections, configuradas uma vez, ficam recolhidas até você abri-las. Novo na segurança? Primeiros passos com a segurança a configura em dois cliques.

Antes de começar#

Os dados de segurança só são lidos pelos papéis Project Owner e Project Admin e pelos três papéis de segurança; os outros papéis não veem nada em Security Events. Veja Papéis.

Enviar eventos de segurança#

1. Crie uma chave de ingestão#

   Abra Configurações do projeto → Telemetria e APM → Chaves de ingestão e clique em Criar chave de ingestão. Os eventos de segurança usam as mesmas chaves que o resto da sua telemetria.

2. Envie os seus eventos#

   Envie JSON para /security-events/v1/ingest com a chave em x-status200-token:

   OCSFGoogle UDMGeneric JSON

   OCSF

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=ocsf" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -H "x-status200-service-name: my-security-source" \
     -d '{ "events": [ { "class_uid": 3002, "severity_id": 4, "status": "Failure", "message": "Failed logon for alice", "actor": { "user": { "name": "alice" } }, "src_endpoint": { "ip": "203.0.113.7", "hostname": "laptop-alice" } } ] }'

   Google UDM

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=udm" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "metadata": { "event_type": "USER_LOGIN" }, "principal": { "hostname": "laptop-alice", "user": { "userid": "alice" }, "ip": ["203.0.113.7"] }, "security_result": [{ "severity": "HIGH", "action": ["BLOCK"] }] } ] }'

   Generic JSON

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "severity": "high", "event_type": "ssh_brute_force", "message": "12 failed SSH logins in 60s", "username": "root", "hostname": "web-01", "src_ip": "203.0.113.7" } ] }'

   O endpoint responde 200 assim que os eventos entram na fila. Um evento enviado sem hora, como estes, é colocado no momento em que chega.

3. Encontre-os em Eventos#

   Abra Produtos → Security Events → Eventos. Os eventos aparecem em poucos segundos, com gravidade, classe, usuário, host e endereços IP preenchidos.

Formatos#

Informe o formato com ?format=, com o cabeçalho x-oneuptime-security-event-format ou com um campo "format" de nível superior. Se você o omitir, o formato de cada evento é descoberto separadamente, então um mesmo webhook pode misturar detecções com eventos brutos.

• O corpo pode ser um evento, um array de eventos ou { "events": [...] }.
• O cabeçalho x-status200-service-name nomeia o serviço de telemetria ao qual os eventos pertencem. Sem ele, pertencem ao serviço com o nome do produto ou do fornecedor do primeiro evento, ou a Security Events.
• Nada é descartado por não ter sido mapeado: cada campo da origem chega aos atributos do evento.

Campos de JSON genérico#

Um evento genérico é lido por nomes de campo comuns:

Uma palavra de gravidade vira um nível OCSF: info é lido como Informational, warning como Low, error como Medium, alert como Critical e emergency como Fatal.

Encaminhe com o Fluent Bit#

Para enviar logs de segurança que você já coleta, como os do auditd, do syslog ou do Falco, adicione ao Fluent Bit uma saída http:

[OUTPUT]
    Name             http
    Match            security.*
    Host             status200.ru
    Port             443
    tls              On
    URI              /security-events/v1/ingest
    Format           json
    Json_date_key    timestamp
    Json_date_format iso8601
    Header           x-status200-token YOUR_INGESTION_TOKEN
    Header           x-status200-service-name my-security-source
    Retry_Limit      5

A página Guia de configuração, em Connections, tem esses trechos com o seu próprio host e a sua chave já preenchidos.

Encontrar eventos de segurança nos seus logs#

O cartão Seus logs, no topo de Connections, transforma em uma origem os logs que você já envia ao Status200. Com Encontrar eventos de segurança nos seus logs ativado, os logs novos do projeto são lidos a cada minuto, e cada login SSH, comando sudo, registro de auditoria do Kubernetes, mudança no AWS CloudTrail e ataque web que eles contêm é salvo como evento de segurança. Consulte Primeiros passos com a segurança para saber o que cada tipo cobre.

Conecte um produto de segurança#

Connections consulta um produto de segurança por você e importa os registros novos dele como eventos de segurança. Uma conexão guarda as configurações do produto e uma credencial criptografada; um worker a consulta no intervalo que você define e pula os registros que já importou.

• Os alertas do próprio produto no nível de Open Cases From ou acima (Alta e acima, a menos que você escolha outro nível, ou Nunca) abrem casos, agrupados pelo usuário, host ou endereço de que tratam.
• Uma conexão lê os registros pelo momento em que o produto os criou, não pelo momento da atividade que descrevem. Uma regra de SIEM que roda de hora em hora cria detecções muito depois dos eventos correspondentes, e mesmo assim elas são importadas.
• A primeira consulta olha 24 horas para trás, então uma conexão nova mostra registros recentes na hora.
• Testar conexão, na linha da conexão, verifica o acesso ao produto e se os workers do próprio Status200 estão rodando, sem importar nada. Run now consulta na hora.

O que um evento contém#

Cada evento é salvo com campos tipados e o payload de origem:

Explorar os eventos de segurança#

Eventos é um explorador de telemetria como os de logs e traces: um gráfico dos eventos da janela por gravidade, uma barra lateral de facetas, a lista e um painel com cada campo e atributo do evento que você abrir. A janela, os filtros e a pesquisa ficam todos na URL, então uma visualização filtrada pode ser compartilhada e sobrevive a um recarregamento.

Pesquisa#

A barra de pesquisa fala a mesma linguagem dos outros exploradores de telemetria (veja Sintaxe de pesquisa):

Um campo é um nome curto (severity, class, category, activity, status, vendor, product, rule, user, host, ip, targetuser, targethost, targetip, processname, commandline, parentprocessname, observable, tactic, technique) ou o nome próprio do campo, como severityName ou principalHost. Qualquer outro nome é lido como atributo de origem. observable:<value> encontra cada evento que menciona um valor, de qualquer lado da atividade em que ele estivesse.

Facetas#

A barra lateral conta os eventos da janela por Origem, Gravidade, Classe de evento, Category, Atividade, Status, Fornecedor, Produto, Detection Rule, Usuário de origem, Host de origem, Processo e Processo pai. Clique em um valor para manter só os eventos dele, ou no sinal de menos ao lado para excluí-los. Clique de novo para desfazer. O gráfico e cada contagem descrevem exatamente os eventos da lista.

Correlacionar#

Correlacionar desenha os eventos em torno de um host, um usuário ou um endereço IP: as classes de evento deles em torno do que você pesquisou, marcadas pela pior gravidade, e os outros valores vistos nos mesmos eventos no anel externo. Clique em uma classe para listar os eventos dela, ou em um valor para correlacionar a partir dele. Cada observable no painel de um evento em Eventos abre Correlacionar sobre ele.

Regras de detecção#

Uma regra de detecção é uma regra Sigma, um formato YAML aberto para descrever atividade suspeita, que o Status200 roda em uma programação sobre os seus eventos. Quando corresponde, ela abre um caso ou entra em um já aberto, abre um alerta, opcionalmente um incidente, e grava um Detection Finding de volta nos eventos. A Rule Library tem regras prontas para começar.

Crie uma regra#

Uma primeira regra, que corresponde a logins com falha vindos de fora de 10.x.x.x:

title: Failed logon burst
description: Repeated authentication failures from one source.
level: high
tags:
  - attack.t1110
  - attack.ta0006
detection:
  selection:
    className: Authentication
    statusName: Failure
  filter_internal:
    principalIp|startswith: '10.'
  condition: selection and not filter_internal

O que uma regra pode dizer#

O Status200 roda o núcleo booleano do Sigma:

• As seleções são mapas de campos (cada campo precisa corresponder; uma lista de valores corresponde a qualquer um deles) ou listas de palavras-chave, que correspondem em qualquer parte da mensagem.
• As condições combinam seleções com and, or, not e parênteses, ou com 1 of selection_*, all of selection_*, any of them e all of them.
• Modificadores de campo: contains, startswith, endswith, all, re, cased, gt, gte, lt, lte, cidr, exists e windash. O texto é comparado sem diferenciar maiúsculas, a menos que você acrescente cased.
• Um campo é um campo tipado (principalUser), uma grafia Sigma comum de um deles (CommandLine, src_ip, Hostname) ou qualquer chave de atributo, escrita como está no evento (threat.matched).
• Image e CommandLine leem o processo de que o evento trata, o que foi iniciado na inicialização de um processo (processPath, processCommandLine), e ParentImage e ParentCommandLine o processo que o iniciou (parentProcessPath, parentProcessCommandLine). principalProcess é o processo que agiu, que em uma inicialização é o processo pai.
• level define a gravidade: informational, low, medium, high ou critical, e medium quando falta. Os IDs ATT&CK em tags (attack.t1110, attack.ta0006) preenchem os campos MITRE do achado.

Agregações como | count() by principalIp > 5 são recusadas ao salvar: use uma regra de correlação, ou Group By Field e Match Count Threshold. logsource é apenas informativo e não restringe nada: coloque esse filtro em uma seleção, como className: Authentication. Um timeframe é ignorado, porque o intervalo da regra define a janela dela.

Regras de correlação#

Uma correlação do Sigma dispara com vários eventos juntos, e não com um só. Cole-a em Sigma Rule (YAML) com as regras que ela lê, como documentos YAML separados por ---, ou cite regras que o projeto já tem pelo name ou pelo id do Sigma. A Rule Library tem algumas prontas, como logins com falha seguidos de um bem-sucedido.

title: Failed sign-ins, then a success from the same address
level: high
correlation:
  type: temporal_ordered
  rules:
    - failed_sign_ins
    - successful_sign_in
  group-by:
    - principalIp
  timespan: 10m
---
title: Five failed sign-ins
name: failed_sign_ins
correlation:
  type: event_count
  rules:
    - failed_sign_in
  group-by:
    - principalIp
  timespan: 10m
  condition:
    gte: 5
---
title: Failed sign-in
name: failed_sign_in
detection:
  selection:
    className: Authentication
    statusName: Failure
  condition: selection
---
title: Successful sign-in
name: successful_sign_in
detection:
  selection:
    className: Authentication
    statusName: Success
  condition: selection

• Um grupo é o valor dos campos de group-by, como um endereço. As contagens são móveis: uma rajada que duas execuções dividem ainda é contada inteira dentro do seu timespan, que é de no máximo 24 horas.
• new_value é um tipo próprio do Status200, já que o Sigma não tem uma correlação de "visto pela primeira vez": ele compara com até 30 dias de histórico. value_sum, value_avg, value_percentile e value_median são recusados ao salvar.
• A coluna Tipo de Detection Rules nomeia o tipo de cada regra, e o formulário diz em uma frase o que a regra procura.

Configurações de avaliação#

O agrupamento e a contagem distinta aceitam os mesmos nomes de campo que a regra. Com eles, o limite diz "tantos, da mesma coisa, em uma execução", sem um monitor por cima:

Quando uma regra roda#

O Status200 verifica a cada minuto quais regras habilitadas já passaram do intervalo desde a última execução. Cada execução lê os eventos cujo horário do evento cai entre a execução anterior e dois minutos atrás, e depois avança. Os dois minutos dão tempo aos eventos que ainda estão a caminho, como uma linha de log lida um minuto depois de escrita:

• As janelas vêm uma depois da outra, não deslizam. Com um intervalo de 10 minutos, falhas às 09:58 e às 10:01 podem cair em execuções diferentes e são contadas separadamente, então deixe folga ao escolher um limite.
• Depois de uma lacuna, como uma queda do worker ou uma regra reativada, a próxima execução cobre a lacuna inteira, até as últimas 24 horas.
• Um evento que chega com mais de dois minutos de atraso, depois que uma execução já cobriu o seu horário, é salvo e pode ser pesquisado, mas essa regra nunca o lê.
• Cada grupo que atinge o limite vira um Detection Finding, até 10.000 por execução. Alertas, incidentes e casos abrem para os 100 com as contagens mais altas; o restante compartilha um caso sobre a regra, e o Último erro da regra diz quantos grupos corresponderam.

Gravidade#

O level de uma regra é a gravidade dos achados dela: informational, low, medium, high e critical viram Informational, Low, Medium, High e Critical. Os alertas e incidentes dela recebem uma das severidades do seu projeto, nesta ordem:

1. A Severidade do alerta (ou Severidade do incidente) da regra, quando definida.
2. A sua severidade com o nome do nível, como High, sem diferenciar maiúsculas.
3. Por posição: as regras critical e high recebem a sua severidade mais alta, as outras a mais baixa.

Alertas e achados#

Cada grupo que dispara abre um alerta com o título [Detection] <rule name> — <group value>, ou [Detection] <rule name> para uma regra sem campo de agrupamento. Enquanto ele está aberto, mais correspondências desse grupo não abrem outro. Uma regra só vê correspondências e não consegue saber que um ataque parou, então os alertas dela ficam abertos até alguém resolvê-los.

Um Detection Finding é um evento de segurança da classe Detection Finding (classe OCSF 2004) do produto Status200 Detections, com as tags MITRE da regra, o valor do grupo em primeiro lugar em observables e estes atributos:

Os achados são eventos comuns: pesquise-os em Eventos e faça pivô sobre eles em Correlacionar. Para testar uma regra nova em silêncio, desative todas as ações menos o achado até confiar nela.

Monitores de eventos de segurança#

Um monitor de eventos de segurança conta os eventos que correspondem aos filtros dele em uma janela deslizante e aplica à contagem os critérios habituais de monitor: muda o status do monitor, abre alertas ou incidentes e aciona o plantão. Crie um em Monitores → Criar monitor, com Security Events como tipo; ele aparece lá junto com seus outros monitores.

O formulário dele mostra Monitor events that include this text, Monitor Security Events for (time), Event Severity e Classe de evento. Filtrar por serviço de telemetria e Filtrar por atributos ficam em Mais campos, cujo cabeçalho mostra os que um monitor usa. Os critérios dele verificam Security Event Count.

Escreva a detecção em si como uma regra, com o limite dela. Use um monitor quando quiser uma janela deslizante, um status que se recupera sozinho, uma página de status ou políticas de plantão diferentes por critério.

Vigie as suas detecções#

Os achados são eventos, então um monitor pode vigiar as próprias regras:

• Tempestades: um monitor sobre a classe Detection Finding, contando cada achado. Vinte regras diferentes disparando em uma hora são um sinal que nenhuma regra sozinha consegue ver.
• Mudanças de ritmo: filtre pelo status200.detection.rule_id de uma regra. Uma regra que dispara toda semana e de repente cinquenta vezes por hora pede outra resposta.
• Silêncio: achados que caem a zero, quando você normalmente vê alguns, costumam significar que uma origem parou de enviar. Use um critério que verifique uma contagem abaixo de um número.

A ação Criar monitor na linha de uma regra abre um monitor novo já configurado assim: a classe Detection Finding, o ID da regra (nunca o nome dela, que uma renomeação mudaria) e a última hora. Um monitor assim conta achados, um por grupo por execução, não os eventos por trás deles. Para exigir um número de eventos antes que qualquer coisa dispare, use o Match Count Threshold da regra.

Inteligência de ameaças#

Threat Intel assina feeds STIX/TAXII de endereços IP, domínios, URLs, endereços de e-mail e hashes de arquivos maliciosos conhecidos. Os eventos que mencionam um deles são marcados na chegada com atributos threat.*, pelos quais regras e monitores podem filtrar, e a cada minuto os eventos recentes são comparados com os feeds, abrindo alertas e achados como uma regra faz. Veja Inteligência de ameaças.

Retenção e cobrança#

Os eventos de segurança são cobrados por GB ingerido, como o resto da sua telemetria, e mantidos pela sua retenção de telemetria: a Retenção Padrão (Dias) do projeto, em Configurações do projeto → Telemetria e APM → Retenção de dados, ou uma retenção definida no serviço de telemetria ao qual pertencem. Quando a retenção de um evento termina, ele é excluído.

Solução de problemas#

Próximos passos#