Veracode, l’insicurezza critica del settore pubblico

La sicurezza applicativa è un aspetto strategico quando si parla di cybersecurity. Non si tratta solo di proteggere il funzionamento del software, ma anche e soprattutto dei dati elaborati, sfida ancora più importante se si parla di dati, software e applicazioni del settore pubblico. Maturano le tecnologie – si pensi anche all’AI – evolvono anche le minacce e per le istituzioni governative è imperativo rafforzare le proprie difese. Il rapporto Veracode, State of Software Security Public Sector 2024, fornisce una panoramica esauriente delle vulnerabilità che affliggono il settore pubblico, sottolineando una preoccupante stratificazione nel tempo di carenze nella sicurezza.

Lo spiega così Chris Eng, chief research officer di Veracode: “Parliamo proprio di un ‘debito’ di sicurezza che perdura da decenni, generato da software non patchati e configurazioni inadeguate che caratterizzano le applicazioni al servizio del settore pubblico. Senza un approccio sistematico e continuo alla ricerca e alla correzione delle falle, la PA è pericolosamente esposta agli attacchi dei criminali informatici”.
Il report fotografa un momento in cui gli attacchi informatici continuano a crescere, superando i ‘record’ precedenti, anno dopo anno. Per il settore pubblico, la situazione è poi particolarmente delicata perché una falla di sicurezza può compromettere dati sensibili di milioni di cittadini. I numeri presentati analizzano migliaia di applicazioni, utilizzando metriche avanzate per valutare la prevalenza e la gravità dei debiti di sicurezza.

I numeri di Veracode

State of Software Security Public Sector 2024 rivela che il 59% delle applicazioni del settore pubblico contiene vulnerabilità non risolte da almeno un anno, una percentuale superiore rispetto alla stessa criticità fotografata nel settore privato (42%). Questo significa non solo una maggiore esposizione a rischi, ma anche la lentezza nel rispondere alle minacce emergenti. Il rapporto evidenzia inoltre che il 40% delle entità pubbliche ha vulnerabilità di alta gravità, con rischi significativi per la stabilità delle reti governative.

La situazione potrebbe, quasi per assurdo, sembrare meno critica se si guarda all’analisi dei debiti di sicurezza (numericamente corrispondenti al 68%, rispetto al 71% di altri settori) ma le PA però tendono ad accumularne di più nel tempo e solo il 3% delle applicazioni in uso è privo di falle, rispetto al 6% degli altri. Oltre a questo, il 40% delle aziende della PA presenta vulnerabilità gravi e persistenti che proprio per queste due caratteristiche costituiscono un debito di sicurezza critico se queste falle venissero sfruttate dai criminali informatici, devastante per riservatezza, integrità e stabilità.

Dove si concentra il debito di sicurezza nella PA? Come è facile immaginare, questo capita nelle applicazioni più datate ed estese (22%), quando il debito è critico questa percentuale cresce ulteriormente al 30%, sottolineando la correlazione tra età delle applicazioni e accumulo di debito. Confrontando invece il profilo del debito distribuito nei diversi linguaggi di sviluppo, i ricercatori hanno scoperto che le applicazioni Java e .NET si distinguono come fonti significative di “insicurezza“.

Un ulteriore approfondimento: il debito di sicurezza nel settore pubblico riguarda principalmente il codice di primo sviluppo (93%), ma oltre la metà di quello di livello critico proviene da terze parti (più del 55%).

Questo dato rafforza l’importanza della Open Source Security Software Initiative (OS3I), un gruppo di lavoro inter-agenzie che si occupa di garantire che il software open source sia “tanto sicuro, protetto e sostenibile quanto aperto”, ma rimarca anche la necessità di concentrarsi sia sul codice di origine che su quello di terze parti per ridurre efficacemente il debito di sicurezza.

“Lo stato attuale della sicurezza del software nel settore pubblico rafforza l’importanza di adottare un approccio secure by design come standard per tutto il mondo connesso alla rete – prosegue Eng –. Apprezziamo il recente annuncio di Cisa (Cybersecurity Infrastructre Security Agency) del suo Secure by Design Pledge (Veracode è tra i primi firmatari, Ndr.).
Il nostro obiettivo con questa ricerca è quello di supportare ulteriormente i nostri partner del settore pubblico nel promuovere un utilizzo su larga scala di questi principi”.

Cisa Secure by Design Pledge, riferimenti universali

Li riprendiamo, i principi, perché anche se ‘pensati’ nel contesto Usa, offrono indicazioni di riferimento di fatto universali con un occhio fisso ai regolamenti già disponibili in Europa che per diversi aspetti già superano le proposte. Secure by Design Pledge propone una serie di impegni volontari per i produttori di software, con l’obiettivo di migliorare la sicurezza dei loro prodotti e servizi. Sintetizziamo quindi i principali impegni spiegati nel documento:

1. Autenticazione multifattoriale (Mfa): Entro un anno dalla firma del patto, i produttori devono dimostrare azioni volte ad aumentare l’uso dell’autenticazione multi-fattore tra i loro prodotti, con un’attenzione particolare per forme di Mfa resistenti al phishing.
2. Password predefinite: L’obiettivo è ridurre l’uso delle password predefinite nei prodotti, sostituendole con meccanismi di autenticazione più sicuri, inclusa, se possibile, la Mfa.
3. Riduzione intere classi di vulnerabilità: I produttori devono lavorare per ridurre significativamente la prevalenza di specifiche classi di vulnerabilità nei loro prodotti, come Sql Injection, gli attacchi portati tramite cross-site script e le vulnerabilità legate alla sicurezza della memoria.
4. Patch di sicurezza: Gli obiettivi in questo caso includono l’aumento dell’installazione delle patch di sicurezza da parte dei clienti, facilitando l’aggiornamento automatico dove possibile e supportando ampiamente l’applicazione delle patch.
5. Policy di divulgazione delle vulnerabilità: Entro un anno dalla firma, i produttori devono offrire una policy di divulgazione delle vulnerabilità che autorizzi il test dei loro prodotti da parte del pubblico, impegnandosi a non intraprendere azioni legali contro chi segnala vulnerabilità in buona fede.
6. Cve (Common Vulnerabilities and Exposures): I produttori devono dimostrare trasparenza nella segnalazione delle vulnerabilità, includendo i campi Cwe (Common Weakness Enumeration) e Cpe (Common Platform Enumeration) in ogni record Cve e pubblicando tempestivamente le Cve critiche o di alto impatto.
7. Evidenza sulle intrusioni: L’impegno qui è legato all’incremento della capacità dei clienti di raccogliere prove di intrusioni informatiche, fornendo artefatti e capacità come i log di audit che documentano aspetti critici dell’uso del prodotto.

© RIPRODUZIONE RISERVATA