Umgang mit Cloud-basierten Sicherheitsrisiken und Governance

Die Umstellung auf cloudbasierte Dienste (d. h. Azure, AWS und Google Drive) hat ihre eigenen Auswirkungen – nicht zuletzt auf die Sicherheit – und bietet Geschäftseffizienz, Kostenvorteile und Wettbewerbsvorteile. Viele gehen davon aus, dass der Wechsel zu cloudbasierten Diensten und der Einsatz ihrer Sicherheitstools bereits bestehende Sicherheitslücken oder -mängel beheben wird – aber das ist einfach nicht der Fall.

Public Clouds bieten Perimetersicherheit für die in ihren Rechenzentren gespeicherten Daten, was eine wichtige Funktion ist. Doch das ist nur ein Aspekt unter vielen, um Sicherheit zu gewährleisten.

CIOs sprechen oft von der Notwendigkeit, sichere Container zu bauen, um die Markteinführung zu beschleunigen. Obwohl der Fokus im Cloud-Bereich in letzter Zeit auf Kubernetes und Containerisierung liegt, lassen Sie uns den Wald für die Bäume nicht verlieren. Die Sicherheitsanforderungen sind weitreichend, und Kubernetes ist nur ein kleiner Teil dieser Gleichung.

Weitere wichtige Komponenten sind Compliance-Überlegungen, DevOps-Automatisierung und die Schaffung einer robusten Testplattform, die statische (im Vergleich zu dynamischen) Schwachstellenscans umfasst.

Compliance-Erwägungen

Verschiedene Industriesparten (z. B. Gesundheitswesen) haben ihre eigenen komplexen, starren Compliance-Standards, deren Aufrechterhaltung bekanntermaßen kostspielig und aufwändig ist. Und die Aktualisierung von Applications und Infrastruktur, um Compliance-Standards zu erfüllen, birgt häufig verschiedene Sicherheits- und Compliance-Schwachstellen.

Aber wie ich bereits erwähnt habe, können Sie Schwachstellen bekämpfen, indem Sie in Automatisierung und Sicherheitsscans für die Codeentwicklung und -bereitstellung investieren. Die Automatisierung dieser Prozesse bedeutet einen schnelleren Zugriff auf Informationen, die Sicherheitslücken identifizieren können, damit Sie effizienter darauf reagieren können.

Sobald Sie Ihre Sicherheitslücken identifiziert haben, ist es nur natürlich, sich zu fragen, welche Sicherheitsfunktionen Ihre cloudbasierten Dienste erfüllen können und für die Sie weiterhin verantwortlich sein müssen. Wie ein Unisys-Kollegen erklärte, ist die Realität, dass Cloud-Sicherheit eine gemeinsame Verantwortung ist.

Wie ich bereits erwähnt habe, kümmern sich Cloud-basierte Dienstleister in der Regel um die Perimetersicherheit für Daten, die Sie in ihren Rechenzentren speichern, sowie um begrenzte Compliance-Kontrollen für die Infrastruktur. Für jede Anwendung, die Sie in die Cloud verlagern, sind Sie jedoch für die Konfiguration geeigneter Sicherheitskontrollen, die Identifizierung und Zertifizierung der Einhaltung von Compliance-Anforderungen und das Management des Datenlebenszyklus verantwortlich.

Wenn das viel zu bewältigen scheint, dann ist es so.

Wie können Sie es einfacher machen? Durch den Einsatz von Automatisierung.

DevSecOps Automatisierungskultur

Die kontinuierliche, kontinuierliche Bewertung Ihres Netzwerks und Ihrer Anwendungen und die Berichterstattung über alle von Ihnen identifizierten Nichtkonformitäten oder potenziellen Risiken ist ein unglaublich mühsamer und traditionell manueller Prozess. Stellen Sie sich vor, Sie gießen über Dutzende – wenn nicht Hunderte – von Compliance-Standards, stellen sicher, dass jeder von ihnen erfüllt wird, und kennen die Folgen, wenn diese Standards nicht erfüllt werden.

Eine der Herausforderungen bei der Einbettung von Sicherheit besteht darin, die Denkweise des Unternehmens zu ändern. Mit der DevSecOps-Kultur sind Entwickler nicht nur „sicherheitsbewusst“, sondern können auch als erste Verteidigungslinie agieren. Verstehen, dass eine sicherheitsbewusste Kultur für die Mitglieder aller funktionalen Teams notwendig ist, um potenzielle Anomalien zu melden. Übersetzen Sie anwendbare Kontrollen (Policy-as-Code) in geeignete Softwarekomponenten im Rahmen des sich weiterentwickelnden SDLC-Prozesses.

Dies ist jedoch ein Rezept für Fehler, die mit einer hohen Geldstrafe verbunden sein können.

Statt sich unnötigen Haftungsrisiken auszusetzen, bauen Sie eine DevSecOps-Automatisierungskultur auf. Durch die Automatisierung der Risikoberichterstattung und -überwachung stellen Sie sicher, dass Ihr Netzwerk und Ihre Applications ständig überwacht werden.

Testing-as-a-Service

Sie denken vielleicht, dass Automatisierung großartig ist, aber eine ständige Risikoüberwachung ist teuer und erfordert, dass Sie sie von Grund auf neu aufbauen. Deshalb sollten Sie Tests als Dienstleistung betrachten.

Mit Testing as a Service können Sie eine zentrale Organisation beauftragen, die das Prüfgerät im Auftrag Ihres Unternehmens handhabt. Solche Tests sind nicht sicherheitsspezifisch. Sie kann auch auf Integration, Regression, Leistung und mehr angewendet werden. Dies ist in der Regel kostengünstiger als die Schaffung der Infrastruktur und Organisation rund um eine so robuste Testplattform im eigenen Haus.

Sie müssen nicht von Grund auf neu beginnen, wenn Sie sofort einsatzbereite Testfunktionen von einem externen Anbieter erwerben können – oder noch besser, wenn Sie den Anbieter bitten, ein spezielles Testprogramm für Ihr Unternehmen zu erstellen.

Fordern Sie sie beispielsweise auf, die End-to-End-Testing-as-a-Service-Vorlagen (Testplanung, -ausführung und -berichterstattung) mit Wiederverwendbarkeit, Wartungsfreundlichkeit und Kostensenkung als Kernziele zu standardisieren. Dies gibt Ihnen die Flexibilität, die Fähigkeiten zu erweitern, ohne dass Anbieter eingebunden werden müssen, und stellt sicher, dass Sie die Public-Cloud-Anbieter herausfordern, die schweren Aufgaben für Sie zu erledigen. Sie könnten für Sie einen Rahmen wie den folgenden schaffen:

• Framework: Maven Page Objektmodell-Framework
• Programmiersprache: Java
• Plattformen: Web-App (Selenium), Mobile (Appium), API-Tests (REST Assured), Datenbank (PostgreSQL)
• Testen: Performance (Jmeter), Sicherheit durch statische und dynamische Schwachstellen-Scans (Veracode)
• Berichterstattung: Ausmaßbericht, Log4J
• CI (kontinuierliche Integration) und CD (kontinuierliche Bereitstellung): Azure DevOps

Wenn Sie Ihre Strategie für das Testen auf potenzielle Schwachstellen entwickeln, müssen Sie auch die Vor- und Nachteile dynamischer oder statischer Scans abwägen.

Statische Scans werden bei ausgeschalteter Anwendung durchgeführt und beinhalten die Untersuchung von Quellcode oder Applications-Binärdateien zur Identifizierung von Sicherheitslücken. Wenn Sie Millionen von Codezeilen untersuchen, kann dieser Prozess schnell umständlich und hochgradig ineffizient werden.

Dynamisches Scannen findet während der Ausführung der Anwendung statt und beinhaltet die Manipulation der Anwendung – wie sie in der realen Welt verwendet werden würde – um Risikobereiche zu entdecken. Dies ist in der Regel umfassender, aber auch eine ineffiziente Methode zum Scannen, da ich festgestellt habe, dass 10 Millionen Codezeilen mehr als einen Monat in Anspruch nehmen können.

Es geht nicht darum, zwischen statischem und dynamischem Scannen zu entscheiden. Sie sollten verstehen, dass Sie Testanbieter herausfordern müssen, um eine bessere Alternative zu entwickeln. Diese Alternative könnte durch technologische Innovationen oder Verbesserungen beim dynamischen Scannen erreicht werden. Unternehmen spielen auch eine Rolle bei der Optimierung von Sicherheitsscans, unter anderem durch Refactoring und Modernisierung ihres Codes.

Wenn Sie jedoch nur eine Lektion aus diesem Artikel lernen, sollten Sie sich um die kontinuierliche Sicherheit Ihrer Cloud Applications kümmern. Vermeiden Sie die Wiederholung von Vorgängen, die Sie mit älteren On-Premise-Bereitstellungen getan haben. Zukunftsorientierte Sicherheitsakteure wissen, dass der beste Weg, um zukünftige Haftungsrisiken zu vermeiden, die Implementierung eines robusten Sicherheitsprogramms von Anfang an ist.