Questa volta voglio scrivere un articolo riguardante l'informatica, E lo voglio scrivere perche' alla fine tutti i problemi che stiamo avendo con i social network  li stiamo avendo per lo stesso identico motivo, ovvero la mancanza di una cultura della sicurezza informatica. Vorrei sottolineare quanto catastrofica sia questa mancanza, puntando ad un caso reale.

Dopodiche' spieghero' cosa c'entri questo con i social network.

Il caso reale e' questo: https://eu.desmoinesregister.com/story/news/crime-and-courts/2019/09/19/iowa-state-senator-calls-oversight-committee-investigate-courthouse-break-ins-crime-polk-dallas/2374576001/

Succede che l'equivalente del ministro dell'interno vuole sapere quanto sicuri siano i sistemi dello stato. E siccome le elezioni presidenziali stanno arrivando (e avrete saputo quanto importante era il caso della Clinton che ha fottuto PER INTERO la sicurezza nazionale americana con la sua trovata geniale dei server in bagno) , la cosa e' importante.

Allora danno un incarico SCRITTO ad un'azienda di sicurezza, che esegue un "friendly hacking" . In questa operazione di pentesting, alcuni impiegati (convinti di agire in legittimita', dal momento che erano stati incaricati dal loro "bersaglio") sono riusciti ad entrare nei sistemi dello stato. Poiche' non hanno causato danni, chi si occupava di sicurezza si e' accorto degli attacchi e ha rintracciato gli attaccanti.

Non sto a dire chi sia stato piu' bravo, perche' si potrebbe discutere molto. Magari gli hacker non sono mai penetrati davvero nel sistema e sono finiti in un Honeypot (trappole piazzate apposta per attirare l'hacker) , oppure sono davvero penetrati e la security li ha presi solo perche' non hanno eliminato i log del loro passaggio.   Ci sono diversi modi di vedere la cosa, a seconda di cosa sia successo veramente. Ma non e' qui il punto.

Il punto e' che la reazione dell'ente aggredito e' stata quella di richiedere l'arresto e la persecuzione legale di coloro che hanno lavorato (si trattava di un'azione legittima) a penetrare le difese dello stato.

Se leggete le assurde argomentazioni di chi vuole il processo, noterete che ci sono alcune frasi terrificanti, comprese quelle tipo "non avreste dovuto lavorare cosi', ma avreste dovuto avvisarci prima".

Ma sappiamo bene cosa sarebbe successo se avessero avvisato prima. L' IT manager, che non vuole piantarci figure di merda, avrebbe ordinato di promuovere OGNI allarme a "Priorita' massima", ottenendo la chiamata ad uno specialista per OGNI anomalia rilevata. Nel caso di un sistema che faccia outlier detection (cioe' che si occupi di notare le anomalie), avrebbe ridotto al minimo la devianza standard richiesta per alzare un allarme, e ogni minima fluttuazione avrebbe causato una telefonata a tutto il team di operations, per tutta la notte.

Questo e' dovuo al fatto che gli impiegati pubblici lavorano con la stessa mentalita' in tutto il mondo: minimizzare il rischio di perdere la poltrona. Non importa fare un cattivo lavoro, non importa il fatto che questo lavoro di "friendly hacking" possa chiudere falle pericolosissime. Importa solo che nessuno dica "il tuo sistema era vulnerabile, hai fatto un cattivo lavoro".

Quindi no, la storia "questa cosa non adava fatta in maniera furtiva" e' una stronzata: e' come se durante le esercitazioni si chiedesse ai militari della GE di non disturbare i radar del bersaglio, dal momento che cosi' non riescono a difendersi, o peggio, di annunciare e pianificare l'attacco, in modo da non venire colti di sorpresa. Ma lo scopo di un attacco stealth e' proprio quello di prenderti di sorpresa, e l'esercitazione serve a capire se sia possibile, e se riesce bisogna capire cosa sia andato storto.

SI potrebbe liquidare la storia dicendo semplicemente "ma cosa credi , che gli hacker veri di Russia e CIna ti avviseranno prima di attaccare?". Ma, come ho gia' scritto, nel mondo dell'impiego pubblico il problema non e' mai quello di fare un buon lavoro: il problema e' di non essere quello che viene accusato di aver fatto un cattivo lavoro. Quindi chi se ne fotte di russi e cinesi e altri hacker.

La seconda frase che lascia terrificati e' "da ora in poi dire che avevate il contratto non vorra' piu' dire niente". Qui siamo al delirio. Un contratto e' valido o non valido: se un cliente mi chiama per assalire un sistema e mi paga per farlo, e' ovvio che l'intrusione non e' in conflitto con la sua volonta': mi sta dicendo che SE RIESCO ad entrare in casa sua non ha nulla in contrario, a patto che io gli dica come ho fatto.

Ma possiamo fare un pochino di reverse engineering di questa affermazione per capire dove vogliano portare: se lo stesso dipartimento attaccato avesse stipulato lo stesso contratto chiedendo di  attaccare i propri server, quasi sicuramente non avrebbero avuto nulla in contrario. Il problema qui e' che UN ALTRO dipartimento dello stato aveva pagato per farlo.

Quindi il tutto si traduce in : "gli altri dipartimenti dello stato devono farsi i cazzi loro". Ma che differenza ci sarebbe stata se gli hacker avessero avuto un contratto con il dipartimento che hanno assalito? La differenza sarebbe stata che il rapporto con le valutazioni tecniche sarebbe stato consegnato al manager IT , il cui dipartimento era vittima dell'attacco, e quindi lo stesso dirigente avrebbe potuto gestirlo , dandogli la pubblicita' voluta. Avrebbe reso pubblico il risultato se positivo, mentre avrebbe nascosto la polvere sotto il tappeto nel caso contrario: non importa che nel caso di brutte notizie avrebbe potuto comunque riparare le falle (motivo per cui si paga quel tipo di "attacco") , il punto e' che la logica e' quella del "i panni sporchi si lavano in casa".

Sia chiaro, ci sono anche manager di entita' private che ragionano cosi': per questa ragione i dipartimenti di "IT security" sono sempre isolati, emarginati e "tenuti sotto controllo". A meno che , nei piani alti, non si voglia fare davvero sicurezza.

Allora, mettetevi nei panni del solito dirigente IT "voglio una vita tranquilla", che ha autorizzato cattive pratiche pur di "non bloccare il progetto". Questo manager non fa una vita tranquilla e non dorme bene: dopo aver mandato in produzione (=su internet) servizi scritti col culo, pieni di workaround e fallati da decine di cattive pratiche, adesso vive nel terrore che gli hacker penetrino il sistema.  

Ma lui e' confidente di due cose, che lo aiutano a dormire:

  • Se sono VERI hacker, potra' dire che "nessun sistema e' 100% sicuro" e contare sul fatto che gli hacker sono visti come persone dai poteri magici , e non come individui che contano sulle cattive pratiche dei programmatori e dei sistemisti.
  • Se sono FINTI hacker (cioe' contractor assunti per questo), il manager colpito sa che internamente all'azienda ci sara' sempre un manager piu' in alto  che li giustifica e che gli dara' dell'incompetente. Ma , attenzione, puo' sempre rivolgersi ad un ente ottuso , indifferente e automatico. Potra', cioe', denunciarvi alla polizia.

Nel secondo caso, la denuncia gli serve per provare di "essersi accorto dell'intrusione", come se questa fosse un'attenuante. Certo, i delinquenti entrano in casa tua, ti picchiano, ti derubano, ti stuprano la moglie, certo che ti sei accorto dell'intrusione!!! (specialmente tua moglie)

Ma dire che "ti sei accorto dell'intrusione" non significa nulla: quando ti arriva addosso un aereo stealth, normalmente ti accorgi della bomba, giusto prima di morire. Ma il punto e' che e' troppo tardi, e dire "pero' me ne sono accorto" non significa NULLA. Avrebbe significato qualcosa se accorgersi dell'intrusione fosse servito a fermarla, o ad impedirla del tutto. Altrimenti, significa solo che sei rimasto impotente a guardare mentre i ladri ti stupravano la moglie di fronte agli occhi.(ma ICINGA  aveva un sacco di lucine rosse, eh).

In pratica, in questa vicenda vediamo solo una cosa: che la sicurezza come cultura e' molto lontana dall'essere accettata dal management di qualsiasi azienda. Questa carenza arriva in DUE fasi, piu' un seguito (aggravante se non criminoso):

  • Quando, per non "fermare" il progetto si autorizzano security exception e si scrivono requisiti irrealizzabili senza attenuare la sicurezza. Il prodotto deve andare live, e non ti puoi mettere di mezzo solo perche' qualcuno si chiama Robert DROP TABLE FBI;– (cit.)
  • Quando si dirigono servizi IT, e si nascondono dei data leak, si nascondono le intrusioni, e si intende lavorare non tanto per chiudere le falle, ma per nascondere la loro esistenza.
  • Quando, per aggirare il GDPR, si mantengono delle finte "vulnerabilita'" allo scopo preciso di offrirle (a pagamento) come accesso ai dati per "aziende di terze parti" che li pagano.

Il terzo punto ci conduce, direttamente, al punto dei grandi social network, che stanno simulando "attacchi hacker" per giustificare l'uscita di dati dalle loro reti, e non venire sanzionati a norma di GDPR.

Non so se lo avrete notato, ma da quando il GDPR si e' fatto strada , si sono moltiplicati i casi pubblici di "furto di dati da parte di hacker", "password salvate in chiaro ed esposte su internet" , "scoperta vulnerabilita' che ha permesso l'uscita di dati di milioni di persone".

Queste vulnerabilita' sono state, in gran parte, costruite ad hoc. Siccome il GDPR presume multe pesantissime per chi vende i vostri dati senza la vostra autorizzazione, ma non sanziona chi ha vulnerabilita' sfruttate dagli hacker, allora

I grandi player stanno costruendo finte vulnerabilita' nei loro sistemi.

Quando vogliono vendere i vostri dati, triangolano i soldi e poi danno al cliente che li ha comprati le istruzioni per accedere ai dati. Lo stesso fanno coi governi: dopo lo scandalo di snowden i grandi player si sono trovati nella posizione imbarazzante di giustificare che avevano consentito ai governi di  accedere ai dati per condurre spionaggio di massa.

Per liberarsi dal problema, la soluzione e' stata semplice: "facciamo finta che i dati ci vengano rubati contro la nostra volonta'".

Allora se il governo USA vuole i dati di un grande social network, non si fa piu' una linea dedicata e ufficiale che porta direttamente al database. Chiede al grande social network di costruire una finta vulnerabilita' , poi consegna allo stato americano le istruzioni su come usarla. Cosi', se per caso qualcuno si accorgesse del fatto che lo stato possiede quei dati, non faranno altro che dire "la bravissima NSA , dotata dei migliori hacker, e' penetrata nei nostri sistemi e ci ha preso i dati contro la nostra volonta': come possiamo fare qualcosa contro i maghi della NSA?". (per esempio, non lasciare le chiavi sotto il tappetino magico di casa?)

Lo stesso fanno con i privati: il GDPR vieta ai grandi social network di vendere i vostri dati, e lo sanziona se i dati vengono venduti. Ma non sanziona nessuno se ha un problema di sicurezza. Cosi', i grandi social network stanno costruendo VOLUTAMENTE delle falle alla sicurezza, per poi venderle ai clienti: quando un cliente vuole comprare i vostri dati, si limita a pagare con qualche mezzo indiretto , e in cambio riceve le istruzioni per usare una "falla alla sicurezza", che guarda caso verra' chiusa appena ha scaricato la quantita' pattuita di dati.

Se la quantita' e' molto grossa e temono che qualcuno possa incazzarsi, allora giocano d'anticipo e dichiarano alla stampa che "furto di dati da parte di hacker", "password salvate in chiaro ed esposte su internet" , "scoperta vulnerabilita' che ha permesso l'uscita di dati di milioni di persone", lavandosi le mani in vista del momento in cui qualcuno fara' dei male usando quei dati, e non si potra' nascondere che sono stati venduti rubati.

In definitiva, quindi, il GDPR ha costretto molte aziende a fare "privacy by design" (art.22) ma poiche' non sanziona il furto di dati da parte di "hacker", allora ha creato un mercato parallelo di finte vulnerabilita' con le quali vengono venduti i dati dei clienti che non avevano autorizzato la vendita.

E qui torniamo alla mentalita' della sicurezza: sino quando non verranno scritte leggi che proteggono gli attori legali (le aziende che fanno friendly hacking, i White hackers , etc) , non si potra' fare alcuna vera sicurezza. Se i programmi di bug bounty  sono ancora pochi e non consentono agli hacker di vivere del proprio lavoro, (tranne in pochissimi casi), queste finte vulnerabilita' costruite per vendere dati in nero non rappresentaranno un rischio.

L'unico rischio nel lasciare le chiavi sotto il tappetino di casa e' che le trovi qualcun altro. Il rischio che hanno i grandi social network quando creano queste finte vulnerabilita' e' proprio che qualche vero hacker possa usarle. Se depenalizziamo l'attivita' di bug bounty (la caccia alle vulnerabilita') , e diventa sempre possibile farlo, allora la cattiva pratica di costruire finte vulnerabilita' per aggirare il GDPR si fermera'.

Se qualcuno lascia la chiave di casa sotto il tappetino per  un complice allo scopo  simulare il furto, farsi pagare dall'assicurazione  ma tenersi i gioielli, un certo numero di finti ladri che vadano (a pagamento) in giro ad alzare i tappetini e' la sola maniera per fermare questa cattiva pratica.

Altrimenti, il GDPR e' gia' stato aggirato: il grande Social network di turno non fara' altro che creare una vulnerabilita' ad hoc per il cliente di turno, si fara' pagare in nero , e poi vendera' i vostri dati.

Se vogliamo chiudere questa falla, occorre decidere che se un hacker penetra un sistema ma non fa danni, e da' l'allarme PRIMA che un baco sia trovato, come si fa con le CVE, oppure  rende pubblico il baco  se niente cambia, dopo un tempo prefissato) , non e' punibile.

Altrimenti, i grandi social network continueranno a cedere i vostri dati a governi e aziende, creando volutamente delle vulnerabilita', e poi dando la colpa "agli hacker" evitando le sanzioni del GDPR. Come stanno gia' facendo oggi.

La sola differenza e' che la patetica scusa "e' stato un hacker", quando lo dice un grande social network, viene presa sul serio.