I sistemi cyberfisici (“CPS” / Cyber Phisycal Systems) e l’Internet of things svolgono un ruolo sempre più importante nelle infrastrutture critiche e nella nostra vita quotidiana: automobili, dispositivi medici, reti intelligenti ne sono un chiaro esempio. Una delle attività principali nell’ambito del Cybersecurity Assessment, consiste nella valutazione dei rischi di sicurezza dovuti a potenziali minacce e sfruttamento di vulnerabilità all’interno di questi prodotti. A differenza del tradizionale risk management in ambito sistemi informativi, la valutazione dei rischi del prodotto segue una metodologia simile, ma con uno scopo ben definito che è quello di comprendere la superficie di attacco del prodotto in questione.
Indice degli argomenti
Rischi del prodotto: si parte con la modellazione delle minacce
Tutto inizia con la modellazione delle minacce. La modellazione delle minacce (Threat modeling) serve per identificare, comunicare e comprendere minacce e mitigazioni nel contesto della protezione di un bene tangibile o intangibile di valore (asset).
La modellazione delle minacce può essere applicata a un’ampia gamma di “prodotti”, inclusi software, applicazioni, sistemi, reti, sistemi distribuiti, IoT. La modellazione delle minacce deve essere eseguita preferibilmente all’inizio, in modo che i risultati possano subito dare informazioni utili in fase di implementazione del prodotto.
Successivamente si valutano le potenziali vulnerabilità, quindi si procede al calcolo degli impatti degli scenari di minaccia, alla probabilità che si verifichino le vulnerabilità considerate, e da questo semplice prodotto, si può costruire la matrice dei rischi del prodotto.
I rischi del prodotto nei vari settori industriali
Questo processo che sembra semplice si differenzia a seconda dell’ambito/settore in cui operiamo e può essere più o meno complicato in base ai diversi standard/best practice che intendiamo applicare.
Automotive
Nel settore automotive, lo standard ISO 21434 di prossima pubblicazione nella versione finale, definisce i requisiti per la cosiddetta T.A.R.A (Threat Analysis e Risk Assessement).
Per eseguirla, si può ricorrere a varie metodologie: si possono usare metodi come Stride (ovvero categorizzare le minacce secondo la casistica Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privileges) oppure utilizzare attacchi ad albero come dettati dal progetto europeo Evita (E-safety Vehicle Intrusion Protected Applications) o ancora seguire altri metodi come Heaven o Octave.
Indipendentemente da questi metodi, è necessario giungere alla definizione di una mappa, in forma di tabella, dove si evidenziano tutte le minacce al nostro sistema e le relative vulnerabilità che associate ognuna a una probabilità e impatto, forniranno l’indicazione del livello di rischio associato.
Questo esercizio si deve fare senza trascurare nessuno degli asset di valore, cioè qualunque bene tangibile o intangibile che abbia valore per l’analisi: software, dati e connettività possono essere, ad esempio, le tre categorie di riferimento per identificare tutti gli asset del sistema, oppure le ECU (Electronic Control Units), le centraline presenti ormai numerosissime all’interno dei nostri veicoli con le associate funzioni e segnali di comunicazione (ad esempio tramite la rete CAN bus).
Ecco quali sono in sintesi i passi da eseguire:
- Asset Identification
- Asset Impact analyses
- Threat analyses
- Vulnerability Analyses, Attack Analyses
- Attack Feasibility Assessment
- Risk evaluation
Industria 4.0 e Energy
La serie di standard ISA / IEC 62443, sviluppata dal comitato ISA99 e adottata dalla Commissione elettrotecnica internazionale (IEC), fornisce un quadro flessibile per affrontare e mitigare le vulnerabilità di sicurezza attuali e future nei sistemi di automazione e controllo industriali (ICS) e in molti altri ambiti come prodotti di tipo IoT, Smart building, e Medical device. Il comitato attinge al contributo e alla conoscenza degli esperti di sicurezza di tutto il mondo per sviluppare standard di consenso applicabili a tutti i settori industriali e alle infrastrutture critiche. Lo standard è suddiviso in 14 documenti a loro volta distribuiti in 4 livelli: General, Policies and Procedures, System, Component.
In particolare, i documenti nel terzo livello rispondono ai requisiti a livello di “sistema”. Il documento di riferimento per la Risks Analysis è il seguente:
- IEC – 62443-3-2: “Security Risk Assessment and System Design”
- Affronta la valutazione dei rischi per la sicurezza e la progettazione del sistema.
Ecco gli step fondamentali da seguire in base a questa normativa:
- Identificare il SUC (System Under Consideration)
- Valutazione iniziale del rischio per la sicurezza informatica.
- Suddividere il SUC in zone e condotti (Zones and conduits)
- Confrontare i rischi
- Eseguire una valutazione dettagliata dei rischi per la sicurezza informatica
- Documentare i requisiti, i presupposti e i vincoli della sicurezza informatica.
- Approvazione finale da parte del proprietario della risorsa (Asset owner)
TLC
La raccomandazione ITU-T X.1055 (Risk management and risk profile guidelines for telecommunication organizations) descrive e raccomanda i processi, le tecniche e i profili funzionali per la gestione del rischio di sicurezza delle informazioni per le telecomunicazioni a supporto delle altre raccomandazioni ITU-T. Questi processi e tecniche possono essere utilizzati per valutare i requisiti di sicurezza e i rischi identificati nelle telecomunicazioni e aiutano a selezionare, implementare e mantenere / aggiornare adeguati controlli dei rischi per la sicurezza delle informazioni. Esistono molte metodologie specifiche che sono state sviluppate per soddisfare i requisiti per la gestione del rischio.
La raccomandazione fornisce i criteri per la valutazione e la selezione di metodologie appropriate per un’organizzazione di telecomunicazioni.
Il processo di gestione del rischio comprende le seguenti fasi.
Valutare innanzitutto il rischio, considerando quanto segue:
- Asset e loro valore o utilità (es: “Information Assets, HW Assets, SW Assets, Services, Facility and supporting utility system, People”).
- Minacce e vulnerabilità associate a queste risorse (in base a: confidenzialità, integrità, disponibilità)
- Rischio di esposizione di queste risorse a minacce e vulnerabilità (ovvero perdita di confidenzialità, integrità, disponibilità ma anche di autenticazione, responsabilità e affidabilità)
- Rischi e impatti derivanti da questo rischio di esposizione (Profilazione dei rischi)
Segue la fase del trattamento del rischio, considerando quanto segue:
- selezione dei controlli;
- allocazione di risorse, ruoli e responsabilità;
- implementazione dei controlli.
Infine, segue la fase di monitoraggio dei rischi, considerando quanto segue:
- misurazioni relative al rischio;
- revisione e rivalutazione dei rischi;
- procedure per aggiornare e migliorare i controlli:
Avionica
Nel settore Avionico/Aerospace la norma di riferimento principale è quella della RTCA (“Radio Technical Commission for Aeronautics”) chiamata DO-326 “Airworthiness Security Process Specification” che insieme a quella equivalente europea EUROCAE ED-202, rappresenta di fatto il set di standard obbligatori in materia di Cybersecurity per i velivoli e i sistemi di bordo.
La valutazione del rischio per la sicurezza può essere eseguita a due livelli di sviluppo: aeromobile e sistema. A ogni livello, si ha la responsabilità di identificare eventuali rischi inaccettabili derivanti da scenari di minaccia.
La valutazione del rischio per la sicurezza deve essere eseguita in due fasi di sviluppo:
- valutazione preliminare del rischio per la sicurezza, eseguita durante la fase di progettazione.
- valutazione del rischio finale di sicurezza, finalizzata durante la fase di integrazione.
Le attività da svolgere sono organizzate secondo la seguente ripartizione,
- Determinare l’ambiente operativo dell’aeromobile/sistema per la sicurezza delle informazioni
- Identificare le condizioni e gli scenari di minaccia e valutare i rischi e le vulnerabilità per la sicurezza del sistema.
- Identificare le condizioni e gli scenari di minaccia e valutare i rischi e le vulnerabilità per la sicurezza degli aeromobili.
IoT
Gli attacchi moderni abbracciano un’ampia gamma di possibili mezzi e motivazioni. Gli approcci per enumerare le minacce informatiche e i metodi di attacco includono elenchi di vettori di attacco come riferisce la best practice di OWASP (Open Web Application Security Project) o l’approccio di categorizzazione delle minacce Stride e la modellazione delle minacce.
La best practice OWASP è di fatto lo standard riconosciuto a livello mondiale per la sicurezza del software, mantiene e aggiorna la lista delle principali vulnerabilità sia in ambito SW che per il mondo Mobile e IoT. In particolare, la “IoT Top Ten” include le seguenti dieci principali categorie di vulnerabilità potenziali nei dispositivi IoT:
1. Insecure web interface
2. Insufficient authentication/authorization
3. Insecure network services
4. Lack of transport encryption
5. Privacy concerns
6. Insecure cloud interface
7. Insecure mobile interface
8. Insufficient security configurability
9. Insecure software/firmware
10. Poor physical security
Questo elenco è un buon punto di partenza per analizzare i tipi di attacco rilevanti. Anche il modello Stride è stato esteso per incorporare i sistemi IoT. Questo modello consente di individuare rapidamente le minacce al nostro dispositivo, seguendo la relativa categorizzazione, come evidenziato nel seguito:
- Spoofing: questo è un tipo di minaccia in cui una persona o un dispositivo utilizza le credenziali di un’altra persona come login e password. Un dispositivo può utilizzare un ID dispositivo contraffatto.
- Tampering: alterazione dei dati relativi a un dispositivo o attraversamento della rete.
- Repudiation: negazione del coinvolgimento di una persona o di un dispositivo in una particolare transazione o evento. Si riferisce alla capacità (o alla sua mancanza) di rintracciare quale persona o dispositivo era responsabile di un evento.
- Information Disclosure: esposizione di informazioni a persone che non dovrebbero avere accesso ad esse. Nell’Industrial Internet, questo potrebbe significare i dati dei sensori per una città intelligente nelle mani di persone con l’intenzione di lanciare un attacco alla città.
- Denial of service: si riferisce alla mancata disponibilità di un particolare servizio, spesso a causa del consumo di risorse o dell’esecuzione inaffidabile.
- Elevation of privileges: un utente senza privilegi ottiene un accesso sufficiente per compromettere o distruggere un intero sistema. Nell’elevazione delle minacce di privilegio, un utente malintenzionato ha penetrato tutte le difese del sistema ed è diventato parte del sistema affidabile stesso, una situazione davvero pericolosa
Dispositivi medicali
Nel settore dei dispostivi medicali, una norma di riferimento principale è quella della FDA (Food and Drug Administration), “Content of Premarket Submissions for 11 Management of Cybersecurity in Medical Devices” e l’analoga norma FDA per la parte Post-Market, oltre che alle recenti normative europee come MDR e MDCG.
Le raccomandazioni in questa guida hanno lo scopo di aiutare i produttori a:
1) impiegare un approccio basato sul rischio per la progettazione e lo sviluppo di dispositivi medici con adeguate protezioni di sicurezza informatica;
2) adottare un approccio olistico alla sicurezza informatica dei dispositivi valutando rischi e mitigazioni durante il ciclo di vita del prodotto;
3) garantire la manutenzione e la continuità della sicurezza dei dispositivi critici ed essenziali
4) promuovere lo sviluppo di dispositivi affidabili per contribuire a garantire la sicurezza continua ed efficacia dei dispositivi. La FDA raccomanda ai produttori di prendere in considerazione i seguenti elementi mentre affrontano la sicurezza informatica durante la progettazione e lo sviluppo del loro dispositivo medico.
- Identificazione di risorse, minacce e vulnerabilità
- valutazione dell’impatto di minacce e vulnerabilità sulla funzionalità del dispositivo e fine utenti / pazienti;
- valutazione della probabilità di sfruttare una minaccia e una vulnerabilità;
- determinazione dei livelli di rischio e adeguate strategie di mitigazione; e valutazione del rischio residuo e criteri di accettazione del rischio.
Ai fini di aiutare a chiarire le raccomandazioni per la sicurezza informatica pre-commercializzazione della FDA, sono definiti due “livelli” di dispositivi in base al loro rischio di sicurezza informatica:
Livello 1 “Rischio di sicurezza informatica più elevato”
Un dispositivo è un livello 1 se vengono soddisfatti i seguenti criteri:
- il dispositivo è in grado di connettersi (ad esempio, cablato, in modalità wireless) a un altro prodotto medicale, o su una rete, o su Internet;
- un incidente di sicurezza informatica che interessa il dispositivo potrebbe provocare direttamente danni al paziente.
Livello 2 “Rischio di sicurezza informatica standard”
- un dispositivo medico per il quale non sono soddisfatti i criteri per un dispositivo di livello 1.
Conclusioni
Il proprio sistema/prodotto sarà sotto attacco da una molteplice varietà di tecniche di hacking soprattutto se si tratta di un prodotto di successo. Forse gli attaccanti vorranno semplicemente copiare il progetto, o forse vorranno anche decodificare e rubare le idee realizzative e gli algoritmi sottostanti per creare un vantaggio competitivo. Cercheranno anche di attaccare il sistema da remoto per rubare informazioni riservate o prendere il controllo dei componenti interni importanti. È necessario essere preparati a questi scenari di minaccia, valutando fin dall’inizio di un progetto la superfice di attacco del nostro prodotto.
La gestione dei rischi del prodotto dovrebbe aiutarci in questo processo:
- rischi individuati
- rischi valutati in termini di conseguenze per l’attività
- la probabilità e le conseguenze di questi rischi vengono comunicati e compresi
- definizione dell’ordine di priorità per il trattamento del rischio
- priorità per le azioni volte a ridurre i rischi che si verificano
- efficacia del monitoraggio del trattamento del rischio
I manager e il personale devono essere istruiti sui rischi e sulle azioni da intraprendere per mitigarli.
Il processo di gestione dei rischi del prodotto deve essere applicato all’organizzazione nel suo complesso, deve coinvolgere tutti i processi aziendali di sviluppo del prodotto e in base al classico modello di sviluppo a V, identificare e gestire i rischi lungo tutte le principali fasi di progettazione, come riassunto nella figura seguente.