Auf DevOps folgt der Bedarf an DevSec

Inhaltsverzeichnis

Seit kurzer Zeit macht ein neuer Begriff die Runde: DevSec. Unschwer erkennbar handelt es sich dabei um die Abkürzung von Development Security. Darin spiegeln sich die wachsenden Bedenken hinsichtlich der Sicherheitsprozesse in der Softwareentwicklung wider. Denn diese stellt zunehmend das Herzstück bei der Entwicklung von Softwaresystemen dar.

DevSec ähnelt nach Inhalt und Begrifflichkeit dem DevOps-Konzept. Sollte es bei Letzterem um die engere Verzahnung von Entwicklung und Operations für kürzere Releasezyklen und weniger Fehler gehen, geht es auch bei DevSec darum, das Sicherheitsdenken und entsprechende Praktiken fest in der Entwicklung und den zugehörigen Prozessen zu verankern. Dazu gehört, eine "single source of truth", einen Referenzbestand an allen Quellcodedateien zu institutionalisieren und diesen nicht nur gegen Angriffe von außen, sondern auch gegen Bedrohungen von innen abzusichern. Notwendig ist DevSec auf jeden Fall. Denn DevOps droht unter dem Druck der Automatisierung die Sicherheit in der Entwicklung zu vernachlässigen.

Gleich mehrere Faktoren tragen zu diesem Bewusstseinswandel bei. Zuerst wächst die Wachsamkeit gegenüber "Insider-Bedrohungen" als eine der größten Quellen für Sicherheitslecks. Schließlich sind Entwicklungsumgebungen – von IDEs über Build Engines bis zu QA-Tools – dafür bekannt, sich nur schwer mit traditionellen Sicherheitswerkzeugen zur Vermeidung von Datenverlusten (Data Loss Prevention) überwachen zu lassen. Insider-Bedrohungen darf man nicht zwangsläufig als Mitarbeiteraktivitäten bösartiger oder illegaler Absicht missverstehen. Entwickler könnten ja auch schlicht nachlässig sein und dadurch einem Externen ermöglichen, einen erfolgreichen Angriff zu begehen oder seine Identität zu verschleiern, um geistiges Eigentum zu stehlen.

Hierbei handelt es sich nicht um bloße Theorie. Im vergangenen Jahr wurde einer der größten Chiphersteller Opfer eines großen Code-Diebstahls. Das Unternehmen versuchte ein Jahr lang, die Ursache des Problems zu finden. Doch erst als ein Tool zur Verhaltensanalyse zum Einsatz kam, konnte das Unternehmen einige Mitarbeiter als Übeltäter entlarven. Selbstverständlich wollen nur wenige Firmen öffentlich über Diebstahl am geistigen Eigentum reden. Deshalb ist es schwierig, Größe und Schwere des Schadens einzuschätzen. So bezifferte ein Detica-Bericht die Kosten des Diebstahls geistigen Eigentums allein für Firmen in Großbritannien mit einer Summe von rund 12,5 Milliarden Euro, während eine BITKOM-Umfrage vom Sommer 2015 von über 50 Milliarden Euro an jährlichem Schaden für die deutsche Wirtschaft ausgeht.

Mit DevOps kommt DevSec

Zeitgemäße Entwicklungspraktiken schüren ihrerseits die DevSec-Bedenken, insbesondere wegen der exponenziellen Zunahme von DevOps-Praktiken in den Unternehmen. Nach diesem Konzept arbeiten Entwicklungs- und Betriebsteams enger zusammen, was Softwareprojekte schneller zum erfolgreichen Abschluss bringen soll. Dass die Einführung von Continuous Delivery die Releasezyklen verkürzt, bringt Unternehmen in die Zwickmühle zwischen Sicherheit und Geschwindigkeit.

Diese Herausforderung wird durch die schiere Menge und Verschiedenartigkeit der an Softwareprojekten beteiligten Parteien noch größer. Das erschwert es, lückenlos nachzuverfolgen, wer was, wann und wo durchführt. Herkömmliche Sicherheitswerkzeuge – selbst jene, die zum Beispiel zur Verwaltung von Zugangsberechtigungen oder zur Abwehr von Insider-Bedrohungen konzipiert sind – sorgen nur mit viel Mühe für Transparenz, was in der Entwicklungsumgebung tatsächlich vor sich geht. Code-Repositories sind häufig siloartig voneinander getrennt und Entwickler in ihrer Arbeit oftmals vom Rest der Unternehmensorganisation, auch wenn sie Teil eines Teams sind. Ds gilt gerade in Zeiten zunehmender Verbreitung verteilter Versionskontrollsystemen (DVCS). Denn die meisten DVCS-Repositories kennen Größenbeschränkungen. Entwickler, die DVCS-Systeme nutzen, spalten ihre Repositories daher regelmäßig auf und verwahren die Binärdateien getrennt voneinander, auf lokalen Laufwerken oder Cloud-Diensten wie Dropbox.

Ein neuer Ansatz ist also für den Schutz von Softwareentwicklungsprojekten vor Sicherheitslecks nötig. Er darf sich nicht auf traditionelle Verteidigungsmaßnahmen à la Burgmauern und Zugbrücken wie Firewalls, Zugangsberechtigungen oder sichere Authentifizierungsverfahren beschränken, sondern muss sich mehr auf die Daten konzentrieren und dokumentieren, wie die Projektbeteiligten mit dem Softwarecode und anderen Assets interagieren, und das über Software- und Hardwareteams hinweg.

Dabei gilt es, fünf Fragen zu beantworten:

• Was ist das wirklich wertvolle geistige Eigentum in einer Organisation? Wo liegt es und mit welchen Werkzeugen wird es verwaltet? Viele Firmen tun sich schwer damit, da das geistige Eigentum über die Systeme verteilt ist und sich so kaum ein Gesamtbild ergibt.
• Welche Gruppen oder Individuen sollten auf das geistige Eigentum zugreifen dürfen? Zwar müssen etablierte Tools für Berechtigungsmanagement weiterhin ihre Rolle spielen, doch haben auch andere Softwaretechniken eingebaute Zugriffskontrollen: Werkzeuge zur Versionskontrolle zum Beispiel umfassen üblicherweise Funktionen, mit denen sich kontrollieren und steuern lässt, wer innerhalb eines Asset Repository worauf zugreifen darf. Zu den Assets zählen etwa Softwarecode, CAD-Zeichnungen, Supportdokumentation und Bilddateien.
• Kommt eine Multifaktor- und/oder kontinuierliche Authentifizierung zum Einsatz? Wie granular ist die Zugangskontrolle zu wichtigen Assets geregelt? Starke Authentifizierungsmechanismen und eine Zugriffssteuerung auf Asset-Ebene gehören zu jedem guten Sicherheitshaushalt. Auch wenn diese klassischen Ansätze keinen hundertprozentigen Schutz versprechen, ist es auf jeden Fall sinnvoll, so viele Barrieren wie möglich zu errichten, vor allem dann, wenn Mitarbeiter von zu Hause aus oder unterwegs auf Assets zugreifen.
• Lassen sich Ruhe- und Bewegungsdaten verschlüsseln? Auch hierbei handelt es sich nicht um eine neue Technik, sondern um bewährte Praxis.
• Wird jeglicher Zugriff auf geistiges Eigentum lückenlos überwacht? Eine detaillierte Protokollierung in einem sicheren Repository für Softwarekonfigurationsmanagement ist Pflicht. Noch wesentlicher ist es allerdings, diese mit einer Verhaltensanalyse zu kombinieren.