L’architettura del sistema operativo Android, rappresentata in Figura 6^[1], ha caratteristiche uniche. Costruita con la filosofia di essere un ambiente completamente open, che ogni soggetto potesse modificare a suo piacimento, Android è formato da un insieme di componenti eterogenei, in buona parte “off-the-shelf” – ovvero liberamente disponibili sul mercato – e integrati.

Introdurremo brevemente le caratteristiche utili a capire il funzionamento di Android attraverso queste componenti, in modo da poter poi ragionare sulle principali problematiche di sicurezza.

Il kernel di Android (in rosso nell’immagine) è un kernel Linux generico, multi-utente, in uso su desktop e server. Una simile scelta permette ai produttori di comporre l’hardware dello smartphone che intendono commercializzare con molti gradi di libertà, in quanto è estremamente probabile che, per ogni componente hardware assemblato, sia disponibile il corrispondente driver Linux. La definizione di un kernel nuovo, ad hoc per Android, avrebbe magari potuto essere più performante, specie sui primi dispositivi con poca disponibilità hardware; tuttavia, avrebbe limitato le possibilità dei produttori di smartphone, che avrebbero dovuto attendere lo sviluppo del corrispondente driver per poter aggiungere uno specifico componente alla propria architettura, con il rischio di una riduzione della diffusione di Android.

L’Hardware Abstraction Layer (HAL – in azzurro) è un insieme di moduli di libreria, ognuno specifico per una componente hardware. Lo scopo di tutti gli HAL è semplificare la comunicazione tra i servizi dei livelli superiori del sistema operativo e l’hardware: ad esempio, questo permette ai livelli più alti del sistema operativo (in particolare al Java API Framework) di ignorare le specificità dei driver sottostanti per poter comunicare con i componenti hardware corrispondenti, nonché di utilizzare un set di istruzioni standard eseguite su astrazioni indipendenti dall’attuale componentistica dello smartphone. È compito poi delle funzioni di libreria dell’HAL tradurre i comandi nei corrispondenti sui driver specifici del kernel.

Android si basa su un insieme di librerie native (in viola), ovvero scritte in C/C++, che sono state inserite a supporto delle funzionalità, anche in questo caso, del Java API Framework e delle app. Tali librerie, ampiamente disponibili “off-the-shelf”, sono state inserite con la filosofia di riutilizzare quanto già disponibile, senza doverlo riscrivere. Rientrano in questo gruppo, tra le altre, le librerie per il rendering 2D e 3D (usate estensivamente dai videogiochi) e le librerie con i font e i codec audio/video supportati dallo smartphone.

L’Android Runtime (in giallo) è l’ambiente di esecuzione delle app. ART è una macchina virtuale in grado di eseguire il codice delle app, compilandolo nell’architettura nativa dello smartphone durante l’installazione. Per l’esecuzione, si basa su un insieme di librerie Java chiamate Core Libraries che corrispondono a un sottoinsieme dell’SDK di Java, più un insieme di classi specifiche di Android.

Il Java API Framework (in verde) implementa un insieme di servizi fondamentali che supportano l’esecuzione delle app, fornendo l’accesso ai servizi dei livelli sottostanti del sistema operativo, nonché la comunicazione tra app tramite uno specifico driver del kernel chiamato Binder. Ogni servizio è specifico per un certo tipo di attività: gestire l’installazione delle app, il loro ciclo di vita quando in esecuzione, la posizione, le telefonate e le notifiche, nonché il rendering delle schermate delle app. Questo componente del sistema operativo è stato completamente implementato da zero.

Infine, le app (in blu) occupano il livello gerarchico più alto e sfruttano tutti i servizi sottostanti per la loro esecuzione.

Aspetti e problemi di sicurezza di Android

Da un punto di vista della sicurezza, il sistema operativo ha una doppia valenza. Da una parte, come ogni pezzo di software, contiene delle vulnerabilità ed è soggetto al threat model del confused deputy che abbiamo presentato precedentemente. In questo caso, come per le app, l’attacco può provenire da app malevole installate dall’utente; tuttavia alcuni attacchi possono essere eseguiti anche dall’esterno tramite le connessioni di rete (Wi-Fi, 5G, Bluetooth, NPC), anche se in letteratura questi attacchi sono molto specifici, limitati e appartenenti soprattutto alle prime versioni del sistema operativo.

D’altra parte, Android è anche la componente che deve essere modificata in prima battuta per “hardenizzare” il canale di comunicazione tra app, per ridurre, come discusso, la probabilità che un malware installato possa attaccare con successo un’app vulnerabile o lo stesso sistema operativo. Come si può intuire la parte di hardening richiede, nel caso migliore, un’integrazione dei meccanismi di sicurezza esistenti oppure, nel caso peggiore, la loro parziale ridefinizione e riscrittura.

Sistemi di sicurezza in Android

L’eterogeneità architetturale di Android si manifesta anche nei corrispondenti sistemi di sicurezza, che prendono il nome di Android Security Framework (ASF) e sono principalmente distribuiti nel kernel e nel Java API Framework. Introdurremo di seguito i principali sistemi di sicurezza di Android senza pretese di completezza, riferendoci in particolare a quelli esistenti fin dalle prime versioni e che sono stati consolidati nel tempo, a riprova della loro affidabilità. Tuttavia, saranno sufficienti per ragionare sulle principali problematiche di sicurezza del sistema operativo.

Sistemi di sicurezza nel Kernel

In un kernel Linux generico il principale meccanismo di sicurezza è il DAC (Discretionary Access Control), applicato su ogni file del sistema, dove i permessi sono espressi in termini di diritti di lettura, scrittura ed esecuzione per il proprietario del file, per gli utenti che appartengono allo stesso gruppo del proprietario e, infine, per tutti gli altri. I permessi su ogni file sono assegnati dal proprietario in maniera insindacabile. Quest’ultimo punto è una debolezza di Android, perché permetterebbe a uno sviluppatore di avere troppo impatto sulla sicurezza del sistema.

A titolo di esempio, si supponga che uno sviluppatore dia troppi permessi ai file della propria app, fornendo accesso completo al gruppo “altri”. In questo caso, un malware installato riconoscerebbe immediatamente questa situazione e otterrebbe l’accesso a tutti i dati dell’app. Inoltre, il DAC non permette comunque di definire politiche di sicurezza che valgano per tutto il sistema e tutte le app installate.

Per superare questa limitazione, a partire da Android 4.2, il DAC è stato integrato con un modello MAC (Mandatory Access Control) tramite una componente chiamata SEAndroid (Security Enhanced Android)^[2], un’estensione di SELinux^[3] che permette di definire regole che valgono su tutto il sistema, di fatto limitando il problema precedente e permettendo ai produttori di scrivere le proprie politiche di sicurezza per il singolo smartphone. Samsung Knox^[4] è l’implementazione di Samsung di SEAndroid sui propri dispositivi.

Infine, un sistema di sicurezza definito da Android a livello Kernel, è la Sandbox^[5], che installa ogni app in un utente differente a livello Kernel, nell’ottica di aumentare la separazione tra app e diminuendo la probabilità di interazione tra malware e app.

Sistemi di sicurezza nel Java API Framework

Il Java API Framework implementa soluzioni di sicurezza native (ovvero sviluppate ad hoc per Android) per la protezione delle app e dell’utente. Uno di questi sistemi è ben noto allo stesso utente, ovvero il sistema dei permessi. Ogni app deve disporre di specifici permessi per accedere ai servizi del sistema operativo o di altre app. Alcuni permessi vengono dati di default (come, ad esempio, il permesso per accedere a Internet), mentre altri richiedono l’intervento dell’utente: a questa categoria fanno riferimento tutti i permessi che possono ledere la privacy dell’utente (ad esempio accedere alle foto o alla posizione dello smartphone), per i quali è ragionevole permettere la scelta all’utente stesso. Il mapping tra le app e i loro permessi viene gestito da un componente del Java API Framework chiamato package manager, che si occupa della quasi totalità degli aspetti di sicurezza a questo livello. È quindi il package manager che decide se una app abbia o meno i permessi richiesti per una certa operazione. Lo stesso è responsabile dell’installazione e della disinstallazione delle app.

Queste operazioni coinvolgono controlli di sicurezza importanti. In primo luogo l’app, che viene distribuita come un archivio compresso chiamato APK (Android PacKage) viene accettata solo se firmata dallo sviluppatore con la propria chiave privata. Pertanto il package manager verifica innanzitutto la firma e l’integrità di ogni file presente nell’app, installandola solo in caso di controllo con esito positivo.

Tuttavia questo controllo non identifica lo sviluppatore, che per poter firmare e distribuire le app non deve avere un certificato rilasciato da un’autorità riconosciuta: è sufficiente abbia una coppia di chiavi, pubblica e privata, che può autogenerarsi con tool ampiamente disponibili.

Pertanto, Android non ha l’obiettivo di identificare gli sviluppatori; questa è una scelta di business. Imporre l’identificazione dello sviluppatore potrebbe avere conseguenze sul numero di app sviluppate e distribuite, in quanto un certo numero di sviluppatori potrebbe non voler essere riconosciuto o avere più identità fittizie (ognuna con una coppia di chiavi diversa).

Durante l’installazione, il package manager provvede a interagire con il kernel per creare un nuovo utente a livello kernel per l’app (Sandbox) e generare in modo random il percorso dove installarla. Lo scopo di questa randomizzazione, utilizzata nelle più recenti versioni di Android, è nascondere ai malware la localizzazione delle app bersaglio, per ridurre la probabilità che queste siano individuate e attaccate.

Problemi di sicurezza in Android

Lo scopo dei meccanismi di protezione è fornire ad un sistema un insieme di garanzie di sicurezza. Ricapitolando, i sistemi di protezione dell’ASF precedentemente introdotti garantiscono:

1. la verifica dell’integrità dell’app in fase di installazione;
2. l’isolamento tra le app, grazie all’installazione su utenti diversi a livello kernel (Sandbox) e percorsi delle home randomici;
3. l’autorizzazione ad accedere alle risorse del sistema e di altre app tramite i permessi;
4. la possibilità di definire politiche di sicurezza da parte del produttore del dispositivo.

A fronte di tali garanzie, il lettore converrà che i meccanismi di protezione risultino convincenti e di fatto siano effettivamente focalizzati a ridurre la probabilità che un malware raggiunga un’app vulnerabile.

Qualora le garanzie promesse da questi – e da tutti gli altri meccanismi dell’ASF – fossero mantenute, probabilmente avremmo un sistema operativo da sempre sicuro. La storia di Android, come di qualunque altro sistema operativo, è però ricca di vulnerabilità e attacchi.

Cercheremo di capire perché, premettendo come la frase che più si addice a chi cerchi problemi di sicurezza in software complessi sia “il diavolo sta nei dettagli”.

Interazione e integrazione

Interazione. Come abbiamo visto, l’eterogeneità architetturale di Android si riscontra anche nei meccanismi dell’ASF. A livello kernel le regole di sicurezza sono espresse in termini di DAC/MAC su file e processi. A livello applicativo, le regole sono indicate in termini di permessi (“autorizzi l’app ad accedere alle tue foto?”). Appare evidente che diversi livelli dello stack Android parlino lingue diverse. In questo caso, i problemi di sicurezza si possono nascondere nell’interazione tra gli stessi: come si traduce il permesso “accesso alle foto” in un insieme di regole DAC a livello del sistema operativo che rispetti anche le regole MAC imposte dal produttore? Questa interazione avviene in modo corretto e completo? Ci possono essere conflitti o mancanze?

Non esiste documentazione ufficiale a riguardo e, qualora il lettore volesse capire come avviene ad esempio il processo di richiesta di posizione GPS da parte di un’app fino all’interrogazione del driver del GPS del dispositivo, dovrebbe analizzare il codice open-source di Android. Ma questo, ovviamente, lo può fare anche un attaccante.

Il problema dell’interazione tra meccanismi diversi è stata risolta, nel tempo, attraverso le diverse versioni di Android, seppur ogni modifica ai meccanismi di sicurezza di Android richieda comunque una verifica della correttezza di queste comunicazioni.

Integrazione. Oltre a un problema di diversità del linguaggio, l’eterogeneità architetturale di Android ha ripercussioni anche sull’integrazione tra i meccanismi di sicurezza e può snaturare algoritmi e protocolli delle singole componenti architetturali per realizzare uno specifico meccanismo.

A titolo di esempio, si consideri l’isolamento tra le app tramite la sandbox, che porta ogni app ad essere installata in un utente diverso a livello kernel. Seppur i vantaggi di questa separazione siano palesi in termini di hardening, per ottenere questo risultato alcune funzionalità native del kernel sono state modificate.

In Linux, ogni nuovo processo (figlio) viene generato a partire da un processo già esistente (padre) tramite una system call, ovvero una chiamata di funzione al kernel, detta fork^[6], che dapprima crea una copia esatta del processo-padre e poi sostituisce il codice del padre nella copia con quello del processo-figlio prima di eseguirlo. Si noti che con la fork entrambi i processi appartengono al medesimo utente.

La scelta della sandbox ha portato a un utilizzo non canonico della fork. Si pensi alla seguente ipotesi: quando un utente riceve su WhatsApp un allegato che vuole aprire con un’altra app, come fa l’app di WA, che appartiene a un utente, a creare e lanciare in un nuovo processo (di un altro utente) la seconda app a livello kernel? Certamente non con l’uso standard della fork, che non prevede questa possibilità.

Android risolve il problema tramite un processo ad hoc chiamato Zygote, dove la creazione di nuovi processi avviene tramite l’uso di una fork eseguita come root (quindi con massimi privilegi) che crea il nuovo processo, inserisce il codice dell’app da eseguire e cambia la proprietà del processo da root a quello dell’utente corrispondente.

Pertanto, la scelta necessaria è stata trasformare una system call con pochi privilegi e sicura in una con massimi privilegi e ad alto rischio. La conseguenza diretta sulla sicurezza di Android è stata una serie di vulnerabilità legate a questo processo, che ha permesso a diversi attaccanti di abusarne con conseguenze significative ^{[7], [8], [9]}.

Vulnerabilità dei meccanismi di sicurezza

Oltre agli esaminati problemi di integrazione e di utilizzi non standard, va notato che i meccanismi di protezione sono anch’essi pezzi di software e, come tali, possono contenere vulnerabilità sfruttabili per bypassarli.

A titolo di esempio, dalla prima versione di Android fino alla 4.2, il già discusso controllo dell’integrità dell’APK svolto dal package manager era eseguito in maniera non corretta. Per una scelta implementativa, si usavano due librerie diverse per verificare l’integrità di ogni file nell’APK e per installare i file verificati^[10]. L’utilizzo di queste due librerie conteneva una vulnerabilità, chiamata Master Key Vulnerability, tale per cui se nell’APK vi fossero stati due file con lo stesso nome, la verifica dell’integrità sarebbe stata eseguita sul primo, mentre il secondo, tramite la seconda libreria, sarebbe stato installato senza essere verificato. Di conseguenza, un attaccante avrebbe potuto prendere una app legale, inserirvi tramite app repackaging (cfr. Sezione 4.3.2) un file malizioso con lo stesso nome di un altro file presente e ridistribuirla. In questo modo, qualora l’app fosse stata installata, anche il file malizioso sarebbe stato installato automaticamente dal package manager nel dispositivo, senza alcun controllo di integrità su di esso.

Questo tipo di vulnerabilità viene cercato costantemente dal gruppo di sicurezza di Google, chiamato Android Security Teams, oltre che da una comunità di ethical hacker spinti alla ricerca di nuove vulnerabilità da motivi economici: dal 2014 Google ha attivato un Bounty Program, oggi chiamato Google and Alphabet Vulnerability Reward Program^[11], che remunera parti terze che rilevano e segnalano vulnerabilità nel sistema operativo.

Il risultato di questo processo è stata la scoperta e la risoluzione di un grande numero di vulnerabilità nelle diverse versioni di Android; e a “stretto giro”, ovvero entro poco tempo dall’uscita di ogni update del sistema operativo. La maggior parte degli aggiornamenti minori (ovvero non legati al rilascio e all’aggiornamento del sistema operativo a una nuova versione) sono in buona parte risoluzioni delle vulnerabilità scoperte.

A questo processo, negli anni e attraverso le diverse versioni del sistema operativo, si è affiancata un’attività di hardening sempre maggiore, spinta soprattutto da un crescente numero di malware per Android; questo ha portato Google ad applicare politiche sempre più restrittive per ridurre, da un lato, la probabilità di interazione tra malware e app vulnerabili e, dall’altro, per ridurre indirettamente il numero di vulnerabilità nelle app.

Ad esempio, in Android 9 è stato introdotto il divieto di utilizzare http nelle app, forzando l’uso di https: in questo modo si riduce la superficie di attacco dell’app forzando lo sviluppatore ad usare solo connessioni cifrate.

Per capire le ragioni di questa crescente fase di hardening da parte di Google, occorre fare una riflessione: l’ASF, così come ogni altro sistema di protezione, non è mai completo. Ovvero, non protegge tutto il sistema ma solo la maggior parte dei canali di comunicazione tra app e sistema operativo. Questo non è dovuto a pigrizia o impreparazione, ma è una “ragionevole scelta di compromesso”. I meccanismi di protezione hanno infatti un “costo” sul sistema operativo, sulle risorse del sistema e, non ultimo, sulla libertà dell’utente. Estremizzare i meccanismi di protezione può rendere il sistema molto più sicuro ma poco usabile, con la conseguenza di demotivare all’utilizzo di Android sia utenti che sviluppatori. A valle di questa riflessione, è chiaro come il processo di hardening costante svolto dalle prime all’ultima versione di Android abbia avuto come obiettivo quello di aumentare la superficie di sistema protetta dall’ASF, pur mantenendo un alto grado di usabilità.

Inoltre, l’evoluzione hardware degli smartphone ha certamente favorito lo sviluppo di nuovi meccanismi di sicurezza nelle ultime versioni di Android, che, qualora implementate su vecchi dispositivi con hardware limitato, avrebbero impattato molto più negativamente sulla “user experience”.

Side Channels

Alla fine, possiamo concludere che le ultime versioni dell’ASF forniscono una protezione più completa delle diverse componenti del sistema. Tuttavia, rimangono componenti che non sono protette o perché ritenute poco rischiose dal punto di vista della sicurezza, o perché esiste la necessità che siano condivise tra tutte le app in maniera libera. Si pensi, in questo secondo caso, alle impostazioni di sistema o alla scheda SD, entrambe per definizione accessibili da tutte le app. In particolare, la scomparsa delle schede SD dai recenti smartphone è proprio per la scelta delle app di non utilizzarle, trattandosi di una memoria condivisa e visibile a tutti.

Tuttavia queste componenti non protette possono diventare, se utilizzate opportunamente, dei canali di comunicazione non standard, detti side channels.

La storia della mobile security è ricca di esempi dove l’abuso dei side channels ha portato ad attacchi (detti side channel attacks) che hanno eluso l’ASF.

Per chiarire, nel grande numero di malware più o meno complessi che sfruttano side channel, usiamo un esempio semplice: quello del primo malware che ha dimostrato la sfruttabilità dei side channel in Android, che prende il nome di SoundComber.

SoundComber^[12] è uno dei primi malware basati sul threat model delle colluded app che abbiamo presentato in Figura 2 e formato da due app all’apparenza innocue, ovvero un registratore di note vocali (con il permesso di registrare l’audio) e un calendario (con il permesso di connettersi a Internet per sincronizzare gli appuntamenti). I due malware collaborano per rubare numeri di carte di credito digitati tramite la tastiera dello smartphone usando il “volume” come side channel.

Il principio è semplice: durante una telefonata dove l’utente invia il numero della sua carta di credito via telefono, digitando sulla tastiera virtuale, il primo malware registra il tasto digitato, riconosce il numero e cambia il livello del volume audio a una intensità pari al numero digitato. Il secondo malware legge il valore guardando il livello del volume e, per ogni cifra digitata dall’utente, invia a un server esterno il valore corrispondente.

Da quando SoundComber ha dimostrato la fattibilità di questi attacchi, molti attaccanti hanno cercato potenziali side channel e sviluppato malware che li sfruttassero. D’altro canto, ogni volta che un nuovo side channel veniva scoperto e sfruttato l’ASF è evoluto di conseguenza per proteggerli, pur mantenendo, ove possibile, l’utilizzo atteso.

Tuttavia, alcune protezioni possono essere “vulnerabili” a loro volta. Le componenti “off-the-shelf” di Android possono avere potenziali side channel nativi. In questi casi, Android li limita e protegge tramite opportuni meccanismi nell’ASF. Tali protezioni possono però risultare incomplete o, appunto, vulnerabili.

È il caso del servizio inotify^[13] di Linux che permette ai processi di venire notificati in caso di cambio di stato di un processo target (ad esempio quando il processo si avvia, è in esecuzione, viene bloccato…), secondo un modello publish-subscribe. Un simile servizio permetterebbe a un malware di essere notificato quando un’app bersaglio si esegue. Recentemente è stato dimostrato che la protezione dell’ASF è insufficiente e che un malware può sfruttare facilmente inotify per essere notificato circa l’avvio di un’app^[14].

Ma qual è l’impatto e come si sfrutta una simile vulnerabilità? Si supponga che l’app richieda, come quasi ogni app, l’inserimento di credenziali utente. Se il malware avesse la stessa identica interfaccia grafica dell’app bersaglio e venisse notificato da inotify quando questa si esegue, esso potrebbe eseguirsi immediatamente dopo ed essere mostrato all’utente al posto di quella originale, che verrebbe lanciata e subito messa in background. In questo modo, l’utente fornirebbe le sue credenziali al malware anziché all’app legale. Si noti che questa vulnerabilità colpisce tutte le versioni di Android fino a quella attuale (13) e che, al tempo della scrittura di questo testo, non è ancora stata risolta da Google.

Discussione

La fase di hardening degli ultimi 15 anni ha reso Android particolarmente sicuro. La ricerca di vulnerabilità presenti nelle prime versioni, come quelle correlate allo Zygote o all’utilizzo di side channel semplici (come le impostazioni), sarebbe in massima parte infruttuosa. La ricerca di side channel è invece ancora promettente – come dimostrato dall’esempio di inotify – ma, rispetto ai primi side channel, aumenta la difficoltà nel poterli sfruttare una volta individuati.

Va però sottolineato che ogni nuova versione di Android contiene nuove funzionalità a supporto degli sviluppatori di app. Queste funzionalità possono nascondere nuove vulnerabilità, non presenti nelle precedenti versioni di Android.

Note

^[1] Figura presa da https://developer.android.com/guide/platform

^[2] Security-Enhanced Android. https://source.android.com/docs/security/features/selinux?hl=it

^[3] https://www.redhat.com/en/topics/linux/what-is-selinux

^[4] https://www.samsungknox.com/it

^[5] Android Sandbox. https://source.android.com/docs/security/app-sandbox?hl=it

^[6] https://man7.org/linux/man-pages/man2/fork.2.html

^[7] https://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/

^[8] Armando, A., Merlo, A., Migliardi, M., & Verderame, L. (2012). Would You Mind Forking This Process? A Denial of Service Attack on Android (and Some Countermeasures). Proc. of IFIP-Sec 2012 (p. 13-24). Heraklion, Crete: Springer.

^[9] Lee, B., Lu, L., Wang, T., Kim, T., & Lee, W. (2014). From Zygote to Morula: Fortifying Weakened ASLR on Android. Proc. of 2014 IEEE Symposium on Security and Privacy. San Jose, California, USA: IEEE.

^[10] J. Forristal – BlueBox (2013). Master Key Vulnerability. https://nvd.nist.gov/vuln/detail/CVE-2013-4787

^[11] Google and Alphabet Vulnerability Reward Program. https://bughunters.google.com/

^[12] Schlegel, R., Zhang, K., Zhou, X., Intwala, M., Kapadia, A., & Wang, a. X. (2011). SoundComber: A stealthy and context-aware sound trojan for smartphones. Proc. 18th Annual Network and Distributed System Security Symposium (NDSS ’11). San Diego, California: The Internet Society.

^[13] https://man7.org/linux/man-pages/man7/inotify.7.html

^[14] Ruggia, A., Possemato, A., Merlo, A., Nisi, D., & Aonzo, S. (2023). Android, Notify Me When It Is Time To Go Phishing. Proc. of the 8th IEEE European Symposium on Security & Privacy (EuroS&P 2023). Delft, The Netherlands: IEEE.

Questo articolo è stato estratto dal white paper “Mobile Security – Nozioni e Riflessioni” disponibile in maniera libera e gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/mobile-security-nozioni-e-riflessioni/

Articolo a cura di Alessio Merlo

https://www.ictsecuritymagazine.com/articoli/sicurezza-del-sistema-operativo-android/

Set 23, 2024 Stefano Silvestri Hacking, Malware, Minacce, News, Phishing, Tecnologia, Vulnerabilità 0

---

Nell’ultima settimana, il CERT-AGID ha condotto un’analisi approfondita delle minacce informatiche rilevanti per lo scenario italiano.

L’indagine ha portato all’identificazione di 56 campagne malevole, di cui 41 specificamente mirate a obiettivi italiani e 15 di natura più generica ma con impatto sul territorio nazionale.

A seguito di questa attività, il CERT-AGID ha fornito ai suoi enti accreditati un totale di 778 indicatori di compromissione (IoC), strumenti essenziali per rilevare e contrastare queste minacce.

I temi più rilevanti della settimana

Nell’ultima settimana, le campagne malevole sul territorio italiano hanno sfruttato 21 temi diversi. Tra questi, il Banking è stato particolarmente colpito, con numerose campagne di phishing e smishing rivolte ai clienti di istituti come Intesa Sanpaolo, Monte dei Paschi di Siena, Banca Popolare di Sondrio e Poste Italiane. Inoltre, il malware Irata è stato diffuso tramite file APK ai danni dei clienti di N26.

Il tema degli Ordini è stato utilizzato per veicolare vari malware come FormBook, AgentTesla, Remcos e PXRECVOWEIWOEI attraverso email.

Le campagne legate ai Documenti hanno preso di mira DocuSign con attacchi di phishing e hanno diffuso i malware AgentTesla e AsyncRAT.

Il tema dei Pagamenti è stato sfruttato sia per campagne di phishing che per la diffusione dei malware Vidar (tramite PEC) e Adwind (via email). Gli altri temi identificati sono stati impiegati per diverse campagne di malware e phishing.

Tra gli eventi di particolare interesse, è stata individuata una nuova campagna che diffonde il malware Vidar attraverso PEC compromesse, simulando richieste di pagamento per false fatture insolute e sfruttando un vecchio dominio del portale Excite.

È stata inoltre rilevata una campagna di phishing bancario che sfrutta il tema SPID per raccogliere le credenziali di accesso degli utenti di vari istituti bancari italiani, invitandoli a inserire i propri dati su una pagina web fraudolenta con il pretesto di rinnovare l’identità digitale.

Infine, è emersa una nuova campagna mirata agli utenti di GitHub per diffondere il malware Lumma Stealer, avvertendo i destinatari di una presunta vulnerabilità di sicurezza nei loro repository e inducendoli a compiere azioni che consentono l’esecuzione del codice malevolo.

Malware della settimana

Nel corso della settimana sono state identificate 11 famiglie di malware che hanno preso di mira l’Italia.

Tra le campagne più significative, AgentTesla si è distinto con cinque attacchi italiani incentrati sui temi “Documenti” e “Ordine” e veicolati tramite email con allegati BAT, EXE, ISO e RAR. Si registrano anche due campagne generiche, tutti diffusi tramite email con vari allegati EXE e ZIP.

FormBook ha lanciato due campagne italiane e una generica sul tema “Ordine”, mentre Lumma Stealer ha sfruttato i temi “Avvisi sicurezza” ed “Energia” in due campagne italiane che hanno sfruttato link malevoli ed email con allegati EXE e PDF.

Vidar ha condotto una campagna italiana focalizzata sui “Pagamenti”, utilizzando PEC con allegati JS. AsyncRAT ha colpito con una campagna italiana sul tema “Energia” e una generica sui “Documenti”, sfruttando email con allegati JAR e EXE.

Irata si è concentrato sul settore bancario, diffondendosi tramite SMS con APK malevoli. Umbral è stato rilevato in una campagna generica veicolata via email.

Remcos ha preso di mira il settore bancario italiano con email contenenti allegati HTML. VIPKeylogger ha lanciato una campagna generica sui “Pagamenti”, mentre PXRECVOWEIWOEI si è diffuso attraverso una campagna generica sul tema “Ordine”, tramite email contenti link a file VBS.

Infine, Adwind ha colpito l’Italia con una campagna incentrata sui “Pagamenti”, utilizzando email con allegati HTML e PDF contenenti link a file JAR malevoli.

Queste diverse campagne mostrano la varietà e la sofisticazione delle minacce informatiche attuali, sfruttando temi comuni e metodi di diffusione diversificati per colpire utenti e organizzazioni in Italia.

Phishing della settimana

Nell’ambito delle attività di monitoraggio delle minacce informatiche, la settimana appena trascorsa ha visto emergere un significativo numero di campagne di phishing, che hanno coinvolto complessivamente 22 marchi diversi.

Tra le varie campagne rilevate, due in particolare si sono distinte per la loro intensità e frequenza. La prima ha preso di mira i clienti di Intesa Sanpaolo, uno dei maggiori gruppi bancari italiani.

Questa concentrazione di attacchi verso un’istituzione finanziaria così rilevante suggerisce un tentativo coordinato di sfruttare la vasta base clienti della banca, probabilmente mirando a ottenere credenziali di accesso e informazioni finanziarie sensibili.

Parallelamente, l’INPS è stato l’altro obiettivo principale delle campagne di phishing. La scelta di questo ente pubblico come bersaglio è particolarmente insidiosa, considerando la vasta platea di cittadini che interagiscono regolarmente con l’INPS per questioni previdenziali e assistenziali.

Formati e canali di diffusione

L’analisi delle campagne malevole ha rivelato l’uso di una varietà di formati di file, con dodici tipi diversi identificati.

I file eseguibili (EXE) hanno confermato la loro predominanza, essendo stati utilizzati in sei campagne distinte. Seguono i formati ZIP e HTML, ciascuno impiegato in tre occasioni separate. I file BAT, PDF e JAR hanno avuto una presenza moderata, apparendo in due campagne ciascuno.

Altri formati come APK, JS, RAR, SCR, VBS e ISO sono stati riscontrati in singole occorrenze, dimostrando la versatilità delle tattiche adottate dai cybercriminali.

Per quanto riguarda i metodi di diffusione, le email si sono riconfermate come il canale preferito dagli attori malevoli. Ben cinquantuno campagne separate hanno sfruttato questo mezzo di comunicazione, sottolineando la sua efficacia persistente nel raggiungere un vasto numero di potenziali vittime.

La Posta Elettronica Certificata (PEC) è emersa come un vettore significativo, essendo stata impiegata in tre casi distinti. Infine, gli SMS sono stati sfruttati in due occasioni, evidenziando come i cybercriminali continuino a diversificare i loro approcci per massimizzare la portata e l’efficacia delle loro campagne malevole.

---

---

---

https://www.securityinfo.it/2024/09/23/cert-agid-14-20-settembre-778-ioc-phishing-spid/?utm_source=rss&utm_medium=rss&utm_campaign=cert-agid-14-20-settembre-778-ioc-phishing-spid

https://www.securitymagazine.com/blogs/14-security-blog/post/101010-saas-governance-is-improving-but-ai-presents-new-challenges

Certificate authorities and browser makers are planning to end the use of WHOIS data verifying domain ownership following a report that demonstrated how threat actors could abuse the process to obtain fraudulently issued TLS certificates.

TLS certificates are the cryptographic credentials that underpin HTTPS connections, a critical component of online communications verifying that a server belongs to a trusted entity and encrypts all traffic passing between it and an end user. These credentials are issued by any one of hundreds of CAs (certificate authorities) to domain owners. The rules for how certificates are issued and the process for verifying the rightful owner of a domain are left to the CA/Browser Forum. One “base requirement rule” allows CAs to send an email to an address listed in the WHOIS record for the domain being applied for. When the receiver clicks an enclosed link, the certificate is automatically approved.

Non-trivial dependencies

Researchers from security firm watchTowr recently demonstrated how threat actors could abuse the rule to obtain fraudulently issued certificates for domains they didn’t own. The security failure resulted from a lack of uniform rules for determining the validity of sites claiming to provide official WHOIS records.

Specifically, watchTowr researchers were able to receive a verification link for any domain ending in .mobi, including ones they didn’t own. The researchers did this by deploying a fake WHOIS server and populating it with fake records. Creation of the fake server was possible because dotmobiregistry.net—the previous domain hosting the WHOIS server for .mobi domains—was allowed to expire after the server was relocated to a new domain. watchTowr researchers registered the domain, set up the imposter WHOIS server, and found that CAs continued to rely on it to verify ownership of .mobi domains.

The research didn’t escape the notice of the CA/Browser Forum (CAB Forum). On Monday, a member representing Google proposed ending the reliance on WHOIS data for domain ownership verification “in light of recent events where research from watchTowr Labs demonstrated how threat actors could exploit WHOIS to obtain fraudulently issued TLS certificates.”

The formal proposal calls for reliance on WHOIS data to “sunset” in early November. It establishes specifically that “CAs MUST NOT rely on WHOIS to identify Domain Contacts” and that “Effective November 1, 2024, validations using this [email verification] method MUST NOT rely on WHOIS to identify Domain Contact information.”

Since Monday’s submission, more than 50 follow-up comments have been posted. Many of the responses expressed support for the proposed change. Others have questioned the need for a change as proposed, given that the security failure watchTowr uncovered is known to affect only a single top-level domain.

An Amazon representative, meanwhile, noted that the company previously implemented a unilateral change in which the AWS Certificate Manager will fully transition away from reliance on WHOIS records. The representative told CAB Forum members that Google’s proposed deadline of November 1 may be too stringent.

“We got feedback from customers that for some this is a non-trivial dependency to remove,” the Amazon representative wrote. “It’s not uncommon for companies to have built automation on top of email validation. Based on the information we got I recommend a date of April 30, 2025.”

CA Digicert endorsed Amazon’s proposal to extend the deadline. Digicert went on to propose that instead of using WHOIS records, CAs instead use the WHOIS successor known as the Registration Data Access Protocol.

The proposed changes are formally in the discussion phase of deliberations. It’s unclear when formal voting on the change will begin.

https://arstechnica.com/?p=2051511

Remy Ra St. Felix spent April 11, 2023, on a quiet street in a rented BMW X5, staking out the 76-year-old couple that he planned to rob the next day.

He had recently made the 11-hour drive up I-95 from southern Florida, where he lived, to Durham, North Carolina. It was a long way, but as with so many jobs, occasional travel was the cost of doing business. That was true especially when your business was robbing people of their cryptocurrency by breaking into their homes and threatening to cut off their balls and rape their wives.

St. Felix, a young man of just 25, had tried this line of work closer to home at first, but it hadn’t gone well. A September 2022 home invasion in Homestead, Florida, was supposed to bring St. Felix and his crew piles of crypto. All they had to do was stick a gun to some poor schlub’s head and force him to log in to his online exchange and then transfer the money to accounts controlled by the thieves. A simple plan—which worked fine until it turned out that the victim’s crypto accounts had far less money in them than planned.

Rather than waste the opportunity, St. Felix improvised. Court records showed that he tied the victim’s hands, shoved him into a vehicle, and drove away. Inside the car, the kidnappers filmed themselves beating the victim, who was visibly bleeding from the mouth and face. A gun was placed to the victim’s neck, and he was forced to record a plea for friends and family to send cryptocurrency to secure the man’s release. Five such videos were recorded in the car. The abducted man was eventually found by police 120 miles from his home.

A messy operation.

So St. Felix and his crew began to look out of state for new jobs. They robbed someone in Little Elm, Texas, of $150,000 and two Rolex watches, but their attention was eventually drawn to a tidy home on Wells Street in far-off Durham. The homeowner there was believed to be a significant crypto investor. (The crew had hacked into his email account to confirm this.)

After his day of surveillance on April 11, St. Felix and his partner, Elmer Castro, drove to a local Walmart and purchased their work uniforms: sunglasses, a clipboard, reflective vests, and khaki pants. Back at their hotel, St. Felix snapped a photo of himself in this getup, which looked close enough to a construction worker for his purposes.

The next morning at 7:30 am, St. Felix and Castro rolled up to the Wells Street home once more. Instead of surveilling it from down the block, they knocked on the door. The husband answered. The men told him some story involving necessary pipe inspections. They wandered around the home for a few minutes, then knocked on the front door again.

But this time, when the wife answered, St. Felix and Castro were wearing ski masks and sunglasses—and they had handguns. They pushed their way inside. The woman screamed, and her husband came in from the kitchen to see them all fighting. The intruders punched the husband in the face and zip-tied the hands and feet of both homeowners.

Castro dragged the wife by her legs down the hallway and into the bathroom. He stood guard over her, wielding his distinctive pink revolver.

In the meantime, St. Felix had marched the husband at gunpoint into a loft office at the back of the home. There, the threats came quickly—St. Felix would cut off the man’s toes, he said, or his genitals. He would shoot him. He would rape his wife. The only way out was to cooperate, and that meant helping St. Felix log in to the man’s Coinbase account.

St. Felix, holding a black handgun and wearing a Bass Pro Shop baseball cap, waited for the shocked husband’s agreement. When he got it, he cut the man’s zip-ties and set him in front of the home office iMac.

The husband logged in to the computer, and St. Felix took over and downloaded the remote-control software AnyDesk. He then opened up a Telegram audio call to the real brains of the operation.

The actual robbery was about to begin.

https://arstechnica.com/?p=2051106

More than 1,000 ServiceNow Knowledge Base (KB) articles were found to be misconfigured. This misconfiguration could expose sensitive enterprise data to external users — including malicious actors. Potentially exposed information may include: 

Security leaders weigh in

Guy Rosenthal, Vice President of Product, at DoControl:

“This ServiceNow Knowledge Base exposure highlights a critical issue in SaaS security that we’re seeing more and more: the challenge of maintaining proper configurations across complex, ever-evolving platforms.

“The technical issues here are multifaceted. First, we’re dealing with legacy configurations. Many organizations are running older versions of ServiceNow where Knowledge Bases are set to public by default. It’s a classic case of “set it and forget it” — teams might not realize they need to revisit these settings. Then there’s the complexity of access controls. ServiceNow’s User Criteria feature is powerful, but it’s also easy to misconfigure. A small mistake in these rules can inadvertently grant access to unauthenticated users. It’s like leaving your front door unlocked because you thought you turned the key, but actually didn’t.

“The syncing issue with databases adds another layer of complexity. When you’re dealing with large-scale enterprise systems, ensuring that access control changes propagate correctly across all connected databases and services is crucial. It’s not just about flipping a switch — it’s about making sure that switch affects all the right circuits.

“These challenges underscore a broader shift in the security landscape. The rapid adoption of SaaS platforms demands a fundamental change in our approach to cybersecurity. We’re moving beyond the era of simple perimeter defense into a world where continuous vigilance of our SaaS ecosystem is paramount.

“The intricacy of modern SaaS environments has outpaced our ability to secure them through manual processes alone. It’s clear that we need to embrace automated, round-the-clock monitoring and remediation strategies. This isn’t just a best practice anymore — it’s becoming a necessity for maintaining a robust security posture in the face of ever-increasing SaaS complexity.

“We’re seeing firsthand how critical it is for organizations to gain comprehensive visibility and control over their SaaS environments. Without it, vulnerabilities like these Knowledge Base exposures can slip through the cracks, potentially leading to significant data breaches. Organizations need to ensure that they have the right tools and insights required to navigate this complex SaaS security landscape effectively.”

Stephen Kowski, Field CTO at Pleasanton, Calif.-based SlashNext Email Security+:

“The recent discovery of more than 1,000 misconfigured ServiceNow enterprise instances exposing sensitive corporate information highlights the ongoing challenge of securing SaaS applications. Despite updates to Access Control Lists (ACLs) in 2023, many Knowledge Bases (KBs) remain vulnerable due to outdated configurations and misconfigured access controls. To mitigate these risks, organizations should prioritize regular diagnostics on KB access controls and implement Business Rules to deny unauthenticated access to KB content by default. By leveraging advanced security controls and automation, security teams can better protect their SaaS application environments and prevent data exposure.”

https://www.securitymagazine.com/articles/101062-configuration-flaw-puts-servicenow-knowledge-base-articles-at-risk

A new Federal Trade Commission (FTC) staff report that examines the data collection and use practices of major social media and video streaming services shows they engaged in vast surveillance of consumers in order to monetize their personal information while failing to adequately protect users online, especially children and teens.

The staff report is based on responses to orders issued in December 2020 to nine companies including some of the largest social media and video streaming services: Amazon.com, Inc., which owns the gaming platform Twitch; Facebook, Inc. (now Meta Platforms, Inc.); YouTube LLC; Twitter, Inc. (now X Corp.); Snap Inc.; ByteDance Ltd., which owns the video-sharing platform TikTok; Discord Inc.; Reddit, Inc.; and WhatsApp Inc.

The orders asked for information about how the companies collect, track and use personal and demographic information, how they determine which ads and other content are shown to consumers, whether and how they apply algorithms or data analytics to personal and demographic information, and how their practices impact children and teens.

The report found that the companies collected and could indefinitely retain troves of data, including information from data brokers, and about both users and non-users of their platforms. The staff report further highlights that many companies engaged in broad data sharing that raises serious concerns regarding the adequacy of the companies’ data handling controls and oversight. In particular, the staff report noted that the companies’ data collection, minimization and retention practices were “woefully inadequate.” In addition, the staff report found that some companies did not delete all user data in response to user deletion requests.

The staff report also found that the business models of many of the companies incentivized mass collection of user data to monetize, especially through targeted advertising, which accounts for most of their revenue. It further noted that those incentives were in tension with user privacy, and therefore posed risks to users’ privacy. Notably, the report found that some companies deployed privacy-invasive tracking technologies, such as pixels, to facilitate advertising to users based on preferences and interests.

Additionally, the staff report highlighted the many ways in which the companies fed users’ and non-users’ personal information into their automated systems, including for use by their algorithms, data analytics, and AI. The report found that users and non-users had little or no way to opt out of how their data was used by these automated systems, and that there were differing, inconsistent, and inadequate approaches to monitoring and testing the use of automated systems.

Furthermore, the staff report concluded that the social media and video streaming services didn’t adequately protect children and teens on their sites. The report cited research that found social media and digital technology contributed to negative mental health impacts on young users.

Based on the data collected, the staff report said many companies assert that there are no children on their platforms because their services were not directed to children or did not allow children to create accounts. The staff report noted that this was an apparent attempt to avoid liability under the Children’s Online Privacy Protection Act Rule. The staff report found that the social media and video streaming services often treated teens the same as adult users, with most companies allowing teens on their platforms with no account restrictions.

The report also noted some of the potential competition implications of the companies’ data practices. It noted that companies that amass significant amounts of user data may be in a position to achieve market dominance, which may lead to harmful practices with companies prioritizing acquiring data at the expense of user privacy. It noted that when there is limited competition among social media and video streaming services, consumers will have limited choices.

The staff report makes recommendations to policymakers and companies based on staff’s observations, findings, and analysis, including:

• Congress should pass comprehensive federal privacy legislation to limit surveillance, address baseline protections, and grant consumers data rights.
• Companies should limit data collection, implement concrete and enforceable data minimization and retention policies, limit data sharing with third parties and affiliates, delete consumer data when it is no longer needed, and adopt consumer-friendly privacy policies that are clear, simple, and easily understood.
• Companies should not collect sensitive information through privacy-invasive ad tracking technologies.
• Companies should carefully examine their policies and practices regarding ad targeting based on sensitive categories.
• Companies should address the lack of user control over how their data is used by systems as well as the lack of transparency regarding how such systems are used, and also should implement more stringent testing and monitoring standards for such systems; Companies should not ignore the reality that there are child users on their platforms and should treat COPPA as representing the minimum requirements and provide additional safety measures for children.
• The Companies should recognize teens are not adults and provide them greater privacy protections.
• Congress should pass federal privacy legislation to fill the gap in privacy protections provided by COPPA for teens over the age of 13.

https://www.securitymagazine.com/articles/101064-ftc-investigates-video-streaming-and-social-media-for-data-collection

The Overseas Security Advisory Council (OSAC) has announced the appointment of a new Executive Director, Supervisory Special Agent Jerry J. Tavares. SSA Tavares served with the U.S. Marine Corps in Japan, the Philippines, and Egypt. He is fluent in Spanish, Lao, and Northern Thai, and holds a Bachelor of Business Administration from Columbus State University.

SSA Tavares previously held the position of DSS Division Director for Physical Security, where he was responsible for protecting more than 25,000 facilities and diplomatic sites across more than 170 countries. He promoted the modernization of the Department’s risk management system and implemented amendments to the Secure Embassy Construction and Counterterrorism Act.

Furthermore, SSA Tavares served as Deputy Regional Security Officer (RSO) at the U.S. Embassy in Baghdad, Iraq; RSO at the U.S. Embassy in Manama, Bahrain; and RSO at the U.S. Embassy in Vientiane, Laos. He also worked as Assistant RSO at U.S. Embassies in Iraq, Colombia, and Afghanistan.

In 2004, SSA Tavares began his career as a Special Agent in the DSS Miami Field Office. Later, he served as Agent in Charge with Dignitary Protection. SSA Tavares also worked as Branch Chief, Worldwide Protective Services, overseeing the solicitation, acquisition, and management of a $1.3-billion Task Order, offering security services for five U.S. State Department compounds in Kabul, Afghanistan.

https://www.securitymagazine.com/articles/101061-jerry-j-tavares-appointed-as-osac-executive-director

Set 20, 2024 Marina Londei Approfondimenti, Attacchi, Attacchi, Hacking, In evidenza, News, RSS 0

---

Secondo il report del primo trimestre 2024 di Cisco Talos Incident Response (Talos IR) i cybercriminali stanno prendendo di mira le debolezze dell’autenticazione multi-fattore: l’analisi evidenzia che quasi la metà di tutti gli incidenti di sicurezza hanno riguardato la MFA.

Nel 25% dei casi, la causa è stata l’accettazione da parte degli utenti di notifiche push MFA fraudolente, mentre nel 21% dei casi l’implementazione dell’autenticazione multi-fattore non era corretta.

Nel caso delle notifiche push non autorizzate, i cybercriminali sommergono gli utenti con avvisi MFA finché le vittime, esasperate dai messaggi, accettano la richiesta e consentono l’accesso. Cisco Duo, l’azienda di Cisco che si occupa di servizi MFA, ha rilevato, da giugno 2023 a maggio 2024, circa 15.000 attacchi basati su notifiche push. L’analisi riporta inoltre che questi attacchi avvengono principalmente all’inizio della giornata lavorativa, quando gli utenti si autenticano ai sistemi aziendali.

Oltre alle notifiche push, per superare l’MFA i cybercriminali sfruttano i token di sessione rubati o usano tecniche di ingegneria sociale fingendosi qualcuno che la vittima conosce (come un collega del reparto IT) per ottenere le sue credenziali.

In alcuni casi gli attaccanti prendono di mira un fornitore dell’azienda per accedere agli account usando un dispositivo compromesso, oppure compromettono un singolo endpoint per disattivare del tutto la protezione MFA. Cisco Talos IR ha inoltre individuato attacchi che usano applicazioni software provenienti dal dark web che utilizzano script per disabilitare gli strumenti di sicurezza.

Per implementare correttamente l’MFA, i ricercatori di Cisco Talos consigliano di abilitare il number matching per avere un ulteriore livello di sicurezza e impedire agli utenti di approvare notifiche push dannose. È opportuno inoltre configurare un alert per l’autenticazione, in modo da individuare facilmente anomalie e modifiche alle policy dell’MFA, e formare gli utenti per aggiornarli sui pericoli a cui sono esposti.

L’MFA andrebbe in ogni caso implementata per tutti i servizi critici, compresi quelli di accesso remoto e gestione dell’accesso all’identità.

---

---

---

https://www.securityinfo.it/2024/09/20/i-cybercriminali-prendono-di-mira-lautenticazione-multi-fattore/?utm_source=rss&utm_medium=rss&utm_campaign=i-cybercriminali-prendono-di-mira-lautenticazione-multi-fattore

With the advancements in AI and other technologies, cybersecurity risks have grown more prevalent in an increasingly complex threat landscape. Naturally, this calls upon cyber professionals to uplevel and expand, but the cyber talent skills gap presents a challenge across industries. 

According to a recent study, nearly 90% of organizational leaders said they experienced a breach that they can partially attribute to a lack of cyber skills in the past year. Although there has been traction and initiatives across the security industry to address this problem, even from a federal level with the National Cyber Workforce and Education Strategy (NCWES), the skills gap persists.

A strong cybersecurity defense is essential to the success and longevity of any business that leverages technology in its day-to-day operations, but an industry with an added element of urgency that likely is not top-of-mind is the farming space. 

From planting to harvesting, farming leverages the latest and most advanced technology to centralize everyday operations to power these massive business operations. So much so that the world’s food security is dependent on securing and protecting the data of machines and equipment, which makes the deficiencies in the cybersecurity workforce a major point of concern. 

The stakes are high. But as long as the skills gap remains, there will be tremendous opportunities for aspiring security professionals to pursue careers in rapidly growing tech spaces like agriculture, where their talents can be fostered and cultivated. 

Analyzing the security needs in farming

While the need for cybersecurity talent is universal across all industries, especially as the threat landscape expands, the unique challenge it presents in agriculture is that the security of farming operations directly impacts our global food supply. The COVID-19 pandemic gave a glimpse of what food insecurity could look like, with shortages of staples in grocery stores and local markets. A massive cyberattack could amplify food insecurity on a global scale, leading to the decimation of entire crops or farms shutting down entirely.  

For the security sector in agriculture specifically, there is a knowledge gap around the uniqueness of the product — cyber threats on farming equipment are a new concept, and the skills needed to combat these threats are also not widely practiced. Because cybersecurity in the agriculture space is a less seasoned career path, young talent doesn’t always think to consider it. However, with a new and exciting need for talent in this particular field, there is an opportunity for young professionals to pursue a career in a rapidly developing space. 

The industry needs to capitalize on this rising interest by providing the proper tools and training to support talent growth and learning — whether through training programs that include hands-on, real-life simulations or recruitment initiatives that provide prospective talent with accessible opportunities to get involved in the industry. When it comes to addressing the skills gap, the challenge isn’t necessarily attracting talent, it’s creating an environment that can foster the specialized skill set that is needed. 

Addressing the skills gap

In any industry with a plethora of IoT devices, there are unique skills required from security professionals. For example, tractors have multiple unique operating systems and each one of those systems has a back door that is susceptible to threat actors. Examples range from correction services used for precision farming or open debug and USB ports that can be used to extract keys that are common across an entire fleet. Defenders must be able to easily identify whether each event is a malfunction or an attack. 

In terms of training, effective cybersecurity professionals need to know all IT domains — this means being familiar with all possible areas that could be attacked so they can identify where risks are and how they could be exploited. The best way to build this familiarity is to expose talent to hands-on training experiences where they can get familiar with attacks, learn what to watch for, and understand how attackers operate. The more a defender can think like an attacker, the better position they will be in to look at systems from a critical view. 

Talent also needs to be able to analytically assess a fleet — this particular skill is a new necessity for the industry. This skill means asking the right questions to get critical answers. It’s important to get cyber defenders to start at the highest level of analysis, and then to get more detailed: what kind of data do they have, who interacts with it, and are there other external connections? 

The challenge is to cultivate talent that can think critically while identifying weak spots. The best way to train talent to do this is to develop scenarios that align with this approach.

Cultivating talent

Inevitably, not providing proper training and education will only cause the skills gap to widen. Cybersecurity is a high-pressure and challenging job, and in the past year alone 74% of business leaders reported staff taking time off due to stress, fatigue or burnout. This is why it’s so important to provide people with the tools, resources and training that not only helps attract new talent to the field but also cultivates an environment that keeps people hungry to learn and do their best work. 

As technology advances in agriculture, a wider talent pool of cyber professionals becomes not only a nice thing to have but a necessity to ensure global food security. With the right initiatives, planning and training opportunities, the industry will be able to capitalize on this significant turning point in agriculture and create a workforce more skilled and readily able to defend against future attacks. 

https://www.securitymagazine.com/articles/101060-addressing-the-wider-cyber-skills-gap-through-the-agriculture-industry