Eventi di sicurezza (SIEM)

Status200 conserva gli eventi di sicurezza accanto ai tuoi log, tracce e metriche, e dà a ciascuno la stessa forma, OCSF (l'Open Cybersecurity Schema Framework), qualunque sia il formato in cui è arrivato. Invia eventi da qualsiasi origine, cercali e trova quelli importanti con regole di rilevamento Sigma, threat intelligence e monitor. Ciò che trovano diventa casi da gestire, e i playbook vi rispondono.

Come funziona#

Apri Prodotti → Security Events, sotto Osservabilità. Il suo menu ha una sezione per ogni parte della sicurezza, e una pagina a sé per ogni cosa che contiene:

Detections, IA e Connections, che si configurano una volta, restano chiuse finché non le apri. Nuovo alla sicurezza? Primi passi con la sicurezza la configura in due clic.

Prima di iniziare#

I dati di sicurezza li leggono solo i ruoli Project Owner e Project Admin e i tre ruoli di sicurezza; gli altri ruoli non vedono nulla in Security Events. Vedi Ruoli.

Inviare eventi di sicurezza#

1. Crea una chiave di ingestione#

   Apri Impostazioni del progetto → Telemetria e APM → Chiavi di acquisizione e fai clic su Crea chiave di ingestione. Gli eventi di sicurezza usano le stesse chiavi del resto della tua telemetria.

2. Invia i tuoi eventi#

   Invia JSON a /security-events/v1/ingest con la chiave in 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" } ] }'

   L'endpoint risponde 200 appena gli eventi sono in coda. Un evento inviato senza orario, come questi, viene collocato nel momento in cui arriva.

3. Trovali in Eventi#

   Apri Prodotti → Security Events → Eventi. Gli eventi compaiono in pochi secondi, con gravità, classe, utente, host e indirizzi IP compilati.

Formati#

Indica il formato con ?format=, con l'intestazione x-oneuptime-security-event-format o con un campo "format" di primo livello. Se lo ometti, il formato di ogni evento viene ricavato a parte, così un webhook può mescolare rilevamenti ed eventi grezzi.

• Il corpo può essere un evento, un array di eventi o { "events": [...] }.
• L'intestazione x-status200-service-name nomina il servizio di telemetria a cui appartengono gli eventi. Senza di essa, appartengono al servizio che prende il nome dal prodotto o dal fornitore del primo evento, oppure a Security Events.
• Nulla viene scartato perché non si è riusciti a mapparlo: ogni campo dell'origine arriva negli attributi dell'evento.

Campi del JSON generico#

Un evento generico viene letto tramite nomi di campo comuni:

Una parola di gravità diventa un livello OCSF: info si legge come Informational, warning come Low, error come Medium, alert come Critical ed emergency come Fatal.

Inoltrare con Fluent Bit#

Per inviare log di sicurezza che già raccogli, come quelli di auditd, syslog o Falco, aggiungi a Fluent Bit un output 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

La pagina Guida alla configurazione, sotto Connections, contiene questi frammenti con il tuo host e la tua chiave già compilati.

Trovare eventi di sicurezza nei tuoi log#

La scheda I tuoi log, in cima a Connections, rende una sorgente i log che invii già a Status200. Con Trova eventi di sicurezza nei tuoi log attivo, i nuovi log del progetto vengono letti ogni minuto, e ogni accesso SSH, comando sudo, voce di audit di Kubernetes, modifica di AWS CloudTrail e attacco web che contengono viene salvato come evento di sicurezza. Vedi Primi passi con la sicurezza per cosa copre ciascun tipo.

Collegare un prodotto di sicurezza#

Connections interroga per te un prodotto di sicurezza e ne importa i nuovi record come eventi di sicurezza. Una connessione contiene le impostazioni del prodotto e una credenziale cifrata; un worker la interroga all'intervallo che imposti e salta i record già importati.

• Gli avvisi propri del prodotto di livello pari o superiore a Open Cases From (Alta e superiori a meno che tu non scelga un altro livello, oppure Mai) aprono casi, raggruppati per l'utente, l'host o l'indirizzo che riguardano.
• Una connessione legge i record in base al momento in cui il prodotto li ha creati, non al momento dell'attività che descrivono. Una regola SIEM che gira ogni ora crea rilevamenti molto dopo gli eventi corrispondenti, e vengono comunque importati.
• La prima interrogazione guarda indietro di 24 ore, così una nuova connessione mostra subito i record recenti.
• Testa la connessione, nella riga della connessione, verifica l'accesso al prodotto e che i worker di Status200 siano in funzione, senza importare nulla. Run now interroga subito.

Cosa contiene un evento#

Ogni evento viene salvato con campi tipizzati e il suo payload di origine:

Esplorare gli eventi di sicurezza#

Eventi è un esploratore di telemetria come quelli di log e tracce: un grafico degli eventi della finestra per gravità, una barra laterale di facet, l'elenco e un pannello con ogni campo e attributo dell'evento che apri. La finestra, i filtri e la ricerca stanno tutti nell'URL, così una vista filtrata si può condividere e sopravvive a un ricaricamento.

Ricerca#

La barra di ricerca parla la stessa lingua degli altri esploratori di telemetria (vedi Sintassi di ricerca):

Un campo è un nome breve (severity, class, category, activity, status, vendor, product, rule, user, host, ip, targetuser, targethost, targetip, processname, commandline, parentprocessname, observable, tactic, technique) oppure il nome proprio del campo, come severityName o principalHost. Qualsiasi altro nome viene letto come attributo di origine. observable:<value> trova ogni evento che menziona un valore, da qualunque lato dell'attività si trovasse.

Facet#

La barra laterale conta gli eventi della finestra per Origine, Gravità, Classe di eventi, Category, Attività, Stato, Fornitore, Prodotto, Detection Rule, Utente di origine, Host di origine, Processo e Processo padre. Fai clic su un valore per tenere solo i suoi eventi, o sul segno meno accanto per escluderli. Fai di nuovo clic per annullare. Il grafico e ogni conteggio descrivono esattamente gli eventi dell'elenco.

Correla#

Correla disegna gli eventi intorno a un host, un utente o un indirizzo IP: le loro classi di eventi intorno a ciò che hai cercato, marcate con la gravità peggiore, e gli altri valori visti negli stessi eventi sull'anello esterno. Fai clic su una classe per elencarne gli eventi, o su un valore per correlare su di esso. Ogni observable nel pannello di un evento in Eventi apre Correla su di esso.

Regole di rilevamento#

Una regola di rilevamento è una regola Sigma, un formato YAML aperto per descrivere attività sospette, che Status200 esegue secondo una pianificazione sui tuoi eventi. Quando corrisponde, apre un caso o si aggiunge a uno già aperto, apre un avviso, facoltativamente un incidente, e scrive un Detection Finding negli eventi. La Rule Library offre regole pronte da cui partire.

Creare una regola#

Una prima regola, che corrisponde agli accessi falliti da fuori 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

Cosa può esprimere una regola#

Status200 esegue il nucleo booleano di Sigma:

• Le selezioni sono mappe di campi (ogni campo deve corrispondere; una lista di valori corrisponde a uno qualsiasi) o liste di parole chiave, che corrispondono in qualsiasi punto del messaggio.
• Le condizioni combinano le selezioni con and, or, not e parentesi, oppure con 1 of selection_*, all of selection_*, any of them e all of them.
• Modificatori di campo: contains, startswith, endswith, all, re, cased, gt, gte, lt, lte, cidr, exists e windash. Il testo si confronta senza distinguere maiuscole e minuscole, a meno che tu non aggiunga cased.
• Un campo è un campo tipizzato (principalUser), una grafia Sigma comune di uno di essi (CommandLine, src_ip, Hostname) o qualsiasi chiave di attributo, scritta come nell'evento (threat.matched).
• Image e CommandLine leggono il processo di cui parla l'evento, quello avviato nell'avvio di un processo (processPath, processCommandLine), e ParentImage e ParentCommandLine il processo che lo ha avviato (parentProcessPath, parentProcessCommandLine). principalProcess è il processo che ha agito, che in un avvio è il processo padre.
• level imposta la gravità: informational, low, medium, high o critical, e medium se manca. Gli ID ATT&CK in tags (attack.t1110, attack.ta0006) compilano i campi MITRE della risultanza.

Le aggregazioni come | count() by principalIp > 5 vengono rifiutate al salvataggio: usa invece una regola di correlazione, oppure Group By Field e Match Count Threshold. logsource è solo informativo e non restringe nulla: metti quel filtro in una selezione, come className: Authentication. Un timeframe viene ignorato, perché la finestra la fissa l'intervallo della regola.

Regole di correlazione#

Una correlazione Sigma scatta su più eventi insieme invece che su uno solo. Incollala in Sigma Rule (YAML) con le regole che legge, come documenti YAML separati da ---, oppure indica regole che il progetto ha già con il loro name o id Sigma. La Rule Library ne ha di pronte, come accessi falliti seguiti da uno riuscito.

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

• Un gruppo è il valore dei campi di group-by, come un indirizzo. I conteggi sono mobili: una raffica che due esecuzioni si dividono viene comunque contata per intero nel suo timespan, che dura al massimo 24 ore.
• new_value è un tipo proprio di Status200, perché Sigma non ha una correlazione «visto per la prima volta»: confronta con fino a 30 giorni di storico. value_sum, value_avg, value_percentile e value_median vengono rifiutati al salvataggio.
• La colonna Tipo di Detection Rules indica il genere di ogni regola, e il modulo dice in una frase che cosa cerca la regola.

Impostazioni di valutazione#

Il raggruppamento e il conteggio distinto accettano gli stessi nomi di campo della regola. Con essi, la soglia dice «tanti, dalla stessa cosa, in un'esecuzione», senza un monitor sopra:

Quando gira una regola#

Status200 controlla ogni minuto quali regole abilitate hanno superato il loro intervallo dall'ultima esecuzione. Ogni esecuzione legge gli eventi il cui orario dell'evento cade tra l'esecuzione precedente e due minuti fa, poi va avanti. I due minuti lasciano tempo agli eventi ancora in arrivo, come una riga di log letta un minuto dopo essere stata scritta:

• Le finestre sono una dopo l'altra, non scorrono. Con un intervallo di 10 minuti, errori alle 09:58 e alle 10:01 possono cadere in esecuzioni diverse e vengono contati separatamente, quindi lascia margine quando scegli una soglia.
• Dopo un'interruzione, come un worker fermo o una regola riattivata, l'esecuzione successiva copre l'intera interruzione, fino alle ultime 24 ore.
• Un evento che arriva con più di due minuti di ritardo, quando un'esecuzione ha già coperto il suo orario, viene salvato ed è ricercabile, ma quella regola non lo legge mai.
• Ogni gruppo che raggiunge la soglia diventa un Detection Finding, fino a 10.000 per esecuzione. Avvisi, incidenti e casi si aprono per i 100 con i conteggi più alti; gli altri condividono un caso sulla regola, e l'Ultimo errore della regola dice quanti gruppi hanno corrisposto.

Gravità#

Il level di una regola è la gravità delle sue risultanze: informational, low, medium, high e critical diventano Informational, Low, Medium, High e Critical. I suoi avvisi e incidenti prendono una delle gravità del tuo progetto, in quest'ordine:

1. La Gravità avviso (o Gravità incidente) della regola, se impostata.
2. La tua gravità che prende il nome dal livello, come High, a prescindere da maiuscole e minuscole.
3. Per rango: le regole critical e high prendono la tua gravità più alta, le altre la più bassa.

Avvisi e risultanze#

Ogni gruppo che scatta apre un avviso intitolato [Detection] <rule name> — <group value>, oppure [Detection] <rule name> per una regola senza campo di raggruppamento. Finché è aperto, altre corrispondenze di quel gruppo non ne aprono un altro. Una regola vede solo corrispondenze e non può capire che un attacco è finito, quindi i suoi avvisi restano aperti finché qualcuno non li risolve.

Un Detection Finding è un evento di sicurezza di classe Detection Finding (classe OCSF 2004) del prodotto Status200 Detections, con i tag MITRE della regola, il valore del gruppo per primo in observables e questi attributi:

Le risultanze sono eventi normali: cercale in Eventi e fai pivot su di esse in Correla. Per provare una nuova regola in silenzio, disattiva ogni azione tranne la risultanza finché non ti fidi di lei.

Monitor di eventi di sicurezza#

Un monitor di eventi di sicurezza conta gli eventi che corrispondono ai suoi filtri su una finestra mobile e applica al conteggio i soliti criteri dei monitor: cambia lo stato del monitor, apre avvisi o incidenti e chiama la reperibilità. Creane uno in Monitor → Crea monitor, con Security Events come tipo; viene elencato lì insieme agli altri tuoi monitor.

Il suo modulo mostra Monitor events that include this text, Monitor Security Events for (time), Event Severity e Classe di eventi. Filtra per servizio di telemetria e Filtra per attributi aspettano in Altri campi, la cui intestazione mostra quelli che un monitor usa. I suoi criteri controllano Security Event Count.

Scrivi il rilevamento vero e proprio come regola, con la sua soglia. Usa un monitor quando vuoi una finestra mobile, uno stato che si ripristina da solo, una pagina di stato o politiche di reperibilità diverse per criterio.

Sorveglia i tuoi rilevamenti#

Le risultanze sono eventi, quindi un monitor può sorvegliare le regole stesse:

• Tempeste: un monitor sulla classe Detection Finding, che conta ogni risultanza. Venti regole diverse che scattano in un'ora sono un segnale che nessuna regola da sola può vedere.
• Cambi di ritmo: filtra sul status200.detection.rule_id di una regola. Una regola che scatta ogni settimana e all'improvviso cinquanta volte l'ora richiede un'altra risposta.
• Silenzio: risultanze che scendono a zero, quando di solito ne vedi alcune, di solito significano che un'origine ha smesso di inviare. Usa un criterio che controlla un conteggio sotto un numero.

L'azione Crea monitor nella riga di una regola apre un nuovo monitor già configurato così: la classe Detection Finding, l'ID della regola (mai il suo nome, che una ridenominazione cambierebbe) e l'ultima ora. Un monitor così conta le risultanze, una per gruppo per esecuzione, non gli eventi che ci sono dietro. Per richiedere un numero di eventi prima che scatti qualcosa, usa la Match Count Threshold della regola.

Intelligence sulle minacce#

Threat Intel si abbona a feed STIX/TAXII di indirizzi IP, domini, URL, indirizzi email e hash di file malevoli noti. Gli eventi che ne menzionano uno vengono marcati all'arrivo con attributi threat.*, su cui regole e monitor possono filtrare, e ogni minuto gli eventi recenti vengono confrontati con i feed, aprendo avvisi e risultanze come fa una regola. Vedi Intelligence sulle minacce.

Conservazione e fatturazione#

Gli eventi di sicurezza vengono fatturati per GB acquisito, come il resto della tua telemetria, e conservati secondo la tua conservazione della telemetria: la Conservazione predefinita (giorni) del progetto, in Impostazioni del progetto → Telemetria e APM → Conservazione dei dati, oppure una conservazione impostata sul servizio di telemetria a cui appartengono. Quando la conservazione di un evento termina, l'evento viene eliminato.

Risoluzione dei problemi#

Passaggi successivi#