Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Direttore responsabile Alessandro Longo

industry 4.0

Ma quale sicurezza “by default”, ecco i nuovi rischi per le PMI

di Claudio Telmon, ICT security adviser and consultant, Clusit

16 Giu 2017

16 giugno 2017

Una piccola azienda che cerchi di proteggersi o di essere conforme alle normative sul trattamento dei dati personali adotterà logiche di protezione “by default”, ma quelle stesse logiche non sono spesso adottate dai produttori di apparati, con la conseguenza che i sistemi adottati per proteggersi diventano vulnerabilità

Negli ultimi anni, l’attenzione verso le tematiche di cybersecurity è cresciuta enormemente. La sensibilizzazione passa, purtroppo, attraverso gli incidenti: il fenomeno del ransomware ha messo in evidenza a molte aziende la loro dipendenza dalle informazioni e dai sistemi informativi, e in generale eventi su scala nazionale o globale generano attenzione da parte della collettività e dei politici.

Ne risulta da una parte un aumento delle norme specifiche o che comunque considerano aspetti di cybersecurity, principalmente a livello europeo, dall’altra una maggiore disponibilità da parte delle aziende ad affrontare il tema, investendo almeno in una conformità non solo formale ai requisiti normativi. Anche a livello italiano, il cosiddetto Piano Calenda per l’Industry 4.0 prevede la cybersecurity (“Sicurezza durante le operazioni in rete e su sistemi aperti”) come una delle nove aree di tecnologie abilitanti. Si tratta di un passaggio importante: per quanto la protezione del perimetro aziendale rimanga nonostante tutto un cardine della sicurezza dei sistemi informativi, l’interazione con l’esterno attraverso questo perimetro è ormai tale che nessuna azienda e nessun sistema si può ormai considerare più isolato e quindi irraggiungibile da attacchi esterni.

Persino su uno dei fronti più ostici della cybersecurity, ovvero quello dell’individuazione e cattura dei cybercriminali, si vedono segni di miglioramento importanti, almeno quando l’attività criminale è evidentemente tale (più spinoso il tema degli attacchi supportati direttamente o indirettamente da stati sovrani).

In questo quadro complessivamente positivo di attenzione al tema della cybersecurity e di presa di coscienza (il primo passo per risolvere un problema riconoscere di averlo), permane però un’area grigia nella quale si nascondono problemi che possono rendere sostanzialmente inefficaci gli investimenti fatti finora e previsti per il futuro. È un problema chiaro da molti anni, ma è uno di quei temi dei quali non si parla, perché noti a tutti ma fastidiosamente difficili da affrontare.

Mi riferisco al problema della sicurezza nella supply chain, e in particolare nei prodotti hardware e software che installiamo nelle nostre aziende. Per capire l’entità del problema bastano due esempi recenti.

Il primo è l’attacco a Dyn[1] dell’ottobre dello scorso anno. Si è trattato dell’attacco di denial of service di maggiore entità fino a quel momento, che ha causato disservizi importanti negli Stati Uniti ed in Europa, bloccando servizi di aziende come Twitter, the Guardian, Netflix, Reddit, CNN e molte altre. L’attacco ha sfruttato la botnet Mirai, una rete di sistemi infettati da malware sotto il controllo di un unico “burattinaio”, che l’ha usata per generare una mole enorme di traffico verso i server di Dyn, bloccandoli e bloccando quindi tutti i sistemi che ne dipendevano. La particolarità di questo attacco, a parte le dimensioni (il traffico generato è stato dell’ordine del Terabit per secondo), sta nel fatto che i “sistemi infettati” erano migliaia di videocamere di sorveglianza e videoregistratori connessi ad internet[2]. Paradossalmente quindi, degli oggetti installati per sicurezza, che inquadrano aree critiche per aziende e privati cittadini, una volta connesse ad Internet diventano fonte di vulnerabilità. L’utilizzo all’interno di Mirai è il problema minore, quello più grave, a parte quello della privacy e sicurezza fisica, è che sono una testa di ponte nelle aziende e nelle reti domestiche in cui sono installate. La vulnerabilità di queste videocamere si riconduce al fatto che, come è ormai la norma, marchi e modelli diversi condividono in realtà spesso la stessa base hardware e firmware, prodotta in Cina. Il punto non è la produzione cinese, e neanche l’economicità dei componenti: il punto è la progettazione di questi componenti senza un’adeguata attenzione alla sicurezza. Consideriamo adesso il secondo esempio, più recente e relativo a componenti tutt’altro economici. Si tratta di una vulnerabilità di alcuni chip Intel[3] destinati specificamente ad aziende Small Business. La vulnerabilità è in una funzionalità di gestione remota dei sistemi, che può essere sfruttata senza che il sistema operativo o gli eventuali antivirus abbiano modo di rilevare quello che sta accadendo, perché si svolge appunto a livello di chipset. La vulnerabilità è presente in questi chip dal 2010.

Si tratta di due problemi apparentemente molto diversi: da una parte, componenti a basso costo inseriti in prodotti IoT che presentano vulnerabilità su “funzionalità” di cui l’utente non è neppure a conoscenza e per le quali spesso può fare poco[4]. Nel secondo, si tratta di funzionalità destinate ad una gestione da parte delle aziende, funzionalità di principio utili quando un sistema operativo non sta funzionando a dovere.

In realtà quello che accomuna i due problemi, da un punto di vista pratico, è molto più di quello che sembra. Consideriamo infatti una piccola azienda che cerchi di proteggere le proprie attività e le proprie informazioni, o anche solo che cerchi di essere conforme a normative come quella sul trattamento dei dati personali. Secondo quanto richiesto dal GDPR, adotterà logiche di protezione “by default”, minimizzando l’accesso ai dati personali, cercando di proteggere in modo adeguato i dati secondo logiche di gestione del rischio, e assicurando che anche i suoi fornitori siano conformi quando trattano dati personali di cui l’azienda è titolare… tutto questo però, può essere completamente vanificato dalla presenza di una videocamera o di un chipset vulnerabili esposti in rete. Il punto non è “non esporre in rete”: fra gli oggetti IoT vulnerabili spesso ci sono router SOHO, e chipset vulnerabili potrebbero essere presenti su sistemi utilizzati per implementare le stesse prote0zioni perimetrali. Il punto è invece che quelle stesse logiche di security by default richieste all’azienda non sono in generale adottate dai produttori di apparati, né è chiesto loro di farlo. Non vale neppure la pena, naturalmente, di considerarli fra i “fornitori” su cui la piccola azienda dovrebbe vigilare, è chiaro che sarebbe una posizione astratta ed irrealistica. Il punto è che nessuno richiede a questi soggetti di produrre sistemi progettati e realizzati secondo logiche di sicurezza by default. Naturalmente è possibile che Intel adotti questo tipo di logiche, ma nessuno le richiede di farlo.

Quando si parla però di richiedere ai produttori di hardware e software di dare delle garanzie sulla sicurezza di quanto vendono, sono sollevate sempre alcune obiezioni. La principale è che il software è complesso, e i grossi prodotti software sono quanto di più complesso sia mai stato realizzato, e che quindi escludere la presenza di vulnerabilità è impossibile. L’obiezione in sé è corretta, ma irrilevante. Anche alle aziende europee infatti, il GDPR non richiede di escludere la presenza di vulnerabilità sulle loro reti e sui loro sistemi: richiede di adottare logiche di valutazione del rischio e di buona progettazione per ridurne adeguatamente la probabilità. Se un’azienda abilitasse un accesso amministrativo da remoto ad una applicazione sviluppata in casa ad esempio, chiunque le richiederebbe di utilizzare meccanismi di autenticazione forte e di cifratura del traffico, e il software che implementasse questo accesso, almeno di principio, dovrebbe essere disegnato e verificato in modo da minimizzare la presenza e le conseguenze di una vulnerabilità. È paradossale che ad una piccola azienda venga richiesto questo sforzo per proteggere un singolo accesso, e non venga richiesto lo stesso sforzo a chi di accessi di questi accessi ne implementa migliaia o addirittura milioni.

La seconda obiezione generalmente riguarda il come imporre questi vincoli. Su questo, settori molto più ostici, come quello alimentare, hanno dimostrato che controlli sulla filiera, anche a livello internazionale, sono praticabili anche se imperfetti. Si tratta di operare almeno a livello europeo, introducendo vincoli man mano più stringenti nel corso degli anni, per evitare che siano disattesi. Anche perché, se possiamo immaginare produttori “alternativi” europei di videocamere, difficilmente possiamo immaginare alternative europee ad Intel. Si tratta evidentemente di un processo che dovrebbe durare molti anni, ma il tema è noto da almeno due decenni, e se si fosse affrontato da allora, probabilmente adesso saremmo già a buon punto. Soprattutto, prima o poi bisogna cominciare.

_____________________________________________________

[1] https://www.theguardian.com/technology/2016/oct/26/ddos-attack-dyn-mirai-botnet
[2] https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-massive-internet-outage/
[3] https://www.certnazionale.it/bollettini/2017/05/02/vulnerabilita-critica-nel-firmware-intel-management-engine-con-funzionalita-amt/
https://www.ssh.com/vulnerability/intel-amt/ fornisce anche i riferimenti alla descrizione dettagliata della vulnerabilità, https://www.embedi.com/files/white-papers/Silent-Bob-is-Silent.pdf
[4] https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/

Articoli correlati