Ids, il Nist detta le linee guida

Un recente documento dell’istituto collegato agli ambienti istituzionali statunitensi ha stabilito l’utilizzo dell’intrusion detection negli ambienti dell’amministrazione pubblica. Primo “effetto Bush”?

Il Nist, National Institute of Standard and Technology, ha rilasciato una serie di linee guida, anche a titolo di mera introduzione all’argomento, in ordine agli Ids (Intrusion detection system). Il documento ha lo scopo di assistere le agenzie federali americane ed altri ambienti di tipo enterprise nell’adozione e nell’implenentazione degli Ids. L’obiettivo si può dire nettamente raggiunto.


Il principio operativo degli Ids è simile a quello di un antivirus, laddove si ricorre alla comparazione delle firme degli attacchi o dei pattern degli stessi. Questa tecnica è generalmente definita con il termine pattern matching and signature analisys, e consiste, per l’appunto, nel ricercare all’interno del traffico analizzato, corrispondenze con log entry ben definite.


Partendo da questo presupposto, potrà essere di sicuro ausilio il fatto che gli Ids sono in grado, per esempio, di rilevare su un segmento di rete ove sono stati piazzati, dei pattern univocamente definiti come sintomatici di attacco, oppure, su un host, oltre ad eventuali risposte anomale dei sistemi informativi, delle modifiche arbitrarie dei file di sistema, del loro checksum o della loro configurazione, fattori sicuramente importanti nel riconoscimento di un’attività di violazione in atto.


Spesso, però, alcuni Nids (Network intrusion detection system) non garantiscono definitivamente il completo e totale monitoraggio di throughput vicini al Gigabit. A dire il vero alcuni vendor, che hanno un approccio “distribuito”, dichiarano di esservi ormai molto vicini, mentre altre aziende hanno definitivamente abbandonato i progetti in questo settore.


Altro problema riguarda la gestione del traffico crittografato. Molto spesso, infatti, dei Nids hanno grosse difficoltà nell’esaminare i pacchetti in transito sottoposti a crittografia, mentre, allo stesso modo, la complessità aumenta nella gestione (e individuazione) degli Ip fragmentation attack, cioè degli attacchi basati sulla frammentazione anomala dei pacchetti Ip e dei covert channel, istruzioni malicious fatte passare, perché evidentemente encapsulate, all’interno di transazioni consentite dal firewall.


Le indicazioni “dall’alto”


Presunti limiti a parte, le linee guida impartite dal nuovo Governo americano hanno definito, anche chiaramente alcune configurazioni tipo degli Ids, suddivise anche per impiego e tipologia di strumento.


Le linee guida recano una grande attenzione all’approccio (differenze tra Nids, Ids Host based, application e hybrid model) e, soprattutto, al piazzamento dei sensori. Questo rappresenta un argomento da scindere in due sottoinsiemi. Il primo riguarda la collocazione al di qua o al di la dei firewall, con uno sguardo alla Dmz. I documenti, pur cercando di mantenere una certa imparzialità, sembrano essere propensi a privilegiare la collocazione dietro il firewall stesso, in quanto si può operare con maggiore vicinanza alla risorsa da proteggere. Un altro delicato argomento, oltre a quello del piazzamento dei sensori, riguarda il posizionamento delle unità di controllo ed analisi degli eventi. Le correnti di letteratura si dividono il campo con due approcci differenti. Il primo concerne il piazzamento dell’unità sulla stessa macchina da proteggere . Detto anche host co-location, questo approccio risulta essere poco consigliato, in quanto, in caso di compromissione della macchina ove risiedono detta unità e target, questi vengono messi automaticamente messi fuori uso o, peggio ancora consentire una falsificazione dei dati mandati alla console centrale.


Il secondo approccio coinvolge il posizionamento del sensore su macchine separate. In questa maniera si può ovviare ai pericoli di cui sopra e lavorare ulteriormente ad una fortificazione dell’Ids.


Sia il posizionamento dei sensori, sia la parte relativa al modello architetturale adottato, devono, secondo il documento in questione, essere analizzati profondamente, in quanto sono elementi fondamentali per la scelta del tipo di Ids da utilizzare. A tal proposito, in ordine alla scelta del “giusto candidato” per la propria rete, sarebbe opportuno effettuare lo stesso ragionamento di base che si effettua per gli antivirus: il miglior prodotto non esiste. Quello che si può fare è un’analisi dei prodotti in base alle loro features e all’impatto di queste ultime sul ciclo biologico dell’It aziendale.


Altra indicazione riguarda i cosiddetti controlli di qualità, da effettuare sugli Ids in produzione. Questi consistono, tra l’altro, nelle operazioni di verifica dei log e le correlazioni tra questi ultimi, ai fini della reale identificazione degli eventuali attacchi. Questo perché il fenomeno dei falsi allarmi, sia pur in diminuzione, è sempre presente. L’operazione di cui sopra costituisce una vera e propria fase di tuning, necessaria sia nella fase amministrativa sia in quella di forensics.


Proprio in ordine a quest’ultimo aspetto, il Nist ha inserito nel documento una parte relativa alla gestione delle informazioni di logging. In questo caso si parte dal presupposto che, anche nel caso in cui non dovesse essere in grado di effettuare la detection ed il blocco in tempo reale di un attacco, l’Ids è in grado di fornire informazioni di carattere identificativo, sia in ordine all’evento, sia, alla possibile identificazione delle macchine di provenienza.

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome