DevSecOps in der Versicherungswirtschaft

Manchmal kann man den Eindruck gewinnen, die Software-Engineering-Praxis springt gerne von einem Extrem in das andere. Es gab mal eine Zeit, da war Softwareentwicklung extrem aufgeteilt. Jeder Prozessabschnitt sollte geplant, modelliert, dokumentiert, entwickelt und getestet sein. Und alles war soweit in sich abgeschlossen, dass der nächste Schritt problemlos von einem anderen Team übernommen werden konnte. Spezialisierung galt wohl als Schlüssel für hohen Durchsatz bei hoher Qualität. Gut funktioniert hat das oft nicht. Modelle und Dokumente erzeugen Aufwand und sind schwer, aktuell zu halten. Schnell entsteht der Eindruck, dass sie ohnehin nicht gelesen würden. So verkommen sie zu einer mühseligen Pflichtübung, die Qualität der Dokumentation sinkt weiter und aus dem Eindruck wird eine selbsterfüllende Prophezeiung. Natürlich funktioniert die Übergabe zwischen den Teams dann mehr schlecht als recht. Theoretisch fertige Artefakte bleiben liegen, wenn das nachfolgende Team keine Zeit hat, sie zu übernehmen und sich einzuarbeiten. Wenn es dann später dazu kommt, sind Rückfragen schwer, da das vorhergehende Team längst in einem neuen Thema steckt.

Typ:
Blogartikel
Rubrik:
Analytik & IT
Themen:
Agilität Cybercrime IT
DevSecOps in der Versicherungswirtschaft

Mit agilen Methoden alte Hürden überwinden

Mit Agilität und kontinuierlicher Integration sollten solche (und weitere) Schwierigkeiten überwunden werden. Die agilen Methoden bedeuten zunächst ein Umdenken für die Entwicklungsabteilungen, langfristig ist es aber nur konsequent, wenn die Änderungen auch in den IT-Betrieb hineinwirken. Denn es macht wenig Sinn, die Softwarekomponenten mit großem Schwung und Elan zu entwickeln, und dann genau so wie vorher vor der Mauer zum Betrieb abzustellen, nur noch kleinteiliger und mit viel weniger Dokumentation.

DevOps ist eine Lösung für diesen Strömungsabriss. IT-Entwicklung (development), Qualitätssicherung und -betrieb (operations) werden zusammengeführt. Die Menschen, die die Software entwickeln, begleiten sie bis zur Inbetriebnahme und sind auch später für Wartungsaufgaben greifbar. Natürlich hat auch diese Lösung Vor- und Nachteile. Die Reibungen und der Informationsverlust an den Übergabepunkten nehmen ab und die Änderungen kommen schneller zum Einsatz. Wo früher Entwickler aus Unwissenheit über die eigentlichen Zielsysteme Inkompatibilitäten verursachten, die dann erst ausgebessert werden mussten, wird jetzt gleich beim ersten Mal passend entwickelt.  Ineffizienzen können jedoch auch in der schönen neuen DevOps-Welt entstehen, z. B. weil die Mitarbeiter sich durch konkurrierende Entwicklungs- und Wartungsaufgaben nicht auf ein Thema konzentrieren können. Gerade für Scrum ist die Exklusivität der Entwicklungsaufgaben ein hohes Gut. Wer in einem Sprint ist, sollte gerade nicht durch Rückfragen und Wartungsaufgaben abgelenkt werden.

IT-Sicherheit soll Kanon ergänzen

In letzter Zeit wird mancherorts probiert, noch einen weiteren Aspekt, nämlich die IT-Sicherheit, mit in den Kanon zu nehmen. So entstehen dann DevSecOps. Dafür spricht, dass Sicherheitsaspekte idealerweise sowohl während der Entwicklung als auch während der Übernahme in den Betrieb beachtet werden müssen. Gerade im Wechsel zwischen den Entwicklungs- und Betriebswelten können Gefahren versteckt sein. Die reine Lehre ist, dass „Sicherheit eine lokale Eigenschaft“ sein muss. Demnach sollte jede IT-Komponente fürsich genommen sicher arbeiten, unabhängig davon, wie sie eingesetzt wird. In der Praxis wird dieses Ideal oft vernachlässigt und man verlässt sich darauf, dass bestimmte Komponenten in einer sicheren Umgebung mit vertrauenswürdigen Eingabedaten betrieben werden. Dazu muss die Einsatzbedingung aber während der Entwicklung bekannt sein und darf auch später nicht mehr geändert werden. Wenn die IT-Sicherheitsexperten nun tief in Entwicklung und Betrieb involviert sind, haben sie auch die besten Voraussetzungen, genau solche  Veränderungen des Einsatzes zu erkennen und zu verstehen, welche Gefahren darin für die konkret eingesetzten Systeme lauern. Ohnehin wäre zu erwarten, dass Sicherheitsexperten, die direkt in der Entwicklung eingebunden sind, es leichter haben, die richtigen Weichen zu stellen, als solche, die erst später zum Auditieren hinzugezogen werden. Nun ist die Versicherungswirtschaft durch die regulatorischen Rahmenbedingungen (VAIT, MaRisk, KRITIS etc.) ohnehin alles andere als frei in der Entscheidung, ob und wie IT-Sicherheit erreicht wird. In regulierten Bereichen sind begleitende Sicherheitsmaßnahmen und nachträgliche Prüfungen kein „entweder oder“ sondern eher ein „sowohl als auch“.

Schattenseiten des neuen Paradigmas

Doch auch ohne die regulatorischen Besonderheiten der Finanzwirtschaft kann das Paradigma DevSecOps seine Schattenseiten haben. Das Ganze funktioniert überhaupt nur dann richtig, wenn die nötigen Kompetenzen aus den verschiedenen Bereichen auch wirklich in den DevSec-Ops-Teams vorhanden sind und ausreichend Zeit für die kontinuierliche Durchführung aller Aufgaben eingeräumt wird. Zurzeit wird viel nach „Full-Stack-Entwicklern“ gesucht, die alle Fähigkeiten in einer Person vereinen. Möglicherweise ist das gar nicht so klug. Der Sinn eines interdisziplinären Teams liegt schließlich nicht darin, dass wenige alles gleichermaßen können, sondern dass viele aus verschiedenen Richtungen auf ein Problem schauen. So lohnend es sein mag, in alle Bereiche einmal hineingeschnuppert zu haben und grundsätzlich mitreden zu können: Ab einer bestimmten Teamgröße sind Spezialisierungen empfehlenswerter. Falsch umgesetzt kann DevSecOps auch zum Feigenblatt verkommen, das Vakanzen versteckt. Solange die Bereiche getrennt sind, fiele es gleich auf, wenn im Sicherheitsteam kein einziger Sicherheitsexperte wäre. Aber sogar eine komplett aus Quereinsteigern besetzte Sicherheitsabteilung könnte ihren Zweck erfüllen, da sich die Mitarbeiter zwangsläufig einarbeiten würden. In einem DevSec- Ops-Team aus Generalisten fällt ein Mangel möglicherweise viel zu spät auf, da sich jeder auf den anderen verlässt und alle durch Entwicklungs-, Test- und Betriebsaufgaben ausgelastet sind. Auch wenn die Kompetenzen im Team vorhanden sind, kann es passieren, dass alle Ressourcen auf einen Engpass geworfen werden und in Sachen Qualität und Sicherheit derweil unbeachtet die technologischen Schulden wachsen.

DevSecOps ist also keine Lösung, um mutmaßliche Qualitäts- oder Sicherheitsmängel en passant in den Griff zu bekommen, sondern eher ein Weiterentwicklungspfad für Teams, die alle Teildisziplinen für sich genommen im Griff haben.

Themen Tags