Dieser Artikel erzählt eine wahre Begebenheit, worin aus einer Routineanfrage für ein SaaS-Assessment ein Risiko-Beben wurde.

(Rechtliche Hinweise: Beteiligte, Unternehmen und Personen, Abteilungen sowie Applikationen wurden aus Vertraulichkeitsgründen nicht genannt bzw. umgeschrieben.)

Governance, Risk und Compliance (GRC) bilden ein integriertes Rahmenwerk, das Unternehmen dabei unterstützt, ihre Ziele abzustimmen, Risiken gezielt zu steuern und die Einhaltung gesetzlicher sowie interner Vorgaben sicherzustellen. GRC ist dabei weit mehr als eine Sammlung von Richtlinien oder Softwarelösungen. Es stellt einen ganzheitlichen Managementansatz dar. Als übergreifendes Betriebsmodell verknüpft es Governance-Strukturen, Risikomanagement und Compliance-Verpflichtungen nahtlos über alle Unternehmensbereiche hinweg.

Für spezifische Beschaffungsvorhaben, wie z.B. Cloud Software, braucht es allerdings Prüfprogramme und Security & Risk Frameworks, die in die GRC Prüfprozesse eingebunden werden und bei der gesamtheitlichen Bewertung des Angebots eine massgebliche Rolle spielen.

Jetzt aber zur diesbezüglichen Story 🙂

Irgendwann in nicht allzu weiter Vergangenheit, sollte das IT-Security Office ein Projekt bei der Ausschreibung zur „Migration einer Kernapplikationen zu eine Cloud SaaS Lösung“ routinemässig unterstützen.

Ihre Hauptaufgabe war es,

• das Vorhaben hinsichtlich Informations- und IT-Sicherheit (technisch, organisatorisch) und Datenschutz unter Anwendung des etablierten Prozesses und dessen geltenden Prüfungsstandard nach Risikogesichtspunkten und C/I/A Kriterien (Confidentiality/Integrity/Availablity) zu bewerten,
• die Einhaltung der Richtlinien und Prozesse der Informationssicherheit vor Offerteneingaben, über die Anbieterauswahl bis zur Implementierung zu gewährleisten.

Die Business-seitige Erwartungshaltung war dabei ganz klar:

• Eine schlanke Angebots- und Freigabephase ermöglichen.
• Offerten zeitnah sichten und offene Fragen schnell klären, um die Entscheidung nicht zu verzögern.

Das IT Security Office sollte im Projekt durch den aktuellen IT Security Manager vertreten und i. A. durch das Cloud Security Team ausgeführt werden. Ein Routine-Check also, für unsere geübten Augen.

Wir starteten mit den ersten Schritten, den Sachverhalt aufzunehmen und das Vorhaben sowie den technischen Hintergrund zu verstehen. Auch das Kennenlernen aller Beteiligten Personen und Instanzen gingen wir an.

Doch diesmal war es etwas anders. Irgendwas sagt mir zu Beginn, dass das, was uns zu Beginn propagiert wurde, so nicht stimmen kann.

ÖFFNUNG #1 – „Oh Gott, das sind ja 3 SaaS Apps, nicht Eine!!!

Die als Standardlösung deklarierte SaaS Applikation entpuppte sich bei Sichtung der Offerten als eine Integrierte Lösung, bestehend aus mehreren SaaS Lösungen. Die hohe Motivation und Euphorie, eine veraltete OnPrem Kernapplikation endlich durch eine modernere SaaS abzulösen hatte anscheinend den ernannten Projektleiter sowie weitere Beteiligte davon abgehalten, die Applikationsarchitektur zu hinterfragen. Es war ja eine SaaS Lösung, die endlich alle Probleme in diesem spezifischen Unternehmensbereich lösen sollte 🙂 Die Cloud-Zeit war endlich angebrochen.

Auswirkungen:

Das „Security & Risks Measurement Framework“ musste in diesem Fall als monolithische  Cyber-Sicherheitsüberprüfung für jede Applikation separat angewendet werden (Fokus auf den Cloud Service Provider). Die Auswertungen mussten neben dem IT Sicherheitsfragenkatalog für Ausschreibungen, je Applikation mehrmals durchgeführt werden, was zu beginn der Beschaffungsphase so nicht vorgesehen war. Es war nicht vorgesehen, dass die Kontrollen eine Multi-App Umgebung testen sollte.

Demnach mussten alle Applikationen also einzeln getestet und die Schnittstellen separat bewertet werden. Drei SaaS Applikationen, die miteinander in einer Umgebung arbeiten sollen um eine einzige Lösung zu verwirklichen, bringen entsprechend zusätzliche Risiken mit sich. Angefangen von der API Sicherheit bis hin zur Sicherheit und Integrität der Daten sowie die Absicherung der Umgebung ist administrativ und verwaltungstechnisch anspruchsvoller. „Also gut“ dachten wir, jetzt wissen wir wenigstens, was der Scope in diesem Projekt tatsächlich ist. Tja….. nicht zu voreilig. Wenn da nicht diese Matroschka wäre…

ÖFFNUNG #2 – Das sind ja 3 Cloud Provider und ganze 5 Sites (RZ), eine Site sogar auf einem Hyperscaler – NICHT ein Provider und eine Site!

Als wir die Projektleitung gebeten hatten uns mit dem SaaS Anbieter zu verknüpfen um die entsprechenden Prüfungskoordination angehen zu können, Lief uns der kalte Schweiss so langsam den Rücken runter, als wir erfuhren, dass der Anbieter gar kein Anbieter ist, sondern lediglich ein Integrator, ein Generalunternehmen sozusagen, der unabhängig von allen Cloud Service Provider die Lösung zusammengebaut hat, um den Enterprise Bedarf in diesem Umfeld abdecken zu können. Das ist löblich, doch ist zugleich wesentlich schwieriger zu prüfen, da man in solch einem Fall weitere Akteure hat, die uns hinsichtlich unserer Sicherheit, der Verfügbarkeit und de Integrität direkt oder indirekt beeinflussen können. Sie müssen reguliert sein und zumindest unseren Basiskontrollen unterzogen worden sein, bevor sie als qualifizierte Lieferanten in Anspruch genommen werden dürfen. Sprichwort: Supply Chain Security.

Fragestellungen in Angesicht unserer Backup- und Notfallkonzepte (BCM) zeigten, dass wir auch Datenschutz, Lieferkettensicherheit und die technischen Massnahmen unserer Datenverarbeiter berücksichtigen mussten, vor allem wegen der diversen Standorte und Provider.

Auswirkungen:

Die integrierte Lösung musste nun nicht nur mehr aus Sicht “Technische Sicherheit und Verbindlichkeit” sondern auch aus Sicht

• Vertragliche Risiken und
• Datenschutz und Auftragsverarbeitungsverträge sowie
• Service Level und Wartungsverträge

durchleuchtet werden. Die Feststellung, dass es sich tatsächlich um einen Unternehmer, 3 Cloud Provider, 5 Sites und mehrere Sub-Lieferanten handelte, machte die gesamte Prüfung wesentlich komplizierter.

Differenzierung: Nun könnte man meinen „Es sind ja SaaS Applikationen, das sollte anders betrachtet werden als klassische IT Hosting Verträge oder Managed Services“. Dann sollte man sich im Gegenzug fragen: „Warum? Was ist an einer SaaS Lösung wesentlich vertrauenswürdiger, so dass ich mir keine Gedanken mehr um meine Risiken machen müsste?“

Deswegen müssen eben alle Verträge, Subvereinbarungen, technische und organisatorische Voraussetzungen etc. durchleuchtet werden. Denn niemand will aufgrund einer administrativen und technologischen Vereinfachung die Sicherheit herunterschrauben sowie neue Risiken in Kauf nehmen müssen.

ÖFFNUNG #3 – Es waren 3 Hauptlieferanten, nicht nur 1 GU

Einen weiteren Schock erlitten wir, als wir feststellen mussten, dass das Unternehmen, das uns die Lösung liefern und warten sollte, gar kein Lieferantenverhältnis mit uns darstellten konnte. Es waren die drei SaaS Applikationsanbieter, die zugleich als Lieferanten in die Verträge aufgenommen wurden. Der Generalunternehmer hatte somit technisch keine Möglichkeit die Lieferanten vollumfänglich zu regulieren oder zu beeinflussen, so dass ggf. unser Sicherheitsregelwerk vollumfänglich durchgesetzt werden konnte.

Auch administrative Tasks wurden vertraglich über direkte Verhältnisse zu Lieferanten delegiert. Doch diese hatten untereinander keinerlei Verträge. Es war immer eine 1 zu 1 Beziehung zwischen Kunde und Lieferant festzustellen. Somit war es z.B. dem Hauptapplikationslieferanten A gleichgültig, wenn die Applikation beim Lieferanten B ausfallen würde und der Kunde, also wir die Lösung nur noch teilweise hätten benutzen können.

Das war ein hohes Risiko für uns, weshalb wir einzelne Verträge hätten mit den Lieferanten bzw. den jeweiligen Cloud Service Provider abschliessen müssen, oder… wir verpflichteten einfach das Generalunternehmen dazu, den Kopf hinzuhalten, sollte einmal dieses ITSCM Szenario auftreten.

Frage: Welche Variante hättet ihr gewählt?

Auswirkungen:

Stärkere Involvierung der Rechtsabteilung. Nachverhandlungen im Vertragswesen mit dem General Unternehmen, ggf. auch General Unternehmen mit Hauptlieferanten und weiteren Supplier.

ÖFFNUNG #4 – Es war eine Inbound-Verbindung in unser eigenes Rechenzentrum notwendig

Erst auf unsere Anfrage hin, wie das Access-Konzept sowie das Security Monitoring dieser Umgebung realisiert werden würde, stellten wir das Vorhaben einer Inbound-Verbindung fest, die zudem noch eine Schnittstelle aufgewiesen hat, die eine Art Synchronisationen aus einer anderen, datenkritischen Applikation in Richtung Cloud dienen sollte.

Inbound-Verbindungen waren für uns insofern ein Sonderthema, da die internen Anforderungen diesbezüglich sehr streng waren und unser Sicherheitskontrollsystem für Cloud Bedarfe eine Inbound-Prüfung nicht beinhaltete.

An dieser Stelle platzte uns der „Kragen“ und die Matroschka explodierte 🙂

Auswirkungen auf das Projekt:

Wir mussten weitere Schnittstellen evaluieren, die gezielte Architektur im Vorfeld besprechen und weitere Fachabteilungen befragen(Netzwerksicherheit, SOC, Firewall-Team etc.)

Die Konvergenz der Erkenntnisse

An dieser Stelle hatten wir zu viele Feststellungen aus unterschiedlichen Themen und Disziplinen sammeln müssen. Einige Feststellungen deuteten auf signifikante Risiken für unser Unternehmen hin. Nicht nur die Komplexität der Beteiligten Technik und Firmen machte uns zu schaffen, sondern die Involvierung der Rechtsabteilung vergrösserte die Reichweite der Auswirkungen, welche das Projekt direkt beeinflusste.

All unsere Bemühungen, unsere Risiken zu erheben und diese Risiken bewerten zu können, brachte selbstverständlich auch den negativen Effekt mit sich: Unser Office wurde innerhalb der Projektleitung als „Showstopper“ wahrgenommen. Die Beschwerden über uns häuften sich allmählich.

Wir entschieden uns aus diesem Grund, den Stand der Erkenntnisse umfangreich in einem Zwischenbericht samt Feststellungskatalog sowie Massnahmenempfehlungen an das „Steering Committee“ zu eskalieren.

Problems at a Glance:

• Das Projekt hatte das interne Prüfungssystem für Cloud-Beschaffung überrannt.
• Das Cloud Security Kontrollsystem war in dieser Phase für die Behandlung von  Multi-Cloud/Multi-Site/Multi-Supplier Projekten nicht ausreichend skaliert.
• Policies und Prozesse zu Cloud-Diensten behandelten überwiegend homogene SaaS Gebilde.
• Architekturvarianten und Multi-Betreibungsmodelle wurden noch nicht berücksichtigt.
• Identifizierte Risiken wären aufgrund ansonsten fehlender Erfahrungen untergegangen.

Lessons Learnd

• Das Steering Committee war durch unsere Arbeit erfreut, da Risiken hervorgehoben wurden. Es war jedoch gleichzeitig kritisch über die Stolpersteine (Perspektive) im Gang in die Cloud.
• Die Projektleitung sowie der General Unternehmer waren aufgrund Time/Budget enorm gestresst und fühlten sich von uns stark gehindert (Umsetzungsdruck)
• Haftungslücken mussten rechtlich nachgeregelt werden (Rechtliche Anpassungen)
• Datenschutzrechtliche Korrekturen waren notwendig (Data Privacy Compliance)
• Technische Überwachung der Konzepte zu Schnittstellen und Sicherheitsarchitektur wurde obligatorisch (Technische Sicherheitskontrolle)

Fazit

Das Projekt kann insgesamt als erfolgreich bewertet werden, jedoch traten im Verlauf mehrere strukturelle und organisatorische Schwächen zutage. Während das Management die erzielten Ergebnisse und den inhaltlichen Mehrwert unserer Arbeit ausdrücklich positiv hervorhob, zeigte sich zugleich ein Bedarf an Optimierung in verschiedenen Bereichen.

Die Projektleitung sowie der Generalunternehmer standen unter erheblichem Zeit- und Budgetdruck, was zu Spannungen und Behinderungen im operativen Ablauf führte. Diese Situation verdeutlicht die Notwendigkeit einer realistischeren Ressourcen- und Terminplanung sowie einer klareren Rollen- und Verantwortungsverteilung.

Im rechtlichen Bereich mussten Haftungsfragen nachträglich präzisiert und angepasst werden, um bestehende Lücken zu schliessen. Ebenso wurden datenschutzrechtliche Korrekturen erforderlich, um die Compliance-Anforderungen zu erfüllen.

Auf technischer Ebene wurde die Überwachung der Konzepte zu Schnittstellen und Sicherheitsarchitektur nachträglich verpflichtend eingeführt. Dies unterstreicht die Bedeutung einer frühzeitigen und kontinuierlichen Qualitätssicherung im Projektverlauf.

Zusammenfassend lässt sich sagen, dass das Projekt trotz erheblicher Herausforderungen im weiteren Verlauf erfolgreich umgesetzt wurde. Die aufgetretenen Stolpersteine lieferten wertvolle Erkenntnisse für zukünftige Vorhaben, insbesondere im Hinblick auf Governance, Compliance und technische Kontrollen.