Siamo entusiasti di riportare Transform 2022 di persona il 19 luglio e virtualmente dal 20 al 28 luglio. Unisciti ai leader dell’IA e dei dati per discussioni approfondite ed entusiasmanti opportunità di networking. Registrati oggi!
Data la complessità, la sensibilità e la scalabilità dello stack software tipico di un’azienda, la sicurezza è sempre stata una preoccupazione centrale per la maggior parte dei team IT. Ma oltre alle ben note sfide alla sicurezza affrontate dai team devops, le organizzazioni devono anche considerare una nuova fonte di sfide alla sicurezza: l’apprendimento automatico (ML).
L’adozione del ML sta salendo alle stelle in ogni settore, con McKinsey che ha scoperto che entro la fine dello scorso anno il 56% delle aziende aveva adottato il ML in almeno una funzione aziendale. Tuttavia, nella corsa all’adozione, molti stanno affrontando le sfide di sicurezza distinte che derivano dal ML, insieme alle sfide nell’implementazione e nell’utilizzo responsabile del ML. Ciò è particolarmente vero nei contesti più recenti in cui l’apprendimento automatico è distribuito su larga scala per casi d’uso che coinvolgono dati e infrastrutture critiche.
I problemi di sicurezza per il machine learning diventano particolarmente pressanti quando la tecnologia opera in un ambiente aziendale reale, data l’entità delle potenziali interruzioni causate da violazioni della sicurezza. Nel frattempo, il ML deve anche integrarsi nelle pratiche esistenti dei team IT ed evita di essere una fonte di colli di bottiglia e tempi di inattività per l’azienda. Con i principi che regolano l’uso responsabile dell’IA, ciò significa che i team stanno cambiando le loro pratiche per creare solide pratiche di sicurezza nei loro carichi di lavoro.
Contents
L’ascesa di MLSecOps
Per rispondere a queste preoccupazioni, tra i professionisti dell’apprendimento automatico c’è una spinta ad adattare le pratiche che hanno sviluppato per i devops e la sicurezza IT per l’implementazione di ML su larga scala. Questo è il motivo per cui i professionisti che lavorano nel settore stanno costruendo una specializzazione che integra sicurezza, devops e operazioni di sicurezza di machine learning, o ‘MLSecOps’ in breve. In pratica, MLSecOps lavora per riunire l’infrastruttura ML, l’automazione tra sviluppatori e team operativi e le politiche di sicurezza.
Ma quali sfide risolve effettivamente MLsecOps? E come?
L’ascesa di MLSecOps è stata incoraggiata dalla crescente importanza di un’ampia serie di sfide alla sicurezza che il settore deve affrontare. Per dare un’idea della portata e della natura dei problemi a cui è emersa la risposta a MLSecOps, analizziamone due in dettaglio: l’accesso agli endpoint del modello e le vulnerabilità della catena di approvvigionamento.
Accesso al modello
Esistono importanti rischi per la sicurezza posti da vari livelli di accesso illimitato ai modelli di apprendimento automatico. Il primo e più intuitivo livello di accesso ad un modello può essere definito come accesso “black-box”, ovvero poter effettuare inferenze sui modelli ML. Sebbene questa sia la chiave per garantire che i modelli vengano utilizzati da varie applicazioni e casi d’uso per produrre valore aziendale, l’accesso illimitato per consumare previsioni a un modello può introdurre vari rischi per la sicurezza.
Un modello esposto può essere soggetto ad un attacco “contraddizionale”. Un tale attacco vede un modello decodificato per generare “esempi contraddittori”, che sono input per il modello con rumore statistico aggiunto. Questo rumore statistico serve a far sì che un modello interpreti erroneamente un input e preveda una classe diversa da quella che sarebbe intuitivamente prevista.
Un esempio da manuale di attacco del contraddittorio riguarda l’immagine di un segnale di stop. Quando si aggiunge un rumore contraddittorio all’immagine, può indurre un’auto a guida autonoma alimentata dall’intelligenza artificiale a credere che sia un segnale completamente diverso, come un segnale di “rendimento”, mentre sembra ancora un segnale di stop per un essere umano.
Esempio di un comune attacco contraddittorio ai classificatori di immagini. Immagine di Fabio Carrara, Fabrizio Falchi, Giuseppe Amato (ISTI-CNR), Rudy Becarelli e Roberto Caldelli (Unità di Ricerca CNIT al MICC ‒ Università di Firenze) via ERCIM.
Poi c’è l’accesso al modello “white-box”, che consiste nell’accesso alle parti interne di un modello, in diverse fasi dello sviluppo del modello di apprendimento automatico. In una recente conferenza sullo sviluppo del software, abbiamo mostrato come sia possibile iniettare malware in un modello, che può attivare codice arbitrario e potenzialmente dannoso quando viene distribuito in produzione.
Ci sono altre sfide che possono sorgere riguardo alla perdita di dati. I ricercatori sono stati in grado di decodificare i dati di addestramento dai pesi interni appresi di un modello, il che può comportare la divulgazione di dati sensibili e/o di identificazione personale, causando potenzialmente danni significativi.
Vulnerabilità della catena di approvvigionamento
Un altro problema di sicurezza che deve affrontare il ML è quello che sta affrontando anche gran parte dell’industria del software, che è il problema della catena di fornitura del software. In definitiva, questo problema si riduce al fatto che un ambiente IT aziendale è incredibilmente complesso e si basa su molti pacchetti software per funzionare. E spesso, una violazione di uno solo di questi programmi nella catena di approvvigionamento di un’organizzazione può compromettere una configurazione altrimenti completamente sicura.
In un contesto non di riciclaggio, si consideri la violazione di SolarWinds del 2020 che ha visto vaste aree del governo federale degli Stati Uniti e del mondo aziendale violate a causa di una vulnerabilità della catena di approvvigionamento. Ciò ha indotto una maggiore urgenza di rafforzare la catena di fornitura del software in ogni settore, soprattutto considerando il ruolo del software open source nel mondo moderno. Inoltre, anche la Casa Bianca sta ora ospitando vertici di alto livello sulla preoccupazione.
Proprio come le vulnerabilità della catena di approvvigionamento possono indurre una violazione in qualsiasi ambiente software, possono anche attaccare l’ecosistema attorno a un modello ML. In questo scenario, gli effetti possono essere anche peggiori, soprattutto considerando quanto il ML si basa sui progressi dell’open source e quanto possono essere complessi i modelli, inclusa la catena di approvvigionamento a valle delle librerie di cui hanno bisogno per funzionare in modo efficace.
Ad esempio, questo mese è stato riscontrato che il pacchetto Ctx Python di lunga data sul repository open source PyPI era stato compromesso con codice di furto di informazioni, con oltre 27.000 copie dei pacchetti compromessi scaricati.
Poiché Python è uno dei linguaggi più popolari per il ML, i compromessi della catena di approvvigionamento come la violazione Ctx sono particolarmente urgenti per i modelli ML e i loro utenti. Qualsiasi manutentore, collaboratore o utente di librerie di software avrebbe sperimentato a un certo punto le sfide poste dalle dipendenze di secondo, terzo o quarto livello o superiore che le librerie mettono in gioco: per ML, queste sfide possono diventare significativamente più complesse.
Dove entra in gioco MLSecOps?
Qualcosa in comune con entrambi gli esempi precedenti è che, sebbene siano problemi tecnici, non hanno bisogno di nuove tecnologie per essere affrontati. Invece, questi rischi possono essere mitigati attraverso processi e dipendenti esistenti ponendo standard elevati su entrambi. Ritengo che questo sia il principio motivante alla base di MLSecOps: la centralità di processi forti per rafforzare il ML per gli ambienti di produzione.
Ad esempio, mentre abbiamo trattato solo due aree di alto livello specifiche per i modelli e il codice ML, esiste anche una vasta gamma di sfide relative all’infrastruttura del sistema ML. Le best practice in materia di autenticazione e autorizzazione possono essere utilizzate per proteggere l’accesso al modello e gli endpoint e garantire che vengano utilizzati solo in base alla necessità. Ad esempio, l’accesso ai modelli può sfruttare sistemi di autorizzazione multi-livello, che possono mitigare il rischio che i malintenzionati abbiano accesso sia black-box che white-box. Il ruolo di MLSecOps, in questo caso, è quello di sviluppare pratiche solide che rafforzano l’accesso ai modelli inibendo minimamente il lavoro dei data scientist e dei team di devops, consentendo ai team di operare in modo molto più efficiente ed efficace.
Lo stesso vale per la catena di fornitura del software, con un buon MLSecOps che chiede ai team di creare un processo di verifica regolare delle proprie dipendenze, aggiornarle in modo appropriato e agire rapidamente nel momento in cui una vulnerabilità viene rilevata come una possibilità. La sfida di MLSecOps consiste nello sviluppare questi processi e integrarli nei flussi di lavoro quotidiani del resto del team IT, con l’idea di automatizzarli ampiamente per ridurre il tempo speso per la revisione manuale di una catena di fornitura del software.
C’è anche una vasta gamma di sfide intorno all’infrastruttura dietro i sistemi ML. Ma ciò che si spera ci abbiano mostrato questi esempi è questo: mentre nessun modello ML e il suo ambiente associato possono essere resi non hackerabili, la maggior parte delle violazioni della sicurezza si verificano solo a causa della mancanza di best practice nelle varie fasi del ciclo di vita dello sviluppo.
Il ruolo di MLSecOps è quello di introdurre intenzionalmente la sicurezza nell’infrastruttura che supervisiona il ciclo di vita del machine learning end-to-end, inclusa la capacità di identificare quali sono queste vulnerabilità, come porvi rimedio e come questi rimedi possono adattarsi alla giornata- vita quotidiana dei membri del team.
MLSecOps è un campo emergente, in cui le persone che lavorano dentro e intorno ad esso continuano a esplorare e definire le vulnerabilità della sicurezza e le migliori pratiche in ogni fase del ciclo di vita dell’apprendimento automatico. Se sei un praticante di ML, ora è un ottimo momento per contribuire alla discussione in corso mentre il campo di MLSecOps continua a svilupparsi.
Alejandro Saucedo è il direttore tecnico dell’apprendimento automatico presso Seldon.
DataDecisionMakers
Benvenuto nella comunità VentureBeat!
DataDecisionMakers è il luogo in cui gli esperti, compresi i tecnici che lavorano sui dati, possono condividere approfondimenti e innovazioni relative ai dati.
Se vuoi leggere idee all’avanguardia e informazioni aggiornate, best practice e il futuro dei dati e della tecnologia dei dati, unisciti a noi su DataDecisionMakers.
Potresti anche considerare di contribuire con un tuo articolo!
Leggi di più da DataDecisionMakers
