Operational Runtime Behavior Mining for Open-Source Supply Chain Security

Riepilogo Tecnico: Estrazione del Comportamento di Runtime Operativo per la Sicurezza della Catena di Approvvigionamento Open-Source

Dichiarazione del Problema
Gli attacchi alla catena di approvvigionamento del software open-source (OSS) si basano sempre più su logiche maligne eseguite durante le fasi di installazione, importazione o post-installazione, che l'analisi statica spesso non rileva a causa dell'offuscamento o della generazione dinamica. I difensori fanno affidamento sulla telemetria di runtime, ma questi dati sono eterogenei: alcune fonti preservano artefatti concreti (domini, indirizzi IP, comandi), mentre altre espongono solo riepiloghi comportamentali aggregati (conteggi delle chiamate di sistema, bucket di accesso ai file). Ciò crea un disallineamento tra le valutazioni incentrate sul modello (che trattano il rilevamento come una classificazione binaria a livello di pacchetto) e le esigenze degli analisti (che richiedono pivot di runtime specifici e azionabili). Inoltre, gli attuali spiegatori di grafi identificano caratteristiche che preservano le previsioni del modello ma non corrispondono necessariamente a piste di indagine azionabili, poiché gli archi ad alta importanza possono riflettere comportamenti benigni comuni o rumore ambientale. La sfida principale è la caccia limitata dall'osservabilità: la specificità delle prove investigative è strettamente limitata da ciò che la fonte di telemetria registra.

Metodologia: Framework HetHunt
Gli autori presentano HetHunt, un framework di caccia su grafi di runtime consapevole dell'osservabilità progettato per colmare il divario tra la previsione del rischio a livello di pacchetto e l'indagine rivolta all'analista. Il framework opera in tre fasi:

1. Grafici Canonici di Prove di Runtime:

   • HetHunt mappa la telemetria di runtime eterogenea da diverse fonti (tracce a livello di evento e riepiloghi aggregati) in uno schema di grafo eterogeneo tipizzato e condiviso.
   • L'ontologia include sei tipi di nodi: PKG (identità del pacchetto), PROC (istanza del processo), FILE, NET (endpoint di rete), SYSCALL e CMD (stringa di comando).
   • Undici tipi di archi codificano le interazioni (ad esempio, LOAD, DEPEND, EXEC, READ, CONNECT). Una caratteristica chiave del design è il livello intermedio PROC, che crea percorsi multi-hop (ad esempio, PKG → PROC → FILE) per distinguere comportamenti come le scritture durante l'installazione dalle connessioni di rete durante l'importazione.

2. Codificatore di Grafo Relazionale (Previsione del Rischio):

   • Il framework utilizza una Rete Convoluzionale su Grafo Relazionale (R-GCN) per apprendere il rischio a livello di pacchetto dalla struttura del grafo.
   • Sebbene siano stati valutati altri codificatori (GAT, HAN, HGT), l'R-GCN è stato selezionato per la pipeline finale grazie al suo equilibrio tra prestazioni competitive di classificazione, bassa latenza di inferenza e un'interfaccia diretta sugli archi tipizzati adatta a mappare i punteggi sui pivot di runtime.

3. Dall'Importanza alla Sospettosità (Il Livello di Caccia):

   • Apprendimento dell'Importanza degli Archi: Un modulo di maschera sugli archi apprendibile (ispirato a PGExplainer) identifica le interazioni di runtime più influenti per la previsione del modello.
   • Filtraggio Ambientale: Filtri basati su regole sopprimono il rumore di fondo ad alta frequenza (ad esempio, registri comuni, percorsi di sistema, comandi di sondaggio routinari) per impedire che comportamenti benigni condivisi dominino la classificazione.
   • Calibrazione della Rarità Benigna: Per convertire l'importanza degli archi rivolta al modello in sospettosità rivolta all'analista, il framework calibra i punteggi rispetto a una popolazione di riferimento benigna. Il punteggio di sospettosità di un arco è calcolato come:
     $$s(e) = \text{importanza}(e) \times (1 + \alpha \cdot \text{rarità}(e))$$
     dove la rarità è derivata dalla frequenza del documento della destinazione dell'arco nei pacchetti benigni. Ciò garantisce che gli archi influenti siano anche insoliti rispetto al comportamento normale.
   • Punteggio a Livello di Grafo: I pacchetti sono classificati in base alla media di sospettosità dei loro primi $K$ archi mantenuti, dando priorità ai grafi con prove di alta sospettosità concentrate.

Contributi Chiave

1. Formulazione della Caccia Limitata dall'Osservabilità: Il documento formula la caccia alla catena di approvvigionamento di runtime come un problema di grafo in cui gli output sono esplicitamente limitati dalla granularità della telemetria, distinguendo tra prove a livello di IOC, a livello di TTP, contestuali e con lacune nella telemetria.
2. Grafici Canonici di Prove di Runtime: Uno schema di grafo compatto e tipizzato che unifica la telemetria eterogenea di esecuzione dei pacchetti (da fonti a livello di evento e aggregate) in una rappresentazione condivisa.
3. Framework di Sospettosità HetHunt: Una pipeline end-to-end che disaccoppia il rischio del pacchetto, l'importanza degli archi rivolta al modello e la sospettosità rivolta all'analista, utilizzando il filtraggio ambientale e la calibrazione della rarità benigna consapevole delle relazioni.
4. Valutazione Orientata alla Caccia: Un protocollo di valutazione innovativo che valuta non solo l'accuratezza della classificazione dei pacchetti, ma anche la qualità delle classifiche derivate dagli archi e la specificità dei pivot emersi attraverso diverse granularità di telemetria.

Valutazione e Risultati
Il framework è stato valutato su due dataset:

• QUT-DV25: 14.271 pacchetti Python con telemetria di analisi dinamica aggregata e stabile.
• OSPTrack: 9.758 esecuzioni in sandbox cross-ecosistema con telemetria a livello di evento (domini, indirizzi IP, comandi).

Risultati Chiave:

• QUT-DV25 (Telemetria Aggregata): HetHunt calibrato sulla rarità ha raggiunto prestazioni di classificazione elevate (0,876 AUROC, 0,880 AUPRC e Precision@100 perfetta). Tuttavia, i pivot emersi erano principalmente a livello di TTP o contestuali (ad esempio, "connessione di rete durante l'installazione") piuttosto che IOC concreti, riflettendo la natura aggregata dei dati.
• OSPTrack (Telemetria a Livello di Evento): Sebbene questo dataset preservasse artefatti concreti (IOC), l'alto volume di rumore ambientale (attività del gestore di pacchetti, accesso ai registri) ha limitato l'allertamento affidabile con bassi falsi positivi. La calibrazione della rarità ha migliorato la classificazione quando limitata alle relazioni di rete, ma la precisione in cima alla lista è rimasta debole.
• Utilità per l'Aanalista: L'annotazione dei pivot principali ha confermato che un'alta qualità di classificazione non garantisce un'alta specificità del pivot. QUT-DV25 ha prodotto prove astratte, mentre OSPTrack ha prodotto candidati concreti ma spesso locali al pacchetto o guidati dall'ambiente.
• Volume della Telemetria vs. Osservabilità: Un volume di telemetria più elevato non si è correlato a una migliore utilità di caccia; in OSPTrack, le tracce con il volume più alto erano dominate da attività benigna, mentre tracce più pulite e a volume inferiore hanno prodotto una migliore qualità di classificazione.

Significato e Affermazioni
Il documento afferma che le spiegazioni dei grafi di runtime devono essere calibrate all'osservabilità della telemetria prima di poter supportare la caccia operativa. HetHunt dimostra che i grafi di runtime eterogenei possono colmare efficacemente il divario tra la previsione del rischio a livello di pacchetto e l'indagine dell'analista, a condizione che:

1. Le spiegazioni siano trattate come pivot di indagine limitati dalla telemetria e non come Indicatori di Compromissione (IOC) confermati.
2. Venga applicata una calibrazione della rarità benigna per distinguere gli archi influenti per il modello dal rumore di fondo comune.
3. La specificità dell'output (IOC vs. TTP vs. Contestuale) sia compresa come una funzione della fonte di telemetria sottostante e non solo delle capacità del modello.

Gli autori sottolineano che HetHunt non sostituisce i classificatori a livello di pacchetto, ma fornisce i necessari "pivot di runtime" per guidare l'ispezione dell'analista, riconoscendo che la mancanza di indicatori concreti può riflettere lacune nella telemetria o comportamenti non attivati piuttosto che fallimenti della spiegazione.