La sempre crescente domanda di sicurezza delle informazioni, o di Cyber sicurezza, per usare le parole di cui all’articolo quattro della direttiva 2055 del 14 dicembre 2022 (d’ora in poi NIS 2), oltre alla capacità di disporre di risorse tecnologiche adeguate, implica, necessariamente, o almeno sino ad ora ha implicato, la presenza all’interno delle organizzazioni di figure professionali competenti, in grado di governare e gestire dette tecnologie ed corrispondenti processi organizzativi, interni ed esterni, utili a conseguire gli obiettivi di sicurezza desiderati. In questo senso in effetti, la direttiva NIS 2, all’art. 20, rubricato Governance, pone a carico dei soggetti che hanno il potere di gestione delle procedure e delle politiche di sicurezza di una organizzazione pubblica o privata, la responsabilità personale per l’inottemperanza e le conseguenti violazioni alle previsioni normative; ma non solo, sempre con riferimento alla necessità di incardinare ruoli e responsabilità correlati, più in generale, ad obblighi di controllo in materia di Cybersicurezza, il recente disegno di legge 1717 dello scorso 16 febbraio ha previsto, all’articolo 6, in capo determinati soggetti, ad esempio i comuni con più di 100.000 abitanti, i capoluoghi di regione e le Asl, l’obbligo di istituire un referente per la Cyber sicurezza.
Chiarito ciò che precede, al fine di quanto si occupa, preme sottolineare, in particolare con riferimento specifico alle responsabilità del penetration tester, che tra le misure di rafforzamento della resilienza delle pubbliche amministrazioni sono previste espressamente alla lettera g) del citato art. 6, quelle di monitoraggio e valutazione continua delle minacce della sicurezza e delle vulnerabilità di sistemi per il loro pronto aggiornamento. Nondimeno l’articolo 21 comma 2 della direttiva NIS 2 specifica che le misure di gestione dei rischi di cybersicurezza devono comprendere, almeno, tra le altre: la sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete, compresa la gestione e la divulgazione delle vulnerabilità nonché strategie e procedure per valutare l’efficacia delle misure di gestione dei rischi di cybersicurezza.
In conclusione, quindi, in forza del contenuto delle disposizioni normative da ultime richiamate, da ritenersi secondo chi scrive, integrative delle disposizioni di cui all’articolo 32 lettera D del GDPR, che prevede che tra le misure di sicurezza tecniche ed organizzative imposte ai titolari ed ai responsabili del trattamento, vi debbano essere procedure per valutare l’efficacia delle misure tecniche ed organizzative adottate, è ormai preciso obbligo dei soggetti sopra citati, servirsi di tecnologie, e di professionisti in grado di usarle, funzionali alla valutazione continua delle vulnerabilità. Come noto, le norme ISO in materia di sicurezza delle informazioni, nel definire la nozione di vulnerabilità, introducono la necessità di dare un contesto specifico ai vari tipi di vulnerabilità che possono affliggere i sistemi.
In particolare le norme della famiglia 27000, definiscono una vulnerabilità come “una debolezza di un asset o di un gruppo di asset che potrebbe essere sfruttata da una minaccia”, stabilendo, in primo luogo, che le organizzazioni conducano una valutazione dei rischi per identificare le vulnerabilità presenti nei loro sistemi informativi, in secondo luogo, che sviluppino ed implementino un piano di trattamento dei rischi, che comprende la gestione delle vulnerabilità identificate e l’adozione di misure tecniche, organizzative e procedurali per ridurle o eliminarle e proteggere le informazioni, ed infine, che sia effettuato un monitoraggio costante delle vulnerabilità ed effettuate revisioni periodiche del sistema per identificare nuove minacce o vulnerabilità emergenti. Le vulnerabilità vengono tipicamente identificate e valutate attraverso un processo noto come valutazione delle vulnerabilità (Vulnerability Assessment o VA), che comprende vari passaggi e metodologie per individuarle nei sistemi, nelle reti, nelle applicazioni e in altri componenti dell’infrastruttura IT di un’organizzazione, oltre che nei suoi processi organizzativi.
L’approccio comune all’individuazione ed all’analisi delle vulnerabilità tecniche contempla l’utilizzo di strumenti automatici che scansionano i sistemi e le reti per individuare vulnerabilità note, quali, ad esempio, versioni obsolete del software, configurazioni errate o impostazioni non sicure, generando report che identificano, evidenziano e valutano le vulnerabilità identificate, insieme ai livelli di gravità e ai potenziali rischi, in base, ad esempio, al Common Vulnerability Scoring System (CVSS), così consentendo alle organizzazioni di stabilire le priorità su quali vulnerabilità affrontare per prime in base alla loro gravità e all’impatto potenziale. In particolare, il CVSS, giunto ormai alla versione 4.0, è un sistema che identifica le principali caratteristiche tecniche delle vulnerabilità presenti nel software, nell’hardware e nel firmware, composto da quattro gruppi di metriche: Base, Minaccia, Ambientali e Supplementari.
Il punteggio Base nel CVSS riflette la gravità di una vulnerabilità in base alle sue caratteristiche intrinseche, che rimangono costanti nel tempo e presuppongono il peggior impatto possibile su diversi ambienti di implementazione, le metriche della Minaccia adattano la gravità di una vulnerabilità in base a fattori come la disponibilità di codice proof-of-concept o exploit attivi, le metriche Ambientali raffinano ulteriormente il punteggio di gravità risultante per un ambiente informatico specifico, considerando fattori come la presenza di mitigazioni in quell’ambiente e le caratteristiche di criticità del sistema vulnerabile. Infine, le metriche Supplementari descrivono e misurano attributi estrinseci aggiuntivi di una vulnerabilità, con lo scopo di aggiungere contesto.
Ciò detto, sembra importante, a questo punto, sottolineare che non tutte le vulnerabilità devono essere corrette. Alcune vulnerabilità possono essere considerate accettabili in base alla tolleranza al rischio dell’organizzazione e al contesto in cui si trovano. Ad esempio, se una vulnerabilità esiste in un sistema isolato dall’accesso esterno, il rischio potrebbe essere considerato basso. Inoltre, occorre osservare, per completezza, che non tutte le vulnerabilità possono essere rilevate attraverso la scansione automatica, richiedendosi, invece, in alcune circostanze che siano condotti specifici test e valutazioni manuali.
In questi casi, si parla più propriamente di penetration testing (Pentest o PT) che consiste nella simulazione di attacchi reali per individuare vulnerabilità non rilevabili tramite scansioni automatiche.
Dal punto di vista strettamente legale, la prestazione resa dal penetration tester, che si caratterizza per competenze specializzate, conoscenze tecniche avanzate e capacità analitiche per individuare vulnerabilità nei sistemi informatici e proporre soluzioni adeguate e richiede un elevato grado di creatività e intelligenza, può essere considerata, pur non trovando una tipizzazione propria nei contratti nominati, una prestazione d’opera intellettuale, ai sensi delle disposizioni del Codice Civile italiano, alla quale si applica quindi la regola in materia di responsabilità di cui all’art. 2236 secondo il cui disposto: Se la prestazione implica la soluzione di problemi tecnici di speciale difficoltà, il prestatore d’opera non risponde dei danni, se non in caso di dolo o di colpa grave.
Prossimo numero
Hai una domanda per l'autore?
Al codice del consumo (n.206/2005) vengono aggiunti nuovi articoli
Nel prossimo numero, si approfondiranno le principali metodologie di penetration testing e, all’interno dei contenuti dell’ENISA Cybersecurity Skills Framework si individueranno le competenze necessarie per svolgere le corrispondenti attività, unitamente alle responsabilità ed attività principali proprie della sua funzione.
