0689178001

Il Progetto H.A.P.S.

storie_di_successo, tecnologie, Drools

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

  • d.barbato
  • Nessun commento

Caratteristiche dei “Sistemi Esperti” basati su Regole, esperienza sul progetto e conclusioni

I “Sistemi Esperti” sono sul mercato da molti anni (almeno dagli anni ‘90) e rappresentano un primo esempio di applicazioni dotate di “Intelligenza”. Diversamente dagli algoritmi di Machine Learning non hanno la capacità di imparare da soli (o quasi da soli…): nel caso dei sistemi RuleBased l’addestramento si riduce a definire una serie di “regole logiche” (scritte con un linguaggio specializzato) a cura di un Esperto di Dominio. L’intelligenza del programma è in pratica la codifica della esperienza dell’Esperto. Si potrebbe parlare di programmi che possono avere un loro “ragionamento automatico” piuttosto che una “intelligenza” vera e propria.

Nel progetto HAPS per realizzare il prototipo tecnologico (Proof-Of-Concept) del modulo di Analisi di Scenario, è stato impiegato il tool Drools Expert.

Drools è un progetto opensource di Red Hat su piattaforma Jboss, composto da:

  • Drools Expert, motore di esecuzione delle regole
  • Drools Fusion, ambiente open source per l’elaborazione di eventi basato su Java; gli eventi raccolti possono poi essere trattati eseguendo le regole di Drools Expert.

L’utilizzo di una piattaforma che gestisce flussi di dati in forma di eventi singoli è fondamentale per poter realizzare un sistema basato su regole, perché prima ancora di definire le regole vanno definiti i tipi di fatti (o eventi) a cui queste regole si applicheranno.

Ad esempio, questo è il formato per definire un “tipo di evento” con Drools

declare event_type_name
    // metadata
    @role( event )
    @timestamp( attribute_name )
    @duration( attribute_name )
    @expires( time_offset )
    // other metadata attributes
    // attributes
    attribute_name_1 : data_type [metadata_annotations]
    …..
    attribute_name_n : data_type [metadata_annotations]
end

In pratica si tratta della definizione di un record di informazioni relative ad un “fatto” di un certo tipo (event_type_name) avvenuto in un particolare momento (@timestamp), che ha una serie di “parametri” che regolano il suo trattamento (@expires determina dopo quanto tempo l’evento non sarà più utilizzabile dalle regole) e che ha delle precise caratteristiche (attributi e valori ammessi).

A livello di programmazione Java, gli eventi possono essere realizzati con oggetti di classi java elementari (POJO) che hanno come attributi proprio le caratteristiche dell’evento stesso.

Le regole sono scritte nel Drools Rules Language (drl), che è un linguaggio strutturato con una sintassi semplificata dovrebbe essere abbastanza intuitiva, e hanno questa forma generale:

rule rule_name
    < rule_attribute >
    when
    event_pattern // Left Hand Side (LHS)
    then
    actions // Right Hand Side (RHS)
end

Ad esempio, la regola che segue controlla se esiste nella WM un evento $I2 con specifiche caratteristiche ( stream, event presenti negli oggetti di classe NewLog, che definisce gli eventi inseriti nella WM) e, se esiste, inizia a preparare una segnalazione in output in forma di POJO (ResponseDTO), impostando alcuni parametri utili per ulteriori elaborazioni.

rule "log"
    when
    $l2 : NewLog( stream == "SNORT" && eventType == "DDOS" );
    then
    rdt.setEventType("DDOS");
    rdt.setAlarmLevel("ORANGE");
    rdt.setSecondsToCheck(15);
    rdt.setNeedOtherCheck(true);
    rdt.setMessage("found SNORT log of DDOS type");
end

Sembrano normali istruzioni tipo if-then-else di un qualunque linguaggio di programmazione, ma ci sono importanti differenze:

  • Le regole possono operare solo sugli eventi: le condizioni delle regole (event_pattern) devono essere espresse solo in termini di eventi e delle loro caratteristiche
  • Prima di far “scattare” le Regole, gli eventi devono essere inseriti in una area di memoria dinamica, chiamata Working Memory (WM). I criteri per creare l’insieme dei fatti da analizzare con le Regole, fanno parte della progettazione del sistema
  • Le regole sono scritte in un file esterno alla applicazione che le esegue: per cambiare la logica della Applicazione basta scrivere nuove regole e aggiornare il file .drl. Non va modificato il codice vero e proprio della applicazione o del “motore” che analizza le regole
  • Nei file .drl la sequenza con cui le regole sono scritte nei fogli .drl non definisce l’ordine con cui sono eseguite, è il “motore” che governa l’esecuzione delle Regole che sceglie quali regole applicare sulla base delle condizioni che si verificano dopo aver esaminato tutti gli eventi nella WM: per prima cosa si sceglie quali regole potrebbero “scattare” (perché la loro pre-condizione è soddisfatta) poi si decide in quale sequenza applicare le regole selezionate. Il processo di scelta dell’ordine in cui eseguire le regole è realizzato da una funzione di Drools chiamato Agenda.
  • Nel caso che esistano delle incertezze (“conflitti”) al momento di decidere quali regole attivare, la Agenda di Drools decide la sequenza con cui lanciare le regole, sulla base di:
    • Alcune strategie predefinite (LIFO, FIFO) in base all’ordine in cui le regole sono state dichiarate “pronte” per essere attivate;
    • Alcuni parametri che possono essere impostati al momento della definizione delle regole (ad es. @salience che può dare un peso, un priorità, una importanza specifica ad una regola)
  • Ogni regola attivata produce una action, che può essere qualunque cosa, la produzione di un Alert (come nel nostro caso) come istanza di una classe java POJO, oppure l’inserimento, la modifica, la cancellazione di un “fatto” nella WM: questa variazione può far scattare altre regole!

In sintesi, le “regole” non si comportano come “semplici” If perché quali regole eseguire (ed in quale sequenza) sono decisioni prese dal “motore” di Drools con sue regole di “ragionamento automatico”.

Come Sviluppare in Java una Applicazione “Basata su Regole”

Dal punto di vista realizzativo, per utilizzare Drools Expert, è necessario creare una applicazione ospite scritta in Java che può avere la architettura schematizzata come segue.

Riassumiamo gli step necessari per elaborare eventi con un Sistema Esperto Basato su Regole:

1. Acquisire gli eventi in input, anche da diverse fonti; formattare gli eventi secondo i “tipi” previsti

2. Inserire le istanze degli eventi che si vogliono analizzare nella “Working Memory” (WM) condivisa con il modulo Drools Expert . E’ conveniente anche inserire gli eventi “elementari” in un DB interno alla applicazione, per avere la possibilità di interrogare un log degli eventi trattati. La Applicazione è responsabile di decidere quando far partire l’analisi degli eventi (fireAllRules): si potrebbe chiedere l’analisi degli eventi per ogni nuovo evento in input, o solo dopo aver raccolto tutti gli eventi nati in un periodo di tempo prefissato o in una finestra temporale “scorrevole”.

3. Drools Expert (che è incluso nella Applicazione come un package java che rende disponibili le classi necessarie per trattare gli eventi) elabora gli eventi elementari (o “fatti”) presenti nella WM seguendo una procedura in tre step:

    • Seleziona le regole applicabili agli eventi nella WM, esaminando quali condizioni sono verificate dagli eventi nella WM
    • Decide le priorità / risolve i conflitti
    • Esegue le regole in sequenza, considerando che ogni regola potrebbe creare nuovi fatti nella WM che potrebbero far attivare nuove regole.

4. Al termine di un ciclo di elaborazione degli eventi nella WM, si possono pubblicare i risultati della elaborazione degli eventi. Si parla a questo punto di “eventi derivati”, che rappresentano i risultati della analisi comparativa effettuata da Drools Expert su tutto l’insieme degli eventi inseriti nella Working Memory.

Riprendere il ciclo dall’inizio, da step 1, su un nuovo set di eventi, risultato del progredire del tempo.

Esperienze dopo aver realizzato una Applicazione “Basata su Regole”

L’applicazione è un prototipo tecnologico del modulo di Analisi di Scenario di HAPS.

Esamina le segnalazioni di potenziali allarmi (che sono gli eventi di interesse per questo sistema) prodotte da diversi moduli di HAPS (modulo di AI/ML e Modulo IDS SNORT) e valuta il livello di allarme complessivo della situazione: se lo stesso tipo di attacco viene segnalato dai diversi moduli entro un breve lasso di tempo, il livello di allarme si alza perché l’attacco è “confermato”. Questo controllo viene ripetuto ad intervalli di tempo regolari su eventi compresi in una precisa “finestra temporale” per dare una visione dinamica di come varia livello di allarme.

Si può vedere una demo della applicazione realizzata, con una descrizione del codice sviluppato:

Per realizzare la logica di controllo del livello di allarme sono state utilizzate delle regole Drools, definite sugli eventi tipo segnalazioni di allarme prodotti da altri moduli di HAPS, simulando il flusso continuo e temporizzato di eventi che alimentano il modulo di analisi di scenario.

Uno degli scopi dello sviluppo del prototipo era valutare quanto sia possibile creare delle regole Drools solo sulla base della “conoscenza di una materia” (e non di regole di programmazione), e quanto le regole potessero effettivamente definite indipendentemente le une dalle altre, lasciando alla funzione di Agenda di Drools decidere quali regole attivare. Questa proprietà sarebbe estremamente utile per gestire lo sviluppo incrementale della base di regole.

All’atto pratico il linguaggio di definizione delle Regole si è dimostrata molto “compatto” (rispetto alla verbosità di java) e dispone di molte opzioni specifiche per trattare eventi e definire regole, ma si è dimostrato un linguaggio non molto intuitivo da utilizzare, perché:

  • “Compatto” non vuol dire semplice, la logica di concatenazione delle regole non è semplice da apprendere e le implicazioni degli “automatismi” che fanno scattare le regole devono essere ben comprese da chi scrive le regole stesse.
  • Bisogna avere una chiara comprensione di quale sia la architettura Java della Applicazione che “ospita” il package Drools Expert e di come si possa scrivere logica aggiuntiva in java per gestire gli input e gli output della elaborazione (che sono classi POJO)

Conclusioni

A questo punto l’esperienza dice che per definire correttamente una “regola per un Sistema Esperto”:

  • L’analisi può essere fatta da un “Esperto della Materia” a partire dalla definizione di “eventi” e “attributi degli Eventi”
  • La realizzazione deve essere lasciata ad un Developer Java-Drools specializzato.

Se siete interessati ad approfondire dal punto di vista tecnico la problematica dello sviluppo di applicazioni Drools in Java, ad esempio per sviluppare un prototipo per un caso di vs. interesse, potete contattare inviando un richiesta tramite il nostro form di contatto.

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.