Lehren aus Googles FedRAMP-Programm für die Skalierung auf eine CISO-Position mit mehreren Frameworks

Drew Gutstein hat Compliance-Probleme in nahezu allen Größenordnungen behoben. Fast fünf Jahre lang entwickelte und leitete er Googles FedRAMP-Programm. 2023 wechselte er zu Hudson River Trading (HRT), um dort die Sicherheits-Governance-Funktion von Grund auf aufzubauen. Im darauffolgenden Jahr übernahm er die Position des CISO und jonglierte mit den Anforderungen von NIST CSF, DORA und SEBI-CSCRF – insgesamt etwa einem Dutzend Regulierungsregimen. Mittlerweile hat er HRT verlassen, um sein eigenes Unternehmen, Gutstein Security Works, zu gründen. Dort entwickelt er maßgeschneiderte, automatisierte Cybersicherheitslösungen für komplexe Geschäftsumgebungen. Wir trafen ihn mitten in der Entwicklungsphase, um mit ihm über die Erkenntnisse zu sprechen, die nur jemand mit Erfahrung in allen drei Rollen (CISO, Sicherheitsingenieur und Ansprechpartner für regulatorische Angelegenheiten) vermitteln kann: Warum Compliance in jeder Größenordnung auf die gleiche Weise versagt und wie man diese Probleme tatsächlich beheben kann.

Wir sprachen darüber, was als erstes kaputtgeht, wenn Compliance nicht mehr manuell erfolgt, warum sich das Insiderrisiko stillschweigend verschlimmert und warum das Drittparteienrisikomanagement bisher noch niemand wirklich gelöst hat.

KI erweitert nicht nur das externe Risiko, sondern auch das Insiderrisiko.

Fragt man Gutstein nach der nächsten Risikowelle, verweist er auf Entwickler-Endpunkte und darauf, wie KI die Bedrohungslage durch Insider auf zweierlei Weise verändert. Erstens sind KI-Systeme selbst ein Ziel: „Der Einsatz von KI in Unternehmen schafft eine riesige Angriffsfläche für Phishing-Angriffe“, erklärt er. Ein KI-System lässt sich genauso manipulieren wie ein Mensch durch einen schädlichen Link getäuscht werden kann. Zweitens schreibt und committet KI nun direkt Code. Wird dieser Code eingecheckt und implizit als vertrauenswürdig eingestuft, wie es bei von Menschen geschriebenem Code üblich ist, kann er in der Produktionsumgebung – oder schlimmer noch, in der CI/CD-Pipeline eines Unternehmens – landen, bevor das Problem überhaupt erkannt wird.

Seine Empfehlung: Entwicklerumgebungen mit deutlich weniger Vertrauen behandeln – und zwar in beiden Bereichen. „Haltet Entwickler-Endpunkte von allem fern“, sagte er. „Hier haben die Angriffe auf die Lieferkette ihren Ursprung.“ Er möchte außerdem eine Vorgehensweise aus dem Open-Source-Bereich vollständig übernehmen: Interne Codeänderungen müssen vor der Veröffentlichung einer unabhängigen Prüfung unterzogen werden, genauso wie ein Maintainer einen Pull Request von einem Fremden prüft. „Wir haben bereits eine sehr ausgereifte Methode, um es Nutzern zu ermöglichen, Code, der ihnen nicht gehört, sicher zu bearbeiten. Das nennt man Open Source“, sagte er. Sein Argument: Open-Source-Maintainer vertrauen einem Beitrag niemals allein aufgrund des Einreichers. Jede Änderung wird vor dem Zusammenführen unabhängig geprüft, egal ob sie von einem Fremden stammt oder nicht. Unternehmen hingegen schenken dem Code ihrer Mitarbeiter (und mittlerweile auch ihren eigenen KI-Agenten) in der Regel automatisch Vertrauen, obwohl dieser Code das gleiche Risiko birgt. Drew hat noch kein einziges Unternehmen erlebt, das diese Open-Source-Disziplin intern eingeführt hat, so naheliegend die Lösung auch sein mag, wenn man sie ausspricht.

Compliance im Hypermaßstab

Bei Google verantwortete Gutstein die FedRAMP-Konformität für über 33 Millionen virtuelle Maschinen und Millionen von Containern – eine Größenordnung, bei der der tabellenkalkulationsbasierte Ansatz des Programms an seine Grenzen stieß. FedRAMP schreibt monatliche Sicherheitslückenberichte vor, und bei Googles Umfang passten die Zahlen schlichtweg nicht in eine Tabelle. Diese Größenordnung führte somit dazu, dass das vom Programm erwartete Berichtsformat nicht mehr praktikabel war. „Stellen Sie sich eine Tabelle mit 33 Millionen Maschinen und unzähligen Sicherheitslücken vor. Das passt einfach nicht in eine Tabelle“, erklärte er. Diese Diskrepanz führt er darauf zurück, dass die Hyperscale-Entwicklung die von allen – einschließlich der Regulierungsbehörden – verwendeten Tools so schnell überholt hat.

Diese Lücke veranlasste Gutstein, an OSCAL zu arbeiten, einem vom NIST unterstützten Standardformat für Kontrolldaten. „Man kann es sich wie die XML-Version des Sicherheitsplans im PDF-Format vorstellen“, erklärte er. Der Grundgedanke war, Nachweise maschinenlesbar statt manuell zusammenzustellen. Er vertrat Google außerdem im Cloud Service Provider Advisory Board und drängte Cloud-Anbieter dazu, gegenüber den FedRAMP-Regulierungsbehörden mit einer Stimme zu sprechen, wie die Einhaltung der Vorschriften tatsächlich gemessen werden sollte, anstatt widersprüchliche Forderungen zu stellen, die die Weiterentwicklung von FedRAMP behindern würden.

Die Skalierung führte auch intern zu Engpässen. Googles Kerninfrastruktur bot integrierte Sicherheitsfunktionen, GCP jedoch nicht. Um die Scanabdeckung auf GCP auszuweiten, musste Googles internes Scan-Team, das bisher nur die eigene Infrastruktur und nie die kundenorientierten Produkte von GCP geprüft hatte, eingebunden werden. Die Zustimmung des Teams war bis hin zur CEO von Google Cloud erforderlich. Selbst mit dieser Unterstützung reichte die Kapazität bei Weitem nicht aus: Geplant waren 40 gescannte Produkte im Quartal; das Team schaffte tatsächlich nur zwei.

Eine strukturelle Lösung, die er noch immer bewundert, stammt von einem Konkurrenten. Microsoft entwickelte eine „Änderungstyp-Autorisierung“, die es ermöglicht, neue Azure-Produkte innerhalb weniger Wochen auf den FedRAMP-Marktplatz zu bringen, anstatt der üblichen einjährigen Wartezeit. „Microsoft wollte seinen Softwareentwicklungszyklus (SDLC) so auditieren, dass die Regierung jede Version einfach abnehmen kann. Und ja, der Prozess selbst wird regelmäßig von Prüfern kontrolliert“, sagte er, aber sie sparen dadurch trotzdem effektiv viel Zeit. „Man muss nicht Microsoft sein, um das zu schaffen“, sagt er, räumt aber gleichzeitig ein, dass es schwierig ist, ein solches System zu entwickeln und erfolgreich zu implementieren.

Das Drittparteienrisikomanagement ist noch immer nicht gelöst.

Gutstein ist hier ungewöhnlich direkt: „TPRM ist einfach noch nicht ausgereift“, sagt er. Bei HRT führte sein Team eine informelle Studie durch, in der es durch Nachrichten ausgelöste Sicherheitswarnungen mit Benachrichtigungen aus dem formalen Drittanbieter-Risikomanagementsystem verglich. Das Ergebnis war beunruhigend: „Es dauerte deutlich länger, bis die Warnung vom Drittanbieter-Risikomanagementsystem einging, und es schien keinerlei Zusammenhang zwischen der Risikobewertung und der Wahrscheinlichkeit eines Angriffs zu bestehen.“

Ein Teil des Problems liegt seiner Ansicht nach darin, dass die Disziplin immer noch fast ausschließlich auf selbstberichteten Dokumenten beruht. Fragebögen erwecken zwar den Anschein von Sorgfalt, ohne das Risiko zwangsläufig zu reduzieren, und können angesichts dokumentierter Fälle gefälschter Compliance-Berichte sogar irreführend sein. Denselben Ansatz, der ihn zur Open-Source-Code-Review für internen Code geführt hat, wendet er auch auf das Lieferanten-Ökosystem an und zieht damit eine Unterscheidung, die die meisten TPRM-Programme außer Acht lassen: Open-Source- und Fremdauftragscode verdienen ein anderes Vertrauensmodell als Lieferantensoftware, keine einheitliche Pauschalrichtlinie. Kurz gesagt: Jeder Code wird gründlich geprüft, und zwar je nach dem tatsächlichen Risiko, das er birgt, unterschiedlich.

Sein wichtigster Punkt betrifft den eigentlichen Engpass bei der Lieferantensteuerung. Um die Prüfflut zu vermeiden, die zu Blockaden führt und Teams dazu zwingt, den Prozess komplett zu umgehen, schlägt er vor, dass jede Anfrage für ein neues Tool oder einen neuen Lieferanten einer zentralen Frage unterzogen werden sollte, bevor sie überhaupt die Sicherheitsabteilung erreicht. „Die wichtigste Frage im Drittanbieter-Risikomanagement lautet: Brauchen Sie es wirklich? Und wenn die Antwort ‚ein bisschen‘ lautet, brauchen Sie es wahrscheinlich nicht“, sagte er und argumentierte, dass Tools bereits im Beschaffungsprozess aussortiert werden sollten, bevor sie überhaupt in die Sicherheitsprüfung gelangen.

Bei den Tools, die sich durchsetzen, sieht er die Automatisierung von TPRM in Richtung neuerer Lösungen gehen, die SaaS-Konnektoren in einer einzigen Integrationsschicht konsolidieren und statische, auf Selbstauskünften basierende Fragebögen durch kontinuierlichere Daten ersetzen. Diese Tools binden sich über APIs direkt in die Systeme eines Unternehmens (Okta, Cloud-Plattformen usw.) ein und erfassen Daten in Echtzeit, anstatt dass jemand manuell eine Tabelle exportieren und hochladen muss.

Gleichzeitig unter einem Dutzend regulatorischer Rahmenbedingungen tätig

Der Wechsel von einem Bundesprogramm zu einer CISO-Rolle mit mehreren Rahmenwerken konfrontierte Gutstein mit einer neuen Komplexität: Überschneidungen. Bei HRT überwachte er gleichzeitig die Verpflichtungen gemäß NIST CSF, DORA, SEBI-CSCRF und anderen. Rahmenwerke, so Gutstein, konvergieren zunehmend um dieselbe zugrunde liegende Kontrollsprache, obwohl ständig neue hinzukommen. Sein Ansatz bestand darin, Kontrollen verschiedener Systeme auf Äquivalenz zu prüfen und mithilfe von Automatisierung Nachweise wiederzuverwenden, anstatt dieselbe Kontrolle mehrfach nachzuweisen.

Der größere Wandel, so argumentiert er, liege im Timing: „Wenn man ein Dutzend Aufsichtsbehörden hat und ständig parallel Audits stattfinden, muss man permanent vorbereitet sein. Deshalb braucht man kontinuierliche Compliance und kontinuierliche Sicherheit.“ Er spricht auch offen über die Wettbewerbsvorteile: „Wenn ich wirklich gute Arbeit leiste und die Messlatte für alle anderen höher lege, umso besser.“

Der rote Faden

In seinen drei Funktionen – CISO, Sicherheitsingenieur und Ansprechpartner für regulatorische Angelegenheiten – kommt Gutstein immer wieder zum selben Schluss. „Deshalb bin ich so begeistert von Automatisierung“, sagt er, „denn genau hier liegt der Nutzen: Man kann die Sicherheitslast von denjenigen nehmen, die eigentlich nicht dafür zuständig sind.“ Governance ist seiner Ansicht nach keine reine Bürokratie. Es geht um die Gestaltung menschlichen Verhaltens, und die Lösung ist fast immer dieselbe: Die Beweissicherung automatisieren, nach tatsächlichem Risiko priorisieren und aufhören, Aktivitäten mit Sicherheit zu verwechseln.