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.