Banner Aktuelle IT-Sicherheit Online-Schulungen Rabatt
Artikel kostenlos lesen

Resilience und Management-Systeme : Aspekte der Qualität in Sicherheits- und Datenschutzmaßnahmen

Der vorliegende Beitrag liefert eine Definition der Resilience und ergründet kurz ihre Korrelation mit klassischen Sicherheitszielen. Im Hauptteil geht es darum, wie man dieses Konzept in Maßnahmen und Management-Systemen zur Informationssicherheit (ISMS) und zum Datenschutz (DSMS) berücksichtigen kann und sollte.

Lesezeit 11 Min.

Von Bernhard R. Barz und Daniel Effenberg, Aachen

Mit der zunehmenden Digitalisierung werden auch Technikfolgenabschätzungen im Sinne der Beherrschbarkeit entsprechender Risiken immer bedeutsamer – es stellt sich die Frage, ob die derzeitigen Perspektiven und Modelle zur Informationssicherheit und zum Datenschutz den gegebenen Anforderungen gewachsen sind. In diesem Umfeld ist häufig auch vom Begriff der Belastbarkeit/Widerstandsfähigkeit (engl. Resilience) die Rede.

Resilience kommt aus dem Lateinischen und wird im Allgemeinen mit „zurückspringen“ übersetzt. Erste Verwendungen gehen auf die frühen 1940er- bis 1950er-Jahre zurück, als der Begriff in der (Entwicklungs-) Psychologie als die Fähigkeit diskutiert wurde, trotz widriger und unterschiedlicher sozialer Umfelder ein erfolgreiches Leben zu führen. Über die Erweiterung in Ökonomie und Ökosystemen findet der Begriff heute zunehmend auch im Engineering Verwendung.

Ein allgemeiner Ansatzpunkt zur Begriffsdefinition im Umfeld der Digitalisierung ergibt sich durch eine Annäherung im Sinne der allgemeinen Systemtheorie (bspw. nach Günther Ropohl [1,2]): Ausgangspunkt ist der Betrieb eines Systems, das aus Einzelkomponenten oder einer Vernetzung mehrerer Komponenten und Systeme besteht. Dieses „Gesamt-System“ ist sowohl inneren Einflüssen als auch Einflüssen durch das Nutzungsumfeld ausgesetzt.

Aus Sicht der Funktionsfähigkeit des Gesamt-Systems entspricht Resilience als „Zielfunktion“ der Maximierung des Funktionserhalts in Abhängigkeit von ungewünschten Einflüssen. Wird ein Ausfall als Grenzzustand der Funktionsfähigkeit betrachtet, ergibt sich die Definition von Resilience als die Fähigkeit eines Systems, unter inneren und äußeren Störungen und Einflüssen einen betrieblichen (Gleichgewichts-) Zustand derart aufrechtzuerhalten, dass weiterhin eine – wenn auch eingeschränkte – Funktionalität gegeben ist. Oder in aller Kürze: Das System soll (weiter) funktionieren – beziehungsweise im Sinne der Digitalisierung: Daten verarbeiten.

Sicherheits- und Datenschutzziele

Die Definitionen der Informationssicherheitsziele Vertraulichkeit, Integrität und Verfügbarkeit in der ISO 27000 sind allesamt als Eigenschaften (Properties) von Assets definiert. Vertraulichkeit (Confidentiality) fokussiert explizit auf das Asset „Information“: Das System beziehungsweise seine Funktionen müssen sicherstellen, dass sie nur von berechtigten Entitäten einsehbar oder für diese verfügbar ist. Bei der Integrität (Integrity) ist durch das System (bzw. System-Funktionen) sicherzustellen, dass die Vollständigkeit und die Verlässlichkeit der Assets geschützt bleiben. Vertraulichkeit und Integrität sind also quasi durch das äußere Umfeld der Assets herzustellende Eigenschaften. Dagegen wird Verfügbarkeit (Availability) als eine inhärente Eigenschaft der Assets verstanden, bei Bedarf „zugänglich (accessible) und nutzbar (usable)“ zu sein.

Die EU-Datenschutzgrundverordnung (DSGVO) definiert in Artikel 32 Anforderungen an die Sicherheit: Demnach sollen technische und organisatorische Maßnahmen getroffen werden, welche die Fähigkeit mit sich bringen, „die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste im Zusammenhang mit der Verarbeitung [der personenbezogenen Daten] auf Dauer sicherzustellen“. Etwas unverhofft tritt hier also der Begriff „Belastbarkeit“ (in der engl. Fassung „Resilience“) neben die klassischen Schutzziele. Da in der DSGVO nebst Erwägungsgründen keine weiteren Erläuterungen oder Definitionen existieren, lässt sich an dieser Stelle mit Gonscherowski (et al., [3]) nur konstatieren, dass Resilience hier auf eine dauerhafte Beherrschung der Risiken für die Rechte und Freiheiten von Petenten bei der Verarbeitung ihrer personenbezogenen Daten fokussiert. Dies entspricht somit eher dem Funktionsbegriff des Systems als inhärenten oder nicht-inhärenten Eigenschaften von Assets – aus Datenschutzsicht ist Resilience somit eher nicht als eigenständiges Schutzziel anzusehen.

Weitere Ansätze

Die European Union Agency for Network and Information Security (ENISA) verbindet mit dem Begriff die Metriken „Availability“, „Reliability“, „Safety“, „Confidentiality“, „Integrity“ and „Maintainability“, womit Resilience eher als Konzept zu verstehen ist (s. a. https://resilience.enisa.europa.eu/ sowie [4,5]).

Anders sieht das etwa in der ISO 22301:2012 „Societal security – Business continuity management systems – Requirements“ aus, die eben nicht nur ein technisches Notfallmanagement, sondern ein umfassendes BCM-System definiert. Business-Continuity an sich wird darin als die Fähigkeit verstanden, Produkte und Services in akzeptablem und vordefiniertem Umfang auch noch bei „disruptiven Ereignissen“ zu erbringen. Der Bezug „societal“ macht deutlich, dass Business-Continuity als Beitrag zu einer resilienten Gemeinschaft verstanden wird, sodass auch das Umfeld der Organisation in der Planung zu berücksichtigen ist. Hier werden also in aller Deutlichkeit einerseits Maßnahmen zur Informationssicherheit unter den Fokus der Aufrechterhaltung der Geschäftsprozesse definiert und andererseits klar die Auswirkungen der Vernetzung zwischen Organisationen adressiert.

In ebenso klarer Art und Weise grenzt die NIST Special Publication (SP) 800-160 Vol. 2 „Systems Security Engineering: Cyber Resiliency Considerations for the Engineering of Trustworthy Secure Systems“ [6] die Resilience von der Security ab. Während Security konzeptionell daran orientiert ist, den Verlust von Assets zu vermeiden, geht Resilience – und im Fall der SP „Cyber-Resilience“ – darüber hinaus. Neben den Sicherheitsüberlegungen sind demnach auch Servicebeeinträchtigungen, Verhinderung und Unterbrechung von Services, Modifikationen/Korrumpierung oder Zerstörung von Ressourcen sowie nichtautorisierte Offenlegung von Informationen Gegenstand eines Cyber-Resiliency-Frameworks.

Resilience geht somit deutlich über die klassischen Ziele der Informationssicherheit hinaus: Einerseits stehen die Services beziehungsweise Geschäftsprozesse in Gänze im Vordergrund, andererseits werden ein holistischer Systembegriff sowie Qualitätsmerkmale und eine integre Betriebsweise ausgeprägt – hierin liegt deutlich mehr als die augenscheinliche Verknüpfung zwischen Resilience und Verfügbarkeit.

Integration in Managementsysteme

Mit der Definition von Resilience als konzeptionelle Ausprägung ist klar, dass eine Umsetzung und Berücksichtigung in Informationssicherheits- (ISMS) und Datenschutz-Managementsystemen (DSMS) nicht dadurch erfolgen kann, dass ein oder mehrere neue Controls/Control-Sets (oder Bausteine im Sinne des BSI-Grundschutzes) definiert werden. Vielmehr ist es erforderlich, Resilience als Qualitätsmerkmal und Sichtweise bei der Gestaltung und Umsetzung einer Vielzahl von Controls/Bausteinen in unterschiedlicher Ausprägung umzusetzen.

Zur Orientierung können hierbei sogenannte Resilience-Principles dienen, mit denen sich die besonderen Aspekte herausstellen lassen. In Anlehnung an internationale Empfehlungen werden hier die in Tabelle 1 dargestellten und definierten Kernelemente vorgestellt.

Durch den Charakter als spezifische Ausprägung fügen sich Resilienceaufgaben und -arbeiten quasi nahtlos in Managementsysteme zur Informationssicherheit und zum Datenschutz ein. Ausgehend von Sicherheits- und Risikolagen, Geschäftsanforderungen sowie gesetzlichen Anforderungen werden technische und organisatorische Vorleistungen in einer Planungsphase definiert (plan).

Im Falle eines Ereignisses steht die Aufrechterhaltung des Betriebs im Vordergrund (absorb/withstand): Das bedeutet, dass ein System in definiertem Umfang Störungen absorbieren kann (vgl. Abb. 1) und – zur Vermeidung eines betrieblichen Zusammenbruchs – vordefinierte Ausweichmaßnahmen aktiviert werden. Sollte dennoch ein Systemzusammenbruch stattfinden, legt man alle Aufmerksamkeit auf die Herstellung einer Minimal-Betriebsfähigkeit (recover).

Nach Abschluss einer Störung und Übergang in den Normalbetrieb stehen die Bewertung der Wirksamkeit sowie gegebenenfalls eine Optimierung von Maßnahmen im Sinne eines kontinuierlichen Verbesserungsprozesses an (adapt/learn).

Tabelle 1

Tabelle 1: Ausgewählte Resilience-Principles

Maßnahmen zur Resilience-Integration

Grundlage der Integration ist die organisatorische Übernahme der Verantwortung durch die Organisationsleitung. Wesentlich ist hierzu die Definition und Deklaration in der Organisationsleitlinie, dass Resilience als konzeptioneller Bestandteil in das ISMS und DSMS zu integrieren ist. Resilience-Prinzipien sind äquivalent zu Informationssicherheits- und Datenschutzzielen als Gestaltungs- und Kontrollziele in der Leitlinie festzuschreiben.

Die Basis zur Ermittlung geeigneter Maßnahmen ist eine Service-Impact-Analysis (SIA), in der nicht nur die für kritische Geschäftsprozesse evidenten Assets (als Anwendung, Kommunikations- und sonstige Netze, Komponenten, Services oder Daten) ermittelt werden, sondern unter Resilienzaspekten auch Vorgaben zu treffen sind, in welchem minimalen Maße (Quantität und Qualität) diese zur Aufrechterhaltung des Geschäftsbetriebs bereitstehen müssen. Resilienzspezifische Gefährdungen sind an der Aufrechterhaltung des Geschäftsprinzips zu orientieren und umfassen Kriterien wie die Aufrechterhaltung der Kommunikationsfähigkeit, des Datenaustauschs, der Verarbeitungsfähigkeit oder auch die Erfassung der Betriebszustände von Assets.

Eine resiliente Systemarchitektur zielt wesentlich auf eine Reduzierung von Komplexität und Abhängigkeiten. Hierunter fallen Techniken wie (Mikro-) Segmentierungen von Anwendungen, Netzen und Komponenten sowie Festlegungen zu Netzübergängen in Abhängigkeit von Funktion, Standort und Risikoprofil der Netzwerksegmente. Zielsetzung ist es, Netze und Netzwerkübergänge so zu gestalten, dass sich Einflüsse und Störungen eines Teilbereichs nicht systemübergreifend auswirken (Minimierung der Angriffsflächen / reduce attack surface).

Somit sind neben der Erstellung eines angemessenen Zonenkonzepts auch die Minimierung der Verbindungsarten, Kommunikationsmethoden und Verbindungszeiten von und zu kritischen Systemen grundlegende Resilienzaufgaben. Äquivalente Maßnahmen sind auch für Netze und Zugangs-/Zugriffs-Strukturen zur Administration zu gestalten.

Zur Gestaltung von Redundanzmaßnahmen sind diese unter Resilienzgesichtspunkten von der reinen Umschaltung zwischen (Teil-) Komponenten auf die Asset-Ebene des kritischen Geschäftsprozesses zu heben. Nur wenn alle für den Minimalbetrieb erforderlichen Komponenten auch bei einem Störereignis betriebsfähig bleiben, sind die genannten Kriterien der Gefährdungsbetrachtung vollständig berücksichtigt.

Bei den in einem Netz wirksamen Sicherheitsservices wie Datenflusssteuerung, Virenschutz und Identifizierungs-/Authentisierungsdienste ist strikt darauf zu achten, „Single Points of Security“ zu vermeiden. So zeichnet sich beispielsweise die Resilienz von Verzeichnisdiensten nicht nur dadurch aus, dass diese gegebenenfalls auf redundanten Systemen laufen, sondern auch durch eine Platzierung redundanter Systeme in unterschiedlichen Netzwerksegmenten. Nur so wird zumindest bei einem Teil-Netz-Ausfall eine Minimal-Erreichbarkeit hergestellt.

Selbstredend umfasst die Reduzierung der Angriffsflächen auch Konfigurationsmaßnahmen, welche die Preisgabe von Informationen zu Netz- und/oder Systemstatus/-typ sowie Betriebssystemversionen in Richtung unsicherer Netze auf ein Minimum reduzieren.

Überdies sind Maßnahmen zur bewussten Schaffung weiterer Hürden für Störeinflüsse zu erwägen: So ist es durchaus sinnvoll, zentrale Firewallsysteme durch komponentenspezifische (lokale) Firewalldienste zu ergänzen, sodass man im Sinne eines Defence-in-Depth-Ansatzes sowohl zeitliche Vorteile schafft als auch unterschiedliche Angriffsvektoren erfasst.

Ein zentraler Resilienzaspekt ist die kontinuierliche Erfassung aller Verarbeitungs- und Betriebszustände. Dies lässt sich im laufenden Betrieb durch ein umfangreiches Monitoring und Alarmierungssystem erreichen. Besonderes Augenmerk ist hierbei auf die Überwachung der Datenströme im Sinne der genannten Schwellenwerte zu legen, wobei besonders auf Netzübergänge zwischen unterschiedlichen Sicherheitsniveaus zu achten ist. Die Referenzdaten für alarmierungswürdige Ereignisse erfordern ein kontinuierliches Baseline-Behavior-Monitoring, das übliche Steigerungen aus dem Geschäftsbetrieb sicher berücksichtigt.

Neben laufenden Betriebszuständen werden auch an die Betriebsprozesse selbst erhöhte Anforderungen gestellt: Hier sind Maßnahmen zur Erhaltung der Integrität als vorbeugende Maßnahmen besonders wichtig. Nicht zuletzt sind vermeintlich sichere Updateprozesse gemäß dem Prinzip „Limit the Need for Trust“ insofern auf den Prüfstand zu stellen, als Updates vor Einspielen in die technischen Komponenten auf ihre Herkunft und inhaltliche Integrität geprüft werden (bspw. mittels Signaturen und Hashverfahren). Für kritische Assets ist nach Updates und Changes zu prüfen und zu dokumentieren, dass definierte Resilienzmaßnahmen (bspw. autom. Redundanzumschaltungen) weiterhin wirksam sind und im Ereignisfall greifen.

Abbildung 1

Reaktion resilienter und nicht-resilienter Systeme auf ein Störereignis (Shock) – wichtig ist, dass ein minimaler Betrieb
(Funktionserhalt) gegeben bleibt.

Vorsorge für den Falle der Fälle

In einem Störungs-/Bedrohungsereignis setzt Resilienz zunächst einmal voraus, dass noch Handlungsfreiräume gegeben sind. Dies lässt sich bei Netzzugangssystemen etwa dadurch bewerkstelligen, dass man zunächst die realen technischen Systemgrenzen in Bezug auf Kommunikationsparameter (wie max. Anzahl von Sessions, Paket-Durchsatzrate etc.) im Verhältnis zur Administrierbarkeit ermittelt. Auf Basis dieser Informationen können dann sinnvolle Schwellenwerte für eine Überwachung und Alarmierung definiert werden.

Darüber hinaus sind dynamische Reaktionen auf Störfälle zu betrachten, die im Idealfall entweder automatisiert oder durch eine – unabhängig von Störbedingungen funktionierende – manuelle Steuerung erfolgen. Dynamische Reaktionen auf Komponentenebene können etwa die automatische Zuschaltung weiterer Systemkomponenten zur Übertragung oder Verteilung der Last sein (bspw. zusätzliche Web- oder Loadbalancer-Systeme). Bei Störungen aus und über öffentliche Netze (bspw. DDoS-Attacken) kann die Reaktion auf Systemebene aber auch in der Übertragung/Umleitung von Internetverbindungen auf eine externe Clearingstelle liegen. Dies gewährleistet auch, dass die Kapazität der eigenen Verbindungen im Wesentlichen auf die eigenen betrieblichen Anforderungen (inkl. Wachstumszuschlägen) ausgerichtet bleiben kann. Die Steuerungsfähigkeit als Bestandteil des Berechtigungskonzepts ist selbstredend ebenfalls ausreichend zu berücksichtigen. Als Mindestmaßnahmen sind physische Zugangsmöglichkeiten auf wichtige Systeme und die Fähigkeit zur Authentifizierung sicherzustellen.

Die dargelegten Resilienzmaßnahmen zur Handlungsfähigkeit haben überdies auch einen Einfluss auf Investitions- und gegebenenfalls auch strategische Aspekte: So sind im Kapazitätsmanagement Entscheidungen zu Erweiterungen/Erneuerungen daran auszurichten, dass nicht die technischen Systemgrenzen relevant sind, sondern die zur Sicherstellung der Handlungsfähigkeit definierten Schwellenwerte.

Abläufe und Maßnahmen, die im Falle eines Resilience-Ereignisses anzuwenden sind, sowie Verantwortliche, die gemäß Alarmierungsketten zu kontaktieren sind, gilt es in Form von Incident-Response-Plänen zu erfassen und in regelmäßigen Tests zu verifizieren. Diese Pläne sind mindestens für die wahrscheinlichsten Szenarien gemäß SIA zu erstellen. Bestandteil davon sind allem voran Festlegungen zu Kommunikations- und Maßnahmenschnittstellen mit externen Organisationen, die als Kunde, Lieferant oder Auftragsverarbeiter am Geschäftsprozess beteiligt sind. Darüber hinaus sind auch Kontakte zu Ermittlungs- und Strafverfolgungsbehörden sowie gegebenenfalls externe Unterstützer wie Computer-Emergency-Response-Teams (CERTs) zu ermitteln und regelmäßig zu aktualisieren.

Fazit

Neben den klassischen Sicherheitszielen gehören zunehmend auch Qualitäts- und Systemfaktoren wie die Resilienz zu den Aspekten von Informations- und Datenschutz-Managementsystemen. Als übergreifende und konzeptionelle Aspekte werden hiermit Qualitäts- und Dynamikthemen im Systembetrieb vorangetrieben. Zudem wandert der Fokus weg von einzelnen Anwendungen hin zu einem ganzheitlichen Systembetrieb – bis hin zu einer organisationsübergreifenden Sichtweise.

Durch die aus der Praxis getriebene Notwendigkeit der Resilienzausprägung von Maßnahmen ergibt sich für Verantwortliche auch die Notwendigkeit, sich mit Aus- und Fortbildungen unter dem Stichwort „Security Engineering“ zu beschäftigen. Schließlich gilt es, die neuen Anforderungen auch mithilfe nationaler und internationaler Standards so zu verankern, dass man mit Zertifizierungen entsprechende Nachweise erbringen kann.

M. Sc. Bernhard Barz ist Informationssicherheitsbeauftragter der regio iT, Aachen. Daniel Effenberg war bis Februar 2019 stellv. Informationssicherheitsbeauftragter der regio iT und ist seither für die Amadeus Leisure IT GmbH, Würselen tätig.

Literatur

[1] Günter Ropohl, Allgemeine Systemtheorie: Einführung in transdisziplinäres Denken, edition sigma, September 2012, ISBN 978-3-8360-3586-6
[2] Günter Ropohl, Allgemeine Technologie, Eine Systemtheorie der Technik, universitätsverlag karlsruhe, ISBN 978-3-86644-374-7, online frei verfügbar über https://publikationen.bibliothek.kit.edu/1000011529
[3] Susan Gonscherowski, Marit Hansen, Martin Rost, Resilienz – eine neue Anforderung aus der Datenschutz-Grundverordnung, Datenschutz und Datensicherheit (DuD), Vol. 42/7, Juli 2018, S. 44, https://doi.org/10.1007/s11623-018-0976-3
[4] European Union Agency for Network and Information Security (ENISA), Resilience Metrics and Measurements, Studienergebnisse, 2010/2011, www.enisa.europa.eu/topics/critical-information-infrastructures-and-services/internet-infrastructure/metrics
[5] European Union Agency for Network and Information Security (ENISA), Enabling and managing end-to-end resilience, Januar 2011, www.enisa.europa.eu/publications/end-to-end-resilience
[6] NIST Computer Security Resource Center (CSRC), Systems Security Engineering: Cyber Resiliency Considerations for the Engineering of Trustworthy Secure Systems, NIST SP 800-160 Vol. 2 (Draft), März 2018, https://csrc.nist.gov/publications/detail/sp/800-160/vol-2/draft
[7] Klaus Thoma (Hrsg.), Resilien-Tech – „Resilience-byDesign“: Strategie für die technologischen Zukunftsthemen, acatech Studie, Mai 2014, www.acatech.de/Publikation/resilien-tech-resilience-by-design-strategie-fuer-dietechnologischen-zukunftsthemen-2/

Diesen Beitrag teilen: