Introduzione

La vulnerabilità “Heartbleed” di OpenSSL del 2014 è servita da campanello d’allarme per l’industria del software, richiamando l’attenzione sui rischi significativi inerenti la supply chain. Un semplice messaggio heartbeat ha esposto a un grave bug che ha messo a rischio i dati degli utenti, un evento che è servito come reminder urgente dell’importanza cruciale di testare le librerie di terze parti. Dopo un decennio, continuiamo a confrontarci con vulnerabilità simili. Nel nostro mondo sempre più connesso, dove i confini tra il mondo fisico e quello digitale si confondono, i rischi della supply chain nel ciclo di vita dello Secure Software Development Life Cycle (SSDLC) hanno conseguenze di vasta portata in un ampio spettro di settori. Questo articolo approfondisce il panorama dei rischi, esplorando i principi fondamentali dell’SSDLC, le tecniche per l’analisi del codice, i devastanti failure alla supply chain e l’importanza critica dell’SSDLC per l’Internet of Things (IoT) e la Operational Technology (OT).

Un ritorno a Heartbleed: l’Importanza di Testare Librerie di Terze Parti

All’indomani della vulnerabilità Heartbleed, l’industria del software ha iniziato a capire che trascurare di testare rigorosamente le librerie di terze parti era una svista fatale. OpenSSL, un software open source ampiamente utilizzato per comunicazioni sicure, conteneva un bug che consentiva l’accesso non autorizzato a informazioni sensibili. Anche se OpenSSL non è stato sviluppato dalle organizzazioni che hanno risentito da Heartbleed, esse hanno dovuto sostenere l’impatto maggiore poiché avevano incorporato questa libreria di terze parti con vulnerabilità nei loro sistemi.

Rischi della Supply Chain del Software e Principi SSDLC

L’incidente Heartbleed ha rafforzato l’importanza dei solidi principi SSDLC, un approccio che integra le pratiche di sicurezza direttamente nel ciclo di vita dello sviluppo del software. I componenti fondamentali di SSDLC includono l’analisi dei requisiti, la progettazione, la codifica, i test e la manutenzione, il tutto con particolare attenzione alla sicurezza fin dall’inizio. In particolare, l’approccio “shift-left” sottolinea la necessità di considerare i problemi di sicurezza il prima possibile nel ciclo di vita, piuttosto che applicare successivamente patch e correzioni al software sviluppato.

Analisi Statica e Dinamica del Codice

Le analisi statiche e dinamiche del codice fungono da strumenti preziosi in un approccio SSDLC. L’analisi statica del codice consiste nell’analisi del codice sorgente senza eseguire il programma, consentendo il rilevamento delle vulnerabilità nelle fasi iniziali. D’altra parte, l’analisi dinamica del codice prevede l’esame del software mentre è in esecuzione, consentendo l’identificazione di errori di runtime che l’analisi statica potrebbe non rilevare. La combinazione di questi approcci fornisce una visione completa delle potenziali vulnerabilità sia nel codice sviluppato che nelle librerie di terze parti.

Il fuzzing, noto anche come fuzz testing, è una tecnica molto efficace impiegata durante l’analisi statica del codice. Fondamentalmente, il fuzzing prevede l’iniezione deliberata di dati non validi o inaspettati in un sistema software al fine di scoprire vulnerabilità come arresti anomali, perdite di memoria o comportamenti imprevisti. Alimentando un sistema con un’ampia gamma di input irregolari, gli sviluppatori possono identificare problemi che potrebbero passare inosservati durante i test regolari ma che potrebbero essere potenzialmente sfruttati in scenari reali.

Un vantaggio significativo del fuzzing sta nella sua capacità di automatizzare la scoperta di nuove vulnerabilità precedentemente sconosciute. Gli strumenti di analisi statica convenzionali fanno molto affidamento sul rilevamento di modelli noti di codice non sicuro. Sebbene tali strumenti siano efficaci per rilevare problematiche comuni e ben comprese, potrebbero non scoprire vulnerabilità nuove o complesse. Il fuzz testing, d’altra parte, non si basa su modelli di vulnerabilità note, ma piuttosto sul comportamento del sistema di fronte a input irregolari.

Ciò rende il fuzzing un potente strumento per portare alla luce vulnerabilità precedentemente inesplorate. Detto ciò, l’implementazione efficace del fuzzing nell’analisi statica del codice richiede un’attenta pianificazione ed esecuzione. Per cominciare, gli sviluppatori devono decidere i tipi di input da utilizzare per i test. Questi potrebbero variare da dati totalmente casuali a input che sono versioni leggermente modificate di quelli normali. Quest’ultimo, spesso noto come “mutational fuzzing”, può essere particolarmente utile per scoprire problemi di casi limite. Inoltre, l’interpretazione dei risultati del fuzzing può essere complessa, poiché non tutti i comportamenti irregolari indicano una vulnerabilità della sicurezza. Pertanto, è fondamentale incorporare il fuzz testing come parte di un SSDLC completo, insieme ad altre tecniche di analisi statica e dinamica, per una comprensione completa della postura di sicurezza di un sistema software.

Gli analisti di sicurezza della Deutsche Telekom, utilizzando diverse tecniche per causare comportamenti imprevisti nelle applicazioni (code coverage-guided fuzzers – AFL e libFuzzer), hanno recentemente scoperto una vulnerabilità nella libreria MatrixSSL (AFL e libFuzzer) e AddressSanitizer, un tool per rilevare errori di memoria. CVE-2022-43974 è una vulnerabilità bufer overflow che potrebbe consentire la divulgazione di informazioni e l’esecuzione di codice in modalità remota. La libreria del software è stata patchata. MatrixSSL è una libreria open source integrata Secure Sockets Layer (SSL) e Transport Layer Security (TLS). MatrixSSL è scritto in C e fornisce un’opzione minimalista e ad alte prestazioni per l’aggiunta di funzionalità SSL/TLS ad applicazioni, dispositivi e sistemi integrati o con risorse limitate. Uno dei vantaggi più significativi di MatrixSSL è il suo poco spazio in memoria che la rende una scelta popolare per l’uso nei dispositivi IoT, sistemi in tempo reale e altri ambienti in cui le risorse di sistema sono preziose. MatrixSSL supporta una gamma di algoritmi crittografici ed è conforme ai principali standard del settore. Ciò lo rende flessibile e adattabile a diversi requisiti di sicurezza e ambienti normativi. MatrixSSL include anche funzionalità per analizzare e convalidare i certificati X.509, comunemente utilizzati nei protocolli SSL/TLS.

I ricercatori di sicurezza del software di Loria, INRIA in Francia, hanno scoperto una vulnerabilità buffer over-read nella libreria wolfSSL utilizzando un nuovo protocollo fuzzer chiamato tlspuffin. CVE-2022-42905 descrive questa vulnerabilità per questa libreria critica. WolfSSL, precedentemente noto come CyaSSL, è un’implementazione leggera, portatile e open source dei protocolli Secure Sockets Layer (SSL) e Transport Layer Security (TLS). È progettato pensando ai sistemi integrati e agli ambienti con risorse limitate, offrendo un minimo spazio, altamente desiderabile in tali ambienti. Un aspetto importante di wolfSSL è il suo focus su una solida sicurezza, con test completi e peer review per garantire la robustezza. Inoltre, offre supporto per crittografia hardware e accelerazione hardware per velocizzare le operazioni nei sistemi che includono hardware specifico per questo scopo. In termini di utilizzo, wolfSSL può essere trovato in un’ampia gamma di applicazioni, inclusi dispositivi IoT, router, stampanti e persino sistemi aeronautici, rendendolo uno strumento importante nello sviluppo di sistemi software sicuri.

Esempi di devastanti failure della Supply Chain del Software

Forse nessun incidente sottolinea le terribili conseguenze delle interruzioni della supply chain meglio dell’hack di SolarWinds Orion. Nel 2020, gli attori delle minacce hanno manipolato il processo di sviluppo della piattaforma software Orion, incorporando codice dannoso negli aggiornamenti software. L’uso diffuso del software SolarWinds Orion ha fatto sì che la vulnerabilità abbia raggiunto molte organizzazioni, comprese le agenzie governative. L’impatto diretto dell’attacco è stato notevole. Ha colpito fino a 18.000 clienti SolarWinds, inclusi diversi dipartimenti del governo degli Stati Uniti e aziende Fortune 500. La violazione dei dati ha compromesso informazioni sensibili, portando potenzialmente a minacce alla sicurezza nazionale e perdite finanziarie significative. Inoltre, il costo della riparazione, che include l’identificazione e la rimozione della minaccia, l’indagine sull’intera portata della violazione e il rafforzamento delle misure di sicurezza, è stato monumentale.

Oltre all’impatto diretto, l’hacking di SolarWinds Orion ha avuto anche conseguenze indirette di vasta portata. Ha accresciuto la consapevolezza delle potenziali vulnerabilità nelle supply chain dello sviluppo del software, portando a un maggiore controllo e attenzione normativa al ciclo di vita dello sviluppo del software e alle pratiche di cybersecurity. Ha spinto le organizzazioni di tutto il mondo a rivalutare le proprie strategie di sicurezza informatica, in particolare in relazione ai rischi del software di terze parti e della supply chain. L’hack ha sottolineato l’importanza fondamentale di rigorose misure di sicurezza informatica, monitoraggio continuo e capacità di risposta rapida per mantenere la sicurezza e l’integrità dei sistemi digitali.

Infine, l’hack di SolarWinds Orion ha avuto un impatto significativo sulla fiducia – fiducia nei fornitori di software, nei sistemi digitali e anche nell’infrastruttura di Internet. Ricostruire questa fiducia è un compito complesso, che richiede maggiore trasparenza, pratiche di sicurezza migliorate e, potenzialmente, regolamentazione e supervisione più rigorose. L’hack ha ricordato in maniera molto forte che nel nostro mondo digitale interconnesso, la sicurezza dei singoli componenti ha un impatto sulla sicurezza dell’intero ecosistema.

SSDLC in IoT e OT: Settore manifatturiero, automobilistico e sanitario

Le implicazioni dei principi SSDLC si estendono oltre il software tradizionale e nei campi in espansione di IoT e OT. Con queste tecnologie, i difetti del software possono tradursi in minacce alla sicurezza e alla protezione del mondo reale. Nel settore manifatturiero, le vulnerabilità possono interrompere le linee di produzione, portando a costosi tempi di inattività. Nell’industria automobilistica, le violazioni possono compromettere le prestazioni del veicolo e la sicurezza dei passeggeri. Nel frattempo, nel settore sanitario, i guasti del sistema e le violazioni dei dati potrebbero mettere a rischio la vita dei pazienti e la privacy. Un solido SSDLC che incorpori test rigorosi e misure di sicurezza è essenziale per mitigare questi rischi. Analizziamo il seguente esempio.

I Rockwell Automation PanelView sono una serie di pannelli utilizzati nei sistemi di controllo industriale. Questi dispositivi forniscono un’interfaccia grafica che consente agli operatori di interagire con il sistema di controllo di una macchina o di un processo. I terminali PanelView sono utilizzati per applicazioni come il monitoraggio, il controllo e la visualizzazione grafica delle informazioni, consentendo agli operatori di comprendere lo stato dell’operazione e prendere decisioni consapevoli sulla base dei dati presentati. I terminali PanelView sono disponibili in diverse forme, dimensioni e complessità, che vanno dai modelli base push-button ai modelli fullfeatured con touchscreen. Sono utilizzati in vari ambienti industriali tra cui la produzione, l’imballaggio e le industrie di trasformazione.

Le capacità di questi dispositivi possono variare notevolmente, ma in generale consentono agli utenti di:

1 Monitorare lo stato e le prestazioni della macchina o del processo in tempo reale.

2 Controllare le operation come l’avvio o l’arresto di un processo, la regolazione delle impostazioni o il comando manuale.

3 Visualizzare e analizzare i dati storici per il monitoraggio delle prestazioni o la risoluzione dei problemi.

4 Avvisare gli operatori di potenziali problemi o malfunzionamenti tramite allarmi o messaggi.

I dispositivi Rockwell Automation’s PanelView HMI possono essere utilizzati in vari ambienti sanitari per migliorare l’efficienza, mantenere il controllo della qualità e facilitare operazioni affidabili. Alcuni dei casi d’uso nel settore sanitario includono:

  • Industria Farmaceutica: Nei processi di produzione farmaceutica, PanelView può aiutare a monitorare e controllare i processi di produzione. Ciò potrebbe includere la supervisione di aspetti come la miscelazione degli ingredienti, il controllo della temperatura e della pressione o i processi di sterilizzazione. Può anche aiutare a garantire una rigorosa conformità alle normative mantenendo meticolose registrazioni in tempo reale dei parametri di processo e dei dati di controllo della qualità.
  • Apparecchiature Mediche: le interfacce PanelView possono essere integrate in varie apparecchiature mediche come macchine per dialisi, sistemi di ventilazione o macchinari di laboratorio automatizzati. Consentono agli operatori sanitari di controllare l’apparecchiatura, monitorare lo stato del paziente e regolare i parametri secondo necessità.
  • Infrastrutture Ospedaliere: gli ospedali spesso si affidano a sistemi complessi per il riscaldamento, la ventilazione e l’aria condizionata (HVAC), l’illuminazione e la sicurezza. PanelView può fornire un’interfaccia per la gestione di questi sistemi, semplificando il monitoraggio e la regolazione secondo necessità per un funzionamento ottimale e un’efficienza energetica.
  • Biotecnologie e Scienze Della vita: nei laboratori di biotecnologie e scienze della vita, PanelView può aiutare a gestire e monitorare processi come il sequenziamento del DNA, la sintesi proteica o i sistemi automatizzati di coltura cellulare. Può aiutare a garantire il mantenimento delle condizioni corrette e avvisare gli operatori di eventuali anomalie che potrebbero compromettere la validità degli esperimenti o della produzione.
  • Medical Supply Chain e Inventory Management: i sistemi automatizzati di archiviazione e recupero nel settore sanitario possono utilizzare le interfacce PanelView per gestire e monitorare le operazioni. Ciò include il monitoraggio dei livelli di inventario, l’automazione del processo di recupero e la supervisione delle attività di manutenzione.

In questi modi e altro ancora, PanelView di Rockwell Automation aiuta a semplificare i processi, mantenere gli standard di qualità e garantire operazioni affidabili ed efficienti nel settore sanitario. Poiché la trasformazione digitale continua a rimodellare l’assistenza sanitaria, è probabile che tali strumenti diventino sempre più essenziali. Questi dispositivi costituiscono una parte essenziale della tecnologia operativa in molti ambienti industriali, colmando il divario tra gli esseri umani e i processi automatizzati. Nel contesto di un mondo industriale sempre più digitale, contribuiscono all’efficacia e all’efficienza delle operazioni, aiutando le aziende a raggiungere una maggiore produttività e ridurre i tempi di inattività.

L’11 maggio 2023, la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti ha pubblicato un avviso sulle vulnerabilità che interessano Rockwell Automation PanelView 800 che potrebbero consentire l’esecuzione di codice in modalità remota. Il punteggio CVSS v3 di 9,8 è quello attribuito a questa CVE. Il prodotto è vulnerabile all’out-of-bounds write che potrebbe consentire a un utente malintenzionato di eseguire un heap buffer overflow se l’utente ha abilitato la funzionalità di posta elettronica nel file di progetto utilizzato da WolfSSL. Quella funzione è disabilitata per impostazione predefinita. Per gli utenti che richiedono la funzione, è disponibile una patch. CISA raccomanda le seguenti misure difensive:

  • Ridurre al minimo l’esposizione della rete per tutti i dispositivi del sistema di controllo e assicurarsi che non siano accessibili da Internet.
  • Individuare le reti del sistema di controllo e i dispositivi remoti dietro i firewall e isolarli dalle reti aziendali.
  • Quando è richiesto l’accesso remoto, utilizzare reti private virtuali (VPN), riconoscendo che le VPN potrebbero presentare vulnerabilità e dovrebbero essere aggiornate alla versione più recente disponibile. Una VPN è sicura solo quanto i suoi dispositivi connessi.

Framework Normativi che Impongono Controlli SSDLC

Man mano che il panorama del rischio si evolve, stanno emergendo quadri normativi che prescrivono controlli obbligatori in SSDLC. Questi includono standard come ISO/IEC 27034, che fornisce linee guida per la sicurezza delle applicazioni, e il NIST Cybersecurity Framework, che offre un approccio basato sul rischio per la gestione del rischio di sicurezza informatica. Questi framework mirano a garantire che le organizzazioni di tutti i settori integrino la sicurezza nei loro processi di sviluppo software.

Negli Stati Uniti, sulla base dell’ordine esecutivo presidenziale sul miglioramento della sicurezza informatica della nazione, l’Office of Management and Budget ha emesso una guida per garantire che le agenzie federali utilizzino software che è stato creato seguendo pratiche di sicurezza comuni. L’obiettivo è utilizzare solo software che segua standard di sviluppo software sicuri, crei un modulo di autocertificazione per i produttori e le agenzie di software e consenta al governo federale di identificare rapidamente i bug di sicurezza quando vengono scoperte nuove vulnerabilità.

Conclusioni

La vulnerabilità Heartbleed in OpenSSL ha messo in evidenza i rischi inerenti alla supply chain del software. Dieci anni dopo, continuiamo ad affrontare queste sfide, come dimostrato da incidenti come l’hacking di SolarWinds Orion. Poiché i confini tra il mondo digitale e quello fisico hanno i contorni sempre più sfumati e poiché ci affidiamo sempre più a IoT e OT in tutti i settori, la necessità di un solido SSDLC diventa più urgente che mai. L’adesione ai framework normativi che impongono i controlli SSDLC non è semplicemente un problema di compliance; è una necessità per la sicurezza e la resilienza del nostro mondo interconnesso. Guardando al futuro, il principio è chiaro: la sicurezza non può essere un dettaglio; deve essere incorporata in ogni fase del ciclo di vita dello sviluppo del software.

Autore: Viktor Polic

Twitter
Visit Us
LinkedIn
Share
YOUTUBE