Das CISO-Paradoxon: Innovation ermöglichen und Risiken managen

Eine der Hauptaufgaben von CISOs besteht darin, nicht mehr die „Abteilung des Neins“ zu sein. Sie müssen Wege finden, die schnelle Bereitstellung von Produkten und Dienstleistungen für das Unternehmen zu ermöglichen, ohne gleichzeitig neue Risiken einzuführen.

Das ist, kurz gesagt, das Paradoxon. In einem Umfeld, in dem Produktteams ständig neue Technologien testen und Updates in Rekordgeschwindigkeit bereitstellen müssen, können traditionelle Audits am Ende des Entwicklungszyklus nicht mithalten. Sicherheit muss vorgelagert werden. Sie muss in den täglichen Betrieb integriert werden, mit proaktiven, umsetzbaren Maßnahmen, die Innovationen fördern, anstatt sie zu bremsen.

CISOs müssen daher von Anfang an enger mit den Teams zusammenarbeiten, um klare und praktische Risikotoleranzen festzulegen und Sicherheit in die Entwicklungsabläufe zu integrieren.

Frühzeitig Partnerschaften eingehen, um Ergebnisse zu gestalten

CISOs gewinnen nicht an Einfluss, wenn sie erst am Ende auftauchen. Sie müssen ihre Gatekeeper-Mentalität ablegen und vom ersten Tag an echte Partner sein. In der Vergangenheit, als Sicherheitsmaßnahmen erst in der Endphase eingeführt wurden, standen Entscheidungsträger vor einer schwierigen Wahl: Projektverzögerungen akzeptieren oder unverminderte Risiken in Kauf nehmen. Als Produktzyklen noch quartalsweise waren und Geschwindigkeit nicht über die Wettbewerbsfähigkeit entschied, war dieser Ansatz sinnvoll. In der heutigen Realität mit KI-gesteuerter Produktentwicklung funktioniert ein solcher Prozess in einem Umfeld, das aus Wochensprints, kontinuierlicher Bereitstellung und Abhängigkeiten von Herstellern besteht, nicht mehr.

Wenn die Sicherheitsabteilung die Umsatzziele, Kundenversprechen und regulatorischen Risiken versteht, werden die Leitlinien konkret und hilfreich. Unternehmen sollten daher jedem Produktteam einen Sicherheitsbeauftragten zur Seite stellen. Dadurch gibt es immer eine vertraute Person, die sich mit Entscheidungen zu Identität, Datenflüssen, Protokollierung und Verschlüsselung befasst, sobald diese anstehen. Wir sollten nicht wollen, dass Entwickler für eine einfache Frage zweiwöchige Tickets eröffnen müssen. Es sollte offene „Sprechstunden”, Chat-Kanäle und kurze Telefonate geben, damit sie sofortiges Feedback zu Entscheidungen wie API-Design, Verschlüsselungsanforderungen und regionalen Datenbewegungen erhalten.

Bürokratie muss im Sicherheitsumfeld abgeschafft werden. Sicherheitsmanager sollten an Sprint-Planungen und frühen Design-Reviews teilnehmen, um wichtige Fragen zu klären – beispielsweise Authentifizierungspfade, Least-Privilege-Zugriffe, Logging-Abdeckungoder wie Änderungen in der Produktion durch SIEM und EDR überwacht werden. Wenn CISOs mit am Tisch sitzen, ändert sich die Frage von „Können wir das machen?“ zu „Wie machen wir das sicher?“ und schon vom ersten Tag an werden bessere Ergebnisse erzielt.

Risikotoleranzen und Leitplanken festlegen

Teams werden langsamer, wenn sie sich nicht sicher sind, wie sie vorgehen sollen. Deshalb sollten ihnen ein Teil der Entscheidungsfindung abgenommen und die Integration von Authentifizierung, Autorisierung und Abrechnung in den Entwicklungsprozess übernommen werden. Für die Authentifizierung sollten Sie Lösungen für das Identitätsmanagement im Unternehmen einrichten und nutzen, anstatt Accounts zu entwickeln, die fest in Datenbanken geschrieben werden und die leicht kompromittierbar sind.

Sicherheitschefs müssen außerdem standardisierte rollenbasierte Zugriffskontrollstufen definieren, die eine klare Aufgabentrennung im Lösungsdesign gewährleisten. Dazu sollte die Abrechnung nicht nur aus Protokollen bestehen, sondern Daten mit hoher Kardinalität zur Erkennung von Anomalien erfassen. Anschließen müssen diese in ein zentrales SOC (Security Operations Center) zur Erkennung und Reaktion auf Bedrohungen integriert werden. Produktentwicklungsteams sollten nicht mit Sicherheitsaufgaben betraut werden; stattdessen sollten andere Teams die Sichtbarkeit der Bedrohungen für die Lösungen in der Produktion im Auge behalten.

CISOs müssen die Risikobereitschaft des Unternehmens in einer Geschäftssprache definieren, die keine Interpretationsspielräume zulässt. Sie sollten festlegen, welche Profile von Drittanbietern einer eingehenden Bewertung bedürfen und welche als begrenzte Pilotprojekte mit kompensierenden Kontrollen durchgeführt werden können. Entscheiden Sie, welche Schwachstellen einen Merge blockieren müssen und welche mit einem zeitlich begrenzten Behebungsplan fortgesetzt werden können. Klären Sie, welche Datenklassifizierungen regionenübergreifend sein dürfen und welche Schutzmaßnahmen dafür erforderlich sind.

Anschließend müssen diese Entscheidungen in Automatisierung umgesetzt werden. Integrieren Sie Schutzmaßnahmen in CI/CD und Infrastructure-as-Code, damit die Durchsetzung konsistent und sichtbar ist. Scannen Sie jeden Code-Commit auf Schwachstellen, und wenn eine Änderung gegen eine kritische Richtlinie verstößt, schlägt der Build fehl – mit einer klaren Begründung und einem Lösungsweg. Liegt die Änderung innerhalb der Toleranzen, wird er ohne manuelles Eingreifen fortgesetzt. Das Ergebnis ist Governance als Beschleuniger: vorhersehbar, transparent und abgestimmt auf die Arbeitsweise der Entwicklungsteams.

Security-by-Design in schnelle Entwicklerzyklen integrieren

Wenn Entwickler mehrmals täglich Code bereitstellen, funktioniert eine „abschließende Sicherheitsüberprüfung” vor der Veröffentlichung einfach nicht. Dieses traditionelle Gatekeeping-Modell am Ende des Prozesses blockiert nicht nur Innovationen, sondern versäumt es auch, reale Risiken zu erkennen. Um effektiv zu sein, muss Sicherheit während der Entwicklung eingebettet werden und nicht erst nachträglich überprüft werden.

Wenn der sichere Weg schwieriger ist als der unsichere Weg, werden Entwickler jedes Mal den einfachen Weg wählen. Die Aufgabe des CISO besteht nicht darin, ein 50-seitiges PDF zu verteilen, sondern Sicherheit direkt in die Entwicklerumgebung zu integrieren und ihnen vorab geprüfte, gehärtete Templates mit bereits integrierter Authentifizierung und Autorisierung zur Verfügung zu stellen, die standardmäßig sicher sind. Wenn die sichere Komponente einfacher zu verwenden ist als die unsichere Alternative, können Entwickler sie problemlos und jederzeit einsetzen.

Automatisierung ist die Durchsetzungsebene für diese Strategie. Wenn Sicherheitstools direkt in die CI/CD-Pipeline integriert sind, ist Feedback fast in Echtzeit verfügbar. So kann das Team bei kritischen Risiken „schnell scheitern“ und gleichzeitig umsetzbare Korrekturen vornehmen.

Diese Disziplin muss sich bis in die Produktion hineinziehen. Selbst mit erstklassigen DevSecOps wissen wir, dass Zero-Day-Angriffe oder Konfigurationsabweichungen auftreten können. Deshalb sollten wir uns auf übergreifende Lösungen zum Schutz von Webanwendungen verlassen, die eine robuste Web-Application-Firewall mit Laufzeit-Angriffsabwehr und Selbstschutz integrieren. Diese Lösungen mindern Schwachstellen und Risiken in Echtzeit, während die Anwendung in der Produktion läuft. Sie verschaffen den Entwicklungsteams die entscheidende Zeit, die sie benötigen, um das zugrunde liegende Problem ohne Dienstunterbrechung oder Sicherheitsverletzung zu beheben. Zudem wird so sichergestellt, dass wir selbst dann eingreifen können, wenn alle anderen Kontrollen versagen.

Laufzeit-Telemetrie und risikobasierte Warnmeldungen sind die letzte Schutzschicht in diesem Konzept. Dies fördert einen kulturellen Wandel, der es Entwicklern ermöglicht, die volle Verantwortung für ihre Anwendungen zu übernehmen, von der ersten Codezeile bis hin zur Produktion. Die Sicherheit wiederum erreicht so eine umfassende und dauerhafte Abdeckung, ohne zum Engpass zu werden. (jm)

Lesetipp: Vaillant-CISO im Interview – “Starten statt Warten”