Evaluation Pitfalls and Multimodal Baselines for the \dataset{} IoT Malware Dataset

Nel mondo digitale, i ricercatori della sicurezza agiscono come medici del sistema immunitario per i computer. Essi costruiscono strumenti per individuare il software malevolo, o malware, prima che possa causare danni. Per addestrare questi strumenti, hanno bisogno di vaste librerie di dati: registrazioni di come si comportano i computer quando sono sani e registrazioni di come si comportano quando sono malati. La qualità dei dati di addestramento determina quanto bene funzioneranno gli strumenti di sicurezza risultanti. Se i dati sono difettosi, gli strumenti falliranno nel mondo reale, spesso mancando minacce pericolose o generando falsi allarmi. Una grande sfida in questo campo è garantire che il modo in cui i ricercatori suddividono i propri dati in gruppi di addestramento e di test non introduca accidentalmente pregiudizi. Se un programma informatico vede un pezzo specifico di malware durante l'addestramento e poi vede esattamente lo stesso pezzo durante il test, non sta realmente imparando a rilevare nuove minacce; sta semplicemente memorizzando la risposta. Inoltre, i ricercatori devono decidere se giudicare uno strumento di sicurezza in base a quanto bene cattura singoli momenti di attività sospetta, o in base a quanto bene identifica interi programmi infetti, il che può essere un compito molto diverso.

Un team di ricercatori dell'Università di Tarim ha recentemente rivolto la propria attenzione a una nuova e insolitamente dettagliata libreria di dati chiamata CIC-YNU-IoTMal2026. Questo dataset è un tesoro per gli esperti di sicurezza perché registra simultaneamente tre diversi tipi di informazioni per migliaia di programmi informatici. Cattura il traffico di rete in entrata e in uscita, l'attività di sistema come l'uso della CPU e l'elenco specifico dei comandi che il programma impartisce al sistema operativo. Questi programmi sono stati eseguiti su quattro diversi tipi di chip per computer per vedere se gli strumenti di sicurezza potessero funzionare su hardware differenti. I ricercatori non hanno costruito un nuovo strumento di sicurezza; al contrario, hanno agito come auditor. Hanno esaminato il dataset stesso per vedere se i modi standard di testare gli strumenti di sicurezza su questi dati stessero nascondendo problemi seri. Volevano sapere se gli alti punteggi riportati da altri ricercatori fossero reali o se fossero il risultato di sottili errori nella gestione dei dati.

L'audit è iniziato esaminando come i dati venivano suddivisi. Il metodo più comune consiste nel prendere tutti i momenti registrati di attività e mescolarli casualmente, mettendone alcuni in un mucchio di addestramento e altri in un mucchio di test. I ricercatori hanno scoperto che questo approccio era fondamentalmente errato per questo specifico dataset. Poiché i dati registrano interi programmi, mescolare i momenti significava che il mucchio di test conteneva momenti provenienti da programmi che erano già presenti nel mucchio di addestramento. In effetti, ogni singolo momento di test condivideva il suo programma genitore con l'insieme di addestramento, e una piccola percentuale dei momenti di test erano duplicati esatti dei momenti di addestramento. Ciò significava che qualsiasi strumento di sicurezza testato in questo modo stava essenzialmente venendo valutato su domande a cui aveva già visto le risposte. Sebbene ciò non abbia gonfiato artificialmente i punteggi su questo particolare dataset, significava che i risultati non potevano essere considerati affidabili per prevedere quanto bene uno strumento avrebbe funzionato su programmi veramente nuovi e mai visti. I ricercatori hanno concluso che l'unico modo equo per testare questi strumenti è mantenere gli interi programmi insieme, assicurando che nessun programma appaia sia nel gruppo di addestramento che in quello di test.

Anche quando i ricercatori hanno corretto il metodo di suddivisione dei dati, hanno scoperto un secondo problema, più ingannevole. Il dataset contiene migliaia di minuscoli istantanee di attività, e molti strumenti di sicurezza vengono giudicati in base a quanto bene catturano queste singole istantanee. I ricercatori hanno scoperto che questo metodo nasconde una modalità di fallimento pericolosa. Circa il sedici per cento dei programmi malevoli nel dataset sono stati completamente ignorati dagli strumenti di sicurezza. Questi programmi mancati non erano sofisticati; erano semplicemente dormienti. Erano stati eseguiti nell'ambiente di test ma non si erano "svegliati" per iniziare le loro attività malevole, quindi sembravano esattamente programmi innocui. Poiché i programmi malevoli che si erano svegliati erano molto rumorosi e generavano centinaia di istantanee di attività, essi dominavano le statistiche. I programmi silenziosi e dormienti venivano oscurati, facendo apparire lo strumento di sicurezza molto migliore di quanto non fosse in realtà. I ricercatori hanno sottolineato che, per ottenere un quadro reale della sicurezza, bisogna giudicare lo strumento in base alla sua capacità di catturare l'intero programma, non solo i momenti rumorosi.

Lo studio ha anche investigato come gli strumenti si comportano di fronte a diversi tipi di chip per computer. Il dataset includeva programmi in esecuzione su quattro diverse architetture, e i ricercatori hanno testato se uno strumento addestrato su tre di esse potesse rilevare le minacce sulla quarta. I risultati sono stati netti. Quando lo strumento è stato testato su un tipo specifico di chip chiamato ARM, comune in molti piccoli dispositivi, è crollato. Lo strumento è diventato così inaffidabile da segnalare programmi innocui come pericolosi quasi l'ottanta per cento delle volte, pur catturando quasi tutti i malware reali. Questo fallimento non era dovuto al fatto che lo strumento non potesse riconoscere il malware; era perché i programmi innocui sul chip ARM si comportavano diversamente dai programmi innocui sugli altri chip. Lo strumento aveva appreso i pattern sbagliati per ciò che rappresentava la "normalità" su quell'hardware specifico. I ricercatori hanno scoperto che questo problema poteva essere risolto in modo molto economico. Mostrando allo strumento solo una minuscola frazione dei programmi innocui del nuovo chip — meno dell'uno per cento del totale dei dati — le prestazioni dello strumento sono tornate istantaneamente vicino alla perfezione. Ciò suggeriva che la soluzione per la sicurezza cross-chip non risiede in algoritmi complessi, ma nel semplice esporre lo strumento a pochi esempi del nuovo ambiente.

Infine, i ricercatori hanno esaminato i diversi tipi di dati disponibili: traffico di rete, attività di sistema e tracce di comando. Hanno scoperto che, in un ambiente controllato, combinando tutti e tre i tipi di dati, gli strumenti di sicurezza diventavano quasi perfetti. Tuttavia, questa perfezione era fragile. Quando gli strumenti erano costretti a fare affidamento solo sul traffico di rete, perdevano i programmi dormienti. Quando si affidavano solo alle tracce di comando, fallivano completamente quando l'architettura del chip cambiava. La combinazione più robusta si è rivelata essere un mix di traffico di rete e attività di sistema, che evitava le specifiche debolezze degli altri metodi. I ricercatori hanno anche notato che il tipo specifico di modello matematico utilizzato per costruire lo strumento contava molto poco. Che usassero un modello lineare semplice o una rete neurale complessa, i risultati erano quasi identici. Ciò ha dimostrato che il fattore determinante per il successo non era la sofisticatezza dello strumento, ma le scelte fatte su come suddividere i dati, come definire un successo e come gestire i diversi tipi di chip per computer.

Il documento si conclude con un insieme di linee guida chiare per chiunque utilizzi questo dataset. Raccomandano di mantenere sempre gli interi programmi insieme quando si suddividono i dati, di riportare i risultati basandosi sul fatto che gli interi programmi siano catturati piuttosto che solo i singoli momenti, e di essere trasparenti su come vengono trattati i programmi sconosciuti o non classificati. Esortano inoltre i ricercatori a testare i loro strumenti su diversi chip per computer e a riportare quanto variano i risultati se l'esperimento viene eseguito più volte. Il messaggio più importante è che la strada verso una migliore sicurezza non risiede nel costruire modelli più complessi, ma nel porre domande migliori e nell'utilizzare dati più puliti. Correggendo i metodi di valutazione, la comunità può garantire che gli strumenti che costruisce funzioneranno davvero quando saranno più necessari.