Sicurezza, ICT e altro

Prendo spunto da un post di Schneier su un articolo di InfoWorld su “dieci trabocchetti” in cui cadono le aziende. Quello che mi ha colpito sono stati i commenti: riflettono chiaramente quella che dovrebbe essere la discussione principale nel campo della sicurezza. Alcune posizioni “tipo”:

Reading that list I read: You can’t cure stupid.

Questa, mi dispiace dirlo, è la fin troppo frequente posizione del tecnologo che sembra credere che occuparsi di informatica lo abbia reso l’unica persona intelligente della terra (insieme a pochi altri eletti, tutti informatici). Su questo non dico altro. Più interessante è questa, comune a molti commentatori:

Some of the advice appears to be to hire something other than specimens of Homo Sapiens, and that’s going to be difficult. Humans do things in certain ways. Humans have continued to do things in certain ways despite all sorts of ranting and threatening. It is unsafe to assume that humans will suddenly change their ways to be convenient for corporate policy.

Quanto è vero. Quante politiche di sicurezza scritte nell’illusione che basti scrivere una regola su un foglio di carta per cambiare il modo di pensare e di agire delle persone (certo, ci sono cascato anch’io). Peraltro, non bisogna eccedere: si può arrivare all’estremo opposto, in cui qualsiasi cosa che sia di fastidio agli utenti non si può fare perché “poverini non gli possiamo mica chiedere…”. Ma se rendersi conto del fatto che determinate cose non sono realistiche aiuta ad evitare errori, non risolve però i problemi. Infine, c’è questo tipo di commento:

The problem is less that auto-complete leads to data breaches and more that auto-complete could be a lot better. I think something as simple as “highlight the background of contacts inside and outside the organization differently” would help mitigate this problem, maintain the current ease-of-use, and actually make it more useful.

Un esempio purtroppo ancora raro: si cerca di risolvere il problema in un modo per cui la sicurezza non aggiunge ostacoli e difficoltà, ma al contrario cerca di rendere più semplice l’attività dell’utente (se l’utente sbaglia spesso un’azione, la soluzione non è impedirgli l’azione ma aiutarlo a farla correttamente). Purtroppo questa posizione si scontra con uno dei problemi fondamentali della sicurezza, ovvero la “sicurezza dall’inizio”. Questo tipo di soluzioni richiede infatti spesso di cambiare qualcosa alla radice (in questo caso, si tratta di una modifica al software anziché alla configurazione). Questo al momento è nella maggior parte dei casi un mito: la sicurezza non viene aggiunta quasi mai dall’inizio per una serie di motivi di cui ho già parlato tante volte. E qui arriviamo ad un secondo post, questa volta di Spafford, che riassume alcuni concetti molto importanti legati alle soluzioni “di ripiego”. Con il boom della virtualizzazione di questi tempi, si cominciano a sentire anche le prime critiche ragionate. Una molto frequente  è che la virtualizzazione aggiunge un nuovo strato, quindi nuove vulnerabilità e consumo di risorse: sarebbe più corretto se certe cose (ottimizzare l’uso di risorse, segregazione, ecc.) le facesse il sistema operativo che è fatto apposta. Ebbene, questa è la frase fondamentale:

The similarity suggests that virtualization solutions compete with operating systems. I now believe that a part of their success must be because operating systems do not satisfy these needs well enough

Mi trova incondizionatamente d’accordo. È un’ottima cosa discutere di quale sarebbe la migliore soluzione di un problema (nello specifico, scrivere s.o. migliori). Altro è sconsigliare una soluzione esistente perché teoricamente la soluzione dovrebbe essere un’altra. Questa seconda è una posizione accettabile solo se chi la esprime si sente in grado di influire sullo sviluppo della soluzione corretta. Altrimenti, si tratta di chiacchiere accademiche, che non è corretto utilizzare quando si devono dare soluzioni a problemi reali e attuali. Dato che al momento i s.o. sono tutt’altro che “sicuri”, ci sono molte situazioni in cui la virtualizzazione aumenta la sicurezza complessiva.

E riguardo alla sicurezza dei sistemi operativi: la notizia del giorno è il “contest” nel quale è stato violato un Mac, poi Vista, mentre Ubuntu ha resistito. Io interpreto il risultato in modo abbastanza diverso da quanto sottinteso dalla maggior parte degli articoli che ho letto. Tutti e tre i s.o. hanno resistito agli attacchi da remoto. Va premesso che la capacità di un sistema di resistere agli attacchi dipende fondamentalmente dai servizi e dalle attività che il sistema è configurato per svolgere, e quindi nello specifico dalla configurazione che è stata sottoposta ad attacco; e non basta dire che tutti e tre (immagino) erano configurati per le stesse attività: ogni s.o. se la può cavare meglio per attività diverse. Il punto importante è però che se ben configurato, un sistema operativo recente e decente non è banale da attaccare. Se ci sono tanti attacchi da remoto, il problema non è avere nuove tecnologie ma l’utilizzo corretto di quelle esistenti. E naturalmente, si ripete il concetto che è più importante conoscere bene il sistema operativo che si utilizza, piuttosto che sceglierne uno “più sicuro”. Altra considerazione: anche in questo caso, come per quanto riguarda i server, il problema più grosso sono le applicazioni e non i sistemi operativi. A proposito di Flash, utilizzato per attaccare Vista e che a me sta particolarmente sullo stomaco: durante le ferie di Pasqua ho installato un nuovo modem ADSL a casa di mio padre… il programma di installazione del driver del modem richiedeva Flash installato… sì, per installare il driver di un modem. Non ho parole.

Infine, un commento all’articolo di Punto Informatico: non so se è stato un tentativo estremo di essere “politically correct”, una svista o un riferimento all’articolo sbagliato, ma l’articolo al quale si fa riferimento alla fine dice:

In the end, it was reported that some folks on hand had discovered bugs in the Linux OS, but many of them “didn’t want to put the work into developing the exploit code that would be required to win the contest.”

Non hanno voluto “metterci il lavoro necessario” per sviluppare l’exploit. Molto diverso da quanto riferisce Punto Informatico:

Nonostante i partecipanti avessero individuato alcune falle, nessuno pare abbia voluto infierire sviluppando un exploit in grado di sfruttarle: “Sono sorpresa che non sia stato assegnato” ha detto Terri Forslof, portavoce degli organizzatori. La spiegazione più accreditata è che gli hacker impegnati sulla piattaforma open source non abbiano voluto agire contro i loro colleghi per ragioni etiche.

Anche qui, dove si parla della “sorpresa” di Forslof, di “ragioni etiche” per non attaccare Linux non si parla. Mah…

Si è parlato molto di uno studio che ha mostrato come sia possibile recuperare dati da memorie RAM per un certo tempo dopo che non sono più alimentate. Un’applicazione di questa possibilità è stata recuperare le chiavi di cifratura dei dischi di un notebook appena spento, ad es. perché sottratto mentre era in standby. La notizia c’è e non c’è. La notizia vera naturalmente è che è possibile recuperare dati dalla RAM per tempi più lunghi e con strumenti più semplici di quanto ci si aspettava, in pratica sopravvivono a un reboot del sistema. Che poi una volta avuto accesso a questi dati, si riescano a superare i meccanismi di cifratura dei dischi, è una conseguenza al momento abbastanza ovvia.

Mi sembra quindi che ci siano due considerazioni interessanti. La prima è legata al TPM e a BitLocker: per essere completamente efficace, il TPM dovrebbe essere integrato nel processore, ed avere qui un’area di memoria in cui gestire le informazioni critiche come appunto la chiave di cifratura del disco. Da questo punto di vista ha ragione Intini, nel precisare che le indicazioni di Microsoft al riguardo sono chiare (è molto meno ovvio che queste informazioni arrivino all’utente, ma questo è un altro discorso). Naturalmente, se il TPM fosse integrato nel processore, continuerebbe ad essere attaccabile se si potesse attaccare internamente il processore, ma la difficoltà sarebbe, allo stato attuale delle (mie?) conoscenze, decisamente più elevata che attaccare un componente esterno. In effetti, il problema è noto e l’integrazione del TPM nei processori era prevista, anche se per quello che ne so è stata rinviata.

La seconda considerazione, anch’essa ben chiara nelle indicazioni di Microsoft, è che l’efficacia o meno di un meccanismo di sicurezza dipende dal modello delle minacce al quale si fa riferimento ed alle altre ipotesi fatte sul contesto. Spesso nei nostri modelli c’è tutta una serie di ipotesi implicite, delle quali ci rendiamo conto solo quando crollano. Nello specifico, l’ipotesi è che il pc venga attaccato quando è spento, e l’ipotesi implicita è che se il computer è spento i dati in RAM siano spariti. Se una delle due ipotesi non è verificata, il disco cifrato è attaccabile esattamente come lo è da parte di un trojan horse che avesse accesso al pc acceso con il disco montato.

Quello delle ipotesi implicite è un grosso problema, perché la disciplina della sicurezza ICT ne è piena: un po’ perché è una disciplina giovane e poco assestata, un po’ perché il settore è sempre in evoluzione e quindi modelli e ipotesi vengono definiti in tempi brevi, quindi con un rischio elevato di aver date troppe cose per scontate. Devo dire che mi ha stupito che Microsoft abbia una pagina su BitLocker così chiara al riguardo (mi avrebbe stupito quasi di chiunque).

Comunque sia, questo è un altro motivo per cui è sempre meglio avere ridondanza e difesa in profondità: perché un meccanismo che può sembrare ottimo può rivelarsi fallace da un giorno all’altro, quando ci si rende conto che una delle ipotesi su cui si basava è sbagliata. Va detto anche che per ora, se il problema del furto dei portatili fosse l’accesso ai dati cifrati di pc in standby, saremmo già messi bene: purtroppo invece per ora il problema sono i dati in chiaro. Un’altra considerazione è che per ora non è ancora il caso di fidarsi della “dimostrabilità” della sicurezza delle soluzioni, proprio perché, fra modelli delle minacce e ipotesi implicite, la probabilità che gli errori siano nelle ipotesi, anziché nelle conclusioni, è molto alta.