Come scrivere di incidenti informatici

Un dibattito ispirato a questo articolo di Dave Lee, reporter della BBC, in cui si interroga su come fare giornalismo quando si parla di attacchi informatici. Vengono di seguito quotati alcuni passaggi per evidenziare i temi focali toccati:

"Cyberwar will be the defining story of our generation, but right now we’re dangerously unequipped to report on it accurately."

David menziona la Cyberwar, e l’analogia che viene alla mente è “la guerra”. Ma la natura astratta della cyberwar rende la comprensione della stessa molto difficile. In questo momento, chi è in guerra con chi? Anche chi dovesse ricevere un attacco informatico, come potrebbe identificare l’attaccante? E se io vengo attaccato, sono davvero l’obiettivo dell’attacco o un falso bersaglio, o vengo scelto per criteri che non conosco, a mio riguardo?

La prima differenza da approfondire è quella tra un attacco mirato ed un attacco massivo. Nella vita di un consulente di sicurezza informatica, spesso di viene chiamati a gestire incidenti da clienti preoccupati. Hanno scoperto che uno dei loro computer, che siano terminali usati in ufficio o server, sono stati compromessi. Pensano che l’attacco sia stato mirato: un concorrente? il governo? l’amico hacker dell’amante? (non sto inventando, è questo al quale si pensa quando si viene attaccati), ma la stragrande maggioranza degli attacchi non è mirata. Prende un po’ tutti. Chi lo giudica? in base a quali parametri? Questa è la prima domanda alla quale deve rispondere l’esperto. Senza comprendere il tipo di attacco, conoscere la sensibilità dei dati contenuti nella macchina, mancherebbero le informazioni necessarie a inquadrare il caso.

"In years gone by, when reporting on war, journalists have sometimes needed to be inventive in getting the news out."

In un contesto fisico, come la guerra, che più o meno è la stessa, è facile fare assunzioni, ipotesi e ottenere conclusioni. Qualcuno invade, qualcuno resiste, obiettivi vengono conquistati. Se questa competenza l’abbiamo appresa dalle ore di storia alle elementari, e poi approfondita negli anni, lo stesso non è ancora avvenuto con l’equivalente digitale. L’uso di un termine errato, come confondere un denial of service distribuito rispetto ad un denial of service basato su pochi pacchetti dati (e scommetto che qui i lettori stanno scuotendo la testa: scusate, ma è la differenza tra una manifestazione in cui qualcuno rompe i vetri di una banca, rispetto ad una macchina che il lunedì mattina lancia una mattonella e scappa), pregiudica l’intera comprensione delle motivazioni e delle risorse in gioco. E poichè non si può (ancora) pretendere che dei giornalisti abbiano questo livello di dettaglio, e lo sappiano comunicare ai lettori, l’effetto dell’improvvisazione è quello di venire bistrattati da un ambiente tecnologico (che pure fa fatica a comprendere quello che succede, perché fondamentalmente il 99% dei tecnici è ignorante in termini di sicurezza, e non ha stimoli a comprenderne il significato, nonostante la responsabilità delle debolezze sia proprio di quella categoria)

"There is a duty not to compromise the operations of the military, particularly when lives are at risk."

E qui, David Lee, tocca l’altro punto non ancora chiaro, ne per i reporter, ma neppure per i netizen. Il livello di interconnessione delle vite e dei servizi, causa che anche qualcosa di apparentemente insignificante, come il futuro delle credenziali di un sito di dating online, possano portare ad attaccare altre realtà. Compromettere un forum di dating online, può essere usato per attacchi di password reuse o di spear phishing su obiettivi sensibili. La persona che siete su facebook e su OKCupid, è la stessa che il giorno dopo, dallo stesso dispositivo, lavora sui dati del suo business. L’utente percepisce questa distinzione, magari è addestrato a particolari precauzioni sui dati del suo business, ma se l’attacco ha colpito quando le barriere psicologiche erano abbassate. L’attacco può quindi scalare su dati sensibili. A quel punto, è giusto spiegare la correlazione così da aumentare la sensibilità pubblica, o è meglio lasciare la notizia riservata, o non menzionare gli attori. E chi ci dice che l’attacco sia terminato lì, e non serva ad una prossima escalation ?

"But as history shows, governments on both sides of a conflict mostly do whatever they can to share as little as possible. And what they do share is often propaganda."

La propaganda è un grande rischio, del resto le informazioni digitali possono essere create ad arte per ingannare l’analista che arrivirà, o quantomeno per rendere le indagini più confuse. Chi fa le analisi stesse, potrebbe modificare la percezione, ma questo credo sia un rischio realizzabile solo quando l’istituzione ha chiaro cos’è successo, e può permettersi di modificare la percezione. Il rischio di divulgare propaganda quando non è chiaro l’avvenimento, è quello di un auto-goal imbarazzante. Pensiamo ai dataleak fatti per danneggiare l’immagine di un’azienda o di un’istituzione: come saranno stati fatti? da un insider? da un computer venduto come usato i quali dati non sono stati cancellati? da un attaccante con un piano o da un attaccante che ha avuto un colpo di fortuna? Mentire quando l’attaccante può ancora rilasciare rivelazioni che invalidino la tua dichiarazione è molto rischioso, per questo il comportamento che si vede è sminuire, tranquillizzare, dire che si è subito corso ai ripari…

"There are no sounds of gunshots to make it obvious something is happening."

"There are no soldiers on the ground that can be observed and asked: “Who do you work for?”

Quello che può essere riportato da un giornalista, dipende anche trasparenza con la quale la vittima divulga dettagli sull’attacco. In alcuni casi, questi dettagli sono implicitamente delle descrizioni di vulnerabilità, quindi non possono essere comunicati fino a quando la debolezza non viene corretta. Questo può richiedere poche ore o settimane. Un’altra opzione, indipendentemente dai dettagli sul tipo di attacco, è che la realtà vittima della compromissione faccia una valutazione dei dati sottratti, e comunitich conseguenze del caso peggiore. Parlo del caso peggiore perché ignorare la perdita di un dato è peggio che dover gestire l’incidente. Clienti e partner possono adeguarsi al rischio, e tenere a mente che le interazioni con altre realtà informatiche possono sempre essere manomesse. Per questo avere una procedura di recupero ed applicarla quando può esserci il bisogno, non fa male, e potrebbe portare a pratiche periodiche. Dobbiamo forse far capire che la responsabile disclosure non è una perdita di immagine, ma un gesto di civiltà verso una società interconnessa basata sulla fiducia.

Fare report di statistiche aggregate può essere una soluzione, ma prima del problema di divulgazione responsabile, esiste un grave problema di analisi dei propri dati, di controllo degli accessi e di rilevamento delle anomalie.