Security Konzept, nur auf dem Papier - doag.org · Übergreifendes Security Konzept - Database Security ist zu wenig Schutz über alle Layer - Z.B. auf Protokoll- und Datenbank-Ebene

|

Existiert Ihr Security Konzept auch nur auf dem Papier? Warum werden viele Security Konzepte nur unzureichend umgesetzt?

Ralph Baumbach

Hamburg, den 17.09.2014

|

Security Konzept, nur auf dem Papier?

Präsentationstitel 2

  Ausgangssituation

  Beispiele aus dem Feld   Die Schublade

  Die Potemkinschen Dörfer

  Das Aushöhlen

  Ursachen   Der Hundert Prozent Anspruch

  Die Verallgemeinerung

  Fehlende Akzeptanz

  Das Ziel ist nicht bekannt

  Lösungsansätze

  Methodik

|



Sicherheit, ein typisches Beispiel

|


 Sicherheit ist immer mit Beschränkung/Einschränkung verbunden

 Diese Beschränkungen werden, wenn möglich, umgangen

=> Maßnahmen, um Umgehen zu verhindern, sind erforderlich, Wirksamkeit überwachten

 Oft gestellte Forderung:

Sicherheit ja, aber Prozeß/Ablauf darf nicht beeinflußt werden

IST UNREALISTISCH

Abwägung von Sicherheit zu Benutzerfreundlichkeit und Administrierbarkeit


Ausgangssituation

|



Das Anforderungs-Triangle

|


Auf der einen Seite:

 Risikobewertung

-   Wie wahrscheinlich ist es, das ein Schaden entsteht

-   Wie hoch ist der mögliche Schaden

Auf der anderen Seite:

 Nutzenbewertung

-   Wie wahrscheinlich kann der Schaden vermieden werden

-   Aufwand

-   Kosten

Kein Return of Investment ROI


Kosten / Nutzen Abwägung

|


Sicherheit in Bezug auf:

•   Vertraulichkeit

•   Integrität

•   Verfügbarkeit

•   Nachvollziehbarkeit

Daten bez. Vertraulichkeit können in vier Stufen eingeteilt werden:

•   Öffentlich

•   Nur für den internen Gebrauch

•   Geheim (Daten sind vertraulich zu behandeln)

•   Streng Geheim


Mögliche Security Kategorien

|


 Das keine Security Konzepte vorhanden sind, ist nur selten anzutreffen

 Wohl aber viele Konzepte, die nicht oder nur unzureichend umgesetzt wurden

Security Konzept Mapping:

 Vergleich des existierenden Security Konzeptes mit der Realität (Mapping)


Security Konzepte. Anspruch und Wirklichkeit

|


Ein Security Konzept Mapping Beispiel:


Beispiel: Die Schublade

Init.ora /Spfile Parameter Empfehlung Anmerkungen DB1 DB2 DB3

_TRACE_FILES_PUBLIC FALSE

Trace Files enthalten unter anderem auch sensitive Daten (Werte aus Tabellen). Ein Zugriff für alle sollte daher unterbunden

werden.

FALSE TRUE TRUE

REMOTE_OS_AUTHENT FALSE

Eine Authentifizierung durch das Betriebsystem kann leicht gefälscht werden und sollte daher nicht genutzt werden. Anders sieht das aus, wenn ein zentrales Authenifizierungssystem zum

Einsatz kommt.

TRUE TRUE TRUE

REMOTE_OS_ROLES FALSE Dito TRUE TRUE TRUE

AUDIT_TRAIL OS, DB oder DB_extended

Hier ist OS in Verbindung mit Syslog vorzuzuiehen NONE NONE NONE

OS_AUTHENT_PREFIX Null Für REMOTE_OS_AUTHENT, sollte nicht verwendet werden. OS$ OS$ OS$

OS_ROLES FALSE Dito TRUE TRUE TRUE

UTL_FILE_DIR „ „ Ein alter Mechanismus um auf Files zugreifen zu können. „/u01/app/

oracle/data „“ „*“

SQL92_SECURITY TRUE Erhöhte Sicherheit durch SQL 92 Standard TRUE TRUE TRUE

O7_DICTIONARY_ACCESIBILITY FALSE

Dictionary Zugriffe nach Oracle 7 sind unsicher und sollten daher nicht genutzt werden

FALSE TRUE FALSE

AUDIT_SYS_OPERATIONS TRUE Auditierung aller Operationen des Users SYS NONE NONE TRUE

!

|


Wahrscheinlich: Konzept wurde durch eine einzelne Fachabteilung erstellt

 Security ohne Sponsoring durch das Management

-   Mehr als nur die allgemeine Aussage: “Wir wollen Security”

 Keine Kommunikation mit den anderen Fachbereichen (Stakeholder)

 Keine Bereitschaft Kosten und Aufwände aufzubringen

 Keine Kompromissbereitschaft

 Management muss dahinter stehen

 Alle Seiten müssen an dem gleichen Strang ziehen


Ursache: Fehlende Akzeptanz

|


Beispiel 1: Während eines Audits:

 Auditor “überprüft” die Nutzung personalisierter Accounts

 Währenddessen führt ein DBA ein “connect / as sysdba” aus

Nachvollzierbarkeit der Anmeldung durch zusätzliche Daten, z.B. OS-Account

 Anmeldungsprozess über mehrere Hubs

 Cron-Jobs, Background Prozesse


Beispiel: Die Potemkinschen Dörfer

|


Beispiel 2: Auditierung ist “eingeschaltet”:

 Audit Records sind ungeschützt (nicht manipulationssicher)

 Audit Records werden zeitnah gelöscht (“Audit nach /dev/null”)

 Datenfriedhof der Audit Records



|


Oft zu beobachten:

 Oberste (“einzige”) Priorität:

-   Audits zu bestehen und

-   die Einhaltung von Compliance Regulatorien und

-   Gesetze nachzuweisen

führt oft zu Scheinsicherheit.

 Sicherheit wird abgehakt

 Ampel wird (für das Management) auf grün gestellt



|


Wahrscheinlich: Security Vorgaben durch eine zentralen Stabssstelle (“aus dem “Elfenbeinturm”)

 Alle möglichen Gefährdungen werden ungewichtet berücksichtigt

 Keine Berücksichtigung der Gegebenheiten

 Keine Kommunikation mit den Fachbereichen

 Kompromisslose Vorgaben / keine Ausnahmen

 Security Vorgaben berücksichtigen das spezielle Gefährdungspotential nur unzureichend

 Firmen sind oft Audit getrieben


Ursache: Der Hundert Prozent Anspruch

|


 Compliance Regularien / Audits

-   Checklisten; Security wird abgehakt (“… ist erledigt!”)

-   Papier ist wichtiger als Umsetzung: “Security by paper”

-   Für Management “steht die Ampel auf Grün”

 Für das Management ist Security gelöst, warum also weiter investieren?

 Security Vorgaben sind teilweise kontraproduktiv


Ursache: Die Verallgemeinerung

|


 Security Vorgaben durch zentrale Stelle

-   Aus Gefahrenpotentiale werden Forderungen/Maßnahmen abgeleitet

-   Maßnahmen werden umgesetzt ohne das dahinter liegende Teilziel zu kennen oder zu berücksichtigen

 Compliance Regularien / Audits

-   Checklisten werden abgehakt, ohne den “Sinn” der geforderten Maßnahme in Frage zu stellen

-   “Security by paper”, Papier ist das Ziel

=> Security Maßnahmen, Maßnahmen ohne das Ziel zu kennen


Ursache: Das Ziel ist nicht bekannt

|


Beispiel 1:

 Bessere Sicherheit durch das Einführen von Database Vault

-   Unterstützt Separation of Duty (SoD)

-   Bietet Factor Based Access Control (FBAC)

Nutzung durch den Kunden:

 Keine Sicherheitsregeln definiert, da keine Sicherheits-Administration

=> Nur Role Based Access Control (RBAC), kein FBAC

 Account Management durch die DBAs

=> Kein SoD

  Technische Accounts werden von Mitarbeitern genutzt


Beispiel: Das Aushöhlen

|


Beispiel 2:

 SYS Passwort für Platinum Service

Es werden Rechte gefordert, die nicht notwendig sind

“Der Weg um die Schranke herum ist schneller, als die Schranke zu öffnen”


Beispiel: Das Aushöhlen

|


Sicherheitsregeln werden durch viele Ausnahmen praktisch unwirksam

 Business- oder Applikationsanforderungen

-   Pauschale Aussagen

-   Unüberprüft / nicht hinterfragt

 Ausnahmen sind zeitlich nicht begrenzt

 Ausnahmen gelten auch für Systeme, für die gar nicht die Notwendigkeit einer Ausnahme besteht

 “Der Weg um die Schranke herum ist einfacher”



|


 Security ohne Sponsoring durch das Management

-   Mehr als nur die allgemeine Aussage: “Wir wollen Security”

 Keine Kommunikation mit den anderen Fachbereichen (Stakeholder)

 Keine Bereitschaft Kosten und Aufwände aufzubringen

 Keine Kompromissbereitschaft

=> Alle Seiten müssen an dem gleichen Strang ziehen



|


 Härtung von Datenbanksystemen (Datenbankparameter)

  Trennung der Zuständigkeiten („Separation of Duties“)

 Authentifizierung, ggf. Kopplung mit bestehenden Infrastrukturen (z.B. „Single-Sign-On“)

 Autorisierung (Berechtigungen, Rollen, dedizierte Privilegien)

  Zugriffskontrolle (Berechtigung auf Objekte wie z.B. Tabellen)

 Verschlüsselung (Netzwerk, Datensatz, Export-Dump, Backup und File)

 Anonymisierung von sensitiven Informationen

 Auditierung für Reporting und Dokumentation der Aktivitäten

 Rückverfolgbarkeit und Wiederherstellbarkeit historischer Daten („Wie war ein bestimmter Wert vor einem Jahr?“)

 Schutz gegen „Einschleusen“ unerwünschter Codes (SQL-Injection)


Security Maßnahmen

|


“Gib mir mal dein Account”

 Rechte passen nicht zu den Business Funktionen

-   Keine klare Rollen definiert (Business-Rollen => Technische Rollen)

-   Änderungen dauern zu lange

 Rechteakkumulierung

-   “Der Praktikant hat alle Rechte”

  Technische Accouts

-   Passwörter bekannt / werden nicht geändert

-   Viele Privilegien

 Objektowner

-   Wird für die Administration missbraucht


Separation of Duty

|


Was ist erforderlich?

 Rechte passen nicht zu den Business Funktionen

-   Klare Aufgaben und Zuständigkeiten

-   Einfaches Account-Management

 Rechteakumulierung

-   Einfaches Rollen-Management

  Technische Accouts

-   Strikte Trennung von Technischen Accounts und Mitarbeiter-Accounts

-   Technische Accounts sind beschränkt auf den speziellen Einsatzbereich

 Objektowner

-   Ein Account nur für die Business-Objekte


Separation of Duty

|


Funktions-Rollen rund um die Datenbanken

 Datenbank Administration

 Account Management (User Provisionierung)

 Security-Management

 Applikationsbetreuung (“Applikations-DBAs”)

 Applikations-Objekt-Eigentümer

 Applikationsuser (Endanwender oder Shared Pool Account)

 Server Administration

 Storage Management

 Backup Management


Separation of Duty

|



Beispiel:Account Profile in Oracle Datenbanken

|



Beispiel:Account Profile in Oracle Datenbanken

|


Hindernisse:

 Unklare Aufgabenteilung

-   Funktionen nicht klar beschrieben

-   Nicht klar, welche Funktionen getrennt werden müssen

  Fürstentümer

-   Aufgaben werden nicht ohne Widerstand abgegeben

 Anforderungen ändern sich schnell

-   Z.B. Virtualisierung (PDBs)


Separation of Duty

|


Bedeutende Hindernisse für die Umsetzung der Security Konzepte:

 Anpassung der Organisation an den aktuellen Bedürfnissen

 Account und Rechte-Management

 Auditierung und Logging

 Erweiterte Zugriffskontrolle


Herausforderungen

|


  Vorhandene LDAP oder AD Struktur kann für Oracle Datenbank Anmeldung genutzt werden.

  EUS ist limitiert auf Datenbankbenutzer.

  Die endgültigen Rechte eines Benutzers setzten sich zusammen aus seinen individuellen Rechten auf und den allgemeinen Rechten des Schemas, gegen das er jeweils gemappt wird. Dies erschwert die Verwaltung

  Das für EUS notwendige LDAP Verzeichnis muss hochverfügbar aufgebaut sein, um Ausfälle bei Datenbankanmeldungen auszuschließen.

  Audits und Reports über Datenbankbenutzer sind nicht „out-of-the-box“ in EUS enthalten.

  Temporäre Zugriffsrechte, Genehmigungsworkflows, etc. sind nicht Teil von EUS.


Oracle Enterprise User Security EUS

|


  OIM provisioniert sowohl Datenbankbenutzer als auch Applikationsbenutzer.

  Benutzer erhalten nur die Datenbank- und OS-rollen, die ihnen über ein unternehmensweiten Businessrollenschema zugewiesen wurden.

  Rollen und Rechte werden über entsprechende teilweise mehrstufige Genehmigungsworkflows erteilt.

  OIM muss nicht hochverfügbar sein, da es nicht für Datenbankanmeldungen genutzt wird.

  OIM verfügt über integrierte Audits und Reports über Datenbankbenutzer. Ein „Wer hat(te) was, wann, in welcher Datenbankinstanz?“-Report kann „out-of-the-box“ angezeigt werden.

  OIM bietet die Möglichkeit Compliance-Vorschriften über Beglaubigungsvorgänge von Datenbankbenutzer einzuhalten.

  OIM unterstützt Reconciliation (Abgleich) von Datenbankfeldern pro Benutzer wie Login, Tablespace, Profil oder Rolle.

  Self-Service und Passwort Management für Datenbank und andere Applikationen


Oracle Identity Manager OIM

|


 Reconciliation (Abgleich) von Datenbanken

 Reporte für operative und historische Daten

 Mit Stored Procedures erweiterbar

 Eigene angepasste Compliance Reports

  Nachvollziehbare Beglaubigungsvorgänge (Approval-Prozesse)


Reporting durch den Oracle Identity Manager OIM

|


Berechtigungsvergabe in der Applikation ist grundsätzlich sinnvoll

  kann aber mit direktem Zugriff auf die Datenbank umgangen werden, wie z.B. sqlplus Zugriffe

 Gerade Berechtigungskontrolle durch die Applikation erfordert oft hochprivilegierte Datenbank-Accounts

  Technische Accounts werden oft von Mitarbeitern für administrative Tätigkeiten genutzt

 Administrative Tätigkeiten mit dem Account des Object-Owners

 Unkontrollierte Zugriffe mit hochprivilegierten Accounts

 Daher Schutzmaßnahmen ergreifen (z.B. Vulnerability Scanner)


Applikations Design Security

|


“Da schalten wir mal das Audit der Datenbank ein”

 Was Auditieren? Wie? (Oracle internes Auditing vs. Third Party Systeme)

 Speicherung

  Zentralisierung, Anbindung an Third Party System

 Sicherheit der Audit Daten

 Aggregierung

 Reports

 Warehouse Prozesse

 Daten anderer Quellen (Enrichment)

 Archivierung

 Housekeeping


Audit

|


 Übergreifendes Security Konzept

-   Database Security ist zu wenig

 Schutz über alle Layer

-   Z.B. auf Protokoll- und Datenbank-Ebene

 Auditierung und Logging der wichtigen Ereignisse

-   Sichtbarkeit der Vorkommnisse inc. Alarmierung

 Schutz gegen unberechtigten Zugriff in Echtzeit

 Reporting und Assessment der Regelverstöße

 Datenklassifizierung

 Management von Berechtigungen und Konfigurationen


Security Konzepte, was ist erforderlich?

|



Allgemeine Security Richtlinien

|


 Security ist kein Produkt

 Das primäre Ziel sollte definiert werden

 Es gibt keine hundertprozentige Sicherheit

 Abwägen von Aufwand und Nutzen (Bedarfsanalyse, Risikobewertung)

  Zielerreichung sollte messbar sein

 Kein Return-of-Investment für Security berechenbar

 Ein fortlaufender Prozess ist erforderlich “Stillstand ist Rückschritt”


Lösungsansätze

|


 Management und alle Beteiligten (Stakeholder) einholen

-   Akzeptanz

-   Bereitschaft mitzuarbeiten

-   Bereitschaft Veränderungen mitzutragen

 Primärziel definieren

 Randbedingungen klären

-   Organisatorisch

-   Technisch

 Risiko- und Datenmanagement

  Zwischenziele und Anschlussprojekte definieren


Methodik

|


 Datenmanagement und Klassifizierung

-   Wo entstehen die Daten und wer sind die Eigentümer?

-   Wo und wie werden diese genutzt?

-   Klassifikation nach Vertraulichkeit, Integrität und Verfügbarkeit

 Risikobewertungen

-   Einfaches Punktesystem

-   Common Vulnerability Scoring System (CVSS) Ansatz

 Module: Lösungsansätze, die bei entsprechenem Gefährdungspotential angewendet werden können

 Alternativ-Lösungen

 Ergebnisdarstellung


Methodik

|



NIST Common Vulnerability Scoring System (CVSS) Calculator

|


Ergebnisdarstellung:

 Keine Ampeln

 Balkenfortschrittsdiagramm

 Scorecard

 Netzdiagramm


Methodik

| | Präsentationstitel 41

Fragen?

|

Vielen Dank. MT AG

Balcke-Dürr-Allee 9 40882 Ratingen

Telefon: +49 (0) 21 02 309 61-0 Telefax: +49 (0) 21 02 309 61-10

E-Mail: [email protected]

www.mt-ag.com

Documents

Security Konzept, nur auf dem Papier - doag.org · Übergreifendes Security Konzept - Database Security ist zu wenig Schutz über alle Layer - Z.B. auf Protokoll- und Datenbank-Ebene