Softwaretechnik Mit Secure Scrum zu mehr Softwaresicherheit im IoT

Franz Graser

Anbieter zum Thema

In diesem Teil des Interviews mit Professor Hans-Joachim Hof von der Hochschule München geht es um Lösungsansätze, die zu besserer Embedded-Softwarequalität führen können. Konsistente Entwicklungsprozesse spielen hier eine zentrale Rolle.

Professor Dr. Ing Hans-Joachim Hof leitet die Munich IT Security Research Group. Der IT-Experte mahnt vor allem bessere Softwarequalität an sowie ein Umdenken bei der Entwicklung eingebetteter Software.
Professor Dr. Ing Hans-Joachim Hof leitet die Munich IT Security Research Group. Der IT-Experte mahnt vor allem bessere Softwarequalität an sowie ein Umdenken bei der Entwicklung eingebetteter Software.
(Bild: Hochschule für angewandte Wissenschaften München)

Im ersten Teil des Gesprächs mit Professor Hof von der Hochschule für angewandte Wissenschaften München wurde vor allem die Problemstellung beschrieben. Viel zu häufig, so Hof, herrsche im Embedded-Umfeld das Prinzip „verbaut und vergessen“ vor: Gerätesoftware werde entweder gar nicht oder viel zu selten aktualisiert. Mitunter fehle auch das Verständnis für die Notwendigkeit solcher Systemupdates, da die Entwickler zumeist keinen Informatik-Hintergrund hätten.

Um die Softwaresicherheit der Geräte zu steigern, die mit dem Internet verbunden sind, so Hof, müsse zunächst einmal die Softwarequalität deutlich verbessert werden. Aus Sicht des Security-Experten ist hier ein konsistenter Entwicklungsprozess von Bedeutung.

„Sichere Software-Entwicklungsprozesse müssen auch bei den IoT-Entwicklern einziehen“, fordert Hof. Dabei zeige sich aber, dass einige der gängigen Prozessmodelle, die in der allgemeinen Softwareentwicklung gepflegt werden, nicht ohne Weiteres auf die zumeist mittelständisch strukturierten Embedded-Gerätehersteller übertragbar sind.

Hof, der regelmäßig mit Unternehmen in Kontakt steht, berichtet beispielsweise, dass der Microsoft-SDL (Security Development Lifecycle) für viele mittelständische Entwicklungshäuser zu komplex sei: „Die Firmen sagen: Ich kann damit nichts anfangen. Der BSI-Grundschutz geht in eine etwas andere Richtung, aber auch da sagen die Leute: Ich kann damit nichts anfangen, das ist viel zu komplex.“

Wie kann aber eine vergleichsweise kleine Firma einen sicheren Entwicklungsprozess aufsetzen, wenn es zum Beispiel, wie der Professor berichtet, mitunter noch an anderen Stellen hakt – wenn etwa die Versionsverwaltung in mit Hilfe von ZIP-Dateien gehandhabt wird und auch die Testmethoden noch recht rudimentär sind?

Die von Hof geleitete Forschungsgruppe MuSe (Munich IT Security Research Group) hat deshalb das Verfahren „Secure Scrum" entwickelt, das es erlaubt, das agile Entwicklungsmodell Scrum um IT-Sicherheitsaspekte zu ergänzen.

Das Scrum-Modell ist grundsätzlich iterativ angelegt. Das Team geht innerhalb eines sogenannten Sprints in einem begrenzten Zeitraum ein überschaubares Aufgabenpaket an, an dessen Ende in der Regel testbare Software stehen muss. Sind die mit dem Auftraggeber abgestimmten Funktionspunkte innerhalb des Sprints abgearbeitet und abgenommen worden, steht das nächste Paket an.

Dieses Methodenmodell ist ausgesprochen attraktiv und wird auch im Embedded-Bereich sehr oft eingesetzt, weiß Professor Hof. „Wir haben Scrum um Elemente angereichert, die dazu führen, dass sich die Entwickler der Sicherheitsprobleme bewusst werden“, erläutert der Hochschullehrer die Vorgehensweise: „Das beginnt damit, dass wir am Anfang alle User-Stories kennzeichnen, die in irgendeiner Form sicherheitsrelevant sind, und sie mit pragmatischen Problemlösungen verlinken.“

Was bedeutet das konkret? Ein Entwickler, der eine bestimmte User-Story implementieren muss, sieht zum Beispiel sofort, dass es einen Eintrag in der Knowledge-Base gibt, die ihm bei der Lösung des Problems hilft. Ein zweiter Ansatz ist es, auch externes Wissen einzubinden – auch wenn das ein wenig im Widerspruch zur reinen Methodenlehre bei Scrum steht.

„Wir haben anerkannt, dass es Situationen geben kann, in denen die Entwickler nicht weiterkommen“, erläutert Hof: „Ein Embedded-Entwickler wird sicherlich keinen energieffizienten Krypto-Algorithmus implementieren. Wir haben also eine einfache Methode erfunden, wie man externes Know-how einbinden kann und trotzdem Scrum nicht kaputt macht.“

„Scrum möchte ja immer, dass am Ende eines Software-Entwicklungszyklus ein fertiges Inkrement steht, also testbare Software“, erläutert der MuSe-Leiter. „Jetzt haben Sie aber das Problem, dass IT-Sicherheitstests, vor allem das Penetrationstesten, eine ganze Weile dauern. Das funktioniert aber nicht mit der Definition von 'Done'.”

Der Hintergrund: „Es ist ja so, dass der Kunde das Produkt abnimmt und einen Haken daran macht. Bei funktionalen Requirements ist das problemlos möglich. Bei nicht funktionalen Requirements wie zum Beispiel IT-Sicherheit ist das extrem schwierig. Und da haben wir eine Möglichkeit gefunden, den Testing-Ablauf in Scrum zu integrieren. Das lag auch den Scrum-Entwicklern sehr am Herzen.”

Letzten Endes liegt aber ein Problem – vielleicht das zentrale – in dem Kostendruck, mit dem sich Softwareentwickler im Embedded-Umfeld konfrontiert sehen. „Es soll immer alles billig sein“, ereifert sich Professor Hof. „Daher ist meine persönliche Meinung: Wir bräuchten in Deutschland ein Softwarehaftungsgesetz, dass derjenige, der den Schaden verursacht, auch dafür haftet.“ Das könnte derjenige sein, der Software entweder herstellt oder der Gerätehersteller, der sie in einem Device verwendet.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

(ID:44017171)