Quando la sicurezza è una seccatura...
Nel
corso degli anni, l'offerta di sicurezza informatica, particolarmente in ambiente distribuito, è passata
dai primi prodotti semiartigianali, alla disponibilità di una
grande scelta di prodotti e servizi, che vanno dalle esigenze
dell'utente casalingo fino a quelle più sofisticate. Le
tipologie di prodotti sono aumentate, come anche le
funzionalità. Da un paio di anni tuttavia, si vede tutto sommato
poco di nuovo. Al di là di adattamenti di tecnologie note a
nuovi ambienti (es. wireless), di nuovi nomi per piccoli cambiamenti
tecnologici (es. IPS), o di tecnologie note che cominciano a
raggiungere una certa maturità e diffusione (es. biometria), le
tecnologie sono tutto sommato cambiate di poco. In parte sarà
colpa delle difficoltà del mercato, o dell'ubriacatura di
soluzioni diverse negli anni precedenti, ma penso che se ci fosse spazio ed
interesse per nuove tecnologie, continuerebbero ad essere proposte
anche in questa fase di assestamento.
Il problema è che da tempo è chiaro che le tecnologie non
bastano, serve usarle in modo efficace. L'attenzione adesso è
principalmente sull'ISMS, principalmente fondato sui criteri del
BS7799, con particolare attenzione alla business continuity e alla
valutazione del rischio, in modo da avere misure di sicurezza
funzionali alle esigenze aziendali. Importante è poi la conformità alle
normative che ormai quotidianamente vanno a toccare settori
strettamente legati all'IT. Quindi
chi si occupa di sicurezza, che sia CSO, consulente o anche
sistemista, si deve sempre più attrezzare con nuove competenze:
giuridiche, spesso per rimediare allo scarso o nullo supporto fornito
dall'ufficio legale, che raramente dà in questo settore delle
indicazioni utili per le scelte operative; di organizzazione aziendale,
perché la sicurezza parte dai processi aziendali e dalle loro
esigenze; di sicurezza fisica, che sempre più cade, in mancanza
di altri riferimenti, sulle spalle di chi spesso in azienda è
l'unico con un minimo di cultura e di forma mentis adatta ad affrontare
il problema.
Tutto
questo sta portando a una migliore sicurezza? Di principio verrebbe
certamente da dire di sì, l'ISMS è senz'altro un concetto
importante che affronta problemi notoriamente lasciati aperti dalle
soluzioni puramente tecnologiche; a parte i facili
entusiasmi però, e fatte salve le ovvie eccezioni, nel complesso
direi che i miglioramenti reali sono spesso pochi, perché tutto
questo non
ha ancora superato lo scoglio principale che da sempre la sicurezza in
azienda deve affrontare: non la vuole nessuno. Nonostante i diversi
modi in cui è stata proposta (compresa la "enabling technology"
del commercio elettronico), la sicurezza continua ad essere
principalmente una seccatura. Inoltre, nel corso degli ultimi anni
l'impostazione di molti
fornitori di prodotti e servizi di sicurezza, orientata al "ti vendo la
soluzione ai tuoi problemi", e che purtroppo tuttora va per la
maggiore, ha portato a grandi delusioni e a una forte diffidenza da
parte
potenziali utenti. Per di più, la sicurezza logica è nota
per "disturbare" la facilità di gestione e utilizzo dell'IT, e
quindi il rapporto con la gestione IT spesso non è semplice, con
un frequente atteggiamento di "muro di gomma" nei confronti delle
richieste o delle proposte della sicurezza. Con l'arrivo del BS7799, se
vogliamo, la situazione è anzi peggiorata, perché chi
si occupa di sicurezza IT non se ne sta più a discutere nel
datacenter con i sistemisti; va in giro per l'azienda facendo domande
agli owner dei processi e dei dati, domande che spesso mettono in luce
le magagne non solo della sicurezza, ma della gestione generale dei
processi aziendali (domande tipo: "di chi sono questi dati?") e creando
ancora più fastidi.
E il famoso "supporto alla politica di sicurezza da parte dell'alta
dirigenza"? Quando c'è, spesso sono solo parole, perché
la dirigenza alla fine convive molto più con i process owner
(che di solito ha anche scelto) piuttosto che con chi si occupa di
sicurezza, e in fondo se si agita lo spauracchio della minore
produttività...
Perché
in fondo il problema della sicurezza IT continua ad essere lo stesso di
sempre: viene
vista come una fonte di ritardi e complicazioni, non come un
miglioramento dei processi aziendali, indipendentemente da quello che
può suggerire la valutazione del rischio; e qui arriviamo al
nocciolo del discorso. Probabilmente in molti casi
è vero: soprattutto quando è motivata da
conformità a normative, o quando è guidata da scelte si
sicurezza "assolute" anziché adeguate alle esigenze, l'utente
non la sente come utile. Un esempio di scelte assolute è questo:
si tende a dire che per un firewall il fail-safe vuole dire che in caso
di fallimento, il firewall deve
bloccare tutto il traffico piuttosto che permetterne di non
autorizzato. In un
contesto in cui la disponibilità è il fattore più
importante, una politica di questo tipo chiaramente può
essere deleteria: in caso di fallimento può essere preferibile
appoggiarsi ad una seconda linea di difesa (finanche la sicurezza del
singolo server), piuttosto che interrompere il servizio. Sono
valutazioni che, con un'adeguata analisi del rischio, dovrebbero
portare alle giuste conclusioni. Purtroppo, l'analisi del rischio
è un problema ampiamente riconoscuto come difficile, e
scelte così controcorrente rispetto alle posizioni più
diffuse possono essere difficili da sostenere (se si sbaglia, le
conseguenze a
livello personale sono ancora peggiori). A dire la verità, ho la
sensazione che spesso l'analisi del rischio venga utilizzata nel
tentativo, più o meno cosciente, di giustificare i costi di
scelte sostanzialmente già fatte, piuttosto che per riconoscere realmente le esigenze dell'azienda
(es. "il danno di immagine è rilevante e quindi concentriamoci
sul server web; prima però serve un'analisi del rischio che
evidenzi i costi del danno di immagine").
Esiste
però un altro motivo che rende la sicurezza un fastidio
anziché un miglioramento, e il problema si vede bene nella
gestione della business continuity. La business continuity è
un'esigenza facilmente riconosciuta anche dall'alta dirigenza,
dall'owner del processo aziendale e dalla gestione IT. Tuttavia,
pochissime aziende hanno affrontato realmente il problema. Il motivo
è noto: la business continuity costa tanto, e i ritorni si
vedono solo nelle (sperabilmente) rare occorrenze di disastri. Il
responsabile che deve scegliere di investire in business continuity si
può porre il problema: "Voglio mettere a bilancio delle spese
ingenti per la business continuity, i cui effetti positivi, se si
vedranno, con un po' di fortuna si vedranno quando qualcun'altro mi
avrà sotituito (con il turnover attuale probabilmente bastano
pochi anni), o voglio invece investire quei soldi in attività
che aumentino la produttività sotto la mia gestione? Dopotutto,
nel caso
sfortunato in cui il disastro accada nei prossimi tre-quattro anni,
dato che la business continuity non la fa nessuno, difficilmente io ne
avrei un grosso danno di immagine personale. Infine, se
anche cominciassi un piano di business continuity adesso, difficilmente
sarebbe completo in pochi anni, ma intanto le spese le dovrei sostenere
io...". Se vogliamo, il problema del "mal comune mezzo gaudio"
è evidente con le epidemie di worm: molte grosse aziende non
riescono ancora ad arginare il
problema, per il quale ci sono gli strumenti (quantomeno per contenere
validamente le infezioni), e i cui danni sulla disponibilità del
sistema informativo sono riconosciuti; ma siccome il problema è
diffuso, nessuno viene licenziato perché l'intero sistema ha
subito un blocco a
causa dei worm, e viceversa pochi vengono apprezzati per averlo evitato.
Il problema è quindi che molte misure di sicurezza, anche suggerite
da una corretta analisi del rischio, servono ad evitare eventi magari
altamente dannosi, ma occasionali, mentre l'impatto
sull'usabilità e la gestione del sistema è quotidiano.
Questo è secondo me il motivo per cui la sicurezza spesso viene
affrontata (seriamente) solo dopo qualche grosso incidente.
Ma
allora, ci sono aspetti della sicurezza che possono migliorare,
anziché complicare, la
quotidianità? Ce ne sono molti: la protezione da virus e spam,
la robustezza dell'infrastruttura di rete, le procedure di gestione dei
profili utente, il monitoraggio dei servizi, della rete e del carico,
la stabilità e l'aggioramento delle workstation... tutte cose
che, una volta implementate correttamente, possono ridurre il lavoro
per il sistemista, e spesso migliorare l'usabilità del sistema
per l'utente.
Qui la cosa si fa più interessante, perché sono problemi
normalmente affrontati in una rete ben gestita, spesso anche dove non
c'è una figura specifica che si occupa dei problemi
di sicurezza, o una richiesta esplicita di sicurezza. E dove c'è
un sistema di monitoraggio
efficace, non è visto dai sistemisti come un fastidio, ma come
un aiuto; ad esempio, la possibilità di individuare quale
macchina sta generando un certo traffico in base al mac address,
risalendo di switch in switch
con tool semiautomatici, è uno strumento di troubleshooting,
molto prima che di sicurezza. Nella mia esperienza, c'è una
distinzione netta e ben riconoscibile fra reti ben gestite e reti
gestite male: fra reti in cui i disservizi sono rari e in cui i guasti
di rete vengono individuati e corretti rapidamente, e le reti in cui
invece qualsiasi problema provoca
espressioni imbarazzate e scuse acrobatiche. Naturalmente ci sono i
casi intermedi, ma non capita spesso di trovare reti in cui alcuni
aspetti sono gestiti molto bene, ed altri molto male. Questo
perché si tratta principalmente di una questione di
mentalità, sia dell'azienda che della gestione IT. Dove il
sistema informativo è visto realmente come critico per l'azienda
(non solo a parole), c'è attenzione a questi aspetti anche con
mezzi limitati. Dove l'attenzione non c'è, il sistema
informativo va avanti solo grazie a notevoli iniezioni di risorse. In
quest'ultimo caso, non è detto che l'utente (o la dirigenza) sia
in grado di riconoscere il cattivo stato ed i costi eccessivi del
sistema informativo, perché come ci si abitua alla
necessità di riavviare le workstation, così, in mancanza
di confronti, ci si abitua ai disservizi della rete.
La cosa interessante è che laddove i sistemi informativi sono
ben gestiti, molti dei tipici problemi di sicurezza non si trovano, e
l'introduzione di misure di sicurezza è molto più facile
e meno intrusiva che in quelle mal gestite. Quando mi trovo ad esempio
a parlare con un
tecnico dell'introduzione di un firewall a dividere due
sottoreti, se la rete è gestita con cura sono certo che la
modifica sarà effettuata in breve tempo, in modo efficce e con
il minimo disturbo necessario per l'utenza, posto naturalmente che sia
stato superato il problema delle risorse e
sia convinta la gestione IT della necessità dell'intervento. Per
contro, su reti mal
gestite, anche attività ovvie come l'installazione di un
firewall fra la rete aziendale e Internet
possono richiedere tempi inaccettabili.
Questa
è una delle conseguenze interessanti del vedere la sicurezza non
solo in termini di tecnologie di autenticazione e controllo accessi, ma
valutando realmente le esigenze aziendali: per moltissime aziende, il
problema principale non è il defacement del sito web o i
problemi di intercettazione del traffico; il punto cardine è la
disponibilità. La disponibilità è quella che
garantisce che le risorse per cui hanno pagato siano accessibili e che
le attività non si interrompano;
credo che per molte aziende, una seria analisi del rischio metterebbe
questo come priorità. Se l'azienda è sensibile a questi
problemi, non ha bisogno di essere convinta ad adottare certe misure,
le vuole già di suo a tutti i livelli.
Forse
allora è questa la strada da seguire per portare la sicurezza in
azienda senza incontrare ostilità o indifferenza: lavorare prima
sugli aspetti di sicurezza che migliorano la gestione e la
disponibilità. Migliorare le
prestazioni del sistema informativo ha un effetto
sull'operatività quotidiana, ed il ritorno è molto
più facile
da misurare che non gli effetti di una tecnologia sofisticata di
intrusion detection, che spesso poi nessuno utilizza in modo adeguato.
Magari la nostra analisi direbbe che ci sono prima altre
priorità, ma se sappiamo (o abbiamo già provato) che
quelle priorità non verranno accettate, forse è inutile
incaponirsi su una strada magari più corretta ma impraticabile,
ed è meglio scegliere una via di minore resistenza; e magari,
nel frattempo, si riesce a mettere insieme una classificazione dei dati
e dei processi aziendali. Una volta arrivati a un'infrastruttura
robusta ed efficente, si
può provare a toccare il resto; viceversa, se non si arriva
neppure a questo, allora forse il problema dell'azienda non è la
sicurezza, e ci si può mettere il cuore in pace.
|