Sichere Software in 10 Schritten

Security by Design Principles des OWASP

| Autor / Redakteur: Mirco Lang / Stephan Augsten

Trotz des Web-Fokus ist das Open Web Application Security Project (OWASP) generell eine gute Anlaufstelle für Sicherheit in der Entwicklung.
Trotz des Web-Fokus ist das Open Web Application Security Project (OWASP) generell eine gute Anlaufstelle für Sicherheit in der Entwicklung. (Bild: owasp_logo.png / Samantha Groves / BY-SA 4.0)

Sicherheit wird in der Software-Entwicklung wird vermehrt mit Security by Design in Verbindung gebracht. Das Open Web Application Security Project, kurz OWASP, hat hierzu zehn wichtige Grundsätze erfasst.

Software-Sicherheit hieß früher allzu oft: Man entwickelt eine Anwendung, schaut sich anschließend nach Schwächen um und härtet sie anschließend, baut vielleicht eine Schutzwand auf – Security by Design bedeutet aber, dass Sicherheit noch vor der ersten Code-Zeile in grundsätzliche Prinzipien gegossen wird. Dies sollte jeder Entwickler berücksichtigen, zumal auch Kunden dies zunehmend erwarten

Auch heute noch gibt es noch massenhaft weit verbreitete Systeme, die jeden Monat mit etlichen Sicherheitspatches versorgt werden müssen. Natürlich schreit der Markt auch nach Geschwindigkeit, man denke nur an Microsofts Ur-Strategie „First to Market“. Wenn eine Nische einmal besetzt ist, kann man immer noch nachbessern. Wer will schon ein sichereres Produkt in einem Jahr herausbringen, wenn es auch heute schon verkauft werden kann? Die Konkurrenz schläft nicht.

Doch diese Denke gehört nicht mehr in die heutige Zeit. Wie sehr auch Absatzmärkte einbrechen können, können Sie zum Beispiel in unserem Beitrag über die Sicherheitsanforderungen an Softwareentwickler seitens des Bundes nachlesen.

Spätestens wenn potenzielle Kunden Angebote von vorneherein ausschließen, weil wichtige IT-Security-Strukturen fehlen, dürfte die Erkenntnis reifen. Und das https://www.owasp.org/ Open Web Application Security Project (OWASP) ist immer wieder eine gute Anlaufstelle, auf die sich beispielsweise auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) regelmäßig bezieht.

Die OWASP Security by Design Principles sollte im Grunde jeder in der Entwicklung kennen, vom Architekten über den Coder bis hin zu den Management-Verantwortlichen. Übrigens: Unangetastet von all diesen Prinzipien thronen natürlich nach wie vor die drei Grundsäulen Integrität, Vertraulichkeit und Verfügbarkeit als Ziele aller Sicherheitsbemühungen über allen Maßnahmen.

Sicherheit für Web­an­wen­dungen mit Zed Attack Proxy

Tool-Tipp: OWASP Zed Attack Proxy (ZAP)

Sicherheit für Web­an­wen­dungen mit Zed Attack Proxy

10.07.18 - Administratoren oder Entwickler, die Webanwendungen betreiben, kämpfen ständig mit Sicherheitslücken. Das Open-Source-Tool „Zed Attack Proxy“ (ZAP) gehört zum „Open Web Application Security Project“ (OWASP) und ermöglicht automatisiert Web-Apps auf Sicherheitslücken zu überprüfen und Angriffe durchzuführen. lesen

Angriffsfläche minimieren

Viele Entwickler neigen vor allem bei mittelgroßen Projekten dazu, die berühmte eierlegende Wollmilchsau zu produzieren. Klar, mehr Funktionen verheißen ein breiteres Kundenfeld. Doch jede Funktion bietet eine eigene Angriffsfläche.

Ein schönes Beispiel ist die Hilfefunktion in früheren Windows-Versionen: Für Nutzer gesperrte Funktionen konnten noch in Windows XP teilweise über Links in den Hilfedateien aufgerufen werden. Dieses „Feature“ wurde später gefixt, man hätte aber auch gleich auf eine Online-Hilfe oder Text- statt anklickbare Links setzen können.

Sichere Vorgaben

Die sicheren Defaults werden auch heute noch sehr häufig vernachlässigt – Konfigurationsmanagement dürfte auch nicht immer bei den Kernentwicklern liegen. Es geht um den Auslieferungszustand von Software. Beispielsweise sollten keine Standardpasswörter gesetzt werden, Standardnutzerrollen sollten immer mit möglichst wenig Rechten ausgestattet sein, Log-Funktionen immer Opt-in und so weiter.

Die Forderung nach sicheren Auslieferungszuständen finden Sie zum Beispiel auch in den Mindeststandards Bund des BSI, die immerhin bindend für den Bund und nahezu bindend für Länder und Kommunen sind. Bei größeren Systemen könnte diese Aufgabe natürlich auch den Systemintegratoren vor Ort beim Kunden zufallen. Hier sollte also von vorneherein entsprechender Austausch mit den Entwicklern stattfinden.

Minimale Rechte

Die Forderung dürfte wohl selbsterklärend sein: Nutzer und Komponenten sollten immer nur die Privilegien besitzen, die auch wirklich benötigt werden, um ihre Aufgaben lösen zu können. Das gilt für CPU-Zyklen eines Threads genauso wie für Schreibrechte eines Sachbearbeiters oder Administrationsrechte eines Managers.

Ein kleiner Tipp aus der Praxis: Bei Mitarbeitern sollten Sie aber auch nicht zu viel Freiheiten abknapsen! Wie sagte Jeff Goldblum so schön im ersten Jurassic Park: „Das Leben findet einen Weg.“ Und auch Mitarbeiter finden kreative Wege, wenn man sie mit zu viel Einschränkungen drangsaliert.

Sicherheit in der Tiefe

Hier können Sie sich an der Sortimentstiefe, etwa im Supermarkt, begrifflich orientieren: Die Breite des Sortiments sorgt dafür, dass Sie viele unterschiedliche Produktarten bekommen. Die Tiefe dafür, dass Sie von einem Produkt mehrere Varianten erstehen können.

In der IT-Security heißt das: Ein Kontrollmechanismus ist gut, drei sind besser. Die Integrität von Code lässt sich beispielsweise über strenges User-Logging gewährleisten, über intensive Peer-Review-Prozesse und auch durch technische Ansätze. Aber es lohnt sich eben, hier Prozessketten aufzubauen und unterschiedliche Sicherheitstechniken kummulativ einzusetzen.

Sicher fehlschlagen

„Fail securely“ lässt sich nicht wirklich gut ins Deutsche übersetzen und ist umgangssprachlich eigentlich kaum nachzuvollziehen. Gemeint ist der Fail auf Code-Ebene: Prozesse in Applikationen werden immer wieder mal fehlschlagen, egal wie sauber an sie plant und produziert.

Ob es dann an „kreativen“ Nutzereingaben liegt, die niemand vorhersehen konnte oder an technischen Störungen wie Updates und Stream-Abbrüchen, es wird passieren. Und wenn, dann sollte die Software solche Fehler abfangen. Kurz gesagt: Machen Sie ausgiebig Gebrauch von Try-Catch-Statements und sonstiger Fehlerbehandlung – auch, wenn dieselbe Funktion dann ein paar Zeilen mehr Code benötigt.

Services nicht trauen

Outsourcing ist heute eine Selbstverständlichkeit in jeder Form und Größe der IT. Und wenn es nur der Dropbox-Speicher zum Teilen von Ideen mit den Kollegen ist, die Code-Verwaltung über Github, die Rendering-Farm auf AWS, Bibliotheken von Drittanbietern oder was auch immer. Trotz aller Verträge, die Sie möglicherweise mit solchen Dienstanbietern geschlossen haben, sollten Sie alle Datenflüsse nochmal eigenverantwortlich kontrollieren. Je nach Möglichkeit gilt das auch für die Security-Zusagen Ihrer externen Partner.

Trennung von Verantwortlichkeiten

In vielen Produkten kann man ein schönes Phänomen sehen: Die Rechte von Nutzerrollen vererben sich komplett auf die nächst höhere Stufe, so dass der „Master User“ alles darf, was der „User“ darf, plus reine „Master-Angelegenheiten“. Der „Admin“ darf dann all das plus noch mehr und der „CEO-User“ darf dann schlicht alles.

In der Praxis ist bereits der Admin häufig eine Art „God User“. Dabei soll der Admin nur administrieren – er soll das System nicht wie ein normaler Nutzer nutzen! Wenn die Rolle „Admin“ sowohl administrieren als auch nutzen kann, wird der geneigte Account-Inhaber wohl beides mit dem Admin-Konto erledigen – über organisatorische Regelungen ist das schwer zu etablieren, technisch lässt sich das Problem zumindest in einigen Fällen angehen.

Keine Security by Obscurity

Es gibt tatsächlich noch Menschen in der IT, die meinen, ihr Code wäre sicherer, wenn sie nur niemanden hineinschauen ließen – ein Mythos, den eigentlich nur ziemlich Code-ferne Kollegen weiterpflegen dürften. Offenheit und Transparenz haben sich sowohl in der Praxis als auch in Studien in den vergangenen Jahrzehnten wieder und wieder als sicherer bewiesen.

Geschlossener Code und möglichst umständliche, nicht nachvollziehbare Routinen haben als Sicherung in den meisten Fällen versagt. Allein ein Blick auf Windows und Linux dürfte hier mehr sagen als tausend Worte. Eine Software, die nur sicher ist, so lange ein Angreifer den Code nicht kennt, ist ein irres Risiko – denn Leaks, Unfälle und Reverse Engineering finden statt.

Das beste Beispiel dürften im Grunde Verschlüsselungsalgorithmen sein: Alles was hier relevant ist, ist komplett offen und transparent – und häufig sogar durch offene Wettbewerbe entstanden. Sicherheit entsteht hier durch die immense Rechenleistung, die für das Knacken von Passwörter benötigt wird, es werden also immer massig finanzielle, technische und zeitliche Ressourcen benötigt. Würde die Sicherheit nur von der Geheimhaltung des Quellcodes abhängen, würde ein einzelner Unfall genügen, um die (IT-)Welt ins Chaos zu stürzen.

Sicherheit einfach halten

Code und Architektur sollten möglichst einfach und übersichtlich gehalten werden. Bei allzu komplexen, ineinander verschachtelten Strukturen wird es zum einen schwierig, den Überblick zu behalten und zum anderen können sich Fehler in einzelnen Bereichen auf das gesamte System auswirken.

Bisweilen lassen sich Sicherheitslücken dann gar nicht mehr beheben, ohne das System auch noch an 50 weiteren Stellen anpassen zu müssen, so es denn überhaupt geht. Auch etwaigen Personalwechseln sollten man bei diesem Punkt nicht außer Acht lassen. Die Zeiten, da es nur einen einzigen „Guru“ im Betrieb gab, der tatsächlich alles wusste, sollten (längst) vorbei sein, auch neue Mitarbeiter müssen sich einigermaßen fix in eine Codebasis einarbeiten können.

Sicherheitsprobleme korrekt beheben

Trotz aller Vorsorge: Es wird zu Sicherheitsvorfällen kommen, garantiert. In solchen Fällen sollten Sie nicht bloß mit möglichst wenig Aufwand zeitnah einen Fix bereitstellen, sondern den Fehler über festgelegte Prozesse analysieren. So können Sie wirklich verstehen, warum ein Fehler aufgetreten ist und folgend überprüfen, ob sich dieser oder ähnliche Fehler vielleicht auch in anderen Code-Basen finden lassen. Und mit diesen Erkenntnissen können Sie dann einen guten Fix ausrollen.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45708958 / Softwareentwicklung)