{"id":26884,"date":"2022-06-24T14:54:41","date_gmt":"2022-06-24T12:54:41","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?page_id=26884"},"modified":"2022-06-24T15:10:38","modified_gmt":"2022-06-24T13:10:38","slug":"the-eus-upcoming-cyber-resilience-act-should-set-new-rules-for-the-game","status":"publish","type":"page","link":"https:\/\/www.kaspersky.it\/blog\/the-eus-upcoming-cyber-resilience-act-should-set-new-rules-for-the-game\/","title":{"rendered":"L&#8217;imminente legge sulla resilienza informatica dell&#8217;UE dovrebbe stabilire le nuove regole del gioco"},"content":{"rendered":"<style>.c-wysiwyg blockquote{background: rgb(0 153 129 \/ 10%);}.c-wysiwyg blockquote p{font-style:normal} .img-big { width: 100vw!important; max-width: 66.875rem!important; left: 53%!important; position: relative; transform: translateX(-50%); }.accent{color: #00a88e; margin: 0;font-size:1.5rem;font-weight: 900;}.c-wysiwyg .accented-list li:before {top:1.15rem}.c-wysiwyg .accented-list li{margin-bottom:1.25rem}.c-wysiwyg hr+*{margin-top:2.5rem}.c-wysiwyg hr{border-bottom: 2px solid #00a88e; width: 120px;margin: 1rem 0 -1.25rem 0;}blockquote h5 { color: #00a88e; font-style: initial; } span.accented-quote { display: block; font-size: 60px; font-family: sans-serif; line-height: 20px; margin-top: 30px; margin-left: -3px; }@media(min-width: 40.6875rem){.accent{font-size:2rem}.c-wysiwyg .accented-list li:before {top:1.75rem}.c-wysiwyg hr{border-bottom: 2px solid #00a88e; width: 160px;}}.c-wysiwyg ol>li:before{left: -1.85rem; top: -0.25em; font-size: 2.875rem;}.c-wysiwyg ol>li{padding-left: 1rem;}span.footnotes { position: relative; display: inline-block; border-bottom: 1.5px dashed #333; line-height: 1em;transition: 0.5s; background: transparent; cursor: pointer; } span.note { position: absolute;line-height: 1.6em; width: 300px; opacity: 0; visibility: hidden; left: 0; top: 15px; transform: translateX(-50%); transition: 0.3s; background: white; padding: 15px 20px; box-shadow: 0px 3px 7px #ababab; border-radius: 3px; cursor: initial; } span.footnotes:hover { background: #ffffd5; } span.footnotes:hover .note { z-index:999;opacity: 1; visibility: visible; }@media(max-width:480px){span.note {position: fixed;left: 5px; top: 50vh;transform: translatey(-50%); width: 100vw;}}.c-wysiwyg .illustration-list { margin-left: 0; display: grid; grid-column-gap: 5vw; grid-template-areas: \"a a\" \"b c\" \"d e\"; } @media (max-width: 640px) { .illustration-list { grid-template-areas:\"a\" \"b\" \"c\" \"d\" \"e\" }  } .c-wysiwyg .illustration-list li { margin-bottom: 2em; } .illustration-list li:before { display: none; } .illustration-list span.accent { font-size: 1em; } .illustration-list img { width: 128px; }.desktop-banner {display:block!important} .mobile-banner{display:none!important} @media(max-width:768px){.desktop-banner {display: none!important} .mobile-banner{display: block!important}} .c-article__title:after { content: \"Pubblicato il 10 giugno 2022\"; font-size: 1.15rem; font-weight: 300; display: inline-block; border-left: 4px solid #009981; padding-left: 1rem; }<\/style>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"img-big aligncenter size-full wp-image-26886\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2022\/06\/24145028\/the-eus-upcoming-cyber-resilience-act-should-set-new-rules-for-the-game.jpg\" alt=\"\" width=\"1200\" height=\"800\" \/><\/p>\n<p><em>Riflessioni sugli elementi che i decisori dovrebbero prendere in considerazione per raggiungere effettivamente una maggiore sicurezza informatica nei prodotti e nei servizi digitali.<\/em><\/p>\n<p>Nel maggio 2022, la Commissione europea ha invitato tutte le parti interessate a condividere i propri contributi per l&#8217;imminente Cyber Resilience Act (CRA). Avendo individuato la necessit\u00e0 di rafforzare la sicurezza dei &#8220;prodotti e servizi digitali&#8221; moderni e avendo ravvisato la mancanza di incentivi &#8211; sia per i consumatori che per i produttori &#8211; a valutare la sicurezza di prodotti e servizi, la Commissione ha avviato una discussione pi\u00f9 ampia su una potenziale nuova serie di requisiti diretti di cybersecurity per &#8220;tutto ci\u00f2 che oggi \u00e8 un computer&#8221; (e non solo). Ci\u00f2 potrebbe rivoluzionare concretamente l&#8217;intero settore tecnologico al di l\u00e0 dei confini formali dell&#8217;UE, ma anche avere ulteriori implicazioni tecnologiche ed economiche.<\/p>\n<p>In questo articolo vorremmo suggerire alcuni quadri di riferimento per questa discussione e per il futuro CRA. Scopo principale \u00e8 quello di condividere le nostre prime riflessioni (dato l&#8217;attuale inizio anticipato del processo legislativo) derivanti dalla nostra vasta esperienza professionale in campo di cybersecurity. Di seguito ci concentreremo su sei idee principali; l&#8217;elenco completo di tutte le riflessioni \u00e8 disponibile nella presentazione completa fatta il mese scorso.<\/p>\n<p>Non esitate a contattarci per condividere il vostro feedback: saremo lieti di discuterne!<\/p>\n<h4><strong>#1 Adottare un approccio differenziato: i prodotti (hardware e software) e i servizi digitali richiedono una serie di requisiti di cybersecurity su misura, e devono essere presi attentamente in considerazione.<\/strong><\/h4>\n<p>Data l&#8217;intenzione di introdurre requisiti di cybersecurity per i prodotti digitali e i servizi accessori, ci\u00f2 che va considerato per prima cosa \u00e8 la necessit\u00e0 di mantenere un approccio attentamente differenziato per ogni sottoinsieme di tali prodotti, ossia <em>hardware, software, IoT<\/em> e servizi. \u00c8 necessario un approccio personalizzato per cogliere in modo realistico le specificit\u00e0 dell&#8217;uso di tali prodotti e, di conseguenza, i loro profili di rischio. In particolare, l&#8217;uso di servizi digitali non crea generalmente rischi diretti di compromissione della rete dei clienti o degli utenti finali, al contrario di quanto avviene con l&#8217;uso di prodotti digitali <em>on-premise<\/em>. In modo analogo, <em>software<\/em> e <em>hardware<\/em> sono prodotti con una &#8220;natura&#8221; e un&#8217;applicazione diverse.<\/p>\n<h4><strong>#2 Anche gli strumenti e le librerie <em>open source<\/em> utilizzati nei servizi critici dovrebbero essere presi in considerazione.<\/strong><\/h4>\n<p>La recente divulgazione di una serie di vulnerabilit\u00e0 in librerie <em>open source (log4j)<\/em> ha messo in evidenza la &#8220;vulnerabilit\u00e0 endemica&#8221; in tutta la rete Internet globale all&#8217;interno di prodotti <em>software<\/em> vecchi e nuovi, coinvolgendo cos\u00ec pi\u00f9 parti interessate nella comunit\u00e0 di sviluppo del <em>software<\/em>, nell&#8217;industria tecnologica e negli apparati governativi. Sebbene non sia stata sviluppata una soluzione universale per risolvere il problema, \u00e8 importante sollevare la questione della disponibilit\u00e0 e della sicurezza di strumenti e librerie <em>open source<\/em> cos\u00ec critici. Si spera che il futuro CRA impegni sotto questo punto di vista, in uno sforzo coordinato, tutta l&#8217;UE nonch\u00e9 i partner internazionali.<\/p>\n<h4><strong>#3 L&#8217;intero ciclo di vita dei prodotti digitali <em>on-premise<\/em> dovrebbe essere coperto da requisiti di <em>cybersecurity<\/em>, mentre i servizi richiedono un approccio diverso.<\/strong><\/h4>\n<p>Nell&#8217;analisi, di cui siamo coautori, sulle lacune politiche nel garantire la sicurezza della catena di approvvigionamento delle TLC (sviluppato con una comunit\u00e0 <em>multistakeholder<\/em> all&#8217;interno del Gruppo di lavoro 6 dell&#8217;Appello di Parigi), abbiamo sottolineato che &#8220;garantire la sicurezza dei prodotti e dei servizi TLC \u00e8 uno sforzo continuo, lungo tutto il ciclo di vita della distribuzione, per proteggere i clienti e gli utenti finali&#8221;. Questo non \u00e8 certo un concetto definitivo. A questo proposito, in particolare, concordiamo con i Paesi Bassi sul fatto che il CRA dovrebbe coprire l&#8217;intero ciclo di vita, ossia &#8220;dalla fase di progettazione fino alla dismissione e allo smaltimento&#8221;. Ma ci sono importanti sfumature.<\/p>\n<p>Primo: l&#8217;uso, la manutenzione, la disattivazione e lo smaltimento non sono gli stessi per i prodotti o per i servizi. In particolare, i servizi digitali (ad esempio, nel contesto dell&#8217;elaborazione in <em>cloud<\/em>) non sono soluzioni <em>on-premises<\/em>, il che significa che il cliente o l&#8217;utente finale non ha la completa propriet\u00e0 locale dei dati elaborati o del <em>software<\/em> e dell&#8217;<em>hardware <\/em>utilizzati. In secondo luogo, la maggior parte dei servizi digitali non pu\u00f2 essere completamente autonoma (ad eccezione di reti chiuse basate su <em>cloud<\/em> specificamente progettate): l&#8217;accesso da parte di terzi \u00e8 una caratteristica predefinita, il che significa che il produttore o il fornitore (una parte terza) svolge un ruolo nel garantire la sicurezza durante l&#8217;intero ciclo di vita.<\/p>\n<p>Questo porta chiaramente a diversi prodotti e servizi con diverse forme di relazione tra produttori\/fornitori e clienti\/utenti finali. Ad esempio, i requisiti di gestione delle vulnerabilit\u00e0 dovrebbero essere differenziati in particolare tra <em>software on-premise<\/em> e servizi <em>cloud<\/em>, per riflettere i diversi ruoli e responsabilit\u00e0 in materia. Nel caso di <em>software on-premises<\/em>, il cliente o il committente conosce meglio la propria infrastruttura e ha il pieno controllo di definire e controllare i requisiti di sicurezza; per questo motivo sarebbe il principale responsabile della gestione immediata delle <em>patch<\/em> e dovrebbe anche garantire che tutti i prodotti del perimetro funzionino con <em>software<\/em> o <em>hardware<\/em> aggiornati. Nel caso dei servizi <em>cloud<\/em>, la situazione \u00e8 diversa: \u00e8 il proprietario di un servizio <em>cloud<\/em> il principale responsabile dell&#8217;efficace <em>patch<\/em> dei suoi servizi e della mitigazione di eventuali vulnerabilit\u00e0, non il cliente.<\/p>\n<p>Ci auguriamo che questi diversi contesti, usi e forme di relazione, vengano presi in considerazione nel futuro CRA per sviluppare requisiti di <em>cybersecurity<\/em> su misura.<\/p>\n<h4><strong>#4 Gli incentivi per un comportamento pi\u00f9 orientato alla sicurezza dovrebbero essere forniti sia dal lato della domanda che da quello dell&#8217;offerta.<\/strong><\/h4>\n<p>Apprezziamo lo sforzo della Commissione di affrontare anche la mancanza di incentivi come prerequisito per una maggiore consapevolezza della sicurezza sia da parte dei consumatori e dei produttori. Nel rapporto analitico del Paris Call WG6 citato in precedenza, abbiamo sviluppato un elenco dettagliato e strutturato di incentivi chiave per stimolare un comportamento orientato alla sicurezza nel mercato. Gli incentivi economici &#8211; che comprendono la pressione dei clienti\/utenti finali, la pressione dei pari e la concorrenza con altri operatori &#8211; sono solo una parte della storia. Anche se gli incentivi possono essere specifici per il mercato e per il settore, l&#8217;intervento del governo si configura come indispensabile al fine di risolvere l&#8217;asimmetria informativa esistente (ne abbiamo scritto in un precedente blogpost) e la mancanza di incentivi.<\/p>\n<p>Cosa si pu\u00f2 fare, dunque? Etichettatura, valutazioni di conformit\u00e0 e certificazioni sono solo parte di un disegno pi\u00f9 grande. L&#8217;introduzione di un&#8217;etichettatura volontaria della sicurezza dei prodotti digitali \u00e8 una delle pratiche normative discusse anche dall&#8217;OCSE, dal Dialogo di Ginevra e negli Stati Uniti, dove l&#8217;Ordine Esecutivo del Presidente ha gi\u00e0 prescritto misure per i programmi di etichettatura dei prodotti di consumo <em>IoT<\/em> e dei <em>software<\/em> di cybersecurity. Il NIST statunitense ha persino proposto una bozza di criteri di base per l&#8217;etichettatura della cybersicurezza del <em>software<\/em> per i consumatori e ha sviluppato quattro categorie di attestazioni in base alle quali i consumatori possono ottenere maggiori informazioni sullo sviluppo sicuro del <em>software<\/em>, sulle pratiche di protezione dei dati e altro ancora. Nell&#8217;affrontare questo aspetto all&#8217;interno del CRA, riteniamo che si debbano considerare alcuni fattori chiave:<\/p>\n<ul>\n<li>\u00e8 fondamentale che il CRA, in quanto legislazione orizzontale, sia armonizzato e coerente con altre legislazioni &#8211; il Cybersecurity Act dell&#8217;UE, che ha gi\u00e0 imposto la creazione di una certificazione europea di cybersecurity. Nel definire i requisiti di cybersecurity, il CRA dovrebbe integrare il Cybersecurity Act, non sovrapporvisi.<\/li>\n<li>I moderni prodotti <em>software<\/em> sono multicomponenti e, nella progettazione di etichette\/valutazioni di conformit\u00e0, difficilmente possono funzionare criteri statici per <em>software<\/em> dinamici destinati ai consumatori, poich\u00e9 la conformit\u00e0 a tali criteri diventerebbe obsoleta abbastanza rapidamente. L&#8217;attenzione, quindi, dovrebbe essere spostata dalle valutazioni statiche alla valutazione dei processi e dei controlli. Per esempio, invece di un requisito di sicurezza per un prodotto software formulato come &#8220;non presenta vulnerabilit\u00e0&#8221;, sarebbe meglio &#8220;attiva controlli di gestione e divulgazione delle vulnerabilit\u00e0&#8221;.<\/li>\n<\/ul>\n<p>In un articolo separato, abbiamo scritto di pi\u00f9 sui fattori chiave per rendere efficace l&#8217;etichettatura del software per i consumatori.<\/p>\n<h4><strong>#5 Il divario esistente in materia di fine vita (EOL) deve essere affrontato.<\/strong><\/h4>\n<p>Numerose discussioni tra esperti nell&#8217;ambito del Dialogo di Ginevra, dell&#8217;OCSE e del rapporto analitico del Gruppo di lavoro Paris Call WG6 sulle lacune delle politiche in materia di sicurezza della catena di approvvigionamento delle TLC hanno messo in evidenza l&#8217;attuale divario tra la fine del ciclo di vita (EOL), ossia tra la fine del supporto alla sicurezza e la fine dell&#8217;utilizzo.<\/p>\n<p>Per affrontare il gap EOL, \u00e8 necessario un approccio personalizzato per i diversi prodotti (<em>software<\/em>, <em>hardware<\/em> o <em>IoT<\/em>). Alcune idee includono, ad esempio, la richiesta agli attori del lato dell&#8217;offerta di progettare e implementare politiche EOL chiare e trasparenti per i loro prodotti e servizi digitali, la pubblica dichiarazione circa la durata minima per la quale un prodotto verr\u00e0 fornito con aggiornamenti di sicurezza.<\/p>\n<h4><strong>#6 La cooperazione internazionale \u00e8 fondamentale per evitare la frammentazione degli standard e dei requisiti emergenti.<\/strong><\/h4>\n<p>La Commissione ha annunciato l&#8217;obiettivo di sviluppare modelli di cybersecurity al fine di &#8220;rafforzare la leadership dell&#8217;UE nella definizione di standard, definendo standard per i prodotti digitali e i servizi ausiliari che potrebbero servire come parametri di riferimento a livello globale&#8221;, in conformit\u00e0 con la strategia dell&#8217;UE per la standardizzazione (febbraio 2022). Dato l&#8217;importante ruolo che l&#8217;UE svolge a livello globale nello sviluppo di norme e nel perseguimento di valori nell&#8217;approccio alla regolamentazione della cybersecurity, chiediamo di sviluppare il dialogo con altri Paesi (e con i loro organismi di regolamentazione), gli organismi di standardizzazione, l&#8217;industria e la comunit\u00e0 tecnica in generale a livello internazionale.<\/p>\n<p>Se il CRA stabilisce requisiti diretti di cybersecurity per i moderni prodotti e servizi digitali, compresi gli IoT (fino a quando questi non saranno chiaramente esclusi dal campo di applicazione), non c&#8217;\u00e8 dubbio che la legislazione dell&#8217;UE avr\u00e0 un impatto sull&#8217;intero settore tecnologico, interessando un numero di produttori ben superiore a quelli registrati nell&#8217;UE. Ecco perch\u00e9 \u00e8 fondamentale garantire un dialogo internazionale continuo per evitare la frammentazione degli standard e dei requisiti emergenti. Raccomandazioni simili sono state formulate anche dall&#8217;OCSE come parte delle sei raccomandazioni di alto livello rivolte ai responsabili politici, cos\u00ec come dal Dialogo di Ginevra (durante il suo evento online con i rappresentanti dei governi, dell&#8217;industria, della ricerca e della comunit\u00e0 accademica).<\/p>\n<h4><strong>Conclusioni<\/strong><\/h4>\n<p>Sostenendo pienamente le intenzioni della Commissione Europea di stabilire requisiti diretti di cybersecurity per i moderni prodotti e servizi digitali, siamo ansiosi di vedere se un singolo atto legislativo sar\u00e0 in grado di coprire l&#8217;intero insieme di tali prodotti e servizi (<em>software<\/em>, <em>hardware<\/em>, IoT, servizi <em>cloud<\/em> [per tutti: sia industriali che consumer]). In ogni caso, l&#8217;avvio di una pi\u00f9 ampia discussione del settore sul futuro CRA \u00e8 un passo che arriva nel momento giusto, nonch\u00e9 molto apprezzato da parte dell&#8217;autorit\u00e0 di regolamentazione per portare maggiore sicurezza e protezione in una societ\u00e0 che si sta rapidamente digitalizzando.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Riflessioni sugli elementi che i decisori dovrebbero prendere in considerazione per raggiungere effettivamente una maggiore sicurezza informatica nei prodotti e nei servizi digitali. Nel maggio 2022, la Commissione europea ha<\/p>\n","protected":false},"author":2706,"featured_media":26886,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_acf_changed":false,"footnotes":""},"categories":[],"class_list":["post-26884","page","type-page","status-publish","has-post-thumbnail"],"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/the-eus-upcoming-cyber-resilience-act-should-set-new-rules-for-the-game\/"}],"acf":[],"banners":"","is_landing":true,"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/pages\/26884","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/2706"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=26884"}],"version-history":[{"count":13,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/pages\/26884\/revisions"}],"predecessor-version":[{"id":26900,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/pages\/26884\/revisions\/26900"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/26886"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=26884"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=26884"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}