Security Operations bezeichnet die laufende Überwachung, Analyse und Reaktion auf sicherheitsrelevante Ereignisse in zunehmend cloudbasierten Umgebungen mit verteilten Endpunkten und integrierten XDR-Plattformen. Für Analysten bedeutet das: Alarme entstehen nicht mehr nur aus einzelnen Systemen, sondern aus zusammenhängenden Signalen über Identität, E-Mail, Endpunkt, Cloud-Workloads und SIEM-Daten.
Die Microsoft-Zertifizierung SC-200 richtet sich an Security Operations Analysts, die Bedrohungen mit Microsoft Sentinel, Microsoft Defender XDR und Microsoft Defender for Cloud erkennen, untersuchen und darauf reagieren. Sie ist vor allem für Personen relevant, die in einem SOC arbeiten, aus Administration oder Cloud-Betrieb in Security wechseln oder ihre praktischen Detection-and-Response-Fähigkeiten strukturiert nachweisen möchten.
Was die SC-200 in der Praxis abbildet
Die Rolle des Security Operations Analyst ist operativ geprägt. Sie verbindet Triage, Threat Hunting, Incident Response, KQL-Abfragen, Regelpflege und Automatisierung. Ein einzelner Alarm ist dabei selten die ganze Wahrheit. Gute Analyse entsteht durch Korrelation: Ein verdächtiger Login wird mit Endpunktaktivität, E-Mail-Telemetrie, Identitätsereignissen und Cloud-Signalen zusammengeführt.
SC-200 validiert genau dieses Zusammenspiel. Im Mittelpunkt stehen Microsoft Sentinel als SIEM- und SOAR-Plattform, Microsoft Defender XDR als korrelierte Sicht auf Endpunkte, Identität, E-Mail und Kollaboration sowie Defender for Cloud für Cloud-Sicherheitslage und Workload-Schutz. Wer die offizielle Skill-Outline auf Microsoft Learn prüft, sollte sie nicht als reine Themenliste lesen, sondern als Abbild eines SOC-Arbeitstages: Daten verbinden, Vorfälle priorisieren, Angriffe untersuchen, Abfragen schreiben, Erkennungen verbessern und Reaktionen auslösen.
Wichtig ist auch die Abgrenzung zu anderen Microsoft-Security-Zertifizierungen. SC-200 fokussiert Detection, Investigation und Response. SC-300 passt eher zu Rollen rund um Identity and Access Administration. AZ-500 richtet sich stärker an Azure Security Engineers, die Azure-Ressourcen absichern und Plattformkontrollen konfigurieren. SC-100 ist architektonischer ausgerichtet und setzt stärker auf die Gestaltung übergreifender Security-Strategien.
Eine strukturierte Vorbereitung kann sinnvoll sein, wenn neben Theorie auch praktische Labs, Fallanalysen und geführte KQL-Übung benötigt werden. Das SC-200 Training von Readynez ist in diesem Kontext eine mögliche Option, sollte aber nicht die eigene Arbeit im Tenant, in Sentinel und im Microsoft Defender Portal ersetzen.
Die Microsoft-Tools im SC-200-Kontext
Microsoft Defender XDR bündelt Signale aus mehreren Schutzbereichen. Defender for Endpoint liefert Telemetrie zu Geräten, Prozessen, Netzwerkverbindungen und verdächtigem Verhalten. Defender for Office 365 ergänzt E-Mail- und Kollaborationssignale, etwa Phishing-Kampagnen, verdächtige Anhänge oder schädliche Links. Defender for Identity erkennt auffällige Identitätsmuster, etwa Reconnaissance, ungewöhnliche Authentifizierung oder mögliche laterale Bewegung.
Microsoft Sentinel übernimmt die SIEM- und SOAR-Perspektive. Dort werden Datenquellen angebunden, Analytic Rules erstellt, Incidents untersucht, Hunting Queries geschrieben und Playbooks ausgelöst. Wer tiefer in Sentinel-Konfiguration und Betriebsmodelle einsteigen möchte, findet mit dem Kurs zu SIEM-Sicherheitsoperationen mit Microsoft Sentinel einen passenden thematischen Anschluss.
Defender for Cloud ergänzt den Blick auf Cloud-Workloads und Sicherheitskonfigurationen. Für SC-200 ist daran besonders relevant, wie Cloud-Signale in Incident-Untersuchungen einfließen: etwa eine riskante öffentliche Ressource, verdächtige Aktivität auf einer virtuellen Maschine oder Hinweise auf fehlende Härtung. Die Prüfung verlangt deshalb weniger ein isoliertes Produktwissen als die Fähigkeit, aus Signalen eine belastbare Untersuchung zu machen.
In der Praxis scheitern SOC-Prozesse häufig nicht an fehlenden Tools, sondern an zu breiter Datensammlung ohne klares Ziel. Sentinel kann schnell teuer und unübersichtlich werden, wenn alle Datenquellen unkritisch angebunden werden. Sinnvoller ist ein schrittweises Onboarding: zuerst Identität, Endpunkt und hochrelevante Cloud-Signale, danach weitere Quellen anhand konkreter Detection Use Cases. Ebenso wichtig ist die Unterscheidung zwischen Analytics- und Basic-Tabellen sowie eine bewusste Retention-Strategie, damit Kosten, Abfrageleistung und Untersuchungswert zusammenpassen.
Fallbeispiel: Verdächtiger Login und laterale Bewegung
Das folgende Szenario ist abgeleitet aus typischen SOC-Abläufen und verwendet keine Kundendaten. Ein Benutzerkonto meldet sich erfolgreich aus einem ungewohnten Standort an. Kurz danach greifen Prozesse auf einem Endpunkt auf interne Freigaben zu, und Defender for Identity meldet Hinweise auf ungewöhnliche Authentifizierungsversuche. Ein unerfahrener Analyst könnte den ersten Alarm als isoliertes Login-Ereignis behandeln. Ein geübter Analyst formuliert dagegen eine Hypothese: Das Konto könnte kompromittiert sein und für laterale Bewegung genutzt werden.
Eine KQL-Abfrage hilft, diese Hypothese zu prüfen. Sie verbindet Anmeldeereignisse mit auffälliger Endpunktaktivität in einem engen Zeitfenster. Die konkrete Tabellennamensgebung hängt vom angebundenen Datenmodell ab; in einem Lab sollte die Abfrage deshalb gegen vorhandene Microsoft Sentinel-Tabellen validiert und bei Bedarf angepasst werden.
Example — Anomalie-Login mit Endpunktaktivität korrelieren
let Lookback = 24h;
let SuspiciousSignins =
SigninLogs
| where TimeGenerated > ago(Lookback)
| where ResultType == 0
| where LocationDetails !has "Germany"
| project UserPrincipalName, SigninTime = TimeGenerated, IPAddress, LocationDetails;
SuspiciousSignins
| join kind=inner (
DeviceFileEvents
| where TimeGenerated > ago(Lookback)
| where FolderPath has_any ("\\\\fileserver", "\\\\share")
| project DeviceName, UserPrincipalName = InitiatingProcessAccountUpn,
FileTime = TimeGenerated, FolderPath, InitiatingProcessFileName
) on UserPrincipalName
| where FileTime between (SigninTime .. SigninTime + 2h)
| project SigninTime, FileTime, UserPrincipalName, IPAddress, LocationDetails,
DeviceName, FolderPath, InitiatingProcessFileName
Die Abfrage funktioniert, weil sie nicht nur nach einem ungewöhnlichen Login sucht, sondern nach einer zeitnahen Folgeaktivität, die zum Angriffspfad passen könnte. In einem Lab lässt sich das mit Testdaten prüfen, indem ein kontrollierter Login aus einer abweichenden Region oder ein simuliertes Share-Zugriffsmuster erzeugt wird. Die Validierung sollte dokumentieren, ob die Tabellen Daten enthalten, ob die Join-Felder sauber befüllt sind und ob das Zeitfenster zu viele oder zu wenige Treffer liefert.
Eine häufige SOC-Falle besteht darin, ausschließlich auf Alarme zu reagieren. Threat Hunting beginnt dagegen mit einer Annahme und sucht gezielt nach Belegen oder Gegenbelegen. Ohne Baseline für normales Verhalten entstehen Rauschen und blinde Flecken: Ein ungewöhnlicher Standort ist bei einem reisenden Vertriebsteam anders zu bewerten als bei einem Servicekonto, das nie interaktiv genutzt werden sollte.
Fallbeispiel: Phishing-Korrelation über E-Mail, Identität und Endpunkt
Ein zweites Szenario betrifft eine Phishing-E-Mail, die mehrere Postfächer erreicht. Defender for Office 365 erkennt einen Teil der Kampagne, aber ein Benutzer klickt auf einen Link und meldet sich anschließend an einer verdächtigen Anwendung an. Für die Untersuchung reicht es nicht, die E-Mail zu löschen. Entscheidend ist, ob Zugangsdaten abgegriffen wurden, ob weitere Logins stattfanden und ob Endpunkte nachgelagerte Aktivität zeigen.
Die folgende KQL-Abfrage ist als Ausgangspunkt für eine Untersuchung gedacht. Sie sucht E-Mail-Ereignisse mit Phishing-Hinweisen und korreliert sie mit nachfolgenden Anmeldeereignissen derselben Benutzer. Für produktive Umgebungen sollten Allow-Lists, interne Testkampagnen und bekannte Security-Awareness-Plattformen berücksichtigt werden, damit die Abfrage nicht unnötig viele legitime Trainingsereignisse meldet.
Example — Phishing-E-Mail und nachfolgende Logins verbinden
let Lookback = 48h;
let PhishingMessages =
EmailEvents
| where TimeGenerated > ago(Lookback)
| where ThreatTypes has "Phish" or DetectionMethods has "Phish"
| project RecipientEmailAddress, SenderFromAddress, Subject,
EmailTime = TimeGenerated, NetworkMessageId;
PhishingMessages
| join kind=leftouter (
SigninLogs
| where TimeGenerated > ago(Lookback)
| where ResultType == 0
| project RecipientEmailAddress = UserPrincipalName,
SigninTime = TimeGenerated, IPAddress, AppDisplayName, Location
) on RecipientEmailAddress
| where isnull(SigninTime) or SigninTime between (EmailTime .. EmailTime + 6h)
| project EmailTime, SigninTime, RecipientEmailAddress, SenderFromAddress,
Subject, IPAddress, AppDisplayName, Location, NetworkMessageId
| order by EmailTime desc
Der Lernwert liegt in der Korrelation. Eine einzelne Phishing-Erkennung kann harmlos erscheinen, wenn sie blockiert wurde. Ein erfolgreicher Login nach Zustellung derselben Kampagne verändert die Priorität. In einer echten Untersuchung würden anschließend Audit-Logs, OAuth-App-Berechtigungen, Postfachregeln und Endpunktaktivität geprüft.
Automatisierung kann diesen Ablauf beschleunigen, sollte aber nicht unkontrolliert wachsen. Sentinel-Playbooks auf Basis von Logic Apps müssen in Incident-Response- und Change-Prozesse eingebettet werden: Wer genehmigt eine Geräteisolation, wie wird ein Rollback dokumentiert, welche Aktionen werden protokolliert, und wann muss ein Mensch entscheiden? Ohne diese Leitplanken entsteht Automation Sprawl, bei dem viele Playbooks existieren, aber wenige zuverlässig betrieben werden. Wer Defender XDR dafür vertiefen möchte, kann die Inhalte zu Cyberbedrohungsabwehr mit Microsoft Defender XDR als ergänzenden Lernpfad betrachten.
Ein realistisches Mini-Lab für die Vorbereitung
Für SC-200 ist praktische Arbeit unverzichtbar. Viele Kandidaten lernen zu lange aus Modulen und Folien, bevor sie KQL schreiben, Incidents untersuchen oder eine einfache Analytic Rule konfigurieren. Ein kleines Lab kann bereits reichen, um die wichtigsten Abläufe zu verstehen: ein Microsoft 365 Developer Tenant mit E5-Funktionen, ein Azure-Testkonto, ein Log Analytics Workspace, Microsoft Sentinel und ausgewählte Defender-Integrationen.
Das Lab sollte bewusst klein bleiben. Sensible Echtdaten gehören nicht in eine persönliche Übungsumgebung. Ebenso sollten Datenquellen nur selektiv angebunden werden, weil Sentinel-Kosten von Datenaufnahme, Aufbewahrung und genutzten Features abhängen können. Nach Übungen sollten nicht benötigte Ressourcen, Playbooks, Connectors und Workspaces überprüft oder entfernt werden. Wer mit E-Mail-, Identitäts- und Endpunktsignalen arbeitet, sollte außerdem Datenhaltungs- und Datenschutzanforderungen des eigenen Unternehmens beachten.
Ein sinnvoller Ablauf besteht darin, zuerst Microsoft Sentinel bereitzustellen, dann eine kleine Zahl relevanter Connectors zu aktivieren und anschließend wenige Detection-Szenarien sauber durchzuarbeiten. Dazu gehören ein verdächtiger Login, eine Phishing-Untersuchung, eine einfache Incident-Zuweisung, eine KQL-Hunting-Abfrage und ein Playbook, das zunächst nur ein Ticket oder eine Benachrichtigung erzeugt. Erst wenn diese Schritte nachvollziehbar funktionieren, sollte eine automatisierte Eindämmung getestet werden.
Prüfungslogistik und Vorbereitung ohne Rätselraten
Prüfungsdetails ändern sich. Deshalb sollten Kandidaten Registrierung, verfügbare Sprachen, regionale Preise, Prüfungsmodalitäten und Identitätsanforderungen immer auf der offiziellen SC-200-Exam-Seite bei Microsoft Learn und im Pearson-VUE-Registrierungsprozess prüfen. Angaben zu Fragenanzahl, Dauer oder Kosten sollten nicht aus älteren Blogartikeln übernommen werden, wenn sie dort nicht direkt auf aktuelle Microsoft-Informationen zurückgeführt sind.
Für die Vorbereitung ist die offizielle Skills Outline besonders wichtig. Sie zeigt, welche Kompetenzbereiche Microsoft prüft und wo Schwerpunkte liegen. Gute Lernplanung beginnt mit dieser Struktur, geht dann aber schnell in praktische Arbeit über. KQL muss geschrieben, nicht nur gelesen werden. Analytic Rules müssen getestet, nicht nur verstanden werden. Playbooks müssen mit Fehlerfällen betrachtet werden, nicht nur im Idealfall.
Ein nützlicher Lernrhythmus ist, jede Woche ein kleines Szenario vollständig zu bearbeiten: Hypothese formulieren, Datenquelle identifizieren, KQL-Abfrage schreiben, Ergebnis interpretieren, Incident dokumentieren und eine Verbesserungsmaßnahme ableiten. So entsteht eine Arbeitsweise, die sowohl für die Prüfung als auch für den SOC-Alltag relevant ist.
Wie SC-200 im Lebenslauf Wirkung entfaltet
Das Zertifizierungs-Badge kann im Screening helfen, aber es ersetzt keine sichtbaren Arbeitsproben. In vielen Security-Rollen zählen Artefakte: kommentierte KQL-Abfragen, ein kurzes Runbook für Phishing-Triage, ein Beispiel für eine Sentinel Analytic Rule, eine Beschreibung eines Playbook-Designs oder ein anonymisierter Incident-Report aus einem Lab. Solche Nachweise zeigen, dass eine Person nicht nur Produktnamen kennt, sondern Untersuchungen strukturieren kann.
Gerade Quereinsteiger aus Systemadministration, Microsoft 365, Azure-Betrieb oder Helpdesk sollten diese Brücke sichtbar machen. Erfahrung mit Identitäten, Geräten, Conditional Access, Mailflow oder Cloud-Ressourcen ist für Security Operations wertvoll, wenn sie in Detection- und Response-Denken übersetzt wird. SC-200 kann dabei ein Rahmen sein, um vorhandene Betriebserfahrung in SOC-relevante Fähigkeiten zu überführen.
Den nächsten Schritt sinnvoll wählen
SC-200 lohnt sich besonders, wenn die Zielrolle nahe an Incident Response, Threat Hunting, SIEM-Betrieb oder Defender-XDR-Untersuchungen liegt. Wer primär Identitäten und Berechtigungsmodelle verwaltet, sollte SC-300 prüfen. Wer Azure-Plattformhärtung, Netzwerksicherheit und Workload-Schutz verantwortet, wird eher bei AZ-500 ansetzen. Die Wahl der Zertifizierung sollte der tatsächlichen Rolle folgen, nicht dem allgemeinsten Security-Interesse.
Die wirksamste Vorbereitung verbindet offizielle Microsoft-Lernziele mit wiederholter praktischer Arbeit: kleine Labs, echte KQL-Abfragen, saubere Incident-Notizen und bewusst begrenzte Automatisierung. Readynez kann diese Vorbereitung durch ein geführtes SC-200-Format unterstützen; entscheidend bleibt jedoch, dass Kandidaten die Werkzeuge selbst bedienen und die Denkweise eines SOC-Analysten entwickeln. Weitere Microsoft-Security-Kurse sind über die Microsoft-Trainingsübersicht auffindbar, wenn nach SC-200 ein angrenzender Schwerpunkt vertieft werden soll.
