Was prüfen Vorstellungsgespräche für Cyber Security Analysten wirklich?

Wer tatsächlich im Raum sitzt

Bei einer Cyber Security Analyst-Stelle findet das erste Gespräch selten nur mit der Personalabteilung statt. Rechnen Sie von Anfang an damit, dass der SOC-Manager oder ein Senior Analyst dabei ist, denn die entscheidenden Fragen kann niemand stellen, der nicht selbst schon Alerts bearbeitet hat. In kleineren Unternehmen kann es direkt der CISO sein. In größeren gibt es oft zuerst ein technisches Screening (ein Senior Analyst oder Team Lead, 30-45 Minuten, stark auf Szenarien fokussiert), gefolgt von einem Panel mit dem Hiring Manager und manchmal jemandem aus dem IT-Betrieb oder einem Plattform-Team, mit dem Sie zusammenarbeiten würden — denn ein großer Teil der Arbeit besteht aus Eskalieren und Übergeben, nicht nur aus Erkennen.

Wenn das Unternehmen ein ausgereiftes SOC betreibt, treffen Sie möglicherweise auch die Person, die das SIEM verantwortet (Splunk, Microsoft Sentinel, QRadar, Elastic) und die Person, die das EDR verantwortet (CrowdStrike, Defender for Endpoint, SentinelOne). Sie stellen unterschiedliche Fragen, weil sie sich um unterschiedliche Fehlermodi kümmern: Der SIEM-Verantwortliche will wissen, ob Sie eine brauchbare Suchabfrage schreiben können; der EDR-Verantwortliche will wissen, ob Sie zwei Stunden lang einem harmlosen PowerShell-Script nachjagen, weil Sie den Parent-Prozess nicht zuerst geprüft haben.

Die technische Übung: wie sie aussieht

Die meisten technischen Assessments für diese Rolle sind keine Programmiertests. Es sind Triage-Übungen, denn Triage ist die Arbeit. Gängige Formate:

• Alert-Triage in einem sandboxed SIEM oder einem Screenshot-Paket. Sie erhalten eine Handvoll Alerts — ein Login aus ungewöhnlicher Geografie, ein Anstieg ausgehender DNS-Abfragen, eine EDR-Erkennung als "suspicious" statt "malicious" markiert — und werden gebeten zu sagen, welche Sie eskalieren, welche Sie schließen würden und warum. Der Interviewer beobachtet Ihre Argumentation, nicht Ihre finale Antwort.
• Ein pcap oder Log-Auszug. Sie bekommen möglicherweise Wireshark-Output oder rohe Firewall-Logs und werden gebeten zu rekonstruieren, was passiert ist: Ist das ein Port-Scan, ein gescheiterter Brute-Force-Versuch, C2-Beaconing in ungewöhnlichem Intervall. Manche Unternehmen verwenden stattdessen eine Phishing-E-Mail mit Headern und bitten Sie, die Received-Kette zu lesen und SPF/DKIM/DMARC-Ergebnisse zu beurteilen.
• Ein Tabletop-Incident-Szenario. "Ransomware-Nachricht erscheint am Freitag um 16 Uhr auf einem Laptop aus der Finanzabteilung. Führen Sie mich durch die nächste Stunde." Dies testet, ob Sie die Struktur des NIST 800-61 Incident-Lifecycle kennen — Identification, Containment, Eradication, Recovery, Lessons Learned — ohne ihn als Liste aufzusagen. Gute Kandidaten isolieren den Host, bevor sie fragen, wer verantwortlich ist.
• Ein Take-home, seltener als noch vor ein paar Jahren. Üblicherweise ein schriftlicher Incident-Report aus einem gegebenen Log-Satz oder ein kurzes Threat Model für ein hypothetisches System. Wenn Sie eines bekommen, prüfen die Interviewer, ob Sie für jemanden schreiben können, der nicht im Raum war — denn Incident-Reports werden von Leuten gelesen, die nicht im Call waren.

Was selten getestet wird, trotz dessen was generische Interview-Guides nahelegen, ist ob Sie das OSI-Modell aufsagen oder "Zero Trust" aus dem Gedächtnis definieren können. Das kommt höchstens als Aufwärmfrage. Die Übung existiert, um zu sehen, was Sie tun, wenn der Alert mehrdeutig ist, denn die meisten Alerts sind mehrdeutig.

Die Fragen, die tatsächlich Kompetenz prüfen

Manche Fragen klingen wie Small Talk, sind es aber nicht. Hier ist, was sie wirklich prüfen:

"Erzählen Sie mir vom letzten False Positive, den Sie geschlossen haben." Das ist kein Gedächtnistest. Es prüft, ob Sie verstehen warum es ein False Positive war — den Mechanismus, nicht nur das Label — und ob Sie danach etwas getuned haben oder einfach nur auf Schließen geklickt haben. Ein Analyst, der nicht beschreiben kann, wie er eine Detection Rule getuned oder eine störende Quelle unterdrückt hat, hat den Job nicht lange genug gemacht, um das von ihm erzeugte Rauschen zu reduzieren.

"Was ist Ihr Vorgehen, wenn Sie einen Alert bekommen, den Sie nicht verstehen?" Sie hören auf eine Abfolge: Asset prüfen (ist es ein Domain Controller oder jemandes Laptop), normales Verhalten des Accounts prüfen, verwandte Events in einem Zeitfenster um den Alert herum ziehen, prüfen ob der IOC anderswo auftaucht, dann entscheiden. Wenn die Antwort direkt zu "Ich würde eskalieren" springt, ist das für einen erfahrenen Interviewer ein Red Flag, denn alles zu eskalieren ist das, was jemand tut, der nicht weiß, wie man investigiert.

"Erzählen Sie mir von einem Vorfall, bei dem Sie falsch lagen." Das ist absichtlich unangenehm. Analysten, die nur Tickets bearbeitet, aber keine echten Incidents erlebt haben, haben oft keine Antwort, denn falsch zu liegen erfordert, unter Unsicherheit eine Entscheidung getroffen zu haben. Interviewer nutzen das, um Leute zu unterscheiden, die einem Runbook gefolgt sind, von Leuten, die um 2 Uhr morgens mit unvollständigen Informationen ein Urteil fällen mussten.

"Wie halten Sie Threat Intel aktuell, und wie verändert das, worauf Sie achten?" Nicht "Lesen Sie Blogs". Sie wollen wissen, ob Sie eine spezifische Feed oder Quelle benennen können (Threat Research eines Vendors, ein ISAC, eine interne IOC-Liste aus einem früheren Incident) und, wichtiger noch, ein Beispiel einer Detection oder Hunt geben können, die Sie aufgrund von etwas gebaut haben, das Sie gelesen haben — nicht nur, dass Sie eine Mailingliste abonniert haben.

Fragen zu MITRE ATT&CK verlangen normalerweise nicht, dass Sie Taktik-IDs aufsagen. Sie prüfen, ob Sie es als Arbeitswerkzeug nutzen: Können Sie eine beobachtete Technik (etwa T1053 für Scheduled Task Abuse) darauf abbilden, was Sie als nächstes in der Kette erwarten würden, und ob Sie es erkennen würden, wenn Sie es sehen.

Wie eine oberflächliche Antwort klingt

Für jemanden, der tatsächlich ein SOC leitet, sind das die Anzeichen:

• Detection vollständig in Bezug auf Tools beschreiben ("wir haben Splunk und CrowdStrike verwendet") ohne zu erwähnen, wonach Sie gesucht haben oder wie die Query-Logik war. Das SIEM zu nennen ist nicht dasselbe wie zu zeigen, dass Sie es nutzen können.
• "Was ist der Incident-Response-Prozess" beantworten, indem man die NIST-Phasen der Reihe nach auflistet, ohne angehängtes Beispiel. Jeder kann sechs Wörter auswendig lernen. Der Interviewer will einen Incident, bei dem Containment schwieriger war als das Lehrbuch es darstellt — weil ein Produktionssystem, das man nicht einfach vom Netz nehmen kann, oder ein kompromittierter Account, der auch der Account ist, der einen kritischen Service betreibt, dort liegt, wo echtes Urteilsvermögen gefragt ist.
• Jedes Szenario so behandeln, als ob die Antwort "an das Incident-Response-Team eskalieren" wäre, ohne zu zeigen, dass Sie wissen, was dieses Team zuerst übergeben bekommen möchte: Scope, betroffene Hosts, Zeitpunkt des ersten Indikators, ob Containment bereits begonnen hat.
• Vulnerability Management mit Detection verwechseln. Nach einem CVE gefragt werden und nur sagen können "wir würden patchen", ohne kompensierende Controls, Exposure oder Exploitability in Ihrer Umgebung zu erwähnen, deutet darauf hin, dass Sie nicht in einem Patch-Priorisierungs-Meeting gesessen haben.
• Über Zertifizierungen (Security+, CySA+, GCIH, OSCP) als Achievements sprechen statt als Nachweis spezifischer Fähigkeiten. Ein Interviewer, der selbst GCIH hält, wird fragen, was Sie in den Labs gemacht haben, nicht ob Sie bestanden haben.

Was Sie vor Ihrem nächsten Interview tun sollten

Wählen Sie zwei Incidents oder Investigations aus Ihrer eigenen Arbeit — echte, auch kleine — und seien Sie bereit, sie in ausreichend technischem Detail zu beschreiben, dass ein anderer Analyst der Argumentation folgen könnte: Was den Alert ausgelöst hat, was Sie ausgeschlossen haben und wie, was Sie anders machen würden. Das ist nützlichere Vorbereitung als jede Liste generischer Fragen, denn es ist das, was der Interviewer tatsächlich von Ihnen zu hören versucht.

Wenn Sie sich gleichzeitig auf mehrere SOC- oder Analysten-Stellen bewerben und die Anzeigen alle nach leicht unterschiedlichen Tool-Kombinationen fragen (hier Sentinel, dort QRadar, eine SOAR-Plattform, die Sie nur einmal angefasst haben), liest jobmarket.pro jede Anzeige vollständig und erstellt eine Bewerbung aus Ihrer tatsächlichen Erfahrung, ohne Vertrautheit mit Tools zu erfinden, die Sie nicht benutzt haben.