Bereich 9 Vorfallsreaktion

vPierre Cloud, Cloud Computing, Sicherheit / Security Leave a Comment

  • Einleitung

Die Vorfallsreaktion (IR) ist ein kritischer Aspekt jedes Informationssicherheitsprogramms. Präventive Sicherheitskontrollen können die Möglichkeit einer Gefährdung wichtiger Daten nicht vollständig beseitigen. Die meisten Organisationen haben einen gewissen IR-Plan, der regelt, wie ein Angriff untersucht wird, aber mit den deutlichen Unterschieden beim Zugriff auf forensische Daten und der Governance in der Cloud müssen Organisationen überlegen, wie sich ihre IR-Prozesse ändern werden.

Dieser Bereich möchte jene zu IR gehörigen Lücken aufdecken, die durch die besonderen Charakteristika des Cloud-Computing entstehen. Sicherheits-Fachleute können das als Referenz nutzen, wenn sie Reaktionspläne entwickeln und andere Maßnahmen während der Vorbereitungsphase des IR-Lebenszyklus leiten. Dieser Bereich ist in Übereinstimmung mit dem gemeinhin anerkannten Lebenszyklus von Vorfallsreaktionen organisiert, wie er im Computer Security Incident Handling Guide des National Institute of Standards and Technology beschrieben ist (NIST 800-61) [1].

Nach der Beschreibung des Lebenszyklus der Vorfallsreaktion wie in  NIST 800-61 beschäftigt sich jeder nachfolgende Abschnitt mit einer Phase im Lebenszyklus und untersucht die potenziellen Überlegungen für Einsatzkräfte bei der Arbeit in einer Cloud-Umgebung.

  • Überblick
  • Lebenszyklus der Vorfallsreaktion

NIST 800-61

  • Vorbereitung: „Aufbau der Fähigkeiten zur Vorfallsreaktion, damit die Organisation vorbereitet ist, um auf Vorfälle zu reagieren“
    • Prozess zum Umgang mit den Vorfällen
    • Kommunikation und Einrichtungen der Handelnden
    • Hardware und Software zur Vorfallsanalyse
    • Interne Dokumentation (Port-Listen, Anlagen-Listen, Netzwerkdiagramme, aktuelle Ausgangswerte des Netzwerkverkehrs)
  • Erkennung & Analyse
    • Alarmierungen (Endpunkt-Schutz, Netzwerk-Sicherheitsüberwachung, Host-Überwachung, Kontoerstellung, Rechteausweitung, andere Anzeichen für Gefährdung, SIEM, Sicherheitsanalysen (Erkennung von Ausgangswerten und Anomalien))
    • Bestätigung von Alarmierungen (Verringerung von Falschmeldungen ) und Eskalation
    • Aufbau einer Zeitachse des Angriffs
    • Bestimmung des Ausmaßes des potenziellen Datenverlustes
    • Dokumentation des Vorfalls und Beschaffung von Beweisen (Kontrollkette)
  • Eindämmung, Bekämpfung & Wiederherstellung
    • Eindämmung: Systeme vom Netz nehmen. Überlegungen hinsichtlich Datenverlust gegenüber Service-Verfügbarkeit. Sicherstellung, dass sich Systeme nach der Erkennung nicht selbst zerstören.
    • Bekämpfung & Wiederherstellung Bereinigung kompromittierter Geräte und Wiederherstellung der Systeme für normalen Betrieb. Bestätigung, dass System ordnungsgemäß funktionieren sowie Installation von Kontrollen zur Vermeidung ähnlicher Vorfälle.
  • Post-mortem
    • Was hätte man besser machen können? Hätte der Angriff früher erkannt werden können? Welche zusätzlichen Daten wären hilfreich gewesen, um den Angriff schneller zu isolieren? Muss der IR-Prozess verändert werden? Wenn ja, wie?
  • Wie beeinflusst die Cloud I/R
  • Vorbereitung
    • SLAs und Governance: Was macht Ihre Organisation? Wofür ist der CSP verantwortlich? Kontaktstellen? Erwartungen an die Reaktionszeit? Eskalations-Verfahren? Kommunikationsabläufe außer der Reihe (falls Netzwerke betroffen sind)? Wie funktionieren die Übergaben? Auf welche Daten müssen Sie zugreifen?
      • Test des Verfahrens mit dem CSP. Gewährleistung, dass Eskalationen und Rollen/Zuständigkeiten klar sind.
      • Sicherstellung, dass der CSP Kontaktdaten hat, um Sie über erkannte Vorfälle zu informieren, und dass dies in Ihren Prozess integriert ist.
      • Gewährleisten Sie für sich und Ihren CSP Kontakte auch außer der Reihe und testen diese.
    • IaaS/PaaS versus SaaS: Wie können für Ihre Cloud spezifische Daten in einer Mehrmandantenumgebung für eine Untersuchung bereitgestellt werden?
    • „Cloud Jump Kit:“ Für eine Untersuchung an einem entfernten Standorte benötigte Werkzeuge (wie cloudbasierte Ressourcen).
    • Gestaltung der Cloud-Umgebung für schnellere Erkennung, Untersuchung und Reaktion (Eindämmung und Wiederherstellbarkeit)
      • Geräteausstattung (ziehen von Telemetrie von jeder Schicht des Technologie-Stacks)
      • Isolierung, damit sich Angriffe nicht ausbreiten und die gesamte Anwendung gefährden können.
      • Unveränderbare Server: Wenn ein Problem erkannt wird, werden Arbeitslasten von einem gefährdeten Gerät zu einer neuen Instanz in bekanntem guten Zustand verschoben. Größeres Augenmerk auf Dateiintegritäts-Überwachung und Konfigurationsmanagement.
      • Karten des Anwendungs-Stacks zum Verstehen, wo Daten liegen werden, um geographische Unterschiede in der Überwachung und Datenerfassung zu berücksichtigen.
  • Erkennung und Analyse
    • Überwachung als ein Service stellt Alarmierungen bereit, die einen automatisierten I/R-Arbeitsablauf auslösen können.
      • Wird von einigen Cloud-Providern für ihre Plattform angeboten und einige Überwachungsoptionen für Dritte sind verfügbar.
      • Zunehmend verfügbar in IaaS und einigen PaaS, aber nicht üblich für SaaS.
    • Cloud-Plattform-Protokolle, die in bestehende Sicherheitsabläufe/Überwachung integriert werden können.
      • Nicht bei allen Providern verfügbar. Wieder eher bei IaaS und PaaS zu sehen als bei SaaS.
    • Unterschiede bei IaaS und PaaS/SaaS: Wer (Ihre Organisation oder der CSP) ist für die Erkennung verantwortlich? Verstehen der operativen Realitäten, für eine volle Untersuchung mit dem CSP zusammenarbeiten zu müssen.
    • Cloud-Konsole als ein Mittel zur Erkennung von Umgebungs-/Konfigurationsänderungen.
  • Datenquellen
    • Cloud-Plattform-Protokolle können einen Option sein, sind aber nicht universell verfügbar. Sollten alle Aktivitäten der Managementebene zeigen.
      • Verstehen, was protokolliert ist und welche Lücken die Vorfallsanalyse beeinträchtigen können.
      • Provider können bei einem schwerwiegenden Vorfall weitere Protokolle zur Verfügung haben, die den Kunden normalerweise nicht zugänglich sind.
    • Beschränkte Netzwerksichtbarkeit (Flussaufzeichnungen in einigen Instanzen, kein volle Paketerfassung)
      • Was kann vom CSP bereitgestellt werden?
    • Instrumentieren Sie den Technologie-Stack (innerhalb von Instanzen, Servern und Anwendungs-Code) zum Erhalt von Telemetrie, die für die Untersuchung wichtig ist.
    • Achten Sie besonders auf PaaS und serverlose Anwendungs-Architekturen. Wahrscheinlich müssen Sie eine individuelle Protokollierung auf Anwendungsebene hinzufügen.
    • Externe Bedrohungsanalysen (helfen Anzeichen der Gefährdung zu erkennen und Informationen zum Gegner zu erhalten)
    • Potenzielle Herausforderungen, ob von einem CSP bereitgestellte Informationen die Fragen der Kontrollkette überleben. An diesem gibt es keine Präzedenzfälle.
    • Wichtige zu stellende Fragen (aus der Anleitung 3.0.1 – Seite 98)
  • Forensische und investigative Unterstützung
    • Berücksichtigen Sie, was der CSP bereitstellen kann und ob das die Kontrollkette einhält
    • Aufgrund der dynamischen Natur der Cloud müssen viele forensische/investigative Prozesse automatisiert werden. Infrastruktur wächst und schrumpft, was I/R komplizierter macht.
      • Momentaufnahmen der Speicherung
      • Erfassung der Metadaten zum Zeitpunkt der Alarmierung, so dass die Analyse basierend darauf erfolgen kann, wie die Infrastruktur zu diesem Zeitpunkt ausgesehen hat.
    • Bestimmung des Ausmaßes der potenziellen Kompromittierung
      • Analyse von Netzwerkflüssen zur Kontrolle, ob die Netzwerkisolierung standgehalten hat
      • Konfigurationsdaten zur Kontrolle, ob andere Instanzen ähnlich angegriffen worden sind
      • Datenzugriffsprotokolle (falls verfügbar) und Anmelde-/Identitäts-Informationen für Verletzungen der Cloud-Plattform
      • Serverlose und PaaS-basierte Architekturen erfordern eine Korrelation zwischen Plattform- und Anwendungs-Protokollen
      • Metadaten von der Cloud-Konsole können Anhaltspunkte zur Art der Instanz, dem Anwendungs-Eigentümer und Schwachstellen geben, die andere Komponenten, Daten und Instanzen in der Cloud beeinflussen könnten
  • Eindämmung, Bekämpfung und Wiederherstellung
    • Bedrohungsmodellierung ist eine theoretische Übung, um die wirksamsten Mittel zur Eindämmung für verschiedene Angriffsarten auf unterschiedliche Komponenten im Cloud-Stack zu finden
      • Es gibt Unterschiede in den Möglichkeiten bei SaaS, PaaS und IaaS.
    • Stellen Sie zuerst immer sicher, dass die Cloud-Managementebene/Metastruktur nicht angegriffen ist
      • Sie können einen Angriff nicht eindämmen, wenn der Angreifer noch in der Managementebene ist.
    • In dieser Reaktionsphase bietet die Cloud weit mehr Flexibilität (vorwiegend für IaaS)
      • Eine software-definierte Infrastruktur (Nutzung von Vorlagen zum Aufbau des gesamten Stacks) ermöglicht Ihnen den schnellen Neuaufbau in einer sauberen Umgebung von Grund auf.
      • Sofortige Quarantäne (schieben Sie die Instanz einfach aus der Rechengruppe heraus und ersetzen sie)
      • Keine Notwendigkeit zum „Auslöschen“ des Angreifers, weil die neuen Instanzen der Infrastruktur sauber sind
        • Dennoch muss sichergestellt werden, dass die zum Eindringen genutzte Schwachstelle geschlossen ist
      • Die Umgebung heilt automatisch (wenn sie richtig konzipiert ist)
      • Stellen Sie sicher, dass das „Rezept“ für neue Infrastruktur/Anwendungen nicht kompromittiert worden ist
    • Bei SaaS und etwas bei PaaS können Sie sehr beschränkt sein und werden stärker auf den Cloud-Provider vertrauen müssen.
    • Post-mortem
      • Arbeiten Sie mit einem internen Reaktionsteam und dem Provider und finden heraus, was funktioniert, was nicht funktioniert sowie zu verbessernde Handlungsbereiche
      • Isolieren Sie Beschränkungen in der Datenerfassung und finden heraus, wie bei diesem Problem voranzukommen ist.
      • SLAs sind schwierig zu ändern, aber wenn die vereinbarten Reaktionszeiten nicht ausreichend waren, versuchen Sie diese neu zu verhandeln.
  • Empfehlungen
  • SLAs und die Festlegung der Erwartungen darüber, was der Kunde macht gegenüber dem was der Provider macht, ist der wichtigste Aspekt der I/R für cloudbasierte Ressourcen. Eine klare Mitteilung der Rollen/Zuständigkeiten und die Ausübung der Reaktionen und Übergaben sind wichtig.
  • Cloud-Kunden müssen geeignete Kommunikationswege mit dem CSP einrichten, die bei einem Vorfall genutzt werden können. Bestehende offene Standards können die Vorfalls-Kommunikation erleichtern.
  • Cloud-Kunden müssen Inhalt und Formate der Daten kennen, welche der CSP zu Analysezwecken bereitstellen wird und müssen beurteilen, ob die verfügbaren forensischen Daten die rechtlichen Anforderungen der Kontrollkette erfüllen.
  • Cloud-Kunden sollten die kontinuierliche und serverlose Überwachung cloudbasierter Ressourcen begrüßen, um potenzielle Probleme früher als in herkömmlichen Rechenzentren zu erkennen.
  • Cloudbasierte Anwendungen sollten Automatisierung und Orchestrierung ausnutzen , um die Reaktion einschließlich Eindämmung und Wiederherstellung zu optimieren und zu beschleunigen.
  • Für jeden genutzten Cloud-Dienstleister (CSP) muss die Vorgehensweise zur Erkennung und Behandlung von Vorfällen unter Beteiligung von beim Provider gehosteten Ressourcen geplant und im Vorfallsreaktionsplan des Unternehmens beschrieben werden.
  • Die SLA jedes genutzten Cloud-Dienstleisters muss die Unterstützung bei der Vorfallsreaktion garantieren, die für eine wirksame Umsetzung des Vorfallsreaktionsplans des Unternehmens in jeder Stufe der Vorfallsreaktion notwendig ist: Erkennung, Analyse, Eindämmung, Beseitigung und Wiederherstellung.
  • Tests werden mindestens jährlich oder nach erheblichen Änderungen an der Architektur der Anwendung  durchgeführt. Kunden sollten versuchen, ihr Testverfahren mit denen ihres Providers (und anderer Partner) im größtmöglichen Ausmaß zu integrieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.