Zu viel des Guten ist auch schlecht | Fachartikel zur Schutzbedarfsanalyse beim Assetmanagement

Voit, Stefan | 02.05.2023
OMNINET Newsbeitrag Schutzbedarfsanalyse 770x395

Treffsichere Schutzbedarfsanalyse beim Assetmanagement vermeidet Überschutz

Schutzbedarfsanalysen sind für einen effizienten Schutz aller Unternehmenswerte wesentlich – dabei gibt es naturgemäß starke Überschneidungen mit dem Assetmanagement. Unsere Autoren zeigen, wie Organisationen Assets sinnvoll clustern und auf ihren Schutzbedarf hin bewerten können, welche Vorteile das mit sich bringt und welche Anforderungen eine hierbei eingesetzte Softwarelösung erfüllen sollte, um sowohl zu geringe als auch zu hohe Schutzbedarfszuweisungen an Assets zu vermeiden.

Ziel einer Schutzbedarfsanalyse ist es, allen Unternehmenswerten, die sich in Informationen spiegeln, einen Bedarf an Schutzmaßnahmen zuzuweisen, sodass sie mit optimalen Ressourceneinsatz geschützt werden. Dazu sollte man Unternehmenswerte (Assets) im Assetmanagement in Klassen zusammenfassen (clustern), um darauf aufbauend Methoden einzusetzen, mithilfe derer sich einzelne Assets und deren tatsächlich notwendiger Schutz individuell bewerten und ermitteln lassen. Aufgrund der besonderen Relevanz für den Schutz einer Organisation (bis hin zur Existenzabsicherung) wird ein funktionierendes Assetverzeichnis beispielsweise in der ISO 27001, im VDA ISA und im BSI-Standard 200-2 gefordert.

Schutzbedarfsanalysen sind Bestandteil zahlreicher Managementsysteme, die sich mit der Informationssicherheit einer Organisation beschäftige, und etwa bei einer Zertifizierung nach ISO 27001 verpflichtend vorzunehmen. Um informationsbasierte Unternehmenswerte zu schützen, müssen diese naturgemäß erst einmal erkannt und hinsichtlich ihrer Kritikalität eingeordnet werden.

Anschließend modelliert man, in welchen (IT-)Systemen, an welchen Orten oder in welcher Form Assets zu finden sind, und beschreibt ihren Schutzbedarf hinsichtlich einschlägiger Schutzziele – mindestens Vertraulichkeit, Integrität und Verfügbarkeit. Da jeder Schutz mit Kosten verbunden ist, müssen Organisationen die Waage halten zwischen ausreichend hohem Schutz und möglichst niedrigem Ressourceneinsatz – ein übertriebener Schutz von Assets (Überschutz) ist zu vermeiden.

Im Zuge der Asset-Erhebung könnte man beispielsweise bei dem Prozessverantwortlichen abfragen, welche Auswirkungen es hätte, wenn eine Information in die falschen Hände gelangen würde (Vertraulichkeit), wenn Daten einer automatisierten Steuerung verfälscht werden (Integrität) oder aber ein System ausfällt (Verfügbarkeit). Aus der Abfrage solcher potenziellen Schadensfälle lässt sich dann der Schutzbedarf ableiten und man kann entsprechende Maßnahmen zur Absicherung festlegen.

Vollständige Erfassung

Unter Assets fallen Unternehmenswerte wie Informationen, Know-how und Prozesse sowie zusätzlich sämtliche Soft- und Hardwareelemente, die zu deren Verarbeitung oder Schutz beitragen. Wird ergänzend der Geltungsbereich (Organisation, Infrastruktur, IT-Systeme, Anwendungen, Personal) definiert, lässt sich die Vollständigkeit des Assetverzeichnisses abschätzen und prüfen.

Für die Existenz eines Unternehmens besonders kritische Assets sollte die Geschäftsleitung in aller Regel schnell identifizieren können. Danach bietet es sich an, die jeweiligen Verantwortlichen jeder Abteilung zu bitten, ihre Informationswerte zu ergänzen. Diejenigen Organisationen, die bereits im Zuge einer Zertifizierung nach ISO 9001 ein Qualitätsmanagement mit Turtle-Diagramm eingeführt haben, können hier auf die bestehenden Prozessbeschreibungen zurückgreifen – vorausgesetzt natürlich, dass das Qualitätsmanagement auch in der Praxis gelebt wird und nicht nur als Scheinfassade für ein Zertifizierungsaudit herhalten musste. Beim Übertragen von Assets anhand der Prozessbeschreibungen lassen sich in der Regel Schnittstellen und somit erste Effizienzpotenziale erkennen, wenn dasselbe Asset prozessübergreifende Relevanz hat.

Abgrenzung Assets zu Configuration-Items

Assets der Prozesse sowie der Informationswerte bezeichnet man als Primary Assets – Secondary Assets sind all diejenigen, die unterstützend wirken. Letztere lassen sich noch in weitere Ebenen untergliedern, wenn ein Secondary Asset ein anderes unterstützt.

Es ist allerdings auch möglich, dass Primary Assets (z. B. Informationen) anderen Primary Assets (z. B. Prozessen) untergeordnet sind.

Bei den Secondary Assets besteht die Kunst darin, bei möglichst hoher Vollständigkeit ihre Anzahl und damit die Komplexität sinnvoll zu begrenzen. Oft findet man den Vorschlag, eine Configuration-Management-Database (CMDB) aus dem IT-Service-Management zu übernehmen. Die wäre zwar schnell zur Hand, hat aber eine zu hohe Detailauflösung, die das Assetmanagement unnötig erschwert. Zudem sind nicht alle Secondary Assets darin enthalten, da auch andere Arten von unterstützenden Werten existieren, welche die IT in der Regel dort nicht führt – etwa Tresore, Gebäude oder Vereinzelungsanlagen. Kurz: Asset ist nicht Configuration-Item (CI). Ein ergänzender Blick in eine vorhandene CMDB schadet dennoch nicht, um eventuelle Abhängigkeiten innerhalb der eigenen IT-Struktur zu erkennen beziehungsweise zu bewerten. Um handlungsorientierte Daten zu liefern, lohnt es sich, die Configuration-Items den Assets zuzuordnen.

Aufbau von Assetklassen

Relevant für die Erstellung einer Assetklasse sind der ihr zugeordnete Schutzbedarf sowie eine gleichartige Umsetzung der Schutzmaßnahmen: Alle Assets mit gleichem oder sehr ähnlichem Schutzbedarf fallen dann in eine Klasse und werden so geclustert. Immer wenn es zu Abweichungen im Schutzbedarf der einzusortierenden Assets oder in der Art der Sicherheitsanforderungen und umzusetzenden Maßnahmen kommt, spaltet man eine Assetgruppe auf.

Beispielsweise könnte man bei Endgeräten danach unterscheiden, ob es sich um ein Notebook oder eine Workstation handelt, da eine Festplattenverschlüsselung etwa nur bei Notebooks für notwendig gehalten wird. Bei Workstations kann eine weitere Granulierung erfolgen, je nachdem, ob es sich etwa um eine Rückmeldestation oder einen Trainingsrechner handelt, wodurch es womöglich Unterschiede bei der Authentifizierungsmethode geben könnte. Hier sei erneut auf mögliche Überlappungen zwischen Assets und CMDB hingewiesen.

Vererbung

Schaubild Vererbung des Schutzbedarfs vom Secundary Asset zum Primary Asset

Abbildung 1: Vererbung von Schutzbedarfen nach dem Maximalprinzip

Als Ergebnis der Sammlung von Assets entsteht eine Netz- oder Baumstruktur, die eine Unterordnung der unterstützenden Assets zu den unterstützten Assets beschreibt und sich nun für die Zuordnung der Schutzbedarfe nutzen lässt.

Eine mögliche Methode ist die Vererbung des Schutzbedarfs (zum Beispiel beim BSI-Standard 200-2, Kap. 8.2.2). Hierbei wird das Maximum des Schutzbedarfs aller in den Secondary Assets enthaltenen Informationswerte als Schutzbedarf des Primary Assets angesehen (siehe Abb. 1). Die Idee dahinter ist, dass sich der Schutzbedarf einer Information natürlich auch auf die Systeme überträgt, in denen diese beispielsweise verarbeitet wird – und von dort aus wiederum auf weitere unterstützende Systeme, welche diese etwa speichern. Diese Vererbung erfolgt je nach eingesetzter Anwendung auch automatisiert.

Dieses Vorgehen übersieht aber, dass dieser Ansatz einige „Weichmacher“ enthält (vergleiche BSI-Standard 200-2, IT-Grundschutz-Methodik, Version 1.0, Kapitel 8.2.2):

  • Abhängigkeiten: Ist eine Anwendung auf die Ergebnisse einer anderen Anwendung angewiesen, überträgt sich ihr Schutzbedarf auf diese liefernde Anwendung – das wird bei einer vertikalen Vererbung nicht berücksichtigt.
  • Kumulationseffekt: Unterstützt ein Asset viele andere (z. B. Server mit vielen abhängigen Systemen), kann sein individueller Schutzbedarf höher sein als der Schutzbedarf der unterstützten Assets.

Für die Praxis bedeutet das, dass eine individuelle Bewertung jedes Assets notwendig wird. Denn eine Vererbung nach dem Maximalprinzip tendiert dazu, dass sich der höchste Schutzbedarf eines Assets nach unten durchvererbt, wodurch tieferliegende Ebenen unter Umständen zu sehr geschützt werden. Dieser Effekt verstärkt sich umso mehr, je mehr Ebenen die Struktur der Secondary Assets umfasst.

Andererseits existieren auch Faktoren, welche die Kritikalität wieder senken, wie zwei Beispiele veranschaulichen mögen:

  • Verteilungseffekt: Wenn eine Anwendung auf mehrere Systeme verteilt ist, kann der Schutzbedarf der unterstützenden Werte geringer sein. Wird etwa ein Cluster für hochverfügbare Informationen eingesetzt, da diese auch beim Ausfall eines Knotens noch zugreifbar sein sollen, dann müssen die Knoten selbst (z. B. Speichersysteme) nicht mehr hochverfügbar sein. Der Schutzbedarf ist aufgrund des Verteilungseffekts also geringer.
  • Verschlüsselung: Chiffriert etwa ein E-Mail-Programm versendete Nachrichten, können auch über ungesicherte Leitungen streng vertrauliche Informationen sicher übertragen werden.

Ergänzende Faktoren

Zusätzlich zu den bisher beschriebenen Mechanismen ist daher eine Ergänzung um die Bewertung des Angebots, des Bedarfs sowie der Anforderung eines Assets zielführend (vgl. Abb. 2):

  • Das Angebot gibt den Schutzbedarf an, für den ein Asset gedacht und im besten Fall auch mit Maßnahmen abgesichert ist. Es ist sozusagen der Ist-Zustand des Assets, den der jeweilige für das Asset Verantwortliche vorgesehen hat und kennt.
  • Der Bedarf ist hingegen derjenige Schutzbedarf den ein Asset von seinen Unterstützern fordert. Gibt es also eine Verringerung des Schutzbedarfs durch Maßnahmen, wie zum Beispiel Redundanz oder Verschlüsselung, wird hier ein geringerer Wert an die darunterliegenden Assets weitergegeben. Die Frage nach solchen Mechanismen, die den Schutzbedarf verringern, lässt sich in der Regel schnell beantworten.
  • Die Anforderung ist das Maximum aller Bedarfe von unterstützten Assets, also der darüberliegenden Ebene. Dies ist üblicherweise der vorgegebene Schutzbedarf.
Schaubild individuelle Assetbewertung anhand von Angebot, Bedarf und Anforderung

Abbildung 2: Ergänzende Faktoren zur zielführenden Schutzbedarfsermittlung voneinander abhängiger Assets

Diese Aufspaltung der Schutzbedarfe hat diverse Auswirkungen. Um dies zu verdeutlichen, betrachten man gedanklich ein kritisches Asset, das von einem normalen Asset unterstützt wird. Die Weitergabe eines kritischen Bedarfs hat dann die folgenden Konsequenzen:

  • Das automatische Durchvererben über die Ebenen findet nicht mehr statt, da sich zunächst nur die Anforderung auf der nächsten Ebene ändert, nicht jedoch automatisch der Bedarf.
  • Beim unterstützenden Asset zeigt sich eine Schieflage zwischen der Anforderung und dem Angebot – das lässt sich über einen Trigger an die für das Asset verantwortliche Person melden. Dadurch wird eine Kommunikation zwischen den Verantwortlichen des übergeordneten und des unterstützenden Assets gefördert.

Austausch auch zwischen Asset-Verantwortlichen

Diese Kommunikation könnte bewirken, dass Prozesse angepasst oder andere Assets hinzugezogen werden. Dies kann sinnvoll sein, wenn es sich um nur einmalige Anforderungen handelt oder sich dadurch Kosten sparen lassen. Denkbar wäre beispielsweise ein Szenario, in dem man streng vertrauliche Informationen, die üblicherweise via E-Mail versendet werden, zukünftig über eine sichere Austauschplattform übermitteln, anstatt das E-Mail-System nachzurüsten. Möglich wäre auch, dass der Verantwortliche des „Kostentreibers“ Maßnahmen ergreift, um den Bedarf zu senken, wenn dies in Summe günstiger ist – zum Beispiel indem streng vertrauliche Informationen des übergeordneten Assets schon dort sicher verschlüsselt werden und sich so der Schutzbedarf der unterstützenden Assets verringert.

Das Angebot des unterstützenden Assets kann natürlich auch durch weitere Sicherheitsmaßnahmen so angepasst werden, dass es die neuen Anforderungen erfüllt. Alles in allem wird hier deutlich, dass sich mit einer Einzelfallentscheidung die simple Vererbung eines (teuren) Schutzbedarfs durchbrechen lässt. Dieses Verfahren hat sich in der Praxis etwa bei der Implementierung für eine Erstzertifizierung nach ISO 27001 als sinnvoll erwiesen, gerade weil die Richtlinien so gestaltet sind, dass sie für verschiedene Schutzbedarfe gestaffelte Sicherheitsmaßnahmen vorschreiben.

Nutzen für ISB/CISO und IT

In puncto Schutzbedarf sind Abweichungen in beide Richtungen – also Überschutz und zu niedriger Schutz – mit Kosten und Risiken verbunden: Denn zu hohe Sicherheitsmaßnahmen werden im Arbeitsalltag leicht ignoriert. Ein solches Verhalten geht auch zulasten von Schutzmaßnahmen für wirklich wichtige Informationswerte. Über die grundsätzlich weiter verwendete Vererbung wird immer noch ein Maximum aller Bedarfe ermittelt, um die Anforderungen an ein Asset zu beurteilen – es findet jedoch keine vollständig automatisierte und unkontrollierte Durchvererbung durch alle Ebenen mehr statt. Das führt dazu, dass man das Problem zuerst dort zu lösen versucht, wo es entsteht. Mithilfe dieses Vorgehens lassen sich Kostenvorteile entdecken, indem Kostentreiber von Schutzmaßnahmen oder zu schwache Schutzmechanismen gezielt erkannt werden.

Die getroffenen Sicherheitsmaßnahmen für das Angebot eines Assets lassen sich gegen die notwendigen Maßnahmen aus den Richtlinien prüfen. Weichen Anforderung und Bedarf voneinander ab, müssen (IT-)Sicherheitsmaßnahmen hinterlegt sein, die sich prüfen lassen – ein unkontrolliertes Abweichen sollte man ausnahmslos unterbinden.

Nicht zuletzt profitieren auch die Verantwortlichen der Secondary Assets vom Assetmanagement und diesem Vorgehen: Sie erfahren, in welchen Prozessen ihre Technik verwendet wird und wer die Anforderungen in die Höhe treibt. Veränderungen werden nicht mehr automatisiert und teils unbemerkt weitergegeben, sodass sie in Kommunikation mit den Nutzern ihrer Infrastruktur treten können, um mitzuentscheiden. Gerade in großen Organisationen kann es für IT-Abteilungen schwierig sein, die Relevanz ihrer Systeme einzuschätzen – genau diese Transparenz schafft das beschriebene Assetmanagement.

Softwaregestützte Umsetzung

In der Praxis braucht es ein System, in das sich Informationen zu Assets übersichtlich eintragen und pflegen lassen. Grundsätzlich lässt sich ein Assetinventar auch mit einer Tabellenkalkulation umsetzen, wobei es allerdings einige Beschränkungen gegenüber guten spezialisierten Lösungen gibt, welche Tabelle 1 exemplarisch aufführt – umgekehrt lassen sich daraus sinnvolle Anforderungen an eine speziell für die Bewertung von Assets entwickelte Software entnehmen.

Die Tabelle ist zwar nicht vollständig, jedoch lässt sich schnell erkennen, dass ab einer gewissen Komplexität und Größe der Assetlandschaft eine eigens dafür entwickelte Softwarelösung rentabel sein dürfte, um alle essenziellen Anforderungen abzubilden. Bei diesem (Asset-)Managementsystem sollten sich Assetklassen flexibel definieren lassen. Außerdem ist es ratsam, die Lösung so weit wie möglich in die bestehende IT-Infrastruktur und Prozesslandschaft zu integrieren, sodass zentralisierte Zugriffe auf Informationen, Prozesse und Daten möglich sind. Letztlich reduziert erst das den manuellen Pflegeaufwand und steigert die Zuverlässigkeit der Schutzbedarfsanalysen aufgrund der höheren Transparenz.

Tabellenkalkulation Assetmanagement-Software
Begrenzte Skalierbarkeit Nachhaltige Lösung auch bei wachsenden Unternehmensstrukturen
Assetklassen müssen separat gepflegt werden – Änderungen führen nicht zu automatischen Anpassungen der enthaltenen Assets. Querverbindungen zwischen Assetklassen und den jeweils zugeordneten Assets bewirken einen geringeren Pflegeaufwand.
Datensicherheit und Dokumentation von Änderungen sind nur bedingt möglich. Zugriffsrechte sollten über zugewiesene Rollen implementiert sein, eine Dokumentation über Historieneinträge erfolgen.
Starke Limitierung bei „Wenn-dann“-Regeln Sollte beliebige Anpassungen von Regelfestlegungen und Automatismen unterstützen
Feinjustierung nach Angebot, Bedarf und Anforderung ist mühsam, da ein Panoramablick über die Assetlandschaft als Ganzes fehlt. Relevante Informationen sowie Querverbindungen zu anderen Assets sollten übersichtlich erkennbar sein, sodass fundierte Entscheidungen über Angebot, Bedarf und Anforderung möglich werden.
Anlegen, Pflegen und (Neu-)Bewerten von Assets bedeutet manuellen Aufwand. Zuordnung eines Assets in eine Klasse sollte automatisch zur Vergabe der für diese Klasse festgesetzten Schutzziele führen.
Eine Kommunikation zwischen den für die Assets Verantwortlichen ist nicht ohne Weiteres möglich. Es sollte eine Übersicht über alle Beteiligten mit automatisiert getriggerten Benachrichtigungen geben.
Die Weiterbearbeitung von Informationen, die sich auf Risikobewertungen beziehen, erfordert meist einen Toolwechsel. Abgeleitete Risiken sollten sich im integrierten Risikomanagement weiter bearbeiten lassen.
Liefert meist nur Abbildung des Ist-Zustands, wodurch Rückschlüsse erschwert werden, wie es zu einzelnen Bewertungen kam – das erschwert regelmäßige Neubewertungen innerhalb des Asset-Lebenszyklus. Prozessübergreifende Abhängigkeiten von Assets sollten leicht erkennbar sein, um Ergänzungen und Änderungen während des Asset-Lebenszyklus nachvollziehbar zu machen.
Wartungs- und pflegeintensiv – tendenziell fehleranfällige Insellösung, die losgelöst von sonstigen Geschäftsprozessen ist Sollte als Plattformarchitektur ein prozessumspannendes Ökosystem ermöglichen, um Synergieeffekte durch zentralisierte Datenbanken und die Nutzung bereits vorhandener Prozess- und IT-Infrastruktur zu erzielen.

Tabelle 1: Der Vergleich zwischen Tabellenkalkulation und Assetmanagement-Software offenbart sinnvolle Funktionen/Anforderungen spezialisierter Lösungen.

Sollte dann wirklich eine Gefahr oder ein Schaden eintreten beziehungsweise sollten sich Risikobewertungen ändern, kann man schneller und besser prüfen, ob es Querverbindungen oder Abhängigkeiten zu anderen Assets gibt, die ebenfalls betroffen sein könnten. Auch Entscheidungen über Angebot, Bedarf und Anforderung lassen sich aufgrund von strukturiert zur Verfügung stehenden Informationen und einer besseren Transparenz der Prozessstrukturen passgenau treffen. Insellösungen sind hier nicht zielführend. In Summe braucht es eine integrierte Assetmanagement-Lösung, die auf eine Geschäftsprozessplattform aufsetzt – nur so sind zuverlässige Schutzbedarfsanalysen möglich, aus denen heraus sich Risiken und Maßnahmen koordinieren lassen. Ein integrierbares Risikomanagement ist ebenfalls sehr zu empfehlen.

Abschließend sei noch einmal erwähnt: Ein Assetmanagement dient nicht dem Zertifizierungsaudit, sondern ist Grundlage für den Schutz von existenzkritischen Informationswerten eines Unternehmens. Organisationen sollten dies bei der Entscheidung für ein (integriertes) Assetmanagement-System beachten.


Dipl. Ing. Andreas Chlebnicek war lange Zeit im Automotive- sowie PKI-Umfeld als Software-Entwickler tätig, bevor er in die Beratung wechselte – seit 2021 ist er Head of Governance, Risk and Compliance (GRC) Management bei OMNINET.

Dr. Kaufmann (author of this article)Dr. Thomas Kaufmann war viele Jahre CISO und Datenschutzbeauftragter eines börsengehandelten Automobilzulieferers und ist heute selbstständiger Berater und Geschäftsführer der DatenSchutzBeratung Dr. Kaufmann GmbH.


Dieser Beitrag erschien zuerst in <kes> – die Zeitschrift für Informations-Sicherheit, Ausgabe 2022 #6, S. 27ff.