Cos'è l'attacco Local File Inclusion (LFI)

Chi si avvicina alla cyber security potrebbe essere disturbato dalle centinaia di termini non certo di uso comune che si troverà di fronte.

Se vi dico "attacco Local File Inclusion" sarà difficile capire di che si tratta solo dal nome, ecco quindi che provo a spiegarlo.

Local File Inclusion, anche abbreviato in LFI, è una vulnerabilità web dovuta ad errori di programmazione presenti nel sito o servizio web. La presenza di questo tipo di vulnerabilità consente all'attaccante di inserire nel sito dei file o applicazioni maligne che potranno essere eseguite successivamente sul sito stesso. Questo tipo di vulnerabilità non è molto comune ma può essere molto pericolosa e in alcuni casi può facilitare altri tipi di attacchi come il Cross Site Scripting o Remote Code Execution.

Ma ora cerchiamo di capire come funzione LFI.

Quando un'applicazione web non implementa adeguati controlli di sicurezza sulle richieste in ingresso, un utente malintenzionato potrebbe sfruttare questa vulnerabilità per passare come input un percorso di file locale o uno script malevolo attraverso una richiesta HTTP. Se l'applicazione non gestisce correttamente questa richiesta e include il file specificato dall'utente senza verificare la sua legittimità, si apre la porta a un attacco di Local File Inclusion. Una volta incluso il file, l'attaccante potrebbe ottenere informazioni sensibili, eseguire codice dannoso o compromettere il sistema. 

Se ci pensate si tratta di un attacco concettualmente simile alle SQL Injection di cui abbiamo parlato tante volte, però non sfrutta SQL come vettore ma HTTP e sfrutta input non adeguatamente validati o filtrati per eseguire azioni non autorizzate.

Come si può prevenire e mitigare questo tipo di attacco?

Esistono diversi metodi per prevenire questo tipo di attacco, vediamo i più comuni:

- Validazione dell'input: verificare che l'applicazione web validi e filtri correttamente gli input degli utenti, inclusi parametri URL, cookie e dati inviati tramite form;

- Limitazione dell'accesso ai file: impostare le autorizzazioni sui file e sulle directory in modo rigoroso, consentendo solo l'accesso necessario all'applicazione e riducendo al minimo i privilegi dei file sensibili;

- Utilizzo di percorsi assoluti anziché relativi: quando l'applicazione include file locali, utilizza percorsi assoluti anziché percorsi relativi. In questo modo, l'applicazione non dipende dal contesto in cui è stata richiamata;

- Whitelisting delle risorse: limitare le risorse che l'applicazione può includere tramite LFI utilizzando un elenco "whitelist";

- Utilizzo di framework e librerie sicure: utilizzare framework e librerie di sviluppo web sicure e aggiornate che integrino misure di sicurezza per prevenire le vulnerabilità più comuni;

- Monitoraggio e logging: implementare un robusto sistema di monitoraggio e logging per registrare le attività sospette o potenzialmente dannose.

- Formazione e consapevolezza: formare gli sviluppatori e il personale IT sulla sicurezza delle applicazioni web e sulle best practices aiuta alla prevenzione;

- Assegnazione di ID: memorizzare i percorsi dei file in un database sicuro e assegnare loro un ID univoco a ciascuno. In questo modo, gli utenti vedono solo l'ID e non hanno accesso diretto ai percorsi dei file, riducendo così il rischio di manipolazione da parte di un aggressore;

- Utilizzo di database: evitare di includere direttamente file sul server web che potrebbero essere compromessi e, invece, memorizzare i dati sensibili o le risorse in un database.

- configurazioni del server: configurare il server in modo che invii automaticamente intestazioni di download per i file anziché eseguirli direttamente nella directory specificata. Questo previene l'esecuzione accidentale di file potenzialmente dannosi e la perdita di dati.

Per finire, utilizzare un Web Application Firewall (WAF) può essere estremamente utile nella mitigazione degli attacchi di Local File Inclusion e in generale nella protezione delle applicazioni web da una grande varietà di minacce. In generale un buon WAF può contribuire a mitigare gli attacchi LFI grazie alle sue capacità di analisi e filtraggio delle richieste HTTP in ingresso, di validazione dell'input e di protezione dei file sensibili.

Implementando queste misure preventive e mantenendo costantemente aggiornate le difese dell'applicazione, è possibile ridurre significativamente il rischio di successo di un attacco di Local File Inclusion.

Qualche caso reale?

Ci si potrebbe aspettare che questo tipo di attacco sia recente, niente di più sbagliato!

Nel 2005 il worm Samy si diffuse su MySpace, una popolare piattaforma di social media, sfruttando una combinazione di cross-site scripting (XSS) e Local File Inclusion (LFI). Samy sfruttò un LFI per includere del codice JavaScript dannoso da un file locale, diffondendo così il malware tra gli utenti di MySpace.

Più recente l'attacco conosciuto come Panama Papers data leak, del 2016, dove sembra sia stata utilizzata una combinazione di diverse tecniche tra cui anche LFI. Con questo attacco furono esfiltrate 4,8 milioni di email, 3 milioni di record di DB e 2 milioni di file PDF., circa 20 volte il più famoso WikiLeaks.

Da allora sono diversi gli attacchi di una certa rilevanza messi in opera con tale tecnica e continuano ancora oggi.

Ecco perchè è così importante implementare controlli di sicurezza robusti per mitigare questo tipo di minaccia.

Alessandro Rugolo

Sitografia

- https://www.acunetix.com/blog/articles/local-file-inclusion-lfi/

- https://brightsec.com/blog/local-file-inclusion-lfi/

- https://www.hackers-arise.com/post/2018/08/01/confessions-of-a-professional-hacker-how-hackers-obtained-the-secrets-of-the-panama-paper

- https://www.hackingarticles.in/comprehensive-guide-to-local-file-inclusion/

- https://seerbox.it/white-paper/

- https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion

Meltdown: considerazioni sull'impatto sui sistemi classificati

Meltdown, un termine il cui significato è sinonimo di "disastroso collasso", oppure "catastrofe nucleare" è entrato nell'uso comune a causa dei problemi di sicurezza evidenziati su alcune tipologie di processori tra cui praticamente tutti i processori Intel, parte dei processori AMD e così via, realizzati dal 2010 ad oggi.

Sono veramente pochi i processori non colpiti da questa vulnerabilità (o da Spectre, per certi versi molto simile), tra questi buona parte degli ARM, gli SPARC e i Raspberry.

Ma di che si tratta? 

Cosa è realmente Meltdown?

E soprattutto, quale impatto può avere sui sistemi informatici ed in particolare sui sistemi classificati impiegati in ambiente militare?

Con questo articolo cercherò di fare un po di chiarezza su questa vulnerabilità e sul potenziale impatto nel mondo della sicurezza e, tanto per cominciare, è utile ribadire che la vulnerabilità è hardware e non software.

Questo fa un po la differenza rispetto a ciò che siamo abituati a sentire. In pratica, per fare un paragone con il mondo delle automobili, è come se in (quasi) tutte le auto del mondo si scoprisse che un particolare del motore per un difetto di progettazione sia soggetto a rottura, probabilmente in un caso del genere le case produttrici sarebbero costrette a ritirare dal mercato il modello incriminato e a risarcire il consumatore, oppure a richiamare in fabbrica le auto per una sostituzione gratuita del pezzo.

Con Meltdown questo non è avvenuto, forse perchè ancora non vi è una vera consapevolezza dei diritti del consumatore e forse perchè nonostante il clamore suscitato dalla notizia sono ancora troppo pochi coloro che sono in grado di capire la reale dimensione del problema.

In ogni caso ribadisco che Meltdown colpisce determinate famiglie di processori di diverse marche, indipendentemente dal Sistema Operativo che vi è installato sopra!

Ma in che cosa consiste il malfunzionamento?

Per capire come agisce Meltdown occorre sapere come funziona un sistema operativo, almeno nelle sue linee essenziali.

In primo luogo è utile dire che il compito principale di un sistema operativo consiste nel fornire una serie di servizi e garanzie di sicurezza affinchè i programmi che vi girano sopra si comportino come il progettista della sicurezza vuole. 

L'approccio progettuale alla sicurezza è particolarmente sentito per i sistemi militari o, più in generale, per sistemi che trattano informazioni che hanno un elevato valore.

Una delle caratteristiche principali dei Sistemi Operativi consiste nella sua capacità di garantire la "separazione della memoria" tra processi e utenti differenti in quanto ogni utente o processo deve poter accedere solo alla memoria che gli viene riservata.

I Sistemi Operativi moderni, affinchè siano impiegabili, anche allo scopo di sfruttare al massimo le caratteristiche delle CPU di nuova generazione, hanno introdotto alcune caratteristiche che velocizzano determinate operazioni, teoricamente senza diminuirne la sicurezza.

1. La prima di queste caratteristiche consiste nella possibilità di eseguire più processi in parallelo, ovvero di svolgere compiti differenti o a favore di utenti o programmi differenti dando loro l'impressione che siano gli unici a poter disporre di tutte le potenzialità del computer. Per fare ciò è necessario usare particolari tecniche di assegnazione della memoria che vanno sotto il nome di "virtual page memory".

2. Per evitare che utenti o processi potessero disturbarsi a vicenda e causare danni scrivendo dei dati in uno spazio di memoria già impiegato, magari proprio dal Sistema Operativo, è stato introdotto il concetto di "protection domain". In pratica il Sistema Operativo assegna ad ogni utente o processo un livello al quale è associata la possibilità di poter impiegare una certa area di memoria. Quando un processo cerca di accedere ad un'area di memoria per cui non è autorizzato generalmente viene "terminato".

3. La terza caratteristica legata alla architettura dei nuovi processori, normalmente dotati di più unità di calcolo, consiste nella possibilità di eseguire istruzioni o operazioni in parallelo o, in certi casi, di eseguire la stessa istruzione su valori diversi per velocizzare determinate operazioni. Si tratta di funzionalità conosciute come "instruction pipeline" e "speculative execution". Su ciò si basa il concetto di "Out-of-order execution" ovvero l'esecuzione di istruzioni di un programma non ancora necessarie ma che probabilmente dovranno essere eseguite.

4. Infine, per sfruttare l'enorme velocità di calcolo dei moderni processori sono state introdotte particolari tipi di memoria il cui accesso in scrittura e lettura avviene in tempi molto inferiori rispetto alla memoria presente in un hard disk normale. La presenza di queste memorie chiamate di "cache", associate all'analisi dei dati più utilizzati, consente al processore di non rimanere troppo spesso disoccupato in attesa che gli vengano forniti i dati necessari che si trovano nell'hard disk.

Bene, la questione è semplice. 

Se è vero che le caratteristiche suindicate sono state introdotte per sfruttare le caratteristiche dei nuovi processori, è altrettanto vero che quanto fatto ha aumentato non di poco la complessità dei sistemi e di conseguenza la possibilità di introdurre delle vulnerabilità non banali, ed è questo il caso di Meltdown.

Ora, occorre sapere che uno degli utenti del computer è il Sistema Operativo, esso è considerato "utente privilegiato" e può compiere particolari operazioni, non concesse ad un utente generico.

Meltdown permette di superare il concetto di "separazione della memoria", consentendo ad un processo o utente non autorizzato di venire a conoscenza dei dati presenti in spazi di memoria non propri sfruttando un tipo di attacco chiamato "side channel attack", in particolare un tipo di side channel attack chiamato "chache side channel attack" che consiste nel dedurre il contenuto della cache misurando i tempi di caricamento dei dati da parte di un altro processo in esecuzione. 

Meltdown riesce a fare ciò utilizzando a suo vantaggio le caratteristiche dei moderni processori a 64 bit viste sopra per raggiungere il suo obiettivo ovvero rubare i dati dall'area di memoria destinata ai processi del kernel del Sistema Operativo.

Dato lo scopo di questo articolo e la complessità dell'argomento non ha senso proseguire nella descrizione dei particolari di funzionamento di questo tipo di attacco, quanto piuttosto cercare di comprendere le implicazioni di sicurezza di questo attacco in relazione ai sistemi informatici militari.

Una prima considerazione va fatta sul concetto di verifica e certificazione dei sistemi.

Questo perchè, come spero sia ora chiaro, quasi tutti i processori in combinazione con i Sistemi Operativi più utilizzati risultano essere soggetti all'attacco Meltdown, tra questi vi sono anche i sistemi operativi Windows 7 client e windows server 2008 R2 a 64 bit, che se si va a vedere sul sito dei sistemi certificati Common Criteria sono certificati per l'uso nei sistemi classificati di buona parte delle nazioni del mondo.

Possibile che nel corso dei test nessuno abbia notato il comportamento insicuro dei sistemi?

Occorre forse ripensare alle modalità con cui i Centri di Validazione eseguono i test, forse troppo incentrati sul testare quanto dichiarato dalle case produttrici, senza indagare (molto) oltre?

Eppure vi sono chiare indicazioni di possibili problemi sulle architetture dei processori sin dal lontano 1995, ad opera della National Security Agency.

Una seconda considerazione riguarda invece la possibilità di applicazione di patch di sicurezza.

Non appena si è saputo di Meltdown, le principali case produttrici di software hanno cercato di porre rimedio attraverso modifiche software ai problemi architetturali dell'hardware.

Tra queste la Microsoft che ha immediatamente rilasciato la patch, ma con che risultato?

The hacker news in un articolo di qualche giorno fa ha pubblicato lo studio del ricercatore indipendente Ulf Frisk che ha mostrato come la patch abbia solo peggiorato la situazione, consentendo che il furto di dati ora sia ancora più veloce di quanto lo era senza l'applicazione della patch.

Questo è un altro punto da considerare con attenzione: l'applicazione di una patch, quando pure sia possibile (e non sempre lo è senza ricertificare il sistema!), potrebbe essere ancora più dannosa del lasciare le cose come stanno.

Ma allora come occorre comportarsi di fronte a problemi così profondamente insiti nell'architettura dei sistemi? 

Quali certezze, quali garanzie, ci possono dare sistemi militari che potenzialmente sono stati oggetto di attacchi simili a Meltdown per anni? 

Infatti conosciamo Meltdown pubblicamente dal luglio del 2017 ma non sappiamo se qualche organizzazione conoscesse e sfruttasse precedentemente questa vulnerabilità, potenzialmente insita nei processori di nuova generazione a partire dal 2010.

Non ho una risposta, ma solo un suggerimento: nel mondo attuale niente è più sicuro, forse perchè difficilmente una persona, anche preparata, è in grado di governare la complessità dei sistemi.

In ogni caso, trattandosi di sicurezza nazionale, forse sarebbe opportuno potenziare le strutture deputate all'analisi dei sistemi informatici e delle vulnerabilità, anche facendo ricorso alle Università, invece che fidarsi di quanto dichiarato dalle società produttrici di hardware e software.

Forse l'Intelligenza Artificiale potrà aiutarci... o forse, più probabilmente, complicherà ulteriormente il problema?

Alessandro RUGOLO

Per approfondire:
- https://meltdownattack.com/meltdown.pdf;
- https://thehackernews.com/2018/03/microsofts-meltdown-vulnerability.html;
- Cenni su processori INTEL: https://www.tomshw.it/differenze-i-processori-intel-75496;
- Cenni su processori ARM: https://www.ilsoftware.it/articoli.asp?tag=Differenza-tra-processori-ARM-e-x86_14683;
- Cenni sui processori SPARC: http://www.pcpedia.it/Il-Processore/ultrasparc.html;
- Cenni sui processori Raspberry: https://opensource.com/resources/raspberry-pi;
- https://www.commoncriteriaportal.org/

Novità sul fronte Cyber: pubblicato il DPCM 17 febbraio 2017

E' uscita di recente la nuova "direttiva recante indicazioni per la protezione cibernetica e la sicurezza informatica nazionali".

Occorreva una nuova norma?

Direi di si.

Vediamo di capire cosa c'è di nuovo e di fare alcune considerazioni personali di carattere generale.

La "Direttiva recante indirizzi per la protezione cibernetica e la sicurezza informatica nazionali" è ora Decreto della Presidenza del Consiglio dei Ministri, emanato il 17 febbraio 2017 e pubblicato in Gazzetta Ufficiale, serie generale nel numero 87 del 13 aprile 2017.

Quale è il suo scopo?

In primo luogo aggiornare la normativa preesistente risalente a quattro anni fa (DPCM 24 gennaio 2013), quindi "ricondurre a sistema e unitarietà le diverse competenze coinvolte nella gestione della situazione di crisi..." nel campo cyber, la cui mancanza (di unitarietà!) è evidentemente origine della difficoltà nel dare risposte ad un eventuale attacco informatico verso una o più infrastrutture critiche nazionali.

L'articolo 1 ci introduce all'argomento indicando l'oggetto della Direttiva (architettura istituzionale deputata alla tutela della sicurezza nazionale relativamente alle infrastrutture critiche materiali e immateriali...) e i principali soggetti  interessati (principalmente Ministero dello Sviluppo Economico, Agenzia per l'Italia Digitale, Ministero della Difesa e Ministero dell'Interno).

E' interessante l'articolo 2 in cui si raccolgono le definizioni più importanti per il campo cyber. Necessarie, senza ombra di dubbio, anche se non tutte personalmente condivisibili. Parlo in particolare della definizione di "spazio cibernetico" e delle conseguenze che questa può avere nella analisi del rischio cyber.
Iniziamo con la definizione del DPCM. 

"Spazio cibernetico: l'insieme delle infrastrutture informatiche interconnesse, comprensivo di hardware, software, dati e utenti, nonché delle relazioni logiche, comunque stabilite, tra di essi".

Ora prendiamo alcune delle definizioni di Cyberspace adottate dalle nazioni più avanzate nel settore: USA e RUSSIA.

- USA: The notional environment in which communication over computer networks occurs;

- RUSSIA: A sphere of activity within the information space, formed by a set of communication channels of the internet and other telecommunications networks, the technological infrastructure to ensure their functioning, and any form human activity on them (individual, organizational, state);

Queste definizioni sono tratte dal sito del NATO Cooperative Cyber Defence Centre of Excellence che si trova a Tallin, in Estonia (https://ccdcoe.org/cyber-definitions.html).

Ora, consideriamo la definizione della Russia: è facile notare che, oltre a parlare di rete internet e di canali di comunicazione, fa riferimento alle "infrastrutture tecnologiche che permettono il funzionamento delle reti di comunicazioni", infrastrutture non comprese né nella definizione USA né in quella italiana.
A mio parere la mancanza di questo riferimento potrebbe indurre in errore chi è interessato a sviluppare l'analisi del rischio cyber di una infrastruttura critica, per esempio inducendolo a non considerare la centrale elettrica che alimenta un data center critico.
Certamente questo è solo un banale esempio, ma a volte le banalità possono fare la differenza!

Altra definizione a mio parere incompleta è quella che parla di "evento cibernetico".
Secondo la direttiva un evento cibernetico è un "avvenimento significativo, di natura volontaria o accidentale, consistente nell'acquisizione e nel trasferimento indebiti di dati, nella loro modifica o distruzione illegittima, ovvero nel controllo indebito, danneggiamento, distruzione o blocco del regolare funzionamento delle reti e dei sistemi informativi o dei loro elementi costitutivi".

Anche in questo caso, a mio parere, manca qualcosa: come potremmo infatti inquadrare un evento come quello conosciuto col nome di "Stuxnet", con cui Stati Uniti e Israele (per quanto si sa) hanno sabotato la centrale nucleare iraniana di Natanz?
Il virus in questo caso ha danneggiato le centrifughe, ha cioè agito contro un elemento che non fa parte di alcuna rete informatica, eppure non si può non considerare tale evento come "attacco cyber".

Ecco due esempi che fanno capire l'importanza dell'adozione di idonea normativa e di corrette definizioni.E' chiaro che si tratta di punti di vista e che metterli in evidenza serve esclusivamente a creare consapevolezza e diffondere la conoscenza.
Per cui, benvenuto al DPCM che comunque fa chiarezza!

Ma andiamo oltre.

L'articolo 3 illustra i compiti attribuiti al Presidente del Consiglio dei Ministri, "responsabile della politica generale del Governo e vertice del Sistema di informazione per la sicurezza della Repubblica, ai fini della tutela della sicurezza nazionale anche nello spazio cibernetico".

Il Presidente del Consiglio si avvale del Comitato interministeriale per la sicurezza della Repubblica (CISR) per la definizione del quadro strategico nazionale per la sicurezza dello spazio cibernetico.

E' interessante, in questo contesto, il richiamo al quadro strategico nazionale che contiene le "tendenze evolutive delle minacce e delle vulnerabilità dei sistemi e delle reti di interesse nazionale, la definizione dei ruoli e dei compiti dei diversi soggetti, pubblici e privati, e di quelli nazionali operanti al di fuori del territorio del Paese, [..] strumenti e delle procedure con cui perseguire l'accrescimento della capacità del Paese di prevenzione e risposta rispetto ad eventi nello spazio cibernetico, anche in un'ottica di diffusione della cultura della sicurezza".

E' sempre il PCM (su delibera del CISR) che adotta il "Piano nazionale per la protezione cibernetica e la sicurezza informatica" contenente obiettivi e linee d'azione coerenti con il quadro strategico nazionale.

L'articolo 4 tratta del CISR, in particolare il comma f. recita: "esercita l'alta sorveglianza sull'attuazione del Piano nazionale per la sicurezza dello spazio cibernetico".

L'articolo 5 introduce il CISR tecnico, come organismo di supporto al CISR, presieduto del Direttore Generale del Dipartimento per le Informazione per la Sicurezza (DIS), e finalmente si entra nel vivo! E' proprio qui sta la grande novità infatti.

Le specifiche attribuzioni al DIS sono meglio specificate nell'articolo 6. Infatti

proprio il DIS, nella figura del suo direttore generale, viene individuato dal DPCM come colui che "adotta le iniziative idonee a definire le necessarie linee di azione di interesse generale".

Lo scopo delle linee d'azione è quello di "innalzare e migliorare i livelli di sicurezza dei sistemi e delle reti...", in previsione delle necessarie azioni di contrasto e risposta ad una eventuale "crisi cibernetica da parte delle amministrazioni ed enti pubblici e degli operatori privati...".

In pratica al DIS viene dato mandato di coordinare le azioni di contrasto e risposta ad attacchi cyber in Italia. Concetto chiaramente espresso nell'articolo 7 comma 2, in cui si dice che il Direttore del DIS cura il coordinamento delle attività di ricerca informativa finalizzate a rafforzare  la protezione cibernetica e la sicurezza informatica in Italia.

L'articolo 8 introduce il "nucleo per la sicurezza cibernetica", costituito permanentemente presso il DIS per gli aspetti di prevenzione e preparazione alle situazioni di crisi e "per l'attivazione delle procedure di allertamento". Tale nucleo è presieduto da un vice direttore generale del DIS ed è composto dal consigliere militare e dai rappresentanti di:

- DIS;

- AISE;

- AISI;

- Ministero degli affari esteri;

- Ministero dell'interno;

- Ministero della difesa;

- Ministero della giustizia;

- Ministero dello sviluppo economici;

- Ministero dell'economia e delle finanze;

- Dipartimento della protezione civile;

- Agenzia per l'Italia digitale;

- Ufficio centrale per la segretezza.

Il nucleo, a mente dell'articolo 9, svolge funzioni di "raccordo tra le diverse componenti dell'architettura istituzionale che intervengono a vario titolo nella materia della sicurezza cibernetica, in particolare mantiene attiva l'unità per l'allertamento e la risposta a situazioni di crisi, unità attiva h24, 7 giorni su 7.

L'articolo 10 stabilisce composizione e compiti del Nucleo in caso di emergenza cyber, con particolare riferimento al coordinamento che deve porre in essere per la reazione e stabilizzazione. Nel comma 3 si dice che si avvale, per le sue attività tecniche, del CERT nazionale del Ministero dello sviluppo economico e del CERT PA dell'Agenzia per l'Italia digitale. E in questo caso mi trovo perfettamente d'accordo sulla necessità di unire le forze (e le risorse)!

L'articolo 11 impone agli operatori privati una serie di regole. Tra queste vi è l'obbligo di comunicare "ogni significativa violazione della sicurezza e dell'integrità dei propri sistemi informatici" e l'obbligo di collaborare alla gestione delle crisi cibernetiche contribuendo al ripristino della funzionalità dei sistemi e delle reti da essi gestiti. Sulla denuncia delle violazioni probabilmente non avverrà niente di sostanziale in quanto non è definita in alcun modo la "significatività" di un evento cibernetico, ciò comporta che ognuno valuta come vuole, invece è molto importante il fatto che gli operatori privati debbano collaborare, anche mettendo a disposizione i "Security Operation Center" aziendali.

Sempre l'articolo 11, al comma 2, indica come competenza del Ministero dello Sviluppo Economico il promuovere "l'istituzione di un centro di valutazione e certificazione nazionale per la verifica delle condizioni di sicurezza e dell'assenza di vulnerabilità...", compito a mio parere più adatto al Ministero dell'Università e della Ricerca, sotto la supervisione del DIS.

Per finire, diamo uno sguardo all'articolo 13, disposizioni transitorie e finali.

Il comma 1 da una chiara idea di come il problema cyber sia sentito a livello governativo, infatti il comma 1 recita: "Dal presente decreto non derivano nuovi oneri a carico del bilancio dello Stato". 

Mi viene un dubbio: che sia tutto uno scherzo?

Non credo, infatti, che l'articolo 13, comma 1, sia compatibile con tutto quanto detto prima!

Alessandro RUGOLO

Immagine tratta da: https://www.sicurezzanazionale.gov.it/sisr.nsf/chi-siamo/organizzazione.html