Incident Response, was ist das?

Bevor wir über Incident Response sprechen, ist es wichtige ein paar grundlegende Dinge zu klären.

Incident Management

Das Incident Management kümmert sich um Störungen von IT-Services. Es umfasst den gesamten organisatorischen und technischen Prozess, der sich mit der Reaktion auf sogenannte Incidents beschäftigt. Ein Incident ist eine Störung eines IT-Services. Solche Störungen können funktional oder eine Beeinträchtigung der Verfügbarkeit sein. Das Incident Management definiert Prozesse, Rollen und Tools, die Incidents über deren gesamten Lebenszyklus verwalten. In ITIL gibt es auch einen Incident Management Prozess, der oft in Unternehmen eingesetzt wird. Zu ITIL habe ich noch ein anderes Video erstellt, welches ich hier verlinke. ITIL was ist das? (Information Technology Infrastructure Library)

Was können Beispiele für Incidents sein? Ein interner Service ist aufgrund einer Überlastung nicht erreichbar. Daten von einem IT-Service können nicht mehr gespeichert werden, da die Festplatte des Servers voll ist. Ein anderes Incident ist, wenn ein Mitarbeiter sein Passwort vergessen hat und sich an den HelpDesk wendet. Solche Arten von Vorfällen bezeichnen wir als Incidents.

Security Incident Management

Wir haben eben über Incidents gesprochen. Security Incidents sind nun eine spezielle Art von Incidents. Ein Security Incident liegt vor, wenn die Schutzziele der IT-Security verletzt wurden. Die Schutzziele sind Verfügbarkeit, Vertraulichkeit und Integrität. Wurde mindestens eins dieser Schutzziele verletzt, so sprechen wir von einem Security Incident. Das Security Incident Management verwaltet nun ähnlich wie das Incident Management alle Security Incidents im gesamten Lebenszyklus.

Sowohl das Incident Management als auch das Security Incident Management arbeiten oft im Unternehmen eng zusammen. Es ist üblich, dass Security Incidents zunächst im Incident Management erscheinen und dort bewertet werden. Stellt sich heraus, dass es sich bei dem Vorfall um ein Incident mit Bezug zur IT-Security handelt, dann wird das Security Incident an das Security Incident Management weitergeleitet.

Incident Response

Als Incident Response kann man einen Teil des Security Incident Management bezeichnen. Dies besteht aus einer Menge von Richtlinien und Prozessen, die dafür eingesetzt werden, Security Incidents zu identifizieren, einzudämmen und zu beseitigen. Auf Cyber-Angriffe schnell reagieren und genau zu wissen, was zu tun ist. Das erreicht man mit Incident Response. Wie das geht, erkläre ich in diesem Video.

1. Phase: Preparation

In dieser Phase werden existierende Security Kennzahlen und Prozesse reviewt, um diese auf ihre Effektivität zu überprüfen. Hierbei wird auch ein Risiko Assessment durchgeführt, um die aktuellen Bedrohungen auf die IT-Assets zu bestimmen. Die Ergebnisse werden genutzt, um die Behandlung von verschiedenen Arten von Security Incidents festzulegen und je nach Wichtigkeit der Assets zu priorisieren. In dieser Phase werden fehlende Prozesse erstellt und die beteiligten Rollen an Mitarbeiter verteilt, damit die Verantwortlichkeiten bei der Behandlung von Security Incidents vor einem solchen geklärt und abgestimmt sind.

2. Phase: Identification

Die Prozesse und Tools der „Preparation“ Phase werde hier genutzt, um ungewöhnliche Aktivitäten zu beobachten und zu erkennen. Sobald ein Cyber-Angriff erkannt wurde, sind die Security Analysten damit beschäftigt diesen zu analysieren. Die Analysten müssen herausfinden, woher der Angriff kam, was das Ziel ist und um was für eine Art von Cyber-Angriff es sich handelt. Beweise werden gesammelt und sichergestellt, damit diese in den folgenden Phasen verwendet werden können. Die Analysten müssen ihr Vorgehen dokumentieren, damit alles möglichst genau auch für eine Strafverfolgung nachvollzogen werden kann. So bald bestätigt wurde, dass es sich um ein Security Incident handelt, werden die Kommunikationspläne aktiviert. Das bedeutet, die relevanten Stakeholder, Fachbereiche, Ermittlungsbehörden und eventuell auch Kunden werden über den Vorfall und den Stand der Ermittlung informiert.

3. Phase: Containment

Nachdem ein Security Incident identifiziert wurde, wird nun damit begonnen den entstandenen Schaden einzudämmen und auf ein Minimum zu begrenzen. Dazu werden betroffene Systeme im Netzwerk isoliert, damit sich der Angriff nicht weiter ausbreiten kann. Dies kann man erreichen, wenn man zum Beispiel bestimmte Netzwerksegmente isoliert, sodass keine Kommunikation mehr nach außen oder nach innen möglich ist. Ist nur ein einzelner Server infiziert, so kann dieser vom Netz getrennt werden. Oft werden in dieser Phase zur Sicherheit auch alle relevanten Passwörter getauscht. Server werden mit den neusten Updates gepatcht und Backups werden für die Wiederherstellung der infizierten Systeme vorbereitet.

4. Phase: Eradication

Nach dem Abschluss der „Containment“ Phase ist klar, über welche Systeme sich der Cyber-Angriff erstreckt hat. Alle infizierten Systeme müssen nun aus dem Backup oder einem sauberen Image wiederhergestellt werden. Diese Phase endet, nachdem alle Spuren des Cyber-Angriffs beseitigt und alle infizierten Systeme wiederhergestellt wurden.

5. Phase: Recovery

In dieser Phase werden die betroffenen Systeme und IT-Services wieder in den live Betrieb gebracht. Hier kann es sein, dass es durch die Wiederherstellung der Backups zu Datenverlusten gekommen ist. Nachdem alles wieder online ist, sollten diese Systeme beobachtet werden, um zu sehen, ob alle Spuren des Angreifers entfernt wurden oder ob der Angreifer zurückkommt.

6. Lessons learned

Nachdem das Security Incident erfolgreich behandelt wurde, wird in der „Lessons learned“-Phase die Behandlung des Security Incidents analysiert. Es wird geschaut, ob die Prozesse oder Kommunikationswege angepasst werden müssen, ob zusätzliche IT-Security-Maßnahmen eingerichtet werden sollten oder ob es andere Möglichkeiten gibt, die Behandlung von Security Incidents zu verbessern. In dieser Phase wird auch analysiert, ob die identifizierten Risiken richtig bewerten wurden und ob das Security-Monitoring erweitert werden muss.

Runbooks

Nachdem wir nun über die 6 Phasen des Incident Response gesprochen haben, spreche ich noch über Runbooks. Was sind Runbooks? Man kann sich Runbooks als eine Art Mini-Prozesse vorstellen. Ein Runbook beschreibt was zu tun ist, wenn ein fest definiertes Szenario eintritt. Gibt es beispielsweise einen Alarm aus dem Security Monitoring, der auf eine ungewöhnliche Aktivität hinweist, dann beschreibt ein Runbook, was in diesem Fall zu tun ist. Hat es also eine Brute-Force-Angriff auf den Login der Unternehmenswebseite gegeben, dann steht in dem entsprechenden Runbook, das zu prüfen ist, von welchen IP-Adressen der Angriff kam, welche Nutzer betroffen sind und um welche Server es sich hierbei handelt. Das Runbook gibt vor, was zu prüfen ist und wer in welchen Fällen informiert werden muss.

Der Vorteil von Runbooks ist es, dass bekannte Angriffsmuster standardisiert abgearbeitet werden können. Daher können auch Mitarbeiter, die wenig IT-Security Know-How haben bei der Behandlung von Security Incidents unterstützen. Es ist sogar möglich Runbooks komplett zu automatisieren. Das spart Personal und reduziert somit die Kosten. Je mehr bei der Behandlung von Security Incidents automatisiert wird, desto mehr haben die Analysten die Zeit schwerwiegende Security Incidents in der Tiefe zu analysieren.

Wenn Ihnen dieses Video gefallen hat, dann hinterlassen Sie einen Like und abonnieren Sie meinen Kanal:

Kanal abonnieren