Individuelles Auditing von vielen Datenbanken

Individuelles Auditing von
vielen Datenbanken
Agenda
¡ Einführung
¡ Audit-Ansätze
¡ Sicherheitsvorfälle
¡ Spinnennetz
¡ Lessons Learned
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.
Spinnennetz
Action
(Logon,
CC
Select,
...)
18
Spinnennetz
19
Unbekannter
DBUser
Action
(Logon,
<
CC
Select,
...)
Spinnennetz
20
Unbekannter
DBUser
Action
(Logon,
Z<<
<
CC
Select,
...)
Spinnennetz
Unbekannter
DBUser
Action
<<<<<<<<<<<<<<<<<<<<<<<
(Logon,
Z<<
<
CC
<<<<<<<<<<<<<<<<<<<<<<<
Select,
<<<<<<<<<<<<<<<<<<
...)
21
Spinnennetz
Alle 8 (=2^3)
Zugriffswege sind
definiert
Unbekannter
DBUser
Action
<<<<<<<<<<<<<<<<<<<<<<<
(Logon,
Z<<
<
CC
<<<<<<<<<<<<<<<<<<<<<<<
Select,
<<<<<<<<<<<<<<<<<<
...)
22
Auditing und §87 Betriebsverfassungsgesetzes
Betriebsverfassungsgesetz
§ 87 Mitbestimmungsrechte
(1) Der Betriebsrat hat, soweit eine gesetzliche oder tarifliche Regelung
nicht besteht, in folgenden Angelegenheiten mitzubestimmen:
[...]
6.Einführung und Anwendung von technischen Einrichtungen, die dazu
bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu
überwachen;
• Der gewählte Ansatz erlaubt es, die “guten“ Zugriffe, die in der
Regel mehr als 99,9% aller Zugriffe darstellen, von der Protokollierung
auszuschließen
• Dadurch wird keine Verhalten– oder Leistungskontrolle durchgeführt.
23
Beispiel
Login Unbekannter DB Benutzer
• Beschreibung Event:
Ein Datenbank-Benutzer, der bisher noch nicht für einen Login
verwendet wurde, wurde zum erfolgreichen Login benutzt. Dieser
Nutzer kann neu oder bisher noch nicht verwendet worden sein.
• Mögliche Erklärungen:
• Es wurde ein neuer DB Benutzer angelegt. Existiert ein Ticket?
• Es wurde eine neue Software installiert, die einen neuen
Benutzernamen verwendet (z.B. ANW4 statt ANW3).
• Es wird eine neue Funktionalität verwendet, die bisher nicht
verwendet wurde.
• Im Zugriff eines Angriffs legt der Benutzer einen neuen an (z.B.
HACKER)
24
Login unbekannter DB Benutzer
Regulär
Kein Log
25
<
CC
Login
illegal
Beispiel Database Export
• Beschreibung Event:
Ein Benutzer exportiert die gesamte Datenbank oder Teile davon.
• Mögliche Erklärungen:
• Export von Daten für einen Kunden zum Neuaufsetzen eines
Systems (Refresh)
• Diebstahl von Daten
26
Export Datenbank
rest
illegal
Export
Z<<
<
CC
DB
illegal
27
illegal
Regeln
Mittels der (abgenommenen) Werte der verschiedenen Faktoren kann
man nun die Sicherheitsvorfälle je Datenbank implementieren.
Die Regeln je DB Plattform sind für alle Anwendungen identisch, nur die
Parameterwerte (z.B. $executable) variieren.
Logon mit
unbekanntem
Executable
session_state = NEW_SESSION and
not (
(application contains $executable)
or
(application contains $sysadmexecutable )
)
Architektur
Die gesamte Architektur am Projektende folgendermaßen aus.
Andere Kunden implementieren den Ansatz ohne SIEM bzw. Ticket
System.
DAM Server
SIEM
DB Monitor
DB Monitor
DB Monitor
Ticket
System
Security
Operation
Center
2
Lessons learned
¡
Wesentlich bessere Übersicht, wie eine Datenbank verwendet wird und was
Abweichungen davon sind (Wer verbindet sich wie oft auf die Datenbank)
¡
Nach einer Lernphase geringe Anzahl von kritischen Events
¡
Regelwerk erforderte nur wenige Anpassungen
¡
Notwendigkeit die Parameterwerte zu pflegen (am besten an die
entsprechende Fachabteilung auslagern)
¡
Testen der gesamten Umgebung vom Incident bis zum Ticket sehr wichtig
¡
Gute Schulung der Mitarbeiter, die die Tickets/Incidents bearbeiten
¡
¡
Ansatz ist mit unterschiedlichen Produkten (Auditing, SIEM, Ticketing,...)
implentierbar
Bei kleineren Umgebungen (bis 100 DBs) mit sehr geringem Aufwand
implementierbar
F & A?
Danke
Kontakt:
Red-Database-Security GmbH
Eibenweg 42
D-63150 Heusenstamm
Deutschland