Wie man Cybersecurity-Engineers bewertet: der richtige Weg
Die Security-Hiring-Falle
Die meisten Firmen bewerten Cybersecurity-Talent gleich wie jede Engineer: Code-Tests und Trivia. Eine Security-Engineer schreibt Code. Sie sollte gut in Algorithmen und Systems-Design sein. Aber wenn du nur basierend darauf hirest, verpasst du das tatsächliche Security-Signal.
Der Fix ist, Bewertung zu bauen, die misst, was Security-Engineers tatsächlich tun: Threat-Modeling, Trade-off-Reasoning und architektonisches Urteil.
Drei Bewertungs-Komponenten, die funktionieren
1. Threat-Modeling-Szenario (30 Min, Take-Home)
Das Format: Beschreibe ein System (z.B. "eine Web-App für Healthcare-Scheduling mit User-Authentication, Calendar-Sharing und Termin-Reminders via SMS"). Bitte die Kandidatin, die Top 3 Sicherheitsrisiken zu identifizieren, nach Severity zu ranken und die Mitigation für das höchste zu erklären.
Was du misst:
- Können sie aus Angreifer-Perspektive denken?
- Berücksichtigen sie die volle Attack-Surface?
- Können sie Risiko nach Likelihood und Impact ranken, nicht nach Fear-Factor?
- Sind ihre Mitigations praktisch oder theoretisch?
Was eine gute Antwort ist: Nicht "stelle sicher, dass du HTTPS und parameterized Queries nutzt" — das weiß jeder. Eine gute Antwort sieht aus wie: "Das höchste Risiko ist SMS-Interception für Termin-Reminders, weil der SMS-Channel unverschlüsselt ist und ein Angreifer mit SMS-Zugriff Termine umplanen oder Patienten-Namen lesen kann. Mitigation: sende keine Patienten-Identifier in SMS, nur einen Code für lokales Lookup."
2. Code-Review + Vulnerability-Urteil (45 Min)
Präsentiere einen realistischen Code-Snippet mit eingebetteter Security-Lücke.
Python-Snippet mit SQL-Injection-Risiko:
query = f"SELECT * FROM users WHERE email = '{email}'"
Aber frage: "Was ist das tatsächliche Risiko hier?" Eine Kandidatin, die "SQL-Injection" sagt, hat technisch recht, aber unvollständig. Eine, die sagt "SQL-Injection, ja, aber nur wenn Email-Input nicht erst validiert wird — was ist die Validierung?" denkt wie eine Security-Engineer.
3. Architektur-Bewertung: Defense-in-Depth (60 Min)
Gib ihnen ein Architektur-Problem: "Designe die Authentication-Schicht für eine Plattform mit Public- und Private-APIs, wo Token-Compromise katastrophal ist."
Was du misst:
- Schichten sie Defenses (Tokens + Rate-Limiting + IP-Restrictions)?
- Können sie erklären, warum ein einzelner Control nicht genug ist?
- Denken sie über Detection und Recovery, nicht nur Prevention?
Wie die Bewertung gewichten
Für Security-Generalisten:
- 40% Threat-Modeling
- 30% Code-Review
- 30% Architektur
Das Follow-up ist wichtig
Async-Bewertung gibt dir Signal, ist aber nicht komplett. Im Follow-up: "Geh durch dein Threat-Model. Was hast du verpasst?" "Wie würdest du diese Mitigation einer Engineer erklären, die sagt 'das ist overkill'?"
Was NICHT zu bewerten
- Memorisierte OWASP Top 10 (können googeln)
- "Welche Cipher ist am besten?"-Trivia
- Geschwindigkeit beim Lösen von LeetCode-Puzzles
- Spezifische Zertifizierung bestehen
Bauen vs. Kaufen
Einige Plattformen bieten vorgefertigte Cybersecurity-Bewertungen. Sie sind ein Startpunkt. Aber die besten Bewertungen sind auf deine Rolle und dein Threat-Model customized. Kaufe die Plattform; baue die Fragen.
ClarityHire bietet anpassbare Security-Bewertungen mit Live-Coding-Räumen, File-Uploads für Architektur-Diagramme und Multi-Stage-Bewertung.
Das Outcome
Bewerte Threat-Reasoning, keine Trivia, und du wirst Engineers hiren, die per Default defensiv denken. Diese Engineers werden zu Force-Multipliern.