Un modello integrato control-flow e data-flow per il rilevamento ...

3
Un modello che integra control
flow e data flow
L’execution graph e il modello data flow visti, a patto di eseguire correttamente il
training, se uniti costituiscono uno strumento molto potente per il rilevamento di
comportamenti anomali da parte del software che gira su un elaboratore. Il modello
costruito con questa tecnica rappresenta molto fedelmente e in modo molto sintetico
quello che è concesso e quello che non è concesso fare ad un programma. Tuttavia,
anche assumendo un training perfetto, vi sono situazioni in cui diventa impossibile
rilevare che il programma monitorato non sta facendo quello per cui è stato pensato.
La debolezza sorge dal fatto che l’accoppiamento del modello data flow con il modello
control flow è relativamente basso.
3.1 Debolezze dei modelli esistenti
Il software, come è noto, è costruito “a strati” e tipicamente le parti più basse pos-
sono essere richiamate da diverse parti che si collocano più in alto nell’architettura.
Ad esempio, un web server avrà del codice dedicato alla gestione dei log, codice
che viene richiamato dal codice che si occupa dell’autenticazione, da quello che si
occupa dell’interazione con i client e così via. Pensando ad un’ipotetica funzione
log event(), se questa viene chiamata dal codice di autenticazione provocherà la
scrittura nel log-file che un dato utente, ad esempio, ha immesso la password errata,
mentre se chiamata dal codice che interagisce con i client provocherà, ad esempio, la
scrittura di un messaggio che informa l’amministratore che un dato client ha inviato
una richiesta malformata. Le proprietà data flow apprese dal modello di [2] però
non saranno in grado di dire nulla di più di qualcosa come