Monitoraggio dell'Integrità dei File

Il monitoraggio dell'integrità dei file risponde a una domanda: un file che non doveva cambiare è stato modificato? Il controllo registra uno stato di fiducia di file, cartelle e impostazioni selezionati, poi segnala ogni differenza successiva insieme all'orario e all'account responsabile. Il valore sta meno nel rilevamento in sé che nel fatto che una modifica non spiegata diventa una registrazione che qualcuno deve chiudere, invece di una modifica silenziosa che nessuno nota.

Il FIM si basa sulla verifica dell'integrità dei file, cioè sull'atto stesso di verificare. La differenza sta nella continuità: un controllo una tantum risponde alla domanda una volta, mentre il FIM la pone di continuo e conserva la storia di ogni risposta. Questa storia serve all'investigatore quando un file di configurazione è stato modificato settimane prima che qualcuno se ne accorgesse.

Ogni percorso monitorato segue lo stesso ciclo. Dallo stato noto come buono si ricava una baseline di hash e attributi. Ogni evento successivo viene confrontato con quella baseline, così l'avviso riflette ciò che differisce davvero e indica file, modifica, account e orario. La qualità del controllo dipende soprattutto dalla baseline e dalla disciplina di chi gestisce gli avvisi, non dal motore di rilevamento.

Il confronto programmato ricontrolla la baseline a intervalli fissi e segnala le divergenze. È economico e facile da verificare, ma una modifica fatta subito dopo una scansione resta nascosta fino alla successiva. Il monitoraggio in tempo reale reagisce a scritture, spostamenti ed eliminazioni nel momento in cui avvengono, per questo un SOC lo vuole di solito per i binari di sistema, gli script di avvio e le regole di accesso.

La modalità in tempo reale costa di più. Richiede un agente sull'host, genera più eventi e va tarata fin dal primo giorno. Molti team usano entrambe: il tempo reale per i pochi percorsi più importanti e il confronto programmato per il resto del parco, così che un evento sfuggito all'agente venga intercettato dalla scansione completa successiva. Per la pratica più ampia vedi il monitoraggio continuo.

Un avviso su un file modificato, da solo, dice poco. Segnala che un percorso differisce dalla baseline, ma nulla sull'intenzione. Il FIM acquista valore quando l'avviso confluisce nello stesso flusso di tutti gli altri segnali, così l'analista lo legge accanto ad accessi, processi e al ticket che dovrebbe spiegare la modifica. I team che già inviano eventi a una integrazione SIEM possono collocare la modifica del file sulla stessa linea temporale di accessi e connessioni.

Il FIM è uno dei controlli più citati nei framework di sicurezza, per questo i team SOC lo adottano anche quando non si è verificato alcun incidente. La maggior parte degli auditor chiede le stesse prove: un elenco definito di file critici, avvisi per modifiche non autorizzate e la prova che una persona ha esaminato ogni avviso e lo ha chiuso con una decisione.

• Lo standard PCI DSS richiede un meccanismo di rilevamento delle modifiche sui sistemi che trattano dati di carte, con confronto dei file critici almeno una volta a settimana.
• Il controllo SI-7 del NIST SP 800-53 copre l'integrità di software, firmware e informazioni.
• La tutela dell'integrità prevista da HIPAA si aspetta che i soggetti coperti dispongano di meccanismi elettronici che confermino che le informazioni sanitarie elettroniche non sono state alterate o distrutte senza autorizzazione.
• L'Allegato A della ISO/IEC 27001 include controlli di gestione delle modifiche e di integrità dei sistemi, che un processo FIM documentato aiuta a dimostrare.
• Gli auditor chiedono di solito l'inventario dei file protetti, campioni di avvisi e una traccia di revisione che mostri la chiusura di ogni avviso con una decisione, non solo la sua generazione.

Anexet non crea una baseline per percorsi di sistema arbitrari né calcola l'hash di ogni file su un server, quindi non è un motore FIM classico. La console registra le operazioni sui file nelle postazioni e nelle condivisioni di rete: per i file, creazione, lettura, scrittura, eliminazione, rinomina, esecuzione e modifica dei permessi; per le cartelle, un insieme più ristretto. Ogni profilo di agente sceglie quali operazioni registrare. Le condivisioni di rete sono coperte dal controllo dei trasferimenti di file e delle condivisioni di rete.

Il rischio operativo maggiore del FIM non è perdere una modifica reale. È sommergere il SOC di rumore finché ogni avviso viene scartato senza essere letto. I container cambiano il quadro: le immagini si ricostruiscono anziché essere corrette sul posto, quindi la baseline passa nella pipeline di costruzione delle immagini. L'ottimizzazione segue una sequenza prevedibile:

1. 1

   Acquisire la baseline

   Registratela da una build del sistema nota come buona.

2. 2

   Eseguire in modalità solo report

   Scoprite cosa cambia normalmente in quella classe di sistemi.

3. 3

   Escludere i percorsi volatili

   Lasciate fuori i percorsi che cambiano legittimamente, come cache, log e metadati del gestore di pacchetti.

4. 4

   Instradare gli avvisi a un responsabile

   Il responsabile chiude ogni avviso con un motivo registrato.

Il FIM rileva che un file monitorato è cambiato. Non giudica se il nuovo contenuto sia dannoso e non impedisce la modifica. Non vede nulla dell'attività che non tocca mai un percorso monitorato, come l'esecuzione in memoria, l'abuso di credenziali o i dati copiati senza alterare alcun file.

Un SOC maturo tratta quindi il FIM come un controllo di rilevamento tra più altri. Lo affianca a controlli di accesso che limitano chi può scrivere nei percorsi protetti, alla verifica dell'integrità dei log, perché gli eventi di integrità sopravvivano su un'infrastruttura che l'attaccante non controlla, e a backup e ripristino, così che una modifica non autorizzata confermata possa essere annullata.

Cominciate dai pochi file la cui modifica silenziosa farebbe più danni: i binari di sistema sui server, la configurazione degli strumenti di sicurezza e i percorsi che contengono dati protetti. Aggiungete altri percorsi solo dopo che il responsabile ha spiegato ogni avviso prodotto dal primo gruppo.

Per approfondire: Meccanismi per garantire la sicurezza dei sistemi informativi; Cosa sono i sistemi SIEM per la gestione della sicurezza informatica?.