DevOps Security
Security reloaded: Single-Point-in-Time-Tests versagen bei DevOps
Sicherheits-Zertifikat für den Entwicklungsprozess
Neun von zehn Java-Anwendungen sind verwundbar. Das liegt auch daran, dass es kaum Richtlinien für die Entwicklung sicherer Web-Applikationen gibt. Diese sind allerdings dringend nötig, um Security zu garantieren und Vertrauen zu stärken. Julian Totzek-Hallhuber, Solution Architect bei CA Veracode , erklärt, wie Unternehmen von Sicherheitszertifikaten anhand fester Standards profitieren.
Je komplexer ein Softwareprodukt, desto anfälliger ist es für Cybercrime-Aktivitäten. Dass kommerzielle Off-the-Shelf-Programme besser gegen Sicherheitslücken abgedichtet sind als Eigenentwicklungen, ist ein Irrglaube. Im Gegenteil: Wer fremde Komponenten verwendet, seien es Third-Party-Produkte oder Open Source-Software, erhöht das Risiko eines Angriffs. Hinzu kommt: Gerade geschäftskritische und damit besonders schützenswerte Anwendungen werden heute maximal flexibel erstellt, beispielsweise mit agilen Methoden oder im Rahmen von DevOps-Strukturen. Testvarianten, bei denen ein Anwendungssystem nur einmal oder in großen Abständen untersucht wird (Single-Point-in-Time), versagen hier zwangsläufig.
Mangelhafter Überblick über die Komponenten
Wie der aktuelle „State of Software Security Report“ (SoSS) des zu CA Technologies gehörenden Sicherheitsspezialisten Veracode ausweist, enthalten 88 Prozent der untersuchten Java-Anwendungen mindestens eine Komponente, die als Einfallstor für Cyber-Angriffe dienen kann. Um diese Studie zu erstellen, wurden zwischen April 2016 bis März 2017 fast 250 Milliarden Code-Zeilen von 1.400 Unternehmen ausgewertet.
Die Ergebnisse sind alarmierend: Der Untersuchung zufolge haben die wenigsten Betriebe tatsächlich einen Überblick darüber, welche Komponenten sie in ihren Anwendungen eigentlich verwenden. Nicht einmal 28 Prozent analysieren die Bestandteile ihrer Applikationen regelmäßig. Dabei sind gerade die Fremdkomponenten für Cyber-Kriminelle ein lohnendes Angriffsziel: Weil diese Komponenten zu Tausenden genutzt werden, lässt sich hier mit wenig Aufwand maximaler Schaden anrichten.
Laut SoSS-Report bestehen typische Anwendungen heute zu drei Vierteln aus Open Source-Komponenten. Die Entwickler verwenden sie gern, um Routinefunktionen zu implementieren, deshalb wollen und können sie kaum darauf verzichten. Verständlicherweise haben sie keine Lust, das Rad ständig neu zu erfinden. Das müssen sie selbstverständlich auch nicht. Aber sie sollten sich des immanenten Risikos bewusst sein, die Schwachstellen regelmäßig analysieren und im Falle einer konkreten Bedrohung oder gar einer Sicherheitsverletzung sofort reagieren. Leider ist vor allem Letzteres selten der Fall: Nur 22 Prozent der aufgedeckten Schwachstellen werden innerhalb einer Frist von 30 Tagen behoben, so die Veracode-Studie. Die Cyberkriminellen dürfen sich also über ein riesiges Zeitfenster freuen, innerhalb dessen sie aktiv werden können.
Security-Praktiken müssen transparent sein
Sicher gibt es eine Reihe von Sicherheitsnormen, an denen sich die Unternehmen orientieren können – angefangen vom internationalen Standard ISO/IEC 27001 über den „IT-Grundschutz“, einen vom Bundesamt für Sicherheit in der Informationstechnik (BSI) herausgegebenen Umsetzungskatalog für die ISO/IEC-Norm, bis hin zum Open Web Application Security Projekt (OWASP), das unter der Bezeichnung „Top Ten“ die Mindestanforderungen für sichere Web-Anwendungen vorgibt. Doch egal, für welchen dieser Standards sich ein Unternehmen entscheidet – es wird in den meisten Fällen überfordert sein mit der Aufgabe, die eigenen und fremden Softwarekomponenten auf Schwachstellen zu untersuchen. Zwar können und sollen die Softwarekäufer ihre kommerziellen Lieferanten zur Einhaltung bestimmter Sicherheitsnormen verpflichten, aber sie werden sich schwertun, diese auch zu überprüfen.
Gemäß einer Studie, die in Zusammenarbeit mit der International Data Group (IDG) entstand, bauen 84 Prozent der Softwarekunden tatsächlich schon Sicherheitsanforderungen in ihre Kauf- oder Mietverträge ein. Oft verbunden mit dem Anspruch, dass die Einhaltung der Standards auch nachweisbar sein muss. Drittanbietern ist also dringend anzuraten, alles zu dokumentieren, was sie im Hinblick auf die Anwendungssicherheit tun. Am besten lassen sie ihre Security-Praktiken auch von einer unabhängigen dritten Seite prüfen und bestätigen. Der Wettbewerbsvorteil, der aus einem solchen Attest oder Zertifikat erzielbar ist, wächst ständig – in dem Maße, wie immer mehr Sicherheitslecks und Cyber-Angriffe publik werden.
Schlüsselfaktoren für mehr Anwendungssicherheit
Die Binsenweisheit, dass es hundertprozentige Sicherheit nicht gibt, sollte weder die Softwareanbieter noch deren Kunden davon abhalten, ihre Security-Praktiken ständig zu verbessern. Dafür sind vier Aspekte entscheidend:
- Eine Roadmap hält die Entwickler davon ab, sich zu verzetteln. Im Mittelpunkt der Planung stehen praktische Ergebnisse und geschäftlicher Nutzen. Daran orientieren sich dann auch der Aufbau und die Weiterentwicklung des unternehmenseigenen Programms für Anwendungssicherheit.
- Das Thema Anwendungssicherheit sollten die Unternehmen proaktiv angehen – vor allem, wenn sie mit dem Verkauf von Software ihr Geld verdienen. Programme und Komponenten sind nach einem verbindlichen Prozess zu entwickeln, der regelmäßige Security-Tests von Anfang an einschließt. Umso besser, wenn ein unabhängiger Dritter das nachprüft und attestiert.
- Überhaupt ist „Prozess“ das Schlüsselwort für mehr Anwendungssicherheit. Es kann nicht darum gehen, einer Komponente ein für allemal zu bescheinigen, dass sie nach menschlichem Ermessen „sicher“ sei. In agilen Entwicklungssystemen und DevOps-Umgebungen ändert sich der Code ständig. Deshalb lässt sich nur bewerten, wie sinnvoll und stringent der Prozess ist, der zu sicheren Systemen führt und aus DevOps am Ende DevSecOps macht.
- Die Softwarekäufer können ihre Nachfragemacht nutzen, um die Anbieter auf höhere Sicherheitsstandards zu verpflichten. Sie können sogar verlangen, dass sie Einblick in den Entwicklungsprozess erhalten und dessen Sicherheit von einer unabhängigen Stelle überprüft wird.
Es gibt am Markt Dienstleister, die sich auf Anwendungssicherheit spezialisiert und hierfür eigene Standards entwickelt haben. Sie scannen den Code, analysieren den Prozess und bescheinigen dem Unternehmen im Erfolgsfall beispielsweise, dass seine Anwendungen oder Komponenten keine „bedenklichen“ oder „brandgefährlichen“ Schwachstellen enthalten sowie dass etwaige Lecks innerhalb von 60 Tagen repariert werden können. Sie helfen ihm aber auch, einen „Sicherheits-Champion“ zu benennen und Trainingsprogramme für die Entwickler aufzubauen. Denn Anwendungssicherheit ist zu wichtig, um sie Amateuren zu überlassen.
