Condividi tramite

Valutazione dei rischi di intelligenza artificiale per i tecnici di Machine Learning

  • Articolo

Nonostante i motivi convincenti per proteggere i sistemi di Machine Learning, il sondaggio di Microsoft che si estende su 28 aziende ha rilevato che la maggior parte dei professionisti del settore ha ancora in mente di prendere in considerazione l'apprendimento automatico antagonista (ML). Venticinque delle 28 aziende hanno indicato che non hanno gli strumenti giusti per proteggere i propri sistemi di Machine Learning. Inoltre, stanno cercando in modo esplicito indicazioni. Abbiamo scoperto che la mancanza di preparazione non è limitata alle organizzazioni più piccole, che vanno da fortune 500 aziende, governi e organizzazioni non profit. I clienti riconoscono la necessità di proteggere i sistemi di IA, ma semplicemente non sanno come.

Questo documento è un primo passaggio per le organizzazioni per valutare il comportamento di sicurezza dei sistemi di intelligenza artificiale. Ma invece di aggiungere un altro framework per le organizzazioni da seguire, abbiamo tentato di fornire il contenuto in modo che possa essere bloccato nei framework tradizionali di valutazione dei rischi per la sicurezza.

Per questo documento sono previsti tre obiettivi:

  • Offrire una prospettiva completa alla sicurezza del sistema di intelligenza artificiale. È stato esaminato ogni elemento del ciclo di vita del sistema di intelligenza artificiale in un'impostazione di produzione: dalla raccolta dei dati all'elaborazione dei dati alla distribuzione del modello. Abbiamo anche tenuto conto della supply chain di intelligenza artificiale e dei controlli e dei criteri relativi alla pianificazione del backup, del ripristino e dell'emergenza correlati ai sistemi di IA.
  • Delineare le minacce agli asset di intelligenza artificiale critici e indicazioni per proteggerle. Per aiutare direttamente i tecnici e i professionisti della sicurezza, abbiamo enumerato la dichiarazione delle minacce in ogni passaggio del processo di compilazione del sistema di intelligenza artificiale. Successivamente, viene fornito un set di linee guida che sovrappongono e rafforzano le procedure esistenti nel contesto dei sistemi di intelligenza artificiale.
  • Consentire alle organizzazioni di eseguire valutazioni dei rischi per la sicurezza dell'IA. Il framework consente di raccogliere informazioni sullo stato corrente di sicurezza dei sistemi di IA in un'organizzazione, eseguire l'analisi dei gap e tenere traccia dello stato di avanzamento del comportamento di sicurezza.

L'abbiamo formulata insieme agli stakeholder di Microsoft, con rappresentanti di Sicurezza di Azure, Strategia di intelligenza artificiale responsabile in ingegneria, Microsoft Security Response Center, Sicurezza di Azure e intelligenza artificiale, etica ed effetti in ingegneria e ricerca (Aether).

Introduzione

È consigliabile usare questo documento per iniziare la discussione sulla protezione dei sistemi di intelligenza artificiale allineati alle attività di sicurezza delle informazioni e agli obiettivi aziendali. Il documento è incentrato sui sistemi di IA e sull'inclusione dei controlli tradizionali perché i sistemi di intelligenza artificiale sono basati sull'infrastruttura IT tradizionale.

Vengono illustrate le aree seguenti correlate ai sistemi di intelligenza artificiale.

Controlli amministrativi Descrizione
Criteri di sicurezza di Machine Learning Controlli e criteri relativi ai criteri documentati che regolano l'apprendimento automatico, l'intelligenza artificiale e la sicurezza delle informazioni.
Controlli tecnici Descrizione
Raccolta di dati Controlli e criteri correlati alla raccolta, all'archiviazione e alla classificazione dei dati usati per l'apprendimento automatico e l'intelligenza artificiale.
Elaborazione dei dati Controlli e criteri relativi all'elaborazione e alla progettazione dei dati usati per l'apprendimento automatico e l'intelligenza artificiale.
Training del modello Controlli e criteri relativi alla progettazione, al training e alla convalida dei modelli.
Distribuzione del modello Controlli e criteri relativi alla distribuzione dei modelli e all'infrastruttura di supporto.
Monitoraggio del sistema Controlli e criteri relativi al monitoraggio continuo dei sistemi di Machine Learning.
Gestione degli eventi imprevisti Controlli e criteri relativi alla gestione degli eventi imprevisti correlati al sistema di intelligenza artificiale.
Continuità aziendale e ripristino di emergenza Controlli e criteri relativi alla perdita di proprietà intellettuale tramite il furto del modello, la riduzione del servizio o altre vulnerabilità specifiche dell'IA.

Il framework esistente di controlli e criteri è stato adattato dallo standard ISO27001:2013 più diffuso ed è stato mappato attraverso il processo di compilazione del sistema di intelligenza artificiale, dalla fase di raccolta dei dati alla risposta alle minacce ai sistemi di intelligenza artificiale. Le organizzazioni potrebbero avere alcuni o tutti i controlli esistenti implementati da ISO27001:2013 o già conformi a diversi framework di rischio (NIST 800-53, PCI-DSS, FedRamp e così via) come parte degli sforzi esistenti per la sicurezza delle informazioni.

La mancata protezione adeguata dei sistemi di IA aumenta il rischio non solo per i sistemi di IA affrontati in questa valutazione, ma più in generale per l'intero ambiente informatico e di conformità.

L'obiettivo di questo documento non è sostituire nessuno di questi sforzi esistenti, ma descrivere la protezione dei sistemi di intelligenza artificiale dal punto di vista degli strumenti e dei framework esistenti ed estenderlo a tutte le parti del processo di compilazione dell'intelligenza artificiale.

Le linee guida elencate di seguito non sono prescrittive, perché ciò richiederebbe più contesto, ad esempio la piattaforma sottostante, il tipo di dati sottostante e la scelta dell'algoritmo. Se si è un cliente di Azure Machine Learning, vedere l'articolo Sicurezza e governance aziendali.

Gravità suggerita, probabilità, impatto

Non tutti i controlli sono di importanza critica per la sicurezza di un sistema di intelligenza artificiale. Pertanto, per classificare correttamente il lavoro, ogni controllo deve essere valutato dall'organizzazione con una classificazione di gravità rilevante per l'impatto aziendale di non implementare un determinato controllo. Un'organizzazione potrebbe scegliere di accettare il rischio di un controllo critico e implementare invece un controllo di compensazione per ridurre il rischio. In definitiva, queste valutazioni sono utili per guidare il processo decisionale basato sul rischio invece di prescrivere le attività.

Gravità

La gravità di una compromissione dipenderà dal caso d'uso del modello di intelligenza artificiale. Fortunatamente, se i dati o i sistemi usati erano di importanza critica prima dell'integrazione di Machine Learning, dovrebbe rimanere invariato. Analogamente, se il modello usato è "off-the-shelf" senza altri input, a seconda del contesto in cui viene usato il modello, è probabile che la gravità di una compromissione sia inferiore. Tecniche come la privacy differenziale possono ridurre il potenziale impatto di una compromissione. Tuttavia, questo contesto non riduce la criticità del sistema, dei dati o del modello. È consigliabile proteggere i modelli usando una strategia di difesa avanzata anziché basarsi su un'implementazione difensiva.

Livello di gravità suggerito

Suggerito come critico

  • Se viene eseguito il training del modello di intelligenza artificiale o inserisce dati personali sensibili, dati classificati o dati regolati da requisiti di conformità, ad esempio PCI, HIPAA, GLBA e così via.
  • Se il modello di intelligenza artificiale viene usato in un'applicazione o in un sistema business critical, in modo che la compromissione abbia un impatto negativo elevato sulle operazioni aziendali
  • Se il modello di intelligenza artificiale viene usato nelle applicazioni in cui il danno o il danno fisico o la morte è un possibile risultato
  • Se il modello di intelligenza artificiale viene usato in un sistema che supporta l'infrastruttura critica (ad esempio, acqua, alimentazione, integrità)

Consigliato come alto

  • Se il modello di intelligenza artificiale viene sottoposto a training o inserisce dati personali sensibili, informazioni riservate o dati altrimenti considerati critici dall'organizzazione
  • Se la compromissione di questo modello di intelligenza artificiale avrebbe un impatto elevato ma con ambito sulle operazioni aziendali
  • Se il modello di intelligenza artificiale viene usato in applicazioni o sistemi critici per l'azienda

Suggerito come medio

  • Se viene eseguito il training del modello di intelligenza artificiale in un subset di dati di training che contiene tipi di dati sensibili
  • Se la compromissione di questo modello di intelligenza artificiale avrebbe implicazioni per i modelli distribuiti nell'ambiente di produzione
  • Se il modello di intelligenza artificiale viene usato in applicazioni non critiche ma aziendali
  • Se il modello di intelligenza artificiale non viene usato nell'ambiente di produzione ma contiene informazioni sui modelli di produzione

Suggerito come basso

  • Se viene eseguito il training del modello di intelligenza artificiale sui dati non usati nell'ambiente di produzione
  • Se il modello di intelligenza artificiale non viene usato nell'ambiente di produzione e non contiene informazioni sui modelli di produzione

Suggeriti come informativi

  • Se i dati non vengono classificati da un'origine verificata
  • Se il modello di intelligenza artificiale non viene usato nell'ambiente di produzione

Probabilità

La probabilità ha due componenti principali, la disponibilità del modello e la disponibilità delle tecniche. Per ridurre la probabilità di un attacco, un'organizzazione deve implementare controlli che:

  1. Rimuovere la superficie di attacco o rendere la superficie di attacco più difficile da enumerare.
  2. Assicurarsi che la registrazione e gli avvisi funzionino come progettato per garantire una risoluzione rapida dei problemi.
  3. Assicurarsi che tutti i sistemi di supporto siano aggiornati con i requisiti di sicurezza.

I controlli possono includere endpoint di controllo, segmentazione di rete o limitazione della frequenza. È necessario prestare particolare attenzione ai flussi di traffico e ai diagrammi di rete o pipeline, ad esempio un utente malintenzionato che compromette e si trova all'esterno e lavora all'indietro attraverso una pipeline.

Impatto

L'impatto è correlato alle conseguenze dell'organizzazione. È consigliabile iniziare a acquisire familiarità con diversi modi in cui i sistemi di Machine Learning possono essere attaccati e prendere in considerazione i modi in cui i modelli di produzione possono influire sull'organizzazione. Per altre informazioni, vedere l'articolo Modalità di errore in Machine Learning. Al termine di questa familiarità, è possibile eseguire il mapping a una matrice di gravità.

Matrice di gravità

La tabella seguente è una matrice di gravità dei rischi e della vulnerabilità di base per iniziare. È consigliabile compilare una categorizzazione simile tramite la convocazione di architetti della sicurezza, tecnici di Machine Learning e membri del red team di intelligenza artificiale.

Tipo di attacco Probabilità Impatto Sfruttabilità
Estrazione Alto Basso Elevato
Evasione Alto Medio Alto
Inferenza Medio Medio Medio
Inversione Medio Alto Medio
Avvelenamento Ridotto Alto Basso

"La progettazione e lo sviluppo di un'intelligenza artificiale sicura è un elemento fondamentale dello sviluppo di prodotti di intelligenza artificiale in BCG. Poiché la società deve proteggere i sistemi di IA diventa sempre più evidente, gli asset come Il framework di gestione dei rischi per la sicurezza della sicurezza dell'intelligenza artificiale di Microsoft possono essere contributi fondamentali. Microsoft implementa già le procedure consigliate disponibili in questo framework nei sistemi di intelligenza artificiale che sviluppiamo per i nostri clienti e siamo entusiasti che Microsoft abbia sviluppato e open source questo framework a vantaggio dell'intero settore". —Jack Molloy, Senior Security Engineer, Boston Consulting Group

Uso di base

Il resto del documento segue questa struttura:

  • Un controllo di rischio contiene una descrizione dell'area a cui si riferisce il controllo.
  • L'obiettivo del controllo e quello che dovrebbe raggiungere.
  • Dichiarazione di minaccia che fornisce una descrizione del rischio da attenuare.
  • Linee guida per l'implementazione di un controllo. Sappiamo che non tutte le linee guida possono essere implementate per motivi aziendali legittimi. È consigliabile documentare indicazioni che non possono essere implementate.

La tabella seguente è un controllo estratto dalla valutazione dei rischi dei sistemi di intelligenza artificiale, vengono aggiunte note per descrivere ogni parte di una struttura delle categorie di rischio.

Controllo di esempio

Come leggerlo

1. Raccolta dati

Categoria primaria

Controlli e criteri relativi alla raccolta e all'archiviazione dei dati da tutte le origini usate per l'apprendimento automatico e l'intelligenza artificiale.

Vengono descritti i controlli di questa categoria a livello generale.

2. Origini dati

Categoria di controllo

Obiettivo: garantire l'integrità dei dati raccolti usati per i modelli sottoposti a training.

Deve descrivere il rischio risolto con i controlli.

Dichiarazione delle minacce: i dati vengono raccolti da origini non attendibili che potrebbero contenere dati personali sensibili, altri dati indesiderati che potrebbero influire sulla sicurezza di un modello o presentano rischi di conformità all'organizzazione.

Istruzione che descrive il risultato della mancata implementazione del controllo.

Controllo: i dati devono essere raccolti da origini attendibili. È consigliabile mantenere e aggiornare un elenco di origini attendibili. Approvazioni per la raccolta di dati non attendibili deve essere considerato caso per caso.

Verbiage specifico che descrive le procedure consigliate per il controllo.

Indicazioni:

  1. Tutti gli sforzi ragionevoli devono essere effettuati per garantire che i dati possano essere considerati attendibili prima di eseguire il training di un modello. I dati non attendibili o sconosciuti potrebbero introdurre vulnerabilità di sicurezza più avanti nella pipeline.
  2. Dati che contengono dati personali sensibili, se usati per scopi di data science o altrimenti devono essere puliti o archiviati e accessibili in modo appropriato.
  3. La raccolta di dati senza considerazioni sul contesto potrebbe comportare set di dati contenenti dati non validi. Le attività di raccolta dei dati devono essere consapevoli del materiale protetto da copyright, delle violazioni dei dati, degli endpoint non protetti che causano accidentalmente perdite di dati.

Il materiale sussidiario è consigliato per soddisfare i criteri precedenti. Li forniamo in modo indipendente da prodotto e fornitore per dare spazio alle organizzazioni per risolvere il problema in modo che abbia senso per loro.

Valutazione della sicurezza di Machine Learning

Operazioni preliminari

Lo scopo di questa valutazione è aiutare le organizzazioni a descrivere, tenere traccia e correggere i rischi per le operazioni aziendali introdotte dai sistemi di IA. Questa valutazione deve essere usata per:

  1. Raccogliere informazioni sullo stato corrente della sicurezza dell'intelligenza artificiale all'interno dell'organizzazione.
  2. Eseguire un'analisi delle lacune e creare una roadmap per l'implementazione di raccomandazioni.
  3. Tenere traccia dello stato di sicurezza eseguendo questa valutazione ogni anno o bi-annualmente.

Se un'organizzazione non dispone di un programma di sicurezza, questa valutazione non è la posizione da avviare. Un'organizzazione deve avere un programma di sicurezza delle informazioni funzionante prima di implementare le raccomandazioni in questa valutazione. Per altre informazioni, vedere l'articolo Linee guida sulla sicurezza di Azure in Cloud Adoption Framework.

Raccolta dati

Controlli e criteri relativi alla raccolta e all'archiviazione dei dati da tutte le origini usate per l'apprendimento automatico e l'intelligenza artificiale.

Obiettivo: garantire l'integrità dei dati raccolti nei sistemi di intelligenza artificiale.

Origini dati

Controllo: i dati devono essere raccolti da origini attendibili. È consigliabile mantenere e aggiornare un elenco di origini attendibili. Le approvazioni di gestione per la raccolta di dati non attendibili devono essere considerate caso per caso. Se un'origine non attendibile viene approvata, deve essere documentata.

Dichiarazione delle minacce: i dati vengono raccolti da origini non attendibili che potrebbero contenere dati personali sensibili, altri dati indesiderati che potrebbero influire sulle prestazioni di un modello o presentano rischi di conformità all'organizzazione.

Indicazioni:

  1. I dati di input devono essere convalidati e attendibili tramite l'approvazione della gestione prima dell'uso in un sistema di intelligenza artificiale.
  2. I dati raccolti per un sistema di intelligenza artificiale devono essere esaminati prima dell'uso o dell'archiviazione.
  3. Se appropriato, i dati raccolti devono essere puliti di voci indesiderate.
  4. L'origine dei dati deve essere documentata e mantenuta con i dati.
  5. I dati di inferenza usati per eseguire il training di un modello non devono essere considerati implicitamente attendibili e devono essere considerati come nuovi dati.
  6. Le attività di raccolta dei dati devono essere documentate e controllate. I dati raccolti devono avere un proprietario responsabile della conformità ai criteri documentati.

Tipi di dati sensibili

Controllo: per garantire che i dati archiviati per i sistemi di intelligenza artificiale siano protetti correttamente, monitorati e classificati in base alla sensibilità e al caso d'uso. Questo controllo include etichette di classificazione dei dati appropriate, criteri di accesso, informazioni sulle licenze, statistiche descrittive, origine di origine e data di raccolta.

Istruzione di minaccia: i dati usati nei sistemi di intelligenza artificiale vengono usati, archiviati o a cui si accede in modo non appropriato a causa di una mancanza di attributi, metadati o documentazione necessari.

Indicazioni:

  1. Sviluppare criteri di dati che includano la privacy e la protezione dei tipi di dati sensibili e comunicare i criteri a tutti i dipendenti coinvolti nell'uso o nella creazione di sistemi di IA.
  2. Implementare pipeline di training e distribuzione che proteggono la riservatezza e l'integrità dei dati usati nei sistemi di intelligenza artificiale.

Archiviazione di dati

Controllo: i dati devono essere archiviati in modo appropriato in base a un processo di classificazione documentato. I set di dati devono essere indicizzati e considerati asset soggetti a criteri di gestione degli asset e di controllo di accesso.

Dichiarazione delle minacce: i dati vengono archiviati in modo non sicuro e possono essere manomessi o modificati da parti o sistemi non autorizzati. I dati non vengono classificati correttamente, causando la divulgazione di informazioni riservate o dati personali sensibili.

Materiale sussidiario

  1. Assicurarsi che gli account o i sistemi di ricerca di sviluppo o intelligenza artificiale non abbiano accesso ai database di produzione e viceversa.
  2. I dati usati nei sistemi di intelligenza artificiale devono essere classificati e protetti in base a criteri di classificazione documentati.
  3. I dati usati nei sistemi di intelligenza artificiale vengono monitorati in base a criteri di gestione degli asset documentati.
  4. I dati usati per i casi d'uso di intelligenza artificiale sensibili vengono archiviati in sistemi approvati e gestiti.
  5. L'accesso ai dati deve essere controllato e gli utenti che richiedono l'accesso devono eseguire un processo formale di controllo di accesso che include l'approvazione della gestione.
  6. I dati usati nei processi di Machine Learning non devono essere esposti a Internet.
  7. I dati estratti da Internet (o da altre origini non attendibili) devono essere sottoposti a un processo di filtro che include l'approvazione della gestione.
  8. I set di dati devono essere con controllo delle versioni con processi formali di controllo delle modifiche.

Accesso ai dati

Controllo: i set di dati devono essere rilevati e verificati in modo appropriato tramite hash crittografico prima dell'uso.

Istruzione di minaccia: i set di dati vengono modificati senza autorizzazione.

Indicazioni:

  1. È necessario applicare il controllo degli accessi in base al ruolo per i set di dati.
  2. Eseguire controlli di accesso regolari per garantire che gli account con accesso ai set di dati abbiano accesso ai set di dati. Assicurarsi che ogni account funzioni entro limiti normali.
  3. Se non viene usata una piattaforma di rilevamento centrale, è necessario esaminare l'accesso ai dati tramite i log di accesso non elaborati per scopi. Assicurarsi che ogni account funzioni entro limiti normali.
  4. I provider di risorse di terze parti, i terzisti o altre parti esterne non devono avere accesso in eccesso o inappropriato agli asset di dati di training/test di un'azienda senza contratti in vigore.

Integrità dei dati

Controllo: i set di dati devono essere attendibili e rimanere attendibili nel ciclo di vita del sistema di intelligenza artificiale.

Dichiarazione delle minacce: i set di dati vengono modificati durante il ciclo di vita dell'intelligenza artificiale senza la possibilità di controllare o tenere traccia delle modifiche.

Indicazioni:

  1. I set di dati devono essere identificati in modo univoco in modo che le modifiche non autorizzate a un set di dati approvato provocherebbero una revisione del set di dati.
  2. I set di dati e le relative descrizioni crittografiche devono essere rilevati in una posizione centrale. È necessario controllare l'accesso al set di dati.
  3. Le modifiche apportate al set di dati devono includere una descrizione crittografica aggiornata e l'approvazione della gestione prima di essere inviata al servizio di rilevamento centrale.

Elaborazione dati

Controlli e criteri relativi all'elaborazione dei dati usati per l'apprendimento automatico e l'intelligenza artificiale.

Obiettivo: garantire l'elaborazione sicura dei dati dal formato non elaborato a un modulo intermedio pronto per il training.

Pipeline di elaborazione

Controllo: le pipeline di elaborazione devono essere adeguatamente protette.

Dichiarazione delle minacce: un attore di minacce può apportare modifiche non autorizzate al sistema modificando le pipeline di elaborazione dati.

Indicazioni:

  1. Non tutti i dati che si spostano attraverso un sistema di produzione sono rilevanti per le attività di data science. È importante analizzare solo i dati necessari e assicurarsi che tutti i dati spostati da un'impostazione di produzione sicura a un'impostazione di sviluppo vengano rilevati in modo appropriato. Si consideri che alcuni tipi di dati potrebbero non essere in grado di essere spostati in un ambiente di sviluppo. L'analisi scientifica dei dati potrebbe dover essere eseguita in un ambiente intermedio sicuro.
  2. Il controllo corretto dell'accesso ai dati durante tutto il ciclo di vita dell'elaborazione dati è importante. Senza account separati, non è possibile controllare in modo sufficiente l'accesso. Inoltre, la possibilità di rispondere a un evento imprevisto non può verificarsi senza influire potenzialmente sui processi aziendali. La compromissione di un singolo account comporta la compromissione di tutti i dati lasciando l'ambiente di produzione sicuro.
  3. I processi di data science potrebbero richiedere risorse esterne a un limite di conformità rigoroso.
  4. I processi di data science devono essere sempre conformi ai requisiti esistenti. Questo processo può includere lo spostamento di risorse e processi di data science in un ambiente conforme.
  5. I dati devono essere monitorati per l'intero ciclo di vita; questo rilevamento include subset di set di dati di dimensioni maggiori. È necessario che un modello possa essere ricontracciato ai dati su cui è stato eseguito il training. Inoltre, dovrebbe esistere una copia di tali dati nel suo insieme.

Apertura del set di dati

Controllo: per garantire sottoinsiemi (ad esempio, sezioni temporali, categoriche) di dati inclusi per la creazione di modelli e come potrebbero causare pericoli per la sicurezza (perdita di privacy, avvelenamento/integrità tramite sovraemfasi sul feedback e così via).

Dichiarazione delle minacce: l'attore di minacce può recuperare parti dei dati ricostruendo/recuperando subset di dati.

Indicazioni:

  1. I subset di dati sono set di dati stessi. Questi subset devono avere gli stessi metadati associati al set di dati padre e devono essere esaminati in modo analogo per i tipi di dati sensibili.
  2. A seconda dei criteri relativi alle procedure di Machine Learning (contratti di servizio, metriche di distorsione e così via), qualsiasi set di dati specifico (inclusi i subset) deve soddisfare uno standard minimo documentato intorno a queste metriche se devono essere usate nella compilazione del modello. I metadati devono essere sempre collegati al set di dati.
  3. Tutti i set di dati che violano i criteri esistenti devono avere un'eccezione documentata approvata dalla gestione. L'eccezione inclusa nell'eccezione deve essere un motivo documentato per l'eccezione oltre ai metadati necessari.
  4. Tutti i dati usati per la creazione di modelli devono essere rilevati in una posizione centrale. I dati devono essere controllabili in qualsiasi momento. Inoltre, i modelli rilevati per il training su dati non registrati devono essere estratti dall'ambiente di produzione fino a quando non corrispondono a un set di dati noto con i metadati necessari.
  5. I set di dati devono essere con controllo delle versioni appropriati in modo che tutti i metadati vengano aggiornati e che gli utenti dei dati comprendano il contenuto e le proprietà statistiche. Se necessario, è necessario l'approvazione della gestione per i casi d'uso sensibili.

Training del modello

Controlli e criteri relativi al training di modelli e algoritmi.

Progettazione del modello

Controllo: il codice di training del modello viene esaminato da un'entità responsabile.

Dichiarazione delle minacce: codice o vulnerabilità non corretti nel codice del modello generano rischi di disponibilità, integrità o riservatezza.

Indicazioni:

  1. La progettazione e la ricerca dei modelli devono essere eseguite nell'ambiente appropriato. La progettazione e l'architettura del modello possono avere un grande effetto sull'efficacia di un modello. Gli ambienti di produzione non sono il posto per la ricerca o per testare attestazioni nonprovabili sull'efficacia di una progettazione.
  2. La selezione del modello per un sistema di produzione deve essere esaminata e approvata dalla gestione. Questo processo dovrebbe verificarsi all'inizio della fase di sviluppo e deve essere monitorato tramite qualsiasi meccanismo disponibile (Excel, DevOps, Git e così via). Le eccezioni devono essere documentate.
  3. I modelli sono spesso specifici del dominio e deve essere presente una documentazione adeguata che accompagna il modello durante l'uso in un'organizzazione.
  4. Verificare che i metadati del modello siano accessibili agli utenti e agli usi non approvati dei modelli siano documentati e applicati. È accettabile che un utente ottimizzazione di un modello esistente purché i nuovi metadati siano collegati e monitorati in modo appropriato.

Training del modello

Controllo: il criterio di selezione del modello (set di metriche e di controllo) simula la deriva naturale e tutte le condizioni antagoniste che potrebbero essere previste in fase di distribuzione.

Dichiarazione delle minacce: è probabile che un modello sottoposto a training in condizioni ideali sia fragile quando viene distribuito nelle impostazioni antagoniste.

Materiale sussidiario

  1. I set di training e convalida devono rispettare le dipendenze temporali naturali. Ad esempio, per i classificatori malware, un set di convalida deve includere solo versioni software successive a quelle contenute nel set di training.
  2. Aggiungere in modo esplicito l'affidabilità del modello aumentando i set di dati con danneggiamenti comuni che potrebbero essere ragionevolmente individuati in natura.
  3. Eseguire il training in modo esplicito in base a condizioni peggiori usando la ripetizione del training antagonista.
  4. Tenere traccia degli esperimenti e dei meta associati.

Selezione del modello

La selezione del modello consiste nella scelta di un modello da un set di candidati, in cui ogni candidato ha un set univoco di parametri del modello, algoritmo di training e iper-parametri di training. Il criterio di selezione per il modello vincente è spesso basato su una singola metrica quantificabile (ad esempio, perdita minima, frequenza massima di rilevamento) misurata su un set di dati di controllo comune o come media in un set di convalida K-fold.

Controllo: la progettazione del modello e l'algoritmo di training includono la regolarizzazione esplicita o implicita del modello.

Dichiarazione delle minacce: i modelli sono eccessivamente adatti a un set di dati di training e/o a convalida singola e sono più vulnerabili alle modalità di errore.

Indicazioni:

  1. Se fattibile a livello di calcolo, è consigliabile usare la convalida incrociata K-fold per impedire l'overfitting a un singolo set di controllo.
  2. Verificare che i modelli selezionati funzionino correttamente su set di controllo diversi per verificare che non siano stati superati.
  3. Assicurarsi che i processi esistano.

Gestione della versione dei modelli

Controllo: i modelli vengono continuamente sottoposti a training man mano che i nuovi dati di training passano alle pipeline di training.

Dichiarazione di minaccia: si verifica un evento imprevisto, ma il modello coinvolto non può essere individuato per l'indagine.

Indicazioni:

  1. I modelli di versione in modo che ogni volta che viene eseguito il training di un modello, viene assegnata una nuova versione. I qualificatori, ad esempio my_model_dev_1.1 o my_model_prod_1.1, devono essere usati per delineare la produzione dai modelli di preproduzione. Questo controllo delle versioni consente di isolare i problemi relativi a un problema di produzione o di preproduzione. Fare riferimento a processi o criteri SDL sicuri esistenti.

Distribuzione del modello

Controlli e criteri relativi alla distribuzione di modelli, algoritmi e infrastruttura di supporto.

Test di sicurezza

Controllo: i modelli inseriti nell'ambiente di produzione sono adeguatamente protetti.

Dichiarazione delle minacce: i sistemi di intelligenza artificiale non vengono testati in modo adeguato per le vulnerabilità prima della distribuzione.

Indicazioni:

  1. I criteri di test di accettazione formale non sono stati definiti e documentati per i nuovi sistemi di intelligenza artificiale, gli aggiornamenti e le nuove versioni.
  2. I nuovi sistemi di intelligenza artificiale, gli aggiornamenti o le nuove versioni devono essere implementati con test formali.
  3. Gli strumenti automatizzati devono essere usati per testare sistemi informativi, aggiornamenti o nuove versioni.
  4. L'ambiente di test deve essere simile all'ambiente di produzione finale.
  5. È necessario documentare la frequenza, l'ambito e i metodi per le verifiche di sicurezza indipendenti.

Revisione della sicurezza e della conformità

Controllo: una gestione affidabile della rete sottostante è fondamentale per proteggere il sistema di Machine Learning e l'infrastruttura.

Dichiarazione delle minacce: compromissione del sistema di Machine Learning accedendo alla rete non protetta.

Indicazioni:

  1. I dispositivi gateway ai sistemi ML devono essere configurati per filtrare il traffico tra domini e bloccare l'accesso non autorizzato.
  2. I requisiti legali, normativi e contrattuali pertinenti devono essere definiti e documentati in modo esplicito e affrontati, insieme a controlli specifici e responsabilità individuali.
  3. Le linee guida per la configurazione sicura devono essere documentate, implementate o esaminate.
  4. Il criterio per la separazione delle reti ml in domini deve essere coerente con i criteri di controllo di accesso dell'organizzazione o i requisiti di accesso dell'organizzazione.
  5. I meccanismi come gateway sicuro, VPN, routing per i sistemi ml devono essere implementati sufficientemente per abilitare un set di controlli laureato.
  6. Gli utenti e i tecnici di Machine Learning devono adottare o seguire i requisiti per l'implementazione dei controlli per separare e limitare correttamente l'uso di sistemi accessibili pubblicamente, reti interne e asset critici.

Monitoraggio del sistema

Controlli e criteri relativi al monitoraggio continuo dei sistemi di Machine Learning e dell'infrastruttura di supporto.

Log e revisione log

Controllo: la registrazione e il monitoraggio sono fondamentali per i sistemi di Machine Learning per motivi di sicurezza.

Istruzione sulle minacce: durante un'indagine, i log per i sistemi di Machine Learning non vengono trovati.

Indicazioni:

  1. La registrazione e il monitoraggio devono essere eseguiti in modo coerente in tutti i sistemi di intelligenza artificiale e i relativi componenti, tra cui archiviazione, pipeline, server di produzione e così via.
  2. I log eventi e di sicurezza devono essere esaminati regolarmente per individuare comportamenti anomali.
  3. I report e gli avvisi consolidati sull'attività di sistema devono essere generati ed esaminati dalla gestione o da un rappresentante della sicurezza.

Gestione incidenti

Ruoli e responsabilità

Controllo: i log di sicurezza devono essere raccolti in una posizione centrale.

Dichiarazione delle minacce: durante un'indagine, gli analisti della sicurezza non hanno un playbook formalizzato.

Indicazioni:

  1. Le organizzazioni per devono seguire un processo formale per segnalare gli eventi imprevisti dei sistemi di IA nel contesto della perdita di servizio, perdita di apparecchiature, perdita di strutture, malfunzionamenti del sistema, overload del sistema, errori umani, non conformità con criteri o linee guida, violazioni della sicurezza fisica, modifiche del sistema non controllate, malfunzionamenti software, malfunzionamenti hardware e violazioni dell'accesso.
  2. È consigliabile sviluppare procedure formali di risposta agli incidenti e escalation per documentare le azioni intraprese in caso di ricezione di un report di un evento di sicurezza delle informazioni.
  3. Le procedure di risposta agli eventi imprevisti devono essere testate periodicamente, monitorando le metriche di risposta.

Pianificazione della continuità aziendale

Pianificazione, revisione e risultati

Controllo: assicurarsi che i sistemi di Machine Learning possano essere corretti e ripristinati dopo un evento imprevisto.

Dichiarazione delle minacce: gli eventi imprevisti causano problemi di riservatezza, integrità o disponibilità permanenti ai sistemi di Machine Learning critici.

Indicazioni:

  1. Gli asset critici di intelligenza artificiale devono essere identificati e inclusi nell'inventario.
  2. L'organizzazione deve sviluppare un piano di continuità aziendale (BCP) o un processo di ripristino di emergenza in caso di attacchi ai sistemi di intelligenza artificiale.
  3. L'organizzazione deve identificare in ordine di priorità i rischi associati all'impatto della perdita di sistemi di intelligenza artificiale critici agli attacchi.
  4. Le organizzazioni devono disporre di un test di continuità aziendale gestito in base a una pianificazione ripetuta per i sistemi di intelligenza artificiale critici.

Riferimenti

In caso di domande, commenti o commenti, contattare atml@microsoft.com.

Scaricare un PDF di questo documento dal repository GitHub.