Un contesto di sicurezza in evoluzione
Il concetto di "software sicuro" si è evoluto dai tempi del mainframe o dei PC non interconnessi, isolati in una sorta di ecosistema autonomo (in termini tecnici si direbbe stand-alone) molto diversa dall'attuale realtà di reti che collegano sistemi, personal computer e dispositivi intelligenti di nuova generazione come telefoni e palmari (per non parlare della tv e di altri apparecchi, multimediali e no, di uso domestico) sempre più inter-dipendenti.
Una volta la sicurezza consisteva prevalentemente nel proteggere fisicamente la macchina su cui il software veniva eseguito; oggi la sicurezza comprende un ampio spettro di attività e ambiti e investe lo stesso codice sorgente dalla sua implementazione fino alle procedure e agli standard che governano il come e dove questo software viene utilizzato.
E quanto più aumenta il numero di processi di business basati su un'infrastruttura di rete pubblica, come Internet, tanto più la sicurezza diventa un fattore decisionale critico per tutte le aziende - molte delle quali non avrebbero in passato avuto tale necessità - che devono acquisire software.
Garantire un'infrastruttura IT sicura è sempre più un problema complesso, che richiede strategie differenziate a diversi livelli; grandi organizzazioni, piccole e medie aziende e singoli individui hanno tutti una diversa e specifica esigenza di sicurezza. Le grandi aziende devono gestire sistemi complessi e molto diversificati, che comprendono piattaforme software diverse, applicazioni commerciali e sviluppate ad hoc: il tutto spesso messo a disposizione di una base di utenti che si espande e accede nel tempo a un sempre maggior numero di dispositivi.
Perfino il singolo consumatore, il singolo individuo, un tempo solo preoccupato di non perdere dati salvati su un floppy disk, oggi non può trascurare i rischi legati a codice "sospetto", alle frodi informatiche e alle violazioni della privacy.
L'evoluzione di questi rischi nei vari contesti ha una cosa in comune: se in passato il problema della sicurezza era un problema affrontato quasi esclusivamente dai professionisti, dagli specialisti del settore, oggi è un problema di tutti coloro che in qualche modo hanno a che fare con l'informatica.

I vari "fronti" sui quali la battaglia per la sicurezza deve essere combattuta possono essere così sintetizzati:

• Tecnologia: prima fra tutti il software, che si tratti di un sistema operativo, di una componente o di un intero ambiente di sviluppo, di una applicazione isolata piuttosto che un servizio di rete, deve essere fondamentalmente sicuro;
• Implementazione: il software deve essere sviluppato e gestito 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.
• Politiche: sia a livello organizzativo che di governance, devono esistere regole molto chiare che determinino il modo con cui il software viene progettato e che permettano di gestire adeguatamente individui e organizzazioni che contribuiscono allo sviluppo e manutenzione.
• Processi: i produttori di software devono poter contare su meccanismi e processi che consentano di gestire e risolvere i problemi legati alla sicurezza dei loro utenti, mentre le organizzazioni e gli individui devono essere in grado di poter installare e beneficiare delle eventuali modifiche necessarie.
• Individui: la tecnologia può garantire da solo un alto livello di sicurezza; ciò non toglie che gli utenti di quella tecnologia debbano essere consapevoli e attenti ai potenziali rischi.

Sicurezza applicativa
Negli ultimi cinque anni il paradigma di sicurezza applicativa è lentamente, ma con passo continuo, uscita dall'ombra del molto ben conosciuto e documentato campo della network security. Sorge spontanea una domanda: quanto si è evoluto il giovane campo di sicurezza applicativa. Cosa stanno facendo le altre aziende per risolvere il problema della sicurezza nelle applicazioni?

Il ciclo di sviluppo software
Ciclo di sviluppo software, o SDLC (Software Development Life Cycle), è il termine generale che descrive il processo che un'azienda segue durante lo sviluppo di strumenti software o applicazioni.
Nel corso degli anni, nel passaggio dalla visione artigianale alla visione industriale del software, si e' compreso che il processo andava formalizzato attraverso:

• un insieme di fasi in cui decomporlo,
• un insieme di prodotti delle varie fasi,
• un insieme di metodi da adottare nelle varie fasi,
• un insieme di tecniche e/o modelli con cui descrivere i prodotti di ogni singola fase.
  

Nella figura 1 è possibile trovare un modello di processo di sviluppo software sequenziale, che contiene al suo interno le seguenti fasi: studio di fattibilità o definizione prelimare del problema, definizione dei requisiti, progetto, sviluppo/implementazione, test e sviluppo. Il modello presentato non vuole definire una metodologia, ma piuttosto un metamodello cui far riferimento

Figura 1 - Schema del ciclo di vita delle applicazioni software

Nella Tabella 1, sono definiti una serie di step che intendono definire un framework concettuale per effettuare un piano di sicurezza durante il ciclo di sviluppo. Questo framework, deve essere utilizzato solo come esempio e non come metodologia definitiva, contiene all'interno una descrizione degli step principali di cui vi dovrete far carico.

Tabella 1 - Sicurezza nel ciclo di sviluppo

Fase 1: Studio di fattibilità
Durante questa fase sono analizzate le esigenze informative connesse allo sviluppo di un nuovo progetto per arrivare alla individuazione di una o piu' soluzioni architetturali e fornire alla direzione gli elementi di valutazione necessari per prendere una decisione riguardo alla realizzazione operativa del progetto.
Entra subito a far parte del gruppo di sviluppo una nuova figura è che l' IT Security Officer.
L'IT Security Officer sarà coinvolto nelle seguenti attività:
Security Categorization - viene fatto un assessement sulla sensibilità delle informazioni, possibili danni, minacce, leggi, problematiche ambientali, caratteristiche di sicurezza e politiche di sicurezza aziendali.

Fase 2: Analisi dei requisiti
Durante questa fase sono documentati e definite le funzionalità (requisiti funzionali), vincoli e obiettivi del prodotto con l'approvazione del cliente o del management.
Analisi dei rischi preliminare - analisi preliminare dei rischi per identificare l'ambiente in cui l'asset software dovrà operare, e per identificare i requisiti necessari alla protezione dell'asset. Sono presi in considerazione le policy aziendali, procedure e best practice. Un altro aspetto preso in considerazione in questa fase sono i dati e gli utenti. Tramite una analisi preliminare dei rischi è possibile identificare gli asset da proteggere, e determinare i requisiti funzionali di sicurezza.

Fase 3: Progettazione
Durante la seconda fase vengono identificate le componenti software ed hardware dell'architettura generale. Si descrivono le funzioni che il sistema deve svolgere, ciascuna delle quali verrà trasformata in uno o più programmi eseguibili. Obiettivo di questa fase è anche effettuare una schedulazione abbastanza precisa dei tempi di sviluppo del progetto.
Le funzioni di sicurezza coinvolte in questa fase sono:

Analisi dei rischi - analisi che identifica i requisiti di sicurezza per il sistema tramite un processo formale di analisi dei rischi. Questa analisi si basa sui dati ottenuti nella fase precedente, ma i risultati ottenuti sono molto più dettagliati e specifici. Il processo di analisi è solitamente diviso in quattro fasi:

1. identificazione delle minacce al sistema: identificazione di tutte le potenziali cause di incidente (deliberato o accidentale) che possono danneggiare un componente del sistema o il sistema stesso;
2. identificazione delle vulnerabilità: identificazione dei punti deboli nella sicurezza delle informazioni; tali debolezza potrebbero essere sfruttate per violare la sicurezza del sistema;
3. determinazione del livello di rischio: determinare la probabilità che una data minaccia si avvantaggi delle vulnerabilità per provocare un incidente;
4. definizione di contromisure: definizione di un piano d'azione per ridurre il livello di rischio individuato per ogni singolo componente o processo.
   

Definizione di linee guida di sicurezza - revisione o eventuale definizione delle linee guida di sicurezza per lo sviluppo di codice sicuro, test e archittetturali. Devono essere prese in considerazione le policy e standard aziendali in termini di sicurezza, oltre agli attuali standard come ISO17799 o OWASP.
Definzione della architettura di sicurezza - individuazione dell'architettura di sicurezza da implementare nel progetto, compreso il sistema di autorizzazione, autenticazione, identificazione, sistemi di protezione quali firewall, proxy e IDS, oltre a definire le procedure da implementare prima di poter mettere in produzione il software.

Fase 4: Sviluppo e test di unità
In questa fase, il progetto viene realizzato come insieme di programmi (moduli) nel linguaggio di programmazione scelto. Il testing di unità serve per verificare che ciascun modulo soddisfi le specifiche richieste.
Le funzioni di sicurezza coinvolte in questa fase sono:
Analisi e test del codice - prima di rilasciare nuove parti di codice allo sviluppo, sono effettuati test per individuare eventuali vulnerabilità tipo buffer overflow, sql code injection, etc...
Metriche e post mortem - mantenete traccia dei problemi di sicurezza individuati durante i test. Per ogni vulnerabilità, è necessario mantenere traccia delle vulnerabilità in un database dei bug. Il database dei bug sarà popolato anche di tutte le vulnerabilità di sicurezza non ancora risolte.

Fase 5: Integrazione test di sistema
In questa fase, si integrano le singole unità tra loro e si esegue il testi di sistema completo per assicurarsi che le specifiche siano soddisfatte.
I test di sicurezza coinvolti in questa fase possono essere individuati in cinque macro attivià:

1. Mapping della rete;
2. Analisi delle vulnerabilità tramite strumenti automatici;
3. Penetration Testing;
4. Password Cracking;
5. Revisione ed auditing dei log;

Fase 6: Deployment e manutenzione
E' la fase più lunga del ciclo di vita di un prodotto software (oltre il 50% dei costi complessivi del ciclo di vita). Il sistema viene utilizzato.
La manutenzione comporta la correzione di errori che non erano stati scoperti nelle fasi precedenti, migliorando la realizzazione delle unità del sistema ed aumentando i servizi forniti man mano che si richiedono nuovi requisiti.
Se l'errore individuato risulta essere una minaccia di sicurezza, e non una deficienza funzionale del prodotto, deve essere documentata la natura del problema, le circostanze entro le quali il problema insorge, ed un piano di risposta al problema. Deve essere effettuato uno studio di analisi sulla minaccia, per determinare se è possibile creare un exploit per la vulnerabilità, e dare un valore di rischio (alto, medio e basso) alla minaccia.
Se il livello di rischio è elevato, il gruppo di sviluppo scriverà una patch per fissare il problema di sicurezza. Questo è possibile solo se durante lo sviluppo si è fatto uso di un sistema di revision control.
In ultimo sarà necessario rivedere le azioni intraprese, per individuare se è necessario o meno rivedere le attuali politiche e linee guida di sicurezza aziendali.

Divulgare le informazioni
Uno dei passi chiave per l'integrazione del processo sicurezza nel ciclo di sviluppo è assicurare che chiunque necessiti di informazioni ne abbia disponibilità, in una forma a lui utile. Utilizzando i passi del ciclo di vita sopracitati, descriviamo il tipo di informazioni richieste per ogni funzione.

• Studio di fattibilità: il personale addetto alla definizione dei concetti base del prodotto o programma deve familiarizzare con le strategie e politche di sicurezza aziendali. Solo quando avrà familiarizzato con questi concetti può delineare dei concetti compatibili con l'ambiente di sicurezza attuale, presente e futura.
• Analisi dei requisiti: il personale addetto allo sviluppo delle specifiche e requisiti funzionali e tecnologici deve avere disponibilità dei requisiti di sicurezza. L'azienda può decidere di mantenere online i requisiti di sicurezza e privacy e renderli disponibili agli analisti che devono sviluppare i requisiti di business.
• Progettazione: gli analisti devono avere accesso alle informazioni circa prodotti di sicurezza e architetture enterprise sicure, così che la progettazione del prodotto si possa integrare con ogni esistente (o futuro) meccanismo e servizio di sicurezza ;
• Codifica:gli sviluppatori devono avere accesso agli standard/linee guida di sviluppo, best pracitces,librerie, ed esempi pratici di codifica precendetemente definiti dall'azienda.
• Test:deve essere formalizzato un piano di test che includa ogni requisito di sicurezza con una procedura per testare e verificare la corretta implementazione dei requisiti.Il piano di test, come tutte le altre informazioni, deve essere sempre disponibile e comprensibile al personale addetto ai test per poterlo utilizzare in modo efficace e semplice;
• Deployment e manutenzione: questa è la fase in cui il prodotto o programma è posto in produzione. I passi richiesti per integrare i controlli e misure di sicurezza come l'autenticazione, controllo accessi, encryption, backup, etc. devono essere documentati e disponibili al personale che implementa il progetto.

Sommario
Sfortunatamente, non è possibile sviluppare un sistema software sicuro al 100%.Ma, è altresì possibile sviluppare un sistema software più sicuro e creare nuove opportunità di business.
L'introduzione del problema sicurezza ciclo di vita di un prodotto software, non riduce le performance del sistema, ma piuttosto ne aumenta le performance garantendo la tutela di Confidenzialità, Integrità, e Displinibilità degli assets software.

Bibliografia
[1] "Security Considerations in the Information System Development Life Cycle", NIST Special Publication, http://www.iwar.org.uk/comsec/resources/security-life-cycle/
[2] Larry G. Wlosinski, "Implementing Information Technology (IT) Security in the SDLC - A How to approach", GIAC,October 2002