E adesso, ragazzi e ragazze, woo-hoo! Oggi \u00e8 uno di quei giorni in cui esultare sembra essere la cosa pi\u00f9 giusta da fare. WOO-HOO!!!<\/p>\n
Perch\u00e9, vi chiederete?<\/p>\n
Abbiamo lanciato ufficialmente un sistema operativo sicuro<\/a> per i dispositivi di rete, i sistemi di controllo industriali e l\u2019Internet delle Cose. Il sistema operativo \u00e8 stato concepito l\u201911 novembre; ecco perch\u00e9 lo chiamiamo con il nome in codice 11-11. \u00c8 stato un ciclo di sviluppo molto lungo: abbiamo lavorato al progetto per 14 anni e abbiamo anche realizzato una prova di presentazione del mondo reale<\/a>. Adesso il sistema operativo pu\u00f2 essere utilizzato dalle parti interessate in diverse situazioni.<\/p>\n Vi risparmio tutti i dettagli nerd al riguardo; per ulteriori informazioni tecnologiche, potete consultare questo link<\/a>. Preferisco focalizzarmi sulle cose che non sono state trattate in quel post, per questo motivo risponder\u00f2 ad alcune delle domande pi\u00f9 frequenti e sfater\u00f2 alcuni miti sul nostro nuovo sistema operativo.<\/p>\n Questa \u00e8 una delle domande pi\u00f9 gettonate. La risposta \u00e8 semplicissima e abbastanza chiara: questo non \u00e8 Linux<\/strong>. Non \u00e8 presente nemmeno una sequenza del codice di Linux. Abbiamo progettato il sistema operativo da zero, per diverse applicazioni e diversi scopi.<\/p>\n Ci\u00f2 che pi\u00f9 importa a Linux, a Windows, al sistema operativo mac e ad altri sistemi simili \u00e8 la compatibilit\u00e0<\/em> e l\u2019universalit\u00e0<\/em>. Gli sviluppatori fanno il loro meglio per diffondere le loro soluzioni, semplificando al massimo lo sviluppo delle app e dei servizi. Ma quando si tratta dei nostri destinatari (sviluppatori hardware, sistemi SCADA, Internet delle cose, ecc.) questo approccio \u00e8 un disastro: ci\u00f2 che pi\u00f9 importa \u00e8 la sicurezza<\/em>.<\/p>\n Per creare un ambiente sicuro, abbiamo bisogno di abilitare un Default Deny<\/a> globale nel processo e inserirlo in un microkernel. In parole povere, si tratta di un sistema che fa solo quello che gli viene ordinato e che non pu\u00f2 fare nient\u2019altro. Con i sistemi operativi tradizionali tutto questo \u00e8 impossibile.<\/p>\n Ad ogni modo, si possono creare meccanismi di sicurezza in un sistema gi\u00e0 funzionante. In sostanza, questa \u00e8 la nostra principale attivit\u00e0<\/a>. Quello che facciamo \u00e8 sufficiente per molte applicazioni. Ad ogni modo, con alcune applicazioni anche il pi\u00f9 piccolo rischio di cyberattacco rappresenta un disastro. Quando si deve garantire la sicurezza, dobbiamo creare qualcosa di nuovo. Qualcosa che sia sicuro fin dalla sua progettazione<\/em>.<\/p>\n Non diciamo di aver creato qualcosa di assolutamente nuovo. Ovviamente ci sono stati altri tentativi di creare un sistema operativo sicuro. A volte alcuni progetti hanno anche avuto successo, ma il costo per la loro realizzazione \u00e8 lo stesso per quella di un aeroplano (stranamente venivano utilizzati sistemi del genere negli aeroplani), quindi progetti simili non erano mai destinati a produrre attrezzature che si potessero applicare su larga scala.<\/p>\n Altri progetti<\/a> si limitavano al settore della ricerca accademica. In altre parole, alcune menti brillanti avrebbero costruito un microkernel e avrebbero festeggiato con champagne e tante conferenze. Nessun progetto ha mai raggiunto la fase della diffusione o della commercializzazione su larga scala. Ma un veicolo funzionante non finisce con un motore; pu\u00f2 funzionare senza le ruote, senza la sospensione e senza un\u2019infinit\u00e0 di altre cose.<\/p>\n Abbiamo deciso di progettare il sistema in modo tale che questo fosse importante in diversi ambiti, permettendo la personalizzazione a livello granulare basata sull\u2019applicazione. In poche parole abbiamo creato tre prodotti. Si tratta di: un sistema operativo (KOS), un hypervisor sicuro e autonomo (KSH) e un sistema per l\u2019interazione sicura tra i componenti del sistema operativo (KSS). Questi tre prodotti possono affrontare le sfide anche da soli, a seconda dell\u2019applicazione.<\/p>\n Ad esempio, SYSGO, un\u2019azienda tedesca, ha autorizzato<\/a> ad utilizzare KSS nel suo sistema operativo, PikeOS. Alcuni fornitori sono interessati solo nell\u2019hypervisor (KSH), che permette loro di avviare in maniera sicura le applicazioni esistenti senza modificarle. Ma per gli switch di Kraftway<\/a>, questo livello di integrazione non era sufficiente; per questo motivo hanno deciso di utilizzare il sistema operativo completo.<\/p>\n In altre parole, il vantaggio fondamentale del nostro sistema operativo \u00e8 la sua natura pratica e accessibile; \u00e8 stato creato appositamente e non \u00e8 stato pensato per situazioni generiche e ipotetiche.<\/p>\n Ovviamente, non appena abbiamo detto che il sistema era sicuro fin dalla sua progettazione, alcune persone hanno smentito questa nostra affermazione, non reputandola vera. Va benissimo: nel mondo della cybersicurezza non bisogna prendere tutto come oro colato.<\/p>\n L\u2019architettura del nostro sistema operativo si basa sul principio di divisione degli oggetti nel massimo numero di entit\u00e0 isolate. I clienti possono controllare il codice sorgente per assicurarsi del fatto che non ci siano funzionalit\u00e0 irregolari all\u2019interno del sistema. Tutto il resto viene configurato insieme al cliente sotto forma di diverse politiche di sicurezza pensate per controllare ogni piccola cosa.<\/p>\n Il sistema far\u00e0 solo le cose che voi volete che faccia. Quindi, i criminali non saranno in grado di approfittarsi nemmeno di un bug di un\u2019app creata per questo sistema operativo. Ovviamente potete scrivere un codice lunghissimo con tanti bug. Affinch\u00e9 il codice funzioni, deve per\u00f2 attenersi a politiche severe che definiscono cosa possa o non possa fare un codice.<\/p>\n Certo, perch\u00e9 il nostro sistema \u00e8 assolutamente flessibile! In generale, pu\u00f2 essere modificato ulteriormente affinch\u00e9 diventi un prodotto di massa, ma questo richiederebbe molto tempo e molte risorse. Al momento non abbiamo pensato a una cosa del genere e crediamo che la nostra soluzione sia un\u2019offerta per un mercato di nicchia.<\/p>\n Inoltre, ricordate che \u00e8 possibile importare i codici di terze parti nel nostro sistema operativo. La nostra soluzione include un hypervisor sicuro che permette ai clienti di avviare virtualmente qualsiasi sistema operativo come un sistema operativo ospite e le applicazioni personalizzate (come l\u2019avvio di Linux su un server Apache).<\/p>\n S\u00ec, se potessimo prendere questo server, dividerlo in tante parti e scrivere politiche su come queste interagiscono tra di loro, avremo un livello molto pi\u00f9 alto di sicurezza. Ma si tratta di tanto lavoro. Allo stesso tempo, tutto \u00e8 possibile se si ha coraggio e abbastanza risorse. \ud83d\ude42<\/p>\n Ecco perch\u00e9 abbiamo abilitato le applicazioni personalizzate nell\u2019hypervisor. S\u00ec, avremo un sistema operativo inizialmente sicuro con una personalizzazione inizialmente insicura. Tutto quello che avviene all\u2019interno di questa personalizzazione sar\u00e0 poco chiaro. Ma saremo in grado di controllare le sue interazioni con l\u2019hardware, le altre personalizzazioni e il mondo esterno. \u00c8 gi\u00e0 qualcosa. Con una configurazione del genere, scappare dal sandbox \u00e8 molto improbabile.<\/p>\n Il kernel non trasmette nulla da nessuna parte (tutto questo si pu\u00f2 verificare semplicemente dando un\u2019occhiata al codice sorgente (cfr. sopra). Il microkernel non ha praticamente nulla al suo interno. Tutti i driver sono isolati. Quindi per passare qualsiasi tipo di dato, bisogna scrivere un\u2019altra parte del codice. Si vedr\u00e0 chiaramente (non dovete nemmeno controllare il codice sorgente). Tutto questo \u00e8 scritto nelle politiche di sicurezza. E il cliente sar\u00e0 sempre in grado di controllare queste politiche, a prescindere dal codice. Qualora le politiche non contengano alcuna istruzione per inviare dati, il sistema non lo far\u00e0.<\/p>\n Sinceramente, non ho mai comprato occhi, quindi non sono abbastanza aggiornato sugli attuali prezzi di mercato. Al momento per\u00f2 quest\u2019affermazione \u00e8 abbastanza discutibile. Il nostro sistema operativo non \u00e8 un prodotto fuori dal comune; \u00e8 un\u2019offerta di progetto<\/em>.<\/p>\n Non stiamo vendendo una soluzione in scatola con dei rimedi per tutti. Al contrario, collaboriamo con fornitori e sviluppatori che forniscono attrezzature di rete, sistemi di automazione industriale, soluzioni automobilistiche e anche frigoriferi intelligenti. Forniamo il codice e aiutiamo a configurare il sistema in base alle loro richieste. Di conseguenza, il costo della soluzione dipende dall\u2019applicazione e dal lavoro che bisogna investire nel prodotto finale.<\/p>\n Sono d\u2019accordo, non esiste una risposta perfetta (tranne la numero 42<\/a>). Tutto pu\u00f2 succedere. Ad ogni modo, non c\u2019\u00e8 alcun motivo per arrendersi! La vera essenza della cybersicurezza \u00e8 rendere la vita dei cybercriminali il pi\u00f9 difficile possibile, facendo in modo che i cyberattacchi siano cos\u00ec costosi che diventino delle attivit\u00e0 non redditizie. A tal riguardo, il nostro sistema operativo \u00e8 molto avanti rispetto a tutta la concorrenza.<\/p>\nPerch\u00e9 avremmo bisogno di un altro Linux?<\/strong><\/h2>\n
Dai, un sistema operativo sicuro non \u00e8 una novit\u00e0! E allora?<\/strong><\/h3>\n
Come provereste il fatto che il sistema operativo consente il funzionamento solo delle operazioni della lista consentiti?<\/strong><\/h3>\n
Pensate sul serio che possa funzionare qualcosa su questo sistema operativo?<\/strong><\/h3>\n
Dai, raccoglier\u00e0 i dati ugualmente<\/strong><\/h3>\n
Ok, ma coster\u00e0 un occhio della testa<\/strong><\/h3>\n
Tutto pu\u00f2 essere hackerato e il vostro sistema operativo non \u00e8 un\u2019eccezione!<\/strong><\/h3>\n