Security Incident Management Prozess – Planung und Umsetzung

Gerade im Jahr 2020 hat die Digitalisierung einen enormen Schub erfahren. In nur wenigen Wochen mussten Unternehmen lernen und umsetzen, ihre IT so anzupassen, dass Mitarbeiter dezentral arbeiten können. Das erforderte ein schnelles Umsetzen.

Wenn die Digitalisierung eines Unternehmens nicht adäquat durchgeführt wird, kann es passieren, dass damit auch die Anzahl an Security Incidents zunimmt. Unabhängig davon, wie sicher die IT innerhalb einer Firma ist, ist ein gutes Incident Management – oder auch IT-, Vorfalls- oder Störungsmanagement – das A und O für die Informationssicherheit. Die Planung und das Aufsetzen eines Konzepts für unerwartete Sicherheitsvorfälle ist vermutlich eine der größten Herausforderungen für Security-Fachkräfte. Mit einem umfassenden und effektiven Plan zur Reaktion auf Incidents haben Mitarbeiter eine Grundlade für den Umgang mit IT-sicherheitsrelevanten Zwischenfällen.

Alles zum Thema Security Incident Management

Wie für ITIL^® gibt es auch im Bereich des Cybersecurity verschiedene Frameworks. Ein solcher Plan zur Reaktion auf einen Incident ist in der Regel ein dokumentierter Leitfaden mit mehreren Phasen. Die ordnungsgemäße Erstellung und Verwaltung eines solchen Incident-Management-Plans erfordert regelmäßige Updates und Schulungen.

Security Incident Management Prozess

Nachfolgend sind mögliche Phasen des Security Incident Management Prozesses aufgelistet:

Preparation

Erfahrungsgemäß besteht die Vorbereitung hauptsächlich darin, die entsprechenden Incident-Managment-Tools und Prozesse bereitzustellen. STORM bringt hier als SOAR-Software bereits einiges mit: Ein an die Sicherheitsanforderungen individuell anpassbares Tool sowie eine Menge Know-How unserer Cybersecurity-Experten.

Im Grunde genommen wird der Prozess des Incident-Response-Plans wie bei ITIL^® auch an Best Practices angelehnt. Wichtige Phasen werden im Tool modelliert, so dass sie bei einem Incident die wichtigsten Informationen in Kürze erfassen, die der Kunde zur Reaktion benötigt.

Zunächst einmal ist die grundlegende Aufgabe, sicherzustellen, dass die Mitarbeiter ihre Rollen und Verantwortlichkeiten im Falle eines Incidents, wie zum Beispiel bei einem Verstoß gegen den Datenschutz, kennen. Zudem können sie Szenarien für die Reaktion auf Sicherheitsvorfälle entwickeln und diese regelmäßig durchspielen, um sie zu bewerten und zu optimieren. Ihr Reaktionsplan sollte gut dokumentiert sein sowie die Rollen und Verantwortlichkeiten aller Beteiligten gründlich erklären. Dann muss der Plan getestet werden, um sicherzustellen, dass Ihre Mitarbeiter so arbeiten, wie sie geschult wurden. Je besser Ihre Mitarbeiter vorbereitet sind, desto geringer ist die Wahrscheinlichkeit, dass sie kritische Fehler machen.

Folgende Fragen sollten beantwortet werden:

• Sind die Mitarbeiter bezüglich der Sicherheitspolitik geschult worden?
• Wurden die Sicherheitsrichtlinien und der Plan zur Reaktion auf Vorfälle von der zuständigen Leitung genehmigt?
• Kennt das Incident Response Team seine Aufgaben und die erforderlichen Benachrichtigungen, die es vornehmen muss?
• Haben alle Mitglieder des Incident Response Teams an Übungen teilgenommen?

Identification

In der zweiten Phase geht es darum, herauszufinden, ob ein Incident vorliegt. Die Analyse vorliegender Daten aus Log-Management-Systemen, IDS/IPS, Threatsharing-Systemen sowie von Firewall-Protokollen und Netzwerkaktiväten z. B. über ein SIEM, hilft bei der Einordnung der entsprechenden Events. Sobald eine Bedrohung identifiziert wurde, sollte sie der festgelegten Richtlinie entsprechend dokumentiert und kommuniziert werden.

Der Bewertungsprozess (Triage) kann komplett im STORM Prozessmanagement abgebildet werden. Events sind Ereignisse, Incidents sind Vorfälle. Andere Systeme zum Beispiel melden üblicherweise Events. Die Einordnung, ob dieses Event ein Incident ist, zu einem Incident gehört oder fälschlicherweise positiv angezeigt wird, wird durch den Analysten, der die Triage durchführt, vorgenommen. Zum Verständnis ein Beispiel aus der realen Welt: Die Eingangstür eines Hauses ist offen (Event). Nun schauen Sie nach, ob jemand in der Wohnung ist oder etwas entwendet wurde (Triage). Wenn etwas entwendet wurde oder jemand in der Wohnung ist, wird es zum Incident.

Ein zusätzliches STORM Feature kann zudem den eigenen Ticketbestand schnell nach ähnlichen Mustern durchsuchen. Eventuell ist die IP-Adresse schon bekannt? Gab es bereits solche Events oder Incidents?

Wie bereits erwähnt, kann aus einem Event ein Incident werden (True Positive). Wie das von statten geht, hängt vom jeweiligen System ab. In STORM wird in diesem Fall das Event-Ticket automatisch geschlossen und ein neues Ticket erstellt, was den Incident behandelt.

Mit STORM kann ein Analyst im Incident-Ticket Sicherheitsempfindlichkeitsstufen über die Farbkodierung des TLP (Traffic Light Protocol) in automatischen E-Mail-Benachrichtigungen signalisieren. Das Ziel: Den berechtigten Empfängern bereits mittels schriftlicher und visueller Zeichen Informationen über die Informationsvertraulichkeit mitteilen.

Das Protokoll sollte sowohl das Ausmaß als auch die Auswirkungen des Incidents mitteilen und alle Informationen so detailliert wie möglich wiedergeben. Diese Informationen können später in der Phase „Lessons Learned“ für eine detaillierte Review verwendet werden.

Containment

In der Containment-Phase muss das Incident Response Team daran arbeiten, die Bedrohung einzudämmen. Ziel ist es, weitere Schäden an anderen Systemen zu verhindern. Es stellen sich Fragen wie: Wie ist die Schadenssoftware überhaupt reingekommen? Welche Sicherheitslücken gab es? Manchmal werden beim Evaluieren des Hergangs forensische Analysen zur Unterstützung herangezogen. In STORM gibt es hierfür die Funktion innerhalb eines Tickets: einen neuen „Task erstellen“.

Die Erstellung eines „Task“-Tickets dient dazu, für den Incident uninteressante Informationen, wie zum Beispiel den Auftrag für den Forensiker, den Techniker, die Rechtsabteilung, oder dem Marketing, abzuspalten. Relevante Informationen hingegen, wie zum Beispiel das Analyseergebnis der Forensik, laufen zurück in das Incident-Ticket sowie die getroffenen Maßnahmen. Dadurch ist es einfach, zu jeder Zeit den Überblick zu behalten.

Die Eindämmung dient dazu, die Schadsoftware „einzusperren“. Das heißt, eine weitere Ausbreitung zu verhindern. Dies kann durch das Herunterfahren von Systemen oder das Abschalten des Netzwerks (Kabel ziehen) erfolgen.

Eradication

Ist die potentielle Bedrohung eingedämmt, muss herausgefunden werden, was die Ursache (Root Cause) des Incidents bzw. des Problems war, um alle Spuren zu beseitigen. Das bedeutet, dass alle Malware sicher entfernt, die Systeme gepatcht, Updates eingespielt und ggf. die Software aktualisiert werden sollten.

Recovery

Nun geht es daran, innerhalb der Recovery-Phase vom Incident betroffene Systeme und Geräte wiederherzustellen und in ihre Geschäftsumgebung zurückzuführen. Dies wird meist von der IT durchgeführt. Das Security Team gibt in diesem Schritt die Systeme sozusagen für die IT frei.

Außerdem legt das Incident Response Team fest, zu welchem Zeitpunkt der Betrieb wiederhergestellt wird, ob infizierte Systeme vollständig gesäubert und wiederhergestellt werden. Fragen, die Sie sich während der Recovery-Phase stellen sollten:

• Wann können die Systeme wieder in Produktion gehen?
• Sind die Systeme gepatcht und getestet worden?
• Kann das System von einem vertrauenswürdigen Backup wiederhergestellt werden?

Lessons Learned

Zu guter Letzt: die Lessons Learned. In dieser Phase geht es darum, zu prüfen was während des Prozesses gut und was schlecht lief. Das beinhaltet die Abwicklung des Incidents, aber auch die Erkennung z. B. durch das SIEM. Daraus lassen sich Änderungen von Erkennungsmustern, Sicherheitsmaßnahmen und/oder Schulungen von Mitarbeitern ableiten.

Eine Schlüsselfrage, die sich während der Lessons-Learned-Phase stellt, ist „wer wusste wann welche Informationen?“ Da Sicherheitsumgebungen oft auf einer „need to know“-Basis funktionieren und die Bedeutung der Frage, wer über den Vorfall Bescheid wusste und wer Maßnahmen im Zusammenhang mit dem Vorfall ergriffen hat, von entscheidender Bedeutung ist. Mit STORM werden alle Aktivitäten protokolliert und denjenigen, die entsprechenden Zugriff haben, schreibgeschützt zur Verfügung gestellt: Dazu gehören alle Ticketdaten, z. B. wer einen Artikel gelesen oder einen Anhang heruntergeladen hat. Diese exklusiven STORM Funktionen machen das Auditing genauer und viel einfacher.

Im Nachgang eines Incidents wird eine detaillierte Nachbesprechung aller Beteiligten des Sicherheitsvorfalls empfohlen. Stellen Sie sicher, dass Sie folgende Fragen bezüglich des Incident Managements beantworten:

• Welche Änderungen müssen an der Sicherheit vorgenommen werden?
• Welche Schwächen wurden ausgenutzt?
• Wie wird sichergestellt, dass sich etwas ähnliches nicht wiederholt?
• Sollten Mitarbeiter anders ausgebildet werden?

Eine Studie der OTRS Group hat herausgefunden, dass 66% der IT-Verantwortlichen einen Anstieg der Sicherheitsvorfälle verzeichnet haben. Demnach müssen und sollten Unternehmen ihre IT zunehmend absichern. STORM kann hier das geeignete Tool sein. Unsere Security-Experten analysieren mit Ihnen zusammen den IST-Zustand, designen dann die passende Lösung für Ihre IT und setzen diese anschließend um.

Erfahren Sie mehr über STORM