Embedded-Software absichern Mit Sicherheit entwickeln

Eine mehrdimensionale Herangehensweise ist unerlässlich für sichere Embedded-Software.
Eine mehrdimensionale Herangehensweise ist unerlässlich für sichere Embedded-Software.

Bei Software ist Sicherheit kein Zusatz, den man zum Schluss hinzufügt, sondern sie muss für den ganzen Lebenszyklus eingeplant sein. Entwicklungs-Tools helfen bei dieser Aufgabe – wenn man beachtet, wie man sie richtig einsetzt.

Im Zuge der Digitalisierung werden viele Hersteller analoger Produkte plötzlich zu Softwareentwicklern: Von der Waschmaschine mit App-Anbindung bis hin zur Industrie-4.0-tauglichen Fertigungsanlage – zahlreiche Produkte sind heute digital. Im Wettbewerbsdruck konzentrieren sich viele Unternehmen meist zunächst auf das Wesentliche: die Funktionalität sicherstellen. Doch nicht nur vernetzte Fahrzeuge oder Medizingeräte erlauben keine Kompromisse bei der Sicherheit. In unserer digitalisierten Welt muss diese das Rückgrat eines jeden Entwicklungsprojekts darstellen – und damit von Anfang an auf unterschiedlichsten Prozessstufen im Zentrum der Überlegungen stehen.

Die steigende Komplexität moderner Softwareentwicklungsumgebungen stellt Unternehmen branchenunabhängig vor Herausforderungen. Im Zuge der Digitalisierung steigt die schiere Menge an Code und anderen digitalen Assets rapide an. Dafür zu sorgen, dass entwickelter Code sowohl sicher ist als auch erforderliche Compliance-Vorgaben erfüllt, wird damit zunehmend zur Herausforderung – zumal das Hauptaugenmerk vieler Entwickler oft weniger auf der Erstellung von sicherem Code als vielmehr auf der Entwicklung von innovativen Lösungsansätzen für ein bestehendes Problem liegt.

Mittlerweile lässt sich hier ein gewisses Umdenken beobachten: In vielen Entwicklungsabteilungen verbreitet sich zunehmend die Einsicht, dass es sich bei der Entwicklung sicherer Software nicht um einen separaten Arbeitsschritt am Ende des Prozesses handelt (oder Sicherheit vielleicht sogar erst im Produktivbetrieb in Form von Sicherheitsfixes „nachgeliefert“ werden kann). Vielmehr stellt Sicherheit eine kontinuierliche Aufgabe auf jeder Stufe des Lebenszyklus der Software dar – von der ersten Idee bis hin zur späteren Wartung.

Auch im Embedded-Bereich kommen zunehmend Vorgehensweisen wie DevOps zum Einsatz, und mit ihnen rücken Ansätze wie DevSecOps ins Zentrum der Aufmerksamkeit. Diese spiegeln das neue Verständnis von Sicherheit wider: So fordert beispielsweise die „Shift Left“-Bewegung, Testprozesse an einen möglichst frühen Zeitpunkt („nach links“) im Entwicklungsprozess zu verlagern und damit bereits den Entwicklern mehr Verantwortung für Tests zukommen zu lassen.

Um all diesem zusätzlichen Aufwand gerecht werden zu können, sind höhere Automatisierungsgrade notwendig, beispielsweise durch den Einsatz von Test- und Code-Analyse-Tools, die Projektbeteiligte entlasten und einen möglichst großen Teil des Arbeit im Hintergrund übernehmen. Denn in aller Regel haben Softwareentwickler weder Zeit noch Muße, neben ihrer eigentlichen Aufgabe auch noch zu Softwaretestexperten zu werden.

Vorab eine Warnung: Automatisierung ist eine große Hilfe, jedoch nicht, wenn dadurch lediglich massenhaftes Datenrauschen generiert wird, aus dem sich nur mit Mühe wirklich verwertbare Informationen gewinnen lassen. Wichtig ist, sich auf die Tests fokussieren zu können, die tatsächlich eine echte Relevanz besitzen, beispielsweise indem automatisiertes Continuous Testing mit Smart Analytics kombiniert wird. Mittlerweile gibt es auch schon erste Beispiele für den Einsatz von Machine Learning in automatisierten Testing-Tools. Auch wenn diese Entwicklung noch ganz am Anfang steht, wird die entsprechende Technologie in Zukunft eine unerlässliche Komponente automatisierter Testprozesse darstellen.

Besonders in Branchen, in denen Compliance und Sicherheit eine große Rolle spielen, ist auch die Einhaltung von Kodierungsstandards eine wichtige Voraussetzung für die Entwicklung sicheren Codes. Gerade für komplexere Programmiersprachen – wie C++, das im Embedded-Kontext häufig zum Einsatz kommt – sind diese zentral. Solche Sprachen ermöglichen Entwicklern aufgrund ihrer Hardware-Nähe große Freiheitsgrade. Durch den spiegelbildlichen Interpretationsspielraum besteht jedoch selbst für versierte Entwickler ein recht hohes Risiko, unbeabsichtigt Fehler in den Code einzubauen.

Kodierungsstandards beinhalten Richtlinien, die Entwickler vor diesem Hintergrund dabei unterstützen, Code zu entwickeln, der die zentralen Anforderungen an Sicherheit erfüllt und gleichzeitig den erforderlichen Compliance-Vorschriften entspricht. Auch hierbei ist Automatisierung zentral, besonders für Embedded-Projekte mit großen Codemengen und komplexen Strukturen. So sind beispielsweise Tools zur statischen Code-Analyse in der Lage, Softwarecode in Echtzeit während des Verfassens auf Einhaltung des jeweils relevanten Kodierungsstandards zu prüfen und unmittelbar auf Abweichungen aufmerksam zu machen.

Auch Open Source ist „nur“ eine Art von Software und damit nicht weniger vor Sicherheitslücken und Bugs gefeit als proprietäre Software. OpenSSL beispielweise zählt zu den weltweit meistgenutzten Open-Source-Security-Lösungen – dennoch werden auch hier immer wieder kritische Fehler entdeckt. Dies bedeutet: Eine sorgfältige Pflege ist auch für quelloffene Software eine Pflicht und nicht etwa nur reine Kür. Ähnliches gilt für das Versionskontroll-Tool Git. Dieses ist zwar weitverbreitet im Einsatz, doch haben Unternehmen oft komplexere Anforderungen an Sicherheit, als es die Open-Source-Community in ihrem hauptsächlich auf Entwickler zugeschnittenen Tool berücksichtigt hat.

Ein weiterer Faktor, den es zu bedenken gilt: Open Source ist oft kostenlos beziehungsweise günstig in der Anschaffung und „umgeht“ damit nicht selten die unternehmensinterne Beschaffung, kommt also „unter dem Radar“ zum Einsatz. Gerade hier müssen Unternehmen Mittel und Wege finden, um sicherzustellen, dass jede genutzte quelloffene Software im Einklang mit den internen Sicherheitsvorgaben steht.

Die Entwicklung praktikabler Open-Source-Richtlinien erfordert eine sehr breite Expertise. Der Aufwand, der erforderlich ist, um immer auf dem neuesten Stand zu bleiben, mag dazu verleiten, es mit der gebotenen Sorgfalt nicht immer ganz genau zu nehmen. Zudem werden Lösungen oft weniger stark auf Basis objektiver Kriterien – wie etwa die Kompatibilität mit dem bestehenden Ökosystem – ausgewählt. Die Folgen: Ein wahres „Potpourri“ aus Lösungen unterschiedlichster Open-Source-Anbieter, inkonsistente Service Level Agreements (SLAs) über die einzelnen Komponenten im Stack hinweg, ein Mangel an Klarheit über Zuständigkeiten sowie die Gefahr, nicht länger in der Lage zu sein, sich schnell genug an die neuesten Technologie-Einführungen anzupassen. All diese Risiken sollten bei der Einführung einer neuen Open-Source-Software in jedem Fall gegen die erhofften Vorteile abgewogen werden.

Wenn es darum geht, Software gegen Cyberangriffe abzusichern, sollten Unternehmen eine Bedrohungsmodellierung in Erwägung ziehen. Bei diesem Prozess werden potenzielle Bedrohungen aus Sicht eines Angreifers sowohl identifiziert als auch priorisiert. Auf welche Art von Daten hätte es dieser womöglich abgesehen? Welchen Angriffsvektor könnte er nutzen, um Zugriff darauf zu erhalten? Ein beliebtes Modell zur Bedrohungsanalyse ist „Stride“, das in Kombination mit dem Risk-Assessment-Framework „Dread“ verwendet werden kann. Beide helfen Unternehmen dabei, zu erarbeiten, wie wahrscheinlich eine bestimmte Bedrohung ist, welche möglichen Konsequenzen daraus entstehen könnten und ob das entsprechende Risiko in Kauf genommen werden kann oder nicht.

Für Web-Anwendungen beispielsweise hat die Open Web Application Security Project Foundation eine Liste der zehn häufigsten und gefährlichsten Sicherheitsrisiken herausgeben. Diese ist auch für Software anderer Art eine hervorragende Referenzquelle. Jede Bedrohung wird dort eingestuft nach mehreren Faktoren: Akteur, Ausnutzbarkeit, Verbreitung, Erkennbarkeit und technische sowie geschäftliche Auswirkung.

Die Top Ten der OWASP lassen sich zudem zur Verbesserung der Sicherheit von Schnittstellen (APIs) nutzen. Auch in diesem Kontext etabliert sich zunehmend der Ansatz, bereits auf jeder Stufe ihres Lebenszyklus ein Augenmerk auf ihre Sicherheit zu werfen. Denn ist eine API erst einmal veröffentlicht und tritt dann ein Problem auf, bleibt oft nur sehr wenig bis gar keine Zeit, Abhilfe zu schaffen: Analog zu einer Website, die kurz nach ihrer Online-Schaltung bereits zahlreichen Angriffsversuchen ausgesetzt ist, stehen auch APIs meist sehr schnell im Kreuzfeuer von Kriminellen.

Eine Verbesserung der API-Sicherheit beginnt bei der Unternehmenskultur. Alle Projektmitglieder müssen sich der Rolle bewusst sein, die sie selbst für die Verbesserung der Sicherheit sowie für die Risikominimierung spielen. Dies gilt sowohl für interne als auch externe Beteiligte, von denen einige unter Umständen über wenig Entwicklungserfahrung verfügen – schließlich erfordert die Erstellung von Schnittstellen oft kein umfassendes Spezialwissen. Entsprechend hilft die Einrichtung von Prozessen, die automatisiert und konsistent für alle APIs angewendet werden können, dabei, sinnvolle Sicherheitspraktiken zu etablieren.

Sichere Softwareentwicklung ist keine Frage von Einzelmaßnahmen, sondern setzt sich aus unterschiedlichsten Faktoren zusammen. Dazu gehören neben der Etablierung einer sicherheitsfokussierten Unternehmenskultur auch die Realisierung eines möglichst hohen Automatisierungsgrads sowie Arbeitsprozesse, die jederzeit das große Ganze im Blick behalten. Gerade dieser letzte Punkt ist besonders wichtig: Denn Transparenz bezüglich der Arbeit der anderen Projektbeteiligten stellt die Grundlage dafür dar, die Auswirkung der eigenen Beiträge zum Gesamtprojekt zu verstehen und unter Sicherheitsaspekten beurteilen zu können.

Mit dem Voranschreiten der Digitalisierung wird die Bedeutung von Software für immer mehr Unternehmen ansteigen. Gleichzeitig nimmt die Komplexität moderner Softwareentwicklung kontinuierlich zu: So erfordern die digitalen Produkte unserer heutigen Zeit immer umfangreichere Codebasen, die jedoch mit dem Grad ihrer Vernetzung stärker in den Fokus von Hackern und Cyberkriminellen rücken. Die Etablierung einer mehrdimensionalen Herangehensweise an sichere Entwicklung muss daher zur Priorität in der modernen Embedded-Entwicklung werden – und von der ersten Idee an im Softwareprojekt verankert sein.