Per molteplici ragioni spesso si ragiona in termini di sicurezza solo affidandosi ad aspetti tecnologici senza tener conto di quelli che possono essere i possibili vincoli che l'ambiente pone. Con il termine ambiente intendiamo l'insieme di tutti i fattori che possono influenzare la corretta riuscita di un progetto di sviluppo che risultano essere spesso mutevoli (anche nell'arco dello stesso progetto) e difficilmente catalogabili. Quindi, rispetto a quanto si può comunemente attendere, l'aspetto della sicurezza tecnologica è quello meno problematico da gestire poiché spesso si limita alla selezione e all'adozione di una serie di tecnologie o di componenti software e/o hardware. Ciò che risulta fondamentale, diviene pertanto, l'approccio alle scelte e il processo di codifica dei rischi.
Una buona cultura della sicurezza parte dall'acquisizione di alcuni concetti preliminari:

• la sicurezza secondo un'ottica di processo (ISMS);
• concetti base della sicurezza;
• come l'organizzazione influenza scelte di sicurezza.

Il processo di gestione della sicurezza Il Sistema di Gestione per la Sicurezza delle Informazioni (ISMS-Information Security Management System), sviluppato nella parte prima della BS7799, costituisce parte integrante del sistema organizzativo, ed è volto a stabilire, implementare, monitorare, mantenere e migliorare la sicurezza. Le modalità di protezione risiedono nell'assicurare adeguati livelli di confidenzialità, integrità e disponibilità (principi che verranno espressi nel seguito dell'articolo), attraverso la gestione controllata dei processi secondo un approccio simile a quello degli standard della serie ISO9000, per la certificazione di qualità. Nel seguente schema vengono riportate gli step principali che costituiscono il processo.

Figura1 - Schema dell'ISMS

Dalla Figura 1 è facile individuare la volontà degli "ideatori" di fornire un formalismo, privo però della rigidità che spesso accompagna uno schema, a sostegno di ogni sistema decisionale. Forse sarebbe più idoneo parlare di metodo piuttosto che di processo. In quest'ottica l'utilizzo dell'ISMS può essere integrato con tutti i processi di sviluppo esistenti:

• A cascata
• Incrementale
• Iterativo
• RUP (Rational Unified Process)

Si può affermare che la scelta di un processo di sviluppo rispetto ad un'altro sia già l'adozione, se pure a volte involontaria, dell'ISMS. Prendiamo ad esempio in considerazione (Figura 2) il processo A cascata in cui il progetto viene scomposto in una sequenza di fasi, ciascuna delle quali produce un output che costituisce l'input per la fase successiva. Le frecce di ritorno tra una fase e l'altra indicano eventuali ricicli per modifica necessari nel momento in cui all'inizio di ogni nuova fase, si mettono in discussione i risultati della fase precedente.

Figura 2 - Schema del processo di sviluppo a cascata

Una valutazione dei RISCHI (primo step dell'ISMS) di tale processo porterebbe ad evidenziare ad esempio che:

• Le prime verifiche concrete, in termini di risultati visibili e comprensibili da committenti e utenti, arrivano verso la fine del progetto, nel periodo finale della fase di test e questo potrebbe avere come risultato la mancata corrispondenza ai requisiti, impliciti ed espliciti richiesti, con il conseguente incremento dei tempi e dei costi di progetto.
• Si basa sull'assunzione che sia possibile, nella fase iniziale del progetto, chiarire tutti i requisiti del sistema e che ottenuto l'accordo sui requisiti, i requisiti stessi non cambino più fino alla fine del progetto.

Evidenziare tale rischi non significa escludere a priori questo processo di sviluppo, ma valutarne l'applicabilità nel proprio conteso. Ad esempio se i tempi di realizzazione sono brevi e i requisiti semplici da definire, tale processo può considerarsi utilizzabile. In questo caso si può dire che il rischio residuo derivante dalla scelta di adottare tale processo di sviluppo è considerato accettabile e marginale. Come abbiamo visto, l'ISMS può essere utilizzata per la scelta di un processo di sviluppo rispetto ad un altro (fase pre-sviluppo), ma allo stesso tempo in ogni fase dello sviluppo stesso. Il tipo di rischio e i metodi per contenerne i danni sono naturalmente differenti per le varie fasi. Prendiamo in considerazione sempre il processo A cascata, nella fase di coding, ad esempio, uno degli aspetti che spesso si tralascia è la mancanza di esperienza degli sviluppatori che può incidere notevolmente sulla riuscita del progetto. In questo caso valutarne il rischio significa attribuirgli un valore, anche di tipo qualitativo, sulla base, ad esempio, dei precedenti tipi progetto a cui hanno partecipato gli sviluppatori, sul tipo di formazione, etc. Una mitigazione a tale rischio diviene l'introduzione di linee guida per lo sviluppo sicuro di applicazioni, la scelta di una risorsa rispetto ad un'altra, l'avvio di un piano di formazione, etc.

Concetti base della Sicurezza
Poiché il temine sicurezza è stato per tempo largamente utilizzato associandogli semantiche di varia e a volte dubbia natura, si è ormai diffusa e consolidata l'usanza di considerarla come RISPOSTA alle esigenze di:

• Confidenzialità: solo gli utenti autorizzati possono accedere alle informazioni necessarie;
• Integrità: protezione contro alterazioni o danneggiamenti; tutela dell'accuratezza e completezza dei dati;
• Disponibilità: le informazioni vengono rese disponibili quando occorre, nell'ambito di un contesto pertinente e con livelli di servizio "efficienti".

Il rispetto di tali principi è sicuramente vincolato da una scelta tecnologica che si concretizza nell'identificazione di un prodotto, ma allo stesso tempo è altrettanto chiaro che la scelta di un prodotto deve essere subordinata ai vincoli organizzativi e alle esigenze funzionali. Una soluzione a questo scenario può essere presentata attraverso la risposta a due domande:

• Qual è il livello di sicurezza che i servizi esposti dell'applicazione deve avere?
• Quali caratteristiche di sicurezza deve avere il prodotto?.

Applicazione e Servizio In questo ambito per servizio intendiamo una serie di funzionalità offerte da un componente applicativo, utilizzate da un utente, fornite e gestite da un fornitore, commissionate da un contraente. Le varie funzionalità, possono essere aggregate in maniera logica, secondo un criterio di finalità: l 'uso e il controllo del servizio avvengono attraverso interfacce specifiche di uso e di gestione/configurazione/ operazione. Le interfacce costituiscono, in quest'ottica, gli insiemi aggregati di funzionalità:

• Service Usage
• Service Management
• Service Customization
• Service Operation
• Service Monitoring

In figura Figura 3 un'applicazione è presentata come servizio a cui accedono, con finalità diverse, attori differenti attraverso interfacce. Nel caso in cui il servizio dipenda da servizi esterni, occorre specificare se dipende solo da interfacce d'uso o anche da interfacce di gestione (in figura abbiamo inserito entrambe le interfacce).

Figura 3 - Definizione di Applicazione in un ottica di servizio

Come abbiamo anticipato, ogni interfaccia è utilizzata da diversi attori che hanno esigenze differenti: le interfacce, quindi, devono essere la traduzione delle esigenze funzionali e organizzative esposte dai vari attori; I requisiti di interfaccia devono cioè mappare le esigenze organizzative e funzionali aziendali che possono essere espresse da un singolo utente ma allo stesso tempo anche da un'itera organizzazione. In ottica di sicurezza questo significa evidenziare i requisiti di confidenzialità, integrità e disponibilità di ogni interfaccia applicativa. Prendiamo in considerazione l'interfaccia di Management "Service Management": quale deve essere il livello di visibilità che i gestori devono avere sull'applicazione? E' chiaro che la risposta a questa domanda esprime un requisito di Confidenzialità ed è espressa solamente da una volontà organizzativa.

I contesti della Sicurezza
Aggregando le funzionalità su interfacce applicative facilita la definizione di requisiti chiave o almeno li categorizza in aree di operatività. Nella seguente tabella esponiamo per ogni interfaccia applicativa quali possono essere le esigenze organizzative che richiedono vincoli su aspetti di sicurezza

Tabella 1 Interfacce-esigenze-requisiti

Fino a questo punto abbiamo evidenziato solamente il contesto organizzativo ma lo sviluppo applicativo, è guidato anche da un insieme più vasto di principi, che possono essere raggruppati in categorie sulla base dei seguenti ambiti:

• Organizzativo: sia a livello organizzativo che di governance (politico), devono essere definite linee guida, policy, procedure e requisiti molto chiari che regolino il contesto operativo aziendale. E' in tale ambito che vengono individuati e gestiti eventuali vincoli normativi che influenzano direttamente o indirettamente lo sviluppo applicativo, che determinino il modo con cui il software deve essere utilizzato e che permettano di gestire adeguatamente possibili incidenti di sicurezza.
• Processo: L'articolazione di un progetto e quindi la determinazione del modello di processo di sviluppo, spesso determinata da una rigida sequenza di fasi predefinite, deve essere pianificata attraverso la gestione sistematica dei rischi di progetto, per arrivare alla loro progressiva diminuzione. La scelta della modalità di gestione può condizionare in maniera rilevante la buona riuscita di un progetto:la mancata realizzazione è il peggiore degli incidenti di sicurezza.
• Implementativo: L'architettura applicativa deve essere progettata ed il software implementato in modo da resistere agli attacchi e agli usi impropri, mantenendo allo stesso tempo la caratteristica di poter essere aggiornato e modificato con l'evolversi delle modalità di attacco.
• Tecnologico: La realizzazione del prodotto finito passa attraverso l'adozione di particolari tecnologie (sia che si tratti di framework di sviluppo, sia dell'adozione di particolari componenti software, oppure dell'utilizzo di protocolli di comunicazione o di particolari servizi di rete), la cui scelta deve essere fatta sulla base del livello di sicurezza richiesto dalle specifiche del progetto.
• Individuale: la tecnologia non può garantire da sola un alto livello di sicurezza; gli utilizzatori di un sistema sicuro devono essere consapevoli e attenti ai potenziali rischi di sicurezza derivanti dal loro comportamento. Un esempio consiste nella corretta gestione della segretezza delle password di accesso ai diversi servizi offerti dall'applicazione.

Il comportamento del sistema viene ad esplicarsi attraverso una serie di azioni che possono essere intraprese nel rispetto dei vincoli di sicurezza. Se indichiamo con meccanismo decisionale l'insieme di queste azioni, possiamo scomporre questo meccanismo in quattro grandi categorie di competenze:

• gestione
• progettazione
• controllo
• utilizzo

Possiamo allora evidenziare in che modo l'adozione di una politica di sicurezza (che fa parte di uno degli ambiti precedentemente elencati) influenzi il meccanismo decisionale con la seguente tabella:

Con il simbolo XX si vuole indicare una dipendenza stretta mentre con il solo X si vuole indicare una semplice influenza marginale. La tabella vuole esprimere, per fare un esempio, che i principi di sicurezza del contesto organizzativo guidano le decisioni a livello manageriale ed influenzano comunque l'intero insieme di competenze. Al contrario, possiamo evincere che le procedure di controllo del sistema sono governate dai principi del contesto di processo ed applicativo, ed influenzate dai principi organizzativi e tecnologici.

I criteri di valutazione di un tecnologia Dal punto di vista tecnologico il rispetto di requisiti di sicurezza può passare attraverso la congruenza ai seguenti criteri di valutazione.

1. Norme funzionali relative ai prodotti, aventi come scopo principale la ricerca della interoperabilità dei sistemi.
2. Criteri di valutazione dell'assurance, ossia della fiducia riponibile nella sicurezza realizzata da sistemi e prodotti
   • TC SEC (Applicato in USA)
   • IT SEC (Applicato in Europa)
   • ISO/IEC 15408 (Common Criteria - evoluzione ed integrazione di entrambi)
3. Norme relative al sistema di gestione della sicurezza
   • ISO 9000 (solo di riflesso - Analisi del rischio)
   • ISO/IEC TR 13335 (parti 1, 2, 3, 4)
   • BS 7799 parte1 - Code of practice
   • BS 7799 parte2 - Verifica
   • ISO/IEC 17799 (che recepisce la parte 1 delle BS7799
4. Norme legali
   • Legge 675/96
   • DPR 318/99
   • Legge 196/2003
   • Altre leggi e direttive nazionali ed europee.

    

Conclusioni
In questo breve articolo si sono affrontati alcuni temi che dovrebbero dare una visione generale di come la sicurezza costituisce un elemento costante nello sviluppo di applicazioni. L'organizzazione come il processo costituiscono gli elementi fondamenti nella scelta di una soluzione tecnologica. E' necessario adattare la tecnologia alle esigenze funzionali e organizzative.

Bibliografia
BS7799 Part 1. Thomas R. Peltier-Information Security Risk Analysis