Il costo energetico dei modelli di detection

Ogni alert ha un costo nascosto: dietro a ogni modello di detection che gira H24 ci sono una bolletta energetica, una quota di CO₂ e delle variabili progettuali che raramente entrano nelle metriche di sicurezza, ma che andrebbero misurate e ottimizzate. È scritto a chiare lettere nello studio pubblicato dall’International Journal of Applied Mathematics dal titolo Towards eco-friendly cybersecurity: machine learning-based anomaly detection with carbon and energy metrics, che porta al centro del dibattito il costo energetico della detection.

Il lavoro propone un framework di anomaly detection ‘eco-aware’ e introduce una metrica dedicata, l’Eco-Efficiency Index, che collega in modo esplicito la qualità del rilevamento all’energia consumata e alla CO₂ emessa dai modelli di machine learning usati nei flussi di monitoraggio. Questo cambio di prospettiva ha un corollario immediato per i team SOC: valutare i modelli anche in funzione del loro profilo energetico significa trattare la capacità di calcolo come parte integrante delle security operations.

Ma andiamo al sodo: quanto costa, in kilowattora e grammi di CO₂, attestarsi su percentuali stellari di detection?​

Il test

Lo studio ribalta in parte l’assunto implicito che più complessità algoritmica equivalga automaticamente a migliore sicurezza. Lo fa partendo da un problema molto concreto per i team SOC: spiegare perché le pipeline di detection ‘divorano’ sempre più CPU e GPU, perché i modelli vanno riaddestrati di continuo e perché il conto del cloud sale a ogni iterazione di tuning.

Lo studio si svolge all’interno di un ambiente controllato in Google Colab, in cui sono stati messi alla prova cinque algoritmi (Logistic Regression, Random Forest, Support Vector Machine, Isolation Forest e XGBoost), al lavoro sulla stessa base dati. Applicando un unico strumento di misura di energia e CO₂, CodeCarbon, i ricercatori hanno quantificato il costo computazionale di addestramento e inferenza per ciascun modello.​ Per dare sostanza a questo approccio, è stato introdotto il Carbon-Aware Cybersecurity Traffic Dataset, una collezione di 2.300 flow di rete che combina feature tipiche della security con metriche energetiche e di carbon footprint, all’interno di esperimenti supervisionati.

​La vera novità sta nel blocco di feature legate alla sostenibilità, che include parametri relativi al consumo istantaneo di potenza, la stima delle emissioni equivalenti, il costo economico dell’energia, l’efficienza energetica del data center e il livello di virtualizzazione coinvolto nel trattamento del traffico. In altre parole, oltre a osservare che cosa succede sulla rete, si registra anche quanto costa in termini di energia e CO₂ per monitorare e classificare quei flussi.

Tutta la fase di preprocessing e analisi esplorativa conferma che il dataset è pulito e integrato con poche feature mirate, e che esiste un legame misurabile tra ciò che passa sulla rete e ciò che si consuma in termini di energia. I ricercatori hanno introdotto alcuni indicatori derivati che mostrano come i flussi più “pesanti” tendano ad associarsi a valori più alti di consumo istantaneo di potenza e di emissioni equivalenti e come, in media, le anomalie presentino consumi energetici ed emissioni leggermente superiori e più dispersi rispetto al traffico normale.​

Sul piano tecnico, gli autori hanno portato tutte le variabili su uno spazio numerico omogeneo, normalizzato le scale e riequilibrato le classi, così da evitare che il predominio del traffico normale schiacciasse i pattern rari legati alle anomalie. Fra i modelli di riferimento, Random Forest, XGBoost e SVC hanno raggiunto le performance di detection più alte; Logistic Regression offre risultati solidi con il minimo costo computazionale e Isolation Forest rimane indietro, rivelandosi utile più come baseline non supervisionata che come candidato serio in presenza di etichette affidabili.

Una risposta interessante

Arriviamo alla parte più interessante del lavoro: il risultato delle misurazioni energetiche e di emissioni nella valutazione dei modelli. Ciascun esperimento di training e inferenza è stato monitorato con CodeCarbon, che ha stimato il consumo energetico sulla base dell’attività di CPU/GPU, delle caratteristiche hardware e di fattori di emissione legati alla regione energetica (nel caso specifico, il profilo era quello statunitense).​ Per ciascun modello sono stati registrati tempo di addestramento, tempo di inferenza, energia totale consumata in kWh e emissioni in grammi di CO₂ equivalente, e i risultati sono stati salvati in un file che permette confronti diretti fra algoritmi.

Come prevedibile, la fase di training pesa molto più dell’inferenza sul bilancio energetico, perché comporta iterazioni multiple, costruzione di alberi, ricerca di iperparametri e altre operazioni intensive.​ I numeri confermano un pattern chiaro: Random Forest è il modello più ‘pesante’ in termini di emissioni (circa 0,0553 g CO₂eq nell’ambiente di test), seguito da SVC. Logistic Regression e XGBoost mostrano un profilo nettamente più efficiente, con emissioni rispettivamente nell’ordine di 0,0001 e 0,0025 g CO₂eq. Isolation Forest consuma pochissima energia grazie alla sua struttura relativamente semplice, ma la scarsa qualità della detection ne limita l’utilità operativa.​

Su questi dati si innesta l’Eco-Efficiency Index (EEI), definito come rapporto tra la qualità della detection e l’energia consumata (in kWh). L’EEI esprime in pratica ‘quanta detection di qualità ottengo per ogni kilowattora speso’, ossia un indicatore unico che consente di comparare modelli anche molto diversi per complessità e architettura. Le visualizzazioni costruite dagli autori mostrano come alcune configurazioni ottimizzate di Random Forest e soprattutto di Logistic Regression offrano un equilibrio particolarmente favorevole tra performance e footprint, risultando più ‘eco-efficienti’ di alternative più pesanti a parità di accuratezza o con scarti trascurabili.​

I risultati del test

L’impatto reale sui SOC

Uno dei messaggi più utili per chi progetta pipeline di detection è che ottimizzazione e riduzione delle feature non servono solo a snellire i modelli, ma hanno un impatto misurabile sul consumo energetico e, di conseguenza, sui costi operativi. Lo studio mostra che le versioni ottimizzate dei modelli migliorano la qualità della detection, mentre le varianti basate su PCA riducono in modo significativo i tempi di training e l’energia consumata, con un effetto minimo sulla qualità delle previsioni. In pratica, una selezione intelligente delle feature e un tuning mirato consentono di rendere i modelli più efficienti dal punto di vista energetico, mantenendo quasi invariata la capacità di rilevamento.

​Dal punto di vista dei SOC, l’applicazione pratica è abbastanza diretta: se misuro il costo energetico dei modelli, posso decidere con maggiore consapevolezza la frequenza di riaddestramento, il livello di complessità ammesso in produzione e il trade-off tra ensemble pesanti e modelli più snelli, soprattutto in contesti cloud dove ogni ciclo di training incide sulla spesa e sull’impronta carbonica dell’organizzazione. Inoltre, l’idea di incorporare metriche come l’EEI nelle scelte di design offre una sponda concreta ai team che devono rispondere a policy di sostenibilità interne o a obblighi di reporting sulle emissioni legate all’IT.

Per chi lavora ogni giorno su SIEM, NDR, EDR e piattaforme di analisi del traffico, il punto è semplice: il prossimo tuning potrebbe non giocarsi solo su un punto di detection in più o in meno, ma anche su qualche wattora risparmiato o sprecato.