Wie DevSecOps Ihr auf ISO 27001 basierendes ISMS ausgereifter machen kann

Vorwort

Beginnen wir mit einem leicht überzeichneten Bild der Informationssicherheit. Warum? Weil sie eine seltsame Sache ist. Nahezu jeder kennt sie. Die meisten Menschen sind bereits direkt oder indirekt damit in Berührung gekommen. Sie erzählen Ihnen, wie wichtig sie ist und wie schlimm es wäre, wenn ein Cyberangriff stattfindet. Auf der anderen Seite müssen sich Sicherheitsbeauftragte, die versuchen, Sicherheitsmaßnahmen zu ergreifen, oft mit Widerständen auseinandersetzen:

• Die "Sicherheitsleute" blockieren oder verlangsamen immer die profitabelsten Projekte für die Geschäftsseite.
• Die Entwickler und Systemadministratoren sehen nur den zusätzlichen Arbeitsaufwand, der ihnen durch die Sicherheit entsteht.
• Für viele Endbenutzer scheint es eine Art Sport zu sein, Sicherheitsmaßnahmen auf die kreativste Weise zu umgehen.

Wie praktisch Sicherheit sein kann

Wir wollen keine Schwarzmaler sein, es ist nicht immer so schlimm, wie wir es gerade beschrieben haben, aber Menschen, die im Bereich der Informationssicherheit arbeiten, kennen einige der oben genannten Geschichten vielleicht schon länger. In diesem Artikel geht es nicht darum, sich zu beschweren, sondern zu erklären, wie praktische Sicherheit in einem sehr frühen Stadium der Softwareentwicklung mit DevSecOps umgesetzt werden kann.

Gleichzeitig bezieht es sich auf die eher theoretischen und auf die Einhaltung von Vorschriften ausgerichteten Informationssicherheitsmanagementsysteme (ISMS), die die meisten Unternehmen heute einsetzen. Es gibt verschiedene Ideen, wie man beide Ansätze miteinander verbinden kann. Wir werden uns auf einen relativ neuen Ansatz konzentrieren: OWASP DSOMM, das DevSecOps Maturity Model des Open Web Application Security Project.

ISO 27001: gut bekannt und weit verbreitet

Beginnen wir mit ISO 27001, der Norm für Informationssicherheit, auf der das ISMS der meisten unserer Kunden basiert. Während die ISO 27001 die allgemeinen Anforderungen definiert, enthält die zugehörige ISO 27002 eine detaillierte Liste der erforderlichen und empfohlenen Dokumente. Sie misst Kontrollen von organisatorischen Themen wie einer gut definierten Informationssicherheitsorganisation über Prozesse (On-/Offboarding, Reaktion auf Vorfälle, Lieferantenmanagement) bis hin zu detaillierten Anforderungen wie einer Passwortpolitik oder einer gut definierten Rollen- und Verantwortungsmatrix.

Was wirklich gebraucht wird

Die Leute beschweren sich über die Anforderungen und Kontrollen der ISO-Norm, weil sie ihr Tagesgeschäft verändert; sie ist zu hoch angesetzt. Viele möchten präzise Anforderungen haben, die sie direkt anwenden und umsetzen können, aber leider funktioniert die reine ISO 27001 / 27002 nicht auf dieser Ebene. Es ist eine Zuordnung zwischen der hohen Ebene und der niedrigen Ebene der praktischen Umsetzung für den täglichen Betrieb erforderlich.

Daher konzentrieren wir uns auf eine neue Abbildungsidee: Ein Teil der in ISO 27002 aufgeführten Anforderungen ist ein "dokumentierter Systementwicklungsprozess" (Abschnitt A.14). An dieser Stelle kommen DevSecOps und das OWASP DevSecOps Maturity Model (DSOMM) ins Spiel.

Warum DevSecOps für Ihr Unternehmen sinnvoll ist

DevOps (Kombination aus Softwareentwicklung - "Dev"; und IT-Betrieb "Ops") ist in der Softwareentwicklungsbranche ebenfalls seit Jahren bekannt. Ihr Ziel ist es, den Lebenszyklus der Systementwicklung zu verkürzen und eine kontinuierliche Bereitstellung mit hoher Softwarequalität zu gewährleisten. Eine solche Softwareentwicklung auf der Grundlage von DevOps wird häufig im Rahmen von agilen Ansätzen wie Scrum oder Kanban umgesetzt, da beide Ideen auf das gleiche Ziel abzielen: kurze Lebenszyklen und kontinuierliche Lieferung.

DevSecOps (DevOps mit tief integrierter Sicherheit - "Sec") wurde später zu DevOps hinzugefügt, als man erkannte, dass die Implementierung von Sicherheit bereits in einer frühen Entwicklungsphase mehrere Vorteile hat. Mögliche Sicherheitsprobleme werden frühzeitig erkannt, und eine Behebung während oder in einem späten Entwicklungsstadium ist nicht erforderlich. Als Faustregel gilt: Je später im Software-Lebenszyklus ein Sicherheitsproblem erkannt wird, desto teurer wird die Behebung.

Identifizierung von Sicherheitsproblemen

Relative Kosten für die Behebung von Fehlern, basierend auf dem Zeitpunkt der Entdeckung

Wenn man sich bereits in der Entwicklungsphase (Anforderungen, Architektur, Kodierung, Integration, Komponententests) um Sicherheitslücken kümmert, kann man eine Menge Ressourcen sparen - Zeit und Budget, aber auch eine schlechte Motivation des Teams.

Um auf die anfänglichen Widerstände zurückzukommen, mit denen Sicherheitsbeauftragte konfrontiert sind, würde DevSecOps mehrere Parteien zufrieden stellen:

1. Erstens, die geschäftliche Seite
   1. keine (oder zumindest weniger) späte "Blocker" von der Sicherheit erhält
   2. geringere Kosten sowie mehr Projekte innerhalb des Zeit- und Budgetrahmens durch frühzeitige Fehlerbehebung
2. Zweitens, die Entwickler und Systemadministratoren
   1. sich während der Tests und der Implementierung mit weniger Sicherheitsproblemen befassen müssen, was viel Zeit sparen könnte
   2. sich automatisch dazu erziehen, es bei künftigen Projekten auf die gleiche und sicherere Weise zu tun, da der Gesamtprozess einfacher und weniger frustrierend war

Wie gerade beschrieben, hat die Softwareentwicklung mit dem DevSecOps-Ansatz viele Vorteile. Das Problem ist, wie wir diesen eher praktischen und entwicklungsorientierten Ansatz als Input für ein ISMS nach ISO 27001 nutzen können:

• wie man Geheimnisse aufbewahrt,
• wie man vertrauliche Parameter übergibt, oder
• wie man eine Bestandsaufnahme laufender Artefakte durchführt, und so weiter.

Bei diesem Ansatz werden diese Themen nicht auf einer so detaillierten Ebene behandelt. Der Input ist notwendig, um zu dokumentieren und nachzuweisen, was getan wird, um bestimmte ISO 27002-Kontrollen zu erreichen. Jeder, der jemals an einem ISO 27001-basierten Audit teilgenommen hat, weiß, wie wichtig solche Informationen sind und wie sehr sich die meisten Auditoren auf das SoA (Statement of Applicability) konzentrieren. Das SoA dokumentiert genau solche Zusammenhänge zwischen einer ISO 27002-Kontrolle und der technischen oder organisatorischen Maßnahme, die ein Unternehmen zu deren Bewältigung umgesetzt hat.

Kombinieren Sie sie: der OWASP DSOMM-Ansatz

Auch das Projektteam von OWASP DSOMM hat diesen Bedarf erkannt. Vor kurzem wurde ein Mapping von den DSOMM-Themen zu den ISO 27002-Kontrollen hinzugefügt. Einige unserer Kunden, die nach DevSecOps arbeiten, nutzen dieses Mapping bereits. Der ISMS-Maintainer kann die Maßnahmen, die während DevSecOps durchgeführt werden, direkt den entsprechenden ISO 27002-Kontrollen zuordnen, wie sie in der SoA aufgeführt sind. Die meisten DSOMM-Zuordnungen beziehen sich auf A.14 (dokumentierter Systementwicklungsprozess) und einige auf Kontrollen wie A.12 (Betrieb, Backups, Überwachung usw.), so dass die Abdeckung bereits relativ groß ist.

Die Verwendung des neuen DSOMM-ISO27701-Mappings könnte also eine Brücke zwischen dem High-Level-ISMS und dem Low-Level-Softwareentwicklungsprozess sein. Wir empfehlen dringend, dieses Thema zwischen den Produkt- und Risikoverantwortlichen der Entwicklungsteams und den Informationssicherheitsbeauftragten (CISO) zu besprechen. Das ist ein Schritt in Richtung einer ausgereiften und sicheren Software. Und gleichzeitig auch ein Schritt zu einem ausgereiften ISMS.

Schlussfolgerung

Entwickeln Sie in Ihrem Unternehmen Software, entweder für den eigenen Gebrauch oder als Produkt für andere? Interessieren Sie sich für Informationssicherheit, nicht nur in der Theorie, sondern auch auf praktischer Ebene? Dann sollten Sie sich auf jeden Fall mit DevSecOps im Allgemeinen auseinandersetzen, insbesondere wenn Ihre Entwicklungsteams bereits agil arbeiten. Wir von der CISO AG helfen Ihnen, die zentralen Sicherheitsaufgaben zu automatisieren und in Ihren DevOps-Workflow zu implementieren.