SOC Analyst werden als Quereinsteiger: So lernst du Monitoring, Logs und Incident Response

Montagmorgen, 8:15 Uhr: Im Security Operations Center erscheint eine Warnung zu mehreren fehlgeschlagenen Anmeldungen auf einem Administratorkonto. Wenige Minuten später folgt eine erfolgreiche Anmeldung aus einer ungewöhnlichen Quelle. Als SOC Analyst musst du nicht sofort wissen, ob es ein echter Angriff ist. Aber du musst strukturiert prüfen, welche Daten fehlen, wie dringend der Fall ist und wer informiert werden muss. Genau diese Fähigkeit macht die Rolle für Quereinsteiger greifbar.

SOC steht für Security Operations Center. Dort überwachen Teams Systeme, Netzwerke, Identitäten und Cloud-Umgebungen auf sicherheitsrelevante Ereignisse. Viele Unternehmen bauen ihre operativen Sicherheitsfähigkeiten aus. Mehr regulatorische Melde- und Sicherheitsanforderungen, unter anderem im Umfeld von NIS2, erhöhen den Druck, Vorfälle früher zu erkennen, nachvollziehbar zu bewerten und abgestimmt zu bearbeiten. Gesucht sind deshalb nicht nur Menschen mit Informatikstudium, sondern auch sorgfältige Analysten mit technischem Verständnis, Lernbereitschaft und einem klaren Blick für Abläufe.

Infografik zu SOC Analyst werden als Quereinsteiger: So lernst du Monitoring, Logs und Incident Response (KI-generiert).

Was ein SOC Analyst im Arbeitsalltag wirklich macht

Die Arbeit im SOC besteht selten aus spektakulären Hackerjagden. Der Kern ist wiederholbare Analyse. Du prüfst Meldungen aus Security-Tools, ordnest sie ein, sammelst Belege und dokumentierst Entscheidungen. Ein Alarm ist dabei zunächst nur ein Hinweis. Erst deine Analyse macht daraus einen bestätigten Vorfall, einen harmlosen Sonderfall oder eine Beobachtung, die weiterverfolgt werden muss.

Typische Aufgaben sind:

• Alarme in einem SIEM prüfen und priorisieren
• Logdaten aus Endgeräten, Servern, Firewalls, Identitätsdiensten und Cloud-Plattformen auswerten
• Auffällige Benutzerkonten, IP-Adressen, Prozesse oder Dateien untersuchen
• Fehlalarme erkennen und begründet schließen
• Verdächtige Aktivitäten an erfahrenere Analysten oder Incident-Response-Teams übergeben
• Tickets verständlich und vollständig dokumentieren
• Bei akuten Vorfällen erste Eindämmungsschritte nach definierten Abläufen begleiten

Je nach Unternehmen arbeitest du in festen Schichten, in einem internen Security-Team oder bei einem Dienstleister für mehrere Kunden. Manche SOCs trennen klar zwischen First-Level-Triage, vertiefter Analyse und Incident Response. In kleineren Teams können diese Aufgaben stärker zusammenlaufen.

Für den Quereinstieg ist das eine Chance: Du musst nicht zu Beginn jede Angriffstechnik selbst beherrschen. Wichtig ist, dass du Daten lesen kannst, Hypothesen bildest und deine Entscheidungen nachvollziehbar machst.

Die Grundlagen, die du vor dem ersten SOC-Projekt brauchst

Ein guter Einstieg beginnt nicht mit einem bestimmten SIEM-Produkt. Tools ändern sich, die grundlegenden Fragen bleiben gleich: Was ist in einem Log passiert? Ist das Verhalten plausibel? Welche Systeme, Konten und Daten sind betroffen? Welche nächste Prüfung schafft Klarheit?

Netzwerke und Betriebssysteme verstehen

Du solltest die wichtigsten Begriffe aus Netzwerken sicher einordnen können. Dazu gehören IP-Adresse, DNS, Ports, TCP, UDP, HTTP, TLS, VPN, Proxy und Firewall. Du musst nicht jedes Protokoll auswendig erklären. Du solltest aber erkennen, warum etwa viele DNS-Anfragen, ungewöhnliche ausgehende Verbindungen oder Anmeldeversuche über einen selten genutzten Dienst auffallen können.

Bei Betriebssystemen sind Windows und Linux besonders relevant. Lerne, wie Benutzerkonten, Berechtigungen, Prozesse, Dienste, Dateien und Ereignisprotokolle zusammenhängen. Unter Windows gehören Anmeldeereignisse, Prozessstarts und Änderungen an Gruppenmitgliedschaften zu den typischen Analysefeldern. Unter Linux sind unter anderem Authentifizierungsprotokolle, Systemdienste und Shell-Aktivitäten wichtig.

Identitäten und Cloud als Sicherheitsfokus

Viele Sicherheitsvorfälle beginnen mit gestohlenen Zugangsdaten. Deshalb solltest du verstehen, wie Mehrfaktor-Authentifizierung, Rollen, privilegierte Konten, Single Sign-on und Zugriffsrichtlinien funktionieren. Auch ohne tiefes Cloud-Wissen hilft es, typische Ereignisse einordnen zu können: neue Anmeldeorte, Änderungen an Berechtigungen, verdächtige OAuth-Freigaben oder das Anlegen zusätzlicher Zugangsschlüssel.

Logik der Angriffe lernen

Statt dich in langen Listen von Schadsoftware-Namen zu verlieren, orientiere dich an Angriffsschritten. Ein Angreifer braucht häufig zunächst Zugang, versucht dann Rechte auszuweiten, bewegt sich im Netzwerk weiter, sammelt Daten oder richtet einen dauerhaften Zugriff ein. Das MITRE-ATT&CK-Modell ist dafür eine nützliche Struktur. Es hilft dir, Beobachtungen wie PowerShell-Aufrufe, neue geplante Aufgaben oder ungewöhnliche Remote-Verbindungen in einen größeren Zusammenhang zu setzen.

Logs lesen: Vom einzelnen Ereignis zur nachvollziehbaren Geschichte

Logs sind die Arbeitsgrundlage im SOC. Sie wirken anfangs unübersichtlich, weil sie oft technische Felder, Zeitstempel und Kennungen enthalten. Mit Übung erkennst du jedoch schnell, welche Informationen für die Triage entscheidend sind.

Bei einer verdächtigen Anmeldung interessieren dich zum Beispiel:

Frage	Relevante Logdaten
Wer hat sich angemeldet?	Benutzername, Konto-ID, Rolle
Wann geschah es?	Zeitstempel, Zeitzone, Reihenfolge weiterer Ereignisse
Von wo kam der Zugriff?	Quell-IP, Standortangabe, Gerät, Netzwerk
Wie erfolgte die Anmeldung?	Dienst, Authentifizierungsmethode, Erfolg oder Fehler
Was passierte danach?	Prozessstarts, Rechteänderungen, Dateizugriffe, weitere Sitzungen

Eine einzelne fehlgeschlagene Anmeldung ist meist kein akuter Vorfall. Hunderte fehlgeschlagene Anmeldungen gegen viele Konten können dagegen auf Passwortangriffe hindeuten. Eine erfolgreiche Anmeldung nach mehreren Fehlversuchen ist auffällig, aber noch kein Beweis. Prüfe deshalb immer den Kontext: Ist die Quell-IP bekannt? Nutzt die Person ein neues Gerät? Gab es zeitgleich Änderungen an Berechtigungen? Wurde anschließend auf sensible Systeme zugegriffen?

Diese Denkweise schützt dich vor zwei typischen Fehlern. Der erste Fehler ist Alarmmüdigkeit: Du schließt Meldungen zu schnell, weil sie häufig auftreten. Der zweite Fehler ist Überreaktion: Du behandelst jede Abweichung wie einen bestätigten Angriff. Gute Triage bedeutet, Unsicherheit sauber zu reduzieren.

SIEM und Alarm-Triage praxisnah lernen

Ein SIEM sammelt und korreliert Sicherheitsereignisse aus unterschiedlichen Quellen. Es kann Regeln auslösen, wenn bestimmte Muster auftreten. Beispielsweise kann eine Regel melden, dass ein Benutzerkonto sich innerhalb kurzer Zeit von weit entfernten Standorten anmeldet oder dass ein Endgerät einen verdächtigen Prozess startet.

Für deinen Einstieg zählt weniger, welches Produkt du zuerst nutzt. Entscheidend ist, dass du einen Alarm konsequent bearbeiten kannst. Halte dich an einen einfachen Ablauf:

1. Lies die Alarmbeschreibung und identifiziere Auslöser, Zeitpunkt und betroffene Objekte.
2. Prüfe die Datenquelle: Ist sie zuverlässig, vollständig und aktuell?
3. Recherchiere Benutzerkonto, Gerät, IP-Adresse, Datei oder Prozess im Umfeld des Alarms.
4. Vergleiche das Verhalten mit üblichen Mustern im System.
5. Bewerte mögliche Auswirkungen und Dringlichkeit.
6. Dokumentiere Fakten, offene Fragen und deine Entscheidung.
7. Eskaliere mit den nötigen Belegen, wenn der Fall nicht sicher geschlossen werden kann.

Besonders wichtig ist die Dokumentation. Ein Ticket wie „Verdächtig, bitte prüfen“ hilft niemandem. Besser ist eine kurze, sachliche Zusammenfassung: Was wurde erkannt, welche Prüfungen hast du durchgeführt, was spricht für oder gegen einen Vorfall und welche Schritte empfiehlst du?

Übungsumgebungen, die dich wirklich weiterbringen

Du brauchst für erste Praxis keine Unternehmensdaten und kein professionelles SOC. Sinnvoll ist eine kontrollierte Laborumgebung, in der du Ereignisse erzeugst und anschließend analysierst. Arbeite nur in eigenen Testsystemen oder in ausdrücklich dafür vorgesehenen Lernumgebungen.

Ein sinnvoller Aufbau kann aus einem Windows-Testsystem, einer Linux-Maschine und einer zentralen Logsammlung bestehen. Ergänze später einen Verzeichnisdienst oder eine Cloud-Testumgebung, wenn du die Grundlagen sicher beherrschst. Wichtig ist nicht maximale Komplexität, sondern dass du den Datenfluss verstehst: Welches System erzeugt welches Ereignis, wie kommt es in die zentrale Analyse und wie sieht der zugehörige Alarm aus?

Gute Übungsaufgaben sind:

• Erzeuge mehrere fehlgeschlagene und anschließend erfolgreiche Anmeldungen.
• Lege einen neuen Benutzer an und ändere dessen Gruppenmitgliedschaft.
• Starte auf einem Testsystem ungewöhnliche, aber harmlose Prozesse und prüfe die Prozesskette.
• Simuliere eine auffällige DNS-Anfrage und untersuche Quelle, Ziel und zeitlichen Zusammenhang.
• Erstelle eine einfache Erkennungsregel für wiederholte Anmeldefehler.
• Schreibe zu jedem Fall ein Ticket mit Bewertung und nächstem Schritt.

Dokumentiere deine Übungen wie echte Arbeitsproben. Screenshots allein reichen nicht. Beschreibe Ausgangslage, Datenquellen, Analyseweg, Ergebnis und Verbesserungsmöglichkeiten. Damit zeigst du später, dass du nicht nur einem Tutorial gefolgt bist, sondern analytisch gearbeitet hast.

Incident Response: Was du als Einsteiger können solltest

Incident Response beginnt nicht erst, wenn ein System abgeschaltet wird. Sie umfasst Vorbereitung, Erkennung, Analyse, Eindämmung, Bereinigung, Wiederherstellung und Nachbereitung. Als SOC Analyst im Einstieg übernimmst du häufig die ersten drei Schritte und unterstützt bei der Übergabe.

Bei einem möglichen kompromittierten Konto könnte ein erster Ablauf so aussehen:

• Alarm und zugehörige Ereignisse sichern.
• Betroffenes Konto, Gerät und Zugriffszeitraum bestimmen.
• Prüfen, ob verdächtige Folgeaktivitäten stattgefunden haben.
• Dringlichkeit anhand vorhandener Kriterien bewerten.
• Verantwortliche Stelle mit klaren Fakten informieren.
• Eindämmungsmaßnahmen nur nach festgelegtem Prozess anstoßen oder begleiten.
• Alle Entscheidungen im Ticket festhalten.

Eigenmächtiges Löschen von Dateien, Sperren wichtiger Konten oder Abschalten von Systemen kann Schaden verursachen. Gute Incident Response ist deshalb koordiniert. Du arbeitest mit Checklisten, Zuständigkeiten und sauberer Kommunikation, nicht mit Aktionismus.

So baust du in drei Monaten ein glaubwürdiges Einstiegsprofil auf

Plane deinen Lernweg in überschaubaren Etappen. Berufstätige profitieren meist mehr von festen, realistischen Lernfenstern als von seltenen Marathon-Sessions.

Im ersten Monat legst du Grundlagen in Netzwerken, Windows, Linux und Identitäten. Lies täglich Logs und erkläre dir selbst, was dort passiert. Im zweiten Monat richtest du eine Übungsumgebung ein, sammelst Ereignisse und bearbeitest erste Alarme. Im dritten Monat arbeitest du mehrere vollständige Fälle durch und dokumentierst sie als Portfolio.

Eine hilfreiche Checkliste für dein Portfolio:

• Drei bis fünf dokumentierte Alarm-Triage-Fälle
• Mindestens ein Fall zu verdächtigen Anmeldungen
• Mindestens ein Fall mit Prozess- oder Endpunktanalyse
• Eine einfache Erkennungsregel mit Erklärung ihrer Grenzen
• Ein Incident-Response-Ablauf für einen realistischen Fall
• Eine kurze Übersicht deiner Laborumgebung und Datenquellen

Zertifikate können deinen Einstieg ergänzen, ersetzen aber keine nachweisbare Praxis. Im Vorstellungsgespräch zählt oft, ob du deine Analyse erklären kannst: Welche Daten hast du geprüft? Warum war ein Alarm ein Fehlalarm oder relevant? Was hättest du bei fehlenden Informationen getan?

Bei uns verbinden intensive Lernformate technische Grundlagen mit konkreten Übungen zu Logs, Monitoring und Sicherheitsvorfällen. Passende Seminare und Termine findest du bei uns auf cmt.de.

Der Quereinstieg als SOC Analyst gelingt, wenn du nicht versuchst, sofort jeden Angriff zu erkennen. Konzentriere dich darauf, Ereignisse sauber zu lesen, wiederholbare Triage-Schritte zu beherrschen und Unsicherheiten professionell zu dokumentieren. Das ist die operative Kompetenz, die ein SOC im Alltag braucht.