Nel suo ruolo strategico di driver per la digitalizzazione delle PA, AGID dedica un’intera sezione a consapevolezza e gestione del rischio. Su questo fronte ha sviluppato un servizio di autovalutazione di conformità al GDPR in tema di cybersecurity – rinvenibile a questo link – che ha l’obiettivo “di fornire una prima e indicativa analisi dello stato di conformità al GDPR al solo scopo auto-valutativo (pre-assessment), senza sostituirsi agli strumenti messi a disposizione dalle autorità competenti”. Vediamone i vantaggi e le modalità di utilizzo.
Nella pagina di presentazione AGID fornisce uno schema generale, vedi figura sottostante, su come si sviluppa in 4 fasi un attacco informatico:
Ma l’elemento più interessante fornito da AGID riguarda la disamina delle seguenti linee guida: Linee Guida per l’adozione di un ciclo di sviluppo di software sicuro.
Degne di nota, infatti sono le sezioni 9 (linee guida per l’adozione di un ciclo di sviluppo software sicuro) e 10 (linee guida per l’implementazione della privacy by design nel sdlc) ove vengono sviluppati i temi del Risk Assessment (con l’obiettivo sia di identificare i relativi rischi oltre che le modalità di gestione del rischio stesso, il c.d. Risk Management)
Ed il tema della DPIA (utile a tal fine lo schema redatto da AGID): Linee Guida per adeguare la sicurezza del software di base.
Degne di nota sono le indicazioni sulle “minacce e tipologie di attacco” (Sezione. 4) con un “Catalogo delle Minacce” (4.1) e Catalogo delle tipologie di attacco (4.2) e la Sezione 5 sulle best practices per adeguare e mantenere la sicurezza del software di base (ove vengono identificate le principali minacce e le relative contromisure) che vengono sintetizzate da AGID con questo schema: Linee Guida per lo sviluppo sicuro di codice.
Queste linee guida hanno come scopo “lo sviluppo di applicazioni informatiche sicure” identificando l’insieme “di best practices da seguire, al fine prevenire eventuali problematiche di sicurezza nel codice, e forniscono nel contempo uno strumento utile nell’individuazione di possibili vulnerabilità presenti nel codice sorgente e le relative contromisure da applicare”. (schema fornito da AGID)
–Linee Guida per la modellazione delle minacce e individuazione delle azioni di mitigazione
Queste linee guida hanno lo scopo di fornire gli strumenti per la “modellazione delle minacce ed individuazione delle azioni di mitigazione conformi ai principi del secure/privacy by design” che spesso si celano all’interno delle applicazioni software. AGID fornisce anche qui uno schema delle fasi principali nella preparazione e nell’esecuzione di una modellazione delle minacce.
Come identificare i sotto-obiettivi
Secondo Agid “il processo di modellazione delle minacce s’identifica in un insieme di passi che realizzano dei sotto-obiettivi, piuttosto che come una singola attività. Essenzialmente, le domande da porsi al fine di identificare i sotto-obiettivi, sono:
• Cosa si sta realizzando?
• Cosa potrebbe andare storto una volta realizzato?
• Cosa è necessario fare per contrastare eventuali problemi?
• È stato svolto un lavoro di analisi accettabile?
Queste domande indirizzano puntualmente i quattro step del processo illustrato graficamente nella figura successivamente e che possono essere così riassunti:
• Modellare il sistema che si sta costruendo, rilasciando o modificando.
• Identificare le minacce.
• Indirizzare le minacce.
• Convalidare il lavoro per completezza ed efficacia sulla base delle best practices.
Cybersecurity: modellazione degli attacchi
Si modellano quindi tanti attack tree quanti sono gli obiettivi di un attaccante. Quindi è necessario identificare i possibili obiettivi di attacco e, per ciascuno di essi, i passi attraverso cui realizzarli.
Si riporta di seguito, un esempio di modellazione di attack tree:
Analisi degli attributi di sicurezza. Linee Guida in commento a pag. 33, spiegano che dopo aver modellato i possibili attacchi al sistema, è necessario analizzare gli attributi di sicurezza del sistema, ciò significa:
- verificare la possibilità o l’impossibilità dell’attacco;
- verificare il costo dell’attacco;
- verificare gli strumenti necessari per realizzare l’attacco.
Analisi dei risultati. Qui Agid verifica l’efficacia e l’efficienza del possibile attacco. L’analisi, infatti, è volta a determinare:
- il costo dell’attacco più economico;
- gli attacchi il cui costo non supera una certa soglia;
- l’attacco più economico che non utilizza attrezzature speciali.
Inoltre i risultati devono essere comparati in base ai diversi livelli di abilità, accesso, avversione al rischio, soldi e così via degli attaccanti (ad es. AGID spiega che “se il potenziale attaccante è la criminalità organizzata, occorre considerare la possibilità di attacchi costosi e “mezzi illeciti” (corruzione, ricatto, ecc.) che espongono l’attaccante fino al rischio di andare in prigione. Se il potenziale attaccante è un terrorista, occorre considerare “mezzi illeciti” che espongono l’attaccante fino al rischio di morire per raggiungere l’obiettivo. Se l’attaccante è un casual hacker si esclude la possibilità di attacchi costosi e “mezzi illeciti” (corruzione, ricatto, ecc.)”).
Analisi What-if. Questa fase riguarda l’adozione delle contromisure. A tal riguardo, nella sezione 4.2.4.3 viene menzionato il TRIKE, cioè un “framework open-source per l’auditing della sicurezza da un punto di vista di risk management basato sulla generazione di modelli di minacce in modo affidabile e ripetibile”. Tale framework può essere utile per la generazione delle minacce o come sviluppatore di sicurezza “inesperto” per trovare le vulnerabilità di sicurezza in modo efficace ed affidabile.
Alla sezione 4.2.4.4 viene sviluppato il tema “P.A.S.T.A” (Process for Attack Simulation and Threat Analysis) processo suddiviso nelle seguenti fasi in grado di “affrontare le minacce più gravi per un determinato obiettivo applicativo. Di seguito in elenco le fasi di cui sopra:
• Definizione degli obiettivi di business;
• Definizione dell’ambito tecnico;
• Scomposizione del sistema;
• Analisi delle minacce;
• Rilevamento della vulnerabilità;
• Enumerazione degli attacchi;
• Analisi del rischio/impatto.
Nella sezione 4.3 viene sviluppato il tema dell’Indirizzamento delle minacce e nella sezione 4.4 viene sviluppato il tema della Valutazione del rischio (tecniche di Risk Ranking).
Cybersecurity, come indirizzare le minacce
Una volta raccolte le minacce, il passo successivo nel processo di modellazione è quello di indirizzare ciascuna minaccia, cioè azioni che si possono intraprendere per contrastare tali minacce:
• Mitigazione delle minacce
• Eliminazione delle minacce
• Spostamento delle minacce (lasciare che qualcuno o qualcos’altro gestisca il rischio)
• Accettazione della minaccia (laddove il costo nell’impedire la minaccia risulta elevato, quindi in questi casi si potrebbe scegliere di accettare il rischio).
L’approccio privacy by design
Infine, nelle linee guida in commento, alla sezione 4.5.1.2 viene sviluppato il tema della Privacy by design e nella sezione 5 vengono fornite le 5 “linee guida per l’individuazione e la rivisitazione dei requisiti di sicurezza e di privacy applicativi”.
Come ricordato da Agid “La Privacy by Design è un concetto sviluppato alla fine degli anni 90 da Ann Cavoukian [A. Cavoukian, Privacy by Design], commissario per l’informazione e la privacy dell’Ontario. Si tratta di un approccio ingegneristico che si concentra sull’intero processo a partire dai principi di privacy e protezione dei dati”.
Come giustamente osservato nelle menzionate linee guida “La tutela della privacy non dovrebbe essere garantita solo dal rispetto delle norme e dai quadri normativi, in quanto non vi è alcuna utilità nelle norme giuridiche di codifica rigorosa se il sistema stesso non ha una solida base per la sicurezza e la tutela della privacy.
La privacy by design può essere raggiunta applicando i sette principi su cui si basa:
• Proattivo non reattivo, preventivo non correttivo: le minacce alla privacy dovrebbero essere anticipate e prevenute, piuttosto che corrette dopo che queste si sono verificate.
• Privacy come impostazione predefinita: la privacy dovrebbe essere lo standard. I dati personali dovrebbero essere protetti automaticamente, anche senza alcuna azione esplicita da parte dell’individuo interessato.
• Privacy incorporata nella progettazione: la privacy non dovrebbe essere considerata un elemento aggiuntivo, ma dovrebbe essere integrata nella progettazione e nell’architettura dei sistemi software e delle attività di business in generale.
• Piena funzionalità – somma positiva, non somma zero: la privacy dovrebbe coesistere con altri interessi di business. Dovrebbero tuttavia essere evitati compromessi non necessari (ad esempio privacy vs. sicurezza o privacy vs. performance). Si dovrebbe cercare di ottenere una somma positiva.
• Sicurezza end-to-end – Tutela dell’intero ciclo di vita: la privacy richiede sicurezza durante l’intero ciclo di vita dei dati personali, garantendo una gestione sicura e completa di tutti i dati.
• Visibilità e trasparenza: gli obiettivi di privacy dichiarati dall’organizzazione e conseguentemente adottati dai sistemi, devono essere visibili e trasparenti agli utenti.
• Rispetto per la privacy degli utenti: devono essere applicate misure adeguate per responsabilizzare l’utente nel trattamento dei propri dati.”
