Sistemi e dipendenze di intelligenza artificiale/apprendimento automatico per la modellazione delle minacce

Di Andrew Marshall, Jugal Parikh, Emre Kiciman e Ram Shankar Siva Kumar

Un ringraziamento speciale a Raul Rojas e all'AETHER Security Engineering Workstream

Novembre 2019

Questo documento è un prodotto finale delle procedure di progettazione AETHER per l'AI Working Group e integra le procedure esistenti di modellazione delle minacce SDL (Security Development Lifecycle) offrendo nuove indicazioni sull'enumerazione e sulla mitigazione delle minacce specifiche per l'intelligenza artificiale e l'apprendimento automatico. È destinato per l'uso come riferimento durante le revisioni di progettazione della sicurezza per gli elementi seguenti:

1. Prodotti/servizi che interagiscono con o dipendono da servizi basati su intelligenza artificiale/apprendimento automatico

2. Prodotti/servizi basati su intelligenza artificiale/apprendimento automatico

Una mitigazione tradizionale delle minacce per la sicurezza è più importante che mai. I requisiti stabiliti da Security Development Lifecycle sono essenziali per creare una base di sicurezza del prodotto, su cui è incentrata questa guida. L'impossibilità di risolvere le minacce tradizionali per la sicurezza apre le porte agli attacchi specifici di intelligenza artificiale/apprendimento automatico trattati in questo documento, sia nel software che nei domini fisici, oltre a vanificare la riduzione dello stack software. Per un'introduzione alle nuove minacce per la sicurezza in questo ambito, vedere Securing the Future of AI and ML at Microsoft (Protezione per il futuro dell'intelligenza artificiale e dell'apprendimento automatico in Microsoft).

In genere il set di competenze dei tecnici della sicurezza e quello dei data scientist non si sovrappongono. Queste indicazioni consentono a entrambe le discipline di elaborare conversazioni strutturate su queste minacce/mitigazioni che rappresentano una novità nella rete senza richiedere ai tecnici della sicurezza di diventare data scientist o viceversa.

Questo documento è suddiviso in due sezioni:

1. "Nuove considerazioni chiave nella modellazione delle minacce" è incentrata su nuovi modi di pensare e nuove domande da porre in fase di modellazione delle minacce nei sistemi di intelligenza artificiale/apprendimento automatico. Si tratta di un playbook destinato a data scientist e tecnici della sicurezza per affrontare discussioni sulla modellazione delle minacce e definire le priorità di mitigazione.
2. "Minacce specifiche per intelligenza artificiale/apprendimento automatico e relative mitigazioni" fornisce informazioni dettagliate su attacchi specifici, oltre alle procedure di mitigazione attualmente adottare per proteggere i prodotti e i servizi Microsoft da tali minacce. Questa sezione è destinata principalmente ai data scientist che potrebbero dover implementare specifiche misure di mitigazione delle minacce conseguentemente al processo di modellazione delle minacce/revisione della sicurezza.

Queste linee guida sono organizzate intorno a una tassonomia delle minacce di Machine Learning antagonista creata da Ram Shankar Siva Kumar, David O'Brien, Kendra Albert, Salome Viljoen e Jeffrey Snover intitolato "Modalità di errore in Machine Learning". Per indicazioni sulla gestione degli eventi imprevisti sulla valutazione delle minacce alla sicurezza descritte in questo documento, vedere la barra dei bug SDL per le minacce di intelligenza artificiale/MACHINE. Tutti questi sono documenti viventi che si evolveranno nel tempo con il panorama delle minacce.

Nuove considerazioni chiave nella modellazione delle minacce: modifica del modo in cui si visualizzano i limiti di attendibilità

Partiamo dal presupposto che i dati di training possano essere compromessi o danneggiati, così come il provider di dati. Per questo motivo è essenziale imparare a rilevare i dati anomali e dannosi, nonché distinguerli dagli altri e ripristinare una situazione normale

Riepilogo

Gli archivi di dati di training e i sistemi che li ospitano fanno parte dell'ambito di modellazione delle minacce. La più grande minaccia per la sicurezza nell'apprendimento automatico è rappresentata dal danneggiamento dei dati dovuto all'assenza di processi standard di rilevamento e mitigazione in quest'ambito, oltre alla dipendenza da set di dati pubblici non attendibili o non curati come origini di dati di training. La capacità di verificare la provenienza e la derivazione dei dati è essenziale per garantirne l'affidabilità ed evitare un ciclo di training di tipo "garbage in, garbage out".

Domande da porre in una verifica della sicurezza

• Come sapere se i dati sono danneggiati o manomessi?

  - Di quale tipo di telemetria si dispone per poter rilevare una differenza nella qualità dei dati di training?

• Il training è basato su input forniti dall'utente?

  - Quale tipo di bonifica/convalida dell'input si esegue sul contenuto?

  - La struttura di questi dati è documentata in modo analogo a Datasheets for Datasets?

• - In caso di training sugli archivi dati online, quali operazioni si eseguono per garantire la sicurezza della connessione tra il modello e i dati?

  - Esiste un modo per segnalare compromessi ai fruitori dei feed?

  - Sono in grado di farlo?

• Qual è il livello di sensibilità dei dati di training?

  - Vengono catalogati oppure si esegue un controllo per l'aggiunta, l'aggiornamento o l'eliminazione di voci di dati?

• Il modello può restituire dati sensibili?

  - Questi dati sono stati ottenuti con l'autorizzazione dall'origine?

• Il modello restituisce solo i risultati necessari per raggiungere l'obiettivo?

• Il modello restituisce punteggi puri di affidabilità o un altro tipo di output diretto che può essere registrato e duplicato?

• Qual è l'effetto del ripristino dei dati di training mediante l'attacco o l'inversione del modello?

• Se i livelli di attendibilità dell'output del modello calano improvvisamente, è possibile capire come/perché, nonché i dati che hanno determinato il calo?

• È stato definito un input ben formato per il modello? In che modo si garantisce che gli input soddisfino questo formato e cosa fare in caso contrario?

• Come capire se gli output non sono corretti, ma non vengono segnalati errori?

• Come sapere se gli algoritmi di training sono resilienti a input antagonisti a livello matematico?

• Come correggere una contaminazione antagonista dei dati di training?

  - È possibile isolare o mettere in quarantena il contenuto antagonista e rieseguire il training dei modelli interessati?

  - È possibile eseguire il rollback o il ripristino di un modello a una versione precedente per ripetere il training?

• Viene applicato l'apprendimento per rinforzo su contenuto pubblico non curato?

• Pensando alla derivazione dei dati, come è possibile monitorare un problema individuato fino alla sua introduzione nel set di dati? Se non è possibile, è un problema?

• È necessario sapere da dove provengono i dati di training e identificare le norme statistiche per iniziare a individuare le anomalie simili

  - Quali elementi dei dati di training sono vulnerabili alle influenze dall'esterno?

  - Chi può contribuire ai set di dati di training?

  - In che modo un utente attacca le origini dei dati di training per danneggiare un concorrente?

Minacce e mitigazioni correlate in questo documento

• Perturbazione antagonista (tutte le varianti)

• Danneggiamento dei dati (tutte le varianti)

Attacchi di esempio

• Messaggi di posta elettronica benigni forzatamente classificati come posta indesiderata o rilevamento trascurato di un esempio dannoso

• Input creati da utenti malintenzionati che riducono il livello di attendibilità della classificazione corretta, soprattutto in scenari a conseguenze elevate

• Rumore inserito in modo casuale da un utente malintenzionato nei dati di origine classificati per diminuire le possibilità che la classificazione corretta venga usata in futuro, riducendo di fatto il livello del modello

• Contaminazione dei dati di training per forzare l'errata classificazione dei punti dati selezionati, determinando azioni specifiche eseguite oppure omesse da un sistema

Identificare le azioni che possono essere eseguite dai modelli o dal prodotto/servizio che possono determinare danni ai clienti online o nel dominio fisico

Riepilogo

Se non mitigati, gli attacchi ai sistemi di intelligenza artificiale/apprendimento automatico possono farsi strada nel mondo fisico. Qualsiasi scenario che possa essere distorto per danneggiare gli utenti in modo psicologico o fisico è un rischio irreversibile per un prodotto/servizio. Questa condizione estende a tutti i dati sensibili relativi ai clienti usati per il training e le scelte di progettazione che possono comportare la perdita di questi punti dati privati.

Domande da porre in una verifica della sicurezza

• Il training viene eseguito con esempi antagonisti? Quale effetto hanno sull'output del modello nel dominio fisico?

• Come si manifesta il trolling nel prodotto/servizio? Come rilevarlo e rispondere in modo appropriato?

• Come fare in modo che il modello restituisca un risultato che induca il servizio a negare l'accesso a utenti legittimi?

• Qual è l'effetto derivante da copia o furto del modello?

• È possibile usare il modello per dedurre l'appartenenza di un utente in un particolare gruppo o semplicemente nei dati di training?

• Un utente malintenzionato può causare danni alla reputazione o reazioni negative a livello pubblico nei confronti del prodotto attraverso l'esecuzione forzata di azioni specifiche?

• In che modo è possibile gestire dati correttamente formattati, ma apertamente influenzati, ad esempio da parte di troll?

• Per ogni interazione o query a cui il modello è esposto, è possibile interrogare il metodo per divulgare i dati di training o la funzionalità del modello?

Minacce e mitigazioni correlate in questo documento

• Inferenza dell'appartenenza

• Inversione del modello

• Furto dei modelli

Attacchi di esempio

• Ricostruzione ed estrazione dei dati di training eseguendo ripetutamente query sul modello per ottenere risultati di massima attendibilità

• Duplicazione del modello stesso tramite corrispondenza completa tra query/risposte

• Esecuzione di query sul modello in modo da rivelare che un elemento specifico di dati privati è stato incluso nel set di training

• Vettura autoguidata indotta a ignorare segnali di stop/semafori

• Bot di conversazione modificati per il trolling di utenti benigni

Identificare tutte le origini delle dipendenze di intelligenza artificiale/apprendimento automatico e i livelli di presentazione front-end nella supply chain di dati/modelli

Riepilogo

Molti attacchi nell'intelligenza artificiale e nell'apprendimento automatico iniziano con accesso legittimo alle API rilevate per fornire l'accesso di query a un modello. Per via della quantità di origini di dati ed esperienze utente interessate, l'accesso per 3^e parti autenticato ma "non appropriato" (si tratta di una zona grigia) ai modelli rappresenta un rischio, in quanto potrebbe fungere da livello di presentazione al di sopra di un servizio fornito da Microsoft.

Domande da porre in una verifica della sicurezza

• Quali clienti o partner sono autenticati per accedere alle API del servizio o del modello?

  - Possono agire come livello di presentazione al di sopra il servizio?

  - È possibile revocare tempestivamente l'accesso in caso di compromissione?

  - Qual è la strategia di ripristino in caso di uso dannoso del servizio o delle dipendenze?

• Una 3^a parte può creare un aspetto intorno al modello per riutilizzarlo per altre finalità e danneggiare Microsoft o i suoi clienti?

• I clienti forniscono direttamente i dati di training?

  - Come vengono protetti i dati?

  - Cosa accade se sono dannosi e il servizio è il target?

• - Qual è l'aspetto di un falso positivo? - Qual è l'impatto di un falso negativo?

• È possibile tracciare e misurare la deviazione dei veri positivi rispetto ai falsi positivi in più modelli?

• Quali tipi di dati di telemetria sono necessari per dimostrare l'attendibilità dell'output del modello ai clienti?

• Identificare tutte le dipendenze delle 3^e parti nella supply chain dei dati di apprendimento automatico/training, non solo il software open source, ma anche i provider di dati

  - Perché vengono usati e come è possibile verificarne l'affidabilità?

• Vengono usati modelli predefiniti di 3^e parti o inviati dati di training a provider MLaaS di 3^e parti?

• Inventariare storie di notizie relative ad attacchi su prodotti/servizi simili. Sapendo che molte minacce di intelligenza artificiale/apprendimento automatico si trasferiscono tra tipi di modelli, qual è l'effetto che questi attacchi hanno sui prodotti?

Minacce e mitigazioni correlate in questo documento

• Riprogrammazione della rete neurale

• Esempi antagonisti nel dominio fisico

• Provider di apprendimento automatico dannosi che recuperano dati di training

• Attacco alla supply chain di apprendimento automatico

• Modello con backdoor

• Dipendenze specifiche di apprendimento automatico compromesse

Attacchi di esempio

• Un provider di MLaaS dannoso esegue un trojan nel modello con un bypass specifico

• Un antagonista individua una vulnerabilità nella dipendenza OSS comune in uso e carica il payload dei dati di training creato per compromettere il servizio

• Un partner senza scrupoli usa API di riconoscimento facciale e crea un livello di presentazione al di sopra del servizio per produrre deep fake.

Minacce specifiche di intelligenza artificiale/apprendimento automatico e relative mitigazioni

N. 1: Perturbazione antagonista

Descrizione

Negli attacchi di tipo perturbativo, l'utente malintenzionato modifica furtivamente la query per ottenere una risposta desiderata da un modello distribuito in produzione[1]. Si tratta di una violazione dell'integrità di input del modello che comporta attacchi di tipo fuzzy, in cui il risultato finale non è necessariamente una violazione di accesso o EOP, ma compromette le prestazioni di classificazione del modello. Tale violazione può anche essere perpetrata da troll che usano determinate parole target in modo che l'intelligenza artificiale li banni, negando in modo efficace il servizio agli utenti legittimi con un nome che corrisponde a una parola "bannata".

[24]

Variant #1a: classificazione errata di destinazione

In questo caso, gli utenti malintenzionati generano un esempio che non si trova nella classe di input del classificatore di destinazione, ma viene classificato dal modello come la classe di input in questione. L'esempio antagonista può apparire come un rumore casuale agli occhi umani, ma gli utenti malintenzionati hanno una conoscenza del sistema di apprendimento automatico di destinazione che permette loro di generare un rumore bianco non casuale, ma che utilizza alcuni aspetti specifici del modello di destinazione. L'antagonista fornisce un esempio di input non legittimo, ma il sistema di destinazione lo classifica come classe legittima.

Esempi

[6]

Soluzioni di prevenzione

• Rinforzo dell'affidabilità antagonista con l'uso dell'attendibilità del modello indotto dal training antagonistiale [19]: gli autori propongono HCNN (Highly Confident Near Neighbor), un framework che combina informazioni di attendibilità e ricerca vicina più vicina, per rafforzare la robustezza antagonista di un modello di base. In questo modo è possibile distinguere tra stime corrette ed errate del modello nelle vicinanze di un punto campionato dalla distribuzione di training sottostante.

• Analisi causale guidata dall'attribuzione [20]: gli autori studiano la connessione tra la resilienza alle perturbazioni antagoniste e la spiegazione basata sull'attribuzione delle singole decisioni generate dai modelli di Machine Learning. Segnalano che gli input antagonisti non sono affidabili nello spazio di attribuzione, ovvero il mascheramento di alcune funzionalità con attribuzione elevata modifica l'indecisione del modello di apprendimento automatico negli esempi antagonisti. Al contrario, gli input naturali sono affidabili nello spazio di attribuzione.

  [20]

Questi approcci possono rendere i modelli di apprendimento automatico più resilienti agli attacchi antagonisti. Per ingannare questo sistema cognitivo a due livelli, infatti, è necessario non solo attaccare il modello originale, ma anche verificare che l'attribuzione generata per l'esempio antagonista sia simile a quella degli esempi originali. Entrambi i sistemi devono essere compromessi contemporaneamente per un attacco antagonista.

Paralleli tradizionali

Elevazione remota dei privilegi poiché l'utente malintenzionato controlla ora il modello

Gravità

Critico

Variant #1b: classificazione errata di origine/destinazione

Questa variante è caratterizzata come un tentativo da parte di un utente malintenzionato di imporre a un modello di restituire l'etichetta desiderata per un determinato input. Il modello restituisce in genere un falso positivo o falso negativo. Il risultato finale è una sorta di acquisizione del controllo sull'accuratezza della classificazione del modello, in cui un utente malintenzionato può indurre quando vuole specifici bypass.

Sebbene questo attacco influisca in modo significativo sull'accuratezza della classificazione, può anche richiedere più tempo per l'esecuzione, dal momento che un antagonista non deve manipolare i dati di origine solo in modo che non vengano più etichettati correttamente, ma anche specificamente con l'etichetta fraudolenta desiderata. Questi attacchi spesso coinvolgono più passaggi o tentativi di forzare la classificazione errata[3]. Se il modello è soggetto ad attacchi di apprendimento induttivo che forzano la classificazione errata mirata, potrebbe non essere rilevabile alcun footprint del traffico dell'utente malintenzionato, in quanto gli attacchi di rilevamento possono essere eseguiti offline.

Esempi

Forzare i messaggi di posta elettronica benigni in modo che vengano classificati come posta indesiderata o far passare inosservato un esempio dannoso. Noti anche come attacchi di evasione o imitazione dei modelli.

Soluzioni di prevenzione

Azioni di rilevamento reattive/difensive

• Implementazione di una soglia di tempo minima tra le chiamate all'API che forniscono i risultati della classificazione. Determina il rallentamento dei test di attacco in più passaggi aumentando la quantità complessiva di tempo necessaria per individuare una perturbazione.

Azioni proattive/protettive

• Funzionalità denoising for Improving Adversarial Robustness [22]: gli autori sviluppano una nuova architettura di rete che aumenta la robustezza antagonista eseguendo la denoizzazione delle funzionalità. In particolare, le reti contengono blocchi che riducono le funzionalità con strumenti non locali o altri filtri; le reti vengono sottoposte a training end-to-end. In combinazione con il training antagonista, le reti con denoising delle funzionalità migliorano in modo sostanziale lo stato dell'arte nell'affidabilità antagonista, nelle impostazioni degli attacchi white-box e black-box.

• Training e regolarizzazione antagonisti: eseguire il training con esempi antagonisti noti per creare resilienza e affidabilità contro gli input dannosi. Può anche essere considerato come una forma di regolarizzazione, che penalizza la norma dei gradienti di input e semplifica la funzione di stima del classificatore (aumentando il margine di input). Include classificazioni corrette con tassi di affidabilità inferiori.

Con la possibilità di investire nello sviluppo di una classificazione monotona con la selezione di funzionalità monotone, l'antagonista non sarà in grado di eludere il classificatore semplicemente inserendo le funzionalità dalla classe negativa [13].

• La compressione delle funzionalità [18] può essere usata per rafforzare i modelli DNN attraverso il rilevamento di esempi antagonisti. Riduce lo spazio di ricerca disponibile per un antagonista, combinando più esempi che corrispondono a vettori di funzionalità diversi nello spazio originale in un uno solo. Confrontando la stima di un modello DNN nell'input originale con quello nell'input compresso, la compressione delle funzionalità consente di rilevare esempi antagonisti. Se gli esempi originali e compressi producono output sostanzialmente diversi dal modello, l'input è probabilmente antagonista. Misurando il disaccordo tra le stime e selezionando un valore di soglia, il sistema può restituire la stima corretta per gli esempi legittimi e rifiutare gli input antagonisti.

  

  [18]

• Difese certificate contro esempi antagonisti [22]: gli autori propongono un metodo basato su un relax semi-definito che restituisce un certificato che per una determinata rete e input di test, nessun attacco può forzare l'errore a superare un determinato valore. In secondo luogo, poiché questo certificato è differenziabile, gli autori lo ottimizzano congiuntamente con i parametri di rete, offrendo un regolarizzatore adattivo che favorisce l'affidabilità verso tutti gli attacchi.

Azioni di risposta

• Emissione di avvisi sui risultati della classificazione con varianza elevata tra i classificatori, soprattutto se da un singolo utente o da un gruppo ridotto.

Paralleli tradizionali

Elevazione remota dei privilegi

Gravità

Critico

Variant #1c: classificazione casuale errata

Si tratta di una variante speciale in cui la classificazione target dell'utente malintenzionato è diversa dalla classificazione di origine legittima. L'attacco riguarda in genere l'inserimento di rumore in modo casuale nei dati di origine classificati per diminuire le possibilità che la classificazione corretta venga usata in futuro[3].

Esempi

Soluzioni di prevenzione

Come la variante 1a.

Paralleli tradizionali

Denial of Service non persistente

Gravità

Importante

Variant #1d: Riduzione della confidenza

Un utente malintenzionato può creare input per ridurre il livello di attendibilità della classificazione corretta, soprattutto in scenari a conseguenze elevate. Questo attacco può anche assumere l'aspetto di un numero elevato di falsi positivi per sopraffare gli amministratori o i sistemi di monitoraggio con avvisi fraudolenti non distinguibili dagli avvisi legittimi [3].

Esempi

Soluzioni di prevenzione

• Oltre alle azioni descritte in Variant #1a, è possibile usare la limitazione degli eventi per ridurre il volume di avvisi da una singola origine.

Paralleli tradizionali

Denial of Service non persistente

Gravità

Importante

#2a avvelenamento da dati mirati

Descrizione

L'obiettivo finale dell'utente malintenzionato è quello di contaminare il modello di computer generato durante la fase di training, in modo che le stime sui nuovi dati vengano modificate nella fase di test[1]. Negli attacchi di poisoning mirati, l'utente malintenzionato vuole creare una classificazione errata di esempi specifici in modo da creare oppure omettere azioni specifiche.

Esempi

Invio di software antivirus come malware per forzarne la classificazione errata come dannosa ed eliminare l'uso di software antivirus mirato nei sistemi client.

Soluzioni di prevenzione

• Definizione di sensori di anomalie per esaminare la distribuzione dei dati su base quotidiana e inviare avvisi in caso di variazioni

  - Misurazione della variazione dei dati di training su base giornaliera, telemetria per deviazione/deriva

• Convalida dell'input (bonifica e controllo dell'integrità)

• Il danneggiamento inserisce esempi di training esterni. Due strategie principali per contrastare questa minaccia sono:

  - Bonifica/convalida dei dati: rimozione degli esempi di danneggiamento dai dati di training - Bagging per contrastare gli attacchi di danneggiamento[14]

  - Difesa di tipo RONI (Reject-on-Negative-Impact)[15]

  -Robust Learning: scegliere algoritmi di apprendimento affidabili in presenza di campioni di avvelenamento.

  -Uno di questi approcci è descritto in [21] in cui gli autori affrontano il problema dell'avvelenamento dei dati in due passaggi: 1) introducendo un nuovo metodo di factorizzazione della matrice affidabile per recuperare il vero spazio secondario e 2) la regressione affidabile dei principi per eliminare le istanze antagoniste in base alla base recuperata nel passaggio (1). Caratterizzano le condizioni necessarie e sufficienti per il recupero del sottospazio reale e sono vincolate alla perdita di stima prevista rispetto alla verità di base.

Paralleli tradizionali

Host con trojan, in cui l'utente malintenzionato persiste nella rete. I dati di training o di configurazione sono compromessi e vengono inseriti/considerati attendibili per la creazione di un modello.

Gravità

Critico

#2b avvelenamento da dati indiscriminati

Descrizione

L'obiettivo è quello di rovinare la qualità/integrità del set di dati attaccato. Molti set di dati sono pubblici/non attendibili/non curati, quindi in questo modo si creano ulteriori dubbi sulla possibilità di individuare in primo luogo tali violazioni dell'integrità dei dati. Il training su dati inconsapevolmente compromessi è una situazione di tipo "garbage in, garbage out". In seguito al rilevamento, la valutazione deve determinare l'entità di dati violati e metterli in quarantena/ripetere il training.

Esempi

Un'azienda scorpora un sito Web noto e attendibile per dati petroliferi futuri in modo da eseguire il training dei modelli. Il sito Web del provider di dati viene conseguentemente compromesso tramite attacchi SQL injection. L'utente malintenzionato può danneggiare quando vuole il set di dati e il modello sottoposto a training non riconosce la contaminazione dei dati.

Soluzioni di prevenzione

Come la variante 2a.

Paralleli tradizionali

Denial of Service autenticato su un asset di valore elevato

Gravità

Importante

#3 Attacchi di inversione del modello

Descrizione

Le funzionalità private usate nei modelli di Machine Learning possono essere recuperate [1]. inclusa la ricostruzione di dati di training privati a cui l'utente malintenzionato non ha accesso. Noti anche come attacchi di tipo "high climbing" nella comunità biometrica [16, 17], individuano l'input che consente di massimizzare il livello di attendibilità restituito, in base alla classificazione corrispondente alla destinazione [4].

Esempi

[4]

Soluzioni di prevenzione

• Le interfacce per i modelli sottoposti a training da dati sensibili richiedono un controllo di accesso avanzato.

• Query con limite di frequenza consentite dal modello

• Implementazione di attività di controllo tra utenti/chiamanti e il modello effettivo eseguendo la convalida dell'input su tutte le query proposte, rifiutando qualsiasi elemento che non soddisfi la definizione di correttezza dell'input da parte del modello e restituendo solo la quantità minima di informazioni necessarie per essere utili.

Paralleli tradizionali

Diffusione di informazioni segrete mirate

Gravità

Il livello predefinito è impostato come importante per la barra dei bug SDL standard, ma diventa critico in caso di estrazione di informazioni personali.

#4 Attacco di inferenza di appartenenza

Descrizione

L'utente malintenzionato può determinare se un record di dati specificato fa parte del set di dati di training del modello o meno[1]. I ricercatori sono stati in grado di stimare la procedura principale di un paziente (ad esempio: chirurgia che il paziente ha attraversato) in base agli attributi (ad esempio, età, sesso, ospedale) [1].

[12]

Soluzioni di prevenzione

I documenti di ricerca che dimostrano la fattibilità di questo attacco indicano la privacy differenziale [4, 9] come una mitigazione efficace. Si tratta di un campo ancora emergente di Microsoft ed AETHER Security Engineering consiglia di creare competenze con investimenti di ricerca in questo ambito. Questa ricerca dovrebbe enumerare le funzionalità di privacy differenziale e valutarne l'efficacia pratica come mitigazioni, quindi progettare modi per ereditare queste difese in modo trasparente sulle piattaforme di servizi online, analogamente al modo in cui la compilazione di codice in Visual Studio offre protezioni di sicurezza attivate integrate, trasparenti per gli sviluppatori e gli utenti.

L'uso del dropout neurale e dello stack dei modelli può rappresentare in un certo modo una mitigazione efficace. L'uso del dropout neurale aumenta non solo la resilienza di una rete neurale a questo attacco, ma anche le prestazioni del modello[4].

Paralleli tradizionali

Privacy dei dati. Vengono eseguite inferenze sull'inclusione di un punto dati nel set di training, ma i dati di training stessi non vengono diffusi

Gravità

Si tratta di un problema di privacy, non di sicurezza. Viene trattato nelle linee guida per la modellazione delle minacce, in quanto i domini si sovrappongono, ma qualsiasi risposta sarebbe determinata dalla privacy, non dalla sicurezza.

Furto di modelli n. 5

Descrizione

Gli utenti malintenzionati ricreano il modello sottostante tramite esecuzione di query legittime. La funzionalità del nuovo modello è identica a quella del modello sottostante[1]. Una volta ricreato, il modello può essere invertito per ripristinare le informazioni sulle funzionalità o creare inferenze sui dati di training.

• Risoluzione delle equazioni: per un modello che restituisce le probabilità della classe tramite output dell'API, un utente malintenzionato può creare query per determinare variabili sconosciute in un modello.

• Ricerca di percorsi: un attacco che sfrutta le peculiarità dell'API per estrarre le "decisioni" prese da un albero durante la classificazione di un input[7].

• Attacco di trasferibilità: un antagonista può eseguire il training di un modello locale, possibilmente eseguendo query di stima sul modello di destinazione, e usarlo per creare esempi antagonisti che si trasferiscono al modello di destinazione[8]. Se il modello viene estratto e individuato come vulnerabile a un tipo di input antagonistico, i nuovi attacchi contro il modello distribuito in produzione possono essere sviluppati completamente offline dall'utente malintenzionato che ha estratto una copia del modello.

Esempi

Nelle impostazioni in cui un modello di apprendimento automatico serve a rilevare comportamenti antagonisti, ad esempio l'identificazione di posta indesiderata, la classificazione di malware e il rilevamento di anomalie di rete, l'estrazione del modello può facilitare gli attacchi di evasione[7].

Soluzioni di prevenzione

Azioni proattive/protettive

• Riduzione/offuscamento dei dettagli restituiti nelle API di stima preservandone al tempo stesso l'utilità per applicazioni "oneste"[7].

• Definizione di una query ben formata per gli input del modello e restituire solo i risultati in risposta a input completati e ben formati corrispondenti al formato.

• Restituzione di valori di affidabilità arrotondati. I chiamanti più legittimati non necessitano di più punti decimali di precisione.

Paralleli tradizionali

Manomissioni non autenticate e di sola lettura dei dati di sistema: diffusione di informazioni mirate di alto valore?

Gravità

Livello importante nei modelli correlati alla sicurezza, altrimenti moderato

N. 6 Riprogrammazione neurale net

Descrizione

Per mezzo di una query appositamente creata da un antagonista, i sistemi di apprendimento automatico possono essere riprogrammati in un'attività che devia dalla finalità originale del creatore[1].

Esempi

Controlli di accesso vulnerabili su un'API di riconoscimento che possono essere incorporati da 3^e parti in app progettate per danneggiare i clienti Microsoft, ad esempio un generatore di deep fake.

Soluzioni di prevenzione

• Autenticazione reciproca client-server<> avanzata e controllo di accesso alle interfacce del modello

• Rimozione degli account all'origine del danneggiamento.

• Identificazione e applicazione di un contratto di servizio per le API. Determinazione di un tempo di correzione accettabile per un problema dopo che è stato segnalato e conferma di non riproducibilità del problema dopo la scadenza del contratto di contratto.

Paralleli tradizionali

Si tratta di uno scenario di abuso. Conviene disabilitare direttamente l'account dell'utente malintenzionato, anziché aprire un evento imprevisto per la sicurezza a riguardo.

Gravità

Da importante a critico

Esempio antagonista nel dominio fisico (atomi di> bit)

Descrizione

Un esempio antagonista è un input/query da un'entità dannosa inviata con l'unico scopo di ingannare il sistema di Machine Learning [1]

Esempi

Questi esempi si possono manifestare nel dominio fisico, ad esempio un'automobile senza pilota che viene indotta a ignorare un segnale di stop a causa di un certo colore di luce (input antagonista) che illumina il segnale, forzando il sistema di riconoscimento delle immagini a non visualizzare più il segnale di stop come tale.

Paralleli tradizionali

Elevazione dei privilegi, esecuzione remota di codice

Soluzioni di prevenzione

Questi attacchi si manifestano in quanto i problemi del livello di apprendimento automatico (il livello degli algoritmi e dei dati sottostante i processi decisionali basati su intelligenza artificiale) non sono stati mitigati. Come per qualsiasi altro sistema fisico *o* software, il livello al di sotto della destinazione può sempre essere attaccato tramite vettori tradizionali. Per questo motivo, le tradizionali procedure di sicurezza sono più importanti che mai, soprattutto con il livello di vulnerabilità non mitigate (il livello degli algoritmi e dei dati) usato tra intelligenza artificiale e software tradizionale.

Gravità

Critico

#8 Provider di Machine Learning dannosi che possono recuperare i dati di training

Descrizione

Un provider dannoso presenta un algoritmo di backdoor, in cui vengono recuperati i dati di training privati. Sono stati in grado di ricostruire visi e testi con il solo modello.

Paralleli tradizionali

Diffusione mirata di informazioni

Soluzioni di prevenzione

I documenti di ricerca che dimostrano la fattibilità di questo attacco indicano la crittografia omomorfica come una mitigazione efficace. Si tratta di un'area ancora con pochi investimenti in Microsoft ed AETHER Security Engineering consiglia di creare competenze con investimenti di ricerca in questo ambito. Questa ricerca dovrebbe enumerare i principi di crittografia omomorfica e valutarne l'efficacia pratica come mitigazioni in presenza di provider dannosi di apprendimento automatico distribuito come servizio.

Gravità

Livello importante se i dati sono informazioni personali, altrimenti moderato

#9 Attacco alla supply chain di ML

Descrizione

A causa di risorse di grandi dimensioni (dati e calcolo) necessari per eseguire il training degli algoritmi, la procedura corrente consiste nel riutilizzare i modelli sottoposti a training da grandi aziende e modificarli leggermente per le attività a portata di mano (ad esempio ResNet è un modello di riconoscimento delle immagini diffuso di Microsoft). Questi modelli vengono curati in un modello Zoo (Caffe ospita modelli di riconoscimento delle immagini comuni). In questo attacco, l'utente antagonista attacca i modelli ospitati in Caffe, causando l'avvelenamento del pozzo per tutti gli altri. [1]

Paralleli tradizionali

• Compromissione di dipendenze non di sicurezza di terze parti

• Archivio di app che ospita inconsapevolmente malware

Soluzioni di prevenzione

• Riduzione al minimo delle dipendenze di terze parti per i modelli e i dati laddove possibile.

• Incorporamento di queste dipendenze nel processo di modellazione delle minacce.

• Capacità di sfruttare l'autenticazione avanzata, il controllo di accesso e la crittografia tra sistemi proprietari e di 3^e parti.

Gravità

Critico

Machine Learning backdoor n. 10

Descrizione

Il processo di training viene esternalizzato a una terza parte dannosa che manomette i dati di training e distribuito in un modello con trojan che forza classificazioni errate mirate, ad esempio la classificazione di un determinato virus come non dannoso[1]. Rappresenta un rischio in scenari di generazione di modelli di apprendimento automatico distribuiti come servizio.

[12]

Paralleli tradizionali

• Compromissione di dipendenze di sicurezza di terze parti

• Meccanismo di aggiornamento software compromesso

• Compromissione dell'autorità di certificazione

Soluzioni di prevenzione

Azioni di rilevamento reattive/difensive

• Il danno è fatto già nel momento in cui viene individuata questa minaccia, quindi il modello e i dati di training forniti dal provider dannoso non possono essere considerati attendibili.

Azioni proattive/protettive

• Training interno di tutti i modelli sensibili

• Catalogazione dei dati di training o conferma di provenienza da una terza parte attendibile con prassi di sicurezza avanzate

• Modellazione di minacce dell'interazione tra il provider MLaaS e i sistemi personali

Azioni di risposta

• Come per la compromissione della dipendenza esterna

Gravità

Critico

#11 Sfruttare le dipendenze software del sistema di Machine Learning

Descrizione

In questo attacco, l'utente malintenzionato NON modifica gli algoritmi, ma sfrutta vulnerabilità del software come il sovraccarico del buffer o il Cross-Site Scripting (XSS)[1]. È ancora più facile compromettere i livelli software sottostanti i sistemi di intelligenza artificiale/apprendimento automatico, anziché attaccare direttamente il livello di apprendimento, quindi è essenziale attuare le tradizionali procedure di mitigazione delle minacce per la sicurezza descritte in Security Development Lifecycle.

Paralleli tradizionali

• Dipendenza software open source compromessa

• Vulnerabilità del server Web (errore di convalida dell'input API, XSS, CSRF)

Soluzioni di prevenzione

Collaborazione con il team addetto alla sicurezza per seguire le procedure consigliate applicabili di Security Development Lifecycle/Operational Security Assurance.

Gravità

Livello variabile. Fino a critico, a seconda del tipo di vulnerabilità software tradizionale.

Bibliografia

[1] Modalità di errore in Machine Learning, Ram Shankar Siva Kumar, David O'Brien, Kendra Albert, Salome Viljoen e Jeffrey Snover, https://learn.microsoft.com/security/failure-modes-in-machine-learning

[2] AETHER Security Engineering Workstream, Data Provenance/Lineage v-team

[3] Esempi antagonisti in Deep Learning: Traits and Divergence, Wei, et al, https://arxiv.org/pdf/1807.00051.pdf

[4] Ml-Leaks: attacchi e difese di inferenza di appartenenza indipendente dai dati e modelli di Machine Learning, Salem, et al, https://arxiv.org/pdf/1806.01246v2.pdf

[5] M. Fredrikson, S. Jha e T. Ristenpart, "Attacchi di inversione dei modelli che sfruttano informazioni di attendibilità e contromisure di base nei procedimenti della Conferenza ACM SIGSAC 2015 su Computer and Communications Security (CCS).

[6] Nicolas Papernot e Patrick McDaniel - Esempi antagonisti nell'apprendimento automatico AIWTB 2017

[7] l furto dei modelli di apprendimento automatico tramite le API di stima, Florian Tramèr, École Polytechnique Fédérale de Lausanne (EPFL); Fan Zhang, Cornell University; Ari Juels, Cornell Tech; Michael K. Reiter, The University of North Carolina at Chapel Hill; Thomas Ristenpart, Cornell Tech

[8] o spazio degli esempi antagonisti trasferibili, Florian Tramèr, Nicolas Papernot, Ian Goodfellow, Dan Boneh e Patrick McDaniel

[9] Comprensione degli attacchi basati su tecniche di inferenza dell'appartenenza su modelli di apprendimento generalizzati Yunhui Long1, Vincent Bindschaedler1, Lei Wang2, Diyue Bu2, Xiaofeng Wang2, Haixu Tang2, Carl A. Gunter1 e Kai Chen3,4

[10] Simon-Gabriel et al., La vulnerabilità antagonista delle reti neurali aumenta con la dimensione di input, ArXiv 2018;

[11] Lyu et al., Una famiglia di regolarizzazione dei gradienti unificata per esempi antagonisti, ICDM 2015

[12] Wild Patterns: Ten Years After the Rise of Adversarial Machine Learning - NeCS 2019 Battista Biggioa, Fabio Destinazioni

[13] Rilevamento di malware avversamente attendibile mediante classificazione monotona, Inigo Incer et al.

[14] Battista Biggio, Igino Corona, Giorgio Fumera, Giorgio Giacinto e Fabio Roli. Bagging di classificatori per contrastare gli attacchi di danneggiamento in attività di classificazione antagoniste

[15] Un rifiuto migliorato sulla difesa a impatto negativo Hongintune Li e Patrick P.K. Chan

[16] Adler. Vulnerabilità nei sistemi di crittografia biometrica. 5ª conferenza internazionale AVBPA, 2005

[17] Galbally, McCool, Fierrez, Marcel, Ortega-Garcia. Sulla vulnerabilità dei sistemi di verifica del viso per gli attacchi di tipo hill climbing. Patt. Rec., 2010

[18] Weilin Xu, David Evans, Yanjun Qi. Squeezing delle funzionalità: rilevamento di esempi antagonisti nelle reti neurali profonde. 2018 Network and Distributed System Security Symposium. 18-21 febbraio.

[19] Rafforzamento dell'affidabilità antagonista mediante l'attendibilità del modello indotta dal training antagonista, XI Wu, Uyeong Jang, Jiefeng Chen, Lingjiao Chen

[20] Analisi causale basata sull'attribuzione per il rilevamento di esempi antagonisti, Susmit Jha, Sunny Raj, Steven Fernandes, Sumit Kumar Jha, Somesh Jha, Gunjan Verma, Brian Jalaian, Ananthram Swami

[21] Regressione lineare affidabile contro il danneggiamento dei dati di training, Chang Liu et al.

[22] Denoising delle funzionalità per migliorare l'affidabilità antagonista, Cihang Xie, Yuxin Wu, Laurens van der Maaten, Alan Yuille, Kaiming He

[23] Difese certificate contro esempi antagonisti, Aditi Raghunathan, Jacob Steinhardt, Percy Liang