der Ideenphase, und eine mögliche Umsetzung mit allen Vorgaben kann frühzeitig mit beispielsweise einem Prototyp überprüft werden. Durch weitere Einhaltung der Sicherheitsvorgaben in den weiteren Produktionsstufen erfüllt das fertige Produkt bestenfalls alle Erfolgskriterien.
Sieben Grundregeln zur Reduzierung der Risiken sollten durch Unternehmen berücksichtigt werden:
1. Angriffsfläche klein halten
Die Angriffsfläche lässt sich deutlich minimieren, indem Überflüssiges deaktiviert wird. Deaktivierte, nicht benötigte Softwareprogramme und Komponenten auf IT-Systemen können auch nicht angegriffen werden.
2. Geeignet authentifizieren und autorisieren
Vertrauliche Informationen und Informationssysteme sollten nur für die gewünschten Kommunikationspartner zugänglich und im erforderlichen Umfang nutzbar sein.
3. Eingaben überprüfen
Jede Eingabe sollte auf zulässige Zeichen, insbesondere Sonderzeichen, und auf die maximal zulässige Eingabelänge geprüft werden. Ein Beispiel: Bei der Bestellung auf einem Web-Portal sind im Feld für das Geburtsdatum des Nutzers nur Zahlen und möglicherweise noch Punkte erforderlich. Ziel hierbei ist die wirksame Verhinderung von Pufferüberläufen oder die Einspeisung von als Code interpretierbaren Zeichenketten.
4. Systeme trennen
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