Requisiti di sicurezza informatica per software sicuri in aziende e PA: le regole

I requisiti di sicurezza informatica sono l’obiettivo, il termine di paragone con cui confrontarci per realizzare sistemi e software sicuri in azienda. Il primo passo, nella creazione di un sistema sicuro è, ovviamente, quello di capire quanto e perché deve essere sicuro. Il quanto è presto detto: la sicurezza ha un costo e quindi bisogna capire fino a che punto arrivare, facendo un’appropriata analisi costi/benefici. Il perché ha l’obiettivo di rendere le misure di sicurezza adottate appropriate alle categorie di pericoli che ci preoccupano di più, quelle, cioè, per cui il rischio è più alto.

Fase di test: verifichiamo l’aderenza ai requisiti enunciati

La qualità dello sviluppo verrà misurata nella fase di test come l’aderenza ai requisiti enunciati. Alta qualità vorrà dire che il prodotto corrisponde in pieno alle aspettative del cliente o, più in generale, degli stakeholder. Nel linguaggio del Project Management, stakeholder è qualunque persona abbia degli interessi nel progetto e possa trarre benefici dalla sua buona riuscita. Può trattarsi di un programmatore che ha aspettative di carriera e crescita professionale, del commerciale, che vuole vendere il prodotto al maggior prezzo possibile, dell’utente finale, che vuole un sistema perfettamente funzionante e usabile.

Un requisito è una condizione o una capacità necessaria per risolvere un problema o raggiungere un obiettivo. Raccogliere correttamente i requisiti significa circoscrivere il problema e limitare lo spazio di tutte le possibili soluzioni.

Tipicamente dei buoni requisiti devono avere cinque proprietà, in particolare devono essere:

• necessari: è importante capire se un requisito debba essere incluso o no;
• raggiungibili: un requisito deve essere tecnologicamente fattibile e deve essere compatibile con i tempi e le risorse assegnate al progetto;
• verificabili: il modo di verificare un requisito determina alla fine i criteri per l’accettabilità o meno dei risultati;
• chiari: devono essere espressi in forma chiara e concisa;
• tracciabili: in generale i requisiti possono essere di vario tipo, dai requisiti di usabilità, ai requisiti di performances, ai requisiti di sistema, ai requisiti tecnologici ecc. Questi costituiranno normalmente una gerarchia, ad esempio il fatto che un utente possa conservare i propri dati in forma criptata, porta a dei requisiti tecnologici, come ad esempio l’adozione di un metodo di criptazione e di un linguaggio di sviluppo, oppure a dei requisiti di sistema, come ad esempio la necessità di installare una Certification Authority. La proprietà di tracciabilità si riferisce al fatto di poter determinare quali requisiti hanno dato origine a quali altri e perché.

Tra gli attributi dell’oggetto dell’analisi di sicurezza, che rientrano tipicamente tra i requisiti, c’è la triade CIA:

• Confidenzialità: i dati possono essere acceduti solo dal legittimo proprietario o da chi, comunque, abbia le autorizzazioni necessarie. Il suo opposto è la disclosure (diffusione);
• Integrità: i dati non possono essere modificati da chi non ha l’autorizzazione per farlo. Il suo opposto è la alterazione;
• Disponibilità: i dati devono essere disponibili a chi abbia le autorizzazioni necessarie nei modi e nei tempi richiesti. Il suo opposto è la distruzione.

A questi, spesso si aggiungono:

• Privacy: il diritto che ha ogni individuo di determinare quando, quanto, come e a chi comunicare le informazioni che riguardano sé stesso;
• Non ripudio: fornire l’evidenza irrefutabile che una certa azione è stata compiuta da una determinata persona e non da altre o che un certo messaggio è stato spedito da un determinato mittente;
• Autenticazione: fornire la prova che l’utente è esattamente chi dice di essere. Da non confondersi con l’identificazione che consiste semplicemente nel dire chi si è. Per fare un esempio, l’identificazione consiste nel fornire la propria username, mentre l’autenticazione nel fornire la propria password. Da notare che in taluni casi, gli attributi privacy e autenticazione possono essere requisiti in conflitto tra loro. Qualora l’autenticazione non sia necessaria si ha l’anonimato;
• Anonimato: il diritto che hanno gli utenti di compiere un’azione senza poter essere riconosciuti;
• Autorizzazione: consiste nello stabilire un meccanismo con cui dare l’accesso o meno alle risorse da parte degli utenti. I modelli di autorizzazione più diffusi sono:

1. Discrezionario: il proprietario della risorsa, o, più in generale, il gestore della risorsa, concede l’utilizzo della risorsa agli utenti, a sua discrezione. In tal caso è appropriato, ai fini del monitoraggio, della documentazione e del controllo della sicurezza costruire una Matrice di Controllo degli Accessi, in cui si riporta risorsa per risorsa che tipo di accesso ha un determinato utente o ruolo;
2. Mandatorio: è basato sulla classificazione delle risorse (ad esempio confidenziale, segreto, top secret) e degli utenti e nello stabilire a priori quali categorie di utenti possono accedere a quali categorie di risorse;
3. Basata su ruoli: consiste nello stabilire a priori i diritti di accesso alle risorse posseduti da determinati ruoli e nell’assegnare i ruoli agli utenti;
4. Dipendente dal contenuto: il diritto di accesso da parte degli utenti è dato in base alla tipologia di risorsa (ad esempio video, musica, file testuali ecc.);
5. Dipendente da regole: ogni risorsa ha una lista di regole di accesso ad essa associate. Un esempio è l’accesso ad una discoteca reso possibile solo da chi è in lista;
6. Dipendente dal contesto: l’accesso a una determinata risorsa è garantito solo da particolari attributi dell’utente, della risorsa o dell’ambiente. Un esempio potrebbe essere l’accesso ad un concerto che è determinato dal possesso del biglietto, oppure il fatto di poter passare da una determinata porta, normalmente chiusa, solo se si è in condizioni di emergenza.

• Tracciabilità: è possibile tracciare le azioni compiute dagli utenti sulle risorse;
• Proprietà intellettuale: che consiste nella possibilità di autorizzare l’uso o meno di opere di ingegno. Per quanto si tratti, comunque, di un argomento che rientra nell’ambito dell’autorizzazione, ci è sembrato comunque giusto enunciarlo a parte, dal momento che ha una sua letteratura, delle sue soluzioni e tematiche specifiche.

I principi di sicurezza da seguire per uno sviluppo compliance

Un insieme di principi di sicurezza più completo è fornito da Information Systems Security Association (ISSA) “Generally Accepted Information Security Principles (GAISP) Version 3.0.” del 2004.

GAISP è organizzato in tre livelli, da quello più generale a quello più specifico:

• Principi pervasivi: hanno come obiettivo la governance e descrivono gli scopi concettuali della sicurezza delle informazioni. Sono pochi, generali, fondamentali e poco variabili. Si basano sulla triade CIA e sono 9:

1. Principio di accountability (PP-1): le responsabilità devono essere chiaramente definite e condivise e le azioni devono essere tracciate (“chi fa cosa” e “cosa fa cosa”);
2. Principio di awareness (PP-2): tutti coloro che sono coinvolti a vario titolo nella sicurezza delle informazioni dovrebbero poter accedere a standard, metodologie, strumenti, convenzioni e best practice relative alla sicurezza ed essere informati delle possibili minacce;
3. Principio dell’etica (PP-3): l’informazione dovrebbe essere utilizzata e gestita in modo etico;
4. Principio di multidisciplinarietà (PP-4): standard, metodologie, strumenti, convenzioni e best practice relative alla sicurezza dovrebbero tenere in considerazione i punti di vista di tutti gli stakeholder;
5. Principio di proporzionalità (PP-5): I controlli relativi alla sicurezza delle informazioni dovrebbero essere proporzionali al rischio di modifica, indisponibilità o diffusione non autorizzata. In sostanza è il principio del rapporto costi/benefici;
6. Principio di integrazione (PP-6): standard, metodologie, strumenti, convenzioni e best practice relative alla sicurezza dovrebbero essere integrati gli uni con gli altri e con le policies e le procedure organizzative al fine di creare e mantenere la sicurezza in tutto il sistema informativo;
7. Principio di temporalità (PP-7): tutte le parti coinvolte nella sicurezza delle informazioni dovrebbero agire in modo coordinato e in sincronia per prevenire le minacce e rispondere a potenziali incidenti di sicurezza;
8. Principio di assessment (PP-8): occorre ripetere periodicamente l’analisi dei rischi cui è soggetta l’informazione;
9. Principio di equità (PP-9): le misure di sicurezza devono essere selezionate, implementate e gestite in modo rispettoso della dignità e dei diritti delle persone;

• Principi funzionali: (Broad Functional Principles ) hanno come obiettivo la gestione operativa e derivano direttamente dai principi pervasivi dettagliandoli ma restando sempre ad alto livello. Sono più numerosi dei precedenti e variano solo a seguito di grossi cambiamenti tecnologici. La relazione tra principi funzionali BFP-x e principi pervasivi PP-x è ben mostrata con la matrice in figura. In totale sono 14:

1. Information security policy (BFP-1): il management deve assicurare che vengano sviluppate e mantenute policy, standard, procedure e linee guida a supporto di tutti gli aspetti della sicurezza delle informazioni;
2. Educazione e sensibilizzazione (BFP-2): il management dovrebbe far in modo che l’information security policy venga comunicata in modo adeguato a tutto il personale;
3. Responsabilizzazione (BFP-3): il management dovrebbe fare in modo che qualsiasi azione fatta sugli asset informativi e sulle risorse IT a supporto venga autorizzata e tracciata;
4. Information Asset Management (BFP-4): il management dovrebbe catalogare e valorizzare gli asset e assegnare livelli di sensibilità e criticità;
5. Environment Management (BFP-5): il management dovrebbe analizzare e compensare i rischi inerenti all’ambiente fisico interno ed esterno dove gli asset informativi e le risorse IT a supporto sono immagazzinate, trasmesse, processate e usate;
6. Qualifiche del personale (BFP-6): il management dovrebbe stabilire e verificare le qualifiche di tutti coloro che accedono agli asset informativi e alle risorse IT a supporto nel senso di integrità morale, competenze e need-to-know;
7. Gestione degli incidenti (BFP-7): il management deve fornire tutto quanto necessario alla risposta e alla risoluzione degli incidenti di sicurezza assicurando che l’impatto sul business sia minimizzato e che la probabilità futura di incidenti simili venga ridotta;
8. Ciclo di vita dei sistemi informativi (BFP-8): il management deve assicurare che la sicurezza sia rispettata in tutte le fasi del ciclo di vita dei sistemi;
9. Controllo degli accessi (BFP-9): il management deve porre in essere controlli appropriati affinché l’accesso ai sistemi informativi sia compatibile con i livelli di rischio richiesti;
10. Continuità operativa (BFP-10): il management deve pianificare e operare l’IT in modo tale da preservare la business continuity;
11. Gestione del rischio (BFP-11): il management deve predisporre contromisure di sicurezza adeguate al valore degli asset e al livello delle minacce;
12. Sicurezza della rete (BFP-12): il management deve stabilire misure di sicurezza di rete appropriate;
13. Requisiti legali e contrattuali della sicurezza dell’informazione (BFP-13): il management dovrebbe soddisfare tutti i requisiti a livello di regolamenti, legali e contrattuali relative agli asset informativi;
14. Pratiche etiche (BFP-14): il management deve rispettare i diritti e la dignità delle persone in fase di selezione e attuazione delle policy e delle norme di sicurezza;

• Principi di dettaglio: sono destinati ai professionisti della sicurezza e guidano all’implementazione dei principi funzionali. Sono molto numerosi e facilmente variabili in funzione dei cambiamenti tecnologici e delle minacce. Un esempio è l’uso di one-time password nell’accesso logico agli asset informativi critici come principio di dettaglio relativo al principio funzionale di controllo degli accessi a sua volta relativo al principio pervasivo di proporzionalità.

Requisiti minimi di sicurezza nella PA

Nella PA italiana la stessa struttura a tre livelli, dal generale al particolare è fornita da linee guida di Agid, requisiti minimi di sicurezza e norme tecniche.

A titolo di esercizio, possiamo fare il mapping tra le misure minime di sicurezza e i principi pervasivi di GAISP.

Ricordiamo che le misure minime comprendono:

ABSC-1 Inventario dei dispositivi autorizzati e non autorizzati

ABSC-2 Inventario dei software autorizzati e non autorizzati

ABSC-3 Proteggere le configurazioni di hardware e software suidispositivi mobili, laptop, workstation e server

ABSC-4 Valutazione e correzione continua della vulnerabilità

ABSC-5 Uso appropriato dei privilegi di amministratore

ABSC-8 Difese contro i malware

ABSC-10 Copie di sicurezza

ABSC-13 Protezione dei dati

Anche OECD (Organizzazione per la Cooperazione e lo Sviluppo Economico) ha redatto nel 2002 le “Linee guida dell’OCSE sulla sicurezza dei sistemi e delle reti d’informazione “. In questo caso, i principi sono 9.

Metodologie per risolvere conflitti tra requisiti di sicurezza

Ora che abbiamo capito cosa si intende per requisiti di sicurezza, il passo successivo è quello di capire come elicitarli, parola che indica l’identificazione, l’analisi e la risoluzione dei conflitti.

A tale scopo sono state introdotte due metodologie: SQUARE e ATAM.

SQUARE (Security Quality Requirements Engineering) è stata  creata a fine 2005 dal CERT (Computer Emergency Response Team) americano, allo scopo di introdurre la sicurezza sin dalle prime fasi del processo di sviluppo del software.

La metodologia ATAM (Architecture Tradeoff Analysis Method), invece, è nata nel 1998 a opera del SEI (Software Engineering Institute) per risolvere i conflitti tra i requisiti, determinando l’impatto che un cambiamento sugli attributi di qualità (es. performances, sicurezza, usabilità, modificabilità ecc.) ha sull’architettura.

Le varie attività di sviluppo del software previste dalle due metodologie vengono compiute da ingegneri dei requisiti dotati di specifiche competenze di sicurezza e in collaborazione con gli stakeholder dei progetti.

Ingegneria dei requisiti: gestire lo sviluppo sicuro del software

Dopo l’elicitazione dei requisiti effettuata applicando le metodologie SQUARE e ATAM, questi andranno portati in un formato comune e infine validati con gli stakeholder, per essere sicuri che ciò che abbiamo raccolto sia effettivamente ciò che è desiderato.

L’Ingegneria dei Requisiti (Requirements Engineering) è un processo formale che si occupa proprio di questo e anche della successiva gestione. Come insegna una delle regole di base del Project Management, ogni progetto richiede un grado di formalismo commisurato con la sua complessità. Pensiamo, ad esempio, all’architettura di un sistema come lo Space Shuttle: in questo caso, il livello di rigore e formalizzazione nella gestione dei requisiti sarà del tutto diverso, naturalmente, rispetto allo stesso identico processo per la realizzazione di un gestionale delle fatture per una PMI.

Finalizzare lo sviluppo: la gestione dei requisiti

Terminata la formalizzazione e la validazione dei requisiti, occorrerà completare anche l’importante fase di gestione ordinaria dei requisiti stessi. È normale che in qualsiasi progetto, avente una durata finita che può essere anche di mesi o anni,   i requisiti possano cambiare in corso d’opera a causa delle mutate condizioni al contorno: cambiamenti nelle priorità di business, maturazione di nuove tecnologie, più promettenti e a costi più bassi,  risorse umane, e quindi competenze, che si avvicendano, stakeholder che cambiano, regolamenti e leggi che pongono nuovi vincoli e così via. È importante essere preparati a questo ed è, anzi, il motivo per cui nei progetti software sono nate le metodologie agili: piuttosto che adottare un modello di sviluppo a cascata in cui i requisiti vengono definiti all’inizio e mai più toccati fino alla fine è opportuno, quando si teme che le condizioni al contorno mutino frequentemente, adottare un modello più veloce, con rilasci e consolidamento di singoli gruppi di funzionalità in tempi più brevi.

È per questo che si adotta un processo di Change Management formale anche per i requisiti.