Individuelles Auditing von vielen Datenbanken

Transkript

1 Individuelles Auditing von vielen Datenbanken

2 Agenda Einführung Audit-Ansätze Sicherheitsvorfälle Spinnennetz Lessons Learned

3 Einführung Im Zuge eines großen Auditing-Projektes stellte sich die Frage: Wie auditiere ich sinnvoll Datenbanken (Instanzen) verschiedener Hersteller?

4 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

5 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

6 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 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

7 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

8 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-party- Lösung.

9 Grundlagen

10 DB-Logon Es gibt in der Regel unterschiedlichste Arten von Zugriffen (z.t. 30+) auf eine Datenbank

11 DB-Logon Es gibt in der Regel unterschiedlichste Arten von Zugriffen (z.t. 30+) auf eine Datenbank Wie erkennt man den verdächtigen Zugriff?

12 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.

13 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.

14 Beispiel Detection (Objects)

15 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.

16 Sicherheitsvorfälle (Auszug) Die Sicherheitsvorfälle werden mit dem Kunden definiert und entsprechend als Audit-Regel umgesetzt.

17 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.

18 Spinnennetz Action (Logon, CC Select,...) 18

19 Spinnennetz Action (Logon, <CC Select,...) Unbekannter DBUser 19

20 Spinnennetz Action (Logon, Z<< <CC Select,...) Unbekannter DBUser 20

21 Spinnennetz <<<<<<<<<<<<<<<<<<<<<<< Action (Logon, <<<<<<<<<<<<<<<<<<<<<<< Z<< <CC Select, <<<<<<<<<<<<<<<<<<...) Unbekannter DBUser 21

22 Spinnennetz Alle 8 (=2^3) Zugriffswege sind definiert <<<<<<<<<<<<<<<<<<<<<<< Action (Logon, <<<<<<<<<<<<<<<<<<<<<<< Z<< <CC Select, <<<<<<<<<<<<<<<<<<...) Unbekannter DBUser 22

23 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

24 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

25 Login unbekannter DB Benutzer Regulär Kein Log Login CC < illegal 25

26 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

27 Export Datenbank rest illegal Export Z<< <CC DB illegal illegal 27

28 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 ) )

29 Architektur Die gesamte Architektur am Projektende folgendermaßen aus. Andere Kunden implementieren den Ansatz ohne SIEM bzw. Ticket System. DB Monitor DAM Server DB Monitor DB Monitor SIEM Ticket System 2 Security Operation Center

30 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

31 F & A?

32 Danke Kontakt: Red-Database-Security GmbH Eibenweg 42 D Heusenstamm Deutschland