IBM i Monitoring - l'importanza delle correlazioni tra gli eventi

IBM i Monitoring e il controllo della sicurezza

Il controllo della sicurezza fatto di eventi da correlare

Il controllo della sicurezza IBM i e l'importanza delle correlazioni tra gli eventi

Eventi legati alla sicurezza: cosa si intende per correlazione
Partiamo da un esempio esterno al mondo IT. Supponiamo che, per controllare la sicurezza di casa nostra, installiamo delle telecamere per vedere quante persone sostano vicino alla porta d'ingresso. Alla fine di ogni giornata abbiamo un numero assoluto di persone. E' davvero così utile questo dato in una forma così neutra? Non è forse meglio avere informazioni da aggiungere a questo dato per ottenere qualcosa di più utile alla sicurezza? Chi sono queste persone? E' il vicino di casa o sono degli sconosciuti? Quante volte una stessa persona si ferma davanti alla mia porta nella stessa giornata? In che orari sostano quelle persone? Queste e altre ancora sono le informazioni che, correlate tra loro, possono aiutarmi ad individuare un reale rischio oppure a lasciarmi tranquillo.

Controllo della sicurezza nel mondo IT: gli errori più comuni
Torniamo al nostro mondo informatico. Controllare la sicurezza di un sistema significa registrare costantemente quello che avviene, in ogni momento, e poter distinguere gli episodi anomali dalla normale operatività. Spesso mi viene detto "tutti gli accessi al sistema vengono registrati", bene, ma è davvero così utile questo dato se tenuto come informazione isolata? Migliaia di accessi al giorno, magari messi su dei giganteschi reports, a cosa servono nella pratica? Sicuramente servono a recuperare informazioni storiche nel caso di un danno subito, ma la vera sfida è fare i controlli in real time per riuscire a prevenire quel danno. Le raccolte di eventi massivi, senza una qualche forma di correlazione, sono si necessarie, ma hanno una bassa resa in termini di prevenzione sulla sicurezza.

Controllo della sicurezza nel mondo IT: gli eventi
Abbiamo fin qui detto che, per controllare la sicurezza IT, è necessario raccogliere costantemente gli eventi che accadono e poi cercare di correlarli tra loro per dargli un valore che mi aiuti ad individuare le reali situazioni anomale. Ma quali possono essere questi eventi da raccogliere? Un elenco non esaustivo potrebbe essere il seguente:

Accessi al sistema: interattivi, remoti, batch (tramite processi)

Accessi errati al sistema: password sbagliate, utenti inesistenti, utenti disattivi

Gestione delle utenze: creazione, modifica di ruolo, cancellazione, disattivazione

Gestione dei file con dati sensibili/personali: modifica e cancellazione

Cambio della data e dell'ora del sistema

Comandi eseguiti dagli utenti con diritti elevati

Gestione dei dati di business: inserimento, cancellazione e modifica dei dati importanti per l'azienda (anagrafiche clienti, gestione del personale, gestione bancaria, giacenze di magazzino...)

Sono solo alcuni esempi che, nel mondo IBM i, possono essere raccolti grazie al giornale di audit di cui ho parlato in questo articolo Controllare la sicurezza sui sistemi IBM i: l'Audit Journal

Controllo della sicurezza nel mondo IT: le proprietà degli eventi
Ogni evento monitorato deve poter essere arricchito di più informazioni possibili, ovviamente informazioni che rendano utile il controllo della sicurezza. Non basta infatti sapere che l'utente "mmoret" (esempio) si è collegato al sistema, ma bisogna conoscere altri dati come:

Quando si è collegato

Da dove si è collegato

Con quale programma si è collegato

Da quale porta di sistema o con quale protocollo si è collegato

Quanto tempo è rimasto collegato

Controllo della sicurezza nel mondo IT: le correlazioni
Arriviamo allo scopo principale di questo articolo, parliamo delle correlazioni nel mondo IT e lo facciamo con degli esempi chiarificatori. Gli eventi descritti finora diventano veramente utili per la sicurezza solo se li leghiamo tra di loro con qualche algoritmo che chiamiamo correlazione.

Accessi al sistema, la loro provenienza e il software utilizzato: mettendo insieme queste tre informazioni e il tempo in cui avvengono, possiamo creare una semplice correlazione per capire se considerare pericoloso un evento di accesso oppure no. Infatti, supponiamo che l'accesso avvenga da utenti conosciuti, sempre dallo stesso IP, con il software gestionale installato proprio su quell'IP e in orario d'ufficio. E' un'informazione pericolosa? Dovendo fare una selezione possiamo dare un basso livello di gravità a quel tipo di accesso, mentre alzeremmo il livello se lo stesso accesso avvenisse di notte e magari da un IP diverso da quello atteso

Gestione degli utenti e accessi: un utente che viene creato, utilizzato e poi eliminato, nel giro di pochi minuti, è un altro esempio di correlazione tra tre eventi diversi e il periodo temporale. Questa correlazione sicuramente ci allerta su una situazione anomala, almeno da verificare il prima possibile

Accessi errati e la loro provenienza: unendo più eventi diversi e il tempo in cui avvengono, possiamo facilmente individuare eventuali robot che tentano di accedere ai sistemi, magari da un PC ignaro di avere installato quel programma fraudolento. Per farlo è semplice, basta correlare gli eventi di accesso errato con l'orario di accesso e l'IP di provenienza, il gioco è fatto, il robot così lo individuiamo immediatamente. Questa correlazione è importante perché, gli accessi errati continui ai sistemi, provocano spesso una disattivazione delle utenze come contro mossa di autoprotezione, con il conseguente fermo di attività da parte delle utenze.

Utenze amministrative troppo diffuse: potremmo non renderci conto di quanto siano diffuse le password degli utenti amministratori di sistema ma le correlazioni tra gli eventi di sicurezza ci possono aiutare. Infatti, basterebbe verificare, in real time, da quanti IP diversi si stanno collegando tali utenze e il momento in cui lo fanno, per capire se lo stesso profilo è utilizzato da più persone.

Tali correlazioni devono essere continuamente attive per poter avere dei riscontri immediati che mi aiutino a controllare il prima possibile le anomalie di sicurezza. Per questo motivo non è possibile farle manualmente ma bisogna dotarsi di prodotti o di programmi, anche sviluppati in modo "custom", che diano questo valore aggiunto al controllo di sicurezza.

Controllo della sicurezza sui sistemi IBM i
Come già detto, è il giornale di audit il registro centrale su cui il sistema IBM i scrive quello che accade al suo interno. E' importate conoscere che un nuovo server IBM i nasce con questo registro disattivato. Sta al cliente di IBM decidere se attivarlo e come gestirlo.

Per chi parla di sicurezza IT, il giornale di audit deve essere necessariamente attivato e configurato così da raccogliere tutto ciò che serve a capire come viene utilizzato il sistema. Il sistema operativo IBM i fornisce già, nativamente, le istruzioni per fare tutto ciò e anche per leggere gli eventi che, su tale giornale, vengono registrati.

Il giornale di audit però archivia in modo verticale i singoli eventi, per tipologia, non fa le correlazioni di cui tanto ho parlato in questo articolo. Come fare a correlare questi eventi? Purtroppo, ad oggi, non c'è nulla di nativo. Possiamo quindi creare degli script che estraggono, correlano ed eventualmente avvisano, oppure appoggiarci a prodotti che hanno questi concetti di controllo già al loro interno.

Per uno sviluppatore di sw i passaggi sono ben conosciuti: si pensa ad un algoritmo di correlazione di eventi, si reperiscono i dati verticali dal giornale di audit e li si mettono in un archivio unico. Si estraggono blocchi di eventi da questo archivio unificato, si applicano le regole dell'algoritmo precedentemente analizzato e la procedura di controllo è fatta. Se poi l'algoritmo individua una situazione anomala, si avvisa chi di dovere, anche solo con una semplice mail.

Controllo della sicurezza sui sistemi operativi IBM i: un esempio schematizzato
Concludo con un semplice esempio schematizzato che rappresenta il valore delle correlazioni. Lo scenario è il seguente: l'amministratore di sistema IBM i (utente QSECOFR) accede da 3 indirizzi IP diversi tra le 9 e le 10 di mattina. E' un evento strano? E' stato il collega con una motivazione valida? Quello lo potrò capire indagando, ma la cosa importante è sapere subito che questo episodio è avvenuto. Se non avessi nulla che correli il numero di accessi, il tempo in cui sono avvenuti e il nome dell'utente, scoprirei questa cosa magari la settimana dopo, quando viene generato il report degli accessi settimanali (che dovrei anche aprire e leggere).

Se invece avessi un prodotto oppure degli script custom che correlano continuamente gli eventi, potrei sapere subito quello che è accaduto, magari tramite una mail ricevuta come allarme, e quindi indagare sulle motivazioni per cui il QSECOFR ha fatto quei tre accessi da IP diversi in così poco tempo.

Sperando di essere stato chiaro nell'esposizione di questo articolo, ti auguro un buon lavoro e resto disponibile per un confronto su queste tematiche. Scrivimi pure o scegli quando incontrarci cliccando qui

Marco Moret Monitoring Project Manager presso smeup ICS

Tutti gli articoli
5 motivi per cui è fondamentale controllare il sistema IBM i
il controllo della sicurezza IBM i e l'importanza delle correlazioni tra gli eventi

Gestisci, analizza e controlla il sistema IBM i
Scarica, installa e lavora in pochi secondi
IBM i Monitoring Facility - Check è completamente gratuito fino a fine mese