{"id":15557,"date":"2018-05-04T10:40:28","date_gmt":"2018-05-04T08:40:28","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=15557"},"modified":"2019-11-22T11:04:52","modified_gmt":"2019-11-22T09:04:52","slug":"rogue-one-analysis","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/rogue-one-analysis\/15557\/","title":{"rendered":"Rogue One e la cybersicurezza"},"content":{"rendered":"

L\u2019anno scorso abbiamo analizzato un incidente che si svolge in Star Wars: Episodio IV<\/a><\/em>. Avevamo comunque il presentimento che i problemi di sicurezza che hanno portato alla distruzione della Morte Nera fossero solo la punta dell\u2019iceberg. I problemi dell\u2019Impero con i sistemi per la protezione delle informazioni sono chiaramente di natura per lo pi\u00f9 galattica. Per fortuna, i ricercatori della Lucasfilm hanno analizzato a fondo gli eventi che hanno preceduto questo incidente e li spiegano tutti in Rogue One: A Star Wars Story<\/em>. Ecco cosa ne \u00e8 venuto fuori.<\/p>\n\n

\n<\/p>

La sicurezza inizia dalle Risorse Umane<\/h3>\n

Rogue One<\/em> si apre con il capo della divisione Ricerca Armi Avanzate dell\u2019Impero Galattico, Orson Krennic, accompagnato da un team di specialisti in Risorse Umane che convincono lo sviluppatore Galen Erso a lavorare al progetto della super arma segreta della Morte Nera. Cosa sappiamo di Erso? Innanzitutto, sappiamo che aveva lavorato in precedenza al progetto prima di rassegnare le sue dimissioni. In secondo luogo, non aveva alcuna fretta di ritornare. Ma le Risorse Umane Galattiche gli hanno fatto un\u2019offerta impossibile da rifiutare ed eccolo di ritorno. Successivamente Krennic scoprir\u00e0 che Erso era una spia industriale, colui che filtra il progetto della nave spaziale.<\/p>\n

Un dipendente di questo tipo non sarebbe mai dovuto venire in possesso di informazioni cos\u00ec sensibili (non avrebbero proprio dovuto assumerlo), un team di Risorse Umane se ne sarebbe dovuto accorgere durante il processo di selezione. E invece non sono riusciti a identificare i rischi. Inoltre, una formazione per tempo sui rischi alla sicurezza avrebbe aiutato a interpretare adeguatamente i campanelli di allarme durante il processo di analisi.<\/p>\n\n\n\n\n
Andrey Nikishin, \u00a0Special Projects Director, Future Technologies,\u00a0 Kaspersky Lab<\/b><\/td>\n<\/tr>\n
\"\"<\/td>\nSe pensate che si tratti di una situazione di fantasia, vi sbagliate. Il fattore umano e una formazione inadeguata in cybersicurezza sono le principali cause della maggior parte degli incidenti negli impianti industriali.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Laboratorio top-secret su Eadu<\/h3>\n

Galen Erso viene portato in un impianto di trasformazione di cristalli kyber sul pianeta Eadu, una sorta di gulag stile \u201cufficio di progettazione sperimentale<\/a>\u201c, dove \u00e8 obbligato a lavorare a un progetto militare top-secret. Come abbiamo detto in precedenza, affidargli un progetto segreto non \u00e8 stata una mossa intelligente, ma lasciarlo lavorare senza alcuna supervisione ha peggiorato la situazione. Erso decide cos\u00ec di inserire una vulnerabilit\u00e0 nella Morte Nera.<\/p>\n

Quando si tratta di progetti complessi, soprattutto se parliamo della progettazione di infrastrutture critiche, \u00e8 fondamentale analizzare pi\u00f9 volte il progetto degli impianti prima di passare alla loro costruzione. E bisogna tenere gli occhi ancora pi\u00f9 aperti se si ha a che fare con un dipendente sospetto e scontento.<\/p>\n\n\n\n\n
Andrey Nikishin, Special Projects Director, Future Technologies, Kaspersky Lab<\/b><\/td>\n<\/tr>\n
\"\"<\/td>\nSono sicuro al 100% che i nostri metodi moderni di sviluppo di software sicuri fossero noti agli sviluppatori galattici. Perch\u00e9 non li hanno adottati? Probabilmente per lo stesso motivo per cui non lo fanno certi sviluppatori del nostro mondo, la loro attenzione \u00e8 rivolta altrove. La Morte Nera \u00e8 il primo esempio di ci\u00f2 che potrebbe accadere quando non si presta attenzione a certi aspetti.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

La mancanza di assistenza in termini di sicurezza non \u00e8 nulla di nuovo. Ma l\u2019idea di isolare Erso, che non ha alcun contatto con il mondo esterno, ma che s\u00ec pu\u00f2 comunicare con i piloti dell\u2019Impero (arrivando addirittura a reclutarne uno), beh diciamo che \u00e8 davvero troppo.<\/p>\n

In sostanza, Erso riesce a:<\/p>\n

    \n
  1. Informare l\u2019Alleanza Ribelle dell\u2019esistenza della Morte Nera;<\/li>\n
  2. Specificare loro quale sia la sua vulnerabilit\u00e0;<\/li>\n
  3. Indicare l\u2019ubicazione del progetto sul pianeta Scarif.<\/li>\n<\/ol>\n

    Scarif<\/h3>\n

    Il centro dati di alta sicurezza \u00e8 progettato molto meglio della maggior parte delle altre infrastrutture dell\u2019Impero. Innanzitutto, Scarif \u00e8 circondato da un campo di forza grazie al quale non pu\u00f2 passare alcun oggetto fisico (che fa anche da firewall). \u00a0\u00c8 dotato di un solo punto di ingresso, controllato dal centro. I dati sono immagazzinati su hard disk offline (un air-gap di un certo livello), protetti da accesso biometrico. L\u2019antenna di trasmissione \u00e8 sconnessa dalla rete, \u00e8 necessario l\u2019accesso fisico a essa per attivarla.<\/p>\n

    Tuttavia, i meccanismi di protezione biometrici non sono l\u2019ideale.; in questo caso, l\u2019ostacolo viene superato prendendo \u201cin prestito\u201d la mano di un ufficiale morto, che viene avvicinata allo scanner. E il firewall non \u00e8 la panacea di tutti i mali: \u00e8 vero che blocca il trasferimento di grandi quantit\u00e0 di dati, ma pu\u00f2 essere aggirato rafforzando il segnale dei trasmettitori dell\u2019Alleanza Ribelle mediante sistemi di comunicazione interni. Inoltre, per connettere la nave al sistema non bisogna fare altro che collegare qualche cavo e tirare una leva, non c\u2019\u00e8 alcun sistema di autenticazione! L\u2019Alleanza Ribelle riesce cos\u00ec a lanciare un potente attacco DDoS dall\u2019orbita diretto al firewall.<\/p>\n

    E la cosa peggiore \u00e8 che la tanto importante antenna di trasmissione non \u00e8 affatto protetta. Basta inserire un dischetto e il gioco \u00e8 fatto! Davvero affidare tutto all\u2019impenetrabilit\u00e0 del firewall?<\/p>\n\n\n\n\n
    Andrey Nikishin, Special Projects Director, Future Technologies, Kaspersky Lab<\/b><\/td>\n<\/tr>\n
    \"\"<\/td>\n\u00c8 ci\u00f2 che accade pi\u00f9 o meno alle difese informatiche degli impianti industriali moderni. Tutto sembra ben organizzato fino a quando non viene richiesta una consulenza sulla sicurezza o viene progettato un threat model<\/em> e allora iniziano a saltar fuori semplici e potenti vettori di attacco. E gli attacchi nel nostro mondo non si limitano a fughe di dati, \u00a0le conseguenze possono essere irreparabili.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    L\u2019Internet delle Cose<\/h3>\n

    Una menzione speciale va fatta alla catastrofica situazione che riguarda la protezione dell\u2019Internet delle Cose. L\u2019Alleanza Ribelle utilizza una droide K-2SO riprogrammato\u00a0; e non \u00e8 una sorta di interprete o meccanico galattico, K-2SO \u00e8 un analista di fondamentale importanza e, a giudicare dal suo comportamenti, si tratta di un tentativo di hackeraggio ben riuscito. Tutto ci\u00f2 che c\u2019\u00e8 da sapere sui protocolli galattici \u00e8 immagazzinato nella memoria di questo droide, ma quale sistema operativo permette la riprogrammazione? E perch\u00e9 il sistema galattico pensa ancora che K-2SO abbia ancora un comportamento amichevole e autorizzi le comunicazioni con i computer? Come \u00e8 possibile che l\u2019Impero non sappia che il droide \u00e8 passato dall\u2019altra parte? Dopotutto, si tratta di un\u2019infrastruttura critica.<\/p>\n

    Come risultato della mancanza di sicurezza, K-2SO riesce tranquillamente a prendere dati da altri droidi, si connette all\u2019Archivio dell\u2019Impero alla ricerca di informazioni e prende il controllo dei meccanismi di difesa della stazione.<\/p>\n

    L\u2019Alto Comando Imperiale<\/h3>\n

    Le decisioni prese dai comandanti dell\u2019Impero che riguardano la sicurezza informatica meritano di essere analizzate in dettaglio.<\/p>\n

    Grand Moff Tarkin<\/h4>\n

    Tarkin impiega tattiche molto dure nella sua lotta alla fuga di informazioni. Praticamente distrugge intere citt\u00e0 se scopre una fuga di dati. Ad esempio, ordina di far distruggere la citt\u00e0 santa del pianeta Jedha quando viene a sapere da alcuni agenti della presenza di un disertore che sa della costruzione della Morte Nera. La seconda volta avviene a Scarif quando giunge la notizia dell\u2019attacco dell\u2019Alleanza Ribelle.<\/p>\n

    Orson Krennic<\/h4>\n

    A parte l\u2019incomprensibile ossessione di includere di nuovo Galen Erso nel progetto segreto, le decisioni prese da Krennic hanno una loro logica. Da un lato, prova a portare avanti delle indagini; quando arriva alla base di Scarif, ordina che vengano analizzati tutti i messaggi inviati da Galen Erso. Anche se si tratta di una decisione presa con un certo ritardo, ci\u00f2 avrebbe potuto aiutare a trovare la vulnerabilit\u00e0.<\/p>\n

    Ricordate anche che Krennic ha avuto la brillante idea di chiudere la base e di proteggerla durante l\u2019attacco dell\u2019Alleanza Ribelle, attivando il firewall in qualsiasi situazione.<\/p>\n\n\n\n\n
    Andrey Nikishin, Special Projects Director, Future Technologies, Kaspersky Lab<\/b><\/td>\n<\/tr>\n
    \"\"<\/td>\nDal mio punto di vista, Rogue One \u00e8 forse il miglior film dal nuovo capitolo della saga. Inoltre, fornisce abbastanza materiale per la formazione su tematiche della cybersicurezza di impianti industriali e infrastrutture critiche. Chi si occupa di queste tematiche dovrebbe guardare questo film, anche chi non \u00e8 fan di Star Wars. \u00c8 un manuale per un ipotetico corso su come NON proteggere le infrastrutture con informazioni sensibili\u201d.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"

    Manuale per un ipotetico corso su come non proteggere le infrastrutture con informazioni sensibili. <\/p>\n","protected":false},"author":700,"featured_media":15559,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2956],"tags":[2829,1205,2832,1424,2831,2827,2830,2828],"class_list":{"0":"post-15557","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-smb","9":"tag-death-star","10":"tag-fughe-di-dati","11":"tag-guerre-stellari","12":"tag-infrastrutture-critiche","13":"tag-la-morte-nera","14":"tag-mtfbwy","15":"tag-rogue-one","16":"tag-star-wars"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/rogue-one-analysis\/15557\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/rogue-one-analysis\/13244\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/rogue-one-analysis\/11046\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/rogue-one-analysis\/6035\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/rogue-one-analysis\/15316\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/rogue-one-analysis\/13594\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/rogue-one-analysis\/12924\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/rogue-one-analysis\/16001\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/rogue-one-analysis\/20503\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/rogue-one-analysis\/4899\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/rogue-one-analysis\/22273\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/rogue-one-analysis\/10380\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/rogue-one-analysis\/10264\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/rogue-one-analysis\/16561\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/rogue-one-analysis\/20308\/"},{"hreflang":"nl","url":"https:\/\/www.kaspersky.nl\/blog\/rogue-one-analysis\/23836\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/rogue-one-analysis\/20211\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/rogue-one-analysis\/20201\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/mtfbwy\/","name":"MTFBWY"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/15557","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\/700"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=15557"}],"version-history":[{"count":5,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/15557\/revisions"}],"predecessor-version":[{"id":18638,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/15557\/revisions\/18638"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/15559"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=15557"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=15557"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=15557"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}