Che cosa distingue un evento da un log

SmartEvent è la soluzione unificata di security event management di Check Point: riduce la massa dei log a un numero gestibile di eventi ordinati per gravità. La distinzione va fissata subito. Un log è la registrazione di una connessione o di un’azione; un evento è la registrazione di un incidente di sicurezza, costruito a partire da uno o più log e dalle regole scritte nella Event Policy.

Non tutti i log diventano eventi. Quelli di Firewall, VPN e HTTPS Inspection non vengono convertiti in automatico, per non far crollare le prestazioni sotto il volume. I log delle altre lame diventano eventi automaticamente, mentre gli eventi correlati nascono solo quando la SmartEvent Correlation Unit riconosce uno schema sospetto distribuito su più log. Si consultano da SmartConsole, dalla SmartView Web Application o dal client SmartEvent.

I componenti, e chi legge i log di chi

I ruoli sono tre: il Log Server raccoglie i log dai Security Gateway, la SmartEvent Correlation Unit li analizza e rileva gli eventi, il SmartEvent Server ospita il database degli eventi.

Nel deployment all-in-one si aprono le proprietà del Security Management Server e si abilitano, nella scheda Management, tre lame: Logging & Status, SmartEvent Server e SmartEvent Correlation Unit. Nel deployment dedicato si crea un oggetto Check Point Host per il server SmartEvent, si stabilisce la SIC e si abilitano le stesse tre lame; se quel server non fa anche da Log Server, nella pagina Logs va lasciata deselezionata l’opzione Enable Log Indexing. In ambiente Multi-Domain SmartEvent deve stare su un server dedicato.

Il passo che sfugge quasi sempre: la Correlation Unit non trova i log da sola. In SmartEvent Settings & Policy, scheda Policy, sezione Correlation Units, si definisce l’oggetto Correlation Unit e si selezionano i Log Server da cui leggere, quelli di produzione e il Log Server locale del SmartEvent Server. Senza quella selezione la correlazione gira a vuoto.

La catena di correlazione, passo per passo

Quando un log arriva alla Correlation Unit il percorso è sempre lo stesso.

  1. Global Exclusions (Policy tab, Event Policy, Global Exclusions): se il log corrisponde a un’esclusione globale viene scartato e non raggiunge nessuna definizione.
  2. Event Definitions: si verifica prima che il product type del log rientri fra quelli ammessi, poi i campi specifici del prodotto, come Event Type, Action, Port e Protocol.
  3. Event Candidate: i log che corrispondono vengono aggregati in un candidato; proprietà diverse, per esempio un indirizzo sorgente diverso, aprono un candidato nuovo.
  4. Event Exclusions: prima di generare l’evento, gli attributi del candidato vengono confrontati con le esclusioni della Event Policy.
  5. Generazione: raggiunta la soglia, il candidato diventa evento nel database degli eventi, e i log corrispondenti continuano ad aggiungersi per tutta la finestra.

La soglia si legge nella forma «Detect the event when more than X logs were detected over a period of Y seconds»; la severità si sceglie fra Informational, Low, Medium, High e Critical.

Dagli eventi agli alert: le Automatic Reactions

L’alert non è un effetto collaterale dell’evento: è un oggetto che si crea e poi si collega. Il percorso è SmartConsole, Logs & Events, SmartEvent Settings & Policy, General Settings, Objects, Automatic Reactions.

  • Mail: notifica via posta; il SmartEvent Server deve raggiungere il mail server.
  • SNMP Trap: il messaggio viaggia come DisplayString da 256 byte; se l’OID non è di tipo testo l’invio fallisce.
  • Block Source: istruisce il Security Gateway a bloccare l’indirizzo IP sorgente dell’evento per una durata configurabile, da 10 minuti a una settimana, oppure personalizzata fra 1 e 32.767 unità.
  • Block Event Activity: per attacchi distribuiti su più sorgenti o verso più destinazioni, con le stesse durate.
  • External Script: script Bash o C-Shell, che deve terminare entro 10 minuti o il SmartEvent Server lo interrompe. Servono formato UNIX, permesso di esecuzione e nessuno spazio nel nome del file.

Creata la reazione, la si collega dal campo Automatic Reactions dell’evento nella Event Policy. Poi, sempre: Menu, File, Save e quindi Actions, Install Event Policy.

Trappole tipiche d’esame

  • Troppi alert prodotti da regole di evento definite male. È l’errore che il vendore segnala per primo: soglie troppo basse e filtri troppo larghi generano rumore costante, e gli operatori smettono di guardare. La cura usa gli stessi strumenti della catena: alzare la soglia, restringere i campi della definizione, usare Global Exclusions per il traffico noto ed Event Exclusions per i candidati legittimi.
  • Il Security Management Server che non manda i log a SmartEvent. Abilitare le lame non basta. Se la Correlation Unit non ha in elenco i Log Server da cui leggere, o se i gateway trattengono i log in locale invece di inoltrarli al Log Server dedicato, la console resta vuota: la risposta giusta guarda alla sorgente dei log, non al motore.
  • Salvare senza installare. Una modifica alla Event Policy o una nuova Automatic Reaction non ha effetto finché non si esegue Actions, Install Event Policy: il salvataggio da solo resta locale.
  • Confondere Block Source e Block Event Activity. La prima blocca l’IP sorgente dell’evento; la seconda serve quando le sorgenti o le destinazioni sono molte.