Überprüfen von vielen Datenbanken gegen Sicherheitsrichtlinien. Alexander Kornbrust Red-Database-Security GmbH

Transkript

1 Überprüfen von vielen Datenbanken gegen Sicherheitsrichtlinien Alexander Kornbrust Red-Database-Security GmbH

2 Inhalt Einführung Typische Sicherheitsrichtlinien/Baselines Entwicklung eigener Richtlinien Tools&Werkzeuge Zusammenfassung

3 Einführung Datenbanken (und große Anwendungen wie SAP) sind sicherheitsmäßig oft in einem schlechten Zustand Schwache Passworte Default-Konfigurationen Falschkonfigurationen Zu viele Privilegien Fehlende Patches Manchmal Hintertüren Datenbanken untereinander inkonsistent (Test/ Prelive/Prod)

4 Einführung Erster Schritt bei der Lösung dieser Probleme ist die regelmäßige Überprüfung der Datenbanken Fragen Gegen welchen Standard sollte getestet werden Welche DBs sollten wie oft überprüft werden Wer ist verantwortlich Was machen bei Findings/Baseline-Verletzungen

5 Entwicklung eines Standards Meistens wird die Security Abteilung mit der Erstellung der Baseline beauftragt Start mit google (oder bing, ) Suche nach Oracle Security Baseline, Oracle Security Checklist oder Oracle Security Policy Erstellen eines eigenen Dokumentes basierend auf den gefundenen Dokumenten erweitert um Firmenspezifische Ergänzungen

6 Standard

7 Typische Security Baselines CIS Benchmark (Oracle, DB2, MySQL, MSSQL) DISA Stig (Oracle, MSSQL) SANS Score (Oracle) NSA Guide (Oracle, MSSQL) DB Vendor Security Checklist Weitere (Basel II, BSI,...)

8 CIS Benchmark Verfügbar für Oracle, DB2, MySQL, MSSQL, Sybase route=downloads.browse.category.benchmarks.ser vers.database Unterschiedliche Qualität je nach Autor/ Autorengruppe DB2/MySQL/MSSQL gut (und kurz) Oracle zu lang, z.t. falsch (basiert auf Oracle Security Step-by-Step) Lizenzen bei der Verwendung in kommerzieller SW

9 DISA Stig Verfügbar für Oracle, MSSQL index.html# Entworfen für US Behörden Normalerweise sehr lange Ausgaben Enthält Tests zum Ausführen

10 SANS Score Verfügbar für Oracle Basiert auf Oracle Security Step-by-Step

11 NSA Guide Verfügbar für Oracle, MSSQL (veraltet) oracle9i_guide.pdf Verweist inzwischen auf DISA Stig

12 DB Vendor Security Checklist Meistens in Form von Whitepapern, recht allgemein Für Ideen in Ordnung, aber sonst zu wenig Fleisch Möglichst wenig Änderungen um wenig Support- Requests zu erzeugen

13 Weitere Baselines Baselines wie Basel-II, SOX, BSI sind meistens nicht spezifisch genug. Jeder bastelt sich was zusammen Mehr ein Me-Too von SW-Herstellern als wirklicher Mehrwert

14 Problem aller Baselines Viel Papier (bigger is better) Einige Punkte oft nicht testbar (Verfügbarkeit eines Backups, Alles von Public entfernen) Viele wichtige Tests fehlen (zu Passworten, da kompliziert zu implementieren, PASSWORT=USER meistens keine Verletzung der Policy) Meistens keine Tool-Untersützung Für eine einzelne DB entworfen Keine Behandlung von Aussnahmen Erstellt von Nicht-Experten Design von Tests oft unlogisch (grant dba to public ist ein finding, grant dba to connect nicht)

15 Realität in großen Firmen/ Organisationen ,000 Datenbanken (Instanzen) Wenig Zeit der Administratoren Datenbanken Know-How fehlt in den Security Abteilungen Security Know-How fehlt in den Fachabteilungen/ Administration Viele der gefundenen Probleme erfordern die Zusammenarbeit vieler Gruppen (DBA, Fachabteilung, SW Hersteller, Security, ) Baselines widersprechen Vorgaben der 3 rd -party SW Hersteller

16 Mögliche Lösungsansatz Papier-Dokument UND Automatische Überprüfung mittels eines Werkzeuges Eigene Baseline im Tool Prozess zur Behandlung der Ausnahmen Möglichkeiten zur Risk Mitigation

17 Papier-Dokument Typische Probleme mit Baselines Eindeutige Nummerierung jedes Tests (z.b a, b,... Jeder Punkt nur 1 Test, um entscheiden zu können ob bestanden oder nicht Tests müssen implementierbar sein ( Verwendung least privilege Was ist least privilege auf Anwendung APP1? )

18 Papier-Dokument TESTKLASSEN Unsichere Konfigurationseinstellungen (z.b. UTL_FILE_DIR=*) Unsichere Privilegien (z.b. UTL_TCP an PUBLIC) (Absichtlich) schlechte Konfiguration / Hintertür (z.b. GRANT DBA TO PUBLIC) Passworte (z.b. schwache Passworte, Passworte aus Wörterbuchdatei) Fehlende Patches (z.b. letzter CPU oder PSU fehlt) Verschlüsselung OS Tests Manuelle Tests

19 Papier-Dokument Unsichere Konfigurationseinstellungen (z.b. UTL_FILE_DIR=*) Eher selten Wird in der Regel von der Anwendung gefordert Erfordert oft eine Risk Acknowledgement, da das Problem nicht gelöst werden kann

20 Papier-Dokument Unsichere Privilegien (z.b. UTL_TCP an PUBLIC) Oft default-einstellungen des DB Herstellers Betreffen (fast) alle Datenbanken Erfordern viele Änderungen und Mut des DBA und oft die Genehmigung der 3rd-party SW Firma Wird oftmals nur für neu aufgesetzt DBs gefordert.

21 Papier-Dokument (Absichtlich) schlechte Konfiguration / Hintertür (z.b. GRANT DBA TO PUBLIC) Selten, kommt aber vor Z.T. durch Fehler beim DB Hersteller entstanden Meistens einfach zu entfernen

22 Papier-Dokument Passworte (z.b. schwache Passworte, Passworte aus Wörterbuchdatei) Tests z.t. schwierig zu implementieren (erfordert z.t. Reverse Engineering) Obwohl größtes Problem, wird es in der Realität meistens nicht getestet Findings erfordern große Änderungen und ist zeitaufwendig Viele Gruppen involviert DBAs (SYS, SYSTEM,...) End-Benutzer (MSCHMITT,...) Anwendungsverantwortliche (APPS, HR, WEBUSER) Monitoring/Backup (TIVOLI, PATROL, BACKTRACK,...)

23 Papier-Dokument Fehlende Patches (z.b. letzter CPU oder PSU fehlt) Z.t. schwierig festzustellen, da die meisten SW Hersteller das Feststellen des Installierten Patches nicht sichtbar machen Aus Zeit und Zertifizierungsgründen schwierig neue Patches einzuspielen. Erfordert viele Updates an den Tests, wenn getestet werden soll, ob die aktuellen Patches installiert sind.

24 Papier-Dokument Verschlüsselung Meistens nur für Top-Security-Anwendungen Schwierig in einer Baseline zu lösen, da meistens die Architektur der Anwendung bekannt sein muss Verschlüsselung in der Datenbank (Ablage- Verschlüsselung) oft nachteilig für die Sicherheit (Interessante Daten werden markiert und Verschlüsselung meistens transparent)

25 Papier-Dokument OS Tests Abhängig von den verschiedenen Betriebssystemen Erfordern z.t. komplexe Kommandos die gut getestet werden müssen.

26 Papier-Dokument Manuelle Tests Notwendig um manuelle Checks (least privilege,...) implementieren zu können Notwendig, falls bestimmte Tests nicht implementiert werden können

27 Papier-Dokument Tests Jeder Test und das erwartete Ergebnis sollte beschrieben werden Jeder Test sollte eine Priorität/Kritikalität haben Verschiedene Tests SQL-Befehle OS-Kommandos Passworte & Co. Manuelle Tests (alles was nicht implementiert werden kann)

28 Abfragen Tests Tests sollten nach Möglichkeit de-normalisierte und reduzierte Ausgaben liefern, um Probleme leichter identifizieren zu können Die identischen Tests sollten für verschiedene Datenbanken untereinander stehen

29 Abfragen Wer hat DBA Rechte (Oracle) 1 SQL> select grantee from dba_role_privs where granted_role='dba'; MANI12 SYS ALEX_ROLE E1 DEV4 CHECK1 DIRK ADMALEX SYSTEM CREDIT RS FLOWS_020100

30 Abfragen Wer hat DBA Rechte (Oracle) 2 SQL> SELECT SUBSTR (SYS_CONNECT_BY_PATH (grantee, ';'), 2) csv FROM (SELECT distinct grantee, ROW_NUMBER () OVER (ORDER BY grantee ) rn, COUNT (*) OVER () cnt FROM (select distinct grantee from dba_role_privs where granted_role='dba') ) WHERE rn = cnt START WITH rn = 1 CONNECT BY rn = PRIOR rn + 1; ADMALEX;ALEX_ROLE;CHECK1;CREDIT;DEV4;DIRK;E1;MANI12;SYS; SYSTEM

31 Abfragen Wer hat DBA Rechte (Oracle) 3 SQL> SELECT SUBSTR (SYS_CONNECT_BY_PATH (grantee, ';'), 2) csv FROM (SELECT distinct grantee, ROW_NUMBER () OVER (ORDER BY grantee ) rn, COUNT (*) OVER () cnt FROM (select distinct grantee from dba_role_privs where granted_role='dba' and grantee not in ('SYS','SYSTEM','FLOWS_020100','CTXSYS', 'SYSMAN','BAM','ORASSO','PORTAL','WKSYS'))) WHERE rn = cnt START WITH rn = 1 CONNECT BY rn = PRIOR rn + 1; ADMALEX;ALEX_ROLE;CHECK1;CREDIT;DEV4;DIRK;E1;MANI12

32 Weitere Testansätze

33 Automatische Werkzeuge Kein DBA liest Seiten komplett durch Interesse an dem Ergebnis (Bestanden oder nicht bestanden) Einfach zu verstehender und kurzer Report Vergleich mit anderen Datenbanken Leere Ergebnisse sollten (optional) ausgeblendet werden können, um die Ausgabe-Menge zu reduzieren

34 Automatische Werkzeuge

36 Eigene Baseline Werkzeug sollte in der Lage sein, eigene Baselines zu unterstützen Baseline von viele Abteilungen Gruppen lesen lassen Erstellung und Test der Baselines sollten parallel erfolgen, um ein besseres Finetuning zu erreichen Workflow/Prozesse definieren, wie mit Verletzungen umgegangen werden soll.

37 Risk Acknowledgement (RA) Werkzeug sollte in der Lage sein Ausnahmen zu unterstützen Jede Ausnahme sollte zeitlich begrenzt sein und vom Management genehmigt sein Ausnahmen, die alle Datenbanken betreffen sollten zur Überarbeitung der Baseline oder zu einem globalen Risk Acknowledgement führen.

38 Risk Acknowledgement

42 Weitere Testansätze Privilegien-Überprüfungen lassen sich schlecht in bestehende Baselines integrieren, da diese in der Regel abhängig von der Zugrunde liegenden Anwendung ist

43 Weitere Testansätze

44 Mitigation Viele Probleme können nicht einfach/schnell gelöst werden (z.b. Passworte) Datenbank-Trigger oder Database Activity Monitoring (DAM) kann das Risiko (z.t. erheblich) reduzieren. Mitigation muss je Datenbank/Anwendung erfolgen und ist zeitaufwendig

45 Zusammenfassung Überprüfen der Datenbanken hilft bei der Erhöhung der Sicherheit in Unternehmen. Status Quo feststellen Maßnahmen definieren (Weiterbildung, SW/Härten, regelmäßige Tests..) Maßnahmen durchführen Die überwiegende Mehrheit (>95%) der DB Kunden verwenden schwache/unsichere Konfigurationen

46 Thank you Contact: Red-Database-Security GmbH Bliesstr. 16 D Neunkirchen Germany