Information Security Standard: ISO 17799 – BS 7799. Policy e procedure per il Risk Managent.

 

 

Autore: Dott. Stefano Fio

 

 

Abstract:

Il proposito dei programmi legati all’Information  Security è quello di proteggere la “risorsa informazione”  di enti governativi, aziende private ed aziende pubbliche. Questo programma viene stilato selezionando ed applicando policy specifiche, standard e procedure.  Le “mission” aziendali si incrociano armai sempre di più con problematiche legate alla gestione del rischio ed alla sicurezza.

 

 

            La tendenza alla standardizzazione è divenuta negli ultimi anni un “must”. Quasi tutto ciò che implementiamo segue degli standard. Finalmente anche la gestione della sicurezza informatica e del rischio ha degli standard.

 

            La ISO (International Organization of Standardization) ha pubblicato di recente il “Code of Practice for Information Security Managenent” ISO 17799 e la “British Standard”  BS 7799. Questi documenti come l’ISO/TR 13569 per la sicurezza dei servizi bancari e finanziari e la General Accepted Information Systems Security Practices (GASSP), forniscono ai professionisti del settore sicurezza informatica una vera e propria mappa da seguire per la realizzazione degli “Information Security Program”.

 

            I due standard oggetto di questo articolo: BS 7799 e ISO 17799, sono molto simili. La differenza sostanziale è rappresentata della presenza nella ISO 17799 di una sezione “non-action” (Section 1) prima della lista degli standards (Section 2). La prima sezione si preoccupa di fornire raccomandazioni per l’Information Security Management ad uso di coloro che saranno i responsabili per il set up, l’implementazione ed il mantenimento della security all’interno dell’organizzazione. L’intento è quindi quello di avere a disposizione una base per sviluppare i security standard aziendali.

 

            Sebbene questa “Sezione 1” sia intitolata “standard” in realtà descrive delle linee guida. Quindi possiamo utilizzare la 17799 anche per capire quali sono i percorsi alternativi per raggiungere uno stesso obiettivo.

           

            Nella “Sezione 2” invece ritroviamo Termini e Definizioni:

 

 

-          Information Security: Ha come obiettivo quello di prservare confidenzialità, integrità e garantire la disponibilità delle informazioni.

-          Confidentiality: Assicurarsi che le informazioni siano accessibili solo a coloro che hanno l’accesso autorizzato.

-          Integrità: Salvaguardare l’accuratezza e la completezza dell’informazione nonché la tecnica con la quale viene processata.

-          Availibility: Assicurarsi che le utenze autorizzate abbiano accesso all’informazione ed a tutto ciò che ad essa è collegato quando richiesto.

-          Risk assessment: Rilevamento delle minacce e loro impatto, vulnerabilità delle informazioni e del processo coinvolto al trattamento delle stesse e probabilità che tali eventi ricorrano.Questo processo viene anche denominato Risk Analisys

-          Risk management: Processo di identificazione, controllo e relativo contenimento o eliminazione del security risk di cui è affetto il sistema ad un costo accettabile.

 

Elaborazione alternativa: POLICY
Elaborazione alternativa: LEGGI E REGOLAMENTI
Elaborazione alternativa: PROCEDURE
Elaborazione alternativa: STANDARD & GUIDELINES

 

 


 

 

 


 

 

 


 

 

 

 

 


Fig.1

 

Il primo, fondamentale step, come mostrato in Fig.1, è legato alla verifica di eventuali leggi o regolamenti locali o nazionali che impongono degli obblighi particolari.

 

 Di seguito vengono stilate policy intese come postulati a livello enterprise e obiettivi per aree.  Esempio: L’accesso alle informazioni aziendali è ristretto e controllato. Questo macro postulato genererà policy, standard, guidelines e procedure tipo:

 

-          Policy: L’accesso al sistema informativo aziendale e limitato al solo personale autorizzato.

-          Standard:Gli utenti devono essere in possesso di un UserId univoco e di una password nota solo a loro.

-          Guideline: Le password devono essere lunge almeno otto caratteri ed essere alfanumeriche.

-          Procedure: La richiesta di uno UserId e relativa password deve contenere la firma del titolare delle informazioni. Tale firma sarà verificata tramite il manuale di riferimento delle firme autorizzate.

 

Dall’esempio risultano chiari anche gli altri step:

Gli Standards: rappresentano attività obbligatorie e regole. Tali standards sono spesso costosi da amministrare e quindi devono essere impostati con molto giudizio. Le guidelines: Sono principi più generali che a differenza degli standard possono rappresentare delle raccomandazioni e non necessariamente degli obblighi. Con il termine Procedure, indichiamo invece gli specifici step su come implementare policy, statndards e guidelines. Tali step devono essere completati in ordine.

 

Di seguito “dieci comandamenti” da seguire per una corretta redazione delle procedure.

 

1)      Teniamo presente il target al quale le procedure sono rivolte.

Si potrebbe facilmente incorrere nell’errore di redigere documentazione non comprensibile relativamente allo skill dei lettori.

 

2)      Organizziamo il materiale.

Le procedure devono essere scritte in sequenza logica, con la tecnica dei flussi. L’obiettivo è quello di creare un documento facilementedigeribilie”. Non ci aspettiamo che gli utenti si impegnino nella lettura di un documento lungo e complesso per poter eseguire le loro mansioni in ottemperanza alle procedure.

 

3)      Leggiamo e correggiamo il materiale.

Una volta completato il materiale, prima di inviarlo in tipografia, non ci limitiamo ad un controllo ortografico e grammaticale, ma rileggiamo con cura tutto , verificando che ciò che leggiamo abbia per per noi un senso, perché in caso contrario, per gli altri risulterà completamente incomprensibile!

 

4)      Cerchiamo persone esperte.

In fase di redazione delle procedure, spesso ci si avvale di collaborazioni esterne, è quindi fondamentale cercare soggetti che conoscano già la problematica. Tali collaboratori dovranno essere redarguiti sul flusso della procedura. Queste persone non saranno comunque addette al test della procedura stessa.

 

5)      Utilizziamo parole chiare e familiari.

L’audiance che leggerà tali documenti non sarà molto contenta di leggere parole, espressioni ed acronimi poco familiari. Per questo risulta utile la creazione di una sezione legata alle definizioni.

 

6)      Manteniamo i periodi brevi e semplici.

Teniamo sempre a mente il principio KISS (Keep It Simple Sweetie). Periodi lunghi possono far diminuire il livello di comprensione. Sarebbe opportuno mantenersi in un range tra 10 e 15 parole.

 

7)      Utilizziamo illustrazioni a supporto dei vari argomenti.

“Un’immagine vale più di mille parole”. Risulta opportuno interrompere il flusso del testo con delle immagini a supporto, magari rappresentando graficamente ciò che il testo vuole trasmettere: print screen, grafici, diagrammi.

 

8)      Utilizzo di “voce attiva”.

Scriviamo le frasi in modo tale da rendere ben chiaro chi è il responsabile di una operazione e per quale operazione. Esempio:

-          “ Voce passiva”:  “Ogni 15 giorni verrà affettuato un backup normale dal backup operator”.

-          “Voce attiva”: “Il backup operator” è responsabile del backup normale quindicinale”

 

9)      Assicuriamoci che punteggiatura e grammatica siano corretti.

Non sottovalutiamo questi aspetti: quando inviamo la documentazione agli incaricati del review e questi trovano il documento pieno di errori, badano esclusivamente alla correzione, non tenendo presente il contenuto che potrebbe alla fine risultare alterato.

 

10)   Utilizziamo uno stile non troppo accademico ma più vicino alla conversazione.

Senza fraintendere troppo questa affermazione, tipo non scendiamo all’utilizzo di slang ed idiomi, ma semplicemente cerchiamo di scrivere come se stessimo parlando con una platea, ma senza per questo mancare di precisione.

 

 

Quando ci sediamo  alla nostra scrivania e cominciamo a scrivere, dobbiamo avere ben presente un precisa checklist da seguire:

 

-          Titolo. Stabiliamo gli argomenti delle procedure che sitamo per stilare.

-          Intento. Descriviamo con termini generali cosa tale procedura si propone di soddisfare.

-          Scopo: Breve descrizione del processo che la procedura vuole coprire.

-          Responsabilità. Identifichiamo chi eseguirà ogni specifico step identificandolo non con un nome ma con un ruolo lavorativo, tipo “responsabile del Personale” e non Mario Rossi.

-          Sequenza degli eventi. E’ fondamentale impostare le  condizioni al verificarsi delle quali l’utente deve eseguire il suo task.

-          Approvazioni. Identificare ed ottenere a priori tutte le necessarie autorizzazioni per l’esecuzione del task.

-          Prerequisiti. Elencare tutte le pre-condizioni necessarie prima di avviare un task.

-          Definizioni. Teniamo sempre a mente l’audience delle procedure, inseriamo in ognuna il significato di termini ed acronimi utilizzati nella stessa.

-          Equipaggiamento necessario. Individuiamo tutto ciò di cui l’utente che deve eseguire il task ha bisogno.

-          Warnings. Se il mancato rispetto dell’appropriata sequenza delle operazioni può provocare gravi danni, è fondamentale sottolinearlo e ribadire i requisiti per l’esecuzione degli specifici task.

-          Precauzioni. Identifichiamo tutti gli step da intraprendere per evitare problemi o danni.

 

 

 

Conclusioni:

 

Quanto scritto rappresenta un overview dei contenuti dalla ISO 17799 e della BS 7799, che ricordiamo essere documenti protetti da copyright ed in quanto tali per ottenerli bisognerà acquistare  copia completa degli stessi. E non dimentichiamo che un corretto apprendimento di tali regolamenti può sicuramente avvantaggiare gli attuali esperti di sicurezza a raggiungere la posizione di ISSO (Information Systems Security Officer) per grandi realtà.

 

 

 

 Dott. Stefano Fio

                                                                                   Security & Risk Manager

stefano.fio@securityarchitect.it