"Security by design" beschreibt eine Art der Soft- und Hardware-Entwicklung, bei der IT-Sicherheit schon in der Entstehung von Produkten und Lösungen berücksichtigt wird. Das Ziel ist es, das Produkt so unempfindlich wie möglich gegen Angriffe zu machen.

Nicht alle Entwickler sind davon begeistert. Viele wollen sich nicht von Sicherheitsthemen bremsen lassen. Daher gibt es häufig Widerstände gegen die Integration der Sicherheitsabteilungen in den Entwicklungsprozess - etwa in Form von DevSecOps.

Wie lässt sich das Problem lösen?

Das Verständnis von Security muss sich ändern

Laut Holger Hartwig, Cybersecurity-Spezialist bei Capgemini Outsourcing Services, muss zuerst ein generelles Umdenken stattfinden. Er beschreibt dies an einem Fall, den er selbst vor 15 Jahren erlebt habe: Bei der Applikationsentwicklung für ein Unternehmen beschwerte sich ein Entwickler, dass Security den Prozess ausbremse und es schneller gehen würde, wenn man Sicherheitsvorkehrungen nachträglich implementiere. Darauf fragte seine Vorgesetzte, wozu bei einem Auto die Bremsen verantwortlich wären. "Zum Bremsen," antwortete der Entwickler, worauf sie erwiderte: "Nein, um das Auto in die Lage zu versetzen, schneller zu fahren."

Laut Hartwig gilt es, diese Denkweise auf die Rolle der Security zu übertragen. Sie dürfe nicht als zusätzliche Komponente gesehen werden, die nachträglich an- oder eingebaut wird, sondern als von Beginn an gleichwertige Funktion - wie alle anderen Leistungsanforderungen, die es abzubilden gilt. Sei sie normaler Bestandteil der Entwicklung, werde sie nicht mehr als Bremse empfunden.

Gelassene Vermittler sind gefragt

Um Sicherheit und Entwicklung einander anzunähern, sei ein spezielles Skillset auf Seiten der Security gefragt, meint Christian Kahlo, Software Architekt bei der Adesso AG. Entwickler seien im Grunde Künstler, die kreativ und relativ frei arbeiten müssten, um ihre Aufgaben zu erfüllen. Sie setzten andere Prioritäten als die auf Absicherung bedachte Security. Hier stehe, vereinfacht ausgedrückt, eine lösungsorientierte Sicht einer problemorientierten gegenüber.

Soll der Wandel in der Denkweise stattfinden und auch gelebt werden, ist es laut Kahlo wichtig, Mitarbeiter zusammenzuführen, die beide Seiten kennen. Security-Leute, die selbst Entwickler sind (oder umgekehrt), kennen die Herausforderungen des Development-Prozesses. Sie können einschätzen, wie die Abläufe am besten angepasst werden können, um die gebotene Sicherheit mit der geforderten Kreativität in Einklang zu bringen.

Aufgabe dieser Vermittler ist es auch, ein Auge auf das Miteinander der Abteilungen während der Entwicklung zu haben. Die Entwickler sollten nicht das Gefühl haben, die Security überwache sie nun permanent - das behindere sie bei ihrer kreativen Aufgabe. Vielmehr sollten die IT-Sicherheitsexperten als Unterstützer auftreten.

Um diese Aufgaben wahrnehmen und mit beiden Parteien auf Augenhöhe sprechen zu können, benötigen die Grenzgänger zwischen beiden Welten einen bestimmten Charakter, meint Kahlo. Sachlich und ruhig sollten sie sein. Probleme gelte es, realistisch und mit Augenmaß in den Teams zu diskutieren. Dabei sei es wichtig, Erfolge positiv hervorzuheben anstatt Angst vor Fehlverhalten zu schüren. Verantwortliche Mitarbeiter mit solchen Qualitäten förderten die Erfolgschancen der Einführung von Security by design.

Security by design ist nicht teuer

Die Einführung selbst brauche anfänglich Investitionen, sagt Kahlo. Das sei aber auch bei jeder anderen neuen Entwicklungsmethode, wie beispielsweise Scrum, der Fall und auf lange Sicht seien die Kosten vernachlässigbar. Allerdings sorgt ein generelles Imageproblem der IT-Sicherheit für Herausforderungen. Security ist weitestgehend unsichtbar und tritt nur in Erscheinung, wenn sie versagt. Notwendige Investitionen werden als reiner Kostenfaktor angesehen. Da aber Sicherheit laut Kahlo oft als Argument verwendet werde, um für Projekte mehr Gelder zu erhalten, werde sie als "teuer" empfunden. Kahlo stellt klar: "Security ist weder teuer, noch schwer, man muss es nur machen."

Stefan Pütz, Leiter Network- and IT-Security bei der Deutschen Telekom, sieht das ähnlich. Er ist verantwortlich für das seit 2010 eingesetzte Privacy and Security Assessment (PSA) zur Gewährleistung von Sicherheit und Datenschutz im Konzern. Nach seiner Erfahrung senkt eine frühe Einbindung der IT-Security die Entwicklungskosten sogar, weil das Produkt ausgereifter und sicherer würde.

Security-Verantwortliche von Anfang an einbinden

Damit Sicherheit Teil des Entwicklungsprozesses wird, sollte sie von Anfang an mitgedacht werden. Bereits bei der ersten Ideenfindung zu einem neuen Projekt gilt es, Security-Verantwortliche mit an den Tisch zu holen. Gemeinsam mit allen anderen Beteiligten werden dann die Anforderungen an Funktionen, Leistung und eben auch Sicherheit definiert. Dabei ist es Aufgabe der Sicherheitsexperten darauf zu achten, dass die Features gesetzliche Vorgaben wie die DSGVO aber auch individuelle Policies und branchenspezifische Auflagen einhalten. Zudem gilt es, das angemessene Schutzniveau des Produkts und damit auch den nötigen Sicherheitsaufwand und die Kosten festzulegen. Dabei können eine Machbarkeitsstudie oder eine Risikoabwägung helfen.

Dies kann, so Stefan Pütz, durchaus zur Folge haben, dass sich eine Idee aus Sicherheitsgründen nicht wie geplant umsetzen lässt. Ist das der Fall, sollten Entwicklung und Sicherheit gemeinsam Alternativen ausloten, das Konzept anpassen oder - falls sich keine umsetzbare Lösung findet - die Idee ad acta legen.

Hilfreich ist hier, wenn dieser Prozess in einem strukturierten Interview-Leitfaden vorliegt. Sind Sicherheitsaspekte frühzeitig festgelegt und in den allgemeinen Entwicklungsprozess eingebettet worden, können Vorurteile gegen eine etwaige Bremswirkung durch Sicherheitsaspekte vermieden werden. Zudem hilft ein formalisierter Fragebogen dabei, Security als Standardkomponente langfristig zu etablieren.

Der letzte Punkt darf laut Hartwig nicht vernachlässigt werden. Um Security by design als neue Denkweise im Unternehmen einzuführen, ist sowohl Wissen, was bezüglich Security zu beachten ist, als auch Awareness, dass Security eine zentrale Rolle spielt, gefragt.

Sicherheitstests müssen durchgehend laufen

Während der Entwicklung gilt es, sowohl die Funktionsfähigkeit als auch die Sicherheit laufend zu testen. Dabei bieten sich laut Capgemini-Manager Hartwig Penetrationstests an.

Im Zuge der Risikoabwägung werden auch die möglichen Angriffsarten definiert, denen die Software oder das Gerät ausgesetzt sein könnten. In den verschiedenen Entwicklungsphasen gilt es, immer wieder Test zu fahren und auftauchende Mängel frühzeitig auszumerzen. Auch Testverfahren wie Dynamic Application Security Testing (DAST) zur Prüfung von HTTP- und HTML-Interfaces laufender Web-Applikationen oder Static Application Security Testing (SAST) zur Analyse des Codes der Anwendung bieten sich an.

Diese Tests sind fester Bestandteil des Entwicklungsprozesses und dienen dazu festzustellen, ob das Sicherheitsniveau den Anforderungen entspricht. Dabei ist es wichtig, im Hinterkopf zu behalten, dass es nie eine hundertprozentige Absicherung gibt. Das erwünschte Sicherheitsniveau richtet sich nach den eingangs definierten Anforderungen und Risiken.

Ist die jeweilige Entwicklungsphase beendet, rät Telekom-Mann Pütz zu einer finalen Sicherheitsabnahme durch das Security-Team inklusive praktischer Abnahmetests. Je nach Ergebnis sollten die Tester auch bestehende Restrisiken analysieren sowie risikominimierende Maßnahmen ableiten.

Kontinuierliche Security-Updates

Ist das Produkt oder die neue Softwareversion im Einsatz, stellt sich die Aufgabe, das erreichte Sicherheitsniveau aufrechtzuerhalten. Vor dem Hintergrund immer neuer und cleverer Bedrohungen, ist Patch-Hygiene entscheidend. Laufende Updates zu aufkommenden Angriffsvektoren müssen zeitnah ausgeliefert und implementiert werden.

Gilt es, neue Features in ein Produkt einzubauen, sollten dieselben Mechanismen greifen, wie bei einer Neuentwicklung. Das Team muss Risiken und Anforderungen identifizieren und gegeneinander abwägen. Ist es beispielsweise unbedingt notwendig, eine Applikation mit weiteren Lösungen oder gar kritischen Systemen zu vernetzen? Entstehen dadurch neue Einfallstore, gegen die zusätzliche Schutzkomponenten eingebaut werden müssen? Gebietet die neue Funktionalität, dass zusätzliche Regularien oder Policies beachtet und abgebildet werden müssen? Während der Weiterentwicklung gilt es, die verschiedenen Stadien der neuen Version regelmäßig auf Schwachstellen bezüglich der erarbeiteten Risiken zu testen und eventuell anzupassen.

Da kein Produkt zu hundert Prozent sicher ist, sorgen zwischen den Updates Monitoring-Lösungen in Unternehmen oder Überwachung der Infrastruktur über ein Security Operations Center (SOC) für kontinuierlichen Schutz. So können neue Schwachstellen und Angriffe zeitnah entdeckt und Gegenmaßnahmen ergriffen werden, bis ein Patch die Lücke in der Lösung selbst schließt.

Legacy-Schutz braucht mehr Aufwand

Neben neuen, sicher entwickelten Anwendungen und Produkten existieren in Unternehmen oft auch ältere, weniger sichere Lösungen, die aus technischen oder Kostengründen nicht ersetzt oder verändert werden können. Das kann etwa die spezialisierte OT-Applikation sein oder das uralte Legacy-System, an dem ein gesamter Geschäftsprozess hängt. Es stellt sich die Frage, wie diese Komponenten an das Sicherheitsniveau angepasst werden können.

Hier sieht Stefan Pütz von der Telekom drei Optionen:

• die Anforderungen trotzdem umsetzen;

• die Plattform vom Rest der Infrastruktur und dem Internet isolieren;

• die Restrisiken bewerten und gegebenenfalls akzeptieren.

Ähnlich bewertet das auch Holger Hartwig von Capgemini. Hat ein Krankenhaus beispielsweise anfällige medizinische Geräte in Betrieb, die nicht einfach umgeschrieben werden können, sollten sie zumindest voneinander und möglichst auch von Teilen des Netzes abgekoppelt werden. So wird ein Eindringling, der es auf das Gerät schafft, am Weiterwandern gehindert.

Solche Lösungen sind relativ teuer und benötigen viel Aufwand, da sie permanent überwacht werden müssen. Laut Hartwig ist das aber in so einem Fall die einzige Möglichkeit, ein gewisses Maß an Sicherheit zu gewährleisten. Dasselbe gilt auch für andere Legacy-Anwendungen. Absichern ist hier nur möglich, indem ein moderner "Security-Zaun" darum errichtet wird.

Unternehmen müssen sich der Risiken bewusst sein

Abschließend fasst Hartwig zusammen, dass es bei der Umsetzung von Security by design keine allgemeingültige Lösung gebe, mit der jede Herausforderung gemeistert werden könne. Es gehe zu allererst darum, die richtige Grundeinstellung zu haben, die von allen Beteiligten aktiv gelebt werden müsse. Der Rest komme von ganz allein.

Der größte Fehler, den Unternehmen in seinen Augen machen können, sei zu glauben, sie bräuchten das Sicherheitsniveau durch Security by design nicht, da es bei ihnen nichts zu holen gäbe. Dieses Argument sei heute nicht mehr haltbar. Startup, Mittelstand und Konzern stünden gleichermaßen im Visier der Hacker.