C5v2: BSI stellt aktualisierten C5-Katalog vor

Das BSI hat den 2016 veröffentlichten „Cloud Computing Compliance Criteria Catalogue“ einer umfassenden Revision unterzogen. Der „C5“ wird von Cloud-Anbietern aller Größen zum Nachweis der Sicherheit von Cloud-Diensten verwendet. Die Aktualisierungen betreffen sowohl Formalia als auch die Kriterien, die an den aktuellen Stand der Technik angepasst wurden. Er enthält außerdem eine neue Domäne zur Produktsicherheit und berücksichtigt damit nun auch die Regelungen und Anforderungen des 2019 in Kraft getretenen EU Cybersecurity Acts. Zudem wurde – insbesondere für kleinere Cloud-Anbieter – der Nachweisweg über die direkte Prüfung eröffnet.

Der C5 legt fest, welche Kriterien das interne Kontrollsystem der Cloud-Anbieter erfüllen muss bzw. auf welche Anforderungen der Cloud-Anbieter mindestens verpflichtet werden sollte. Der Nachweis, dass ein Cloud-Anbieter die Anforderungen einhält und die Aussagen zur Transparenz korrekt sind, wird durch einen Bericht nach dem Wirtschaftsprüferstandard ISAE 3402 bzw. IDW PS 951 erbracht.

https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html

Wolkenphisher: Cloud-Dienste als Angriffsvektoren

Cloud-Dienste entwickeln sich aufgrund ihrer Verbreitung und Vielfalt immer mehr zu möglichen Angriffsvektoren. Der Security-Journalist Brian Krebs berichtet von einem Fall, in dem ein Benutzerkonto eines cloudbasierten CRM nicht mittels Multi-Faktor-Authentifizierung geschützt war und hierdurch eine Phishing-Kampagne angeblich im Namen der Firma durchgeführt werden konnte.

https://krebsonsecurity.com/2019/08/phishers-are-angling-for-your-cloud-providers/

Alles ist verbunden – Multiple Single Points of Failure

Von großen – im Sinn von weitreichenden – Cloudausfällen war an dieser Stelle und in den Weiten des Internets in letzter Zeit häufig zu hören. Denn je mehr der Markt reift (sprich, je mehr Unternehmen relevante Teile ihrer Infrastruktur in die Wolke verlagern) und je mehr sich der Kuchen des Cloud-Geschäfts im Wesentlichen auf eine Handvoll großer Cloudanbieter und ein paar Dutzend Security-Services-Anbieter verteilt, desto größer kann der Impact eines einzelnen Zwischenfalls sein. Nun war Cloudflare an der Reihe, dies am eigenen Astralleib zu erfahren: Ein harmlos erscheinender regulärer Ausdruck, der weltweit bösartiges „Inline“-JavaScript herausfiltern sollte, brachte die Prozessorlast sämtlicher Filter auf 100 %, sodass bei den vielen Cloudflare-Kunden für eine halbe Stunde nichts mehr ging. Dann war das Problem erkannt und die Funktion gekillt – im Gegensatz zu Google im Mai konnte Cloudflare die Managementinterfaces nämlich ohne Probleme erreichen. Hatte der DDoS- und Websecurity-Spezialist aus Kalifornien schlampig gearbeitet? Ja und nein, die neue Funktion war zwar per Knopfdruck sofort weltweit, aber immerhin nur im Testmodus ausgespielt worden, der nichts hätte blocken sollen. <Ironie>Dass die Komplexitätstheorie bei den seit Jahrzehnten als mögliche Ressourcenmonster verrufenen RegExen einen Strich durch die Rechnung machen würde, konnte ja niemand ahnen … </Ironie>

In einer überraschenden Fügung des Schicksals hätte der Ausfall beinahe ein längst in eine dunkle Flasche verbanntes Monster wiederbelebt: 2017 hatte der junge Malware-Forscher Marcus “MalwareTech” Hutchins in einem heldenhaften Einsatz (siehe Lesetipps am Ende dieses Digests) per „Sinkhole“, also eine geistesgegenwärtig reservierte Domain, der Welt den größten Teil der ersten WannaCry-Angriffswelle erspart. Diese Sinkhole-Domain erhält bis heute riesige Mengen an Anfragen von schlummernden WannaCry-Infektionen, die nachfragen, wann sie denn nun endlich losschlagen sollen.Später wurde ebendiese pro bono (und natürlich für den Werbeeffekt) von Cloudflare übernommen – und war seither nie down. Um ein Haar hätte der Cloudflare-Ausfall also ein Heer von Schläfern erweckt, die Schäden von hunderten Millionen hätten verursachen können. Glücklicherweise genügte die immerhin noch ausgelieferte Fehlermeldung (HTTP-Code 502), um die Viren zu beruhigen. Sie schlummern also weiter auf unseren ungepatchten Systemen und laben sich an unseren technischen Altlasten …

Paging Münchhausen – Cloud braucht Cloud

Am 2. Juni standen weite Teile der Google Cloud für bis zu vier Stunden still. Dass Google damit die Jahres-SLAs gerissen hat, ist nur ein Teil des Problems, schließlich kamen und kommen Downtimes auch in selbstbetriebener IT immer wieder vor. Bedenklich ist vielmehr, dass es zu einem derart langen länderübergreifenden Ausfall kommen konnte, obwohl Google derart viel in Redundanz, Notfallplanung und Desaster Recovery investiert. Und zwar technisch wie konzeptionell. Nach ersterem Maßstab hat sich der Betreiber nicht viel vorzuwerfen, denn der Root-Cause war eine schwer vorauszusehende Interaktion drei verschiedener Bugs. Das Problem war schnell erkannt, verstanden und die Lösung schnell entworfen.

Allerdings gibt es zwei große Lessons Learned hier (für Google wie für die Kunden der großen Cloudanbieter): Erstens, die komplexen internen Abhängigkeiten der Gesamtsysteme, die Cloud-Dienste/-Rechenzentren/-Angebote darstellen, sind noch nicht ausreichend verstanden. Denn erst beim Incident-Handling fiel auf, dass man zur Behebung des Problems die, *tada*, Google Cloud benötigt, welche ja gerade nicht verfügbar war. Es fehlt also noch die Fähigkeit eines Baron Münchhausen, sich am eigenen Schopf aus dem Sumpf zu ziehen, sogenanntes Bootstrapping, im Energiesektor als Schwarzstartfähigkeit bekannt. Eine solche vorrätig zu halten, kostet Geld, was dem Kostendruck in der Cloud zuwiderläuft.

Das zweite Thema ist noch eine Ebene prinzipieller: Die großen Kosten- und Effizienzvorteile erzielt man im Cloud-Computing durch weitgehende Automatisierung – und die braucht als Basis Mono- oder zumindest Oligokulturen. Wie in der industriellen Landwirtschaft steigt mit der Effizienz hierbei auch das Risiko, dass ein einzelner Schädling/eine einzelne Schwachstelle/Bug/Fehlkonfiguration ganze Landstriche verwüsten und Hungersnöte auslösen kann. Meist wird man dies mittels viel Chemie unter Kontrolle halten können – was aber wieder nur das Risiko konzentriert und vertagt.

Sicher ist: Das dicke Ende kommt noch – und wir tun uns auf Dauer keinen Gefallen, wenn wir die Auseinandersetzung damit einfach nur in die Zukunft verschieben.

Zum Thema Cloud Security empfehle ich unseren aktuellen Webcast „Wege in die Cloud – aber sicher!“