Sichere Software ist ein wundervolles Ziel – für die Hersteller mindestens genau so sehr, wie für die unbescholtenen Nutzer, denen schlussendlich das Vertrauen in die Zuverlässigkeit von System zustehen sollte. Doch bedauerlicherweise nehmen die Berichte über kompromittierte Systeme ständig zu. Allein die schiere Menge an Daten, die dem empfehlenswerten Dienst Have I been pwned zur Verfügung steht sowie eine Auswertung des BSI untermauern das sehr dramatisch.
Sichere Softwareentwicklung:
1. Sicherheit als wertvolle Investition jenseits von DSGVO und Cyber Resilience Act
Mit der DSGVO und dem sehr frischen Cyber Resilience Act gibt es sogar gesetzliche Vorgaben, die Herstellern erhebliche Verantwortung beim Schutz von Daten und der Produktsicherheit zuteilwerden lassen. Doch von den gesetzlichen Vorschriften sowie den mit Verstößen verbundenen Strafen völlig abgesehen, gibt es weitere gute Gründe in die Sicherheit von Software zu investieren:
- Vorbeugung von Kosten für die Beseitigung von Mängeln sowie Haftungsansprüchen
- Sicherstellung von Kontinuität im Geschäftsablauf
- Schutz von Daten und Geschäftsgeheimnissen
- Vertrauen von Kunden und Partnern
Dennoch gibt es immer wieder teils schwerwiegende Lücken in Softwaresystemen und niemand möchte gern dafür verantwortlich sein. Doch woran liegt das eigentlich?
2. Fehlende Bewusstheit als maßgebliche Ursache
Das mit Abstand größte Risiko für die Sicherheit von Software ist mangelhafte Bewusstheit bei der Entstehung von Software, und zwar in zweierlei Hinsicht. Gemeint ist einerseits die Planung von Softwareprojekten und andererseits die handwerkliche Umsetzung.
In vielen Softwareprojekten spielt die Sicherheit anfänglich kaum eine Rolle und das ist in gewisser Weise auch überaus nachvollziehbar. Wer möchte schließlich am Anfang einer großartigen Idee schon darüber nachdenken, was schief gehen kann? Oft kommt der Gedanke daran erst im Laufe der Entwicklung und mitunter ist der Zeit- oder Budgetdruck so groß, dass gar keine Zeit dafür übrig ist, an die Sicherheit zu denken.
3. Bewusstheit Schaffen als wesentlicher Hebel
Eine sichere Softwareentwicklung beginnt daher bereits mit der Bewusstheit bei der Planung und dementsprechend in einer frühen Phase. Die zunehmend frühere Berücksichtigung von Sicherheitsanforderungen im Verlauf von Softwareprojekten ist dabei keine neue Idee. Dieser Gedanke wird als “Shift Left” und “Security by Design” sehr treffend auf den Punkt gebracht.
Daraus lässt sich jedoch klar ableiten, dass Sicherheit nicht nur Softwareentwickler betrifft. Es ist unerlässlich, dass bei allen Beteiligten die Bewusstheit vorliegt – von Management, über Projektleitung hin zu Qualitätssicherung und Betrieb.
4. Grundsätze für mehr Sicherheit bei der Entwicklung
Risikobewertungen sollten bereits früh im Projektverlauf eingeplant werden, denn sie ermöglichen Entscheidungen bewusst zu treffen. In einer agilen Vorgehensweise können Reviews mit Blick auf Missbrauchspotential eines Features zum Teil der Definition of Done werden. Penetration Testing zusammen mit der Möglichkeit auftauchende Lücken zu korrigieren als einen Meilenstein vor wesentlichen Releases einzuplanen, stellt eine sinnvolle Ergänzung dar.
Die Berücksichtigung von Sicherheit der Software in Planung und Methodik ist wesentlicher Teil der Herausforderung und darf nicht unterschätzt werden. Das schafft letztendlich den notwendigen Raum, um bei der Erstellung der Software gewissenhaft auf eine sichere Implementierung zu achten. Viele Sicherheitslücken haben ihre Ursache nämlich in Programmierfehlern, die zunächst nicht die funktionale Korrektheit einschränken.
5. Programmierfehler im Alltag vermeiden
Das Open Web Application Security Project (OWASP) trägt die häufigsten Fehler als Top 10 zusammen und gibt auch erste Empfehlungen zur Vermeidung dieser Fehler – immer wieder einen Blick wert. Allerdings erfordert es Einiges an Erfahrung und Übung, die Vielfalt dieser Tücken “mal eben neben” der Umsetzungen von Anforderungen bewusst vor Augen zu haben – wenn es überhaupt gelingt.
Peer Reviews mit erfahrenen oder speziell ausgebildeten Teammitgliedern können dabei wesentlich unterstützen, indem die Verantwortung zwischen anforderungsgerechter und zügiger Umsetzung getrennt
Übrigens: auch die konsequente Umsetzung von Domain Driven Design hat durchaus positiven Einfluss auf die Sicherheit der Software, denn der starke Fokus auf die Gestaltung des Domänenmodells überschneidet sich inhärent mit der Vermeidung von ungültigen und damit auch für Missbrauch anfälligen Zuständen.
6. Einbindung von Tooling
Entwicklungsteams haben darüber hinaus auch die Möglichkeit, vielfältige Werkzeuge einzusetzen. Dabei gibt es im Wesentlichen drei Kategorien
- Statische Codeanalyse
- Die Analyse von Third-Party-Komponenten auf Schwachstellen
- Tools zum Angreifen der Anwendungen
Selbstverständlich ist die Einbindung von Tools eine erhebliche Unterstützung zur Vermeidung von Programmierfehlern, bevor sie ausgenutzt werden können. Allerdings bleibt die Verantwortung für eine korrekte und sichere Umsetzung in den Händen des Entwicklungsteams und stellt somit eben nur eine sinnvolle Ergänzung zu einem gut ausgebildeten Team dar.
7. Am Rande: Entgegen der Kognition
Den Wert einer Investition in die Sicherheit einer Software zu bemessen hat im Übrigen eine besondere kognitive Herausforderung. Denn der echte Wert dieser Investition zeigt sich maßgeblich im Ausbleiben von Schäden. Im besten Fall spürt man als verantwortliche Person daher nie, welche schmerzhaften Auswirkungen man sich und den davon betroffenen Nutzern tatsächlich erspart hat. Tatsächlich neigen Menschen mitunter dazu, die Eintrittswahrscheinlichkeit sowie die Auswirkungen von nachteiligen Ereignissen zu unterschätzen. Dieser Effekt nennt sich Optimismusverzerrung und gehört in die Kategorie von Wahrnehmungsverzerrungen.
8. Fazit
Sicherheit in der Entwicklung muss von Anfang an bei der Planung berücksichtigt sein und das setzt die Bewusstheit – sowohl über den Wert als auch über die Maßnahmen zur Vermeidung – bei allen Projektbeteiligten voraus. Diese Bewusstheit wiederum bildet die Grundlage dafür, das umfangreiche Wissen aus dem Bereich sichere Softwareentwicklung durch das Entwicklungsteam bei der Umsetzung einfließen zu lassen. Der Erwerb dieses Wissens und der dazugehörigen Erfahrung erfordert seinerseits eine intensive Auseinandersetzung mit dem Thema.
Ein Vorgehen, das die in diesem Artikel genannten Grundsätze und Maßnahmen umsetzt, kann man kompakt als SecDev (abgekürzt von Secure Development) beschreiben. Es lässt sich auch mit der Idee von DevOps kombinieren zu DevSecOps.
Selbstverständlich ist nicht jede Software den gleichen Risiken vollumfänglich ausgesetzt und eine Abwägung der notwendigen Maßnahmen ist ökonomisch sinnvoll. Genau dieses bewusste Risikomanagement ist ein wesentlicher Bestandteil bei Einhaltung des Cyber Resilience Acts.
9. Wir möchten die Softwarewelt ein Stückchen besser machen
Beim Einstieg in die Softwareentwicklung, unabhängig davon, ob durch eine IHK-Ausbildung oder ein Studium, geht es am Anfang zunächst immer darum, dass ein Programm eine bestimmte Aufgabe übernimmt. Erst die Erfahrung und die echte Berührung mit der Auswirkung von Sicherheitslücken wirft die Nebenbedingung auf “…und nicht mehr”.
Mit unserem Workshop „Secure Coding – Security by Design“ möchten wir dabei helfen, diese Lücke zu überbrücken und freuen uns, wenn wir damit einen Beitrag leisten können, um Schwachstellen zu vermeiden. Der Workshop bietet die ideale Gelegenheit, sich durch praktische Übungen mit dem Thema SecDev vertraut zu machen. Insbesondere potenzielle Sicherheitslücken aus Sicht eines Angreifers identifizieren zu können hilft dabei, sie effektiv zu vermeiden.
Autor
Oliver Milke
Teamleiter Softwareentwicklung & SecDev Advocate
Jobs
Ihr Ansprechpartner
Gerne erzählen wir Ihnen mehr zu diesem Thema.
- Autor: Gastautor
- Datum:
