Sicherheit durch Design? Erstellen Sie keine YAPWAV!

Bei der Sicherheit geht es darum, Risiken sichtbar zu machen und die Auswirkungen möglicher Zwischenfälle auf ein akzeptables Niveau zu reduzieren. Die Philosophie des "Security by Design" zielt darauf ab, dass jede Anwendung bzw. jedes System jederzeit ein akzeptables Risikoniveau aufweist. Wenn man mit einem "Secure by Design"-Ansatz beginnt, werden häufig bestehende Sicherheitsprozesse einfach in den Entwicklungslebenszyklus integriert. Einer der größten Fehler dieses Ansatzes besteht darin, von den Teams zu verlangen, eine YAPWAV durchzuführen. YAPWAV steht für die Entwicklerhölle namens: Yet Another Process Without Added Value. Ein YAPWAV ist eine Aktivität, die ein Team nur durchführen muss, um einen Stakeholder zufrieden zu stellen, ohne das Produkt, das es entwickelt, spürbar zu verbessern. Ein klassisches Beispiel für einen YAPWAV ist die obligatorische Risikobewertung für jede Softwareeinführung, nur um einen Dokumentationsprozess zu erfüllen. Diese Art von Sicherheitsprozessen ist zum Scheitern verurteilt, da sie dem Produkt, das das Team erstellt, keinen (sichtbaren) Wert hinzufügen. In der agilen Philosophie sollte jede Aktion oder Aktivität zum Wert des Produkts beitragen. In dem Moment, in dem eine Aktivität eingeführt wird, die keinen sichtbaren Mehrwert bringt, werden die Teams entscheiden, dass sie den Aufwand nicht wert ist und aufhören, sie durchzuführen.

Ihre Annahmen sind falsch; das Ende ist nicht mehr nah

Traditionell werden Sicherheitsprozesse von einem strukturierten, kontrollierbaren Standpunkt aus entworfen. Die Softwareentwicklung hat einen Anfang und ein Ende, und Sie können die Aktivitäten auf dieser Planung aufbauen. Zu Beginn eines Projekts werden Risiko- und Folgenabschätzungen durchgeführt, und kurz vor dem Veröffentlichungstermin wird ein Sicherheitstest durchgeführt und Genehmigungen eingeholt. Dieser Ansatz ist vielleicht nicht optimal, aber in einer Welt, die größtenteils statisch ist, oft ausreichend. Mit der Einführung von Agile und DevOps wurde die Softwareentwicklung zu einem kontinuierlichen Prozess. Selbst wenn Teams Mechanismen wie Sprints mit einem Anfang und einem Ende verwenden, werden Änderungen an der Software in einem kontinuierlichen Tempo eingeführt. Dieser kontinuierliche Fluss von Änderungen macht viele Sicherheitsprüfungen zunichte.Die Annahme diskret zeitlich festgelegter Phasen mit Anfang und Ende ist nicht mehr gültig. Die Auferlegung von phasenabhängigen Prüfungen für jede Änderung führt zu einem ineffizienten Prozess, der Ihre Organisation stark belastet.Zunächst wird dieser Ansatz eine Menge Sprint-Ressourcen von Entwicklungsteams verbrauchen. Als nächstes wird die Anzahl der Anträge auf Genehmigungen und Ausnahmen Ihre Risiko- und Compliance-Abteilungen überfordern. Im Grunde handelt es sich um den Versuch, ein System zur Kontrolle aller Personen am Schlosstor auf eine moderne Stadt zu übertragen. Das lässt sich einfach nicht skalieren und führt nur zu einer Menge Frustration, ohne einen Mehrwert zu schaffen.

[caption id="" align="alignnone" width="1290"] Nicht skalierbare Mautstellen führen zu Frustration[/caption]

Erstellen Sie eine Karte für Sicherheit durch Design

Die agile Softwareentwicklung beginnt mit rohen Ideen und verfeinert und präzisiert diese kontinuierlich, bis die zu erledigende Arbeit klar ist. Der Schlüssel zum Erfolg für kontinuierliche Sicherheit liegt darin, die phasenabhängigen Prüfungen in einen kontinuierlichen Fluss von Aktivitäten umzuwandeln und sie auf diese agile Arbeitsweise abzustimmen. Microsoft hat mit seinem Ansatz'Agile Development Using Microsoft Security Development Lifecycle' bereits die Grundlage dafür geschaffen. In diesem Ansatz unterscheiden sie zwischen Aktivitäten, die in jedem Sprint erforderlich sind, und Aktivitäten, die nur zu bestimmten Zeiten oder unter bestimmten Umständen erforderlich sind. Dieser Ansatz ist ein guter Ausgangspunkt, aber es gehört noch mehr dazu.Die Integration von Sicherheitsprozessen in die agile Entwicklung wird nur dann erfolgreich sein, wenn Sie sie in bestehende Aktivitäten integrieren können. Viele Sicherheitsaktivitäten haben ein vergleichbares funktionales Gegenstück: Sicherheitstests sind nur eine Form des Testens, die Modellierung von Bedrohungen ist eine Form des Entwerfens, Sicherheitsanforderungen sind eine Form von Geschäftsanforderungen usw. usw.In der nachstehenden Tabelle habe ich eine Reihe von Sicherheitsaktivitäten den üblichen Aktivitäten in Agile und Devops zugeordnet. Wie immer sind dies nur Richtlinien, die Sie an Ihre eigene Arbeitsweise anpassen können.

Effektiv sein

Indem Sie Sicherheits-JAPWAVs in bestehende Prozesse einbinden, führen Sie nur minimalen Overhead ein und verbessern die Gesamtqualität und den Wert Ihres Systems. Die Wahrscheinlichkeit, dass diese integrierten Prozesse angenommen werden, ist größer, da es sich nicht mehr um Prozesse handelt, die nur für einen einzigen Interessenvertreter ausgeführt werden. Sicherheit ist zu einem "weiteren Qualitätsmerkmal" geworden, das die Grundlage für die Philosophie "Secure by Design" bildet.

[caption id="" align="alignnone" width="2592"] Sicherheit durch Design ist eine Frage der Überholspur[/caption]