Cloud Security – TeleTrust Podcast

Herzlich willkommen beim Teletrust Podcast. Mein Name ist Franziska Bock und unser heutiger Gast ist Sascha Dubbel. Sascha ist seit 1994 in der Informationstechnik tätig und hat sich seit dem Jahr 2000 auf Informationssicherheit spezialisiert.

Er hat unter anderem in Unternehmen wie McAfee und Palo Alto Networks gearbeitet. Bei Lacework, seinem jetzigen Arbeitgeber, betreut er heute Partner und Technologieallianzen in Zentraleuropa. Seit neun Jahren legt sein Schwerpunkt auf KI-basierten Cybersecurity-Lösungen.

Er ist seit 2007 Teletrust-Informations-Security-Professional, also TIS-Absolvent und aktives Mitglied der Community. Ebenso ist er in den Arbeitsgruppen Recht, Standard Technik und in der Arbeitsgruppe Cloud Security aktiv. Das ist unter anderem auch das heutige Thema Cloud Security.

Viel Spaß bei der Folge. Herzlich willkommen im Teletrust Podcast, Sascha. Danke für die Einladung.

Ich würde sagen, wir starten direkt rein in das Thema Cloud Security und vielleicht magst du uns da mal ein bisschen abholen, diejenigen, die vielleicht auch noch nicht ganz in dem Thema drin sind, mal so einen kurzen Overview geben, womit sich Cloud Security eigentlich ganz genau beschäftigt, wenn man das so in drei Wörtern zusammenfassen kann. Cloud Security beschäftigt sich mit der Absicherung von Daten, Infrastrukturen, Arbeitslasten, die in der Cloud ausgeführt werden und Cloud Security geht idealerweise auch Hand in Hand mit der Softwareentwicklung, um Risiken bereits bei der Erstellung von Softwarecode auszuschließen und qualitativ guten und sicheren Programmcode zu erstellen. Die Methodik ist unter dem Begriff DevSecOps, also Development Security Operations, zusammengefasst und ist ein geflügelter Begriff in dem Umfeld.

Cloud Security erfordert ein kulturelles Umdenken, weil wir Security eben schon ganz früh in der Softwareerstellung implementieren wollen. Das Gute ist dabei, wir können Cloud Security mit den richtigen Securitylösungen heute in einem hohen Maß auch automatisieren. Ich habe mich natürlich auch auf die Recherche begeben, was Cloud Security genau ist und mir ist dabei immer wieder Cloud Computing über den Weg gelaufen als Begriff.

Magst du da vielleicht noch mal den Unterschied beziehungsweise die genaue Differenzierung uns geben, damit man das vielleicht auch besser unterscheiden kann? Mir hat mal in Ostwestfalen ein mittelständischer IT-Leiter gesagt, Cloud ist der Computer eines anderen. Und im Wesentlichen trifft es das auch. Cloud Computing bedeutet, ich nutze die Infrastruktur oder Software oder Plattformen aus einem internetverbundenen Rechenzentrum eines externen Dienstleisters, in der Regel auf virtualisierten Systemen, die auf gemeinsamer Hardware genutzt werden und dann logische Netzwerkseparation erlauben.

Das heißt, ich habe eine eigene Umgebung, sie ist allerdings virtuell meine eigene. Der Vorteil ist, ich kann Cloud Computing dynamisch Systemcluster aus mehreren hundert Nodes zur Spitzenlastabdeckung betreiben und automatisiert auch die Kapazität wieder runterfahren, wenn die Ressourcen nicht benötigt werden. Und damit kann ich enorm viel Geld einsparen.

Möchte ich Spitzenlasten im eigenen Rechenzentrum abgedeckt wissen, dann muss ich halt sämtliche maximale Hardware auch beschaffen, betreiben. Ich muss mich um die Sicherheit kümmern und Cloud Security ist hier natürlich eine deutliche Erleichterung und bietet Kostenoptimierungsmöglichkeiten. Das Ganze unterteilt sich dann noch in unterschiedliche Spielarten.

Es gibt also fertige Software, die in der Cloud betrieben wird und ich als SaaS-Lösung nutzen kann und dann einfach dort die Software fertig verwende. Da gibt es Customer Relationship-Lösungen zum Beispiel, die marktführend sind wie Salesforce oder es gibt auch Infrastructure as a Service. Das sind dann die bereitgestellten Plattformen der Cloud-Service-Provider wie Amazon, Azure und Google oder Plattform as a Service, wenn ich halt einen weiteren Abstraktions-Layer darüber habe und dann in einer Plattform vielleicht meinen Code laufen lasse, um die darunter liegende Technik nicht weiter auseinandersetzen zu müssen.

Das hört sich ja jetzt erstmal an, als sei das die Lösung für alles. Aber es gibt ja bestimmt auch gewisse Risiken, wenn man das jetzt von der systematischen Betrachtung aus oder aus dem Blickwinkel betrachtet. Welche Risiken gibt es denn bei der Nutzung von Cloud-Diensten? Es gibt natürlich Risiken, die wir betrachten müssen und in der Cloud-Nutzung, wenn wir jetzt selber unsere eigene Infrastruktur bei einem Cloud-Provider nutzen wollen, das heißt unsere Softwareprojekte in die Cloud

reinbringen, vielleicht mit Technologien wie Container, Workloads oder Kubernetes-Clustern arbeiten, da muss ich mir natürlich vorher Gedanken machen, ist der Anbieter per se geeignet, um meine Datenverarbeitung sicher durchzuführen? Die großen global agierenden Hoster sind da in der Regel hochzertifiziert und können dann halt auch mit zum Beispiel dem C5-Kriterienkatalog punkten.

Das muss berücksichtigt werden. Also der Cloud-Anbieter muss in meiner Supply-Chain bewertet werden. Ich habe natürlich auch durch diese Skalierungsmöglichkeiten mitunter eine ungewollte Vervielfachung meiner Angriffsoberfläche, denn wenn ich jetzt einen verwundbaren Service hundertmal laufen lasse, dann wird auch meine Angriffsoberfläche natürlich hundertmal so groß.

Das heißt Misskonfigurationen müssen frühzeitig identifiziert werden, damit sie aufgrund des hohen Automatisierungsgrades eben nicht zu einem großen Problem werden. Idealerweise prüft man so etwas dann auch kontinuierlich. Man schaut also fortlaufend nach, ob die Einstellungen gut und richtig sind, so wie sie eben aus der Sicherheitsperspektive empfohlen werden, auch durch unterschiedliche Frameworks.

Wir haben uns auch mit Software-Verwundbarkeiten auseinanderzusetzen. Immer wenn ich Software verwende, ich kann natürlich eigene Software schreiben, aber meist besteht so ein Applikationscontainer auf einer Betriebssystem-Grundlage und aufgesattelt werden dann meist eine ganze Menge Standard-Libraries und Standard-Pakete verwendet und die können natürlich Verwundbarkeiten aufweisen, genauso wie auf einem Server, den ich in meinem eigenen Rechenzentrum betreibe, müssen wir uns hier auch entsprechend darum kümmern. Ein anderes Risiko ist dann natürlich der klassische Cyberangriff, d.h. ein Angreifer hat vielleicht bereits eine Hintertür eingepflanzt und nutzt diese oder er versucht, Systeme in ihrer Verfügbarkeit zu beeinträchtigen und distributet Denial-of-Service-Angriffe.

Das sind natürlich auch Risiken, die wir entsprechend berücksichtigen müssen. Da ist es vielleicht auch interessant zu erwähnen, dass wir bei Cyberangriffen auch solche Angriffsarten identifizieren können müssen, bei denen wir den initialen Angriffsvektor nicht kennen, bei dem wir vielleicht gar nicht wissen, welche Verwundbarkeit hat der Angreifer genutzt, weil die Verwundbarkeit einfach noch nicht in der Industrie bekannt ist und es einfach noch kein CWI dazu gibt und man dementsprechend auch nicht patchen kann. Ich weiß, Automatisierung ist dir sehr wichtig und darüber sprechen wir später auch nochmal, das habe ich aus unserem Vorgespräch so mitgenommen.

Jedoch haben wir auch Zuhörer und Zuhörerinnen, die vielleicht noch nicht ganz so lange in der IT-Sicherheit Fuß gefasst haben und deswegen würde ich gerne nochmal auf die ersten zwei Sätze eingehen, die du eben gesagt hast. Kannst du kurz erklären, was C5-Kriterien sind oder C5-Kriterien-Katalog und Supply Chain? Ja, also eine Supply Chain ist im Prinzip meine Lieferkette. Das sind all die, die daran arbeiten, die Services bereitzustellen, die ich nutze in der klassischen Industrie.

Ist das ein Zulieferer, der mir zum Beispiel ein Blechteil liefert, ich verwende dann Werkzeuge und mache ein Auto daraus und wenn mein Zulieferer mir qualitativ mangelhafte Ware zur Verfügung stellt, dann habe ich natürlich im Endprodukt ein Problem. Das Auto rostet vielleicht viel früher als es soll und genauso ist es halt auch in der Cloud-Security und es gibt einen Cloud-Security-Kriterien-Katalog, den das BSI schon seit einigen Jahren bereitstellt und der liefert sehr geeignete Prüfkriterien, um seinen Cloud-Service-Provider zum Beispiel im Hinblick auf seine technischen und organisatorischen Maßnahmen hin zu überprüfen und eben zu schauen, wenn ich jetzt meine Daten ihm anvertraue, wie sicher ist denn sein Rechenzentrum überhaupt? Welche eigenen Qualitätsstandards setzt er? Welche Security-Frameworks unterstützt er? Vieles leitet sich aus ISO 27001 hier ab, aber das ist es, was zum Beispiel den BSI C5-Katalog ausmacht. Danke dir erstmal dafür.

Wie können wir jetzt das Ganze mit Cloud-Computing im Hinblick auf die IT-Sicherheit sehen? Wie wird das Ganze eingesetzt im Bezug der IT-Sicherheit in dem Riesenthemengebiet? Das ist ein guter Punkt. Zum einen muss man unterscheiden. Es gibt natürlich Security-Lösungen, die als SaaS-Service selber angeboten werden.

IDA-Systeme zum Beispiel, also digitale Flugschreiber auf den Endpoints, auf den Servern, die Anomalien und schädliche Aktivitäten aufzeichnen können. Aber auch Cloud-Security-Plattformen wie das, was Lacework zum Beispiel selber anbietet. Das Thema Log-Management und Sieben kann in die Cloud verlagert werden.

Dann reden wir von Cloud-SaaS-Services. Zum anderen gibt es dann natürlich die Cloud-Dienste, die man selber in der Cloud betreibt und die man dann halt auch selber absichern möchte. Wir haben bei Cloud-Infrastrukturen.

Wenn ich jetzt zum Beispiel einen Webshop aufsetze und ich habe ein skalierendes Frontend, das heißt, ich weiß zum Black-Friday-Sale, wenn alle Leute bei mir einkaufen

wollen, dann brauche ich mehr Ressourcen, dann werden diese Ressourcen skaliert. Ich habe eine Datenbank dahinter, die entsprechend ausgelegt worden ist. Und all diese Ressourcen, die ich nun einstelle, die müssen natürlich in sich sicher gemacht sein.

Das heißt, wir wollen keine Verwundbarkeiten drin haben, die wir nicht vertreten können. Wir möchten keine Misskonfigurationen drin haben, dass zum Beispiel der Webshop nicht verschlüsselt erreicht werden kann. Also solche Dinge wollen wir halt auf ein gutes und sicheres Maß bringen und kontinuierlich überprüfen.

Ja, klassische Lösungen, die man in der Vergangenheit genutzt hat, sind in der Cloud leider nicht immer adäquat zu nutzen. Das heißt, all das, was ich aus dem Desktop- und Serverumfeld kenne, Antivirusprogramm, IDA-Lösungen und Personal Firewall sind hier einfach in der Art und Weise, wie sie bedient werden, nicht zu nutzen. Und in der Regel halten sie auch mit dieser hohen Dynamik der Cloud-Architektur nicht stand.

Wenn ich auf einmal 15 neue Systeme einstelle und man stelle sich vor, man müsste wegen dem Virenscanner das System dreimal neu rebooten, bevor es in meine Produktionsumgebung eingefügt werden kann, dann wäre es schlicht und ergreifend nicht machbar. Und da brauchen wir eben zeitgemäße Lösungen, die genau für diese Anforderungen gemacht sind. Jetzt hast du es mir schon nahezu in den Mund gelegt.

Was sind denn zeitgemäße Lösungen? Ja, zeitgemäße Lösungen sind Lösungen, die viele unterschiedliche Arbeiten, die ich normalerweise im schlimmsten Fall händisch durchführen müsste, von meinen Schultern runternehmen. Das heißt, einen hohen Grad von Automatisierung bieten. Zum einen im Hinblick auf die Compliance, eben schauen, sind meine Ressourcen sicher konfiguriert.

Entspricht die Konfiguration dem, was zum Beispiel ISO 27001 empfiehlt oder auch die Security Best Practices aus der Cloud-Community? Wir müssen schauen, dass wir bei der Analyse von Arbeitslasten eben nicht mehr nur mit statischen Regelwerken arbeiten, die mich im Prinzip auf Probleme hinweisen, die bekannt sind und die es erforderlich machen, dass ich all diese ungewollten Situationen beschreibe, also mit Regelwerken arbeite. Das macht man im Compliance-Umfeld sicherlich, weil da die Vorgaben relativ stark fokussiert sind. Wenn ich allerdings Cloud-Security in einer Umgebung versuche durchzuführen, in der ich mit vielleicht heute einem halben Dutzend von Verwundbarkeiten rechne, die schlicht und ergreifend noch nicht bekannt sind, dann

muss ich in der Lage sein, mehr Daten zu verarbeiten, also Telemetriedaten, die beim Betrieb der Cloud ohnehin anfallen.

Diese sinnvoll zu nutzen, wie zum Beispiel das Cloud-Audit-Log, in dem ich genau sehe, welche Services, welche Autorisierungsdienste werden verwendet. Wo gibt es zum Beispiel die Erstellung neuer Ressourcen? Das muss man kontinuierlich überwachen und genauso betrifft es Anomalien in zum Beispiel meinem Web-Shop. Wenn ich jetzt zum Beispiel sehe, da wird eine Verbindung geöffnet zu einem Host, mit dem ich normalerweise nie etwas zu tun habe und da werden Daten verschickt, dann ist das eine höchst kritische Anomalie.

Und eine gute Cyber-Security-Lösung für Cloud-Umgebung, die unterstützt mich dabei, solche relevanten Findings entsprechend zu priorisieren und mir dann in meinen Business-Prozess, also in meinen Alerting oder in meinen SIEM oder in meinen Slack-Pager-Duty, was auch immer ich für eine Benachrichtigung nehme oder einen SMS-Service, dann entsprechend mich zur Handlung aufruft. Und das ist ein ganz großes Unterscheidungskriterium, weil viele regelbasierte Lösungen sind sehr gut darin, mit hunderten Alarmtausende von Findings pro Tag zu produzieren. Und ein sehr gängiges Problem ist bei den Unternehmen einfach, dass sie zum einen unter Ressourcenmangel leiden, gar nicht genügend Analysten dort bereitstellen können, um diesen Wust an Alarmen zu durchforsten.

Und die Leute werden auch einfach betriebsblind. Je mehr Alarme ich habe, desto ermüdender wird die Aktivität und desto größer ist das Risiko, dass ich genau das, was relevant ist, einfach in diesem Grundrauschen von anderen weniger relevanten Ereignissen nicht sehe und dann auch nicht handel. Und das haben uns Breaches aus der Vergangenheit in den letzten 30 Jahren schon gezeigt.

Es war häufig dieser, ja, die Amerikaner sagen Alert-Fatig, diese Müdigkeit auf diesen großen Volumen von Alarmen. Jetzt haben natürlich meine Ohren geklungen, als du meintest mehr Daten und Daten, Daten, Daten. Da kommt ja dann die DSGVO ins Spiel.

Gerade in Deutschland ein riesengroßes Thema, super wichtig oder auch nicht. Welche Rolle spielt die DSGVO hinsichtlich der Cloud-Dienste oder welche Position nimmt sie dort auch ein? Zum einen muss man differenzieren zwischen dem Einfluss, den die DSGVO auf den Cloud-Dienste im Allgemeinen hat. Und da muss ich natürlich eines festhalten.

Alle Daten, die ich verarbeite und die irgendeinen Personenbezug haben, die also in irgendeiner Art und Weise mit einem Individuum verknüpft werden können, die sind für die Datenschutzgrundverordnung relevant. Das heißt, wenn ich solche Daten erhebe und verarbeite und es ist unabhängig davon, ob ich das in meinem eigenen Rechenzentrum mache oder in einer Ressource, die ich eben bei einem Cloud-Service-Provider gemietet habe, muss ich Sorge dafür tragen, dass die Daten nicht Unberechtigten Dritten zur Verfügung gestellt werden. Ich muss mich um die Verschlüsselung kümmern und ich muss natürlich auch die Datensparsamkeit als wichtiges Gebot heranziehen.

Und das gibt mir jetzt auch den Brückenschlag zur Cyber Security. Natürlich wollen Security-Anbieter immer möglichst viele Daten haben. Und eines ist sehr wichtig zu verstehen.

Gute Security-Lösungen müssen nicht unbedingt in den Content reingucken. Also ich muss nicht sehen, was ein Web-Server für Transaktionen durchführt. Wenn ich imstande bin, genügend und relevantes Wissen über sicherheitsrelevante Geschehnisse aus den Metadaten, die rundherum um das Processing des Contents erfasst werden, eben anfallen.

Das heißt, wir schauen uns nicht an, mit wem spricht der Web-Server gerade und was hat der Kunde bestellt und wie ist der Vorname und Nachname. Diese Daten wollen wir als Security-Anbieter gar nicht haben und wir brauchen die auch nicht, um unseren Job zu erfüllen. Wir gucken uns an, wer hat den Web-Server gestartet, wie lang läuft der Web-Server typischerweise, welche Prozessketten sind daran beteiligt, mit welchen anderen Hosts unterhält sich jetzt zum Beispiel eine Worker-Node in meinem Cluster und daraus bilden wir ein Normal und vermeiden eben auch ganz aktiv, sensitive Daten überhaupt in die Erfassung aufzunehmen.

Wir haben ja jetzt schon eben ein bisschen über die Risiken bei der Nutzung von Cloud-Diensten gesprochen. Welche Sicherheitsvorteile kannst du denn auf der anderen Seite vom Cloud-Service entgegenwiegen sozusagen? Was kann man da Positives rausziehen? Cloud-Dienste bieten tatsächlich einige Sicherheitsvorteile. Zum einen habe ich in vielen Services, die ich nutzen kann, einen gewissen Zwang zum regelmäßigen Patching, weil meine Ressourcen sonst vom Provider einfach nicht mehr betrieben werden, weil das Sicherheitsrisiko nicht mehr zu vertreten ist.

Es gibt aber noch viel wertvollere Sicherheitsvorteile, nämlich ich kann standardisierte und vorgehärtete Services verwenden. Das heißt, ich kann eine MySQL-Datenbank zum Beispiel bei einem CSP entsprechend nutzen und habe dann in einem weiten Rahmen schon eine sehr viel sicher gestaltete Ressource, als wenn ich dies versuchen würde, selber aufzubauen. Das ist also ein wichtiger Faktor.

Man muss natürlich immer noch schauen, wie die grundsätzliche Konfiguration darum aussieht. Und da helfen dann technologische Ansätze wie die Definition von Infrastructure as Code. Da kann man dann sagen, wenn eine Cloud-Umgebung, ein Webshop, um in diesem Beispiel zu bleiben, gebaut werden soll, welche beteiligten Services sind dann eben hier involviert und sind die denn auch sicher konfiguriert? Also das können wir von beiden Seiten eben deutlich besser machen, als es von Hand in klassischen Rechenzentren möglich ist.

Wir haben auch sehr gute und sehr tiefgreifende Berechtigungs- und Rollenkonzepte in Cloud-Architekturen. Das heißt, ich kann durchgängig zum Beispiel eine Nutzung von Multifaktor- Authentifizierung umsetzen. Ich kann prüfen, ob die Rotation von kritischen Accounts regelmäßig passiert.

Ich kann eben auch schauen, brauche ich dieses Berechtigungs-Niveau an der Stelle überhaupt? Denn es sollte nicht viele Super-User-Accounts in einer Cloud-Umgebung geben, im Idealfall eigentlich gar keinen, sondern alles wird dann halt auf diese Berechtigungs- und Rollenkonzepte umgewälzt. Und das lässt sich einheitlich prüfen und das lässt sich eben mit Security-Plattformen, wie wir sie anbieten, auch automatisiert kontinuierlich überwachen. Ich habe auch ein sehr gutes Angebot an Beratungs-Dienstleistungen und so einen gleichmäßig hohen Qualitätsstandard, wenn ich eben Hilfe benötige und Cloud-Service nutze, weil alle Cloud-Provider natürlich Trainings anbieten in ihren entsprechenden Bereichen und dort eine einheitliche Prüfung dann stattfindet der entsprechenden Consultants.

Ich muss mir um die physikalische Sicherheit, also der Absicherung meiner Hardware, wo steht das Ding, ist es sicher, kann da jeder rein und raus und Stromkabel rausziehen. Das ist alles natürlich sehr stringent geregelt und ich habe dort sehr hohe Sicherheitsanforderungen an diesen Rechenzentren, an den Betrieb. Ich kann auch relativ einfach Georedundanzen aufbauen, Ausfallsicherheit herstellen.

Das ist eben auch ein sehr, sehr wichtiger Faktor. Das heißt, möchte ich georedundant eine Ressource betreiben, dann muss ich halt in zwei verfügbaren Zonen oder in Geolokationszonen eben meine Ressourcen definieren und muss kein zweites Rechenzentrum dafür bauen. Das ist ein sehr kostengünstiger Aspekt.

Wir haben ja auch schon ein bisschen so die ganzheitlichen Absicherungen angesprochen und im Vorgespräch sind wir auch darauf eingegangen und da kam gerade auch das Thema zutage, dass es ja einen gewissen Fachkräftemangel in Deutschland und wahrscheinlich auch in ganz Europa gibt. Welche Auswirkungen siehst du in Bezug auf Cloud Security und den Fachkräftemangel? Also ja, vielleicht wahrscheinlich Zeitmangel, Ressourcenmangel in den Unternehmen etc. PP, magst du das nochmal ein bisschen ausführen? Gerne.

Der IT-Fachkräftemangel macht sich insbesondere in der Cyber Security bemerkbar und wenn wir dann noch Spezialisten zum Beispiel im Cloud-Umfeld suchen, dann wird der verfügbare Pool immer kleiner. Laut Bitkom fehlen nach einem relativ aktuellen Erhebung knapp 137.000 Experten allein in Deutschland. Unternehmen haben häufig mit sehr vielen Fehlalarmen zu kämpfen.

Das hatte ich schon mal angesprochen. Das Wichtige geht in der Fülle der Alarme einfach unter und das setzt Unternehmen unter Druck, eben viele Dinge zu automatisieren. Und dazu gilt eben auch die Automatisierung in der Cloud Security, um den Mangel an Personal zu kompensieren.

Und dazu gehört es halt auch, möglichst den Scope der verwendeten Security-Tools, die ich habe, möglichst zu konsolidieren, damit ich nicht im Worst-Case fünf Security-Tools verwende, die fünf Administratoren oder Security-Analysten dann tagtäglich binden. Das funktioniert einfach nicht, das skaliert nicht. Und die Notwendigkeit, Automatisierung zu nutzen, ist dann ein sehr wichtiger Treiber für unsere Kunden in Deutschland, Österreich und der Schweiz, um hier vielleicht auch umzudenken und die Prioritäten hinsichtlich Automatisierbarkeit von Security voranzutreiben.

Wir sind ja eben schon mal auf den Kriterienkatalog eingegangen. Mich würde jetzt noch mal so interessieren, welche Regelwerke braucht man denn generell oder welche Regelwerke brauche ich und wie könnte man das vom Unternehmen her oder in einem Unternehmen generell ein bisschen mehr automatisieren? Und das führt dann auch gleich zur nächsten Frage, wie man es erst nicht dazu kommen lassen kann, dass die

Feuerwehr eingreifen muss durch diesen ganzen Automatisierungsprozess. Also man muss zunächst einmal unterscheiden, wo brauche ich überhaupt Regelwerke und kann ich nicht auch regelunabhängig arbeiten im Compliance-Assessment-Umfeld? Also dauert, wenn ich prüfe gegen SOC 2 oder PCI-DSS oder ISO 27001, dann habe ich natürlich ganz klare regelbasierte Assessments, die durchgeführt werden müssen.

Da kommt man um Regeln nicht herum. Es gibt auch ein paar grundsätzliche Regeln, wie ich etwas umsetzen soll, wie ich also meinen Code und meine Architektur möglichst ordentlich plane. Das sind dann aber eher Handlungsempfehlungen, die aus Well-Architected-Frameworks, die gibt es für alle Cloud-Service-Provider, die kann ich heranziehen und entsprechend dann diese Maßnahmen umsetzen.

Das ist ebenfalls ein Pflichtteil. Je besser ich von vornherein meine Architektur plane, desto weniger habe ich später dann mit Skalierungsfehlern zu kämpfen, mit Ausfällen oder mit Kompromittierungen. Bei der Analyse dessen, was in Cloud-Workloads und auch in den Cloud-Accounts selber passiert, da lässt sich sehr, sehr gut heute Machine Learning implementieren.

Wir verwenden selber patentierte Machine Learning-Ansätze, um das Aufkommen von falsch positiven Erkennungen zu minimieren und gleichzeitig bei den verbleibenden und relevanten Alarmen dann direkt Kontext zu schaffen. Das heißt, ein Analyst, der über einen Vorfall informiert wird, der soll dann direkt alle Informationen haben, die er braucht, um die Situation zu bewerten und eben nicht überlegen, ist das erstmal eine falsch positive Erkennung und wen möchte ich denn bitte fragen, um weitere Informationen zu bekommen? Im schlimmsten Fall bis zum Entwickler hin, der ihm dann erklären soll, wie der Code typischerweise läuft. Wir können dieses typische Laufen, die typische Ausführung und die typischen Aktivitäten in Cloud-Accounts und in Cloud-Workloads heute automatisiert lernen und dann Anomalien identifizieren, die dort einfach nicht hingehören.

Wir können natürlich auch Cyber Threat Intelligence nutzen, um starke Indikatoren, die es aus der Industrie gibt, die aus eigenen Threat Intelligence Teams kommen, hier ebenfalls mit den Daten, die erhoben und verarbeitet werden, verschneiden, um dann hochwertige Alarme zu erstellen und solche Alarme zu produzieren, bei denen der Analyst gerne reinschaut und nicht nachher sagt, oh je, es war schon wieder ein falsch Positiver und jetzt muss ich mich wieder eine Stunde kümmern, bis ich die falsche Regel in eine möglicherweise noch weiter aufgeweichte Regel umgesetzt habe und damit die Security nicht mehr erhöhe, sondern noch weiter schwäche. Okay, das war ja schon mal

dann ganz gut zu den Regelwerken. Jetzt gehen wir aber bitte nochmal ein bisschen genauer darauf ein, wie man es schafft, dass diese Feuerwehr sozusagen gar nicht erst eingreifen muss.

Dazu gilt es natürlich erstmal ein Verständnis über die Risiken, die ich habe, zu bekommen und diese dann natürlich zu minimieren. Das ist gut investierte Zeit. Ressourcen werden sicherer bereitgestellt.

User-Accounts sind optimal konfiguriert. Es gibt eben keine Super-User im regulären Betrieb. Wir haben Passwort-Retention-Policies.

Damit minimiere ich die Angriffsoberfläche. Die verwendeten Betriebssysteme und Software-Pakete sind idealerweise frei von nicht tolerierbaren Mängeln, zumindest die, die bekannt sind. Ich muss natürlich auch, wenn ich mit entsprechenden Abweichungen von meiner gewollten Zielkonfiguration bin, wenn ich zum Beispiel Verstöße sehe, dann muss ich eine Priorisierung haben.

Ein Beispiel ist, ich habe vielleicht ein Software-Image in meiner Container-Registry und ich weiß, das Ding hat 200 Verwundbarkeiten. Das ist jetzt auch keine absurd hohe Zahl. Das ist durchaus ein Durchschnittsmaß.

Dann kann ich mir die Zeit nehmen und diese 200 Verwundbarkeiten beheben und natürlich dafür eine Menge Zeit verwenden. Wenn ich allerdings weiß, dass dieses Software-Image überhaupt nicht zu meiner Angriffsoberfläche beiträgt, weil es überhaupt nicht in der Produktion auftaucht, kann ich meinen Fokus und meine Prioritäten auf das konzentrieren, was tatsächlich in meiner Umgebung läuft. Das heißt, wir verknüpfen mit den Daten, mit dem Wissen, welches wir aus den Laufzeitumgebungen haben, dann auch das Wissen und die Führung darüber, welche Prioritäten zuerst zu erledigen sind.

Dann hätte ich natürlich auch noch in Bezug auf den Teletrust eine Frage. Wir versuchen uns da ja immer stetig weiterzuentwickeln und auch für unsere Mitglieder Mehrwert zu liefern. Und was denkst du, kann Teletrust in Bezug auf Cloud Security machen, um vielleicht noch mehr Awareness unter den Mitgliedern oder in den Unternehmen zu schaffen? Ja, der Teletrust hat schon eine Reihe von unterschiedlichen Materialien, die Unternehmen helfen, den Security-Status-Quo einfach solide zu bewerten.

Zum einen die Handreichung zum Stand der Technik, in der in unterschiedlichen Bereichen auf technische und organisatorische Maßnahmen eingegangen wird, die ein Unternehmen im Umgang mit allen möglichen Cyber Security relevanten, aber auch eben mit Cloud Security relevanten Themen abdeckt. Und wir haben eine Cloud-Security-Handreichung, die ganz konkret eingeht auf viele der Themen und Bereiche, die wir heute besprochen haben. Und diese Handreichungen sind jedermann kostenfrei bereitgestellt und können von der Teletrust-Website einfach heruntergeladen werden.

Und diese Handreichungen werden mehr und mehr wichtig, weil wir in den kommenden Jahren mehr und mehr auch sehr gegenüber Cloud konservativ eingestellten Unternehmen den Umzug in die Cloud sicher ermöglichen wollen. Denn für viele Unternehmen ist es tatsächlich so, dass ein Umzug bestimmter Ressourcen in die Cloud einfach die Wettbewerbsfähigkeit verbessert und auch die Digitalisierung dann weiter vorantreibt. Jetzt nochmal ein kleiner Themen-Cut.

Wir wissen ja auch, dass du, haben wir ja im Intro gehört, dass du in der Arbeitsgruppe Rechtsstand der Technik sehr aktiv bist. Und wenn man sich den Stand der Technik durchliest, kommt ja auch öfter der Begriff Cloud-Security auf. Welche Rolle spielt der Stand der Technik in Hinsicht auf Cloud-Security? Ja, wie in allen Bereichen der Cyber-Security schaffen natürlich zeitgemäße und moderne Sicherheitslösungen Vorteil in der Absicherung von Cloud-Umgebungen.

Der Teletrust unterstützt mit seiner Handreichung zum Stand der Technik, um zeitgemäße Maßnahmen aufzuzeigen. Wir haben auch in der Arbeitsgruppe Cloud-Security sehr umfassendes Paper, welches auf die unterschiedlichen Aspekte eingeht. Und damit schaffen wir auf der breiten Front einige sehr wertvolle Informationen für die Unternehmen.

Sascha, vielen Dank erstmal für deine Zeit. Und zum Abschluss habe ich noch eine kleine Frage, die wir gerne so auf den Weg mitnehmen könnten. Was denkst du aus deiner Perspektive jetzt heraus? Wir haben ja viele kleine und mittelständische Unternehmen, die uns zuhören, die auch Mitglieder beim Teletrust sind.

Was können diese machen, um sich mehr zu schützen? Zum einen sollten Unternehmen, auch kleine Unternehmen, Beratungsexpertise in Anspruch nehmen. Cloud-Service-Provider bieten Informationsprogramme an, aber es gibt halt auch

spezialisierte Unternehmen, die die richtige Nutzung der Security-Tools und die Eingliederung in die Prozesse entsprechend begleiten können. Das ist ein sehr wichtiger Schritt, um nicht etwas zu bauen, was man nach relativ kurzer oder vielleicht auch langer Zeit dann irgendwann wieder abreißen muss, weil man einfach einige grundsätzliche Dinge nicht ordentlich berücksichtigt hat.

Eine Empfehlung ist auch, zu überlegen, ob ich das, was ich baue, in einer Art und Weise gestalten kann, dass ich es auch in anderen Cloud-Service-Umgebungen abbilden und betreiben kann. Das heißt, weniger Abhängigkeit auf einen bestimmten Anbieter schaffe und vielleicht auch wegkomme, dann bestimmte Security-Tools nur eines Anbieters zu verwenden und dann in Zugzwang gerate, falls ich aus welchen Gründen auch immer all meine Applikationen jetzt einem anderen Provider betreiben möchte. Ein Punkt, der in der Diskussion, im Dialog mit CSUS häufig zutage kommt, ist, wenn wir sicher Software-Projekte in die Cloud bringen wollen, ist das Thema DevSecOps-Kulturen ein sehr wichtiger Punkt und hier müssen wir schauen, dass wir keine Fronten aufbauen zwischen den klassischen Security-Teams.

• und den Developern, die nun ganz anders, viel schneller, als es damals in monolithischen Umgebungen der Fall war, ihre Applikationen releasen wollen und dann, letztendlich vielleicht Probleme dort einbauen.

Das heißt, die sichere Erstellung von Code, die muss sehr frühzeitig beginnen und die Kultur darum liegt darin, dass wir alle Teilnehmer darin befähigen, das Beste aus dem Security-Aspekt zu schaffen, und am Ende des Tages zu der Position gelangen und zu dem Standpunkt gelangen, dass gute und gut umgesetzte Security

nicht mehr kostet, sondern am Ende Kosten spart, Ärger spart und es ermöglicht, einfach schnellere Innovationszyklen umzusetzen.

Und ein anderer Punkt ist eben, Cloud-Infrastrukturen sollten immer mit zeitgemäßer Technologie, mit einem hohen Automatisierungsgrad kontinuierlich überwacht werden. Die Zeiten, dass man Compliance Assessment alle zwei Jahre durchführt, sind in Anbetracht der Bedrohungslage schlicht und ergreifend nicht mehr zeitgemäß.

Es hilft den Unternehmen auch deutlich einfacher, durch einen Compliance Audit durchzugelangen, wenn ich im Prinzip die ganze Zeit, die ganzen zwei Jahre fortlaufend immer, wieder Unzulänglichkeiten in meinen Konfigurationen, in meinem Setup direkt behebe, als dann auf den großen Tag zu warten und, eine riesengroße Liste von Dingen zu bekommen, die abgestellt werden müssen.

Dann wieder, ja, wie die Feuerwehr dort hinterher renne, um dann nach zwei Jahren wieder von vorne anzufangen. Da kann man sich viel Zeit und Mühe sparen, wenn man das Ganze einfach kontinuierlich, Tag für Tag im bestmöglichen Sicherheitsstand hält.

Und proaktiv schon vorbeugende Solutions findet sozusagen, ne? Genau. Alles, was ich an Angriffsoberfläche direkt von Anfang an vermeiden kann, sollte natürlich auch vermieden werden.

Denn wenn ich jetzt einfach überlege, ich habe einen Breach, ich wurde gehackt und meine relevanten und sensiblen Kundendaten sind weg, dann habe ich eine ganze Menge zu tun.

Da muss ich überlegen, wer hat die Daten, wer ist betroffen. Ich muss analysieren, wie konnte es überhaupt dazu kommen. Und das nimmt sehr, sehr viel Zeit in Anspruch und sorgt in, der Regel auch für eine große Beeinträchtigung der geschäftlichen Aktivitäten, Imageverlust, Kundenspringen ab.

Ich habe vielleicht auch mit einer Penale, zu rechnen oder mit einem entsprechenden Verfahren dann wegen Dingen, die ich hätte umsetzen sollen und die ich vielleicht einfach ignoriert habe. Wenn wir versuchen, diesen Fokus zu verlagern in, ich mache alles von Anfang an richtig, ich versuche Software mit einem hohen Qualitätsstandard, einem hohen Sicherheitsstandard in meine Architekturen zu bringen, dann ist das Risiko deutlich geringer.

Und ja, jeder Cent, den ich dafür ausgebe, der zahlt sich am Ende doppelt und dreifach aus. Das sind doch wunderschöne Abschlussworte. An dieser Stelle Sascha, erst einmal vielen, vielen Dank für deine Zeit.

Wir werden natürlich alles verlinken, wie man dich gegebenenfalls auch kontaktieren kann, wenn man noch weitere Nachfragen hat oder, natürlich auch die von Teletrust publizierten Handreichungen, die du erwähnt hast, dass man die auch kostenfrei herunterladen kann.

Und wie immer natürlich sehr, sehr gerne Feedback an der Stelle an info-at-teletrust.de. Feedback, Anregungen, natürlich nur positive Art und Weise, konstruktive Kritik.

Und ansonsten, wie gesagt, lieber Sascha, vielen Dank für deine Zeit. Ich denke, wir haben versucht, ein bisschen knapper und kürzer als sonst, ein sehr großes Thema von einigen Seiten zu beleuchten und darzustellen.

Und ich hoffe, dass ihr etwas mitnehmen konntet. Ja, danke auch nochmal von meiner Seite. Ich stehe gerne für Rückfragen natürlich jederzeit bereit.