0689178001

Il Progetto H.A.P.S.

storie_di_successo, tecnologie

Il Progetto H.A.P.S. – Parte Seconda

  • d.barbato
  • Nessun commento

Il contributo di NS12 al progetto e l’importanza dell’Analisi di scenario

Estensioni al modello iniziale HAPS

Le caratteristiche del progetto di Ricerca & Sviluppo finanziato dalla Regione Lazio “HOLISTIC ATTACK PREVENTION SYSTEM” – che abbiamo raccontato nell’articolo “Il Progetto HAPS” a cui rimandiamo per approfondimenti in merito – ha portato allo sviluppo di una Soluzione di Cyber Security basata su algoritmi di Intelligenza Artificiale, per individuare in real-time gli attacchi informatici.

In questo articolo approfondiremo gli input di cui NS12 si è fatta portavoce, proponendo una serie di estensioni che sono state accettate dai Partner dell’ATI (Reply Whitehall ed Expleo) per essere poi sviluppate ed inserite nel sistema finale, rilasciato al termine del progetto.

Il riferimento principale è ai punti 9 e 10 evidenziati nell’immagine che segue.

Contributi NS12 alla architettura di HAPS

9. SNORT è un software open source del tipo Network Intrusion Detection System (IDS), leader nel suo segmento, che intercetta le HTTP Requests dirette verso specifici server con moduli detti sniffers e ne esamina il contenuto in tempo quasi-reale con un motore di parsing molto efficiente per cercare combinazioni di dati (pattern) nel singolo pacchetto che possano indicare un intento malevolo della request stessa. Ad esempio nei casi di attacchi tipo XSS e SQL Injection cerca nella request sequenze tipiche di caratteri che si presentano in questi casi (nel protocollo HTTP porta 80). SNORT è facilmente configurabile per intercettare nuove sequenze che possono essere indizio di attacchi, perché legge le “regole” da applicare da un file esterno. In particolare, le regole sono scritte con uno specifico linguaggio e sono raccolte in file di formato “.rules”. Possono essere aggiornate dalla comunità che sviluppa e presidia SNORT e possono essere immediatamente utilizzate leggendo i file .rules aggiornati.

Si può definire SNORT un “Sistema Esperto basato su regole (rule-based)” in quanto la sua “intelligenza” dipende dall’Esperto che ha scritto le Regole. Anche i “Sistemi Esperti” come SNORT fanno parte della famiglia delle applicazioni di AI, quindi si inserisce coerentemente nella architettura di HAPS.

Comunque SNORT da solo non basterebbe (o comunque non sarebbe completamente affidabile) per identificare con certezza un attacco ma può rafforzare le sue segnalazione integrandosi con altre fonti, ad esempio con gli algoritmi di AI/ML di HAPS: di qui il suggerimento di NS12 di aumentare la capacità di predizione e di identificazione della “Soluzione HAPS” utilizzando il maggior numero possibile di informazioni raccolte da diverse fonti alimentando un unico modulo che ricostruisce lo “Scenario di attacco”.

10. Modulo di “Analisi di Scenario”. Nasce con l’obiettivo di interpretare le segnalazioni generate dal modulo di AI/ML (analisi che sono intrinsecamente soggette ad percentuale di incertezza) sulla base di informazioni provenienti anche da altre fonti, per validare la situazione reale sulla base della maggior quantità di informazioni possibili correlando fra loro anche eventi che avvengono in momenti diversi. Viene realizzato con un sistema esperto “a Regole” per essere rapidamente aggiornato, anche per riconoscere nuove minacce che non si sono ancora concretizzate (ad esempio zero-day-exploit).

Cosa si intende per “Analisi di Scenario”?

Per presentare il concetto di “analisi di scenario” può essere utile ricordare cosa è successo in una situazione drammaticamente reale, durante il cosiddetto “incidente dell’equinozio autunnale”, il 26 settembre 1983.

In quella occasione, un ufficiale sovietico addetto al monitoraggio del sistema satellitare posto a sorveglianza dei siti missilistici statunitensi, vide sui propri monitor il segnale di un attacco con missili intercontinentali dagli Stati Uniti verso la Russia, attacco a cui la Russia avrebbe dovuto rispondere con una massiccio (e totalmente distruttivo) contrattacco, sulla base del “principio” della “certezza della mutua distruzione”. Il rischio era la distruzione del mondo come lo conosciamo.

Ma, anche se i segnali dai monitor erano inequivocabili (prima uno, poi altri quattro missili risultavano lanciati da una base USA verso la Russia) e la reazione sembrava inevitabile, l’Ufficiale non prese la decisione di lanciare la (devastante) rappresaglia nucleare perché lo “scenario” in cui si manifestava l’attacco non era per lui verosimile. Infatti non era “logico” che gli USA attaccassero la Russia con UN SOLO missile (o con pochi missili) perché era scontato che, dopo un primo attacco che non avrebbe distrutto la capacità di reazione del “nemico”, la reazione sarebbe stata devastante. Quindi si sarebbe trattato di un attacco velleitario, anzi controproducente. Quindi illogico, non credibile.

Fortunatamente mancavano anche altri riscontri, da altri sistemi di controllo, che i missili fossero effettivamente in volo, quindi l’Ufficiale decise di non scatenare la rappresaglia, prendendosi la responsabilità di affermare che si trattava di una errata segnalazione del sistema di monitoraggio satellitare.

La decisione fu quella giusta. Se volete conoscere la sorte dell’Ufficiale, potete leggere il seguito della storia su https://it.wikipedia.org/wiki/Stanislav_Evgrafovi%C4%8D_Petrov.

Tornando ad HAPS, anche in un sistema di monitoraggio della Cyber Security, possono / devono essere impiegati diversi strumenti di monitoraggio, perché di fronte alla sempre maggiore capacità di “attacco” dei pirati informatici, bisogna rispondere con tutti i mezzi possibili.

Quindi, insieme ai (probabili ma non certi) Alert prodotti dagli algoritmi di ML di HAPS possono essere considerati gli Alert prodotti da altri sistemi che sfruttano altre tecnologie, forse meno innovative ma complessivamente affidabili, come appunto i “Sistemi Esperti” e le loro Regole.

Machine Learning vs. Sistemi Esperti Rule-Based

Per realizzare sistemi che aggiungono “esperienza” o “intelligenza” al sistema non è necessario utilizzare tecniche di ML, anzi si possono utilizzare le piattaforme per realizzare “Sistemi basati su regole”, per alcune caratteristiche distintive che questi sistemi hanno rispetto ai sistemi basati su algoritmi di ML:

  • Possono essere programmate delle regole anche per trattare casi che non sono mai avvenuti, ma che potrebbero avvenire o che sono già avvenuti in altre situazioni (zero-day-exploit). In questi casi non si disporrebbe dei trainingSet per fare l’addestramento dei moduli di ML;
  • L’ applicazione di nuove regole, inserite in aggiunta a quelle già presenti, è immediata e quindi la “protezione” del sistema dai nuovi attacchi è più rapida rispetto al processo di preparazione trainingSet, training, verifica necessario per aggiornare gli algoritmi di ML;
  • Le nuove regole possono essere fornite anche da una community esterna e sono quindi immediatamente utilizzabili;
  • I “sistemi basati su regole” possono essere personalizzati per proporre (o attuare automaticamente) anche delle “reazioni” alle situazioni rilevate;
  • Si può sempre sapere quali “regole” che sono state applicate per arrivare alla segnalazione finale, dando a chi deve valutare la situazione, informazioni utili per capire “cosa è successo” prima di decidere le contromisure da adottare. Non tutte le tecniche di ML riescono invece a spiegare il “perché” il sistema di AI/ML fa le sue segnalazioni: ad esempio gli “alberi di decisione” possono elencare le “regole logiche” che sono state applicate, le Reti Neurali (e molti altri algoritmi) invece no; si può sapere che qualcosa è stato segnalato ma non perché il sistema di ML lo ha segnalato, quindi non si può verificare cosa è successo e capire perché é successo…;
  • I Sistemi Basati su Regole sono progettati anche per trovare correlazioni fra fatti diversi che avvengono in momenti diversi. Gli algoritmi di ML di solito sono addestrati a riconoscere un singolo fatto (e a classificarlo).

Gli scenari di analisi della sicurezza informatica sono per loro natura scenari in continua evoluzione e la difficoltà ad applicare tecniche di ML potrebbe risalire, in prima istanza, alla grande variabilità (ed eterogeneità) delle situazioni a cui gli algoritmi di ML dovrebbero continuamente adattarsi.

Il Penetration Test effettuato su HAPS ha dimostrato la necessità di addestrare gli algoritmi di ML con “casi” di attacchi allo stato-dell’arte (e non casi presi da dataset di benchmarking con dati vecchi di anni).

In pratica, introducendo nella architettura HAPS anche “sistemi basati su regole”, e considerando anche le loro segnalazioni al momento di fare una analisi complessiva della situazione, si può realizzare una architettura in grado di rispondere rapidamente alle minacce di nuovi attacchi, anche se il modello di ML non è ancora stato “addestrato” a riconoscerli. Questa soluzione in letteratura è considerata un sistema di AI “misto”.

Conclusioni

Per cercare di risolvere in modo strutturale il problema della difficoltà del “training continuo” dei sistemi basati su algoritmi di ML, si possono valutare approcci complementari al ML, ad esempio approcci basati sulla definizione di regole “euristiche” per identificare in modo più rapido (seppur meno flessibile) gli eventi tendenzialmente “negativi”, regole da applicare comunque in modo efficiente ed automatizzato alla analisi degli eventi effettivi.

L’approccio dei “Sistemi Esperti basati su regole” non è di per sé una novità anzi è già stato da tempo adottato con successo, ed implementato in strumenti consolidati e largamente diffusi, come ad esempio nei motori e filtri anti-spam, in grado di classificare i messaggi sulla base di modelli costruiti analizzando migliaia di messaggi sulla base di files di regole che stabiliscono i pattern da riconoscere ed interpretare.

Anche se gli algoritmi di apprendimento automatico, e più in generale l’intelligenza artificiale, avranno un ruolo importante nelle strategie e framework di sicurezza (e sono da molti considerati il futuro della sicurezza informatica), essi non sostituiranno (almeno nel breve-medio termine) gli esseri umani, il cui ruolo, contributo ed esperienza restano determinanti.

Si delinea piuttosto uno scenario di collaborazione tra “uomo e macchina”. Da un lato, il processo di apprendimento automatico richiede comunque la supervisione degli esperti per migliorare continuamente ed adattarsi a nuovi scenari. Dall’altro, la capacità di analisi degli umani è fondamentale sia per interpretare correttamente le minacce identificate automaticamente dai sistemi ed il livello di rischio effettivo, sia per decidere l’eventuale strategia di risposta più opportuna in uno specifico scenario.

Un approccio interamente basato sull’automazione è esso stesso potenziale fonte di vulnerabilità. È infatti importante sottolineare che gli attaccanti stessi sono a conoscenza degli algoritmi di apprendimento automatico e cercano da un lato di eluderne le capacità sfruttandone i limiti, e dall’altro di utilizzarli a loro vantaggio per elaborare nuove forme di attacco.

Per saperne di più sulle caratteristiche dei “Sistemi Esperti basati su Regole” e conoscere gli aspetti esperienziali della realizzazione di un’applicazione basata su Regole, come è stato appunto il caso di HAPS, rimandiamo alla terza e conclusiva parte del nostro approfondimento sul progetto.

Utilizziamo i cookie per essere sicuri che tu possa avere la migliore esperienza sul nostro sito. Se continui ad utilizzare questo sito noi assumiamo che tu ne sia felice.