BSIMM: Ein Fahrplan in Richtung Softwaresicherheit

Das Building Security In Maturity-Modell ist ein Studiendesign zu real existierenden Software Security Initiatives, kurz SSIs. Hier werden die Praktiken vieler verschiedener Unternehmen quantifiziert und hinsichtlich von Gemeinsamkeiten sowie individuellen Variationen beschrieben. Dadurch liefert der Bericht quasi ein Spiegelbild der Softwaresicherheit von Unternehmen rund um den Globus. 

Die Ergebnisse sind zwar besonders relevant für Unternehmen, die Softwarekomponenten entwickeln oder zusammenstellen, aber im Grunde ist jeder, der heute unternehmerisch tätig ist, auch ein Softwareunternehmen. Software, um ein Unternehmen zu führen, ein Produkt zu vermarkten und sehr wahrscheinlich auch, um das Produkt zu entwickeln. Software ist in allen Abteilungen unverzichtbar geworden. Software ist zudem die Grundlage für die meisten Geräte und Dienste, mit denen wir uns alltäglich umgeben. Einschließlich der Geräte im Internet of Things (IoT) und dem Internet of Everything (IoE).

All diese Geräte, Systeme und Netzwerke funktionieren (oder versagen) aufgrund von Software. Wie wir alle wissen, ist Software nicht perfekt und Cyberkriminelle nutzen Konfigurations- und Designfehler, Bugs und andere Schwachstellen weidlich aus. Angesichts der potenziell schwerwiegenden Auswirkungen ist Softwaresicherheit entscheidend für das, was wir heute im modernen Leben als selbstverständlich ansehen, sowohl individuell als auch kollektiv.

BSIMM wurde erstmals 2009 veröffentlicht. Ziel war es, Unternehmen dabei zu unterstützen, Sicherheit innerhalb des gesamten Software-Entwicklungslebenszyklus (SDLC) zu integrieren und nicht erst am Ende dieses Prozesses. Was deutlich mehr Zeit und Geld kostet. Genau das macht BSIMM relevant.

Das Modell dokumentiert, was Unternehmen genau jetzt tun – und wieviel Zeit und Geld sie in Initiativen zur Softwaresicherheit investieren. Dabei basiert BSIMM11 auf SSIs von 130 teilnehmenden Unternehmen, in primär 9 Branchen: Cloud, IoT, unabhängige Softwareanbieter, Hochtechnologie, Gesundheitswesen, Versicherungen, Finanzdienstleistungen, FinTech und Einzelhandel. Der diesjährige Bericht verfolgt 121 separate Aktivitäten zur Softwaresicherheit. Sind in 12 Praktiken gruppiert, die wiederum in 4 Bereiche sortiert sind: Governance, Intelligenz, sicherer Software-Entwicklungszyklus (SSDL) und Bereitstellung. Daraus geht hervor, was die teilnehmenden Unternehmen genau tun und welche Tools sie verwenden. Vielleicht noch wichtiger ist die Tatsache, dass BSIMM zeigt, wie häufig jede Aktivität im aktuellen Datenpool auftaucht. Das wiederum ist für andere Branchenteilnehmer in anderen Bereichen hilfreich. 

Zu den wichtigsten Erkenntnissen des diesjährigen Berichts zählen die teilweise erheblichen Verschiebungen bei den Softwaresicherheitsinitiativen: 

Aus »Shift left« wird »Shift everywhere« 

In den ersten BSIMM-Ausgaben wurde vielfach das Shift-Left-Konzept, also das Verschieben der Sicherheit nach links, so früh wie möglich im SDLC, beschrieben. Der Begriff wurde schnell zu einem Mantra für Anbieter und dominierte Präsentationen, Vorträge und Podiumsdiskussionen. Man sollte das Konzept allerdings nicht auf Shift-Left einengen. Vielmehr geht es um „shift everywhere“. Also darum, eine Aktivität so schnell wie möglich und mit höchster Genauigkeit durchzuführen, sobald die Artefakte verfügbar sind, von denen diese Aktivität abhängt. Manchmal ist das links der laufenden Aktivitäten, aber oft ist es rechts, vielleicht sogar gänzlich innerhalb der Produktion.

Engineering fordert mehr Tempo bei der Sicherheit

In vielen Fällen sind Entwicklungsteams mittlerweile für einen Großteil der Softwaresicherheitsmaßnahmen zuständig. Mit Mitarbeitern, die für CloudSec, ContainerSec, DeploymentSec, ConfigSec, SecTools, OpsSec usw. verantwortlich sind. Das führt zu eher durchwachsenen Ergebnissen. Solche Teams sind agil und dadurch schnell. Das ist gut. Für das Management geht das nicht selten zu schnell. Jedenfalls, wenn man die Auswirkungen auf das Unternehmensrisiko verlässlich bewerten will. Das ist weniger gut. Derzeit haben nur wenige Unternehmen zentralisierte Sicherheitsmaßnahmen für Governance- und Engineering-Software vollständig zu einem zusammenhängenden, nachvollziehbaren und vertretbaren Risikomanagementprogramm harmonisiert. Trotzdem hat die Geschwindigkeit, mit der Engineering-Teams Features entwickeln und integrieren, Priorität. 

Sicherheitstest-Tools, die synchron und unsichtbar in ihren Toolketten laufen, und das sogar kostenlos und als Open Source, haben heute wahrscheinlich einen höheren Wert als gründlichere kommerzielle Tools. Die verursachen mehr Reibungspunkte als Nutzen erzeugen oder zumindest scheint das so zu sein. Die Botschaft: Wir hätten gerne (mehr) Sicherheit in unseren Wertströmen – wenn sie uns nicht ausbremst. In einigen Unternehmen wird Sicherheit zu einem Teil der Qualität, die wiederum von Zuverlässigkeit und diese zu Resilienz. Und die wird dadurch für viele Engineering-Teams zum operativen Ziel. Sicherheitsverantwortliche, die nur “Pen-Tests und Patchen“ kennen, werden vermutlich von Engineering-Teams, die sich weiterentwickelt haben, aus dem Wertstrom ‘gepatcht’ werden. 

Strukturelle Sicherheit 

Sicherheitsbefürworter aus den eigenen Reihen oder Entwicklungsteams arbeiten auf einem eher persönlichen Level zusammen. „Champions“ in ihrem Metier bringen Sicherheits-Know-how direkt in Code in Form von Toolchain-Sensoren ein. Darüber ermitteln sie, ob die Erwartungen an die Software eingehalten werden (z.B. Bibliotheksnutzung, Beheben bestimmter Defekte, Codierungsstandards), welche genehmigten Konfigurationen und Konfigurationsprüfungen (z.B. für Container) existieren und welche wiederverwendbaren Sicherheitsbibliotheken und so weiter. Sie schaffen sozusagen „strukturelle“ Sicherheit. Wenn Entwickler ihren Code in einer sicheren Struktur schreiben, erstellen sie auch sicherere Software.

Die Cloud: Verantwortung teilen 

Die Vorteile eines Wechsels in die Cloud werden stark propagiert und sind gut dokumentiert. Sie effektiv zu nutzen bedeutet aber auch, dass zumindest Teile der Sicherheitsarchitektur, der Bereitstellung von Funktionen und andere Bereiche der Softwaresicherheitspraxis, die traditionell lokal passieren, an den Cloud-Anbieter ausgelagert werden.Cloud-Anbieter sind zu 100 % für die Bereitstellung von Sicherheitssoftware verantwortlich, aber die Unternehmen sind zu 100 % für die Softwaresicherheit verantwortlich. Unternehmen, die Softwaresicherheit in privaten Rechenzentren unzureichend umgesetzt haben, werden das in der Cloud kaum besser machen. 

Digitale Transformation: Jeder tut es

Die digitale Transformation schreitet auf allen Ebenen voran. In der Realität ist Softwaresicherheit ein Schlüsselelement auf jeder Unternehmensebene. Auf der Executive-(SSI)-Ebene sollte ein Unternehmen Technologie-Stacks, Prozesse und Mitarbeiter zu einer “Automated First”-Strategie führen. Auf SSG-Level sollte ein Team die analoge Bringschuld senken, Dokumente und Tabellen durch Governance in Code-Form ersetzen. Auf der Engineering-Ebene sollte die Intelligenz in Tools, Toolchains, Umgebungen, Software und überall sonst integriert werden.

Sicherheit: Wird einfacher – und schwieriger zugleich

Grundlegende Softwaresicherheitsaktivitäten werden gleichzeitig einfacher und schwieriger. Das Softwareinventar war früher gemeinhin eine Excel-Tabelle mit Anwendungsnamen. Es wurde dann zu einer (meist veralteten) Datenbank für das Konfigurationsmanagement. Heute müssen Unternehmen Anwendungen, APIs, Mikro-Services, Open Source, Container, Glue-Code, Orchestrierungscode, Konfigurationen, Quellcode, Binärcode, laufenden Anwendungen und so weiter inventarisieren. Automatisierung hilft dabei, aber es gibt eine enorme Anzahl beweglicher Teile. Die Bedrohungsmodellierung wird tatsächlich einfacher (zu bündeln) und schwieriger zugleich (nämlich zu wissen, wann was zu tun ist). Das Patchen wird in einigen Fällen einfacher (ein Container gegenüber 100 Anwendungen) und in anderen Fällen schwieriger (zu wissen, wo CI/CD-Toolchains, Glue-Code, eigen- entwickelte Tools und so weiter vorliegen).

Fazit

Es gibt noch viele weitere Branchentrends, die unsere Aufmerksamkeit verdienen. Insbesondere das aktuelle politische Klima hat weltweit zu nachhaltigen Veränderungen im Softwaresicherheitsprozess, bei der Technologie und den vorgehaltenen Ressourcen geführt. In erster Linie hat sich die Prozessautomatisierung beschleunigt, der Einsatz intelligenter Sensoren, aber auch die Einsicht, welche Sicherheitstests innerhalb eines Lieferlebenszyklus überhaupt durchgeführt werden können und welche nicht. 

BSIMM11 hilft Firmen nicht nur zu Beginn ihrer Softwaresicherheitsinitiativen, sondern bietet zusätzlich die Möglichkeit, den Reifegrad der SSI zu bewerten. Die Spanne reicht von “in der Entstehung” oder gerade erst am Anfang, über “reifend”, d.h. in Betrieb, einschließlich einiger Unterstützung und Erwartungen seitens der Geschäftsführung, bis hin zu “optimierend”. Damit sind Unternehmen gemeint, die vorhandene Sicherheitskapazitäten fein justieren, um die eigene Risikobereitschaft mit den notwendigen Investitionen auszubalancieren. 

Wo immer ein Unternehmen sich auf dieser Reise befindet, BSIMM liefert einen Fahrplan, um die gesetzten Ziele zu erreichen.