Ein SIEM-Alert wird wegen eines verdächtigen Logins ausgelöst. Führen Sie mich durch Ihr Triage-Vorgehen.
Kurzantwort
Bestätigen Sie vor dem Handeln, dass der Alert echt ist: Lesen Sie, was ausgelöst wurde und warum, dann reichern Sie an — wer ist der Benutzer, sind Quell-IP/Geo/Gerät erwartbar, ist es Impossible Travel, gab es zuvor Fehlschläge? Klassifizieren Sie als echten oder falschen Treffer, eskalieren oder dämmen Sie ein, wenn echt (Sitzung deaktivieren, MFA-Reset erzwingen), und dokumentieren Sie alles, damit der nächste Analyst Ihrer Argumentation folgen kann.
Bei Triage geht es darum, eine Frage effizient zu beantworten: Ist das echt, und wenn ja, wie schlimm? Interviewer wollen einen wiederholbaren Prozess sehen, keinen Reflex. Direkt zu „Konto deaktivieren" zu springen ist ein Warnsignal — Sie könnten auf einen Fehlalarm reagieren und Vertrauen verbrennen oder einen Angreifer warnen, bevor Sie den Umfang verstehen.
1. Validieren
Beginnen Sie damit, die Detektion selbst zu lesen. Welche Regel hat ausgelöst, auf welcher Datenquelle, und was ist die genaue Bedingung, die zutraf? Ein „verdächtiger Login" könnte eine einzelne Geovelocity-Regel oder eine Korrelation mehrerer Signale sein. Zu wissen, warum er ausgelöst wurde, sagt Ihnen, welche Belege zu sammeln sind.
2. Mit Kontext anreichern
Hier liegt der größte Wert. Ziehen Sie die umgebenden Fakten heran:
- Identität: Wer ist der Benutzer, was ist seine Rolle, meldet er sich normalerweise zu dieser Stunde an?
- Quelle: Stammt die IP aus einem bekannten Unternehmensbereich, einem VPN, einem Privatkunden-ISP oder einem Hosting-Provider / Tor-Exit? Welches Land, und ist das plausibel?
- Gerät: Ist es ein verwaltetes Gerät mit dem erwarteten User Agent oder etwas Neues?
- Abfolge: Gab es fehlgeschlagene Versuche vor dem Erfolg (Password Spray / Brute Force), und gibt es Impossible Travel — zwei Logins, geografisch zu weit auseinander, um dieselbe Person zu sein?
3. Klassifizieren
Mit Kontext in der Hand entscheiden Sie: echter Treffer, Fehlalarm oder gutartiger echter Treffer (real, aber autorisiert, z. B. der reisende Benutzer). Sagen Sie es explizit und halten Sie die Belege fest, die Sie dorthin geführt haben.
4. Eindämmen (wenn echt)
Sieht es nach einer Kontokompromittierung aus, handeln Sie verhältnismäßig: widerrufen Sie die aktive Sitzung, erzwingen Sie ein Credential- und MFA-Reset und prüfen Sie, was die Sitzung getan hat — Postfachregeln, OAuth-Berechtigungen, Datenzugriff. Eindämmung schlägt Abwarten.
5. Eskalieren und dokumentieren
Übergeben Sie an Incident Response, wenn der Schadensradius mehr als ein Konto umfasst oder Sie Lateral Movement sehen. In jedem Fall: schreiben Sie es auf — was ausgelöst wurde, was Sie geprüft haben, was Sie geschlossen haben und was Sie getan haben. Gute Notizen sind das, was einem SOC erlaubt, Detektionen zu tunen und ein Audit zu überstehen.
Warum das wichtig ist
Die Struktur zeigt Urteilsvermögen. Jeder kann auf „Blockieren" klicken; ein Analyst, der erklären kann, warum ein Login bösartig war oder nicht — und der eine saubere Spur hinterlässt —, ist derjenige, dem größere Incidents anvertraut werden.
Wahrscheinliche Anschlussfragen
- Was bedeutet Impossible Travel und wie würden Sie es erkennen?
- Wann eskalieren Sie an Incident Response, statt es selbst zu bearbeiten?
- Wie tunt man eine laute Regel, ohne einen blinden Fleck zu schaffen?