Questo articolo fa parte di una serie di approfondimenti sulla Data Security che abbiamo pubblicato nei giorni scorsi: gli argomenti che andremo ad affrontare in questa sede sono relativi al tema del Vulnerability Assessment (VA), uno dei concetti chiave alla base delle moderne metodologie di sicurezza informatica.
Come sempre partiremo dalla definizione, per poi recuperare il contesto storico in cui si viene a determinare la necessità di condurre verifiche di vulnerabilità sui sistemi informatici; nella seconda e ultima parte dell'articolo ci occuperemo di definire alcune best practice e linee guida prendendo a riferimento gli standard più autorevoli ad oggi disponibili.
Per meglio comprendere le premesse da cui si muove il presente articolo consigliamo di leggere i nostri approfondimenti sul contesto generale relativo alle metodologie di Information Security in Italia e in Europa:
- Sicurezza Informatica - Misure minime per le Pubbliche Amministrazioni, che contiene un'analisi dettagliata delle misure minime di sicurezza ICT per le pubbliche amministrazioni previste da Agenzia per l'Italia Digitale;
- Information Security - Linee Guida ENISA, che offre una panoramica delle Technical Guidelines for the implementation of minimum security measures for Digital Service Providersa rilasciate dalla European Union Agency for Cybersecurity.
Definizione
Il Vulnerability Assessment consiste in un processo che, mediante i risultati di una serie di verifiche di sicurezza automatiche e/o manuali, consente di definire, identificare e classificare i principali rischi connessi alla messa in esercizio e/o all'operatività di un dato sistema informatico (ad es. un applicativo software, un network aziendale, un singolo device o una applicazione web). Per dirla in altri termini, il VA consente di dare risposta alla seguente domanda: quante probabilità ha il sistema di cadere preda di attacchi informatici?
Cenni storici
Le origini del Vulnerability Assessment risalgono alla seconda metà degli anni '70, quando cominciano a diffondersi i primi rudimentali software di prevenzione dagli attacchi informatici: è soltanto però dopo un decennio, quando i personal computer cominciano a diffondersi in ogni ambito lavorativo, che si comincia a comprendere la necessità di operare una valutazione preventiva sui rischi di sicurezza relativi a software e infrastrutture. Oggi, complice l'enorme quantitativo di cyber threats esistente, i Test di Vulnerabilità sui sistemi informatici sono largamente diffusi in tutto il mondo e vengono effettuati a qualsiasi livello: sulle reti, sui device (compresi i dispositivi Internet of Things) e, ovviamente, sugli applicativi software e sui siti web; si può ragionevolmente affermare che qualsiasi azienda che desideri dotarsi di una moderna policy di sicurezza informatica deve necessariamente prevedere l'esecuzione periodica di test di vulnerabilità.
Le 4 fasi del Vulnerability Assessment
L’attività di Vulnerability Assessment si suddivide in 4 fasi principali:
- Analisi dell'inventario degli asset e delle funzionalità del sistema oggetto di analisi;
- Valutazione dell'importanza delle risorse individuate utilizzando un sistema di classificazione standard;
- Ricerca, identificazione e classificazione delle vulnerabilità (riscontrate o potenziali) per ciascuna delle risorse individuate;
- Predisposizione di un Gap & Remediation report che documenti le azioni che è necessario effettuare per eliminare o mitigare le vulnerabilità riscontrate, ovvero per ridurre il rischio che quelle potenziali si verifichino in un prossimo futuro;
Inutile dire che, nello stilare il report di cui al punto 4, occorrerà dare agli interventi ipotizzati una priorità variabile a seconda dell'importanza della risorsa (punto 2) e della criticità, in termini di probabilità e impatto, della vulnerabilità riscontrata. Come si può vedere, si tratta di una metodologia che ha molte cose in comune con le metodologie oggi impiegate per il Risk Assessment, standardizzate nella famiglia ISO 31000: la cosa non deve stupire, visto che le vulnerabilità non sono altro che una particolare tipologia di rischio. E' dunque corretto affermare che il Vulnerability Assessment costituisce parte integrante di un più generico Risk Assessment, con un focus particolare sugli aspetti legati a una determinata categoria di rischi connessi alla information security: gli attacchi informatici. Non a caso, viene spesso fatto confluire all'interno del Security Assessment svolto in un contesto di Risk Assessment generale.
Ricerca, identificazione e classificazione
Delle 4 fasi sopra elencate è utile spendere qualche parola ulteriore sulla terza, che costituisce il cuore dell'attività di analisi vera e propria: la ricerca, l'identificazione e la classificazione delle vulnerabilità. Si tratta di una serie di attività strettamente collegate tra loro, che richiedono un buon livello di conoscenza informatica e procedurale.
- Ricerca delle vulnerabilità informatiche
- Analisi delle vulnerabilità rilevate
- Classificazione dei rischi
- Produzione di un vulnerability report
Nel caso in cui si utilizzi un software apposito, come quelli messi a disposizione da OWASP e/o da servizi web dedicati (come il servizio Vulnerability Management della Qualys Cloud Platform, disponibile in prova gratuita per 30-60 giorni o grauitamente nell'edizione community), queste attività saranno con tutta probabilità eseguite automaticamente in modo sequenziale, sollevando l'auditor (o l'operatore) da gran parte degli oneri operativi: al tempo stesso, sarà fondamentale rivedere il prodotto delle procedure automatiche alla luce dello scenario di riferimento, in quanto i rischi connessi a ciascuna vulnerabilità rilevata potrebbero essere sostanzialmente diversi a seconda del tipo di sistema e/o di servizio, della sua esposizione, del tipo di dati che è pensato per gestire, etc: in altre parole, sarà necessaria una context-aware analysis che con tutta probabilità non potrà essere delegata al software, necessitando di compenze specifiche e di una conoscenza approfondita del contesto di riferimento.
Penetration Test
Una parte fondamentale del Vulnerability Assessment è data dal Penetration Test (noto anche come PenTest), ovvero dal processo operativo con cui si mettono alla prova le caratteristiche di sicurezza del sistema informatico oggetto di valutazione. Si tratta di un'analisi condotta su più fasi, in cui il tester assume il punto di vista di un potenziale attaccante simulando l'attacco informatico di un utente malintenzionato utilizzando programmi e/o software suite appositamente pensati per assolvere a tale scopo.
Ecco una lista non esaustiva di alcuni tra i software più utilizzati per i penetration test:
- Information Gathering: Maltego, FOCA, DNSEnum, DNSMap, TheHarvester;
- Scanning e Service Enumeration: Nmap, Hping, P0f, ARPing, DirBuster, Metasploit;
- Vulnerability Discovery: NeXpose, OpenVAS, WPScan, BurpSuite, SqlMap, Metasploit, Nikto, Beef, W3af scanner;
- Exploitation: Ettercap, Bettercap, SSLStrip, AirCrack, Metasploit, BurpSuite;
- Escalation Privileges: Metasploit, John the Ripper, Ophcrack.
Come si può vedere, ciascun software è specializzato per simulare una tipologia di attacco ben precisa: per questo motivo è importante saper scegliere il software giusto a seconda di ciò che si ha intenzione di testare, ovvero delle caratteristiche del sistema oggetto di analisi; ancora una volta, dunque, emerge l'importanza del fattore umano, ovvero il valore aggiunto dato dalla conoscenza del contesto di riferimento e della valutazione rischi effettuata per quello specifico scenario.
A prescindere dalla tipologia di attacco, ciascun test ha come obiettivo quello di evidenziare le debolezze della piattaforma fornendo il maggior numero di informazioni sulle vulnerabilità che ne hanno permesso l'accesso non autorizzato, fornendo una stima sulle capacità di difesa e del livello di penetrazione raggiunto. Ad essere oggetto di scansione sono sia le vulnerabilità esterne che quelle interne al sistema.
A cosa serve il PenTest?
Giunti a questo punto può essere utile sgombrare il campo da un frequente equivoco che genera il Penetration Test nel contesto più generale del Vulnerability Assessment di cui solitamente fa parte: la convinzione secondo cui affidarsi ad esso per velocizzare l'attività di ricerca delle proprie vulnerabilità può essere una scelta vantaggiosa o in qualche modo percorribile: sfortunatamente, senza timore di esagerare, possiamo affermare che pensarla in questo modo significa compiere un grave errore di valutazione. Il PenTest va inteso piuttosto come un mezzo che consente di scoprire una situazione inattesa, una "falla" imprevista che può essere sfruttata da un potenziale attaccante esterno particolarmente ingegnoso, magari sfruttando una vulnerabilità recente o poco nota: non è il modo corretto per verificare la tenuta di un sistema in termini di sicurezza informatica, in quanto non vi è alcuna garanzia che i test effettuati siano esaustivi o mettano alla prova l'infrastruttura in tutte le sue debolezze: ad esempio, potrebbero risultare grandemente inefficaci per scoprire problematiche legate alle modalità di scansione antivirus degli allegati ricevuti tramite posta elettronica o altri canali (SFTP, FTP, upload, etc), o l'aggiornamento di componenti del sistema operativo che non possono essere sfruttate dall'esterno.
In termini più generali, è corretto affermare che il Penetration Test non può essere considerato uno strumento di protezione e certamente non consente di creare una mappatura efficace delle proprie vulnerabilità. Questo ovviamente non significa che non si tratti di una risorsa importante per misurare la tenuta del nostro sistema: il punto è che assolve a una funzione diversa e specifica, ovvero aiutarci a scoprire nuove e impreviste vulnerabilità da aggiungere alla mappatura esistente e da gestire e valutare come qualsiasi altro unexpected incident, ovvero per mezzo degli strumenti propri dell'analisi dei rischi.
La prova di quanto diciamo è data dal fatto che in uno scenario di sicurezza ideale, ovvero quando tutte le vulnerabilità sono state corrette in modo opportuno, il Penetration Test non sortirà alcun effetto, in quanto nessuno dei suoi attacchi simulati riuscirà ad avere luogo. Al contrario, tenderà ad essere più efficace (e quindi più "allarmante") in tutti i casi in cui non siano state prese le dovute contromisure volte a ridurre il rischio di esposizione a un possibile attacco informatico: nei prossimi paragrafi ci dedicheremo ad approfondire due metodologie che giocano un ruolo fondamentale per la corretta implementazione di queste contromisure, note come Patch Management e Change Management.
Patch Management
Prima di poter dare una corretta definizione di patch management è opportuno fare un passo indietro e comprendere cosa si intende con il termine patch. Si tratta di una parola di origine anglosassone, traducibile in italiano come "toppa", che in ambito informatico indica una particolare tipologia di software (o script) che ha il compito di correggere, aggiornare o migliorare le funzionalità di un programma esistente: un sinonimo, o per meglio dire una particolare tipologia di patch, è il fix (anche detto bugfix).
Gli aggiornamenti periodici che molti dei programmi applicativi di uso comune scaricano dal web, incluse le app per dispositivi mobili, sono un perfetto esempio di patch. La presenza di internet e di device permanentemente connessi alla rete ha consentito ai produttori di software di svolgere questa attività in modo pressoché automatico e quasi impercettibile dall'utente finale, ma non è sempre stato così: fino a non molti anni fa la quasi totalità delle patch veniva distribuita esclusivamente attraverso canali offline, lasciando all'utente (o all'amministratore di sistema) il compito e la responsabilità di occuparsi di questa delicata ma importantissima attività, che ancora oggi viene chiamata patching (talvolta italianizzato in "patchare").
Il patching, ovvero l'applicazione e l’installazione effettiva delle patch, è un'operazione che oggi - come abbiamo detto - avviene spesso in modo relativamente automatizzato e trasparente, ma in alcuni casi può necessitare di particolare attenzione: un esempio efficace è dato dall'aggiornamento del sistema operativo di un mobile device, che nella maggior parte dei casi comporterà prima un blocco temporaneo del dispositivo (ovvero un certo periodo di tempo in cui questo non potrà essere utilizzato) e poi un riavvio. Si tratta quindi di una patch che viene applicata "a freddo", ovvero interrompendo l'esecuzione di determinati processi e servizi, a differenza delle patch "a caldo" condotte in background da strumenti appositi come l'App Store di iOS o il Play Store di Android.
In un contesto aziendale o, più in generale, all'interno di un'organizzazione, risulta evidente come l'attività di patching non possa essere affidata alla buona volontà del singolo utente o al giudizio insindacabile dell'amministratore di sistema. Al contrario, è fondamentale dotarsi di una procedura specifica che preveda il patching periodico di tutti i dispositivi e i software mediante un processo standardizzato da ripetere a intervalli regolari, possibilmente basata sulle notifiche provenienti dai canali di aggiornamento ufficiali e comprensiva di un report inalterabile a conferma dell'avvenuta operazione: questa che abbiamo appena dato non è altro che la corretta definizione di Patch Management.
In tutti i casi in cui il processo di patch management non viene formalizzato, non è ottimizzato in modo opportuno o non copre la totalità degli applicativi a rischio, le chance di avere delle vulnerabilità - e quindi di subire un attacco informatico - aumentano. Questa affermazione ci consente di apprendere due lezioni fondamentali:
- Il patch management deve essere basato sul rischio, in quanto è necessario stabilire quali sono gli applicativi maggiormente esposti nei consueti termini di probabilità e impatto.
- Il patch management deve essere ripetuto ogni volta che la nostra infrastruttura è soggetta a un cambiamento, quantomeno a livello di valutazione dei rischi.
Il cambiamento di cui si parla nel secondo punto può essere dovuto all'introduzione di nuovi software, all'ampliamento del network grazie a nuove periferiche, all'aggiunta di un endpoint a uno dei webservice, ma anche a un "semplice" aggiornamento di sistema. Questo significa che, oltre al Patch Management, abbiamo bisogno di un ulteriore processo standardizzato che si ponga l'obiettivo di aggiornare il nostro Vulnerability Assessment ogni volta che il sistema cambia: questa funzione è svolta dall'insieme di metodologie note come Change Management.
Change Management
Non è la prima volta che parliamo di Change Management: appena qualche giorno fa abbiamo pubblicato alcuni approfondimenti sul tema, per recuperare i quali rimandiamo all'articolo Change Management: cos'è, come funziona, come affrontarlo. In questa sede, per ragioni di spazio, ci limiteremo a ripetere la definizione più convincente di questo importante processo:
Un complesso di attività strutturate volto a costruire un percorso di transizione che, partendo dalla situazione attuale (as-is), fissa un obiettivo (to-be) attraverso una serie di scelte metodologiche (how-to).
Nell'articolo di cui sopra abbiamo sottolineato come i cambiamenti possano avere luogo a seguito di due principali eventualità:
- una scelta proattiva, in cui l'iniziativa di change viene presa a seguito della decisione di uno stakeholder (es. il management);
- una risposta a un evento, in cui l'iniziativa di change viene determinata da circostanze terze (es. un provvedimento normativo);
In entrambi i casi, il cambiamento può essere una risposta a un rischio (inteso come incident, ovvero come situazione indesiderabile che è opportuno sanare) o un tentativo di sfruttare un'opportunità (ad esempio i vantaggi connessi a una scoperta tecnologica); ancora una volta, dunque, l'analisi dei rischi gioca un ruolo fondamentale, al punto che tutti i principali modelli di Change Management che oggi riscuotono maggior successo (8-Step Model, ADKAR, etc.) sono basati sul rischio.
Mantenere il focus sull'analisi dei rischi ci consente di comprendere in modo evidente lo stretto rapporto che intercorre tra Change Management e Patch Management in un contesto di Vulnerability Assessment: avere un Change Management basato sul rischio significa valutare l'impatto, in termini di sicurezza, di ogni aggiunta o modifica operata sui propri sistemi, che consentirà dunque di mantenere il processo di Patch Management costantemente aggiornato e ottimizzato. A valle di questo processo si colloca il Penetration Test, che consente di proteggersi da minacce non ancora sufficientemente note nel rispetto del ciclo di miglioramento continuo (continuous improvement) alla base della ISO 27001 e ribadito dalle linee guida ENISA e AgID.
Conclusione
Siamo giunti al termine di questo approfondimento sul Vulnerability Assessment e sui processi che ne consentono la corretta implementazione (Change Management, Patch Management e Penetration Test): ci auguriamo che le informazioni che abbiamo condiviso possano essere d'aiuto a tutti gli interessati, con particolare riguardo agli amministratori di sistema e a quanti lavorano nel campo dell'information security. Alla prossima!
