Softwareentwicklung lernt Sicherheitskultur

von Lucas von Stockhausen, Director Solutions bei Synopsys

„Sicherheitskultur“ ist ein schillernder Begriff. Pragmatisch gesehen bedeutet er ein gemeinsames Handeln und Kommunizieren in einer Organisation, bei der alle Angehörigen die Anforderungen der Sicherheit fortwährend und ungezwungen mitdenken und dies als integralen Teil ihrer Arbeit betrachten. Für das Thema Cyber-Sicherheit sind viele Unternehmen diesem Idealzustand bereits recht nahe – der Studie BSIMM12 zufolge gelingt dies nun auch zunehmend den Softwareentwicklern. Aber wo liegt dort eigentlich genau das Problem?

Hinter den Bemühungen um eine Sicherheitskultur in ganzen Unternehmen oder Abteilungen steckt eine lange evolutionäre Entwicklung. Sie beginnt ein paar Jahre nach der Jahrtausendwende mit einer ersten Abkehr von der Vorstellung, die normalen Anwender müssten von Administratoren und Sicherheitsverantwortlichen permanent zu richtigem Verhalten gedrängt werden, und zwar am besten mit möglichst exakten Regeln und Sanktionen. Die Vorgaben allerdings waren oft nur für Fachleute verständlich. Wenig später, als Folge immer mächtigerer Hard- und Software-Werkzeuge in den Händen der „Nur“-Anwender und der gleichzeitig um sich greifenden Vernetzung, entstand zusätzlich die Vorstellung, dass „Insider“ gleichzeitig eine ebenso große Bedrohung für die Unternehmens-IT bedeuten wie schwer fassbare Hacker im Internet.

Sicherheitspartner statt „Nur“-Anwender

Beide Einschätzungen sind noch immer nicht ganz verschwunden. Aber nach und nach hat sich ein partnerschaftliches Verhältnis zwischen IT-Security-Abteilungen und Anwendern durchgesetzt, bei denen die Mitarbeiter für Security-Belange sensibilisiert werden und man sie befähigt, sich für die jeweils sicherste Vorgehensweise bei der Arbeit mit der IT zu entscheiden. Die Sicherheitsteams wiederum verstehen sich seltener als Oberlehrer in Sachen Security und stehen als Ratgeber bei schwierigeren Entscheidungen bereit.

Vergleichsweise schlecht hat der Paradigmenwechsel kurioserweise in einem Bereich funktioniert, in dem eigentlich alle Beteiligten IT-Spezialisten sind: Im Sektor der Software-Entwicklung. Woran das liegt, erschließt sich bei einem genauen Blick auf die Vorbedingungen von Sicherheitskultur einerseits und von typischen Software-Entwicklungsprojekten andererseits.

Sicherheitskultur bedeutet, wie schon erwähnt, dass die Angehörigen einer Organisation nicht nur Befehlsempfänger in Sachen sicheres Verhalten sind, sondern vertrauensvoll in Security-relevante Entscheidungen eingebunden werden. Dies kann zum Beispiel bedeuten:

• Beteiligung an Risiko-Einschätzungen,
• Beteiligung an der Klassifizierung von Informationen und
• Mitarbeit an geeigneten Methoden zur Umsetzung von Sicherheitsvorgaben.

Sicherheit als Störfaktor

Vor allem der letzte Punkt verdient dabei Beachtung. Kommt Sicherheit nur als Vorgabe daher oder in Form von rigiden Vorschriften des Typs „one size fits all“, führt dies fast immer dazu, dass einige Anwendergruppen durch die Maßnahmen stärker in ihrer Arbeit behindert werden als andere. Aufwändige Anmeldeprozeduren mögen im Büro unproblematisch sein, in der Produktionshalle dagegen halten sie den Betrieb auf oder führen sogar zu gefährlichen Verzögerungen beim schnellen Zugriff auf eine Maschine. Ständige „Reviews“ eines Arbeitsprozesses stören eine Routinetätigkeit weniger als einen kreativen Entwicklungsprozess. Ob eine Sicherheitskultur entstehen kann, hängt also stark davon ab, ob Maßnahmen oder Prozesse zum Teil des Arbeitsalltags werden können oder nicht.

Darüber hinaus müssen die Security-Teams und Anwender Einverständnis darüber erzielen, dass hinter Sicherheitsmaßnahmen und -regeln keine abstrakten, willkürlichen Vorgaben stecken, sondern notwendige Schutzvorkehrungen für die Produktion, die Kommunikation, die im Unternehmen vorhandenen Daten und für die Produkte, wie sie die Kunden tatsächlich verlangen.

Zielkonflikte

Die problematische Situation im Bereich Softwareentwicklung resultiert aus mehreren Besonderheiten. Softwareentwicklung gerät heute häufig zu einer Art „kreativer Produktion im Akkord“. Sie findet in spezialisierten Unternehmen oder Abteilungen statt, welche innerhalb eines Unternehmens häufig abgekoppelt agieren. Die internen oder externen Kunden der Entwickler drängen angesichts der zunehmend dynamischen Entwicklung der Anforderungen seitens der Endanwender auf Agilität und Flexibilität. Das macht sorgfältiges Vorgehen und tiefgehende Tests unter Umständen schwierig. Belohnt wird hier, wer schnell neue Funktionen bereitstellen kann. Zugleich aber steigen die Anforderungen an die Sicherheit von Code, und zwar wieder aufgrund von Vorgaben oder Erwartungen der Endkunden. Im Business-to-Business-Sektor wird es Usus, von Softwarelieferanten Sicherheitsgarantien zu fordern oder Einblicke in die sicherheitsbezogenen Prozesse der Produktion zu verlangen. Aus dieser Perspektive werden Sorgfalt und Tests belohnt. Dass aber auch ein entsprechender Zeitrahmen für derartiges Vorgehen eingeräumt wird, kommt aufgrund des Agilitätsdrucks kaum vor.

Nun mag man einwenden, dass in der skizzierten Schere zwischen dem Agilitätsprimat und Sorgfaltspflicht heute fast alle IT-Services stecken. Was für die Software-Entwicklung aber noch hinzukommt, ist die ungünstige Form der Erfolgskontrolle. Sie besteht fast immer in einer Endabnahme zum geforderten Lieferdatum. Zu diesem Zeitpunkt müssen die geforderten Funktionen bereitstehen, und der Kunde prüft auf abstrakte Sicherheitsvorgaben hin – die er leider meist nicht risiko- und situationsbezogen aufstellt, sondern in Form einer absoluten Forderung: Die Software muss fehlerfrei sein. Im Extremfall könnte es sein, dass ein Produkt einfach deshalb nicht abgenommen wird, weil es Open-Source-Komponenten enthält, die bekanntermaßen eine Sicherheitslücke aufweisen.

Prinzipien der sicheren Softwareentwicklung

Auf den ersten Blick scheint dieses Prinzip der Sicherheit durchaus dienlich zu sein, auf den zweiten Blick allerdings führt es zu unnötigem Druck aus dem oben beschriebenen Zielkonflikt heraus. Programmierer greifen zu Open-Source-Komponenten, wenn es für Teilanforderungen ihres Projekts bereits erprobte Lösungen gibt. Sie tun dies, um Zeit zu sparen, das Lieferdatum einhalten zu können und Energie auf spezifische, neue Lösungen verwenden zu können. 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. Und nicht selten 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.

Die letzten beiden Jahre haben uns bereits eine Reihe von Angriffen auf unwahrscheinlich anmutende Ziele beschert, und auch in Zukunft werden Angreifer von Vorteilen durch Software-Exploits profitieren. DevSecOps löst nicht ohne Grund mehr und mehr den zentralisierten Ansatz für Anwendungssicherheit ab. Über die Zeit mündete dieser in einen trägen und frustrierenden Prozess, der zuverlässig dafür gesorgt hat, dass Entwickler die Sicherheitsabteilungen als Verhinderer betrachten. Das Endergebnis sind Anwendungen, die kaum sicherer sind und die zudem verzögert auf den Markt kommen.

Im aktuellen Modell ist Sicherheit untrennbar mit der Softwareentwicklung verbunden und in jede Phase eingebettet, vom Design über die Implementierung bis hin zur Wartung, automatisiert und so weit wie möglich in den Softwareentwicklungsprozess integriert.

Damit gelingt es die Vorteile der Automatisierung auszunutzen, die Geschwindigkeit zu maximieren und im besten Fall eine Kultur der kontinuierlichen Verbesserung zu etablieren.
In anderen Bereichen Bereichen kommen laut den Ergebnissen von BSIMM12 Mechanismen der risikogesteuerten Sicherheit ins Spiel. Schwachstellen werden dort nur angegangen, wenn sie relevant sind. Genau deshalb hat die Security in den vergangenen Jahren Verfahren entwickelt, die eine Kontext- und Risiko-bezogene Priorisierung von Maßnahmen erlauben. Dies setzte allerdings neben dem Aufbau von Tool-Sets auch die Zusammenarbeit zwischen den Betreibern der produktiven Systeme in den Organisationen (z.B. den „Application Ownern“) und den Sicherheitsspezialisten voraus, bei denen man sich über abstrakte Mindestanforderungen und jene Risiken austauscht, die zusätzlichen Schutzbedarf indizieren.

Bedarfsgerechtes Sicherheitsniveau

Das bräuchte die Software-Entwicklung auch, um passgenaue Qualität und Sicherheit bei gleichzeitig maximaler Agilität zu erreichen. Die Studie „BSIMM12“ der Synopsys Software Integrity Group zeigt, dass Software-Entwickler in verschiedenen IT-Bereichen und Branchen zunehmend Prozesse anstoßen, die die Produktionsmethodik in die entsprechende Richtung bewegen. „BSIMM“steht dabei für „Building Security in Maturity Model“. Die Studie befragt Jahr für Jahr Organisationen im Bereich Software-Entwicklung danach, auf welche Security-bezogenen Qualitätsmaßnahmen sie besonderen Wert legen und welche wie besonders vorantreiben. Und hier zeigt sich in der aktuellen Ausgabe ein ganzes Bündel an Aktivitäten, die auf eine positive Sicherheitskultur hinauslaufen können. Ein paar der wichtigsten Punkte:

Risikobasierte Sicherheit: Laut den Resultaten von BSIMM12 werden Sicherheitsfunktionalitäten an den Risiken ausgerichtet, denen die fertige Software in ihrem Einsatzkontext ausgesetzt ist. Dazu wird es immer wichtiger, sich während der Entwicklung schon über das Sicherheitsniveau der Hosts und des Netzwerks abzustimmen, in der die Software arbeiten soll. „Kooperation“ ist hier der zentrale Aspekt.

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

Häufigeres, kleinteiliges und integriertes Testen: Statt groß angelegter passiver und aktiver Security-Tests (deren Ergebnisse Entwicklungsprojekte auch immer wieder zurückwerfen können) werden einzelne Module möglichst automatisiert getestet und auch bei kleineren Fortschritten fokussierte Prüfungen durchgeführt. Damit verliert die Sicherheitsbewertung ihren Charakter als „Angstgegner“ dem man tunlichst aus dem Weg gehen sollte.

Insgesamt findet ein Perspektivenwechsel statt, der „Resilience“ – also die Widerstandsfähigkeit von Software gegen Angriffe oder Bedrohungen – zum integralen Qualitätsmerkmal macht. Es genießt als Ziel während der Entwicklungsarbeit den gleichen Stellenwert wie die funktionalen Aspekte und kann mit ähnlichen Mitteln erreicht werden.

https://www.synopsys.com/

Aufmacherbild / Quelle /Lizenz
Photo by Markus Spiske on Unsplash