Immer schnellere Zyklen bei der Softwareentwicklung und aggressiv gesetzte Release-Termine führen nach verbreiteter Ansicht zu Mängeln bei der Sicherheit und Zuverlässigkeit: Es wird aus unterschiedlichen Gründen nicht immer gründlich genug getestet, heißt es. Tatsächlich muss diese Konsequenz nicht zwangsläufig eintreten. Es gilt vielmehr, ein in moderne, agile Entwicklungsverfahren integriertes Testmodell zu etablieren. Automatisierung und risiko-orientierte Priorisierung bei der Behandlung von Verwundbarkeiten sind die Schlüssel zum Erfolg.

Illustration: Absmeier Geralt

In DevOps, der möglichst engen Verzahnung von »Development« und »Operations«, steckt von vornherein ein Konflikt. Zumindest lässt sich dies in vielen Beiträgen zur modernen Softwareentwicklung nachlesen, gleich ob in Blogs oder Print-Publikationen. Entwickler wollen Kunden schnell mit neuen, trendigen, vielleicht nur vorübergehend interessanten Funktionen bedienen und Probleme durch Ad-hoc-Automatisierung lösen. Der Service und Helpdesk stöhnen anschließend über unausgegorene Ergebnisse und Qualitätsmängel und hohen manuellen Aufwand. Die SW-Entwickler werden an ihrer Liefertreue gemessen und müssen unter ständigem Zeitdruck umsetzen, »Operations« wünscht sich stabile Funktionalität und Verlässlichkeit. Noch schlimmer: Während auf der einen Seite, Markt- und Kundenbedürfnisse durch die Entwicklung zeitnah umgesetzt werden, stecken die anderen anschließend die Kritik der Anwender für die Unzulänglichkeiten in tatsächlichen Betrieb ein.

Chancen und Risiken der Agilität

In den einschlägigen Foren und sozialen Medien für Entwickler und Security-Spezialisten ist das geschilderte Problem inzwischen hier und da zum »Meme« geworden unter dem Motto »Wenn der Entwickler schnell mal was aus dem Internet eingebaut hat«. Die Zahl der Varianten steigt und steigt, das Thema trifft offensichtlich einen blank liegenden Nerv. Bleibt es nur bei funktionalen Designfehlern aufgrund von Termindruck, sind Spott und dauerndes Nachbessern zwar lästig, aber zu verschmerzen. Wenn Fehler bei allzu eifrigen agilen Entwicklungsprojekten allerdings zu Beeinträchtigung der Softwaresicherheit oder sogar den Zugriff auf sensible Daten ermöglichen, können die Folgen ein Unternehmen nachhaltig in Schieflage bringen – von den Schäden für die Kunden ganz zu schweigen. Nur: Wie lässt sich das Risiko vorab quantifizieren oder wenigstens qualifizieren?

Klassische Tests am Anschlag

»Testen« soll die Antwort sein. Traditionelle Vulnerability-Tests, die gewöhnlich erst am Ende der Entwicklungsprozesse oder beim Erreichen größerer Meilensteine anstehen, sind für moderne Produktionsverfahren längst zu unflexibel geworden. Erstens sind die gängigen Checks oft langwierig und geraten damit für manches Projekt zur echten Geduldsprobe, zweitens liefern sie häufig eine Menge nicht relevanter Fehlermeldungen, die häufig nicht leicht zu interpretierenden Ergebnisse – und drittens beansprucht sie die zuständigen Entwickler zur Nacharbeit. Stellt sich beispielsweise heraus, dass die finanziell attraktive und zeitsparende Einbindung einer bestimmten Software-Bibliothek aus dem Open-Source-Bereich zu Sicherheitsproblemen führt, kann das nachträgliche Ausmerzen der in einem frühen Entwicklungsstadium getroffenen Entscheidung für dieses Modul zu erheblichem Nachbesserungsaufwand führen – und angesichts der dann erst recht ausbrechenden Hektik auch zu neuen Fehlern.

Dabei ist zu berücksichtigen, dass Software heute tendenziell seltener »aus einem Stück« gegossen ist. Verteilte Teams arbeiteten mit verschiedenen Container- und Komponentenmodellen und versuchen dabei, einmal Erstelltes so oft wie möglich wiederzuverwerten. Dies führt zu komplexen Strukturen, in denen einzelne Module auch immer wieder anderen Wert, eine sich verändernde Bedeutung und damit auch ein breit variierendes Störpotenzial haben – von »hochkritisch« bis »vernachlässigbar«.

Darüber hinaus werden auch die Einsatzgebiete von Softwareprodukten immer vielfältiger. Sie zielen schon lange nicht mehr nur auf den klassischen Business-IT-Bereich, für den auch das klassische Vulnerability-Scanning einmal entwickelt und optimiert wurde, sondern auf Bereiche mit gänzlich anderen funktionalen und sicherheitstechnischen Anforderungen wie Web, Mobile Computing, IoT, IIoT, OT und Cloud. Hier ist »Vertraulichkeit« das höchste Ziel, dort »Integrität« und immer häufiger schlicht »Verfügbarkeit«. Das gleiche Modul wirft in der einen Umgebung nicht tolerierbare Probleme auf und ist für die andere optimal austariert.

Der Fluch der Komplexität

Für DevOps kennzeichnend wird damit eine Situation, die für viele Bereiche des IT- und Informationssicherheitsmanagements schon länger gilt: Die Unüberschaubarkeit des Fachgebiets macht es für die Akteure extrem schwierig, angemessene Entscheidungen zu treffen, die Business- und Sicherheitsmaßstäben zugleich gerecht werden. Souveränität weicht einer Kontrollillusion, die den Managern und Praktikern spürbar zu schaffen macht. Damit wird die oberflächlich technische

Problematik zum Management-Gau:

Wie viele Ressourcen welcher Art sollen strategisch für Entwicklungsprojekte und DevOps bereitgestellt werden? In welche Sicherheitsvorkehrungen sollte man wie viel investieren, und von welchen Zeitbudgets ist dabei auszugehen?
Wie sollte man sich dem Thema operativ nähern? Durch Einhaltung bestimmter Secure-Development-Prozesse, dann angelehnt an Compliance-Vorgaben – aber an welche? Wie lässt sich all das automatisieren?
Wie geht man taktisch mit Herausforderungen um, die Tag für Tag im Projekt entstehen und vielleicht zu Verzögerungen führen? Sollte man die Lösung eines frisch aufgetretenen Problems priorisieren oder erst andere Schritte vorantreiben?

Im Informationssicherheits-Management begegnet man ähnlichen Anforderungen mit einer Kombination aus Prozessen mit festgelegten Kontrollschritten, der Einbindung von Spezialisten unterhalb der engeren Management-Ebene in die Entscheidungsfindung und mit möglichst weitgehender Automatisierung, um die Kernteams von Routineaufgaben der Entscheidungsfindung zu entlasten.

Wunderwaffe Automatisierung

Mindestens zwei Punkte davon passen auch in die DevOps-Welt und die Sphäre der agilen Entwicklung: Die Integration des Testens in den dynamischen Entwicklungsprozessen selbst und eine weitgehend regelbasierte Aufbereitung der Testergebnisse. Genau das leisten moderne Application-Security-Werkzeuge.

Aber zuerst noch einen Schritt zurück. Die hier implizit vorgetragene Idee, Entscheidungsprozesse teilweise einem Algorithmus zu überlassen, mag beim einen oder anderen Leser Stirnrunzeln hervorrufen. Ist es nicht die hohe Kunst der Unternehmensführung oder – eine Stufe tiefer – des Projektmanagements, über die Annahme, Behandlung oder Akzeptanz von Risiken zu befinden und das Ergebnis gegen die Chancen eines Projekts abzuwägen?

Das stimmt, aber die Wurzel des Automatisierungsgedankens liegt im Terminus »informierte Entscheidung«. Wie schon angedeutet, muss ein Entscheider die wirtschaftliche Situation eines Unternehmens mit Wissen über Risiken und Bedrohungen in Einklang bringen. Und genau dieser Akt setzt einen gewissen Grad an Aufbereitung der Basis-Datenlage voraus, der es einem Manager ohne Ausbildung in Software-Development, menschlichen Faktoren, Netzwerktechnik, Datenschutz und Informationssicherheit überhaupt erlaubt, ohne akute Angstzustände über Vorhaben mit Risiko-, Informationssicherheits- und Datenschutz-Implikationen zu entscheiden. Was nicht heißen soll, dass es Managern mit diesen Fähigkeiten wesentlich leichter fällt, die entsprechenden Weichenstellungen einzuleiten.

Tools mit Sinn für Dynamik

Was Software leisten kann, ist somit, den Grad der Informiertheit bei einer Entscheidung erhöhen, die nach wie vor ein Mensch zu treffen hat. Tools nehmen dem Entscheider schlicht die Vorarbeit der Erhebung und Korrelation von Informationen aus verschiedenen Quellen ab, die hohe, nahezu unerreichbare Anforderungen an Fachwissen und Erfahrung stellen. Besser: Die Werkzeuge heben die Ausgangslage auf ein Niveau, auf dem ein kluger Kopf mit Sinn für IT und Vertrauen in seinen Stab von Spezialisten noch mit gutem Gewissen Entscheidungen für sein Unternehmen treffen kann.

Im hier diskutierten Fall bezieht sich dies auf folgende Aspekte:

Orchestrierung: Es gibt eine ganze Reihe von bewährten Application-Security- (AppSec-) Tools, die Teilbereiche der Applikationstests perfekt abdecken und für Spezialisten sicherlich interessante Ergebnisse bieten. Das Ziel allerdings liegt darin, die Werkzeuge für den jeweiligen Einsatzzweck und die Software-Komponenten passend auszuwählen und die Ergebnisse auch Personen zugänglich zu machen, die nicht mit Bits und Bytes auf Du sind. Übernehmen diese Aufgabe nicht das Werkzeug selbst und seine übergeordneten Instanzen wenigstens zu einem gewissen Anteil, müsste das Spezialisten-Team im Haus die Dolmetscher-Arbeit von A bis Z leisten – in der Regel haben diese Experten aber Anderes zu tun.

Korrelation: Die Ergebnisse unterschiedlicher Analyse-Werkzeuge mit unterschiedlichen Schwerpunkten müssen für einen bestimmten Einsatzzweck von Software zueinander in Beziehung gesetzt werden. Sagt ein bestimmtes Tool unter bestimmten Voraussetzungen« Nein«, muss geklärt werden, wie viele andere unter anderen Umständen und Zielsetzungen »Ja« sagen und warum. Dieser Informationsabgleich kann ebenfalls automatisiert geleistet werden.

Priorisierung: Unter den oben beschriebenen Voraussetzungen genießen immer bestimmte (Sicherheits-) Ziele Priorität vor anderen. Verwundbarkeiten, die in speziellen Umgebungen schwerwiegende Folgen haben, können in anderen vollkommen irrelevant sein. Ein gutes Tool gleicht die Anforderungen, die ein einem Projekt gelten, deshalb mit den potenziellen Auswirkungen von Sicherheitslücken ab.

Tracking der Maßnahmen: Sind Entscheidungen für Maßnahmen getroffen, muss nachverfolgt werden, wie weit die Umsetzung gediehen ist – vor allem in Form beschlossener weiterer Tests. Für die Teams selbst ist die Dokumentation ihres engagierten Tuns meist eine lästige Pflicht. Je mehr sie diese Aufgabe (unter ihrer Regie) einem Werkzeug überlassen können, desto weniger Arbeit fließt in den kostenträchtigen Overhead.

Die zentrale Übersicht: Alle Beteiligten an Application-Testing-Maßnahmen brauchen einen stets verfügbaren zentralen Überblick über den Stand ihrer Aktivitäten. Geeignete Tools bieten dazu passende Dashboards.

Fazit

Moderne Application-Testing-Tools gehen weit über das traditionelle Spektrum des Vulnerability-Scannings hinaus. Sie integrieren sich reibungslos in moderne DevOps-Prozesse und agile Software-Entwicklung an. Das Interessante dabei ist, dass nicht die fortschreitende Analysetiefe der wichtigste Aspekt der Weiterentwicklung ist. Die neuen Werkzeuge unterstützen die Entscheidungs- und Priorisierungsprozesse, die mit moderner, sicherer Softwareentwicklung einhergehen. Sie liefern so einen wichtigen Beitrag zu einer Produktion, die zwischen Funktionalitätsansprüchen und Sicherheitsanforderungen die Waage halten kann.

Florian Thurmann, Synopsys

77 Artikel zu „AppSec“

NEWS | TRENDS 2020 | TRENDS SECURITY | IT-SECURITY | STRATEGIEN

AppSec: Softwaresicherheit als Reaktion auf DevOps und digitale Transformation

16. September 2020

Die 11. Version des »Building Security In Maturity Model« demonstriert, wie Unternehmen Softwaresicherheit anpassen können, um moderne Software-Entwicklungsparadigmen zu unterstützen. Synopsys veröffentlichte BSIMM11, die aktuelle Version des Building Security In Maturity Model (BSIMM). BSIMM unterstützt Unternehmen bei der Planung, Ausführung, Analyse und Verbesserung ihrer Softwaresicherheitsinitiativen (SSIs). Die Studie spiegelt die Softwaresicherheitspraktiken von 130 Unternehmen…