I dati e le loro anomalie nascoste

La motivazione per questo articolo nasce dalla crescente problematica di gestione sulle anomalie dei dati, che fino ad oggi venivano gestite ed imputate a livello software, ma non sono mai state gestite come elementi critici alla sicurezza dello stesso e ad i suoi legami con le procedure aziendali.

La semplice lettura della definizione di 0-DAY presa da wikipedia, specifica il perché di questa teoria. Wikipedia.it definisce infatti 0-DAY nel seguente modo:

Lo 0-day è un tipo di attacco informatico che inizia nel "giorno zero", cioè nel momento in cui è scoperta una falla di sicurezza in un sistema. Questo tipo di attacco può mietere molte vittime, proprio perché è lanciato quando ancora non è stata distribuita alcuna patch e quindi i sistemi non sono ancora protetti.

Molti 0-day sono scoperti da cracker, e non vengono rivelati pubblicamente; perciò il cracker può facilmente "bucare" il sistema, perché nessuno oltre a lui è a conoscenza del bug. Ci sono cracker indipendenti o riuniti in organizzazioni più o meno piccole (blog privati, mailing list...) che si scambiano informazioni e 0-day; questi gruppi sono molto pericolosi.

Gli 0-day sono tra i peggiori pericoli del web, in quanto sono noti solo a una ristretta cerchia di cracker, e possono causare moltissimi danni prima di essere scoperti.

Negli ultimi vent’anni si è assistito da un lato ad una massiccia diffusione delle reti informatiche, dall’altro ad una crescita vertiginosa delle utenze di tali reti: La rete ha quindi inevitabilmente generato una nuova tipologia di “crimini informatici”; nella maggior parte dei casi si tratta di tentativi, da parte di malintenzionati, di accesso non autorizzato a sistemi informatici, magari contenenti dati sensibili.

L’accesso criminoso da parte di un qualcuno ad un sistema può essere fonte di danni di qualsiasi tipo, non ci dilungheremo oltre su tale tematica perché l’approccio che seguiamo non mira a conoscere la pericolosità di tali atti ma a prevenirli gestendoli in totale sicurezza. Per meglio esplicitare la filosofia di tale studio di seguito viene riportato un assunto letterario prima e come lo si vuole gestire nel futuro.

Ad oggi:

l’anomaly detection attraverso l’intrusion detection, si occupa di sviluppare metodi tramite i quali un sistema possa rilevare la presenza di utenze non autorizzate al suo interno e notificare la sopraggiunta situazione di pericolo ad un amministratore, prima che il corretto funzionamento dello stesso sia del tutto compromesso.

Nel futuro:

l’anomaly detection, si occuperà di sviluppare metodi tramite i quali un sistema può rilevare, in tempo utile la presenza di utenze autorizzate e non al suo interno notificando la sopraggiunta situazione di pericolo ad un amministratore, prima che il corretto funzionamento dello stesso sia del tutto compromesso.

Ad oggi la sicurezza informatica, soprattutto se rivolta alla verifica e gestione dei software che gestiscono le basi dati e comunque l’operatività diretta degli utenti, non richiede più solo abilità tecniche ma anche ed in particolar modo approcci e metodi efficaci e innovativi, soprattutto per quanto riguarda anomaly detection e correlazione di allarmi.

L’anomaly detection, nel suo termine filosofico, è l’unica tecnica di Intrusion Detection (ID) in grado di rilevare uno 0-day attack (come precedentemente individuati); gli IDS classici (di tipo misuse) non sono più sufficienti, essendo in grado di rilevare attacchi soltanto se conosciuti, va da se che essendo conosciuti vengono intercettati in un momento successivo all’eventuale danno apportato e quindi come nel vecchio proverbio è come “chiudere la stalla quando i buoi sono scappati”.

Secondo un rapporto pubblicato all’inzio di novembre 2006 da SANS Institute, le vulnerabilità 0-day sono sempre più sfruttate. Per definizione, un exploit di tipo 0-day ha sempre successo: è utilizzato per sferrare un attacco prima che la vulnerabilità sfruttata venga scoperta e corretta. Solo nel 2006, Microsoft ed Apple contano oltre 20 vulnerabilità 0-day riportate.

Anche a fronte di quanto appena citato e alla luce delle nuove necessità della ricerca nel campo, della correlazione di allarmi, sarebbe opportuno sviluppare un lavoro di metodo e di pratica che sia in grado di valutare l’efficacia e l’applicabilità degli approcci finora noti anche all’anomaly detection.

Si deve sempre tener presente che nell’informatica non esiste sicurezza nell’accezione totale del termine, infatti ad oggi tutti i software presenti sul mercato affrontano la problematica al più subito dopo che il sistema è stato bucato quanto meno nella sua regola di integrità. Sono ormai molti anni che si studiano metodologie e tecniche per riuscire a gestire in maniera proattiva i comportamenti inattesi di sistemi informatici, complessi o meno.

Le applicazioni ad oggi sul mercato sono rivolte verso i “sistemi critici”, quei sistemi in cui un errore durante il funzionamento potrebbe portare a conseguenze gravi, in alcuni casi da un punto di vista economico.

Sono stati definiti una serie di parametri (nelle varie aziende attente a tale problematica si parla di policy della sicurezza), per poter misurare “quanto bene” funzioni un determinato sistema, ma nessuno di questi riesce a prevenire le criticità.

Nella letteratura corrente l’insieme delle policy di sicurezza sono identificate nella dependability.

Le tecniche per la correlazione di allarmi devono essere approfondite: sembrano infatti essere l’unico approccio valido per lo sviluppo di IDS ibridi, in cui i contro delle tecniche classiche vengono compensati dai pro degli algoritmi di anomaly detection, e viceversa.

Come già precedentemente detto, i moderni sistemi informatici sono molto sofisticati e complessi; altrettanto complesso è l’ambiente distribuito in cui questi sistemi sono immersi su scala, oggi, globale. Questa situazione è caratterizzata da un rischio particolarmente elevato per le istituzioni il cui business è basato sull’erogazione di servizi internet.

Oggi il problema ha raggiunto proporzioni tali da non riguardare più solo i sistemi informatizzati ma la totalità degli “ingranaggi aziendali” in cui il concetto di computer security è solo un aspetto che purtroppo non copre tutte le possibilità di attacco ma soprattutto non riesce a gestire la possibilità di errore umano che nella stragrande maggioranza dei casi si tramuta per i sistemi da errore umano a attacco inconscio.

Volendo esprimere il concetto di sicurezza in maniera un pò più articolata, potremmo dire che si tratta di una branca dell’informatica che si occupa della salvaguardia dei sistemi di calcolo da potenziali rischi e violazioni dei dati, studiando proprietà, che devono valere al fine di poter parlare di sistemi sicuri, e meccanismi, atti a minimizzare le minacce che potrebbero invalidare tali proprietà.

Dalla definizione che ne viene data emerge chiaramente come dependability e security siano non solo concetti fra loro estremamente legati, ma anche che il secondo sia in qualche modo assimilabile al primo: è sufficiente suddividere i guasti in accidental faults e malicious fault. In questo modo, fare error detection assume un significato più generale, senza la necessità di considerare se il guasto che ha generato l’errore sia, ad esempio, di tipo hardware, software o peggio ancora il risultato finale di un attacco andato a buon fine. Il software in esecuzione potrebbe contenere un errore di programmazione e quindi eseguire alcuni dei suoi compiti in modo erroneo, oppure un componente hardware potrebbe rompersi e non comportarsi più secondo le sue specifiche; in ogni caso il risultato potrebbe essere un comportamento inatteso o, peggio ancora, il fallimento dell’intero sistema.

Il massimo comune denominatore che raggruppa gli studi fatti in questi anni è la messa a punto di sistemi, così detti, fault-tolerant, ossia sistemi in grado di continuare a lavorare in maniera corretta anche in caso di guasti, oppure, qualora i guasti fossero troppo gravi, capaci di interrompere del tutto il proprio servizio, in attesa di una riparazione, lasciando però il sistema in uno stato safe.

Quanto appena detto vale per la gestione dei rischi su guasti di tipo hardware, ma lo stesso enunciato non ha validità se il guasto da intercettare è di tipo software. Un esempio sarà maggiormente esplicativo: Si pensi ad una banca nella quale l’utente abilitato alla correzione degli estratti conti non si rende conto di aver aggiornato inavvertitamente un dato di un cliente o che addirittura abbia lasciato il pc aperto all’uso di estranei. Queste due azioni nei giorni a seguire e comunque quando verranno rilevate saranno gestite alla stregua di un crimine informatico senza che nessuno possa accorgersi che l’anomalia sul dato è stata generata erroneamente e senza malizia alcuna. Tale errore genera una anomalia del dato che prima di essere intercettata genera danni al sistema che aumentano con l’aumentare dei giorni in cui tale anomalia resta oscura alla banca.

Questo passaggio è fondamentale per l’approccio che si vuole dare a questo studio, perché è fondamentale comprendere che si vuole approcciare alla sicurezza del dato nella sua interezza e non solo attraverso le policy conosciute.