Prima di definire un Vulnerability Management Process occorre comprendere che cos’è una vulnerabilità informatica.

Lo standard ISO 27002 definisce una vulnerabilità come “una debolezza di un asset o di un gruppo di asset che può essere sfruttato da una o più minacce”.

In presenza di vulnerabilità, spesso ineliminabili, è necessario predisporre dei piani di gestione delle vulnerabilità.

Un vulnerability management process è un processo nel quale sono identificate le vulnerabilità dei sistemi informativi con relativa valutazione del rischio.

Questa valutazione porta alla correzione delle vulnerabilità, quando possibile, o all’accettazione formale del rischio da parte della direzione di un’organizzazione.

Ad esempio, se un rischio è molto basso e ha un impatto molto basso, con un elevato costo di riduzione, l’organizzazione potrebbe decidere di accettare il rischio.

Il termine gestione delle vulnerabilità viene spesso confuso con il vulnerability scanning.

La scansione delle vulnerabilità consiste nell’utilizzo di software per identificare le vulnerabilità nelle reti e nei sistemi, mentre la gestione delle vulnerabilità è il processo che si occupa del relativo controllo, tenendo conto anche di altri aspetti come ad esempio l’accettazione del rischio.

In un precedente articolo abbiamo trattato le categorie più comuni di vulnerabilità di sicurezza, come ad esempio il Cross-Site Scripting (XSS) e il Broken Access Control, che sono presenti nella lista OWASP Top 10.

I vulnerability assessment e i penetration test sono la prima risposta alle minacce informatiche che sfruttano le vulnerabilità di sicurezza, ma per molte aziende la creazione di un piano di vulnerability management rappresenta un piano “work in progress” o addirittura non realizzabile.

Quali sono le principali difficoltà nella creazione di un efficace piano di pentesting?

Vediamo quali sono le principali difficoltà nella creazione di un efficace vulnerability management process e piano di pentesting:

• Talent matching: è difficile ingaggiare esperti di sicurezza informatica con competenze specifiche di penenetration test;
• Spese: spesso le aziende non sanno determinare un budget per un penetration test o addirittura non viene messo a budget nemmeno un euro;
• Tempistiche: tra engagement, scoping ed esecuzione, la realizzazione di un penetration test può richiedere molto tempo, soprattutto se non si adottano delle metodologie consolidate per la sua pianificazione.

Esistono però altri controlli di sicurezza che le aziende possono adottare in autonomia e inserire, ad esempio, nel ciclo di vita dello sviluppo software (SDLC) per trovare e correggere le vulnerabilità prima della messa in produzione il codice.

Secure Development Lifecycle: come rendere sicuro un software

Le tecniche di seguito descritte fanno parte dei cosiddetti principi di “Secure Software Development”.

Si tratta di processi di sviluppo software per creare un ciclo di vita di sviluppo sicuro, il cosiddetto Secure Development Lifecycle (SDL):

• Code Review: anche chiamata peer review, che consiste nella revisione del codice da parte di tecnici non coinvolti nella scrittura del codice sorgente. L’attività può essere svolta anche sotto forma di audit esterno, per aumentare il livello di imparzialità della verifica
• Threat Modeling: un processo da attivare giù dalla fase di progettazione del software in maniera proattiva (security by design e security by default), che serve a mappare e gestire le potenziali minacce considerando, tra gli altri aspetti, l’ambiente in cui sarà effettuato il deploy della soluzione e chi la utilizzerà. Anche in questo caso, approccio proattivo e reattivo devono coesistere, perché l’evoluzione dinamica del ciclo di vita di un software non permette di prevedere a priori tutte le security issues dalla nascita del prodotto
• Playbooks & Training: la redazione di manuali operativi e la formazione periodica sulle Secure-Development Best Practices (come le OWASP Secure Coding Practices o il Secure Software Development Framework pubblicato dal NIST) diminuiscono il rischio collegato all’inesperienza delle risorse junior e al turnover del personale
• DAST/SAST/IAST Analysis: test sugli applicativi realizzati in forma statica (static application security testing o test white-box, sul codice sorgente), dinamica (Dynamic application security testing o test black-box, sul codice compilato) o interattiva (interactive application security testing, ovvero durante in real-time durante l’esecuzione dell’applicazione stessa)
• Abuse Case Tests: creazione di scenari di utilizzo dannoso (e non previsto) del software, da parte di un team composto non solo da sviluppatori, ma anche da business analyst e project manager
• Fuzzing (fuzz testing): tecnica di test automatizzato di tipo black-box, che consiste nell’individuare bug software immettendo dati malformati

Prevenire i rischi: vulnerability management process e ruolo del pentesting

La prevenzione delle vulnerabilità è senza alcun dubbio la strada migliore da seguire.

L’uso combinato di queste tecniche rappresenta un’ottima soluzione per ridurre al minimo i rischi.

Infatti, il solo penetration test non può assicurare la sicurezza delle applicazioni, ma solo aiutare a rilevare le criticità.

Ad esempio, il pentesting può aiutare a convalidare tutti i findings ottenuti dalle altre analisi.

Per rimanere aggiornato sull’argomento, scopri come BIT4LAW opera in ambito di IT audit e pentesting e quali servizi offrire nel campo della security.