Cyber Resilience Act (CRA) – Riflessione di un informatico ---------------------------------------------------------- Questa email è relativa alla nuova proposta di legge discussa in questi giorni da parte del parlamento Europeo. Mi sto in particolare riferendo al Cyber Resillienct Act, abbreviato in CRA. Sto scrivendo questa email in quanto, per come è scritto attualmente, rilevo nel CRA determinate problematiche che, da informatico, ed in particolare da cittadino facente parte dell'Unione Europea, mi sento in dovere di elencare. Le problematiche di cui sto parlando possono essere ricondotte a due particolari classi: - Classe I (Open-Source): la prima classe colpisce principalmente l'ecosistema dell'open source e potrebbe danneggiare l'esistenza di realtà critiche per lo sviluppo dell'unione europa. - Classe II (Richieste): la seconda classe di problematiche è relative alle richieste che vengono poste a chi sviluppa prodotti con elementi digitali. ---------- Per quanto riguarda la classe I, trovo le seguenti problematiche: - La restrizione alla distribuzione di "software incompleto" si basa su una concezione anacronistica dello sviluppo del software ed è in diretta opposizione con il modello di sviluppo ed evoluzione tecnologica dell'Open Source. - Nell'attuale disegno di legge, "fini commerciali" è definito come "fornire una piattaforma software tramite la quale il produttore possa monetizzare altri servizi" ma questo è il business model di quasi tutte le realtà Open Source, che quindi non sarebbero esenti dal disegno di legge, contrariamente a quanto indicato in un passaggio precedente. - L'articolo 16, sancisce che "chi applica modifiche sostanziali" ad un progetto, è considerato al pari dell'autore in termini di responsabilità. Questo è un forte disincentivo alla collaborazione da parte di terzi che contraddistingue tutti i progetti Open Source. Per queste ragioni, le organizzazioni dei più importanti progetti Open Source sarebbero costrette a chiudere i battenti e smettere di erogare i propri prodotti e servizi su tutto il territorio Europeo, con significative ripercussioni su tutte le realtà cyber Italiane ed Europee, che fanno ampio uso di componenti Open Source all'interno dei propri prodotti. In ultimo, il beneficio di utilizzare componenti Open Source per accelerare lo sviluppo dei progetti sarebbe invece mantenuto da tutte le realtà EXTRA-EU che avrebbero un notevole vantaggio competitivo. ---------- Per quanto riguarda la classe II, invece, trovo le seguenti problematiche: - Annex I, Essential cybersecurity requirements, parte 1.2 "Products with digital elements shall be delivered without any known exploitable vulnerabilities;" Questa tipologia di richiesta è, nella sua essenza, tecnicamente irraggiungibile dal mio punto di vista, in quanto i prodotti software/hardware si trovano in un costante ciclo tra scoperte di vulnerabilità e update di sicurezza. Capisco che si è utilizzato la prola "known" proprio per indicare il fatto che ci si vuole proteggere anche e solo rispetto al passato. Il problema qui è che definire una timeline precisa per tutte le entità coinvolte nella produzione di software può essere molto, molto difficile. Il problema non sta tanto nella richiesta in sé, ma nella totale assolutezza rispetto al "numero" di queste vulnerabilità, che devono essere zero, appunto. In altre parole, qualsiasi tipo di vulnerabilità, basta che può essere attaccata, e già è un problema, in quanto renderebbe non conformi al CRA. Migliorerei questo paragrafo introducendo una rispettiva analisi dei rischi, come del resto è già stato fatto in altri punti. Si potrebbe quindi scrivere una cosa del genere: "Products with digital elements shall be delivered without any known exploitable vulnerabilities in such a way that they ensure an appropriate level of cybersecurity based on the risks tha can be assessed by the producer of such products" - Annex I, Essential cybersecurity requirements, parte 1.f "protect the availability of essential functions, including the resilience against and mitigation of denial of service attacks;" Anche qui, si sta richiedendo in particolare di essere resilienti ad attacchi di tipo DDoS. Purtroppo questo non è sempre possibile, in quanto un attacco DDoS non sfrutta particolare vulnerabilità del servizio, quanto piuttosto sfrutta proprio il fatto che il servizio, per funzionare correttamente, deve svolgere determinate funzioni. La definizione stessa di attaccho DDoS è alquanto difficile da scrivere. I server di google ricevono talmente tante richieste: sono sempre e costantemente sotto attacco DDoS? No, è semplicemente che la loro utenza è enorme. La differenza dunque non è di natura tecnica (quante richieste ricevo), ma piuttosto di natura intenzionale (qual è l'intenzione dietro a queste richieste? sono malevoli oppure no?). E, come ben si sa, è assai diffiicle capire l'intenzione di una richiesta. Questo per dire che è molto difficile proteggersi in generale da questa tipologia di attacchi. L'assolutezza di questo punto nuovamente è un problema, perché poche realtà possono veramente dichiararsi di essere resilienti ad un attacco DDoS, forse nessuna lo può fare veramente. - Annex I, Essential cybersecurity requirements, parte 1.e "minimise their own negative impact on the availability of services provided by other devices or networks;" Questo punto è, tecnicamente parlando, impossibile da verificare. È un punto talmente ambiguo che non capisco che effetto potrebbe avere. Lo toglierei. - Annex I, Essential cybersecurity requirements, parte 2.2 "in relation to the risks posed to the products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates;" Il problema di questo punto è l'utilizzo delle parole "without delay". Molto spesso succede che per portare avanti una robusta campagna di protezione dei propri prodotti software e hardware, non tutte le vulnerabilità sono trattate nello stesso modo, in quanto la criticità delle varie vulnerabilità è diversa, e molto spesso serve del tempo per capire il miglior modo di risolvere una vulnerabilità, in quanto altrimenti un eventuale fix mal riuscito potrebbe, non solo non sistemare la vulnerabilità iniziale, ma potrebbe persino introdurne delle altre. Bisogna quindi stare attenti a richiedere tempistiche troppo veloci. Prendiamo la vulnerability disclosure policy utilizzata da Google: si contatta il vendor interessato e gli si danno 90 giorni per sistemare la vulnerabilità. Al fine di questo periodo si pubblicano alcuni dettagli (non necessariamente tutti, a seconda del livello di rischio) rispetto alla vulnerabilità per informare il pubblico. Questi sono solo alcuni dei punti che necessitano, dal mio punto di vista, di essere modificati. Come si può vedere da questi piccoli esempi, il problema del CRA è che sta cercando di regolamentare un mondo estremamente tecnico in modo fin troppo ambiguo. L'unica cosa non ambigua sono le sanzioni e alcune richieste sono tecnicamente impossibili da soddisfare del tutto. La conseguenza della combinazione tra forte ambiguità di richieste e forte precisione di sanzioni è che si sta dando un potere troppo grande, secondo me, a chi dovrà interpretare la regolamentazione per capire chi è conforme e chi no. Tecnicamente, nessuno sarà veramente conforme, almeno per come è scritto attualmente. ---------- Per finire, è chiaro che la sicurezza dei sistemi digitali deve essere controllata e regolata, come è controllata e regolata la sicurezza di altri oggetti della nostra vita quotidina. La domanda, come al solito, non è in ciò che si dovrebbe fare, ma in come lo si fa. In generale, sento una forte distanza tra le parole presenti in questa regolamentazione e la realtà che si sta cercando di regolamentare. Spero che in futuro le cose possano cambiare per rendere veramente più sicuro il futuro di tutti noi. In ultima analisi, chiedo personalmente di rivedere i punti menzionati prima, e di cercare di immettere in questa nuova regolamentazione un pochino di più della realtà che si sta cercando di regolamentare. Seguono riferimenti (in particolare le prime tre) - Commenti delle realtà Open al CRA: https://blog.opensource.org/the-ultimate-list-of-reactions-to-the-cyber-resilience-act/ - Overview sul CRA (inglese): https://berthub.eu/articles/posts/eu-cra-secure-coding-solution/ - Conseguenze del CRA (inglese): https://berthub.eu/articles/posts/eu-cra-practicalities/ - Panoramica sulla CRA: https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act Leonardo Tamiano Informatico Cittadino dell'Unione Europea