Incident Response Prozess – Beispiele für IT-Sicherheitsvorfälle und wie Unternehmen reagieren können
Szene aus einem mittelständischen Unternehmen: Ein externes Security Information und Event Management (SIEM) und Security Operations Center (SOC) waren die Wunschlösung der Geschäftsführung für mehr IT-Sicherheit. Im Zweifel übernehmen die Profis – das sollte für ein beruhigendes Gefühl sorgen. Dann schrillt der Alarm: Das SIEM meldet ein Ereignis, das SOC Team muss weitere Akteure im Unternehmen oder beim Kunden einbeziehen. Und nun…? In der Kette weiß keiner genau, was bei dem Vorfall zu tun ist. Denn es gibt keinen strukturierten Incident Response Prozess.
Die kurze Szene zeigt: Ohne die Zuteilung von Verantwortung im Alarmfall und ohne vorstrukturierte Prozesse für verschiedene Arten von Bedrohungen und Vorfällen droht in Unternehmen der „Headless Chicken Mode“. Ein kopfloses Agieren ist jedoch gerade im Fall von IT Security sehr kontraproduktiv. Insbesondere, weil die reale Bedrohungslage ständig ernster wird: Mit immer kreativeren Methoden versuchen organisierte Banden, an Geld oder Informationen von Firmen, Banken und Instituten zu gelangen. Der Schaden, der durch Cyberkriminalität entsteht, erreicht jährlich neue Milliarden-Höchststände.
Das Zusammenspiel von SOC, ISB und Fachbereichen organisieren
Mindestens ebenso wichtig wie die Implementierung technischer Grundstrukturen wie eben einer SIEM-Lösung ist die Organisation der betrieblichen Abläufe. Im konkreten Fall muss ein Unternehmen aus SOC-Mitarbeitern und Fachbereichen ein Team bilden. In vielen Fällen – und diese Rolle wird häufig übersehen – sollte auch ein Informationssicherheitsbeauftragter (ISB) bzw. Chief Information Security Officer (CISO) dazwischengeschaltet werden.
Wir zeigen, wie das Zusammenspiel für verschiedene Arten von sicherheitsrelevanten IT-Vorfällen aussehen kann. Drei grundsätzliche Fälle lassen sich unterscheiden, die es unterschiedlich zu behandeln gilt:
Fallabschließende Bearbeitung durch das SOC, Handlungsbedarf identifiziert durch den ISB
Fallabschließende Bearbeitung durch das SOC; Information an den ISB
Grafik: Ein geeigneter Security Incident Response Prozess (Respond) gehört zu den fünf Kernanforderungen des NIST Cybersecurity Frameworks.
(1.) Nicht fallabschließende Bearbeitung durch das SOC, Handlungsbedarf durch die Fachabteilung oder den ISB
Kommt der SOC-Analyst zu der Einschätzung, das Ticket benötigt ein Eingreifen durch die Organisation, erfolgt eine Meldung an die jeweilige Fachabteilung und in besonderen Fällen direkt beim ISB. Bei dringlichen und/oder zeitkritischen Fällen erfolgt mitunter auch ein Anruf des SOC-Analysten bei der Fachabteilung.
Beispiele hierfür sind:
- eine gerade aktive Ransomware – darunter ist eine bösartige Software zu verstehen, die durch Verschlüsselung den Zugriff auf Daten verhindert und den Computer sozusagen als Geisel nimmt. Dies ist häufig verbunden mit einer hohen Lösegeldforderung, damit der PC wieder freigegeben wird.
- eine mögliche dolose Handlung eines Mitarbeiters, die gerade im Gange ist (z.B. ein Abzug großer Datenmengen).
Unabhängig vom weiteren Vorgehen ist es sinnvoll, ein Protokoll über die weiteren Vorgehensschritte zu führen und nach Abschluss des Vorfalls einen Vermerk im Ticket über den Ausgang zu hinterlegen.
(2.) Fallabschließende Bearbeitung durch das SOC, Handlungsbedarf identifiziert durch den ISB
In einigen Fällen kann das zunächst rein informativ weitergeleitete Ticket dazu führen, dass die fallabschließende Klassifizierung durch den SOC-Analysten innerhalb der Organisation anders beurteilt wird. Die interne Einschätzung kann eine Nacharbeit erforderlich machen.
Zu besseren Orientierung kann folgender Case dienen:
Ein Mitarbeiter steckt einen unerlaubten Wechseldatenträger in den PC. Das SOC gibt der Fachabteilung einen Hinweis. Für das SOC besteht kein weiterer Handlungsbedarf – es schließt den Fall ab.
Die Organisation kann aber Nacharbeiten in Form einer Awareness Maßnahme oder einer Prüfung des Anlasses (durch Befragung des Mitarbeiters) für nötig befinden.
(3.) Fallabschließende Bearbeitung durch das SOC, Information an den ISB
Der dritte Fall ist, dass das Ticket lediglich informativer Natur auf beiden Seiten ist. Das Ereignis ist abgehandelt und erfordert in der Organisation keine weiteren Nacharbeiten mehr.
Auch hier kann wieder das Beispiel des auffälligen Nutzerverhaltens benutzt werden, mit dem Unterschied, dass sowohl das SOC als auch die Organisation das Ereignis als fallabschließend klassifiziert.
Bei dieser Einordung durch das SOC wie auch der Organisation kann das Ticket ohne weitere Bedenken abgelegt werden.
Welche Ereignisse immer interne Reaktion erfordern
Soweit zur Theorie. Was heißt das für die Praxis? Auf zwei Meldungen muss besonderes Augenmerk gelegt werden, da fast immer interne Maßnahmen erforderlich sind:
(1.) Reaktionsmöglichkeiten rund um auffälliges Nutzerverhalten: Eskalationsmodell
Ist ein auffälliges Nutzerverhalten gemeldet, kann die Ereignisbehandlung disziplinarische Konsequenzen innerhalb der Organisation nach sich ziehen. Ein entsprechendes Praxisbeispiel hierfür ist ein mehrfacher Anmeldeversuch eines Mitarbeiters an einem System, für das keine Berechtigung vorliegt. Oder es kann sich um einen spontan erforderlichen Change handeln, der nicht ordnungsmäßig dokumentiert wurde und für den daher kein legitimer Anlass erkennbar ist. Für solche Fälle ist ein stufenweises Eskalationsmodell empfehlenswert:
Stufe 1: Befragung des Mitarbeiters oder dessen Vorgesetzten
Zuerst muss der betroffene User selbst oder dessen Vorgesetzter zu dem Case befragt werden. Ziel ist die Aufklärung des Vorgangs, wobei diese Fragen als Hilfestellung dienen:
- Kann das Vorgehen plausibel erklärt werden?
- Kann das Vorgehen durch einen Change oder Incident begründet werden?
- Gibt es hierzu eine entsprechende Ticketnummer?
- wenn nein: warum wurde keine Ticketnummer erstellt?
- wurde der Vorgesetzte im Vorhinein über den Vorgang informiert?
- Kann das Ereignis als unbedenklich aufgeklärt werden?
Stellt sich heraus, dass durch die Abarbeitung der Fragen der Fall geklärt werden konnte, kann der Mitarbeiter wieder freigegeben werden, sollte dieser vorsorglich gesperrt worden sein.
Stufe 2: Sperren des betroffenen Users
Kann mit Hilfe der Erstbefragung das Mitarbeiterverhalten nicht plausibel erklärt werden, sollte der betroffene Mitarbeiter gesperrt werden. Der Grund: Hier handelt es sich in den meisten Fällen um ein sicherheitsrelevantes Ereignis, das weiterbearbeitet werden muss.
Stufe 3: Beweismittel sichern
Da es im weiteren Zusammenhang der Behandlung des Sicherheitsereignisses dazu kommen kann, dass Beweismittel gesichert werden müssen, ist es sinnvoll, vorab Logfiles und Protokolle zu sichern. Als praktikabel hat sich hierbei herausgestellt, alle Logfiles auf dem betroffenen Client und/oder Server zu sichern. Gegebenenfalls ist es empfehlenswert, die betroffenen Geräte vom Computer-Netzwerk zu trennen oder sicherzustellen.
Um die Verwertbarkeit von Beweismaterial in forensischen Untersuchungen oder auch gerichtlichen Prozessen zu wahren, müssen die Informationen vor unbefugten Zugriffen, Löschen oder versehentlichem Überschreiben geschützt werden. Um die Anforderungen zu erfüllen, ist es von Vorteil, die entsprechenden Informationen auf ein externes Medium oder einem explizit hierfür vorgesehenen Client oder Server zu speichern.
Stufe 4: Forensik initiieren
Werden während der Behandlung von Vorfällen Verstöße von Mitarbeitern gegen interne Regelungen oder Gesetzesverstöße erkannt, bzw. sind solche zu vermuten, müssen forensische Untersuchungen eingeleitet werden.
Eine forensische Untersuchung wird mit dem Ziel durchgeführt, einen Vorgang in einem Rechnersystem zu untersuchen, nachzuvollziehen und zu dokumentieren. Dies umfasst das Identifizieren, Sicherstellen und Analysieren von Spuren, die im weiteren Verlauf der Ermittlungen als Beweise verwendet werden können.
Stufe 5: Strafrechtliche Ermittlungen einleiten
Falls es sich bei dem Sicherheitsereignis um eine strafbare Handlung handelt, müssen strafrechtliche Ermittlungen eingeleitet werden.
(2.) Möglichkeiten der Reaktion auf Virenmeldungen: Notfallmanagement aktivieren
Enthält das Ticket eine Virenmeldung und konnte diese nicht automatisch beseitigt werden, ist ein Handeln durch die Organisation notwendig.
- Erste Handlungsschritte sind hierbei, in Falle eines größeren Ereignisses wie eines Ransomware-Angriffs, die betroffenen Geräte schnellstmöglich vom Computer-Netzwerk zu trennen, sowie das Schadensausmaß zu ermitteln.
- Danach ist das Notfallmanagement zu aktivieren, da bei dieser Meldung davon auszugehen ist, dass es sich um ein Ereignis mit hohem Schadensrisiko handelt. Kleinere Vorfälle können im Normalfall automatisch in Quarantäne gesetzt werden.
Um weitere Vorfälle dieser Art zu verhindern, sollte der auslösende Mitarbeiter ermittelt und entsprechend geschult und unterstützt werden.
Fazit: Wer Verantwortlichkeiten klar regelt, schützt das Kerngeschäft
Wie jetzt ersichtlich wird, ist es für die Geschäftsführung durchaus möglich, sich ruhigen Gewissens auf das Kerngeschäft zu konzentrieren, wenn die Zuständigkeiten und Maßnahmen umfassend geklärt sind. Ein Unternehmen ist nicht frei von jeder Verantwortung, kann aber durch bewusstes Regeln der Verantwortlichkeiten mögliche Szenarien routiniert abdecken.
