Managed SIEM/SOC in einem hybriden Modell – Teil 4 Implementierung und GoLive eines Managed SIEM oder SOC

Anbieter zum Thema

Vogel IT-Medien GmbH

Arvato Systems

Fujitsu Technology Solutions GmbH

Ist im Unternehmen die Entscheidung für das Outsourcing von IT-Security-Services gefallen, wurde die Umsetzung organisatorisch strukturiert geplant und wurde die Auswahl des MSSP in einem mehrstufigen Verfahren getroffen, ist der Zeitpunkt der Umsetzung gekommen. Der vierte Teil der Serie liefert mögliche Fragestellungen, zu Toolauswahl sowie Implementierung und geht auf mögliche Fallstricke des Service-GoLive ein.

Die Tool-Frage und die grundlegende Architektur der Implementierung ist bei einem ausgelagerten Service (eigentlich) eher sekundär, sollte beim Service „Managed SIEM“ aber im Hinblick auf die Kompatibilität trotzdem näher betrachtet werden. Eventuell existieren entsprechende Fragenkataloge und verwertbare Festlegungen bereits auf Seiten des Auftraggebers, ebenso Erfahrungen aus z. B. zurückliegenden Projekten. Folgende, mögliche Fragen verschaffen einen Überblick:

• Liefern die eingesetzten Systeme und Services auf Seiten des Auftraggebers die relevanten Informationen zur Abbildung der spezifizierten Usecases?

• Welche Komponenten für die Managed-SIEM-Plattform muss der Auftraggeber bereitstellen, wo genau liegt der Verantwortungsübergang?

• Ist der Einsatz von Logkollektoren auf Endpoints vorgesehen und zulässig? Wenn ja, sind die Spezifikationen der Logkollektoren kompatibel zu den eingesetzten Betriebssystemversionen und Richtlinien, z. B. Stichwort „Non-root-Betrieb“?

• Erhält der Auftraggeber dauerhaft Zugriff auf die SIEM-Plattform und/oder die zugrunde liegenden Systeme?

• Werden die durch die SIEM-Plattform erhobenen Daten ausschließlich vom SOC verarbeitet oder liegen Anforderungen aus nachgelagerten Verteidigungslinien (z. B. Compliance, Revision) vor? Wichtig ist dies auch vor dem Hintergrund der Log-Retention und dem Sizing der Systeme.

• Welche Methode wird beim Update verwendet? Setzt diese gar eine Servicedowntime voraus?

• Welche Schnittstellen bzw. zusätzliche Tools werden im Detail während der Vertragslaufzeit für das Handling der Security-Incidents genutzt und/oder bereitgestellt?

• Wie sehen die seitens des MSSP vorgesehenen Regelungen bezüglich der Gewährleistung für das oder die eingesetzte(n) Produkt(e) aus?

Managed SIEM/SOC in einem hybriden Modell – Teil 1

Praxistips zum Outsourcing von Services in der Informationssicherheit

Auch wenn die die eigentliche Leistungserbringung bis hin zum SIEM-Lifecycle-Management extern erbracht werden soll ist es sinnvoll, entsprechendes Tool-spezifisches Know-How auf Seiten des Auftraggebers aufzubauen bzw. auszuweiten. Welche Lernpfade sehen entsprechende Tool-spezifische Schulungsprogramme vor? Auch hier können Lernerfolge durch entsprechende Personenzertifizierungen nachgewiesen werden. Die überwiegende Zahl der SIEM-Tools am Markt werden volumenabhängig (Datenvolumen, Events per Second und/oder kombiniert) lizenziert. Existieren bereits Installationen eines seitens des MSSP favorisierten Tools auf Seiten des Auftraggebers, die noch Potential beim Ausreizen der Lizenz bzw. einen Discount ermöglichen? Während der Vorfallsbehandlung ist es gängige Praxis, die Loglevel nach oben anzupassen. Die Kalkulation der benötigten Lizenzen auf Basis der Datenmenge sollte daher eine dahingehende Toleranz berücksichtigen. In wessen Infrastruktur bzw. Verantwortung liegen die erhobenen Daten? Ein mögliches Kriterium gegen die Berücksichtigung im weiteren Auswahlverfahren, stellt die Weiterleitung, Speicherung oder Verarbeitung der Daten in/im Nicht-EU-Ausland dar.

Definition von KPIs als Basis für die kontinuierliche Verbesserung

Um die Servicequalität messbar zu gestalten und getätigte Investitionen fortlaufend begründen zu können, sind speziell für „Managed SIEM“ und „Hybrid SOC“ die vertragliche Definition relevanten KPIs essentiell wichtig, hier mögliche Beispiele:

• Summe aller behandelten Incidents pro Incidentkategorie

• Mean time to detect je Incident-Kategorie

• Anzahl der Incidents pro Zeiteinheit

• Aufgewendete Zeit pro Incident (Gesamtsumme und Differenzierung z. B. Auslösung, Disposition, Auflösung)

• Impact-Analyse: Kosten und mögliche Downtime pro Incident

• Anzahl der False-Positives pro Zeiteinheit

Fragen an den MSSP in diesem Zusammenhang: Wie und auf welcher Basis erfolgt die Erhebung relevanter Daten für die Berechnung? Sind die Anwendungs- und Berechnungsmodelle der MSSP untereinander vergleichbar? Die KPIs gilt es während der Servicelaufzeit turnusgemäß in Servicemeetings zu thematisieren und bei Auffälligkeiten entsprechende Maßnahmen abzuleiten. Ein weiterer Schwerpunkt der Servicemeetings ist die tiefergehende Analyse bei der Bearbeitung konkreter Incidents aus der Retroperspektive:

• Wie war der genaue zeitliche Verlauf von der Detektion bis zum Recovery?

• Wer war involviert?

• Was lief gut, was schlecht?

• Welche Informationen hätten rascher bereitgestellt werden müssen?

• Welche Indikatoren sollten künftig mit in die Bewertung/Kategorisierung einfließen?

• Welche zusätzlichen Tools oder Ressourcen werden benötigt, um zukünftige Vorfälle rascher zu erkennen, besser zu analysieren und deren Impact zu mindern?

Managed SIEM/SOC in einem hybriden Modell – Teil 2

Planung und Umsetzung von Outsourcing

Orientierung am Deming-Cycle

In diesen Meetings ist auch die Anwendung der aktuell jeweils implementierten Usecases auf mögliche Veränderungen in der Organisation des Auftraggebers zu prüfen. Auf dessen Seite muss ein ausgeprägtes Bewusstsein dafür vorhanden sein, dass möglicherweise bereits kleinste Veränderungen in den Rahmenbedingungen (z. B. verändertes Risikoprofil bei der Anpassung der Ziele der Organisation oder IT-Strategie), der eingesetzten Technologien (z. B. Hardware, Software, Cloud) oder bei externen Faktoren (z. B. überarbeitete Version regulatorischen Auflagen) eine direkte Auswirkung auf die extern erbrachten Information-Security-Services haben. Dies ist daher fortlaufen zu prüfen und zusammen mit dem MSSP zu bewerten. Um zeitaufwendige, manuelle Tätigkeiten bei der Vorbereitung dieser Servicemeetings zu umgehen, sollten entsprechende Informationen automatisiert zur Verfügung bzw. abgeglichen werden, beispielsweise via KPI-, SLA-Dashboard, Report oder Überblick über die aktuellen Service-Requests, den Lizenzstatus oder der Abgleich der Asset-Informationen. Dieses Vorgehen stellt auch sicher, dass belegbare Fakten objektiv in Echtzeit thematisiert werden können und nicht in Form von Freitextfeldern in Präsentationen. Die Verantwortlichkeit für die inhaltliche Planung der Servicemeetings, deren Agenda, Intervall, Dauer, die der eingesetzten Werkzeuge und Kommunikationsplattformen sowie der personellen Besetzung sollte ebenfalls in den PoCs abgestimmt werden und fester Vertragsbestandteil sein. Die automatisiert bereitgestellten Daten sind auch die Basis für die Sicherstellung des kontinuierlichen Verbesserungsprozesses und erlauben es darüber hinaus, diese für die Erstellung von Reports zu nutzen. Sicher existieren dahingehend Anforderungen seitens der Geschäftsleitung, der zweiten oder dritten Verteidigungslinie.

Finale Auswahl durch das Steering-board

Die Liste an Empfehlungen und weiterer Fragen lässt sich beliebig erweitern. Wichtig ist, dass der MSSP, wie bereits thematisiert, alle für Ihn relevanten Informationen erhält und der Auftraggeber seinerseits alle für die finale Entscheidung relevanten Inhalte in Erfahrung bringt und objektiv weiterverarbeitet. Das Steering-board muss bei finalen Lieferantenauswahl befähigt werden, objektiv nach Faktenlage zu entscheiden.

Managed SIEM/SOC in einem hybriden Modell – Teil 3

Den richtigen MSSP finden

Implementierung und GoLive

Nach der finalen Entscheidung für einen MSSP steht die Umsetzung auf Basis der in den zurückliegenden Phasen geplanten Aktivitäten an. Mögliche Issues sollten daher im Rahmen der Projekttoleranzen aufgelöst werden können. Im Idealfall sind zu diesem Zeitpunkt im Projekt auch die parallel zur MSSP-Auswahl umgesetzten Tätigkeiten (Professionalisierung von Aufbauorganisation und Workflow-Management, Auswahl/Screening & Onboarding neuer Mitarbeiter) rund um das Erlangen relevanter Fähigkeiten und Kompetenzen auf Experten-Niveau abgeschlossen. Dadurch entsteht die Option, ein oder mehrere Tabletop-Exercises zusammen mit dem MSSP vor dem GoLive durchzuführen. Ziel ist es, dabei mindestens einen konkreten Fall pro Kategorie eines Security-Incidents zu simulieren. Dies impliziert, dass auch schwerwiegende Vorfälle bis hin zu forensischen Analysen mit einhergehender gerichtsfester Sicherung von Evidenzen (Chain of Custody) und Meldungen an Behörden unter Laborbedingungen trainiert werden. Die Erarbeitung realistischer Szenarien und die Verantwortung für die Maßnahme obliegt dem Auftraggeber. Sämtliche Tätigkeiten und Erfahrungen sollten in die Weiterentwicklung der Checklisten und Runbooks einfließen, die auch im Fall der Fälle zum Einsatz kommen. Die Wahrscheinlichkeit ist hoch, dass in dieser späten Projektphase und der Zeit nach dem Projekt Lücken beim Reifegrad entsprechender Prozesse und/oder Fähigkeiten zu Tage treten. Das Projekt kann daher nur die Basis für Folgetätigkeiten schaffen. Daher sollte während des Projekts die Verantwortung für die Weiterentwicklung der im Projekt erarbeiteten Management- und Spezialisten-Produkte konkret festgehalten und zugeordnet werden. Unmittelbar nach dem GoLive der Services ist die Wahrscheinlichkeit sehr hoch, dass es trotz dem vermeintlichen Ausschluss aller möglichen Unwägbarkeiten zu „Anlaufschwierigkeiten“ kommt. Das kann technische (z. B. Ausfall der Schnittstelle Assetmanagement-SIEM) oder organisatorische (falsche Zuordnung im Rechte-/Rollenmodell) Gründe haben. Daher sollte daher eine Transition-Phase eingeplant werden, deren Dauer sich am Projektscope orientiert und bereits in der Projektplanung zeitlich gedeckelt wird. Erst nach Abschluss der Transition-Phase sollte ein „Low Watermark“ bezüglich der oben beschriebenen Maßnahmen zur quantifizierbaren, kontinuierlichen Verbesserung Anwendung finden.

Fazit

Eine Auslagerung entbindet den Auftraggeber nicht von der Pflicht für die Betriebsverantwortung. Dennoch kann durch das Zurückgreifen auf extern erbrachte Services das Sicherheitsniveau relativ rasch erhöht werden. Wichtig ist dabei, die Implementierung von den individuellen Zielen der Organisation abhängig zu machen, eine Top-Management-Attention für das Thema zu wecken und trotz ggf. nur partieller Auslagerung adäquate Ressourcen in angemessener Form zur Verfügung zu stellen. Existierende Standards und Best-Practice-Ansätze liefern praxiserprobte Vorlagen. Jedes vernetzte Element kann Ziel eines Angriffs werden, das Zitat „It is not a matter if but when” wurde bereits x-fach in der Öffentlichkeit verwendet. Organisationen sollten sich daher entsprechend wappnen und Simulationen kontinuierlich durchführen und qualitätssichern. Eins muss dennoch klar sein: Der Zustand wird nie perfekt sein, aber kontinuierlich besser (in Anlehnung an ISO/IEC 27001, clause 10.2).

Managed SIEM/SOC in einem hybriden Modell – Teil 1

Praxistips zum Outsourcing von Services in der Informationssicherheit

Managed SIEM/SOC in einem hybriden Modell – Teil 2

Planung und Umsetzung von Outsourcing

Managed SIEM/SOC in einem hybriden Modell – Teil 3

Den richtigen MSSP finden

Managed SIEM/SOC in einem hybriden Modell – Teil 4

Implementierung und GoLive eines Managed SIEM oder SOC

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

(ID:47382346)