Nach einem erfolgreichen Angriff auf ein System versuchen Angreifer häufig, von dort nach und nach Zugriff auf weitere Systeme zu erhalten. Systeme sollten daher voneinander getrennt werden und über eine abgesicherte Netzwerkverbindung miteinander kommunizieren.
5. Vertrauliches verschlüsseln
Der Zugang zu Systemen der Datenspeicherung, -verarbeitung und -übermittlung liegt meistens nicht vollständig in der Hand des eigenen Unternehmens, etwa wenn Cloud-Dienste genutzt werden. Umso wichtiger ist es, vertrauliche Informationen zu schützen.
6. Regelmäßig aktualisieren
Systeme sind schutzlos, wenn sie nicht stets auf einen aktualisierten Versionsstand gebracht werden. Nur so wird verhindert, dass Angreifer bekannte Sicherheitslücken nicht ausnutzen können. Neue Versionsstände enthalten zum Beispiel oftmals Abwehrmechanismen gegen bekannt gewordene Sicherheitslücken der Vorgängerversionen.
7. Sicherheit kontinuierlich testen
Der Zustand der Systeme muss im Hinblick auf ihre Sicherheit und Angreifbarkeit kontinuierlich durch Security-Checks wie der Überprüfung der Konfiguration und möglicher Sicherheitsschwachstellen kontrolliert werden.
3.4 Sicherheit in agilen Entwicklungsprozessen
Bisher war die Sicherheit bei der Softwareentwicklung die Aufgabe von Fachspezialisten innerhalb der Endphase der Entwicklung. Bei der Verwendung des Wasserfallmodells sowie längeren Projektlaufzeiten (Monate oder Jahre) war das auch kein größeres Problem. Mit Verwendung von modernen agilen Entwicklungsprozessen bzw. DevOps-Ansätzen könnten veraltete Methoden zur Einhaltung von Sicherheitsstandards sich eher nachteilig für Unternehmen auswirken. Bei schnelleren und häufigeren Entwicklungszyklen (Wochen oder Tage) wird die Agilität ausgebremst
Mit einem kollaborativen DevSecOps-Ansatz wird die Sicherheit von Anwendungen und der Infrastruktur von Anfang an in den Ablauf der Softwareentwicklung integriert und durch Automatisierung von wiederholenden Aufgaben (wie z. B. Funktionstests und Sicherheitsprüfungen) sowie den dazu passenden Tools unterstützt. Hierbei ist eine andere Kultur der frühen Zusammenarbeit zwischen Entwicklern und Sicherheitsspezialisten erforderlich.
4 Veränderte Bedrohungslage durch Cloud-Nutzung
Nach der Klärung wesentlicher Sachaspekte der Cloud muss die Frage gestellt werden, inwiefern die Cloud zu einer veränderten Bedrohungslage und damit zu einer notwendigen Veränderung der IT-Security-Kontrollelemente führt. Hierbei steht die Public Cloud im Vordergrund, da sie die prominenteste und am meisten genutzte Verbreitungsform darstellt. Durch die Nutzung von Public-Cloud-Lösungen gewinnen einige bisher eher unbedeutende Bedrohungsszenarien wesentlich an Bedeutung, andere verändern sich oder kommen neu hinzu. Beispielhaft ist hierbei die Co-Location von eigenen Unternehmensressourcen mit denen von beliebigen anderen Cloud-Nutzern (inkl. von Einzelpersonen) auf derselben Hardware (Computer, Storage etc.). Daraus resultierende Gefahren sind oft nicht im Bedrohungskatalog klassischer IT-Modelle enthalten.
4.1 Exponierte Lage
Die wohl wesentlichste Veränderung aus IT-Security-Sicht ist jedoch das „public“ in Public Cloud. Ressourcen, insbesondere die Control und Data Plane, sind öffentlich zugänglich. Um den Zugriff einzuschränken, muss vielfach erst eine entsprechende Absicherung erfolgen. Grundlegende Funktionen, wie z. B. das Cloud-Management-Portal bzw. die API, bleiben jedoch immer uneingeschränkt aus dem Internet erreichbar. Maßgeblich ist daher der Schutz der Zugriffsinformationen (z. B. Benutzername/Passwort, API Keys etc.). Hier muss das Schutzniveau deutlich erhöht werden, da Identitäten der Dreh- und Angelpunkt sind („Keys to the Kingdom“). In diesem Zusammenhang kann daher von den Identitäten als dem neuen Perimeter gesprochen werden. Der Verlust einer Identität, z. B. durch Phishing, wird bei öffentlich zugänglichen Ressourcen immer unmittelbare, negative Konsequenzen haben. Ein weiteres Problem ist die unbeabsichtigte Veröffentlichung von Cloud API Keys in öffentlichen Repositorien (z. B. GitHub). Zahlreiche Fälle der letzten Jahre haben dies immer wieder verdeutlicht.
Während in der klassischen IT im eigenen Rechenzentrum eine Fehlkonfiguration, wie z. B. ein unsicherer Dienst im internen Netz, nicht unmittelbar zu Problemen führt und der Fehler ggf. erst deutlich später auffällt, wird eine Fehlkonfiguration in der Cloud möglicherweise bereits wenige Minuten später ausgenützt. Dies war wiederholt die Ursache größerer Offenlegungen von Daten bei zahlreichen Firmen. Während es in der Vergangenheit als Best Practice angesehen wurde, z. B. mit einen Schwachstellenscanner regelmäßig (z. B. monatlich) das eigene, interne Netz zu durchsuchen, ist dies in der Cloud nicht mehr adäquat. Es benötigt vielmehr neue Wege, um auf Fehlkonfigurationen in der Cloud zu reagieren. Hier kommt eine entsprechende Automatisierung zum Tragen, die bei erkannten Fehlkonfigurationen sofortige Gegenmaßnahmen ergreift, da bis zu einem manuellen Eingreifen zu viel Zeit vergehen würde. In dieser Zeit könnten die fehlkonfigurierten Cloud-Dienste bereits angegriffen werden.
Ein weiteres Problem entsteht durch die Nutzung von Daten oder Software aus öffentlichen Quellen, wie z. B. dem Cloud Marketplace, GitHub oder aus Container-Repositories. Bei diesen, speziell bei Entwicklern, gerne genutzten Quellen stehen schnell notwendige Anwendungskomponenten zur Verfügung. Der Sicherheitsstatus solcher Ressourcen ist jedoch meist unklar. Neben der Möglichkeit von Hintertüren besteht die Gefahr, dass eine Weiterentwickelung und damit notwendige Sicherheitsupdates nicht stattfinden und damit eventuell vorhandene funktionale Fehler oder Sicherheitsschwachstellen nicht kurzfristig behoben werden können.
Um auf diese Bedrohungen angemessen reagieren zu können, sind Automatismen entscheidend. Gegenmaßnahmen sollten dabei unmittelbar beim Auftreten eines kritischen Ereignisses ausgelöst werden („event driven security“). Hierfür stehen zahlreiche Mechanismen in der Cloud zur Verfügung. Durch geeignete Kombination und der Nutzung von (serverless) Funktionen können damit beliebig komplexe Workflows ausgelöst werden. Dies auch als Cloud Security Posture Management (CSPM) bezeichnete Vorgehen kann sowohl durch Cloud-Native-Werkzeuge als auch durch Drittanbieterprodukte unterstützt werden. Wesentlich hierbei sind die kuratierten Prüfungen, bereits definierte Abwehrmaßnahmen und speziell bei Drittanbietern die Multi-Cloud-Funktionalität. Diese Werkzeuge bilden in der Regel gängige Security-Best-Practice-Empfehlungen, wie z. B. vom Center of Internet Security (CIS), ab. Neben der unmittelbaren Konfigurationsüberwachung sind auch die Themen Logging & Monitoring inkl. Security Operation Center, Datenverschlüsselung sowie das Identity Management wesentliche Schlüsselelement für einen sicheren Cloud-Betrieb. Speziell bei Letzterem sind Strategien für den bedingten Zugriff, die Mehrfaktorauthentifizierung sowie das Management privilegierter Zugriffe wichtige Schlüsselelemente. Analysewerkzeuge der Cloud Service Provider können dabei unterstützen, von den durch die Governance vorgegebenen Richtlinien oder bewährten Best Practices abweichende Konfigurationen oder Berechtigungen zu erkennen. Auch ein entsprechendes Netzdesign in der Cloud bietet zusätzlichen Schutz. Dies kann z.B. über ein Landing-Zone-Konzept erzwungen werden. Ziel der Netzwerkarchitektur sollte dabei sein, Ressourcen auch bei einer Fehlkonfiguration vor unmittelbaren Angriffen zu schützen. Werden diese Maßnahmen geeignet kombiniert, automatisiert und weiterentwickelt, kann dadurch eine kontinuierliche Sicherheit erreicht werden.
4.2 Cloud-Technologie und Governance
Auch die Cloud selbst und deren Dienste
