Database Activity Monitoring zum Schutz vor Datenmissbrauch

Beim Database Activity Monitoring handelt ist sich um die Aufzeichnung und Analyse von Ereignissen oder Statistiken auf den Datenbanksystemen, um Informationen über die Systemnutzung und Performance in einer sauberen und verständlichen Form darzustellen. Das Ziel eines Database Activity Monitoring Systems ist die Erkennung von Sicherheits- oder Complianceverletzungen sowie die Formulierung von Empfehlungen zur Verbesserung der Administration, der Security und der Umsetzung von Complianceanforderungen

Database Activity Monitoring ist ein generelles Verfahren, um eine unabhängige Prüfung und Auswertung von verarbeiteten Daten und Aktivitäten zu ermöglichen. Dieses Verfahren wurde entwickelt, um nachfolgende Funktionen zur Verfügung zu stellen:

    • Sicherstellung der Erfüllung von Complianceanforderung über etablierte Security Policies und Betriebsverfahren
    • Aufspüren von bekannten und unbekannten Sicherheitslücken und Formulierung von Empfehlungen zur Verbesserung der Administration, der Security und der Umsetzung von Complianceanforderungen über etablierte Security Policies und Betriebsverfahren
    • Erkennung und Verhinderung von Abweichungen vom Normverhalten speziell der technischen und hoch privilegierten Accounts
    • Klärung der Frage nach dem tatsächlichen Verursacher von Datenbankaktionen

Somit zielt das Database Activity Monitoring auf grundlegende Fragen des Datenzugriffs mit dem Zweck der Identifikation Wer Wann Welche Daten geändert hat inkl. des originalen Datenkontextes. Z.B. “Wer hat auf eine Kreditkartennummer zugegriffen?“; “Wann hat jemand eine Kundenadresse geändert?”; “Wie war der Inhalt eines Datensatzes vor der Änderung?”; und “Welche Applikation ist für den Zugriffe auf sensitive Daten genutzt worden?” In der Vergangenheit lag der Focus des Database Activity Monitoring primär auf der Korrektheit von Finanzdaten und war ausgerichtet auf Anforderungen, die von externen Auditoren definiert worden sind. Inzwischen wurde das Database Activity Monitoring auf alle Typen von Daten einschließlich kritischer Personen- und Unternehmensdaten wie z.B. Kreditkarten- und Sozialverischerungsnummern, Finanz und Gesundheitsdaten sowie Corporate Financials ausgedehnt. Mit der zuneh-menden Anforderung zur Absicherung von persönlichen Daten und beschränktem Zugriff auf kritische Daten in Datenbanken, wurde das Database Activity Monitoring ausgeweitet auf privilegierte Nutzer wie Datenbankadministratoren (DBAs) und IT Professionals.

Mit der Verschiebung des Fokus des Database Activity Monitoring auf tiefere Analysen des Datenzugriffs, werden auch höhere Anforderungen hinsichtlich Performance, Skalierbarkeit und Reporting, Rollenteilung innerhalb des Systems sowie Zentralisierung der Administration über mehrere hundert oder tausend Datenbanken hinweg an die Database Activity Monitoring Systeme gestellt.

War Database Activity Monitoring bisher meist ein manueller Prozeß, der durch die Sammlung von Audit Daten des IT Security- und Auditpersonals geprägt war, dass zur Filterung und Klassifizierung von großen Logdatenmengen eigene Skripte und andere Methoden einsetzte, ist Database Activity Monitoring heute nicht mehr ein reines reaktives Prüfen Logdaten, sondern ist in der Lage Risiken und Bedrohungen der Vertraulichkeit und Integrität von Unternehmensdaten zu verringern.

Weil Hacker kontinuierlich neue Methoden entwicklen, um sich unautorisierten Zugriff auf sensitive Daten zu verschaffen, sind Unternehmen gezwungen neueste Sicherheitstechnologien und Real-time Protection zum Schutz ihrer Daten einzusetzen. Das bedeutet, dass seit Hacker nur wenige Sekungen benötigen, um sensitive Daten von einer Datenbank zu kopieren, ist es nicht mehr menschenmöglich solche Angriffe zum Zeitpunkt wenn sie stattfinden aufzuspüren. Daher ist heute Real-time Database Protection zu einer kritischen Anforderung geworden und wird zunehmend im Rahmen von Database Activity Monitoring Aktivitäten berücksichtigt.

Traditionell sind Network Intrusion Detection Systems (NIDS) darauf ausgelegt Angriffe auf das Netzwerk zu erkennen. IDS Systeme basieren auf der Identifikation von bekannten Angriffsmustern und Verhaltensanomalien. Die in jüngerer Zeit entwickelten Datenbank IDS/Third Party Database Activity Monitoring Systeme sind darauf ausgelegt worden, Datenbanken zu monitoren und abzusichern. Um heute auch kritische Personen- und Unternehmensdaten zu sichern ist eine Kombination aus Network IDS System und Datenbank IDS Systems typischerweise empfohlen.

In den weiteren Artikeln werden verschiedene Arten von potenziellen Angriffen auf Datenbanksysteme vorgestellt einschließlich der Möglichkeiten diese zu entdecken sowie die konzeptionelle Architektur von Database Activity Monitoring Systemen und die Herausforderungen, denen sich diese Database Activity Monitoring Lösungen stellen müssen sowie der Umfang des Database Activity Monitoring beschrieben.

Grundsätzlich kann ein erfolgreicher Schutz von Datenbanken nur durch einen klar definierten Prozess erfolgen, in dessen Verlauf Aufgaben aus unterschiedlichen Bereichen zu meistern sind. Diese Bereiche sollen nachfolgend genannt werden:

    • Discovery und Assessment
    • Riskmanagement und Mitigation
    • User-Rights Management
    • Database Activity Monitoring/Firewalling

Hierbei liefern die Antworten jedes Bereichs den Input für die nachfolgenden Bereiche. Z. B. fordert die SOX-Compliance einen Audit-Trail über alle Änderungen an den Finanzdaten eines Unternehmens. In diesem Fall werden die Ergebnisse aus dem Bereich Discovery und Assessment (u.a. Datenklassifzierung hier Finanzdaten) direkt als Kriterium im Bereich Database Activity Monitoring als Regel verwendet z.B. „Logge alle INSERT, UPDATE, DELETE auf allen Datenbanken in den Finanzdaten gespeichert sind“. Daneben können die Ergebnisse des Bereichs User-Rights Management im Bereich Database Activity Monitoring dazu genutzt werden die Frage zu beantworten „ob und wann auf sensible Daten von Usern einer Abteilung zugegriffen worden ist und welche Berechtigung sie dafür haben“.

Angriffe auf Datenbanksysteme

Angreifer/Angriffe lassen sich in zwei Kategorien einteilen:

1. Intruder/Insider

Intruder – Eine Person die Zugriff auf ein Computersystem erlangt und versucht wertvolle Informationen zu extrahieren.

Insider – Eine Person, die zur Gruppe der vertrauten Benutzer gehört und versucht mittels ihrer eigenen Zugriffsberechtigungen Informationen zu erlangen. Die Literatur gibt es zahlreiche Beispiele von solchen Attacken:

      • Ein Accountmanager ändert die die Adresse eines Kunden auf seine eigene Adresse, fordert einen neue Kreditkarte und PIN an, die dann an seine eigene Adresse geschickt wird, um damit Geld von den Kundenkonten abzuheben
      • Mitarbeiter stehlen und verkaufen Kreditabrechnungen ihrer eigenen Kunden

2.    Hierbei lassen sich drei Typen unterscheiden:

      • Getarnte User nutzen widerrechlich fremde Logoninformationen (User/Pwd), um sich Zugriff zu Enterprise Applikationen und Daten zu verschaffen
      • Legitime User haben zwar einen authorisierten Zugriff auf die Systeme, mißbrauchen aber ihre Zugriffsrechte, um sich Informationen anzusehen oder diese zu kopieren ohne dass diese für Ihre Arbeit notwendig sind
      • Verborgene User besitzen administrative Zugriffsrechte ohne diese für ihre Arbeit tatsächlich zu benötigen

Weitere Informationen zu diesem Thema finden sich in dem Artikel: Top-Datenbankbedrohungen.

Top-Datenbankbedrohungen

Nachfolgend eine Liste der häufigsten Bedrohungen denen Datenbanksysteme heute ausgesetzt sind:

    • Missbrauch legitimer Berechtigungen (Insider Angriffe) – Jeder berechtigte Benutzer kann auch legitime Datenbankberechtigungen für nicht autorisierte Zwecke missbrauchen. Hier gibt es zwei Risiken, die in Betracht zu ziehen sind. Das erste Risiko ist ein böswilliger Benutzer, der Datensätze vielleicht verkaufen möchte. Das zweite sogar häufigere Risiko ist ein fahrlässiger Benutzer, der große Datenmengen aus der Datenbank abruft, auf seinem Client-Gerät zu Arbeitszwecken speichert und die Daten damit Bedrohungen wie Trojanern, Laptopdiebstahl usw. aussetzt.
    • Missbrauch übermäßiger Berechtigungen (Nicht autorisierte Aktionen privilegierter User) – Anwendern bzw. Anwendungen denen Datenbankzugriffberechtigungen erteilt werden, die ihren Aufgabenbereich übersteigen, können diese Berechtigungen u.U. zu böswilligen Zwecken missbrauchen. Z.B. sind Datenbankadministratoren (DBA), die grundsätzlich über erweiterte Rechte zur Erfüllung ihrer Aufgaben verfügen, in der Lage unerkannt Aktivitäten auf der Datenbank durchzuführen, die nicht zur Erfüllung ihren Aufgaben gehören. Häufig werden Datenbankbenutzern auch nur übermäßige Berechtigungen erteilt, weil die Datenbankadministratoren nicht genügend Zeit haben, abgestufte Kontrollmechanismen für die Zugriffsberechtigungen einzelner Benutzer zu definieren und auf dem neuesten Stand zu halten. Die Folge ist, dass allen Benutzern oder großen Benutzergruppen allgemeine Standardzugriffsberechtigungen erteilt werden, die weit über die Anforderungen ihrer Aufgaben hinausgehen.
    • Missbräuchliche Berechtigungserweiterung (Privilegien Eskalation) – Erlangung von umfassenden Zugriffsrechten (z.B. Administrationsberechtigungen) durch einen normalen Benutzer indem Datenbank Schwachstellen ausgenutzt werden (abhängig vom DBMS). Solche Schwachstellen können in gespeicherten Prozedu-ren, integrierten Funktionen, Protokollimplementierungen und sogar in SQL-Statements auftreten. Mit diesen Berechtigungen könnte der böswillige Benutzer anschließend Prüfmechanismen umgehen, Daten manipulieren oder stehlen, unerlaubte Transaktionen durchführen etc.
    • Ausnutzen von Schwachstellen fehlerhaft konfigurierter Datenbanken – In der Praxis finden sich sehr häufig Datenbanken mit nicht gepatchten Schwachstellen und solche mit Standardkonten und Konfigurationsparameter. Angreifer werden Systeme typischerweise auf diese Schwachstellen hin prüfen, sodass hier die Gefahr einer Sicherheitsverletzung gegeben ist. Zudem ist während der Zeit, in der ein Datenbankanbieter einen Patch für eine bestimmte Schwachstelle entwickelt, die Datenbank einer Organisation nicht gegen Angreifer geschützt. Und selbst wenn ein Patch freigegeben worden ist, steht dieser u.U. noch nicht sofort zur Verfügung. Grundsätzlich sind beim Patchen einer Datenbank verschiedene Aspekte in Betracht zu ziehen. Zunächst muß eine Organisation den Patchvorgang für das System für diesen bestimmten Patch bewerten und verstehen, welche Auswirkungen sich auf das System ergeben. Der Patch könnte evtl. bereits vorhandenen Code beeinträchtigt oder eine Work-Around-Möglichkeit eröffnen. Zudem verursacht ein Patchvorgang immer Ausfallzeiten, in denen der Datenbankserver nicht für die Benutzer zur Verfügung steht. Große Unternehmen mit einer großen Anzahl von Datenbanken müssen eine zeitliche Abfolge für das Patching festlegen und Datenbanken eine Priorität zur Behebung der Schwachstelle zuordnen. Daher ist es üblich, dass sich Patching-Vorgänge in vielen Organisationen über Monate hinziehen – typischerweise werden zwischen 6 und 9 Monate benötigt (basierend auf von der Independent Oracle User Group – IOUG* durchgeführten Studien). Beim Patching-Vorgang spielen DBAs, System- und IT-Admins, Entwickler eine Rolle. Aus diesen Gründen bleiben Server oft noch Monate nach der Freigabe eines Patches angreifbar und können von einem Angreifer über Standardkonten und Konfigurationsparameter, die aus einer produktiv genutzten Datenbank nicht ent-fernt worden sind, ausgenutzt werden. Ein Angreifer könnte z.B. versuchen, über ein Standardkonto Zugriff auf die Datenbank zu erlangen. Schwache Audit-Parameter erläuben es einem Angreifer, Audit-Kontrollen zu umgehen oder Spuren seiner Aktivitäten zu verwischen. Schwache Authentifizierungsschemata ermöglichen es Angreifern, die Identität legitimer Datenbankbenutzer anzunehmen, indem Anmeldeinformationen gestohlen oder anderweitig erhalten werden, Nutzung eines Exploits, um Zugang zur OS Shell zu erhalten. Darüber kann dann der Code von Services/Daemons in der Art geändert werden, dass die zugreifenden Controls, Auditing oder Authentication Mechanismen deaktiviert werden. (abhängig vom DBMS)
    • SQL Injection – Bei einem SQL-Injection-Angriff werden typischerweise nicht autorisierte Datenbank-Statements in einen angreifbaren SQL-Datenkanal wie gespeicherte Prozeduren und Eingabeparameter von Web-Applikationen eingeleitet. Diese eingefügten Statements werden anschließend zur Datenbank weitergegeben und dort ausgeführt, wodurch Angreifer uneingeschränkten Zugriff zur gesamten Datenbank erlangen können.
    • Unzureichender Audit-Trail – Elementarer Bestandteil jeder Datenbankimplementierung sollte sein, alle vertraulichen und/oder ungewöhnlichen Datenbanktransaktionen automatisch aufzuzeichnen. Schwache Datenbank-Audit-Richtlinien stellen auf vielen Ebenen ein ernsthaftes organisatorisches Risiko dar.
      • Regulatorisches Risiko – Organisationen mit schwachen oder fehlenden Datenbank-Audit-Mechanismen werden zunehmend feststellen, dass sie behördlichen Regulierungsanforderungen nicht entsprechen.
      • Abschreckung –Datenbank-Audit-Mechanismen dienen dazu, Angreifer abzuschrecken, weil sie wissen, dass Datenbank-Audit-Aufzeichnungen Ermittlern Beweismaterialien liefern, um Eindringlin-gen eine Straftat nachzuweisen.
      • Erkennung und Wiederherstellung –Sicherheitsverletzungen können nach ihrem Auftreten durch Audit-Daten identifiziert werden und dienen der Zuordung zu bestimmten Anwendern und/oder Reparatur des Systems.
    • Schwachstellen in grundlegenden Audit-Merkmalen – Datenbanksoftware-Plattformen verfügen in der Regel über grundlegende Audit-Merkmale, welche allerdings häufig mehrere Schwachstellen aufweisen, die ihre Implementierung einschränken oder ausschließen.
      • Fehlende Benutzerüberwachung – Wenn Anwender über Web-Applikationen auf Datenbanken zugreifen, lassen sich spezifische Benutzeridentitäten mit nativen Auditmechanismen nicht identifizieren, da die Benutzeraktivitäten dem Web-Applikatios-Account zugeordnet werden. Missbräuchliche Datenbanktransaktionen in nativen Audit Logs lassen sich somit nicht auf den verantwortlichen Anwender zurückverfolgen.
      • Leistungseinbußen – Native Datenbank-Audit-Mechanismen belegen häufig erhebliche CPU- und Festplattenressourcen, weswegen viele Organisationen wegen der auftretenden Leistungseinbußen Audit-Funktionen zurücknehmen oder vollständig deaktivieren.
      • Pflichtentrennung – Anwender mit Administrationsrechten für den Datenbankserver können Audit- Funktionen einfach abschalten, um missbräuchliche Aktivitäten zu verschleiern. Daher sollten Audit-Pflichten idealerweise zwischen Datenbankadministratoren und der Datenbank-Server-Plattform getrennt sein.
      • Begrenzte Granularität –Native Audit-Mechanismen zeichnen häufig nicht alle erforderlichen Details, um Angriffe zu erkennen, den forensischen Nachweis zu führen sowie Systeme wiederherzustellen. Datenbank-Client-Anwendung, Quell-IP-Adressen, Query-Response-Attribute und fehlgeschlagene Abfragen als wichtiger Indikator für Ausspähungen vor einem Angriff werden z. B. von vielen nativen Mechanismen nicht aufgezeichnet.
      • Proprietäre Formate – Da sich Audit-Mechanismen und Logs einzelner Datenbankserver-Plattformen z.T. erheblich voneinander unterscheiden, ist es für Organisationen mit gemischten Datenbankumgebungen nahezu unmöglich, einheitliche, skalierbare Audit-Prozesse über das gesamte Unternehmen hinweg zu implementieren.
    • Denial of Service (DoS) – Dies bezeichnet eine allgemeine Angriffskategorie, in der Angriffe dazu führen, dass berechtigten Anwendern der Zugriff auf Netzwerk-Applikationen und Daten verweigert wird. Denial of Service (DoS)-Zustände lassen sich über zahlreiche verschiedene Techniken hervorrufen, wobei viele dieser Techniken die bereits erwähnten Schwachstellen ausnutzen. Ein DoS lässt sich z. B. verursachen, indem Schwachstellen der Datenbankplattform genutzt werden, um einen Server zum Absturz zu bringen (z.B. Initiierung von Buffer Overflows). Weitere verbreitete DoS-Techniken sind die Kompromittierung von Daten, eine Überflutung des Netzwerks mit Netzwerkverkehr und eine Überlastung von Serverressourcen (Speicher, CPU usw.). Ressourcenüberlastungen treten besonders häufig in Datenbankumgebungen auf. Die Motivationen, die hinter DoS-Angriffen stecken, sind ähnlich vielfältig. DoS-Angriffe kommen häufig in Zusammenhang mit Erpressungsversuchen vor, in denen ein Remote-Angriffs-Server die Datenbank wiederholt zum Absturz bringt, bis das Opfer Gelder auf ein internationales Bankkonto überweist. In anderen Fällen lassen sich DoS-Zustände auf eine Wurm-Infektion zurückführen. Unabhängig von der Ursache stellen DoS-Angriffe für viele Organisationen eine ernsthafte Bedrohung dar.
    • Schwachstellen im Datenbankkommunikationsprotokoll – In Datenbankkommunikationsprotokollen aller Datenbankanbieter werden immer mehr Sicherheitsschwachstellen entdeckt, wobei in den jeweiligen nativen Audit-Trails keine Aufzeichnungen dieser Aktivitäten vorhanden sind, weil sie Protokolloperationen nicht abdecken. Missbräuchliche Aktivitäten, die auf diese Schwachstellen abzielen, reichen von nicht autorisierten Zugriffen auf Daten bis zu Datenkompromittierungen und DoS-Angriffen.
    • Nicht autorisierte Kopien vertraulicher Daten – Häufig werden nicht alle Datenbanken ordnungsgemäß erfasst und gewartet. Neue Datenbanken werden erstellt ohne dass das Sicherheitsteam Kenntnis von diesen Datenbanken weiß. Werden nun vertrauliche Daten wie Transaktions-, Kunden- und Mitarbeiterdetails in diese Datenbanken kopiert werden, sind diese einem Sicherheitsrisiko ausgesetzt, sofern die erforderlichen Kontrollen nicht implementiert werden. Ein weiteres Beispiel sind alte Datenbanken, die vergessen und nicht in die Bewertung einbezogen wurden.
    • Unzureichend geschützte Backup-Daten – Oft sind Speichermedien mit Datenbank-Backups völlig ungeschützt. In der Vergangenheit wurden immer wieder Fälle bekannt, in denen Bänder und Festplatten von Datenbank-Backups gestohlen worden sind, was zu ernsthaften Sicherheitsverletzungen geführt hat.
    • Angriffe per Web Applikation – Applikationen, die mit einer Datenbank im Hintergrund arbeiten, können kompromittiert werden, um Zugriffsrechte zu erweitern und damit umfassenden Zugriff auf die Datenbankresourcen zu erlangen (z. B. per SQL Injection). Hier ist es notwendig, dass die Database Activity Monitoring Lösung statt dem Applikationsaccounts auch Zugriff auf den wirklichen Verursacher der Aktion hat.
    • Zugriff auf OS Ressourcen per Datenbankangriff – z.B. ermöglicht die Änderung des UTL_FILE_DIR Parameters bei Oracle der Prozedur SYS.UTL_FILE wichtige Files auf dem Betriebssystem zu überschreiben oder Daten zu extrahieren.
    • Password Angriffe („BruteForce-Attacken“) – Hier wird versucht Passworte zu erraten, indem zahlreiche Zei-chenkombinationen per Skript am DBMS ausprobiert werden oder DB Schwachstellen werden ausgenutzt.
    • Cross Site Scripting (XSS) – Zugriff auf die Datenbank durch Diebstahl von Logoninformationen von legitimen Benutzern einer Webapplikation indem Userdaten in der Datenbank gespeichert werden und später anderen Usern auf der Website unverschlüsselt angezeigt werden.

Obwohl Datenbankinformationen somit vielen verschiedenen Angriffen ausgesetzt sind, ist es dennoch möglich, Risiken durch eine Konzentration auf die wichtigsten Bedrohungen, erheblich zu reduzieren. Wenn es Organisationen gelingt, den oben beschriebenen wichtigsten Bedrohungen mittels geeigneten Maßnahmen wie gelebten Berechtigungskonzepten, Erfüllung der Anforderungen an sichere Datenbanksysteme, dem Einsatz von Database Activity Monitoring Lösungen etc.  zu begegnen, erfüllen sie damit globale Compliance-Anforderungen und bewährte Industriestandards bezüglich Datenschutz und Risikominimierung.

Konzeptionelle Architektur von Database Activity Monitoring Lösungen

Gegeben ist ein Log mit Wer hat Was mit Welchen Daten Wann und Wie getan. Ein Database Activity Monitoring System sollte in der Lage sein die Frage nach dem Warum zu beantworten. Database Activity Monitoring Systeme helfen Organisationen dabei:

    • Aufspüren/Verhindern von Einbruchsversuchen in die Systeme einschließlich Privileged User
    • Erstellung eines regelmäßigen Reports hinsichtliche Systemnutzung und Datenmodifikationen
    • Erkennung und Wiederherstellen von Datenbanksystemen im Falle von System- und Bedienungsfehlern

Die Basisarchitektur eines Database Activity Monitoring Systems ist in der nachfolgenden Grafik dargestellt. Dannach besteht das System aus drei wesentlichen Komponenten wie einem Logger, einem Analyzer, und einem Notifier. Der Logger zeichnet Informationen auf, wobei die Art der zu speichernden Information durch die Security Policies festgelegt wird. Der Analyzer analyisert das Log in der Art, ob es Securityverstösse gibt oder ob noch weitere Informationen geloggt werden sollten. Der Notifier hat die Aufgabe die Ergebnisse an den Analysten zu reporten.

Logger

Die Definition der Loggingmethode umfaßt die Definitionen der Event-Typen und den Umfang des Monitorings. Damit bestimmt der Logger Inhalt, Zeit, Ort, Methode und Häufigkeit des Datenbankloggings sowie andere wesentliche Bereiche des Systems. Z.B. hat der Ort des Loggings einen direkten Einfluß auf die Effizienz von Analyse und Datenbereitstellung. Daneben muß das System dafür Sorge tragen, dass die Loggdaten während des Auditprozesses gegenüber unberechtigten Zugriffen geschützt sind und zudem auch ausreichend viele Informationen geloggt werden, um letztendlich ein umfassendes Monitoring sicherzustellen. Insgesamt ist der definierte Log-Umfang für ein Database Activity Monitoring System ein kritischer Faktor, weil die Möglichkeiten der Analysten, zur Rekonstruktion von auffälligen Events ganz besonders vom Inhalt und Richtigkeit des Datenbanklogs abhängen.

Analyzer

Die Analyse ist durch zwei Hauptfaktoren definiert: Das Ziel der Analyse und deren Zeiten und Wiederholungen. Das Ziel der Analyse bezieht sich auf die generellen Ziele des Monitorings, die sich wiederum auf das Aufspüren von Securityverletzungen beziehen. Der Analyseprozeß folgt typischerweise den nachfolgenden 4 großen Zielen:

    • Entdecken von Notwendigkeiten zur Änderung von Systempolicies
    • Aufspüren von definierten Problemen und Anomalien
    • Bestimmung der Verantwortlichkeit von Useraktivitäten
    • Erstellung eines regelmäßigen Reportings hinsichtlich Systemnutzung und Datenmodifikationen

Die Häufigkeit der Analyse wird bestimmt durch die oben genannten Ziele und kann periodisch, auf Transactionshäufigkeiten und/oder Real-time erfolgen. Häufigere Analysen erhöhen zwar die Wahrscheinlichkeit Missbräuche frühzeitig zu entdecken und die Reaktionszeit zu reduzieren, was jedoch auch steigende Kosten zur Folge hat. Real-time Analyse bietet die höchste Analysehäufigkeit und ist aber gleichzeitig auch die teuerste Alternative, die typischerweise den kritischen Systemumgebungen vorbehalten ist. Periodische Analysen werden grundsätzlich genutzt, um einen allgemeinen Systemüberblick zu erhalten oder ein regelmäßiges Reporting zu unterstützen. Die Transactionshäufigkeitsmethode erführt immer nach einer bestimmten Anzahl von Transaktionen eine Analyse durch.

Notifier

Das Notifikationsystem unterstützt die verfügbaren Recherchertechniken in der Art, dass die Daten in einer Form dargestellt werden, die den Analysten ermöglicht potentielle Bedrohungen und Verletzungen von Policies frühzeitig aufzudecken und bereinigt die Daten auf Basis der definierten Regeln und Rechteebenen der jeweiligen Betrachter.
Dies dient der Sicherheit der Daten gegenüber Änderungen der Informationen, abhängig vom jeweiligen User, dessen Informations-Level und den Ergebnissen. Der Bereinigungprozeß entfernt alle Informationen, die nicht relevant sind oder deren Informations-Level höher ist als der auf den der jeweilige User Zugriff haben darf.

Dies erfolgt durch zwei Prinzipien: 1. Getrennte Privilegien – > Trennung der Verantwortlichkeiten (Separation of duties) und 2. Minimale Privilegien. Getrennte Privilegien schützen die Daten dadurch, dass mehr als ein Key oder eine Au-thentication für den Zugriff auf sensitive Daten notwendig ist. Z.B. ist mehr als ein privilegierter User notwendig, um den Zugriff auf kritische Logs zu erhalten. Das Prinzip der Minimalen Privilegien gewährleistet, dass nur wenige Zugriffsrechte vergeben werden. Z.B. können User bei ihrer Suche und dem Datenzugriff auf einzelne Bereiche der Datenbank eingeschränkt werden, wobei keinem User gestattet ist auf alle Datenbankeinträge zuzugreifen.

Herausforderungen des Database Activity Monitoring

Performance

Database Activity Monitoring kann erheblichen Einfluß auf die Performance der Datenbanksysteme haben. Wenn alle Auditmöglichkeiten auf alle Objekte innerhalb der Datenbank aktiviert sind, kann der Performance Impact sehr hoch sein. Daher ist es unbedingt notwendig im Vorfeld festzulegen, welche Events auditiert werden sollen und welcher Performance Impact sich daraus ergibt. Hierbei sollte der Fokus primär auf sensiblen Daten liegen. Dies ist umso wichtiger, wenn das Database Activity Monitoring in Echtzeit arbeiten soll. Einige 3rd Party Lösungen bieten hierzu innovative Konzepte zum Umgang mit diesem Problem.

Protokollierungsebene

Um eine umfassende Sicherheit zu bieten, sollte die Database Activity Monitoring Lösung in der Lage sein Datenbankaktivitäten auf zwei Ebenen zu erfassen: Netzwerk Ebene (z.B. SQL Befehle, Angriffe auf Passworte und Benutzerinformationen), Datenbank Ebene (z.B. Column/Row, Tabellen, Views etc.). Native Database Activity Monitoring Lösungen sind meistens auf die Datenbankebene beschränkt, während 3rd Party Lösungen beide Ebenen abdecken.

Komfort

Führende kommerzielle Datenbankanbieter bieten native Auditfunktionalitäten in ihren Produkten. Während diese Funktionalitäten einerseits sehr leistungsfähig sind, sind diese andererseits aber häufig sehr schwierig zu konfigurieren. Es nimmt meistens viel Zeit in Anspruch, um alle richtigen Einstellungen zu aktivieren und die Falschen zu deaktivieren. Zudem muß diese Konfiguration für jeden Datenbankserver individuell durchgeführt werden, was in einer Enterprise-Umgebung mit häufig mehreren hundert Systemen vollkommen unwirtschaftlich und fehleranfällig ist. Die meisten 3rd Party Lösungen bieten hier wesentlich intelligentere Konfigurationsmöglichkeiten in ihren Produkten.

Bereinigung

Bereinigung durch Modifikation und Verschlüsselung von Auditinformation dient der Sicherheit der Daten gegenüber Änderungen der Informationen, abhängig vom jeweiligen User, dessen Informations-Level und den Ergebnissen. Der Bereinigungprozeß entfernt alle Informationen, die nicht relevant sind oder deren Informations-Level höher ist, als der auf den der jeweilige User Zugriff haben darf. Database Activity Monitoring Lösungen sollten in Lage sein die Auditdaten auf Basis der definierten Policies und der Zugriffsebenen der Auditoren zu bereinigen.

Sicherheit der Audit Logs

Audit Logs stellen ein attraktives Ziel für Angriffe dar, weil ein Angreifer hier die Spuren seines Angriffs komplett wieder entfernen kann. Zum Schutz des Audit Logs, müssen die Logdaten gegen Modifikationen geschützt sein. In diesem Zusammenhang muß unbedingt die Forderung nach einer Trennung der Verantwortlichkeiten („Separation of Duties“) berücksichtigt werden, damit selbst privilegierte Datenbank-Accounts keinen Einfluß auf die Logdaten nehmen können.

Datenbankbedrohungen

Vor der intensiven Nutzung des Internets waren Datenbanken gut geschützt, wobei der Zugriff per Standardverfahren wie Views und SQL Authorisierung erfolgte. Aber mit der rasanten Entwicklung von Webapplikationen, steigt die Zahl von Angriffen auf Datenbanken sprunghaft an und zeigt, dass die bestehenden Zugriffskontollmechanismen für web-bassierte Systeme nicht mehr ausreichend sind. Ein anderes ungelöstes Problem stellen die Insider Angriffe dar. Zwar wurden verschiedene Data-Mining Methoden zur Lösung des Problems entwickelt, wenn aber der Insider ein DBA ist, sind diese Methoden nicht einsetzbar, da der DBA alle Auditmechanismen deaktivieren kann. Die in dem Artikel Top-Datenbankbedrohungen genannten Punkte zeigen, dass die Entwicklung und Implementierung von geeigneten Lösungen gegen solche Arten von Angriffen eine dringende Herausforderung darstellen.

Database Activity Monitoring Lösungen

Ein wesentlicher Punkt im Rahmen der Data Security ist die Überwachung der Unternehmensdatenbanken zur frühzeitigen Erkennung von ungewöhnlichen Aktivitäten, die auf Angriffe oder Missbrauchsversuche hinweisen können.

Zur Bewältigung dieser Aufgabe werden neben herstellerspezifischen (native) Auditmechanismen der verschiedenen Datenbanksysteme heute vermehrt herstellerneutrale (Third Party) Database Activity Monitoring Tools (DAM) angeboten und eingesetzt.

    • Mit Database Activity Monitoring Lösungen lassen sich Datenschutzrichtlinien in Unternehmen besser durchsetzen, der Schutz vor internen Bedrohungen verbessern und die Einhaltung von Vorschriften wie zum Beispiel BASEL II, BDSG, Sarbanes-Oxley (SOX) oder PCI-DSS sicherstellen.
    • Die Lösungen bieten umfangreiche Auditfunktionalitäten, Unterstützung zahlreicher Datenquellen, revisionssichere Speicherung der Auditdaten und performanceneutrale Auditmechanismen.
    • Unautorisierte Aktivitäten, die gegen Sicherheitsrichtlinien und die Grundsätze ordnungsgemäßer Unternehmensführung verstoßen, lassen sich automatisch und schnell erkennen.
    • Die Generierung von Alerts und Compliance-Berichten erfolgt weitgehend automatisiert und die Integration eines Ticketsystems zur Nachverfolgung von Auffälligkeiten läßt sich über vorbereitete Schnittstellen herstellen.

Bei aller Euphorie für solche Tools sind jedoch grundsätzlich immer die Einschränkungen von Logging & Monitoring Maßnahmen zu beachten. Siehe hierzu auch die Ausführungen im Artikel „Möglichkeiten und Grenzen von Logging & Monitoring„.

Möglichkeiten und Grenzen von Logging & Monitoring

Der Betrieb von IT-Systemen beinhaltet immer das Risiko eines vorsätzlich missbräuchlichen Zugriffs. Im Vordergrund der Data Security sollte somit immer das Verhindern von Angriffen stehen!

Daher sind präventive Maßnahmen immer der erste und wichtigste Schritt hin zur Verbesserung der Sicherheit. Solche Maßnahmen verringern das Risiko erheblich, ohne es jedoch in jedem Fall auf ein akzeptables Niveau zu bringen. Im Rahmen des normalen Applikationszugriffs kann dem Datenmissbrauch z.B. durch geeignete Schwellwerte entgegen gewirkt werden. Ein Missbrauch erweiterter Zugriffsreche z.B. von Administratoren und Power-Usern, erfordert jedoch neben dem Einsatz von Verfahren z.B. zur Abschottung von administrativen Accounts von den Daten auch ein datenzugriffsbezogenes Logging & Monitoring. Zudem können Hacker-Angriffe bzw. -Versuche nur durch Speichern und Korrelieren von Logdaten wie Zugriffe, IP-Adressen etc. erkannt und nachverfolgt werden.

Sobald es bereits zu einem Security Vorfall gekommen ist, ist eine Beweisfähigkeit und Nachvollziehbarkeit des Vorgehens eines Angreifers dringend erforderlich, was nur durch den Einsatz von Logging & Monitoring Maßnahmen gewährleistet werden kann. Darüber hinaus ist zu klären wie privilegierte Benutzer, z.B. Administratoren und Power-User, zu ihrem eigenen Schutz sowie zur Einhaltung von Gesetzen und Richtlinien in ein umfassendes Überwachungskonzept eingebunden werden können.

Normen, wie der Data Security Standard der Kredikartenindustrie (PCI DSS), fordern zudem z.B. das Aufzeichnen von Zugriffen auf bestimmte Daten. Somit ergeben sich unterschiedliche Aufgaben, die man mit Logging- und Monitoring-Konzepten und Maßnahmen größtenteils bewältigen kann.

Beim Aufbau einer Logging- und Monitoring Umgebung sollte grundsätzlich immer zuerst festgelegt werden, welche Ereignisse zu protokollieren sind, wie sich missbräuchliche Handlungen erkennen lassen und auf welche Weise das Auditing überwacht wird.

Solche Ereignisse stellen i.d.R. Abweichungen von der Norm dar und sollten nicht massenhaft auftreten. Bei einer zu großzügigen Definition der Filter kann die Anzahl der Log-Einträge jedoch massiv ansteigen und die Systemperformance stark beeinträchtigen. Daher sollten die zu überwachenden Ereignisse sorgfältig ausgewählt und die Log-Datenmenge im Sinne von „Handhabbarkeit“, „Datensparsamkeit“, „Reduktion von Performance-Auswirkungen auf hoch frequentierte Systeme“, „Schutz der Arbeitnehmer vor falschen Verdächtigungen“ sowie „Verhinderung von Leistungs- und Verhaltenskontrollen der Arbeitnehmer“ minimiert werden ohne jedoch das eigentliche Ziel der Maßnahmen und mögliche gesetzliche Anforderungen aus den Augen zu verlieren.

Grundsätzlich ist beim Einsatz von Logging & Monitoring Maßnahmen jedoch immer zu beachten, dass falls z.B. verdächtige Aktivitäten von Accounts aufgefallen sind, die Frage, ob tatsächlich die Person, der dieser Account gehört, die Aktion durchgeführt hat oder ob sich nicht ein Fremder dieses Accounts für seine Aktivitäten bedient hat, nicht zweifelsfrei beantwortet werden kann. Denn ein intelligenter interner Angreifer wird i.d.R. nicht mit seinem eigenen Account Datenmißbrauch betreiben. Ein Externer Angreifer kann sogar nur mit fremden Accounts arbeiten, nachdem er sich Zugang zu deren Logon-Informationen verschafft hat.

Somit kann Logging & Monitoring nur im Nachhinein Angriffe erkennen und evtl. die Wege von Angreifern nachvollziehbar machen und damit evtl. Sicherheitslücken in Zukunft schließen, aber weder Prävention gegen Datenmißbrauch leisten, noch Aktivitäten zweifelsfrei auf ganz bestimmte Personen zurückführen, sondern nur Hinweise auf einen möglichen Täter liefern. Für einen zweifelsfreien Nachweis sind daher weitergehende Maßnahmen wie z.B. forensische Untersuchungen des PCs von dem der Angriff erfolgt ist, Benutzerbefragungen etc. notwendig.

Data Security Standard der Kredikartenindustrie (PCI DSS)

Die wesentlichen Regelungen des Data Security Standard der Kredikartenindustrie (PCI DSS) für den Bereich Data Security sind:

1. Build and Maintain a Secure Network

    • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
    • Requirement 2: Do not use vendor-supplied defaults for system passwords and other
      security parameters

2. Protect Cardholder Data

    • Requirement 3: Protect stored cardholder data
    • Requirement 4: Encrypt transmission of cardholder data across open, public networks

3. Maintain a Vulnerability Management Program

    • Requirement 5: Use and regularly update anti-virus software
    • Requirement 6: Develop and maintain secure systems and applications

4. Implement Strong Access Control Measures

    • Requirement 7: Restrict access to cardholder data by business need-to-know
    • Requirement 8: Assign a unique ID to each person with computer access
    • Requirement 9: Restrict physical access to cardholder data

5. Regularly Monitor and Test Networks

    • Requirement 10: Track and monitor all access to network resources and cardholder data
    • Requirement 11: Regularly test security systems and processes

6. Maintain an Information Security Policy

    • Requirement 12: Maintain a policy that addresses information security

Weitere Informationen zum Data Security Standard der Kredikartenindustrie (PCI DSS) finden Sie hier.

Basel II

Basel II bezeichnet die Gesamtheit der Eigenkapitalvorschriften, die vom Basler Ausschuss für Bankenaufsicht in den letzten Jahren vorgeschlagen wurden, wobei (IT-)Sicherheitsmaßnahmen, die maßgeblich Risiken für das Unternehmen mindern und sich nach Basel II somit positiv auf mögliche Kreditkonditionen auswirken können.

Die Regeln müssen gemäß den EU-Richtlinien 2006/48/EG und 2006/49/EG seit dem 1. Januar 2007 in den Mitgliedsstaaten der Europäischen Union für alle Kreditinstitute und Finanzdienstleistungsinstitute (= Institute) angewendet werden.

Weitere Informationen zu Basel II finden Sie hier.

Umfang des Database Activity Monitoring

Ziel ist es grundsätzlich lesende und ändernde Zugriffe auf schützenwerte Daten auf Datenbankebene zu protokollieren, um die Gesamtmenge der Auditdaten auf das Wesentliche zu begrenzen und damit überhaupt ein effizientes Monitoring zu ermöglichen.

Lokalisierung von vorhandenen Datenbankinstanzen

Die Datenschutzinitiative sollte grundsätzlich damit beginnen, die vorhandenen Datebankinstanzen ausfindig zu machen, da nur das geschützt werden kann, was auch bekannt ist. Hierbei sollten nicht nur die Netzwerksegmente, sonderen auch die Datenbankinstanzen des Recovery & Deasaster-, Test- und Staging-Umfelds betrachtet werden. Dies ist in einem gesonderten Dokument zur jeweiligen Datenbank bzw. Applikation zu beschreiben.

Definition und Lokalisierung von schützenswerten Daten

Da nicht jede Datenbankinstanz für das Datenbank Activity Monitoring interessant ist, sollte in diesem Schritt pro Datenbank bzw. Applikation überprüft werden, ob überhaupt sensible und schützenwerte Daten in der Datenbank vorhanden sind erfasst werden. Dies ist in einem gesonderten Dokument zur jeweiligen Datenbank bzw. Applikation zu beschreiben.

Die Informationen zur Existenz von sensiblen Daten in der Datenbank zusammen mit Informationen zum Härtungsstatus der Datenbank aus den Datenbank-Scans lassen nun die Ableitung eines Risikos für die schützenswerten Datenbanken zu. Ein errechneter Risikowert auf einer Skala von 1 bis 10 bietet nun einen guten Überblick darüber, wo der größte Handlungsbedarf besteht.

Datenklassifizierung

Das Database Activity Monitoring ist erst effizient, wenn die Anzahl der “false positives” und “false negatives” sowie der Umfang der Auditdaten minimal sind. Zur Erzielung dieser Effizienz müssen in diesem Schritt die Speicherobjekte mit sensitiven Daten identifiziert und klassifiziert werden. Eine Klassifizierung der sensiblen und schützenswerten Daten kann z. B. in unterschiedliche Datentypen wie Personaldaten, Finanzdaten, Kreditkarten Informationen, User Credential etc. erfolgen.

Regeldefinition

Im Anschluß an die Datenklassifizierung sind zu den einzelnen Datenklassen entsprechende Regeln/Policies zu definieren, die bei einem Zugriff auf die Daten der zugrunde liegenden Datenklasse anschlagen. Solche Policies müssen klar und eindeutig formuliert und gleichzeitig flexibel gegenüber regelmäßigen Änderungen in den Systemen, Datenobjekten, Benutzerrollen, den Regularien und den strategischen Unternehmensrichtlinien und -zielen sein. Beispiele von möglichen Policies sollen nachfolgend beschrieben werden:

    • Financial Data Policy – Das Database Activity Monitoring System sollte jeden Zugriff auf Finanzdaten monitoren.
    • Personal Data Policy – Das Database Activity Monitoring System sollte jeden Zugriff auf Personaldaten monitoren.
    • Schema Change Policy – Das Database Activity Monitoring System sollte jede Änderung von Datenbankchemata und Benutzerkonten monitoren.
    • Large Data Set Policy – Das Database Activity Monitoring System sollte jeden Zugriff auf große Mengen von z.B. Kundendaten erkennen und monitoren.
    • Failed Login Policy – Das Database Activity Monitoring System sollte alle fehlgeschlagenen Verbindungsversuchen zum Datenbankserver monitoren.

Das Database Activity Monitoring System muß hierzu in der Lage sein bei der Regeldefinition die relevanten Daten-banken, Tabellen, Objekte und Felder entsprechend zu konfigurieren. Z. B. sollte es möglich sein eine Regel auf einer definierten Datenbank für eine bestimmte Tabelle für eine bestimmt Aktion zu erstellen.

Datenerhebung

Abhängig von den definierten Regeln kommen u.a. nachfolgende Daten in Frage, die von einem Database Activity Monitoring System erhoben werden können:

    • Anmeldeinformationen an den Datenbanken
    • Aktivitäten auf der Datenbank mit welchen Privilegien

Implementierung der entsprechenden Regeln/Policies

Die konkrete Implementierung der entsprechenden Regeln/Policies ist vollständig abhängig von der Database Activity Monitoring Lösung und ist in einem gesonderten Dokument zur Lösung zu beschreiben.