Le aziende hanno qualche problema in più, specifico, messe di fronte ai pericoli causati dalle vulnerabilità Spectre e Meltdown. Sia perché i fronti di infezione sono diversi e più ampi, sia perché le aziende devono tenere conto di particolari accortezze anche quando valutano le soluzioni al problema. Se da una parte, infatti, per queste vulnerabilità corrono il rischio di furto di dati riservati, dall’altra se cercano di proteggersi in modo frettoloso possono subire danni alla produttività e al business.
Per questi motivi è importante analizzare nello specifico la questione dal punto di vista delle aziende.
VEDI LA SCHEDA CON LE INFO BASE PER TUTTI
I problemi specifici per le aziende
Oltre ai problemi in comune con gli utenti consumer (su computer e smartphone in particolare), le aziende fronteggiano due ulteriori scenari di rischio: i servizi in cloud utilizzati dall’aziende e i suoi desktop virtuali.
- Cloud: se ho dati in cloud su risorse condivise con altri utenti, uno di questi potrebbe sfruttare la vulnerabilità e così accedere ai dati presenti sugli altri sistemi che condividono la stessa macchina. Risorse condivise significa infatti che tutti i sistemi, di aziende diverse, usano lo stesso processore. Un criminale può utilizzare un programma malevolo che sfrutta le note vulnerabilità del processore e così colpire tutti i sistemi relativi.
- Desktop virtuali: la situazione è quella di un’azienda con diversi sistemi con desktop virtuali. Basta che solo un utente di questi venga infettato da un programma che sfrutta le note vulnerabilità perché siano a rischio i dati di tutti i desktop virtuali. Anche in questo caso infatti le risorse hardware sono condivise.
Meno concreto invece un altro rischio paventato: che siano infettati sistemi internet delle cose industriali, Nas, videocamere, sistemi di allarme. Anche i loro processori sono a rischio, è vero, ma sembra remota allo stato la possibilità che si possa fare eseguire un programma malevolo su questi (banalmente, questi apparati, come i server, non navigano su internet).
Soluzioni specifiche per le aziende
Il problema è grave, ma il gestirlo in contesti aziendali non è così banale: la semplice pubblicazione delle patch da parte dei produttori potrebbe non bastare per risolvere in tempi brevi.
L’azienda dovrebbe quindi monitorare gli aggiornamenti che arrivano per tutti i propri sistemi e apparati e poi valutarne l’installazione.
Bene che ci siano le patch, infatti, ma se aggiorno il browser di tutti i pc della mia organizzazione e di conseguenza smette di funzionare il mio CRM o gestionale (che di colpi diventa incompatibile con la nuova versione del browser), per prevenire un possibile attacco ho di fatto creato un danno di business ingente. Vale per i browser come per i sistemi operativi, il cui aggiornamento potrebbe rendere di colpo inutilizzabile un hardware aziendale, per esempio.
Se anziché pensare ai pc pensiamo ai server, immaginiamo se la patch smette di far funzionare un servizio su un server… di nuovo danno di business.
Astraiamo ancora di più: in contesto large enterprise magari server e desktop sono virtualizzati. Se metto una patch su sistema di virtualizzazione e smette di funzionare qualche decina di server?
Per tutte queste ragioni è importante che nelle aziende, nonostante la bagarre ed il rilievo mediatico del momento, vengano rispettate quelle che dovrebbero essere le normali procedure operative e policy per la gestione degli aggiornamenti, con l’applicazione in un contesto controllato (magari l’ambiente di test, di sviluppo, il pre-esercizio, l’ambiente per la formazione, o comunque ambienti non di produzione).
Bisogna assicurarsi la possibilità di fare roll back (cioè di tornare allo stato pre-patch) in caso di problemi.
Se io fossi una grande azienda con decine di migliaia di pc, forse preferirei correre il rischio che venga infettato un pc piuttosto che avere centinaia di utenti che non sono in grado di lavorare per “prevenzione”. Bisogna anche tenere conto che l’azienda si esporrebbe solo ai rischi connessi al rinvio di una patch; comunque può e deve contare su tutto il resto: firewall, antispam, antivirus, content filtering, ad-block, formazione agli utenti. Si consideri infine che si tratta di un attacco che non può essere eseguito da remoto direttamente (devo avere già il controllo del pc o necessito di interazione con l’utente).
Discorso a parte per il cloud; se parte dei miei servizi che gestiscono dati critici gira su servizi di terzi (penso ad Azure, AWS, GoogleAPP, ma potrei citare altri provider di IaaS o SaaS, penso alla media azienda che mi fornisce un servizio).
- Dobbiamo quindi accertarci che il nostro fornitore stia agendo per affrontare il problema. Può essere una questione critica con fornitori minori.
- Se il mio fornitore di CRM in the cloud o di gestione HR in the cloud ignora il problema e rubano i miei dati dalla sua infrastruttura, potrei avere delle responsabilità e di certo subire danni (anche solo di immagine). Allora bisogna sapere cosa prevede il contratto (il fornitore deve risolvere il problema? Il tutto è compreso nel servizio o comporta costi aggiuntivi? Entro quando deve farlo? Quali le sue e le mie responsabilità in caso di incidente?).
Purtroppo è un tema governato solo se gestito a monte. Cosa che non solo si consiglia di fare come best practice, ma che in ottica GDPR diventa indispensabile per il principio di accountability.
In conclusione
Come sempre, chi si era preoccupato di politiche, procedure, contratti, prima dell’emergenza ora sa cosa fare e riuscirà a limitare i danni facendo scelte ragionate e guidate da criteri oggettivi. Gli altri dovranno prendere decisioni strategiche sull’onda di situazioni stressanti, guidati dall’emotività e cercando di calmierare i danni, sperando di non farne di più gravi per eccesso di zelo, avventatezza.
