Wenn Kunden nach sicherer Software fragen

von Lucas von Stockhausen, Director Solutions bei Synopsys

Getrieben von Compliance-Anforderungen verlangen Kunden heute immer häufiger Garantien von Softwareentwicklern, die die Cybersicherheit ihrer Produkte betreffen, oder aber sie fordern detaillierte Einblicke ins Entwicklungsverfahren. Zugleich soll die Softwareproduktion agiler und flexibler ablaufen. Die Studie BSIMM12 liefert wertvolle Anhaltspunkte, wie der Zielkonflikt zwischen Geschwindigkeit und Sorgfalt gelöst werden kann – und zum Teil schon gelöst wird.

Kunden sind tendenziell fordernd: Von Softwareentwicklern erwarten sie agiles Vorgehen und neue Funktionen mit immer geringerer Vorlaufzeit. Gründe sind das allgemein rasante Innovationstempo und der hohe Wettbewerbsdruck. Firmen sind immer stärker davon abhängig, bestimmte Online-Funktionalitäten zumindest genauso schnell anbieten zu können wie die Konkurrenz. Diesen Druck geben sie weiter.

Zugleich aber stellen dieselben Kunden zunehmend detailliertere Sicherheitsanforderungen auf und verankern sie in Verträgen, Ausschreibungen und laufenden Überprüfungen. Wer Software anbietet, soll im Zweifelsfall genau belegen können, welchen Prinzipien einer sicheren Entwicklungsmethodik er folgt, welche Tests er zu welchen Zeitpunkten durchführt und welches Sicherheitsniveau seine Produkte einhalten. Praktisch läuft das Drama dann meist in zwei Akten ab: Der Kunde verlangt Einsicht in die Entwicklungsverfahren einerseits und prüft das Endprodukt andererseits – allerdings eher auf abstrakte oder absolute Sicherheitsanforderungen hin.

Softwareentwicklung „muss draußen bleiben“

Der letztgenannte Punkt verdient besondere Aufmerksamkeit. Hinter dem Wunsch, Softwareprodukte in einem perfekt sicheren Zustand übernehmen zu wollen, also ohne Sicherheitslücken jedweder Art, steckt bei vielen Kunden der verzweifelte Versuch, die Komplexität zu reduzieren. Software, die produktiv genutzt wird oder in Produkten zum Einsatz kommt, soll möglichst Black-Box-artig und sorgenfrei integriert werden können und auf keinen Fall eigene Probleme aufwerfen.

Damit stellt sich allerdings die drängende Frage, ob die Entwicklungsteams zu diesem Zeitpunkt genug darüber wissen, wie die Komponenten zukünftig genutzt werden – ein grundsätzliches Problem aus dem Themenkreis „sichere Softwareentwicklung“. Gemäß einem Defense-in-Depth-Ansatz und unabhängig vom jeweiligen Unternehmen ist es sinnvoll, Sicherheitsprobleme und Schwachstellen einer Software zu beheben, egal wie unwahrscheinlich ein konkreter Exploit nach heutigem Kenntnisstand erscheinen mag. Nicht selten aber wird bestehendes Wissen zur Defense-in-Depth-Philosophie oder das Prinzip der minimalen Rechtevergabe ebenso wie andere Best Practices innerhalb der Softwareentwicklung auf dem Altar der Agilität geopfert.

DevSecOps löst mehr und mehr den zentralisierten Ansatz für Anwendungssicherheit ab. Und das aus gutem Grund. Im aktuellen Modell ist Sicherheit untrennbar mit der Softwareentwicklung verbunden. Sicherheit ist in jede Phase eingebettet, vom Design über die Implementierung bis hin zur Wartung automatisiert und so weit wie möglich in den Softwareentwicklungsprozess integriert.

Inzwischen übernehmen immer mehr App-Entwickler die volle Verantwortung für ihre eigenen Sicherheitsbelange – mit geeigneter Unterstützung durch das Sicherheitsteam. Für Anwendungsentwickler ein Grund mehr, verstärkt auf DevSecOps-Prozesse zu setzen. Damit schöpfen sie die Vorteile der Automatisierung aus, maximieren die Geschwindigkeit und etablieren im besten Fall eine Kultur der kontinuierlichen Verbesserung.

---

Die Softwareentwicklung sollte ihrerseits transparent und risikobasiert vorgehen. Also Sicherheitsmaßnahmen und Tests in den Entstehungsprozess der Produkte integrieren, die gegenüber den Kunden gut darstellbar sind – und die vor allem deren Sicherheitsmanagement-Konzepten aus einschlägigen Normen wie der ISO 270xx ähnelt.

---

Angemessen versus absolut

Die Ressourcen von Security-Teams sind begrenzt und können niemals so ausgebaut werden, dass ein perfektes Sicherheitsniveau für jeden Teil der eigenen Infrastruktur zu erreichen wäre.
Deshalb nutzen viele Unternehmen das Primat einer angemessenen statt einer absoluten Sicherheit. In manchen Normen ist das Prinzip des „gut genug“ sogar explizit verankert. Wer sich beispielsweise auf ein Audit gemäß der Kreditkarten-Sicherheitsnorm PCI-DSS vorbereitet wird darauf drängen, den sensiblen Kundendatenbereich in ein möglichst abgeschottetes Segment zu verlegen, einfach damit die Anforderungen der Norm nur dort umgesetzt und geprüft werden müssen.

Die präventive und reaktive Security hat in den vergangenen Jahren außerdem Verfahren entwickelt, welche die Kontext- und Risiko-bezogenen Priorisierungen von Maßnahmen erlauben. Dazu gehören geeignete Werkzeuge und eine gut ausgebaute Kommunikation zwischen den Betreibern der produktiven Systeme (z.B. den „Application Ownern“) und den Sicherheitsspezialisten. Zwischen diesen Gruppen tauscht man sich über abstrakte Mindestanforderungen und jene Risiken aus, die außergewöhnlichen Schutzbedarf aufweisen.

Maßnahmenbündel

Die Softwareentwicklung sollte in dieses risikobasierte Vorgehen integriert werden und nicht außerhalb des priorisierten Vorgehens operieren. Damit das möglich ist, müssen zwei Voraussetzungen erfüllt sein:

Die Kunden sollten Entwicklern Informationen über den Sicherheitskontext bereitstellen, in dem das Produkt arbeitet. Dazu gehören bestehende Risiken, potenzielle Bedrohungen, sowie das Sicherheitsniveau der Infrastruktur.

Die Softwareentwicklung sollte ihrerseits transparent und risikobasiert vorgehen. Also Sicherheitsmaßnahmen und Tests in den Entstehungsprozess der Produkte integrieren, die gegenüber den Kunden gut darstellbar sind – und die vor allem deren Sicherheitsmanagement-Konzepten aus einschlägigen Normen wie der ISO 270xx ähnelt.

Es gibt Organisationen und Branchen, in denen die entsprechende Verzahnung schon existiert – häufiger ist dies beispielsweise bei Finanzdienstleistern der Fall. Wie passgenaue Qualität und Sicherheit bei gleichzeitig maximaler Agilität auch in der Breite erreicht werden kann, zeigt die Studie BSIMM12 der Synopsys Software Integrity Group. Sie weist nach, dass Softwareentwickler in verschiedenen IT-Bereichen und Branchen zunehmend Prozesse anstoßen, welche die Produktionsmethodik(en) risikobasiert ausrichten und auf eine engere Kommunikation mit den internen und externen Kunden setzen. BSIMM steht dabei für Building Security in Maturity Model. Die Studie befragt Jahr für Jahr Organisationen im Bereich Softwareentwicklung, auf welche Security-Maßnahmen sie besonderen Wert legen und welche sie vor allem vorantreiben.

Die wichtigsten Punkte aus dem Maßnahmenkatalog der befragten Organisationen umfassen:

Lifecycle Instrumentation setzt ein risikobasiertes Vorgehen durch, wo immer dies möglich ist, und richtet die Produktion darauf aus, Fehler in der Software früher zu finden. Es gibt mehre, aber dafür kürzere Testphasen, die sich in den Produktionsprozess integrieren lassen und die Entwickler somit nicht immer wieder zurückwerfen. Das Verfahren ist nach außen gut als gelebte Governance darstellbar. Die kleinen, obligatorischen Tests ähneln den Pflicht-Sicherheitsbetrachtungen, zu denen sich Projekt-Teams in der IT während der Umsetzung von Projekten immer wieder zusammenfinden müssen.

• Externe Tester einbinden: Für Statuserhebungen im Bereich Sicherheit externe Experten heranzuziehen, gilt in der ganzen Branche als sinnvoll und ist an einigen Stellen auch aus Compliance-Gründen notwendig. Übernehmen Entwickler diese Praxis, nähern sie sich den anderen Security-Arbeitsfeldern an.

• Interaktion mit Incident Response: Softwareentwickler stimmen sich enger mit den Security-Spezialisten in der Organisation ab, die tatsächliche Angriffe und Bedrohungen identifizieren. So wandelt sich Sicherheit vom abstrakten Thema zur realen, nachvollziehbaren Anforderung

• Datenschutzimplikationen frühzeitig erkennen: Entwicklerteams gehen dazu über, Risiken aus dem Einsatz ihrer Produkte im Bereich personenbezogener Daten gleich zu Beginn zu identifizieren und ihre Arbeit darauf auszurichten. Da Datenskandale für Unternehmen zu den größten Schreckgespenstern gehören, sollten sie dieses Vorgehen verstehen und honorieren – während die Entwickler es vermeiden, in diesem heiklen Bereich später aufwändig nachbessern zu müssen.

• Sicherheits-Features einem Review unterziehen: Ebenfalls gleich zu Beginn prüfen Entwicklungsorganisationen vermehrt, ob die vereinbarte Sicherheitsfunktionalität der Produkte angemessen ist – etwa, ob verschlüsselt werden muss oder wie stark die Authentifizierungsmechanismen sein müssen. Dieser Check auf Angemessenheit ist ebenfalls gut vermittelbar und kommt den Kunden entgegen, bei denen das Endprodukt ja in die entsprechende IT-Umgebung möglichst passgenau integriert werden soll.

Weitere Maßnahmen lassen sich in der Studie selbst nachvollziehen. Betrachtet man die dort aufgeführten zehn wichtigsten, ist es allerdings unabdingbar, dass sich sowohl die Entwickler als auch die Kunden auf einen Perspektivenwechsel einlassen müssen. Kern ist dabei auf Entwicklerseite, Sicherheitsanforderungen nicht als einschränkende Hürden aufzufassen, sondern als Teil der Qualität und Funktion der neuen Produkte zu verstehen.

Das gilt aber auch auf Kundenseite. Denn für die wird „Resilience“ – also die Widerstandsfähigkeit gegen Angriffe oder Bedrohungen – immer wichtiger. Die aktuellen Maßnahmen der befragten Organisationen laufen deshalb darauf hinaus, eine Sicherheitskultur in der Softwareentwicklung zu verankern, die das Thema Security zum integralen Bestandteil des Arbeitsalltags macht.

https://www.synopsys.com/

Lesen Sie

einen weiteren Beitrag

von dem Experten Lucas von Stockhausen,

Director Solutions bei Synopsys:

Softwareentwicklung lernt Sicherheitskultur