Security Analyst vs. Security Engineer: Wo liegt der echte Unterschied?

Die Titel werden in Stellenanzeigen oft synonym verwendet, aber die tägliche Arbeit ist genuinely unterschiedlich. Wenn du dich auf eine Richtung konzentrieren möchtest, wird das Verständnis dieses Unterschieds dir Monate ersparen, in denen du die falschen Zertifikate und Fähigkeiten verfolgen würdest.

Was ein Analyst den ganzen Tag tatsächlich tut

Ein Security Analyst verbringt die meiste Zeit damit, zu überwachen, zu triagieren und zu untersuchen. Das bedeutet, auf einem SIEM (Splunk, Sentinel, QRadar) zu starren, Alert-Queues zu bearbeiten und zu entscheiden, ob ein gekennzeichneter Prozess auf einer Workstation ein False Positive oder der Anfang eines Incidents ist. Ein großer Teil der Arbeit besteht darin, Erkenntnisse so klar zu dokumentieren, dass ein Manager oder ein Client ohne Sicherheitshintergrund versteht, was vorgefallen ist.

Tier-1-Analysten triagieren. Tier-2/3-Analysten graben tiefer — holen Process Trees, prüfen EDR-Telemetrie in Tools wie CrowdStrike oder Defender for Endpoint, korrelieren Logs über Firewalls und Identity Provider hinweg, um eine Zeitleiste zu erstellen. Die Arbeit ist von Natur aus reaktiv: Etwas passiert, du herausfindest, was es bedeutet und was du dagegen tun kannst.

Eine typische Aufgabenliste für einen Analyst: nächtliche Alerts überprüfen, False Positives mit dokumentierter Begründung schließen, eine verdächtige PowerShell-Ausführung eskalieren, ein Runbook nach einem neuen Phishing-Muster aktualisieren und bei einem Incident-Call teilnehmen. Es ist investigative und kommunikationsintensive Arbeit.

Was ein Engineer tatsächlich aufbaut

Ein Security Engineer baut und wartet die Systeme, auf die der Analyst angewiesen ist. Das bedeutet, Detection Rules in Sigma oder KQL zu schreiben, ein SIEM so zu tunen, dass es die Queue nicht mit Noise überschwemmt, EDR-Agents auf 5.000 Endpoints bereitzustellen und zu konfigurieren, oder eine Phishing-Response-Playbook in einer SOAR-Plattform wie Tines oder Cortex XSOAR zu automatisieren.

Engineers arbeiten auch vorgelagert von Incidents: Cloud-Konfigurationen in AWS oder Azure zu härten, Netzwerksegmentierung aufzusetzen, Terraform zu schreiben, um Security-Group-Rules durchzusetzen, CI/CD-Pipelines zu patchen, damit Secrets nicht in die Git-History gelangen. Viel Engineering-Arbeit ist unsichtbar, bis sie fehlschlägt — niemand bemerkt eine gut konfigurierte WAF-Rule, aber alle bemerken es, wenn sie fehlt.

Wo ein Analyst fragt "Was ist hier passiert", fragt ein Engineer "Wie verhindern wir, dass diese Klasse von Problemen überhaupt auftritt, oder wie können wir sie zumindest beim nächsten Mal schneller erkennen." Engineers schreiben häufiger Code — Python für Automatisierung, manchmal Go oder Rust für Tools, YAML und Terraform für Infrastructure.

Fähigkeiten, die die zwei tatsächlich trennen

Analysten brauchen starke Pattern Recognition, Log-Analyse-Kompetenz und die Fähigkeit, Incident Reports unter Zeitdruck zu schreiben. Tools: Splunk SPL, Wireshark, grundlegende Malware-Triage, MITRE ATT&CK-Mapping. Zertifikate, die gut passen: Security+, CySA+, GCIH, manchmal auch GCFA für tiefergehende Forensics-Arbeit.

Engineers müssen tatsächlich Dinge bauen können: Scripting (Python, Bash), Infrastructure-as-Code, API-Integration zwischen Security Tools und genug Systems- und Network-Wissen, um zu verstehen, warum eine Rule die Production bricht. Zertifikate hier tendieren zu GCED, Cloud-Security-Zertifikaten (AWS Security Specialty, AZ-500) und eventuell OSCP, wenn die Rolle eher offensive Aspekte hat.

Die Überschneidung ist real — ein guter Analyst lernt, eigene Enrichment-Queries zu scripten, und ein guter Engineer muss immer noch Logs lesen können, um zu wissen, ob seine Detection tatsächlich feuert. Aber der Schwerpunkt unterscheidet sich: Analysten leben in der Alert Queue, Engineers leben in den Config Files und Code Repos.

Karrierewege und wie Menschen zwischen ihnen wechseln

Die meisten fangen als Analysten an, weil SOC-Rollen mehr Entry-Level-Positionen anbieten und die Lernkurve dir beibringt, wie "normal" in einer echten Umgebung aussieht. Dieses Fundament ist wichtig, auch wenn du später Engineer werden möchtest.

Von Tier-1-Analyst führt ein häufiger Weg zu Tier-2/3-Analyst, dann entweder zu Threat Hunter oder Detection Engineer, eine echte Hybrid-Rolle, die Detections auf Basis dessen schreibt, was Analysten in der Queue übersehen. Von dort wechseln einige komplett in Security Engineering (Plattformen bauen) oder Architecture (ganze Security Programme entwerfen).

Engineers kommen manchmal von ganz anderer Seite — Software Developer oder Sysadmins, die sich auf Security spezialisieren, statt in einem SOC anzufangen. Dieser Weg umgeht die Alert-Fatigue-Phase, kann aber Lücken in Incident-Response-Instinkten hinterlassen.

Welche Richtung solltest du zuerst einschlagen

Wenn du Investigation, Schreiben und das Lösen von Rätseln unter Druck magst, starte auf der Analyst-Seite. Wenn du lieber Code schreibst und Root Causes behebst, statt Alerts zu verfolgen, ziele auf die Engineer-Seite ab, aber erwarte, etwas Analyst-ähnliche Erfahrung zu brauchen, um glaubwürdig zu sein — niemand vertraut einer Detection, die du geschrieben hast, wenn du selbst nie eine Alert Queue bearbeitet hast.

Beide Wege konvergieren letztendlich auf Senior-Ebenen, wo der Job weniger um den Titel und mehr um das Verständnis der gesamten Attack Surface geht. Korra Studio hat Segmente zu SOC-Workflows, SIEM-Query-Schreiben und Cloud-Security-Engineering-Grundlagen, die es wert sind, erkundet zu werden, wenn du die täglichen Tools für einen dieser Tracks aus der Nähe sehen möchtest.