Întrebări exemplu pentru teste de ciberseguranță: ce să întrebi (și de ce)

De ce trivia generică de securitate eșuează

Majoritatea evaluărilor de ciberseguranță întreabă despre liste CVE, OWASP memorate sau comenzi de unelte. O candidată care recită OWASP Top 10 sau descrie AES-256 în detaliu poate fi competentă. Sau poate fi bună la citit checklist-uri. Evaluarea nu îți spune care.

Munca reală de securitate e despre raționament asupra amenințărilor sub ambiguitate. Detectarea misconfigurației subtile. Decizia ce merită patch-uit vs ce e risc acceptabil. Explicarea unui trade-off către un stakeholder sceptic. Acele abilități nu vin din memorare.

Ce măsoară o întrebare puternică de ciberseguranță

O întrebare bună îi dă candidatei un scenariu, nu o definiție. Îi cere să raționeze prin informații incomplete, să explice trade-off-uri și să apere o decizie. Răspunsul revelează dacă gândește ca o ingineră de securitate.

Iată exemple reale pe roluri.

1. Analist SOC: triajul incidentelor

Scenariu: SIEM-ul tău flag-uiește 2.000 de încercări de login eșuate pe [email protected] între 1am-3am UTC. Adresele IP sunt distribuite în 15 țări. Același username, parole diferite. Coada ta de alerte are 47 de item-uri. Ce faci în următoarele 15 minute?

Ce măsori:

• Pot tria pe severitate (atac de credential-stuffing vs brute-force vs fals pozitiv zgomotos)?
• Pun întrebări clarificatoare (e contul dezactivat, are MFA, ce e normal pentru utilizatorul ăsta)?
• Pot prioritiza sub presiune fără să escaladeze excesiv?

Răspuns slab: "Alertează imediat admin-ul." Răspuns puternic: "Mai întâi, verific dacă MFA e activat pe contul ăsta — dacă da, încercările eșuate nu contează. Dacă nu, verific istoricul de schimbare a parolei și ultimul login reușit. Dacă nu există semnal recent de compromitere, îl documentez ca credential-stuffing, adaug IP range-urile la o listă de blocare dacă am capacitate, altfel îl deprioritizez sub conturile cu login-uri reușite."

2. Pentester: judecata vulnerabilității

Scenariu: Găsești un subdomeniu (api-old.company.com) care întoarce răspunsuri API fără autentificare. E live dar nu e documentat în nici un sistem curent. Suprafața API e identică cu API-ul principal. Care e severitatea? Ce raportezi?

Ce măsori:

• Înțeleg riscul dependent de context (API vechi poate fi inofensiv sau catastrofal)?
• Pot distinge între vulnerabilitate și exploatabilitate?
• Comunică finding-uri într-un mod care primește acțiune, nu e respins ca zgomot?

Răspuns slab: "Critic. Acces API neautentificat." Răspuns puternic: "Potențial înalt dacă acest API e încă conectat la date live. Aș verifica: face proxy către DB-ul de producție, sau e o replică? Expune câmpuri sensibile dincolo de API-ul public? Dacă e replică reală a API-ului public, severitatea scade. Aș recomanda să-l dezactivez complet, dar dacă nu se poate, să-l restricționez la o subnet VPN și să activez rate-limiting."

3. Inginer de securitate: decizie de arhitectură

Scenariu: Aplicația ta trebuie să stocheze secrete API (credențiale DB, chei terțe). Opțiuni: HSM (modul de securitate hardware), secret store gestionat (AWS Secrets Manager), variabile de mediu criptate sau hardcoded (pentru dev local). Ai un buget. Recomandă și apără.

Ce măsori:

• Cunosc trade-off-urile (cost, complexitate operațională, fricțiune dev, câștig real de securitate)?
• Pot dimensiona threat model-ul la rol (startup vs enterprise)?
• Iau decizii care țin, sau over-engineerează și ard credibilitate?

Răspuns slab: "Folosește HSM, e cel mai sigur." Răspuns puternic: "Depinde de threat model-ul tău și constrângerile tale. Pentru un startup: AWS Secrets Manager cu politici IAM least-privilege. E gestionat (fără sarcină operațională), auditat, costă ~$0.40/secret/lună. Pentru enterprise cu cerințe de compliance: HSM sau managed HSM dacă ai nevoie de FIPS 140-2. Pentru dev local: fișiere .env criptate. Niciodată hardcoded."

4. Cloud security: detectarea misconfigurației

Scenariu: O developer îți cere să-i revizuiești politica de bucket AWS S3:

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

Spune: "Doar fișiere publice sunt acolo." E ok? De ce sau de ce nu?

Ce măsori:

• Detectează riscul (wildcard-uri, Principal: "*")?
• Înțeleg că politicile se schimbă, bucket-urile cresc, se întâmplă greșeli?
• Aplică defense-in-depth sau doar au încredere în structura de directoare?

Răspuns slab: "Pare OK dacă urmează convenția de denumire." Răspuns puternic: "Nu. O politică ce are încredere într-o convenție de directoare e un eșec ce așteaptă să se întâmple. Folosește setarea S3 Block Public Access la nivel de cont și folosește object tagging sau partiționare bucket cu credențiale separate dacă chiar ai nevoie de obiecte publice. Așa, chiar dacă cineva încarcă pe prefixul greșit, nu se scurge."

Cum să folosești asta în hiring

O evaluare puternică dă candidatelor 3-4 scenarii ca acestea, tipic distribuite în 90 de minute (take-home sau proctorate). Lasă-le să-și explice raționamentul în text sau prin video scurt. Notează pe:

• Claritate threat model: Întreabă ce contează?
• Raționament trade-off: Pot explica ce aleg și de ce?
• Realism operațional: Propun lucruri care chiar funcționează, sau idealuri teoretice?
• Umilință: Recunosc incertitudinea și edge case-urile?

Perechea asta cu un interviu de follow-up pentru a verifica raționamentul. Evaluarea nu e despre răspuns — e despre procesul de gândire.

ROI-ul întrebărilor bazate pe scenarii

Dacă angajezi pentru securitate, evaluarea bazată pe scenarii e nenegociabilă. Filtrează candidate care au memorat certificări dar nu au construit judecată. Scoate la lumină candidate care gândesc sistematic asupra trade-off-urilor. Și dă echipei tale o șansă să vadă cum vor gestiona decizii ambigue, cu mize mari în viața reală.

Alternativa — teste bazate pe trivia și interviuri tip PowerPoint — nu corelează cu judecata reală de securitate. Salvează verificările de memorare pentru fundații. Evaluează judecata cu scenarii.