L’analisi di sicurezza: l’approccio “safety case”

Introduzione

L’uomo moderno tecnologico-scientifico vive nella società del rischio. Non tutti ne sono coscienti ma molti lo ignorano (o fanno finta di ignorarlo). La cultura della sicurezza in Italia ha subito un forte balzo in avanti con l’emissione delle leggi sulla sicurezza sul lavoro (L. 626, 81/8 et alter; http://www.repertoriosalute.it/normativa-essenziale-2010-2019). Infatti, il testo unico in materia di salute e sicurezza nei luoghi di lavoro (noto anche con l’acronimo TUSL) è un complesso di norme in materia di salute e sicurezza sul lavoro, emanate con il Decreto legislativo 9 aprile 2008, n. 81.

In passato, pochi campi applicativi erano regolamentati da leggi specifiche concernenti la sicurezza. Tutti i sistemi, siano essi semplici e/o complessi, presentano implicazioni di problemi di sicurezza a cominciare dai sistemi dei trasporti (terrestri, aerei, navali, aerospaziali ecc.).

In campo aeronautico, è stata elaborata a livello internazionale una normativa esaustiva di sicurezza del volo valida sia in campo militare che civile, recepita in Italia dagli anni ‘50. Nelle altre nazioni europee e negli Stati Uniti d’America la cultura della sicurezza è certamente un passo avanti in termini tecnico-scientifici, poiché il mondo industriale e del lavoro ha una tradizione più antica. In queste nazioni è iniziato, con congruo anticipo, il discorso della formulazione della politica per lo sviluppo della analisi di criticità e di sicurezza dei sistemi e quindi della razionalizzazione scientifica della problematica della sicurezza. In questo panorama, il contributo della Health and Safety Executive alla prima edizione della norma CEI (IEC) 1508 è stato decisivo. Infatti nel Regno Unito, dopo la discussione sul “Rapporto Robens”, la legge che governa la salute e la sicurezza sul lavoro è stata varata nel 1974 con lo “Health and Safety at Work Act”. I principi dell’analisi del rischio e il principio “ALARP” (As Low As Reasonably Practicable) vengono impiegati normalmente già dagli anni ‘70.

A quei tempi, tra i campi di sicurezza più regolamentati spiccava il nucleare con la Direttiva apparsa sul G.U.C.E. (Gazzetta Ufficiale della Comunità Europea) N.11 del 20 febbraio 1959 (Direttiva 2 febbraio 1959), N.57 del 9 luglio 1962 (Direttiva 5 marzo 1962) e N. 216 del 26 novembre 1966 (Direttiva 27 ottobre 1966), successivamente modificata con la Direttiva Euratom 66/45 (Rif. 11,12, 13,14).

Tab. N° 1 Norme sulla Sicurezza Nucleare (Gazzetta Ufficiale)
1	GU L 13 del 17.1.2014, pag. 1.
2	GU L 296 del 7.11.2013, pag. 12.
3	GU C 33 E del 5.2.2013, pag. 46.
4	GU C 36 del 29.1.2016, pag. 76.
5	GU C 390 E del 18.12.2012, pag. 147.
6	GU C 36 del 29.1.2016, pag. 195
7	GU C 208 del 10.6.2016, pag. 697.

Più recentemente, queste direttive sono state aggiornate per diventare la Direttiva del Consiglio Europeo del 1 giugno 1976 relative alla “protezione sanitaria della popolazione contro i pericoli derivanti dalle radiazioni ionizzanti”. Una delle più recenti è la Direttiva 2014/87/Euratom del Consiglio Europeo dell’8 luglio 2014 che modifica la direttiva 2009/71/Euratom che istituisce un quadro comunitario per la sicurezza nucleare degli impianti nucleari.

Le “tre S” e il software

Recentemente, la problematica della sicurezza dei sistemi basati sui calcolatori e quindi la problematica della sicurezza del software è ormai regolamentata in modo profondo anche con il grande impulso dato al “cyber engineering”.

Esistono, per esempio, curricula universitari specifici e metodologie standardizzate di miglioramento dei processi di sicurezza. La nuova norma “UNI ISO 45001:2018 – sistema di gestione per la salute e sicurezza sul lavoro” sottolinea l’importanza della sicurezza e della security (protezione/salvaguardia). Esiste comunque un’enorme differenza fra la sicurezza – in inglese “safety” – e la “security”, ossia la protezione da azioni pericolose e quindi la salvaguardia (in inglese “saveguard”). Questi tre elementi di sicurezza si interfacciano fra di  loro secondo le relazioni mostrate in Fig. 1.

Ciò implica un risveglio dei processi di gestione e controllo manageriale. Anche le pubblicazioni tecniche in materia sono aumentate sensibilmente ma non ancora esiste un corpo ben preciso, rigoroso e maturo dei trattamento della problematica della sicurezza dei sistemi, con particolare riguardo ai sistemi basati su calcolatori e, quindi, alla sicurezza del software.

Alla base della transizione verso la società della cyber security e della IA (intelligenza artificiale) come parte integrante della sicurezza in generale, la parte da leone è ancora svolta dalla tradizione e dall’insegnamento orale basato soprattutto nella miriade di convegni e riunioni sull’argomento. La problematica della sicurezza sta vivendo quindi un momento di transizione verso una trattazione esauriente, completa e soddisfacente per le necessità moderne della società. In questo periodo di transizione, esistono vari tentativi di sistematizzazione dell’analisi di sicurezza e della relativa certificazione convalidata anche da leggi già emesse, ma che dovranno essere prontamente riviste per includere tutti o almeno la maggiore parte del “corpo” di discipline sulla sicurezza.

In altre parole, se si introducono innovazioni nei sistemi già esistenti, i problemi di sicurezza aumentano. Per esempio, aggiungere la programmabilità a un sistema già esistente che è già complesso di per sé: significa aumentare enormemente la complessità del sistema stesso. Sempre la programmabilità aumenta la complessità del sistema! L’introduzione di sistemi elettronici programmabili (PES) ha consentito e consente di aumentare la potenza del sistema, per esempio aumentando le interfacce dell’operatore oppure aumentandone le funzioni eseguibili. Tutto ciò si ottiene a discapito di un aumento di software che, quindi, richiede progettazione e verifica di buon funzionamento e affidabilità del software stesso. Tuttavia, questo aumento di software non è, a stretto rigore, un vero problema di software ma un problema di aumento di complessità globale del sistema. Diventano necessarie comprensione e autocoscienza per la realizzazione del successo del dispiegamento di sistemi, critici per la sicurezza, e che siano il risultato di un approccio multidisciplinare. Senza adeguata conoscenza e affidabilità nelle prestazioni di sicurezza del sistema, i sistemi critici per la sicurezza sono proni al guasto e possono provocare disastri. Questa posizione intellettuale equivale alla rinuncia al programma originario di ricerca e progettazione di sistemi sicuri al 100%, mentre purtroppo bisogna enfatizzare la problematica della sicurezza del software.

Garanzia di sicurezza adeguata

La comunità scientifica e quella professionale direttamente implicata nella progettazione di sistemi critici per la sicurezza riconoscono che non si può garantire al 100% la sicurezza dei sistemi. In particolare, non si può garantire al 100% la sicurezza di sistemi basati sull’impiego dei calcolatori e, quindi, sul software. Si assiste a un enorme aumento di sistemi basati su calcolatori con una storia relativamente priva di guasti critici che hanno condotto a veri e propri disastri. A riprova storica, si può accennare ad uno studio empirico – forse un pò datato – sulle morti procurate da guasti critici di calcolatori eseguito dal MacKenzie (Rif. 8), il quale ha stimato che la percentuale di morti dovuta a guasti critici prodotti da errori di software nei calcolatori, entro la fine dell’anno 1992, rispetto al numero totale di morti nell’intero pianeta è pari solo al 3% del numero totale che ammontava a circa 1100 ± 1.

La degradazione entropica dei sistemi fisici, la irreversibilità tipica dei processi e dei modi di guasto mostrano la tipica tendenza dei sistemi a degenerare nel caos. D’altro canto, l’idea (o legge) di Perow (Rif. 9) sugli “incidenti normali” (normal accidents) provocati da guasti dovuti alla complessità dei sistemi e dal forte accoppiamento dei vari sottosistemi influenzano la criticità dei sistemi. In questo ambito, la adeguatezza della garanzia della sicurezza rispetto a guasti procurati da errori di software rimane problematica anche se gli aspetti legali sono stati ormai affrontati con le varie direttive comunitarie e prima fra queste la Direttiva della Comunità Europea sulla Responsabilità del Prodotto dell’anno 1985. L’articolo 6 di questa direttiva definisce un prodotto difettoso “…quando non fornisce la sicurezza che una persona si aspetta…”.

L’obiettivo prefissato quindi  è l’analisi della garanzia dell’adeguatezza della sicurezza del sistema, mediante due argomentazioni:

1. qual è il livello di sicurezza considerato adeguato;
2. quale livello di garanzia viene considerato adeguato.

Queste domande sono direttamente connesse alle leggi nazionali e direttive comunitarie (Rif. 1 delle Norme e Direttive EC-85) che regolano la responsabilità di chi immette sul mercato un prodotto non adeguatamente sicuro. Il requisito legale -almeno in UK – è il rispetto del principio che il rischio deve essere tanto piccolo quanto  ragionevolmente praticabile (principio di ALARP). In pratica, tutto ciò significa che prima di tutto bisogna ridurre al massimo e/o eliminare i rischi applicando il principio di precauzione. Quindi bisogna assumere che i rischi residui siano tollerabili. Questo principio implica che  bisogna spendere la maggiore energia possibile per rendere i rischi residui il più piccoli possibili. Quest’approccio conduce direttamente e facilmente alla introduzione del concetto di rapporto costi benefici (cost effectiveness) nell’analisi dei rischi e quindi nella progettazione e gestione del “safety case”.

L’analisi del caso di specie – safety case – include la partecipazione di tutta una serie di enti, persone, offici e organizzazioni alla disanima, allo studio e a tutto il percorso del “safety case”. Ad esempio qualcosa del genere avrebbe dovuto essere eseguito ed elaborato preventivamente in casi specifici, come l’evento del Ponte Morandi a Genova. Ma del senno di poi son piene le tombe!

Molte volte il lavoro di analisi di sicurezza deve essere rinviato di anno in anno per problemi di disponibilità finanziaria; così, diviene più semplice ridurre i rischi entro il “budget” previsto se il “budget” stesso è ragionevolmente congruo a poter sviluppare il massimo sforzo possibile di analisi di riduzione dei rischi. La determinazione di ciò che è ragionevole in pratica per ogni circostanza non è possibile se non, forse, davanti al giudice. Non si può assolutamente definire qualcosa di standard in materia di ragionevolezza pratica di riduzione del rischio al minimo. Così, il principio di cui si argomenta riconosce, tuttavia, che la sicurezza assoluta è irraggiungibile. Quando si afferma che un certo software è sicuro, si intende dire che esso non viene usato in una applicazione correlata a problemi di sicurezza. Nel caso che il pacchetto di software in esame, viene impiegato in un sistema soggetto a problemi di sicurezza e che quindi può diventare critico per la sicurezza, allora è necessario quantificare la parola “sicuro” applicata al software. La quantificazione comporta anche implicazioni di costi da analizzare. Si può migliorare la sicurezza di un sistema spendendo più denaro per ridurre i rischi intrinseci al livello più piccolo possibile, ma la legge non può richiedere di spendere una somma infinita di denaro per raggiungere la sicurezza assoluta, posto che ci si riesca.

Questo principio viene riconosciuto dalla legislazione comunitaria e recepito in Italia. Secondo le Direttive europee recepite dall’Italia in termini di Atto della Protezione del Consumatore, si asserisce il principio della responsabilità stretta in certe circostanze. La Commisione europea, nell’ambito delle Direttive Europee per la Sicurezza, ha deciso che qualsiasi persona che venga, in qualche maniera, danneggiata fisicamente da parte di un prodotto difettoso, non deve trovarsi di fronte alla difficoltà di perseguire giuridicamente il responsabile che sia sufficientemente ricco da potere pagare i danni. In altre parole, il problema della responsabilità giuridica del danno da prodotto difettoso diventa problema di politica sociale e non solo di giustizia.  In ogni caso il danno deve essere precisamente identificabile così come deve essere rigorosamente identificato il produttore del prodotto difettoso ma, alla stessa stregua, (si veda anche la Lg 626) il danneggiato deve dimostrare, per essere ricompensato, di non essersi comportato in modo negligente.

L’unico problema aperto nella Direttiva è dato dal fatto che se lo stato dell’arte della conoscenza scientifica non ha consentito di scoprire, durante tutto il periodo di produzione, il difetto o il guasto del prodotto, allora il produttore non è responsabile del danno. In questo contesto, il produttore deve fornire quindi una difesa del proprio operato. Una “difesa accettabile” contro una azione prevista nelle suddette direttive è ciò che viene definito una “difesa allo stato dell’arte”.

 

Articolo a cura di Giuseppe Quartieri