Nell’ambito della gestione delle applicazioni e dei sistemi informatici, è noto che l’approccio più utilizzato è quello del “finché funziona, non lo tocco”.
Quando si tratta di sicurezza, invece, molto spesso è necessario provare a “rompere” le cose per capire se le nostre applicazioni sono sufficientemente robuste e resistenti agli attacchi a cui sono potenzialmente esposte. Non importa che si tratti di applicazioni destinate al solo uso interno, magari residenti su un server accessibile solo dalla rete privata dell’azienda, o che siano accessibili a chiunque, siano esse ospitate in casa propria o presso un hosting o cloud provider. In tutti i casi è fondamentale eseguire, con regolarità e non solo occasionalmente, delle attività che ne verifichino lo stato.
Le verifiche possibili si suddividono tipicamente in due categorie differenti:
- il vulnerability assessment
- il penetration testing
1. Il Vulnerability Assessment: la radiografia periodica della sicurezza
Il vulnerability assessment (VA), o valutazione delle vulnerabilità, è il processo sistematico di analisi e identificazione delle falle di sicurezza all’interno di un sistema, di una rete o di un’applicazione.
Potremmo pensarlo come una sorta di “scansione” o “inventario dei punti deboli”. L’obiettivo non è quello di sfruttare le vulnerabilità per vedere fin dove si può arrivare (quello sarà compito del penetration testing), ma piuttosto di scattare una fotografia dello stato di salute della nostra infrastruttura. Il VA ci risponde a domande come: “Quali server hanno versioni di software obsolete, non più supportate o affette da vulnerabilità e bug noti?”, “Ci sono configurazioni errate che potrebbero esporci a rischi?”, “Quali sono le vulnerabilità critiche che dobbiamo assolutamente patchare subito?”.
Si tratta quindi di un’attività, solitamente automatizzata, eseguita con software specifici chiamati “scanner di vulnerabilità”. Questi strumenti analizzano i sistemi target alla ricerca di migliaia di firme di vulnerabilità conosciute, confrontando ciò che trovano con database aggiornati (come il famoso CVE – Common Vulnerabilities and Exposures). Al termine della scansione, producono un report dettagliato che elenca le vulnerabilità trovate, classificate per gravità (bassa, media, alta, critica) e spesso con indicazioni su come risolverle.
Eseguire un VA con regolarità (ad esempio trimestralmente, o dopo ogni modifica significativa all’infrastruttura) è considerata una buona pratica di igiene informatica. Permette di tenere sotto controllo il “debito tecnico” di sicurezza e di intervenire tempestivamente prima che qualcuno con cattive intenzioni possa approfittare di una di quelle finestre lasciate aperte.
Strumenti utili per il Vulnerability Assessment
Per eseguire queste analisi, il mercato offre diverse soluzioni. Tra quelle più note possiamo trovare strumenti commerciali molto potenti e ricchi di funzionalità, come ad esempio Nessus, Qualys o Nexpose, che sono lo standard in molte grandi aziende. Accanto a questi, esiste un fiorente ecosistema di strumenti open source, estremamente validi e flessibili, come OpenVAS (il fork di Nessus prima che diventasse closed) o Nikto per le applicazioni web. A questi strumenti si affiancano poi noti e consolidati strumenti di information gathering come nmap e gobuster, o strumenti specializzati come wpscan.
2. Il Penetration Testing: oltre la scansione, la simulazione d’attacco
Se il vulnerability assessment fornisce una fotografia statica dei punti deboli, il penetration testing (o pen testing) rappresenta un passo successivo e più approfondito nel ciclo di gestione della sicurezza. Si tratta di un attacco informatico simulato e AUTORIZZATO, condotto su sistemi, reti o applicazioni, con l’obiettivo di identificare e sfruttare attivamente le vulnerabilità, esattamente come farebbe un attaccante reale.
La differenza sostanziale rispetto al VA risiede nell’azione. Mentre lo scanner di vulnerabilità si limita a rilevare e classificare le falle in base a database di firme note, il penetration test tenta di validarne la concreta sfruttabilità. L’obiettivo non è la produzione di una lista di vulnerabilità potenziali, ma la determinazione del rischio effettivo per l’organizzazione.
Un penetration test si propone di:
- Validare le vulnerabilità: Non tutte le vulnerabilità individuate da uno scanner sono realmente sfruttabili in uno specifico contesto. Il PT verifica se una falla può essere effettivamente utilizzata per ottenere un accesso non autorizzato, scalare privilegi o intercettare dati.
- Testare i meccanismi di difesa e risposta: Oltre a saggiare la robustezza di sistemi e applicazioni, il test valuta l’efficacia dei controlli di sicurezza perimetrali (firewall, WAF, IDS/IPS) e, non meno importante, la capacità del personale interno di rilevare e reagire tempestivamente a un incidente in corso.
- Valutare l’impatto potenziale di un breach: L’esercizio mira spesso a raggiungere un obiettivo definito a priori, come l’esfiltrazione di dati sensibili da un database, la compromissione di un server critico o l’interruzione di un servizio. Questo consente di quantificare il danno, sia operativo che reputazionale, che un attacco reale potrebbe causare.
A differenza del VA, che è un processo prevalentemente automatizzato, il penetration testing richiede un approccio manuale, basato sull’esperienza e sulla capacità di ragionamento laterale del penetration tester. Lo scanner fornisce indizi, ma è il tester che deve interpretarli, concatenarli e adattare le tecniche di attacco al contesto specifico, simulando la creatività e la determinazione di un avversario umano.
La profondità e la tipologia del test variano in base al livello di conoscenza del bersaglio concesso al team di testing:
- Black-box: Il tester opera senza alcuna informazione pregressa, simulando un attaccante esterno privo di accessi privilegiati. L’approccio è dall’esterno verso l’interno e comprende idealmente la fase preliminare di information gathering tramite le tecniche come OSINT, social engineering, ecc.
- White-box: Al tester viene fornita piena visibilità sull’infrastruttura target (codice sorgente, schemi architetturali, credenziali). Questo approccio consente un’analisi più approfondita e mirata, ottimizzando i tempi e coprendo scenari come l’insider threat.
- Grey-box: Il tester dispone di informazioni e credenziali parziali (ad esempio, quelle di un utente autenticato di un’applicazione), una via di mezzo che bilancia realismo e profondità di analisi.
In sintesi, se il vulnerability assessment è un’attività di igiene informatica da condurre con regolarità, il penetration testing è un esercizio tattico più complesso, da pianificare con cadenza periodica (solitamente annuale) o in concomitanza con cambiamenti significativi dell’infrastruttura o il rilascio di applicazioni critiche, per ottenere una garanzia sostanziale della loro resilienza.
Strumenti utili per il penetration testing
Uno degli strumenti “principe” usati per il penetration testing è il framework Metasploit, un vero e proprio “coltellino svizzero” dell’ethical hacking, contenente migliaia di exploit già pronti e un’ampia gamma di payload da iniettare nel bersaglio.
Se l’obiettivo è un’applicazione web, tra gli strumenti più usati troviamo Burp Suite e OWASP ZAP, che agiscono come proxy per intercettare, analizzare e modificare le richieste effettuate dal browser.
Ovviamente il panorama di strumenti utilizzabili in queste attività non si limita ai pochi prodotti citati, ma ce ne sono svariate decine (tra quelli già pronti) e innumerevoli tra quelli “custom” che ciascun pentester personalizza e colleziona nella sua personale “cassetta degli attrezzi”. A questi si aggiungono gli script, scritti in diversi linguaggi, realizzati appositamente per target specifici. Tra i linguaggi più usati ci sono soprattutto Bash e Python, ma anche Ruby e Perl.
Quando e cosa “patchare”?
In base a quanto discusso in precedenza, si potrebbe evincere che quando si riscontrano delle vulnerabilità all’interno di una rete o tra le applicazioni di un’azienda, il passo immediatamente conseguente sia quello di correggere tali vulnerabilità (in gergo patchare) al fine di chiudere tutti i potenziali buchi di sicurezza.
La realta, però, è spesso diversa. Le vulnerabilità vengono normalmente classificate in base alla loro gravità, ovvero in base ai potenziali danni che ne potrebbero derivare in caso di sfruttamento. Distinguiamo tra vulnerabilità con gravità critica, alta, media, bassa. Quando un’azienda si trova davanti ad un report di vulnerability assessment che elenca una serie di vulnerabilità, non deve banalmente procedere a chiuderle tutte; deve in realtà valutarle una ad una e decidere il piano d’azione.
Chiudere le falle di sicurezza, cioè correggere ed eliminare le vulnerabilità, non è un’attività a costo zero. Si deve pertanto fare una stima dei costi e capire se il budget disponibile è sufficiente a fare tutto. In caso contrario, bisognerà fare delle scelte. La decisione più logica e scontata è, chiaramente, quella di allocare budget per correggere le falle più gravi. Per le altre si vedrà.
Alcune volte, tuttavia, i costi per rimediare a certe vulnerabilità possono essere improponibili o sproporzionati rispetto al beneficio che se ne trarrebbe. Per questo, in alcuni casi particolari, può essere più conveniente dismettere il sistema vulnerabile, isolarlo o decidere di migrare a una soluzione differente.
Qui si conclude questa mia breve dissertazione sull’argomento. Spero, nel prossimo futuro, di riuscire a scrivere qualche riga a proposito di alcuni degli strumenti che ho citato per mostrare come funzionano.