Sistemi di IA per la rilevazione di attacchi informatici

Nel precedente articolo, abbiamo discusso del concetto di intelligenza, presentato le definizioni standardizzate di (sistemi di) intelligenza artificiale ed evidenziato che in alcuni ambiti come la sicurezza informatica è necessario progettare i sistemi di IA in maniera da tenere in debito conto le possibili mosse di avversario intelligente. Ora vediamo concretamente come questo sia possibile.

Come è possibile realizzare sistemi di IA capaci di operare in ambiente ostile?

Il punto è progettare i sistemi in maniera che le funzionalità e prestazioni siano resilienti a manipolazioni dei dati da parte di un avversario intelligente. Ciò è fondamentale quando si utilizza l'apprendimento automatico, poiché questo meccanismo è intrinsecamente pensato per adattare un modello in base ai dati. Sembrerebbe un problema senza via d'uscita, ma ci sono delle soluzioni ingegneristiche pratiche ed efficaci.

Consideriamo il caso dei sistemi di IA applicati alla rilevazione di intrusioni informatiche (Intrusion Detection System). Un primo punto chiave è assicurarsi che il sistema faccia affidamento sulle informazioni veramente discriminanti che distinguono un attacco da una istanza legittima. Per discriminanti intendo che, per un avversario, la modifica di queste informazioni può indebolire un attacco o renderlo proprio impossibile. Si tratta di caratteristiche che devono essere presenti nei dati perché un attacco sia efficace o abbia realmente successo. La modifica di tali dati ha cioè un costo per l'avversario.

Facciamo un esempio molto semplice. Consideriamo l'applicazione web di Google che fornisce i risultati di ricerca (https://www.google.com/search). Essa riceve la chiave di ricerca tramite il parametro q ed il numero del risultato da cui partire tramite il parametro start (i risultati sono limitati a 10 per ogni pagina). As esempio, per ottenere i risultati associati alla ricerca "adversarial machine learning" a partire dal decimo (start=10), la URL è la seguente (lo spazio, non permesso nelle URL, è codificato dal segno +):

https://www.google.com/search?q=adversarial+machine+learning&start=10

Provate a modificare il valore di start sulla barra degli indirizzi del vostro browser, ad esempio mettendo il valore 20, 30, etc., vedrete che la pagina dei risultati Google sarà diversa.

In generale, chiunque può inserire un valore arbitrario per qualsiasi ingresso dell'applicazione. Ad esempio, un attaccante potrebbe inserire valori (payload) per verificare la presenza di possibile vulnerabilità a SQL injection, al terzo posto nella classifica delle vulnerabilità più comuni TOP 10 OWASP, come questo (start=AND 1):

https://www.google.com/search?q=adversarial+machine+learning&start=AND+1

Supponete ora di voler rilevare questo tipo di attacchi.

Potreste ad esempio collezionare una lista payload più comuni per SQL injection e fare un confronto con i dati in ingresso all'attributo. Questo approccio a "forza bruta" funzionerebbe, ma solo per attacchi strettamente in questa lista. Per un attaccante potrebbe essere piuttosto semplice trovare un payload che voi non avete in lista e realizzare con successo l'attacco senza essere rilevato. Ad esempio lo potrebbe fare in automatico con lo strumento principe sqlmap. Inoltre, la rilevazione avrebbe un costo computazionale che incrementerebbe ad ogni nuovo payload (dovendo, ad ogni richiesta, fare il confronto dell'ingresso con ogni elemento della lista).

Un approccio più efficace potrebbe essere invece addestrare un modello basato su apprendimento automatico sulla base di una lista di payload SQL injection tipici, come fatto qui. In questo caso, il modello sarebbe in grado di rilevare anche payload nuovi, mai visti in fase di addestramento, ma con caratteristiche simili a questi ultimi. Poniamo pure che sia in grado di rilevare tutti i tentativi di SQL injection automatizzati da parte di strumenti come sqlmap. Il costo per un avversario sarebbe maggiore rispetto al caso precedente di rilevazione a forza bruta. Le capacità di rilevazione sarebbero comunque limitate ai soli attacchi di questo tipo, ma ne esistono innumerevoli altri tipi di injection, ad esempio, XML, XPath, command, CRLF e cross-site scripting.

A questo punto, siete determinati. Per ogni categoria di attacco nota, predisponete un classificatore basato su apprendimento automatico/AI. Il costo per l'attaccante dovrebbe essere maggiore rispetto al caso precedente: per evadere la rilevazione dovrebbe escogitare un attacco non coperto dai classificatori. Il vostro sistema potrebbe funzionare bene ma il costo computazionale salirebbe notevolmente in funzione del numero di classificatori che, contemporaneamente o in successione, dovrebbero analizzare i valori dell'attributo. Inoltre, la probabilità di avere falsi allarmi incrementerebbe all'aumentare del numero di classificatori utilizzati (ognuno indipendentemente potrebbe fare una predizione errata). In ogni caso, sareste in grado di rilevare solo ed esclusivamente gli attacchi di tipologia nota che avete tenuto in considerazione, e sareste scoperti di fronte a nuove tipologie di attacchi (ad esempio, che sfruttano vulnerabilità zero-day).

Anche una semplice manipolazione come questa, con un valore negativo (start=-10):
https://www.google.com/search?q=adversarial+machine+learning&start=-10 passerebbe inosservata.

Come fare allora?

Finora abbiamo fatto esempi di una tecnica di rilevazione basata su firme (signature) di attacchi noti, nota come misuse-based. Ampiamente utilizzata anche negli antivirus/antimalware e motivo principale per cui devono essere costantemente aggiornati. Qui i difensori partono intrinsecamente svantaggiati, poiché inermi di fronte a varianti di attacco sufficientemente sofisticate per evadere la rilevazione o a nuove tipologie di attacco. Inoltre, i dati di addestramento sono generati dagli stessi attaccanti, che potenzialmente possono manipolarli a piacimento per rendere vane o compromettere l'apprendimento automatico da parte di un sistema di AI. Un esempio di qualche anno fa, lo trovate qui.

C'è però una tecnica complementare, più potente e robusta di fronte ad un avversario (se correttamente progettata): quella basata su anomalie, nota come anomaly-based.

La tecnica di rilevazione basata su anomalie

Nel caso in esame, potremmo collezionare tutti i valori ricevuti per l'attributo start e delineare la statistica del tipo di dato osservato. Ci accorgeremmo che nella gran parte dei casi start riceve un numero intero, e potremmo prendere questo tipo di dato come normale o legittimo. Potremmo addirittura stabilire qual'è il valore minimo e massimo accettabile per l'intero. Qualsiasi deviazione da questo modello potrebbe sollevare un allarme. E' possibile costruire un sistema di AI che automatizza completamente questa operazione. A questo punto, per l'attaccante le possibilità di realizzare un qualsiasi attacco injection senza essere identificato sono praticamente nulle. Infatti, è necessario sempre inserire un qualche carattere inatteso: ecco cosa intendevo per informazione discriminante. Il costo di una qualsiasi manipolazione per l'attaccante è massimo: inviando un intero nella gamma di valori attesi (imparata automaticamente dall'algoritmo) non è proprio in grado di eseguire un attacco che fa leva su una qualsiasi erronea validazione dell'input.

Attraverso questa tecnica ci focalizziamo su ciò che è normale e possiamo rilevare qualsiasi attacco, noto o sconosciuto, come una anomalia - una deviazione dalla normalità. L'assunto base -tipicamente verificato- è che il profilo normale/tipico del traffico sia legittimo. Il risultato è un modello semplicissimo ma estremamente efficace.

Nell'esempio in esame, ci si attende che la maggior parte del traffico provenga da utenti legittimi, che utilizzano il servizio Google nella maniera attesa, indirizzati dal servizio stesso attraverso le interfacce utente.

E se ciò non fosse verificato?

Questa è certamente una possibilità. Per rendere robusto l'apprendimento, è possibile ad esempio:

• selezionare il traffico utilizzato per l'apprendimento (ad esempio, considerando solo quello di utenti registrati sul sistema);
• prevedere dei limiti all'influenza che ciascuna sorgente di traffico (es. ciascun utente registrato) può avere sul modello appreso;
• stabilire se è effettivamente possibile identificare un profilo proponderante (normale) nel traffico;
• utilizzare dei modelli predefiniti che inglobino la conoscenza a priori del problema (da parte di un esperto) e delle techiche robuste di inferenza statistica;

In questa maniera, un attaccante può avere una influenza molto limitata sull'addestramento e la rilevazione può essere molto robusta ed efficiente.

Badate bene: scelte di progetto che invece non considerano l'ambiente ostile possono portare ad algoritmi incredibilmente vulnerabili, in cui l'attaccante può con pochissimo traffico può creare enormi variazioni nel modello.

Conclusioni

In questo articolo abbiamo esplorato, con un esempio concreto, le principali tecniche utilizzabili per la rilevazione di attacchi informatici, ed evidenziato i vantaggi di quella basata su anomalie di fronte ad un avversario. In realtà, entrambe le tecniche sono utili e complementari: dovrebbero sempre essere combinate opportunamente perché i sistemi di AI possano fornire informazioni sulla tipologia di attacco (misuse-based), e rilevare attacchi nuovi (anomaly-based). L'obiettivo chiave è realizzare sistemi di rilevazione che si focalizzino e facciano affidamento solo su caratteristiche invarianti degli attacchi, che devono essere presenti perché questi abbiano successo.