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.
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 facilemente “digeribilie”.
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