Einführung Im Zuge eines großen Auditing-Projektes stellte sich die Frage: Wie auditiere ich sinnvoll 1000+ Datenbanken (Instanzen) verschiedener Hersteller?
Ansätze für Auditing 1.
Alle Aktivitäten mit auditieren (enorme Datenmenge, Performance Impact, selten verwendet)
2.
Alle DDL-Befehle + Logon mitprotokollieren (oft Ansatz in der Oracle Welt)
3.
Auditierung von verdächtigen/gefährlichen Aktivitäten
1. Ansatz (alles auditieren) 1.
Alle Aktivitäten werden mitprotokolliert und an ein SIEM System gesendet (Security Information and Event Management)
2.
Die enorme Menge an Daten ermöglicht das Nachvollziehen aller Aktivitäten führt aber auch zu hohem Platzbedarf und z.t. hohen Lizenzkosten.
3.
Die Vorfälle müssen in der Datenmenge „gefunden“ werden
2. Ansatz (DDL Befehle) 1.
Alle DDL-Befehle (=Rechte/Strukturänderungen/...) werden mitprotokolliert und an ein SIEM System gesendet
2.
Erheblich reduzierte Menge an Daten (typischerweise 300-6000 Events pro Tag pro DB)
3.
Es werden nur DDL/Logon Aktivitäten mitprotokolliert
4.
Die Vorfälle müssen in der Datenmenge „gefunden“ werden
3. Ansatz (Sicherheitsvorfälle) 1.
Es werden nur Verletzungen von vorher definierten Sicherheitsvorfällen mitprotokolliert und an ein SIEM System gesendet
2.
Erheblich reduzierte Menge an Daten durch individuelles Baselining je Datenbank
3.
Die Vorfälle können durch eine Klassifizierung in gut / verdächtig / gefährlich sehr einfach identifiziert werden
1.
Der Kunde entschied sich für Ansatz 3
2.
Da verschiedene DB Hersteller (Oracle, MySQL, Sybase ASE und DB2 LUW) abgedeckt werden mussten, entschied sich der Kunde für eine 3rd-partyLösung.
Grundlagen
DB-Logon
¡
Es gibt in der Regel unterschiedlichste Arten von Zugriffen (z.T. 30+) auf eine Datenbank
DB-Logon
¡
Es gibt in der Regel unterschiedlichste Arten von Zugriffen (z.T. 30+) auf eine Datenbank
¡
Wie erkennt man den verdächtigen Zugriff?
Faktoren Für eine Datenbankverbindung benötigt man zumindest die folgenden Parameter / Faktoren: 1.
Datenbank-Benutzer
2.
Executable
3.
Source-Host
4.
OS-Benuter
Diese Parameter erlauben die Definition von gut/böse/verdächtig.
Wie unterscheidet man „gute“ von „bösen“ Zugriffen? Aufzeichnung aller Zugriffe auf die Datenbank über einen längeren Zeitraum (mind. 4 Wochen). Dies man man einfach mit Hilfe eines Logon-Triggers oder spezieller 3rd-party-Tools implementieren und automatisieren.
Damit werden alle in diesem Zeitraum auftretenden Anwendungen und administrativen Werkzeuge mitprotokolliert. Danach neu auftretende Kombinationen (z.B. Quartals- oder Jahresabschluss) werden nachgepflegt.
Beispiel Detection (Objects)
Abnahme Die Werte der Faktoren müssen von der Fachabteilung/Anwendungs-DBA und der DB-Administration abgenommen werden. Da die Werte in der Regel passen, ist es für die Fachabteilung „relativ“ einfach. Nachfragen gab es selten.
Sicherheitsvorfälle (Auszug) Die Sicherheitsvorfälle werden mit dem Kunden definiert und entsprechend als Audit-Regel umgesetzt.
Spinnennetz Die Sicherheitsvorfälle werden mit dem Kunden gemäß seinem Sicherheitsbedarf definiert und entsprechend als Audit-Regel umgesetzt. Zum besseren Verständnis wurden der Zusammenhang zwischen Regel und Faktoren (DBUser, Executable, Host) als Spinnennetzgrafik implementiert.
