Pianificare un test di penetrazione: ambito, procedura e costi
Un test di penetrazione esamina sistemi autorizzati dal punto di vista di un attacco. Conta la possibilità di utilizzare i risultati nell’attività, non il numero più elevato di segnalazioni. Descriva obiettivo e limiti perché i fornitori valutino lo stesso incarico. La verifica riguarda un periodo e un ambito definiti, non ogni cambiamento futuro.
Collegare il test a una decisione concreta
Il lancio di un servizio, una modifica importante e la verifica di correzioni richiedono lavori diversi. Indichi la decisione attesa e i processi più importanti. Una scansione automatizzata e un test manuale hanno profondità differenti.
Un elenco di vulnerabilità non spiega da solo l’impatto. Richieda verifiche dei collegamenti rilevanti, per esempio ruoli e diritti di accesso. Un audit organizzativo completo o una certificazione non sono automaticamente inclusi.
Delimitare i sistemi da esaminare
Conteggi separatamente applicazioni e obiettivi di rete. Ruoli, interfacce e flussi complessi possono richiedere più lavoro di un ulteriore host semplice. Definisca che cosa rappresenta ogni obiettivo nel preventivo.
| Ambito | Da chiarire nel preventivo |
|---|---|
| Applicazione web / API | Applicazioni, ruoli, interfacce e flussi importanti |
| Rete interna / esterna | Host, reti e servizi espressamente autorizzati |
| Configurazione cloud | Account, responsabilità e autorizzazioni |
| Applicazione mobile | Piattaforme, versioni e servizi collegati |
Concordare autorizzazioni e regole prima dell’avvio
L’incarico deve autorizzare espressamente il test dei sistemi interessati. Chiarisca piattaforme di terzi e servizi esternalizzati: il loro utilizzo non autorizza l’esame dell’intera infrastruttura. L’elenco dettagliato e gli eventuali accessi saranno scambiati in seguito tramite un canale sicuro.
Concordi finestre temporali, metodi esclusi, limiti di carico, contatti d’emergenza e regole di arresto. Prove di disponibilità, ingegneria sociale e altri metodi particolari richiedono un accordo esplicito. La richiesta di preventivo non è ancora un mandato tecnico.
Scegliere informazioni e ambiente adeguati
Un esame esterno con poche informazioni e un test con account o dettagli architetturali hanno priorità diverse. Chieda perché il metodo proposto risponde all’obiettivo. Meno informazioni non significa automaticamente una verifica più approfondita.
Un ambiente di test può limitare i rischi operativi se riproduce le impostazioni rilevanti. In produzione servono particolare attenzione a protezioni, monitoraggio e coordinamento. Prepari dati neutri e account dedicati senza inserire dossier clienti nel modulo.
Richiedere un rapporto utilizzabile
Il rapporto deve indicare ambito, data, metodo e limiti. I risultati confermati richiedono prove comprensibili, effetti e indicazioni per correggere. Una sintesi e i dettagli tecnici possono servire destinatari diversi.
Stabilisca le priorità secondo il rischio concreto nell’ambiente. Un punteggio tecnico o il numero di risultati non bastano. Definisca trasmissione riservata, conservazione, cancellazione dei documenti e comunicazione dei risultati urgenti.
Confrontare profondità e risultati equivalenti
I costi dipendono da ambito, complessità, informazioni disponibili, esami manuali e documentazione. Distingua preparazione, test, rapporto, discussione e verifica successiva. Una scansione può coprire meno attività di un’analisi della logica operativa.
Confronti sistemi ed esclusioni uguali. Chiarisca obiettivi aggiuntivi, ostacoli imprevisti e modifiche di data. Correzioni e monitoraggio continuativo sono prestazioni separate, salvo inclusione esplicita.
| Voce di costo | Ambito confrontabile |
|---|---|
| Preparazione | Obiettivi, autorizzazioni e accessi di test |
| Esame | Profondità manuale, ruoli, sistemi e finestre |
| Risultato | Rapporto, priorità e discussione |
| Verifica successiva | Correzioni interessate e termine |
| Lavori aggiuntivi | Estensioni, correzioni e altri test separati |
Gestire i risultati e verificare le correzioni
Assegni i risultati importanti a un responsabile e segua le correzioni. La verifica successiva riguarda quanto concordato, non è automaticamente un nuovo esame completo. Ambito e prove attese vanno definiti nel preventivo.
Per una prima richiesta bastano obiettivo, tipi e numero di sistemi, ambiente e calendario. Modifiche importanti e nuove interfacce possono richiedere una nuova valutazione. Il rapporto precedente descrive soltanto lo stato allora esaminato.
Domande frequenti
Una scansione equivale a un test di penetrazione?
La scansione rileva determinati schemi noti. Un test può esaminare manualmente anche collegamenti e impatti. Conta l’ambito concordato.
Si può esaminare la produzione?
Può essere appropriato con finestre, protezioni e regole di arresto concordate. Non è possibile garantire in generale l’assenza di disservizi.
Un esito favorevole prova la sicurezza completa?
No. Riguarda ambito e periodo concordati. Restano possibili aree non esaminate, nuove vulnerabilità e modifiche successive.
La certificazione è inclusa?
Un rapporto non costituisce una certificazione automatica. Criteri, ambito e riconoscimento di attestazioni particolari vanno chiariti prima.
Devo inserire password nella richiesta?
No. Basta una descrizione non riservata. Gli eventuali accessi di test vengono concordati separatamente e scambiati in sicurezza dopo autorizzazione.
Quando serve una verifica successiva?
Dopo la correzione di risultati importanti. Precisi quali correzioni verificare e se sono necessari ulteriori test.
