Ingegneria della sicurezza e ciclo di vita dei sistemi digitali: l’approccio corretto

La sicurezza cibernetica è una necessità impellente per tutte le organizzazioni che fanno dell’innovazione e della cultura digitale il paradigma del proprio business e della propria missione e che, nello stesso tempo, hanno acquisito consapevolezza di dover contrastare le sempre più diffuse e pericolose minacce cibernetiche che mettono a rischio la loro stessa esistenza.

Tale capacità deve essere parte delle infrastrutture Enterprise e più in generale dei sistemi digitali (ICT/IT/OT), interni all’organizzazione o realizzati per i clienti.

Per quanto concerne i sistemi interni, è essenziale non solo garantire la qualità, la correttezza e la continuità operativa dei servizi che erogano a supporto dei processi produttivi e della missione, ma anche evitare l’esfiltrazione di informazioni che procurino o un vantaggio per gli avversari o ledano i diritti fondamentali dei propri utenti e della loro vita sociale.

Per quanto concerne i sistemi realizzati per i clienti, occorre offrire adeguate capacità e garanzie di sicurezza, in modo che non diventino leve per attacchi mirati e dannosi negli ambienti operativi in cui verranno dispiegati e usati.

Ecco che tutti i sistemi digitali devono essere pensati, progettati, realizzati e manutenuti per essere sicuri (cyber security) e resilienti (cyber resilience), per garantire il raggiungimento e il mantenimento degli obiettivi di business e di missione e per salvaguardare gli interessi di tutti gli stakeholder coinvolti.

Questa esigenza è stata ed è oggetto di innumerevoli processi normativi, a tutela degli interessi di settore, nazionali ed europei, tra questi: il Cyber Resilience Act, il Perimetro di Sicurezza Nazionale Cibernetica, il GDPR, le misure di sicurezza per la Pubblica Amministrazione e gli Schemi Nazionali per la valutazione e certificazione di sicurezza. Occorre dunque che sia indirizzata già nella realizzazione dei sistemi, attraverso opportuni processi di ingegneria della sicurezza.

“L’ingegneria della sicurezza deve pertanto essere parte essenziale della più ampia ingegneria di sistema” (cfr. NIST SP 800-160, Vol.1).

L’ingegneria di sistema può essere definita come “un approccio strutturato che coinvolge specialisti di diverse discipline tecniche e gestionali, risorse di vario genere (ad es.: economiche, tecnologiche, infrastrutturali), con l’obiettivo di trasformare le necessità e i vincoli degli stakeholder in soluzioni di cui dovrà supportare l’intero ciclo di vita” (cfr. ISO/IEC/IEEE15288).

Da questo punto di vista, risulta particolarmente calzante la definizione di ingegneria della sicurezza come “approccio e strumenti interdisciplinari finalizzati alla realizzazione di prodotti sicuri. È focalizzata sulla definizione delle esigenze dei clienti, dei requisiti e delle funzionalità di sicurezza, fin dall’inizio del ciclo di vita dello sviluppo dei sistemi; attraverso la produzione dei requisiti, la progettazione, l’implementazione e la verifica e convalida del sistema, considerando l’intero problema” (cfr. CNSSI 4009, 2022).

Seguire, inoltre, l’approccio dell’ingegneria di sistema basata sui modelli (Model-Based Systems Engineering) risulta particolarmente efficace anche in ambito sicurezza: creare il modello di un sistema nel suo ambiente operativo che ne descriva la struttura e il comportamento, anche dal punto di vista della sicurezza, facilita senz’altro la comprensione del problema di sicurezza da parte di tutti gli stakeholder e la sua gestione.

Se poi il modello (o sue parti) è realizzato in formato digitale ai fini della simulazione (Modeling & Simulation), si è in grado di effettuare migliori scelte progettuali, realizzative, operative e di manutenzione, in quanto basate sull’osservazione del suo comportamento e di sue caratteristiche non evidenti nella documentazione di design. Ciò è tanto più vero quanto più il sistema è complesso per numero di funzionalità, interazioni al suo interno o con il mondo esterno.

Armonizzare le regole UE per una cibersicurezza fondata sulla privacy

Architettura di sicurezza

Per architettura si intende “l’insieme dei concetti o delle proprietà fondamentali di un sistema nel suo ambiente rappresentati nei suoi elementi, relazioni, e nei principi della sua progettazione ed evoluzione” (cfr. ISO/IEC/IEEE 42010).

L’architettura di sistema è dunque finalizzata a catturare aspetti metodologici e comportamentali, relazioni sociali, obiettivi di business, competenze, requisiti normativi, concetti operativi, soluzioni tecniche, caratteristiche ambientali eccetera.

L’architettura di sicurezza deve essere parte essenziale dell’architettura di sistema e, in quanto tale, deve essere basata sul modello del sistema stesso e dell’ambiente in cui opera. Diventa quindi particolarmente utile l’applicazione di un framework architetturale che supporti la modellizzazione dei sistemi (ad es.: NAF, UAF, TOGAF ecc.).

È così possibile arricchire il modello del sistema e del suo ambiente operativo considerando anche aspetti fondamentali per la sicurezza:

In questo modo si evitano di applicare in modo dogmatico liste di requisiti-soluzioni preconfezionate, avulse dall’architettura di sistema e dagli interessi reali degli stakeholder.

Perfino strumenti molto diffusi di Security Risk Assessment (SRA) risultano essere “pericolosi”, se non si effettua una corretta e completa definizione dell’architettura di sistema e il loro output non viene inquadrato attraverso un framework architetturale.

In generale, uno strumento di SRA allo stato dell’arte dispone di una propria base di conoscenza che è definita una volta per tutte e associa asset a minacce e vulnerabilità, e queste ultime a contromisure.

In tal modo supporta il lavoro dell’analista, ma non dovrebbe sostituirlo e non dovrebbe essere un alibi per errori di progettazione, perché i fattori di rischio, la loro applicabilità agli asset e l’adeguatezza delle contromisure devono comunque essere valutati e rivisti rispetto all’architettura di sistema e ai numerosi aspetti che essa include e rappresenta, in primis il modello.

Modeling & Simulation

La Model-Based Systems Engineering, solida base anche per l’ingegneria della sicurezza, tende sempre più ad includere (cfr. S.E. Vision INCOSE) aspetti di Modeling & Simulation di supporto alle attività progettuali, implementative, operative e manutentive e ad oggi è considerata a tutti gli effetti parte della più ampia Digital Engineering.

I benefici dell’impiego di un modello del sistema (o di sue parti) e del suo ambiente operativo per effettuare simulazioni risultano evidenti in molti casi. Potrebbe accadere, ad esempio, che:

1. il ciclo di vita non risulti lineare, richiedendo che diversi cicli di vita di sue parti si innestino in quello principale con pianificazioni a volte non compatibili. Dei test di integrazione o verifica potrebbero richiedere alcune parti del sistema non ancora disponibili, ma che possono essere simulate;
2. occorra effettuare delle valutazioni e delle scelte per la fase di design del sistema vero e proprio, che debbano essere validate dall’utente finale per ridurre il rischio di progetto;
3. è necessario raggiungere obiettivi di performance, efficacia e qualità.

Simulare il sistema o parti di esso consente anche di effettuare attività, valutazioni e scelte di sicurezza, considerando interazioni complesse e comportamenti emergenti anche rispetto a specifiche minacce cibernetiche. Si possono, ad esempio:

1. affinare i modelli di minaccia e quindi di contromisure, effettuando un SRA più realistico;
2. valutare gli impatti delle contromisure sui servizi offerti dal sistema;
3. valutare la resilienza del sistema di fronte ad attacchi informatici in un Cyber Range;
4. effettuare delle scelte di design e di configurazione;
5. addestrare meccanismi di rilevamento basati sul comportamento del sistema specifico e sul rilevamento di anomalie (Machine Learning), che diventano in tal modo più efficaci e meno soggetti a produrre falsi positivi.

In questi casi l’applicazione della Digital Engineering comporta lo studio e la realizzazione di strumenti digitali utili allo sviluppo delle capacità di sicurezza del sistema.

Ciclo di vita

Il ciclo di vita di un sistema (dalla sua concezione alla sua gestione in ambiente di produzione) prevede una serie di attività definite all’interno di processi di ingegneria di sistema.

L’ingegneria della sicurezza, come parte integrante dell’ingegneria di sistema, deve seguire e integrarsi con i processi di quest’ultima.

Attraverso la classica rappresentazione a V (cfr. Model Views, D. Scheithauer e K. Forsberg, 2013), si possono evidenziare delle possibili attività di sicurezza nel ciclo di vita dei sistemi. Si tratta di una rappresentazione logica sequenziale, non strettamente cronologica che, nella accezione degli studi più recenti, tende a coprire sia aspetti architetturali che di processo su più livelli.

In questa sede considereremo, a titolo d’esempio, tre livelli, a partire dal cosiddetto sistema di sistemi che, per sue caratteristiche intrinseche, pone notevoli sfide per la sicurezza:

1. il sistema di sistemi (intero sistema), sistema composto da sottosistemi non strettamente dipendenti tra loro, gestiti e operati separatamente, che collaborano, che sono distribuiti geograficamente e sono interconnessi;
2. il sistema (sottosistema dell’intero sistema);
3. e gli elementi di sistema come limite inferiore di scomposizione.

Il modello a V proposto di seguito evidenzia da un lato i processi tecnici principali di ingegneria di sistema, per ogni diverso livello di astrazione (ambiente operativo, sistema di sistemi, sistema, suoi elementi, implementazione), dall’altro i processi di ingegneria della sicurezza associati.

Essendo una vista logica della normale gestione tecnica di progetto, è possibile “muoversi” all’occorrenza sia in senso verticale che orizzontale, anche iterando gruppi di attività, al fine di seguire o la metodologia di gestione desiderata (ad es. agile o waterfall) o gli eventi di progetto (ad es. interazioni con gli stakeholder esterni).

La linea blu in discesa indica un processo progressivo di scomposizione del sistema insieme ad un processo di affinamento e gestione dei requisiti e del modello.

La linea gialla in salita indica un processo progressivo di integrazione del sistema insieme ad un processo di verifica e validazione dei requisiti.

Le linee rosse estendono la classica V: la fase preparatoria allo sviluppo e la fase di gestione in esercizio. Quest’ultima potrebbe ricongiungersi ad altre fasi dello sviluppo o del testing, in quanto l’operatività offre indicazioni per migliorare ed effettuare correzioni (ad es. per nuove vulnerabilità / minacce), e il sistema o sue parti potrebbero essere oggetto nuovamente di analisi, modifiche e testing di sicurezza.

Di seguito si descrivono brevemente i diversi step della V, fornendo indicazioni di massima su possibili attività di sicurezza associate ad essi.

Requisiti di sicurezza

I requisiti tracciano la strada da seguire nella concezione e realizzazione di un sistema in quanto costituito da parti che interagiscono al fine di raggiungere gli scopi prestabiliti.

Essi evolvono durante il ciclo di vita del sistema. Si parte dai requisiti utente che ne catturano le esigenze nel contesto operativo, per arrivare, attraverso un processo di affinamento progressivo, ad una traduzione di tali esigenze in requisiti tecnico-implementativi, gestiti direttamente dai gruppi tecnici di sviluppo.

I requisiti di sicurezza non fanno eccezione. Dati gli obiettivi di sicurezza iniziali su confidenzialità, integrità, disponibilità, tracciamento degli eventi di sicurezza ecc., è possibile tradurli in termini di requisiti, attraverso un processo di valutazione del rischio di sicurezza e procedere, quindi, con l’identificazione di contromisure adeguate ad abbassarlo ad un livello accettabile.

Durante la progettazione, le contromisure dovranno essere specificate come requisiti con dettaglio crescente (lato sinistro della V), fino ad un livello sufficiente per consentirne la realizzazione come meccanismi, politiche da applicare sul sistema, configurazioni e procedure.

Occorre, però, prestare particolare attenzione su di un aspetto importante: le contromisure possono essere funzioni del sistema (ad es.: identificazione e autenticazione, controllo degli accessi ecc.) o sue proprietà (ad es.: assenza di vulnerabilità implementative, capacità di mantenere attive sue funzioni essenziali nonostante attacchi in corso, applicazione di principi di sicurezza come il principio dei privilegi minimi ecc.).

Molto spesso si rischia di considerare o solo alcune funzioni o solo alcune proprietà di sicurezza, ad esempio: se svolgiamo dei test per trovare e gestire vulnerabilità implementative e, se trovate, le risolviamo, non è detto che il sistema possa raggiungere gli obiettivi di sicurezza prefissati. Potremmo invece adagiarci su di un falso senso di sicurezza e, probabilmente, non sono stati implementate funzioni di sicurezza adeguate a garantire una protezione sufficiente dei dati e dei servizi di sistema.

Nel modello a V proposto sopra, l’affinamento dei requisiti procede in parallelo a quello di scomposizione, necessario ad individuare, ad esempio, parti del sistema che ne raggruppano funzionalità / proprietà e che possono essere realizzate in modo coerente con competenze e risorse comuni. La scomposizione può essere svolta per gradi, a seconda della complessità del sistema.

Anche in questo caso, i meccanismi di sicurezza seguono lo stesso iter. Va tuttavia tenuto presente che la capacità di sicurezza di un sistema è trasversale a tutte le altre e va definita sia nelle singole parti del sistema che nella sua interezza.

Ad esempio, l’assenza di vulnerabilità non può essere richiesta solo su sulle singole parti del sistema, ma deve esserlo anche per il sistema nella sua interezza; infatti, le parti interagendo tra loro fanno emergere comportamenti e caratteristiche sfruttabili da attori malevoli. Ciò è tanto più vero quanto più è complesso il sistema: un sistema di sistemi non offre vulnerabilità che sono la somma di quelle dei singoli sistemi, ma potrebbe farne emergere delle altre, strettamente collegate alle interazioni funzionali tra i sistemi che lo compongono.

Compliance

Quasi per tutte le attività di sicurezza rappresentate nel modello a V possono essere applicate leggi, regolamenti, standard, linee guida, best practice, metodologie ben definite.

Ciò dipende dal contesto in cui dovrà operare il sistema, ma anche dalle scelte interne dell’organizzazione che lo sviluppa. Avere un framework normativo di riferimento per l’ingegneria di sicurezza consente di consolidare competenze e processi produttivi e di aumentare la fiducia degli stakeholder sulle garanzie di sicurezza offerte.

Test di sicurezza

Risalendo dal lato della V di modello, i test diventano sempre più articolati, man mano che procede l’integrazione, con l’obiettivo di verificare che la soluzione finale sia correttamente integrata e funzionante per rispondere ai requisiti progettuali e alle attese dell’utente finale anche per quanto concerne gli aspetti di sicurezza.

I test di sicurezza (funzionali, vulnerability assessment statici e dinamici, pentest, audit rispetto a standard ecc.) devono essere ripetuti nei diversi step di risalita della V, inclusa la fase operativa. In quest’ultima possono essere svolti periodicamente, a valle di un incidente, su segnalazione di nuove vulnerabilità, a valle di cambiamenti nel sistema eccetera.

Hanno infatti l’obiettivo di intercettare quanto prima problematiche di sicurezza, ridurre le rilavorazioni, fornire confidenza che gli obiettivi di sicurezza definiti con l’utente finale siano correttamente raggiunti e mantenuti.

Security assurance

A ulteriore garanzia che siano soddisfatti gli interessi di sicurezza di tutti gli stakeholder, può essere implementato un processo di assurance sulla sicurezza del sistema. Un simile processo richiede che esperti di sicurezza (anche esterni al progetto o all’organizzazione) acquisiscano e valutino argomenti ed evidenze su come è stato affrontato il problema di sicurezza durante le varie fasi del ciclo di vita del sistema.

Tali evidenze possono coincidere con quelle già previste dai normali processi ingegneristici oppure possono esserne richieste delle altre, a seconda del processo che è stato definito. Sicuramente il livello di rischio a cui sarà esposto il sistema nel suo ambiente operativo e la sua criticità per i processi produttivi e di missione sono fattori importanti per determinare l’accuratezza dell’esame.

Gran parte della normativa di sicurezza è focalizzata su questo aspetto al fine di stabilire dei processi di misura e verifica della sicurezza di prodotti e sistemi, a tutela degli utenti finali. L’attuale proposta di Cyber Resilence Act europeo esprime esattamente questi principi. Anche la normativa sul Perimetro di Sicurezza Nazionale include dei requisiti di assurance per i prodotti più critici.

È fuor di dubbio che i processi di assurance non possono che trarre beneficio dai processi di ingegneria della sicurezza, poiché offrono basi solide per ogni asserzione sulla sicurezza del sistema. D’altro canto, l’assurance non può sostituire la corretta progettazione e implementazione delle soluzioni di sicurezza in un sistema, sarebbe come rincorrere l’esaminatore nelle sue richieste.

Conclusione

In sintesi, abbiamo visto un possibile macro-processo di ingegneria della sicurezza innestato nell’ingegneria di sistema per la concezione, realizzazione e manutenzione di sistemi digitali sicuri, dai più semplici ai più complessi come i sistemi di sistemi e le infrastrutture Enterprise.

Ovviamente, si tratta di indicazioni generali che non considerano i molti aspetti specifici (programmatici, tecnici, organizzativi ecc.) di un’organizzazione aziendale o di un progetto. Sono tuttavia utili a sensibilizzare, indirizzare e dare spunti di riflessione sulla necessità di sviluppare in modo puntuale processi e competenze ingegneristiche di sicurezza all’interno della propria organizzazione.

Infatti, la sicurezza di un sistema non dovrebbe basarsi solo su audit/test di sicurezza a posteriori o su soluzioni al contorno (ad es. firewall, antivirus o infinite altre soluzioni avveniristiche applicate senza un preciso razionale), dovrebbe, invece, essere parte delle sue fondamenta, considerata cioè fin dalla fase della sua concezione e sviluppata attraverso pratiche ingegneristiche consolidate, affinché siano rese esplicite e opportunamente indirizzate le esigenze di sicurezza legate all’operatività del sistema stesso e al valore dei dati che tratta.