Quando si esegue una scansione di sicurezza, il problema non è sempre trovare le vulnerabilità. Spesso è capire da dove cominciare.
Un report può contenere numerosi risultati: alcuni riguardano configurazioni migliorabili, altri software obsoleto, altri ancora problemi che potrebbero permettere a un attaccante di compromettere un sistema.
Se ogni rilievo viene trattato allo stesso modo, si rischia di perdere tempo su problemi secondari mentre quelli più importanti rimangono irrisolti.
Per questo la gestione delle vulnerabilità non dovrebbe limitarsi a produrre un elenco di risultati. Deve aiutare a decidere quale problema affrontare per primo, perché e con quale urgenza.
Perché il numero di vulnerabilità non basta?
Immaginiamo due sistemi.
Il primo presenta dieci rilievi relativi a configurazioni migliorabili, senza un impatto immediato evidente.
Il secondo presenta un solo problema che potrebbe consentire l'accesso non autorizzato a dati sensibili.
Quale dovrebbe essere affrontato per primo?
Non necessariamente quello con più rilievi.
Il numero dei problemi non indica, da solo, il rischio complessivo. Bisogna valutare la natura di ciascun rilievo, il contesto in cui compare e le conseguenze di un'eventuale compromissione.
1. Comprendere la differenza tra rilievo e vulnerabilità confermata
Una scansione può individuare un comportamento sospetto o una configurazione che merita attenzione.
Questo non significa che ogni risultato sia una vulnerabilità confermata.
Per esempio, uno strumento potrebbe rilevare una versione software associata a un problema noto. Prima di concludere che il sistema sia vulnerabile, bisogna verificare se il componente sia effettivamente presente nella versione interessata e se siano soddisfatte le condizioni necessarie.
È utile distinguere almeno tre stati:
- Da verificare: il risultato suggerisce un possibile problema.
- Confermato: le verifiche hanno dimostrato che il problema è presente.
- Non applicabile o falso positivo: il risultato non descrive una vulnerabilità effettiva nel contesto analizzato.
Questa classificazione evita di confondere gli indizi automatici con problemi già accertati.
2. Valutare la gravità tecnica
Uno dei riferimenti più utilizzati per descrivere la gravità delle vulnerabilità è il CVSS, un sistema di punteggio che aiuta a rappresentare caratteristiche e impatto potenziale di un problema.
Il punteggio può essere utile per organizzare i risultati, ma non dovrebbe essere l'unico criterio utilizzato per decidere l'ordine delle correzioni.
Una vulnerabilità con un punteggio elevato può richiedere condizioni particolari per essere sfruttata. Un problema con un punteggio inferiore può invece essere molto rilevante se interessa un sistema esposto e fondamentale per l'organizzazione.
La gravità tecnica è quindi un punto di partenza, non una decisione automatica.
3. Considerare l'esposizione del sistema
Una vulnerabilità presente su un sistema raggiungibile pubblicamente può avere un profilo di rischio diverso rispetto allo stesso problema su un componente isolato e accessibile soltanto da una rete strettamente controllata.
Per esempio:
Servizio A
→ accessibile da Internet
Servizio B
→ accessibile soltanto da una rete interna
Se entrambi presentano lo stesso problema, l'esposizione può influenzare la priorità.
Questo non significa che i sistemi interni siano automaticamente sicuri. Un attaccante potrebbe riuscire a raggiungerli attraverso altri sistemi compromessi o percorsi di accesso non previsti.
La valutazione deve considerare l'architettura reale.
4. Capire cosa protegge il sistema
La criticità dell'asset è un altro fattore fondamentale.
Un problema su un sito informativo potrebbe avere conseguenze differenti rispetto a una vulnerabilità che interessa:
- un sistema di autenticazione;
- un database con dati personali;
- un'API che gestisce pagamenti;
- un pannello amministrativo;
- un servizio utilizzato da molte applicazioni.
Per questo è utile associare ogni rilievo all'asset interessato e al suo ruolo nell'infrastruttura.
Senza questo contesto, anche un report tecnicamente accurato può risultare poco utile dal punto di vista operativo.
5. Verificare se esistono prove di sfruttamento
Alcune vulnerabilità sono note e potrebbero essere già utilizzate in attacchi reali.
Quando esistono indicazioni attendibili di sfruttamento attivo, questo elemento può aumentare sensibilmente l'urgenza della verifica e della correzione.
Bisogna inoltre distinguere tra:
- vulnerabilità teoricamente sfruttabile;
- vulnerabilità per cui esiste un exploit pubblico;
- vulnerabilità per cui sono documentati attacchi reali;
- compromissione effettiva del proprio sistema.
Sono situazioni differenti e richiedono risposte diverse.
Se emergono indizi di compromissione, non basta applicare una patch: potrebbe essere necessario attivare le procedure di risposta agli incidenti e verificare eventuali accessi non autorizzati.
6. Valutare l'impatto aziendale
La priorità non dipende soltanto dalla tecnologia.
Occorre considerare anche le conseguenze per l'organizzazione.
Un problema potrebbe compromettere la riservatezza dei dati, interrompere un servizio essenziale o consentire modifiche non autorizzate.
Per esempio, una vulnerabilità su un servizio che gestisce ordini e pagamenti potrebbe avere un impatto operativo ed economico maggiore rispetto a un problema analogo su una pagina secondaria.
Questo contesto aiuta a stabilire quanto rapidamente intervenire e quali persone coinvolgere.
Un modello pratico per assegnare le priorità
Per ogni rilievo è utile raccogliere almeno queste informazioni:
| Criterio | Domanda da porsi | | ------------------------ | -------------------------------------------------- | | Gravità tecnica | Quanto può essere serio il problema? | | Esposizione | Il sistema è raggiungibile da Internet? | | Sfruttabilità | Esistono condizioni realistiche per sfruttarlo? | | Asset interessato | Quale servizio o dato potrebbe essere compromesso? | | Sfruttamento noto | Esistono prove attendibili di attacchi in corso? | | Affidabilità del rilievo | Il problema è confermato o soltanto ipotizzato? | | Impatto operativo | Quali conseguenze avrebbe una compromissione? |
Non serve necessariamente costruire subito un algoritmo complesso. Anche una valutazione strutturata e documentata è meglio di un elenco ordinato soltanto per punteggio.
Esempio: tre rilievi, tre priorità differenti
Immaginiamo di ricevere questi risultati:
| Rilievo | Contesto | Valutazione iniziale | | ------------------------------------- | ------------------------------------------------------------------------ | --------------------------------- | | Software con vulnerabilità nota | Servizio pubblico, problema confermato e sfruttamento attivo documentato | Urgente | | Pannello amministrativo raggiungibile | Autenticazione presente, configurazione da verificare | Approfondire in base ai controlli | | Header HTTP migliorabile | Informazione tecnica non sensibile | Generalmente secondario |
La tabella è un esempio illustrativo, non una regola universale.
Se il pannello amministrativo permettesse accessi non autorizzati o il problema sugli header rivelasse credenziali valide, le priorità cambierebbero radicalmente.
È il contesto a determinare il rischio effettivo.
7. Definire una scadenza e un responsabile
Un rilievo non dovrebbe rimanere indefinitamente nello stato "da correggere".
Per ogni problema confermato è utile stabilire:
- chi è responsabile;
- quale azione deve essere eseguita;
- entro quando;
- come verrà verificata la correzione;
- quale rischio residuo rimarrà.
Le scadenze dovrebbero essere proporzionate alla gravità e alle procedure interne. I problemi urgenti richiedono interventi tempestivi, mentre quelli meno critici possono essere inseriti in un piano di manutenzione.
Se una correzione non è immediatamente possibile, si possono valutare misure temporanee di mitigazione, documentando il rischio residuo e la data prevista per la soluzione definitiva.
8. Verificare che la correzione abbia funzionato
Chiudere un'attività perché è stata applicata una modifica non significa necessariamente aver risolto il problema.
Dopo l'intervento, è importante verificare che:
- il componente sia stato aggiornato correttamente;
- la configurazione sia effettivamente cambiata;
- il servizio non esponga più il problema;
- non siano state introdotte regressioni;
- il risultato della verifica sia registrato.
Quando opportuno, si può ripetere il controllo che aveva individuato il rilievo.
Questo passaggio permette di distinguere una correzione realmente verificata da una modifica semplicemente dichiarata come completata.
Gli errori più comuni nella gestione delle vulnerabilità
Tra gli errori da evitare troviamo:
- correggere soltanto i rilievi con il punteggio più alto;
- considerare ogni risultato automatico una vulnerabilità confermata;
- ignorare i servizi pubblici non riconosciuti;
- trascurare le vulnerabilità note perché il sistema sembra funzionare correttamente;
- non assegnare un responsabile;
- applicare una correzione senza verificarne l'efficacia;
- chiudere i rilievi senza documentare il rischio residuo.
Una gestione efficace richiede un processo continuo, non soltanto una scansione occasionale.
In sintesi
Dare priorità alle vulnerabilità significa combinare gravità tecnica, esposizione, sfruttabilità, criticità dell'asset e impatto potenziale.
Un report è davvero utile quando aiuta a rispondere a tre domande:
- Quali problemi sono effettivamente presenti?
- Quali possono causare le conseguenze più gravi?
- Quali azioni devono essere eseguite e verificate per prime?
MiHakero è pensato per aiutare a individuare e organizzare i problemi di sicurezza osservabili dall'esterno, rendendo più semplice capire quali esposizioni richiedono un approfondimento e quali interventi meritano maggiore attenzione.