Politiche e sicurezza

White hackers: perché è importante proteggere chi segnala vulnerabilità informatiche

Il caso sulla vulnerabilità Log4Shell ha seguito il processo di divulgazione responsabile: di cosa si tratta, come funziona, come si stanno muovendo i paesi europei, la proposta della direttiva NIS, perché i white hackers sono spesso minacciati

07 Feb 2022
Carolina Polito

Ph.D. Candidate LUISS Guido Carli

I white hackers sono i ricercatori che scoprono la vulnerabilità di un software e/o di un sistema informatico. Spesso, quando decidono di segnalarla, devono affrontare minacce legali.

La divulgazione delle vulnerabilità è stata oggetto di un dibattito decennale nella comunità informatica. La difficoltà di questo processo è che deve essere gestito in modo coordinato tra il ricercatore e la società che presenta la vulnerabilità. Un’erronea condivisione con il pubblico dei dettagli di una vulnerabilità (ad esempio prima dello sviluppo della patch) è in grado di sottoporre il sistema a rischio di hackeraggio e chiaramente comportare conseguenze negative per gli utenti.

Per questo, tra direttiva NIS2, che approderà nel corso dell’anno al negoziato in Trilogo (Commissione, Parlamento e Consiglio Ue), prevede tra le proposte l’obbligo per gli Stati membri di stabilire una politica coordinata di divulgazione delle vulnerabilità.

Cyber sicurezza, cosa ci aspettiamo dal nuovo anno dopo un 2021 da “shock”

White hackers e il caso Log4Shell

Il 24 novembre 2021, il team di ricercatori di Alibaba informa l’Apache Software Foundation di una vulnerabilità nel sistema Apache Log4j, il tool di Apache per la gestione del log in ambiente Java (i.e. registrazione sequenziale e cronologica delle operazioni effettuale). Il 26 novembre, il MITRE, una no profit statunitense, nota per aver creato il database CVE per identificare, definire e catalogare le vulnerabilità, assegna alla vulnerabilità il numero identificativo CVE-2021-44228. Il 29 novembre Apache inizia a lavorare alla risoluzione dell’exploit e il 6 dicembre pubblica la prima patch. Tre giorni dopo, la vulnerabilità viene condivisa con il pubblico attraverso un tweet di un ricercatore del team di Alibaba.

WEBINAR
21 Maggio 2022 -
Finance e cyber minacce: come proteggersi davvero e affrontare gli scenari di crisi

La vulnerabilità, meglio nota con il nome di Log4Shell, è stata definita come “la vulnerabilità più critica dell’ultimo decennio ed ha costretto gli sviluppatori di numerosi prodotti software a rilasciare aggiornamenti o mitigazioni ai loro clienti. Il processo attraverso il quale questa vulnerabilità è stata trovata e divulgata al pubblico ha seguito il così detto processo di divulgazione responsabile.

In un’epoca in cui le vulnerabilità e la loro vendita sul mercato nero sono sempre più diffuse, si sono resi necessari processi decisionali per preservare lo stato di diritto online e responsabilizzare gli organi di governo in materia. I vari Stati membri dell’UE stanno quindi attualmente lavorando alla creazione di politiche nazionali per la divulgazione coordinata delle vulnerabilità (CVD).

White hackers: come funziona il Processo di Divulgazione Coordinata delle Vulnerabilità

Il processo di Divulgazione Coordinata delle Vulnerabilità (CVD) è definito nella norma ISO/IEC 29147: “La divulgazione delle vulnerabilità è un processo attraverso il quale i venditori e ricercatori possono collaborare per trovare soluzioni che riducano i rischi associati alle vulnerabilità di sistema. Questo processo include azioni come la segnalazione della vulnerabilità, il coordinamento e la pubblicazione di informazioni su un’exploit e sulla sua risoluzione.”

Gli obiettivi della divulgazione responsabile delle vulnerabilità includono:

i) garantire che le vulnerabilità identificate siano risolte;

ii) ridurre al minimo il rischio derivante dalle vulnerabilità;

iii) fornire agli utenti informazioni sufficienti per valutare i rischi derivanti dalle vulnerabilità dei loro sistemi.[2]

Alcuni ruoli sono fondamentali per il processo, in particolare:

  • Ricercatore: l’individuo o l’organizzazione che identifica la vulnerabilità,
  • Venditore: l’individuo o l’organizzazione che ha creato o mantiene il prodotto vulnerabile,
  • Distributore: l’individuo o l’organizzazione che deve distribuire una patch o intraprendere altre azioni correttive (spesso il vendor stesso),
  • Coordinatore: un individuo o un’organizzazione che facilita il processo di risposta coordinato (per esempio il CSIRTs nazionale).

Partendo dagli standard specificati nella ISO/IEC 30111 e considerando vari modelli di CVD, è possibile identificare le seguenti fasi del processo CVD:[3]

  • Scoperta: Uno o più ricercatori scoprono una vulnerabilità utilizzando una delle metodologie disponibili.
  • Reporting: Il ricercatore presenta un report sulle vulnerabilità al vendor o, se il vendor non risponde, al coordinatore.
  • Validazione e triage: Il report viene validato per garantirne l’accuratezza prima di intraprendere qualsiasi azione pratica di risposta.
  • Riparazione: Viene sviluppato e testato un piano di riparazione (i.e. patch).
  • Divulgazione pubblica: La vulnerabilità stessa e la relativa patch vengono divulgate al pubblico.
  • Distribuzione: La patch viene applicata ai sistemi distribuiti.

Secondo quanto descritto dal centro nazionale belga per la cybersecurity, dopo che il ricercatore ha individuato e segnalato la vulnerabilità, l’organizzazione responsabile rimane, a meno che non sia diversamente indicato, libera di scegliere di sviluppare e implementare una soluzione.

Idealmente, la soluzione dovrebbe essere sviluppata entro 90 giorni.

È importante mantenere al minimo questa scadenza, soprattutto se vi sono rischi per la protezione dei dati personali.

Se l’organizzazione non fosse in grado di risolvere immediatamente il problema, il sistema informatico dovrebbe essere messo temporaneamente fuori servizio.

Se la soluzione è pronta e la vulnerabilità interessasse altre organizzazioni, questa dovrebbe essere comunicata al coordinatore CVD in via prioritaria e prima di qualsiasi divulgazione pubblica. Se una delle parti non risponde, le parti possono rivolgersi al coordinatore designato.[4]

White hackers: il problema della protezione legale dei ricercatori

Esistono numerose sfide legali associate al processo descritto. Gli individui che scoprono una vulnerabilità “spesso devono affrontare minacce legali quando decidono di segnalarla. Queste minacce possono derivare non solo dall’applicazione del diritto civile e penale, ma anche dall’applicazione del diritto commerciale e altri tipi di legislazioni.”[5] Nella maggior parte dei paesi dell’UE, il quadro giuridico non è stato aggiornato per fornire tutele legali ai ricercatori.

Secondo le disposizioni legali esistenti nella maggior parte dei casi, quindi, chiunque rilevi e divulghi una vulnerabilità scansionando un sistema senza previa autorizzazione è vincolato dal diritto penale e da altre disposizioni legislative.

La Convenzione sulla criminalità informatica, infatti, prevede che l’accesso intenzionale a un sistema informatico senza autorizzazione è un reato.

Sia nei casi in cui i ricercatori stiano cercando attivamente le vulnerabilità, sia nei casi in cui le vulnerabilità vengono trovate in modo accidentale durante il normale utilizzo di un sistema, il ricercatore può inavvertitamente accedere a dati critici e quindi incorrere in azioni legali una volta segnalata la vulnerabilità al venditore.

Come si stanno muovendo i paesi europei

Al momento, ancora pochi paesi in Europa hanno adottato misure che garantiscono un ambiente giuridico favorevole alla ricerca delle vulnerabilità e alla protezione degli white hackers.

I Paesi Bassi hanno guidato gli sforzi dell’UE nella definizione del processo di CVD. Il paese dispone di un quadro giuridico adeguato, nonché di procedure chiare per segnalare le vulnerabilità.

Olanda, Francia, Belgio e Lituania sono gli unici quattro Stati membri con una politica nazionale sulla CVD pienamente consolidata.

Altri Stati membri sono sul punto di promulgare una CVD policy; la proposta è esaminata a livello di responsabili politici e testata nell’ambito di progetti pilota. La maggior parte dei paesi europei non ha tuttavia ancora pubblicato alcuna CVD policy.

La situazione corrente è però in continua evoluzione e si prevede che nei prossimi anni tutti i Paesi implementeranno una CVD policy. L’obbligo per gli Stati membri di stabilire una politica coordinata di divulgazione delle vulnerabilità è infatti una delle nuove proposte nella direttiva NIS2, che dal 2022 approderà al negoziato in Trilogo (Commissione, Parlamento e Consiglio Ue).

Come ha dimostrato il recente caso di Log4Shell, una buona gestione del processo di divulgazione è fondamentale, soprattutto per le vulnerabilità altamente critiche; tale proposta è quindi da accogliere molto positivamente.

______________________________________________

Note e bibliografia

Questo articolo fa riferimento a: Pupillo, L., Ferreira, A., & Varisco, G., (2018), Software Vulnerability Disclosure in Europe: Technology, Policies and Legal Challenges, Report of a CEPS Task Force, CEPS Task Force Reports 28 June 2018.

  1. ISO/IEC, “ISO/IEC 29147:2014 Information technology-Security techniques-Vulnerability disclosure”, 2014.
  2. “The CERT Guide to Coordinated Vulnerability Disclosure”, by Allen D. Householder, Garret Wassermann, Art Manion and Chris King, Software Engineering Institute, Carnegie Mellon University, August 2017, p. 2. This part of this report draws from this source.
  3. Centre for Cybersecurity Belgium (2020), Guide to Coordinated Vulnerability Disclosure Policies Part I: Good Practices. Available at: https://ccb.belgium.be/sites/default/files/Guide%20CVDP%20part%20I%20Good%20pratices.pdf
  4. ENISA, “Good Practice Guide on Vulnerability Disclosure – From challenges to recommendations”, January 2016, p. 7.
  5. Questa sezione fa riferimento a: OECD, (2021), “Encouraging Vulnerability Treatment: Overview for Policy Makers”, February p. 29. Available at: https://www.oecd.org/sti/encouraging-vulnerability-treatment-0e2615ba-en.htm

WHITEPAPER
Cosa serve per risparmiare davvero sull’energia? L’IoT da solo non basta!
@RIPRODUZIONE RISERVATA

Articolo 1 di 3