Una valutazione delle vulnerabilità aiuta a individuare e analizzare i punti deboli in un insieme concordato di sistemi. Un penetration test verifica se tali punti deboli possono essere sfruttati per raggiungere un obiettivo preciso, come accedere a dati protetti. Entrambi gli approcci sono utili, ma rispondono a domande diverse. Per scegliere la verifica, definite prima la decisione che i suoi risultati dovranno sostenere.
Se è necessario un elenco di problemi per la risoluzione regolare, iniziare con una valutazione delle vulnerabilità. Se è necessario verificare un percorso di attacco specifico o la resilienza di un’applicazione importante in uno scenario definito, considerare un test di penetrazione. Nessun report garantisce la protezione contro ogni attacco. Ogni test ha dei limiti in termini di tempo, ambito, accesso e azioni consentite.
Comprendere che cosa verifica ciascun approccio
Valutazione delle vulnerabilità: dal rilevamento ai risultati verificati
Una valutazione può includere scansioni automatizzate, controlli di configurazione e analisi manuale dei risultati. Uno scanner confronta i componenti e il loro stato scoperti con i segni noti di problemi. Uno specialista conferma se i risultati sono applicabili, rimuove duplicati e falsi positivi, valuta le conseguenze e propone azioni. Un’esportazione da uno scanner non è quindi equivalente a una valutazione completa.
Un test esterno mostra la parte di un sistema accessibile dall’esterno. Un test interno esamina le condizioni all’interno di una rete o ambiente concordato. Un test con credenziali può rivelare più informazioni sulle versioni e le impostazioni rispetto all’osservazione esterna, ma la sua copertura dipende dai permessi concessi e dal successo dell’accesso. Un fallimento nell’autenticazione dello scanner non dimostra l’assenza di vulnerabilità. Scegliere queste opzioni per l’attività, piuttosto che presumere che un metodo sia il migliore.
Penetration test: verifica di uno scenario concordato
I tester indagano sul bersaglio autorizzato e cercano di confermare un percorso verso un risultato significativo. Possono combinare diverse debolezze che appaiono meno serie individualmente. Il lavoro combina strumenti e analisi manuale. L’exploit, l’escalation dei privilegi, l’accesso ai dati e il test della risposta dei controlli di protezione sono consentiti solo entro i limiti concordati.
Un test non deve coprire ogni dispositivo e ogni possibile attacco. A volte, la semplice prova di un potenziale accesso, senza copiare dati reali, è sufficiente per confermare un rischio. Le regole del gioco definiscono la profondità. Il fallimento nel riprodurre un attacco entro il tempo previsto non significa che il percorso sia impossibile.
Confrontare i metodi in base alle condizioni operative
|
Criterio |
Valutazione delle vulnerabilità |
Penetration test |
|---|---|---|
|
Domanda principale |
Quali debolezze sono state individuate, quali sistemi sono interessati e cosa deve essere riparato? |
È possibile che specifiche debolezze o la loro combinazione raggiungano l’obiettivo concordato? |
|
Ambito |
Un insieme definito di risorse, servizi e metodi di accesso. Spesso è necessario un’ampia copertura, ripetibile. |
Applicazioni, ambienti o scenari concordati. L’ambito può essere ristretto o ampio a seconda del compito. |
|
Metodo |
Scansione, revisione della configurazione e analisi per verificare se i risultati sono applicabili. |
Indagine di scenari, test manuali e conferma autorizzata della fattibilità di un attacco. |
|
Autorizzazione |
È necessario ottenere l’approvazione del proprietario, definire i limiti, i metodi e le condizioni di partenza. |
È necessario stabilire regole scritte che definiscano chiaramente le azioni consentite e quelle vietate. |
|
Rischio operativo |
Anche i test attivi possono causare sovraccarico o interrompere un servizio critico. |
I tentativi di sfruttamento aumentano il rischio di impatto; sono necessarie condizioni di arresto e ripristino. |
|
Risultato |
Una lista di risultati verificati, prove, applicabilità, raccomandazioni e limitazioni di ambito. |
Percorsi confermati, risultati ottenuti, limitazioni, prove e raccomandazioni. |
|
Frequenza |
Ripetere in base al rischio, alle modifiche e ai requisiti applicabili. L’automazione aiuta, ma non sostituisce l’analisi. |
Eseguire quando è necessario testare uno scenario, dopo modifiche significative e in conformità con i requisiti applicabili. |
|
Limite principale |
Non tutti i risultati di scansione sono reali; errori sconosciuti e logiche complesse potrebbero rimanere inosservati. |
Tempo, conoscenza del team e azioni consentite limitano la profondità. Non è garantito l’ottenimento di risultati esaustivi. |
La sola dimensione dell’azienda non determina il metodo. Un piccolo sviluppatore potrebbe aver bisogno di un test approfondito di un’applicazione client, mentre un’organizzazione di grandi dimensioni necessita di valutazioni regolari su numerosi dispositivi. Confrontare le offerte con lo stesso ambito e risultato atteso. Il costo dipende dalla complessità, dall’accesso, dallo sforzo manuale, dalla generazione di report e dai test di verifica. Un prezzo o una durata universali non sarebbero utili.
Scegliere la prova in base all’obiettivo
|
Situazione |
Scelta pratica |
Condizione per un risultato utile |
|---|---|---|
|
Manca un elenco affidabile dei punti deboli dei sistemi gestiti |
Una valutazione della vulnerabilità con copertura e applicabilità verificate. |
Sono disponibili i proprietari degli asset e le persone in grado di analizzare e risolvere i risultati. |
|
È necessario testare l’accesso ai dati di altri utenti prima del lancio di un’applicazione importante. |
Test di penetrazione mirati, con scenari e account autorizzati per diversi ruoli. |
L’ambiente, i dati sicuri e le regole di test sono preparati; gli sviluppatori sono pronti a risolvere i problemi. |
|
Esistono strumenti di protezione, ma la loro capacità di bloccare un particolare percorso di attacco è incerta. |
Testare lo scenario concordato. Se necessario, testare separatamente la rilevazione e la risposta. |
La valutazione della risposta è inclusa nell’incarico, con ruoli e metodi di notifica concordati. |
|
Esiste un lungo elenco di problemi noti senza interventi assegnati |
Prima analizzare, stabilire le priorità e correggere i problemi verificati. |
Commissionare un nuovo test per risolvere un’incertezza specifica, piuttosto che sostituire il lavoro su problemi noti. |
|
L’infrastruttura è cambiata o un problema importante è stato risolto. |
Rivalutare l’ambito interessato o eseguire un test mirato del percorso di attacco precedente. |
La modifica è stata verificata e sono chiare eventuali dipendenze correlate che il lavoro potrebbe aver influenzato. |
Dopo un incidente, eseguire innanzitutto la risposta concordata, preservare le prove e limitare l’impatto. Un test di penetrazione programmato non sostituisce un’indagine. Concordare le soluzioni di test e i percorsi di attacco rimanenti dopo la stabilizzazione, in modo da non interferire con il recupero e l’analisi.
Una valutazione della conformità, un programma per ricercatori esterni per individuare vulnerabilità e un esercizio di sicurezza del team hanno i propri obiettivi e regole. Non sono automaticamente sinonimi di test di penetrazione. Se il cliente si aspetta un test di rilevamento o di risposta del personale, includerlo separatamente nell’incarico invece di considerarlo una parte obbligatoria di ogni test.
Preparare l’ambito e condizioni di lavoro sicure
Ottenere l’autorizzazione dal proprietario del sistema autorizzato. Per i servizi esterni e l’infrastruttura cloud, verificare i termini del fornitore. Un contratto di una società con un testatore non autorizza il test delle risorse di un’altra azienda. Registrare gli indirizzi, le applicazioni, gli account e gli ambienti consentiti. Specificare le esclusioni, gli impatti vietati e il processo per approvare le modifiche dello scopo separatamente.
- Indicare l’obiettivo, le date, il periodo di lavoro, il punto di partenza e le informazioni che il team riceve in anticipo.
- Definire se sono consentite le verifiche attive, i tentativi di sfruttamento, i test del personale e l’accesso ai dati. L’assenza di un divieto non sostituisce l’autorizzazione.
- Assegnare i contatti operativi e di emergenza, le condizioni di interruzione immediata e un processo di ripresa.
- Accordo sui limiti di carico, sulle misure di ripristino e sulla preparazione dei backup, nel caso in cui i test possano compromettere le operazioni. Discutere prima un metodo di test sicuro per i sistemi sensibili.
- Descrivere la protezione dei risultati, la conservazione delle prove, la consegna del rapporto e la rimozione dell’accesso temporaneo e dei dati. Le password e i dati sensibili non devono comparire nei rapporti accessibili al pubblico.
Anche la quantità di informazioni iniziali influisce sul risultato. I test senza modelli di progettazione interni limitano la conoscenza, ma la scoperta consuma tempo. Fornire l’architettura e l’accesso consente un test più approfondito delle condizioni selezionate. Questo non è una scala di qualità. L’approccio deve corrispondere alla domanda del cliente. Registrare le informazioni fornite e i vincoli attivi in modo da poter confrontare i risultati.
Concordare il rapporto e seguire i risultati attraverso la verifica della risoluzione.
Che cosa dovrebbero contenere i risultati
- Breve conclusione per il responsabile del processo: cosa è stato testato, cosa è stato riscontrato e quale decisione è necessaria.
- Ambito reale, date, metodi, accesso, esclusioni e controlli falliti. Gli asset non testati devono rimanere visibili nel rapporto.
- Per ogni riscontro: asset interessato, condizioni scatenanti, prove, livello di confidenza e possibili conseguenze.
- Raccomandazioni con un effetto atteso chiaro. I test di penetrazione devono anche includere una descrizione del percorso confermato e del risultato ottenuto entro i limiti consentiti.
- Il processo per segnalare i risultati critici durante i test, i criteri per il ripetuto test e le regole per la consegna del rapporto tecnico dettagliato.
La gravità tecnica aiuta a confrontare i risultati, ma non sostituisce la valutazione della loro importanza per un determinato sistema. La priorità di risoluzione tiene conto anche dell’accessibilità del percorso di attacco, dell’exploit confermato, del ruolo dell’asset e dei vincoli esistenti. Mantenere la matrice di priorità dettagliata separatamente. L’assegnazione del test deve fornire prove sufficienti per riempirla.
Chi segue gli interventi dopo la consegna del rapporto
Assegnare un responsabile a ogni problema confermato e un implementatore per la sua risoluzione. Concordare tempi, dipendenze e una finestra di modifica sicura. Se un risultato è contestato, richiedere un controllo di applicabilità e conservare le motivazioni. Eliminare i falsi positivi attraverso le prove, non perché la risoluzione sia scomoda. Documentare qualsiasi impossibilità di apportare modifiche immediatamente come decisione temporanea con un responsabile e una data di revisione.
Dopo la modifica, testare il componente pertinente e le condizioni che hanno precedentemente scatenato il problema. Per una catena di attacchi confermata, verificare che il percorso verso l’obiettivo sia stato rimosso, piuttosto che solo un singolo risultato visibile. Testare l’operatività dell’applicazione separatamente. Un ripetuto test può confermare una specifica soluzione, ma non rende permanentemente sicuro l’intero ambiente. Restituire i risultati al normale processo di gestione delle vulnerabilità.
Confermare la frequenza dei test e i formati richiesti rispetto ai contratti, ai requisiti e al loro ambito applicabili. Non inferire lo stesso obbligo per ogni azienda semplicemente dal nome di un settore o di uno standard. Richiedere il requisito esatto e il criterio di accettazione prima di scegliere un fornitore. La valutazione delle vulnerabilità e i test di penetrazione possono complementarsi, ma uno non soddisfa automaticamente un requisito per l’altro.
Se è necessario prima ottenere un quadro verificato delle debolezze tecniche, discutere l’attività con i responsabili della sicurezza tramite la pagina Valutazione della sicurezza. Concordare l’ambito, le informazioni iniziali e i risultati attesi della valutazione.
