Database Activity Monitoring mit Imperva SecureSphere

Erfahrung aus der Praxis: Database Activity Monitoring mit Imperva SecureSphere

In dem ersten Artikel Protokollierung der Datenbank Aktivitäten wurde bereits erörtert, dass das Protokollieren der Aktivitäten innerhalb einer Datenbank weit mehr als die Speicherung bestimmter Datenbank Operationen ist. Die Forderungen aus den verschiedenen Regularien beziehen sich immer auf die Kontrolle der Zugriffe auf Daten mit besonderem Schutzbedarf und dem Nachweis, dass die für den Schutz dieser Daten definierten Regeln wirken und eingehalten werden. Daher ist neben der Speicherung auch die Auswertung der Daten erforderlich.

Aus diesen Fakten ergibt sich außerdem, dass neben dem eigentlichen Protokollieren – Aufzeichnen der Aktivitäten zwecks Nachweises – auch eine Alarmierung vorhanden sein sollte, um auf Regularien-Verstöße direkt reagieren zu können. Daher unterscheiden wir in diesem Artikel auch zwischen folgenden Begriffen:

• Protokollierung

Datenbank Aktivitäten werden aufgezeichnet, ohne das unmittelbar ein Regelverstoß festgestellt wurde. Diese Ereignisse besitzen entweder Merkmale, die auf ein erhöhtes Risiko hinweisen, oder aber sie können für andere Ereignisse wichtige Daten liefern. Oft werden erst Verstöße oder Datenmissbräuche festgestellt, wenn verschiedene Protokolldaten in Relation zueinander gesetzt werden.

• Alarmierung

Bei Datenbank Aktivitäten, bei denen unmittelbar ein Regelverstoß festgestellt werden kann, wird eine Alarmierung ausgelöst. Neben der Erfassung und Speicherung der Operation mit allen zu dieser Operation vorhandenen Daten erfolgt üblicherweise eine Aktion, wie zum Beispiel das Informieren von bestimmten Personengruppen.

Für das Database Activity Monitoring (DAM) sind folgende Funktionen erforderlich, um die erhobenen Daten auch sinnvoll nutzen zu können:

1. Erfassung der Aktivitäten
2. Erkennen (Parsen) der Operationen
3. Bewertung der Operationen gemäß einem Regelwerk
4. Klassifizieren und Aggregieren der Daten
5. Ggf. Ergänzung mit Daten anderer Quellen, z.B. mit Daten aus einer „Configuration Management Database“ (CMDB)
6. Speicherung und Archivierung der Daten
7. Einlesen älterer Archive für eine erneute Auswertung
8. Ggf. Weiterleiten der Daten an ein nachgelagertes System, z.B. einem „Security Information and Event Management System“ (SIEM)

Im folgenden Artikel wird ein System beschrieben, mit dem ein Database Activity Monitoring betrieben wird, welche Ansätze gewählt wurden, um eine für die Umgebung geeignete Lösung zu finden und welche weiteren Möglichkeiten existieren, um ein Monitoring zu optimieren.

Ausgangslage

In einer Enterprise Umgebung mit mehreren Hundert Datenbanken, im wesentlichen Oracle und Microsoft SQL Datenbanken wird ein Database Activity Monitoring mit SecureSphere betrieben. Ziel ist es die Datenbanken als Plattform abzusichern. So soll unter anderem der Zugriff auf die Applikationsdaten durch DBAs überwacht werden.

Der Fokus lag bei diesem Projekt auf den Oracle Datenbanken, auch wenn MS SQL und Sybase Datenbanken ebenfalls angebunden wurden. Daher beziehe ich mich im Folgenden auf DAM für Oracle Datenbanken.

Database Activity Monitoring mit SecureSphere

Imperva SecureSphere ist ein Produkt, um ein Activity Monitoring verschiedener Systeme zu betreiben. Es kann als Web Application Firewall (WAF) die Aktivitäten auf Web-Servern kontrollieren, die Zugriffe auf Fileserver mittels File Activity Monitoring (FAM) und die Aktivitäten innerhalb von Datenbanken diverser Datenbank-Provider mittels Database Activity Monitoring (DAM) überwachen. Gerade die Kombination der Überwachung der unterschiedlichen Komponenten kann einen großen Mehrwert darstellen. Beim Kunden lag allerdings der Fokus ausschließlich auf das Activity Monitoring der Datenbanken und hier im Wesentlichen auf denen der Oracle Datenbanken.

Beim Database Activity Monitoring mit SecureSphere werden aus den Netzwerk Paketen die SQL-Statements extrahiert und mittels Regular Expression die Statements geparst. Zusammen mit den anderen aus den Netzwerk Paketen ermittelten Attributen wie z.B. Programmname, Client-Hostname und Username werden die Werte mit den dem System zugewiesenen Regeln verglichen. Gemäß diesen Regeln wird bestimmt, was protokolliert (Audit-Policies) und was alarmiert (Security-Policies) wird.

Database Activity Monitoring mit SecureSphere nutzt drei Gruppen von Komponenten.

1. Agenten

Die Agenten sind im Wesentlichen für die Datenerhebung zuständig. Dadurch, dass sie im Kernel eingebunden sind, können sie neben dem Netzwerkverkehr auch die direkten Datenverbindungen (BEQ, IPC) lesen. Damit ist auch die Datenerhebung bei aktiver Transportverschlüsselung möglich.

Zur Reduzierung der Datenmenge können über „Agent Monitoring Rules“ (AMR) Ausschlusskriterien definiert werden. Alle Daten, die nicht durch eine AMR Ausschlussregel herausgefiltert wurden, werden an das Gateway geschickt, an dem der Agent aktuell angemeldet ist.

Ein Agent wird nicht pro Datenbank, sondern pro Datenbank-Server installiert. Selbst wenn auf einem Server mehrere Datenbanken laufen, so wird nur ein Agent benötigt. Bei Cluster-Systemen gilt wiederum, dass auf allen Servern des Clusters ein Agent benötigt wird. So sind zum Beispiel bei einer Datenbank auf einem 4-Knoten RAC System mit zwei Standby One-Node RAC Datenbanken insgesamt sechs Agenten erforderlich.

• Gateways

Die eigentliche Arbeit findet auf den Gateways statt. Die auf den Datenbanken ausgeführten Statements werden aus den Daten der Agenten extrahiert, diese werden geparst und entsprechend der definierten Regeln für das Speichern und Alarmieren ausgewertet. Die Daten werden auf den Gateways gespeichert. Über einen Zeitplanjob werden diese archiviert und ältere wieder entfernt.

• Management Server (MX)

Der Management Server dient im Wesentlichen der Steuerung der Komponenten und der Administration. Über einer Web-GUI werden hier fast alle Einstellungen vorgenommen. Auch die Regeln werden auf dem MX definiert, die dann automatisch an die Gateways und Agenten verteilt werden. Auch das Zuführen externer Daten (Enrichment) erfolgt über den MX.

Umgebung

In der Umgebung, die wir als Beispiel betrachten, sind knapp 180 Agenten auf 8 Gateways verteilt. 10 Gateways sind in zwei Gateway Clustergruppen im Einsatz, wobei jeweils ein Gateway pro Gateway-Cluster für die Hochverfügbarkeit im Leerlauf ohne Agenten läuft. Fällt bei dieser Konfiguration ein Gateway im Gateway-Cluster aus, so werden die Agenten dieses Clusters automatisch auf die verbleibenden verteilt.

Einige große Datenbanken mit sehr vielen Operationen pro Sekunde produzieren große Mengen an Protokolldaten. Dementsprechend werden auch viele Daten von den Agenten an die Gateways weitergeleitet. Trotzdem wurden bisher nur wenige Lastspitzen bei den Gateways festgestellt. Bei allen Agenten ist zwar das Capping (Limitierung der CPU-Last) aktiv, um die Performance der Datenbanken nicht zu beeinflussen. Die Agenten mussten aber das Capping derzeit nicht nutzen. In früheren Versionen wurde gelegentlich von Performance Problemen bei den Agenten berichtet. Das Problem scheint offensichtlich nicht mehr aufzutreten.

Da der Kunde die Endverarbeitung und Langzeitarchivierung der Protokollierung beim SIEM System haben wollte, wird SecureSphere nur für die Erfassung und Aufbereitung der Datenbank Aktivitäten genutzt, nicht aber für die Endverarbeitung und Speicherung. Stattdessen werden die Daten über Syslog im CEF ähnlichem Format an das SIEM System weitergesendet. Die Gateways archivieren zwar täglich ihre Daten auf einem NFS-Laufwerk, dieses dient aber nur als Fallback-Lösung, sollten Daten nicht an das SIEM System gesendet werden.

Regelwerk

Für das Protokollieren und das Alarmieren können in SecureSphere verschiedene Regeln definiert werden. Diese Regeln können in drei Gruppen unterteilt werden.

• Agent Monitoring Rules (AMR)

Diese Regeln kommen bereits auf den Agenten zur Ausführung. Sie dienen meist als Vorfilter um die Datenmenge zu begrenzen.

• Audit Rules

Diese bestimmen, was protokolliert wird. Die SQL-Statements mit allen Zusatzinformationen werden gespeichert und dienen unter anderem als Datenbasis für Forensische Analysen.

• Security Rules

Da einige Privilegien bestimmten Datenbank Gruppen nicht entzogen werden können, muss mit anderen, mitigierenden Maßnahmen sichergestellt werden, dass keine Verstöße gegen das Sicherheitskonzept auftreten. Durch Security Rules können solche Verstöße festgestellt und entsprechende Maßnahmen eingeleitet werden. Daher sind diese Regeln in den meisten Fällen auch mit Action-Sets verknüpft, damit aus einer Regelverletzung auch eine Handlung erfolgen kann.

Bei RAC Datenbanken hat es sich als vorteilhaft herausgestellt, die Daten einiger Background-Prozesse bereits auf dem Agenten durch Agent Monitoring Rules (AMR) herauszufiltern. Für diese Regeln bieten sich hier gerade die Kriterien Prozess-Eigentümer, Prozess-Gruppe und der Prozessname an. Der Ausschluss kann auch für alle Child-Prozesse gelten, was in der Regel auch gewünscht wird. Im Kundensystem wurden zum Beispiel AMRs definiert, um einige Prozesse für die RAC-Steuerung und dem Backup von der Weiterverarbeitung auszuschließen. Hier wird durch andere Verfahren ein Missbrauch verhindert.

Für das Analysieren von Sicherheitsvorfällen ist es hilfreich den genauen Zeitpunkt der Anmeldung des Benutzers an das System und auch an anderen Systemen festzuhalten. Daher ist eine Audit Policy für Logins/Logouts sinnvoll. Allerdings sind für einige Applikationen, die eine hohe Connect Rate besitzen, Ausschlüsse definiert worden, zumal diese Anwendungen über ein eigenes Logging verfügen.

Für einige hochprivilegierte Accounts sollte eine vollumfängliche Protokollierung implementiert werden, da hier die zugewiesenen Privilegien weit größer sind, als erforderlich. Das größte Risiko geht von solchen Kennungen aus.

Für eine Datenbank-Plattform-Überwachung wurden Regeln erstellt, die zum Beispiel beim lesenden, schreibenden oder strukturändernden Zugriff auf die Objekte der Applikation durch einen DBA-Account ein Alert-Event erzeugen. Damit soll eine striktere Trennung zwischen Datenbank Plattformadministration und Applikation gewährleistet werden. Auch werden Segregation of Duty (SoD) Verletzungen alarmiert, die gemäß einer internen Richtlinie für bestimmte privilegierte Befehle, wie zum Beispiel „alter user“ definiert sind.

Viele Regeln nutzten externe Quellen, um eine bessere Einordnung vornehmen zu können und damit auch eine bessere Unterteilung zwischen „Erlaubt“ und „Verboten“ zu ermöglichen. So werden Lookup Data Tables genutzt, um zum Beispiel eine Liste mit bestimmten Accounts abzufragen. Einige dieser Listen sind statisch, aber die meisten werden dynamisch erzeugt. Bei dynamischen Lookup Data Tables werden die Inhalte durch SQL-Queries oder Active Directory Abfragen regelmäßig aktualisiert. Damit sind die Daten für die Regeln immer aktuell und müssen nicht laufend nachgepflegt werden.

Eine Möglichkeit des Data Enrichments bietet SecureSphere, indem aus bestimmten vordefinierten SQL-Kommandos, dass der Datenbankuser in der Zieldatenbank absetzt, Werte ermittelt werden. Implementiert wurde die Übermittlung einer Ticketnummer. Bei einem lokalen Connect wird automatisch ein bestimmtes SQL-Kommando aufgerufen und die Ticketnummer gesetzt. Da lokale Anmeldungen in der beschriebenen Umgebung nur möglich sind, wenn eine gültige Ticketnummer eingegeben wird, werden alle DBA-Aktivitäten der Datenbank Session mit einer Ticketnummer verknüpft und können damit den DBA-Aufgaben zugeordnet werden.

Aggregieren

Wenn die Kriterien einer Database Security Regel erfüllt sind werden die Daten als Violation Event gespeichert und die bei der Regel hinterlegten Folgeaktionen (Action-Sets) ausgeführt. Wenn mehrere Violations einer Regel mit ähnlichen Eigenschaften innerhalb eines Zeitraumes auftreten, werden diese automatisch in nur in einem Alert zusammengefasst. Ein Alert ist daher immer die Repräsentation eines, oder aber mehrerer – ggf. sehr vieler – Violation Events. Damit ist in SecureSphere die Übersicht gewährleistet, selbst, wenn viele Millionen Events innerhalb eines kurzen Zeitraumes auftreten, wie dieses zum Beispiel bei Massen-Inserts der Fall wäre.

Da in der beschriebenen Kundenumgebung alle Events durch Action-Sets an das SIEM System weitergeleitet werden, spielt in diesem Fall die Aggregierung in SecureSphere eine untergeordnete Rolle. Im Wesentlichen wird hier innerhalb des SIEM Systems aggregiert. Nur auf der Web-GUI von SecureSphere kann die SecureSphere eigene Aggregierung genutzt werden.

Weitere Möglichkeiten in SecureSphere Suchfilter zu setzen, vereinfacht ebenfalls die gezielte Suche nach bestimmten Datensätzen.

Anbindung an externe Systeme

Da beim beschriebenen Kundensystem für die Endverarbeitung und die Speicherung ein SIEM System zum Einsatz kommen sollte, wurde bei den Security Policies und bei den Audit Policies Folgeaktionen (Action-Sets) ausgewählt, die die Daten über Syslog in einem CEF ähnlichen Format an das SIEM System schicken. Je nach Typ des Action-Sets erfolgt die Übertragung der Ereignisdaten des Managements Server (MX) oder von dem jeweils involvierten Gateway.

Das System bietet aber weitere Möglichkeiten auf Ereignisse, wie zum Beispiel einen Alarm zu reagieren. So können unter anderem auch E-Mails mit den Daten versandt oder ein Remedy Ticket eröffnet werden. Das System bietet eine Vielzahl von Action-Sets, die man bei der Protokollierung, der Alarmierung und dem Reporting nutzen kann.

Reporting

Es können Reports in Form von PDF oder CSV-Dateien generiert werden, die einen Überblick über die aktuellen Einstellungen und die eingebundenen Systeme geben. Reports können aber auch einen Ausschnitt von Audit-, Alert- und System-Logs enthalten.

Über einen Zeitplanjob können Reports wiederkehrend automatisch ausgeführt werden. Die Ausführung kann außerdem mit einem Action-Set verbunden werden, so dass z.B. ein Report per Mail, per NFS-Speicherung oder per OS-Skript weitergeleitet wird. In der beschriebenen Umgebung wurde z.B. ein Agenten Statusbericht umgesetzt, der regelmäßig die Statusdaten der Agenten als File an ein anderes Überwachungstool überträgt.

RESTful API

Imperva SecureSphere besitzt eine RESTful API, mit der man in der aktuellen Version alle wesentlichen Konfigurationseinstellungen abfragen, Einstellungen verändern oder neue Objekte anlegen kann. Damit ist eine applikations- oder skriptgesteuerte Anpassung von SecureSphere möglich.

In einem Projekt war geplant diese Schnittstelle für die Automatisierung der Rekonfiguration zu nutzen. Über eine CMDB werden die zu überwachenden Datenbanken mit ihren Eigenschaften ermittelt und mit dem Stand in SecureSphere verglichen. Der sich aus dem Delta ergebende Änderungsbedarf wird überprüft, gegebenenfalls werden einige Anpassungen vorgenommen und diese dann als neuer, aktuelle Stand freigegeben. Mit der Freigabe werden API-Calls ausgeführt, die die notwendigen Änderungen in SecureSphere vornehmen. Damit werden neue Datenbanken hinzugefügt und dekommissionierte Datenbanken ausgetragen.

Weitere Möglichkeiten

Kunden, die SecureSphere sowohl als Web Application Firewall (WAF), als auch für das Database Activity Monitoring (DAM) einsetzen, haben den Vorteil die Daten aus beiden Bereichen miteinander verknüpfen zu können. Daten, die aus WAF ermittelt werden, können direkt in DAM genutzt werden. So ist bei Three-Tier Architekturen in DAM nur derselbe Datenbank User des Connection Pools bekannt. Mit WAF können aber die Enduser Informationen ermittelt und mit der jeweiligen Datenbank Session in DAM verknüpft werden. Das dürfte gerade auch bei Oracles Application Express (APEX) Anwendungen von Vorteil sein. Bei APEX ist die Web-Anwendung mit der Datenbank eng verknüpft.

Resümee

Das vorgestellte System erfüllt alle eingangs beschriebenen Anforderungen:

1. Erfassung der Aktivitäten

Die Erfassung der Aktivitäten erfolgt durch Auswertung der Netzwerk-Pakete durch den Agenten. Durch Agent Monitoring Rules (AMR) können die Aktivitäten gewisser Prozesse bereits frühzeitig herausgefiltert werden.

• Erkennen (Parsen) der Operationen

Die Daten werden vom Agenten an das Gateway geschickt. Hier werden die Statements geparst. Dieses erfolgt durch Regular Expression Regeln, die von Imperva bereits mitgeliefert werden.

• Bewertung der Operationen gemäß einem Regelwerk

Die Daten der Operationen werden mit den Regeln verglichen, die der Kunde gemäß seiner Anforderungen angelegt hat. Bei Übereinstimmung werden die Daten gespeichert und die hinterlegte Folgeoperation (Action-Set) ausgeführt.

• Klassifizieren und Aggregieren der Daten

Violations einer Regel mit ähnlichen Eigenschaften innerhalb eines Zeitraumes werden als Alert zusammengefasst. Damit ist auch beim Auftreten vieler Events die Übersicht gewährleistet. Durch diverse Filter kann gezielt nach bestimmten Daten, auch Target-übergreifend, gesucht werden.

• Ergänzung mit Daten anderer Quellen

Die Regeln können mit Werten aus statischen und dynamischen Listen ergänzt werden. So können Daten aus einer CMDB eingelesen und für die Regeln genutzt werden.

Aus bestimmten SQL-Operationen können Werte ermittelt werden, die als zusätzliche Attribute an die Session gepinnt werden. Damit kann z.B. eine Ticketnummer den SQL-Statements zugeordnet werden. 

• Speicherung und Archivierung der Daten

Über einen Zeitplanjob werden die Daten entsprechend von den Gateways auf ein NFS-Laufwerk archiviert.

• Einlesen älterer Archive für eine erneute Auswertung

Diese Archivierungen können jederzeit wieder ins System eingelesen werden, um eine Auswertung auch viel älterer Daten vornehmen zu können.

• Weiterleiten der Daten an ein nachgelagertes System

Die Events aus den Audit-Policies und Security-Policies können direkt an ein nachgelagertes SIEM-System geschickt werden oder direkt ein Ticket in Remedy erzeugen.