In The Code: Security by Design

Alen Mijatovic postuliert sieben goldene Regeln für mehr Sicherheit in der Software-Entwicklung.
 
APIs, Kollaboration, Cloud, IoT – die IT-Systeme werden offener. Gleichzeitig nimmt die Zahl der Cyberattacken rapide zu. Im Idealfall wird Security nicht erst dem Endprodukt übergestülpt, sondern im Software-Engineering von der Idee bis zur Abnahme als Designelement abgebildet.
 
Ende August verkündete die 'NZZ', dass eines der wichtigsten unbewältigten mathematischen Rätsel offenbar gelöst werden konnte: das so genannte "P vs. NP"-Problem aus der Informatik. Sollte die mathematische Beweisführung sich als korrekt herausstellen, heisst es, wären die gängigen Verschlüsselungsmethoden, wie sie für Online-Banking und -Shopping verwendet werden, tatsächlich sicher.
 
Aber wieso erst sichern und verschlüsseln, wenn die Applikation bereits existiert?
Warum nicht Security von Beginn an in den Überlegungen berücksichtigen? Und zwar bereits in der Ideen- und Designphase.
 
Sicherheit gehört als Kriterium in die Spezifikation
Die überwiegende Mehrheit erfolgreicher Cyberangriffe beruht auf schlecht programmierter, schlecht gewarteter oder schlecht konfigurierter Software.
 
Doch werden dem Entwickler Sicherheitsfunktionen als Designkriterium vorgegeben, lassen sich Systemfehler von vornherein vermeiden. Denn ein Entwickler arbeitet Spezifikationen ab. Gehört Security nicht zu den Designkriterien bei der Software- und Applikationsentwicklung, arbeitet er es in der Regel auch nicht ab.
 
In der Ideenphase stellt sich der Software-Entwickler die Fragen, wie beispielsweise die Eingabemaske aussehen soll. Oder wie leistungsfähig die neue Software sein soll. Was sie alles können muss. Was läge näher, als auch die Security-relevanten Aspekte in diese grundsätzlichen Klärungen einzubeziehen:
  • Lässt sich die Idee unter Sicherheitsgesichtspunkten überhaupt realisieren?
  • Wie muss die funktionale Sicherheitsanforderung aussehen?
  • Wie lässt sie sich konkret über alle relevanten Funktionen hinweg umsetzen?
Im Idealfall fliesst der Sicherheitsaspekt so bereits in den Prototyp ein – und wird durch alle Produktionsstufen mitgetragen.
 
Mit sieben Grundregeln Angriffsfläche um mehr als 95 Prozent reduzieren
Experten empfehlen sieben Grundregeln, an denen sich Entwickler im Security by Design orientieren sollten, um die Angriffsfläche ihrer Produkte um mehr als 95 Prozent zu reduzieren.
 
Erstens: Angriffsfläche klein halten: Die Angriffsfläche lässt sich deutlich minimieren, indem Überflüssiges weggelassen oder zumindest deaktiviert werden kann. Ganz nach dem Motto "Was gar nicht erst da ist, kann auch nicht angegriffen werden". Und was nicht ständig benötigt wird, sollte auf inaktiv gestellt werden können.
 
Zweitens: Geeignet authentifizieren: Vertrauliche Informationen und Informationssysteme sollten nur für die gewünschten Kommunikationspartner zugänglich sein. Wer sicherstellt, dass nur authentifizierte Nutzer oder Systeme auf etwas zugreifen können, schliesst mit einer hohen Wahrscheinlichkeit alle nicht identifizierten aus.
 
Drittens: Eingaben überprüfen: Jede Eingabe sollte auf zulässige Zeichen, insbesondere Sonderzeichen, und auf die maximal zulässige Eingabelänge geprüft werden. Beispiel: Bei der Bestellung auf einem Webportal sind im Feld für das Geburtsdatum des Nutzers nur Zahlen und möglicherweise noch Punkte erforderlich. Ein Angriff kann somit verhindert werden, indem alles ausser Zahlen und Punkte ignoriert wird.
 
Viertens: Wo möglich automatisieren: Auch Entwickler sind Menschen, denen Fehler unterlaufen. Assistenzsysteme können, wenn in Entwicklungsumgebungen integriert, automatisiert die Fehler erkennen, die zu Sicherheitsproblemen führen, und Alternativen zur Lösung vorschlagen.
 
Fünftens: Systeme trennen: Nach einem erfolgreichen Angriff auf ein System versuchen Angreifer häufig, von dort nach und nach Zugriff auf weitere Systeme zu erhalten. Systeme sollten daher voneinander getrennt werden. Wenn ein Angreifer dann etwa den Webserver hackt, ist er noch lange nicht in der Datenbank.
 
Sechstens: Security über den Software-Lebenszyklus führen: Taucht dann doch in einer Version der Software eine Schwachstelle auf, muss das Versionenkontrollsystem so konfiguriert sein, dass es diese Version erst dann im Repository zulässt, nachdem die Schwachstelle eliminiert wurde.
 
Siebtens: Nicht sorglos werden: Selbstverständlich muss auch sicherheitsdesignte Software regelmässig aktualisiert und kontinuierlich getestet werden. Neue Versionen enthalten meist auch neue Abwehrmechanismen gegen bekannt gewordene Sicherheitslücken der Vorgängerversionen. Und der Zustand der Systeme insgesamt muss im Hinblick auf Angreifbarkeit ohnehin kontinuierlich überprüft werden.
 
Weniger Haftungsrisiko und geringere Folgekosten
Mit der anrollenden Welle von IoT-Anwendungen müssen Hersteller künftig damit rechnen, dass sie dafür haften, wenn Sicherheit nicht von vornherein vernünftig eingebaut worden ist. Unternehmen verringern somit mit Security by Design ihr Haftungsrisiko.
 
Und werden durch Security by Design Sicherheitslücken von allem Anfang an reduziert, dann können auf Anwenderseite Aufwände für Wartungsprozesse reduziert werden, da deutlich seltener Sicherheitspatches organisiert, getestet sowie ggf. verteilt und installiert werden müssen. Dadurch vermindern sich die Kosten einer Software im Betrieb, was letztlich als Verkaufs- und Marketinginstrument taugen kann. (Alen Mijatovic)
 
Über den Autor
Alen Mijatovic ist Head of Business Development & Deal Management bei T-Systems Schweiz.
 
Über "In The Code"
Im Monatsrhythmus erhalten Spezialisten unterschiedlicher Schweizer Unternehmen Gelegenheit, ihre Praxis-Erfahrungen zu teilen.