Come gestisci l'analisi del registro?

OSSEC è un ottimo FOSS HIDS che funziona bene per ridurre il numero di eventi di registro che è necessario controllare con qualcosa potenzialmente gestibile.

Supporta tutte le fonti log che hai menzionato: link

Abbiamo creato un'app interna che ci consente di eseguire un "controllo giornaliero" rapido di tutti gli avvisi che l'OSSEC genera in un giorno; in genere ci impiegano meno di 20 minuti per richiamare un messaggio chiaro o per avviare un'indagine sugli incidenti. Per un ambiente riceviamo ~ 70.000 avvisi OSSEC al giorno, ma la maggior parte degli avvisi / eventi sono cluster di eventi di autenticazione o errori delle app che inviano spam al sistema di registrazione, ad esempio:

DatochehaiSplunk,potrestifarel'integrazioneSplunk+OSSEC: link

L'altro giorno ho visto un paio di SIEM aziendali in azione - sono rimasto sbalordito nell'apprendere che a quanto pare non hanno segnalazioni dettagliate che descrivono eventi di log insoliti o rari. Eventi insoliti e rari sono spesso i migliori indicatori di qualcosa di brutto e possono fungere da elenco breve di eventi da inseguire fino a quando i cavi non si raffreddano.

Usiamo anche Logwatch come analizzatore di log secondario.

Questa funzionalità è generalmente ottenuta con l'aiuto delle soluzioni SIM o SIEM. Esistono diversi fornitori famosi per questi CA, ArcSight, Loglogic, splunk, ecc.

Puoi raccogliere i log, essere informato sugli avvisi e agire in base alla correlazione delle regole. Puoi raccogliere i log da tutte le possibili fonti, database, Unix, Windows, firewall ecc.

I metodi spesso differiscono a seconda della scala e della posizione, ad esempio la registrazione perimetrale per un'azienda è di solito troppo per un team di allerta interno, quindi di solito è affidata a uno dei fornitori di servizi gestiti, che passeranno poi in avvisi pertinenti.

Per le organizzazioni più piccole o per la registrazione specifica dell'host, il problema è molto più gestibile, tuttavia è comunque necessario considerare come si allena e si ottimizza il processo di avviso. Splunk e gli altri faranno il lavoro, ma è necessario pianificare la quantità di risorse necessarie per occuparsi durante le prime settimane, su qualsiasi aggiornamento o modifica all'ambiente registrato, su qualsiasi cambiamento nei profili di attacco e, di fatto, continuamente. tempo.

Detto questo, i soliti meccanismi sono l'uso di allarmi basati su firme e statistiche: le firme sono veloci e possono essere aggiornate dai fornitori di servizi, quindi richiedono uno sforzo minimo, tuttavia devono essere create in modo da non identificare i nuovi tipi di attacco, mentre gli allarmi statistici rispondono a qualsiasi cambiamento nella registrazione - così puoi finire sovraccaricato di falsi positivi fino a quando non ti sintonizzi.

Da un punto di vista della sicurezza (ci sono molte altre cose per cui vale la pena controllare i registri) allora i registri mostreranno solo in modo affidabile dove la sicurezza è funzionante come previsto. Se qualcuno ha aggirato le misure di sicurezza, probabilmente non verrà rilevato dai registri / i log potrebbero essere compromessi, quindi sono di uso limitato.

Inoltre, se puoi costruire un meccanismo per analizzare i registri per potenziali violazioni, allora, nella maggior parte dei casi, è altrettanto semplice applicare la politica piuttosto che attendere che si verifichi una violazione.

L'analisi del registro non può sostituire un controllo di integrità dei file basato su host (come coperchi, tripwire)

Detto questo, ti consiglio di utilizzare fail2ban dove appropriato.

Anche l'analisi del registro dovrebbe tenere conto della routine di gestione delle modifiche dell'organizzazione o, più specificamente, del processo di aggiornamento software / hardware, almeno nel senso che l'integrità del file sia cambiata.