Un mio conoscente lavora in uno studio di ingegneria civile, dove si occupano di progettazione: mi ha contattato di recente poiché nel loro ufficio hanno ricevuto un’email dalla società Autodesk in cui sono stati avvisati (ma il mio conoscente così come i suoi colleghi ne erano già al corrente!) che la versione di Autocad che stavano utilizzando su tutti i pc dello studio era sprovvista di regolare licenza (nel gergo tecnico ci si riferisce a software crackato).

Attraverso l’email, Autodesk ha “gentilmente” avanzato ai legali dello studio la richiesta di 15000€ per il tempo di utilizzo del software Autocad già trascorso e quello futuro, pena la disattivazione perenne da remoto del software (leggi blocco e impossibilità di ulteriore utilizzo delle varie copie di Autocad operative nello studio).

Mi è stato chiesto: ma Autodesk può farlo?
Tecnicamente, accettando le condizioni contrattuali durante l’installazione del software, di fatto si autorizza Autodesk a condurre verifiche da remoto (ed ho riferito al mio interlocutore che personalmente trovo il comportamento della software house più che lecito). Viceversa, se legalmente possano o non possano farlo, ossia bloccare da remoto un software privo di licenza comunicando quello che di fatto è stato un ultimatum, è una pastoia legale che lascio volentieri ai veri esperti in Diritto dell’Informatica (avvocati praticanti, o almeno si auspica) . Concludendo, al mio conoscente – ma soprattutto al suo responsabile che anni addietro decise di autorizzare le installazioni pirata – tecnicamente ho suggerito alcune dritte per evitare il blocco da remoto, ma non ho dato seguito alle modifiche sulle postazioni dello studio poiché personalmente sono assolutamente d’accordo con Autodesk: se il software che si decide di installare nasce come commerciale (da non confondere, quindi, con i gratuiti software muniti di regolare licenza FOSS), andrebbe regolarmente pagato, ergo acquistato, non crackato, così come andrebbero sempre remunerate le attività di manutenzione e/o le consulenze fatte da programmatori, sistemisti o esperti di sicurezza informatica di cui ci si avvale, a meno che questi signori non lavorino gratis per i propri committenti. Questa propensione (tremendamente italiana) ad avvalersi disoftware crackato è vergognosa e pericolosa, soprattutto perché molto spesso gli utilizzatori finali (architetti, ingegneri, progettisti meccanici o elettronici solo per citare il mondo Autocad) lavorano pressorinomati studi che possono eccome permettersi l’acquisto di qualche licenza software in più: quello che invece accade più o meno regolarmente, a mio avviso, è che in Italia molte aziende e tantissimi utenti decidono di non farlo, ossia scelgono anticipatamente di barare installando software pirata o (che dir si voglia) crackato con il beneplacito del tecnico informatico di turno, solo che questa gente dimentica che la malìzia non è una Virtù ma un vizio: e come tutti i vizi, prima o poi qualcuno viene a chiedere il conto ai trasgressori.

Pessima idea quella di usare software crackato in azienda (sotto diversi punti di vista: etici, legali ma soprattutto dal punto di vista della (in)sicurezza informatica) ma se proprio non puoi farne a meno, come minimo assicurati di installarlo e utilizzarlo all’interno di una VM isolata dalle altre postazioni della tua rete LAN, altrimenti la prossima rete hackerata da un ransomware potrebbe essere proprio la tua.

Un approfondimento sull’argomento.

A tratti unpopular opinion, ma fondamentalmente biasimo da nostalgico della disciplina che insegno da tempo e che continuo a praticare sia con vecchie che con nuove infastrutture informatiche, virtualizzate e non: l’amministrazione dei sistemi ICT, pane quotidiano di tutti i veri sysadmin.

Francamente penso che il mercato dell’Informatica da una parte si stia assuefacendo all’Automazione dei sistemi finalizzata alla riduzione dei costi (DevOps), dall’altra parte stia perdendo di vista il Santo Graal di tutti i sistemi informatici: la Disponibilità.

L’Automazione può rendere i sistemi più veloci ed economici riducendo l’elemento umano, ma un’operazione critica come quella di aggiornare un componente fortemente (troppo?) integrato nel sistema operativo andrebbe supervisionata: il recente disastro informatico legato al BSOD provocato da Falcon – l’agent software commercializzato dalla nota azienda CrowdStrike – è infatti la dimostrazione che anche i più blasonati operatori del settore commettono errori e possono provocare devastanti incidenti informatici, e almeno per ora, francamente non vedo un orizzonte rassicurante nemmeno per un futuro prossimo: non possono infatti testare alla perfezione ogni rilascio, per ogni possibile target, per ogni intricato scenario di utilizzo variabile (da più di qualche anno, ormai, ci si sono messi in mezzo sia il Cloud che il mondo IoT con i suoi firmware personalizzati spesso Insecure by Default).

La soluzione non è ovviamente quella di aspettare che i sistemisti abbiano il tempo di applicare gli aggiornamenti a mano, ma definire preventivamente procedure chiare e testate, e avere in squadra persone che sappiano eseguirle nei tempi e modi opportuni: cioè tempestivamente, ma non alla cieca. Ci devono essere precise fasi di STAGING ed esperti (ossia figure senior) che possano bloccare il passaggio in produzione prima che avvengano danni gravi…come quelli provocati da CrowdStrike.

Costoso? Ovviamente… e invece bloccare inaspettatamente voli intercontinentali e banche di mezzo mondo non ha avuto alcun impatto?

Obsoleto pensare a interventi manuali?
Già, proprio come quelli che sono stati necessari per ripristinare i sistemi coinvolti, secondo alcuni esperti addirittura per mesi.

Suggerimento: rileggere le due frasi precedenti immaginando che un episodio analogo colpisca, invece degli aeroporti (la foto sottostante ritrae i nastri trasportatori presso l’aeroporto “LaGuardia” di NYC durante l’incidente informatico del 20 luglio 2024), i sistemi di controllo di una rete idrica o elettrica, o impianti chimici, o i sistemi di sale operatorie o ancor peggio sistemi MILITARI.

Forse è utile riportare l’attenzione sulla Formazione, e relativamente al mercato del lavoro, coinvolgere chi realmente conosce e ha esperienza nella gestione delle infrastrutture o si è preparato alacremente per questo, non solo chi sa esclusivamente installarci sopra delle applicazioni solo perché costa meno sul libro paga.

Addendum:
tutti i media sono corsi a intervistare gli esperti di Cybersecurity più in voga (tutti esperti di kernel Windows, di puntatori a puntatori nonché di gestione della memoria heap a basso livello?!?🤔ma davvero?🤔) poiché così vanno le cose (anche in Italia), giacché se oggi un sistema informatico o una rete si interrompe, immediatamente il mainstream grida all’attacco informatico, tuttavia nel caso di CrowdStrike non si è trattato di questo.

Intendiamoci, c’è effettivamente di mezzo un’azienda (CrowdStrike) che di quello si occupa (e se non fosse un aspetto importante della vicenda, non insegnerei Cybersecurity e Sistemi operativi in contesti diversi, dai corsi professionalizzanti per diplomati ai master per neolaureati) ma focalizzarsi sul fatto che detta azienda si occupi di Cybersecurity fa perdere di vista il problema essenziale, ossia che si è trattato di un problema sistemistico, generato da un bug contenuto in un software proprietario commercializzato da un’azienda che sviluppa software per la Sicurezza Informatica, e la soluzione al problema, pur avendola tirata fuori dal cilindro i progettisti stessi di CrowdStrike, sulle reti in produzione l’hanno poi applicata dei sistemisti, non dei malware analyst né dei penetration tester.

Poi è interessante notare come la profezia in qualche modo si sia auto-avverata, con svariati attacchi informatici mascherati da soluzioni al problema… di nuovo facendo leva sul pretenzioso desiderio di Automazione perfetta.

A questo link è possibile consultare un recente articolo della stessa CrowdStrike per approfondire la soluzione della problematica che essi stessi hanno generato.

Concludo questo messaggio in bottiglia destinato a quei CISO e architetti di sistemi ICT che transitano da queste parti: incidenti informatici come questo invocano la necessità di ridefinire il concetto di HA (High Availability) studiato nelle Università; se i vari Domain Controller, server FTP, HTTP, SMB ecc.. fossero stati duplicati anche su sistemi Linux (quante sono le organizzazioni che continuano a investire ciecamente solo su Microsoft Windows quando invece molti dei medesimi servizi si possono erogare anche su Linux/Unix?), questo disastro informatico di portata globale si sarebbe potuto “banalmente” evitare con una migrazione temporanea verso i relativi sistemi Linux/Unix ridondati e aggiornati con i medesimi dati contenuti nei database Windows operativi fino a qualche minuto prima. La (Cyber)Security by Design (che oltre al codice andrebbe applicata anche alle architetture dei sistemi informativi) è tutt’altro che improvvisazione: non si può dunque improvvisare affidando il disegno e la gestione del proprio patrimonio informativo al primo ciarlatano o alla prima società di consulenza solo perché suggerita dall’amico dell’amico del collega del CISO tal dei tali (che magari non ha mai realmente seguito un corso né di (Cyber)Security by Design, né di Secure Coding né di Zero Trust Security), poiché prima o poi potrebbe ricapitare ciò che è già successo…e cadresti, come tanti altri/e, nel medesimo (o|e)rrore strutturale provocato dall’approccio ingenuo di chi ti ha evidentemente venduto incompetenza spacciata per Professionalità.

Riflettici.