IT201900017273A1 - Metodo per rendere sicuro un dispositivo elettronico - Google Patents

Description

Descrizione del trovato avente per titolo:

"METODO PER RENDERE SICURO UN DISPOSITIVO ELETTRONICO"

CAMPO DI APPLICAZIONE

Forme di realizzazione qui descritte si riferiscono ad un metodo e ad un apparato per rendere sicuro un dispositivo elettronico, che può essere impiegato nel campo della sicurezza informatica, per prevenire attacchi informatici e minacce informatiche di qualsiasi tipo effettuati contro dispositivi elettronici, ovvero malfunzionamenti strutturati o intervenuti nel tempo.

STATO DELLA TECNICA

Sono noti software per la sicurezza informatica per la rilevazione e rimozione di eventuali minacce informatiche che possono interessare dei dispositivi elettronici. In alcuni casi, le minacce informatiche possono comprendere pacchetti dati malevoli, che vengono trasmessi mediante una rete informatica, o anche mediante altri mezzi, come ad esempio dispositivi di archiviazione, a dei dispositivi elettronici ad essa connessi.

Ci sono anche casi di malfunzionamenti, provocati da fattori interni o esterni al dispositivo, bug o mancati aggiornamenti del software, che possono comprometterne il funzionamento.

Tali minacce informatiche, che quindi includono sia attacchi dolosi che malfunzionamenti, possono quindi interessare un grande numero ed un’ampia varietà di dispositivi elettronici, collegati in rete ad altri dispositivi, o meno.

In fig. 1 è schematicamente illustrata una possibile architettura software di un apparato informatico, che comprende un sistema operativo, memorizzato in una periferica di memorizzazione 102b e provvisto di vari componenti A software, come ad esempio programmi applicativi, ed uno o più programmi di gestione F, ad esempio firmware, memorizzati in delle unità di memorizzazione integrate 102a in delle periferiche hardware.

Un possibile attacco informatico ai danni di tale apparato informatico può ad esempio essere configurato come un pacchetto dati malevolo, che arriva dall’esterno dell’apparato, ad esempio da una rete informatica o anche da una chiavetta USB, che può essere trasmesso sia da un altro apparato che da un essere umano, come schematicamente illustrato in figura mediante frecce continue.

Danni all’apparato informatico possono anche essere causati da malfunzionamenti di uno o più componenti A, o del programma di gestione F, causati dai motivi più vari, ad esempio bug, mancati aggiornamenti software o aggiornamenti difettosi, difetti di produzione, che possono indurre comportamenti anomali e potenzialmente dannosi. L’attacco, o il malfunzionamento, una volta raggiunto il sistema operativo, lo infetta, ad esempio corrompendo un file, una cartella, dei registri, delle librerie di funzioni, un componente A, che quindi diventa un componente A infetto, indicato mediante campitura nelle figure.

Un componente A infetto può quindi essere un qualsiasi componente A dell’apparato, sia hardware che software, non operante in modo corretto e coerente con le finalità per cui è stato previsto.

Dal componente A infetto, l’attacco può infettare altri componenti A, accedere alle periferiche hardware, infettare i firmware, o anche propagarsi in una rete, ad esempio rete internet o LAN, infettando altri apparati ad essa collegati. Schematicamente, il funzionamento degli antivirus noti si basa sul confronto fra i dati associati all’attacco in arrivo sull’apparato informatico ed una pluralità di dati archiviati in un database di minacce.

Nel caso in cui i dati associati all’attacco risultino uguali ai dati archiviati, l’attacco viene riconosciuto come minaccia e viene bloccato prima che possa infettare i componenti A.

Tuttavia, antivirus basati su questa tipologia di funzionamento presentano l’inconveniente che nel caso in cui l’attacco sia di tipologia sconosciuta, e quindi i dati ad esso associati non siano presenti nel database o quest’ultimo non sia aggiornato, esso non viene riconosciuto dall’antivirus, ed infetta il sistema operativo.

Inoltre, antivirus basati su database, possono non riconoscere comportamenti dannosi causati da malfunzionamenti o anomalie di vario tipo, in quanto tali comportamenti possono non essere direttamente associati a dati archiviati come minacciosi.

Sono anche noti antivirus non basati su database, come ad esempio quello descritto nel documento brevettuale WO 2016/020660, che presentano degli algoritmi di intelligenza artificiale che confrontano il comportamento del sistema operativo, o di un suo componente, con un comportamento ideale, rilevando eventuali anomalie.

In questi casi, tuttavia, la rilevazione della minaccia avviene solo dopo che la minaccia ha raggiunto ed infettato almeno un componente A del sistema operativo, o comunque dopo che si sono presentate eventuali anomalie.

Trascorre quindi un certo periodo di tempo fra quando la minaccia attacca l’apparato informatico e quando viene riconosciuta e debellata, che, per quanto breve, può comunque consentire alla minaccia di apportare danni e diffondersi su altri apparati.

Un'altra tipologia di possibili minacce informatiche sono quelle schematicamente descritte mediante fig. 2.

Tali tipologie di minacce provengono dai programmi di gestione F dei componenti hardware e delle schede elettroniche dell’apparato.

Nel caso in cui sia il programma di gestione F ad essere infettato, o un qualsiasi firmware presente nell’hardware, risulta più difficile debellare la minaccia, in quanto detta potrebbe bypassare il sistema operativo ed effettuare danni senza che nessun antivirus noto possa intervenire.

Nei casi più gravi, il firmware infettato può essere un firmware di boot del dispositivo elettronico, ad esempio di tipologia UEFI (Unified Extensible Firmware Interface) o BIOS (Basic Input-Output System).

Il firmware UEFI o BIOS è tipicamente preinstallato nel dispositivo elettronico ed è il primo software ad essere eseguito all’avvio.

Inoltre, il firmware è utilizzato per l’inizializzazione dell’hardware e per fornire servizi specifici per il sistema operativo e gli applicativi, come schematicamente illustrato in figura mediante freccia tratteggiata.

In tali casi, al momento dell’accensione del computer, quando il sistema operativo, quindi anche eventuali antivirus ivi istallati, non è stato ancora caricato, il firmware di boot risulta l’unico componente attivo ed operativo dell’apparato, e, se eventualmente infetto, può agire indisturbato attuando qualsiasi tipologia di minacce, come schematicamente illustrato mediante frecce continue.

Esiste pertanto la necessità di perfezionare un sistema di sicurezza informatica che possa superare almeno uno degli inconvenienti della tecnica nota.

In particolare, uno scopo del presente trovato è quello di fornire un metodo per rendere sicuro il funzionamento di un dispositivo elettronico, sia esso connesso in rete o anche a sé stante, che sia più efficace degli antivirus noti, in particolare quelli basati su database, consentendo quindi di rilevare e prevenire anche minacce non archiviate in un database.

Un ulteriore scopo del presente trovato è quello di fornire un metodo in grado di superare gli inconvenienti degli antivirus noti, in particolare quelli basati sul sistema di rilevamento di anomalie, consentendo di rilevare e prevenire le minacce prima che esse possano generare le anomalie e mettere in atto comportamenti dannosi.

Un ulteriore scopo del presente trovato è quello di fornire un metodo in grado di rilevare e prevenire anche minacce provenienti da firmware installati nei componenti hardware di un dispositivo elettronico.

E anche uno scopo quello di intercettare e debellare, fin dall’avvio del dispositivo elettronico, eventuali comportamenti malevoli, anomali e, in generale, dannosi, che possono insorgere per vari motivi.

In particolare, è anche uno scopo del presente trovato quello di fornire un metodo in grado di rilevare e prevenire minacce che possono essere attuate nelle fasi di accensione del dispositivo elettronico, prima che venga caricato il sistema operativo, ed eventuali antivirus ivi installati.

È anche uno scopo quello di rendere sicuri dispositivi elettronici connessi in rete, intervenendo sul dispositivo sia direttamente, dall’ interno, che indirettamente, dall’esterno, mediante altri dispositivi ad esso connessi.

E anche uno scopo quello di rendere sicuri dispositivi elettronici a sé stanti, non connessi in rete, rilevando sia attacchi che eventuali malfunzionamenti interni.

Per ovviare agli inconvenienti della tecnica nota e per ottenere questi ed ulteriori scopi e vantaggi, la Richiedente ha studiato, sperimentato e realizzato il presente trovato.

ESPOSIZIONE DEL TROVATO

Il presente trovato è espresso e caratterizzato nella rivendicazione indipendente. Le rivendicazioni dipendenti espongono altre caratteristiche del presente trovato o varianti dell’idea di soluzione principale.

In accordo con i suddetti scopi, forme di realizzazione qui descritte si riferiscono ad un metodo per rendere sicuro il funzionamento di un dispositivo elettronico, che supera i limiti della tecnica nota ed elimina i difetti in essa presenti.

In forme di realizzazione, il metodo prevede una fase di archiviazione iniziale di dati empirici di partenza noti, in cui a ciascuno dei dati empirici di partenza viene assegnata una probabilità che sia dannoso o sicuro, cioè che sia associato o meno ad una minaccia informatica.

In forme di realizzazione, il metodo prevede un’operazione di destrutturazione dei dati empirici in porzioni di dato progressivamente più piccole.

In forme di realizzazione, il metodo prevede un’operazione di ricombinazione di ciascuna delle porzioni di dati empirici con tutti o parte i dati empirici e con tutte o parte le altre porzioni di dati, ottenendo così dei nuovi dati, cioè dei dati ricombinati, diversi dai dati di partenza.

In forme di realizzazione, il metodo prevede un’operazione di assegnazione ai nuovi dati di probabilità che essi siano sicuri o dannosi, mediante tecniche di statistica Bayesiana, a partire dalle probabilità assegnate ai dati empirici di partenza.

Il metodo prevede quindi di confrontare un nuovo input con i dati empirici e con i nuovi dati, per valutarne la similarità ed assegnare, in funzione della valutazione di similarità, una probabilità che l’input sia dannoso o sicuro, ovvero che sia associato o meno ad una minaccia informatica.

La probabilità viene assegnata a partire dalle probabilità assegnate ai dati empirici e ai nuovi dati, mediante tecniche di statistica Bayesiana.

Vantaggiosamente, il metodo del presente trovato consente quindi di superare gli inconvenienti della tecnica nota, in quanto, mediante destrutturazione e ricombinazione dei dati, consente di prevedere anche possibili nuove minacce informatiche, comportamenti anomali, malfunzionamenti, completamente sconosciuti e/o non archiviati.

Vantaggiosamente, il metodo del presente trovato può essere impiegato per rendere sicuri sia dispositivi connessi in rete che dispositivi a sé stanti.

Vantaggiosamente, il metodo consente inoltre di rilevare e prevenire sia minacce associate al sistema operativo, o ad uno dei suoi componenti, che minacce associate a periferiche hardware o relativi programmi di gestione.

In ulteriori forme di realizzazione, il metodo può rendere sicuro un dispositivo elettronico provvisto di una scheda elettronica ed una o più unità periferiche connesse o integrate con detta scheda elettronica.

In forme di realizzazione, sulla scheda elettronica è prevista un’unità di memorizzazione integrata, in cui è memorizzato un programma di gestione, che, quando eseguito, gestisce il funzionamento della scheda elettronica e delle unità periferiche, mediante un set di istruzioni di gestione.

In forme di realizzazione il metodo prevede:

- creazione di una lista di istruzioni dannose eseguibili dal programma di gestione; - memorizzazione di un programma di sicurezza nell’unità di memorizzazione integrata;

- controllo, in cui il programma di sicurezza controlla il funzionamento del programma di gestione, bloccando l’esecuzione delle istruzioni dannose e consentendo l’esecuzione delle istruzioni di gestione.

In forme di realizzazione, il programma di gestione può essere un firmware, ad esempio un firmware di boot di tipologia UEFI o BIOS, che gestisce l’avvio di un sistema operativo.

Il metodo può quindi essere impiegato sia per la protezione di dispositivi elettronici non provvisti di sistema operativo, come ad esempio dispositivi diagnostici biomedicali, o dispositivi basati su firmware, che per la protezione di dispositivi elettronici provvisti di sistema operativo, nelle fasi di avvio, in cui il sistema operativo non è ancora stato caricato.

Vantaggiosamente, tale soluzione consente di superare gli inconvenienti della tecnica nota legati a possibili minacce informatiche provenienti da firmware infetti. Il metodo del presente trovato risulta quindi più efficiente rispetto ai metodi noti, nel rilevare minacce informatiche a dispositivi elettronici.

ILLUSTRAZIONE DEI DISEGNI

Questi ed altri aspetti, caratteristiche e vantaggi del presente trovato appariranno chiari dalla seguente descrizione di forme di realizzazione, fomite a titolo esemplificativo, non limitativo, con riferimento agli annessi disegni in cui:

- le figg. 1 e 2 illustrano due possibili tipologie di minacce informatiche che possono essere effettuate contro un dispositivo elettronico;

- le figg. 3-6 illustrano il funzionamento di un programma basato un metodo in accordo con forme di realizzazione qui descritte;

- le figg. 7-9 illustrano possibili dispositivi elettronici in cui è presente un programma basato su un metodo in accordo con forme di realizzazione qui descritte;

- le figg. 10-14 illustrano possibili fasi di un metodo in accordo con forme di realizzazione qui descritte;

- tabb. 1-2 e fig. 15 illustrano possibili esempi di esecuzione di alcune fasi di un metodo in accordo con forme di realizzazione qui descritte.

Per facilitare la comprensione, numeri di riferimento identici sono stati utilizzati, ove possibile, per identificare elementi comuni identici nelle figure. Va inteso che elementi e caratteristiche di una forma di realizzazione possono essere convenientemente incorporati in altre forme di realizzazione senza ulteriori precisazioni.

DESCRIZIONE DI FORME DI REALIZZAZIONE

Si farà ora riferimento nel dettaglio alle possibili forme di realizzazione del trovato, delle quali uno o più esempi sono illustrati nelle figure allegate. Ciascun esempio è fornito a titolo di illustrazione del trovato e non è inteso come una limitazione dello stesso. Ad esempio, una o più caratteristiche illustrate o descritte, in quanto facenti parte di una forma di realizzazione, potranno essere variate o adottate su, o in associazione con, altre forme di realizzazione per produrre ulteriori forme di realizzazione. Resta inteso che il presente trovato sarà comprensivo di tali possibili modifiche e varianti.

Prima di descrivere le forme di realizzazione, si chiarisce, inoltre, che la presente descrizione non è limitata nella sua applicazione ai dettagli costruttivi, di disposizione dei componenti e di schematizzazione delle fasi del metodo come descritti nella seguente descrizione utilizzando le figure allegate. La presente descrizione può prevedere altre forme di realizzazione ed essere realizzata o messa in pratica in altri svariati modi. Inoltre, si chiarisce che la fraseologia e terminologia qui utilizzata è a fini descrittivi e non deve essere considerata come limitante.

Il presente trovato si riferisce ad un metodo per rendere sicuro il funzionamento di un dispositivo elettronico 100, prevenendo possibili minacce informatiche.

Il dispositivo elettronico 100 può essere connesso ad una rete informatica o meno, dotato di un sistema operativo o meno.

Una minaccia informatica può comprendere un qualsiasi tipo di azione, operata mediante dispositivi elettronici 100, che può, anche solo potenzialmente, apportare un danno, inteso sia come danno ad un dispositivo, ad esempio compromissione del funzionamento, che danno ad un utente, ad esempio furto di denaro, furto di dati personali, violazione della privacy di qualsiasi tipo.

La minaccia informatica può ad esempio comprendere cyber attacchi, phishing, mail truffa, virus, malware, ransomware, spyware, rootkit, backdoor, ed altro ancora. La minaccia informatica può essere operata sia da una persona fisica, ad esempio un hacker, che da dispositivi provvisti di software o malware configurati a tal fine. Una minaccia informatica può anche comprendere malfunzionamenti di qualsiasi tipo associati ad un dispositivo elettronico 100, ad esempio legati ad un componente software o hardware, ad esempio dovuti a bug, cortocircuiti, mancati aggiornamenti software o aggiornamenti difettosi.

La minaccia informatica può comprendere dei dati, ad esempio file, internamente processati dal dispositivo elettronico 100 o da esso inviati/ricevuti verso/da altri dispositivi.

La minaccia informatica può anche comprendere comportamenti messi in atto dal dispositivo elettronico 100, ad esempio nel caso di applicativi infetti con malware o malfunzionamenti a livello hardware e/o software.

La minaccia informatica può comprendere anche comportamenti messi in atto da un soggetto umano, come un utente del dispositivo elettronico 100, ad esempio nel caso di phishing informatico, o un hacker, ad esempio nel caso di apertura di backdoors.

I dati possono comprendere file in formati noti, come ad esempio .pdf, .doc, .docx, .xls, .xml, .png, .jpg, .jpeg, ,mp4, ,mp3, .dii, .bat, .msg, .exe, script di shell unix come .bash, .tcsh, .sh, .csh, o anche altri ancora.

I comportamenti possono ad esempio comprendere:

- invio/ricezione di email;

- scambio di file, sia mediante email che mediante protocolli di rete come ftp, sftp, vpn;

- accesso a siti internet o a dispositivi di rete, ad esempio mediante browser o ssh, ftp, sftp, vpn:

- installazione/rimozione di software o firmware, sia manuale, operata da un utente, che automatica, operata da programmi;

- esecuzione di applicazioni o di file eseguibili;

- navigazione su internet.

La navigazione su internet può comprendere innumerevoli azioni associate al web, come click su link presenti in pagine web, esecuzione di file multimediali da pagine web, apertura/chiusura di nuove finestre di navigazione, accesso ad applicazioni sensibili, come ad esempio home banking, o pagamenti online, o acquisti online, app collegate a servizi trasporti, prenotazioni di alberghi o altro, registrazioni a dei siti che prevedono l’immissione di dati personali, esecuzione di applicazioni o script, navigazione di zone del web non consentite o non indicizzate, ad esempio dark web. I comportamenti associati ai dispositivi elettronici 100 possono sempre essere caratterizzati da dei dati alfanumerici rappresentativi del funzionamento, come stringhe e parametri operativi, che ne consentono la processabilità.

Qualsiasi minaccia informatica può quindi essere associata ad un input, cioè un pacchetto dati, sia associato a file che a comportamenti, che viene ricevuto o rilevato dal dispositivo elettronico 100.

A differenza degli antivirus basati su database, il metodo del presente trovato consente di prevenire anche minacce informatiche associate ad input ignoti, non contenuti in nessun database o mai rilevati in precedenza, mediante l’uso di un sistema dinamico, il cui funzionamento si basa su delle operazioni di destrutturazione e ricombinazione di dati ed assegnazione di probabilità.

In forme di realizzazione, il sistema dinamico contiene tutti i dati a cui il metodo fa riferimento.

In forme di realizzazione schematicamente descritte mediante fig. 10, il metodo 10 prevede una fase 11 di generazione del sistema dinamico.

Con riferimento a fig. 11, la fase 11 di generazione del sistema dinamico può prevedere una fase Ila di archiviazione iniziale di una pluralità di dati empirici di partenza, noti per essere sicuri o dannosi.

I dati empirici possono comprendere pacchetti dati rappresentativi di una minaccia informatica, e possono comprendere sia dati associati a file che dati associati a comportamenti.

Ad esempio, possibili dati empirici possono comprendere file o porzioni di file, o una o più stringhe contenute in un file.

Ad esempio, possibili dati empirici associati ad un comportamento possono comprendere una tipologia di azioni effettuate, ad esempio apertura di una porta hardware o software, uso delle risorse CPU o RAM, download/upload di file, numero di tentativi di inserimento di username e password, connessione ad un host, determinate tipologie di applicazioni che vengono aperte dal sistema operativo, connessione ad un provider di servizi email, operazioni di click su hyperlink, inserimento di testo, dell’oggetto di una mail o di eventuali allegati.

In forme di realizzazione, a ciascun dato empirico può essere assegnata una probabilità che sia sicuro, cioè non associato ad una minaccia informatica, o dannoso, cioè associato ad una minaccia informatica.

Tale probabilità, anche detta livello di fiducia, può essere associata alla definizione di probabilità della statistica Bayesiana.

In forme di realizzazione, i livelli di fiducia possono comprendere livelli di fiducia a priori, o probabilità a priori, che corrispondono al livello di fiducia per l’ipotesi che il dato sia dannoso o sicuro.

In forme di realizzazione, i livelli di fiducia a priori possono essere impiegati per il calcolo di livelli di fiducia a posteriori, o probabilità a posteriori, all’interno di procedure di calcolo di statistica Bayesiana.

Ad esempio, quando si ha a disposizione un nuovo dato, è possibile verificarne la similarità con dei dati noti e, a partire dai livelli di fiducia a priori assegnati ai dati noti, calcolare il livello di fiducia a posteriori per l’ipotesi in cui il nuovo dato sia sicuro o dannoso, mediante il teorema di Bayes e la formula di calcolo della probabilità Bayesiana.

Ad esempio, la probabilità a posteriori, PXY, che si verifichi un’ipotesi X, una volta che è stata verificata l’ipotesi Y, può essere calcolata, in base al teorema di Bayes, come

dove P(X) è la probabilità a priori che si verifichi l’ipotesi X, P(Y) è la probabilità a priori si verifichi l’ipotesi Y, P(X|Y) è la probabilità a posteriori che si verifichi l’ipotesi X, dopo che si è verificata l’ipotesi Y, P(Y|X) è una funzione di verosimiglianza (likelihood) fra le ipotesi X e Y.

In forme di realizzazione, l’ipotesi X può essere un’ipotesi che un certo dato x, sia sicuro (o dannoso), a cui può essere associata una probabilità a priori P(X).

In forme di realizzazione, l’ipotesi Y può essere un’ipotesi che un certo dato y sia sicuro (o dannoso), a cui può essere associata una probabilità a priori P(Y).

In forme di realizzazione, la funzione di verosimiglianza, P(Y|X), può essere calcolata mediante una valutazione di verosimiglianza fra le due ipotesi X e Y, ad esempio mediante una valutazione di similarità fra i dati x e y.

In forme di realizzazione, la similarità può essere ad esempio verificata mediante confronto tra file, o tra porzioni di file, o tra stringhe, o mediante confronto fra i parametri di esecuzione associati a due azioni, nel caso di comportamenti.

Ad esempio è possibile confrontare la quantità di caratteri uguali fra due stringhe o fra i parametri di utilizzo della CPU, e/o della RAM, o il numero di richieste di connessioni a indirizzi IP, nel caso di due azioni.

In forme di realizzazione possono essere impiegate funzioni di similarità, come ad esempio coseno di similarità.

La probabilità a posteriori P(X|Y), o livello di fiducia a posteriori, può quindi essere associata, ad esempio, alla probabilità che un certo dato x sia sicuro (ipotesi X), sapendo che un dato y è sicuro (l’ipotesi Y), una volta verificata similarità P(Y|X) fra i due dati x e y.

In forme di realizzazione, la probabilità a posteriori può essere calcolata apportando modifiche alla formula sopra indicata, ad esempio si potrà utilizzare una funzione modificata di P’XY, ottenuta operando sulla P(X|Y) mediante una funzione f, come di seguito:

E’ anche individuabile l’uso di un’ulteriore funzione modificata, P”XY, ottenuta modificando, mediante una funzione g, le relazioni fra le variabili P(X), P(Y), P(X[Y), P(Y|X), come di seguito:

Ad esempio, la funzione f e g possono moltiplicare ciascuna variabile per uno o più parametri.

In forme di realizzazione, le probabilità a posteriori possono essere utilizzate per migliorare la stima delle probabilità a priori e delle funzioni di verosimiglianza, in maniera autoconsistente.

In forme di realizzazione, i livelli di fiducia possono essere sia assegnati manualmente dall’utente, o dal programmatore del software, che automaticamente dal software stesso.

In forme di realizzazione, i livelli di fiducia possono essere stimati ed in seguito modificati e migliorati, sulla base di osservazioni ed eventi che si verificano in fase di funzionamento del software.

In forme di realizzazione, i livelli di fiducia possono essere numeri reali, eventualmente compresi fra 0 e 1, in cui 1 indica che l’ipotesi è certa, cioè il dato è sicuramente dannoso o sicuro, e 0 indica che l’ipotesi è inattendibile, cioè non è possibile determinare se il dato è sicuro o dannoso.

I dati empirici, sulla base dei rispettivi livelli di fiducia, vengono archiviati in due sottosistemi P e Q del sistema dinamico: il sottosistema P comprende i dati noti per essere sicuri, o dati noti sicuri, mentre il sottosistema Q comprende i dati noti per essere dannosi, o dati noti dannosi.

In forme di realizzazione, la generazione del sistema dinamico può prevedere una o più fasi 11 b di elaborazione, in cui ciascun dato contenuto nei due sottosistemi P e Q può essere destrutturato in porzioni di dato progressivamente più piccole, per creare una pluralità di dati destrutturati, a cui vengono assegnati rispettivi livelli di fiducia. In particolare, con riferimento a fig. 12, un dato empirico può essere ricorsivamente destrutturato in porzioni di dato, e ciascuna porzione di dato può essere ulteriormente destrutturata in porzioni elementari, a cui è ancora possibile associare un significato e non ulteriormente destrutturabili.

La destrutturazione può essere eseguita ricorsivamente, fino ad isolare le porzioni di dato elementari.

I dati ottenuti mediante destrutturazione dei dati empirici possono essere complessivamente indicati come dati destrutturati.

In forme di realizzazione, i dati destrutturati ereditano i livelli di fiducia dei dati empirici da cui sono ottenuti.

In altre forme di realizzazione, il livello di fiducia di un dato empirico viene diviso fra tutti i dati destrutturati da esso ottenuti, ad esempio un dato empirico a cui è associato un livello di fiducia a priori pari a 1 per l’ipotesi in cui sia sicuro, può essere destrutturato in N dati destrutturati, ciascuno avente livello di fiducia a priori 1/N per l’ipotesi in cui sia sicuro.

In forme di realizzazione, sulla base dei rispettivi livelli di fiducia, i dati destrutturati possono essere ritenuti sicuri e venire aggiunti ai dati noti sicuri contenuti nel sottosistema P, oppure possono essere ritenuti dannosi e venire aggiunti ai dati noti dannosi contenuti nel sottosistema Q.

Con riferimento a fig. 11, la generazione del sistema dinamico può prevedere una o più fasi 1 le di espansione del sistema dinamico, in cui i dati, sia dati empirici che dati destrutturati, possono essere ricombinati fra loro, per creare una pluralità di dati nuovi ricombinati, a cui vengono associati rispettivi livelli di fiducia.

I dati ricombinati risultano così diversi e nuovi sia rispetto ai dati empirici che rispeto ai dati destruturati.

In fig. 12 è esemplificativamente illustrata una possibile operazione di ricombinazione prevista nella fase 1 le di espansione del sistema dinamico.

Nella seguente tabella sono esemplificativamente ricapitolate alcune tipologie di dati che possono essere definite mediante le operazioni di destruturazione e ricombinazione dei dati empirici:

Esempi pratici di possibili destrutturazioni e ricombinazioni di dati sono riportati più in detaglio negli ESEMPI alla fine della presente descrizione, anche con riferimento alle Tabelle 1, 2 e fig. 15.

In forme di realizzazione, è possibile combinare matematicamente livelli di fiducia associati ai dati empirici o ai dati destrutturati per assegnare i livelli di fiducia ai dati ricombinati da essi otenuti, ad esempio mediante operazioni di somma, media, media pesata, norma.

In forme di realizzazione, ai nuovi dati vengono assegnate delle probabilità che siano sicuri o dannosi, mediante tecniche di statistica Bayesiana, a partire dalle probabilità assegnate ai dati empirici di partenza.

In forme di realizzazione, le probabilità per i nuovi dati possono essere determinate o aggiornate usando sia la formula di calcolo di probabilità di Bayes nota (Ρχγ), che le formule modificate (P’XY, P”XY).

In forme di realizzazione, i livelli di fiducia dei dati nuovi possono essere determinati o aggiornati mediante algoritmi di stima ricorsiva Bayesiana, ad esempio minimizzando il valore atteso di una probabilità a posteriori (o funzione di perdita) e/o, equivalentemente, massimizzando il valore atteso di una probabilità a priori (o funzione utilità).

In forme di realizzazione, può essere usata, come funzione di perdita e/o funzione di utilità, una funzione di errore quadratico medio.

In forme di realizzazione, i livelli di fiducia dei dati nuovi possono essere determinati o aggiornati mediante algoritmi di inferenza Bayesiana, in particolare inferendo la pericolosità di un certo dato sulla base di osservazioni precedenti.

In forme di realizzazione, i livelli di fiducia dei dati nuovi possono essere determinati o aggiornati mediante algoritmi ed equazioni di filtro Bayesiano.

In forme di realizzazione, i livelli di fiducia dei dati nuovi possono essere determinati o aggiornati impiegando intelligenza artificiale.

In forme di realizzazione, i livelli di fiducia possono essere migliorati con l’inserimento di nuovi dati o con l’osservazione di nuovi eventi, mediante apprendimento automatico.

Possibili algoritmi di apprendimento automatico possono comprendere algoritmi di apprendimento non supervisionato, ad esempio clustering partizionale, apprendimento mediante regole di associazione, algoritmo K-means, e algoritmi di apprendimento supervisionato, ad esempio apprendimento per rinforzo, che impiega una funzione di ricompensa basata sulla valutazione delle proprie prestazioni.

In forme di realizzazione la fase 11 di generazione del sistema dinamico può prevedere una o più fasi 11 d di archiviazione finale, in cui, sulla base dei rispettivi livelli di fiducia, i dati nuovi possono essere archiviati in due sottosistemi del sistema dinamico, in particolare un sottosistema S, contenente dati nuovi ritenuti sicuri, o dati nuovi sicuri, e un sottosistema T, contenente dati nuovi ritenuti dannosi, o dati nuovi dannosi.

In particolare, può essere valutata la similarità fra i dati nuovi e i dati presenti nei sottosistemi P e Q, associando rispettivi livelli di fiducia alle ipotesi in cui i dati nuovi siano dannosi o sicuri.

I dati nuovi che risultano simili ai dati contenuti nel sottosistema P, vengono archiviati nel sottosistema S, mentre i dati nuovi che risultano simili ai dati contenuti nel sottosistema Q, vengono archiviati nel sottosistema T, aggiornando così i sottosistemi S e T del sistema dinamico.

Il sistema dinamico così generato comprende quindi l’unione dei quattro sottosistemi P, Q, S, T, associati rispettivamente a dati noti sicuri, dati noti dannosi, dati nuovi sicuri, dati nuovi dannosi, che a loro volta comprendono dati empirici, dati destrutturati e dati ricombinati.

In forme di realizzazione, le fasi 11b, 11c e 11d possono essere eseguite ricorsivamente, come indicato dalle frecce in fig. 11 , per destrutturare e ricombinare i dati di ciascun sottosistema in tutte le combinazioni possibili.

In particolare, ogni qual volta viene generato un dato destrutturato nella fase 11b, esso può essere ricombinato con tutti gli altri dati presenti in tutti i sottosistemi P, Q, S, T, e ogni qual volta viene generato un nuovo dato ricombinato nella fase 11 c, esso può essere direttamente ricombinato, o destrutturato e poi ricombinato, con tutti gli altri dati presenti in tutti i sottosistemi P, Q, S, T.

Risulta ovvio all’esperto del settore che una, o più, o tutte le fasi 11a, 11b, 11c, 11d qui descritte per generare il sistema dinamico possono essere effettuate o ripetute, anche in una sequenza diversa da quella qui descritta, ogni qual volta si desideri aggiungere uno o più nuovi dati ad uno o più dei sottosistemi P, Q, S, T.

La generazione del sistema dinamico può quindi essere intesa sia nel senso di creare un nuovo sistema dinamico, che, come riportato in seguito, di aggiornare un sistema dinamico già esistente aggiungendo dati nuovi.

Risulta ovvio per l’esperto del settore che il sistema dinamico, in particolare i dati, empirici, destrutturati e ricombinati, possono sia essere salvati su un’unità di memorizzazione 102 permanente, ad esempio in un file su HD o SSD, che ricalcolati ogni volta che servono e resi temporaneamente disponibili in RAM.

In forme di realizzazione, i dati possono essere salvati in unità di memorizzazione 102 e resi accessibili in remoto, ad esempio disponibili in rete, in particolare in cloud. Risulta anche ovvio che è anche possibile generare solo i dati destrutturati e ricombinati che servono volta per volta, in modo tale da contenere l’impiego di risorse computazionali richieste dal software.

Salvare i dati su disco, mantenerli in RAM, o ricalcolarli all’ occorrenza, possono costituire varianti del metodo non alternative fra loro, che possono dipendere dalla particolare implementazione e che possono essere scelte all’occorrenza, ad esempio in base alla potenza del processore, alla quantità di RAM e di memoria disponibili, al carico di lavoro in esecuzione sul dispositivo elettronico 100.

Il metodo 10 del presente trovato può quindi rendere sicuro il funzionamento di un dispositivo elettronico 100 mediante l’impiego del sistema dinamico così generato. In forme di realizzazione schematicamente descritte mediante fig. 10, il metodo prevede una fase 12 di rilevazione di un input, che potrebbe eventualmente essere associato ad una minaccia informatica.

Il nuovo input rilevato viene confrontato con i dati empirici e i nuovi dati, per valutarne la similarità ed assegnare una probabilità che esso sia sicuro o dannoso, mediante le tecniche di statistica Bayesiana, a partire dalle probabilità assegnate ai dati empirici e ai nuovi dati.

In particolare, in forme di realizzazione, il metodo 10 può prevedere una fase 13 di confronto fra l’input e i dati noti sicuri e noti dannosi contenuti nei sottosistemi P e Q. Con riferimento a fig. 13, la fase 13 di confronto può prevedere un’operazione 13a in cui viene controllato se l’input rilevato è presente nel sottosistema P del sistema dinamico.

In caso affermativo, l’input viene identificato come sicuro ed eseguito (operazione 13b).

In caso negativo, si controlla (operazione 13c) se l’input rilevato è presente nel sottosistema Q del sistema dinamico.

In caso affermativo, l’input viene identificato come dannoso e bloccato (operazione 13f).

In caso negativo, si verifica (operazione 13d) la similarità fra l’input e i dati noti sicuri presenti nel sottosistema P, associando un livello di fiducia a posteriori all’ipotesi in cui l’input sia sicuro rispetto ai dati noti.

Se il livello di fiducia a posteriori dell’ipotesi in cui l’input sia sicuro rispetto ai dati noti è superiore ad una prima soglia di fiducia, i dati associati all’input vengono archiviati nel sottosistema S (operazione 13e) e l’input viene considerato sicuro ed eseguito (operazione 13b).

In caso contrario, si verifica (operazione 13g) la similarità fra l’input e i dati presenti nel sottosistema Q, associando un livello di fiducia a posteriori all’ipotesi in cui l’input sia dannoso rispetto ai dati noti.

Se il livello di fiducia a posteriori dell’ipotesi in cui l’input sia dannoso rispetto ai dati noti è superiore ad una prima soglia di fiducia, i dati associati all’input vengono archiviati nel sottosistema T (operazione 13h) e l’input viene considerato dannoso e bloccato (operazione 13f).

In caso contrario, il metodo 10 può prevedere una fase 14 di aggiornamento del sistema dinamico, in cui il sistema dinamico, in particolare i sottosistemi S e T, viene aggiornato con i nuovi dati associati all’input, secondo le modalità precedentemente descritte con riferimento a fig. 11 per la fase 11 di generazione del sistema dinamico. In particolare, l’input può essere archiviato (fase 11a), assegnando un livello di fiducia, o probabilità, che sia sicuro o dannoso, ed in seguito elaborato (fase 11 b), mediante destrutturazione in porzioni progressivamente più piccole.

È quindi possibile espandere (fase 11c) il sistema dinamico ricombinando le porzioni dell’input, o l’input stesso, con i dati ivi presenti, ottenendo così nuovi dati, a cui vengono assegnate probabilità che siano sicuri o dannosi, mediante le metodologie precedentemente illustrate.

Nella fase 11d di archiviazione finale, il sottosistema S di dati nuovi sicuri e il sottosistema T di dati nuovi dannosi vengono aggiornati con i nuovi dati ottenuti dall’input.

In forme di realizzazione schematicamente descritte mediante fig. 10, il metodo 10 può prevedere una fase 15 di valutazione in cui il nuovo input viene confrontato con i dati nuovi sicuri e i dati nuovi dannosi aggiornati nel sistema dinamico, per assegnare una probabilità che esso sia sicuro o dannoso.

In forme di realizzazione schematicamente descritte mediante fig. 14, nella fase 15 di valutazione viene controllato (operazione 15a) se il livello di fiducia dell’ipotesi in cui l’input sia sicuro rispetto ai dati noti sicuri, contenuti nel sottosistema P, è superiore ad una seconda soglia di fiducia.

In caso affermativo, viene verificato se il livello di fiducia dell’ipotesi in cui l’input sia sicuro rispetto ai dati nuovi sicuri, contenuti nel sottosistema S, è superiore alla prima soglia di fiducia (operazione 15b).

In caso affermativo, l’input viene ritenuto sicuro ed eseguito (operazione 13b).

In caso negativo, viene verificato se il livello di fiducia dell’ipotesi in cui l’input sia sicuro rispetto ai dati nuovi sicuri, è superiore alla seconda soglia di fiducia (operazione 15f).

In caso affermativo, l’input viene aggiunto al sottosistema S (operazione 13 e), ritenuto sicuro ed eseguito (operazione 13b).

In caso negativo, l’input viene eseguito su una macchina virtuale per verificarne la pericolosità (operazione 15e).

Se il livello di fiducia dell’ipotesi in cui l’input sia sicuro rispetto ai dati noti è inferiore alla seconda soglia di fiducia (operazione 15a), viene verificato se il livello di fiducia dell’ipotesi in cui l’input sia dannoso rispetto ai dati noti dannosi, contenuti nel sottosistema Q, è superiore alla seconda soglia di fiducia.

In caso negativo, l’input viene eseguito su una macchina virtuale per verificarne la pericolosità (operazione 15e).

In caso affermativo, viene verificato (operazione 15d) se il livello di fiducia dell’ipotesi che l’input sia dannoso rispetto ai dati nuovi dannosi, contenuti nel sottosistema T, è superiore alla seconda soglia di fiducia.

In caso affermativo, i dati associati all’input vengono archiviati nel sottosistema T (operazione 13h) e l’input viene considerato dannoso e bloccato (operazione 13f)..

In caso negativo, l’input viene eseguito su una macchina virtuale per verificarne la pericolosità (operazione 15e).

Durante l’esecuzione dell’input sulla macchina virtuale (operazione 15e) può essere verificata esplicitamente la pericolosità dell’input e quindi, a seconda del risultato, i dati dell’input possono essere archiviati nel sottosistema S (operazione 13e) o T (operazione 13h), e l’input può essere ritenuto sicuro ed eseguito (operazione 13b) o dannoso e bloccato (operazione 13f).

In forme di realizzazione, la prima soglia di fiducia può essere compresa fra 0,5 e 0,9999, in particolare fra 0,8 e 0,9999, ancora più in particolare fra 0,9999 e 0,90, ad esempio 0,98.

In forme di realizzazione, la seconda soglia di fiducia può essere compresa fra 0,4 e 0,8, in particolare fra 0,5 e 0,7, ancora più in particolare fra 0,55 e 0,65, ad esempio 0,6.

Il metodo del presente trovato, a differenza di metodi noti basati su database, non si limita quindi a confrontare l’input di una minaccia con un database o archivio di minacce note o con dei comportamenti ideali, ma, sulla base delle minacce note, genera delle ipotesi di nuove minacce informatiche a cui vengono associati dei livelli di fiducia, e che vengono confrontate con l’input.

Forme di realizzazione descritte mediante figg. 3, 4, 5, 6, 7, 8 si riferiscono ad un programma PA, PS per dispositivo elettronico 100, per rendere sicuro il funzionamento del dispositivo elettronico 100 su cui è installato, o anche di altri dispositivi o componenti hardware.

Il programma PA, PS è memorizzabile in un mezzo leggibile da un dispositivo elettronico 100, ad esempio un’unità di memorizzazione 102, e contiene istruzioni che, una volta eseguite, determinano l’esecuzione del metodo 10 qui descritto.

Con riferimento a fig. 4, il programma PA, PS può comprendere un programma applicativo PA, che può essere installato in un sistema operativo di un dispositivo elettronico 100, ad esempio un computer, per prevenire minacce informatiche, come illustrato mediante doppia linea continua, ad esempio indirizzate verso un componente A hardware o software.

Con riferimento a fig. 5, il programma applicativo PA può anche rilevare eventuali comportamenti anomali di componenti A del sistema operativo che sono sotto attacco informatico, o anche che sono soggetti ad un malfunzionamento, prevenendo ed evitando possibili danni, come schematicamente illustrato mediante le doppia linee continue.

In forme di realizzazione, il programma può anche comprendere un programma di sicurezza PS, presente in un’unità di memorizzazione 102 di un hardware o del dispositivo stesso 100.

L’unità di memorizzazione 102 può essere ad esempio un hard disk (HD), un hard disk basato su tecnologia SSD (Solid State Drive), una memoria di tipo RAM (Rapid Access Memory), ROM (Read-Only Memory), PROM (Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash.

In forme di realizzazione schematicamente descritte mediante figg. 7 e 8, il dispositivo elettronico 100 comprende una scheda elettronica 101, anche detta in alcuni casi scheda madre, che contiene i circuiti e i componenti principali necessari al funzionamento del dispositivo elettronico 100.

In forme di realizzazione, l’unità di memorizzazione 102 può comprendere, o può essere configurata come un’unità di memorizzazione integrata 102a, ovvero integrata sulla scheda elettronica 101, ad esempio una memoria di tipo EPROM.

In forme di realizzazione, l’unità di memorizzazione integrata 102a può essere un’unità di memorizzazione 102 integrata in un hardware di qualsiasi tipologia.

In forme di realizzazione, l’unità di memorizzazione integrata 102a può contenere un programma di gestione F che, quando eseguito, gestisce il funzionamento della scheda elettronica 101 e in generale delle risorse hardware e software del dispositivo elettronico 100, mediante un set di istruzioni di gestione.

In forme di realizzazione, il programma di gestione F può essere ad esempio configurato come un firmware, ad esempio un firmware di boot come BIOS o UEFI. In forme di realizzazione, il dispositivo elettronico 100 comprende una pluralità di unità periferiche, o semplicemente periferiche 103, 105, 106, 107, 108, 109 connesse o integrate con la scheda elettronica 101, che possono avere ciascuna una o più funzionalità specifiche, il cui funzionamento può essere coordinato e gestito dal programma di gestione F.

Le periferiche 103, 105, 106, 107, 108, 109 possono essere intese come qualsiasi componente, elettricamente, e/o elettronicamente, e/o informaticamente connesso a o integrato sulla scheda elettronica 101, sia per via diretta, ovvero mediante appositi circuiti che collegano direttamente la periferica 103, 105, 106, 107, 108, 109 alla scheda elettronica 101, che per via indiretta, nei casi in cui il collegamento sia mediato da altri componenti.

In forme di realizzazione, può essere prevista, integrata sulla scheda elettronica 101, una periferica 103, 105, 106, 107, 108, 109 per elaborare ed eseguire istruzioni e operazioni, anche detta unità di elaborazione 103, ad esempio una CPU (Central Processing Unit), VPU (Visual Processing Unit), GPU (Graphics Processing Unit), GPGPU (General Purpose computing on Graphics Processing Unit), TPU (Tensor Processing Unit), eventualmente multicore, microprocessori di qualsiasi tipologia, microcontrollori di qualsiasi tipologia, sistemi RISC (Reduced Instruction Set Computer), ad esempio ARM (Advanced RISC Machine), sistemi CISC (Complex Instruction Set Computer).

In forme di realizzazione, le periferiche 103, 105, 106, 107, 108, 109 possono anche comprendere apparati, dispositivi, circuiti e componenti esterni alla scheda elettronica 101, ad essa connessi mediante delle porte 104.

In forme di realizzazione le periferiche 103, 105, 106, 107, 108, 109 possono inoltre comprendere periferiche di alimentazione 105, per il collegamento ad una rete di alimentazione elettrica, periferiche di interfaccia 106, che consentono l’interazione uomo-macchina, dispositivi di rete 107, per connettere il dispositivo elettronico 100 ad una rete informatica, ad esempio rete internet o LAN (Local Area Network), dispositivi di archiviazione 108, 109 per memorizzare dati in formato digitale, che comprendono unità di memorizzazione 102, in questo caso configurate come unità di memorizzazione periferiche 102b.

I dispositivi di archiviazione 108, 109 possono essere configurati come dispositivi di archiviazione portatili 107, ad esempio chiavette USB, floppy disk, CD-ROM, DVD, schede SD, o dispositivi di archiviazione di massa 108, ad esempio memorie di tipo HD, SSD, o anche di altro tipo, e possono essere sia stabilmente montati sul dispositivo elettronico 100, che inseribili/rimovibili all’occorrenza da un utente.

In forme di realizzazione schematicamente descritte mediante fig. 8, il dispositivo elettronico 100 può essere un dispositivo che non prevede un sistema operativo, e che quindi viene gestito direttamente dal programma di gestione F, come ad esempio dispositivi per applicazioni biomedicali, come apparati diagnostici, elettrodomestici, televisori, lettori di ebook, o altro.

In forme di realizzazione schematicamente descritte mediante fig. 7, il dispositivo elettronico 100 può essere un dispositivo che prevede un sistema operativo, e il programma di gestione F gestisce le fasi di accensione del dispositivo e avvio del sistema operativo.

La minaccia informatica può quindi provenire dalla rete informatica a cui il dispositivo elettronico 100 è connesso, dalle periferiche 103, 105, 106, 107, 108, 109 o anche da malfunzionamenti interni.

Il presente trovato può quindi essere impiegato sia per rendere sicuri dispositivi elettronici 100 connessi in rete, che dispositivi elettronici 100 a sé stanti, non connessi in rete e, ad esempio, minacciati ad un malfunzionamento interno.

Forme di realizzazione qui descritte si riferiscono ad un metodo 10 per rendere sicuro il funzionamento del dispositivo elettronico 100.

In forme di realizzazione il metodo 10 prevede:

- creazione di una lista di istruzioni dannose eseguibili dal programma di gestione F; - memorizzazione del programma di sicurezza PS nell’unità di memorizzazione integrata 102a;

- controllo, in cui il programma di sicurezza PS controlla il funzionamento del programma di gestione F, bloccando l’esecuzione delle istruzioni dannose e consentendo l’esecuzione delle istruzioni di gestione.

In forme di realizzazione, la fase di creazione della lista di istruzioni dannose, eseguibili dal programma di gestione F, può essere prevista nelle fasi 11a di archiviazione iniziale e/o 11d di archiviazione finale del sistema dinamico, precedentemente descritte con riferimento a figg. 10 e 11, sia contestualmente alla generazione (fase 11) del sistema dinamico, che contestualmente al suo aggiornamento (fase 14).

In particolare, le istruzioni dannose possono essere comprese fra i dati empirici noti di partenza, ed archiviate nella fase 11a di archiviazione iniziale.

Inoltre, possono essere ottenute nuove istruzioni dannose, destrutturando e ricombinando le istruzioni note fra loro, o con nuove istruzioni associate a nuovi input e nuovi dati che vengono rilevati dal dispositivo elettronico 100.

In forme di realizzazione, il metodo 10 può essere impiegato per la protezione sia di dispositivi elettronici 100 non provvisti di sistema operativo, che di dispositivi elettronici 100 provvisti di sistema operativo, nei momenti in cui il sistema operativo non è attivo, ad esempio in fase di accensione.

Con riferimento a fig. 3, la fase di creazione di una lista di istruzioni dannose eseguibili dal programma di gestione F può essere effettuata dal programma applicativo PA presente nel sistema operativo, ad esempio configurato come un set di istruzioni memorizzate nell’unità di memorizzazione periferica 102b.

In particolare, a dispositivo acceso, il programma applicativo PA può trasmettere la lista al programma di sicurezza PS memorizzato nell’unità di memorizzazione integrata 102a, e il programma di sicurezza PS può controllare il funzionamento del programma di gestione F, come schematicamente illustrato mediante frecce tratteggiate.

Il programma di sicurezza PS può quindi essere aggiornato con i nuovi dati rilevati dal programma applicativo PA.

In forme di realizzazione esemplificativamente descritte in fig. 7, l’unità di memorizzazione periferica 102b in cui è installato il programma applicativo PA e l’unità di memorizzazione integrata 102a in cui è installato il programma di sicurezza PS possono essere previste nello stesso dispositivo elettronico 100.

In tali forme di realizzazione, il presente trovato consente di rendere sicuro il funzionamento del dispositivo elettronico 100 anche nel caso in cui non sia connesso ad una rete informatica.

In forme di realizzazione esemplificativamente descritte in fig. 8, l’unità di memorizzazione periferica 102b in cui è installato il programma applicativo PA e l’unità di memorizzazione integrata 102a in cui è installato il programma di sicurezza PS sono previste in dispositivi diversi, connessi ad esempio mediante un dispositivo di rete 107.

In tali forme di realizzazione, il programma applicativo PA può trasmettere al programma di sicurezza PS la lista di istruzioni dannose mediante un protocollo di rete, ad esempio internet o LAN.

In fase di accensione del dispositivo elettronico 100, quando il programma applicativo PA non è attivo, il programma di sicurezza PS può comunque garantire il corretto funzionamento del programma di gestione F, bloccando e prevenendo possibili minacce informatiche.

Tale caratteristica consente di prevenire l’insorgere di minacce ad esempio nelle fasi di avvio del dispositivo elettronico 100 e nelle fasi di boot del sistema operativo, cioè quando il dispositivo elettronico 100 è più vulnerabile.

Inoltre, come illustrato in fig. 6, quando il dispositivo elettronico 100 è acceso, il programma applicativo PA può verificare il corretto funzionamento del programma di sicurezza PS, evitando che possibili minacce informatiche possano comprometterne il funzionamento ed eventualmente aggiornando la lista di istruzioni dannose.

Tale caratteristica consente quindi di mantenere aggiornata la lista di istruzioni dannose del programma di sicurezza PS.

In forme di realizzazione esemplificativamente descritte mediante fig. 9, il metodo 10 del presente trovato può proteggere una pluralità di dispositivi client 110, di qualsiasi tipologia, connessi fra loro mediante un dispositivo elettronico 100 configurato come un server, e provvisto di un programma applicativo PA e/o di un programma di sicurezza PS.

In questo caso, ad esempio, il programma applicativo PA può essere installato sul sistema operativo del server, per rendere sicuro il funzionamento sia del server stesso che dei dispositivi client 110 mentre il server è acceso, mentre il programma di sicurezza PS può prevenire attacchi informatici al server nelle fasi di accensione. ESEMPIO 1

In Tabella 1 è illustrato un esempio in cui due dati configurati come due stringhe, Stringi e String2, possono essere destrutturati e ricombinati.

Ad esempio Stringi può essere un URL del tipo “/hostl/folderl”, associato ad un’istruzione html del tipo:

<a href=”http://String1/file.html”></a>,

che punta ad un hostl, ad esempio un sito internet.

Ad esempio String2 può essere un path del tipo “/host2/folder2”, associato ad un comando shell tipo:

“ftp user@String2/file2.doc”,

che punta ad un host2.

Combinando tali stringhe fra loro, è possibile ottenere nuove stringhe, come ad esempio “/hostl/folder1:/host2/folder2”.

In fase di destrutturazione dei dati, la stringhe possono essere destrutturate nelle parole Wordl, Word2, Word3, Word4, che ad esempio possono essere rispettivamente “/host1”, “/folder1”, “/host2”, /folder2”.

In fase di ricombinazione dei dati, possono essere generate tutte le possibili combinazioni fra le parole, ad esempio quelle illustrate in Tabella 1, e possono essere generati dei nuovi dati come ad esempio “/host1 /host1”, “/host1 /folder2”, “/host2/host2”, “/host2/folder1”, ed altri ancora.

Possono inoltre essere generate anche combinazioni fra parole e stringhe, come ad esempio “/host1/folder1/folder2”.

Inoltre, i dati possono essere ancora destrutturati fino ad ottenere porzioni più piccole. Ad esempio le parole Word1, Word2, Word3 e Word4 possono essere destrutturate in sequenze di uno o più caratteri, come ad esempio “o”, “o1”, “der2”. I dati possono essere ulteriormente destrutturati fino ad ottenere le porzioni elementari, che in questo caso possono essere uno o più bit di informazione, ad esempio sequenze di 0 e 1, come “0”, “01”, “101”, che possono essere ricombinati fra loro. Ad esempio, dalle sequenze “01” e “101” può essere ottenuta una nuova sequenza “01101”.

A tali dati può in seguito essere associato un livello di fiducia che deriva dai livelli di fiducia dei dati precedenti, ad esempio, alla combinazione “/host1/folder2” può essere associata un’alta probabilità che si tratti di una minaccia se l’indirizzo host1 di partenza era noto per essere malevolo.

ESEMPIO 2

In Tabella 2 è illustrato un altro esempio di destrutturazione e ricombinazione di dati, in cui due file che contengono istruzioni, ad esempio codice C, Java, script bash , o simili, vengono destrutturati nelle loro righe di codice costitutive.

In tali tipologie di file è possibile trovare istruzioni in cui un’espressione, ad esempio expr1(.) e expr2 (.) opera su una variabile, ad esempio Svar1 e $var2.

In fase di destrutturazione, l’espressione può essere riconosciuta e separata dalle variabili su cui opera, come illustrato in tabella.

In fase di ricombinazione, le espressioni e le variabili possono essere mescolate fra loro, in modo tale che, partendo ad esempio da dati empirici noti del tipo expr1(Svar1) e expr2($var2) è possibile ottenere nuove espressioni del tipo expr1(expr2(.)), expr1(expr1(.)), o anche nuove variabili come Svar1var1 o $var1var2, o anche nuove combinazioni di espressioni e variabili come ad esempio expr1(expr2($var2var1)). Ad esempio, dalla combinazione di Svar1 =HOST1 e $var2=HOST2, è possibile generare la nuova variabile Svar1 var2=HOST1 :HOST2.

Se quindi, ad esempio expr2($var2) è una funzione nota per aprire un link verso l’host benevolo HOST2 e expr1(Svar1) è una funzione nota per aprire un link verso l’host malevolo HOST1, alla combinazione expr2($var1var2) verrà assegnata una probabilità che sia malevola, in quanto aprirà una connessione sia verso HOST1 che verso HOST2.

ESEMPIO 3

In fig. 15 viene illustrato un ulteriore esempio, relativo alla destrutturazione e ricombinazione di comportamenti.

Nell’esempio riportato in figura, sono riportati i comportamenti di navigazione web e installazione di un software, che possono essere destrutturati in singole azioni.

Nell’esempio l’installazione software e la navigazione web sono stati destrutturati in creazione di un file dannoso, cambio registri di sistema, download di un cookie, corretto inserimento di una password.

In fase di ricombinazione, è possibile quindi ad esempio prevedere un nuovo comportamento per la navigazione web, in cui vengono creati dei file dannosi, o vengono modificati i registri di sistema, o un nuovo comportamento per l’installazione di un software, in cui viene richiesto l’inserimento di una password o il download di un cookie sicuro da un sito internet.

I livelli di fiducia vengono aggiornati sulla base dei livelli di fiducia associati alle singole azioni.

È chiaro che al metodo e ai dispositivi fin qui descritti possono essere apportate modifiche e/o aggiunte di fasi o di parti, senza per questo uscire dall’ambito del presente trovato come definito dalle rivendicazioni.

È anche chiaro che, sebbene il presente trovato sia stato descritto con riferimento ad alcuni esempi specifici, una persona esperta del ramo potrà senz’altro realizzare molte altre forme equivalenti di metodo, aventi le caratteristiche espresse nelle rivendicazioni e quindi tutte rientranti nell’ambito di protezione da esse definito. Nelle rivendicazioni che seguono, i riferimenti tra parentesi hanno il solo scopo di facilitare la lettura e non devono essere considerati come fattori limitativi per quanto attiene all’ambito di protezione sotteso nelle specifiche rivendicazioni.

Claims (17)

1. RIVENDICAZIONI 1. Metodo per rendere sicuro il funzionamento di un dispositivo elettronico (100), detto metodo comprendendo archiviazione iniziale (I la) di dati empirici di partenza noti, in cui a ciascuno di detti dati empirici di partenza viene assegnata una probabilità che detto dato empirico di partenza sia sicuro o dannoso, caratterizzato dal fatto che detto metodo comprende inoltre: - destrutturazione di detti dati empirici in porzioni di dati progressivamente più piccole; - ricombinazione di ciascuna di dette porzioni di dato con parte o tutti detti dati empirici di partenza e con parte o tutte le altre porzioni di dato, ottenendo così nuovi dati, ricombinati; - assegnazione, a detti nuovi dati ricombinati di probabilità che essi siano sicuri o dannosi, mediante tecniche di statistica Bayesiana, a partire da dette probabilità assegnate ai dati empirici di partenza noti; - confrontare un nuovo input rilevato da detto dispositivo elettronico (100) con detti dati empirici di partenza e detti nuovi dati ricombinati, per valutare la similarità tra detto nuovo input e detti dati empirici di partenza e tra detto nuovo input e detti dati nuovi ricombinati ed assegnare, in funzione di detta valutazione di similarità, una probabilità che detto nuovo input sia sicuro o dannoso, mediante tecniche di statistica Bayesiana, a partire da dette probabilità assegnate ai dati empirici e ai nuovi dati.
2. 2. Metodo come alla rivendicazione 1, caratterizzato dal fatto che prevede una fase (1 1) di generazione di un sistema dinamico, mediante: - detta fase (11a) di archiviazione iniziale, in cui i dati empirici sicuri vengono archiviati in un sottosistema (P) di dati empirici noti sicuri, e i dati empirici dannosi vengono archiviati in un sottosistema (Q) di dati empirici noti dannosi; - una fase (11b) di elaborazione di detti dati empirici, che prevede detta operazione di destrutturazione dei dati empirici; - una fase (11c) di espansione del sistema dinamico, che prevede detta operazione di ricombinazione delle porzioni di dato per ottenere i dati nuovi e detta operazione di assegnazione di probabilità che essi siano sicuri o dannosi; - una fase (11d) di archiviazione finale, in cui, sulla base delle rispettive probabilità, i dati nuovi vengono organizzati in un sottosistema (S) di dati nuovi sicuri ed un sottosistema (T) di dati nuovi dannosi; detto sistema dinamico essendo l’unione di detti quattro sottosistemi (P, Q, S, T).
3. 3. Metodo come alla rivendicazione 2, caratterizzato dal fatto che prevede una fase (14) di aggiornamento di detto sistema dinamico, mediante: - detta fase (11a) di archiviazione iniziale, in cui ad un nuovo input viene assegnata una probabilità che sia sicuro o dannoso; - detta fase (11b) di elaborazione di detto nuovo input, che prevede detta operazione di destrutturazione del nuovo input; - detta fase (11c) di espansione del sistema dinamico, che prevede detta operazione di ricombinazione fra le porzioni dell’input e i dati presenti nel sistema dinamico, ottenendo così nuovi dati a cui vengono assegnate probabilità che siano sicuri o dannosi; - detta fase (11d) di archiviazione finale, in cui il sottosistema (S) di dati nuovi sicuri ed il sottosistema (T) di dati nuovi dannosi vengono aggiornati con i nuovi dati ottenuti dall’input.
4. 4. Metodo come alla rivendicazione 3, caratterizzato dal fatto che prevede: - una fase (11) di generazione di un sistema dinamico; - una fase (12) di rilevazione di un nuovo input; - una fase (13) di confronto di detto nuovo input con i dati noti sicuri e i dati noti dannosi contenuti nel sistema dinamico; - nel caso in cui il nuovo input non sia presente fra i dati noti sicuri e i dati noti dannosi, una fase (14) di aggiornamento del sistema dinamico con il nuovo input; - una fase (15) di valutazione, in cui il nuovo input viene confrontato con i dati nuovi sicuri e i dati nuovi dannosi aggiornati nel sistema dinamico, per assegnare una probabilità che esso sia sicuro o dannoso.
5. 5. Metodo come in una qualsiasi delle rivendicazioni precedenti, caratterizzato dal fatto che le probabilità assegnate in detta fase (11a) di archiviazione iniziale sono probabilità a priori della statistica Bayesiana, e dette probabilità assegnate mediante tecniche di statistica Bayesiana sono probabilità a posteriori della statistica Bayesiana.
6. 6. Metodo come alla rivendicazione 5, caratterizzato dal fatto che dette probabilità a posteriori della statistica Bayesiana sono ottenute mediante una formula di probabilità Bayesiana modificata.
7. 7. Metodo come in una qualsiasi delle rivendicazioni precedenti, caratterizzato dal fatto che dette tecniche di statistica Bayesiana comprendono un algoritmo di stima ricorsiva Bayesiana, che impiega una funzione di errore quadratico medio.
8. 8. Metodo come in una qualsiasi delle rivendicazioni precedenti, caratterizzato dal fatto che dette tecniche di statistica Bayesiana comprendono un algoritmo di inferenza Bayesiana.
9. 9. Metodo come in una qualsiasi delle rivendicazioni precedenti, caratterizzato dal fatto che dette tecniche di statistica Bayesiana comprendono un algoritmo di filtro Bayesiano.
10. 10. Metodo come in una qualsiasi delle rivendicazioni precedenti caratterizzato dal fatto che dette probabilità assegnate mediante tecniche di statistica Bayesiana sono calcolate da un’intelligenza artificiale che impiega algoritmi di apprendimento automatico.
11. 11. Metodo come alla rivendicazione 10, caratterizzato dal fatto che detti algoritmi di apprendimento automatico comprendono apprendimento non supervisionato, in particolare clustering partizionale, apprendimento mediante regole di associazione, algoritmo K-means.
12. 12. Metodo come alla rivendicazione 10, caratterizzato dal fatto che detti algoritmi di apprendimento automatico comprendono apprendimento supervisionato, in particolare apprendimento per rinforzo, che impiega una funzione di ricompensa basata sulla valutazione delle proprie prestazioni.
13. 13. Programma (PA, PS) per dispositivo elettronico (100) memorizzabile in un mezzo leggibile da un dispositivo elettronico (100) che contiene le istruzioni che, una volta eseguite, determinano l’esecuzione del metodo come in una qualsiasi delle rivendicazioni da 1 a 12.
14. 14. Programma (PA, PS) come alla rivendicazione 13, che comprende un programma applicativo (PA) per computer, memorizzabile in un’unità di memorizzazione periferica (102b) di un computer che contiene le istruzioni che, una volta eseguite, determinano l’esecuzione del metodo come in una qualsiasi delle rivendicazioni da 1 a 12.
15. 15. Programma (PA, PS) come alla rivendicazione 14, che comprende un programma di sicurezza (PS) presente in un’unità di memorizzazione integrata (102a) in una scheda elettronica (101) di un hardware, in detta unità di memorizzazione integrata (102a) essendo presente un programma di gestione (F) che, quando eseguito, gestisce il funzionamento di detto hardware mediante un set di istruzioni di gestione, detto programma applicativo (PA) prevedendo, in detta fase (11d) di archiviazione finale, di trasmetere una lista di istruzioni dannose, eseguibili da deto programma di gestione (F), a deto programma di sicurezza (PS), deto programma di sicurezza (PS) controllando il funzionamento di deto programma di gestione (F), bloccando l’esecuzione di dete istruzioni dannose e consentendo l’esecuzione di dete istruzioni di gestione.
16. 16. Dispositivo eletronico (100) provvisto di un’unità di memorizzazione (102) che contiene le istruzioni che, una volta eseguite, determinano l’esecuzione del metodo come in una qualsiasi delle rivendicazioni da 1 a 12.
17. 17. Dispositivo eletronico (100) che comprende un’unità di memorizzazione integrata (102a) in un hardware, in cui è presente un programma di gestione (F) che gestisce il funzionamento dell’hardware ed un programma di sicurezza (PS) che controlla il funzionamento del programma di gestione (F), ed un’unità di memorizzazione periferica (102b), in cui è presente un programma applicativo (PA) come alla rivendicazione 15.