Domande di esempio per test di cybersecurity: cosa chiedere (e perché)

Perché la trivia generica di security fallisce

La maggior parte delle valutazioni di cybersecurity chiede liste CVE, OWASP a memoria o comandi di tool. Una candidata che recita la OWASP Top 10 o descrive AES-256 in dettaglio potrebbe essere competente. O potrebbe essere brava a leggere checklist. La valutazione non te lo dice.

Il vero lavoro di security è ragionamento sulle minacce sotto ambiguità. Individuare la misconfiguration sottile. Decidere cosa vale la pena patchare vs cosa è rischio accettabile. Spiegare un trade-off a uno stakeholder scettico. Quelle skill non vengono dalla memorizzazione.

Cosa misura una domanda forte di cybersecurity

Una buona domanda dà alla candidata uno scenario, non una definizione. Le chiede di ragionare attraverso informazioni incomplete, spiegare trade-off e difendere una decisione. La risposta rivela se pensa come una security engineer.

Ecco esempi reali per ruolo.

1. SOC Analyst: triage incident

Scenario: Il tuo SIEM segnala 2.000 tentativi di login falliti a [email protected] tra l'1 e le 3 UTC. Gli IP sono distribuiti su 15 paesi. Stesso username, password diverse. La tua coda alert ha 47 altri item. Cosa fai nei prossimi 15 minuti?

Cosa stai misurando:

• Possono triagare per severity (attacco credential-stuffing vs brute-force vs falso positivo rumoroso)?
• Pongono domande chiarificatrici (l'account è disabilitato, ha MFA, cos'è normale per quest'utente)?
• Possono prioritizzare sotto pressione senza over-escalare?

Risposta debole: "Avvisare subito l'admin." Risposta forte: "Prima, verificare se MFA è abilitato su questo account — se sì, i tentativi falliti non contano. Se no, controllare lo storico cambio password e l'ultimo login riuscito. Se non c'è segnale recente di compromise, documentarlo come credential-stuffing, aggiungere i range IP a una block list se hai capacità, altrimenti deprioritizzarlo dietro account con login riusciti."

2. Penetration Tester: giudizio di vulnerability

Scenario: Trovi un sottodominio (api-old.company.com) che restituisce risposte API senza autenticazione. È vivo ma non documentato in alcun sistema attuale. La superficie API è identica all'API principale. Qual è la severity? Cosa riporti?

Cosa stai misurando:

• Capiscono il rischio context-dipendente (API vecchia potrebbe essere innocua o catastrofica)?
• Possono distinguere tra vulnerability e sfruttabilità?
• Comunicheranno i findings in modo da ottenere azione, non essere liquidati come rumore?

Risposta debole: "Critico. Accesso API non autenticato." Risposta forte: "Potenzialmente alto se questa API è ancora connessa a dati live. Verificherei: fa proxy al DB di produzione, o è una replica? Espone campi sensibili oltre l'API pubblica? Se è vera replica della pubblica, la severity scende. Raccomanderei di disabilitarla del tutto, altrimenti restringerla a una subnet VPN e attivare rate-limiting."

3. Security Engineer: decisione di architettura

Scenario: La tua applicazione deve memorizzare API secret (credenziali DB, chiavi terze). Opzioni: HSM (hardware security module), secret store gestito (AWS Secrets Manager), variabili d'ambiente cifrate o hardcoded (per dev locale). Hai un budget. Fai una raccomandazione e difendila.

Cosa stai misurando:

• Conoscono i trade-off (costo, complessità operativa, frizione developer, guadagno di sicurezza reale)?
• Possono dimensionare il threat model al ruolo (startup vs enterprise)?
• Prendono decisioni che reggono, o over-ingegnerizzano e bruciano credibilità?

Risposta debole: "Usa HSM, è il più sicuro." Risposta forte: "Dipende dal tuo threat model e vincoli. Per una startup: AWS Secrets Manager con policy IAM least-privilege. È gestito (zero carico operativo), auditato, costa ~$0,40/secret/mese. Per un'enterprise con requisiti di compliance: HSM o managed HSM se ti serve FIPS 140-2. Per dev locale: file .env cifrati. Mai niente hardcoded."

4. Cloud security: detection misconfiguration

Scenario: Una developer ti chiede di recensire la sua policy bucket AWS S3:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/public/*"
    }
  ]
}

Dice: "Lì dentro ci sono solo file pubblici." Va bene? Perché o perché no?

Cosa stai misurando:

• Individuano il rischio (wildcard, Principal: "*")?
• Capiscono che le policy cambiano, i bucket crescono, gli errori succedono?
• Applicheranno defense-in-depth o si fideranno della struttura delle directory?

Risposta debole: "Sembra OK se seguono la convenzione di naming." Risposta forte: "No. Una policy che si fida di una convenzione di directory è un fallimento in attesa. Usa il setting S3 Block Public Access a livello account, e usa object tagging o partizionamento bucket con credenziali separate se davvero ti servono oggetti pubblici. Così, anche se qualcuno carica sul prefisso sbagliato, non leakka."

Come usarlo in hiring

Una valutazione forte dà alle candidate 3-4 scenari come questi, tipicamente spalmati su 90 minuti (take-home o proctored). Lasciale spiegare il loro ragionamento in testo o video breve. Valuta su:

• Chiarezza del threat model: Chiedono cosa conta?
• Ragionamento trade-off: Sanno spiegare cosa scelgono e perché?
• Realismo operativo: Propongono cose che funzionano davvero, o ideali teorici?
• Umiltà: Riconoscono incertezza e edge case?

Abbinalo a un colloquio di walk-through per verificare il ragionamento. La valutazione non è sulla risposta — è sul processo di pensiero.

Il ROI delle domande basate su scenari

Se assumi per security, la valutazione basata su scenari non è negoziabile. Filtra candidate che hanno memorizzato certificazioni ma non costruito giudizio. Fa emergere candidate che pensano sistematicamente sui trade-off. E dà al tuo team la chance di vedere come gestiranno decisioni ambigue ad alto stake nella vita reale.

L'alternativa — test basati su trivia e colloqui in stile PowerPoint — non correla con il vero giudizio di security. Riserva i check di memorizzazione per le basi. Valuta il giudizio con scenari.