Von Jägern und Verwaltern Verbreitete Trugschlüsse in der Operativen Informationssicherheit

Anbieter zum Thema

Arvato Systems

Rapid7 Germany

Keeper Security EMEA Ltd.

Firmen unterliegen oft dem Trugschluss, operative IT-Sicherheit ließe sich ohne dedizierte Experten-Teams im „Tagesgeschäft mitverwalten“. Ein weiteres Risiko ist die Annahme, durch Einsatz von Werkzeugen und Technologie die OnPrem- und Cloud-Welt in einem akzeptablen Security-Reifegrad betreiben zu können. Mandate, Rollen vor- und nachgelagerte Managementsysteme mit definierten Prozessen und Kontrollen werden zu oft nicht oder nur sekundär betrachtet.

Die Hinweise auf die log4j-Schwachstelle im Dezember 2021 hat gezeigt, welchen Impact eine vulnerable Bibliothek selbst in KMU haben kann. Welche Primary Assets, welche Services, welche Systeme, welche Lieferanten sind sicher oder möglicherweise betroffen? Welche Maßnahmen müssen ergriffen werden, um die Lücken durch Patchen oder Mitigation zu eliminieren oder zumindest das Risiko zu minimieren? Wer koordiniert die Maßnahmen, wer setzt sie um? Wer hat den Überblick, welches Mandat, Rolle bzw. Verantwortlichkeit? On Top, unabhängig von log4j: Sind alle Linux-Server in der Organisation bekannt und werden deren Software-Release-Stände, Service-Konfigurationen und Härtungsmaßnahmen aktiv gemangt? Sind alle Assets im Drucker-LAN ausschließlich Druckern zuzuordnen? Sind die Antworten auf die Fragen übergreifend mit objektiven Fakten belegbar, oder werden die Informationen dezentral in Köpfen oder Tabellen verwaltet? Wer kümmert sich aktiv um die 300 Meldungen in der „Cloud Security Plattform“? Wie sehen die Policies, Prozesse und Kontrollen dazu aus? Welche Services betreiben wir eigentlich in der Cloud und/oder zusammen mit Dienstleistern?

Basis: Asset-Management, ISMS und Top-Management-Commitment

Eine Nahezu-Echtzeitauswertung auf Basis der Informationen in einem übergreifenden Asset-Management-System (Stichwort „Führendes System“) ist Grundvoraussetzung dafür, in einem initialen Schritt die relevanten Informationen erheben zu können. Die beispielsweise durch Software-Agenten auf Endpoints, Verwaltungstools oder durch entsprechende Werkzeuge der Hyperscaler erhobenen Daten decken dabei aber nur die Erfassung „bekannter Systeme“ ab. Daten und Informationen aus z. B. Pentests, aktiven und passiven Device-Discovery-Tools lassen die Blind-Spots und „vergessenen Systeme“ aufspüren, von denen erfahrungsgemäß ein höheres Risiko ausgeht, und müssen ebenfalls in das führende System integriert werden. Idealerweise sind die Primary und Supporting Assets im „führenden System“ miteinander verknüpft, sodass Asset- und Risk-Owner rasch eine fundierte und objektive Einschätzung für korrigierende bzw. mitigierende Maßnahmen treffen können. Jede Organisation sollte daher vorab diese Rollen für Primary und Supporting Assets beispielsweise im Sinne der ISO/IEC 27005 definiert haben, um der Organisation einen wirklichen Mehrwert bieten zu können (siehe ergänzend dazu: Maßnahmen zur Risikoanalyse und Risikobehandlung ). Grundlage dafür ist wiederum, dass das Senior-Management entsprechend sensibilisiert ist, hinter dem ISMS steht, ausreichend Ressourcen bereitstellt und einen kontinuierlichen Verbesserungsprozess (KVP) nicht nur unterstützt, sondern entsprechende Kennzahlen definiert und Maßnahmen aktiv einfordert.

Aufbau- und Ablauforganisation

Relativ rasch wird dabei klar werden, dass das (isolierte) Vorgehen in Säulen und Silos konträr zur dauerhaften Sicherstellung einer übergreifenden Kontrolle ist. Die Verzahnung der Abhängigkeiten unterschiedlichster Typen von Assets, Informationen, Prozessen und Kontrollen untereinander verlangt nach einem integrativen Querschnittsdienst, der das Mandat besitzt, unabhängig vom „Tagesgeschäft“, operativ die Kernfunktionen eines Security Operations Center (SOC) wahrzunehmen. Insbesondere in regulierten Branchen ist dies, bis hin zur Nennung rudimentärer Aufgabenbeschreibungen und beispielhafter Nennung des Begriffs, Bestandteil der aktuellen Anforderungen. Doch Vorsicht: Die Aufwände für den Aufbau eines SOC mit Ziel „Erfüllung von Mindestanforderungen“ weichen mitunter signifikant von denen für mit dem Ziel einer nachhaltigen, strategisch an den Zielen der Organisation abgeleiteten Ausrichtung ab.

Make or buy?

Ob die Spezialisten des SOC neben möglichen Kernfunktionen wie z. B. Detektion, Triage, Investigation oder Incident Response auch die Ende-zu-Ende-Verantwortung für das Tool-Engineering übernehmen bzw. hinsichtlich Ressourcenausstattung übernehmen können, hängt von den individuellen Rahmenbedingungen der jeweiligen Organisation ab. Vielfach wird in diesem Zusammenhang ein Teil der Tätigkeiten, bzw. der in diesem Kontext stehender Risiken, ausgelagert. Auch der Grad dieser Auslagerung kann dabei, in Anlehnung an die vielfältigen Servicemodelle von Managed Security Service Providern (MSSP), frei definiert werden. Ein entsprechender Leitfaden geht im Detail auf diese Aufgabenstellung ein. Festzuhalten ist, dass der Auftraggeber die Zieldefinition („Desired state“) z. B. via Lastenheft vorgibt, Tools und MSSP lediglich Hilfsmittel darstellen, diese zu erreichen.

Qualität, Threat Intelligence und 3rd Party Risk

Bei der personellen Ausstattung eine SOC sollte berücksichtigt werden, dass hier Qualität vor Quantität gefordert ist und es aufgrund der wachsenden Komplexität der IT-Systeme weitaus weniger „IT-Generalisten“ existieren als vielleicht angenommen. Darüber hinaus muss oft ein Bewusstsein geschaffen werden und die Befähigung vorhanden sein, auch einmal die Perspektive eines potenziellen Angreifers einzunehmen, den es initial zu kategorisieren (Typ, Motivation, Raffinesse, …) gilt – Stichworte: Skript-Kiddie vs. Stattlich motivierte/unterstützte Organisationen. Das SOC stellt auch Schnittstellen zu z. B. Branchenverbänden und externen Leistungserbringern bereit. Letzteres setzt dabei auch eine enge Verzahnung innerhalb der eigenen Organisation voraus, z. B. dem Vendor-Management. In der Beziehung zu Lieferanten muss z. B. via Service Level Agreement geregelt sein, dass, wie und in welchem Zeitraum, Informationen über Schwachstellen oder Informationssicherheitsvorfälle an den Auftraggeber gemeldet werden bzw. welche Optionen existieren, diese Informationen von Seiten des Auftraggebers einzufordern. Jede Organisation muss stets ein objektives Lagebild über die internen und externen Bedrohungen, Verwundbarkeiten und Risiken in Bezug auf Informationssicherheitsbelange haben, um auf Incidents angemessen reagieren zu können.

Kategorisierung von Incidents

Sie ist daher aufgefordert, die individuellen Faktoren zu identifizieren, die für die Kategorisierung von Incidents relevant sind. Ein möglicher Leitfaden stellt der Annex A der ISO/IEC 27035-3 dar. Bei näherer Betrachtung wird klar, dass sich in Bezug auf die Integration des Top-Managements hier der Kreis schließt. Ziel muss daher sein, Verantwortliche zu befähigen, jederzeit auf Basis objektiver Fakten die richte(n) Entscheidung(en) treffen zu können.

Fazit

Der Aufbau eines SOC ist mit nicht zu unterschätzenden Aufwänden verbunden. Der Top-Management-Support ist dabei essenziell. Es ist unrealistisch anzunehmen, SOC-Funktionen im „Tagesgeschäft mitzuverwalten“. Bei der Implementierung sollte ein induktiver Ansatz, beispielsweise in Form eines Projekts mit einem Phasenmodell gewählt werden. Um den obligatorischen KVP ab Projektstart zu integrieren, empfiehlt es sich dabei direkt auf ein Reifegradmodell zu setzen, um so ab Tag 1 angemessen und objektiv priorisieren zu können.

Über den Autor: Markus Thiel unterstützt Organisationen bei Fragestellungen zu ISMS, SIEM, SOC und Incident Response Management.

(ID:48377983)