Mit CloudHealth Secure State hat VMware einen SaaS-Dienst für das Monitoring der Sicherheit und Compliance in Public Clouds im Angebot. Die Software erkennt Fehlkonfigurationen und bringt dazu passende Regelsätze für die großen Cloudanbieter Amazon, Microsoft und künftig auch Google mit. IT-Administrator hat sich angesehen, wie sich Secure State in der Praxis schlägt.
In den meisten Unternehmen sind Public Clouds inzwischen Teil der IT-Infrastruktur, verheißen die Provider doch Flexibilität beim Hinzufügen und Entfernen benötigter Ressourcen. Das freut insbesondere Entwickler, die, agilen Methoden wie DevOps folgend, ihre Ressourcen selbst verwalten und nicht mehr von einer klassischen IT-Abteilung abhängig sein möchten. Doch des einen Freud ist bekanntlich des anderen Leid und den Informationssicherheitsbeauftragten sträuben sich die Haare beim Gedanken, das Management von Clouddiensten auf viele Köpfe zu verteilen. Schnell gibt eine Fehlkonfiguration sensible Daten preis oder öffnet Angreifern Tür und Tor. Hier verspricht CloudHealth Secure State Abhilfe.
Bereits im Jahr 2018 hat VMware die Softwareschmiede CloudHealth Technologies übernommen. Unter dem Label "CloudHealth by VMware" betreibt die Unternehmenssparte seitdem mit ihrer "CloudHealth Multicloud Platform" ein SaaS-Angebot, das das Kostenmanagement in Multicloud-Szenarien erleichtern soll.
Als weiteren, separat erhältlichen Baustein ergänzte der Hersteller mit "CloudHealth Secure State" einen Dienst, der speziell die Einhaltung von Anforderungen an Sicherheit und Compliance in den Fokus stellt. Das Angebot firmierte ursprünglich unter dem Namen "VMware Secure State" (VSS) und diese Bezeichnung findet sich auch heute noch an einigen Stellen im Produkt und in der Dokumentation. Aktuell betreibt VMware das Backend der Lösung ausschließlich in den USA. Weitere geografische Regionen, darunter Europa, sollen laut Hersteller zukünftig folgen.
In den meisten Unternehmen sind Public Clouds inzwischen Teil der IT-Infrastruktur, verheißen die Provider doch Flexibilität beim Hinzufügen und Entfernen benötigter Ressourcen. Das freut insbesondere Entwickler, die, agilen Methoden wie DevOps folgend, ihre Ressourcen selbst verwalten und nicht mehr von einer klassischen IT-Abteilung abhängig sein möchten. Doch des einen Freud ist bekanntlich des anderen Leid und den Informationssicherheitsbeauftragten sträuben sich die Haare beim Gedanken, das Management von Clouddiensten auf viele Köpfe zu verteilen. Schnell gibt eine Fehlkonfiguration sensible Daten preis oder öffnet Angreifern Tür und Tor. Hier verspricht CloudHealth Secure State Abhilfe.
Bereits im Jahr 2018 hat VMware die Softwareschmiede CloudHealth Technologies übernommen. Unter dem Label "CloudHealth by VMware" betreibt die Unternehmenssparte seitdem mit ihrer "CloudHealth Multicloud Platform" ein SaaS-Angebot, das das Kostenmanagement in Multicloud-Szenarien erleichtern soll.
Als weiteren, separat erhältlichen Baustein ergänzte der Hersteller mit "CloudHealth Secure State" einen Dienst, der speziell die Einhaltung von Anforderungen an Sicherheit und Compliance in den Fokus stellt. Das Angebot firmierte ursprünglich unter dem Namen "VMware Secure State" (VSS) und diese Bezeichnung findet sich auch heute noch an einigen Stellen im Produkt und in der Dokumentation. Aktuell betreibt VMware das Backend der Lösung ausschließlich in den USA. Weitere geografische Regionen, darunter Europa, sollen laut Hersteller zukünftig folgen.
Mit KI gegen Schwachstellen
Das Produkt ist darauf spezialisiert, Sicherheitslücken und Fehlkonfigurationen in den Public Clouds der großen Hyperscaler – Amazon Web Services (AWS), Microsoft Azure sowie zukünftig Google Cloud Platform (GCP) – zu erkennen. Dazu benötigt Secure State zunächst nur lesenden Zugriff auf die API der jeweiligen Cloudumgebung. Darüber liest Secure State sämtliche dort vorhandenen Elemente ein und erstellt ein typischerweise einmal täglich aktualisiertes Inventar.
Weiterhin kann Secure State nahezu in Echtzeit Ereignisse, etwa zu Konfigurationsänderungen oder Start und Stopp von Ressourcen, empfangen. Alle Informationen integriert Secure State zu einem Datenmodell, das VMware als "Interconnected Cloud Security Model" (ICSM) bezeichnet. Die Software analysiert die im ICSM enthaltenen Assets und Aktivitäten mittels künstlicher Intelligenz. Sie versucht, die Beziehungen zwischen Assets sowie Anomalien zu erkennen, und berechnet pro Ressource mit dem "Risk Score" eine Bewertung des Risikos. Dies hilft Admins bei der Priorisierung der gefundenen Sicherheitslücken und Fehlkonfigurationen mit dem höchsten Schadenspotenzial. Bei der Bewertung bedient sich Secure State insgesamt über 500 Regeln, die typische Fehler und Bedrohungen in AWS, Azure und GPC beschreiben.
Arbeiten diverse Teams unabhängig voneinander mit verschiedenen Cloudaccounts, erlaubt Secure State, diese in Projekte zu unterteilen und abgestuft den Zugriff zu delegieren. So können Entwickler direkt einsehen, wie es um die Sicherheit in ihrem Zuständigkeitsbereich bestellt ist, während übergeordnete Admins den Überblick über alle Cloudaktivitäten im gesamten Unternehmen behalten.
Mit einer zum Zeitpunkt unseres Tests nur als Beta-Version verfügbaren Funktion, die der Hersteller als "Auto-Remediation" oder einfach nur "Remediation" bezeichnet, soll Secure State auch automatisch Fehlkonfigurationen abstellen können, doch dazu später mehr.
Nutzungsbasierte Abrechnung
Das Abrechnungsmodell von Secure State basiert auf der Anzahl der von der Software überwachten Cloudobjekte. Dabei stehen vor allem Compute- und Datenbank-Ressourcen im Vordergrund. VMware pflegt in der Onlinedokumentation eine Liste der Ressourcen, die in die Abrechnung eingehen.
Im Webfrontend weist Secure State pro Monat die Gesamtzahl überwachter Objekte aus und schlüsselt diese auch nach Typen auf. So sind etwa virtuelle Maschinen, PostgreSQL-, CosmosDB- oder auch DynamoDB-Datenbank-Instanzen, Azure EventHubs oder Amazon Kinesis DataStreams relevant. Identity und Access Management (IAM), Sicherheitsgruppen oder Blob-Storage-Instanzen zählen dagegen nicht bei der Berechnung der Kosten.
VMware vertreibt die Lösung über das eigene Partnernetzwerk oder auch den AWS Marketplace. Dort ist ein Starterpaket für insgesamt 100 Cloudressourcen pro Monat mitsamt Support für die
Ersteinrichtung verfügbar.
VMware CloudHealth Secure State
Produkt
Anwendung zum Management von Informationssicherheit und Compliance in Public Clouds.
Abrechnung nach Anzahl der überwachten Cloudressourcen. Das Starterpaket im AWS Marketplace für 100 Ressourcen pro Monat kostet 12.000 US-Dollar pro Jahr, 6 US-Dollar werden pro Monat für jede weitere Ressource jenseits von 100 fällig.
Systemvoraussetzungen
Aktueller Browser, Zugang zu Amazon Web Services, Microsoft Azure oder zur Google Cloud Platform.
VMware stellte uns per Einladungslink einen Testaccount zur Verfügung. Bei der ersten Anmeldung an der Plattform mussten wir uns registrieren und ein VMware-Cloudkonto erstellen. Sobald wir unsere E-Mail-Adresse verifiziert hatten, konnten wir uns auch schon am Secure-State-Webfrontend anmelden. Das begrüßte uns mit einem leeren Dashboard und dem Hinweis "No cloud account". Also navigierten wir im horizontal angelegten Menü zum Punkt "Settings / Cloud accounts" und fügten exemplarisch unseren Microsoft-Azure-Tenant hinzu.
Die nötigen Schritte hierzu erläuterte VMware direkt im Frontend sowie auch in der Online-Dokumentation. So fragte der Assistent im ersten Schritt nach dem gewünschten Cloudprovider, wobei das zugehörige Dropdown-Feld nur AWS und Azure zur Auswahl anbot. Die GCP fehlte an dieser Stelle, da sich die Unterstützung für Googles Cloud zum Zeitpunkt des Tests noch in einer geschlossenen Beta-Phase befand.
Optional durften wir noch angeben, um welche Art von Cloudumgebung es sich handelt – None, Production, Staging, Development oder Test. Zudem konnten wir einen Ansprechpartner mit E-Mail-Adresse hinterlegen und dem Account als Freitext ein oder mehrere Tags mit beliebigen Werten zuweisen. Das erleichtert es in sehr großen Multi-Cloudumgebungen, später einzelne Accounts wiederzufinden.
In den nächsten beiden Schritten verlangte der Wizard mit Application-ID, Authentication Key, Tenant-ID und Subscription-ID nach insgesamt vier Informationen, die wir im Microsoft-Azure-Portal ermittelten. So erzeugten wir die Anwendungs-ID mittels "Azure Active Directory / App-Registrierungen / Neue Registrierung" und in den Eigenschaften der App-Registrierung den Key mittels "Zertifikate & Geheimnisse / Geheime Clientschlüssel / Neuer geheimer Clientschlüssel". Tenant-ID und Subscription-ID tragen in der deutschen Lokalisierung des Azure-Portals die Bezeichnungen "Verzeichnis-ID (Mandant)" sowie "Abonnement-ID", beide zu finden unter "Kostenverwaltung + Abrechnung / Kostenverwaltung / Azure-Abonnements". Zu guter Letzt mussten wir in den Eigenschaften unseres Abonnements noch unter "Zugriffssteuerung (IAM)" eine neue Rollenzuweisung anlegen, die der App-Registrierung lesenden Zugriff gestattet.
Zurück im Secure-State-Webfrontend konnten wir damit unseren Account einrichten und im letzten Schritt den "Event Stream" konfigurieren. Der sorgt dafür, dass Secure State dynamisch sämtliche Ereignisse zu Konfigurationsänderungen aus dem Cloudaccount empfängt. Das Webfrontend stellte uns hierzu ein Kommando zur Ausführung in der Azure-Cloud-Shell bereit. Damit stand die Verbindung zwischen Azure und Secure State.
Analog dazu erfordert auch eine Verbindung zu AWS lesenden Zugriff und der Assistent verlangt nach dem Amazon-Ressourcenname (ARN), einer Rolle mit passenden Berechtigungen. Auch im Fall von AWS gelingt die Anbindung des Event Streams mittels eines CLI-Befehls, den Secure State bereitstellt.
Die Einbindung der GCP war bis zum Redaktionsschluss über das Webfrontend noch nicht möglich und erforderte in der Preview-Phase Unterstützung durch den Hersteller. VMware stellte uns daher eine zweite Umgebung zur Verfügung, anhand derer wir uns einen Überblick über die Handhabung einer Multicloud-Infrastruktur mit mehreren Accounts bei den drei großen Hyperscalern verschaffen konnten.
Alle Schwachstellen auf einen Blick
Sobald die Cloudaccounts verbunden waren, begann Secure State mit der Inventarisierung. Die Übersicht im Dash- board des Webfrontends füllte sich daraufhin mit Informationen zu gefundenen Schwachstellen.
So konnten wir auf einen Blick feststellen, wie es insgesamt um die Sicherheit in den Cloudumgebungen bestellt war. Dies umfasste globale Informationen, wie die absolute Zahl an Funden und verletzten Regeln, jeweils die Top 5 der verletzten Regeln sowie der Cloudobjekte mit der höchsten Risikobewertung. Auch zeigte uns die Software die Verteilung der Funde auf die verschiedenen Cloudprovider und ihre Dienste (Bild 1).
Bild 1: Das Dashboard zeigt auf einen Blick, wie es um die Sicherheit der angebundenen Cloudaccounts steht.
Im Menü "Governance / Rules" verschafften wir uns einen Überblick des Regelwerks. So brachte Secure State zum Testzeitpunkt insgesamt 501 Regeln mit, davon 311 für AWS, 157 für Azure und 33 für die GCP. Der Fokus lag also deutlich erkennbar auf Amazon, gefolgt von Microsofts Cloud. Weiterhin unterschied Secure State die Regeln nach den Typen "Violation" oder
"Threat". Erstere wurden, erkennbar an der Quelle "VSS Native", von VMware selbst beigesteuert, während Letztere von Amazons Dienst "AWS GuardDuty" stammten.
Bei den Regeln handelt es sich um Abfragen, die über alle im ICSM gespeicherten Objekte typische Sicherheitslücken und Fehlkonfigurationen erkennen und mit weitestgehend selbsterklärenden Titeln auf die Natur des jeweiligen Funds hinweisen. Dabei handelt es sich etwa um offene Ports ("An EC2 instance's Redshift port (5439) is accessible from the public Internet for any source address"), nicht umgesetzte Sicherheitsempfehlungen ("Web application firewall recommendations are disabled") oder auch fehlende Alarmierungen ("An SQL server security alert email address is not set").
Sinnvolle Compliance noch im Beta-Stadium
Im noch als Beta deklarierten Bereich "Governance / Compliance" hat Secure State mehrere Frameworks mit ihrem Bezug zu den Regeln an Bord. Dabei dominieren internationale Rahmenwerke vom American Institute of Certified Public Accountants (AICPA), Center of Internet Security (CIS) und National Institute of Standards and Technology (NIST). Hierzulande dürfte das Rahmenwerk zur europäischen DSGVO am interessantesten sein, auf das sich insgesamt 67 der enthaltenen Regeln beziehen (Bild 2).
Bild 2: Secure State gleicht die enthaltenen Sicherheitsregeln mit Rahmenwerken wie der DSGVO ab.
In einer separaten grafischen Übersicht unter "Dashboards / Compliance" konnten wir uns ansehen, inwieweit unsere Cloudaktivitäten mit den jeweiligen Rahmenwerken im Einklang standen. Bei anfänglich geringer Übereinstimmung mit den von der DSGVO geforderten Regeln war in unserer Testumgebung noch deutlich Luft nach oben. Und so informierten wir uns unter dem Punkt "Findings" im Hauptmenü in den drei Perspektiven "Findings by object", "Violations by rule" sowie "Violations (all)" im Detail über die Funde. Anschließend konnten wir uns anhand der Empfehlungen von Secure State dann daran begeben, die jeweiligen Schwachstellen zu beheben, sodass sich die Risikobewertung kontinuierlich verbesserte. Daraufhin wechselte der Status des Funds in Secure State von "Open" auf "Resolved".
Flexible Anbindung an Slack, Splunk und Amazon SQS
Im laufenden Betrieb hilft Secure State mit Benachrichtigungen dabei, den Überblick zu behalten. Neben dem klassischen Weg per E-Mail bringt Secure State Schnittstellen zu Splunk, Slack sowie dem Amazon Simple Queue Service (SQS) mit. Die mussten wir zunächst im Menü "Settings / Integrations" global konfigurieren.
Anschließend konnten wir dann unter "Actions / Alerts" die Benachrichtigungen granular konfigurieren. Hier zeigte sich Secure State flexibel und bot per Editor unterstützt die Möglichkeit, Konditionen mit einem oder mehreren Kriterien zusammenzustellen, die eine Alarmierung auslösen. Kriterien können einzelne Objekte, Regeln, Cloudaccounts, Tags oder Environments sein. So schickt Secure State etwa eine Benachrichtigung an einen beliebigen Slack-Kanal, wenn in einem bestimmten Cloudaccount eine neue Schwachstelle mit dem Schweregrad Medium oder High auftritt. Ganz im Sinne eines DevOps-Ansatzes kann Secure State damit Nutzer, die ihre Ressourcen selbst verwalten, direkt und unmittelbar über Fehlkonfigurationen und Sicherheitslücken informieren.
Eingeschränkte Delegation
Abgestuften Zugriff für Untermandanten regelt der Menüpunkt "Settings / Projects". Allerdings gehören zu einem Projekt immer ein oder mehrere Cloudaccounts und wir konnten keine feiner unterteilten Berechtigungen auf Basis einzelner Objekte innerhalb eines Cloudaccounts vergeben.
Wer in der Praxis also den Zugriff auf das Webfrontend delegieren möchte, muss jeder Gruppe von Nutzern einen eigenen Tenant in der jeweiligen Cloud einrichten. Diese Gruppen erhalten dann Zugriff auf Dashboards und Reports nur für ihre Spielwiese und sind damit immer im Bilde über sicherheitsrelevante Funde, die ihre Aufmerksamkeit erfordern.
Regeln lassen sich gezielt aussetzen
Sofern eine Konfiguration, die Secure State bemängelt, sich nicht sofort ändern lässt oder vielleicht sogar bewusst gewünscht ist, bietet das System die Option, Meldungen befristet oder dauerhaft zu unterdrücken. Dabei nutzt Secure State ein zweistufiges Verfahren von Anfrage und Genehmigung. So konnten wir in der langen Liste der Funde einzelne Meldungen ausblenden. Dazu stellten wir in den Optionen eines Funds wahlweise die Anfrage, den spezifischen Fund für ein bestimmtes Objekt ("Request: Suppress violation (on this object)") oder pauschal eine bestimmte Regel ("Request: Suppress Rule") für einen Tag, eine Woche, ein bis sechs Monate, ein Jahr oder bis auf Widerruf auszusetzen. Diese Anfrage mussten wir dann noch unter "Actions / Suppression Requests" mit Begründung bestätigen.
Zusätzlich zu Alarmen für einzelne Funde verschickt Secure State auf Wunsch einmalig, täglich, wöchentlich oder monatlich Berichte per E-Mail. Die konnten wir unter "Reports" im Hauptmenü konfigurieren und ähnlich den Alarmen flexibel die Kriterien auswählen, nach denen Funde in den Bericht wandern. Als Berichtsformat bietet Secure State derzeit ausschließlich CSV-Dateien an.
Individuelle Abfragen selbst erstellen
Im Bereich "Explore" des Hauptmenüs konnten wir pro Cloudaccount das ICSM auf eigene Faust durchsuchen. Nachdem wir das gewünschte Konto in einem Dropdown-Feld zuoberst ausgewählt hatten, formulierten wir in einem Eingabeprompt darunter benutzerdefinierte Abfragen. Dazu dient die VMware Secure State Query Language (VQL), deren Syntax die Online-Dokumentation allerdings nur rudimentär und mit wenigen Beispielen erläutert.
Der Prompt bietet jedoch eine kontextsensitive Auto-Vervollständigung, sodass wir uns die Bedienung mit ein wenig Übung selbst erschließen und eigene Abfragen formulieren konnten. Die VQL zielt darauf ab, die Beziehungen zwischen Objekten in der Cloud zu untersuchen und mittels logischer Operatoren deren Eigenschaften auszuwerten. Für unseren Azure-Tenant etwa zeigte uns eine Abfrage der Form Azure.Compute.VirtualMachine HAS NOT EnableAutomaticUpdates = true sämtliche VMs, die aktuell ohne automatische Updates unterwegs sind.
Beziehungen von Objekten untereinander adressiert ein Pfeil als Operator. So lieferte uns die Abfrage
Azure.Compute.VirtualMachine -> Azure.Network.NetworkInterface -> Azure.Network.NetworkSecurityGroup -> Azure.Network.SecurityRule HAS DestinationPortRange = "3389" AND Access = "Allow"
alle VMs, deren Netzwerkkarte mit einer Netzwerksicherheitsgruppe verknüpft ist, die wiederum mit einer Regel verbunden ist, die den Zugriff auf den Ziel-Port TCP/3389 für das Remote Desktop Protocol erlaubt. Sobald wir eine solche Abfrage mittels "Run" ausführten, visualisierte Secure State in der Graph-Ansicht darunter die passenden Objekte mit ihren Relationen (Bild 3).
Bild 3: Die Explore-Ansicht ermöglicht individuelle Abfragen und stellt Beziehungen zwischen Objekten grafisch dar.
Im Bereich "Governance / Rules" konnten wir unsere Abfragen dann verwenden, um daraus "Custom Rules" zu erzeugen. Dabei durften wir für unsere eigenen Regeln selbst den Schweregrad sowie den Typ der Regel – Violation oder Threat – bestimmen. Auch die benutzerdefinierten Regeln, von denen wir in unserer Test-Umgebung bis zu 25 Stück anlegen konnten, flossen anschließend ins Dashboard, die Findings und Reports ein.
Wirkungsvolle Gegenmaßnahmen
Da VMware die Funktionalität unter "Actions / Remediations" noch als Beta deklariert, ist diese nicht in unseren Test eingeflossen. Nach Auskunft des Herstellers soll die Funktion erst zum Jahresende 2020 fertig geworden sein und somit voraussichtlich beim Erscheinen dieses Artikels generell verfügbar sein.
Das Prinzip der Remediations soll aber trotzdem nicht unerwähnt bleiben, da es durchaus Potenzial besitzt. So sieht der Hersteller vor, dass Secure State Fehlkonfigurationen nicht nur erkennen, sondern auch automatisch Gegenmaßnahmen einleiten kann. Dazu bringt die Software aktuell insgesamt 13 vorgefertigte Remediations für AWS sowie fünf weitere für Azure mit.
In allen Fällen handelt es sich um Python-Skripte, die VMware unter die freie Apache License 2.0 gestellt hat. Die Skripte dienen dazu, als Reaktion auf die Verletzung einer Regel etwa selbsttätig offene Ports für SSH, RDP oder auch PostgreSQL zu schließen, Verschlüsselung sowie Logging auf S3-Speicherbereichen zu aktivieren und öffentlichen Zugriff auf Ressourcen einzuschränken.
Um ohne externen schreibenden Zugriff auszukommen, bedient sich Secure State als "Remediation Worker Groups" bezeichneten Docker-Instanzen. Diese laufen innerhalb der jeweiligen Cloudumgebung und erhalten ihre Aufgaben wahlweise manuell getriggert oder automatisiert ausgelöst (Bild 4). VMware beschreibt die nötigen Schritte zur Konfiguration von Remediation Workern in der Onlinedokumentation. So erfordern Worker natürlich Accounts mit Schreibzugriff innerhalb der Zielumgebung. Zur Inbetriebnahme des oder der eigentlichen Worker stellt VMware ein Docker-Image bereit, das sich mit Anmelde-Informationen gefüttert bei Secure State anmeldet und auf Arbeit wartet. Auf diese Weise kann die Software nicht nur mittels des Event Streams ungewollte Konfigurationen nahezu in Echtzeit erkennen, sondern diese auch umgehend abstellen, bevor sie ausgenutzt werden können.
Bild 4: Secure State nutzt Remediation Worker Groups, um mittelbar Aktionen in einer Cloudumgebung auszuführen (Bildquelle: CloudHealth by VMware).
Fazit
Bereits im derzeitigen Stand der Entwicklung zeigt sich CloudHealth Secure State als praktische Hilfe beim Wahren der Sicherheit in Cloudumgebungen. Hiervon profitieren insbesondere Unternehmen, die die Verwaltung von Cloudressourcen an Entwickler und Endanwender delegieren und trotzdem einen Überblick über die Informationssicherheit behalten möchten. So kann Secure State versehentliche Fehlkonfigurationen schnell erkennen und Gegenmaßnahmen empfehlen.
Es handelt sich um ein noch junges Produkt, das sich schnell entwickelt. Aktuell profitieren Kunden am ehesten von AWS und Azure, während die Unterstützung für die Google Cloud Platform sowie die Funktionalität der Remediations noch in den Kinderschuhen stecken. Sind die Remediations erst allgemein verfügbar, wird der Nutzwert noch einmal deutlich steigen.
(jp)
So urteilt IT-Administrator
Bewertung
Regeln für AWS
8
Regeln für Azure
7
Benachrichtigungen
7
Individuelle Abfragen
6
Inbetriebnahme
6
Dieses Produkt eignet sich
optimal
für Unternehmen, die ihre Aktivitäten in AWS oder Azure absichern möchten.
bedingt
für Unternehmen, die Dienste auf der Google Cloud Platform schützen möchten. Hier sind die zur Verfügung stehenden Regeln noch nicht so weit entwickelt wie die für AWS oder Azure.
nicht
für Firmen, die keinen der drei großen Cloudanbieter nutzen.