CH717594A2 - Sistemi e metodi per il rilevamento di anomalie comportamentali nelle applicazioni. - Google Patents

Abstract

L'invenzione riguarda un sistema e un metodo per rilevare un'anomalia comportamentale in un'applicazione. il metodo può comprendere recuperare (202) identificare (204) almeno una metrica chiave dalle informazioni storiche di utilizzo per un'applicazione su un dispositivo informatico. Il metodo può comprendere generare un modello di regressione (206) configurato per prevedere il comportamento di utilizzo associato all'applicazione e generare un modello statistico (208) configurato per identificare outlier nei dati associati ad almeno una metrica chiave. Il metodo può comprendere ricevere delle informazioni di utilizzo in tempo reale per l'applicazione (210). Il metodo può comprendere prevedere, usando il modello di regressione, un modello d'uso per l'applicazione (212) che indica i valori previsti di almeno una metrica chiave. Dopo aver determinato che le informazioni di utilizzo non corrispondono al modello d'uso previsto (214) e non comprendono un outlier noto (216), il metodo può comprendere rilevare l'anomalia comportamentale (218) e generare un allarme (220).

Description

CAMPO TECNICO

[0001] La presente divulgazione si riferisce al settore della sicurezza dei dati e, più specificamente, a sistemi e metodi per il rilevamento di anomalie comportamentali nelle applicazioni.

STATO DELL'ARTE

[0002] I dati e le applicazioni archiviati sono spesso soggetti ad attacchi informatici dannosi a seconda della loro posizione di archiviazione e delle connessioni di rete associate. Per monitorare intrusioni e malware, le aziende utilizzano sistemi di monitoraggio che rilevano anomalie comportamentali. I sistemi di monitoraggio convenzionali richiedono, tuttavia, la definizione manuale di soglie di allarme per le metriche chiave delle applicazioni. L'impostazione delle soglie di allarme è in primo luogo laboriosa. Le soglie di allarme impediscono anche il rilevamento di comportamenti anomali quando le metriche chiave non rientrano negli intervalli definiti da un amministratore. Per esempio, una soglia di allarme impostata dall'amministratore può identificare come anomala una percentuale di utilizzo della CPU superiore al 65% su un dato server nel periodo tra le 12:00 e le 6:00. Tuttavia, un'entità dannosa che utilizzi solo il 64% dell'elaborazione della CPU non verrebbe rilevata.

[0003] D'altra parte, le soglie di allarme possono anche indurre diversi falsi positivi. Per esempio, un utente autorizzato può in effetti utilizzare il server durante l'intervallo di tempo descritto sopra in modo tale che il 70% dell'elaborazione della CPU sia utilizzato in un punto. Nonostante l'utilizzo da parte di un utente autorizzato, un sistema di monitoraggio convenzionale provocherebbe un falso positivo nel dichiarare un'anomalia. A seconda del modo in cui il sistema è progettato per reagire a un fattore scatenante, l'accesso dell'utente autorizzato può essere reso difficile o impossibile. È pertanto necessario migliorare l'approccio al rilevamento delle anomalie.

SOMMARIO

[0004] Gli aspetti della divulgazione riguardano il campo del rilevamento di un'anomalia comportamentale in un'applicazione. In un esempio, un metodo può comprendere recuperare le informazioni storiche di utilizzo per un'applicazione su un dispositivo informatico. Il metodo può comprendere identificare almeno una metrica chiave dalle informazioni storiche di utilizzo. Il metodo può comprendere generare un modello di regressione configurato per prevedere il comportamento di utilizzo associato all'applicazione in base ai dati associati ad almeno una metrica chiave. Il metodo può comprendere generare un modello statistico configurato per identificare outlier (valori anomali) nei dati associati ad almeno una metrica chiave. Dopo aver generato il modello di regressione e il modello statistico, il metodo può comprendere ricevere informazioni di utilizzo in tempo reale per l'applicazione. Il metodo può comprendere prevedere, usando il modello di regressione, un modello d'uso per l'applicazione indicante i valori previsti di almeno una metrica chiave. Dopo aver determinato che le informazioni di utilizzo ricevute in tempo reale non corrispondono al modello d'uso previsto, il metodo può comprendere determinare tramite il modello statistico se le informazioni di utilizzo comprendono o meno un outlier noto. Dopo aver determinato che le informazioni di utilizzo non comprendono l'outlier noto, il metodo può comprendere rilevare l'anomalia comportamentale. Il metodo può comprendere generare un allarme indicativo dell'anomalia comportamentale.

[0005] In un esempio, le informazioni storiche di utilizzo si sono verificate in un intervallo di tempo periodico e prevedere il modello d'uso comprende inoltre l'utilizzo di una versione del modello di regressione associato all'intervallo di tempo.

[0006] In un esempio, il modello statistico è una distribuzione di probabilità che evidenzia i punti dati associati ad almeno una metrica che non sono anomali.

[0007] In un esempio, almeno una metrica chiave comprende almeno una di (1) connessioni client, (2) latenza, (3) numero di ricerche di account, (4) byte letti e (5) numero di ricerche di file.

[0008] In un esempio, dopo aver determinato che le informazioni di utilizzo ricevute in tempo reale corrispondono al modello d'uso previsto, o che le informazioni di utilizzo comprendono un outlier noto, il metodo può includere determinare che l'anomalia comportamentale non si è verificata e non generare l'allarme.

[0009] In un esempio, determinare che le informazioni di utilizzo ricevute in tempo reale non corrispondono al modello d'uso previsto comprende inoltre determinare che una differenza media tra i valori di almeno una metrica chiave dalle informazioni di utilizzo ricevute in tempo reale e i valori previsti della metrica chiave secondo il modello d'uso previsto supera una differenza di soglia.

[0010] In un esempio, il metodo può comprendere ricevere una risposta all'allarme indicante che l'anomalia comportamentale è un falso positivo e aumentare automaticamente la differenza di soglia.

[0011] In un esempio, il metodo può comprendere ricevere una risposta all'allarme indicante che l'anomalia comportamentale è un falso positivo e regolare sia il modello di regressione che il modello statistico sulla base delle informazioni di utilizzo ricevute in tempo reale, in cui il modello di regressione è riqualificato su un set di dati aggiornato e il modello statistico indica un outlier aggiornato.

[0012] 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 di un supporto informatico non transitorio.

[0013] Il riepilogo semplificato degli aspetti esemplificativi di cui sopra serve a consentire una comprensione basilare della presente divulgazione. Questo riepilogo non è una sintesi esaustiva di tutti gli aspetti contemplati e non intende né identificare elementi chiave o critici di tutti gli aspetti, né delineare la portata di alcuni o di tutti gli aspetti della presente divulgazione. Il suo unico scopo è presentare uno o più aspetti in forma semplificata come preludio alla descrizione più dettagliata della divulgazione che segue. A completamento di quanto precede, uno o più aspetti della presente divulgazione include le caratteristiche descritte ed evidenziate in modo esemplare nelle rivendicazioni.

BREVE DESCRIZIONE DEI DISEGNI

[0014] I disegni accompagnatori, che sono incorporati e costituiscono parte di questa specifica, illustrano uno o più aspetti esemplificativi della presente divulgazione e, insieme alla descrizione dettagliata, servono a spiegarne i principi e le implementazioni.

[0015] La FIG. 1 è un diagramma a blocchi che illustra un sistema per il rilevamento di anomalie comportamentali nelle applicazioni.

[0016] La FIG. 2 è un diagramma di flusso che illustra un metodo per il rilevamento di anomalie comportamentali nelle applicazioni.

[0017] La FIG. 3 presenta un esempio di un sistema informatico generico su cui possono essere implementate delle realizzazioni della presente divulgazione.

DESCRIZIONE DETTAGLIATA

[0018] Nel presente documento sono descritti gli aspetti esemplari nel contesto di un sistema, un metodo e un programma informatico per il rilevamento delle anomalie comportamentali nelle applicazioni. Coloro che hanno un'ordinaria competenza nell'arte si renderanno conto che la seguente descrizione è puramente illustrativa e non intende essere in alcun modo limitativa. Altri aspetti si riveleranno immediatamente a chi è competente nell'arte che si avvarrà di questa divulgazione. Si farà ora riferimento in dettaglio alle implementazioni degli aspetti esemplificativi 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.

[0019] Per affrontare le carenze dei sistemi di monitoraggio convenzionali, un sistema di rilevamento delle anomalie dovrebbe non richiedere alcun lavoro manuale per addestrare i modelli, funzionare per qualsiasi tipo di dispositivo, rilevare automaticamente le anomalie, mettere a punto la definizione delle anomalie in base alle esigenze dell'utente, adattare le soglie in modo che le anomalie possano essere rilevate indipendentemente dal carico del sistema, essere altamente accurato e diminuire gli allarmi-spam (ad esempio, i falsi positivi).

[0020] La FIG. 1 è un diagramma a blocchi che illustra un sistema esemplificativo 100 per il rilevamento di anomalie comportamentali nelle applicazioni. Il sistema di rilevamento delle anomalie (ADS) 102 può essere un modulo di un software di sicurezza come un software antivirus. L'ADS 102 può essere archiviato nel dispositivo di archiviazione 104 per monitorare le anomalie sul dispositivo di archiviazione 104, o può essere archiviato su un dispositivo diverso e comunicare con il dispositivo di archiviazione 104 su una rete come Internet. L'ADS 102 può essere composto da più componenti come il recuperatore di dati 106, il modulo di apprendimento automatico 108, il modulo statistico 110 e il modulo di sicurezza 112.

[0021] In un esempio, il recuperatore di dati 106 dell'ADS 102 può essere configurato per recuperare informazioni storiche di utilizzo di un'applicazione su un dispositivo informatico (ad es. il sistema informatico descritto nella FIG. 3). Le informazioni storiche di utilizzo possono includere dettagli quali quando è stato effettuato l'accesso all'applicazione, da chi, informazioni sullo stato del dispositivo (ad esempio, consumo di RAM, percentuale di utilizzo della CPU, spazio di archiviazione, ecc.), richieste fatte all'applicazione, richieste fatte dall'applicazione, connessioni di rete utilizzate dall'applicazione (ad esempio, indirizzi IP), ecc. In alcuni esempi, le informazioni storiche di utilizzo possono rappresentare tutte le informazioni da quando l'applicazione è stata installata sul dispositivo informatico. In alcuni esempi, le informazioni storiche di utilizzo possono riguardare un determinato intervallo di tempo (ad esempio, dal 1 giugno 2020 alle ore 12:00 al 2 giugno 2020 alle ore 12:00). In alcuni esempi, le informazioni storiche di utilizzo possono riguardare un intervallo di tempo periodico. Per esempio, il recuperatore di dati 106 può recuperare le informazioni di ogni lunedì da quando l'applicazione è stata installata. Sulla base dei dati specifici riguardanti il lunedì, l'ADS 102 può prevedere il comportamento per un lunedì successivo.

[0022] Dalle informazioni storiche di utilizzo, il recuperatore di dati 106 può identificare almeno una metrica chiave. Una metrica chiave può essere, in associazione all'applicazione, un numero di connessioni client, la latenza di comando ed esecuzione, un numero di ricerche di account, una quantità di byte letti e un numero di ricerche di file. Si noti che possono esistere anche molte altre metriche chiave, come la quantità di byte scritti, la durata del tempo di utilizzo, le funzioni a cui si accede nell'applicazione, ecc. Il recuperatore di dati 106 può analizzare le informazioni storiche di utilizzo per identificare almeno una metrica chiave e generare una struttura di dati con dati associati ad almeno una metrica chiave. Per esempio, se la metrica chiave identificata è la quantità di byte letti in associazione all'applicazione, la struttura di dati può includere le marche temporali e i rispettivi numeri di byte letti. Questa struttura di dati è costituita da dati di addestramento 114 ed è utilizzata dall'ADS 102 per generare il modulo di apprendimento automatico 108, che è configurato per prevedere il comportamento di utilizzo associato all'applicazione in base ai dati associati ad almeno una metrica chiave.

[0023] In alcuni esempi, il modulo di apprendimento automatico 108 può essere una macchina a vettori di supporto a una classe (SVM) usata per il rilevamento delle novità. La SVM a una classe può essere addestrata usando metriche chiave acquisite da informazioni storiche di utilizzo. Poiché le anomalie possono essere abbastanza rare, la maggior parte dei dati 114 può indicare solo l'utilizzo corretto di un'applicazione. La SVM a una classe permette di classificare come un'anomalia i dati di utilizzo che appaiono diversi dai dati di addestramento 114 (ossia, le metriche chiave di utilizzo corrette).

[0024] In alcuni esempi, il modulo di apprendimento automatico 108 può essere un algoritmo di apprendimento automatico che mira a un valore di previsione basato su una o più variabili indipendenti. In alcuni esempi, se viene utilizzata solo una metrica chiave, il modulo di apprendimento automatico 108 può utilizzare un modello di regressione lineare. In altri esempi, se più metriche chiave sono considerate nella generazione del modulo 108, viene usato un modello di regressione polinomiale o un modello di regressione lineare multivariabile. L'obiettivo del modulo di apprendimento automatico 108 è quello di apprendere come si è comportata storicamente l'applicazione e quindi prevedere come si comporterà in futuro. Per esempio, se l'applicazione ha avuto una certa latenza e un certo numero di ricerche negli ultimi dieci lunedì tra le 12:00 e le 12:01, ci si può allora aspettare che l'applicazione abbia la stessa latenza e le stesse ricerche in un successivo lunedì. Il modulo di apprendimento automatico 108 può essere addestrato e testato sui dati di addestramento 114 usando un metodo di insegnamento come la discesa stocastica del gradiente.

[0025] L'ADS 102 può anche generare il modulo statistico 110 configurato per identificare gli outlier nei dati associati ad almeno una metrica chiave. Il modulo statistico impiega una distribuzione di probabilità che evidenzia i punti dati associati ad almeno una metrica chiave che non sono anomali. Supponiamo che la metrica chiave sia il numero di byte letti. Per l'intervallo di tempo considerato come il lunedì tra le 12:00 e le 12:01, l'ADS 102 può creare una distribuzione di probabilità indicativa dei byte letti. In questa distribuzione di probabilità, il numero di byte letti che hanno la minore probabilità di verificarsi (e tuttavia di essersi verificati) è considerato come outlier. Per esempio, il 95% delle volte, l'applicazione può aver avuto tra 9 milioni di byte e 10 milioni di byte letti nell'intervallo dato. Tuttavia, il 5% delle volte, l'applicazione ha avuto più di 15 milioni di byte letti nell'intervallo dato. In alcuni esempi, l'ADS 102 può impostare soglie di probabilità per identificare gli outlier. In questo caso, qualunque numero di byte che abbia una probabilità del 5% o meno è considerato come outlier.

[0026] Il modulo di apprendimento automatico 108 e il modulo statistico 110 forniscono insieme un modo per prevedere come probabilmente si comporterà un'applicazione e come l'applicazione potrebbe comportarsi in casi rari. Vi possono essere casi in cui i sistemi di monitoraggio convenzionali dichiarano che un'attività è un'anomalia dannosa. Tuttavia, l'attività può essere associata ad un outlier causato da un utente autorizzato del dispositivo informatico.

[0027] Dopo aver generato il modello di apprendimento automatico (ad esempio, un modello di regressione) e il modello statistico, il recuperatore di dati 106 dell'ADS 102 può ricevere informazioni di utilizzo in tempo reale per l'applicazione. L'ADS 102 può prevedere, usando il modulo di apprendimento automatico 108, un modello d'uso per l'applicazione relativo ad almeno una metrica chiave. Il modello d'uso indica un insieme previsto di valori della metrica chiave in un momento futuro. Per esempio, il modulo di apprendimento automatico 108 può essere fornito con un intervallo di tempo come input e produrrà un numero previsto di byte letti durante l'intervallo. In questo caso, l'output può essere una struttura di dati comprendente un numero di byte letti al secondo.

[0028] Il modulo di sicurezza 112 può essere un modulo configurato per confrontare il modello d'uso previsto con un modello in tempo reale. Per esempio, l'output del modulo di apprendimento automatico 108 può essere costituito da 60 punti dati per un intervallo di tempo associato al lunedì tra le 12:00 e le 12:01 (uno per ogni secondo). I punti dati possono essere un numero previsto di byte letti. Anche il recuperatore di dati 106 può fornire 60 punti dati per lo stesso intervallo di tempo. Questi punti dati possono essere il numero effettivo di byte letti.

[0029] In alcuni esempi, determinare che le informazioni di utilizzo ricevute in tempo reale non corrispondono al modello d'uso previsto comprende determinare che una differenza media tra i valori di almeno una metrica chiave dalle informazioni di utilizzo ricevute in tempo reale e i valori previsti di almeno una metrica chiave secondo il modello d'uso previsto supera una differenza di soglia. Per esempio, il numero medio di byte letti può essere 10 milioni durante l'intervallo di tempo e il numero medio di byte letti previsti può essere 5 milioni. La differenza di soglia può essere un valore iniziale pari a 2 milioni. La differenza tra i valori medi è di 5 milioni, superiore alla differenza di soglia. Di conseguenza, il modulo di sicurezza 112 può determinare che le informazioni di utilizzo sono una potenziale anomalia. Si noti che il numero medio può essere un valore medio, un valore di deviazione standard, un valore mediano, ecc.

[0030] In alcuni esempi, il modulo di sicurezza 112 può confrontare ogni rispettivo punto dati e determinare un errore percentuale nella previsione. Per esempio, il modulo di sicurezza 112 può determinare un errore percentuale tra il primo punto dati nel modello d'uso previsto e il primo punto dati dell'utilizzo effettivo. Per ogni errore percentuale, se l'errore percentuale è maggiore di un errore percentuale di soglia (per esempio, 20%), il modulo di sicurezza 112 può determinare che i dati ricevuti (cioè, le informazioni di utilizzo) non corrispondono al modello d'uso. Per determinare se le informazioni di utilizzo sono una potenziale anomalia, il modulo di sicurezza 112 può determinare il numero di punti dati con errori percentuali maggiori dell'errore percentuale di soglia. Se la maggioranza dei punti dati presenta errori percentuali che superano l'errore percentuale di soglia, le informazioni di utilizzo possono essere identificate come potenziale anomalia. Il passaggio da „potenziale anomalia“ ad „anomalia“ si basa quindi su un modello statistico.

[0031] Più specificamente, il modulo di sicurezza 112 determina se le informazioni di utilizzo ricevute comprendono un outlier noto piuttosto che un'anomalia tramite il modulo statistico 110. Per esempio, un outlier noto può mostrare che l'applicazione in passato aveva in media un po' meno di 15 milioni di byte letti durante un dato intervallo di tempo (mentre il modello di regressione prevedeva al massimo 10 milioni). Se anche le informazioni di utilizzo ricevute mostrano 14,5 milioni di byte letti per un breve periodo di tempo all'interno dell'intervallo di tempo, le informazioni di utilizzo ricevute possono essere considerate come un outlier. Tuttavia, se le informazioni di utilizzo mostrano un numero di byte letti molto più alto (per esempio, 20 milioni di byte letti), il modulo di sicurezza 112 può determinare che questa quantità di byte non è mai stata letta in passato e quindi questo può costituire un'anomalia. Così, dopo aver determinato che le informazioni di utilizzo non comprendono un outlier, il modulo 112 di sicurezza può rilevare l'anomalia comportamentale e generare un allarme indicativo dell'anomalia comportamentale. D'altra parte, dopo aver determinato che le informazioni di utilizzo ricevute in tempo reale corrispondono al modello d'uso previsto, o che le informazioni di utilizzo comprendono l'outlier noto, determinare che l'anomalia comportamentale non si è verificata e non generare l'allarme.

[0032] In alcuni esempi, un'anomalia può essere rilevata quando viene rilevata una finestra comprendente diversi outlier. Per esempio, dopo aver ricevuto le informazioni di utilizzo, l'ADS 102 può generare un altro modello statistico delle informazioni di utilizzo ricevute (in particolare se il comportamento previsto non corrisponde, per conservare la potenza di elaborazione). Le nuove informazioni di utilizzo ricevute possono indicare che durante l'intervallo di tempo il numero di byte letti era circa 14 milioni per il 95% del tempo e solo 7 milioni per il 5% del tempo. Questa percentuale prolungata per la lettura di più di 14 milioni di byte può essere confrontata con una soglia di probabilità anomala (per esempio 70%). Quando la percentuale è maggiore della soglia di probabilità anomala, è possibile determinare che il numero di byte è un outlier, ma la probabilità che l'outlier si verifichi è sufficientemente alta da essere considerata un'anomalia.

[0033] In alcuni esempi, al fine di rilevare un'anomalia comportamentale quando viene rilevato un outlier, il modulo di sicurezza 112 determina se viene rilevato contemporaneamente più di un numero di soglia di metriche chiave esterne. Per esempio, una metrica chiave esterna può essere il numero di byte letti. Un'altra metrica chiave esterna può essere la quantità di latenza. Supponiamo che di 5 metriche chiave tracciate, 3 presentino degli outlier. Dopo aver determinato che una quantità di soglia delle metriche chiave presenta degli outlier, il modulo di sicurezza 112 può rilevare un'anomalia comportamentale. In alcuni esempi, il modulo di sicurezza 112 può rilevare specificamente un'anomalia comportamentale se la quantità di metriche chiave che presentano degli outlier sono metriche chiave indipendenti. Una metrica chiave indipendente può essere una metrica chiave che non viene influenzata da un'altra metrica chiave. Per esempio, il numero di byte letti può essere correlato al numero di ricerche di file. Di conseguenza, se in entrambe le metriche chiave vengono rilevati degli outlier, solo un outlier viene considerato ai fini del confronto con la quantità di soglia. Al contrario, il numero di byte letti può non essere correlato al numero di account di un'applicazione. Di conseguenza, se gli outlier vengono rilevati in entrambe le metriche chiave, possono essere considerati due outlier. L'ADS 102 può tenere traccia di tutte le metriche chiave e di ciascuna delle loro controparti indipendenti in un database.

[0034] Si noti che l'uso del modello statistico facilita la dipendenza dalle soglie da parte del modulo di apprendimento automatico 108. Questo perché anche se l'applicazione non viene utilizzata come storicamente previsto (ad esempio, gli errori percentuali o la differenza media sono troppo diversi rispettivamente da un errore percentuale di soglia o da una differenza di soglia), la verifica della presenza degli outlier riduce al minimo la possibilità di falsi positivi/negativi. Questo perché l'utilizzo che può essere normalmente erroneamente classificato come un'anomalia può essere correttamente classificato come utilizzo normale se l'utilizzo risulta essere un outlier secondo il modello statistico.

[0035] Inoltre, le soglie utilizzate dai moduli 108 e 110 possono essere regolate in base al fatto che l'utilizzo classificato come anomalia sia effettivamente un'anomalia. Per esempio, il modulo di sicurezza 112 può generare un allarme che indica che l'utilizzo dell'applicazione durante un dato intervallo di tempo è un'anomalia. Questo allarme può essere generato su un dispositivo informatico di un utente (ad esempio, un amministratore del dispositivo 104) sotto forma di e-mail, testo, uscita audio, notifica dell'applicazione, ecc. Dopo la generazione dell'allarme, l'ADS 102 può ricevere una risposta all'allarme indicante che l'anomalia comportamentale è un falso positivo. Per esempio, l'allarme può richiedere la conferma se l'utilizzo era da parte dell'utente o di un'entità non autorizzata. L'utente può indicare che l'uso era autorizzato. Di conseguenza, il modulo di sicurezza 112 può regolare le soglie usate dai moduli 108 e 110 (per esempio, riducendole). Nell'esempio della differenza di soglia associata ai valori medi delle metriche chiave (sia prevista che effettiva), il modulo di sicurezza 112 può aumentare automaticamente la differenza di soglia.

[0036] In alcuni esempi, dopo la ricezione di una risposta all'allarme indicante che l'anomalia comportamentale è un falso positivo, il modulo di sicurezza 112 può anche regolare sia il modello di regressione che il modello statistico sulla base delle informazioni di utilizzo ricevute in tempo reale. Più specificamente, l'ADS 102 può riqualificare il modello di regressione utilizzando un set di dati aggiornato dove le informazioni di utilizzo raccolte ricevute in tempo reale sono classificate come non anomale e può rigenerare il modello statistico, che può identificare le informazioni di utilizzo come outlier.

[0037] La FIG. 2 è un diagramma di flusso che illustra un metodo 200 per il rilevamento di anomalie comportamentali nelle applicazioni. Al 202, il recuperatore di dati 106 recupera le informazioni storiche di utilizzo per un'applicazione su un dispositivo informatico. Al 204, il recuperatore di dati 106 identifica almeno una metrica chiave dalle informazioni storiche di utilizzo. Al 206, il sistema di rilevamento delle anomalie 102 genera un modulo di apprendimento 108 configurato per prevedere il comportamento di utilizzo associato all'applicazione in base ai dati associati ad almeno una metrica chiave. Al 208, il sistema di rilevamento delle anomalie 102 genera un modulo statistico 110 configurato per identificare outlier nei dati associati ad almeno una metrica chiave.

[0038] Al 210, il recuperatore di dati 106 riceve le informazioni di utilizzo in tempo reale per l'applicazione. Al 212, il sistema di rilevamento delle anomalie 102 prevede, usando il modulo di apprendimento automatico 108, un modello d'uso per l'applicazione relativo ad almeno una metrica chiave. Al 214, il sistema di rilevamento delle anomalie 102 determina se le informazioni di utilizzo corrispondono al modello d'uso. Dopo aver determinato che le informazioni di utilizzo non corrispondono al modello d'uso, al 216 il sistema di rilevamento delle anomalie 102 determina se le informazioni di utilizzo comprendono un outlier noto. Dopo aver determinato che le informazioni di utilizzo non comprendono un outlier noto, al 218 il modulo di sicurezza 112 rileva un'anomalia comportamentale e al 220 il modulo di sicurezza 112 genera un allarme. Se al 214 o 216 il sistema di rilevamento delle anomalie 102 determina o che le informazioni di utilizzo corrispondono al modello d'uso o che le informazioni di utilizzo comprendono un outlier noto, il metodo 200 ritorna al 210 mentre il sistema di rilevamento delle anomalie 102 continua a controllare le anomalie comportamentali.

[0039] La FIG. 3 è un diagramma a blocchi che illustra un sistema informatico 20 su cui possono essere implementate delle realizzazioni di sistemi e metodi per rilevare anomalie comportamentali nelle applicazioni. Il sistema informatico 20 può essere sotto forma di più dispositivi informatici o sotto forma di un singolo dispositivo informatico, ad esempio un computer da tavolo, 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.

[0040] 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 divulgazione. Per esempio, il processore 21 può eseguire uno qualsiasi dei comandi/passaggi di cui alle FIG. 1-2. La memoria di sistema 22 può essere qualunque memoria per la memorizzazione dei dati qui utilizzati 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.

[0041] 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.

[0042] 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.

[0043] 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 intranet e Internet. Esempi di interfaccia di rete 51 possono includere un'interfaccia Ethernet, un'interfaccia Frame Relay, un'interfaccia SONET e interfacce wireless.

[0044] Aspetti della presente divulgazione possono essere 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 aspetti della presente divulgazione.

[0045] 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 utilizzato nel presente, 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.

[0046] Le istruzioni di programmi informatici descritte nel presente documento 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.

[0047] Le istruzioni di programmi informatici per l'esecuzione delle operazioni della presente divulgazione 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 divulgazione.

[0048] In vari esempi, i sistemi e i metodi descritti nella presente divulgazione 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 speciale. 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 alcune implementazioni, almeno una parte e, in alcuni casi tutte, di un modulo può essere eseguita 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.

[0049] 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 divulgazione 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 potrebbe 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 divulgazione.

[0050] 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.

[0051] Le varie realizzazioni qui illustrate comprendono gli equivalenti noti, presenti e futuri, dei moduli noti cui si fa riferimento a titolo illustrativo. Inoltre, mentre gli aspetti e le applicazioni sono stati mostrati e descritti, è evidente a chi è competente nell'arte e che si avvale della presente divulgazione che molte più modifiche di quelle sopra menzionate sono possibili senza discostarsi dai concetti dell'invenzione qui divulgati.

Claims (16)

1. Un metodo per rilevare un'anomalia comportamentale in un'applicazione, il metodo comprende: recuperare le informazioni storiche di utilizzo per un'applicazione su un dispositivo informatico; identificare almeno una metrica chiave dalle informazioni storiche di utilizzo; generare un modello di regressione configurato per prevedere il comportamento di utilizzo associato all'applicazione in base ai dati associati ad almeno una metrica chiave; generare un modello statistico configurato per identificare gli outlier nei dati associati ad almeno una metrica chiave; dopo aver generato il modello di regressione e il modello statistico, ricevere informazioni di utilizzo in tempo reale per l'applicazione; prevedere, usando il modello di regressione, un modello d'uso per l'applicazione che indichi i valori previsti di almeno una metrica chiave; dopo aver determinato che le informazioni di utilizzo ricevute in tempo reale non corrispondono al modello d'uso previsto, determinare tramite il modello statistico se le informazioni di utilizzo comprendono un outlier noto; dopo aver determinato che le informazioni di utilizzo non comprendono l'outlier noto, rilevare l'anomalia comportamentale; e generare un allarme indicativo dell'anomalia comportamentale.

2. Il metodo secondo la rivendicazione 1, in cui le informazioni storiche di utilizzo si sono verificate in un intervallo di tempo periodico e in cui prevedere il modello d'uso comprende inoltre l'utilizzo di una versione del modello di regressione associato all'intervallo di tempo.

3. Il metodo secondo la rivendicazione 1, in cui il modello statistico è una distribuzione di probabilità che evidenzia i punti dati associati ad almeno una metrica che non sono anomali.

4. Il metodo secondo la rivendicazione 1, in cui l'almeno una metrica chiave comprende almeno uno di: (1) connessioni client, (2) latenza, (3) numero di ricerche di account, (4) byte letti, e (5) numero di ricerche di file.

5. Il metodo secondo la rivendicazione 1, comprendente inoltre: dopo aver determinato che le informazioni di utilizzo ricevute in tempo reale corrispondono al modello di utilizzo previsto, o che le informazioni di utilizzo comprendono l'outlier noto, determinare che l'anomalia comportamentale non si è verificata e non generare l'allarme.

6. Il metodo secondo la rivendicazione 1, in cui determinare che le informazioni di utilizzo ricevute in tempo reale non corrispondono al modello d'uso previsto comprende inoltre: determinare che una differenza media tra i valori di almeno una metrica chiave dalle informazioni di utilizzo ricevute in tempo reale e i valori previsti di almeno una metrica chiave secondo il modello d'uso previsto supera una differenza di soglia.

7. Il metodo secondo la rivendicazione 6, comprendente inoltre: ricevere una risposta all'allarme che indica che l'anomalia comportamentale è un falso positivo; aumentare automaticamente la differenza di soglia.

8. Il metodo secondo la rivendicazione 1, comprendente inoltre: ricevere una risposta all'allarme che indica che l'anomalia comportamentale è un falso positivo; regolare sia il modello di regressione che il modello statistico in base alle informazioni di utilizzo ricevute in tempo reale, in cui il modello di regressione è riqualificato su un set di dati aggiornato e il modello statistico indica un outlier aggiornato.

9. Un sistema per rilevare un'anomalia comportamentale in un'applicazione, in cui il sistema comprende: un processore hardware configurato per: recuperare le informazioni storiche di utilizzo per un'applicazione su un dispositivo informatico; identificare almeno una metrica chiave dalle informazioni storiche di utilizzo; generare un modello di regressione configurato per prevedere il comportamento di utilizzo associato all'applicazione in base ai dati associati ad almeno una metrica chiave; generare un modello statistico configurato per identificare gli outlier nei dati associati ad almeno una metrica chiave; dopo aver generato il modello di regressione e il modello statistico, ricevere informazioni di utilizzo in tempo reale per l'applicazione; prevedere, usando il modello di regressione, un modello d'uso per l'applicazione che indichi i valori previsti di almeno una metrica chiave; dopo aver determinato che le informazioni di utilizzo ricevute in tempo reale non corrispondono al modello d'uso previsto, determinare tramite il modello statistico se le informazioni di utilizzo comprendono un outlier noto; dopo aver determinato che le informazioni di utilizzo non comprendono l'outlier noto, rilevare l'anomalia comportamentale; e generare un allarme indicativo dell'anomalia comportamentale.

10. Il sistema secondo la rivendicazione 9, in cui le informazioni storiche di utilizzo si sono verificate in un intervallo di tempo periodico e in cui la previsione del modello d'uso comprende inoltre l'utilizzo di una versione del modello di regressione associato all'intervallo di tempo.

11. Il sistema secondo la rivendicazione 9, in cui il modello statistico è una distribuzione di probabilità che evidenzia i punti dati associati ad almeno una metrica che non sono anomali.

12. Il sistema secondo la rivendicazione 9, in cui almeno una metrica chiave comprende almeno uno di: (1) connessioni client, (2) latenza, (3) numero di ricerche di account, (4) byte letti, e (5) numero di ricerche di file.

13. Il sistema secondo la rivendicazione 9, in cui il processore hardware è inoltre configurato per: dopo aver determinato che le informazioni di utilizzo ricevute in tempo reale corrispondono al modello d'uso previsto, o che le informazioni di utilizzo comprendono l'outlier noto, determinare che l'anomalia comportamentale non si è verificata e non generare l'allarme.

14. Il sistema secondo la rivendicazione 9, in cui il processore hardware è configurato per determinare che le informazioni di utilizzo ricevute in tempo reale non corrispondono al modello d'uso previsto: determinare che una differenza media tra i valori di almeno una metrica chiave dalle informazioni di utilizzo ricevute in tempo reale e i valori previsti di almeno una metrica chiave secondo il modello d'uso previsto supera una differenza di soglia.

15. Il sistema secondo la rivendicazione 14, in cui il processore hardware è inoltre configurato per: ricevere una risposta all'allarme che indica che l'anomalia comportamentale è un falso positivo; aumentare automaticamente la differenza di soglia.

16. Il sistema secondo la rivendicazione 9, in cui il processore hardware è inoltre configurato per: ricevere una risposta all'allarme che indica che l'anomalia comportamentale è un falso positivo; regolare sia il modello di regressione che il modello statistico in base alle informazioni di utilizzo ricevute in tempo reale, in cui il modello di regressione è riqualificato su un set di dati aggiornato e il modello statistico indica un outlier aggiornato.