{"id":27424,"date":"2022-12-07T17:52:21","date_gmt":"2022-12-07T15:52:21","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=27424"},"modified":"2022-12-07T17:52:21","modified_gmt":"2022-12-07T15:52:21","slug":"updating-ot-infrastructure","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/updating-ot-infrastructure\/27424\/","title":{"rendered":"L’antidoto contro il conservatorismo tecnologico operativo"},"content":{"rendered":"

Lo dico spesso, ormai da anni: l\u2019antivirus \u00e8 morto<\/a>.<\/p>\n

Un\u2019affermazione del genere pu\u00f2 sembrare subito un po\u2019 strana, specie se espressa da chi \u00e8 sempre stato un promotore e sostenitore, fin dagli albori<\/a>, di tutto ci\u00f2 che riguardava virus e antivirus nei tardi anni ottanta<\/a> e all\u2019inizio dei novanta<\/a>. Ad ogni modo, se scavate un po\u2019 pi\u00f9 a fondo nell\u2019argomento antivirus (RIP) e consultate alcune fonti autorevoli nel campo (ormai passato a miglior vita), l\u2019affermazione diventer\u00e0 immediatamente piuttosto logica. Innanzitutto, \u201cgli antivirus\u201d si sono trasformati in soluzioni di protezione \u201ccontro ogni cosa\u201d; in secondo luogo, i virus \u2013 proprio perch\u00e9 esemplari particolari di un programma maligno \u2013 si sono estinti. O quasi.<\/em> Ed \u00e8 proprio la parola \u201cquasi\u201d, cos\u00ec apparentemente innocua, che causa ancora problemi alla cybersecurity ai giorni nostri \u2013 al backend dell\u2019anno 2022! Ed \u00e8 sempre la parola \u201cquasi\u201d alla base del nostro blog post di oggi\u2026<\/p>\n

Parliamo di virus. Quei pochi che sono ancora presenti nella lista rossa<\/a>: dove si trovano di questi tempi e che cosa stanno per fare? \u2026<\/p>\n

Ci risulta che tendano a risiedere in\u2026 uno dei sottocampi pi\u00f9 conservatori dell\u2019automazione industriale: quello della tecnologia operativa<\/a> (la cosiddetta OT, <\/em>da non confondersi con IT).<\/em> OT significa \u201d insieme di hardware e software che rileva e causa un cambiamento attraverso il monitoraggio diretto e \/ o il controllo delle attrezzature industriali, infrastrutture, processi ed eventi (- Wikipedia)\u201d. In sostanza, OT si riferisce a un ambiente di sistemi di controllo industriale (ICS<\/a>) \u2013 a volte anche chiamata \u201cIT nelle aree senza moquette\u201d. OT: sistemi di controllo specializzati in industrie, centrali elettriche, trasporti, settori delle utilities, nonch\u00e9 estrazione e lavorazione in altre industrie pesanti. Quindi \u201cs\u00ec\u201d: infrastrutture. \u201cS\u00ec\u201d: infrastrutture spesso critiche<\/em>. E ancora \u201cs\u00ec\u201d: all\u2019interno di infrastrutture industriali \u00a0critiche possiamo trovare proprio quei virus che credevamo morti ma che, in realt\u00e0, sono ancora vivi e vegeti. Circa il 3% dei cyber-incidenti<\/a> che coinvolgono computer OT in questi ultimi giorni sono causati da questo tipo di malware.<\/p>\n

Il motivo?<\/p>\n

In realt\u00e0 la risposta l\u2019abbiamo gi\u00e0 data sopra: l\u2019OT \u2013 o, meglio, la sua applicazione nell\u2019industria \u2013 \u00e8 molto conservatrice. Se dovessimo trovare un campo che crede fermamente nel vecchio assioma \u201cse non \u00e8 rotto, non aggiustarlo!\u201d, questo \u00e8 proprio il campo dell\u2019OT. L\u2019aspetto pi\u00f9 importante nell\u2019OT \u00e8 la stabilit\u00e0, non i fronzoli. Nuove versioni, upgrade\u2026 anche i semplici aggiornamenti <\/em>(software, ad esempio) vengono visti con scetticismo, se non scherno o addirittura paura! Comunque, la tecnologia operativa nei sistemi di controllo industriale \u00e8 caratterizzata, di solito, da vecchi computer scricchiolanti con\u2026 Windows 2000 (!), oltre ad una serie di altri software antiquati zeppi di vulnerabilit\u00e0 (vi sono anche dei buchi giganteschi nelle policy di sicurezza e una marea di altri terribili incubi per chi si occupa dell\u2019IT). Ritornando velocemente alla nostra definizione di \u201caree senza moquette\u201d: il kit IT in questi ambienti (parliamo, quindi, di uffici e non di reparti produttivi o altri impianti) \u00e8 stato da tempo vaccinato contro tutti i tipi di virus ed \u00e8 costantemente aggiornato, sottoposto ai corretti upgrade e revisioni, oltre ad essere completamente protetto grazie a moderne soluzioni di cybersecurity. Al contrario, in aree diverse, troviamo tutto l\u2019opposto: ecco perch\u00e9 i virus riescono a sopravvivere e proliferare.<\/p>\n

Date un\u2019occhiata alla Top 10 dei programmi malevoli pi\u00f9 diffusi appartenenti alla \u201cvecchia scuola\u201d che si possono trovare nei computer ICS nel 2022:<\/p>\n

\"\"<\/p>\n

Sality<\/a>! Virut<\/a>! Nimnul<\/a>!<\/p>\n

Quindi, cosa significa quello che vediamo nel grafico?<\/p>\n

Innanzitutto, <\/strong>lasciatemi dire che la percentuale sopra indicata si riferisce a una fase \u201cdormiente\u201d di questi virus \u201cvecchia maniera\u201d. Ma nel momento in cui riescono a uscire dai confini di un singolo sistema infetto e diffondersi nell\u2019intera rete possono causare un\u2019epidemia locale piuttosto seria. E invece di un trattamento completo, si fa ricorso al buon vecchio backup. Inoltre, l\u2019infezione pu\u00f2 coinvolgere non solo i computer ICS ma anche controllori a logica programmabile<\/a> (PLC). Per esempio, ben prima dell\u2019avvento di Blaster<\/a> (un virus proof-of-concept in grado di infettare il firmware di un PLC), il loader Sality era gi\u00e0 presente (beh, quasi: non nel firmware ma sotto forma di uno script nei file HTML dell\u2019interfaccia web).<\/p>\n

Quindi, ancora \u201cs\u00ec\u201d: Sality pu\u00f2 combinare un vero e proprio disastro nei processi di produzione automatizzati. E non \u00e8 tutto. Pu\u00f2 creare un guaio nella memoria grazie a un driver malevolo, e anche infettare i file delle applicazioni e della memoria, causando una potenziale avaria totale in un sistema di controllo industriale entro pochi giorni. E in caso di un\u2019infezione attiva, l\u2019intera rete pu\u00f2 crollare, in quanto Sality utilizza dal 2008 la comunicazione peer-to-peer per aggiornare la lista dei centri di controllo attivi. I produttori di ICS difficilmente avrebbero scritto i codici se avessero avuto in mente un ambiente di lavoro cos\u00ec potenzialmente aggressivo.<\/p>\n

In secondo luogo<\/strong>: 0,14% al mese. Lo so che non sembra significare granch\u00e9\u2026 ma questa percentuale indica migliaia di esempi di infrastrutture critiche nel mondo. E tutto ci\u00f2 \u00e8 un vero peccato: pensate solo come questo tipo di rischi potrebbe essere evitato in modo semplice e completo, con l\u2019ausilio di metodi basilari.<\/p>\n

Terzo<\/strong>: dato che la cybersicurezza delle industrie \u00e8 spesso un colabrodo, non ci meravigliamo di leggere notizie relative ad attacchi a questo tipo di aziende da altri tipi di malware \u2013 in particolare ransomware (per esempio: Snake vs Honda<\/a>).<\/p>\n

\u00c8 chiaro perch\u00e9 i team OT siano cos\u00ec conservatori: la cosa pi\u00f9 importante per loro \u00e8 che i processi industriali sui cui vigilano non vengano interrotti. Pertanto, aggiornamenti, upgrading e nuove tecnologie potrebbero creare interruzioni. Ma cosa dovremmo dire, invece, al riguardo degli stop dovuti ad attacchi di virus \u201cvecchia maniera\u201d, che hanno avuto successo solo perch\u00e9 non si \u00e8 aggiornati? Appunto, \u00e8 proprio questo il dilemma dei team OT. Di solito optano per non stare a passo con i tempi ed \u00e8 questa la ragione dei numeri del grafico.<\/p>\n

Ma sapete una cosa? Tale dilemma pu\u00f2 diventare un mero ricordo del passato con la nostra \u201cpillola\u201d\u2026<\/p>\n

In un mondo ideale, sarebbe necessario essere in grado di innovare, aggiornare ed effettuare gli upgrade dei i kit OT senza incorrere in alcun rischio per la continuit\u00e0 dei processi industriali. L\u2019anno scorso abbiamo brevettato un sistema che assicura proprio questo\u2026<\/p>\n

Ecco come funziona brevemente: prima di implementare qualcosa di nuovo nei processi che DEVONO continuare a funzionare, potete testarli con una simulazione del mondo reale, un supporto speciale che emula le funzioni industriali critiche.<\/p>\n

Il modello \u00e8 costituito da una configurazione della rete OT, che gira sullo stesso tipo di dispositivi utilizzati nel processo industriale (computer, PLC, sensori, attrezzature per la comunicazione, vari kit IoT) e li fa interagire tra loro per replicare la produzione o un altro processo industriale. Nel terminale di ingresso del modello si trova un campione del software testato, che inizia ad essere monitorato da una sandbox<\/a> che registra tutte le sue azioni, osserva le risposte dei nodi della rete, le modifiche delle loro performance, l\u2019accessibilit\u00e0 delle connessioni e molte altre caratteristiche. I dati cos\u00ec raccolti permettono di costruire un modello che descrive i rischi di un nuovo software e \u00a0che, a sua volta, permette di prendere delle decisioni consapevoli, come quella di introdurre o meno il nuovo software e ci\u00f2 di cui ha bisogno l\u2019OT per chiudere tutte le vulnerabilit\u00e0 scoperte.<\/p>\n

Aspettate, perch\u00e9 ora si fa ancora pi\u00f9 interessante\u2026<\/p>\n

Nel terminale di ingresso potete letteralmente testare qualsiasi cosa, non solo nuovi software e aggiornamenti da implementare. Per esempio, potete testare la resilienza contro programmi malevoli che aggirano i mezzi di protezione esterna e penetrano in una rete industriale protetta.<\/p>\n

Questo tipo di tecnologia pu\u00f2 avere un potenziale enorme nel campo assicurativo. Le compagnie di assicurazione sarebbero in grado di giudicare al meglio i cyber-rischi, calcolando i premi in maniera ancor pi\u00f9 accurata, mentre l\u2019assicurato non si troverebbe a pagare pi\u00f9 del dovuto senza una buona ragione. Inoltre, i produttori di attrezzature industriali sarebbero in grado di utilizzare i test di collaudo per la certificazione di software e hardware di sviluppatori terzi. Sviluppando ulteriormente tale concetto, questo tipo di schema si adatterebbe anche a centri di accreditamento specifici per l\u2019industria. Vi sono poi enormi potenziali per la ricerca nelle istituzioni educative!<\/p>\n

Ma per il momento ritorniamo al nostro sito produttivo\u2026<\/p>\n

Va da s\u00e9 che le emulazioni non possono riprodurre la gamma completa dei processi nelle reti OT con un\u2019accuratezza del 100%. Tuttavia, basandoci sul modello che abbiamo costruito grazie alla nostra vasta esperienza, possiamo gi\u00e0 sapere dove poterci aspettare delle \u201csorprese\u201d nel momento in cui installiamo un nuovo software. Soprattutto, possiamo controllare in modo affidabile la situazione anche con altri metodi \u2013 ad esempio con il nostro sistema di allerta rapido MLAD<\/a> (di cui ho gi\u00e0 scritto in dettaglio qui<\/a>), che pu\u00f2 individuare problemi in sezioni particolari di un\u2019operazione industriale basata su correlazioni dirette e anche indirette. Con ci\u00f2, milioni \u2013 se non miliardi \u2013 di dollari di perdite a causa di questo tipo di incidenti potrebbero essere evitate.<\/p>\n

Quindi cosa blocca i team OT dall\u2019adottare questo nostro modello di collaudo?<\/p>\n

Beh, forse finora \u2013 visto che sono cos\u00ec conservatori \u2013 non cercano attivamente soluzioni come la nostra in quanto non la considerano necessaria (!). Faremo del nostro meglio per promuovere la nostra tecnologia per salvare i milioni delle industrie naturalmente, ma nel frattempo vorrei aggiungere questo: il nostro modello di collaudo, sebbene complesso, si ripagherebbe da solo molto velocemente se venisse adottato da una grande organizzazione \/ infrastruttura industriale. E non si tratta di un abbonamento o qualcosa di simile: si acquista una volta ma salva la situazione (minimizzando rischi operativi, di legge e anche di reputazione) per anni senza investimenti extra. Ah, e c\u2019\u00e8 un\u2019altra cosa che salvaguarder\u00f2: i nervi del team OT\u2026 o la loro salute mentale.<\/p>\n","protected":false},"excerpt":{"rendered":"

Come proteggere e aggiornare l\u2019infrastruttura OT.<\/p>\n","protected":false},"author":13,"featured_media":27426,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2955,2956],"tags":[2104,2715,3239,3687,83],"class_list":{"0":"post-27424","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-ics","11":"tag-mlad","12":"tag-ot","13":"tag-tecnologia-operativa","14":"tag-virus"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/updating-ot-infrastructure\/27424\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/updating-ot-infrastructure\/24942\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/updating-ot-infrastructure\/20439\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/updating-ot-infrastructure\/10478\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/updating-ot-infrastructure\/27499\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/updating-ot-infrastructure\/25272\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/updating-ot-infrastructure\/25602\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/updating-ot-infrastructure\/28159\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/updating-ot-infrastructure\/34311\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/updating-ot-infrastructure\/46467\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/updating-ot-infrastructure\/19830\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/updating-ot-infrastructure\/20453\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/updating-ot-infrastructure\/29576\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/updating-ot-infrastructure\/33951\/"},{"hreflang":"nl","url":"https:\/\/www.kaspersky.nl\/blog\/updating-ot-infrastructure\/28791\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/updating-ot-infrastructure\/25628\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/updating-ot-infrastructure\/31318\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/updating-ot-infrastructure\/31027\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/ics\/","name":"ICS"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/27424","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=27424"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/27424\/revisions"}],"predecessor-version":[{"id":27428,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/27424\/revisions\/27428"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/27426"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=27424"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=27424"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=27424"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}