Oggi il software rappresenta la componente principale dei sistemi informatici, in particolare di quelli mission-critical.

Man mano che le organizzazioni diventano sempre più dipendenti dalla tecnologia basata sul software aumentano anche i rischi per la sicurezza e la resilienza delle attività connesse.

Spesso, la gestione di questi rischi viene affrontata solo dopo la fase di implementazione, a causa di priorità concorrenti quali il rispetto degli obiettivi di costo e di tempistica.

Tuttavia la mancata gestione di tali rischi nelle fasi iniziali del ciclo di vita dei sistemi può aumentare l’impatto operativo e i costi di mitigazione, nonché limitare le opzioni di gestione.

I rischi legati alla sicurezza e resilienza software

Nei sistemi critici, è particolarmente importante gestire i rischi legati alla sicurezza e alla resilienza del software.

L’identificazione e la correzione proattiva delle vulnerabilità e dei punti deboli del software riducono al minimo il rischio di attacchi informatici, guasti ai sistemi ed altre interruzioni che potrebbero compromettere il corretto funzionamento.

A questo proposito, diverse normative europee e nazionali hanno individuato nel software e nella sicurezza informatica delle sfide continue per la resilienza dei Paesi e hanno posto l’accento sulle misure tecniche per contenerle, varando opportune previsioni normative.

Per affrontare queste sfide, i programmi di sviluppo e acquisizione devono iniziare a gestire i rischi per la sicurezza e la resilienza di un sistema fin dalle prime fasi del ciclo di vita e continuare a farlo per tutta la sua durata.

Ecco il Security engineering framework, uno schema dettagliato, recentemente elaborato dal Software engineering institute della Carnegie Mellon University (SEI), che illustra i processi di ingegneria del software che i programmi di sviluppo e acquisizione possono adottare per gestire i rischi di sicurezza e resilienza durante il ciclo di vita dei sistemi software.

Software assurance

La software assurance è un concetto fondamentale per la qualità, e di conseguenza per la sicurezza e la resilienza del software.

In ambito scientifico, la software assurance (SA) è definita come una disciplina dell’ingegneria o un campo di ricerca interdisciplinare che si occupa di garantire in modo sistematico e misurabile il livello di affidabilità (trustworthiness) del software.

Per “affidabilità” s’intende la probabilità che un sistema software funzioni come previsto e resista a tentativi di manipolazione o malfunzionamento, sia intenzionali che accidentali, per tutto il suo ciclo di vita.

In sintesi, la software assurance è un livello di affidabilità che garantisce il corretto funzionamento del software per tutto il suo ciclo di vita e, al contempo, l’assenza di vulnerabilità intenzionali o non intenzionali progettate o inserite come parte integrante del software stesso.

L’affidabilità del software è diventata sempre più importante per le organizzazioni di tutti i settori, a causa dell’influenza esercitata dal software sui sistemi critici per le attività aziendali.

La gestione della software assurance rappresenta una sfida a causa della crescita delle capacità, della complessità e dell’interconnessione dei sistemi che dipendono dal software.

Si consideri, per esempio, come la dimensione del software sia aumentata nel corso degli anni. Tra il 1960 e il 2000, la funzionalità complessiva di un sistema IT fornita dal software è aumentata dall’8% all’80%.

Si prevede che questa tendenza continui nel tempo. Man mano che il software eserciterà un controllo sempre maggiore sui sistemi complessi, il rischio potenziale rappresentato dalle vulnerabilità aumenterà di conseguenza.

In sintesi, la software assurance si configura come un approccio olistico
all’ingegneria del software orientato alla sicurezza e all’affidabilità. Attraverso l’applicazione di principi scientifici e metodologie rigorose lungo l’intero ciclo di vita del software, mira a costruire e mantenere un elevato livello di fiducia nel funzionamento e nella resilienza dei sistemi software contro minacce interne ed esterne.

Difetti e vulnerabilità del software: una prospettiva sul ciclo di vita

I sistemi che dipendono dal software hanno registrato una crescita esponenziale in termini di dimensioni e complessità del software stesso.

La prassi corrente nell’ingegneria del software, “build then test”, ha reso la loro realizzazione e qualificazione troppo costose.

Il rapporto “Reliability Validation and Improvement Framework“, redatto dal SEI, evidenzia le sfide legate alla certificazione di tali sistemi e presenta i risultati di diversi studi condotti dal governo americano e dall’industria del software.

L’indagine individua i principali fattori di causa e propone un quadro di riferimento per la convalida e il miglioramento dell’affidabilità del software, integrando diverse soluzioni tecnologiche: la convalida dei requisiti formalizzati, un approccio di progettazione basato su modelli incentrato sull’architettura che consente di individuare tempestivamente i problemi a livello di sistema tramite l’analisi, l’utilizzo dell’analisi statica per convalidare il comportamento del sistema e le sue altre proprietà e, infine, la gestione della fiducia nella certificazione tramite l’assurance del sistema.

Questo framework fornisce anche i principi per una serie di metriche che permettono di migliorare l’affidabilità in termini di costi, superando le sfide poste dalla complessità, dall’affidabilità e dalle metriche di costo del software esistente.

Fasi del ciclo di vita dello sviluppo del software

La figura 1 mostra le percentuali di introduzione e di identificazione dei difetti durante il ciclo di vita del software.

Questo dato è stato ricavato dai dati presentati nel rapporto citato. Gli studi sui sistemi critici per la sicurezza hanno dimostrato che il 70% di tutti gli errori viene introdotto durante le fasi di progettazione dei requisiti e dell’architettura. Tuttavia, solo il 20% di questi errori viene individuato entro la fine dello sviluppo del codice e dei test dei singoli componenti, mentre l’80,5% viene scoperto durante o dopo i test di integrazione.

Lo sforzo necessario per correggere i problemi relativi ai requisiti e alla progettazione nelle fasi successive può essere da 300 a 1.000 volte superiore rispetto a quello richiesto per la correzione in fase di sviluppo.

Inoltre, anche dopo la rielaborazione, è probabile che rimangano errori non individuati e, di conseguenza, la percentuale di affidabilità non raggiungerà il valore massimo auspicato.

Identificazione dei difetti del software

Considerata la complessità dello sviluppo di sistemi su larga scala che dipendono dal software, è comprensibile che nessun software sia privo di rischi. Anche i software di altissima qualità presentano difetti.

Per esempio, il codice migliore può presentare fino a 600 difetti per MLOC, mentre il codice di qualità media ne presenta in genere circa 6.000, alcuni dei quali sono debolezze che possono causare vulnerabilità.

La ricerca indica che circa il 5% dei difetti del software sono vulnerabilità di sicurezza. Di conseguenza, il codice migliore può presentare fino a 30 vulnerabilità per MLOC.

Per il codice di qualità media, il numero di vulnerabilità di sicurezza può arrivare fino a 300 per MLOC.

È importante notare che i tassi di difetti citati sono stime che forniscono una visione generale della qualità del codice e del numero di vulnerabilità in esso presenti.

Le percentuali di difetti nei progetti specifici possono variare notevolmente. Tuttavia, queste stime evidenziano l’importanza di ridurre le vulnerabilità di sicurezza del codice durante lo sviluppo del software.

Le best practice di codifica, le revisioni del codice e gli strumenti di analisi sono metodi importanti per individuare e correggere i punti deboli e le vulnerabilità note nel codice.

Sicurezza e resilienza del software per l’intero ciclo di vita

Da tutto ciò si evince che la sicurezza e la resilienza del software devono essere gestite per l’intero ciclo di vita, a partire dallo sviluppo dei requisiti di sistema di alto livello fino alle fasi di operatività e manutenzione.

Gli stakeholder del programma e del sistema devono applicare le migliori pratiche per l’acquisizione, la progettazione e l’implementazione di sistemi software sicuri e resilienti.

Diversi centri di ricerca hanno avviato una serie di iniziative per documentare le migliori pratiche per la gestione dei rischi di sicurezza e resilienza durante il ciclo di vita dei sistemi, fornendo un approccio per integrare la sicurezza e la resilienza in un sistema piuttosto che aggiungerle successivamente alla distribuzione.

Queste iniziative hanno prodotto diversi framework per la sicurezza informatica del software. Tra questi, i più rilevanti sono: il metodo Security engineering risk analysis (SERA), l’Acquisition security framework (ASF) e, per ultimo, il Security engineering framework (SEF).

Security engineering framework

Il software rappresenta una componente sempre più rilevante dei moderni sistemi aziendali e mission-critical.

Di conseguenza, garantire la qualità del software è diventato fondamentale per tutte le organizzazioni, a prescindere dal settore o dall’ambito di riferimento. Un aspetto fondamentale della qualità del software è il mantenimento dei rischi per la sicurezza e la resilienza entro un livello di tolleranza accettabile per l’intero ciclo di vita dei sistemi.
Il Security engineering framework (SEF) è una raccolta di processi e linee guida di ingegneria del software che permettono di gestire i rischi per la sicurezza e la resilienza durante tutto il ciclo di vita dei sistemi, dalla definizione dei requisiti fino alla fase di operations e support (O&S).

Il SEF fornisce una roadmap per integrare la sicurezza e la resilienza nei sistemi software prima del loro deployment e, successivamente, per mantenerle durante la fase di O&S. In sintesi, si tratta di una guida dettagliata che illustra le principali procedure di ingegneria del software e le modalità per attuarle.

Le procedure indicate dal framework contribuiscono a garantire che i processi di
progettazione, il software e gli strumenti siano sicuri e resilienti per l’intero ciclo di vita, riducendo il rischio che gli aggressori possano compromettere le informazioni e le risorse dei programmi e dei sistemi.

Allo stesso modo, anche i programmi di acquisizione possono utilizzare il framework per valutare le proprie procedure di progettazione e definire un percorso di miglioramento, riducendo così i rischi per la sicurezza e la resilienza dei sistemi basati su software implementati.

Il SEF organizza i processi in una struttura ad albero formata da obiettivi e domini e fornisce una guida approfondita per ciascuno di essi.

La guida illustra le capacità associate a ciascun obiettivo e fornisce un approfondimento di ciascuna procedura nel relativo contesto.

Sicurezza e resilienza

Fondamentalmente, il SEF è un risk-based framework che affronta contemporaneamente le criticità legate alla sicurezza e alla resilienza dei sistemi:

• la sicurezza stabilisce e mantiene misure protettive che permettono a un’organizzazione di svolgere la propria missione o le proprie funzioni critiche nonostante i rischi rappresentati dalle minacce ai propri sistemi. Tali misure possono includere una combinazione di misure di protezione, rilevamento, risposta e ripristino, e costituiscono la base dell’approccio di gestione dei rischi di un’organizzazione;
• la resilienza è la capacità di prepararsi e adattarsi a condizioni mutevoli e di riprendersi rapidamente dai disagi. La resilienza comprende la capacità di resistere e riprendersi da attacchi deliberati, incidenti, minacce o disastri naturali.

Il risk management è alla base della gestione della sicurezza e della resilienza.
Infatti, i metodi, gli strumenti e le tecniche di gestione dei rischi vengono utilizzati per gestire entrambi gli aspetti.

Tuttavia, la sicurezza e la resilienza considerano i rischi da prospettive diverse: la prima li valuta dal punto di vista della protezione, la seconda da quello dell’adattamento alle condizioni, alle sollecitazioni, agli attacchi e ai compromessi.

Come mostrato nella Figura 3, vi è una certa sovrapposizione tra le prospettive di rischio della sicurezza e della resilienza. Allo stesso tempo, però, la sicurezza e la resilienza presentano rischi e misure di mitigazione specifici.

Il framework specifica le procedure per la gestione dei rischi relativi alla sicurezza e alla resilienza.

La prospettiva adottata dall’organizzazione, che si tratti di sicurezza, di resilienza o di una combinazione di entrambe, influenza i rischi presi in considerazione durante una valutazione e l’insieme dei controlli disponibili per la loro mitigazione.

La prospettiva adottata dall’organizzazione può essere di sicurezza, di resilienza o una combinazione delle due. Data la correlazione tra sicurezza e resilienza, il framework utilizza il termine “sicurezza/resilienza” in tutto il documento.

Struttura del framework

Come mostrato nella Figura 4, il framework presenta una gerarchia di domain (ambiti), goal (obiettivi) e practice (procedure):

• i domain (ambiti) occupano il livello più alto della gerarchia. Un dominio cattura una prospettiva gestionale o tecnica unica per la gestione dei rischi di sicurezza/resilienza durante il ciclo di vita dei sistemi. Ogni dominio è supportato da due o più obiettivi che costituiscono il livello successivo della gerarchia;
• i goal (obiettivi) definiscono le capacità che un programma utilizza per integrare la sicurezza e la resilienza in un sistema software. Gli obiettivi correlati appartengono allo stesso dominio;
• le practice (procedure) occupano il livello finale e più dettagliato della gerarchia. Le pratiche descrivono le azioni che supportano il raggiungimento degli obiettivi. Il framework formula le practice sotto forma di domande. Le practice correlate appartengono tutte allo stesso obiettivo.

Il framework comprende 3 ambiti, 13 obiettivi e 119 procedure. La sezione seguente descrive gli ambiti e gli obiettivi del SEF come illustrato nella figura 5.

Domain 1: Engineering management

Questo ambito fornisce le basi per il successo del progetto, garantendo che le attività di sicurezza e resilienza siano pianificate e gestite in modo efficace. L’obiettivo del Domain 1 è quello di gestire efficacemente i rischi per la sicurezza e la resilienza del sistema sia che venga sviluppato, che sia acquisito.

I responsabili di programma e di progettazione combinano le loro competenze tecniche con la conoscenza del business e della mission per fornire una gestione tecnica e una leadership organizzativa ai progetti.

I responsabili hanno il compito di pianificare, organizzare e dirigere le attività di progettazione e di sviluppo di un programma di acquisizione. La gestione della progettazione è un tipo di gestione specializzato necessario per guidare con successo il personale tecnico e i progetti.

L’ambito comprende i seguenti tre obiettivi:

• Goal 1.1, Engineering Activity Management: l’obiettivo si occupa della gestione delle attività di progettazione. Le attività di progettazione della sicurezza/resilienza sono pianificate e gestite per l’intero ciclo di vita.
• Goal 1.2, Engineering Risk Management: l’obiettivo è occuparsi della gestione dei rischi legati alla progettazione. I rischi per la sicurezza e la resilienza che possono influire sul sistema vengono valutati e gestiti durante la fase di progettazione e sviluppo dello stesso.
• Goal 1.3, Independent Assessment: l’obiettivo è condurre una valutazione indipendente del programma o del sistema.

Domain 2: Engineering activities

Questo ambito riguarda le procedure quotidiane essenziali per garantire la sicurezza e la resilienza di un sistema software.

L’obiettivo del domain 2 è integrare la sicurezza e la resilienza nelle procedure di ingegneria del software già in uso nel programma.

Tutti i cicli di vita dei sistemi prevedono una base comune di attività ingegneristiche che vanno dalla specifica dei requisiti alla progettazione e alla costruzione del sistema.

Questo ambito amplia l’attenzione del modello del ciclo di vita dei sistemi di un programma includendo la sicurezza/resilienza. L’ambito comprende i seguenti otto obiettivi:

• obiettivo 2.1, Requisiti: l’obiettivo riguarda i requisiti di sicurezza/resilienza del sistema e dei suoi componenti software. In questa fase i requisiti vengono
• specificati, analizzati e gestiti;
• 2.2, Architecture: l’obiettivo tratta l’architettura del sistema. In particolare, vengono valutati e mitigati i rischi per la sicurezza e la resilienza derivanti dalle architetture dei sistemi e del software;
• goal 2.3, componenti di terze parti: l’obiettivo è rivolto alle componenti di terze parti. In questa fase vengono identificati e mitigati i rischi per la sicurezza e la resilienza che possono influire sui componenti di terze parti;
• 2.4, implementazione: l’obiettivo riguarda la fase di attuazione. In questa fase vengono implementati i controlli di sicurezza/resilienza e si valutano e gestiscono i punti deboli e le vulnerabilità del codice software;
• goal 2.5, test e valuazione: l’obiettivo è testare e valutare il software. In questa fase vengono identificati e risolti i rischi per la sicurezza/resilienza che possono influire sul sistema integrato durante le fasi di test e valutazione;
• obiettivo 2.6, autorizzazione ad operare: l’obiettivo è l’autorizzazione all’esercizio. In questa fase, il sistema viene autorizzato a entrare in funzione e il rischio residuo per le operazioni viene esplicitamente accettato;
• obiettivo 2.7, l’obiettivo è l’implementazione del software. In questa fase, si affronta il tema della sicurezza e della resilienza nelle attività di transizione e implementazione;
• obiettivo 2.8: operazioni e sostenibilità: l’obiettivo è l’operatività e la sostenibilità. Man mano che il sistema viene utilizzato e supportato nell’ambiente operativo vengono identificati e risolti i rischi e le problematiche relativi alla sicurezza e alla resilienza.

Domain 3: Engineering infrastructure

Questo ambito si occupa dei rischi relativi alla sicurezza e alla resilienza negli ambienti di progettazione, sviluppo, test e formazione.

Gli obiettivi del domain 3 sono l’utilizzo di software, strumenti e tecnologie che supportino le attività di progettazione e sviluppo del programma e la gestione dei rischi relativi alla sicurezza e alla resilienza dell’infrastruttura di progettazione.

I progettisti e gli sviluppatori utilizzano diversi software, strumenti e tecnologie per supportare le proprie attività di progettazione e sviluppo.

È necessario acquistare, installare e integrare con l’infrastruttura esistente i programmi software, gli strumenti e le tecnologie per l’ingegneria della sicurezza/resilienza.
L’infrastruttura di sviluppo è la parte dell’infrastruttura IT che supporta le attività di progettazione e sviluppo svolte dal personale del programma di acquisizione, dai consulenti e dai fornitori. Di conseguenza, l’infrastruttura può costituire un vettore di attacco per il sistema basato su software acquisito e sviluppato.

I team di supporto IT devono garantire l’applicazione di procedure di sicurezza e resilienza nella gestione dell’infrastruttura di sviluppo per una gestione adeguata dei rischi.

Questo ambito comprende i seguenti due obiettivi:

• obiettivo 3.1, Engineering software, strumenti e tecnologie: questo obiettivo riguarda i software, gli strumenti e le tecnologie per lo sviluppo del software. I software, gli strumenti e le tecnologie per la sicurezza/resilienza sono integrati nell’infrastruttura ingegneristica;
• obiettivo 3.2, questo obiettivo riguarda il funzionamento e la sostenibilità delle infrastrutture. In questa fase vengono identificati e mitigati i rischi per la sicurezza e la resilienza delle infrastrutture IT.

Rapporto in tre parti

Il documento è una raccolta di procedure di ingegneristiche del software per la gestione dei rischi di sicurezza e resilienza lungo il ciclo di vita dei sistemi. Fornisce una roadmap per integrare la sicurezza e la resilienza nei sistemi basati sul software e per mantenere tali capacità durante le operazioni e il mantenimento.

Le procedure del SEF mirano a garantire che i processi di progettazione, il software e gli strumenti siano sicuri e resilienti, riducendo la possibilità che gli aggressori possano compromettere le informazioni e le risorse del programma e del sistema.
Il rapporto è strutturato in tre parti principali:

• Parte 1, introduzione e concetti chiave: questa sezione introduce i concetti fondamentali relativi all’ingegneria dei sistemi, all’ingegneria del software e alla gestione del rischio. Include sezioni su concetti di sistema, gestione del rischio, gestione del rischio di sicurezza/resilienza e struttura del SEF.
• Parte 2, framework e linee guida: presenta le pratiche del SEF organizzate in una gerarchia di domini e obiettivi, fornendo linee guida dettagliate per ciascun obiettivo e pratica.
• Parte 3, appendici: contiene acronimi, un glossario di termini e definizioni e un elenco di riferimenti.

Gli ambiti del SEF forniscono la struttura organizzativa per il contenuto tecnico del framework, ovvero l’insieme di obiettivi e procedure, per il perseguimento di tre obiettivi principali: adottare un approccio risk-based, operare secondo il concetto security by design e considerare la sicurezza come obiettivo e non requisito del sistema.

Linee guida del framework

Le linee guida comprese nel framework, approfondite per ciascun obiettivo e ciascuna procedura, descrivono la capacità rappresentata da ogni obiettivo, il suo scopo, il contesto e le relative procedure di supporto. Esse definiscono anche i concetti chiave e le informazioni di base necessarie per comprendere l’intento di ciascuna fase.

In particolare, il framework documenta le principali procedure di ingegneria del software per la gestione dei rischi di sicurezza e di resilienza durante l’intero ciclo di vita dei sistemi. Il documento è destinato sia ai programmi di sviluppo, che di acquisizione, per valutare le loro attuali procedure di ingegneria della sicurezza/resilienza e definire un percorso di miglioramento, riducendo in definitiva i rischi nei sistemi basati su software distribuiti.

Il framework è condiviso con una community di sviluppatori e, pertanto, in continua evoluzione per recepire i feedback degli utilizzatori e per gestire i nuovi rischi per la sicurezza e la resilienza che dovessero emergere.

Bibliografia

• 2012, Reliability Improvement and Validation Framework, Peter H. Feiler, John B. Goodenough, Arie Gurfinkel, Charles Weinstock, Lutz Wrage.
• 2022, Acquisition Security Framework (ASF), Christopher Alberts, Michael Bandor, Charles M. Wallen, Carol Woody.
• 2024, Introduction to the Security Engineering Risk Analysis (SERA) Framework, Christopher J. Alberts, Carol Woody, Audrey Dorofee.
• 2024, Security Engineering Framework Managing Security and Resilience Risks Across the Systems Lifecycle, Christopher J. Alberts, Charles M. Wallen, Carol Woody, Michael S. Bandor, Tom Merendino.