Introduzione
Nel precedente articolo "Introduzione alla sicurezza applicativa = processo + organizzazione + tecnologia", è delineato il significato del termine sicurezza e la necessità di inserirla all'interno del processo di sviluppo di un'applicazione.
In questo articolo, prendiamo in considerazione gli attuali standard e linee guida di sicurezza organizzativi ed implementativi attualmente presenti.
Prima di inoltrarvi nella discussione, diamo una definizione comune al concetto di sicurezza applicativa, nel suo senso più lato, che per le finalità dell'articolo non è solo parte dei requisiti tecnologici cui l' appplicazione deve sottostare, quali per esempio l'utilizzo di firma digitale o crittografia, ma piuttospo un processo che prende parte a tutte le fasi di crescita di un'applicazione: analisi, design, implementazione, utilizzo del servizio da parte dell'utente e successiva dismissione del prodotto.
Le applicazioni sono lo strato superiore e l'unità di elaborazione delle informazioni all'interno di una infrastruttura IT. La rete ed i sistemi operativi permettono l'utilizzo dell' applicazione da parte dell' utente.
Il primo passo per rendere sicura un'applicazione sarà identificare i punti deboli dell' applicazione e dell' infrastruttura sottostante. Questo esercizio vi sarà di aiuto per focalizzare i vostri sforzi nel consolidare l'applicazione e per mantenerla in esercizio.

Motivazioni all'utilizzo
A parere di chi scrive, vi sono almento 4 buoni motivi per attenerci agli standard propsoti durante le varie fasi che compongo il processo di sviluppo.
Primo fra tutti la "giustificazione dei costi": Solitamente il termine sicurezza è direttamente messo in relazione a spese addizionali. Anche se l'inserimento della sicurezza nel processo non genera direttamente guadagno, trova comunque una giustificazione in termini di costo. Il processo di analisi e gestione dei rischi dovrebbe generare, in modo diretto ed automatico, la giustificazione per i controlli di sicurezza in termini di business riducendo i costi ed i tempi di sviluppo.
Secondo "Rompere le barriere - Business Relationships": Il processo sicurezza interessa sia il management che il personale IT. Il management è responsabile di definire il livello di sicurezza/rischio che l'azienda intende accettare (indicazione che coinvolge anche scelte di business). Il reparto IT è responsabile della definizione dei controlli e delle applicazioni. Oltre ad assegnare direttamente le informazioni ad ogni gruppo, l'analisi dei rischi gioca un ruolo proattivo intensificando il livello di comprensione delle necessità e ruoli dei gruppi implicati nel processo, raggruppando così gruppi di persone con ruoli eterogenei e mettendo in diretta relazione la sicurezza con le problematiche di business.
Quindi la creazione di un programma di "Security Awareness": L'applicazione del programma di analisi e gestione su larga scala, coinvolge in maniera attiva un gran numero di persone, inserendo così il tema sicurezza nella agenda di molte riunioni aziendali ed incrementando il livello di consapevolezza del problema sicurezza nell'azienda.
In ultimo, ma non per importanza, maggior "Coerenza tra i gruppi": Uno dei maggiori risultati ottenuti è l'apporto di coerenza e obiettività nell' approccio alla sicurezza non solo tra diversi applicativi , ma anche tra diverse unità aziendali.
Norme di sicurezza delle informazioni
Oggi è possibile identificare tre ambiti della normazione relativa alla sicurezza: il primo è quello delle norme funzionali, relative ai prodotti, aventi come scopo principale la ricerca dell'interoperabilità dei sistemi informatici.
Queste coprono temi quali ad esempio i protocolli di comunicazione e il formato dei dati sulle smartcard (ISO TC 168). Accanto vi sono poi numerose specifiche tecniche pubbliche emesse da associazioni.
Il secondo ambito è quello dei criteri di valutazione dell'assurance, ossia della fiducia riponibile nella sicurezza realizzata da sistemi e prodotti informatici.
Si concentrano in tre pubblicazioni: i criteri statunitensi TCSEC (Trusted Computing Security Evaluation Criteria, 1985), i criteri europei ITSEC (Information Technology Security Evaluation Criteria, 1991) e i criteri internazionali ISO/IEC 15408 pubblicati nel dicembre '99, noti anche come Common Criteria.
Il terzo ambito è infine quello delle norme relative al sistema di gestione della sicurezza nell'azienda: ISO/IEC TR 13335 (part 1, 2, 3, 4), BS 7799 parte 1 (Code of Practice), parte 2 (verifica) e il recepimento della predetta parte 1 dall'organismo di normazione internazionale ISO/IEC (ISO/IEC 17799).

BS 7799
Vista la scarsa adattabilità dei Common Criteria ed ITSEC, data l' analicità ed il formalismo accentuato dei loro schemi, alla certificazione di sicurezza informatica delle orgnanizzazioni nel 1993 il British Standard Institute decise di sviluppare un documento di riferimento contenente una serie di best practices nell'area della sicurezza informatica.
Lo standard BS7799 è diviso in due parti ISO/IEC 17799:2000 (part 1) e BS7799-2 1999 (part 2).
La prima parte, "standard code of practice", è una sorta di linee guida che definiscono il tipo di controlli di sicurezza che un' organizzazione dovrebbe implementare per salvaguardare i propri assets.
La seconda parte (Part-2) definisce le specifiche standard di gestione per un ISMS (Information Security Management Systems), concetto centrale per l'applicazione dello standard BS 7799. All'interno sono delineati i passi richiesti nella definizione di un framework amministrativo, vi sono incluse le persone, il sistema IT ed i processi all'interno dell'organizzazione. I requisiti definiti all'interno del Information Security Management System mirano ad ottenere i seguenti obiettivi:

• Identificare gli asset da proteggere;
• Definire un approccio organizzativo al risk management;
• Definire ed identificare i controlli da attuare;
• Definire il livello di sicurezza richiesto.
  

Ognuno degli obiettivi sopra descritti deve essere applicato in ogni fase dello sviluppo di una applicazione sicura, anche se il processo richiede attenzioni e misure di sicurezza diverse.

Identificazione degli asset da proteggere
Questo punto dello standard ha lo scopo di definire, le finalità per cui viene istituito l' ISMS, il perimetro della sua applicabilità e competenza, la sua struttura e composizione in termini di riorse professionali, tecnologiche e finanziare.

Definizione di un approccio al risk management
E' uno degli aspetti più importanti ed innovativi della norma che enfatizza la necessità di realizzare, precedentemente alla fase di identificazione dei controlli, una fase di analisi dei rischi.
La normativa non definisce una metodologia da utilizzare, ma bensi delinea la necessità di identificare le minacce, il loro impatto sui beni da proteggere e sull'organizzazione, ed infine di giungere ad una valutazione del rischio (in termini di probabilità di accadimento di una minaccia).
Successivamente all'analisi, si prosegue all' individuazione delle funzioni di sicurezza minime per il livello di servizio richiesto, analizzando come ed in quali termini il livello di rischio può essere ridotto con l'adozione delle funzioni di sicurezza stabilite.

Definizione dei controlli
In questa fase si procede alla definizione dei controlli da implementare e, successiva verifica di riduzione del livello di rischio residuo (ossia dopo avere applicato i controlli di sicurezza).
La normativa prevede 12 diverse categorie di controlli, espressi a livello di specifica funzionale, vale a dire ad un livello di astrazione piutttosto elevato:

1. Politica di sicurezza (Security Policy): Questo controllo istituisce la redazione del documento generale di policy di sicurezza, quali per esempio:
   • Password Protection Policy - Definisce lo standard per creazione, protezione e modifica delle password;
   • Application Security Policy - Definisce le linee guida ed i requisiti di sicurezza da considerare durante la pianificazione, design, implementazione ed utilizzo di un servizio informativo .
     
     
2. Organizzazione della sicurezza (Organisation security): Sancisce l'importanza di una struttura organizzativa interna all'azienda dedicata alla gestione e progettazione del sistema di protezione delle informazioni. Devono essere definiti ruoli e responsabilità per tutti i dipendenti dell'azienda.
   La normativa definisce i ruoli aziendali da attuare, alcuni di questi sono:
   • Information Security Officer - Si occupa direttamente della implementazione dei controlli di sicurezza;
   • Information Owner - Proprietario e responsabile del dato.
     
     
3. Classificazione e controllo degli asset (Asset classification and control): Pur definendo l'informazione, il bene primario da proteggere, altri asset concorrono al mantenimento della riservatezza, confidenzialità e disponibilità delle informazioni. A questo titolo è richiesto di classificare le informazioni e definirne il proprietario, con evidenziazione della criticità di ogni dato.
   
   
4. Gestione del personale (Personnel security): Ancora una volta le informazioni sono il bene primario da custodire, e questo controllo intende definire una serie di contromisure a protezione da attacchi che potrebbero provenire dal personale stesso o da una inaccurata gestione di quest' ultimo. Tra le contromisure proposte spiccano la responsabilizzazione degli utenti nel trattamento delle informazioni e l'importanza di un programma di training adeguato e la necessità di protegerci contro la mancanza di personale.
   
   
5. Sicurezza fisica ed ambientale (Physical and environmental security): Scopo principale di questo controllo è quello di prescrivere i criteri per il controllo accessi alle aree cui sono custodite le informazioni.
   Rientrano in questa categoria dispositivi come una semplice porta chiusa a chiave o tecnologie più avanzate di controllo accessi tramite carte magnetiche.
   
   
6. Gestione dei sistemi (Communications and operations management): Il più esteso e complesso dei controlli definiti nella norma, riguarda l'intero aspetto di gestione delle risorse informatiche. Tra le raccomandazioni più evidenti non possiamo mancare di elencare la necessità di effettuare un capacity planning, la necessità di un sistema di backup, di log delle informazioni e di installare e mantenere un sistema antivirus aggiornato.
   
   
7. Controllo accessi (Access control): Questo controllo, si occupa degli aspetti di controllo delle informazioni, quali per esempio la definizione di una politica di autorizzazione, criteri di gestione degli acccount utente ed assegnazione dei ruoli.
   
   
8. Sviluppo e manutenzione dei sistemi (Systems development and maintenance): Lo scopo dichiarato di questo controllo è quello di suggerire criteri di sicurezza da attuare in fase di progettazione e realizzazione di sistemi e applicazioni. Alcune delle misure introdotte sono una rivisitazione di temi precedentemente trattati.
   E' suggerita la validazione, a livello applicativo, dei dati di input ed output, routine di controllo dei dati, autenticazione dei messaggi e tecniche crittografiche per l'integrità ed autenticità delle informazioni, utilizzo di ambienti di test separati dallo sviluppo e produzione, definizione di procedure di Change Management.
   
   
9. Continuità del business (Business continuity planning): Questo controllo si occupa della definizione di controlli per mantenere la disponibilità delle informazioni nel tempo, tramite l'utilizzo di UPS , sistemi di backup, piano di recovery…
   
   
10. Conformità (Compliance to avoid any breaches of criminal and civil law): L'ultimo dei controlli definiti nella norma, si occupa di evidenziare al lettore la necessità di conformità del sistema informatico, alle leggi, ai contratti e vincoli intercorrenti nei contfronti di terzi.
    

Sarà quindi compito del progettista, una volta selezionati i controlli al momento della gestione del rischio, curare il downsizing a livello di specifica attuativa, tenendo conto del contesto tecnologico cui le contromisure dovrebbero essere applicate.
Nel contesto di sviluppo di applicazioni web, può essere di aiuto affidarci ad un' altro standard l'OWASP (Open Web Application Security Project).

OWASP
Nato nel Settembre 2002, da parte di un folto gruppo di esperti di sicurezza informatica, con l'obiettivo di proporre una guida di riferimento per aiutare chiunque a progettare, sviluppare ed implementare applicazioni web o web service sicuri. Il documento è rivoloto ad architetti, sviluppatori, consulenti.
Come la BS 7799, anche l'OWASP, richiede di anticipare alla fase di definzione ed implementazione dei controlli, una analisi dei rischi collegati allo sviluppo dell'applicazione.
Il documento è diviso in ambiti di applicazione:

1. Linee guida di sicurezza: Un set di principi di alto livello cui tutte le applicazioni dovrebbero aderire.
2. Architettura: breve discussione sulle considerazioni da effettuare, circa l'architettura di sicurezza da implementare, per assicurare il livello di sicurezza richiesto, come per esempio una divisione formale degli ambienti di test, produzione e sviluppo.
3. Autenticazione: descrive i possibili tipi di autenticazione ed i problemi comuni ad ognuno di questi.
4. Gestione delle sessioni: Descrive le modalità corrette di gestione delle sessioni e di generazione dei token di sessione.
5. Controllo accessi ed autorizzazione utenti: Descrive vari concetti base per il controllo degli accessi e l'autorizzazione degli utenti all'utilizzo delle varie funzionalità dell'applicativo.
6. Log degli eventi: Descrive le motivazioni legate all'utilizzo di un file di log, cosa inserire nei log, ed una serie di best practices per la gestione dei log.
7. Validazione dei dati: Definisce una strategia da utilizzare per affrontare il tema di gestione dei dati in input e cosa bloccare.
8. Problemi comuni: Descrive una serie di problemi comuni allo sviluppo di applicazioni web, quali cross site scripting e SQL Injection ed offre una serie di soluzioni per bloccarne la concretizzazione.
   
9. Privacy: Discussione sulle problematiche di privacy che si possono presentare nell'applicazione.
   
10. Crittografia: Discussione su strumenti e metodi di utilizzo della crittografi nella definizione di una applicazione web sicura, e sui motivi per cui la sicurezza è definita dalla segretezza della chiave e non dell' algoritmo.

Conclusione
L'adozione degli standard proposti servono come linee guida per evitare di lasciare buchi nascosti,e pur non risolvendo tutti i problemi legati allo sviluppo di applicazioni "sicure", mi sembra tuttavia che possano essere considerati una buona base di partenza per il lungo, e difficile lavoro che vi aspetta.

Bibliografia
Giulio Carducci - "La tutela dei dati nelle aziende e nelle istituzioni ", Franco Angeli editore, 2003
Fabrizio Cirilli - "La certificazione dei sistemi di gestione per la sicurezza informatica", ICT Security/Nuovo Studio Tecna, Agosto 2003.