Unternehmen der Finanzbranche stehen hinsichtlich ihrer Daten unter besonderer Beobachtung: Regelmäßig prüft die interne Revision und die BaFin die IT-Sicherheit von Kreditinstituten und Versicherungen. Um negativen Ergebnissen zuvorzukommen, sind Self-Audits ein bewährtes Mittel: Stoßen die Unternehmen bei der Selbstprüfung auf Risiken, helfen wir dabei, diese zu managen.

Ein langjähriger Kunde von uns bietet IT-Dienstleistungen im Versicherungsumfeld an. Im Rahmen eines Self-Audits überprüfte dieses Unternehmen unter Nutzung eines extern bereitgestellten Fragenkatalogs die Sicherheit seiner IBM Db2-Datenbanksysteme. Dabei wurden Feststellungen gemacht, die teilweise mit einem hohen Risiko bewertet wurden. Es musste also ein Sicherheitskonzept erstellt werden, das die Anforderungen an die Informationssicherheit für Db2-Datenbanksysteme erfüllt, und die identifizierten Feststellungen beseitigt.

In diesem Fall ist aber zunächst Expertise der Berater*innen als „Übersetzer“ gefragt. Aus den abstrakten, allgemein gehaltenen internen Sicherheitsvorgaben und den Ergebnissen aus dem Audit muss ein Anforderungskatalog erstellt werden, den die Datenbankadministratoren auch verstehen. Der Katalog enthält daher verständliche datenbankspezifische Umsetzungsvorgaben. Ziel ist es, nicht nur die aktuellen Feststellungen zu beseitigen. Es geht auch darum, eine Lösung bereitzustellen, die ein angemessenes Sicherheitsniveau der Db2-Datenbanksysteme nachhaltig sicherstellt.

Vom Schutzbedarf zum Soll

IT-Security ist für den Kunden bis dahin kein priorisiertes Thema im Datenbankbetrieb, und den Datenbankadministratoren fehlt es am notwendigen Know-how. Die Aufgabe von IT-Beratungen: Erklären, was zu tun ist und warum. Es wird ein Anforderungskatalog erstellt und damit abhängig vom Schutzbedarf die Soll-Anforderungen an ein Datenbanksystem festgelegt. Welche konkreten Anforderungen für das jeweilige Datenbanksystem gelten, hängt von der jeweiligen Schutzbedarfskategorie (SBK) der Daten ab, die reichen von SBK1 „niedrig“ bis zu SBK4 „sehr hoch“. Die konkrete Kategorie leitet sich dann nach dem Vererbungsprinzip aus der Schutzbedarfskategorie der Anwendungen ab, die die Datenbank nutzen. Das Sicherheitskonzept berücksichtigt daher alle Anforderungen aus dem Anforderungskatalog bis hin zur jeweiligen SBK. Eine Datenbank mit SBK2 muss zum Beispiel die Anforderungen der Kategorien SBK1 und SBK2 erfüllen.

Der Katalog sollte so gestaltet sein, dass die Anforderungen nicht nur auf den auditierten Datenbanktyp passen, sondern auch auf andere Systeme wie Oracle oder Microsoft SQL Server angewendet werden können. Die Anforderungen decken die gesamte Bandbreite sicherheitsrelevanter Themen ab, darunter zum Beispiel Berechtigungen, Protokollierung, Datensicherungen oder Patch- und Schwachstellenmanagement. Um konkrete Umsetzungsvorgaben herzuleiten, haben die Spezialisten zum einen die internen Sicherheitsvorgaben und die Audit-Feststellungen des Auftraggebers berücksichtigt. Zum anderen haben sie Best-Practice-Beispiele aus dem Security- und Db2-Umfeld herangezogen: besonders CIS Benchmarks, den BSI IT-Grundschutz und die vom Hersteller bereitgestellten Db2 Security Guides. Auf Basis des Anforderungskatalogs konnten wir nun die entsprechenden Sicherheitskonzepte für die Datenbanken erstellen Der Soll-Zustand war damit klar.

Es geht auch darum, dazuzulernen und die Sicherheit bedarfsgerecht weiterzuentwickeln.

Vom Soll zum Ist

Als nächster Schritt folgt ein Soll-Ist-Vergleich: Mittels einer sogenannten Gap-Analyse werden die Abweichungen des Ist-Zustands vom geforderten ermittelt. Dazu werden die Datenbanken erneut überprüft, nur dieses Mal unter Berücksichtigung der bereits bekannten Self-Audit-Feststellungen und gegen die neu erstellten und mit der Informationssicherheit abgestimmten Sicherheitskonzepte. Für die festgestellten Abweichungen werden entsprechende Maßnahmen definiert und in einen Plan zur Nachverfolgung überführt. Darin sind zum Beispiel die Erstellung und Umsetzung von Berechtigungskonzepten, Härtungskonzepten oder die angemessene Verschlüsselung von hochsensiblen Daten aufgeführt. Dabei wird auch die Wirtschaftlichkeit von Sicherheitsmaßnahmen berücksichtigt. Je höher der Schutzbedarf, desto aufwendiger und kostspieliger sind in der Regel die umzusetzenden Maßnahmen.

Schließlich wird der Plan gemeinsam mit dem Kunden bewertet, um zu entscheiden, welche Maßnahmen mit welcher Priorität umgesetzt werden und welches Risiko akzeptabel ist, weil zum Beispiel der Aufwand für eine Behebung in keinem wirtschaftlichen Verhältnis zum Risiko stünde.

Wieder von vorne

In der letzten Phase geht es schließlich darum, die abgestimmten Maßnahmen umzusetzen. Doch damit ist die Aufgabe keineswegs abgeschlossen: Wir haben mit unserer Arbeit lediglich den Startschuss gegeben. Denn Sicherheit ist ein sich ständig wiederholender Prozess. Deshalb werden unter anderem Automatisierungen über Skripte implementiert, um künftige Aufwände zu reduzieren, zum Beispiel für regelmäßige Soll-Ist-Vergleiche der Berechtigungen oder der gehärteten Standard-Konfiguration des Datenbanksystems. Dank des Sicherheitskonzepts und dieser regelmäßigen Gap-Analyse kann der Kunde das Sicherheitsniveau der Datenbanksysteme jederzeit überprüfen, nachbessern und insbesondere nachweisen. Es geht auch darum, dazuzulernen und die Sicherheit bedarfsgerecht weiterzuentwickeln. Plan, do, check, act – und dann wieder von vorne.