Linee guida AgID e OWASP per scrivere software sicuro

Indice dei contenuti

1. Ciclo di sviluppo software sicuro
2. Sviluppo sicuro di codice
3. Configurazione di sicurezza del software di base
4. Modellazione delle minacce e azioni di mitigazione
Conclusioni
Riferimenti

In questo articolo ci dedicheremo all'analisi di una serie di linee guida promosse da Agenzia per l'Italia Digitale (AgID) per lo sviluppo di software sicuro nella pubblica amministrazione.

Si tratta di una serie di consigli che AgID ha messo insieme a partire dal 2017, con il documento introduttivo Linee guida di sicurezza nello sviluppo di applicazioni, e che sono stati poi dettagliati in quattro allegati tecnici realizzati nel corso degli anni successivi (2018-2020):

L'obiettivo di questi documenti è quello di dotare la Pubblica Amministrazione di un vero e proprio modello architetturale che consenta lo sviluppo sicuro dei servizi sia critici che non critici, definendo i principi e le linee guida per garantire ai dati gestiti quelle "misure tecniche e organizzative adeguate al rischio" previste dagli articoli 5 e 32 del GDPR e ulteriormente ribadite nella Direttiva NIS 2016/1148 (Network and Information Security).

Nei prossimi paragrafi proveremo a fornire una utile sintesi dei 4 allegati, che è comunque consigliabile leggere nella loro interezza in quanto contengono a loro volta una sintesi delle best practices contenute nei principali framework di sicurezza diffusi a livello internazionale: Open Web Application Security Project (OWASP), Software Assurance Forum for Excellence in Code (SAFECODE), SANS Software Security Institute (SANS SSI), Web Application Security Consortium (WASC), e molte altre.

Inutile dire che tali linee guida, pur essendo pensate per il servizio pubblico, possono essere utilizzate da qualsiasi azienda privata interessata alla messa in sicurezza dei propri processi tecnici, organizzativi e gestionali in materia di sviluppo software: la sicurezza informatica dei servizi e degli applicativi software ha assunto del resto un’importanza fondamentale negli ultimi anni in quanto, oltre a svolgere un ruolo primario nel garantire la disponibilità, integrità e riservatezza delle informazioni, è direttamente collegata ai principi di privacy previsti dall’ordinamento giuridico.

1. Ciclo di sviluppo software sicuro

Il primo allegato si pone lo scopo di fornire le linee guida per intraprendere un processo di sviluppo del software “sicuro”, nel corso di tutte le fasi del Software Development Life Cycle (SDLC) attraverso l’identificazione e l’implementazione di opportune azioni di sicurezza.

Il SDLC è un processo utilizzato per sviluppare e gestire il software in maniera efficiente allo scopo di migliorare la qualità del software prodotto e garantire che esso realizzi gli obiettivi per cui è stato realizzato. La tematica è tanto rilevante che è stata inserita in un vero e proprio standard internazionale: l'ISO/IEC 12207.

Il documento è suddiviso nei seguenti punti fondamentali:

Esigenze e Ambiti di Applicazione, ovvero come nasce l’esigenza dello sviluppo di software sicuro.
Analisi delle iniziative e degli standard. Questa sezione analizza lo scenario nazionale e globale fornendo una panoramica delle iniziative e dei risultati prodotti in termini di: metodi e modelli, standard best practices, strumenti. In conseguenza di questa analisi viene redatto un Catalogo dei Security Tools.
Secure Software Development Life Cycle (SSDLC). Questa sezione si occupa dell'analisi delle metodologie e dei processi, nonché dei diversi metodi e modelli SDLC esistenti, con l’obiettivo di identificare le caratteristiche che rendono un ciclo di sviluppo software sicuro ed efficace.
La sicurezza in tutte le fasi del ciclo di sviluppo software: un approfondimento sulle varie fasi SDLC allo scopo di enfatizzare la necessità di considerare gli aspetti di sicurezza fin dall’inizio del SDLC stesso.
Training e formazione: sezione che focalizza l’attenzione sul fatto che molti degli attuali problemi di sicurezza derivano da errori di progettazione e/o di implementazione; questi problemi sono risolvibili solo disponendo di personale formato e consapevole.
Certificazioni professionali. Un elenco delle principali certificazioni riconosciute in ambito InfoSec.

Particolarmente importante in questo allegato è il riferimento agli standard definiti dalla comunità OWASP, con particolare riguardo alla lista delle vulnerabilità più critiche delle applicazioni web (OWASP Top 10 Web Application Security Risks). Nello specifico, il documento mette a confronto le vulnerabilità evidenziate nell'ultimo rapporto OWASP (novembre del 2017) con quelle identificate nel rapporto precedente (OWASP Top 10 – 2013), come si evince dalla figura che segue:

2. Sviluppo sicuro di codice

Il secondo allegato si pone lo scopo di supportare, attraverso opportune linee guida, lo sviluppo di applicazioni software sicure. Le linee guida presentate costituiscono un 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.

Il documento è strutturato nel seguente modo:

Capitolo 1. Generalità e scopo del documento;
Capitolo 2. Documentazione applicabile e di riferimento;
Capitolo 3. Definizioni e acronimi;
Capitolo 4. Introduzione alle applicazioni sicure;
Capitolo 5. Insieme di raccomandazioni generali e trasversali alle scelte implementative;
Capitolo 6. Elenco delle principali vulnerabilità software, corredate da esempi puntuali e delle relative contromisure da adottare;
Capitolo 7. Best practices per i linguaggi di sviluppo utilizzati (C/C++, Java, PL/SQL, Javascript, PyThon, C#, ASP, ASP.NET, PHP, VBNET, AJAX, GO) e un'insieme di misure da adottare al fine di diminuire l’esposizione verso problematiche di sicurezza applicativa.

Si tratta di un documento estremamente puntuale che fornisce una panoramica esaustiva delle direttive e degli standard di progettazione più utilizzati per lo sviluppo di applicazioni moderne, con particolare riguardo alle applicazioni web o che necessitano di un'interoperabilità con il web.

L'approccio consigliato dipende dal tipo di progetto: nel caso in cui si tratti di progettazione di applicazioni ex-novo viene suggerito un approccio Secure by Design, mentre nel caso di reingegnerizzazione di applicazioni esistenti si consiglia l'adozione di un approccio Security Control.

Secure by Design. Durante le fasi di analisi della sicurezza applicativa di una architettura di sistema (da definire o in fase di rivisitazione) è necessaria l’attuazione di pratiche di progettazione sicura attraverso l’individuazione di requisiti di sicurezza e contromisure secondo i Security by Design Principles. Le pratiche di progettazione sicura realizzano la sicurezza delle informazioni attraverso un approccio di "Defense in Depth” del layer applicativo. La “difesa in profondità” ha come scopo limitare al minimo i danni in caso di attacco riuscito. In pratica, nell’ipotesi che un attaccante riesca a oltrepassare il primo livello di difesa (ad esempio aggirando il controllo di autenticazione), ulteriori misure più restrittive devono intervenire per ostacolarne l’avanzata (ad esempio, restringendo al minimo i privilegi d’accesso alle risorse o applicando la compartimentazione dell’applicazione al fine di ostacolare bloccare la propagazione dell’attacco all’intero sistema).
Security Control. Nel caso in cui si stiano apportando modifiche su una applicazione esistente, è necessario tenere presenti i seguenti aspetti:
- identificare, quantificare e risolvere i rischi di sicurezza associati ad un’interfaccia, un'applicazione e/o un sistema esistenti;
- validare dal punto di vista della sicurezza applicativa gli sviluppi realizzati da terze parti (sicurezza della supply chain);
- tutelare il proprio patrimonio informativo e i dati.

Il documento passa inoltre in rassegna tutte le principali vulnerabilità derivanti dagli errori di programmazione più comuni: input validation, file inclusion, insecure deserialization, cross-site scripting, directory traversal, SQL injection, session stealing/hijacking, e così via, indicando di volta in volta le best practices da seguire per evitare simili rischi: ancora una volta la principale fonte di riferimento è data da OWASP e dalle contromisure individuate dalla community in risposta a ciascuna delle vulnerabilità indicate.

3. Configurazione di sicurezza del software di base

Il terzo allegato è dedicato all'individuazione e definizione di alcune best practices per la configurazione sicura del software di base, ovvero del sistema operativo e dei principali applicativi dei computer in uso: si tratta, in altre parole, dell'attività convenzionalmente nota come "hardening", che riguarda non soltanto la configurazione dell'OS ma anche le protezioni perimetrali (fisiche e logiche), le architetture di rete (DMZ, segmentazioni, etc.), le procedure organizzative (che riguardano soprattutto le persone che operano dietro alle tecnologie), i programmi formativi di “security
awareness”, e così via.

Il documento è applicabile a tutte le principali tipologie di software di base, middleware e applicativo in uso presso le pubbliche amministrazioni, ed in particolare:

Sistemi Operativi UNIX
Sistemi operativi Microsoft Windows Server
Sistemi operativi Windows Client
Web Browser
Postazioni di Lavoro
Web Application Server
DBMS/Data base server
Mail Server,
Enterprise Service Bus
Principali applicativi di Office Automation (Microsoft Office e OpenOffice).

I paragrafi di cui si compone il documento entrano nel dettaglio delle singole componenti (software di base, middleware, office automation, ecc.); per ciascun componente viene effettuata una analisi approfondita dal punto di vista delle best practices di sicurezza, fornendo un elenco delle misure di sicurezza da adottare a fronte delle minacce più comuni allo scopo di diminuire l’esposizione ai rischi per la sicurezza delle informazioni e dei servizi erogati. In dettaglio, il documento è così suddiviso:

Elenco delle minacce alla sicurezza delle informazioni, ovvero delle principali tipologie di attacco rispetto al software di base, al middleware e al software applicativo più comune.
Raccomandazioni generali: una serie di indicazioni "trasversali" che realizzano la base comune per affrontare le problematiche di sicurezza delle specifiche componenti.
Elenco dei riferimenti alle istruzioni operative di hardening messe a disposizione da enti/istituzioni preposte ed affermate a livello internazionale.
Elenco delle baseline di configurazione e alcuni strumenti software per l’hardening messi a disposizione direttamente dai vendor.

Il documento presenta delle indicazioni estremamente dettagliate, declinate a seconda del sistema operativo di riferimento e del tipo di minaccia che si pone l'obiettivo di mitigare. Particolare enfasi è data alla necessità di abilitare gli strumenti di logging e auditing forniti dal sistema operativo, così da abituare gli amministratori di sistema ad adottare procedure di monitoring e favorire la creazione di procedure di log analysis, estremamente importanti in ottica di prevenzione di alcune minacce particolarmente rilevanti in ottica di data breach (accessi non autorizzati, errata configurazione delle autorizzazioni, etc).

4. Modellazione delle minacce e azioni di mitigazione

L'ultimo allegato si pone l'obiettivo di analizzare il contesto (processi, metodi e modelli) della progettazione di applicazioni sicure, con l'obiettivo di fornire un set di linee guida per la modellazione delle minacce e conseguente individuazione di azioni di mitigazione, in conformità con i principi Secure by Design e Privacy by Design. Questo approccio costituisce una fase importante nel processo d’individuazione preventiva dei requisiti di sicurezza e privacy. Si tratta dunque di un documento che esula dagli aspetti prettamente legati alla progettazione software (allegato 1), allo sviluppo di codice (allegato 2) e alla configurazione degli applicativi (allegato 3), per concentrarsi sugli aspetti di governance, project e process management che costituiscono il contesto generale di queste attività.

Il documento è articolato come segue:

Esigenze e ambiti di applicazione. Capitolo introduttivo che illustra l'importanza di mettere in atto le contromisure adeguate per anticipare le principali minacce, ovvero agire prima che queste si verifichino, in termini di rischi e costi.
Progettazione del software secure/privacy by design. In questo capitolo vengono analizzati gli strumenti e i modelli a supporto della fase di progettazione del software sicuro, in essere e in divenire: BSA Framework for secure software (BSA), Open Software Assurance Maturity Model (SAMM), Building Security in Maturity Model (BSIMM), Comprehensive, Light-weight Application Security Process (CLASP), Microsoft’s Security Development Lifecycle (SDL), e così via.
Linee Guida per l'individuazione e la rivisitazione dei requisiti di sicurezza e di privacy applicativi. Capitolo dedicato alla definizione di alcune linee guida per l’identificazione preventiva delle possibili minacce, delle relative azioni di mitigazione e per la valutazione e prioritizzazione delle minacce stesse: particolare enfasi viene data agli aspetti legati alla modellazione iniziale, che non può prescindere dall'identificazione degli obiettivi di sicurezza (riservatezza, integrità, disponibilità), dalla realizzazione di un disegno di alto livello dell'applicazione, dall'identificazione dei ruoli e degli scenari d'uso, da una analisi approfondita delle tecnologie utilizzate, dei flussi di dati e dai relativi punti di ingresso (entry point) e uscita (exit point) degli stessi.
Esempio Applicativo. Nell'ultimo capitolo viene presentato un caso d'uso applicativo ("Easy Web Site") in cui vengono impiegate le metodologie, gli strumenti di sicurezza e le contromisure indicate nei capitoli precedenti.

Conclusioni

Per maggiori informazioni sugli argomenti trattati, consigliamo di recuperare i seguenti articoli pubblicati sul tema:

GDPR e Privacy – Profili amministrativi e gestionali. I principali protagonisti del trattamento dei dati: Titolare, Contitolari, Rappresentante UE, Responsabile e Sub-Responsabili, Persone autorizzate e soggetti designati, Responsabile della Protezione dei Dati (Data Protection Officer o DPO).
Codice dell’Amministrazione Digitale (CAD): il punto della situazione. Analisi dei contenuti del testo unico che definisce le norme riguardanti l'informatizzazione della Pubblica Amministrazione nei rapporti con i cittadini e le imprese dal 2005 ad oggi.
Information Security: le linee guida ENISA. Panoramica delle Technical Guidelines for the implementation of minimum security measures for Digital Service Providers, lo standard di riferimento per la sicurezza informatica in Europa.