Security Incident Response Management Strukturierte Planung einer Incident Response Readiness

Anbieter zum Thema

Fsas Technologies GmbH

FTAPI Software GmbH

Security Incident Response Management wird zu oft als „reines IT-Problem“ angesehen. Diese Denkweise und daraus vielfach abgeleitete Bereitstellung von Ressourcen lassen eine angemessene Reaktion auf einen Incident daher vielfach nur bedingt zu. Etablierte Standards liefern ein top-down-orientiertes, strukturiertes Vorgehensmodell.

Auf Basis des GmbH Gesetz §43 Abs. 1 und 2 bzw. Aktiengesetz §91 Abs. 2 ist letztendlich die Unternehmensleitung für die Sicherstellung des Betriebes in der Organisation verantwortlich. Durch Studien belegte Argumente und praktische Tipps zum Management von Risiken bis hin zu Checklisten liefert ein Handbuch für Unternehmensvorstände und Aufsichtsräte. Auch der risikoorientierte Ansatz der ISO 27000 Normenreihe impliziert das Einbeziehen des Top-Managements in die Identifikation der Primary Assets (business-relevante Prozesse und Aktivitäten) und Supporting Asssets (Gebäudeinfrastruktur, Menschen, Reputation, Services, Hardware, Software, Industrial Control Systems, Shopfloor-Systeme, IoT-Devices,…). Spätestens der anschließenden Risikoanalyse und -bewertung wird allen Beteiligten bewusst werden, dass IT lediglich eine Teilmenge der Informationssicherheit darstellt und die Aktualität und hohe Qualität der Daten in verwendeten Managementsystemen (Asset, Vulnerability, …) unerlässlich ist.

Standards nutzen

A16 des Annex A der ISO/IEC 27001 liefert die relevanten Controls zu Konformität gegenüber dem internationalen Standard. ISO/IEC 27035-1 und ISO/IEC 27035-2 beschreiben in der initialen Phase „Plan and Prepare“ ein risiko-orientiertes Vorgehensmodell der Planung einer Implementierung eines Information Security Incident Managements.

Voraussetzungen schaffen

Die angewendeten Richtlinien im Bereich der Informationssicherheit müssen kompatibel zu den individuellen Zielen der Organisation ausgearbeitet werden und einem iterativen Prozess der Qualitätssicherung unterliegen. Ein Teil dieser Richtlinien umfasst die verbindliche, schriftlich fixierte Vorgehensweise bei Vorfällen, der Information Security Incident Policy bzw. der daraus abgeleiteten Prozesse und Verfahren in einem Security-Incident-Management-Plan. Die effektive Anwendung (z. B. Faktor Geschwindigkeit) der Inhalte dieser Vorgabedokumente im „Fall der Fälle“ muss sicherstellen, dass die Auswirkung eines Security-Incidents auf die Organisation begrenzt wird und alle internen und externen Stakeholder entsprechend ihrer Rolle und Verantwortlichkeit integriert bzw. informiert werden. Grundlegende Maßnahmen, Mandate (z. B. Abschalten eines Online-Shops), die Methodik einer Priorisierung und Grundsätze einer effektiven Kommunikation bis hin zu verwendeten Sprachen sollten ebenfalls definiert werden.

Stakeholder identifizieren & Policy erstellen

Während der Incident-Behandlung sind neben der IT also innerhalb der Organisation, je nach Incident-Kategorie, möglicherweise auch Datenschutz, Vertrieb, HR, PR, Legal und/oder das Top-Management zu involvieren. Werden Services von externen Providern erbracht, müssen diese möglicherweise ebenfalls in das Incident Response Team (IRT) integriert werden. Außerhalb der Organisation bestehen gesetzlich vorgeschriebene Meldepflichten innerhalb zeitlicher Fristen gegenüber (Aufsichts)-Behörden und möglicherweise Vertragspartnern, Lieferanten oder Kunden. Es ist also essentiell wichtig, die individuellen Rahmenbedingungen und Anforderungen der Organisation bereits in der Planung der Security-Incident-Policy zu identifizieren, zu analysieren und zu berücksichtigen. Dazu gehört es auch, die Mitarbeitervertretungen bzw. die Personalräte/Betriebsräte zu informieren bzw. aktiv einzubeziehen.

Prozeduren, Formulare und Kommunikationsplattform(en) planen

Zur Sicherstellung der späteren Nachvollziehbarkeit aller Tätigkeiten während der Incident-Behandlung ist eine standardisierte Dokumentation aller Schritte elementar wichtig. Diese Vorgehensweise erlaubt es auch, belegbare Fakten für die Etablierung eines iterativen Prozesses zur Qualitätssicherung bzw. -verbesserung bereitzustellen und ermöglicht es darüber hinaus, dass diese Fakten bei einer möglichen forensischen Analyse bis hin zur Sicherung von Evidenzen herangezogen werden können. Die Definition bzw. Erstellung entsprechender, standardisierter Prozeduren und Formulare sollte daher ebenfalls Bestandteil der Planung sein. Bei dieser sollte auch davon ausgegangen werden, dass Standard-Kommunkationsplattformen der Organisation (VoIP-Telefonie, Collaboration-Tools, Incident-Verwaltungs-Systeme, …) während der Incident-Behandlung möglicherweise kompromittiert und damit nicht oder nur eingeschränkt verfügbar bzw. nutzbar sind. Entsprechende Alternativen sollten daher gesondert betrachtet und deren praktische Anwendung ausgearbeitet werden.

Üben, testen, validieren

Breach and Attack Simulationen (BAS) unterstützen dabei, die meist über umfangreiche Dokumente hinweg beschriebenen, theoretischen Inhalte zielgerichtet und in vorab festgelegtem Scope praxisnah anzuwenden. Angekündigte Simulationen können in Form einer Annahme (z. B. Tabletop-exercise) gefahren werden. Dies ermöglicht insbesondere vor dem initialen GoLive nochmals die Option einer Validierung des ausgearbeiteten Security-Incident-Management-Plans. Praktische Live-Simulationen ermöglichen es über den theoretischen Ansatz hinaus, weitere Erkenntnisse zu sammeln, beispielsweise den Reifegrad implementierter Metriken/Tools/Prozesse zur Detektion/Triage, Grenzen volumenabhängiger SIEM-Lizenzmodelle, Funktion von Schnittstellen/APIs, Meldeketten, Fähigkeitslücken innerhalb der Organisation, unzureichende Klassifizierung von Dokumenten, usw. Letztendlich liefern nur unangekündigte Simulationen objektive und realitätsnahe Szenarien. Es sollte daher (evtl. aus Rücksicht auf Beteiligte) nicht davor zurückgeschreckt werden, diese in Randzeiten bzw. in/an Ferien/Wochenenden zu terminieren. Unabhängig von Art und Umfang der Simulation ist die schriftlich dokumentierte Ergebnissicherung und die nachfolgende Lessons-Learned-Session für die dauerhafte Sicherstellung der Konformität gegenüber den Vorgabedokumenten unabdingbar. Neben der Betrachtung der positiven Erkenntnisse sollten dabei insbesondere Abweichungen und die stringente Nachverfolgung priorisierter Maßnahmen im Fokus stehen.

Outsourcing und Herausforderungen

Organisationen gehen beispielsweise vor dem Hintergrund des zunehmenden Fachkräftemangels verstärkt dazu über, einige der oben genannten Leistungen von Managed Security Service Providern (MSSP) zu beziehen. Dies entbindet den Auftraggeber nicht von der Verpflichtung, fortlaufend Umfang, Qualität und Güte der erbrachten Leistungen zu prüfen. Es ist daher sicherzustellen, dass, trotz Auslagerung, entsprechende Fähigkeiten zur Bewertung der gelieferten Ergebnisse auf Seiten des Auftraggebers in quantitativem und qualitativem Umfang vorgehalten werden. Wichtig ist auch, über offensive Skills innerhalb der Organisation zu verfügen um aktuelle Verhaltensmuster und Vorgehensweisen potentieller Angreifer zu kennen, erkennen und verstehen.

„Plan and Prepare“ and beyond

Eine qualitativ hochwertige Planung des Security Incident Response Management ist das Fundament für eine angemessene Reaktion. Technologie kann dabei begrenzt unterstützen („Technology doesn´t win a war“). Wichtiger ist, die relevanten Menschen innerhalb und außerhalb der individuellen Organisation zu identifizieren und aktiv in die Planung zu integrieren. Ziel ist eine angemessene Reaktion sicherzustellen und dabei stets routiniert und besonnen vorzugehen.

Über den Autor: Markus Thiel unterstützt Organisationen bei Fragenstellungen zu ISMS, SIEM/SOC, Incident Response Management und risiko-orientierten Awareness-Trainings.

(ID:46849401)