CORSO DI LAUREA IN: Ingegneria Informatica ELABORATO ... · 1.2 Rappresentazione grafica della...
44
CORSO DI LAUREA IN: Ingegneria Informatica ELABORATO FINALE DI PROGRAMMAZIONE II Monitoraggio di affidabilità e sicurezza dei sistemi software Relatore: Candidato: Ch.mo prof. Fabiano Fusiello Antonio Pecchia Matricola N46 002155 Anno Accademico 2016/2017
Transcript of CORSO DI LAUREA IN: Ingegneria Informatica ELABORATO ... · 1.2 Rappresentazione grafica della...
1
CORSO DI LAUREA IN:
Ingegneria Informatica
ELABORATO FINALE DI
PROGRAMMAZIONE II
Monitoraggio di affidabilità e sicurezza dei sistemi software
Relatore: Candidato:
Ch.mo prof. Fabiano Fusiello
Antonio Pecchia Matricola N46 002155
Anno Accademico 2016/2017
2
Ai miei genitori, per i loro sforzi compiuti che hanno contribuito alla formazione della mia personalità. Ai miei amici d’università, che generosamente mi hanno dato una mano ad abbattere la cosiddetta “barriera della disabilità”, consentendomi di affrontare il mio percorso di studi con maggiore disinvoltura.
3
INDICE DELL’ELABORATO:
Capitolo 1: Panoramica sulla sicurezza di un sistema informatico – pag. 5
1.1 Definizione e breve storia del termine di “security”
1.2 Rappresentazione grafica della security informatica
1.3 Minacce e violazioni della sicurezza di un sistema software
1.3.1 Intrusioni
1.3.2 Malware
1.3.3 Virus
1.3.4 Worms e bots
1.4 La guerra fredda tra gli Stati Uniti d’America e la Russia in ambito
informatico
1.5 Conclusioni e considerazioni sulla sicurezza
Capitolo 2: Analisi dei log e architettura di un sistema SIEM – pag. 14
2.1 Concetto e struttura di un generico log
2.2 Le principali strategie e sfide nell’uso di un log
2.3 Modelli di rilievo adottati in un log
2.3.1 Il modello syslog
2.3.2 Il modello SIEM
2.4 Introduzione al SIEM
2.5 Primo modulo: generazione di eventi
2.6 Secondo modulo: collezione di eventi
2.6.1 Due approcci differenti: agent-based ed agentless
2.6.2 Vantaggi e svantaggi
2.7 Terzo modulo: registrazione ed immagazzinamento
2.8 Quarto modulo: analisi
2.8.1 Rule Engine
2.8.2 Correlation Engine
2.8.3 Knowledge Base (KB)
2.9 Quinto modulo: monitoraggio e reporting
4
Capitolo 3: Il Magic Quadrant relativo alle varie tecnologie SIEM – pag. 28
3.1 Descrizione e criteri di classificazione
3.1.1 Scopo della classificazione
3.1.2 Criteri qualitativi: capacità di esecuzione e completezza di visione
3.1.3 Criteri di raggruppamento: niche players, challengers, visionaries
and leaders
3.2 Aggiunta ed esclusione dei fornitori
3.3 Principali fornitori SIEM
3.3.1 Niche player: SolarWinds
3.3.2 Visionary: AlienVault
3.3.3 Challenger: RSA Security
3.3.4 Leader: IBM
3.4 Confronto tra le soluzioni proposte
Capitolo 4: Il software di LogRhythm ed il formato dati CIM – pag. 38
4.1 L’azienda e i suoi obiettivi
4.2 Il formato MDI Fabric
4.2.1 Terminologia e vantaggi
4.2.2 Architettura a strati del MDI Fabric
4.3 Il Common Information Model
4.3.1 Struttura e definizione
4.3.2 Rappresentazione grafica di un CIM
Riferimenti bibliografici – pag. 44
5
Capitolo 1: Panoramica sulla
sicurezza di un sistema informatico
1.1 Definizione e breve storia del termine di “security”
Il termine di “security” non ha mai significato univoco, e può riguardare qualsiasi
ambito e non solamente quello dell’informatica. Più precisamente la sicurezza
informatica rappresenta solo una specializzazione di un problema molto generale e
molto sentito.
Si può partire anche da una semplice affermazione della vita reale e quotidiana: “Ho
appena finito di lavorare al computer, ora lo spengo e lo lascio nella stanza con la
porta aperta, solo che lo sto lasciando incustodito, magari qualcuno vorrà usare il
mio pc” o meglio, da un interrogativo molto interessante da un punto di vista
esemplificativo: “Ho chiuso la macchina? Però non mi sento tranquillo se la
parcheggio lì”.
Si può subito constatare che Il termine di sicurezza è davvero molto generico, e non
deve per forza avere solo ed unicamente un significato oggettivo. La sicurezza è
anche soggettiva, intesa come una prevenzione di un rischio o pericolo, ed è quindi
basata sulla manifestazione o percezione di un qualsiasi essere umano.
In parole povere la sicurezza soggettiva rappresenta quella percepita. Invece la
sicurezza oggettiva è definita come un insieme di regole oppure di strumenti
scientifici e tecnologici in grado di garantire e proteggere ciascuno di noi da qualsiasi
forma di rischio.
Inizialmente non esisteva una vera e propria definizione di sicurezza in ambito
informatico o comunque tecnologico. La prima organizzazione che riuscì a dare una
valida definizione in tale ambito fu la NIST – National Institute of Standard and
Technology, fu fondata nel 1901 ed ebbe come primo direttore Samuel W. Stratton.
Stratton, fondatore del NIST.
6
Per tale organizzazione la “security” è la protezione di un sistema informatico al fine
di raggiungere obiettivi applicabili, ma soprattutto di preservare la disponibilità,
l’integrità e la confidenzialità delle risorse di un sistema informatico.
In particolare, non abbiamo più un’entità unica ed indivisibile, anzi la security è
un’aggregazione di tre singole componenti! Ciascuna delle componenti, inoltre, è
strettamente legata alle altre due.
È possibile parlare graficamente di una “triade”, rappresentata come segue:
Legame tra confidentiality, integrity e availability.
Allora la sicurezza è scomposta in tre parti distinte (ma comunque legate tra di loro)
ed esse hanno anche una propria definizione.
La confidenzialità rappresenta la protezione delle informazioni sensibili del sistema,
evitando di divulgarle a utenti non autorizzati o comunque estranei dal sistema. È in
questo ambito che si gestiscono le restrizioni o livelli di privacy relative ai dati stessi.
La confidenzialità si dice violata se un utente non autorizzato riesca ad effettuare un
qualsiasi tipo di operazione su un dato che non è il suo.
L’integrità è legata invece alla struttura dei dati stessa, che va mantenuta intatta. Si
dice invece “mancare di integrità” se l’utente estraneo riesce in qualche modo a
modificare il dato. L’integrità rappresenta l’elemento cardine della stabilità e delle
funzionalità di un sistema informatico, infatti se dei dati vitali risultano modificati, la
stabilità di un sistema informatico potrebbe essere compromessa.
La disponibilità invece è una caratteristica propria del sistema, che deve pertanto
essere in grado di fornire servizi e funzionalità SOLO a utenti autorizzati.
Queste tre componenti rappresentano ovviamente le fondamenta della definizione
di “security”, successivamente sono però state aggiunte due nuove componenti che
7
sono in grado di completare il quadro. Quindi ai concetti di confidenzialità –
integrità – disponibilità si aggiungono quelli di autenticità e accountability.
L’autenticità è un indice dell’affidabilità di un servizio, cioè bisogna assicurarsi che
quest’ultimo sia prodotto proprio da quel sistema. Si parla invece di violazione di
autenticità se si verifica un tentativo di CREDENTIAL STEALING, ovvero quando un
servizio malevolo che “finge” di essere un altro sito, che inganna così l’utente e
quest’ultimo fornisce, a sua insaputa, dati sensibili al sito “finto” (si preferisce usare
il termine in gergo informatico “fake” che significa appunto falso, contraffatto).
L’accountability è solo una specifica proprietà, attraverso la quale un servizio web
tiene traccia delle attività dell’utenza. Si tratta però di un termine che non va
confuso con quello di tracking, perché il primo tiene conto solo dell’accesso, dell’uso
delle funzionalità del sito e logout dallo stesso.
Invece la tracking è esattamente un’altra cosa, e tiene conto anche dell’attività di un
utente ai minimi dettagli, compreso anche il testo digitato all’interno di un portale
web.
1.2 Rappresentazione grafica della security informatica
La sicurezza informatica può essere interpretata e configurata come un insieme di
nodi connessi ad una rete LAN, i nodi coincidono con i processi che usufruiscono dei
dati presenti all’interno del sistema stesso.
Interpretazione della sicurezza informatica mediante l’uso dei nodi.
8
In pratica, si vuole analizzare lo schema attraverso quattro passi fondamentali:
1) L’accesso ai dati deve essere tenuto sotto controllo. I dati da proteggere
sono quelli posseduti dal sistema operativo, e se si ritiene necessario, si usano
tecniche di crypting per i file system. (Per file system si intende dire un
meccanismo organizzativo attraverso il quale i dati vengono gestiti)
2) L’accesso al computer deve essere vincolato. In questo caso si parla di user
authentication, quindi prima di utilizzare i servizi forniti da un sistema
informatico, l’utente deve essere autenticato. Esistono anche dei sistemi di
sicurezza avanzati, in particolare le impronte digitali per utilizzare gli
smartphone.
3) Le trasmissioni dati devono essere sicure. Si tratta della “network security”, e
la rete è regolamentata dall’uso di protocolli di comunicazione. È anche
importante conoscere la struttura della rete, e come essa è cablata.
4) Protezione dati sensibili. In quest’ultimo caso, invece la sicurezza è
rappresentata dalla confidenzialità (è sufficiente osservare la “triade”
presente nel paragrafo 1.1) ed è buona norma saper tenere una ristretta
categoria di dati, contenente anche informazioni personali, lontana da occhi
indiscreti.
1.3 Minacce e violazioni della sicurezza di un sistema software
1.3.1 Intrusioni
Le intrusioni sono una prima categoria di minaccia alla sicurezza di un sistema
software. In questo ambito si hanno davvero tante tipologie diverse di intrusi. Essi
sfruttano le cosiddette “vulnerabilità” presenti all’interno di un sistema informatico.
Per vulnerabilità si intende dire una sorta di “punto critico”, ovvero una piccola
componente informatica all’interno della quale le misure di sicurezza sono ridotte o
addirittura assenti.
Per quanto riguarda gli intrusi, esistono
due termini di uso comune che vanno
assolutamente analizzati: l’hacker e la
criminal enterprise.
L’ hacker è un intruso che riesce ad
avere accesso a reti informatiche
protette, e successivamente
acquisisce informazioni riservate
oppure modificandole.
9
Più precisamente essi partono dal codice binario e solo grazie ad esso
riescono a comprendere le funzionalità di un sistema software.
La criminal enterprise è decisamente più pericolosa e dannosa, e riesce in
poco tempo a catturare grandi quantità di dati e password. Esse si basano
sullo sfruttamento commerciale della rete Internet spesso a scopo di lucro,
danneggiando anche i sistemi di sicurezza avanzata di uno Stato attraverso il
sabotaggio.
Per sabotaggio si intende dire il disturbo o il danneggiamento di un sistema in
modo da impedirgli il regolare funzionamento.
1.3.2 Malware
Il termine “malware” è molto generico e sta per MALicious softWARE, e si tratta di
una categoria di programmi finalizzati solo per creare danni, oppure di sottrarre (o
persino esaurire!) le risorse di un computer infetto. Di solito i malware vengono
inglobati all’interno di programmi di uso comune, e si comportano come parassiti,
compromettendo il normale funzionamento di un computer.
Le principali sottocategorie di malware potrebbero essere:
- Backdoor: è un punto d’accesso segreto e nascosto all’interno del codice. Di
solito è utile per aiutare il debug di un programmatore, però vi sono casi in cui i
programmatori “malintenzionati” possono avere accesso non autorizzato a dati
e risorse sensibili.
- Logic Bomb: è un malware particolare che si comporta come un esplosivo. Si
tratta di una bomba che “esplode” al raggiungimento di determinate condizioni
(di solito: presenza o assenza di determinati files, oppure allo scadere di un
tempo prefissato) e causando un susseguirsi di operazioni scorrette, come
bloccare un sistema, cancellando singoli files oppure l’intero hard disk.
- Trojan Horse (Cavallo di Troia): è un
malware molto interessante, che è
contenuto in un altro programma
assolutamente innocuo che l’utente
visualizzerà. Egli, ignaro ovviamente della
minaccia presente al suo interno, lo
considera affidabile e purtroppo,
immetterà dati che verranno catturati dal
malware stesso, e quest’ultimo diventa in
10
grado di attivare funzionalità indesiderate del programma e comunque in modo
indiretto.
1.3.3 Virus
Il virus in ambito informatico si comporta come la sua
controparte biologica.
Se in biologia esso si identifica come una parte del DNA che
si lega ad una cellula e la fa replicare, in informatica il virus
è inteso come un frammento di codice che si moltiplica e si
diffonde sempre di più legandosi ai files. Quindi, se si vuole usare un linguaggio più
tecnico, il virus è dotato di un trigger di attivazione che, al raggiungimento oppure
alla verità di una condizione, esso eseguirà una payload di un programma copiando
anche in altri files il suo frammento di codice. In questo modo il virus sarà in grado di
riprodursi iniziando ad infettare il sistema operativo.
Il ciclo di vita di un generico virus è dato da:
- Fase dormiente: il virus è presente sul computer da colpire ma non compie
alcuna attività. Rimane inerte fino a quando non si verificano le condizioni per
la sua attivazione.
- Fase di propagazione: il virus si propaga, riproducendosi ed andando ad
occupare files sia nella stessa macchina che in altri sistemi.
- Fase di attivazione o di trigger: al verificarsi delle condizioni prestabilite, il
virus inizia l'azione dannosa.
- Fase di esecuzione: il virus lavora a pieno regime, infettando prima il file di
partenza e di conseguenza il sistema operativo.
L’argomento dei virus è sicuramente uno dei più delicati ed interessanti da
affrontare, perché abbiamo una continua antitesi tra gli scrittori di codice infetto
(ovvero i creatori dei virus) e gli antivirus.
Infatti, i primi antivirus venivano implementati basandosi sull’idea che, appena un
virus si legava ad un determinato file, si ha un cambiamento delle dimensioni del file
stesso.
Allora questi primitivi antivirus utilizzavano una tabella di confronto con le relative
dimensioni dei file da scansionare, e appena notavano una modifica proprio sulla
dimensione del file, lo segnalavano come infetto attraverso una notifica di allarme
(di solito si usa il termine “alert”) e si procedeva subito all’eliminazione del file e
della relativa infezione.
11
Col passare del tempo, gli scrittori di codice infetto cominciarono a notare il
funzionamento dei primi antivirus e operarono una compressione del loro codice in
modo che tale dimensione non cambi. Gli antivirus infatti non erano in grado di
individuarli.
Per scovare virus legati a codice compresso, bisogna procedere alla virtualizzazione
dei files, in modo tale che, durante una fase di analisi di un antivirus, ed appena esso
nota un comportamento “sospetto” del file (ovvero, ad esempio, se il file di partenza
per continuare la propria esecuzione utilizza altri files presenti nel sistema
operativo), viene segnalato un virus e il programma legato a codice infetto viene
immediatamente interrotto.
Una valida classificazione dei virus è data da:
- Virus criptato (encrypted virus): per aumentare la sua complessità, il “corpo”
del virus viene criptato con chiavi di cifratura random.
- Virus invisibile (stealth virus): qui vi appartengono tutti i tipi di virus che sono
in grado di nascondersi dalla scansione antivirus e pertanto non vengono
rilevati.
- Virus polimorfo: si comporta in maniera dinamica (come nel campo della
biologia) e che “muta” dopo ciascuna infezione.
- Virus metamorfo: è molto simile al virus polimorfo, in più è in grado di
riscriversi completamente dopo un’infezione, vale a dire il suo codice infetto
(metaforicamente possiamo parlare di “DNA” del virus) viene modificato
radicalmente oppure persino sostituito o riscritto.
1.3.4 Worms e Bots
Un worm (in italiano, letteralmente sta per “verme”) è molto simile ad un virus,
però è in grado di autoreplicarsi molto facilmente, ed a differenza di esso, l’attività
di un worm non è necessariamente legata agli eseguibili del sistema operativo
locale, ma esso viene anche propagato negli altri computer attraverso tutti i
meccanismi di comunicazione in rete (e-mail oppure file sharing). Il più delle volte
un worm è considerato a tutti gli effetti un normale virus.
Un bot invece è genericamente un programma automatico (il termine proviene da
roBOT) che svolge compiti che risultano troppo difficili o gravosi per un essere
umano. Alcuni bots però sono implementati dagli scrittori di codice infetto e spesso
circolano all’insaputa dell’utente.
12
Un computer infetto da un bot malevolo o simili viene considerato a tutti gli effetti
un computer zombie che riesce in qualche modo a comunicare con persone non
autorizzate, seppur in maniera molto nascosta.
Questi programmi sono molto sofisticati e risulta molto difficile, se non impossibile,
risalire all’identità del suo creatore. Una rete costituita da un gruppo di bot viene
denominata botnet.
1.4 La guerra fredda tra gli USA e la Russia in ambito informatico
Anche se la campagna
elettorale per la scelta del
prossimo presidente degli
Stati Uniti si è conclusa con la
vittoria di Donald Trump,
l’Amministrazione uscente del
presidente Barack Obama è
stata decisa a pronunciare
dichiarazioni bellicose nei
confronti della Russia di
Vladimir Putin. Gli scambi di accuse sempre più acrimoniosi tra Washington e Mosca
hanno portato i rapporti tra i due Paesi al livello più basso degli ultimi 25 anni.
Sul tappeto due punti fondamentali del confronto tra le superpotenze. Il primo è
riconducibile alla situazione in Siria, dove russi e americani, dopo il fallimento del
tentativo congiunto di stabilire una tregua umanitaria ad Aleppo, hanno interrotto
qualsiasi forma di cooperazione sul terreno e chiuso i canali di scambio di
informazioni tattiche che avrebbero dovuto comportare un coordinamento
dell’impegno militare contro il Califfato. Il secondo elemento di frizione è dato dalle
accuse, alle quali ha dato pubblicamente credito Obama, di interferenze russe nella
campagna presidenziale americana con tentativi di hackeraggio dei sistemi
informatici del partito democratico, presumibilmente volti a raccogliere
informazioni imbarazzanti per Hillary Clinton e quindi in grado di favorire il suo
avversario, Donald Trump.
Per quanto riguarda le accuse di pirateria informatica – finora, occorre sottolineare,
molto generiche e non circostanziate – ribadite nei giorni scorsi dalla Clinton, queste
sono state smentite ironicamente dal ministro degli Esteri russo, Sergei Lavrov, in
un’intervista alla rete televisiva CNN dell’11 ottobre. Nell’intervista Lavrov ha
sostenuto che per il suo Paese è stato “molto lusinghiero ricevere tanta attenzione,
visto che solo qualche tempo fa il presidente Obama ci ha definito una potenza
13
regionale. Comunque su questo tema non abbiamo visto esibire alcuna prova”. Gli
ha fatto eco il 12 ottobre Putin che, a margine di un convegno finanziario a Mosca,
ha liquidato le accuse di interferenza informatica nella campagna presidenziale
definendole prive di fondamento e “dettate dall’isteria”.
La Cia ha ricevuto ordine da Barack Obama di preparare un cyber attacco "senza
precedenti" contro la Russia in risposta alle interferenze di Mosca nelle elezioni
presidenziali americane. Lo riporta in esclusiva la Nbc citando fonti dell'intelligence
americane. Nei giorni scorsi la Casa Bianca ha preannunciato la possibilità di un
attacco di questo tipo dopo i molti attacchi informatici contro interessi statunitensi
che per lo stesso Obama vogliono destabilizzare il sistema politico degli Stati Uniti.
L'avvertimento. Ancora più dura la reazione del Cremlino durante una cooperazione
internazionale sulla sicurezza informatica, e ha lanciato un vero e proprio
avvertimento agli Usa: "Stanno giocando con il fuoco. Invece di cercare una
distensione e tentare di raggiungere un accordo, stanno cercando di spaventarci. Lo
trovo sfacciato, rozzo e stupido".
Tutte queste dichiarazioni sono state pronunciate nel mese di ottobre 2016.
1.5 Conclusioni e considerazioni sulla sicurezza
La sicurezza va considerata come una problematica in continua evoluzione, così
come si sviluppano le tecnologie sistemistiche. Diciamo che è complessa da
affrontare in quanto l’evoluzione informatica ha andamento esponenziale.
È importante avere strumenti software sempre più sofisticati in grado di respingere
anche le minacce più recenti, però questo non deve essere considerato come l’unico
fattore chiave nell’ambito della security informatica. Anzi, a mio parere, è forse più
importante saper prevedere qualsiasi forma di attacco o minaccia.
Ovviamente alcuni programmi che utilizziamo sono dotati di questa feature, ma se si
è in grado di comprendere tali problematiche anche in maniera soggettiva, è
sicuramente un grande vantaggio, perché in questo modo potremo evitare
direttamente una determinata minaccia, senza che il programma stesso (che sia un
antivirus, oppure un sistema SIEM e così via) debba rilevarla oppure bloccarla, anche
perché l’ultimo caso vale se la minaccia in questione ha già iniziato la sua attività
all’interno del computer “vittima”.
14
Capitolo 2: Analisi dei log e
architettura di un sistema SIEM
2.1 Concetto e struttura di un generico log
Un log è definito come un record di eventi che si verificano all’interno dei sistemi o
reti di un’organizzazione. I log sono costituiti da righe/entries; ogni entry contiene
informazioni relative ad uno specifico evento che si è verificato all’interno di un
sistema o di una rete.
In passato, i log erano usati soprattutto per la risoluzione dei problemi. Ora svolgono
molteplici funzioni come l’ottimizzazione delle prestazioni dei sistemi e delle reti, la
registrazione delle azioni degli utenti, l’investigazione sulle attività malevole.
In seguito all’aumento del numero di dispositivi e all’aumento delle minacce a tali
sistemi, il numero di log è sempre aumentato, e si è arrivati al punto di richiedere un
vero e proprio processo di log management. Con log management si intende il
processo di generazione, trasmissione, memorizzazione, analisi e messa a
disposizione dei log di sicurezza.
È possibile costruire un elenco di software che utilizzano i log.
- Firewall: Blocca o permette il passaggio di traffico di rete. Generalmente
viene generato un record di log per ogni pacchetto o per ogni sessione del
traffico di rete che attraversa il firewall.
- Sistemi AntiMalware:
Tipicamente registrano
tutte le istanze di
malware, file e sistemi
disinfestati e file messi
in quarantena. In più, i
software antivirus (che
a loro volta sono anche
strumenti anti-malware)
possono anche
registrare quando
vengono effettuate
scansioni alla ricerca di
infezioni e quando viene
Registrazione di una scansione con l’antivirus di Avast.
15
fatto l’update del database del motore di scansione.
- Virtual Private Network software: Le VPN garantiscono l’accesso remoto in
modalità sicura alle risorse aziendali. I log di tali sistemi contengono
generalmente tentativi di autenticazioni, sia falliti che andati a buon fine,
durata e provenienza delle connessioni, comprese anche le risorse a cui
l’utente ha avuto accesso.
- Web proxy: I web proxy sono sistemi che fungono da intermediari
nell’accesso alle risorse web, mantenendo una cache locale delle pagine web
e restringendo l’accesso ad alcune risorse web basandosi su policy definite,
proteggendo così la rete dell’organizzazione. I log registrano gli url a cui gli
utenti hanno avuto accesso attraverso il web proxy.
- Applicazioni: Anche i software di uso comune presenti in un computer
possono generare i log, ed essi variano enormemente a seconda del contesto
d’uso delle applicazioni stesse. In particolare si possono registrare le richieste
del client e relative risposte del server (per le applicazioni che necessitano la
comunicazione in rete), le informazioni di un account, le informazioni delle
transazioni compiute attraverso un motore DBMS, o altri eventi significativi
come il verificarsi di una situazione di errore o modifiche della configurazione
di un programma.
2.2 Le principali strategie e sfide nell’uso di un log
Per quanto riguarda l’elenco delle strategie, si ha come segue:
I. Centralizzare nel sistema di log management tutti gli eventi rilevanti. Una
volta definiti gli eventi rilevanti per la propria organizzazione, bisogna fare in
modo che tali eventi siano registrati all’interno di un sistema centralizzato,
con operazioni di filtraggio, aggregazione e normalizzazione.
II. Definire l’ambito di applicazione. Occorre informarsi su quali sistemi rilevanti
viene effettuato il monitoraggio di una determinata categoria di eventi, della
sicurezza o del rispetto alle normative, oppure produrre un documento che
definisca dove sono registrati gli eventi e il periodo di conservazione per ogni
tipologia di log.
III. Revisionare in maniera tempestiva i log. Definire quali sono gli eventi di
interesse, ovvero quelli che possono costituire una minaccia, tenendo conto
che, dei milioni di log prodotti giornalmente, di solito meno dell’1%
rappresenta una minaccia. Inoltre, è necessario stabilire un intervallo di
tempo affinché l’evento venga sottoposto da una determinata procedura,
16
ovviamente solo su eventi “sospetti”. Infine bisogna produrre dei report degli
eventi principali dei dispositivi di sicurezza.
Invece, nell’ambito delle sfide, ovvero degli approcci da adottare per affrontare
problematiche legate al monitoraggio ed alla sicurezza informatica, ce ne sono tre di
rilievo:
A. Gestione e registrazione nel caso di log multipli. Si possono verificare
situazioni in cui si generano diverse tipologie di log, ad esempio
un’applicazione può registrare gli eventi di autenticazione in un log e l’attività
di rete in un’altra. Per efficienza, spesso la sorgente
di log registra solo la parte di informazione ritenuta più importante, e
purtroppo altre informazioni, non comunque secondarie, venivano omesse.
Inoltre il timestamp assume un ruolo fondamentale. Ogni sorgente di log
registra eventi associando un timestamp basato sull’orologio interno del
sistema. Occorre evitare che l’evento venga registrato con un timestamp non
preciso, va a finire che durante la fase di analisi dei log una certa sequenza di
eventi si sia svolta con un ordine cronologico diverso da quanto avvenuto
realmente.
Un’altra problematica è la leggibilità dei log. Molte sorgenti di log usano
diversi formati, come campi separati da virgola, campi separati da
tabulazioni, database, syslog, file xml, file binari. Alcuni formati di log sono
pensati per essere letti da umani, altri no. Per facilitare l’analisi dei log,
occorre implementare sistemi automatici che siano in grado di convertire log
che hanno contenuti e formati differenti verso un formato standard con una
rappresentazione coerente dei campi dati.
B. Protezione dei log. Alcuni log provenienti dai diversi sistemi
dell’organizzazione possono contenere dati delicati dal punto di vista della
sicurezza o della privacy, come password di utenti, dati relativi alla
navigazione oppure e-mail. È necessario preservare la confidenzialità e
l’integrità nell’ambito della security di un sistema software (basti vedere la
triade indicata nel paragrafo 1.1). I log infatti non devono essere alterabili, in
modo tale che i malintenzionati non riescano a coprire le loro tracce. Inoltre
anche la disponibilità dei dati deve essere preservata. Purtroppo in molti
sistemi sono configurati in modo che i file di log abbiano una dimensione
massima e che, raggiunta tale dimensione, i file di log siano sovrascritti.
Inoltre, occorre che le organizzazioni debbano conservare i log per un
periodo di tempo maggiore rispetto a quello di default sui sistemi di origine.
17
C. Analisi dei log. Spesso l’analisi dei log è considerata un’attività a bassa
priorità da amministratori e dal management team, perché altre attività degli
amministratori necessitavano di risposte più rapide. Gli amministratori che
effettuano l’analisi dei log spesso non ricevono formazione adeguata per
effettuare l’analisi efficacemente ed efficientemente, particolarmente per
quel che riguarda l’attribuzione delle priorità. Inoltre molti amministratori
non hanno a disposizione tools che siano efficaci nell’automatizzazione dei
processi di analisi. Un altro problema consiste nel fatto che molti
amministratori considerano l’attività di analisi dei log noiosa e poco proficua
rispetto al tempo richiesto. L’analisi dei log ha un ruolo seriamente vitale per
identificare problemi imminenti. Tradizionalmente, la maggior parte dei log
non viene analizzata in real-time.
2.3 Modelli di rilievo adottati in un log
2.3.1 Il modello syslog
Il syslog fornisce un semplice framework per la generazione, lo storage e il
trasferimento dei log, che ogni sistema operativo, software di sicurezza o
applicazione può utilizzare, sempre se è progettato per poterlo fare. Molte sorgenti
di log usano syslog come formato nativo oppure offrono la possibilità di convertire i
log dal loro formato nativo a syslog.
Lo standard syslog consente di operare una classificazione del messaggio, al fine di
di stabilirne la tipologia e la priorità, sfruttando due attributi: la facility e la severity.
La facility rappresenta la tipologia del messaggio, alcune di esse potrebbero essere:
messaggio del kernel, messaggio di autorizzazione, di sicurezza o dell’applicazione.
La severity, ovvero la priorità, è un numero intero compreso fra 0 (emergency) e 7
(debug).
Il formato syslog è pensato per essere molto semplice e prevede che ogni messaggio
sia formato da 3 parti: la prima parte contiene la facility e la severity descritte
sopra, la seconda parte contiene il timestamp e il nome host (o l’indirizzo IP, nel
caso sia un servizio di rete) del sistema che ha generato l’evento e la terza parte è il
contenuto o payload del messaggio.
Per quanto rigaurda la memorizzazione dei syslog, di solito si effettua un salvataggio
con file di testo locali al sistema che li ha generati oppure può essere effettuando un
forward/inoltro verso uno o più sistemi centralizzati.
In origine il problema più grave è che il syslog era insicuro. Lo standard syslog è
stato progettato in tempi in cui la sicurezza dei log non era oggetto di molta
18
considerazione, per cui presenta alcuni aspetti critici. In primo luogo il protocollo di
trasporto utilizzato da syslog per la trasmissione sulla rete era l’UDP, protocollo
senza connessione che non garantisce la consegna dei pacchetti. In secondo luogo, il
server syslog che raccoglie messaggi via rete non effettuava nessuna forma di
autenticazione, per cui qualsiasi sistema può inviare messaggi al server syslog, senza
nessun ulteriore controllo. In terzo luogo, i log trasmessi via rete da syslog
viaggiavano in chiaro ed era quindi possibile intercettarli.
Fortunatamente, ai tempi d’oggi, vengono attuate alcune implementazioni di syslog
risolvendo alcuni di questi problemi, per esempio utilizzando TCP invece di UDP,
oppure un meccanismo di crittografia e la memorizzazione su database.
2.3.2 Il modello SIEM
Il modello System Information and Event Management (SIEM), pur non essendo
standardizzato prevede maggiori funzionalità rispetto al modello syslog e prevede
un’infrastruttura più complicata ed articolata, contenente uno o più server che
permettono l’analisi dei log, dei strumenti per la correlazione degli eventi, uno o più
database server per lo storage dei log, strumenti sofisticati per la ricerca e la
reportistica. E’ un modello molto sicuro e soprattutto organizzato che sicuramente
può sostituire il tradizionale syslog.
Ora è possibile passare al prossimo paragrafo, dove vengono trattati proprio i SIEM.
Proprio a causa degli svantaggi legati all’uso di un syslog, oggi il SIEM è nettamente
più considerato.
2.4 Introduzione al SIEM
La tecnologia dei sistemi SIEM (Security Information and Event Management) ha
come obiettivo la raccolta centralizzata degli events oppure log, generati da
applicazioni e sistemi in rete, per consentire agli analisti di sicurezza di ridurre i
tempi necessari per le risoluzioni e le indagini su allarmi e incidenti di sicurezza.
Essi sono una combinazione/integrazione di quelli che una volta erano sistemi
separati rientranti nell'ambito dei SIM (security information management - sistemi
di gestione delle informazioni di sicurezza) e dei SEM (security event management -
sistemi di gestione degli eventi di sicurezza) e a volte sono utilizzati come se fossero
intercambiabili.
Ma la cosa che contraddistingue meglio il modello SIEM da qualsiasi sistema di log è
sicuramente l’analisi dei log in tempo reale (real-time analysis).
19
Inoltre il SIEM è caratterizzato da un’elevata modularità. Possiamo distinguere
persino cinque moduli distinti: generazione di eventi, collezione di eventi,
registrazione e immagazzinamento, analisi, monitoraggio e reporting.
Nel seguito del capitolo approfondiremo le funzioni di ciascuno di questi moduli,
unitamente ad una discussione sulle problematiche da affrontare e le possibili
soluzioni. Verranno anche discusse le modalità di integrazione fra i diversi moduli.
Le principali funzioni di un sistema SIEM.
Nell’immagine riportata di sopra, in ordine si ha: scoperta degli asset, accertamento
delle vulnerabilità, rilevamento delle minacce, collezione di eventi, correlazione,
gestione degli eventi e memorizzazione dei log.
Si ricorda che gli asset, nell’ambito della security informatica, è una qualsiasi risorsa
aziendale, che sia un dato, un dispositivo o un computer situato all’interno
dell’organizzazione aziendale.
È anche di notevole importanza conoscere la struttura complessiva o architettura di
un sistema SIEM, che è preferibile riportare in anticipo, successivamente si procede
allo studio dei singoli moduli di un SIEM.
L’architettura è data nella pagina successiva di quest’elaborato.
20
Schema modulare complessivo di un generico sistema SIEM.
2.5 Primo modulo: generazione di eventi
Ad una prima analisi questo modulo sembrerebbe non fare parte del SIEM, tuttavia,
considerando il SIEM come un processo complessivo ed articolato e non un semplice
sistema da acquistare ed installare, anche questo modulo rientra a tutti gli effetti nel
SIEM.
È possibile distinguere due tipi di generatori degli eventi:
21
-I generatori di dati basati su eventi (sensori), generano eventi corrispondenti a
specifiche operazioni svolte da sistemi operativi, applicazioni, dispositivi di sicurezza
e così via sulla rete.
-I generatori di dati basati sullo stato (poller), generano eventi basati sulla reazione
a stimoli esterni, come dati relativi a controlli di integrità o demoni (daemon) che
hanno il compito di verificare lo stato di un certo servizio.
Per quanto riguarda i sensori, si possono far rientrare in questa categoria la maggior
parte delle tipologie di log di sicurezza elencati nella parte introduttiva del capitolo
2, come i log di firewall, VPN, sistemi di autenticazione, i log di sistemi operativi e
applicazioni. Tutti questi tipi di log sono generati, appunto, dagli sensori.
Per quanto riguarda invece i poller, il loro scopo è quello di generare un evento tutte
le volte in cui
un sistema terzo o esterno raggiunga un determinato stato. In un ambito di
sicurezza, i poller sono responsabili della verifica dello stato di servizi e dell’integrità.
2.6 Secondo modulo: collezione di eventi
2.6.1 Due approcci differenti: agent-based ed agentless
Il compito di questo modulo è quello di raccogliere informazioni dai diversi sensori e
poller ed effettuare un processo di traduzione in un formato standard, al fine di
realizzare una base omogenea di eventi.
Esistono principalmente due metodi di collezione. Si parla di metodo basato su
agenti (agent-based) quando esso avviene attraverso un agente software del SIEM
installato sul sistema sorgente, in caso contrario, di metodo senza agenti (agentless),
ovvero quando sul sistema di riferimento non vi sono specifici agenti installati.
-Agent-based: Un agente software è installato sui sistemi che generano i log, allo
scopo di effettuare filtraggio ed aggregazione per un certo tipo di log, trasmettendo
poi i dati dei log normalizzati, quasi sempre in real-time, per l’analisi e
l’immagazzinamento. Se in un sistema è possibile distinguere più tipologie di log di
interesse, è ovviamente necessario installare più agenti.
-Agentless: Nel caso di sistemi senza agente, vi sono due approcci differenti. In
primis, esiste il metodo pull attraverso il quale i sistemi SIEM stabiliscono la
connessione col sistema sorgente grazie a meccanismi di autenticazione ed andando
a recuperare in periodi di tempo regolari i log presenti, solitamente, in un database.
L’altro approccio è costituito dal metodo push che invece implementa un
meccanismo di comunicazione inverso, ovvero basato sul fatto che è il sistema
22
sorgente ad inviare i log al SIEM, ed in quest’ultimo viene inserito un receiver di tali
dati. Un esempio è l’ormai obsoleto (sul piano della sicurezza) syslog.
2.6.2 Vantaggi e svantaggi
Per quanto riguarda l’approccio agentless, il vantaggio principale è che non occorre
installare, configurare e gestire agenti in ogni sorgente di log. Lo svantaggio sta
invece nel fatto che non è possibile effettuare l’operazione di filtraggio,
aggregazione e normalizzazione a livello di sistema sorgente. Un altro possibile
svantaggio è nella necessità di dotare il SIEM di credenziali valide per ogni sistema
sorgente.
Nella maggior parte dei casi, i SIEM hanno comunque metodi predefiniti per il
filtraggio, l’aggregazione e la normalizzazione di log di particolari sistemi o
applicazioni.
Invece per sistemi o applicazioni che non sono dotati di metodi predefiniti i SIEM
forniscono normalmente vari tools che permettono di costruirsi i propri metodi,
rendendo il SIEM molto più flessibile. Naturalmente per costruire il proprio metodo
di collezione è indispensabile conoscere il formato dei log da collezionare e dei
campi dati disponibili all’interno del SIEM.
Per quanto riguarda i significati dei termini che si riferiscono ad azioni sui log:
-filtraggio: si intende la selezione, all’interno del sistema sorgente, dei log che
hanno un certo interesse per la successiva registrazione e analisi e l’esclusione dei
log privi di interesse.
-aggregazione: è il consolidamento di più eventi simili in un’unica entry della
struttura tabellare che abbia un campo contatore del numero di eventi.
-normalizzazione: è un processo volto ad eliminare la ridondanza informatica e
qualsiasi altra forma di incoerenza del contenuto informativo presente nel database.
2.7 Terzo modulo: registrazione ed immagazzinamento
Conoscendo l’elevato numero dei log presenti ai tempi d’oggi, è buona norma
conoscere un meccanismo di memorizzazione di tali log e di conservarli in un
periodo di tempo sufficientemente lungo, in modo che sia possibile l’analisi in un
secondo momento.
Qui assume un ruolo fondamentale la gestione dei database, effettuando query con
l’obiettivo di estrarre informazioni ed eventi di interesse.
23
In ogni caso, generalizzando, esistono tipicamente tre metodi di memorizzazione
dei log: in un database, in file di testo, in file binari. Il caso di memorizzazione in un
database standard
è attualmente il più utilizzato, in quanto è il sistema che permette solitamente il
miglior compromesso fra la necessità di utilizzare i log da parte di altre applicazioni,
la necessità di eseguire facilmente le analisi, e la necessità di accedere a tali dati in
maniera efficiente. I file di testo, pur permettendo l’accesso ai log da parte di altre
applicazioni e di eseguire facilmente analisi, non permettono di accedere in maniera
efficiente ai dati, soprattutto in presenza di archivi contenenti grandi quantità di log.
Al contrario, i formati binari permettono di accedere in maniera efficiente ai dati,
ma non permettono l’accesso ad altre applicazioni al di fuori del SIEM stesso.
Adesso è possibile concentrarsi sulla struttura delle tabelle dei messaggi utilizzate
dal SIEM, in particolare all’interno di un database. Anche se i campi variano
ovviamente a seconda della tipologia implementata nel SIEM, esiste comunque un
insieme minimo di campi coincidenti, o meglio, universali in tutte le varie tecnologie.
1) Time: Contiene il timestamp in cui è avvenuto l’evento. C’è la possibilità di
affiancamento da altri timestamps.
2) Type: Contiene il tipo di sistema che ha generato l’evento, per esempio
sistema operativo, database, firewall, ecc.
3) Category: Contiene la tipologia dell’evento, per esempio se si tratta di
un’autenticazione, di un’autorizzazione, dell’avvio di un’applicazione, ecc.
4) Severity: Contiene il livello di pericolosità dell’evento.
5) Device: È l’identificativo del sistema che ha generato tale evento. Potrebbero
esserci dei sottocampi, in particolare l’indirizzo IP oppure l’hostname.
6) Source: È il computer di origine dell’evento.
7) Destination: Contiene il destinatario dell’evento.
8) User: Contiene, se esiste, l’account che ha generato l’evento. Può essere
diviso in user sorgente e user destinazione per tenere conto del caso di
eventi che contengano una sorgente e una destinazione.
9) Message: Contiene un testo che descrive l’evento, ovvero il “corpo”
dell’evento stesso.
Nella pratica, in generale, il SIEM è in grado di registrare non solo ed unicamente gli
eventi, ma anche le statistiche, e gli alert.
2.8 Quarto modulo: analisi
L’analisi, come è chiaro, ha il compito di rilevare attacchi oppure tentativi di
violazione facendo riferimento al contenuto testuale presente nei log. SI possono
24
distinguere ben tre differenti componenti per l’analisi dei log, il rule engine, il
correlation engine o la base della conoscenza (Knowledge Base o semplicemente KB)
2.8.1 Rule Engine
Il rule engine, solitamente, permette di generare allarmi da mostrare sulla console
agli analisti oppure da inviare via mail, in base al verificarsi di determinate
condizioni. Generalmente le regole vengono scritte utilizzando una qualche forma di
logica booleana.
Si vuole presentare l’argomento attraverso un esempio pratico, come quello di
generare un alert ad ogni accesso dell’utente al server remoto usufruendo delle
credenziali amministrative locali. Normalmente dovremmo definire diversi trigger
all’interno dei diversi sistemi, mentre in un SIEM, utilizzando la logica interna, è
possibile definire un’unica regola basata su diverse variabili che definisca un
trigger. La regola, in forma grafica, è espressa come:
Schema logico sull’esempio di un accesso remoto con i permessi di amministratore.
2.8.2 Correlation Engine
Uno strumento sicuramente più sofisticato per generare allarmi è rappresentato dal
correlation engine, un sottoinsieme del rule engine che permette di correlare
diversi eventi provenienti da diverse sorgenti creando un unico evento correlato.
Tale correlazione viene operata allo scopo di semplificare l’identificazione di
potenziali incidenti e le procedure di risposta.
25
Per correlare gli eventi in uno solo, dal punto di vista implementativo è sufficiente
usare gli operatori booleani, in particolare OR e AND espressi in termini di codice.
Volendo si può fare un esempio di analisi in una sorta di pseudocodice che porta a
considerare un attacco di forza bruta, ed è il seguente:
if [ ( failed login > 2) and then ( successful login ) ]
from the same source within 15 seconds =
Possible Brute Force Attack Attempt
2.8.3 Knowledge Base
La Knowledge Base è, in sintesi, un contenitore di regole utilizzato nel campo
dell’intelligenza artificiale, oppure un database informativo di un’organizzazione
aziendale. Però in ambito della sicurezza, essa assume un ruolo completamente
differente. Questo permette di valutare se un tentativo di intrusione su un certo
sistema può effettivamente portare ad un’intrusione e il livello di criticità di tale
tentativo di intrusione.
Fanno parte della Knowledge Base il database degli asset e soprattutto il database
delle vulnerabilità.
Si vuole trovare una definizione appropriata dei due componenti (perchè essi si
trovano nell’immagine triangolare introduttiva del capitolo 3, ed assumono un ruolo
vitale nel processo SIEM):
- Il database degli asset: è utilizzato per definire alcuni aspetti delle configurazioni
dei sistemi, il tipo di servizio garantito all’interno del sistema informativo, gli altri
sistemi al quale sono correlati, comunque in definitiva lo scopo è quello di
determinare il livello di criticità dei sistemi e l’impatto che può avere un’eventuale
intrusione.
- Il database delle vulnerabilità: contiene informazioni relative alle violazioni
della sicurezza e ai comportamenti insicuri che possono avere impatto sul livello
globale di sicurezza o che potenzialmente possono essere utilizzate da un attaccante
allo scopo di effettuare un’intrusione. Il database delle vulnerabilità può contenere i
seguenti tipi di vulnerabilità:
I. vulnerabilità strutturali, ovvero presenti in software specifici. Questa parte
del database può essere popolata grazie a report ottenuti da software di
vulnerability scanner.
26
II. vulnerabilità funzionali, ovvero vulnerabilità legate a configurazioni e
comportamenti degli utenti. Contrariamente alle vulnerabilità del tipo
precedente, queste dipendono fortemente dall’ambiente in cui risiedono.
La parte più complicata è trovare un modo per definire / formattare questo
tipo di vulnerabilità in maniera tale da popolare il database, cioè trovare
un’appropriata definizione o tipologia di tali vulnerabilità prima di essere
inserite sotto forma di entry nel database.
III. vulnerabilità basate sulla topologia di rete. Questa parte del database
include le vulnerabilità di rete così come l’impatto di intrusioni nella rete con
le loro relative conseguenze. Al fine però di inserire tali informazioni nel
database, è necessario un minimo di modellazione topologica.
Concludendo, l’obiettivo finale della Knowledge Base è quella di valutare lo stato di
sicurezza dei sistemi monitorati. Le informazioni contenute nella Knowledge Base
possono essere processate da un apposito engine, che fornirà una lista delle
vulnerabilità a cui ogni sistema è soggetto e il potenziale impatto di ogni
vulnerabilità. Tale valutazione andrà rigenerata ogni qualvolta venga trovata una
nuova vulnerabilità e ogni qualvolta ci siano modifiche ai sistemi monitorati.
2.9 Quinto modulo: monitoraggio e reporting
Il monitoraggio rappresenta la modalità con cui gli analisti della sicurezza
interagiscono con i log registrati nel SIEM. Generalmente i SIEM hanno una console,
che può essere web-based, o che rispetti il paradigma client/server, in grado di
interagire con i dati registrati sul SIEM. In generale sono presenti tre interfacce di
rilievo:
A. interfaccia per il monitoraggio real-time: fornisce una visione istantanea e
real-time degli eventi che arrivano al SIEM, permettendo un filtraggio base
allo scopo di isolare i messaggi di interesse. Questa interfaccia è usata per
scopi di debugging, per analisi approfondite di eventi specifici o per reazione a
determinati eventi.
B. interfaccia per la gestione degli incidenti: è l’engine utilizzato per la gestione
di ciascun incidente verificato, in particolare serve per avviare procedure di
reazione e risoluzione.
C. interfaccia per le analisi statistiche: fornisce e consente la memorizzazione di
dati sulle statistiche di attività di sicurezza di breve, medio e lungo periodo.
27
Oltre alle console, i SIEM hanno anche strumenti secondari, a disposizione dei
responsabili della sicurezza e del management aziendale. Sono presenti quindi, le
ulteriori interfacce:
-interfaccia per la valutazione dei rischi: fornisce informazioni sull’attuale
livello di sicurezza delle configurazioni dei sistemi monitorati e dei software
installati. Fornisce informazioni sul livello di sicurezza globale, sulle
vulnerabilità e le criticità, gli scenari di intrusioni e i dettagli sulle configurazioni.
-attività di sicurezza: fornisce report a medio e lungo termine sulle intrusioni
verificatisi. I parametri di ciascuna intrusione sono suddivisi in: tipo, frequenza,
sorgente d’origine e conseguenze sui sistemi monitorati. Quest’attività è
particolarmente utile per determinare i sistemi maggiormente colpiti, e per
prevedere in qualche modo questi attacchi.
-stato dei sistemi: fornisce un riepilogo sugli incidenti aperti, sistemi sotto
attacco, e anche meccanismi di intrusione in esecuzione. Fornisce informazioni
sulle procedure di reazione che verranno messe in atto allo scopo di circoscrivere
l’attacco, ovvero delimitare e bloccare la propagazione delle sue conseguenze.
28
Capitolo 3: Il Magic Quadrant
relativo alle varie tecnologie SIEM
3.1 Descrizione e criteri di classificazione
3.1.1 Scopo della classificazione
Le tecnologie SIEM attualmente hanno un ruolo centrale, soprattutto a causa di un
crescente numero di minacce circolanti nei vari sistemi informatici. Questo Magic
Quadrant fornisce un raggruppamento delle varie aziende che hanno realizzato dei
prodotti SIEM per investigare e per analizzare i log. Ovviamente tali fornitori hanno
dei approcci differenti, e quindi vengono distinti per alcune caratteristiche salienti
rispetto ad altre.
Questa classificazione viene fornita da una società di ricerca americana, la Gartner,
fondata nel 1979, e lo scopo di tale raggruppamento è quello di fornire un’analisi
qualitativa del mercato nell’ambito di queste tecnologie, e genericamente si basa
sulla capacità di dirigere i prodotti nel mercato, sulla maturità di ciascuna azienda e
sull’abilità dei suoi membri.
Dunque il Magic Quadrant ha un ruolo puramente statistico, e viene costantemente
aggiornato ogni 1-2 anni.
3.1.2 Criteri qualitativi: capacità di esecuzione e completezza di visione
I criteri qualitativi sono riportati in un grafico bidimensionale, che verrà riportato
successivamente nel paragrafo 3.3, ed esso presenta nell’asse delle ascisse il valore
relativo alla completezza di visione, mentre nell’asse delle ordinate è riportato il
valore relativo alla capacità di esecuzione, intesa anche come “capacità di fare”.
Per quanto riguarda la completezza di visione, essa è suddivisa in:
A. Comprensione del mercato. Tiene conto della valutazione della tecnologia sia
dei fornitori attuali che quelli emergenti, e di convertire le loro esigenze ed
idee in prodotti e servizi SIEM. I fornitori che presentano un alto grado di
completezza di visione sono quelli più preparati alle maggiori esigenze del
cliente, come la necessità di contrastare attacchi e minacce precoci, e
forniscono un’implementazione semplice e curata dei loro servizi.
B. Strategia nel marketing. Rappresenta la capacità del fornitore di comunicare
effettivamente il valore e la differenziazione dei suoi servizi SIEM offerti.
C. Strategia di vendita. Tiene conto della valutazione delle vendite dirette ed
indirette di un singolo prodotto SIEM.
29
D. Innovazione. Rappresenta la capacità di un’azienda di sfornare prodotti SIEM
che siano in grado di distinguersi dalla concorrenza e quindi capaci di
soddisfare esigenze specifiche della clientela. Alcune di esse potrebbero
essere: la rilevazione avanzata delle minacce, le query ad hoc in un database,
le funzioni per la gestione del flusso di lavoro, e persino il monitoraggio
all’interno di ambienti cloud.
E. Strategia geografica. È un indice dei guadagni che un’azienda produce in base
alla sua posizione territoriale. I mercati SIEM nel Nord America (Usa, Canada)
e quelli europei sono sicuramente quelli che creano maggiori profitti. Poi ci
sono quelli del Medio Oriente, quelli asiatici e in Australia che appartengono
alla categoria dei “mercati SIEM emergenti” e che stanno man mano
espandendo e diventando sempre più proficui.
Invece, nell’ambito della capacità di esecuzione, valgono i seguenti punti:
A. Servizi del prodotto. È un indice di valutazione della capacità del fornitore di
fornire funzioni aggiuntive all’interno del prodotto. Le principali sono:
monitoraggio della sicurezza real-time, gestione degli incidenti e reazione ad
essi, ed anche la semplicità di implementazione.
B. Reputazione aziendale. Tiene conto della produttività, della situazione
economica e dei successi finanziari dell’azienda, compresa la probabilità con
cui la stessa garantirà il rilascio di nuovi prodotti e tecnologie SIEM.
C. Esecuzione delle vendite e dei prezzi. Tiene conto delle attività di prevendita,
i successi delle vendite e l’assistenza postvendita. Viene anche valutata
l’efficacia del canale di vendita, ovvero tutti i mezzi attraverso i quali vengono
venduti e consegnati i singoli prodotti SIEM.
D. Reattività del mercato. Valuta un fornitore nell’ambito della soddisfazione
delle esigenze della clientela, compresa l’aggiunta di nuove caratteristiche o
features di un prodotto già in vendita per appagare nuove ed inedite richieste
del cliente.
E. Esperienza del cliente. Tiene conto del contributo di un cliente, attraverso il
quale si migliorano i prodotti di un fornitore SIEM con l’uso di sistemi di
feedback o altre interazioni produttore-consumatore. Questo aspetto non è
per nulla secondario perché con l’ausilio e le esigenze di un cliente l’azienda
potrà garantire prodotti migliori, più semplici da implementare, più stabili e
con più funzionalità.
30
3.1.3 Criteri di raggruppamento: niche players, challengers, visionaries and leaders
-Niche players (“principianti o giocatori di nicchia”): vi appartengono tutti i fornitori
che offrono servizi solo su specifiche tecnologie SIEM, e quindi compatibili con le
esigenze di una ristretta categoria di clienti. Le funzionalità dei loro prodotti sono
abbastanza specifiche. Inoltre gli investimenti di questa categoria di fornitori sono
piuttosto ridotti, oppure con espansione geografica limitata. Comunque il termine
“niche players” non deve per forza avere connotazione negativa perché il più delle
volte vi appartengono società che producono prodotti che si riferiscono a casi d’uso
molto specifici oppure fornitori emergenti nel mercato SIEM.
-Visionaries (“visionari”): qui vengono collocati tutti i fornitori che propongono
prodotti completi, con molte funzionalità e capaci di soddisfare svariate esigenze
della clientela. D’altra parte hanno un basso punteggio nella capacità d’esecuzione a
causa di una minore presenza nel mercato internazionale rispetto alla concorrenza, i
loro investimenti sono ridotti, oppure le sedi dell’azienda non hanno una
distribuzione geografica internazionale ma locale.
-Challengers (“sfidanti”): appartengono in questa categoria tutti i fornitori che
hanno cospicue risorse economiche, hanno una distribuzione geografica capillare e
le cui vendite sono significative e di notevole successo. Dall’altro lato, però, i loro
prodotti non sono abbastanza completi da soddisfare tutte le tipologie di esigenze
della clientela.
-Leaders: vanno in questa categoria tutti i fornitori SIEM che hanno un successo
strepitoso nel mercato ed un elevato numero di vendite, hanno una solida base
aziendale, offrono una tecnologia all’avanguardia o comunque attuale, il loro
supporto e la loro assistenza postvendita è assai evoluta, anche grazie ai feedback
dei clienti. Tali fornitori soddisfano in maniera completa la clientela, andando
incontro anche a bisogni particolari o riferiti ad uno specifico contesto d’uso.
31
3.2 Aggiunta ed esclusione dei fornitori
Il Magic Quadrant viene costantemente aggiornato con un periodo di tempo di 1 o 2
anni. L’esclusione di un fornitore non implica necessariamente il cambiamento
dell’opinione o del giudizio su di esso, ma semplicemente è dovuta all’evoluzione del
mercato SIEM che si concentra e focalizza l’attenzione su nuovi criteri di valutazione.
L’oggetto di questo capitolo della tesi è il Magic Quadrant aggiornato nell’anno
2016, e le principali motivazioni che comportano l’aggiunta o la rimozione di un
produttore SIEM sono le seguenti:
-Aggiunta. Vengono inseriti nel Magic Quadrant tutti i fornitori i cui prodotti:
Garantiscono sia funzionalità SIM che quelle SEM (che appunto formano
insieme il SIEM).
Supportano l’acquisizione di dati da fonti eterogenee, principalmente
dispositivi di rete, di sicurezza o programmi che rispettano il paradigma client-
server.
Vengono inseriti nelle liste di valutazione (cioè ritenuti più utili) elaborate da
organizzazioni end-user.
Vengono consegnati all’utente finale come strumenti software o comunque
basati sulle applicazioni (e non come servizi).
-Eliminazione. Vengono rimossi dal Magic Quadrant tutti i fornitori i cui prodotti:
Offrivano funzionalità SIEM strettamente legate ai dati dei prodotti della
stessa azienda.
Non venivano ritenuti competitivi dalle organizzazioni end-user.
Avevano un fatturato inferiore ai 13.5 milioni di dollari nel corso dell’anno
2015.
Offrivano soluzioni esclusivamente legate a servizi gestiti, dando minore
importanza alle interfacce ed alle applicazioni.
32
3.3 Principali fornitori SIEM
Il Magic Quadrant elaborato nell’anno 2016 è il seguente:
L’obiettivo è quello di analizzare un fornitore o produttore SIEM per quadrante.
Verranno quindi studiate la SolarWinds come “niche player” di riferimento, la
AlienVault come visionaria, la RSA Security come sfidante e infine l’ormai nota IBM
come leader di riferimento.
33
3.3.1 Niche player: SolarWinds
La SolarWinds è una società che fornisce il software Log & Event Manager (LEM). Le
funzionalità comprese in tale programma sono il deposito dei log e la gestione
centralizzata, l’uso della console LEM per visualizzare i dati, compresi anche quelli di
ricerca. Poi vi sono features aggiuntive come la prevenzione della perdita di dati e
reazioni ad incidenti di sicurezza anche automatiche. Nel 2015 viene implementato
anche un meccanismo in grado di prevedere minacce sfruttando i dati e gli
aggiornamenti di una blacklist contenente indirizzi IP a bassa reputazione.
Il sistema di SolarWinds si presenta facile da implementare, ma indirizzato a tutte le
organizzazioni di media o piccola dimensione, perché l’uso di tale programma è
sconsigliato per lo studio di grandi mole di dati in quanto non vengono effettuate
analisi accurate oppure rilevamenti avanzati di minacce.
Punti di forza:
-Semplicità: l’interfaccia di questo software è molto intuitiva ed è possibile
effettuare una grande varietà di operazioni di sicurezza a seconda dei casi d’uso.
-Reattività: il sistema è dotato di una risposta automatica, con un sistema di
prevenzione di minacce ed anche un controllo della quarantena. Inoltre
l’integrazione con altre soluzioni tecnologiche SIEM si è rivelata flessibile.
-Rapporto qualità/prezzo: I clienti SolarWinds sono molto soddisfatti grazie
all’elevato numero di funzionalità che il programma offre nonostante il suo costo sia
abbastanza contenuto.
Difetti:
-Raggio d’azione limitato: le analisi effettuate dall’engine di SolarWinds sono
puramente statistiche e legate al comportamento di base. Quindi questa tecnologia
SIEM si rivela inadatta per la gestione di grandi quantità di dati e utenti.
-Gestione incompleta del flusso: il sistema è dotato di un meccanismo di cattura dei
dati nativo nel flusso, però non è possibile effettuare la correlazione dei dati in real-
time e nemmeno la cattura dei pacchetti in rete.
-Ridotta dotazione di serie: se un cliente ha la necessità di ampliare il prodotto con
altre funzionalità, come il monitoraggio web oppure il supporto ad un elevato
numero di utenti, deve acquistare altri prodotti SolarWinds per estendere tali
caratteristiche.
34
3.3.2 Visionary: AlienVault
L’AlienVault fornisce il sistema USM (Unified Security Management) che è un
prodotto SIEM assai completo, ed include: valutazione delle vulnerabilità,
rilevamento degli asset e delle intrusioni di rete, gestione dei flussi, compresa la
cattura dei pacchetti (che manca nella soluzione SolarWinds). Inoltre è presente un
meccanismo di bilanciamento del carico, di analisi e gestione dei log e di
correlazione degli eventi. Infine vanta di una vasta community di utenti che, con la
discussione e condivisione di informazioni sulle minacce, contribuiscono al rapido
miglioramento dei prodotti AlienVault.
Questo sistema software è sicuramente indirizzato anche a grandi aziende, in
quanto viene offerta una vasta gamma di funzionalità per qualsiasi ambiente di
lavoro e contesto d’uso.
Punti di forza:
-Dotazione di serie completa: acquistando il pacchetto USM, esso già offre tutto
quello che serve nell’ambito della security: monitoraggio, valutazione dell’integrità e
delle vulnerabilità, e rilevamento efficace di intrusioni in rete.
-Qualità del prodotto: il prodotto presenta un’interfaccia completa e ben
progettata. Essa tiene conto della navigazione di eventi, delle attività real-time e
delle informazioni delle minacce, compresi anche gli strumenti per indagare su
eventuali incidenti di sicurezza.
-Vasta community: i clienti contribuiscono al miglioramento dei prodotti Alienware
grazie ai loro consigli e discussioni, inoltre i prezzi del prodotto USM è relativamente
basso date le innumerevoli funzionalità che esso offre.
Difetti:
-Flussi NetFlow: il software USM è in grado di catturare anche flussi NetFlow, ma è
sprovvisto di un sistema di avvisi per informare all’utente della cattura di questo
tipo di flusso.
-Problemi di integrazione con sorgenti di dati non supportati: purtroppo con
formati di dati non previsti o nuovi gli strumenti AlienVault si rivelano abbastanza
ingombranti per tale integrazione. Nel frattempo gli utenti possono sfruttare la
community e richiedere un plug-in da AlienVault per supportare questa integrazione
in maniera più semplice.
35
3.3.3 Challenger: RSA Security
La RSA è una divisione di sicurezza di EMC, e la sua offerta di prodotti SIEM è
denominata come RSA NetWitness. Questi sistemi si focalizzano sul monitoraggio in
tempo reale, analisi, un sofisticato sistema di avvisi, caccia proattiva delle minacce e
risposta immediata ad incidenti di sicurezza. Questa piattaforma sfrutta una
combinazione di uno o più dispositivi fisici o virtuali per la cattura dei pacchetti, per
l’interrogazione e recupero di dati grezzi, l’analisi real-time e la conservazione a
lungo termine di log e report con un archivio. È presente inoltre, fra i prodotti di
RSA, anche quello relativo al servizio cloud-based (tale servizio è denominato RSA
Live Connect), che fornisce aggiornamenti automatici di contenuti di sicurezza
comprese le norme di rivelazione di minacce, di cattura dei pacchetti e di
generazione di log e report. È prevista anche la gestione avanzata degli incidenti di
sicurezza, ed il monitoraggio del traffico di rete grazie alla conservazione di registri
selettivi.
Punti di forza:
-Elevata sicurezza: un’unica piattaforma RSA NetWitness combina svariate funzioni
ed è molto estesa: monitoraggio delle minacce e ricerca costante in tutto il traffico
di rete, compresi anche gli end-point.
-Modularità: il cliente ha il pieno controllo di scegliere o personalizzare il
monitoraggio dell’intero traffico di rete, oppure di rivolgere l’attenzione su
determinati eventi. C’è anche la possibilità di personalizzare l’analisi dei log in base
alle loro esigenze.
-Elevata automazione: il sistema RSA Live offre un approccio prevalentemente
automatizzato nel trasmettere periodicamente aggiornamenti e nuove definizioni
per rilevare ulteriori minacce.
Difetti:
-Complessità: questo sistema offre una tecnologia SIEM di difficile
implementazione, ed è necessaria molta pratica per arrivare ai casi d’uso desiderati.
-Gestione incompleta degli incidenti: il prodotto RSA NetWitness offre solo una
leggera gestione degli incidenti. Se si desidera una dettagliata gestione di tali
imprevisti va aggiunto anche il prodotto SecOps Manager, sempre di RSA.
36
3.3.4 Leader: IBM (International Business Machines Corporation)
Lo strumento software creato da IBM è l’Intelligence Platform QRadar Security,
attraverso il quale le operazioni principali effettuate risultano: la gestione del
rischio, quella delle vulnerabilità, l’analisi e la gestione dei log. Il sistema QRadar è
implementato sia con dispositivi fisici che virtuali, e sono inclusi anche sistemi cloud
proprietari. Ulteriori attività eseguite dal software di IBM sono la collezione di eventi
(è uno dei cinque moduli di un SIEM citati nel capitolo 3), l’elaborazione di eventi di
sicurezza, la gestione dei flussi NetFlow (offerta anche da AlienVault) il monitoraggio
della rete e dei pacchetti. Infine non ci saranno problematiche legate al supporto di
fonti e formati dati, perché QRadar è praticamente in grado di rilevare quasi tutte le
sorgenti dati e di conseguenza, l’integrazione è assai immediata.
Per quanto concerne tutti i miglioramenti di quest’anno, la piattaforma è divenuta
più reattiva e supporta anche casi d’uso specifici, come la sorveglianza sanitaria e la
gestione delle patch di sicurezza. C’è stato anche un aumento delle prestazioni di
ricerca dati.
Punti di forza:
-Completezza di visione: il sistema QRadar fornisce un quadro d’insieme integrato di
tutti i dati di log ed eventi, compresi i flussi dei pacchetti, informazioni su minacce e
vulnerabilità espresse in maniera completa.
-Possibilità di correlazione: l’analisi del traffico di rete e dei pacchetti può essere
correlata con il flusso NetFlow e con gli eventi di log.
-Architettura all-in-one: la tecnologia di QRadar è di implementazione molto
semplice e prevede una struttura “a livelli”. Ciò rende il sistema software
estremamente modulare, supportando il controllo nativo e il monitoraggio anche in
ambienti IaaS (“Infrastructure as a Service”, ovvero infrastruttura distribuita come
servizio).
Difetti:
-Tecnologie thirdparty: alcuni meccanismi di monitoraggio e di rilevamento delle
minacce, oppure per l’analisi dell’integrità dei dati, richiedono l’attività di tecnologie
e componenti aggiuntivi da terze parti.
37
3.4 Confronto tra le soluzioni proposte
Anche se l’obiettivo finale di tutti i sistemi SIEM risulta essere lo stesso, offrire una
protezione quanto più efficace possibile da ogni forma di rischio, in ogni caso ci sono
comunque differenze tra tutte le diverse tecnologie, e quindi esiste un ambito di
applicazione dove ciascuno dei software SIEM riesce a dare il meglio di sé.
Le soluzioni del gruppo “Niche
Players” vengono proposte
principalmente a piccole imprese che
sono appena entrate nel mercato dei
SIEM, ad aziende con distribuzione
geografica limitata, oppure con risorse
economiche e finanziarie modeste.
Nel frattempo queste aziende cercano
di avere sempre un ruolo di rilievo e
quindi i loro prodotti sono caratterizzati da un ottimo rapporto qualità/prezzo. Vale
a dire che le funzionalità offerte da tali sistemi software sono abbastanza numerose
con un prezzo relativamente contenuto.
Le soluzioni del gruppo “Visionaries” sono realizzate per imprese solitamente di
media grandezza, ma che soprattutto puntano agli obiettivi della clientela. La
preoccupazione di tali società è proprio la piena soddisfazione di colui che utilizza i
suoi prodotti SIEM. Ciò è reso possibile grazie allo sfruttamento di un’ampia
community per supportare e migliorare in continuazione il sistema di sicurezza
offerto da tali software.
I prodotti SIEM del gruppo “Challengers” sono quelli che, offrendo un avanzato
numero delle funzionalità, vogliono prepotentemente ritagliare un ruolo
importante, magari come possibili candidati per la categoria “Leader”. Tutto questo
avviene attraverso l’offerta di soluzioni decisamente complete, con un rilevamento
delle minacce aggressivo, un sistema di log management rigoroso e offerta di
sistemi cloud-based. Tuttavia, dall’altra faccia della medaglia, purtroppo va
migliorata l’assistenza per il cliente, cercando di mirare nella realizzazione di
prodotti più adatti proprio per il suo desiderato caso d’uso.
Infine, la categoria “Leader”: qui vi addensano aziende di grande importanza,
distribuzione geografica internazionale e capillare, reddito economico invidiabile,
mentre per quanto riguarda i loro strumenti offerti, essi risultano la combinazione
dei pregi della categoria Visionaries per le esigenze della clientela e del gruppo
Challengers per le funzionalità offerte dai loro software.
38
Capitolo 4: Il software di LogRhythm
ed il formato dati CIM
4.1 L’azienda e i suoi obiettivi
La LogRhythm già risiede nel settore “Leader” del
Magic Quadrant, proprio come la IBM che è stata già
trattata in questa tesi nel capitolo 3.
Quest’azienda offre soluzioni SIEM come le precedenti, però offre il software
proprietario Intelligence Platform Security che è in grado di intercettare anche gli
attacchi più recenti, e di studiare persino il ciclo di vita di una minaccia qualsiasi.
La sua proposta SIEM è data dalla seguente:
- Software SIEM di ultima generazione, compreso il log management
- Monitoraggio locale, per lo studio dell’integrità di files e registro di sistema
- Monitoraggio di rete, per la cattura completa dei pacchetti e dell’ID delle applicazioni web
- Ricerca contestuale rapida
- Sistema di reazione automatica agli incidenti di sicurezza
- Uso del framework SmartResponse per i cyber attacchi più sofisticati
È proprio questo framework appena citato che contraddistingue meglio la soluzione
offerta da LogRhythm rispetto alle altre. Si tratta di un meccanismo di protezione
decisamente originale che rende il suo funzionamento impeccabile e contribuendo
anch’esso nell’ascesa dell’azienda fino al ruolo di leader nel mercato SIEM.
Nel dettaglio, si vuole analizzare questa SmartResponse. Questo framework può
essere considerato appropriatamente come un “ibrido”, perché offre allo stesso
momento: la protezione real-time nell’ambiente informatico, la capacità di
individuare minacce ancora sconosciute, ed un sistema di studio dell’intero ciclo di
vita delle minacce condotto da un team specifico, o volendo, anche in maniera semi-
automatica, esonerando l’utente in alcune situazioni, come la risposta al comparire
di minacce sul proprio sistema.
Un altro problema che è sempre stato a cuore dell’azienda è la velocità di scansione
e anche quella relativa della risposta automatica alle eventuali minacce. Per fornire
gli strumenti quanto più veloci e sicuri possibili, vi sono in dotazione la gestione end-
to-end dei flussi, e un insieme di funzionalità contenute nel cosiddetto out-of-the-
box (che significa appunto funzionalità standard, pronte all’uso) attraverso le quali
Il logo di LogRhythm.
39
gli analisti SIEM aiutano, tramite la comunicazione end-to-end, a risolvere
efficacemente anche i più urgenti problemi di sicurezza dei clienti.
Inoltre è supportata anche la virtualizzazione, consentendo quindi di usare il
software SIEM anche in sistemi operativi virtuali, con l’uso dell’ormai noto
VirtualBox e di altre tecnologie sottostanti:
Parte relativa alla virtualizzazione contenuta nei datasheet di LogRhythm, citati nella bibliografia.
4.2 Il formato MDI Fabric
4.2.1 Terminologia e vantaggi
Questo paragrafo è incentrato sul formato dati “standard” utilizzato da LogRhythm
che ora si vuole analizzare. Innanzitutto, bisogna sapere che il termine MDI è una
sigla e sta per Machine Data Intelligence.
Avevamo già citato che la velocità di scansione e di rilevamento sono i principali
problemi che la LogRhythm ha voluto affrontare e che continua a farlo. Grandi
organizzazioni aziendali, infatti, impiegano giorni o addirittura mesi per individuare
una determinata minaccia, con la conseguente reazione, quando in realtà ne
servirebbero anche pochi minuti.
Queste perdite di tempo possono essere finalmente soppresse con un’architettura
che utilizza il formato MDI e che prevede una suddivisione della gestione dati in tre
livelli diversi. Tale architettura favorisce sicuramente la velocità di reazione e la
scalabilità, e di conseguenza comporta la diminuzione dei costi grazie ad un
sofisticato sistema di indicizzazione.
4.2.2 Architettura a strati del MDI Fabric
L’architettura sopracitata è definita come “Machine Data Processing and Indexing
Tiers”. Il MDI, invece, può essere definito come un set di metadati informativi,
compresi la criticità dell’evento, l’host “vittima” e l’host d’origine che ha trasmesso
l’infezione. Dopo la raccolta e la collezione di tali metadati (questo è uno dei cinque
moduli dell’architettura SIEM presente nel capitolo 2), si ha la normalizzazione e
successivamente l’invio degli stessi ad un motore IA (d’intelligenza artificiale) per
l’analisi e l’indicizzazione.
40
Infine, viene per precauzione (è comunque una buona norma nell’ambito della
security) conservata una copia grezza del messaggio negli archivi, per poterla
estrarre in caso di future necessità.
Nell’architettura indicata dall’immagine è stata già trattata la collezione di tali
metadati, normalizzazione e storage del dato grezzo negli archivi. Tutto questo
rappresenta il primo livello dell’architettura, cioè il data collection.
Scendendo nel secondo livello, il data processing prevede una compressione di tali
dati in log testuali o in linguaggio macchina. Inoltre il software di LogRhythm
arricchisce tali metadati di altre informazioni contestuali, in particolare:
classificazione degli eventi, livelli di priorità, e anche la geolocalizzazione del dato.
Per quanto riguarda invece il timestamp, esso viene opportunatamente gestito
grazie allo strumento LogRhythm TrueTime che consente di eliminare gli
scostamenti di tempo causati dai fusi orari, oppure da orologi di sistema mal
impostati.
Inoltre, ogni file archiviato viene firmato digitalmente in modo da risalire alla sua
vera identità, rilevando così anche i tentativi di manomissione di tale dato. Poi è
presente un ordinamento nell’archivio per data e per descrizione in modo da
consentire una ricerca agevole.
41
Infine, in basso abbiamo il terzo livello, il data indexing, che riceve tutti i messaggi
elaborati dal data processing (il 2° livello) e successivamente li colloca in un
complesso motore di ricerca altamente scalabile, in particolare si tratta di una forma
di ricerca non strutturata, che l’azienda lo nomina Elasticsearch.
Una tipologia di ricerca come questa consente di analizzare anche dati macchina
non elaborati, aiutando in maniera significativa l’analysis team grazie ad una
conversione tra ricerca contestuale e linguaggio nativo.
Questo engine di ricerca funziona anche con le query di un database. Essendo
un’architettura scalabile, ad alte prestazioni e con un sistema di indicizzazione, è
supportata inoltre la ricerca dei cluster di dati, perché è in dotazione un
meccanismo di replicazione degli stessi su più nodi, in modo tale che, se si perde
accidentalmente un nodo, l’impatto è minimo sul sistema e nullo sulle prestazioni,
grazie alla presenza di copie di sicurezza negli altri nodi.
4.3 Il Common Information Model
4.3.1 Struttura e definizione
Il Common Information Model è uno standard che definisce come gli elementi
gestiti nell’ambito della Information Tecnology vengono rappresentati come un
insieme di oggetti relazionati fra di loro. Questo modello è stato reso ufficiale grazie
alla DMTF (Distributed Management Task Force) che ha pubblicato un insieme di
regole per la gestione di tali oggetti a prescindere dal loro produttore o fornitore.
Il Common Information Model relativo alle aziende ed alle imprese.
42
Uno dei possibili modi per descrivere un modello CIM è quello di dire che esso si
presenta come un insieme di più componenti che si integrano tra di loro e quindi
consentendo lo scambio di informazioni.
Inoltre, un modello CIM consente anche di controllare attivamente gli elementi
scambiati. Esso fornisce anche supporto alle diverse implementazioni di un modello
comune, evitando quindi operazioni onerose ed anche costose di conversione dei
dati, a volte con probabile perdita di informazioni.
È possibile costruire un modello CIM sfruttando tre diverse tecnologie:
- CIM Core Model: questa tecnica risulta assai teorica, infatti si tratta di uno
schema concettuale di oggetti con semplici relazioni. Attualmente è preferita
grazie alla sua semplicità ed immediatezza. Il Core Model viene utilizzato pure
nei settori più recenti dell’IT, come quello dei middleware, del cloud storage e
dei servizi di rete. Infine ha facile estensibilità, in modo da essere prontamente
modificato secondo le idee del produttore.
- CIM Common Model: questa tecnica permette di delineare gli oggetti e le loro
relazioni in maniera strutturale, e quindi usa uno dei più diffusi linguaggi
dell’ingegneria del software, l’UML. Si tratta di un approccio ovviamente
orientato agli oggetti, e questi ultimi vengono identificati come classi e le
relazioni che li caratterizzano come associazioni, aggregazioni, composizioni,
dipendenze, responsabilità, e così via.
- CIM Extension Schemas: si tratta di un insieme di estensioni opzionali del
Common Model al fine di arrivare a specifici casi d’uso.
In generale, il Core Model rappresenta un punto di partenza per delineare le prime
funzionalità di un sistema software, mentre il Common Model è utilizzato per
dettagliare la struttura di un sistema nell’ambito della IT mediante la progettazione
o il software design. Se poi si ritiene necessaria una funzionalità aggiuntiva non
contenuta nel Common Model, vanno consultate le Extension Schemas per
verificare la sua presenza, ed in caso affermativo, questa viene integrata.
4.3.2 Rappresentazione grafica di un CIM
Per il Common Information Model non viene utilizzata un’implementazione grafica
di riferimento universale, ma ci sono quattro modi diversi per descrivere
interattivamente la gestione degli oggetti nella Information Technology.
Lo schema che verrà utilizzato è riportato nella pagina successiva.
43
Schema illustrativo basato sui meccanismi e sul funzionamento di un CIM.
Si vogliono delineare queste quattro diverse modalità di gestione.
1. Repository (deposito): è un ambiente di un sistema informatico in cui
vengono gestiti i metadati, attraverso tabelle relazionali, regole e motori di
calcolo.
2. Applicazione DBMS: preleva tutte le definizioni contenute in un diagramma
concettuale e li trasforma in un vero database implementato in una
tecnologia prescelta. I più diffusi sono i RDBMS, cioè i database relazionali.
3. Applicazione degli oggetti: consente di definire i dati di riferimento come
oggetti o classi, mentre un uso di tale oggetto prende il nome di istanza.
4. Scambio dei parametri: qua si ha il passaggio delle istanze delle classi tra le
specifiche applicazioni come se fossero parametri, usufruendo così del
contenuto informativo del Common Information Model.
44
Riferimenti bibliografici
William Stallings – Operating Systems, Internals and Design Principles – 7th edition
Editore: Prentice Hall
RaiNews – La nuova Guerra fredda
URL website: http://www.rainews.it/dl/rainews/articoli/rRussia -senza-precedenti-minacce-
Usa-su-attacchi-informatici-1a1658c3-f543-4876-b579-75afeb4417d3.html
NIST – Guide to Computer Security and Log Management
URL website: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800 -92.pdf
Renaud Bidou – Security Operation Center Concepts & Implementation
URL website: http://www.iv2-technologies.com/SOCConceptAndImplementation. pdf
Kelly M. Kavanagh, Oliver Rochford, Toby Bussa – 2016 Magic Quadrant for SIEM
URL website: https://www.securelink.be/wp-content/uploads/sites/2/2016-Magic-Quadrant-
for-SIEM.pdf
LogRhythm’s security intelligence platform
URL website: https://logrhythm.com/pdfs/datasheets/lr -a4-security-intelligence-platform-
datasheet.pdf
LogRhythm – Data Processing and Indexing Tiers
URL website: https://logrhythm.com/pdfs/datasheets/lr -processing-and-indexing-
datasheet.pdf
DMTF – Common Information Model Infrastructure
URL website:
http://www.dmtf.org/sites/default/files/standards/documents/DSP0004_2.7.0.pdf
