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…
