SecDevOps – Kontinuierlich sichere Software bauen

Bereits mit Entstehung der Produktvision und den ersten Anforderungen sollten Überlegungen hinsichtlich möglicher Sicherheitsrisiken und Angriffsszenarien vorgenommen werden. Als hilfreich hat sich hier das Threat-Modelling erwiesen. Hier wird auf Basis der vorhandenen Anwendungsarchitektur ein Angriffsmodell abgeleitet, welches u. a. durch Festlegung von Trust Boundaries zwischen den Komponenten hilft, potentielle Angriffspunkte und -typen zu identifizieren [1].

Aus den Diskussionen rund um das Threat-Modell ergeben sich dann entsprechende Anforderungen an die Sicherheit. Eine mögliche Kategorisierung von User Stories würde dann wie folgt aussehen:

• User Stories für Security Features  (z. B. Authentifizierung und Rollenmodell)
• AbUser Stories (s. u.)
• User Stories mit sicherheitsrelevanten Akzeptanzkriterien
• User Stories ohne jeglichen Security-Bezug

AbUser Stories (auch bekannt als "Evil User Stories" [2]) werden aus den fachlichen User Stories abgeleitet und beschreiben damit die verbundene gewünschte Funktionalität aus Sicht des Angreifers.

Dabei sollten analog wie bei fachlichen User Stories auch Personas verwendet werden, d. h. statt dem allgemeinen "Hacker" könnte z. B. ein Skript Kiddie, ein Firmen-Insider oder ein Wirtschaftsspion verwendet werden. In Abb.3 ist ein Beispiel für eine fachliche (Business) User Story mit einer abgeleiteten AbUser Story zu sehen. Durch die AbUser Stories können dann im weiteren Verlauf für die Entwicklung im Rahmen der Sprint-Planung entsprechende Tasks erstellt werden.

Die nächste Stufe in der Deployment Pipeline kümmert sich nun um die qualitativen Anteile und beinhaltet u. a. Last- und Performancetests. In dieser Stufe werden dazu nun auch dynamische Sicherheitstests integriert (Abb.5). Hierfür gibt es inzwischen mit OWASP Zap [8] ein sehr gutes Open Source-Werkzeug. Dieses lässt sich über eine REST-API z. B. mit bestehenden UI-Tests (hier mit Selenium [9] in Kombination mit WebTester [10])  verbinden, um auf diesen Szenarien ein aktives Scanning durchzuführen. Dies kann dann nach manueller Prüfung (ggf. "False Positives") als Fehler in die Entwicklung weitergegeben werden.

Betrieb: Mehr als nur Netzwerksicherheit

In vielen Unternehmen kümmert sich der Betrieb häufig nur um die Absicherung der Netzwerke durch entsprechende Netzwerk- und Webanwendungsfirewalls sowie die Transportsicherung durch SSL bzw. TLS. Gerade bzgl. SSL/TLS werden häufig Konfigurationsfehler gemacht (SSLv1 oder unsichere Cipher-Suites). Dabei kann auch dieses mit automatischen Prüfservices wie z. B. von den SSL Labs [11] verbessert werden.

Daneben wird meist das Betriebssystem regelmäßig mit Sicherheitsupdates versorgt. Leider lässt die Patchfrequenz nach, je höher man den Stack hinauf geht (s. Abb.6). Applikationsserver werden nur ungern mit neuesten Patchleveln versehen, da man anschließend alle Anwendungen erneut testen muss. Neben dem eigenen Anwendungscode wird auch häufig das Monitoring der 3rd-Party-Bibliotheken von laufenden Produktivanwendungen vergessen. Gerade hier ist eine enge Zusammenarbeit zwischen Entwicklung und Betrieb immens wichtig. Meldet der Betrieb eine erkannte Schwäche an die Entwicklung, dann sollte dort die betroffene Komponente schnellstmöglich aktualisiert werden und das neue Softwareartefakt durch den Betrieb zeitnah produktiv gesetzt werden.

In der Cloud geht man z. B. bei CloudFoundry dazu über, die Angriffsfläche für Anwendungen durch weitere Infrastrukturmaßnahmen drastisch zu minimieren (s. "Rotate, Repair, Repave" in [12]). Dazu gehört die kontinuierliche Rotation von Zugangsdaten für Services, wie z. B. Datenbanken sowie das regelmäßige Neuaufsetzen von Laufzeitcontainern auf Basis geprüfter und mit Patches versorgter Images (und das ohne Downtime). Somit hat der Angreifer – selbst wenn er erfolgreich Zugriff auf das System erlangt hat – nur noch ein sehr kurzes Zeitfenster um dies auszunutzen zu können.