Nicht jeder IKT-Vorfall hat einen Angreifer
Der Basler Ausschuss für Bankenaufsicht hat vor wenigen Tagen den Report „ICT Risk Management: Range of Practices" veröffentlicht, der eine Blickrichtung einnimmt, die wir sonst selten haben. Es geht im Report bewusst um nicht-böswillige IKT-Vorfälle, also um das, was im Cyber-Umfeld schiefgehen kann, ohne dass Angreifer beteiligt sind.
Der Basler Ausschuss für Bankenaufsicht hat vor wenigen Tagen den Report „ICT Risk Management: Range of Practices“ veröffentlicht, der eine Blickrichtung einnimmt, die wir sonst selten haben.
Es geht im Report bewusst um nicht-böswillige IKT-Vorfälle, also um das, was im Cyber-Umfeld schiefgehen kann, ohne dass Angreifer beteiligt sind.
Und soviel vorweg: die genannten Ursachen liegen erstaunlich nah an der betrieblichen Realität vieler Unternehmen:
- Schwächen im IKT-Änderungsmanagement
- Mängel in Systemdesign, Entwicklung und Test
- Kapazitäts- und Performance-Probleme
Bleibenden Eindruck haben bei mir die Ausführungen zu einer Bank hinterlassen, die über 5 Millionen IKT-Changes allein in 2025 umgesetzt hat!
Diese Menge kann ja niemand vollständig durch den kompletten IKT-Änderungsprozess schleusen. 😵💫
Bei solchen Größenordnungen wird klar, dass Risikoorientierung der einzig sinnvolle Steuerungsansatz ist: IKT-Änderungsrisiken werden bis zu einer gewissen Ebene vorab bewertet, darauf basierend Standard-Changes nach Kritikalität und Risiko definiert und so weit wie möglich automatisiert.
Nur wirklich kritische und risikoreiche Änderungen müssen dann die strengen Quality Gates des IKT-Änderungsmanagements durchlaufen.
Ein zweiter Punkt, der im Report adressiert wird und m.E.n. auch hoch-relevant ist: Unsachgemäße Umgebungstrennung! Denn wenn Testumgebungen die Realität der Produktionsumgebung nur eingeschränkt abbilden, treten Probleme oft erst beim Einspielen eines Changes in die Produktivumgebung auf.
Für mich bestätigt das einen Gedanken, den ich hier immer wieder teile: IKT-Risikomanagement heißt eben nicht, statische Kataloge mit Sicherheitsmaßnahmen abzuarbeiten und generische Soll-Ist-Vergleiche pauschal über den gesamten Anwendungs-Stack zu dokumentieren.
Denn selbst wenn vermeintlich jedes Soll im Ist auch formal umgesetzt wurde – so bleiben doch genau die Sachverhalte, die hier genannt wurden, die Hauptursachen für echte IKT-Vorfälle und für echte IKT-Risiken.
Sie entstehen im Betrieb – und sie verlangen kein theoretisches, sondern angewandtes IKT-Risikomanagement – eine Disziplin, die Grundvoraussetzung für die digitale operationelle Resilienz eines Unternehmens ist.