Monitoraggio e verifica
La maggior parte della documentazione di prodotto usa i due termini come sinonimi. La distinzione utile è operativa, non definitoria. La verifica dell'integrità dei file è l'atto di verifica in sé: un confronto con una baseline, spesso eseguito a intervalli programmati. FIM indica di solito la disciplina continua attorno a quel controllo: rilevamento basato sugli eventi, attribuzione della modifica a un processo e a un utente, avvisi, un flusso di smistamento e report utili per l'audit. In pratica, una implementazione di FIM include la verifica programmata come una delle sue modalità.
Che cosa osserva un controllo FIM
Il perimetro è volutamente ristretto. Il FIM funziona in proporzione a quanto accuratamente viene scelto l'insieme protetto, e tale insieme parte di solito dalla classificazione dei dati. Monitorare tutto produce un flusso di modifiche che nessuno riesce a leggere.
| Asset | Perché viene osservato |
|---|---|
| Binari e librerie di sistema | Sostituzione o patch di componenti centrali. |
| File di configurazione | Una sola riga modificata può disattivare il logging o ampliare gli accessi. |
| Codice applicativo e contenuti web pubblicati | Il punto da cui il codice iniettato raggiunge gli utenti. |
| Punti di persistenza | Attività pianificate, servizi, voci di avvio e definizioni cron. |
| Archivi di credenziali e chiavi | Le modifiche qui spesso significano diritti di accesso cambiati. |
| Agenti di sicurezza e relativa configurazione | Disattivare il monitor è un passo iniziale comune. |
| Registrazioni immutabili | Log e archivi valgono solo se restano invariati. |
Dove si colloca il FIM tra i controlli
Il FIM rileva le modifiche ai file. Non le impedisce, non giudica se il nuovo contenuto sia malevolo e non vede l'attività che non tocca mai un file monitorato, come le tecniche in memoria, l'uso improprio delle credenziali o i dati copiati senza alterare nulla.
Per questo viene affiancato da controlli degli accessi e gestione dei privilegi, rilevamento sugli endpoint per il comportamento in esecuzione, logging centralizzato affinché gli eventi di integrità sopravvivano su un sistema che chi ha modificato non controlla, e backup con ripristino, così da poter annullare una modifica rilevata.
Che cosa deve contenere un evento di modifica
Un evento utile risponde a più della sola domanda se un file è diverso. Registra quattro cose.
L'attribuzione è ciò che trasforma il monitoraggio dell'integrità in uno strumento investigativo. Risponde alla stessa domanda che il monitoraggio delle attività degli utenti pone sulle persone. Una modifica di configurazione in una finestra di manutenzione approvata, eseguita dall'account di deployment, è diversa per natura dalla stessa modifica fatta di notte da una sessione interattiva.
| Domanda | Che cosa registra l'evento | Perché conta |
|---|---|---|
| Che cosa è cambiatoContenuto, permessi, proprietà o timestamp | Idealmente il diff stesso, non solo un segnale | Il revisore può valutare la modifica, non solo la sua esistenza |
| QuandoMomento della scrittura | L'orario della modifica, non solo quello del rilevamento | Un ritardo di rilevamento può nascondere l'ordine reale degli eventi |
| Chi e comeAccount e processo | L'account utente e il processo che ha eseguito la scrittura | Distingue un deployment da una sessione interattiva |
| Previsto o noContesto della modifica | Correlazione con ticket di change, finestre di patch e deployment | Trasforma l'avviso in una domanda chiusa |
Spinte normative
Il FIM è citato o implicito nella maggior parte dei framework di sicurezza e nei requisiti dei settori pagamenti, sanità e pubblica amministrazione. Di solito chiedono due cose: che i file critici siano monitorati per le modifiche e che una persona esamini e risolva gli avvisi. Gli auditor chiedono in genere l'inventario dei file protetti, le prove della revisione e le registrazioni di come ogni modifica rilevata è stata gestita. Il flusso documentato conta quanto lo strumento. Mantenere queste prove aggiornate è il cuore del monitoraggio di conformità.
Implementazione e messa a punto
Gran parte dello sforzo in un programma FIM è nella messa a punto. Una implementazione che salta il periodo di apprendimento finisce quasi sempre ignorata. La baseline è un insieme di impronte digitali di uno stato noto come sano, e ogni avviso nasce dal confronto con essa.
- 1
Costruire la baseline
Partire da uno stato noto come sano.
- 2
Eseguire in modalità solo report
Restare abbastanza a lungo da capire quali modifiche sono normali.
- 3
Escludere i percorsi volatili
Cache, directory temporanee, log e database dei pacchetti.
- 4
Assegnare gli avvisi a un responsabile
Qualcuno smista gli avvisi rimasti.
- 5
Aggiornare la baseline nel change management
I deployment approvati non dovrebbero arrivare come incidenti.
Errori comuni
La maggior parte dei programmi che falliscono cade negli stessi punti.
Monitorare tutto dal primo giorno è il modo più rapido per far disattivare il FIM.
- La baseline non viene mai aggiornata, quindi ogni patch approvata sembra un incidente.
- I percorsi volatili, come cache e log, restano nel perimetro e il flusso di avvisi si riempie di rumore.
- Gli avvisi non hanno un responsabile nominato, quindi nessuno li esamina.
Da dove iniziare
Partite dai file la cui modifica farebbe più danni: binari di sistema, impostazioni di sicurezza e i log che dimostrano cosa è accaduto. Aggiungete il resto solo quando i primi avvisi hanno un responsabile. Una modifica non spiegata è un segnale tra molti, quindi leggetela insieme agli indicatori di minaccia interna.
Per approfondire: Meccanismi per garantire la sicurezza dei sistemi informativi; Cosa sono i sistemi SIEM per la gestione della sicurezza informatica?.
Un file modificato diventa una prova solo quando qualcuno sa dire chi lo ha cambiato e perché.
Anexet Team