Der Quereinstieg in die IT-Sicherheit gelingt aus der Administration und dem technischen Support häufiger als aus jedem Studium, und das aus einem einfachen Grund: Wer jahrelang Systeme betrieben hat, weiß, wie sie sich normal verhalten, und Verteidigung ist zu einem großen Teil das Erkennen des Abnormalen. Was fehlt, ist eine andere Denkweise und ein Stück Handwerk, und beides lässt sich in Monaten aufbauen, nicht in Jahren. Dieser Beitrag zeigt, was ein Admin schon mitbringt, was ihm für das Blue Team fehlt, welche Fehler beim Wechsel typisch sind und wie ein Umstieg in sechs Monaten aussieht, mit oder ohne Arbeitgeberwechsel.
Warum Admins gute Verteidiger werden
Ein Angreifer im Netz fällt nicht dadurch auf, dass er Angreifer-Werkzeuge benutzt, sondern dadurch, dass er Dinge tut, die in dieser Umgebung sonst niemand tut: Ein Dienstkonto meldet sich interaktiv an, ein Buchhaltungsrechner spricht per RDP mit einem anderen Buchhaltungsrechner, ein Server löst nachts hunderte DNS-Namen auf. Wer das als verdächtig erkennt, braucht kein Sicherheitsstudium, sondern ein Gefühl für den Normalzustand, und genau das hat, wer die Umgebung betrieben hat. Dazu kommen die Gewohnheiten des Betriebs: strukturiert Fehler suchen, unter Druck ruhig bleiben, dokumentieren, Bereitschaft aushalten. MITRE nennt in seinem SOC-Handbuch das Einstellen und Entwickeln guter Leute als eigene Strategie, und in der Praxis sind die besten Analysten der ersten Jahre oft die, die vorher die Domain Controller gepflegt haben.
Was du schon kannst
| Aus dem Betrieb | Im Blue Team |
|---|---|
| Active Directory, Gruppenrichtlinien, Berechtigungen | Anmeldeereignisse, Kerberos und die Frage, welche Rechte ein Angreifer mit diesem Konto hätte. Die Windows-Event-IDs sind für dich eine Vertiefung, kein Neuland. |
| Netzwerk, Firewall, DNS, VPN | Netzwerksensoren wie Zeek und die Frage, welche Verbindung nicht hingehört. Du weißt, wie das Netz gebaut ist; der Analyst neben dir muss es erst fragen. |
| Fehlersuche, Logs lesen, Ursachen finden | Triage und Analyse. Der Ablauf ist derselbe, nur die Frage lautet nicht „warum geht es nicht“, sondern „wer hat das getan“. |
| PowerShell, Bash, Skripte | Erkennungsregeln, Automatisierung, Auswertung von Logs. Wer Skripte für den Betrieb schreibt, schreibt Abfragen für das SIEM. |
| Backups, Wiederherstellung, Wartungsfenster | Die Vorbereitung auf den Ransomware-Vorfall. Du weißt, wie lange ein Restore dauert und was dabei schiefgeht. |
| Change- und Ticketprozesse | Fallmanagement, Dokumentation, Beweiskette. Die Disziplin ist dieselbe, der Zweck ein anderer. |
| Bereitschaft und Schichtdienst | Der SOC-Alltag. Wer ihn aus dem Betrieb kennt, hat keine Illusionen. |
Was dir fehlt
- Die Angreiferperspektive. Admins denken in Systemen, die funktionieren sollen; Verteidiger denken in Wegen, die ein Angreifer nimmt. MITRE ATT&CK und die Cyber Kill Chain sind die Landkarten dafür, und Atomic Red Team im eigenen Lab ist die Erfahrung: einmal selbst Zugangsdaten aus dem Speicher gelesen und gesehen, wie es im Log aussieht.
- Beweise vor Reparatur. Der Betriebsreflex ist: Problem beheben, System wieder ans Laufen bringen. Im Vorfall ist genau das der Fehler, der Spuren vernichtet. Die forensische Triage ist die Disziplin, die man als Admin am härtesten lernt, weil sie gegen jede Gewohnheit geht.
- Erkennungslogik. Ein Log lesen kannst du. Eine Regel schreiben, die aus tausend Ereignissen das eine herausfiltert und dabei nicht in Fehlalarmen ertrinkt, ist ein eigenes Handwerk. Sigma ist der Einstieg, weil die Community-Regeln zeigen, wie gute Regeln aussehen.
- Die Annahme, dass sie schon drin sind. Der Admin vertraut seinen Systemen, weil er sie gebaut hat. Der Verteidiger geht davon aus, dass irgendwo im Netz jemand sitzt, der nicht hingehört, und sucht ihn. Das ist keine Paranoia, sondern die Arbeitshypothese, aus der Threat Hunting entsteht.
- Der Rahmen. Meldepflichten, Beweiskette, Kommunikation mit Geschäftsführung und Behörden. Im Betrieb ist ein Ausfall ein technisches Problem; im Vorfall ist er ein rechtliches und ein kommunikatives dazu.
Typische Fehler beim Wechsel
- Erst reparieren, dann fragen. Das kompromittierte System neu aufsetzen, bevor jemand ein Abbild gezogen hat. Der häufigste und teuerste Admin-Reflex im Vorfall.
- Werkzeuge vor Grundlagen. Der Umsteiger will das SIEM lernen. Das SIEM lernt man in zwei Wochen; was in einem Kerberos-Ticket steht, nicht.
- Den Alarm wegerklären. „Das ist bestimmt das Backup-Skript“ ist als Hypothese richtig und als Abschluss falsch. Der Verteidiger prüft, ob es das Backup-Skript war.
- Weniger Bereitschaft erwarten. Ein SOC hat mehr davon, nicht weniger. Wer aus dem Betrieb wechselt, um Nachtschichten loszuwerden, wählt das falsche Ziel.
- Sich für einen Anfänger halten. Ein Admin mit fünf Jahren Erfahrung bewirbt sich nicht auf dieselbe Stufe wie ein Absolvent. Die Betriebserfahrung ist im Interview das stärkste Argument, wenn man sie als solche präsentiert.
Ein Umstiegsplan in sechs Monaten
- Monat 1 und 2: Grundlagen und Lab. Die Beiträge aus dem Bereich Grundlagen dieser Seite, dazu das Homelab mit Domäne, Sysmon und Wazuh. Als Admin steht das an einem Wochenende.
- Monat 3: Telemetrie und Erkennung. Sysmon konfigurieren, die wichtigsten Event-IDs im eigenen Lab erzeugen und finden, die ersten zehn Regeln schreiben und mit Atomic Red Team testen.
- Monat 4: Fremde Vorfälle. Blue-Team-CTFs, zwei vollständige Untersuchungen mit Writeup. Hier lernt sich das Denken in Beweisen.
- Monat 5: Prozess und Reaktion. Den Incident-Response-Prozess und die Playbooks durcharbeiten, im Lab einen Ransomware-Vorfall nachstellen und nach Triage-Reihenfolge bearbeiten, statt zu reparieren.
- Monat 6: Nachweis und Bewerbung. Drei Writeups veröffentlichen, optional BTL1 als Beleg, den Lebenslauf so umschreiben, dass die Betriebserfahrung als Verteidigungserfahrung lesbar wird. Was Arbeitgeber dann sehen wollen, steht im Beitrag SOC-Analyst werden.
Im aktuellen Job anfangen
Der Wechsel muss nicht mit einer Kündigung beginnen, und oft ist der interne Weg der schnellste. Fast jede IT-Abteilung hat Sicherheitsaufgaben, die niemand haben will: die Überwachungsrichtlinie nach Microsofts Empfehlung umsetzen, Sysmon ausrollen, die Logquellen an das SIEM anbinden, das der Dienstleister betreibt, den Incident-Response-Plan schreiben, den es nicht gibt, die Tabletop-Übung vorschlagen und moderieren, die Schwachstellenliste nach ausgenutzten Schwachstellen priorisieren. Wer sich diese Aufgaben holt, hat nach einem Jahr Sicherheitsarbeit im Lebenslauf, ein Netzwerk zum Dienstleister-SOC und oft eine Stelle, die für ihn geschaffen wird, weil die Organisation gemerkt hat, dass sie jemanden braucht. Und er hat das, was der externe Analyst nie haben wird: die Umgebung, die er verteidigt, selbst gebaut.
Ehrlich zu den Erwartungen
Der erste Schritt ins Blue Team ist selten ein Gehaltssprung. Eine Einstiegsstelle im SOC eines Dienstleisters zahlt oft ähnlich wie eine Administratorstelle, manchmal weniger, und die Arbeit in der ersten Linie ist repetitiver, als sie von außen wirkt. Der Gewinn liegt in der Entwicklung danach: Detection Engineering, Incident Response, Forensik und Hunting sind Rollen mit Nachfrage und mit Tiefe, und der Weg dorthin führt durch die erste Linie. Wer die Betriebserfahrung mitbringt, geht ihn schneller als die meisten, weil er die Hälfte der Fragen, die einem Analysten im ersten Jahr gestellt werden, schon einmal aus der anderen Richtung beantwortet hat.
Fazit
Vom Admin zum Defender ist kein Neuanfang, sondern ein Perspektivwechsel: dieselben Systeme, dieselben Logs, dieselben Netze, betrachtet mit der Frage, wer sie gerade missbraucht. Das Wissen über den Normalzustand bringt der Admin mit, die Angreiferperspektive, das Denken in Beweisen und das Handwerk der Erkennung kommen in sechs Monaten Lab, CTF und Lektüre dazu. Ein Blue Team, das einen erfahrenen Admin bekommt, der diesen Wechsel gemacht hat, bekommt jemanden, der die Umgebung versteht, bevor er den ersten Alarm sieht.