SOLUZIONI DI SICUREZZA

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

La sicurezza di un sistema non dovrebbe basarsi solo su audit/test di sicurezza a posteriori o su soluzioni al contorno (firewall, antivirus), ma essere parte delle sue fondamenta per esplicitare e indirizzare le esigenze di sicurezza legate all’operatività del sistema stesso e al valore dei dati che tratta

Pubblicato il 22 Dic 2022

Alessio Caforio

Cyber Security/Resilience Manager and Engineer - Leonardo Spa, NATO

Ingegneria della sicurezza

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:

Elementi Architetturali

Aspetti di Sicurezza

Gli attori (stakeholder) che nutrono interessi verso il sistema.

  • Si considerano attori interessati all’impiego sicuro del sistema.
  • Si considerano attori malevoli intenzionati a sfruttare il sistema e i suoi dati per scopi illeciti.

Gli interessi espressi dagli attori.

  • Si rappresenta l’esigenza di sicurezza in termini di obiettivi da raggiungere.
  • Si considerano interessi avversi legati ad azioni malevoli sul sistema, i servizi che eroga e i suoi dati.

I punti di vista (viewpoint) degli attori rispetto agli interessi che essi esprimono.

  • Si estendono i viewpoint standard considerando caratteristiche strutturali e dinamiche di sicurezza come presenza di domini di sicurezza, minacce, capacità di difesa e di risposta ecc.

Il modello, come sintassi astratta e semantica degli elementi di base, ma anche come rappresentazione digitale.

  • Sono inclusi elementi da proteggere, meccanismi di protezioni, fattori di rischio.

Le viste (view), come rappresentazioni dell’architettura basate sul modello, ognuna rispondente ad un punto di vista.

  • Si definiscono viste specifiche, ad esempio, attraverso l’impiego di strumenti di modellazione delle minacce.

L’Ambiente che influenza il sistema sia in fase di sviluppo che in esercizio.

  • Si caratterizza l’ambiente operativo anche dal punto di vista di sicurezza (ad es. misure fisiche e logiche, organizzazione della sicurezza, livello di esposizione a minacce ecc.).

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.

Fase

Attività di Ingegneria

Livello della V

Attività di Ingegneria della Sicurezza

1

  • Analisi e gestione del problema / opportunità rispetto alle strategie di business, alla missione, al contesto di mercato, al fine di identificare o caratterizzare una soluzione o una classe di soluzioni più adatte.

Ambiente operativo

  • Definire e valutare la strategia di sicurezza atta a salvaguardare il business e la missione rispetto alle soluzioni o alla classe di soluzioni che si sono identificate.

2

  • Caratterizzazione del contesto di impiego
  • Definizione delle necessità degli stakeholder rispetto al contesto di impiego
  • Definizione dell’architettura

Ambiente operativo

  • Definizione degli obiettivi di sicurezza.
  • Security Risk Assessment (SRA).
  • Caratterizzazione dell’ambiente di sicurezza (digitale e fisico):
    1. Definizione/modeling dell’ambiente e delle eventuali misure di sicurezza esistenti nell’ambiente
    2. Definizione/modeling delle minacce di sicurezza cyber
    3. vincoli derivanti dalla normativa applicabile.

3

  • Definizione del modello del sistema di sistemi e aggiornamento dell’architettura.
  • Definizione dei requisiti del sistema di sistemi.

Sistema di sistemi

  • Security Risk Treatment (SRT).
  • Definizione/modeling delle misure e dell’architettura di sicurezza.
  • Definizione dei requisiti di sicurezza del sistema di sistemi.

4

  • Definizione del modello e aggiornamento dell’architettura.
  • Definizione dei requisiti di sistema.

Sistema

  • Affinamento a livello di Sistema del Security Risk Treatment (SRT).
  • Affinamento dei modelli e della definizione delle misure e dell’architettura di sicurezza.
  • Definizione dei requisiti di sicurezza di sistema.

5

  • Scomposizione logica per aspetti funzionali e/o altri principi di coerenza.
  • Assegnazione dei requisiti di sistema agli elementi di sistema.
  • Progettazione degli elementi di sistema.

Elementi di sistema

  • Assegnazione dei requisiti di sicurezza agli elementi di sistema.
  • Progettazione di dettaglio dei meccanismi di sicurezza applicando, lì dove possibile, design pattern di sicurezza standardizzati.
  • Valutazione del rischio di sicurezza dovuto all’impiego di soluzioni di sicurezza offerte da terze parti (Supply Chain Security).
  • Affinamento dei modelli e della definizione delle misure e dell’architettura di sicurezza.
  • Aggiornamento dell’SRA e del SRT in base all’affinamento del modello e ad una migliore definizione della superficie di attacco.

6

  • Realizzazione del sistema nelle sue diverse parti attraverso sviluppi in house, riutilizzo di building block già acquisiti / realizzati o approvvigionamento da terze parti.

Implementazione

  • Realizzazione dei meccanismi di sicurezza attraverso sviluppi in house o acquisizione da terze parti o riutilizzo di building block di sicurezza già implementati.
  • Aggiornamento dell’SRA e del SRT in base all’affinamento del modello e ad una migliore definizione della superficie di attacco.

7

  • Verifica di assenza di errori implementativi nelle parti che costituiscono i singoli elementi.

Implementazione

  • Impiego di strumenti di test per la scrittura di codice sorgente sicuro, integrati nei processi di sviluppo (ad es. secondo la metodologia DevSecOps).
  • Impiego di strumenti e processi per la verifica dell’affidabilità delle parti fornite da fornitori esterni.

8

  • Test di verifica che gli elementi di sistema rispondano ai requisiti ad essi assegnati in fase di progettazione.

Elementi di sistema

  • Test di verifica che i requisiti di sicurezza siano correttamente implementati a livello di elementi di singolo sistema.
  • Test di vulnerabilità sui singoli elementi.
  • Gestione delle vulnerabilità e conseguente aggiornamento di SRA e SRT.

9

  • Integrazione degli elementi di sistema a formare il singolo sistema.
  • Test di verifica che il singolo sistema risponda ai requisiti ad esso assegnati e che sia avvenuta una corretta integrazione degli elementi che lo costituiscono.

Sistema

  • Test di verifica che i requisiti di sicurezza siano correttamente implementati a livello di sistema.
  • Test di vulnerabilità a livello di sistema.
  • Gestione delle vulnerabilità trovate e conseguente aggiornamento di SRA e SRT.

10

  • Integrazione dei sottosistemi a formare il sistema di sistemi.
  • Test di verifica che il sistema di sistemi risponda ai requisiti ad esso assegnati e che sia avvenuta una corretta integrazione dei sottosistemi che lo costituiscono.

Sistema di sistemi

  • Test di verifica che i requisiti di sicurezza siano correttamente implementati a livello di sistema di sistemi.
  • Test di vulnerabilità a livello di sistema di sistemi con un focus particolare sulle interazioni tra i sistemi.
  • Gestione delle vulnerabilità trovate e conseguente aggiornamento di SRA e SRT.

11

  • Dispiegamento in ambiente test conforme a quanto atteso dal cliente per l’operatività.
  • Test di validazione del sistema di sistemi in ambiente operativo, rispetto ai requisiti dell’utente finale.

Ambiente operativo

  • Test di validazione delle soluzioni di sicurezza rispetto agli obiettivi di sicurezza del cliente previsti per l’ambiente operativo.
  • Test di vulnerabilità e penetration test per validare la postura di sicurezza in ambiente operativo.
  • Gestione delle vulnerabilità e conseguente aggiornamento di SRA e SRT.

12

  • Gestione della transizione in ambiente operativo.
  • Gestione e monitoraggio delle operazioni.
  • Manutenzione.
  • Dismissione.

Ambiente operativo

  • Valutazioni e gestione dei cambiamenti dovuti alla messa in esercizio o alla dismissione rispetto agli obiettivi di sicurezza definiti con l’utente finale.
  • Monitoraggio del corretto funzionamento dei meccanismi di sicurezza e gestione di ogni anomalia.
  • Monitoraggio delle minacce applicabili.
  • Monitoraggio e gestione delle vulnerabilità dei moduli sviluppati ad hoc e dei prodotti di terze parti integrati nel sistema.
  • Monitoraggio degli incidenti di sicurezza che coinvolgono il sistema e valutazione delle migliorie progettuali da apportare in base alla lezione appresa da essi.
  • Aggiornamento di SRA e SRT, in base a cambiamenti dei fattori di rischio (ad es.: nuove minacce, nuove vulnerabilità, frequenza degli incidenti ecc.), delle caratteristiche del sistema e dei criteri di rischio.
  • Attivazione di processi ingegneristici correttivi o migliorativi.

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.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Speciale PNRR

Tutti
Incentivi
Salute digitale
Formazione
Analisi
Sostenibilità
PA
Sostemibilità
Sicurezza
Digital Economy
CODICE STARTUP
Imprenditoria femminile: come attingere ai fondi per le donne che fanno impresa
DECRETI
PNRR e Fascicolo Sanitario Elettronico: investimenti per oltre 600 milioni
IL DOCUMENTO
Competenze digitali, ecco il nuovo piano operativo nazionale
STRUMENTI
Da Istat e RGS gli indicatori per misurare la sostenibilità nel PNRR
STRATEGIE
PNRR – Piano nazionale di Ripresa e Resilienza: cos’è e novità
FONDI
Pnrr, ok della Ue alla seconda rata da 21 miliardi: focus su 5G e banda ultralarga
GREEN ENERGY
Energia pulita: Banca Sella finanzia i progetti green incentivati dal PNRR
TECNOLOGIA SOLIDALE
Due buone notizie digitali: 500 milioni per gli ITS e l’inizio dell’intranet veloce in scuole e ospedali
INNOVAZIONE
Competenze digitali e InPA cruciali per raggiungere gli obiettivi del Pnrr
STRATEGIE
PA digitale 2026, come gestire i fondi PNRR in 5 fasi: ecco la proposta
ANALISI
Value-based healthcare: le esperienze in Italia e il ruolo del PNRR
Strategie
Accordi per l’innovazione, per le imprese altri 250 milioni
Strategie
PNRR, opportunità e sfide per le smart city
Strategie
Brevetti, il Mise mette sul piatto 8,5 milioni
Strategie
PNRR e opere pubbliche, la grande sfida per i Comuni e perché bisogna pensare digitale
Formazione
Trasferimento tecnologico, il Mise mette sul piatto 7,5 milioni
Strategie
PSN e Strategia Cloud Italia: a che punto siamo e come supportare la PA in questo percorso
Dispersione idrica
Siccità: AI e analisi dei dati possono ridurre gli sprechi d’acqua. Ecco gli interventi necessari
PNRR
Cloud, firmato il contratto per l’avvio di lavori del Polo strategico
Formazione
Competenze digitali, stanziati 48 milioni per gli Istituti tecnologici superiori
Iniziative
Digitalizzazione delle reti idriche: oltre 600 milioni per 21 progetti
Competenze e competitività
PNRR, così i fondi UE possono rilanciare la ricerca e l’Università
Finanziamenti
PNRR, si sbloccano i fondi per l’agrisolare
Sanità post-pandemica
PNRR, Missione Salute: a che punto siamo e cosa resta da fare
Strategie
Sovranità e autonomia tecnologica nazionale: come avviare un processo virtuoso e sostenibile
La relazione
Pnrr e PA digitale, l’alert della Corte dei conti su execution e capacità di spesa
L'editoriale
Elezioni 2022, la sfida digitale ai margini del dibattito politico
Strategie
Digitale, il monito di I-Com: “Senza riforme Pnrr inefficace”
Transizione digitale
Pnrr: arrivano 321 milioni per cloud dei Comuni, spazio e mobilità innovativa
L'analisi I-COM
Il PNRR alla prova delle elezioni: come usare bene le risorse e centrare gli obiettivi digitali
Cineca
Quantum computing, una svolta per la ricerca: lo scenario europeo e i progetti in corso
L'indice europeo
Desi, l’Italia scala due posizioni grazie a fibra e 5G. Ma è (ancora) allarme competenze
L'approfondimento
PNRR 2, ecco tutte le misure per cittadini e imprese: portale sommerso, codice crisi d’impresa e sismabonus, cosa cambia
Servizi digitali
PNRR e trasformazione digitale: ecco gli investimenti e le riforme previste per la digitalizzazione della PA
Legal health
Lo spazio europeo dei dati sanitari: come circoleranno le informazioni sulla salute nell’Unione Europea
Servizi digitali
PNRR e PA digitale: non dimentichiamo la dematerializzazione
Digital Healthcare transformation
La trasformazione digitale degli ospedali
Governance digitale
PA digitale, è la volta buona? Così misure e risorse del PNRR possono fare la differenza
Servizi digitali
Comuni e digitale, come usare il PNRR senza sbagliare
La survey
Pnrr e digitale accoppiata vincente per il 70% delle pmi italiane
Missione salute
Fascicolo Sanitario Elettronico alla prova del PNRR: limiti, rischi e opportunità
Servizi pubblici
PNRR: come diventeranno i siti dei comuni italiani grazie alle nuove risorse
Skill gap
PNRR, la banda ultra larga crea 20.000 nuovi posti di lavoro
Il Piano
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUMPA2022
PNRR e trasformazione digitale: rivedi i Talk di FORUM PA 2022 in collaborazione con le aziende partner
I contratti
Avio, 340 milioni dal Pnrr per i nuovi propulsori a metano
Next Generation EU
PNRR, a che punto siamo e cosa possono aspettarsi le aziende private
Fondi
Operativo il nuovo portale del MISE con tutti i finanziamenti per le imprese
Servizi comunali
Il PNRR occasione unica per i Comuni digitali: strumenti e risorse per enti e cittadini
Healthcare data platform
PNRR dalla teoria alla pratica: tecnologie e soluzioni per l’innovazione in Sanità
Skill
Competenze digitali, partono le Reti di facilitazione
Gli obiettivi
Scuola 4.0, PNRR ultima chance: ecco come cambierà il sistema formativo
Sistema Paese
PNRR 2, è il turno della space economy
FORUM PA 2022
FORUM PA 2022: la maturità digitale dei comuni italiani rispetto al PNRR
Analisi
PNRR: dalla Ricerca all’impresa, una sfida da cogliere insieme
Innovazione
Pnrr, il Dipartimento per la Trasformazione digitale si riorganizza
FORUM PA 2022
PA verde e sostenibile: il ruolo di PNRR, PNIEC, energy management e green public procurement
Analisi
PNRR, Comuni e digitalizzazione: tutto su fondi e opportunità, in meno di 3 minuti. Guarda il video!
Rapporti
Competenze digitali e servizi automatizzati pilastri del piano Inps
Analisi
Attuazione del PNRR: il dialogo necessario tra istituzioni e società civile. Rivedi lo Scenario di FORUM PA 2022
Progetti
Pnrr, fondi per il Politecnico di Torino. Fra i progetti anche IS4Aerospace
Analisi
PNRR, Colao fa il punto sulla transizione digitale dell’Italia: «In linea con tutte le scadenze»
La Svolta
Ict, Istat “riclassifica” i professionisti. Via anche al catalogo dati sul Pnrr
Analisi
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUM PA 2022
Ecosistema territoriale sostenibile: l’Emilia Romagna tra FESR e PNRR
Il Piano
Innovazione, il Mise “centra” gli obiettivi Pnrr: attivati 17,5 miliardi
Analisi
PNRR: raggiunti gli obiettivi per il primo semestre 2022. Il punto e qualche riflessione
Analisi
PNRR: dal dialogo tra PA e società civile passa il corretto monitoraggio dei risultati, tra collaborazione e identità dei luoghi
Webinar
Comuni e PNRR: un focus sui bandi attivi o in pubblicazione
Analisi
Formazione 4.0: cos’è e come funziona il credito d’imposta
PA e Sicurezza
PA e sicurezza informatica: il ruolo dei territori di fronte alle sfide della digitalizzazione
PA e sicurezza
PNRR e servizi pubblici digitali: sfide e opportunità per Comuni e Città metropolitane
Water management
Water management in Italia: verso una transizione “smart” e “circular” 
LE RISORSE
Transizione digitale, Simest apre i fondi Pnrr alle medie imprese
Prospettive
Turismo, cultura e digital: come spendere bene le risorse del PNRR
Analisi
Smart City: quale contributo alla transizione ecologica
Decarbonizzazione
Idrogeno verde, 450 milioni € di investimenti PNRR, Cingolani firma
Unioncamere
PNRR, imprese in ritardo: ecco come le Camere di commercio possono aiutare
I fondi
Industria 4.0: solo un’impresa su tre pronta a salire sul treno Pnrr
CODICE STARTUP
Imprenditoria femminile: come attingere ai fondi per le donne che fanno impresa
DECRETI
PNRR e Fascicolo Sanitario Elettronico: investimenti per oltre 600 milioni
IL DOCUMENTO
Competenze digitali, ecco il nuovo piano operativo nazionale
STRUMENTI
Da Istat e RGS gli indicatori per misurare la sostenibilità nel PNRR
STRATEGIE
PNRR – Piano nazionale di Ripresa e Resilienza: cos’è e novità
FONDI
Pnrr, ok della Ue alla seconda rata da 21 miliardi: focus su 5G e banda ultralarga
GREEN ENERGY
Energia pulita: Banca Sella finanzia i progetti green incentivati dal PNRR
TECNOLOGIA SOLIDALE
Due buone notizie digitali: 500 milioni per gli ITS e l’inizio dell’intranet veloce in scuole e ospedali
INNOVAZIONE
Competenze digitali e InPA cruciali per raggiungere gli obiettivi del Pnrr
STRATEGIE
PA digitale 2026, come gestire i fondi PNRR in 5 fasi: ecco la proposta
ANALISI
Value-based healthcare: le esperienze in Italia e il ruolo del PNRR
Strategie
Accordi per l’innovazione, per le imprese altri 250 milioni
Strategie
PNRR, opportunità e sfide per le smart city
Strategie
Brevetti, il Mise mette sul piatto 8,5 milioni
Strategie
PNRR e opere pubbliche, la grande sfida per i Comuni e perché bisogna pensare digitale
Formazione
Trasferimento tecnologico, il Mise mette sul piatto 7,5 milioni
Strategie
PSN e Strategia Cloud Italia: a che punto siamo e come supportare la PA in questo percorso
Dispersione idrica
Siccità: AI e analisi dei dati possono ridurre gli sprechi d’acqua. Ecco gli interventi necessari
PNRR
Cloud, firmato il contratto per l’avvio di lavori del Polo strategico
Formazione
Competenze digitali, stanziati 48 milioni per gli Istituti tecnologici superiori
Iniziative
Digitalizzazione delle reti idriche: oltre 600 milioni per 21 progetti
Competenze e competitività
PNRR, così i fondi UE possono rilanciare la ricerca e l’Università
Finanziamenti
PNRR, si sbloccano i fondi per l’agrisolare
Sanità post-pandemica
PNRR, Missione Salute: a che punto siamo e cosa resta da fare
Strategie
Sovranità e autonomia tecnologica nazionale: come avviare un processo virtuoso e sostenibile
La relazione
Pnrr e PA digitale, l’alert della Corte dei conti su execution e capacità di spesa
L'editoriale
Elezioni 2022, la sfida digitale ai margini del dibattito politico
Strategie
Digitale, il monito di I-Com: “Senza riforme Pnrr inefficace”
Transizione digitale
Pnrr: arrivano 321 milioni per cloud dei Comuni, spazio e mobilità innovativa
L'analisi I-COM
Il PNRR alla prova delle elezioni: come usare bene le risorse e centrare gli obiettivi digitali
Cineca
Quantum computing, una svolta per la ricerca: lo scenario europeo e i progetti in corso
L'indice europeo
Desi, l’Italia scala due posizioni grazie a fibra e 5G. Ma è (ancora) allarme competenze
L'approfondimento
PNRR 2, ecco tutte le misure per cittadini e imprese: portale sommerso, codice crisi d’impresa e sismabonus, cosa cambia
Servizi digitali
PNRR e trasformazione digitale: ecco gli investimenti e le riforme previste per la digitalizzazione della PA
Legal health
Lo spazio europeo dei dati sanitari: come circoleranno le informazioni sulla salute nell’Unione Europea
Servizi digitali
PNRR e PA digitale: non dimentichiamo la dematerializzazione
Digital Healthcare transformation
La trasformazione digitale degli ospedali
Governance digitale
PA digitale, è la volta buona? Così misure e risorse del PNRR possono fare la differenza
Servizi digitali
Comuni e digitale, come usare il PNRR senza sbagliare
La survey
Pnrr e digitale accoppiata vincente per il 70% delle pmi italiane
Missione salute
Fascicolo Sanitario Elettronico alla prova del PNRR: limiti, rischi e opportunità
Servizi pubblici
PNRR: come diventeranno i siti dei comuni italiani grazie alle nuove risorse
Skill gap
PNRR, la banda ultra larga crea 20.000 nuovi posti di lavoro
Il Piano
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUMPA2022
PNRR e trasformazione digitale: rivedi i Talk di FORUM PA 2022 in collaborazione con le aziende partner
I contratti
Avio, 340 milioni dal Pnrr per i nuovi propulsori a metano
Next Generation EU
PNRR, a che punto siamo e cosa possono aspettarsi le aziende private
Fondi
Operativo il nuovo portale del MISE con tutti i finanziamenti per le imprese
Servizi comunali
Il PNRR occasione unica per i Comuni digitali: strumenti e risorse per enti e cittadini
Healthcare data platform
PNRR dalla teoria alla pratica: tecnologie e soluzioni per l’innovazione in Sanità
Skill
Competenze digitali, partono le Reti di facilitazione
Gli obiettivi
Scuola 4.0, PNRR ultima chance: ecco come cambierà il sistema formativo
Sistema Paese
PNRR 2, è il turno della space economy
FORUM PA 2022
FORUM PA 2022: la maturità digitale dei comuni italiani rispetto al PNRR
Analisi
PNRR: dalla Ricerca all’impresa, una sfida da cogliere insieme
Innovazione
Pnrr, il Dipartimento per la Trasformazione digitale si riorganizza
FORUM PA 2022
PA verde e sostenibile: il ruolo di PNRR, PNIEC, energy management e green public procurement
Analisi
PNRR, Comuni e digitalizzazione: tutto su fondi e opportunità, in meno di 3 minuti. Guarda il video!
Rapporti
Competenze digitali e servizi automatizzati pilastri del piano Inps
Analisi
Attuazione del PNRR: il dialogo necessario tra istituzioni e società civile. Rivedi lo Scenario di FORUM PA 2022
Progetti
Pnrr, fondi per il Politecnico di Torino. Fra i progetti anche IS4Aerospace
Analisi
PNRR, Colao fa il punto sulla transizione digitale dell’Italia: «In linea con tutte le scadenze»
La Svolta
Ict, Istat “riclassifica” i professionisti. Via anche al catalogo dati sul Pnrr
Analisi
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUM PA 2022
Ecosistema territoriale sostenibile: l’Emilia Romagna tra FESR e PNRR
Il Piano
Innovazione, il Mise “centra” gli obiettivi Pnrr: attivati 17,5 miliardi
Analisi
PNRR: raggiunti gli obiettivi per il primo semestre 2022. Il punto e qualche riflessione
Analisi
PNRR: dal dialogo tra PA e società civile passa il corretto monitoraggio dei risultati, tra collaborazione e identità dei luoghi
Webinar
Comuni e PNRR: un focus sui bandi attivi o in pubblicazione
Analisi
Formazione 4.0: cos’è e come funziona il credito d’imposta
PA e Sicurezza
PA e sicurezza informatica: il ruolo dei territori di fronte alle sfide della digitalizzazione
PA e sicurezza
PNRR e servizi pubblici digitali: sfide e opportunità per Comuni e Città metropolitane
Water management
Water management in Italia: verso una transizione “smart” e “circular” 
LE RISORSE
Transizione digitale, Simest apre i fondi Pnrr alle medie imprese
Prospettive
Turismo, cultura e digital: come spendere bene le risorse del PNRR
Analisi
Smart City: quale contributo alla transizione ecologica
Decarbonizzazione
Idrogeno verde, 450 milioni € di investimenti PNRR, Cingolani firma
Unioncamere
PNRR, imprese in ritardo: ecco come le Camere di commercio possono aiutare
I fondi
Industria 4.0: solo un’impresa su tre pronta a salire sul treno Pnrr

Articoli correlati

Articolo 1 di 2