Embedded-Entwickler stärken – mit Sicherheit Kontinuierliche Software-Releases im Internet of Things

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Viele Sicherheitsbedrohungen im Internet of Things, kurz IoT, gehen auf Bugs zurück, die bereits im Zuge der Software-Entwicklung entstehen. Aber woher kommen diese Bedrohungen eigentlich – und wie reagieren Entwickler?

Das Internet der Dinge (Internet of Things, IoT) ist ein Milliarden Euro schwerer Markt, in dem viele Unternehmen mitspielen wollen. Deswegen geben einige offenbar einem schnellen Markteintritt den Vorrang vor der Sicherheit. Das ist umso gefährlicher, als IoT-Geräte immer beliebtere Angriffsziele werden.

Das Linux-Ökosystem strebt grundsätzlich ein hohes Maß an Qualität an. Historisch gesehen lag es in der alleinigen Verantwortung der Community, Software zu paketieren und jedes Anwendungs-Update einer sorgfältigen Überprüfung zu unterziehen. Sie sollte so sicherstellen, dass das Update wie beschrieben und auf jeder Linux-Distribution funktioniert.

Dies erwies sich aber zunehmend als Herausforderung für alle Beteiligten, nicht zuletzt deswegen, weil so viele Support-Anfragen und Bugs über die Linux-Distributionen übermittelt wurden. Diese Informationen an die entsprechenden Software-Autoren weiterzuleiten, wurde immer schwieriger.

Je größer die Zahl der Anwendungen und Linux-Distributionen, desto klarer wurde, dass dieses Modell nicht mehr trägt. Die Autoren der Software nahmen sich kurzerhand selbst der Sache an: die wählten oft nur eine einzige unterstützte Linux-Distribution aus und umgingen einen App-Store gänzlich. Im Ergebnis machten sie so die Anwendungen schwerer auffindbar und – wegen einer doppelten Infrastruktur – deren Betrieb komplexer.

Bedrohungen adäquat abwehren

Sicherheitslücken wie Spectre und Meltdown, die auf Schwachstellen in der Hardware-Architektur von Prozessoren zurückzuführen sind, haben gezeigt, wie dringend nötig Software-Aktualisierungen sind. Selbst wenn deren Management für Endanwender in Unternehmen noch nicht wesentlich einfacher geworden ist.

Es ist schlicht nicht länger akzeptabel, jede vernetzte Software als fertiges Produkt zu betrachten. Software-Wartung muss sich über die gesamte Produkt-Lebensdauer erstrecken, insbesondere in der heutigen vernetzten Welt. Die Zunahme der Robotik-Anwendungen und das Edge-Computing, die mehr Geräte online bringen, tragen das ihrige bei zur Ausbreitung der Bedrohungen.

Eine Befragung von IoT-Fachleuten durch Canonical ergab, dass sich über zwei Drittel der Befragten über einen fehlenden allgemein gültigen Industriesicherheitsstandard für das IoT Sorgen machen. Ein weiteres Resultat der Studie: fast ein Drittel der Befragten hat Schwierigkeiten, IT-Fachkräfte zu finden, die sich beim Thema IoT-Sicherheit auskennen. Das Problem ist erkannt und bekannt. Indes: ohne die entsprechenden Qualifikationen, sollen Entwickler sicherstellen, dass die Software robust ist.

Zunehmender Druck auf den Entwickler

Die Erwartungen an die Entwickler steigen. Entsprechend schwerer wiegt die Verantwortung, die sie tragen sollen. Sie sind nicht mehr nur die Macher hinter den Kulissen; sie tragen nun das Risiko, dass beispielsweise ein Roboterarm mit ihrem Programmcode bricht oder ein Patch MRT-Geräte zum Absturz bringt.

Als Industrie erkennen wir dieses Problem an, ohne wirklich etwas dagegen zu unternehmen. Man kann ein schlechtes Update haben, weil Software keine exakte Wissenschaft ist; aber dann bitten wir diese Entwickler, Schicksal zu spielen, und – um der Innovation willen – Kompromisse bei der Sicherheit einzugehen.

Auf der anderen Seite können Entwickler die Weiterentwicklung ihrer Software durchaus gegen ein Gefühl der Sicherheit eintauschen, indem sie ihren Code einfach als unveränderlich behandeln. So kommt es, dass immer noch Geräte ausgeliefert werden, die nie ein Update erfahren. Entwickler werden zu diesem Ansatz von den Geräteherstellern getrieben, die verstopfte Support-Leitungen als viel unbequemer betrachten, als sich einer Sicherheitsverletzung zu stellen.

Die Industrie entwickelt weiterhin immer mehr Software-Komponenten, die zusammengesteckt werden können und auf die Lösungen aufgesetzt werden können. Entwickler dürfen sich nicht allein die Update-Frage für ihren eigenen Code stellen, sondern müssen auch beim gesamten Code, der unter ihrem eigenen liegt, allen Entwicklern vertrauen, die vor der gleichen Entscheidung stehen.

Wie sollen Entwickler unter diesem Druck Software liefern, die noch dazu beim Thema Kosten nicht aus dem Ruder läuft? Auch wenn es für diese Herausforderung keinen Königsweg gibt, könnten Snaps eine Lösung bieten.

Das Angebot erweitern

Snapcraft ist eine Plattform zum Veröffentlichen von Anwendungen für Millionen von Linux-Anwendern. Sie ermöglicht es Autoren, Software-Updates herauszugeben, die sich automatisch installiert und im Falle eines Fehlers zurücksetzt.

Die Wahrscheinlichkeit, dass ein fehlerhaftes Update ein Gerät blockiert oder die Endbenutzererfahrung beeinträchtigt, wird dadurch stark reduziert. Wenn in den Bibliotheken, die eine Anwendung verwendet, eine Sicherheitslücke entdeckt wird, wird der Herausgeber der Anwendung benachrichtigt, so dass die Anwendung mit dem mitgelieferten Fix schnell neu gebaut und anschließend bereitgestellt werden kann.

Da Snaps ihre Laufzeitabhängigkeiten bündeln, funktionieren sie auf allen wichtigen Linux-Distributionen, ohne dass Änderungen nötig werden. Sie sind manipulationssicher und arbeiten in einer sicheren Ausführungsumgebung. Ein Snap kann keine andere Anwendung verändern oder von einer anderen Anwendung verändert werden. Jeder Zugriff auf das System über seine sichere Ausführungsumgebung hinaus muss ausdrücklich gewährt werden.

Diese präzise Definition bringt eine einfachere Dokumentation für die Installation und Verwaltung von Anwendungen mit sich. Zusammen mit automatischen Aktualisierungen, die den „Long Tail“ von Versionen beseitigen, sind vorhersehbarere und niedrigere Supportkosten typisch. Die Abweichung zwischen dem, was die Qualitätssicherungs-Abteilung testet, und dem Verhalten der Applikation auf den Systemkonfigurationen der Endanwender ist minimal.

Snapcraft bietet auch leistungsfähige Tools zum Organisieren von Releases in verschiedenen Release-Versionen (Kanäle). Ein Satz von Tools kann verwendet werden, um App-Updates von automatischen CI-Builds an die Qualitätssicherung, Betatester und schließlich an alle Benutzer weiterzuleiten.

Entwickler sollen vertrauensvoll ihre Apps bauen

Der Unterschied zwischen einer realen und einer hypothetischen Bedrohung ist gar nicht so groß. Man muss gewissermaßen auf einen Fehler vorbereitet sein. „Build for failure“ ist besser als anzunehmen, dass etwas „nicht schief gehen kann“. Denn dies kommt ein Unternehmen teuer zu stehen, wenn doch etwas schief geht und es keinen Plan hat.

Snaps verfolgt genau diesen Ansatz. Anstatt Software-Updates als eine riskante Maßnahme zu verstehen und sie nur ganz selten einzusetzen, erkennt Snaps an, dass Aktualisierungen fehlschlagen können. Wenn sie dies tun, geht der Snap zurück zur letzten Version, ohne dass die Endbenutzererfahrung beeinträchtigt wird. Der Entwickler kann dann ohne Zeitdruck den Fehler finden.

Aber da Software-first-Unternehmen immer wieder neu gegründet werden, übt dies einen unermesslichen Druck auf diese Teams aus. Kompromisse sind nötig, sie dürfen aber nicht bei der Sicherheit ansetzen. Cyber-Angriffe sind brandgefährlich. Es steht zu viel auf dem Spiel für Unternehmen. Deswegen sollten Lösungen wie snaps nicht ignoriert werden.

Entwickler werden immer wichtiger für zahlreiche Geschäftsprozesse in Unternehmen. Darum gilt es, sie zu unterstützen und ihnen die Tools an die Hand zu geben, die sie brauchen, um ihren Job machen zu können. Unabhängig davon, ob sie für eine Desktop-, Cloud- oder IoT-Lösung entwickeln, sollten sie auf Open Source und Snaps setzen. Denn diese Kombination gewährleistet, dass Anwender die neueste Software einsetzen und Systemkonfigurationsprobleme wenig wahrscheinlich sind.

In der Konsequenz können Entwickler mehr Code schreiben und müssen weniger debuggen. Wenn Entwickler diesem Beispiel folgen, haben sie die Zeit, aber vor allem das Vertrauen, weiterhin Lösungen zu entwickeln, die so sicher wie möglich sind.

* Martin Wimpress ist Developer Advocate von Canonical, dem Unternehmen hinter Ubuntu.

(ID:47030780)