Egal, um welchen Dienst es sich dreht, den Benutzern geht es immer zu langsam. Der Schwerpunkt des ADMIN-Magazins 05/2011 verrät, mit welchen Tools man ... (mehr)

Ansätze für IaaS-Umgebungen

In IaaS-Szenarien hat die zunehmende Virtualisierung der Maschinen aber auch Vorteile: Per Snapshot-Technologie können mit einem Klick vollständige Abbilder der virtuellen Maschinen erzeugt werden, was gerade für die Digitale Forensik einen enormen Vorteil darstellt. Allerdings bleibt die Frage offen, inwiefern das Abbild auch wirklich valide erzeugt wurde. Das lässt sich vom Anwender nicht auf einfache Art und Weise überprüfen. Hilfreich ist hier sicherlich die Dokumentation der technischen Prozesse im Rahmen eines Snapshot-Vorgangs, da viele CSP mit einer modifizierten Version des Hypervisors arbeiten und man sich daher nicht auf die Prozessdokumentation des Herstellers verlassen sollte.

Des Weiteren bleibt dem Kunden des IaaS-Services der Zugriff auf Netzwerkkomponenten verwehrt. So kann bei einer Untersuchung nicht auf die Logfiles von Routern, Switches, Firewall und so weiter zugegriffen werden und es steht somit von Seiten der Netzwerkschicht keinerlei Beweismaterial zur Verfügung. Diesen Zustand könnte nur der CSP ändern.

Eine Schnittstelle, die es einem Kunden ermöglicht, diese Beweisquelle anzuzapfen wäre sicherlich ein erster Schritt in die richtige Richtung. Auf den Netzwerkkomponenten könnten individuelle Logfiles erstellt werden, die gerade in IaaS-Szenarien auf die virtuelle Instanz zugeschnitten sind. Dies bedeutet, dass lediglich Ausschnitte des Netzwerkverkehrs zur und von der virtuellen Instanz aufgezeichnet werden, die der Kunde anschließend, eventuell sogar gegen eine entsprechende finanzielle Aufwendung, erhält. Des Weiteren könnte der CSP diese Logfiles dem Kunden nur für einen beschränkten Zeitraum zur Verfügung stellen, um unnötigen Verbrauch von Speicherplatz zu vermeiden. Essenziell wäre allerdings, dass der Kunde nur Beweismaterial für seine virtuellen Instanzen erhält und nicht die der benachbarten Instanz.

Für den Kunden hätte dies aber einen entscheidenden Vorteil: Bei einer Kompromittierung wäre es nun möglich, Beweismaterial vom Client mit der Netzwerkschicht und dem Server (IaaS-Instanz) zu korrelieren, unter der Voraussetzung, dass Logfiles der IaaS-Instanz in regelmäßigen Abständen auf einen externen Logfile-Server geschrieben werden. Ansonsten könnte ein Angreifer nach erfolgreichem Eindringen in die IaaS-Instanz die entsprechenden Logfiles löschen oder verändern.

Um solche Angriffe zu verhindern, wäre auch ein Service mittels Virtual Introspection vonseiten des CSP möglich. Hierbei würde sich der Kunde damit einverstanden erklären, dass der CSP mit automatisierten Werkzeugen über den Hypervisor in regelmäßigen Abständen den Systemzustand der virtuellen Instanz überprüft und entsprechende Log-Einträge erstellt. Diese könnten selbst von einem Angreifer nur über eine vollständige Kompromittierung des Hypervisors verfälscht werden [9].

Ansätze für SaaS-Umgebungen

In SaaS-Umgebungen kann der Kunde lediglich über eine vorgefertigte API mit dem Service kommunizieren. Oftmals wird dies direkt über eine Web-Schnittstelle realisiert. Dies kann Vor- und Nachteile haben – ausschlaggebend ist allerdings, dass der Kunde sich nicht um die Sicherheit der Anwendung kümmern muss, die in den Händen des CSP liegt. Allerdings ist er im Gegenzug sehr eingeschränkt, was die Flexibilität der Anwendung angeht: Funktionen, die der CSP nicht implementiert hat, kann er nicht selbst nachreichen. Ein Beispiel hierfür ist die Machbarkeit von forensischen Untersuchungen in SaaS-Szenarien, wie das obige Beispiel aufgezeigt hat. Allerdings gibt es Möglichkeiten, diese Situation zu ändern: Der CSP könnte eine zusätzliche Forensik-Schnittstelle anbieten, mit deren Hilfe der Anwender spezifische Zugriffe auf Datensätze in der SaaS-Anwendung nachvollziehen könnte. Diese Datensätze könnten beispielsweise aus E-Mails, Kundendaten und Finanzdaten bestehen und es ist daher für den Kunden des Cloud-Dienstes erforderlich, nachzuprüfen, wer wann und wie auf diese Daten zugegriffen hat. Eine solche Forensik-Schnittstelle wäre Teil eines größeren Provenance-Frameworks, das alle lesenden und schreibenden Zugriffe auf Datensätze protokolliert. Im Verdachtsfall kann der Anwender somit die API nach entsprechenden Zugriffen befragen und könnte Angriffe wie im obigen Szenario schneller erkennen. Zudem könnten auch automatisierte Evaluierer dafür sorgen, dass keine unrechtmäßigen Fremdzugriffe stattfinden. Für den CSP gestaltet sich die Implementierung einer solchen Schnittstelle einfacher als bei anderen Service-Modellen, da der Kontext der schützenswerten Daten klar ersichtlich ist. Wird beispielsweise bei einem PaaS-Dienst eine API-Funktion für das Speichern einer Datei angesprochen, kann durch Protokollierung des Function Calls erst einmal nur festgestellt werden, dass eine Datei gespeichert wurde. Der weitere Kontext der Datei ist für den CSP unklar. Bei einem SaaS-Dienst ist dies anders: Der Kontext der Daten ist für den CSP klar ersichtlich.

Das Datenformat einer solchen Schnittstelle könnte sich bereits bestehende Datenformate zunutze machen, um so eine Interoperabilität zwischen verschiedenen Tools und Frameworks zu gewährleisten. Ein bekanntes Format ist beispielsweise DFXML von Simson Garfinkel [11], bei welchem es sich um ein XML-Format zur Beschreibung forensischer Informationen handelt. Die Verwendung eines offenen Datenformats hätte den Vorteil, dass bestehende Forensik-Projekte an diese Schnittstelle mit angeschlossen werden könnten. Im Idealfall wäre es dem Kunden somit möglich, firmeninterne Forensik-Frameworks lediglich um den Cloud-Service zu erweitern.

Um weitere Anforderungen wie Integrität, Authentizität und Vertraulichkeit zu gewährleisten, ließen sich im Falle von DFXML bestehende XML-Frameworks zum Signieren und Verschlüsseln nutzen. Dies bedeutet, dass die Log-Informationen in Form von XML über eine API an den Kunden ausgegeben werden und zusätzlich vom CSP signiert oder bei Bedarf auch verschlüsselt werden können. Pauschal ist allerdings nicht zu sagen, welche konkrete Informationen der Kunde für eine eventuelle Untersuchung benötigt – dies hängt sehr stark vom jeweiligen Szenario ab.

Zuletzt wäre noch zu klären, wie lange der CSP die Daten zur Verfügung stellen soll. Auch dies ließe sich individuell im SLA festhalten. Zudem besteht für den Kunden die Möglichkeit, die Daten direkt aus der Schnittstelle zu extrahieren und in eigene Logging-Server zu integrieren.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019