CH719295A2 - Sistemi e metodi per proteggere i dati durante la sincronizzazione. - Google Patents

Abstract

Sono qui presentati sistemi e metodi per prevenire la diffusione di malware in una rete di dati sincronizzati, in cui il metodo comprende: la ricezione, in un primo momento da parte di un server (102) collegato a una pluralità di dispositivi informatici (104, 106, 108), di un file da un primo dispositivo (104) informatico; il monitoraggio delle modifiche al file memorizzato sul server (102); in risposta al rilevamento di una modifica, la creazione di un record indicativo della modifica al file; la ricezione, sul server da un secondo dispositivo informatico (106, 108), di una richiesta di download del file in un secondo momento; la determinazione dell'esistenza o meno di almeno un record che indichi una modifica al file tra il primo e il secondo momento; in risposta alla determinazione dell'esistenza del record, la scansione del file alla ricerca di malware; e, in risposta alla determinazione del fatto che il file memorizzato sul server (102) è associato a malware, la negazione della richiesta di download.

Description

CAMPO TECNICO

[0001] La presente esposizione si riferisce al settore della sicurezza dei dati e, più specificamente, a sistemi e metodi per proteggere i dati durante la sincronizzazione.

STATO DELL'ARTE

[0002] In una rete di dispositivi, il metodo più diffuso per sincronizzare i dati è l'utilizzo di un server centrale che riceve i dati da un dispositivo (ad esempio, uno smartphone) e poi li invia a tutti gli altri dispositivi della rete (ad esempio, un laptop, un computer, un tablet, ecc.). I dati possono essere inviati ai dispositivi di destinazione in forma di link o di copia. Una copia fornisce una versione duplicata dei dati che può essere memorizzata localmente sui dispositivi di destinazione. Un link, invece, fornisce un indirizzo che porta ai dati sul server e consente ai dispositivi di destinazione di accedere direttamente ai dati. Questo schema è ampiamente utilizzato nei moderni servizi cloud per risparmiare spazio sul disco locale.

[0003] Esiste anche un metodo di sincronizzazione diretta in cui i dati vengono inviati al dispositivo disponibile più vicino senza passare attraverso un server centrale. Questo metodo viene utilizzato quando i dispositivi da sincronizzare si trovano nella stessa rete locale e il server centrale si trova nel cloud (ad esempio, una rete globale).

[0004] In entrambi i metodi di sincronizzazione, tuttavia, esiste il rischio di infezione dei dati sincronizzati. Questo accade perché può trascorrere un tempo considerevole tra il caricamento dei dati dal dispositivo di origine e il download sui dispositivi di destinazione. Durante questo lasso di tempo, i dati potrebbero essere infettati sul server centrale o sul dispositivo di origine.

[0005] L'algoritmo standard per proteggere i dati da possibili infezioni prevede l'esecuzione di una scansione antimalware durante l'invio dei dati al server centrale. Tuttavia, i dati sul server possono essere attaccati da ransomware e malware prima di essere inviati a tutti gli altri dispositivi sincronizzati della rete. Ciò può accadere, ad esempio, quando il programma antivirus viene temporaneamente disattivato (spesso necessario quando si installa un nuovo software sul server). In questo modo, nel momento in cui raggiungono i dispositivi di destinazione i dati sincronizzati possono essere infetti nonostante non presentino problemi durante il caricamento dal dispositivo di origine.

SOMMARIO

[0006] In un esempio, le tecniche qui descritte si riferiscono a un metodo per prevenire la diffusione di malware in una rete di dati sincronizzati, il quale metodo comprende: la ricezione, in un primo momento da parte di un server collegato a una pluralità di dispositivi informatici, di un file da un primo dispositivo informatico della pluralità di dispositivi informatici; il monitoraggio delle modifiche al file memorizzato sul server; in risposta al rilevamento di una modifica, la creazione di un record indicativo della modifica al file; la ricezione, da un secondo dispositivo informatico della pluralità di dispositivi informatici, di una richiesta di download per scaricare il file dal server, dove la richiesta di download è ricevuta in un secondo momento successivo al primo; la determinazione dell'esistenza o meno di almeno un record che indichi qualsiasi modifica al file tra il primo e il secondo momento; in risposta alla determinazione dell'esistenza del record, la scansione del file alla ricerca di malware; e, in risposta alla determinazione del fatto che il file memorizzato sul server è associato a malware, la negazione della richiesta di download.

[0007] In alcuni esempi, le tecniche qui descritte si riferiscono a un metodo in cui la ricezione del file include: il rilevamento di una richiesta di caricamento del file dal primo dispositivo informatico; la richiesta, al primo dispositivo informatico, di un risultato di scansione che indichi se il file è associato a malware; in risposta alla ricezione di un risultato di scansione che indica che il file non è associato a malware, l'approvazione della richiesta di caricamento e l'archiviazione del file sul server in un primo momento.

[0008] In alcuni esempi, le tecniche qui descritte riguardano un metodo in cui il record fa parte di un registro distribuito che memorizza, in una pluralità di record, le modifiche apportate ai file sul server.

[0009] In alcuni esempi, le tecniche qui descritte si riferiscono a un metodo in cui il registro distribuito memorizza le modifiche e i risultati di scansione esclusivi dei file sincronizzati tra la pluralità di dispositivi informatici e in cui ogni record della pluralità di record è verificato dalla pluralità di dispositivi informatici.

[0010] In alcuni esempi, le tecniche qui descritte si riferiscono a un metodo che comprende inoltre: l'esecuzione di un'azione correttiva che includa uno o più dei seguenti elementi: rimozione del file dal server, messa in quarantena del file sul server e richiesta, dal primo dispositivo informatico, di una versione del file non associata a malware.

[0011] In alcuni esempi, le tecniche qui descritte si riferiscono a un metodo che comprende inoltre: in risposta alla determinazione del fatto che il file memorizzato sul server non è associato a malware, l'approvazione della richiesta di download e la trasmissione del file al secondo dispositivo informatico.

[0012] In alcuni esempi, le tecniche qui descritte si riferiscono a un metodo che comprende inoltre: la creazione di un altro record che includa i risultati della scansione eseguita sul file memorizzato sul server, dove i risultati indicano che il file non è associato a malware.

[0013] In alcuni esempi, le tecniche qui descritte si riferiscono a un metodo che comprende inoltre: la ricezione, da un terzo dispositivo informatico, di un'altra richiesta di download per scaricare il file dal server, in cui l'altra richiesta di download viene ricevuta in un terzo momento successivo al secondo; in risposta alla determinazione che l'altro record è il record più recente del file, la concessione dell'altra richiesta di download senza eseguire un'altra scansione del file.

[0014] Si noti che i metodi sopra descritti possono essere implementati in un sistema comprendente un processore hardware. In alternativa, i metodi possono essere implementati utilizzando istruzioni informatiche eseguibili di un supporto informatico non transitorio.

[0015] In alcuni esempi, le tecniche qui descritte riguardano un sistema per prevenire la diffusione di malware in una rete di dati sincronizzati, in cui il sistema comprende: una memoria; un processore hardware accoppiato in modo comunicativo con la memoria e configurato per: la ricezione, in un primo momento da parte di un server collegato a una pluralità di dispositivi informatici, di un file da un primo dispositivo informatico della pluralità di dispositivi informatici; il monitoraggio delle modifiche al file memorizzato sul server; in risposta al rilevamento di una modifica, la creazione di un record indicativo della modifica al file; la ricezione, da un secondo dispositivo informatico della pluralità di dispositivi informatici, di una richiesta di download per scaricare il file dal server, dove la richiesta di download è ricevuta in un secondo momento successivo al primo; la determinazione dell'esistenza o meno di almeno un record che indichi qualsiasi modifica al file tra il primo e il secondo momento; in risposta alla determinazione dell'esistenza del record, la scansione del file alla ricerca di malware; e, in risposta alla determinazione del fatto che il file memorizzato sul server è associato a malware, la negazione della richiesta di download.

[0016] Il sommario semplificato delle tecniche e realizzazioni esemplificative di cui sopra serve a consentire una comprensione basilare della presente esposizione. Questo sommario non è una panoramica completa di tutte le tecniche e realizzazioni contemplate e non intende né identificare elementi chiave o critici di tutte le tecniche e realizzazioni né delineare lo scopo di alcune o di tutte le tecniche e realizzazioni della presente esposizione. Il suo unico scopo è presentare una o più tecniche e realizzazioni in forma semplificata come preludio alla descrizione più dettagliata dell'esposizione che segue. A completamento di quanto precede, una o più tecniche e realizzazioni della presente esposizione include le funzionalità descritte ed evidenziate in modo esemplificativo nelle rivendicazioni.

BREVE DESCRIZIONE DEI DISEGNI

[0017] I disegni accompagnatori, che sono incorporati e costituiscono parte di questa specifica, illustrano una o più realizzazioni esemplificative della presente esposizione e, insieme alla descrizione dettagliata, servono a spiegarne i principi e le implementazioni.

[0018] La FIG. 1 è un diagramma a blocchi che illustra un sistema per prevenire la diffusione di malware in una rete di dati sincronizzati.

[0019] La FIG. 2 è un diagramma a blocchi che illustra la scansione selettiva di un file sincronizzato.

[0020] La FIG. 3 illustra un diagramma di flusso di un metodo per prevenire la diffusione di malware in una rete di dati sincronizzati.

[0021] La FIG. 4 è un diagramma a blocchi che illustra i record dei file sincronizzati nel registro distribuito.

[0022] La FIG. 5 presenta un esempio di un sistema informatico generico su cui possono essere implementati esempi dei sistemi e dei metodi della presente esposizione.

DESCRIZIONE DETTAGLIATA

[0023] Nel presente documento sono descritte realizzazioni esemplificative nel contesto di un sistema, un metodo e un programma informatico per prevenire la diffusione di malware in una rete di dati sincronizzati. Agli esperti della tecnica pertinente risulta chiaro che la seguente descrizione è puramente illustrativa e non intende essere in alcun modo limitativa. Altre realizzazioni si riveleranno immediatamente a chi è competente nell'arte e si avvarrà dei vantaggi di questa esposizione. Si farà ora riferimento in dettaglio alle implementazioni delle realizzazioni esemplificative come illustrato nei disegni accompagnatori. Gli stessi indicatori di riferimento saranno utilizzati, nei limiti del possibile, in tutti i disegni e nella seguente descrizione per riferirsi agli stessi elementi o ad elementi simili.

[0024] Un approccio di base per risolvere le carenze descritte in precedenza prevede la scansione di qualsiasi file che deve essere sincronizzato più volte (cioè, una volta quando viene caricato dal dispositivo di origine e una volta per ogni dispositivo di destinazione che scaricherà il file). Tuttavia, le doppie scansioni rallentano notevolmente i tempi di sincronizzazione e riducono le prestazioni. Se ogni file viene scansionato più volte nonostante non abbia subito modifiche, si verifica un notevole spreco di risorse di elaborazione che potrebbero essere utilizzate meglio per altri scopi.

[0025] La presente esposizione presenta quindi l'idea di eseguire un'altra scansione durante il download verso il dispositivo di destinazione solo se i dati sono stati in qualche modo modificati nell'intervallo tra il caricamento e il download. Tuttavia, per controllare l'immutabilità dei dati, vengono utilizzati un driver di monitoraggio e un registro distribuito (ad esempio, una blockchain). Un registro distribuito evita la necessità di avere più copie di un singolo file. Ad esempio, un approccio inefficiente per verificare se un file ha subito modifiche consiste nel confrontare la versione del file durante il caricamento con la versione del file durante il download. L'inefficienza deriva dal fatto che è necessario memorizzare almeno due versioni del file in ogni momento. Questo approccio richiede il doppio dello spazio e richiede comunque una notevole quantità di elaborazione quando è necessario confrontare migliaia di file caricati e scaricati.

[0026] I vantaggi dell'uso del registro distribuito risiedono nel fatto che le modifiche al file possono essere registrate sul registro e verificate da una rete blockchain (che può, ad esempio, comprendere i dispositivi della rete di sincronizzazione). La registrazione degli eventi avviene in parallelo al normale utilizzo dei dispositivi della rete e del server, e quindi l'intera elaborazione (cioè il confronto dei file) non è incentrata sul processo di download, ma consiste semplicemente nel confermare se una modifica è stata registrata sul registro. Inoltre, se più dispositivi informatici devono scaricare il file che ha subito una modifica e una scansione è già stata eseguita e registrata sul registro distribuito (etichettando la modifica come benigna), non saranno necessarie ulteriori scansioni per ogni nuovo dispositivo informatico che sincronizza i propri contenuti locali con il server centrale: tutti possono fare riferimento al record all'interno del registro distribuito. Ciò differisce dall'approccio più impegnativo che prevede il confronto dei file, in cui ogni nuovo dispositivo informatico avrà bisogno di una nuova scansione sulla base del fatto che la versione corrente del file è diversa da quella caricata. Inoltre, un'entità malevola non può mascherare/nascondere le proprie modifiche a un file sul server centrale, perché ogni modifica viene verificata dai membri della rete del registro distribuito.

[0027] La FIG. 1 è un diagramma a blocchi che illustra il sistema 100 per prevenire la diffusione di malware in una rete di dati sincronizzati. Nel sistema 100, il dispositivo informatico104può essere uno smartphone, il dispositivo informatico 106 può essere un laptop e il dispositivo informatico 108 può essere un computer desktop. Ogni dispositivo informatico è collegato agli altri dispositivi in una rete di sincronizzazione. Ad esempio, un utente può catturare un'immagine utilizzando il dispositivo informatico 104, che può essere sincronizzato con il dispositivo informatico 106 e con il dispositivo informatico 108. Di conseguenza, è possibile fornire una copia o un link dell'immagine al dispositivo informatico 106 e al dispositivo informatico 108. Ad esempio, una copia dell'immagine può essere prima memorizzata sul server 102, che poi trasmette le copie dell'immagine memorizzata al dispositivo informatico 106 e al dispositivo informatico 108.

[0028] Per garantire che le attività dannose non si diffondano in tutta la rete, viene introdotto il modulo di sicurezza 110. Il modulo di sicurezza 110 comprende l'agente di scansione 112, il driver di monitoraggio 114 e il registro distribuito 116. L'agente di scansione 112 può essere un software antivirus che verifica la presenza di attività dannose in uno o più file. Il driver di monitoraggio 114 può intercettare i comandi di modifica sul server 102 per determinare se i file sono stati aggiunti, rimossi o modificati sul server 102. Il registro distribuito 116 può essere una blockchain memorizzata su ciascuno dei dispositivi informatici 104, 106 e 108 e sul server 102.

[0029] Il modulo di sicurezza 110 può essere memorizzato su ciascuno dei dispositivi illustrati nella FIG. 1. In alcuni esempi, la versione del modulo di sicurezza 110 memorizzata sul server 102 può essere diversa dalla versione del modulo di sicurezza 110 memorizzata sul server 102. Ad esempio, il driver di monitoraggio 114 può essere memorizzato come modulo thin e thick rispettivamente sui dispositivi informatici e sul server. Il modulo thick del driver di monitoraggio 114 può tenere traccia delle modifiche apportate al server 102 e aggiornare (cioè scrivere su) il registro distribuito 116. Il modulo thin del driver di monitoraggio 114 può leggere gli aggiornamenti sul registro distribuito 116.

[0030] La FIG. 2 è un diagramma a blocchi 200 che illustra la scansione selettiva di un file sincronizzato. Nel diagramma a blocchi 200, il dispositivo informatico 104 seleziona un file locale (ad esempio, un'immagine) per la sincronizzazione. L'agente di scansione 112 sul dispositivo informatico 104 o sul server 102 può eseguire la scansione del file selezionato per assicurarsi che il file non sia dannoso. L'agente di scansione 112 può quindi fornire un risultato (cioè, il file è dannoso o non è dannoso). In un esempio, un file viene selezionato e scansionato sul dispositivo informatico 104 e successivamente trasmesso al server 102 in risposta al risultato fornito dall'agente di scansione 112 che non rileva alcuna attività dannosa.

[0031] Il driver di monitoraggio 114 controlla le modifiche apportate al server 102 (ad esempio, la scrittura del file selezionato sul server 102). In risposta al rilevamento di una modifica, il driver di monitoraggio 114 può generare un record sul registro distribuito 116. Il record può indicare che il file è stato scritto sul server 102. Altre possibili modifiche includono la modifica della directory del file, la ridenominazione del file, la compressione del file, la crittografia del file, ecc. Ogni modifica apportata al server 102 viene rilevata dal driver di monitoraggio 114 e registrata sul registro distribuito 116.

[0032] In alcuni esempi, il registro distribuito 116 è una catena di tutte le modifiche apportate al server 102. Ad esempio, una singola blockchain può includere ogni modifica apportata a uno spazio di archiviazione del server 102. In alcuni esempi, il registro distribuito 116 è una catena di tutte le modifiche apportate ai file associati alla rete che comprende i dispositivi informatici 104, 106 e 108. Ad esempio, il server 102 può memorizzare informazioni per diverse reti e ogni rete può avere la propria blockchain associata. In alcuni esempi, il registro distribuito 116 può essere una catena di tutte le modifiche apportate a un file specifico. Di conseguenza, ogni file ha una propria blockchain che registra ogni modifica apportata al file mentre è memorizzato sul server 102. Supponiamo che, in questo esempio, il registro distribuito 116 sia il secondo tipo di catena (cioè quello associato a una rete specifica di dispositivi). Una copia del registro distribuito 116 è sincronizzata con tutti i dispositivi della rete e ogni record è verificato da ciascun dispositivo.

[0033] Il dispositivo informatico 106 o 108 può avviare un'azione di sincronizzazione. Ad esempio, il dispositivo informatico 106 e/o 108 può lanciare un'applicazione per la visualizzazione di foto che tenti di sincronizzare il proprio contenuto con il server 102. Se il file è un'immagine, l'avvio della sincronizzazione può essere considerato una richiesta dell'immagine. I dispositivi informatici 106 e 108 possono essere dotati di un driver di monitoraggio 114 che controlla il registro distribuito 116 per rilevare modifiche nel file. Come accennato in precedenza, il driver di monitoraggio 114 può essere un thin client che legge i record sul registro distribuito 116. Ad esempio, il driver di monitoraggio 114 può cercare i record che includono un identificatore (ad esempio, nome, dimensione, estensione, ecc.) del file. In risposta al rilevamento di record successivi a un record di caricamento, il dispositivo informatico 106 e/o 108 può confermare che è avvenuta una modifica al file e può richiedere una scansione prima dell'inizio del processo di download.

[0034] L'agente di scansione 114 del server 102 può scansionare il file e fornire un risultato. In risposta al rilevamento di un'attività dannosa, la sincronizzazione viene annullata e il file viene eliminato o messo in quarantena. In questo modo si impedisce la diffusione dell'attività dannosa. Se non viene rilevata alcuna attività dannosa, il server 102 trasmette il file al dispositivo informatico 106 e/o 108.

[0035] In alcuni esempi, il risultato della scansione viene registrato sul registro distribuito 116. Se non viene rilevata alcuna attività dannosa, l'agente di scansione 112 genera un record che indica l'ora in cui è stata effettuata la scansione e il risultato. Supponiamo che la scansione sia stata inizializzata da una richiesta di sincronizzazione da parte del dispositivo informatico 106. In un momento successivo, anche il dispositivo informatico 108 richiede di sincronizzare il file. L'agente di monitoraggio 114 del dispositivo informatico 108 può rilevare che l'ultimo record del file indica che il file non è un malware. Nonostante le modifiche apportate al file prima della scansione, poiché l'ultima scansione indica già l'assenza di malware, non viene eseguita un'altra scansione durante la sincronizzazione con il dispositivo informatico 108. In questo modo si risparmiano risorse di elaborazione perché si evitano scansioni non necessarie.

[0036] In alcuni esempi, ogni volta che viene eseguita una scansione o si verifica una modifica, il driver di monitoraggio 114 genera un record con valore di hash per il registro distribuito 116. Nel caso di una modifica, il valore di hash può essere generato utilizzando una funzione hash applicata a un timestamp e al file modificato. Nel caso di una scansione, il valore di hash può essere generato utilizzando una funzione hash applicata a un timestamp, a un risultato di scansione e al file scansionato.

[0037] La FIG. 3 illustra un diagramma di flusso del metodo 300 per prevenire la diffusione di malware in una rete di dati sincronizzati. Al 302, il modulo di sicurezza 110 riceve, in un primo momento da un server collegato a una pluralità di dispositivi informatici, un file da un primo dispositivo informatico della pluralità di dispositivi informatici. Ad esempio, in alcuni esempi, il modulo di sicurezza 110 rileva una richiesta di caricamento del file dal dispositivo informatico 104 e richiede dal dispositivo informatico 104 un risultato di scansione che indichi se il file è associato a malware. In risposta alla ricezione di un risultato di scansione che indichi che il file non è associato a malware, il modulo di sicurezza 110 approva la richiesta di caricamento e memorizza il file sul server 102 in un primo momento.

[0038] Al 304, il modulo di sicurezza 110 monitora le modifiche apportate al file memorizzato sul server 102. Al 306, in risposta al rilevamento di una modifica al punto 304, il modulo di sicurezza 110 genera un record indicativo della modifica al file. In alcuni esempi, il record fa parte di un registro distribuito che memorizza, in una pluralità di record, le modifiche apportate ai file sul server. In alcuni esempi, il registro distribuito memorizza le modifiche e i risultati di scansione esclusivi dei file sincronizzati tra la pluralità di dispositivi informatici. Inoltre, ogni record della pluralità di record viene verificato dalla pluralità di dispositivi informatici.

[0039] Al 308, il modulo di sicurezza 110 riceve, da un secondo dispositivo informatico della pluralità di dispositivi informatici, una richiesta di download per scaricare il file dal server, dove la richiesta di download viene ricevuta in un secondo momento successivo al primo.

[0040] Al 310, il modulo di sicurezza 110 determina se esiste almeno un record che indica qualsiasi modifica al file tra il primo e il secondo momento. In risposta alla determinazione dell'esistenza del record, il metodo 300 passa al 312, in cui il modulo di sicurezza 110 esegue una scansione del file alla ricerca di malware. Al 314, il modulo di sicurezza 110 determina se il file memorizzato sul server è associato a malware. In risposta alla determinazione del fatto che il file memorizzato sul server è associato a malware, il metodo 300 passa al 316, dove il modulo di sicurezza 110 nega la richiesta di download.

[0041] In alcuni esempi, oltre a negare la richiesta di download, il modulo di sicurezza 110 esegue un'azione correttiva che comprende uno o più dei seguenti elementi: rimozione del file dal server, messa in quarantena del file sul server e richiesta, dal primo dispositivo informatico, di una versione del file non associata a malware.

[0042] Se al 310 il modulo di sicurezza 110 determina che non esiste alcun record indicativo di una modifica, il metodo 300 passa al 318, dove il modulo di sicurezza 110 approva la richiesta di download. Allo stesso modo, se al 314 il modulo di sicurezza 110 determina che il file non è associato ad attività dannose, il metodo 300 passa al 318, dove il modulo di sicurezza 110 approva la richiesta di download. In questo caso, la concessione della richiesta di download comporta la trasmissione del file al secondo dispositivo informatico.

[0043] In alcuni esempi, dopo una scansione, il modulo di sicurezza 110 genera un altro record che include i risultati della scansione eseguita sul file memorizzato sul server. Ad esempio, i risultati possono indicare che il file non è associato a malware. Successivamente, il modulo di sicurezza 110 può ricevere, da un terzo dispositivo informatico, un'altra richiesta di download per scaricare il file dal server, dove l'altra richiesta di download viene ricevuta in un terzo momento successivo al secondo. In risposta alla determinazione del fatto che l'altro record è il record più recente per il file, il modulo di sicurezza 110 approva l'altra richiesta di download senza eseguire un'altra scansione del file.

[0044] La FIG. 4 è il diagramma a blocchi 400 che illustra i record dei file sincronizzati nel registro distribuito. Si supponga che il dispositivo informatico 104 carichi un primo file sul server 102. Il dispositivo informatico 104 e/o il server 102 confermano che il primo file non è dannoso utilizzando un agente di scansione. In risposta alla conferma, al t1, il modulo di sicurezza 110 può calcolare un valore di hash del primo file utilizzando un algoritmo di hashing come SHA1, MD5, ecc. e generare il record 402 nel registro distribuito 116. Un record può includere informazioni come il timestamp, il tipo di azione, l'identificatore del file (ad esempio, l'indirizzo del dispositivo di origine, la directory, il nome, la dimensione, l'estensione, ecc.), un valore di hash associato al record precedente, ecc. Per semplicità, tuttavia, il record 402 della FIG. 4 rappresenta esclusivamente il valore di hash del file e un payload che indica a cosa è associato il valore di hash. Ad esempio, il record 402 rappresenta il caricamento del file 1 sul server 102 dal dispositivo informatico 104.

[0045] Secondo la cronologia, al t2, il primo file caricato viene modificato sul server 102. In alcuni esempi, il modulo di sicurezza 110 può intercettare i comandi che modificano il primo file per generare i record che rappresentano le modifiche. Ad esempio, se il primo file comprende il codice sorgente e la modifica è un'iniezione di codice, il modulo di sicurezza 110 può rilevare l'iniezione e generare un record che indica che il primo file è stato modificato e il suo nuovo valore di hash. In alcuni esempi, tuttavia, il modulo di sicurezza 110 può tenere traccia delle modifiche solo quando viene effettuata una richiesta di download per risparmiare spazio di archiviazione (poiché diverse modifiche possono far aumentare esponenzialmente le dimensioni del registro distribuito 116). Ad esempio, nella FIG. 4, al tempo t2 non viene creato alcun record. Invece, al t4, il server 102 riceve una richiesta di download (ad esempio, dal dispositivo informatico 106) per il primo file. Il modulo di sicurezza 110 può quindi calcolare un valore di hash del primo file al t4 e ricercare il valore di hash nel registro distribuito 116. Poiché il primo file è stato modificato al tempo t2, il modulo di sicurezza 110 potrebbe non trovare un valore di hash corrispondente.

[0046] Se non viene trovata una corrispondenza, il modulo di sicurezza 110 conclude che il primo file deve essere stato modificato dopo il caricamento. Ciò induce il modulo di sicurezza 110 a ripetere la scansione del primo file. Supponiamo che il risultato della scansione sia che il primo file modificato non è dannoso. Il modulo di sicurezza 110 può generare il record 406, che indica che il file è pulito e include un valore di hash del primo file modificato. Poiché il primo file è pulito nonostante sia stato modificato, il modulo di sicurezza 110 esegue la richiesta di download.

[0047] Si supponga che al tempo t6 il server 102 riceva un'altra richiesta di download per il primo file (ad esempio, dal dispositivo informatico 108). Tra t4 e t6, il file non ha subito altre modifiche presso il server 102. Pertanto, il valore di hash che il modulo di sicurezza 110 calcola per il primo file al tempo t6 corrisponderà al valore di hash nel record 406. Poiché il record 406 indica che il primo file è pulito, il modulo di sicurezza 110 esegue la richiesta di download.

[0048] Si noti che diversi file possono essere caricati sul server 102 dalla pluralità di dispositivi informatici. Ad esempio, al tempo t3, un secondo file può essere caricato dal dispositivo informatico 108. Dopo aver confermato che il secondo file è pulito, il modulo di sicurezza 110 può generare il record 404, che include l'indicazione che il file 2 è stato caricato e un valore di hash per il secondo file. Al tempo t5, il secondo file può essere modificato in modo dannoso (ad esempio, un'entità malevola può iniettare malware nel codice sorgente del secondo file). Supponiamo che al t6 la richiesta di download riguardi il secondo file. Poiché il secondo file è stato modificato al t5, quando il modulo di sicurezza 110 calcola un nuovo valore di hash del secondo file al t6, il valore di hash risultante non corrisponde a nessuno dei valori di hash nel registro distribuito (compreso, ad esempio, il valore di hash nel record 404). Di conseguenza, il modulo di sicurezza 110 può eseguire una scansione del secondo file e determinare che il secondo file è dannoso. Il modulo di sicurezza 110 può quindi negare la richiesta di download e generare il record 408, che include l'indicazione che il secondo file modificato è dannoso e il valore di hash del secondo file modificato. Ogni volta che viene ricevuta una richiesta di download successiva per il secondo file, il modulo di sicurezza 110 può negare automaticamente la richiesta in base al record 408.

[0049] In alcuni esempi, il registro distribuito 116 può avere dimensioni molto grandi. Ad esempio, il record che indica che il file 1 è stato caricato può trovarsi a diverse centinaia di record di distanza dal momento in cui viene richiesto il download del file 1. Poiché la comparazione di ciascun valore di hash può risultare complessa e dispendiosa in termini di tempo, il modulo di sicurezza 110 può confrontare innanzitutto un valore di hash calcolato con i valori di hash dei file a cui si accede più frequentemente, può confrontare i record a ritroso nel tempo fino al record di caricamento di un file, può utilizzare metodi di indicizzazione e può anche utilizzare la memorizzazione nella cache. Ciò può migliorare i tempi di ricerca.

[0050] La FIG. 5 è un diagramma a blocchi che illustra un sistema informatico 20 su cui possono essere implementati degli esempi di sistemi e metodi per prevenire la diffusione di malware in una rete di dati sincronizzati. Il sistema informatico 20 può essere sotto forma di più dispositivi informatici o sotto forma di un unico dispositivo informatico, ad esempio un computer desktop, un notebook, un laptop, un dispositivo informatico mobile, uno smartphone, un tablet, un server, un computer centrale, un dispositivo integrato e altre forme di dispositivi informatici.

[0051] Come mostrato, il sistema informatico 20 comprende un'unità di elaborazione centrale (CPU) 21, una memoria di sistema 22 e un bus di sistema 23 che collega i vari componenti del sistema, inclusa la memoria associata all'unità di elaborazione centrale 21. Il bus di sistema 23 può comprendere una memoria del bus o un controller di memoria del bus, un bus periferico e un bus locale in grado di interagire con qualsiasi altra architettura di bus. Esempi di bus possono includere PCI, ISA, PCI-Express, HyperTransport™, InfiniBand™, Serial ATA, I<2>C e altre interconnessioni adeguate. L'unità di elaborazione centrale 21 (detta anche processore) può comprendere un singolo o una serie di processori con uno o più core. Il processore 21 può eseguire uno o più codici informatici eseguibili che implementano le tecniche della presente esposizione. Ad esempio, eventuali comandi/passaggi discussi nelle FIGG. 1-4 possono essere eseguiti dal processore 21. La memoria di sistema 22 può essere qualunque memoria per la memorizzazione dei dati utilizzata in questo contesto e/o programmi informatici eseguibili dal processore 21. La memoria di sistema 22 può includere una memoria volatile come una memoria ad accesso casuale (RAM) 25 e una memoria non volatile come una memoria di sola lettura (ROM) 24, una memoria flash, ecc. o una combinazione di queste. Il sistema di base di input/output (BIOS) 26 può memorizzare le procedure di base per il trasferimento di informazioni tra elementi del sistema informatico 20, come quelle al momento del caricamento del sistema operativo con l'uso della ROM 24.

[0052] Il sistema informatico 20 può comprendere uno o più dispositivi di archiviazione come uno o più dispositivi di archiviazione rimovibili 27, uno o più dispositivi di archiviazione non rimovibili 28 o una combinazione di questi. Uno o più dispositivi di archiviazione rimovibili 27 e dispositivi di archiviazione non rimovibili 28 sono collegati al bus di sistema 23 tramite un'interfaccia di archiviazione 32. In un esempio, i dispositivi di archiviazione e i corrispondenti supporti di archiviazione informatici sono moduli indipendenti dalla potenza per la memorizzazione di istruzioni, strutture di dati, moduli di programma e altri dati del sistema informatico 20. La memoria di sistema 22, i dispositivi di archiviazione rimovibili 27 e i dispositivi di archiviazione non rimovibili 28 possono utilizzare una varietà di supporti di archiviazione informatici. Esempi di supporti di archiviazione informatici includono la memoria a bordo macchina come cache, SRAM, DRAM, RAM a zero condensatori, RAM a doppio transistor, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM; memoria flash o altre tecnologie di memoria come nelle unità a stato solido (SSD) o unità flash; memorizzazione su cassette magnetiche, nastri magnetici e dischi magnetici come, ad esempio, in unità disco rigido o floppy disk; memorizzazione ottica come, ad esempio, in compact disk (CD-ROM) o dischi digitali versatili (DVD); e qualsiasi altro supporto che può essere utilizzato per memorizzare i dati desiderati e che possa essere accessibile dal sistema informatico 20.

[0053] La memoria di sistema 22, i dispositivi di archiviazione rimovibili 27 e i dispositivi di archiviazione non rimovibili 28 del sistema informatico 20 possono essere utilizzati per memorizzare un sistema operativo 35, applicazioni aggiuntive di programmi 37, altri moduli di programma 38 e dati di programma 39. Il sistema informatico 20 può includere un'interfaccia periferica 46 per la comunicazione dei dati provenienti dai dispositivi di input 40, come tastiera, mouse, stilo, controller di gioco, dispositivo a comandi vocali, dispositivo a comandi tattili o altri dispositivi periferici, come stampante o scanner tramite una o più porte I/O, come una porta seriale, una porta parallela, un bus seriale universale (USB), o un'altra interfaccia periferica. Un dispositivo di visualizzazione 47, come uno o più monitor, proiettori o display integrati, può anche essere collegato al bus di sistema 23 attraverso un'interfaccia di uscita 48, come un adattatore video. Oltre ai dispositivi di visualizzazione 47, il sistema informatico 20 può essere dotato di altri dispositivi periferici di uscita (non mostrati), come altoparlanti e altri dispositivi audiovisivi.

[0054] Il sistema informatico 20 può funzionare in un ambiente di rete utilizzando una connessione di rete a uno o più computer remoti 49. Il computer remoto (o i computer) 49 può essere costituito da postazioni di lavoro locali o server che comprendono la maggior parte o tutti gli elementi menzionati sopra nella descrizione della natura di un sistema informatico 20. Nella rete informatica possono essere presenti anche altri dispositivi, quali, ma non solo, router, stazioni di rete, dispositivi peer o altri nodi di rete. Il sistema informatico 20 può comprendere una o più interfacce di rete 51 o adattatori di rete per comunicare con i computer remoti 49 attraverso una o più reti, quali una rete informatica locale (LAN) 50, una rete informatica ad ampio raggio (WAN), una rete intranet e Internet. Esempi di interfaccia di rete 51 possono includere un'interfaccia Ethernet, un'interfaccia Frame Relay, un'interfaccia SONET e interfacce wireless.

[0055] Una realizzazione della presente esposizione può essere implementata come un sistema, un metodo e/o un prodotto di un programma informatico. Il prodotto del programma informatico può includere un supporto di archiviazione informatico (o supporti) con istruzioni per programmi informatici per far sì che un processore esegua realizzazioni della presente esposizione.

[0056] Il supporto di archiviazione informatico può essere un dispositivo tangibile in grado di conservare e memorizzare il codice del programma sotto forma di istruzioni o strutture di dati accessibili da un processore di un dispositivo informatico, come il sistema informatico 20. Il supporto di archiviazione informatico può essere un dispositivo di archiviazione elettronica, un dispositivo di archiviazione magnetica, un dispositivo di archiviazione ottica, un dispositivo di archiviazione elettromagnetica, un dispositivo di archiviazione a semiconduttori o qualunque combinazione appropriata di questi. A titolo di esempio, tale supporto di archiviazione informatico può comprendere una memoria ad accesso casuale (RAM), una memoria a sola lettura (ROM), una EEPROM, una memoria a sola lettura di un compact disc portatile (CD-ROM), un disco digitale versatile (DVD), una memoria flash, un disco rigido, un dischetto portatile, un memory stick, un floppy disk, o anche un dispositivo codificato meccanicamente come schede perforate o strutture in rilievo in un solco con istruzioni registrate. Come usato nel presente contesto, un supporto di archiviazione informatico non è da intendersi come segnali transitori di per sé, come onde radio o altre onde elettromagnetiche che si propagano liberamente, onde elettromagnetiche che si propagano attraverso una guida d'onda o mezzi di trasmissione, o segnali elettrici trasmessi attraverso un filo.

[0057] Le istruzioni di programmi informatici qui descritte possono essere scaricate sui rispettivi dispositivi informatici da un supporto di archiviazione informatico o su un computer esterno o un dispositivo di archiviazione esterno attraverso una rete, ad esempio Internet, una rete locale, una rete ad ampio raggio e/o una rete wireless. La rete può comprendere cavi di trasmissione in rame, fibre ottiche di trasmissione, trasmissione senza fili, router, firewall, switch, computer gateway e/o edge server. Un'interfaccia di rete di ogni dispositivo informatico riceve dalla rete istruzioni di programmi informatici e inoltra le istruzioni di programmi informatici per l'archiviazione in un supporto di archiviazione informatico all'interno del rispettivo dispositivo informatico.

[0058] Le istruzioni di programmi informatici per l'esecuzione delle operazioni della presente esposizione possono essere istruzioni di assemblaggio, insiemi di istruzioni (ISA), istruzioni per macchine, istruzioni dipendenti dalla macchina, microcodici, istruzioni firmware, dati di impostazione dello stato, oppure codici sorgente o codici oggetto scritti in qualunque combinazione di uno o più linguaggi di programmazione, compreso un linguaggio di programmazione orientato agli oggetti e linguaggi di programmazione procedurali convenzionali. Le istruzioni di programmi informatici possono essere eseguite interamente sul computer dell'utente, in parte sul computer dell'utente, come pacchetto software indipendente, in parte sul computer dell'utente e in parte su un computer remoto o interamente sul computer o server remoto. In quest'ultimo caso, il computer remoto può essere collegato al computer dell'utente attraverso qualunque tipo di rete, compresa una rete LAN o WAN, oppure la connessione può essere effettuata a un computer esterno (ad esempio, attraverso Internet). In alcune realizzazioni, i circuiti elettronici che comprendono, ad esempio, circuiti a logica programmabile, gate array programmabili sul campo (FPGA), o array a logica programmabile (PLA) possono eseguire le istruzioni di programmi informatici utilizzando le informazioni di stato delle istruzioni di programmi informatici per personalizzare i circuiti elettronici, al fine di eseguire realizzazioni della presente esposizione.

[0059] In vari esempi, i sistemi e i metodi descritti nella presente esposizione possono essere trattati in termini di moduli. Il termine „modulo“ qui utilizzato si riferisce a un dispositivo, componente o disposizione di componenti reale, implementato tramite un hardware, come ad esempio tramite un circuito integrato specifico di un'applicazione (ASIC) o FPGA, o come una combinazione di hardware e software, come ad esempio tramite un sistema a microprocessore e un insieme di istruzioni per implementare le funzionalità del modulo, che (mentre viene eseguito) trasforma il sistema a microprocessore in un dispositivo per scopi specifici. Un modulo può anche essere implementato come una combinazione dei due, con alcune funzioni facilitate solo dall'hardware e altre funzioni facilitate da una combinazione di hardware e software. In determinate implementazioni, almeno una porzione, e in alcuni casi tutte le porzioni, di un modulo potrebbero essere eseguite sul processore di un sistema informatico. Di conseguenza, ogni modulo può essere realizzato in una varietà di configurazioni adatte e non deve essere limitato ad una particolare implementazione qui esemplificata.

[0060] Per motivi di chiarezza, non tutte le caratteristiche di routine delle realizzazioni sono qui riportate. Sarebbe auspicabile che nello sviluppo di qualsiasi implementazione effettiva della presente esposizione venissero prese numerose decisioni specifiche dell'implementazione al fine di raggiungere gli obiettivi specifici dello sviluppatore, e questi obiettivi specifici variano a seconda delle diverse implementazioni e dei diversi sviluppatori. Resta inteso che un tale sforzo di sviluppo può essere complesso e richiederebbe molto tempo, ma sarebbe comunque un'impresa facile per coloro che hanno un'ordinaria competenza nell'arte che si avvantaggiano di questa esposizione.

[0061] Inoltre, è da intendersi che la fraseologia o la terminologia qui utilizzata ha lo scopo di descrizione e non di restrizione, cosicché la terminologia o la fraseologia della presente specifica deve essere interpretata da chi è competente nell'arte alla luce degli insegnamenti e degli orientamenti qui presentati, in combinazione con le conoscenze di chi è competente nell'arte o nelle arti pertinenti. Inoltre, a nessun termine della specifica o delle rivendicazioni deve essere attribuito un significato non comune o speciale, a meno che non sia esplicitamente indicato come tale.

[0062] I vari esempi qui illustrati comprendono gli equivalenti noti, presenti e futuri, dei moduli noti cui si fa riferimento a titolo illustrativo. Inoltre, sebbene siano stati illustrati e descritti esempi e applicazioni, risulta evidente agli esperti del settore che hanno il vantaggio di avvalersi della presente esposizione che sono possibili molte più modifiche rispetto a quelle citate in precedenza, senza discostarsi dai concetti inventivi qui esposti.

Claims (15)

1. Un metodo per prevenire la diffusione di malware in una rete di dati sincronizzati, comprendente: la ricezione, in un primo momento, da parte di un server collegato a una pluralità di dispositivi informatici, di un file da un primo dispositivo informatico della pluralità di dispositivi informatici; il monitoraggio delle modifiche apportate al file memorizzato sul server; in risposta al rilevamento di una modifica, la creazione di un record indicativo della modifica al file; la ricezione, da un secondo dispositivo informatico della pluralità di dispositivi informatici, di una richiesta di download per scaricare il file dal server, dove la richiesta di download è ricevuta in un secondo momento successivo al primo; la determinazione se esiste o meno di almeno un record che indichi una modifica al file tra il primo e il secondo momento; in risposta alla determinazione dell'esistenza del record, la scansione del file alla ricerca di malware; e in risposta alla determinazione del fatto che il file memorizzato sul server è associato a malware, la negazione della richiesta di download.

2. Il metodo secondo la rivendicazione 1, in cui la ricezione del file comprende: la rilevazione di una richiesta di caricamento del file dal primo dispositivo informatico; la richiesta, al primo dispositivo informatico, di un risultato di scansione che indichi se il file è associato a malware; in risposta alla ricezione di un risultato di scansione che indichi che il file non è associato a malware, l'accoglimento della richiesta di caricamento e la memorizzazione del file sul server in un primo momento.

3. Il metodo secondo una delle rivendicazioni da 1 a 2, in cui il record fa parte di un registro distribuito che memorizza, in una pluralità di record, le modifiche apportate ai file sul server.

4. Il metodo secondo la rivendicazione 3, in cui il registro distribuito memorizza le modifiche e i risultati di scansione esclusivamente su file sincronizzati tra la pluralità di dispositivi informatici e in cui ogni record della pluralità di record è verificato dalla pluralità di dispositivi informatici.

5. Il metodo secondo una delle rivendicazioni da 1 a 4, comprendente inoltre: l'esecuzione di un'azione correttiva che comprenda una o più delle seguenti operazioni: rimuovere il file dal server, mettere il file in quarantena sul server, e richiedere, al primo dispositivo informatico, una versione del file non associata a malware.

6. Il metodo secondo una delle rivendicazioni da 1 a 5, comprendente inoltre: in risposta alla determinazione del fatto che il file memorizzato sul server non è associato a malware, l'approvazione della richiesta di download e la trasmissione del file al secondo dispositivo informatico.

7. Il metodo secondo la rivendicazione 6, comprendente inoltre: la creazione di un altro record che includa i risultati della scansione eseguita sul file memorizzato sul server, dove i risultati indicano che il file non è associato a malware.

8. Il metodo secondo la rivendicazione 7, comprendente inoltre: la ricezione, da un terzo dispositivo informatico, di un'altra richiesta di download per scaricare il file dal server, in cui l'altra richiesta di download viene ricevuta in un terzo momento successivo al secondo; in risposta alla determinazione del fatto che l'altro record è un record più recente del file, la concessione dell'altra richiesta di download senza eseguire un'altra scansione del file.

9. Un sistema per prevenire la diffusione di malware in una rete di dati sincronizzati, il quale sistema comprende: una memoria; e un processore hardware accoppiato in modo comunicativo con la memoria e configurato per: ricevere, in un primo momento da un server collegato a una pluralità di dispositivi informatici, un file da un primo dispositivo informatico della pluralità di dispositivi informatici; monitorare le modifiche al file memorizzato sul server; in risposta al rilevamento di una modifica, generare un record indicativo della modifica al file; ricevere, da un secondo dispositivo informatico della pluralità di dispositivi informatici, una richiesta di download per scaricare il file dal server, in cui la richiesta di download è ricevuta in un secondo momento successivo al primo; determinare se esiste almeno un record che indichi una modifica del file tra il primo e il secondo momento; in risposta alla determinazione dell'esistenza del record, scansionare il file alla ricerca di malware; e in risposta alla determinazione che il file memorizzato sul server è associato a malware, negare la richiesta di download.

10. Il sistema secondo la rivendicazione 9, in cui il processore hardware è configurato per ricevere il file tramite: la rilevazione di una richiesta di caricamento del file dal primo dispositivo informatico; la richiesta, al primo dispositivo informatico, di un risultato di scansione che indichi se il file è associato a malware; e in risposta alla ricezione di un risultato di scansione che indichi che il file non è associato a malware, l'accoglimento della richiesta di caricamento e la memorizzazione del file sul server in un primo momento.

11. Il sistema secondo una delle rivendicazioni da 9 a 10, in cui il record fa parte di un registro distribuito che memorizza, in una pluralità di record, le modifiche apportate ai file sul server.

12. Il sistema secondo la rivendicazione 11, in cui il registro distribuito memorizza le modifiche e i risultati di scansione esclusivi dei file sincronizzati tra la pluralità di dispositivi informatici e in cui ogni record della pluralità di record è verificato dalla pluralità di dispositivi informatici.

13. Il sistema secondo una delle rivendicazioni da 9 a 12, in cui il processore hardware è inoltre configurato per: eseguire un'azione correttiva comprendente una o più delle seguenti operazioni: rimuovere il file dal server, mettere il file in quarantena sul server, e richiedere, al primo dispositivo informatico, una versione del file non associata a malware.

14. Il sistema secondo una delle rivendicazioni da 9 a 13, in cui il processore hardware è inoltre configurato per: in risposta alla determinazione del fatto che il file memorizzato sul server non è associato a malware, approvare la richiesta di download e trasmettere il file al secondo dispositivo informatico.

15. Il sistema secondo la rivendicazione 14, in cui il processore hardware è inoltre configurato per: generare un altro record che include i risultati della scansione eseguita sul file memorizzato sul server, dove i risultati indicano che il file non è associato a malware.