Il comportamento dei sistemi informatici: behaviour analysis, machine learning e caffè

Piccolo focus sul tema dell’analisi del comportamento dei sistemi.

Scendiamo un po’ nel tecnico per capire come si analizza un comportamento e quali paradigmi/algoritmi possiamo utilizzare.

Ovviamente tutto parte dai dati che possiamo collezionare da un sistema informatico: i logs, ovvero i registri degli eventi che le applicazioni compilano durante la loro operatività, ma si tratta di una delle molte fonti di dati. Possiamo infatti prendere in considerazione le metriche prestazionali (carico CPU, utilizzo RAM, impegno di banda, ecc) o il traffico di rete che il sistema genera/riceve.

Tutti i dati citati solo utili a definire un comportamento del sistema: se mettiamo in forma grafica il carico delle CPU di un server o di uno switch vedremo un certo andamento che si ripete nel tempo. Il traffico TCP a cui un sistema è sottoposto è strettamente legato al tipo si servizio che il server eroga, analizzando quindi il traffico di un File Server vedremo per lo più sessioni CIFS o NFS con i vari client della rete e l’intensità del traffico è legata alla presenza di utenza in rete. Anche in questo caso le “conversazioni” tra client e server possono essere quantificate nel tempo a produrre un grafico dove vedremo, ancora una volta, l’andamento delle sessione CIFS del nostro File Server MS.

L’analisi dei comportamenti dei sistemi informatici (behaviour analysis) ci aiuta ad imparare quale sia il comportamento tipico di un sistema complesso (applicazioni, server, reti, persone) e di individuare variazioni sensibili nei trend registrati. Questo consente di poter individuare rapidamente comportamento diversi dall’ordinario senza impostare delle soglie di allarme come si farebbe in un sistema di monitoraggio.

L’analisi comportamentale non prevede statiche impostazioni di policy o soglie di funzionamento, in primo luogo perché non necessariamente i dati raccolti possono essere trattati in questo modo ma soprattutto perché il focus non è il raggiungimento di una soglia critica ma la presenza di comportamenti non consueti e quindi degni di interesse.

Esempio: osservando l’immagine allegata si vede una CPU che tendenzialmente lavora tra il 20% e il 60% di carico e ad una precisa ora il carico varia assestandosi poco sotto il 20%. Un sistema di monitoraggio ci avviserebbe probabilmente solo se la CPU raggiungesse il 90-100% del carico (a seconda delle impostazioni scelte) per un certo periodo di tempo, in questo caso quindi nulla sarebbe accaduto. L’analisi comportamentale ci dice che la CPU sta lavorando in un modo in cui di solito non lavora. Questo diverso approccio porta ad individuare situazione dove le soglie non agirebbero ma dove evidentemente è successo qualcosa che ha avuto un impatto sul carico della CPU.

Il modello di machine learning che personalmente trovo più interessante per individuare un comportamento o pattern è quello dell’apprendimento non supervisionato: il programma, dato un input, cerca di trovare uno schema nei dati collezionati senza che questi vengano etichettati a priori. In questo modo è possibile scrivere algoritmi generici in grado di cercare schemi strutturati in eterogenee fonti di informazioni come possono essere i sistemi informatici di cui si vuole eseguire l’analisi.

La particolarità di questo modello sta nella capacità della macchina di migliorarsi nell’attività di riconoscimento dei pattern e delle relative anomalie. Questo è possibile in quanto con l’aumentare dei campioni di input è possibile istruire l’algoritmo affinché vengano considerati i dati nel loro insieme e non solo in intervalli di tempo definiti aprioristicamente.

In ICT esistono due principali campi di applicazione di questo modello.

Indubbiamente l’analisi di questi dati è utile per comprendere se un sistema complesso, composto da diversi software che collaborano, sta performando correttamente e, in caso contrario, è estremamente utile all’individuazione delle anomalie che impattano sulle prestazioni del sistema.

Sul fronte della sicurezza informatica l’utilità è forse più lampante: malware e attacker generano tipicamente comportamenti inattesi all’interno dei sistemi informatici e tali comportamenti spesso passano inosservati ai classici sistemi di sicurezza che basano il loro funzionamento su specifiche firme o soglie.

In generale è più utile sapere se un utente sta eseguendo attività che di solito non esegue (es: copia massiva dei dati dal File Server) più che bloccare aprioristicamente tutti i canali di comunicazione verso l’esterno, tali azioni possono invece essere eseguite dal sistema che individua l’anomalia (remediation). In questo modo se il sistema ha imparato che l’utente Mario Rossi tipicamente lavora su 50 file al giorno e scambia 2 GB di dati con il File Server, potremmo istruirlo nel limitare il suo accesso ai servizi nel caso in cui il suo comportamento evidenzi una sensibile variazione… E in caso sarà possibile allertare il team competente.

In questo caso potremmo scoprire che la workstation di Mario Rossi è stata compromessa ed è in corso un tentativo di furto di informazioni, o che Mario Rossi stesso sta prelevando massivamente informazioni dal File Server senza apparente ragione che verrà puntualmente indagata.

Concludo con una nota non tecnica: esistono diverse soluzioni che mettono a disposizione queste potenzialità, alcune molto verticali dove sono già pronte alcune specifiche funzionalità, altre molto generaliste che richiedono molte configurazioni per lavorare correttamente. Ho avuto modo di notare che spesso ci si sofferma sulla rete con il paradigma Network-as-a-Sensor, sistema che trovo valido ma che reputo un po’ limitato rispetto alla visione più ampia in cui posso mettere a confronto il traffico di rete con i logs delle applicazioni e le metriche di funzionamento dei sistemi.

Diciamo che, come spesso capita, non c’è una soluzione che spicca particolarmente e il focus deve essere la specifica esigenza.


Team Tecnico Lantech//Longwave