Hai due preventivi sul tavolo. Entrambi parlano di penetration test, ma uno comprende le funzioni disponibili dopo l’accesso e l’altro non le considera. Il totale finale non basta per confrontarli. Per chi deve commissionare la verifica, il primo lavoro è rendere comprensibile la richiesta, anche senza conoscere già ogni dettaglio tecnico.

Parti dal risultato che vuoi ottenere

Una domanda concreta orienta il test: vuoi verificare l’applicazione prima del rilascio, approfondire l’esposizione dei servizi su Internet oppure capire se un utente può accedere a informazioni riservate ad altri ruoli?

Questi obiettivi possono richiedere perimetri e modalità differenti. La guida NIST SP 800-115 dedica una parte specifica alla pianificazione: sistemi coinvolti, attività consentite, organizzazione e risultati attesi devono essere definiti prima dell’esecuzione. Nella richiesta iniziale basta spiegare il bisogno aziendale; il confronto tecnico servirà a precisarlo.

Raccogli poche informazioni, ma utili

Prima del colloquio, prepara una scheda essenziale. Non occorre un documento perfetto: evidenzia anche ciò che resta da chiarire.

  • Sistemi e ambienti: applicazioni, domini, reti o API da includere; produzione o ambiente di prova; componenti da escludere.
  • Funzioni e utenti: operazioni importanti, ruoli disponibili, integrazioni e flussi che trattano dati rilevanti per l’attività.
  • Accessi: eventuali account di test, documentazione e modalità di collegamento da predisporre.
  • Responsabilità: referente interno, soggetti che gestiscono i sistemi e servizi affidati a fornitori esterni.
  • Vincoli: scadenze del progetto, periodi da evitare e disponibilità delle persone coinvolte.

Un esempio ipotetico: due applicazioni possono esporre lo stesso numero di IP, ma una avere un unico ruolo e l’altra distinguere clienti, operatori e amministratori, con approvazioni e API. I percorsi da esaminare cambiano. OWASP richiama proprio l’importanza di autenticazione, autorizzazioni e logiche applicative nella verifica della sicurezza web.

Concorda anche come si può lavorare

Il perimetro indica che cosa verificare; le regole operative chiariscono come farlo. Servono autorizzazioni, finestre concordate, contatti per le segnalazioni urgenti e criteri per sospendere e riprendere le attività. Sono elementi da chiarire prima dell’avvio e possono influire sulla proposta.

Se un sistema è ospitato o gestito da terzi, verifica con chi lo amministra le procedure e le autorizzazioni applicabili. Le indicazioni PTES per la fase preliminare dedicano attenzione anche a questi rapporti. Il fatto che un’applicazione sia utilizzata dall’azienda non chiarisce, da solo, tutte le condizioni per sottoporla a test.

Chiedi che cosa riceverai alla fine

La proposta dovrebbe precisare destinatari e contenuti del report: una sintesi comprensibile alla direzione, evidenze tecniche utili a chi corregge i problemi, impatto e priorità di intervento. OWASP suggerisce di rendere espliciti anche limitazioni e parti non verificate.

Chiarisci inoltre se è previsto un retest, la verifica successiva delle correzioni: quali rilievi coprirà, entro quale finestra e a quali condizioni. Non darlo per incluso solo perché compare la parola “report”.

Quando arrivano le offerte, torna alla scheda iniziale. Stesso obiettivo, stessi sistemi, accessi e risultati attesi rendono il confronto più utile. Se mancano informazioni, chiedi come verranno risolte: è un buon modo per iniziare il lavoro con responsabilità comprensibili.

Fonti e riferimenti