Ihre Cloud-Security-Empfehlungen für 2021

Ihre Cloud-Security-Empfehlungen für 2021 (vorausgesetzt, 2020 endet jemals)

2020. DAS ist also gerade passiert.

In Sachen Cloud-Sicherheit war 2020, als hätte man Raketentreibstoff in ein Benzinfeuer gegossen; aus unseren Dreijahresplänen wurden Umsetzungen in drei Monaten. Und wie ein schön wärmendes Feuer bringt das Vorteile, Chancen, aber auch eine gewisse Gefahr mit sich. Persönlich hat die Pandemie den Großteil meiner Reisetätigkeit beendet und mir tatsächlich geholfen, mehr Arbeit mit einer vielfältigeren Kundenbasis zu erledigen. Während wir alle so tun, als bekämen wir die Gelegenheit, herunterzufahren und die Feiertage zu genießen (was nie wirklich so aufgeht), dachte ich, es wäre ein guter Zeitpunkt, einige der Trends und Lehren zusammenzutragen, die ich gelernt habe und die wir für unsere gemeinsame Planung für 2021 nutzen können.

Wie der große Autor Terry Pratchett einmal sagte: „Mache einem Menschen ein Feuer, und er ist für einen Tag warm. Stecke einen Menschen in Brand, und er ist für den Rest seines Lebens warm.“ Bei 2021 geht es darum, die Feuer so zu steuern, dass sie Wachstum befeuern, ohne Ihr Haus niederzubrennen.

Ich habe einige Cloud-Security-Empfehlungen zusammengestellt, die viele der häufigen systemischen Schwachstellen adressieren, die mir in Projekten begegnet sind, die sich aber auch sinnvoll schrittweise angehen lassen. Wir haben die Cloud-Einführung 2020 erheblich beschleunigt, und das bedeutete, dass viele Organisationen schnell vorgingen, ohne Zeit für ein solides Fundament zu haben. Das ist völlig normal, aber wir sollten nicht zu lange warten, bis wir die Grundlagen nachziehen. Jeder der nachfolgenden Punkte korreliert mit den Ursachen einiger sehr öffentlichkeitswirksamer Fehlschläge.

Beginnen Sie damit, die Cloud-Governance in Ordnung zu bringen

2020 habe ich mit Dutzenden Organisationen gearbeitet und mit Hunderten weiteren gesprochen. Mangelhafte Governance ist mit Abstand das durchgängigste Problem, das ich in der Cloud sehe. Das tritt in verschiedenen Ausprägungen auf. Am häufigsten sehe ich die beiden Extreme: Entweder legt die Organisation den Entwicklern überhaupt keine Beschränkungen auf, oder die Security schnürt alles in Standardmuster ein, die nicht cloudtauglich sind. Ich schlage vor, sich in der Mitte zu treffen: Verlangen Sie eine Freigabe durch die Security für alle neuen Provider und Services und geben Sie der Security die Befugnis, „Nein“ zu sagen – aber nur, wenn sie ihre Begründung darlegen kann. Verpflichten Sie die Security dann dazu, cloudnative Richtlinien und Verfahren zu entwickeln, die cloudnative Praktiken widerspiegeln, statt ihr gesamtes ärgerlich langsames und kontraproduktives Rechenzentrums-Security-Tooling mitzubringen. Bringen Sie alle in einem Cloud Center of Excellence an einen Tisch. Ein sehr großer Teil der Sicherheitsvorfälle in der Public Cloud, die wir sehen, hat seine Wurzeln in gescheiterter Governance und nicht in gescheiterter Technologie.

Apropos Governance: Dies ist ein guter Zeitpunkt, das Konzept des „Security Champion“ einzuführen

Security Champions sind keine BISOs (Business Information Security Officers); es sind lokale Entwickler oder Administratoren in Projektteams, die etwas zusätzliche Schulung erhalten, bei Gremiensitzungen kostenlose Pizza bekommen (die lässt sich liefern, bis die COVID-Quarantänen vorbei sind) und als Bindeglied zwischen einem Projekt und einem Security-Team dienen. Betrachten Sie sie als Ansprechpartner und Fürsprecher.

Verbessern Sie Ihre Transparenz in der Cloud-Sicherheit

Ein weiteres häufiges Governance-Problem besteht darin, die Security bis auf etwas Logging von den Cloud-Konten auszusperren. Beheben Sie das 2021, indem Sie der Security Tooling und Lesezugriff auf jedes Cloud-Deployment bereitstellen (einschließlich Dev-/Test-/Sandbox-Umgebungen) und darüber hinaus einen Notfall-Lese-/Schreibzugriff für die Incident Response. Im Gegenzug legt die Security Richtlinien fest, sodass sie Notfalländerungen nur in den schlimmsten Fällen selbst durchführt, wenn sie das Deployment-Team für die Behebung nicht erreichen kann. Die Transparenz sollte den laufenden Konfigurationszustand der Deployments (CSPM) sowie Event- und Log-Feeds von Echtzeitänderungen (CDR) umfassen.

Wenn Sie nicht mehrere Konten nutzen, um den Wirkungsradius von Angriffen zu begrenzen, fangen Sie jetzt damit an

Ich meine damit nicht nur Prod und Non-Prod, sondern mehrere Konten pro Anwendungsstack. Warum? Weil Identität der neue Perimeter ist und es umso schwieriger wird, Least-Privilege-Kontrollen umzusetzen, je mehr Sie in wenige große Umgebungen hineinschaufeln. Und zwar unmöglich viel schwieriger. 2021 können Sie mit einer Regel „Neues kommt in ein neues Konto“ beginnen. Ich verberge hier eine Menge Komplexität, vor allem auf der Netzwerkseite, wenn Sie App-Stacks miteinander verbinden müssen, aber diese Probleme sind lösbar, sobald Sie cloudnative Muster einsetzen – und der Nutzen ist enorm.

Heben Sie Ihre cloudnative Incident Response auf das nächste Niveau

Ich sehe die Incident Response in zweierlei Hinsicht zurückfallen. Erstens zeigt sich, dass die Standard-Logging-Muster in der Dokumentation der Cloud-Anbieter typischerweise nicht ideal sind, mit langen Verzögerungen zwischen dem Eintreten eines Events und dem Erscheinen einer Benachrichtigung. Am deutlichsten ist das bei AWS, aber alle Anbieter kämpfen damit. Wenn Sie sich auf Standard-SIEM-Anbindungen verlassen, geben Sie Angreifern möglicherweise große Zeitfenster. Zweitens ist der Response-Prozess selbst nicht sauber definiert und mit Werkzeugen ausgestattet. Manuelle Reaktionen auf automatisierte Angriffe sind ein aussichtsloses Unterfangen. Schulen Sie 2021 Ihr IR-Team, optimieren Sie Ihr eventbasiertes Alerting und beginnen Sie, Reaktionsfenster durch Incident-Routing und Automatisierung zu schließen. Und ja, ich empfehle hier mein eigenes Produkt, aber wir haben es nicht nur zum Spaß gebaut. Vieles davon können Sie durchaus selbst mit Open Source und eigenem Code umsetzen, wenn Sie für kommerzielles Tooling noch nicht bereit sind.

Prüfen Sie Ihre IAM-/RBAC-Umsetzung von oben bis unten und ziehen Sie sie straffer

Reduzieren Sie unnötige Berechtigungen und fügen Sie so weit wie möglich Ressourcenbeschränkungen hinzu. Aktivieren Sie jedes einzelne identitätsbezogene Analyse- und Alerting-Werkzeug, das Ihr Cloud-Anbieter bietet. Beginnen Sie, Attribute und bedingte Richtlinien zu nutzen. Sehen Sie: Jeder einzelne größere Public-Cloud-Sicherheitsvorfall im Jahr 2020 beruhte auf einem IAM-Versagen – verlorene Zugangsdaten, zu viele Berechtigungen oder keine MFA bzw. keine bedingten Beschränkungen zur Kontrolle des IAM-Perimeters. Wenn Sie 2021 etwas brauchen, das Sie nachts wachhält, dann ist es das.

Governance. Grundlegende Shared Services. Ein paar taktische Verbesserungen. Wir sind über den Punkt hinaus, an dem jedes Jahr Cloud Computing völlig neue Programme und Werkzeuge zu erfordern schien. 2021 geht es darum, die Grundlagen sauber umzusetzen, sie aber im Hinblick auf Skalierbarkeit, Wirksamkeit und Kosten zu verbessern. Wir wissen sehr viel mehr darüber, welche Praktiken am besten funktionieren, als noch vor wenigen Jahren, und entscheidend ist, die Gelegenheiten zur Modernisierung zu nutzen und die Altlasten fallen zu lassen, die wirklich nicht gut funktionieren.