Le sei più stupide idee della sicurezza informatica

Non so chi di voi ha avuto occasione di leggere "The Six Dumbest Ideas in Computer Security" che tradotto suona più o meno così: "Le sei più stupide idee della sicurezza informatica".

L'autore è Marcus Ranum, esperto di sicurezza e autore di numerose pubblicazioni, il quale propone quelle che secondo lui rappresentano le sei idee alquanto poco geniali della sicurezza informatica. La lettura è interessante ed è spunto di riflessioni sicuramente costruttive.

Innanzitutto noto che qualche volta questi esperti oltreoceano hanno una certa smania di voler per forza schematizzare tutto e devo dire che questo approccio comincia a farmi venire l'orticaria! Possibile che la soluzione di tutto sia un susseguirsi di linee guida e/o di best practice?

Questo può forse essere adatto in contesti con una rigida impostazione, in cui ognuno segue pedissequamente delle regole e non agisce quasi mai di propria iniziativa. Ma quando la situazione è imprevista, cosa succede?

Di certo non sarà contemplata nelle linee guida e allora solo il buon senso e una buona dose di esperienza permetterà di prendere le giusta decisione o per lo meno quella più opportuna in quel momento.

E' un po' come paragonare un sistema esperto ad un sistema dotato di intelligenza artificiale. Il primo avrà un comportamento che scaturirà unicamente dalle regole che utilizza al suo interno, il secondo sarà in grado di "apprendere" nuovi comportamenti.

Vediamo in dettaglio le sei idee che Marcus indica come stupide:

1) Permettere come default (Default Permit): consiste nell'impedire ad un sistema di eseguire le sole azioni malevole e, nel caso queste non si verificassero, continuare indisturbati nell'esecuzione. Questa secondo Marcus è una idea stupida perché il sistema dovrebbe eseguire solo quelle operazioni che gli sono consentite. E' un po' l'esempio delle black-list e delle white-list. Le prime richiedono un continuo aggiornamento delle azioni malevole da bloccare, le seconde richiedono invece una conoscenza approfondita dei "comportamenti" del sistema per enumerarli come azioni consentite e bloccare tutto il resto.

Se però questo è sacrosanto da un punto di vista della sicurezza, potrebbe non esserlo dal punto di vista dell'usabilità. Cosa succede se nel sistema viene installata una nuova componente non annoverata nella white-list? Semplice: la nuova componente non funzionerà! E' quindi evidente che in contesti in cui la sicurezza richiesta sia particolarmente elevata è da preferire il Not-default permit e quindi le white-list, mentre in altri contesti potremmo anche accontentarci di questa "stupida" idea di implementare delle black-list.

2) Enumerare le entità maliziose (Enumerating Badness): questo punto può essere considerato un caso speciale del primo punto. Marcus sostiene che enumerare le entità maliziose di un sistema come virus, trojan, etc. sia un'idea alquanto stupida perché gli attacchi evolvono sempre e quindi sarà una continua rincorsa tra guardie e ladri. Senza considerare che enumerare le attività maliziose consiste nell'enumerare solo quelle conosciute escludendo quindi tutto il resto.
Marcus la inquadra come un caso particolare del default permit perché anche in questo caso il sistema avrà dei vincoli enumerati e qualunque altra operazione verrà permessa. Posiziona però questa idea al secondo posto come stupidità, vista la quantità di volte che questa (stupida) idea viene attuata.

Anche qui valgono le considerazioni che ho fatto nel punto precedente. Sì, in teoria un CTO dovrebbe conoscere a menadito la struttura tecnica che dirige e controlla, ma questo non avviene quasi mai e quasi mai ai dovuti livelli di dettaglio che permetterebbero di implementare meccanismi basati sulla definizione di "cosa il sistema può fare". E' quindi più facile (anche se magari meno sicuro) affidarsi ad attori e strumenti esterni, che essendo appunto tali non possono conoscere la struttura interna, e quindi forniscono unicamente degli strumenti basati sul concetto dell'enumerazione delle entità maliziose (ex: antivirus, IDS rules, etc.).

Penso che un ragionevole equilibrio di strumenti esterni basati appunto su tale concetto e una analisi delle problematiche interne e dei livelli di rischio, permetta al CTO di definire delle zone a diversi livelli di sicurezza e valutare caso per caso se gestire le situazioni con un approccio da enumerazione oppure con un approccio che definisce il comportamento consentito.

3) Penetra e sistema (Penetrate and Patch): non c'è molto da dire su questa terza stupida idea. Rincorrere i bachi, di sicurezza e non, sperando che prima o poi si esauriscano è secondo Marcus una strategia perdente. Bisognerebbe progettare e realizzare i sistemi in modo sicuro.

Concordo appieno con Marcus. Illudersi che la strategia del "penetra e sistema" renda il sistema più sicuro serve solo a tranquillizzare gli animi nel breve periodo. Potremmo dire che è quasi una strategia "Greedy". Il "Security by design" rimane comunque un must della sicurezza informatica e l'interesse che c'è nel Secure SDLC dimostra che forse sta cambiando la mentalità degli operatori del settore verso una sicurezza più progettuale.

4) Hacking è bello (Hacking is cool): Marcus sostiene che l'ethical hacking o l'hacking in generale non sia una buona idea. Anzi è proprio una stupida idea! Basare il proprio skill sulle conoscenze di hacking non è molto furbo per un security man, perché l'hacking si basa su vulnerabilità ed attacchi contestualizzati nel tempo, e che quindi inevitabilmente faranno sì che anche lo skill professionale abbia una durata temporale limitata. Quindi la ricetta di Marcus è quella di una buona ingegneria della sicurezza piuttosto che un approccio basato sull'hacking.

Giusto! E' bene spostare il focus dall'hacking all'ingegneria della sicurezza, in modo che i sistemi siano progettati in modo sicuro sin dall'inizio del ciclo di vita. Ma sostenere che l'hacking è un processo "criminale" mi sembra eccessivo. L'hacking fa parte della nostra cultura di security man e ci permette di avere un approccio a 360° sulla sicurezza informatica. Quindi, da una parte un approccio preventivo con una buona ingegneria del software e di sicurezza, dall'altra un approccio da ethical hacker che consente di comprendere le tecniche di attacco più diffuse per modellare meglio i pattern di attacco, le minacce, i rischi e i test di sicurezza da fare in un ciclo di vita sicuro.
Mi sembra che Marcus con questo punto voglia mettere per forza in contrasto la cultura hacking con la cultura dell'ingegneria della sicurezza. Ma chi ha detto che non possono coesistere?

5) Educare gli utenti (Educating Users): per Marcus educare gli utenti ha poco senso perché bisognerebbe continuare ad educarli in un processo continuo, simile al "Penetra e sistema", per ogni nuovo problema di sicurezza che dovesse sorgere. Marcus è fautore di una forma di auto-educazione degli utenti che, per non rimanere al di fuori del mercato, sarebbero costretti ad imparare.

L'educazione degli utenti alle problematiche di sicurezza è invece per me fondamentale per far sì che un problema di sicurezza venga percepito come tale. Si aumenta anche la consapevolezza degli utenti rendendoli anche più partecipi e quindi più interessati.

Quindi una buona educazione deve anche creare interesse e stimolare gli utenti a progredire da soli, ad andare avanti e ad essere loro stessi i loro migliori maestri. Su questo punto con Marcus non sono d'accordo quindi: l'educazione degli utenti è fondamentale e la differenza è nella qualità della formazione che si fa e nella capacità di coinvolgere gli utenti nel processo formativo.

Secondo me educare gli utenti non è mai una stupida idea.

6) Agire è meglio che aspettare (Action is Better Than Inaction): qui Marcus sostiene che piuttosto che fare qualche cosa di stupido subito, conviene aspettare e fare magari qualche cosa di più intelligente e produttivo poi. Aspettare conviene perché si ha modo di far sedimentare i problemi e reagire nel modo più opportuno, sostiene.

Devo dire che questa filosofia non mi è mai piaciuta: "siccome potrei sbagliare, preferisco rimanere fermo in modo che nessuno mi possa poi dire che ho sbagliato". E' quindi meglio non fare nulla piuttosto che sbagliare? Questa sì che mi sembra una stupida idea!

Sono convinto che "agire" in modo opportuno e sensato sia meglio che "attendere" che qualcuno ci risolva il problema o che si autorisolva. Comunque sono d'accordo con Marcus che non si debba avere la foga di implementare tutte le soluzioni che ci vengono prospettate come miracolose o risolutive dal commerciale di turno, ma che sia necessario vagliarle con attenzione e magari far sedimentare un po' la cosa.

Ora qualche considerazione finale:

In tutti questi punti Marcus ripete spesso questa domanda: "Se non ha funzionato fino ad ora perché dovrebbe farlo adesso?". Come se questa sua tesi dimostrasse che poiché quella stupida idea non ha portato a risultati fino ad ora, non lo farà mai.

Il fatto che una strategia non abbia pagato in passato, non vuol dire che in futuro non possa pagare. Tanto più che queste strategie si basano spesso sul fattore umano che è molto complesso da analizzare e capire fino in fondo e che richiederebbe delle conoscenze specifiche certo non di un Informatico.

Possibile poi che sia tutto bianco o nero in queste sue considerazioni? Che un'idea sia stupida o intelligente? Non è forse come e in quale misura quell'idea viene attuata e portata avanti?

Alla fine queste idee saranno stupide se attuate in modo rigido, lo saranno meno se applicate cum grano salis.

Aspetto i vostri commenti :-)