Sono
passati ormai cinque
anni dalla pubblicazione della versione più nota dello
standard BS-7799, e il mese scorso è stata pubblicata un'ulteriore versione. Sono passati anche cinque anni da
quando ho cominciato ad interessarmene.
Allora la mia opinione era che
uno standard di questo tipo poteva fare per la sicurezza delle reti
molto più di quanto non avessero fatto in tanti anni gli
standard di certificazione dei sistemi, dall'Orange Book fino ai Common
Criteria.
Adesso il BS7799 è noto un po' a tutti ed è
abitualmente citato fra le best practice, e quindi si può
cominciare a ragionare sull'effettivo impatto che può avere
sulla sicurezza aziendale: giusto prima di vedere come si è evoluto con la nuova versione. Il mio giudizio continua ad
essere molto positivo: al di là del fatto che la certificazione
sia ancora poco diffusa, e che si stia avviando a grandi passi sulla
strada dell'ISO-9000, il BS-7799 ha mostrato il suo valore proprio come
best practice nella guida alla gestione della sicurezza informatica.
In
effetti, in questo periodo di scarse e poco rilevanti novità
tecniche, il grosso cambiamento è stato proprio nell'attenzione
alla gestione della sicurezza. Insieme alla gestione è arrivata
l'impostazione basata sulla valutazione del rischio e sulla
strutturazione "a processi", che non sarebbero state praticabili con
l'attenzione focalizzata sulle tecnologie. Il focus sulle tecnologie
era prevalente fino a poco tempo fa,
complici l'atteggiamento dei vendor e l'impreparazione dei loro
clienti.
Adesso è meno frequente e più
facile da criticare l'atteggiamento del tecnico, interno all'azienda o
consulente, che dice:"Io vi ho installato e configurato la soluzione
giusta, poi se gli utenti non la usano non è un mio problema",
come anche la risposta della controparte utente:"La sicurezza è
un problema di gestione dei sistemi informatici, non mi vengano a
seccare con la loro classificazione dei traffici: ho altro da fare".
Adesso queste affermazioni sembrano palesi assurdità, ma fino a
poco tempo fa erano la norma (naturalmente non sto dicendo che questo
atteggiamento sia sparito).
Tuttavia, se guardiamo la sicurezza delle aziende, in realtà
è migliorato abbastanza poco; in effetti, la mia sensazione
è che l'unico miglioramento rilevante e diffuso rispetto a
cinque anni fa sia l'adozione generale di alcune tecnologie di base
(firewall, antivirus...) che seppure non utilizzate al meglio danno in
ogni azienda una base minima dalla quale partire. Dov'è allora il vantaggio nell'adozione del BS7799 come
best practice, se poi l'unico piccolo miglioramento è dato
dall'adozione di poche soluzioni tecniche minime? Mi sto
contraddicendo?
Non credo. L'attenzione si è
spostata verso il problema reale, verso l'alto, ovvero la gestione, e
quindi la guida data dalle esigenze aziendali e dalla valutazione del
rischio, dalle quale poi dovrebbero derivare le scelte tecnologiche e
l'implementazione; tuttavia, l'applicazione del BS7799 si scontra con alcuni
problemi di livello superiore.
I problemi si riconoscono fin dalle prime pagine dello standard. Cito:
"It is essential that an organization identifies its security requirements. There are three main sources.
The first source is derived
from assessing risks to the organization. Through risk assessment
threats to assets are identified, vulnerability to and likelihood of
occurrence is evaluated and potential impact is estimated.
The second source is the legal,
statutory, regulatory and contractual requirements that an
organization, its trading partners, contractors and service providers
have to satisfy.
The third source is the
particular set of principles, objectives and requirements for
information processing that an organization has developed to support
its operations."La
gestione della sicurezza ICT deriva quindi i propri requisiti in
modo molto più diretto dalla gestione del rischio e dalla
valutazione delle esigenze dei processi aziendali: non è
più chiusa su sè stessa e su una protezione "assoluta" di
sistemi e reti, indipendente dal contesto o legata alle valutazioni
più o meno personali del progettista/sistemista, ma si apre ad
una vera interazione con l'azienda su un piano (quello della riduzione
del rischio) molto più comprensibile ai responsabili dei
processi aziendali, per arrivare a soluzioni mirate alla protezione dei
processi e quindi più efficaci ed economicamente giustificabili.
Sembra bello... ma spesso questi requisiti non arrivano. Nel
momento in cui si interagisce con i responsabili dei processi aziendali
per ottenere un'indicazione sulla criticità dei processi, sulla
loro interazione con il sistema informatico, sulla classificazione dei
dati trattati per poi arrivare ad una valutazione del rischio, spesso
si trova il deserto. Naturalmente non sono in grado di entrare nel
merito del perché, ma spesso queste informazioni in
azienda semplicemente non esistono. Il BS7799 sembra quindi basarsi su
un'azienda ideale che, almeno in Italia, non corrisponde ai fatti, e
quindi mancano i presupposti per una corretta applicazione dello
standard. La mia impressione è che ci
sia ancora troppa distanza fra la definizione dei processi aziendali e
la progettazione del sistema informatico che li deve supportare. Il
sistema informatico è ormai alla base di molti di questi
processi, e per alcune aziende è senz'altro uno dei componenti
fondamentali. Eppure, sembra che i processi aziendali siano ancora
pensati con un flusso documentale in mente, in cui i documenti ogni
tanto spariscono nel sistema informatico per "teletrasportarsi" e
ricomparire, modificati, in un altro punto del flusso. Il sistema
informatico poi si arrabatta a supportare questa visione, di fatto
disgregando invece il documento in dati che viaggiano ognuno per la
propria strada, modificandosi e raccogliendo altre informazioni in un
modo del quale il reponsabile del processo non solo non ha
visibilità, ma nemmeno si interessa.
E il responsabile della
sicurezza? Nel tentativo di raccogliere i requisiti per il suo ISMS, si
trova spesso con la responsabilità di far emergere il problema, evidenziando come
il responsabile del processo non abbia controllo sui propri dati,
magari mostrandogli per la prima volta come questi vengano liberamente
riutilizzati in un altro processo con caratteristiche di sicurezza
completamente diverse, semplicemente perché il sistema
informatico li aveva a disposizione.
In pratica quindi, derivare i requisiti di sicurezza dalle esigenze dei
processi aziendali è un problema tutt'altro che banale,
particolarmente se il successo dipende dalla (poca) autorevolezza
di un "reparto sicurezza" della funzione IT, e in modo abbastanza
indipendente dall'eventuale "forte commitment" dei vertici aziendali.
Questo, per inciso, è uno dei motivi per cui ritengo che la sicurezza IT
dovrebbe dipendere da una funzione Sicurezza, vicina ai vertici
aziendali, e non dalla funzione IT (in alcune aziende in effetti è così). A parte questo, penso anche che i
processi dovrebbero oramai essere pensati realmente in termini di flussi di
informazioni, e che chi progetta il supporto da parte del sistema
informatico, coinvolto fin da subito, dovrebbe impegnarsi a presentare
le architetture che disegna in modo che il responsabile del processo
riesca a capire l'effettivo flusso di dati nel sistema e le sue
interazioni con altri flussi. Mancando questo, la sicurezza torna
necessariamente ad essere gestita "tamponando" e
immaginandosi i requisiti, con i limiti di visibilità e
comprensione del processo che l'IT può avere, e con le solite
difficoltà a giustificare le scelte e le spese; in pratica si
torna alla soluzione tecnologica, ormai dichiarata inefficace da tutti
a gran voce, ma che rimane l'unico strumento realmente in mano alla
gestione della sicurezza IT.
Un secondo problema riguarda proprio il coinvolgimento della security
nella progettazione del sistema informatico. È scritto
dappertutto che i problemi di sicurezza devono essere affrontati quanto
prima possibile in un progetto, e la conseguenza è che il
"gruppo di sicurezza ICT", comunque si collochi nell'azienda, deve
essere coinvolto fin dalle prime fasi del progetto. Il problema, anche
quando (quando?) viene coinvolto subito, è il come viene
coinvolto. La sicurezza è generalmente a valle del processo
decisionale, e in fondo il BS7799 appoggia questo atteggiamento: l'ISMS
deriva i requisiti di sicurezza dai processi aziendali e dalla
valutazione del rischio. Data la centralità del sistema
informatico in azienda, non credo che sia più accettabile un
atteggiamento così passivo. Per quello che vedo, ciò che
succede, grossolanamente, è che il processo viene disegnato,
viene progettato il supporto IT, e chi si occupa della sicurezza cerca
di rendere sicuro un processo già definito, lavorando nel
migliore dei casi sulla progettazione del supporto informatico. L'unico
effetto di
un coinvolgimento della sicurezza nelle prime fasi è che se
qualche aspetto del progetto è veramente ingestibile dal punto
di vista della sicurezza, allora viene cambiato qualcosa. È
chiaro che in questo modo la sicurezza continua ad essere un'aggiunta,
un fastidio, un costo, e continua ad avere un'efficacia limitata. Se
effettivamente una valutazione del rischio venisse fatta nelle prime
fasi della definizione di un processo aziendale, e se questa
valutazione trasparisse alla progettazione IT,
allora per alcune tipologie di processo la sicurezza (e di conseguenza
la componente ICT) dovrebbe guidare, e non seguire, sia il disegno del
processo che quella del supporto IT; la sicurezza insomma, è
vista ancora come un problema di implementazione, il che mi sembra in
contrasto con il concetto stesso di gestione del rischio. Per fare un
esempio concreto: il rischio di business legato ad un'attività
di commercio elettronico può essere valutato senza appoggiarsi
alle competenze fornite dalla sicurezza ICT (e quindi, su quali basi di
reale valutazione del rischio viene presa la decisione)? Si può
quindi decidere ad esempio che è opportuno offrire un servizio
via cellulare, prescindendo dalle valutazioni sulla sicurezza dei
metodi di pagamento (o basandosi su una generica affermazione: "abbiamo
la soluzione" fornita da un vendor)? La sicurezza ICT di un servizio di
home banking è davvero solo un fattore di riduzione del rischio
operativo, quando le conseguenze di immagine di una grossa falla
potrebbero togliere per un tempo considerevole la fiducia degli utenti
nel servizio? La scelta di appoggiarsi ad un outsourcer per un servizio
critico per l'azienda può essere fatta senza valutare la
possibilità ed i costi della realizzazione di un'interazione
sicura con l'outsourcer? Per ora la risposta sembra essere certamente
sì nella maggior parte dei casi. Più passa il tempo,
più l'IT diventerà centrale e meno questa posizione
sarà sostenibile. Al momento, mi sembra che la "valutazione del
rischio" più comune sia: lo fanno gli altri, quindi in qualche
modo lo possiamo/dobbiamo fare anche noi. Anzi, le considerazioni di
sicurezza arrivano non solo dopo queste,
ma dopo una serie di altre quali la scelta dei fornitori, delle
architetture, delle clausole contrattuali, dei tempi e di solito anche
degli investimenti; naturalmente, quando gli investimenti sono decisi,
i margini di manovra diventano veramente ridotti.
Allo stesso
modo naturalmente, in
alcuni processi la componente security risulterebbe marginale, con tutte le
gradazioni intermedie. Insomma, l'ISMS è ancora un processo
troppo chiuso su sè stesso, passivo nei confronti delle esigenze
dell'azienda; sembra affrontare più un problema organizzativo
interno all'IT ("gestire" la sicurezza ICT) che le problematiche effettive di
sicurezza ICT legate al business aziendale. Il fatto è che
affrontare queste tematiche in azienda vuole dire andare a toccare
delle carenze organizzative al di fuori dell'ICT, cosa che chiaramente
non è facile fare, anche per questioni di competenza (in tutti i
sensi).
Un terzo problema è legato nuovamente all'attenzione ai processi
ed ai loro rischi, e anche in questo caso il problema è favorito
dall'attuale approccio alla sicurezza dei processi aziendali, anche se
non ne è una conseguenza necessaria. Il percorso in sè
è molto naturale: processo aziendale, rischio del processo,
gestione della sicurezza nel processo, sicurezza dei componenti IT
realizzati in supporto al processo. In questa sequenza si perde
facilmente l'attenzione al contesto in cui si colloca il supporto ICT per il processo. Dato
che ogni catena è robusta quanto il suo anello più
debole, non è pensabile garantire la sicurezza di alcuni
componenti in un contesto che non offre un adeguato supporto ai
meccanismi di sicurezza, e non è pensabile di avere
caratteristiche di sicurezza diverse fra processi se l'infrastruttura non offre un
supporto alla separazione dei processi. Quello che voglio dire è
che affrontare (e quindi finanziare) la sicurezza per singoli processi
rende più difficile affrontare la sicurezza dell'infrastruttura
(ad esempio della intranet), che non è riconducibile al singolo
processo. Il rischio, peraltro supportato anche dall'atteggiamento di
molti fornitori, è che si veda la sicurezza solo a livello
applicativo, nell'illusione che un po' di autenticazione e di cifratura
del traffico siano sufficienti per tutelare l'azienda. La soluzione
in questo caso è relativamente semplice: ricordarsi di
affrontare i problemi di sicurezza dell'infrastruttura ICT nel suo
complesso, ad un livello tale da garantire l'efficacia delle protezioni
scelte per i singoli processi.
Insomma, la conclusione è che l'ISMS non ha portato ad alcun
miglioramento? Certamente no. Resto convinto che l'uso del BS7799 come
best practice, indipendentemente dalle certificazioni, sia un enorme
miglioramento. Il problema è che non è facile mettrlo in
pratica, e chiaramente non risolve tutti i problemi. Sono però
convinto che man mano che questa impostazione si diffonde, si arriverà
sempre più vicino ad una risposta alla domanda fatidica:
perché si spende in sicurezza, e la sicurezza del sistema
informatico non migliora?