IT-Sicherheit Master-Seminar

Präsentation zum Thema: "IT-Sicherheit Master-Seminar"—  Präsentation transkript:

1 IT-Sicherheit Master-Seminar
Bedrohungen, Risiken, Sicherheitsanforderung und -maßnahmen beim Cloud Computing Johannes Raczek & Swen Priebe

2 Cloud Computing – Rückbesinnung auf alte Werte
Zentralisiertes Ressourcenmanagement Zentralisierte Kontrollstrukturen Viele Techn. & Eigenschaften existieren schon seit Jahrzehnten Der Paradigmenwechsel besinnt sich auf viele Eigenschaften der Mainframe-Era Dynamisch allokieren von Ressourcen wenn diese benötigt wurden Ressourcenpool In gewisser weise elastisch Zentral verwaltet Cloud Computing hat sich weiterentwickelt Fehlertolleranz Serviceorientiert Automatisierung Kostenfaktor Entwicklung (mitte 90er) viele unterschiedlich Konfigurierte Server Internet gefolgt von Standards Service-orientierte Ansätze (SOA) Veränderung der Sicherheitsaspekte (on-premise/of-premise) Quelle: [1]

3 Cloud Computing – Grundlagen
Infrastruktur Server Speicher Netzwerkkomponenten (Switch, Router, …) IP-basierte Netzwerke VLANs Physikalisch getrennte Netze Virtualisierung Rechenkapazität (VMs) Netzwerk Infrastruktur Ansammlung unterschiedlichster Komponenten Organisiert um in inkrementellen Schritten zu wachsen Sollten nach wichtigen Gesichtspunkten ausgewählt werden (Skalierbarkeit, Robustheit) IP-basierte Netzwerke Verbindet Nutzer mit den Cloud-Services Besonderes Augenmerk: Single-Point-Of-Failure Partitionierung und Virtualisierung für Skalierbarkeit und Ausfallsicherheit Virtualisierung Heute: Kerntechnologie um schnell Ressourcen bereitzustellen Kosteneffiziens (Server bereitstellen) Bietet Trennung der Customer auf Anwendungsebene

4 Cloud Computing – Grundlagen (2)
Software Automatisierung Provisioning, Accounting, Load Balancing, ... Durchsetzung von Policies Services Service Interface Zugriff auf Cloud-Ressourcen Web-Frontend, GUI, ... Im Konsenz mit SLAs Preisgestaltung

5 Der Cloud Stack Quelle: [1]

6 Cloud Service Modelle – Das SPI-Modell
Software-as-a-Service Provider stellt Services bereit Zugriff über Thin-Clients Limitierte Konfigurationsmöglichkeiten Platform-as-a-Service Consumer kann eigene Anwendungen deployen IDE- & Toolsupport von Provider Kontrolle über die Applikationen Infrastructure-as-a-Service Provisioning virtueller Ressourcen (VMs, Speicher, Netzwerk) Kontrolle über virtuelle IT-Infrastruktur & ggf. bestimmten Netzwerkkomp. Verantwortlichkeiten des Consumers wachsen von SaaS zu IaaS Mehr Fachwissen benötigt Quelle: [1]

7 Cloud Deployment Modelle
Private Cloud Cloud Infrastruktur für eine einzige Organisation Selbstverwaltung oder Verwaltung durch Third-Party Anbieter Community Cloud Infrastruktur wird von mehreren Organisationen geteilt Public Cloud Organisation (Provider) stellt Cloud Infrastruktur der Öffentlichkeit zur Verfügung Hybrid Cloud Komposition aus min. 2 vorhandenen Modellen Verknüpfung von Daten & Applikationen Community Private Public Hybrid Seite

8 Cloud Computing – Eigenschaften & Vorteile
Skalierbarkeit Wiederholende Muster Automatisierung Ausfallsicherheit Effiziens Elastizität Ortsungebunden Transparenz für Endnutzer Mell & Grace haben auf Grundlage der Definition der NIST (National Institute of Science and Technology) folgende Eigenschaften definiert: On-demand: Ressourcen werden dem Customer transparent ohne menschliches Einwirken zur Verfügung gestellt Network access: Fahigkeiten der Cloud werden über Internet-Standards heterogenen Thin-Client zur Verfügung gestellt Ressource Pooling: den Consumern werden nach Bedarf unterschiedlichste Ressourcen bereitgestellt. Der Consumer hat keine Kontrolle oder Wissen über den Ort der b. Ressourcen. Measured: automatisiertes anpassen der Ressourcennutzung auf Grundlage von Messwerten Quelle:

9 Cloud Security – Security Concerns
Netzwerk (Availability) Zukunftsfähige Cloud Provider Disaster Recovery Services auch nach schwerwiegenden Problemen nutzbar Kommunikation & Transparenz Support Benahrichtigungen bei Fehlern Informationen: Policies, Management, tech. Umsetzungen Netzwerk Cloud ist nur von Wert, wenn eine bestimmte Bandbreite gegeben ist Provider Junges Berufsfeld. Vertrauensbasis...

10 Cloud Security – Security Concerns (2)
Kontrollverlust Daten (Confidentiality, Integrity, Accountability) Applikationen (Integrity, Availability) Eingeschränkte Konfigurationsmöglichkeiten Neue Schwachstellen und Risiken Schwachstellen in genutzter Hard- und Software Rechtliche Fragen/Bedenken Gesetze Verträge Zertifikate Kontrollverlust: Public oder Comm. Cloud: Daten nicht mehr im eigenen System Nutzer hat nur begrenzente Kontrollmölichkeiten

11 Sec. Concerns im Detail – Virtualisierung
Kompromittierter Hyporvisor Information Exposure durch Reallokation von Ressourcen Korrekte Fehlerbehandlung (Graceful Ex. Handling) Daten selbst abwickeln (Data Clearance) “A hypervisor does not undergo frequent change and does not run third-party applications. The guest operating systems, which may be vulnerable, do not have direct access to the hypervisor. In fact, the hypervisor is completely transparent (invisible) to network traffic with the exception of traffic to/from a dedicated hypervisor management interface. Furthermore, at present there are no documented attacks against hypervisors, reducing the likelihood of attack.” Andreas Antonopoulos, Quelle: [4] Seite 56

12 Sec. Concerns im Detail – Virtualisierung (2)
Netzwerkangriffe zwischen VMs auf einer physischen Maschine OS-basierte Paket- und Verbindungsfilter Load Balancing kann virtuelle Netzwerktopologie verändern (shape shifting) Problem: Firewall-Regeln mit statischen IP-Adressen Netzwerkvirtualisierung bedarf entsprechender Schnittstellen für die VMs z.B. Brücke zwischen virtuellen und physischen Netzinterface im Hypervisor (virtuelle Switches & Firewalls) Amazon EC2, S3 Open Source: Eucalyptus... (Walrus, Cluster Controller) Layer 2/3 Isolation in mehreren Netzwerkmodis möglich CC: Verwaltet Maschinen/Hypervisors -> DHCP -> IP-Adresszuweisung für VMs

13 Sec. Concerns im Detail – Virtualisierung (3)
Angriffe durch andere Cloud Customer Isolation des Daten- und Kontrollflusses VM tagging / labeling Configuration Management Database (CMDB) Netzwerk-Overlay mit VLANs Virtualisierung verkompliziert das Management der Infrastruktur, ABER: durch den Umfang und die gewünschte Elastizität muss die V. automatisiert werden Das bedeutet: gute Planung und Management sind notwendig Return of control (da nicht mehr ad hoc genutzt) -> bessere Sicherheit möglich

14 Sec. Concerns im Detail – Provisioning
Schnelle, automatisierte und transparente Bereitstellung von Ressourcen Ressourcen/Services können über mehrere Instanzen (ggf. über mehrere Datenzentren) bereitgestellt werden (Availability) Master-Images manipulation Integritätsprüfung durch Provisioning-Service Prozessisolation in jedem Provisioning/Deprovisioning Schritt

15 Sec. Concerns im Detail – Provisioning (2)
Kompromittierung des Provisioning-Service Höheres Risikopotential als ein komprommitierter Hypervisor Isolation bereitgestellter Ressourcen unterschiedlicher Costumer Bedarf nach umfangreicher Versionskontrolle und (automatisierten) Konfigurationsmanagement Unerwünschter Zugriff durch Recycelte IDs / IPs Deprovisioning vollständig & komplett s. 64

16 Daten Sicherheit zentrales Thema des cloud Computing
Umfasst mehr als Datenverschlüsselung Abhängig von den 3 Cloud Service Models und den 4 deployment Modellen Nicht einfach ein übertragen von bekannten und erprobten Maßnamen in die Cloud Betrachtung von ruhenden- und bewegten Daten

17 Hauptbedenken von Cloudnutzern
Verlust der Kontrolle über die Daten, wenn sie nicht mehr im eigenen Netz liegen. Gefahr der Sensitiven Daten durch eine öffentliche Cloud Probleme: Meisten Unternehmen sind nicht qulifiziert in dem Security Bereich oder es ist nicht Ihr Kern bereich. Die einfache Nutzung von computern steht im mittelpunkt Datensicherheit ist oft erwünscht aber nicht das Hauptkriterium Folglich: Daten nicht im eigenen Unternehmen zu haben birgt nicht zwangsweise Risiken, sondern erhöht die Sicherheit Nutzen von externen Dienstleistern ergibt also u.U. bessere Sicherheit und Kostenersparnis Außerdem vertrauen viele Unternehmen für den Fall des disaster-recovery oder die sichere löschung von daten auf externe Dienstleister Folglich werden sensible daten schon an externe weitergeben.

18 Teilweise zu sensitive Daten, können nicht in cloud gespeichert werden (Nationale Sicherheit, zukünftige Produktpläne), solange der CSP niedrigere Sicherheitsrichtlinien hat als das Unternehmen. Generell nicht unmöglich, aber generell zu Teuer Daher verwendung einer Private oder commutity cloud hierfür. Ist nicht ausgeschlossen das es in Zukunft public Hochsicherheitsclouds geben könnte

19 Organisatorische Verantwortlichkeiten - Eigentümer und Verwalter
Verantwortung der Datensicherheit abhängig vom Cloud deployment. Saas: verantworutng beim CSP PaaS geteil zwischen Owner und CSP. Aber nicht kopmlett an CSP übertragen, Owner muss Backups etc machen IaaS: komplett beim Owner Ab dem PaaS ist der Owner ansteigend mitverantwortlich für die Datensicherheit Bei Iaas liegt sie komplett beim Owner Risiken in bezug auf Datensicherheit bestehen zu zwei Zuständen von Daten Data at Rest (gespeicger in der Cloud) Data in Motion (Daten die in bewegung in oder aus der Cloud sind)

20 Data at Rest Gespeicherte Daten in der Cloud
Nicht radikal anders als bei Daten außerhalb einer Cloud Verantwortlichkeit der Sicherheit vom Cloud Deployment abhängig Auswahl des CSP wichtig Genrell kommen die Gleichen verfahren zur Anwendung. Risiko dadruch das der Owner die Daten nicht mehr Verwaltet Kann aber auch Vorteile haben wie gesehen, (wenig eigene kompetenz und somit kostenersparnis) Dies ist abhängig von dem Cloud deployment und der sich daraus ergebendenVerantwortung in Bezug auf die Sicherheit. Auswahl des CSP im Hinblick auf die verwendeten Maßnahmen, Zertifizierte Anbieter, Allgemeine Standards

21 Data in Motion Daten auf dem Weg in/innerhalb der Cloud Ziel:
Bsp. Username und Password Ziel: Sicherung gegen Manipulation Wahrung der Vertraulichkeit Maßnahme: Verschlüsselung der Daten Daten zum Zeitpukt wo sie unterwegs sind, bsp von gespeichertem Status aus einer DB in einer andere Form an der gleich Location, Beispiel username und PW zur authentisierung an einer Website Ist nicht Trivial: Vile Dinge geschehen auf dem Weg zwischen endpunkten Pakete werden gecached auf zwischensystem Tempöräre Dateien erstellt auf Zielsystem Folglich keine Bessere Sicherung möglich als verschlüsseln derDdaten

22 Risiken in Bezug auf Cloud Datensicherheit
Phishing Indirektes Risiko für Daten in Motion Maßnahme: Whitelisting der Source IPs, zufällige Passwort abfragen, Verwendung von key-based Authentisierung CSP Mitarbeiter mir erhöhten Rechten Auch wenn die Verschlüsselung sicher ist, kann der Anwender ausgetrickst werden seine Daten preiszugeben Privelegiertes CSP personal: Gefahr das nicht verschlüsselte Daten durch priveligiertes Personal nach Außen gelangen. gibt’s keine Gegenmaßnahmen nur Vertragsbestimmungen und Praktiken des CSP das dies nicht gemacht wird. Daten verschlüsseln

23 Kryptographische Techniken
Symmetrische Verschlüsselung Asymmetrische Verschlüsselung Problem: Sysmmetrische: Austausch der schlüssel wenn noch kein sicherer Verbindungskanal vorhanden Aufwendiges schlüssel management Asymmetrisch: Da ein schlüssel öffentlich sein kann gut geeignet um vertraulichkeit von date zu gewährleisten. Privater schlüssel kann genutzt werden zur Authentisierung von Benutzern oder Computern Außerdem genutzt zur initiierung einer sicheren Verbindung Kryptographie zentrales thema, aber oft nicht genutzt oder in unsicherer Weise: Bsp auf nicht aktuell gepatchtem PC Nicht nutzen sicherer Protokolle (FTP,HTTP, telnet etc) anstelle der sicheren gegnstücke Einbinden von Passwörtern in binary/konfigurations Dateien Senden von Sensitiven daten unverschlüsselt per mail

24 Daten Sicherungsmethoden
Keine neuen Techniken Wie auch außerhalb der Cloud Authentisierung und Intentity Access Control Encryption Data Masking Authentisierung kann auf Verschiedenste Weisen geschehen Ist eine grundvorausetzungs das sichere Arbeiten Authentisierung: ein faktor authentisierung (bsp. Password) zwei faktor authentisierung (bsp passwort und fingerabdruck) Probleme gibt es wenn Verschiedene Cloud anbieter CSP genutz werden, Syncronisierung der identitäts informationen

25 Access Control Techniken
DAC Discretionary Access Control RBAC Role Based Access Control DAC: jedes Objekt hat einen Besitzer. Dieser legt fest wer wie auf seine Objekte zugreifen darf Aufwendig in der Wartung, nur in Umgebungen mit wenigen Nutzern sinnvoll RBAC: berechtigungen werden durch das System festgelegt. Der zugriffmöglichkeit ist dann äbhängig von der Rolle des Subjekts. MAC: berechtigungen werden durch das System festgelegt und umgesetzt durch labls Zugriffsentscheidung nicht nur aufgrund der Identität des Benutzer und objekter, sondnern mittels zusätzlich definierter regeln/labels Jeder nutzer und jedes objekt erhalten also mittels eines Labls ein level of trust bzw. eine level of trus das nötig ist um auf das objekt zuzugreifen Mandatory Access Control dienen dazu, die Sicherheit von Informationen vor unautorisiertem Zugriff sicherzustellen und auch systemtechnisch zu erzwingen. Der Schutz der Informationen bezieht sich auf Vertraulichkeit und Integrität. MAC setzt also voraus das ein System wie SELinux oder Trusted Solaris verwendet wird, das das Datalabeling unterstützt. Weiter ist es wichtig sich generell gedanken zu machen was für daten in der cloud gespeichert werden sollen und diese zu categorisieren und zu labeln MAC Mandatory Access Control

26 Encryption for Data at Rest
Full Disk: verschlüsselung auf Disk ebene Directory Level: Verschlüsselung auf Verzeichnisebene als Container File Level Application Level Full Disk: OS, Programm, und die daten auf einer Disk werden verschlüsselt. Probleme: wenn nicht in Hardware > langsam, kompletter Datenverlust bei Fehlern Directory Leven: Verschlüsselung der Daten verzeichnisse als Container Zugriff erfordert schlüssel Daten des gleichen SicheheitsLevel/kategorisierung können in Container mit verschiedene Schlüsseln abgelegt werden > zugriff auf daten beschränken File Level: veschlüssleung individueller dateien Application level: Die appliation managt die verschlüsselung ihrer verwendeten daten Generelles Problem: Management der schlüssel für die ver/entschlüsselung Recovery methoden wenn Schlüssel verloren gehen oder nicht verfügbar sind, Welche optionen gibt es, muss gekärt sein, sind backups vorhanden

27 Encryption for Data in Motion
Ziele: Sichern der Daten gegen Manipulation Vertraulichkeit der Daten wahren Maßnahmen: Encryption zur Sicherung der Integrität Authentisierung der Kommunikationspartner zur Sicherung der Vertraulichkeit Manipuliert, d.h. Das die integrität der daten gewahrt ist Vertraulichkeit: kein anderer außer sender/empfänger kann die daten ändern bzw. ihnen einen Sinn abgewinne/eine bedeutung zuordnen. Encryption: Einsatz von HTTPS, TLS, SSL etc Authentisierungmittels PKI Public key Infrastructure Einschränkung der Verschlüsselung von Data in Motion bei SaaS: Beispielweise social network umgebungen wie facebook etc ist es nicht möglich verschlüsselung zur erhaltung der vertraulichkeit zu nutzen. Würde dem Sinn des Service Wiedersprechen und den Anbietern es unmöglich machen mit den daten zu arbeiten. Um bsp angepasste werbung etc anzuzeigen

28 Data Masking Entfernen aller charakteristischen Eigenschaften von Daten Anonymisierung Minimiert die Gefahr der Offenlegung von sensibler Daten Verhindern das die daten sensitive informationen Preisgeben Depersonalisieren, Keine Rückschlüsse mehr möglich Umsetzung mittels Substitution (ersetzen) der Daten Werte durch keys zu einer externen lookup table mit mit den korrekten daten Struktur der Daten bleibt gleich, aber die werte sind in verschiedener weise geändert. Wie dies auch immer umgesetzt ist (verschlüsselung character substitution), es muss so sein, das ein Rückschluss auf die original Daten nicht möglich ist.

29 Cloud Data Storage Storage as a Service
Komplexe Hardware und Software Implementierung Wichtiger Aspekt: Zuverlässigkeit und Verfügbarkeit Verantwortlichkeit für Backups, Desaster Recovery liegt beim CSP Einsatz eines geeigneten Filesystems, bsp. ZFS Replication der daten auf low level, d.h. Mechanismen wie Raid oder durchs filesystem

30 Cloud Storage - replication and availability
ZFS: liefert viele security relevanten funktionen mit, wie copy-on-write cloning Automatische integritäts chechs, mit reperatur

31 Cloud Storage - Cloud Storage Gateway
spezifische Schnittstelle zum Cloud Storage Umsetzung der client seitig genutzten block-basierten Speicherschnittellen (NFS, iSCSI, Fibre channel) zu den Cloud seitigen Schnittstellen (REST/SOAP) Integration des Storage mit den existierenden Anwendungen über Standard Protokolle

32

33 Cloud Lock-In Abhängigkeit von einem Cloudservice
Anpassung der eigene geschäftsprozesse an den service Sehr schwer den cloud provider zu wechseln Die investierte Arbeit wird wertlos Proprietäre Datenformate/Schnittstellen erschweren u.U. Migration

34 Cloud Lock-In - Metadaten
In einer Cloudumgebung entsteht ein nicht geringer Anteil an Metadaten. Bsp. Herkunft der Daten CSP Mitarbeiter mir erhöhten Rechten Problem diese Informationen sollen beim Wechsel zu einem anderen Anbieter/Service nicht verloren gehen. Metadaten: Wer hat welche operationen auf welchen daten ausgeführt Was für änderungen wurden gemacht Liefert also wertvolle informationen über benutzer und ihren bezug, kontext zu daten. In einem SaaS umfeld genriert durch de CSP software über die Zeit. Problem: Es war nie vorgehsen den dienst nicht weiter zu nutzen und man abhängig mit von dem service, aber auch von den Metadaten. Aber durch bestimmte Umstände ist Umstieg nötig, CSP stellt Service ein, gestaltet ihn um. Wie an die daten kommen.

35 Cloud Lock-In - verhindern
Viele Anbieter geben Exportmöglichkeit der: Daten Metadaten Vor Service Verwendung prüfen Wichtig: wie die exportierten Daten vorliegen Wie können sie weitergenutzt werden Vor verwendung eines Service prüfen: Vorhandene Exportmöglichkeiten Sonst keine Möglichkeit an die daten zu gelangen Exportmöglichkeit an sich stellt nicht sicher das die daten weiter genutzt werden können Schauen wie die daten exportiert werden (propriätares Format?) u.U. Nicht oder nur aufwendig umwandelbar Auch wenn klartext export, nicht sichergestellt das import in intelligenter weise möglich

36 Cloud Lock-In - Datenexport Beispiel: Google
Data Liberation Front Ziel: einfache Möglichkeit des Im/Exports von Daten aus Google Produkten Bsp: Google Docs: Möglichkeit des Exports der eigenen Dokumente in verschiedenen Formaten

37 Cloud Lock-In - Datenexport Beispiel: Salesforce.com
Generelle Möglichkeit des Exports vorhanden Muss aber extra gebucht werden Exportiert werden die alle Daten gepackt als ZIP-Datei Format der Daten: CSV Dateien mit den Rohdaten für jedes Salesforce Objekt Anmerkung: Es gibt mehrer andere Anbieter die in der Lage sind die daten zu verstehen und zu Parsen und somit sinnvoll zu importieren. Es ist also ein sinnvolles features.

38 Cloud Lock-In - Datenexport Beispiel: Amazon
Bietet für EC2, Data storage, database compute und noch andere Service eine Export funktion Ansatz: Aufgrund der Menge der Daten kein Download Kunden können eine portable HDD einsenden und einen Auftrag für einen Export stellen. Dies waren nur einige Beispiele. Mitlerweile gibt es unternehmen die sich auschließlich mit dem Thema Lock-in befassen. Bsp. Backupify, bietet die Möglichkeit des Backups und der Archivierung von allen Daten in Bezug auf einen service zu erstellen. Bisher aber nicht im Enterprise cloud Umfeld, sondern nur zur Archivierung von Daten aus Facebook Flickr, Twitter etc. Zukünftig wird sich der Markt aber Richtung Enterprise cloud entwickeln

39 Cloud Security – Anforderungen an die Architektur
Wichtige Faktoren Kosten & Ressourcen Zuverlässigkeit Performance Security Triad (C.I.A.) Regulatorische Einschränkungen & Rechte Erfordern gutes Design und umfassende Planung Ansonsten: hohe laufende Kosten, ineffiziente Prozesse, Operationen (nicht dynamisch genug [Ursprung]) Wichtig: Planung flexibel auslegen; evo. Änderungen erwarten Kosten & Ressourcen: Implementierung von Sicherheitskontrollen und Investitionen (Tech.) müssen sich nach Mitteln richten Zuverlässigkeit: Customer können sich auf die dahinterliegende Tech. Verlassen (delivering services) Performance: Antwortzeiten, Datendurchsatz (entspricht SLAs) Triad: Sicherheitskontrollen müssen den Anforderungen genügen (auch im Hinb. auf Kosten und Performance) Rechte: zusätliche Anforderungen...

40 Cloud Security – Anforderungen an die Architektur (2)
Physikalische Sicherheit Gefahren: Menschliche Aktionen Umweltkatastrophen Disaströse Zwischenfälle (z.B. Brand im Datenzentrum) „Layered Defense“ Sicherheitspersonal Monitoring Automatisierte Kontrollstrukturen Schutz vor Umweltkata., mensch. Aktionen, disaströse Zwischenfälle (Brand, Anker fällt auf Unterseekabel ...) Layered Defense: Sicherheitselemente sollten in autom. Kontrollstrukturen und Monitoring eingebettet sein Beispiel (schwächtes Glied)

41 Cloud Security – Anforderungen an die Architektur (3)
Systemübergreifender Zeitservice Identity Management Schutzt der Identitätsinformationen (C.I.A.) Identitäs-Recycling „Universelle“ Identitätsinformationen (Single Sign-on) Historische Nutzerinformationen Access Management Key Management Security Monitoring Incident Management Zeitservice Synchronisation von Ressourcen (SysLogs, Ereignisverarbeitung,...) Diagone von Fehlern Network Time Protocol (NTP) Identiätsmanagment Komponenten müssen Identität auf Validität prüfen Isolation (nach reprovisioning kein Zugriff auf private Informationen), ggf. Wiederverwendung verhindern Auf vorhandene Infrastrukturen zurückgreifen (Staat)...Single Sign-on (Software as a Service) Nach deprovisioning: histroische Informationen speichern (zukünftige Nachforschungen) Access Management Nutzt Identitäsinformationen (Umsetzen der Security Policy) ... Siehe Johannes Key Management Zugriff auf Schlüssel kontrollieren (Data at rest/motion, VM Images...) Incident Management Störrfälle nach SLAs und im Hinblick auf Security Policy behandeln

42 Cloud Security – Anforderungen an die Architektur (4)
Sicherheitstest & Schwachstellenbekämpfung Penetrationstest Unterschiedliche Environments Patch Management für alle Cloud Komponenten Kompensationskontrollen Konfigurationsmanagement Aktuelle Liste aller relevanten Cloud Assets Klassifizierung der Assets Tests und Bekämpfung Penetrationstest (vor Produktivphase) Koordination mit Monitoring & Konfigurationsmanagment Environments (Tests, Entwicklung, Produktion,...) Patches (Vorteil Provisioning/Deprovisioning) Kompensationskontrolle (wie wird auf welche Gefahren reagiert, woher kommen die Gefahren [Customer...]) Konfig. Management Lister wichtiger Assets (Hardware, Software, Konfiguration,...) die Überwacht werden (ideal: nutzen einer CMDB) Klassifizierung (Funktion, Bedeutung/Relevanz, Impact, weitere Charakteristika)

43 Cloud Security – Patterns & Architekturelemente
Isolation of Subnets Sandboxes Network Honeypots Security Patterns Isolation of VMs Defense In-depth Defense In-depth Stammt aus dem Paper „Information Warfare and Dynamic Information Defense“ von 1996 Idee: individuelle Sicherheitskontrollen unvollständig und selten effizient Mehrere Mechanismen & Kontrollen bieten eine robustere Sicherheitslösung (layered defense) Beispiel: Remote Admin Access nur über VPN & Zugangsrouter prüft Source-Ips (Whitelisting) Sandboxes Abstraktion zwischen Software und Laufzeitumgebung (Android, Virtualisierung) Isolation of VMs Traffic verschlüsseln Traffic filtern (Firewalls) Isolation benachbarter VMs Isolation of Subnets Physikalische Trennung von Netzwerken Netzwerk für administrative Aufgaben und Kontrollfluss Netzwerk für den eigentlichen Cloud Betrieb Netzwerk fürs Security Monitoring Resilience & Grace Wie werden Fehler behandelt Abhängig von der Bedeutung der Ressource (Lebensgefahr?) Graceful resource-management (Elastizität spielt eine Rolle) Welchen Services funktionieren im Fehlerfall noch Deprovisioning fehlerhafter Ressourcen bis Treshholdwert erreicht (beeinträchtigung der Funktion) Cabling Patterns Resilienve & Grace

44 Cloud Security – Public Cloud Architekturbeispiel
OOB: Out-Of-Band Patch Panels Netzwerk (Eintritt) Zwei dedizierte Eintrittspunkte in die Cloud Infrastruktur: 1. Kontrollmechanismen 2. öffentlicher Zugriff 2 redundante industrail-grade Router mit umfangreichen Sicherheitsfunktionen (traffic inspection, black listing, ...) 2 kompakte Router für das Kontroll-Netzwerk (weniger Traffic, hohe Constraints [wenige Protokolle]) Die meisten (normalen) Operationen und Konfigurationen laufen im Core-Netzwerk ab Initiale Konfiguration Im Problemfall Seperate Netzwerke Storage Area Network (Bucket Storage für Images, Caching auf Serverseite) Trennung des Storage Traffic von Core Data Traffic (Performance & Sicherheit) Switches Wie viele Server pro Switches Overhead: switch configuration & management Ausfallsicherheit großer switches Wichtig: Redundanz, Isolation, Kostenfaktor Compute Server Homogene Landschaft Realisieren Services CMDB & Provisioning CMDB als informations-repository Speichert Schlüsselinformationen für die eig. Operation der Clound und deren Sicherheit Security Server Monitoring, Auditing, Security Scanning (Nessus und co.) Quelle: [1]

45 Risikomanagement Basiert auf fundamentalen design und implementierungsentscheidungen Abwägen zwischen den Sicherheitsanforderungen Ihrer Komplexität Kosten der Umsetzung => finden eines sognannten Sweetspots Mittels aus Sicherheit und vertretbarer kosten

46 Risikomanagement - Risiken definieren
Sicherheitsansätze müssen prakmatisch (anwendungsbezogen) sein. d.h. Eine Architektur und Maßnahmen ist nicht für niedrig und hochsicherheitsrelevante umgebungen gleichermaßen geeignet. Risko Wichtig die Risiko Wahrscheinlichkeit zu kennen um bewerten zu Können wie Kritiisch dieses ist. Im Grunde ist das Risiko eine Funktion von Bedrohungen, wie sie Schwachstellen auszunutzen suchen, ins verhältsnis Gesetzt zu den Gegenmaßnahmen und in Bezug zu den bewerteten Assets (zu schützenden Vermögenswerte)

47 Risikomanagement - Risiken bewerten
Threat Categorization Threat Impact Threat Frequency Uncertainty Factor Bedrohungen Kategorisieren Was kann mit den Assets passieren, wodurch werden sie bedroht Bedrohungs auswirkungen Möglichen schaden durch die Bedrohung ermitteln Auftritts Häufigkeit der bedrohung Wie oft wird so eine Bedrohung wohl eintreten Unsicherheitsfaktor über die richtigkeit der 3 Aussagen Problem der ganzen Sache ist, das die aussagen nur auf Wahrscheinlichkeiten basieren Somit erhällt man die bewerteten Riskien Wichtig sind nun aber Maßnahmen um sie zu Verhindern Kosten Kosten/nutzen Diese Frage ist bei einer Public Cloud jedoch rhetorische Fragen. Man erhällt was man wofür man Zahlt, umsetzung sache des CSP Generell nur bei IaaS für den Kunden relevent

48 Risikomanagement - Risiken managen
Planen: festlegen der einzusetzenden Security Controls Kategoriesieren der Informations resourcen untersuchen ob die Maßnahmen adäquat sind und die Risiken minimieren Implementieren: implementierung und konfiguration der Security Control Evaluieren: bewerten der effizienz der security Control und periodische überprüfung Amintain/Aufrechthalten der Sicherheitscontrollen: Maßnahmen sind in Betrieb Periodische überprüfung, anpassungen, reconfigurationen überprüfungen

49 Risikomanagement - Risiken kontrollieren
Security Controls Gegenmaßnamen, Vorkehrungen um Sicherheitsrisiken zu Vermeiden Entgegenzuwirken Erkennen Auf andere Weise reagieren

50 Kategorisierung von Security Controls - NIST
National Institute of Standards and Technology Eingeteilt in 14 Klassen, Innterhalb der klassen die einzelnen detailliert beschrieben Priorisiert (LOW, MODERATE, HIGH) Aussage über die Risiken gegen die die Security Control schützen soll

51 Kategorisierung von Security Controls - NIST
Control Statement: spezifische Aktivitäten/Aktionen die realisiert werden müssen Supplemental Guidance: zusätzliche Informationen Control Enhancements: Hinweise für zusätzliche Maßnahmen, um die beschriebene zu verstärken Reference: Hinweise zu entsprechenden Gesetzen / Standard die relevant sind für Control Umsetzung Priority: Angabe zur Priorisierung von Controls

52 Security Monitoring – Verwendungszweck

53 Security Monitoring – Ereignisquellen – & senken

54 Security Monitoring – Ereignisverarbeitung

55 Security Monitoring – Von Problemen & Modellen