Post on 05-Aug-2019
|
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
|
Security Konzept, nur auf dem Papier?
Präsentationstitel 3
Sicherheit, ein typisches Beispiel
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 4
Ausgangssituation
|
Security Konzept, nur auf dem Papier?
Präsentationstitel 5
Das Anforderungs-Triangle
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 6
Kosten / Nutzen Abwägung
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 7
Mögliche Security Kategorien
|
Security Konzept, nur auf dem Papier?
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)
Präsentationstitel 8
Security Konzepte. Anspruch und Wirklichkeit
|
Security Konzept, nur auf dem Papier?
Ein Security Konzept Mapping Beispiel:
Präsentationstitel 9
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
!
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 10
Ursache: Fehlende Akzeptanz
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 11
Beispiel: Die Potemkinschen Dörfer
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 12
Beispiel: Die Potemkinschen Dörfer
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 13
Beispiel: Die Potemkinschen Dörfer
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 14
Ursache: Der Hundert Prozent Anspruch
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 15
Ursache: Die Verallgemeinerung
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 16
Ursache: Das Ziel ist nicht bekannt
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 17
Beispiel: Das Aushöhlen
|
Security Konzept, nur auf dem Papier?
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”
Präsentationstitel 18
Beispiel: Das Aushöhlen
|
Security Konzept, nur auf dem Papier?
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”
Präsentationstitel 19
Ursache: Fehlende Akzeptanz
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 20
Ursache: Fehlende Akzeptanz
|
Security Konzept, nur auf dem Papier?
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)
Präsentationstitel 21
Security Maßnahmen
|
Security Konzept, nur auf dem Papier?
“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
Präsentationstitel 22
Separation of Duty
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 23
Separation of Duty
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 24
Separation of Duty
|
Security Konzept, nur auf dem Papier?
Präsentationstitel 25
Beispiel:Account Profile in Oracle Datenbanken
|
Security Konzept, nur auf dem Papier?
Präsentationstitel 26
Beispiel:Account Profile in Oracle Datenbanken
|
Security Konzept, nur auf dem Papier?
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)
Präsentationstitel 27
Separation of Duty
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 28
Herausforderungen
|
Security Konzept, nur auf dem Papier?
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.
Präsentationstitel 29
Oracle Enterprise User Security EUS
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 30
Oracle Identity Manager OIM
|
Security Konzept, nur auf dem Papier?
Reconciliation (Abgleich) von Datenbanken
Reporte für operative und historische Daten
Mit Stored Procedures erweiterbar
Eigene angepasste Compliance Reports
Nachvollziehbare Beglaubigungsvorgänge (Approval-Prozesse)
Präsentationstitel 31
Reporting durch den Oracle Identity Manager OIM
|
Security Konzept, nur auf dem Papier?
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)
Präsentationstitel 32
Applikations Design Security
|
Security Konzept, nur auf dem Papier?
“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
Präsentationstitel 33
Audit
|
Security Konzept, nur auf dem Papier?
Ü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
Präsentationstitel 34
Security Konzepte, was ist erforderlich?
|
Security Konzept, nur auf dem Papier?
Präsentationstitel 35
Allgemeine Security Richtlinien
|
Security Konzept, nur auf dem Papier?
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”
Präsentationstitel 36
Lösungsansätze
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 37
Methodik
|
Security Konzept, nur auf dem Papier?
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
Präsentationstitel 38
Methodik
|
Security Konzept, nur auf dem Papier?
Präsentationstitel 39
NIST Common Vulnerability Scoring System (CVSS) Calculator
|
Security Konzept, nur auf dem Papier?
Ergebnisdarstellung:
Keine Ampeln
Balkenfortschrittsdiagramm
Scorecard
Netzdiagramm
Präsentationstitel 40
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: info@mt-ag.com
www.mt-ag.com