ITUD20120016A1 - "apparato industriale, sistema e metodo gestione e analisi di file di log" - Google Patents

Description

DESCRIZIONE del brevetto per invenzione

Avente per titolo:

APPARATO INDUSTRIALE, SISTEMA E METODO GESTIONE E ANALISI DI FILE DI LOG

DESCRIZIONE

Campo tecnico

La presente invenzione riguarda un apparato industriale di gestione e analisi di file di Log secondo le caratteristiche della parte precaratterizzante della rivendicazione 1 .

La presente invenzione riguarda anche un sistema di gestione e analisi di file di Log secondo le caratteristiche della parte precaratterizzante della rivendicazione 9.

La presente invenzione riguarda anche un metodo di gestione e analisi di file di Log secondo le caratteristiche della parte precaratterizzante della rivendicazione 13.

Definizioni

Nella presente descrizione e nelle annesse rivendicazioni si farà riferimento alle seguenti definizioni:

- File di Log o Log indica genericamente un file in cui vengono registrate le attività compiute per esempio da un'applicazione, da un server, o da un interprete di comandi, attività di invio e ricezione della corrispondenza via email.

- Sistema SIM [Security Information Management] indica un sistema in grado di raccogliere, monitorare e analizzare dati inerenti alla sicurezza contenuti nei file di Log.

- Sistema SEM [Security Event Management] indica un sistema in grado di raccogliere, monitorare e analizzare eventi inerenti alla sicurezza contenuti nei file di Log.

- Sistema IMS [Identity Management System] indica un sistema di autenticazione che permette ad un utente di autenticarsi per poter accedere poi a tutte le risorse informatiche della infrastruttura IT alle quali è abilitato.

- Infrastruttura IT indica l'insieme di risolse tecnologiche, hardware e software, condivise la quale fornisce una piattaforma per le specifiche applicazioni del sistema informativo di una impresa.

- Host o ospite indica un computer di una rete che ospita risorse e servizi disponibili ad altri sistemi.

- Intrusione indica qualunque attività non autorizzata su una rete o un sistema o una infrastruttura IT.

- IDS indica un Intrusion Detection System o sistema di rilevamento delle intrusioni. Tecnica anteriore

Uno degli aspetti chiave nella protezione di una struttura IT consiste nella individuazione e, possibilmente, nella prevenzione di attacchi alla struttura informatica dovuti essenzialmente a hacker, cracker e script kiddie. Al fine di aumentare la sicurezza informatica, dunque, si deve innanzitutto tener traccia delle tentate intrusioni, delle intrusioni andate a buon fine e delle modifiche fraudolentemente apportare al sistema violato e, in seconda battuta, occorre cercare di adottare degli strumenti in grado di accorgersi di un tentativo di intrusione ed intervenire prima che il tentativo di intrusione vada a buon fine o comporti gravi conseguenze alla struttura IT o ai dati che sono accessibili tramite la stessa.

Il tracciamento dell’attività che avviene all’interno della struttura IT ha luogo per mezzo di una analisi approfondita dei file di log di sistema, che sono dei file che contengono informazioni sullo stato della/e macchina/e connessa/e alla struttura IT. I file di log, tuttavia, contengono molti messaggi di scarsa importanza mescolati a messaggi che riguardano eventi importanti, che, al contrario dei primi, occorre preservare. Un primo aspetto che la tecnica anteriore si prefigge di risolvere è, quindi, quello di mantenere almeno una copia sempre valida dei file di log anche nel caso in cui essi subiscano delle modifiche sulle macchine locali connesse alla struttura IT a causa dell’attacco informatico. L’utilizzo di un log server, ovvero una macchina che ha il solo e preciso compito di raccogliere i log di altre macchine, consente di avere una copia valida dei log delle macchine che lo utilizzano, cioè una copia non modificata o modificabile dei file di log stessi. In tal modo, anche se i log sulla macchina locale vengono modificati in conseguenza di una intrusione, il sistema mantiene una copia valida dei file di log sulla macchina remota a patto che essa sia inaccessibile durante l’attacco.

Un sistema sicuro comprendente un Log server può quindi migliorare e semplificare notevolmente la gestione centralizzata dei log di diverse macchine e anche l'analisi di eventuali intrusioni o tentativi di intrusione. Sono noti diversi processi di gestione dei file di Log. La gestione dei file di Log riveste una importanza fondamentale sotto diversi aspetti. Ad esempio disposizioni normative a livello nazionale e comunitario prevedono che i file di Log siano gestiti secondo modalità tali da poter ricostruire a posteriori gli avvenimenti accaduti, identificandone in molti casi la fonte di provenienza; essi forniscono inoltre una prova di ciò che è accaduto nel sistema a tutti gli effetti, diventando all'occorrenza uno strumento con valenza probatoria, in caso di contesa legale.

Occorre tenere in considerazione che tale gestione coinvolge un grande quantitativo di file di Log i quali vengono quotidianamente cercati dai moderni sistemi informativi. Questo comporla notevoli costi, sia in termini di strumenti software, sia soprattutto di risorse umane dedicate alla gestione di questi dati. I sistemi della tecnica anteriore, in generale, prevedono una centralizzazione, archiviazione e analisi dei file di Log, in maniera integrata ed automatizzata, riducendo parzialmente i costi di gestione e garantendo integrità, confidenzialità e inalterabilità dei dati raccolti.

L'impiego di algoritmi di cifratura sia nelle fasi di transito che di memorizzazione dei dati consente di mantenere una copia fedele ed inalterata dei Log di ogni host o dispositivo monitorato in un unico archivio centralizzato. Oltre a semplificare notevolmente la gestione e la consultazione di tali dati ed ottimizzare l'impiego delle risorse di memorizzazione (Storage) aziendali, una simile soluzione consente di disporre sempre di una copia inalterata di ogni Log contemplato dal sistema, anche nei casi in cui la sicurezza di un host remoto sia stata compromessa ed i Log locali dello stesso siano stati alterati.

Anche in ambiti puramente operazionali tali Log possono risultare importanti, ad esempio per prevenire o ricostruire le cause di una interruzione di servizio. Scoprire in anticipo che i dispositivi di memorizzazione di un certo host stanno degradando le proprie prestazioni, ad esempio a causa di una temperatura ambientale eccessiva o di un problema al sistema di memorizzazione in uso, consente in molti casi di evitare improvvise e catastrofiche interruzioni di servizio ed intraprendere invece interventi di ripristino opportunamente pianificati.

Alcuni sistemi della tecnica anteriore non si limitano a raccogliere parzialmente e senza alcuna garanzia d'integrità i soli Log necessari a generare allarmi o report in presenza di determinati scenari, ma garantiscono anche che i Log vengano interamente trasmessi nella loro forma originale e ne salvaguardano la loro integrità e sicurezza, per il loro intero ciclo di vita.

Per garantire la validità probatoria dei Log per come vengono gestiti dai sistemi si prevedono anche moduli di firma elettronica integrati nei sistemi di gestione dei Log stessi, in grado di fornire aN'amministratore di sistema uno strumento di certificazione, in grado di attestare l'integrità dei contenuti anche quando essi sono stati esportati dal sistema stesso.

Alcuni processi di gestione dei file di Log prevedono anche l'effettuazione di controlli sui pacchetti ricevuti già a livello IP con la possibilità di definire regole di filtraggio dei pacchetti in modo da minimizzare i rischi derivanti da flooding (tecnica di raccolta di informazioni sullo stato di una rete mediante invio di pacchetti a tutti i nodi collegati), tentativi di connessioni fasulle e attacchi di tipo DoS (Denial of Service).

Sono noti anche processi di analisi statistiche e correlazioni dei dati dei file di Log. Grazie ad essi è possibile eseguire operazioni di ricerca, filtraggio su dati aggregati e generazione dinamica di report.

In generale i meccanismi tramite i quali si cerca di sfruttare l'analisi dei file di Log per rilevare e/o difendersi dalle azioni di malintenzionati sono indicati con Intrusion Detection System o sistema di rilevamento delle intrusioni o IDS che sono strumenti, software o hardware, come ad esempio un altro computer separato da quelli da proteggere. Gli IDS automatizzano il processo di monitoraggio per individuare eventi che rappresentano accessi non autorizzati ai computer oppure alle reti locali, analizzandoli alla ricerca di indicatori riconducibili a problemi di sicurezza.

Ad esempio le attività che un IDS si prefigge di identificare tramite l’analisi dei file di log possono essere lo sfruttamento di una vulnerabilità nota di un servizio, gli attacchi attraverso l'invio di dati malformati, i tentativi di accesso agli host tramite l'innalzamento illecito dei privilegi di accesso degli utenti, il tentativo di un utente remoto non autorizzato di compromettere un servizio di sistema per creare un account, gli accessi non autorizzati ai file, l'installazione di codice maligno come i classici virus, cavalli di troia e worm di rete trasmessi con la posta elettronica o in altro modo. Un buon IDS deve essere in grado di segnalarci, in tempo reale, tentativi di intrusioni generate da hacker, cracker, virus, tool automatici oppure da utenti che a volte inconsciamente utilizzano programmi potenzialmente pericolosi.

A seguito della individuazione di eventi, attività o traffico di dati potenzialmente ostili il sistema IDS generalmente segnala la presenza degli stessi.

Non esiste una definizione legale di intrusione che sia univoca e di facile applicazione. I criteri variano da nazione a nazione e non sono uniformi neppure in ambito nazionale. Non sempre è chiaro se una intrusione è illegale: per esempio si pensi alla scansione delle porte, che è un’attività alquanto comune su Internet e che, in sé, non rappresenta un atto ostile, ma può preludere ad un tentativo di accesso non autorizzato.

Possiamo affermare che, su un piano concreto, il rilevamento delle intrusioni è un processo atto a monitorare eventi che avvengono in un sistema o in una rete, di un individuo o di un’organizzazione, di analizzarli alla ricerca di segnali o attività che una volta riconosciuti segnalino aH’amministratore del sistema, l’individuazione di traffico potenzialmente ostile che presenta tentativi di compromettere riservatezza, integrità e disponibilità delle informazioni o di aggirare i meccanismi di sicurezza utilizzati.

L’IDS deve essere configurato al meglio perché possa agire nel migliore dei modi, in particolare deve conoscere: il o i sistemi operativi, l’attuale versione, le eventuali patch o Service pack installati, lo stack di rete, ecc.

I sistemi attualmente esistenti effettuano una ricerca relativamente semplice, originata dall'analisi di singoli eventi "atomici" attraverso analisi semplice di eventi di Log o di generici testi di un qualsiasi flusso di dati. Tali eventi vengono correlati tra loro con un meccanismo induttivo o deduttivo secondo algoritmi noti nella letteratura dei sistemi esperti per la costruzione di motori inferenziali. In questo caso ci troviamo di fronte a problematiche relativamente semplici.

Ad esempio il sistema IDS può essere basato su tecniche di pattern matching, in cui si sfrutta la corrispondenza dei pacchetti con valori in librerie e database di attacchi e di firme di attacchi (o signature) conosciuti, per rilevare le intrusioni. Quest’ultima fa in modo che l'IDS sia programmato per interpretare una serie di pacchetti, o una parte di dati contenuti in essi, come un attacco. Per la rilevazione di un'intrusione vengono utilizzati degli algoritmi, chiamati pattern matching algorithms, che si basano sul confronto tra le stringhe memorizzate al loro interno (sono delle stringhe che contengono la configurazione di un attacco sotto forma di regola) e la stringa che è stata acquisita dall'IDS. Se la stringa acquisita dall'IDS e una di quelle memorizzale coincidono, l'algoritmo riconosce un attacco e lo comunica all'IDS che si comporterà come deciso dall'amministratore di rete. Questo è un approccio semplice da implementare ma, allo stesso tempo, abbastanza rigido e pesante, dal punto di vista computazionale in quanto ogni pacchetto deve essere confrontato con centinaia di firme di intrusion detection.

Tra gli IDS noti ci sono:

- IDS basati su sistemi di rilevamento euristico o anomaly-based che sfruttano, oltre agli usuali sistemi di identificazione, anche ricerche a livello più avanzato per individuare comportamenti non usuali, come ad esempio il caso di un utente che di solito non utilizza utility per amministratori che improvvisamente e/o immotivatamente tenta di accedere più volte a programmi di gestione del sistema.

- IDS basati su pattern matching, i quali sfruttano la corrispondenza dei pacchetti analizzati con valori di pacchetti disponibili in librerie e database di attacchi e di firme di attacchi (o signature) conosciuti, per rilevare le intrusioni. In pratica l’intrusione viene rilevata mediante il confronto di pacchetti di dati con pacchetti di dati indicativi degli attacchi noti. Per la rilevazione di un'intrusione vengono utilizzati degli algoritmi di pattern matching, che si basano sul confronto tra le stringhe memorizzate al loro interno, cioè le stringhe che contengono la configurazione di un attacco sotto forma di regola, e la stringa che è stata acquisita dall'IDS. Se la stringa acquisita dall'IDS e una di quelle memorizzate coincidono, l'algoritmo riconosce un attacco e lo comunica all'IDS che si comporterà come deciso dall’amministratore di rete.

- IDS basati su sistemi di analisi del protocollo nei quali vengono generati degli allarmi per ogni violazione delle specifiche tecniche di un protocollo di comunicazione, cioè mediante verifica che i pacchetti ricevuti in risposta ad una richiesta corrispondano al protocollo che ci si attende. Nel caso in cui tale condizione non fosse soddisfatta allora il sistema identifica una violazione del protocollo che potrebbe essere indicativa di un attacco in atto.

Sono noti anche sistemi di prevenzione delle intrusioni o Intrusion Prevention Systems o IPS che costituiscono una evoluzione degli IDS o che sono abbinati agli IDS stessi sotto forma di dispositivi hardware autonomi dotati di un proprio sistema operativo. Anziché limitarsi a monitorare il traffico, come gli IDS, gli IPS bloccano il traffico ostile mediante una azione attiva con azioni di contrasto vere e proprie, come ad esempio la modifica regole di firewalling o di software antivirus, disabilitazioni di utenze mail, voip, blocco del traffico destinato o inviato da un determinato IP o porta, ecc.

Problemi della tecnica anteriore

Molti dei sistemi noti di gestione dei file di Log si limitano a monitorare lo stato della infrastruttura IT, gestire gli eventi di violazione con una analisi che permette di risalire aH'origine ed alle cause dei problemi riscontrati. La capacità dei sistemi noti di generare allarmi preventivi che fungano da trigger per azioni di protezione deN'infrastruttura IT è limitata.

I sistemi di IDS basati su pattern matching richiedono continui aggiornamenti relativi ai nuovi tipi di attacco e la loro efficacia dipende fortemente dalla tempestività con cui il database degli attacchi viene aggiornato. Inoltre, un altro inconveniente può essere determinato da regole molto specifiche che producono una rilevante diminuzione di riconoscimento di attacchi. Questo perché se una regola è troppo specifica, gli attacchi che sono simili ma non identici riusciranno a passare senza essere riconosciuti come tali.

I sistemi di IDS basati su rilevamento euristico richiedono un grosso impegno di risorse in termini di manutenzione per l'aggiornamento delle attività effettivamente consentite o usualmente svolte dagli utenti. Inoltre richiedono conoscenze avanzate di matematica e statistica e hanno un costo molto elevato.

I sistemi di IDS basati su analisi del protocollo non sono soddisfacenti in quanto i protocolli sono in genere ben definiti e soggetti al ricorso a stringhe o numeri di verifica generati in sequenza fissa e quindi facilmente prevedibili.

Un problema generale degli IDS è quello dell'affinamento per ridurre i falsi positivi o falsi allarmi ed i falsi negativi o attacchi non rilevati. Se ci si limita a ispezionare ogni pacchetto e a eseguire semplici controlli di pattern matching si usa un approccio troppo generale, che produce molti falsi positivi. Se il pattern matching diventa molto specifico, si rischia di non individuare gli attacchi con numerosi falsi negativi.

Un'analisi effettuata nel metodo classico sopra descritto, è fondamentale ed irrinunciabile per la sicurezza di una infrastruttura. Tuttavia il grosso limite di questi sistemi è la mancanza di "comprendere" un'attività non strettamente connessa alla tecnologia IT ma che molto spesso è causa, concausa e origine degli eventi che poi si ripercuotono sulla struttura IT: gli esseri umani.

Spesso infrazioni, danneggiamenti, violazioni informatiche, sono preceduti da comunicazioni a riguardo tra persone dell'azienda stessa o molto più spesso tra realtà esterne e l'azienda.

L'attività principale in questo senso è la ben nota Social Engineering (pretexting, phishing, ecc.) ovvero la tecnica di manipolazione delle persone per indurle a rivelare informazioni interne, confidenziali o indurle a compiere azioni in buona fede atte a facilitare l'ingresso a vari livelli nella struttura IT e quindi in azienda.

Ad esempio password o dati sensibili possono essere ottenuti da parte di un malintenzionato:

- 'origliando' la comunicazione di autenticazione tra la prima e la seconda entità (attacco di tipo sniffing);

- sostituendosi ad una prima entità, in modo da far credere alla seconda entità che sta inviando la password o i dati a tale prima entità, mentre invece li sta inviando direttamente al malintenzionato (attacco di tipo man-in-the-middle);

- mediante tecniche di "social engineering" e "phishing" nelle quali un malintenzionato, detto ingegnere sociale (social engineer, studia il comportamento della seconda entità, più specificatamente di un utente, al fine di carpire informazioni con l'inganno, nascondendo la propria identità e fingendosi un'altra persona in modo da ricavare informazioni che non potrebbe mai ottenere con la sua identità reale. Un esempio potrebbe essere lo studio di un utente per ottenerne l'indirizzo di posta elettronica ed altri dati sensibili e successivamente il contatto dello stesso fingendosi un amministratore di sistema e chiedendo username e password con la scusa di fare dei controlli sul database dell'azienda.

Scopo dell’invenzione

Scopo della presente invenzione è di fornire un processo ed un apparato per la gestione e analisi di file di Log che consenta un aumentato livello di sicurezza della infrastruttura IT.

Concetto dell'invenzione

Lo scopo viene raggiunto con le caratteristiche della rivendicazione principale. Le sottorivendicazioni rappresentano soluzioni vantaggiose.

Effetti vantaggiosi dell'invenzione

La soluzione in conformità con la presente invenzione, attraverso il notevole apporto creativo il cui effetto costituisce un immediato e non trascurabile progresso tecnico, presenta dei vantaggi sotto diversi aspetti.

Mediante il processo e/o l'apparato secondo la presente invenzione l'infrastruttura IT risulta maggiormente protetta anche da tentativi di intrusione derivanti da tentativi di acquisizione di dati sensibili da parte di malintenzionati.

Il processo secondo la presente invenzione consente anche l'integrazione di diverse fonti di informazioni consentendo l'estrazione di un maggior numero di informazioni rendendo la protezione molto più efficace dei sistemi tradizionali.

Vantaggiosamente la soluzione secondo la presente invenzione, considerando fonti di informazioni più ampie rispetto ai sistemi tradizionali, consente anche di accorgersi ed impedire l'azione di malintenzionati ancora prima che l'attacco effettivo abbia luogo.

Ulteriormente la soluzione secondo la presente invenzione consente l’ottenimento di una gestione affidabile e sicura dei file di log garantendone al contempo l’integrità nel tempo.

La soluzione secondo la presente invenzione consente una più efficiente identificazione delle attività e dei potenziali rischi presenti in una rete di una infrastruttura IT oltre alla individuazione di eventuali anomalie dei sistemi monitorati.

Ulteriormente il sistema secondo la presente invenzione consente di ottenere una riduzione dei costi di gestione della sicurezza rispetto ai sistemi della tecnica anteriore, al contempo aumentando il livello di sicurezza ottenuto.

Descrizione dei disegni

Viene di seguito descritta una soluzione realizzativa con riferimento ai disegni allegati da considerarsi come esempio non limitativo della presente invenzione in cui:

Fig. 1 mostra una vista schematica rappresentante un apparato di gestione e analisi di file di Log secondo la presente invenzione applicato ad una struttura IT.

Fig. 2 mostra una vista schematica rappresentante un’altra forma di realizzazione di un apparato di gestione e analisi di file di Log secondo la presente invenzione applicato ad una struttura IT.

Descrizione dell’invenzione

La presente invenzione prevede l'integrazione delle usuali tecniche di IDS con sistemi di analisi dei file di Log in grado di sfruttare un maggior quantitativo di informazioni che normalmente non vengono considerate e che spesso sono una fonte molto utile per identificare un possibile attacco da parte di malintenzionati prima che l'attacco stesso sia attuato.

L'integrazione di diverse fonti di informazioni consente l'estrazione di un maggior numero di informazioni rendendo la protezione molto più efficace dei sistemi tradizionali.

Il principio si basa su una Analisi Semantica sui dati disponibili. Mediante l'Analisi Semantica si può effettuare una ricerca di elementi utili per identificare eventuali problemi di sicurezza in un linguaggio naturale che quotidianamente viene usato dagli operatori della struttura IT in ogni contesto della propria attività. Con operatori della struttura IT si intendono sia i manager o responsabili della struttura IT stessa ma anche gli utenti finali che utilizzano e sfruttano la struttura IT per la propria attività dalla singola postazione di lavoro. Proprio gli utenti, come precedentemente spiegato, possono essere i punti deboli dei sistemi di protezione in quanto possono inconsciamente rivelare delle informazioni che possono risultare molto utili ad un eventuale malintenzionato. Si pensi ad esempio a e-mail, messaggistica istantanea, accesso al web, documentazione in genere.

Un malintenzionato che venisse a conoscenza di alcuni dati aziendali potrebbe, utilizzando gli stessi, venire a conoscenza di altri dati sensibili per effettuare un attacco alla struttura IT.

Attualmente i sistemi IDS non considerano molte di tali informazioni e spesso intervengono quando ormai l'attacco è in corso e le informazioni sensibili sono già state divulgate al malintenzionato.

Inoltre si prevede che il sistema possa essere ulteriormente esteso anche ad altre forme di comunicazione o di diffusione di informazioni, come ad esempio comunicazioni vocali opportunamente convertite in testi mediante riconoscitori vocali di conversione automatica in testo.

In questo modo si avranno a disposizione molte più informazioni da abbinare alla analisi dei file di Log in modo da ottenere ulteriori riscontri relativamente alle informazioni disponibili nei file di Log stessi e, quindi, si potrà ottenere un livello di sicurezza della struttura IT molto più elevato di quello attualmente consentito dai sistemi della tecnica anteriore.

La possibilità di analizzare il testo sotto certe condizioni con un sistema esperto opportunamente istruito a rilevare minacce che si originano da o che hanno come obiettivo infrastruttura IT consente di identificarle prima ancora o contestualmente ai primi eventi rilevati mediante sistemi SIM [Security Information Management] oppure sistemi SEM [Security Event Management] puri e permette perciò azioni proattive altrimenti impensabili aumentando l'efficienza dal punto di vista di eventuali errori di valutazione (falsi positivi, falsi negativi, ecc.).

Nell'ambito di questa invenzione le fasi fondamentali da effettuare per giungere al risultato finale sono le seguenti:

- Creazione di un lessico specialistico "ad hoc" contestualizzato al mondo IT e a tutte le risorse che ne fanno uso. Il sistema va pertanto messo in grado di avere anche un dizionario tecnico. L'esito finale dell'Analisi Semantica e Logica delle componenti preposte del sistema dipenderà anche e soprattutto dalla ricchezza di tale Dizionario. L'aspetto positivo è che tale operazione è scalabile nel tempo e pertanto integrabile man mano che il sistema diventa sempre più preciso.

- Creazione di una Ontologia idonea istruendo il sistema esperto opportunamente attraverso l'apprendimento del suddetto Dizionario. L'ontologia rappresenta il cuore più importante del motore ed è la parte che richiede più attenzione e lavoro. Qui vengono creati gli schemi e messi in relazione fra di loro sulla base di tecniche di intelligenza artificiale.

- Creazione di un Motore Semantico attraverso il quale effettuare le ricerche sui dati disponibili.

- Eventuale creazione e integrazione di strumenti di normalizzazione delle sorgenti di dati con aggiunta di riconoscitori vocali di conversione automatica in testo (speech to text, image to text).

- Eventuale creazione e integrazione di strumenti di human tagging, come ad esempio face tagging. Questa parte non è strettamente necessaria ma estende le potenzialità della ricerca in maniera significativa estendendo il campione dell'analizzato in maniera esaustiva.

- Creazione di una semantica più semplice per astrarre la verbosità dei Log dei vari servizi mediante una struttura a TAG.

Attraverso l'analisi del linguaggio naturale della base dati fornita dalla conversione dalle diverse sorgenti sarà possibile estrarre delle informazioni riconducibili ad eventi segnalati in varie forme dall'analisi più semplice del motore inferenziale della parte relativa ai sistemi SIM [Security Information Management] oppure sistemi SEM [Security Event Management] vera e propria.

Tale opportunità costituisce un vantaggio che a volte può rivelarsi decisivo nella difesa della struttura perché spesso permette di prevedere con un anticipo che può essere di ore e talvolta di giorni situazioni che altrimenti sarebbero difficilmente individuabili o predicibili con efficacia.

Per l'analisi è necessario costruire un lessico specialistico che sia orientato alla lingua a cui si fa riferimento,

Esempio 1

A titolo di esempio schematico si riporta una analisi completa data dall'abbinamento di motore inferenziale e motore semantico considerando una ipotetica mail inviata da un ipotetico responsabile CED ad un sistemista. Nella tabella sono evidenziati i possibili allarmi che possono scattare in funzione dell'analisi effettuata. Per semplicità non sono riportate alcune analisi effettuate a monte.

MAIL:

step

1 Da: mario.rossi@ced.acme.it

2 A: luigi.ferrari@ced.acme.it

3 Oggetto: attività programmata

4 Ciao Marco,

5 come da accordi telefonici di ieri ti confermo il cambio indirizzo della macchina.

6 Rimetti quello dello scorso mese.

In pratica una email inviata dal responsabile CED ad un sistemista viene analizzata in modo da ottenere delle informazioni che sia possibile mettere in relazione con altri dati, LOG o eventi accessibili al sistema.

Step

1 analisi geografica e black list o spam list dell' IP address di provenienza della mail tramite analisi dell'header del messaggio email.

Già dalla analisi geografica si possono identificare degli eventi anomali. Ad esempio può verificarsi il seguente caso:

1.1 IP proveniente da area geografica non compatibile [cioè dai dati dell’header del messaggio si rileva che il messaggio proviene da un’area geografica che non corrisponde a quella da cui opera il responsabile CED]

1.2 ALLARME [viene generato un allarme che consente immediatamente di intraprendere azioni in modo da evitare che il sistemista destinatario del messaggio agisca sulla base del messaggio che si ritiene potenzialmente pericoloso]

In maniera analoga si potrà agire nel caso in cui dall’header del messaggio si rilevi che il mittente è inserito in una black list o spam list.

Alternativamente dall’header del messaggio potrebbe risultare tutto a posto.

1.1 IP proveniente da area geografica compatibile

2 A questo punto entra in azione il motore semantico che analizza il testo della mail per ottenere il maggior numero di informazioni al fine di incrociare i dati ottenuti con altri dati disponibili da altre fonti di informazione.

- 'attività programmata" presuppone un accordo verbale o scritto tra le due parti o per politiche aziendali. Il motore semantico analizza e per semplicità può ritenere il contesto troppo vago per intraprendere un'azione.

- "Ciao Marco". Il motore semantico riconosce grazie al saluto che il destinatario è Marco. Il contesto è sicuramente un riferimento alla persona a cui si sta indirizzando il contenuto della mail. Marco però non è il nome del sistemista, come si rileva anche dall’indirizzo email del destinatario che è luigi.ferrari@ced.acme.it. Potrebbe essere un errore di distrazione ma anche evidenziare il fatto che chi scrive non è forse Mario Rossi, il responsabile CED che non avrebbe mai compiuto un errore simile. Il motore a questo punto può verificare se esista un altro sistemista con nome Marco. Se non esiste il motore è in grado di fornire un trigger al sistema che può decidere di far scattare un allarme.

- "come da accordi telefonici". Il motore semantico rileva che vi è stata una telefonata

- "di ieri". Il motore semantico identifica che la telefonata tra gli interlocutori è avvenuta il giorno precedente e verifica nei Log se nella giornata precedente vi è stata una telefonata aziendale tra Luigi e Mario. Se non vi è stata non è detto che sia stato usato un canale di comunicazione aziendale e ad esempio la comunicazione potrebbe essere stata effettuata mediante telefoni privati. Tuttavia tale situazione, cioè di assenza di una chiamata tra telefoni aziendali sebbene essa sia citata nella mail, potrebbe essere interpretata come potenziale segnale di un evento sospetto ed essere usata per generare un allarme in caso di ulteriori elementi di sospetto.

- "ti confermo il cambio indirizzo della macchina". Il motore semantico identifica che indirizzo in questo caso si riferisce ad un IP address e che macchina è intesa come host. Conseguentemente il motore semantico identifica che Mario chiede a Luigi di cambiare un indirizzo IP di un host, senza specificare quale. A questo punto si possono intraprendere almeno 4 strade:

a) verificare in tempo reale tramite il semplice SIM/SEM su quale host da adesso in poi acceda Luigi Ferrari;

b) contattare Luigi e/o Marco e chiedere riscontro dell'operazione non programmata;

c) verificare, dopo una conversione speech to text, il contenuto della/e telefonata/e intercorsa/e tra i due nel corso della giornata individuata e alle quali si fa riferimento nella mail;

d) proseguire l'analisi per verificare la presenza di altre informazioni che riconducano direttamente o indirettamente all'host in questione;

- “Rimetti quello dello scorso mese”. Il motore semantico identifica che ΙΊΡ address che sostituirà l’attuale è quello che lo stesso host aveva il mese precedente. Il motore potrà quindi effettuare una verifica per individuare quali host hanno cambiato IP address individuando quindi l’host al quale si fa riferimento.

Da questo semplice esempio si comprende come le potenzialità di controllo ai fini di sicurezza che si ottengono mediante l’applicazione del motore semantico sono enormi e consentono di individuare con opportuni riscontri attività potenzialmente pericolose prima che esse sfocino effettivamente in un attacco alla struttura IT.

Esempio 2

Il crawler, cioè il motore di ricerca, che si occupa della esportazione delle mailbox aziendali individua la seguente mail:

Sender: admin@acme.com

Recipient: name1@xxx

Date: 14/03/2011

Time: 15:30

Subject: Postazioni per ospiti

Corpo della mail:

Come da accordi, ieri ho messo in area ospiti le nuove postazioni, avviate, verificato il funzionamento: tutto ok.

Ciao Name2

Acme

Sysadmin dept.

Occorre notare che in questo semplice esempio i tradizionali controlli su indirizzo IP e mail address del mittente, mail address del destinatario, analisi del log del mailserver, analisi del contenuto per classificazione dello spam non riportano nulla di rilevante e apparentemente “interessante”.

Tuttavia, utilizzando il sistema in conformità con la presente invenzione ed avviando il motore di analisi semantica sulla mail in questione, si otterrebbero interessanti informazioni da utilizzare per verifiche di sicurezza della struttura IT.

Infatti, l’analisi semantica produce il seguente risultato:

Il risultato finale dell’analisi semantica è sintetizzato nella seguente tabella contenente una frase [sentence] con elementi facilmente utilizzabili per effettuare verifiche incrociate con altri dati disponibili:

A questo punto termina il ruolo del motore semantico. La precedente frase è normalizzabile utilizzando un template che, istanziato da una classe “HOST” o “COMPUTER”, ne permetta la valorizzazione degli elementi per una analisi inferenziale. A titolo di esempio si consideri il seguente template:

Dopo la normalizzazione dalla frase iniziale ci troviamo, attraverso l'analisi semantica, con un blocco di semplici "istruzioni" che possono essere analizzate con dei semplici motori inferenziali di correlazione di log oppure con una semplice ricerca per chiavi o sottochiave in un file di log in formato nativo. Andando a verificare nei log registrati dalle sonde che rilevano la presenza di nuovi host o computer in una rete e, nel caso specifico nella rete degli ospiti, si può trovare riscontro di quanto affermato nella mail, ovvero che il giorno prima dei computer siano stati accesi in quella determinata area. Il template Host visualizzato è una semplificazione estrema e viene utilizzato attraverso la stesura di regole, in connubio con altri template, come ad esempio quello relativo al Dominio di Luogo che identifica l’area della rete interessata. I dati ottenuti sono quindi resi facilmente accessibili per consentire analisi inferenziali di verifica incrociata tra dati di diversa origine consentendo l'individuazione di anomalie e la corrispondente generazione di allarmi o avvertimenti.

Esempio 3

Questo esempio dimostra un utilizzo apparentemente un po’ diverso dell’applicazione dell’analisi semantica all’analisi dei contenuti IT. L’azienda Acme S.p.A. ha installato una centralina telefonica aziendale in grado di ricevere e registrare le telefonate per la gestione di un supporto di primo livello ai dipendenti. L’analisi riportata, per quanto estremamente semplificata introduce alcuni nuovi meccanismi, ovvero l’estrapolazione di alcune informazioni utili durante l’analisi semantica per il proseguimento dell’analisi stessa.

Il 14 marzo 2011 l’interno VOIP 100 chiama la centralina telefonica che registra il seguente messaggio: “Sono Rossi, ho problemi con la posta elettronica, oggi alle 15 ho inviato un messaggio a Nome 1 della Nome 2 Corp. con un allegato e non è mai arrivato”.

La centralina telefonica, mediante un componente aggiuntivo apposito, traduce il messaggio vocale in un messaggio in formato testo che quindi viene passato all’analisi semantica.

L’analisi semantica produce il seguente risultato:

Il risultato finale dell’analisi semantica è sintetizzato nella seguente tabella contenente una frase [sentence] con elementi facilmente utilizzabili per effettuare verifiche incrociate con altri dati disponibili:

A questo punto termina il ruolo del motore semantico. La precedente frase è normalizzabile utilizzando un template che, istanziato da una classe “Mail”, ne permetta la valorizzazione degli elementi per una analisi inferenziale, ottenendo:

I log, nella fattispecie di un server di posta, in formato grezzo presentano quasi sempre una data, un’ora, un mittente, un destinatario. In questo caso il destinatario non è noto ma è possibile estrapolarlo isolando le righe di log che le altre informazioni permettono di filtrare. Il campo Ora prevede un intervallo temporale poiché la richiesta telefonica delle ore 3 è approssimativa e molto probabilmente un'indagine alle 15:00:00 precise non porterebbe risultati. Benché il motore semantico abbia esaurito il suo compito rapidamente descriviamo il percorso dell'informazione che ritorna al mittente della mail circa l’esito dell’invio. Praticamente dal messaggio registrato dalla segreteria, tramite la conversione in formato testo e l’analisi semantica si è individuato il problema, il richiedente, l’oggetto del problema e il momento approssimativo in cui esso si è verificato. Con questi dati è possibile effettuare una analisi inferenziale con una ulteriore ricerca nel log nativo del server di posta per cercare l’origine del problema. Ad esempio si ottiene una tabella di risultato identica a quella di normalizzazione ma con tutti i campi popolati, che viene riportata qui di seguito.

Conseguentemente, sulla base di un messaggio voce registrato e convertito in formato di testo, il motore semantico ha individuato dei dati che il motore inferenziale ha usato per la comparazione con i dati del server di posta elettronica riscontrando che la mail inviata ha lasciato correttamente il server di posta elettronica aziendale. A questo punto il problema potrebbe essere invece sul lato server del destinatario. La comunicazione di ritorno a chi ha sollevato la problematica, cioè a Mario Rossi, sull’invio può essere fatta via email, sms o attraverso un sintetizzatore vocale e una chiamata VOIP al richiedente stesso:

"Il messaggio inviato a Nome1@Nome2.com è stato spedito correttamente. Il problema potrebbe essere sul server di posta del destinatario. Verificare nella propria casella di posta se non ci siano notifiche relative alle possibili cause del mancato recapito."

Esempio 4

Si analizzi la seguente mail proveniente dall'indirizzo aziende@banca.it al responsabile finanziario aziendale (ACME S.p.A.). Le analisi classiche non presentano anomalie evidenti relativamente a indirizzo IP di provenienza, indirizzo di posta del mittente, ecc., e, conseguentemente, la mail non viene classificata come spam e la ricezione della mail da parte del destinatario avviene correttamente senza segnalazioni di pericolo.

“Da: aziende@banca.it

A: finance.admin@acme.com

Data: 14/03/2011

Ora: 15:30:34

Oggetto: Contatto immediato

Corpo della mail: Buongiorno, oggi l'ho cercata al telefono ma non sono riuscito a raggiungerla.

Per cortesia mi chiami per comunicazioni urgenti al numero 123 5555555 fino alle 20 poiché ora sono fuori ufficio. Saluti, Nomel - Banca PMI management dept.

L’analisi semantica produce il seguente risultato:

Il risultato finale dell’analisi semantica è sintetizzato nella seguente tabella contenente una frase [sentence] con elementi facilmente utilizzabili per effettuare verifiche incrociate con altri dati disponibili:

Passando alla normalizzazione e considerando uno dei possibili template di normalizzazione ci si focalizza solo sull’azione che deve compiere chi non sarebbe stato raggiunto dalle ipotetiche precedenti chiamate, cioè sulla presenza di eventuali chiamate effettuate da “finance.admin@acme.com” verso chi ha inviato il precedente messaggio.

Durante la fase di normalizzazione dell’evento, cercando nel software di Identity Management aziendale (IMS) si verifica che il numero di cellulare che corrisponde alla presunta identità del mittente della mail (Numero chiamato IMS) non corrisponde a quello specificato nel corpo della mail (Numero chiamato). In pratica il numero che è stato fornito da chi ha inviato la mail non corrisponde al numero presente nel database aziendale e associato a quella persona che si identifica come funzionario della banca. Il risultato di questa parziale indagine semantica e inferenziale successiva, può già essere trattato come un trigger per scatenare una serie di notifiche di allarme o avvisi o ulteriori controlli. Tuttavia, dato il carattere di urgenza invocato nella mail, potrebbe anche essersi verificato il caso che il dipendente della Banca avesse fornito il numero di cellulare personale non presente in alcun database aziendale.

Tuttavia si consideri il caso in cui dal proseguimento della azione di analisi da parte del motore semantico si individui un ulteriore messaggio:

“Da: supporto@gestionali.com

A: amministrazione@acme.com

Data: 14/03/2011

Ora: 16:22:24

Oggetto: Per cortesia richiamate quanto prima

Corpo della mail: Buongiorno, oggi l'ho cercata al telefono ma non sono riuscito a raggiungerla.

Per cortesia mi chiami per comunicazioni urgenti riguardanti la perdita di tutte le fatture ricevute nel mese di Novembre 2010. Mi può trovare al numero 123 5555555 fino alle 23. Saluti, Nome3 - Gestionali SPA”

Tralasciando i passaggi intermedi che sono analoghi al caso del messaggio precedente si ottiene:

Anche in questo caso il numero di riferimento estratto da IMS aziendale non corrisponde a quello fornito nel corpo della mail e valgono le stesse considerazioni del caso precedente. Tuttavia dal confronto delle due email si evince che il numero che viene richiesto di chiamare per le due entità aziendali distinte è lo stesso. A questo punto è chiaro che si tratta di una attività fraudolenta di Social Engineering (phishing) atta a carpire informazioni aziendali messa in atto da un’unica entità e si potranno prendere immediatamente misure atte a prevenire che l’attività fraudolenta abbia successo prima che essa avvenga o sia portata a termine.

Gli esempi riportati sono abbastanza semplici e devono essere intesi esemplificativi del funzionamento della presente invenzione. Le fasi di analisi, benché coerenti, sono esemplificative del meccanismo reale. Ogni evento analizzato può essere normalizzato e rappresentato da più template, ciascuno dei quali potrà essere poi utilizzato per effettuare analisi incrociate inferenziali con differenti basi di dati al fine di individuare eventuali anomalie in relazione a email, telefonate, sms, documenti ricevuti e/o inviati, ecc.

L’analisi semantica mira a comprendere il “significato” del testo in un determinato contesto, come quello dell’IT security. La possibilità di correlare queste informazioni con gli strumenti convenzionali noti permette di procedere con ancora più efficacia nell’intento di garantire la massima sicurezza. Dagli esempi si evidenzia come si possano ritrovare riscontri ad attività sospetta ma soprattutto a come sia possibile predire in molti casi alcuni eventi/comportamenti impostando degli allarmi e predisponendo contromisure al verificarsi di quanto predetto tramite l’analisi semantica.

Ad esempio, nell’esempio 4, sarebbe possibile permettere comunque le chiamate invocate (verso il numero 1235555555), registrandole e magari fornendo informazioni artefatte. L’ambito di ricerca (base dati) e analisi è pressoché illimitato. La ricerca può essere condotta in un database qualsiasi (document management, news, portali di informazione di qualsiasi natura), file del server, flussi di instant messaging, ecc.

L’apparato (17) di gestione e analisi di file di Log secondo la presente invenzione (Fig. 1 , Fig. 2) sarà connesso alla rete (12) ad esempio di una azienda. Sulla rete transitano i dati che devono essere analizzati mediante il motore semantico ed il motore inferenziale. Ad esempio vengono raccolti i dati provenienti dal server (2), da database aziendali (5), da router (3), da switch o bridge (4), da stazioni di lavoro (7), da computer (6) in forma di file di log oppure nella forma di documenti o email. Ulteriormente, come chiarito anche negli esempi precedenti, possono venire anche acquisiti dati nella forma di chiamate telefoniche che provengono dagli apparecchi telefonici (10) mediante un modulo di conversione da voce a testo (11) e possono venire anche acquisiti dati nella forma di fax inviati e/o ricevuti che provengono da apparecchi fax (8) mediante un modulo di conversione OCR (9) in modo da ottenere documenti in formato testo.

Tutti i dati che transitano nella rete vengono opzionalmente ma non necessariamente normalizzati per mezzo di un primo blocco di normalizzazione (13) in modo da avere una base di dati coerenti prima del passaggio degli stessi al motore semantico (14). A questo punto il motore semantico (14) opera come negli esempi descritti, estraendo eventi potenzialmente rilevanti che vengono passati ad un secondo blocco di normalizzazione (15) il quale opera una normalizzazione più o meno spinta, come chiarito negli esempi precedenti.

Gli eventi individuati e normalizzati vengono passati nella forma di frasi facilmente analizzabili ad un motore inferenziale (16) il quale registra gli eventi, genera allarmi e segnalazioni oltre a gestire escalation e comunicazioni di notifica.

L’apparato (17) di gestione e analisi di file di Log secondo la presente invenzione consente quindi di migliorare la sicurezza della infrastruttura IT mediante l’applicazione del motore semantico, il quale sulla base degli argomenti usualmente trattati all’interno della infrastruttura IT (email riguardanti configurazioni di computer, richieste di informazioni, comunicazioni con l’esterno, documenti che circolano sulla rete sia internamente che da e verso l’esterno, ecc.) individua le comunicazioni che sono legate tra di loro e che trattano un medesimo evento. Dalla correlazione tra gli eventi si possono quindi generare allarmi, avvisi, segnalazioni atte a prevenire eventuali azioni fraudolente o potenzialmente pericolose.

Ulteriormente l’apparato di gestione e analisi di file di Log secondo la presente invenzione, oltre a consentire un aumentato livello di sicurezza grazie al ricorso a motori semantici e inferenziali, integra nel sistema stesso anche le funzioni di centralizzazione dei file di LOG e di archiviazione degli stessi, ottenendo quindi un elevato livello di integrazione tra:

- sistema di acquisizione e archiviazione dei file di LOG;

- sistema di acquisizione di dati diversi dai file di LOG che possono essere utili per individuare tempestivamente minacce o tentativi di intrusione nella infrastruttura IT, come ad esempio testi di email, documenti inviati e/o ricevuti via fax, messaggi, telefonate acquisite mediante convertitore da voce a testo;

- motore semantico di analisi;

- motore inferenziale.

L’elevata integrazione dei sistemi che trattano i file di LOG e/o dati ottenuti tramite analisi semantica, dei sistemi di archiviazione e di analisi degli stessi consente inoltre una riduzione dei costi di gestione, garantendo l’integrità del sistema e migliorando anche le prestazioni dal punto di vista della sicurezza complessiva della infrastruttura IT.

L’impiego di algoritmi di cifratura sia nelle fasi di transito che di memorizzazione dei dati consente di mantenere una copia fedele ed inalterata dei log di ogni host o dispositivo monitorato in un unico archivio centralizzato. Oltre a semplificare notevolmente la gestione e la consultazione di tali dati ed ottimizzare l’impiego delle risorse di memorizzazione aziendali (Storage), una simile soluzione consente di disporre sempre di una copia inalterata di ogni log o dati ricavati mediante analisi semantica che vengono generati e gestiti dal sistema, anche nei casi in cui la sicurezza di un host remoto sia stata compromessa ed i log locali dello stesso siano stati alterati. Ciò è particolarmente importante perché tali log permettono di ricostruire a posteriori gli avvenimenti accaduti, identificandone in molti casi la fonte di provenienza; essi forniscono inoltre una prova di ciò che è accaduto nel sistema a tutti gli effetti, diventando all’occorrenza uno strumento con valenza probatoria, in caso di contesa legale. Anche in ambiti puramente operazionali tali log possono risultare importanti, ad esempio per prevenire o ricostruire le cause di una interruzione di servizio. Scoprire in anticipo che i dispositivi di memorizzazione di un certo host stanno degradando le proprie prestazioni, ad esempio a causa di una temperatura ambientale eccessiva o di un problema al sistema di Storage in uso, consente in molti casi di evitare improvvise e catastrofiche interruzioni di servizio ed intraprendere invece interventi di ripristino opportunamente pianificati.

Sempre con riferimento alla analisi semantica si consideri il caso in cui, ad esempio, una comunicazione email inviata riguardi una richiesta di intervento per un guasto al sistema di condizionamento di un’area server e che tramite i file di log provenienti da tale area server si noti un degrado delle prestazioni. Grazie alla analisi semantica il sistema secondo la presente invenzione è in grado non solo di individuare il degrado prestazionale, ma anche di metterlo in relazione con la comunicazione che riguarda il guasto al sistema di condizionamento segnalando, quindi la possibile correlazione tra i due eventi in modo da facilitare l’individuazione del reale problema che ha causato il degrado prestazionale.

Ad esempio si potrà ricorrere ad una architettura client-server nella quale un server si occupa di raccogliere i LOG e le altre informazioni da trattare con il motore semantico precedentemente descritto. Tutti gli altri dispositivi saranno considerati come Client, come ad esempio server (2), database aziendali (5), router (3), switch o bridge (4), stazioni di lavoro (7), computer (6), apparecchi telefonici (10) e relativo modulo di conversione da voce a testo (11), apparecchi fax (8) con relativo modulo di conversione OCR (9). In questo modo i dati vengono raccolti, centralizzati ed archiviati in completa sicurezza ed autonomia, garantendone l’inalterabilità grazie a protocolli cifrati per la trasmissione e la memorizzazione dei dati. Tutti i dati raccolti, quindi, indipendentemente dalla loro origine, vengono trattati nella stessa maniera, eventualmente previa normalizzazione degli stessi e/o analisi semantica per i dati diversi rispetto ai file di LOG grezzi.

II sistema integra le funzioni di SIM (Security Information Management) e SEM (Security Event Management) consentendo anche l’archiviazione ed il mantenimento delle forme originarie dei file di log e delle altre informazioni ottenute mediante il motore semantico, cioè tutte le informazioni che potrebbero essere utili per generare allarmi e segnalazioni ed eventualmente per ricostruire la causa di un problema o una anomalia che non siano stati rilevati in modo da consentire quanto meno per il futuro l’integrazione della casistica particolare che non ha prodotto un allarme o una segnalazione.

Ulteriormente si potrà prevedere l’integrazione di un modulo di firma elettronica, in grado di fornire all’amministratore di sistema un potente strumento di certificazione, in grado di attestare l’integrità dei contenuti anche quando essi sono stati esportati dal sistema stesso. Ad esempio all’atto della richiesta della apposizione di una firma sui dati da esportare, il sistema potrà richiedere l’inserimento di una Smart Card e dei corrispondenti codici di sicurezza prima di effettuare l’operazione di firma digitale dei contenuti da esportare. In questo modo eventuali anomalie nella verifica della firma digitale permetterebbero a posteriori di provare come il file stesso sia stato modificato dopo essere stato esportato dal sistema.

Il sistema consente di acquisire log attraverso protocolli standard (syslog, syslog-NG) o per mezzo di collettori installati sulle macchine da monitorare, i quali trasferiscono i dati in modalità cifrata e con robusti controlli di autenticità, affidabilità ed integrità.

Indipendentemente dal tipo di protocollo e metodologia di trasferimento selezionata, l’apparato (17) di gestione e analisi di file di Log secondo la presente invenzione è in grado di effettuare controlli sui pacchetti ricevuti già a livello IP; la possibilità di definire regole di packet filtering consente così di minimizzare i rischi derivanti da flooding, tentativi di connessioni fasulle e attacchi di tipo DoS (Denial of Service).

Tutti i dati raccolti dall’apparato (17) di gestione e analisi di file di Log vengono gestiti (Fig. 2) mediante un apparato di acquisizione e concentrazione dei dati (19) che si occupa di raccogliere i dati, sia file di LOG che altri dati come precedentemente spiegato, che gestisce anche la memorizzazione degli stessi su un apparato di archiviazione (20) il quale memorizza i dati su filesystem cifrato (in Figura 2 rappresentato mediante un lucchetto che indica la protezione data dalla cifratura dei dati archiviati), nella loro forma originale, ma in modalità compressa, così da consentire un notevole risparmio di spazio su disco. I dati possono essere conservati con le modalità prescritte e per i periodi temporali previsti dalle normative vigenti.

L’acquisizione ed il trasferimento dei file di LOG possono avvenire, come spiegato, da molteplici fonti, attraverso diversi protocolli. Le modalità di trasferimento possono prevedere (Fig. 2) sia l’utilizzo di appositi sensori (18) software, da installare nelle periferiche da monitorare per l’invio dei file di log in forma cifrata (condizione che in Figura 2 è esemplificata dalla presenza di un lucchetto in corrispondenza della rispettiva linea di connessione sulla rete), ad esempio tramite algoritmo Rijndael (standard AES), garantendo in questo modo la sicurezza e quindi l’integrità delle informazioni inviate e ricevute, sia mediante applicazione del protocollo di acquisizione direttamente su TCP, favorendo le prestazioni.

Grazie al ricorso a sensori (18) installati sulle periferiche da controllare è possibile trasferire integralmente il contenuto dei file di log anche nei casi in cui la comunicazione si rende momentaneamente indisponibile. Si prevede infatti che i sensori (18) installati sui singoli dispositivi siano dotati di una doppia cache: la prima cache è mantenuta in memoria RAM e assicura la continuità del servizio in caso di brevi interruzioni, mentre la seconda cache viene mantenuta su disco, preferibilmente in modalità cifrata e permette di fare fronte a periodi di indisponibilità della rete più prolungati.

Preferibilmente il protocollo di trasmissione utilizzato dai sensori (18) per la trasmissione dei dati verso l’apparato (17) di gestione e analisi di file di Log è anche dotato di una serie di funzionalità in grado di aumentare il livello di sicurezza del sistema nel suo complesso ed accertarne il corretto funzionamento, come ad esempio:

- segnali di keep-alive che vengono inviati periodicamente da ciascun Client (o sensore installato sul dispositivo da monitorare) al server e che permettono di individuare immediatamente anomalie accidentali o dolose nelle connessioni, anche nel caso in cui il sistema si trovi in stato IDLE, cioè senza dati da trasferire;

- autenticazione dei Client alla connessione mediante la quale si prevede che all’atto della connessione ciascun Client fornisca una propria password, oltre che un checksum delle proprie caratteristiche software e/o hardware, così da minimizzare le possibilità di furto d’identità da parte di altri sistemi;

- Tag con controlli di sequenza: impiegati anche a livello applicativo e con caratteristiche stateful tra le connessioni, minimizzano le possibilità di attacchi di tipo Man in thè middle;

- Acknowledge a livello applicativo: combinati con l’impiego dei controlli di sequenza precedentemente introdotti, garantiscono l’integrità delle informazioni trasferite anche nei casi in cui le sessioni TCP in essere vadano in Time Out e si rischi quindi la perdita di dati;

- Cambio password di cifratura: la maggiore sicurezza delle connessioni e la minimizzazione dei rischi derivanti da sniffing di rete è garantita attraverso l’impiego di una negoziazione dinamica della chiave di cifratura ad ogni nuova connessione effettuata da un Client;

- Cambio password di autenticazione: in maniera simile a quanto considerato al punto precedente, anche a livello di autenticazione, per ogni successiva connessione, una nuova password viene generata per ciascun Client;

- Checksum sulla lunghezza dei pacchetti: anche a livello applicativo vengono effettuati checksum sulla lunghezza dei payload, a ulteriore garanzia dell’integrità dei dati trasferiti.

Vantaggiosamente, mediante il supporto di trasmissione attraverso i protocolli standard come ad esempio Syslog e Syslog NG (sia su canale UDP che TCP), l’apparato (17) di gestione e analisi di file di Log secondo la presente invenzione è in grado di ricevere dati anche senza l’utilizzo di sensori (18) software installati remotamente; in questo caso il sistema è in grado di appoggiarsi direttamente alle funzionalità e ai protocolli per il trasferimento remoto dei log, nativamente messi a disposizione dai moderni Sistemi Operativi. Questo tipo di configurazione è anche assai utile per il trasferimento di log da dispositivi di rete su cui non è possibile l’installazione di software aggiuntivi, come ad esempio firewall, router (3), switch (4), ecc.

Grazie a questa duplice possibilità di trasferimento, il sistema secondo la presente invenzione è quindi in grado di raccogliere e trasferire i log provenienti dalla maggior parte dei sistemi esistenti ottenendo pertanto la massima flessibilità di applicazione dello stesso a differenti infrastrutture IT.

I protocolli ed i sistemi citati in precedenza sono da considerarsi indicativi, ma non limitanti circa le tipologie di trasferimento che è possibile implementare.

Ulteriormente l’apparato (17) di gestione e analisi di file di Log secondo la presente invenzione consente anche la centralizzazione dei log provenienti da diversi sistemi e l’accentramento delle funzioni di controllo sui dati raccolti. Per mezzo della memorizzazione centralizzata e compressa dei dati è possibile ottimizzare l’utilizzo delle risorse di Storage, oltre che individuare immediatamente eventi degni di nota e quindi ottenere rapidamente specifici frammenti di log da analizzare mediante il motore semantico ed il motore inferenziale.

L’apparato (17) di gestione e analisi di file di Log secondo la presente invenzione è anche in grado di preparare file per il download, eventualmente previa apposizione di firma digitale.

Per salvaguardare sicurezza ed integrità dei log e degli altri dati acquisiti che vengono salvati, questi vengono memorizzati su un filesystem cifrato. Preferibilmente la chiave di cifratura dello stesso è ricavata da caratteristiche hardware e software dell’apparato (17) stesso, oltre che da controlli sui file binari del sistema e da un’apposita chiave hardware per impedire l’accesso ai dati del sistema e proteggerli anche nei casi in cui i supporti di memorizzazione in cui sono stati registrati vengano sottratti o duplicati. Al fine di ottimizzare le risorse di immagazzinamento dei dati i log vengono preferibilmente compressi. La locazione fisica del filesystem su cui risiedono i log può essere locale o remota, essendo previsti modelli in cui la memorizzazione dei log avviene su dispositivi di Storage condivisi o dedicati come SAN o NAS.

Come precedentemente spiegato, l’apparato (17) di gestione e analisi di file di Log secondo la presente invenzione integra sia un motore inferenziale di analisi dei file di log che un motore semantico per l’analisi e la normalizzazione di dati che normalmente non sarebbero trattabili dal motore inferenziale stesso.

In generale la presente invenzione riguarda un apparato industriale, sistema e metodo di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo generati da almeno un dispositivo Client collegato ad una rete di comunicazione e trasmessi ad almeno un apparato di raccolta, gestione e analisi dei file di LOG. Si forniscono mezzi di analisi semantica dei dati informatici e/o dati convertiti in formato testo per mezzo di un motore semantico il quale sulla base di un dizionario lessicale identifica parole chiave nei dati informatici e/o dati convertiti in formato testo, a ciascuna parola chiave essendo associato un corrispondente termine identificato corrispondente ad una determinata attività o evento identificati e genera una matrice di attività o evento identificati sulla base di almeno uno schema identificativo di attività o evento identificati per analisi da parte di mezzi di analisi dei file di LOG.

Ossia la presente invenzione si riferisce ad un apparato industriale (17) di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo atto a ricevere file di LOG di sistema e/o dati informatici e/o dati in formato testo da almeno un dispositivo Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11). L’apparato (17) di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo è dotato di un apparato di acquisizione e concentrazione (19) dei file di LOG di sistema e/o dati informatici e/o dati in formato testo ricevuti da uno o più dispositivi Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11), mezzi di gestione dei file di LOG di sistema e/o dati informatici e/o dati in formato testo atti alla memorizzazione dei file di LOG di sistema e/o dati informatici e/o dati in formato testo su un apparato di archiviazione (20), mezzi di analisi (16) dei file di LOG di sistema e/o dati informatici e/o dati in formato testo. L’apparato (17) comprende mezzi di analisi semantica (14) dei dati informatici e/o dati in formato testo per mezzo di un motore semantico, in cui i mezzi di analisi semantica (14):

- ricercano sulla base di un dizionario lessicale parole chiave nei dati informatici e/o dati convertiti in formato testo, a ciascuna parola chiave essendo associato un corrispondente termine identificato corrispondente ad una determinata attività o evento identificati e/o locazione e/o dati di una macchina e/o intervallo temporale e/o dati di un utente e/o riferimenti ad un IMS [Identity Management] aziendale; - generano una matrice di attività o evento identificati sulla base di almeno uno schema identificativo di detti attività o evento identificati, detta matrice contenente almeno detti termini identificati, detta matrice indicante il verificarsi di detti attività o evento identificati e detti termini identificati fornenti dettagli di specificazione di detta attività specificanti attività o evento identificati e/o locazione e/o dati di una macchina e/o intervallo temporale e/o dati di un utente e/o riferimenti ad un IMS [Identity Management] aziendale;

- salvano detta matrice di attività o evento identificati come file di LOG contenente una frase corrispondente a detti attività o evento identificati in detti dati informatici e/o dati convertiti in formato testo, detto file di LOG contenente detta frase essendo strutturato secondo uno schema atto ad essere interpretato da detti mezzi di analisi (16) dei file di LOG.

Ulteriormente i mezzi di analisi (16) dei file di LOG analizzano i file di LOG corrispondenti a attività o evento identificati nei dati informatici e/o dati convertiti in formato testo ed i file di LOG di sistema per correlare le informazioni in essi contenuti ed individuare attività sospette o potenzialmente pericolose all’interno della rete (12).

L’apparato può essere configurato e strutturato come server di rete.

In particolare la presente invenzione si riferisce ad un sistema o apparato di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo comprendente:

- almeno una rete (12) di comunicazione tra dispositivi;

- almeno un dispositivo Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11) collegato alla rete (12) e dotato di mezzi di generazione di file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo e dotato di mezzi di trasmissione dei file di LOG di sistema e/o dati convertiti in formato testo sulla rete (12);

- almeno un apparato (17) di raccolta, gestione e analisi dei file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo atto a ricevere i file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo da almeno uno di tali dispositivi Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11); l’apparato (17) di raccolta, gestione e analisi dei file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo è dotato di un apparato di acquisizione e concentrazione (19) dei file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo ricevuti dai dispositivi Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11), mezzi di gestione dei file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo atti alla memorizzazione dei file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo su un apparato di archiviazione (20), mezzi di analisi (16) dei file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo.

L’apparato (17) di raccolta, gestione e analisi dei file di LOG e/o dati informatici e/o dati convertiti in formato testo comprende mezzi di analisi semantica (14) dei dati informatici e/o dati convertiti in formato testo per mezzo di un motore semantico, in cui i mezzi di analisi semantica (14):

- ricercano sulla base di un dizionario lessicale parole chiave nei dati informatici e/o dati convertiti in formato testo, a ciascuna parola chiave essendo associato un corrispondente termine identificato corrispondente ad una determinata attività o evento identificati e/o locazione e/o dati di una macchina e/o intervallo temporale e/o dati di un utente e/o riferimenti ad un IMS [Identity Management] aziendale; - generano una matrice di attività o evento identificati sulla base di almeno uno schema identificativo di tali attività o evento identificati. La matrice contiene almeno tali termini identificati ed indica il verificarsi di tali attività o evento identificati ed i termini identificati forniscono dettagli di specificazione di tale attività specificanti attività o evento identificati e/o locazione e/o dati di una macchina e/o intervallo temporale e/o dati di un utente e/o riferimenti ad un IMS [Identity Management] aziendale;

- salvano la matrice di attività o evento identificati come file di LOG contenente una frase corrispondente a tali attività o evento identificati nei dati informatici e/o dati convertiti in formato testo. Il file di LOG contenente tale frase è strutturato secondo uno schema atto ad essere interpretato dai mezzi di analisi (16) dei file di LOG. Ulteriormente i file di LOG corrispondenti a tali attività o eventi identificati nei dati informatici e/o dati convertiti in formato testo ed i file di LOG di sistema vengono analizzati dai mezzi di analisi (16) di file di LOG.

Vantaggiosamente i dati informatici e/o dati convertiti in formato testo possono comprendere email e/o documenti aziendali e/o contenuto di chiamate telefoniche provenienti da apparecchi telefonici (10) convertite in formato testo mediante un modulo o dispositivo di conversione da voce a testo (11) e/o fax inviati e/o ricevuti tramite apparecchi fax (8) convertiti in formato testo mediante un modulo o dispositivo di conversione OCR (9) e/o dati provenienti da firewall e/o dati provenienti da router (3) e/o dati provenienti da switch (4) di rete e/o dati di face tagging ad esempio per il riconoscimento facciale dell’utente. Ad esempio si potranno prevedere dispositivi di rilevamento di immagini per realizzare la funzionalità di face tagging.

I file di LOG corrispondenti ad attività o evento identificati nei dati informatici e/o dati convertiti in formato testo vengono analizzati dai mezzi di analisi (16) per mezzo di un motore inferenziale insieme ai file di LOG di sistema. Il motore inferenziale correla le attività o eventi identificati nei dati informatici e/o dati convertiti in formato testo con le attività o eventi associati ai file di LOG di sistema.

I mezzi di analisi (16) possono comprendere un sistema SIM [Security Information Management] e/o un sistema SEM [Security Event Management], Il sistema SIM raccoglie i file di LOG corrispondenti ad attività o evento identificati ed i LOG di sistema per visualizzazione di report, grafici relativi alle attività. Il sistema SEM raccoglie i file di LOG corrispondenti ad attività o evento identificati e i LOG di sistema per visualizzazione di report, grafici relativi ad attività o eventi e per analisi e generazione di allarmi a seguito di tale analisi.

II sistema di raccolta, gestione e analisi di file di LOG può comprendere almeno un blocco di normalizzazione (13, 15) il quale opera sui file di LOG corrispondenti ad attività o evento identificati e LOG di sistema operando una trasposizione dei file di LOG in un formato unico uniforme comune a tutti i file di LOG.

Il sistema potrà comprendere sensori (18) software o hardware in corrispondenza di almeno uno dei dispositivi Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11) collegati alla rete (12). Il sensore (18) potrà ad esempio comunicare in forma cifrata con l’apparato (17) di raccolta, gestione e analisi dei file di LOG e potrà fornire una password e/o un checksum delle proprie caratteristiche hardware all’atto della connessione con l’apparato (17) o inviare periodicamente segnali di keep-alive.

La memorizzazione di detti file di LOG sull’apparato di archiviazione (20) può avvenire in forma cifrata ed il sistema potrà comprendere un modulo di esportazione dei file di LOG ed un modulo di firma elettronica dei file di LOG durante l’esportazione per certificazione o attestazione della loro integrità.

Ulteriormente la presente invenzione riguarda anche un metodo di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo, tale metodo comprendente le fasi di:

a) configurazione di almeno una rete (12) di comunicazione tra dispositivi;

b) configurazione di almeno un dispositivo Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11) collegato alla rete (12) per la generazione di file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo e per la trasmissione di file di LOG di sistema e/o dati convertiti in formato testo sulla rete (12);

c) configurazione di almeno un apparato (17) di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo per la ricezione di file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo da uno o più dispositivi Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11).

II metodo comprende una fase di analisi semantica (14) dei dati informatici e/o dati convertiti in formato testo per mezzo del motore semantico, in cui la fase di analisi semantica (14) comprende le fasi di :

i) ricerca sulla base di un dizionario lessicale di parole chiave nei dati informatici e/o dati convertiti in formato testo, a ciascuna parola chiave essendo associato un corrispondente termine identificato corrispondente ad una determinata attività o evento identificati e/o locazione e/o dati di una macchina e/o intervallo temporale e/o dati di un utente e/o riferimenti ad un IMS [Identity Management] aziendale; ii) generazione di una matrice di attività o evento identificati sulla base di almeno uno schema identificativo di tali attività o evento identificati. La matrice contiene almeno i termini identificati. La matrice indica il verificarsi di tali attività o evento identificati ed i termini identificati forniscono dettagli di specificazione della attività che specificano l’attività o evento identificati e/o locazione e/o dati di una macchina e/o intervallo temporale e/o dati di un utente e/o riferimenti ad un IMS [Identity Management] aziendale;

iii) salvataggio della matrice di attività o evento identificati come file di LOG contenente una frase corrispondente a tali attività o evento identificati nei dati informatici e/o dati convertiti in formato testo, tale file di LOG contenente tale frase essendo strutturato secondo uno schema atto ad essere interpretato da mezzi di analisi (16) dei file di LOG.

Ulteriormente il metodo comprende una fase di analisi mediante mezzi di analisi (16), in cui tale fase di analisi avviene su tali file di LOG corrispondenti a tali attività o evento identificati nei dati informatici e/o dati convertiti in formato testo e file di LOG di sistema.

La descrizione della presente invenzione e stata fatta con riferimento alle figure allegate in una forma di realizzazione preferita della stessa, ma è evidente che molte possibili alterazioni, modifiche e varianti saranno immediatamente chiare agli esperti del settore alla luce della precedente descrizione. Cosi, va sottolineato che l'invenzione non è limitata dalla descrizione precedente, ma include tutte quelle alterazioni, modifiche e varianti in conformità con le annesse rivendicazioni.

Nomenclatura utilizzata

Con riferimento ai numeri identificativi riportati nelle figure allegate, si è usata la seguente nomenclatura:

1. Infrastruttura IT

2. Server

3. Router

4. Switch/bridge di rete

5. Database

6. Computer

7. Stazione di lavoro

8. Fax

9. Modulo di conversione OCR

10. Telefono

11 . Modulo di conversione da voce a testo

12. Rete

13. Primo blocco di normalizzazione

14. Motore semantico

15. Secondo blocco di normalizzazione

16. Motore inferenziale

17. Apparato di gestione e analisi dei file di log

18. Sensore

19. Apparato di acquisizione e concentrazione dei dati 20. Apparato di archiviazione

Claims (13)

1. RIVENDICAZIONI 1. Apparato industriale (17) di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo atto a ricevere detti file di LOG di sistema e/o dati informatici e/o dati in formato testo da almeno un dispositivo Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11) connesso a detto apparato (17) per mezzo di una rete (12), detto apparato (17) di raccolta, gestione e analisi di detti file di LOG di sistema e/o dati informatici e/o dati in formato testo essendo dotato di un apparato di acquisizione e concentrazione (19) di detti file di LOG di sistema e/o dati informatici e/o dati in formato testo ricevuti da detto almeno un dispositivo Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11), mezzi di gestione di detti file di LOG di sistema e/o dati informatici e/o dati in formato testo atti alla memorizzazione di detti file di LOG di sistema e/o dati informatici e/o dati in formato testo su un apparato di archiviazione (20), mezzi di analisi (16) di detti file di LOG di sistema e/o dati informatici e/o dati in formato testo caratterizzato dal fatto che detto apparato (17) di raccolta, gestione e analisi di detti file di LOG e/o dati informatici e/o dati in formato testo comprende mezzi di analisi semantica (14) di detti dati informatici e/o dati in formato testo per mezzo di un motore semantico, in cui detti mezzi di analisi semantica (14): - ricercano sulla base di un dizionario lessicale parole chiave in detti dati informatici e/o dati convertiti in formato testo, a ciascuna parola chiave essendo associato un corrispondente termine identificato corrispondente ad una determinata attività o evento identificati e/o locazione e/o dati di una macchina e/o intervallo temporale e/o dati di un utente e/o riferimenti ad un IMS [Identity Management] aziendale; - generano una matrice di attività o evento identificati sulla base di almeno uno schema identificativo di detti attività o evento identificati, detta matrice contenente almeno detti termini identificati, detta matrice indicante il verificarsi di detti attività o evento identificati e detti termini identificati fornenti dettagli di specificazione di detta attività specificanti attività o evento identificati e/o locazione e/o dati di una macchina e/o intervallo temporale e/o dati di un utente e/o riferimenti ad un IMS [Identity Management] aziendale; - salvano detta matrice di attività o evento identificati come file di LOG contenente una frase corrispondente a detti attività o evento identificati in detti dati informatici e/o dati convertiti in formato testo, detto file di LOG contenente detta frase essendo strutturato secondo uno schema atto ad essere interpretato da detti mezzi di analisi (16) di detti file di LOG; ed ulteriormente caratterizzato dal fatto che detti mezzi di analisi (16) di detti file di LOG analizzano detti file di LOG corrispondenti a detti attività o evento identificati in detti dati informatici e/o dati convertiti in formato testo insieme a detti file di LOG di sistema.
2. 2. Apparato industriale (17) di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo secondo la rivendicazione precedente caratterizzato dal fatto che detti dati informatici e/o dati convertiti in formato testo comprendono email e/o documenti aziendali e/o contenuto di chiamate telefoniche provenienti da apparecchi telefonici (10) convertite in formato testo mediante un modulo di conversione da voce a testo (11) e/o fax inviati e/o ricevuti tramite apparecchi fax (8) convertiti in formato testo mediante un modulo di conversione OCR (9) e/o dati provenienti da firewall e/o dati provenienti da router (3) e/o dati provenienti da switch (4) di rete e/o dati di face tagging.
3. 3. Apparato industriale (17) di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo secondo una qualsiasi delle rivendicazioni precedenti caratterizzato dal fatto che detti mezzi di analisi (16) analizzano detti file di LOG corrispondenti a detti attività o evento identificati in detti dati informatici e/o dati convertiti in formato testo per mezzo di un motore inferenziale insieme a detti file di LOG di sistema, detto motore inferenziale correlando le attività o eventi identificati in detti dati informatici e/o dati convertiti in formato testo con le attività o eventi associati a detti file di LOG di sistema.
4. 4. Apparato industriale (17) di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo secondo una qualsiasi delle rivendicazioni precedenti caratterizzato dal fatto che detti mezzi di analisi (16) comprendono un sistema SIM [Security Information Management] e/o un sistema SEM [Security Event Management], in cui detto sistema SIM raccoglie detti file di LOG corrispondenti a detti attività o evento identificati e detti LOG di sistema per visualizzazione di report, grafici relativi a dette attività o eventi ed in cui detto sistema SEM raccoglie detti file di LOG corrispondenti a detti attività o evento identificati e detti LOG di sistema per visualizzazione di report, grafici relativi a detti attività o eventi e per analisi e generazione di allarmi a seguito di detta analisi.
5. 5. Apparato industriale (17) di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo secondo una qualsiasi delle rivendicazioni precedenti caratterizzato dal fatto che comprende almeno un blocco di normalizzazione (13, 15) il quale opera su detti file di LOG corrispondenti a detti attività o evento identificati e detti LOG di sistema operando una trasposizione di detti file di LOG corrispondenti a detti attività o evento identificati e detti LOG di sistema in un formato unico uniforme comune a tutti detti file di LOG corrispondenti a detti attività o evento identificati e detti LOG di sistema.
6. 6. Apparato industriale (17) di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo secondo una qualsiasi delle rivendicazioni precedenti caratterizzato dal fatto che è configurato e strutturato come server di rete.
7. 7. Apparato industriale (17) di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo secondo una qualsiasi delle rivendicazioni precedenti caratterizzato dal fatto che detto apparato (17) memorizza detti file di LOG su detto apparato di archiviazione (20) in forma cifrata.
8. 8. Apparato industriale (17) di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo secondo una qualsiasi delle rivendicazioni precedenti caratterizzato dal fatto che comprende un modulo di esportazione di detti file di LOG ed un modulo di firma elettronica di detti file di LOG durante l’esportazione per certificazione o attestazione della loro integrità.
9. 9. Sistema di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo comprendente: - almeno detta rete (12) di comunicazione tra dispositivi - almeno detto dispositivo Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11) collegato a detta rete (12) e dotato di mezzi di generazione di detti file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo e dotato di mezzi di trasmissione di detti file di LOG di sistema e/o dati convertiti in formato testo su detta rete (12) almeno detto apparato (17) di raccolta, gestione e analisi di detti file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo atto a ricevere detti file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo da detto almeno un dispositivo Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11), detto apparato (17) di raccolta, gestione e analisi di detti file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo essendo dotato di detto apparato di acquisizione e concentrazione (19) di detti file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo ricevuti da detto almeno un dispositivo Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11), detto apparato (17) essendo dotato di mezzi di gestione di detti file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo atti alla memorizzazione di detti file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo su detto apparato di archiviazione (20), detto apparato (17) essendo dotato di detti mezzi di analisi (16) di detti file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo caratterizzato dal fatto che detto apparato (17) di raccolta, gestione e analisi di detti file di LOG e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo è un apparato secondo una qualsiasi delle rivendicazioni precedenti e comprende detti mezzi di analisi semantica (14) di detti dati informatici e/o dati convertiti in formato testo per mezzo di detto motore semantico.
10. 10. Sistema di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo secondo la rivendicazione precedente caratterizzato dal fatto che comprende almeno uno di detti moduli o dispositivi di conversione da voce a testo (11) convertente telefonate su detto apparecchio telefonico (10) in dati convertiti in formato testo e/o almeno uno di detti moduli o dispositivi di conversione OCR (9) convertente fax inviati e/o ricevuti tramite detto apparecchio fax (8) in dati convertiti in formato testo e/o dispositivi di conversione in formato testo di dati provenienti da detti firewall e/o router (3) e/o switch (4) di rete e/o dispositivi di rilevamento di immagini e face tagging.
11. 11. Sistema di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo secondo una qualsiasi delle rivendicazioni precedenti da 9 a 10 caratterizzato dal fatto che comprende almeno un sensore (18) software o hardware in corrispondenza di almeno uno di detti dispositivi Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11) collegati a detta rete (12), detto sensore (18) comunicante in forma cifrata con detto almeno un apparato (17) di raccolta, gestione e analisi di detti file di LOG.
12. 12. Sistema di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo secondo la rivendicazione precedente caratterizzato dal fatto che detto sensore (18) fornisce una password e/o un checksum delle proprie caratteristiche software e/o hardware all’atto della connessione con detto apparato (17) di raccolta, gestione e analisi di detti file di LOG e/o detto sensore (18) invia periodicamente segnali di keep-alive a detto apparato (17) di raccolta, gestione e analisi di detti file di LOG.
13. 13. Metodo di raccolta, gestione e analisi di file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo mediante un apparato secondo una qualsiasi delle rivendicazioni precedenti da 1 a 8, detto metodo comprendente le fasi di: a) configurazione di detta almeno una rete (12) di comunicazione tra detti dispositivi b) configurazione di detto almeno un dispositivo Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11) collegato a detta rete (12) per la generazione di detti file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo e per la trasmissione di detti file di LOG di sistema e/o dati informatici e/o dati convertiti in formato testo su detta rete (12) c) configurazione di detto almeno un apparato (17) di raccolta, gestione e analisi di detti file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo per la ricezione di detti file di LOG di sistema e/o dati informatici e/o dati in formato testo e/o dati convertiti in formato testo da detto almeno un dispositivo Client (2, 3, 4, 5, 6, 7, 8, 9, 10, 11), caratterizzato dal fatto che detto metodo comprende una fase di analisi semantica (14) di detti dati informatici e/o dati in formato testo e/o dati convertiti in formato testo per mezzo di detto motore semantico, in cui detta fase di analisi semantica (14) comprende le fasi di: i) ricerca sulla base di detto dizionario lessicale di parole chiave in detti dati informatici e/o dati convertiti in formato testo, a ciascuna parola chiave essendo associato un corrispondente termine identificato corrispondente ad una determinata attività o evento identificati e/o locazione e/o dati di una macchina e/o intervallo temporale e/o dati di un utente e/o riferimenti ad un IMS [Identity Management] aziendale; ii) generazione di detta matrice di attività o evento identificati sulla base di detto almeno uno schema identificativo di detti attività o evento identificati, detta matrice contenente almeno detti termini identificati, detta matrice indicante il verificarsi di detti attività o evento identificati e detti termini identificati fornenti dettagli di specificazione di detta attività specificanti attività o evento identificati e/o locazione e/o dati di una macchina e/o intervallo temporale e/o dati di un utente e/o riferimenti ad un IMS [Identity Management] aziendale; iii) salvataggio di detta matrice di attività o evento identificati come file di LOG contenente una frase corrispondente a detti attività o evento identificati in detti dati informatici e/o dati convertiti in formato testo, detto file di LOG contenente detta frase essendo strutturato secondo uno schema atto ad essere interpretato da detti mezzi di analisi (16) di detti file di LOG; ed ulteriormente caratterizzato dal fatto che detto metodo comprende detta fase di analisi mediante detti mezzi di analisi (16), detta fase di analisi avvenendo su detti file di LOG corrispondenti a detti attività o evento identificati in detti dati informatici e/o dati in formato testo e/o dati convertiti in formato testo insieme a detti file di LOG di sistema che vengono analizzati da detti mezzi di analisi (16) di detti file di LOG.