Article. What i write
La cyber hygiene dei sistemi di IA: criticità e proposte correttive
Pubblicato il 19 maggio 2025 su CyberSecurity360.it
Attualmente non esistono framework di IA che siano secure-by-default. L’adozione di procedure carenti sotto l’aspetto della cyber hygiene fa sì che i sistemi di IA presentino vulnerabilità intrinseche e problemi di sicurezza. Ecco come rendere la sicurezza parte integrante delle piattaforme.
Gli studi recenti finalizzati al conseguimento della cyber hygiene hanno permesso di individuare una serie di strumenti, processi e teorie necessari per garantire il corretto funzionamento e la sicurezza di un sistema IT.
Finora, il campo dell’intelligenza artificiale si è sviluppato rapidamente, ma la sicurezza dei sistemi di IA è stata considerata un aspetto secondario.
L’assenza di un’adeguata attenzione alla sicurezza all’interno della comunità degli sviluppatori di IA ha portato all’adozione di procedure carenti sotto questo aspetto. La conseguenza è che i sistemi di IA presentano vulnerabilità intrinseche e problemi di sicurezza.
Ecco come identificare e analizzare le specifiche tematiche legate alla sicurezza dei modelli e dei dati nei prodotti di IA. Inoltre, servono controlli correttivi ispirati ai tradizionali principi della sicurezza informatica per aiutare gli sviluppatori di IA a rafforzare la propria posizione in termini di sicurezza e migliorare la cyber security generale.
Cyber hygiene per i sistemi di IA
Il ritmo di sviluppo dell’intelligenza artificiale (IA) è stato rapido sin dal primo rilascio della Compute Unified Data Architecture (CUDA) nel 2007, seguito da TensorFlow nel 2015 e da PyTorch nel 2016.
Questi framework sono diventati la struttura portante di molte soluzioni di machine learning, sia in ambito industriale che accademico, ma rappresentano solo i primi di una serie infinita di piattaforme nel campo dell’apprendimento automatico.
Finora, la comunità di sviluppatori dell’IA si è concentrata sulla risoluzione di complessi problemi tecnici computazionali e sull’aggiunta di funzionalità alle piattaforme esistenti per aumentarne la produttività. Tuttavia, è giunto il momento di considerare la sicurezza come parte integrante delle piattaforme. Migliorare la sicurezza dei prodotti di IA innalzerebbe il livello di sicurezza dell’intero settore.
Vediamo se è possibile, e come, migliorare la sicurezza dell’IA a livello di prodotto.
Buone pratiche e soluzioni
Con il passare del tempo, diventa sempre più evidente la necessità di stabilire buone pratiche e soluzioni di sicurezza nel campo dell’intelligenza artificiale.
Nell’ambito del machine learning sono state ripetutamente accettate pratiche di sicurezza inadeguate che hanno portato a:
- modelli di minaccia legati all’uso di modelli zoos [1], come Tensorflow Hub e PyTorch Model Zoo, senza l’adozione di firme o checksum [2];
- semplici procedure di deserializzazione dei modelli e dei dati non attendibili [3] [4];
- l’uso di modelli senza un log, un journal o un manifest che specifichi su quali dati siano stati addestrati [5].
Modelli e dati condivisi tra ricercatori di machine learning: controlli e procedure
I sistemi e i framework di IA sono software, pertanto devono essere gestite le tradizionali vulnerabilità della cyber security.
Lo sfruttamento di una vulnerabilità di cyber security in un sistema di IA potrebbe comportare il furto di un file del modello, l’alterazione dei dati memorizzati su un file system o all’interno di un database per modificare ciò che un modello apprende, nonché la manipolazione di un file del modello per influenzarne le prestazioni.
Il Secure AI Framework (SAIF) di Google analizza queste vulnerabilità in maniera dettagliata e propone l’adozione di un framework secure-by-default come soluzione efficace per la mitigazione del rischio.
Tuttavia, attualmente non esistono framework di IA che siano secure-by-default.
Fortunatamente, esistono controlli di sicurezza [6] e procedure [7] che possono contribuire a mitigare i tradizionali rischi informatici.
Primo passo: la protezione di modelli e data loader
Il primo passo verso la sicurezza di un framework di machine learning è rappresentato dalla protezione dei modelli e dei data loader.
Se questi controlli venissero implementati, si potrebbero ridurre efficacemente il rischio di attacchi e vulnerabilità sia di tipo cyber tradizionale che di tipo Adversarial machine learning [8].
Le casistiche
Ora vediamo le casistiche in cui dovrebbero essere introdotti i tradizionali controlli di cyber security all’interno dei software di IA e, inoltre, proviamo ad identificare gli ambiti in cui dovrebbero essere standardizzati i formati e i processi di sviluppo dell’IA.
L’adozione dei tradizionali controlli di cyber security permetterà di beneficiare di decenni di ricerca su practice, collaudate ed efficaci, quali la crittografia, l’hashing e le checksum e di rafforzare i processi e le relative procedure di cyber security, rendendo l’IA intrinsecamente più sicura.
Le criticità dell’apprendimento automatico
I modelli e i data loader sono sicuramente gli oggetti che necessitano con maggiore urgenza di interventi migliorativi.
I modelli e il data loading sono i due punti critici del flusso di lavoro dell’apprendimento automatico, in quanto gli elementi vengono frequentemente caricati dal sistema o transitano da fonti locali e remote, rendendoli più esposti al rischio di vulnerabilità.
Gli elementi inattivi o in transito sono esposti al rischio di manomissione, soprattutto quando provengono da fonti sconosciute e remote.
In questo contesto, i controlli crittografici e i meccanismi di verifica robusti possono contribuire a proteggere tali parti del flusso di lavoro dell’apprendimento automatico.
I modelli non garantiscono l’integrità, la privacy e l’autorizzazione
Un file di modello è la rappresentazione serializzata di un modello per il machine learning. Esso contiene i parametri, le strutture e le configurazioni di un modello di machine learning o di analisi statistica dopo il processo di addestramento.
Poiché i file di modello devono poter essere riutilizzati anche dopo lo svuotamento della memoria volatile, è necessario salvarli in un formato che ne faciliti l’uso iterativo o la condivisione con altri utenti.
Quando un sistema legge dati serializzati da fonti probabilmente sconosciute, potrebbero verificarsi problemi di deserializzazione non sicura.
L’Open worldwide application security project (OWASP), l’organizzazione che tiene traccia delle vulnerabilità comuni nelle applicazioni software, ha inserito la deserializzazione insicura da fonti non attendibili nella Top 10 di OWASP dal 2017.
A tale scopo, sono stati elaborati metodi, processi e controlli di sicurezza informatica che dovrebbero essere applicati quando si gestisce la deserializzazione da fonti non attendibili, come per esempio:
- mantenere l’integrità dei dati tramite l’uso di checksum;
- impedire la deserializzazione dei dati non attendibili o non sicuri oppure implementare metodi di deserializzazione sicuri;
- utilizzare la crittografia per garantire la privacy dei dati sensibili serializzati.
Assenza di policy di autorizzazione
I file dei modelli di machine learning sono, in sostanza, software. Gli autori di TensorFlow lo hanno persino sottolineato nella loro documentazione. Di conseguenza, quando si carica un modello di apprendimento automatico, si sta caricando un programma serializzato.
Purtroppo, le piattaforme di machine learning caricano qualsiasi modello senza richiedere il permesso o l’autorizzazione del proprietario del sistema o dell’utente corrente.
L’analisi delle funzionalità integrate nelle principali piattaforme di apprendimento automatico ha mostrato l’assenza di meccanismi che consentano di applicare politiche di autorizzazione che specifichino le condizioni in cui un modello possa essere caricato ed eseguito.
Inoltre, non sono presenti meccanismi integrati per verificare l’origine di un file di modello o per garantirne l’integrità tramite la convalida del checksum rispetto alla fonte originale.
In effetti, alcune ricerche hanno dimostrato che le piattaforme di machine learning memorizzano i loro modelli in formati esposti a manomissione e che i modelli non attivi o in transito possono essere modificati da soggetti non fidati.
Anche un modello addestrato può diventare insicuro quando viene deserializzato, perché non esiste un meccanismo che ne garantisca l’integrità del file.
Informazioni riservate
La rappresentazione di un modello richiede un notevole investimento in termini di ricerca, sviluppo, lavoro e risorse. Spesso, i parametri contenuti nel file riguardano informazioni proprietarie e sensibili riguardanti le attività, i clienti o la soluzione di problemi complessi.
Gli elementi contenuti nel file del modello potrebbero far trapelare informazioni riservate relative alla struttura del modello, al modo in cui è stato addestrato o al suo utilizzo.
Se in futuro il modello sarà reso pubblico, un’organizzazione potrebbe desiderare di mantenere la propria riservatezza fino alla data di rilascio prevista. Inoltre, un’organizzazione potrebbe essere soggetta a requisiti normativi specifici per i modelli completamente privati, come il Regolamento generale sulla protezione dei dati (Gdpr), per garantire una protezione aggiuntiva dei dati contenuti nel file del modello.
Più fornitori
In prospettiva, si osserva l’introduzione di più fornitori di piattaforme e di diversi formati di modelli nell’ecosistema dell’apprendimento automatico.
Finora, ogni produttore ha sviluppato dei formati proprietari per l’archiviazione e la condivisione dei file dei modelli. Alcuni, come Hugging Face e Open Neural Network Exchange (Onnx), stanno definendo formati standardizzati per rendere i modelli più sicuri e trasferibili.
Tuttavia, anche i loro formati hanno dimostrato di avere falle in termini di sicurezza.
La comunità di sviluppatori, pertanto, non sta convergendo su nessuno di questi formati, ma continua a utilizzare formati proprietari discreti. Con un numero sempre maggiore di formati di modelli, diventa impossibile tenersi aggiornati su tutti i formati e sui relativi rischi per la sicurezza.
Ciò dimostra la necessità di standardizzare il settore.
Le criticità del file modello
In sintesi, sono state individuate le seguenti criticità relative ai file modello che devono essere risolte con la massima urgenza:
- i file modello sono costituiti da codice, ma non sono trattati o gestiti con lo stesso rigore del codice tradizionale;
- le loro procedure di serializzazione e deserializzazione sono troppo deboli e li rendono vulnerabili a manomissioni e abusi;
- l’esistenza di numerosi formati, ciascuno con proprie debolezze e vulnerabilità distinte e potenzialmente uniche, aumenta la complessità e il rischio.
I data loader non verificano né autorizzano
Un data loader è un componente essenziale nei sistemi di machine learning e data science, in quanto si occupa del caricamento e della preparazione dei dati per l’elaborazione.
Se ci concentrassimo sui dati e sulla loro centralità nel processo di apprendimento automatico, noteremmo che le piattaforme di machine learning sono già focalizzate sui dati, ma non forniscono meccanismi validi per tracciarne la provenienza e garantirne la coerenza in maniera standardizzata.
La tracciabilità della provenienza dei dati e la loro verifica ai fini della coerenza sono fattori essenziali per determinare quali dati di addestramento siano stati utilizzati per formare un modello, se tali dati siano stati verificati, se siano stati autorizzati o approvati per far parte del set di dati.
Il data poisoning
Il data poisoning (o avvelenamento dei dati), per esempio, rappresenta una grave minaccia per il machine learning, in quanto consente di inserire delle backdoor nei modelli di apprendimento automatico.
Attualmente, le etichette ottenute da vari formati di file di annotazione sono utilizzate come meccanismo di base per il caricamento dei dati. Questi formati di annotazione generalmente non contengono controlli di integrità per i file che rappresentano.
Pertanto, è facile modificarli per adattarli alle proprie esigenze. Questa vulnerabilità è presente in tutti i set di dati pubblici noti, indipendentemente dalle loro dimensioni.
Alcuni ricercatori hanno dimostrato che la mancanza di controlli sull’integrità dei dati può rendere i modelli vulnerabili agli attacchi informatici, anche quando i dati di addestramento provengono da fonti su larga scala [9].
Nonostante gli attacchi di avvelenamento possano essere eseguiti con vari metodi, l’adozione di robusti controlli di integrità dei dati ridurrebbe significativamente la superficie di attacco e la conseguente esposizione al rischio, limitando la possibilità di manomettere i modelli e i set di dati.
In assenza di meccanismo per verificare l’integrità o l’origine
Anche per i data loader, come per i modelli, non esiste una firma crittografica né una tracciabilità della catena di custodia per i file di annotazione o di dati, quindi è difficile determinarne la provenienza.
Pertanto, senza un meccanismo in grado di verificarne l’integrità o l’origine, non è possibile automatizzare l’autorizzazione, la catena di custodia o i controlli di integrità prima che i dati vengano utilizzati nel flusso del machine learning.
Ciò conferma che chiunque abbia accesso ai file di annotazione potrebbe alterarne l’integrità e aggiungere o rimuovere elementi dei dati nel corso del processo di training.
Grazie all’aggiunta della firma crittografica e del monitoraggio del passaggio di proprietà, i proprietari potranno determinare chi ha creato e autorizzato i file di dati da utilizzare in un sistema di apprendimento automatico.
Tracciare l’addestramento dei modelli
Non esiste un catalogo o un registro automatizzato creato dai sistemi di machine learning che tenga traccia dell’addestramento dei modelli.
Questa funzionalità sarebbe particolarmente utile per gli utenti dei modelli pubblici di tipo zoo, dove, a parte una descrizione testuale, non è possibile sapere quali dati siano stati utilizzati per addestrare un modello.
Un esempio a riguardo è rappresentato da ImageNet [10]. Questo modello ha subito diverse modifiche nel corso della sua vita e alcune di queste presentano punti di debolezza noti.
In precedenza, è stato riscontrato che i modelli addestrati su ImageNet avevano prestazioni inferiori rispetto ai gruppi di persone sottorappresentati.
Poiché non esiste un catalogo dei dati su cui un modello è stato addestrato, non è possibile determinare se la struttura portante di ImageNet in un particolare modello presenti o meno questi problemi.
È fondamentale che gli utenti possano sapere con facilità su quali dati è stato addestrato, convalidato e testato un determinato modello.
Cosa dovrebbero fare i data loader
Riepilogando, i data loader dovrebbero:
- incorporare i controlli di integrità e le firme per garantire l’integrità dei file;
- implementare meccanismi minimi di catena di custodia che si concentrino sulla prevenzione della manomissione dei dati e che, allo stesso tempo, ne valutino l’idoneità per l’addestramento;
- disporre di un meccanismo di catalogazione dei dati che associ i dati e i modelli in modo sufficientemente chiaro da consentire a una terza parte di determinare quali dati siano stati utilizzati per addestrare, convalidare e testare un modello.
Come proteggere i modelli e i data loader
Se si volesse implementare un livello minimo di sicurezza nel processo di machine learning, sarebbe sufficiente seguire una semplice regola empirica. Nel caso in cui non si fosse sicuri della provenienza o non ci si fidasse del fornitore del modello o dei dati, non bisognerebbe caricarli, proprio come non si dovrebbe caricare un programma sconosciuto sul proprio computer.
I creator e i consumer di modelli hanno bisogno di una modalità di lavoro con i file dei modelli e i dati coerente, affidabile e sicura.
A tal fine, si consiglia di implementare e utilizzare controlli di sicurezza in modo affidabile e verificabile ogni volta che un modello o un dato viene utilizzato.
La corretta implementazione dei controlli di sicurezza
Il livello organizzativo della piattaforma di machine learning è il luogo migliore per implementare i controlli di sicurezza. Ciò presenta però delle difficoltà.
In primo luogo, è stato dimostrato che la corretta implementazione dei controlli di sicurezza è un’attività molto complessa. In particolare, quando l’implementazione è affidata a personale inesperto, è possibile che vengano introdotti errori che possano aumentare il rischio. Ciò può portare a implementare i controlli in modo errato o a eluderli.
In secondo luogo, se ogni programmatore implementasse i controlli di sicurezza in maniera discrezionale, si creerebbe un ecosistema di implementazioni non compatibili in un ambito in cui è necessaria la standardizzazione.
Dopo aver stabilito che il posto migliore per effettuare i controlli di sicurezza sia nelle piattaforme di machine learning, introduciamo alcune verifiche che dovrebbero essere implementate come primo passo per rendere queste piattaforme più sicure dal punto di vista della progettazione.
La AES-256 del Nist
La crittografia, come la AES-256 del National Institute of Standards & Technology (Nist), è considerato il gold standard per la protezione dei dati e dovrebbe essere implementato in modo standardizzato su tutti i formati di modello. Questo strumento aiuta i programmatori dei modelli a garantire che i loro modelli siano privati quando sono inattivi o in transito.
Inoltre, poiché la possibilità di ispezionare un modello è fondamentale per eseguire l’analisi, la crittografia aiuta i programmatori di modelli a mantenere i propri modelli più privati e sicuri dagli attacchi degli avversari, come le minacce legate all’apprendimento automatico.
Firme crittografiche e checksum
Le firme crittografiche e le checksum, comunemente utilizzate nella cyber security, possono risolvere due problemi critici nella protezione dei file dei modelli di apprendimento automatico: la verifica dell’autore di un file di modello e il rilevamento di eventuali manomissioni dopo la sua creazione.
Sarebbe opportuno che le piattaforme di creazione dei modelli supportassero uno standard di checksum e di firma che aiutasse gli utenti a capire chi ha creato un modello e a verificarne le modifiche.
Ciò garantirebbe che l’integrità del modello fosse preservata durante l’intero processo di Machine learning operations (MLOps).
Controlli di autorizzazione
I controlli di autorizzazione proteggono i sistemi, negando l’esecuzione di attività non autorizzate dal proprietario. Pertanto, le piattaforme di apprendimento automatico dovrebbero supportare un quadro standardizzato di autorizzazione dei modelli basato su firme crittografiche.
Questo strumento aiuta i proprietari della piattaforma a creare elenchi di approvazione (allow) e rifiuto (deny), garantendo che solo i modelli di loro scelta vengano caricati ed eseguiti.
Crittografia e meccanismi di autorizzazione per proteggere i data loader
Dopo aver elencato i metodi crittografici e i meccanismi di autorizzazione che possono essere usati per proteggere i modelli di machine learning, vediamo come possono essere sfruttati per proteggere i data loader utilizzati per addestrare i sistemi di apprendimento automatico.
Si raccomanda l’uso di un data loader sicuro che possa essere adoperato dai consumatori per garantire, convalidare e applicare pratiche di gestione dei dati solide e affidabili.
Primo componente di un data loader
Il primo componente di un data loader sicuro è un metodo robusto in grado di verificare le checksum e confermare l’autorizzazione degli elementi dei dati prima del loro caricamento in memoria.
Le checksum dei file di dati devono essere calcolate e verificate prima di essere letti in memoria per essere utilizzati nei sistemi di apprendimento automatico. Ciò garantisce che i dati utilizzati nel sistema non siano stati alterati rispetto alla forma destinata all’addestramento o alla verifica.
Il data loader deve includere anche un sistema di autorizzazione che impedisca il caricamento dei file con checksum non validi, utilizzando i file di annotazione firmati e un elenco di elementi di dati consentiti o negati in base a una firma crittografica.
I programmatori dei sistemi di machine learning possono utilizzare questo meccanismo per garantire che i dati forniti al sistema siano consentiti e integri.
Strumento di data journaling: il secondo componente
Un secondo componente di un data loader sicuro è uno strumento di data journaling che può essere utilizzato per tracciare i dati su cui è stato addestrato un modello, le loro chiavi di verifica (checksum) e le eventuali firme presenti sui dati.
Inoltre, un tool di journaling dovrebbe avere la capacità di aggiungere una firma crittografica al journal stesso, in modo tale che in seguito sia possibile verificarne l’integrità.
Questa funzionalità risolve i problemi di provenienza dei dati e di versioning che caratterizzano le moderne pipeline di machine learning. Idealmente, questo registro potrebbe essere incluso come parte integrante di un file di modello standardizzato, in modo tale che anche gli utenti futuri del modello ne conoscano le origini.
La gestione dei dati criptati
L’ultima funzionalità prevista in un data loader sicuro è la capacità di gestire dati criptati. Quando si effettua il training su dati pubblici, non è necessario che il modello e il data loader supportino il caricamento di dati criptati.
Tuttavia, alcuni gestori potrebbero voler o dover mantenere i dati privati durante il processo di training. A tal fine, un data loader sicuro dovrebbe supportare la lettura di dati criptati e garantire che vengano correttamente eliminati dopo l’uso.
In sintesi, è necessario:
- standardizzare le capacità crittografiche dei modelli, ma non è l’unica misura da adottare: anche la “Guide for Deploying AI System Securely” della National security agency (Nsa) sottolinea la necessità di utilizzare metodi crittografici nel processo di distribuzione dei modelli. Il settore della ricerca sta cercando di sviluppare soluzioni, come ONNX e Hugging-Face safetensors, ma se queste soluzioni non seguiranno una procedura standardizzata, gli sforzi di frammenteranno ulteriormente il panorama dei formati dei modelli
- riunire e standardizzare, in maniera seria e urgente, un formato per il modello di machine learning che fornisca portabilità, flessibilità e controlli di sicurezza crittografici;
- infine, i controlli crittografici e il journaling possono essere integrati nel processo di data loading. Senza queste funzioni, non è possibile garantire la riservatezza e l’integrità dell’intero ciclo di vita dell’apprendimento automatico, che va dall’ingestione dei dati alla creazione dei modelli fino alla loro distribuzione.
Tre suggerimenti ai fornitori o agli operatori del settore
Le esigenze per i sistemi di IA sono:
- la protezione dei modelli di machine learning e dei meccanismi di data loader utilizzati per il training;
- l’applicazione dei tradizionali controlli di sicurezza alle piattaforme di machine learning;
- infine, lo sviluppo di procedure standard e la promozione della collaborazione nell’ambito del machine learning.
È essenziale soddisfare queste esigenze per evitare che i rischi per i sistemi di IA continuino a crescere, manifestandosi probabilmente sotto forma di violazioni della sicurezza, danni alla reputazione, interruzioni operative e perdite finanziarie.
Ecco tre suggerimenti ai fornitori o agli operatori del settore:
- fornire controlli crittografici verificati e coerenti, come la crittografia, le firme e le checksum, nei processi relativi al modello e ai dati su tutte le piattaforme;
- è necessario implementare meccanismi di autorizzazione che permettano ai proprietari del sistema di garantire che nel sistema non vengano caricati contenuti non autorizzati;
- garantire che i processi, le piattaforme e i flussi di lavoro standardizzati relativi ai prodotti di apprendimento automatico applichino buone pratiche di igiene informatica e di IA.
La necessità di un organismo di standardizzazione
Per implementare queste linee guida sarebbe opportuno creare un organismo di standardizzazione composto da membri dell’industria, degli enti di standardizzazione governativi e del mondo accademico che possa garantire la coerenza, l’affidabilità e la sicurezza dei controlli, dei processi e delle procedure che guidano l’IA.
Per problemi specifici, esistono soluzioni praticabili che utilizzano controlli crittografici tradizionali.
Altri problemi riguardanti gli archivi dei modelli e dei dati, oltre ai problemi di sicurezza emersi nella parte bassa dello stack di elaborazione, come la gestione della memoria sulle Gpu [11] e la manomissione dei modelli tramite i compilatori di machine learning [12], si stanno manifestando solo di recente. Queste ulteriori criticità di sicurezza confermano la necessità di realizzare un’implementazione olistica dei meccanismi di sicurezza in tutta la pipeline di machine learning per garantire che i prodotti e i sistemi di IA siano sicuri fin dalla fase di progettazione.
Bibliografia
[1] I model zoos sono collezioni di modelli di machine learning o intelligenza artificiale pre-addestrati che vengono resi disponibili per l’uso, il test, la ricerca o il confronto.
[2] Jiang, W., Synovic, N., Sethi, R., Indarapu, A., Hyatt, M., Schorlemmer, T. R., Thiruvathukal, G. K., & Davis, J. C. (2022). An empirical study of artifacts and security risks in the pre-trained model supply chain. Proceedings of the 2022 ACM Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, 105–114. https://doi.org/10.1145/3560835.3564547
[3] Adia, & Adia. (2024). Data Scientists Targeted by Malicious Hugging Face ML Mod-els with Silent Backdoor. JFrog. https://jfrog.com/blog/data-scientists-targeted-by-malicious-hugging-face-ml-models-with-silent-backdoor/
[4] Lucas, J. (2024). Analyzing the Security of Machine Learning Research Code | NVIDIA Technical blog. https://developer.nvidia.com/blog/analyzing-the-security-of-machine-learning-research-code/
[5] Hardinges, J., Simperl, E., & Shadbolt, N. (2023). We must fix the lack of transparency around the data used to train foundation models. Harvard Data Science Review, Special Issue 5. https://doi.org/10.1162/99608f92.a50ec6e6
[6] Barker, E., & Barker, E. (2016). Guideline for using cryptographic standards in the federal government: Cryptographic mechanisms. US Department of Commerce, National Institute of Standards and Technology.
[7] Nist, G. M. (2023). The NIST Cybersecurity Framework 2.0. Gaithersburg, MD: US Department of Commerce.
[8] Gli attacchi di Adversarial Machine Learning prendono di mira i componenti di apprendimento automatico di un sistema.
[9] Carlini, N., Jagielski, M., Choquette-Choo, C. A., Paleka, D., Pearce, W., Anderson, H., … & Tramèr, F. (2024, May). Poisoning web-scale training datasets is practical. In 2024 IEEE Symposium on Security and Privacy (SP) (pp. 407-425). IEEE.
[10] ImageNet è un grande database di immagini che è diventato la principale base per la computer vision.
[11] Hoover, J. (2022). Analysis of GPU Memory Vulnerabilities.
[12] Clifford, E., Shumailov, I., Zhao, Y., Anderson, R., & Mullins, R. (2024, April) ImpNet: Imper-ceptible and blackbox-undetectable backdoors in compiled neural networks. In 2024 IEEE Conference on Secure and Trustworthy Machine Learning (SaTML) (pp. 344-357). IEEE.