Vergleichsweise Reife : BSIMM 11: Hilfe zur Selbsteinschätzung und Indizien für grundlegende Veränderungen in der Entwicklung der Softwaresicherheit

Von Gunnar Braun, Aachen

Als rein deskriptives Modell besteht der Zweck des Building Security In Maturity Model (BSIMM) ausschließlich darin, zu beobachten und zu berichten. Das lässt sich leichter an einem Beispiel erklären: Wäre BSIMM eine Mischung aus Volkzählung und Marktforschung, würde man ein Stadtviertel besuchen und herausfinden wollen, was dort vor sich geht. Und würde dann beispielsweise feststellen: „In X der Y Häuser, die wir besucht haben, sind Staubsauger-Roboter vorhanden.“ BSIMM sagt aber nicht: „Alle Häuser sollten Staubsauger-Roboter haben“, „Roboter sind die einzig akzeptable Art von Staubsaugern“,
„Staubsauger müssen jeden Tag verwendet werden“ oder trifft andere wertende Urteile. BSIMM liefert lediglich Beobachtungen, über die anschließend berichtet wird.

Der diesjährige BSIMM11-Bericht enthält Daten aus Interviews mit Menschen, die direkt mit Sicherheitsinitiativen für Softwareanwendungen zu tun haben. Er basiert auf den Praktiken von 130 verschiedenen Unternehmen einer Vielzahl von Branchen, darunter Finanzdienstleistungen, Internet der Dinge (IoT), Cloud, Gesundheitswesen und Versicherungen – bei vielen dieser Unternehmen handelt es sich um große bekannte Marken wie Adobe, Alibaba, Cisco, Honeywell, JPMorgan Chase,
Lenovo, NVIDIA, PayPal oder Verizon. Der vollständige 114-seitige Report steht unter Creative-Commons-Lizenz (CC BY-SA 3.0) und kann über www.bsimm.com/content/dam/bsimm/reports/bsimm11.pdf kostenfrei heruntergeladen werden.

Unabhängig davon, wie bekannt ein Unternehmen ist oder wie ausgereift sein AppSec-Programm ist, kann BSIMM als Maßstab für Führungskräfte dienen, um eigene Initiativen gegenüber Branchentrends und anderen Faktoren einzuschätzen. Im schnelllebigen Bereich der Softwaresicherheit kann die eigene Strategie direkt von Informationen darüber profitieren, was die meisten, zumindest etliche oder nur wenige andere Unternehmen im Rahmen ihrer Software-Security-Initiativen (SSIs) tun.

Wird BSIMM umfassend genutzt, dient es zudem als Orientierungshilfe bei der Erstellung oder Verbesserung eines erfolgreichen AppSec-Programms, das auf die spezifischen Anforderungen des jeweiligen Unternehmens zugeschnitten ist. Führungskräfte haben die Möglichkeit, BSIMM-Daten in eigene Vorgaben und Zielsetzungen einzubinden, um einzugrenzen, wo zusätzlicher Aufwand und Investitionen erforderlich sind.

Nicht alle Unternehmen müssen zwangsläufig dieselben Sicherheitsziele umsetzen – dennoch ist der Autor davon überzeugt, dass alle Organisationen von der Verwendung eines gemeinsamen Maßstabs profitieren. BSIMM ist jedoch kein klassisches Reifegradmodell, bei dem man eine Reihe von Aktivitäten auf mehreren Ebenen hinsichtlich Intensität und Umfang wiederholt – auf Stufe 1 macht man dies, auf Stufe 2 etwas mehr davon, auf Stufe 3 macht man es besser und so weiter.

Stattdessen erfasst BSIMM eine Reihe von Aktivitäten, wobei die Aktivitäts-Stufen nur zur Unterscheidung der relativen Häufigkeit dienen, mit der die jeweiligen Aktivitäten in den teilnehmenden Unternehmen beobachtet wurden. Häufig beobachtete Aktivitäten bilden die Stufe 1, weniger häufig beobachtete Aktivitäten Stufe 2 und selten beobachtete die Stufe 3 (vgl. Tabelle 1).

Gemeinsamer Rahmen

BSIMM quantifiziert Aktivitäten, die über unterschiedliche Arten von SSIs in vielen Organisationen ausgeführt werden. Da diese Initiativen unterschiedliche Methoden und Terminologien verwenden, benötigt BSIMM ein Framework, anhand dessen sich jede Initiative einheitlich beschreiben lässt.

BSIMMs Software Security Framework (SSF) und die zugehörigen Vorgangsbeschreibungen stellen dafür ein gemeinsames Vokabular zur Verfügung und erläutern die wichtigsten Elemente einer SSI (www.bsimm.com/framework.html). So lassen sich auch Initiativen vergleichen, die unterschiedliche Begriffe verwenden, in unterschiedlichen Maßstäben, verschiedenen Bereichen des Organigramms oder verschiedenen vertikalen Märkten angesiedelt sind oder die unterschiedliche Arbeitsergebnisse erstellen.

Das BSIMM SSF umfasst die Bereiche (Domains) „Governance“, „Intelligence“, „Secure Software Development Lifecycle (SSDL) Touchpoints“ und „Deployment“. Diese vier Bereiche umfassen wiederum 12 Kategorien/Praktiken (Practices), welche die insgesamt 121 BSIMM11-Aktivitäten enthalten. Eine BSIMM-Scorecard hält fest, welche Aktivitäten in einem Unternehmen beobachtet wurden.

Tabelle 2 zeigt die Scorecard eines Beispielunternehmens, das 40 BSIMM-Aktivitäten umsetzt (in der Spalte „Example Firm“ mit einer 1 erfasst), darunter auch 10 Aktivitäten, die in ihren jeweiligen Praktik-Bereichen am häufigsten vorkommen (graue Hinterlegung bei „BSIMM11 Firms“) – im Bereich „Governance“ wäre das etwa die Aktivität SM1.4: „Implement Lifecycle Governance“, die 117 von 130 Teilnehmern am BSIMM11 (inkl. der „Example Firm“) implementiert haben. Bemerkenswert ist, dass das Beispielunternehmen in zwei Bereichen die am häufigsten beobachteten Aktivitäten nicht durchführt (blaugrüne Kästchen) – etwa im Bereich „Intelligence“ die Aktivität AM1.2 „Create a Data Classification Scheme and Inventory“. An diesen Stellen sollte man vermutlich etwas Zeit investieren, um festzustellen, ob diese verbreitet umgesetzten Aktivitäten auch für die eigenen SSIs notwendig oder nützlich sein könnten.

Generell zeigen die Spalten „BSIMM11 Firms“ die Zahl der Beobachtungen innerhalb der gesamten Stichprobe (derzeit 130) für jede Aktivität, sodass man erkennen kann, wie verbreitet eine bestimmte Aktivität innerhalb aller Teilnehmer des aktuellen Reports war.

Vergleichen und Verbessern

Sobald man ermittelt hat, wo man steht, kann man einen Plan erstellen, welche Praktikbereiche man mithilfe weiterer Aktivitäten verbessern kann oder aktuelle Aktivitäten auf einen größeren Teil des Softwareportfolios skalieren. Dadurch, dass BSIMM tatsächliche Messdaten aus dem „Feld“ liefert, sind auch langfristige und gut nachvollziehbare SSI-Planungen möglich.

Es gibt keinen Grund, auf jeder Stufe sämtliche Aktivitäten für jeden Praktikbereich zu übernehmen. Man sollte genau diejenigen Aktivitäten auswählen, die für das eigene Unternehmen besonders sinnvoll sind, und solche ignorieren, für die das nicht zutrifft. Es ist aber empfehlenswert, diese Auswahl regelmäßig zu überprüfen. Nachdem sie eine Reihe von Aktivitäten übernommen haben, beginnen die meisten Unternehmen damit, im nächsten Schritt Intensität, Umfang und Kosteneffizienz (z.B. durch Automatisierung) der Aktivitäten zu verbessern – sinnvollerweise entsprechend ihrer Einschätzung des damit verbundenen Risikos.

Pegelstand als Reifegrad

Bei seiner Arbeit mit BSIMM zur Bewertung von Initiativen hat der Autor festgestellt, dass die Erstellung eines Netzdiagramms (Spider Chart) mit einem „HighWater-Mark“ (basierend auf den drei Stufen pro Praktikbereich) bereits ausreicht, um eine grobe Einschätzung des Reifegrads zu bekommen – vor allem bei der Arbeit mit Daten aus einer bestimmten Branche. Synopsys weist diese Markierung anhand eines einfachen Algorithmus zu: Wurde in einem bestimmten Praktikbereich (mindestens) eine Aktivität der Stufe 3 (selten) beobachtet, weist man ihm eine „3“ zu – ungeachtet dessen, ob es auch noch Aktivitäten der Stufe 2 oder 1 gibt. Niedrigere „Pegelstände“ von 2, 1 oder 0 (keinerlei Aktivitäten) erfolgen analog dazu.

Eine sinnvolle Verwendung eines Vergleichs anhand eines Netzdiagramms besteht darin, dass man die eigene Bewertung mittels HighWater-Mark den veröffentlichten BSIMM-Diagrammen (mit einer feineren Skala) gegenüberstellt, um zu sehen, wie die eigene Initiative im Vergleich aufgestellt ist. Abbildung 1 zeigt den grafischen Vergleich für die Beispielfirma aus Tabelle 1 mit der gesamten BSIMM11-Stichprobe.

Man muss allerdings nochmals betonen, dass die Aufschlüsselung der Aktivitäten in Stufen für jeden Praktikbereich nur die Beobachtungshäufigkeit widerspiegelt. Als solche können die Stufen einen natürlichen Fortschritt anhand der mit jedem einzelnen Bereich verbundenen Aktivitäten veranschaulichen. Es ist jedoch nicht notwendig, alle Aktivitäten in einer bestimmten Stufe auszuführen, bevor man zu einer anderen Stufe (Aktivitäten, die weniger häufig beobachtet wurden) im gleichen Bereich übergeht.

In diesem Sinne ist das Modell mit den verwendeten Stufen aus statistischer Sicht sinnvoll und stichhaltig: Aktivitäten der Stufe 1 (oft unkompliziert und universell anwendbar) werden am häufigsten umgesetzt, Aktivitäten der Stufe 2 (oft schwieriger zu implementieren, erfordern mehr Koordination) sind etwas weniger häufig und Aktivitäten der Stufe 3 (normalerweise schwieriger zu implementieren und nicht immer anwendbar) eher selten zu beobachteten. Für viele Unternehmen verbessert sich der Reifegrad aber auch direkt durch die Ausweitung von Aktivitäten auf einen größeren Teil des Softwareportfolios, anstatt „mit aller Gewalt“ Aktivitäten der Stufe 3 zu implementieren, nur weil es sich um die hochrangigste Stufe handelt.

Dedizierte Akteure

Auffällig – wenn auch wenig verwunderlich – ist, dass alle BSIMM-Teilnehmer eine interne Gruppe haben, die sich explizit der Softwaresicherheit widmet – die Software-Security-Group (SSG).

Die Studienautoren sagen in den FAQ ganz klar: „Wir haben niemals eine Organisation gesehen, die BSIMM-Aktivitäten ohne SSG erfolgreich umsetzt.“ Dabei zeigte sich zuletzt ein durchschnittliches Pro-Kopf-Verhältnis von gut 2 % – sprich: Über alle 130 teilnehmenden Unternehmen gemittelt gab es einen SSG-Mitarbeiter auf 50 Entwickler. Die durchschnittliche SSG-Größe betrug im BSIMM11 knapp 14 Beschäftigte (der Median lag bei 7).

Konkrete Entwicklungen

BSIMM11 liefert sowohl eine Auswertung zu den einzelnen Aktivitäten als auch zu allgemeinen Trends sowie einen Langzeitvergleich und Zusammenfassungen für die teilnehmenden Branchen (Verticals). Der aktuelle Report hat darüber hinaus vier wesentliche Erkenntnisse zutage gefördert, die Einblicke in die Evolution der Softwaresicherheit versprechen:

Technisch getriebene Bemühungen zur Softwaresicherheit tragen erfolgreich zu DevOps-Wertströmen bei, um Ausfallsicherheit zu gewährleisten

Die Instrumentierung von Continuous Integration / Continuous Delivery (CI/CD) sowie eine Operations-Orchestration sind inzwischen für so manches Unternehmen normaler Bestandteil der Herangehensweise an Softwaresicherheit geworden. Das beeinflusst auch die Organisation, Gestaltung und Ausführung von SSIs. Die Auswertung sieht beispielsweise zunehmend, dass SSIs über Technologiegruppen (20 von 130 Unternehmen) oder an einen CTO (21 von 130 Unternehmen) bis hoch zum CEO berichten.

Einige zentralisierte SSGs suchen zudem verstärkt den Austausch mit den Fachkräften, die häufig in Cloud-Security-Teams und Digital-Transformation-Teams sowie in zukunftsorientierten Entwicklungsteams zu finden sind. Das könnte darauf zurückzuführen sein, dass SSG-Mitglieder an bestimmten Stellen entlang der Wertschöpfung sichere Anwendungsfunktionen bereitstellen, statt lediglich Governance zur Fehlererkennung einzurichten.

Cloud-Service-Anbieter akzeptieren ein Modell gemeinsamer Verantwortung: SSIs können dann mit dem konkurrieren, was tatsächlich ein obligatorisches Outsourcing zumindest von Teilen der Sicherheitsarchitektur ist. Außerdem stellen sie Funktionen und andere SSI-Tätigkeitsbereiche bereit, die klassischerweise vollständig lokal ausgeführt wurden. Zentrales Anliegen ist offenbar, ein vernünftiges Risikomanagement für alle Entwicklungsteams über alle Cloud-Ressourcen hinweg zu gewährleisten.

Softwaredefinierte Security-Governance ist jetzt mehr als nur ein erstrebenswertes Ziel

Initiativen zur digitalen Transformation beziehen Sicherheitsaktivitäten in ihre Bemühungen ein, um eine Art CI/CD-Pipeline-as-a-Service bereitzustellen. Ziel ist es, die Softwarebereitstellung weitgehend zu einem Self-Service für Entwicklungsteams zu machen. Sicherheitsaktivitäten, die von einer SSG separat und im Rahmen von Security-Gates durchgeführt werden, erzeugen hohe Reibungsverluste – eine CI/CD-Pipeline-as-a-Service ist sehr viel transparenter und wird zunehmend standardmäßig eingesetzt. Hier haben Unternehmen teilweise schon erhebliche Fortschritte hinsichtlich von „Governance as Code“ gemacht.

Bereits in BSIMM10 waren drei neue Aktivitäten hinzugekommen, die eine deutliche Richtung zeigen: softwaredefinierte Lifecycle-Governance, softwaregestützte Überwachung der Erstellung softwaredefinierter Assets und automatisierte Überprüfung der softwaredefinierten Infrastruktur. Unternehmen arbeiten also aktiv an Möglichkeiten zur Beschleunigung der Sicherheit, um sich dem Tempo anzugleichen, mit dem Produkte und Funktionen auf den Markt gebracht werden. BSIMM11 erfasst deren Weiterentwicklung mit zusätzlichen Aktivitäten zur Implementierung ereignisgesteuerter Sicherheitstests (ST3.6 Implement event-driven security testing in automation) und zur Veröffentlichung von Risikodaten für einsatzfähige Artefakte (CMVM3.6 Publish risk data for deployable artifacts).

Das Delegieren von wiederholten Analyse- und Verfahrensaufgaben an Bots, Sensoren und weitere Automatisierungen sind zunehmend die bevorzugte Methode, um den Fachkräftemangel sowie Probleme beim Cadence-Management anzugehen. Wenn beispielsweise die Entscheidung, welche Sicherheits-Tools wann laufen sollen, an Algorithmen delegiert wird, macht das häufig eine Vielzahl der bislang von Menschen gesteuerten Prozesse im Lebenszyklus der Anwendung obsolet.

Sicherheit wird zu einem Teil der Qualität, die wiederum der Zuverlässigkeit zugeordnet wird, um zusammen Ausfallsicherheit zu gewährleisten

Viele Aktivitäten, die bisher isoliert waren und von Experten geleitet werden mussten, haben sich zu Verfahren und Prozessen weiterentwickelt, die der jeweiligen Zielgruppe die notwendigen Einblicke gewähren – und zwar kontinuierlich. Ein Beispiel: Inzwischen existiert eine breite Palette von Tools zum Static Application-Security Testing (SAST) – von schnell laufenden Open-Source-Tools für spezifische Probleme bis hin zu Verhaltensanalyse-Tools für ein ganzes Programm mit sehr viel längeren Laufzeiten. Die Ergebnisse der ersteren unterstützen meist Qualitätsziele oder die Betriebssicherheit in der Entwicklung, während letztere Sicherheits- und Ausfallsicherheitsziele in den Governance-Zyklen unterstützen.

Engineering-Gruppen erstellen Funktionen, die sich auf die Inventarisierung von Software, die Katalogisierung ihrer Komponenten sowie die Erfassung der Methoden konzentrieren, mit denen sie erstellt, konfiguriert und bereitgestellt wurde. Anstatt zum Beispiel zu versuchen, alle Probleme vor der Bereitstellung zu finden, optimieren viele DevOps-Gruppen fortlaufend. Dazu nutzen sie das Wissen, was wo läuft und konzentrieren sich auf das Erstellen von Funktionen zum Neustarten oder erneuten Bereitstellen von gepatchter oder zuvor fehlerhafter Software. Ziel ist es, die Grundlagen für Ausfallsicherheit zu schaffen, und dies aufgrund einer Vielzahl von Treibern – inklusive der Sicherheitstelemetrie.

In einer entwicklungsorientierten Kultur greift man gern auf kostenlose Open-Source- oder Freemium-Sicherheitstools zurück. Diese werden beispielsweise bei der automatischen In-Band-Überprüfung und zum Testen von Code benutzt, also als Teil der bereits stattfindenden Aktivitäten, wie zum Beispiel Code-Reviews oder Unit-Tests. Umfangreiche kommerzielle AppSec-Tools decken zumeist längere Zeiträume ab und werden in der Regel weiterhin an Kontrollpunkten verwendet, die für Governance-Gruppen relevant sind. Diese Tests werden allerdings wegen des Zeitaufwands und der zu erwartenden Reibung in der Regel „out-of-Band“, also außerhalb von Entwicklungspipelines durchgeführt.

Sicherheitsfunktionen für Clouds und Plattformen entwickeln sich rasch weiter – das gilt auch für Branching- und Bereitstellungsstrategien oder Ansätze zur Standortzuverlässigkeit. Das macht es für Entwicklungsteams leichter, sich auf die Ausfallsicherheit als primäres Ziel bei der Softwareentwicklung zu fokussieren.

In der Softwarewelt besetzen viele Unternehmen neuerdings Ingenieure für Sicherheit, Qualität, Zuverlässigkeit und Ausfallsicherheit (zusätzlich zu den traditionellen Kernbereichen wie Infrastruktur, Netzwerk usw.). Diese Rollen haben jeweils eigene Ziele, Zeitpläne, Kulturen und Leitlinien. Meist gibt es auch eine eigene Gruppe von Personen, die auf Fehler hinweist – allerdings, ohne dass gemeinsam zumindest grob daran gearbeitet würde, was für alle am besten funktioniert. Um den Unternehmenserfolg über Gruppenziele zu stellen, sind jedoch Priorisierung und ein Brückenschlag zwischen den unterschiedlichsten Fachkräften nötig!

„Shift Left“ wird zu „Shift Everywhere“

Obwohl „Shift Left“ als Methode, um Sicherheitstests bereits während der Entwicklung durchzuführen, durchaus gelobt wurde, ist eine generelle Vorverlegung dieser Aktivitäten auf der Zeitachse doch eine zu grobe Vereinfachung. Im Rahmen der Secure-Software-Development-Lifecycles (SSDLs) versucht man heute, eine Aktivität so schnell wie möglich und so genau wie möglich durchzuführen – und zwar exakt dann, wenn diejenigen Artefakte verfügbar sind, von denen diese Aktivität abhängt. Manchmal befindet sich das „links“ (also früher) von dem Zeitpunkt, zu dem man Dinge heutzutage erledigt, aber häufig ist es auch „rechts“ (also später). Außerdem erfordern Technologietrends naturgemäß eine Verschiebung nach rechts für eine schnelle und präzise Telemetrie aus modernen Sprachen, Frameworks und Software-Orchestrierung.

Etablierte Verfahren, wie die Überprüfung auf sicheren Code, werden mit zusätzlichen Funktionen zur Verwaltung des Quellcodes kombiniert, um eine Kontrolle auch in mehreren Phasen zu ermöglichen: zum Beispiel „Shift Left“ zu anfänglichen Code-Commits und „Shift Right“ zu erweiterten Metadaten, die als Teil von Pull Requests bereitgestellt werden und an Repository-Betreuer gesendet werden, wenn der Code fertig erstellt ist und getestet wurde. Diese Optionen spiegeln den Wunsch wider, Ergebnisse sowohl dort zu präsentieren, wo man sie am frühesten erzielt, als auch dort, wo sie am wirkungsvollsten sind.

Einige der Unternehmen, die Tools und Services zur Fehlererkennung evaluieren, bevorzugen zunehmend eine kontinuierliche, ereignisbasierte Sicherheitstelemetrie innerhalb eines Wertstroms anstelle der Analyse zu einem singulären Zeitpunkt.

Firmen, die ihre Daten zur Software-Inventarisierung möglichst präzise verwalten, bemerken schnell, dass sie diese Initiative mit anderen Prozessen abstimmen sollten. Dazu zählen die Verwaltung der Quellcode-Inhalte, der Erstellungs- und Bereitstellungsprozesse und die Abstimmung auf die jeweilige Betriebsumgebung. Granularität und Inhalt eines Inventars werden wahrscheinlich für jede Sichtweise unterschiedlich sein und sich häufig ändern. Oft zeigen sich Schwierigkeiten dabei, die Effektivität von Inventarisierungs-Anstrengungen aufrechtzuerhalten und sich gleichzeitig an neue Softwarelebenszyklen, Änderungen der Softwarearchitektur und alle zugrunde liegenden Änderungen der Software-, Bereitstellungs- und Cloud-Verfahren anzupassen, die als Reaktion auf die technischen Trends zum Self-Service oder als Folge der digitalen Transformation auftreten.

Fazit

Viele große Trends erfordern Aufmerksamkeit und es ist noch nicht unbedingt ersichtlich, wie sie sich tatsächlich auf die Softwaresicherheit auswirken. Gerade jetzt, aber auch anekdotisch betrachtet, wirken sich Veränderungen in anderen Bereichen – etwa dem politischen Klima – nicht unerheblich auch auf Softwaresicherheitsprozesse, Technologie und die Bereitstellung von Mitteln aus. Viele Firmen berichten von stark rückläufigen Einstellungszahlen, oft verbunden mit der Forderung, die gesteckten Zielsetzungen mit den bestehenden Mitarbeitern und existierender Technik zu erreichen.

Das spiegelt sich in erster Linie in einer deutlichen Beschleunigung der Prozessautomatisierung wider: Irgendeine Art von „Intelligenz“, etwa über Sensoren, soll verhindern, dass Menschen Prozesse blockieren. Gleichzeitig lässt sich ein wachsendes Verständnis dafür beobachten, dass ein höheres Tempo auch bedeutet, dass man nicht alles (z. B. alle gewünschten Sicherheitstests) „in-Band“ vor dem eigentlichen Bereitstellungslebenszyklus durchführen kann.

Wie sollen Sicherheitsverantwortliche aber einschätzen, wie viel zu viel ist, wenn es um ihre AppSec-Aktivitäten geht? Wie wenig ist zu wenig? Welche Investitionen sind für ein bestimmtes Unternehmen sinnvoll und welche sind nur übermäßige Ausgaben? Das BSIMM-Modell bietet hierfür einen belastbaren Benchmark und eine Richtlinie für die (Weiter-)Entwicklung des/eines eigenen Sicherheitsprogramms.

Gunnar Braun ist Security Engineer bei Synopsys.

Dieser Artikel steht unter der Creative-Commons-Lizenz „Namensnennung – Weitergabe unter gleichen Bedingungen 4.0 International“. Um eine Kopie dieser Lizenz zu sehen, besuchen Sie http://creativecommons.org/licenses/by-sa/4.0/. Eine elektronische Fassung dieses Beitrags ist unter www.kes.info/BSIMM11 abrufbar.