Beispielfragen für Cybersecurity-Tests: Was zu fragen ist (und warum)

Warum generische Security-Trivia scheitert

Die meisten Cybersecurity-Bewertungen fragen nach CVE-Listen, OWASP-Memorisierung oder Tool-Befehlen. Eine Kandidatin, die die OWASP Top 10 herunterrasseln oder AES-256 detailliert beschreiben kann, könnte kompetent sein. Oder gut darin, Checklisten zu lesen. Die Bewertung sagt dir nicht, welches.

Echte Security-Arbeit dreht sich um Threat-Reasoning unter Mehrdeutigkeit. Subtile Fehlkonfigurationen erkennen. Entscheiden, was Patching wert ist vs. was akzeptables Risiko ist. Einen Trade-off einem skeptischen Stakeholder erklären. Diese Fähigkeiten kommen nicht von Memorisierung.

Was eine starke Cybersecurity-Frage misst

Eine gute Frage gibt der Kandidatin ein Szenario, keine Definition. Sie bittet sie, durch unvollständige Information zu räsonieren, Trade-offs zu erklären und eine Entscheidung zu verteidigen. Die Antwort offenbart, ob sie wie eine Security-Engineer denkt.

Hier sind echte Beispiele über Rollen.

1. SOC-Analyst: Incident-Triage

Szenario: Dein SIEM flaggt 2.000 fehlgeschlagene Login-Versuche auf [email protected] zwischen 1-3 Uhr UTC. IP-Adressen sind über 15 Länder verteilt. Gleicher Username, jeweils andere Passwörter. Deine Alert-Queue hat 47 weitere Items. Was machst du in den nächsten 15 Minuten?

Was du misst:

• Können sie nach Severity triagieren (Credential-Stuffing-Angriff vs. Brute-Force vs. lautes False-Positive)?
• Stellen sie klärende Fragen (ist der Account deaktiviert, hat er MFA, was ist normal für diesen User)?
• Können sie unter Zeitdruck priorisieren, ohne zu übereskalieren?

Schwache Antwort: "Admin sofort alarmieren." Starke Antwort: "Erst prüfen, ob MFA auf diesem Account aktiviert ist — falls ja, sind fehlgeschlagene Versuche egal. Falls nein, Passwort-Wechsel-Historie und letzten erfolgreichen Login prüfen. Wenn kein neueres Compromise-Signal, als Credential-Stuffing dokumentieren, IP-Ranges zu einer Block-List hinzufügen falls Kapazität, sonst hinter Accounts mit erfolgreichen Logins depriorisieren."

2. Penetration-Tester: Vulnerability-Urteil

Szenario: Du findest eine Subdomain (api-old.company.com), die API-Antworten ohne Authentifizierung zurückgibt. Sie ist live, aber in keinen aktuellen Systemen dokumentiert. Die API-Surface ist identisch mit der Haupt-API. Wie ist die Severity? Was meldest du?

Was du misst:

• Verstehen sie kontextabhängiges Risiko (alte API könnte harmlos oder katastrophal sein)?
• Können sie zwischen Vulnerability und Exploitability unterscheiden?
• Werden sie Findings so kommunizieren, dass Aktion erfolgt, nicht als Noise abgewiesen?

Schwache Antwort: "Kritisch. Unauth API-Zugriff." Starke Antwort: "Potenziell hoch, wenn diese API noch mit Live-Daten verbunden ist. Ich würde prüfen: Proxyt sie zur Production-DB, oder ist es ein Replica? Exposed sie sensitive Felder jenseits der public API? Wenn echtes Replica der public API, fällt Severity. Ich würde empfehlen, sie ganz zu deaktivieren, sonst auf eine VPN-Subnet beschränken und Rate-Limiting aktivieren."

3. Security-Engineer: Architektur-Entscheidung

Szenario: Deine App muss API-Secrets speichern (DB-Credentials, Drittanbieter-Keys). Optionen: HSM (Hardware Security Module), Managed Secret Store (AWS Secrets Manager), verschlüsselte Environment-Variables oder Hardcoded (für lokale Dev). Du hast ein Budget. Mache eine Empfehlung und verteidige sie.

Was du misst:

• Kennen sie die Trade-offs (Kosten, operative Komplexität, Developer-Friktion, tatsächlicher Security-Gewinn)?
• Können sie das Threat-Model auf die Rolle dimensionieren (Startup vs. Enterprise)?
• Treffen sie Entscheidungen, die halten, oder überengineeren und verbrennen Glaubwürdigkeit?

Schwache Antwort: "Nutze HSM, das ist am sichersten." Starke Antwort: "Hängt von deinem Threat-Model und Constraints ab. Für ein Startup: AWS Secrets Manager mit Least-Privilege-IAM-Policies. Es ist managed (keine operative Last), auditiert, kostet ~$0,40/Secret/Monat. Für ein Enterprise mit Compliance-Anforderungen: HSM oder Managed HSM falls FIPS 140-2 nötig. Für lokale Dev: verschlüsselte .env-Dateien. Nie etwas hardcoded."

4. Cloud-Security: Misconfiguration-Detection

Szenario: Eine Developerin bittet dich, ihre AWS-S3-Bucket-Policy zu reviewen:

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

Sie sagt: "Da sind nur public Files drin." Ist das ok? Warum oder warum nicht?

Was du misst:

• Erkennen sie das Risiko (Wildcards, Principal: "*")?
• Verstehen sie, dass sich Policies ändern, Buckets wachsen, Fehler passieren?
• Erzwingen sie Defense-in-Depth oder vertrauen sie nur der Verzeichnisstruktur?

Schwache Antwort: "Sieht ok aus, wenn sie die Naming-Convention befolgen." Starke Antwort: "Nein. Eine Policy, die einer Verzeichnis-Convention vertraut, ist ein wartender Failure. Nutze das S3-Block-Public-Access-Setting auf Account-Ebene und nutze Object-Tagging oder Bucket-Partitioning mit separaten Credentials, wenn du wirklich Public Objects brauchst. So leakt es nicht, selbst wenn jemand auf den falschen Prefix uploaded."

Wie das im Hiring nutzen

Eine starke Bewertung gibt Kandidatinnen 3-4 Szenarien wie diese, typisch über 90 Minuten verteilt (Take-Home oder proctored). Lass sie ihr Reasoning in Text oder per kurzem Video erklären. Bewerte:

• Threat-Model-Klarheit: Fragen sie, was wichtig ist?
• Trade-off-Reasoning: Können sie erklären, was sie wählen und warum?
• Operative Realismus: Schlagen sie Sachen vor, die tatsächlich funktionieren, oder theoretische Ideale?
• Demut: Erkennen sie Unsicherheit und Edge-Cases an?

Paare dies mit einem Walk-Through-Interview, um das Reasoning zu verifizieren. Die Bewertung ist nicht über die Antwort — sie ist über den Denkprozess.

Der ROI von szenariobasierten Fragen

Wenn du für Security hirest, ist szenariobasierte Bewertung nicht verhandelbar. Sie filtert Kandidatinnen heraus, die Zertifizierungen memoriert, aber kein Urteil gebaut haben. Sie zeigt Kandidatinnen, die systematisch über Trade-offs denken. Und gibt deinem Team Chance zu sehen, wie sie mehrdeutige High-Stakes-Entscheidungen im echten Leben handhaben.

Die Alternative — Trivia-basierte Tests und PowerPoint-Interviews — korreliert nicht mit echtem Security-Urteil. Spar dir Memorisierungs-Checks für Grundlagen. Bewerte Urteil mit Szenarien.