Auditing und Compliance Patrick Schwanke Senior Presales Consultant Quest Software GmbH

Agenda Quest Software Compliance / Auditing Techniken und Lösungen Was ist das ? Wer braucht das ? Techniken und Lösungen Verschlüsselung Gewaltenteilung („Separation of duties“) Auditing Projektbeispiel

Quest Software Wir helfen bei Bereitstellung, Verwaltung und Überwachung komplexer Anwendungsumgebungen. Quest-Produkte durchleuchten Anwendungen von der Datenbank bis zum End User. Mit marktführenden Produkten für die Datenbankverwaltung steigern wir die Produktivität von DBAs und Entwicklern sowie die Performance Ihrer Datenbanken. Wir vereinfachen, automatisieren und sichern Ihre Windows-Infrastruktur mit umfassenden Funktionen für Migration & Management und integrieren Unix, Linux sowie Java in die verwaltete Umgebung.

Quest Software Kontinuierliches Wachstum Bei Analysten Nr. 1 476 Mio $ Umsatz 2005 Nasdaq: QSFT über 2.800 Beschäftigte Kunden über 18.000 weltweit 75 % der Fortune 500 Bei Analysten Nr. 1 Mio USD Application Management Software Gartner Dataquest, 2005 Distributed Database Management Facilities Software IDC, 2005 Starke Branchenpartner Windows Server Management Forrester Research, 2004 Der Erfolg unserer Geschäftsstrategie lässt sich leicht an unserem kontinuierlichen Wachstumstrend ablesen. Unser Unternehmen ist solide aufgestellt, zukunftsorientiert und global ausgerichtet. Unsere Aufgabe ist es, Sie zu unterstützen. Branchenanalysten räumen unseren Lösungen eine führende Marktstellung ein. Darüber hinaus unterhalten wir Partnerschaften mit den Unternehmen, die Ihre strategischen Plattformen bereitstellen und damit arbeiten. [KLICKEN]

Warum Compliance ? Gesetzliche Vorgaben, z.B. Basel II Sarbanes-Oxley Branchenbezogene Regelungen / Haftungsfragen, z.B. PCI DSS (Payment Card Industry Data Security Standard) GMP (Good Manufacturing Practices) Annex 11 Interne Anforderungen Schutz sensibler Daten: Geschäftsergebnisse, Gehaltsdaten, … Zertifizierungen Wettbewerbsvorteile IT-Risiken erkennen (Awareness) / bewerten „Passende“ Kontroll-Mechanismen einrichten

Beispiel – PCI DSS Payment Card Industry Data Security Standard einheitlicher, globaler Prüfungsstandard MasterCard & Visa Schutz von Kreditkartendaten Betrifft alle, die Kartendaten auf eigenen Systemen speichern, verarbeiten oder weiterleiten Wer haftet ? Händler/PSP oder Kreditkarten-Organisation Acquirer sind VERPFLICHTET, alle Händler und PSPs inkl. Zertifizierungsstatus zu registrieren Zertifizierungspartner

Beispiel – BSI IT-Grundschutz Maßnahmenkatalog (Ausschnitt): M 4.67 Sperren und Löschen nicht benötigter Datenbank-Accounts M 4.68 Sicherstellung einer konsistenten Datenbankverwaltung M 4.69 Regelmäßiger Sicherheitscheck der Datenbank M 4.70 Durchführung einer Datenbanküberwachung M 4.71 Restriktive Handhabung von Datenbank-Links M 4.72 Datenbank-Verschlüsselung M 4.73 Festlegung von Obergrenzen für selektierbare Datensätze M 4.* Audit und Protokollierung auf diversen Ebenen Quelle: http://www.bsi.de/gshb/deutsch/m/m04.htm

Transparent Data Encryption Verschlüsselung „ruhender“ Daten Datafiles, Redo-/Archivelogs, Backups  Media Protection Transparent für Anwendung Ver-/Entschlüsselung automatisch via SQLNet Auch für „normale“ Datentypen: VARCHAR2, CHAR etc. Auf Spaltenebene sensible Daten, die nicht im Klartext in Datendateien / Backups stehen sollen Kreditkartendaten, medizinische Daten, Versicherungsdaten … Voraussetzung: Oracle 10gR2 EE Inkl. Advanced Security Option

Transparent Data Encryption ALTER TABLE karte MODIFY (inhaber ENCRYPT) Erzeugen eines Random-Key k Öffnen des Wallets, Auslesen des Master-Keys Verschlüsseln von k mit Master Key  k* Speichern von k* im Data Dictionary sys.enc$ dba_encrypted_columns Tabelle KARTE kid inhaber datum 1000 <<crypt>> 14.11.2006 1001 15.11.2006 Wallet Master Key k sys.enc$ Inhaber Klartext

TDE Schlüsselverwaltung Schlüsselverwaltung automatisch durch Oracle verschlüsseltes „Wallet File“: ewallet.p12 sqlnet.ora Parameter: ENCRYPTION_WALLET_LOCATION Default: $ORACLE_BASE/admin/$ORACLE_SID/wallet ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY “mymasterkey“; ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY “mymasterkey“; Nach Öffnen der Datenbank ! Datafiles + Wallet-File + Master-Key = DATEN Never lose your wallet !

Database Vault Schutz gegen Separation of Duties (Gewaltenteilung) Unauthorisierten Zugriff auf Daten (lesend + schreibend) Insider-Threats Separation of Duties (Gewaltenteilung) Datenbank-Administration Daten-Administration "Fine-grained access control" "Realms" = geschützte Bereiche (Schemaobjekte) Schutz vor Benutzern mit DBA- oder ANY-Privileges Anwendungstabellen (sensible oder alle) Einige vordefinierte Realms (Data Dictionary, OEM, DV)

Database Vault Neubewertung von Systemprivilegien (ANY-Privs) Damit auch betroffen: DBA-Rolle, User SYSTEM etc. Neue geschützte Rollen, u.a. DV_ACCTMGR: Benutzer/Profile verwalten DV_REALM_OWNER Schaltet ANY-Privilegien innerhalb zugeordneter Realms frei DV_REALM_RESOURCE RESOURCE-Rolle + CREATE SYNONYM/VIEW Für zugeordneten Realm Z.B. für Anwendungs-Owner mit EINEM Schema DV_ADMIN: DV Administration (z.B. Realms-Verwaltung)

Database Vault installieren Voraussetzung 10gR2 EE mit Patchset 1 (10.2.0.2) mit Oracle Label Security Option installiert OEM Database Control 10.2.0.2 Instanz runterfahren DB Vault installieren (OUI) Auswahl Oracle Home Auswahl EINER (!) Datenbank Für RAC: Konfiguration der anderen Instanzen (DVCA) SYSDBA-Login wieder enablen orapwd ... nosysdba=N Andere Datenbanken konfigurieren (DVCA)

Database Vault Verwaltung: Package: dvsys.dbms_macadm OEM Database Control: http://<host>:<port>/dva

Auditing (Beispiel PCI DSS)

Auditing Was soll wie überwacht werden? Qualifizierung der Systeme Risiko / Daten / Benutzer Was / wieviel soll aufgezeichnet werden? Lückenlos 24x7, aber keine Datenfriedhöfe! Alle ungewöhnlichen / unerwarteten Zugriffe und Zugriffsversuche Wer kümmert sich um Alerts / Incidents? Alerting / Incident Management Anbindung an Ticketing- oder Monitoring-Software Regelmäßige / Ad-hoc Reports Skaliert das Ganze? Menge der Audit-Daten, Archivierung, Audit Data Lifecycle Was passiert wenn neue Systeme hinzukommen? Wieviel Overhead entsteht durch die Überwachung?

Oracle Audit Vault Gemeinsames Repository für vorhandene Audit-Trails OS Audit-Log: normale Audit Log-Datei DB Audit-Log: sys.aud$, sys.fga_log$ Redo Logs (Mining, Übertragung an Audit Vault via Streams) diverse weitere Audit-Logs (Apache, OS etc.) Kollektor-Agent Liest Standard Audit-Trail oder Redo-Logs aus Kein neuer Audit-Mechanismus! Vorkonfigurierte, gehärtete Repository-DB Partitioning  Performance / Information Lifecycle Mgmt Database Vault  Zugriffskontrolle GA angekündigt für Ende Q1/2007

Oracle Audit Vault Viele Komponenten Basiert auf Standard Audit-Trails Audit Trail (Tabelle oder File), Collector, Agent, Streams Hohe Komplexität Basiert auf Standard Audit-Trails Manipulierbar durch Privileged Users (NOAUDIT, DBMS_FGA) Redo-Logs nur bedingt als Audit-Trail geeignet Keine Datenabfragen sichtbar Keine NOLOGGING DMLs sichtbar Kein Workflow SNMP-Alerting, Ticketing-Systeme

InTrust for Databases Vollständigkeit Verifizierbarkeit Zugriffe und Zugriffsversuche Lesende und schreibende Zugriffe (SELECT, DML, DDL) Indirekte Zugriffe (Prozeduren, Trigger, Scheduled Jobs) Lokale Sessions (ohne Netzwerk-Verbindung) Werte von Bindevariablen welche Daten wurden abgefragt ? welche Werte wurden geschrieben ? Verifizierbarkeit Schutz gegen Manipulation der Audit-Daten Auf dem überwachten System Im Audit-Repository Erkennung von Blackouts Audit-Agent läuft nicht (z.B. kill -9) oder deinstalliert

InTrust for Databases Audit Management Server / Repository Auswertung der Policies Aufzeichnen aller Zugriffe / Zugriffsversuche Gefiltert entsprechend den gesetzten Policies Generieren und Aufzeichnen von Incidents / Alerts / Tickets Gehärtete Datenbank Verschlüsselt klare Rechtestruktur (Gewaltenteilung) mit integriertem Lifecycle Management für Audit-Daten Aufbewahrungsfristen, automatische Archivierung / Purging Partitionierung auf Tagesbasis

InTrust for Databases – Architektur Repository Auswertung, Reports Audit Mgmt Server Administration Alerts Audit-Daten / Heartbeat Überwachte Datenbanken

InTrust for Databases Kategorien („Profile“) Policies Policy-Gruppen Systeme, Daten, Benutzer Einfache Skalierbarkeit Policies Einfache Erstellung mit Policy-Builder Policy-Gruppen Entsprechen fachlichen / regulatorischen Auditing-Vorgaben, z.B. Payment Card Data Policies Finance Department Policies HR Department Policies SOX Policies Übersichtliche Zusammenstellung via Dashboard Speicherung im Audit-Repository Versions-, Change- und Deployment-Kontrolle

InTrust for Databases – Policy Dashboard Policy- Gruppen

InTrust for Databases Incident = Verletzung einer Policy, z.B. Alert Zugriff auf sensible Daten und es war nicht die Applikation DDL-Kommando auf produktivem System Fehlgeschlagener Login-Versuch Fehlgeschlagener Lese- oder Schreibversuch Alert z.B. 5 Login-Versuche innerhalb 1 Minute Ticket erzeugen Priorität zuweisen Ticket Workflow, Ownership Interne Behandlung (Ticket Dashboard) Externe Behandlung (Mail oder XML-File)

InTrust for Databases – Ticket Dashboard

Praxisbericht am Beispiel PCI DSS

Praxisbeispiel (Auditing-Projekt) 10.2 Implement automated audit trails for all system components to reconstruct the following events: 10.2.1 All individual user accesses to cardholder data Object policies for a given positive or negative list of clients, applications or users 10.2.2 All actions taken by any individual with root or administrative privileges Out-of-the-box with “Privileged Session” policy. Alternatively: custom policy with a specific list of DB users 10.2.3 Access to all audit trails Auditing of the audit repository itself. I.e., monitoring all access to tables in the INTRUSTDB schema in the Intrust repository database. Standard object policy. 10.2.4 Invalid logical access attempts Out-of-the-box with the “Failed Data Access” policy. 10.2 5 Use of identification and authentication mechanisms Out-of-the-box with the “Failed Login” policy (invalid logins only) or with the “Connection Auditing” policy (invalid plus valid logins) 10.2.6 Initialization of the audit logs Out-of-the-box each purging of the audit log is logged in the repository 10.2.7 Creation and deletion of system-level objects Not possible in IDBv1 as we cannot browse or filter by affected table. This will be possible in IDBv2

Praxisbeispiel (Auditing-Projekt) 10.3 Record at least the following audit trail entries for all system components for each event: 10.3.1 User identification Client IP, client application, OS User and DB user is recorded 10.3.2 Type of event Type of event (“Unauthorized Connection”, “Privileged Session”, “Failed Login”, “Failed Data Access”, “Object Audit” or “SQL Error” is recorded. For “Object Audit”, the name of the affected object audit policy is also recorded 10.3.3 Date and time Event start time is recorded as well as the duration for Connection events 10.3.4 Success or failure indication Is recorded. 10.3.5 Origination of event Affected instance, client IP, OS user and client application is recorded. 10.3.6 Identity or name of affected data, system component, or resource Not possible in IDBv1 as we cannot browse or filter by affected table. This will be possible in IDBv2. As an approximate workaround, the executed SQL can be viewed and used for filtering

Praxisbeispiel (Auditing-Projekt) 10.5 Secure audit trails so they cannot be altered No audit data is written on the audit machine. Only the repository has to be secured. In IDBv1 there is no out-of-the-box solution for this. In IDBv2 we will deliver a hardened repository database out-of-the-box. 10.5.1 Limit viewing of audit trails to those with a job-related need [In IDBv1 there are separate roles for administering IDB and working with security events (assigning, investigating and approving roles) . In IDBv2 there will also be separate roles for administering policies (“policy role”) and for viewing audit data/tickets (“ticket reader role”). 10.5.2 Protect audit trail files from unauthorized modifications [See 10.5] 10.5.3 Promptly back-up audit trail files to a centralized log server or media that is difficult to alter 10.5.4 Copy logs for wireless networks onto a log server on the internal LAN. 10.5.5 Use file integrity monitoring and change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

Praxisbeispiel (Auditing-Projekt) 10.4 Synchronize all critical system clocks and times. This is already the case. 10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). Note: Log harvesting, parsing, and alerting tools may be used to achieve compliance with Requirement 10.6. 10.7 Retain audit trail history for at least one year, with a minimum of three months online availability. In IDBv1 automatic purging of audit data can be scheduled out-of-the-box. In IDBv2 there will be an integrated Information Lifecycle Management which out-of-the-box partitions the audit data on a daily basis. So a rolling window scenario can be established with minimal performance impact.

Resumee Verschlüsselung Gewaltenteilung Auditing Schutz sensibler Daten Ruhende Daten: TDE, DBMS_CRYPTO Bewegte Daten: NDE (Network Data Encryption) Gewaltenteilung Schutz gegen Insider Database Vault Auditing Sicherheitslücken erkennen Policies überwachen Standard / Fine-Grained Auditing Audit Vault (GA 2007) InTrust for Databases (Quest Software)

Fragen ?

Vielen Dank !