Ein Angebot von

Lösbarer Konflikt – Safety und Security in der Softwareentwicklung

| Autor / Redakteur: Richard Bellairs * / Sebastian Gerstl

Da Safety und Security zum Teil unterschiedliche Regelsätze und Protokolle verwenden, zogen es Softwareentwickler in der Vergangenheit vor, eines der beiden über das andere zu priorisieren – meist zu Lasten der Security. Doch das ist nicht zwingend nötig.
Da Safety und Security zum Teil unterschiedliche Regelsätze und Protokolle verwenden, zogen es Softwareentwickler in der Vergangenheit vor, eines der beiden über das andere zu priorisieren – meist zu Lasten der Security. Doch das ist nicht zwingend nötig. (Bild: gemeinfrei / CC0)

Sicherheit ist mehr als nur ein Wort: Safety und Security bei der Softwareentwicklung unter einen Hut zu bringen kann aufgrund unterschiedlicher Regelsätze eine Herausforderung darstellen. Aber sie kann gemeistert werden.

Mit jeder neuen Entwicklung in der IT rückt die Welt ein Stück näher zusammen. Und je enger die Verknüpfung wird, desto anfälliger wird sie für Angriffe von außen. Das zeigt auch die jüngste Vergangenheit: Industrieunternehmen wurden durch Angriffe auf ihre IT-Infrastruktur in die Knie gezwungen und bisweilen sogar in ihren Grundfesten erschüttert. Unternehmen, die sich sicher – zu sicher – fühlten, wurden eines Besseren belehrt.

Das Englische (wie auch die Informatik) kennt zwei Begriffe für Sicherheit: Safety und Security. Im Deutschen wird die begriffliche Unterscheidung so nicht getroffen. Aus diesem Grund bleibe ich dort, wo es notwendig ist, bei den englischen Bezeichnungen. Lange Zeit lag der Schwerpunkt der Entwicklungsarbeit in Bezug auf Sicherheit bei der Safety der Anwendung. Die Security stand weniger im Fokus, obwohl beide – Safety und Security – unterschiedliche Regelsätze und Protokolle verwenden. Doch manches haben sie auch gemeinsam. Und genau unter diesem Aspekt ist es möglich, beim Erstellen von Code beides in einem ganzheitlichen Ansatz „unter einen Hut“ zu bringen.

Und das ist auch wichtig. Denn die Frage nach Safety und Security stellt sich in jeder Anwendung, besonders aber im sicherheitskritischen Bereich. So ist es mitunter schwer, eine formale Definition dessen zu finden, was sicher (safe) und sicher (secure) bedeuten soll, wenn es um Softwareentwicklung geht.

Es gibt zwar funktionale Sicherheitsstandards wie IEC61508 oder ISO26262. Aber wenn man anerkannte Coding-Standards der Industrie für hochintegrierte Systeme mit denen für sicherheitskritische Software vergleicht, wird einem schnell klar: es gibt viele Gemeinsamkeiten. Und vor allem eine große, gemeinsame Grundlage.

Wer setzt die Grenzen, wenn es um Safety- und Security-Features einer Programmiersprache wie C oder C++ geht? Es ist die Sprache selbst. Aus ihr gehen Styles und Vorgehensweisen hervor, die darauf abzielen, Safety und Security einer Applikation für einen oder mehrere Coding-Standards gleichermaßen zu erhalten.

Das Internet der (un)sicheren Dinge

Das Internet der Dinge (IoT) wird auch in den nächsten Jahren stetig und sehr stark wachsen. Zu verlockend sind die Versprechungen, die es mit sich bringt: Effizienz, Kostensenkung, bessere Zusammenarbeit über miteinander verbundene Endgeräte. Gleichzeitig wachsen aber auch die Bedenken. Denn jede Verbindung kann zum Einfallstor für unerwünschte Angriffe werden – und ist damit ein Sicherheitsrisiko.

Erst kürzlich ist es zwei Forschern gelungen, per Hack die Kontrolle über einen modernen SUV während der Fahrt zu übernehmen und dessen Motor abzustellen. Für Hersteller wie Kunden war das ein weltweiter Weckruf: Eindrucksvoll wurde gezeigt, wie ein eigentlich technologisch fortschrittliches System wie ein modernes High-End-Fahrzeug Ziel einer solchen Attacke werden kann – mit möglicherweise fatalen Folgen. Wie steht es dann wohl um die Sicherheit der vielen Millionen einfachen Endgeräte, die mit wenig Geld entwickelt wurden und die den größten Teil des Internets der Dinge ausmachen?

Bild 1: Zahl der bis 2019 geschätzen IoT-Geräte, aufgeteilt in Marktsegmente.
Bild 1: Zahl der bis 2019 geschätzen IoT-Geräte, aufgeteilt in Marktsegmente. (Bild: Business Insider)

Das Bewusstsein für die Bedrohung der Sicherheit ist da. Was immer noch fehlt, ist die Integration der Security als wesentliches Element in die Softwareentwicklung und die Geschäftsprozesse. Die Bedeutung, die die Safety heute schon hat, muss auch die Security bekommen. Die Security-Schwachstellen zeigen ganz deutlich: es gibt keinen Grund zur Gelassenheit angesichts der Anzahl und des Niveaus der Risiken.

Prozess-Level

Es kostet viel Zeit und erheblichen Aufwand, Prozesse so zu implementieren, die Security und Safety gleichermaßen berücksichtigen. Der dafür notwendige Ansatz muss naturgemäß ganzheitlich sein. Deshalb kann er auch nicht auf einzelne Abteilungen oder Entwicklungsphasen beschränkt werden. Der SUV-Hack, zum Beispiel, hat Mängel und Schwachstellen auf vielen unterschiedlichen Ebenen offengelegt, nicht nur in der Architektur oder der Serviceberechtigung, sondern auch bei den Algorithmen für die Passwort-Generierung und vielen anderen Bereichen. Wer seine Produktentwicklung auf wirklich sichere Beine stellen will, muss auf allen Ebenen Verfahren integrieren, die Security und Safety gleichermaßen stärken

Was aber passiert, wenn man den Fokus nur auf die Softwareentwicklung legt? Oder besser: Welche Wahl hat ein Entwickler, wenn er eine sicherheitskritische Anwendung entwickeln soll, die gleichzeitig alle notwendigen Security-Anforderungen erfüllt? Gehen wir einmal davon aus, dass sowohl in der Anforderungs-, als auch in der Designphase alles dafür Notwendige bereits umgesetzt wird, sollten wir uns Gedanken darüber machen, wie wir das in effiziente, hochintegrierte Software übertragen, die alle Security-Anforderungen erfüllt.

Der sicherheitskritische Ansatz

Für die funktionale Sicherheit gibt es zwei Referenzstandards: IEC61508 und davon abgeleitete Standards; DO178B/C und Begleitdokumente wie DO330.

IEC61508 bezieht sich auf die funktionale Sicherheit von sicherheitsrelevanten Systemen im Bereich Elektrik, Elektronik oder programmierbarer Elektronik (EEPE). Da der Standard bei allen sicherheitsrelevanten Systemen mit EEPE-Endgeräten angewendet wird, ist sein Umfang ziemlich breit. Fast alle großen sicherheitsrelevanten Industriestandards, die nicht mit der Luft- und Raumfahrttechnik verbunden sind, wurden von IEC61508 abgeleitet.

DO178C und die dazugehörigen Begleitdokumente DO330, DO331, DO332 und DO333 bilden den Standard für Applikationen der Luft- und Raumfahrttechnik (Avionik). Wer auch immer ein FAA-Zertifikat für ein kommerzielles Avionik-Projekt haben möchte, muss diesen Standard erfüllen.

DO178C bezieht sich viel mehr auf die Software als IEC61508; der Grad der Software-Security (IDAL – item development assurance level) ist bestimmt durch eine Sicherheitsbewertung und Risikoanalyse. Es gibt fünf Grade: von A (katastrophal) bis E (kein Effekt).

Wenn es um sicherheitskritische Anwendungen geht, ist klar definiert, was unter „kritischem Code“ zu verstehen ist. Es gibt standardisierte Methoden, um ihn zu qualifizieren. Wie der Entwicklungsprozess gestaltet werden muss, darüber gibt es klare Anweisungen. Safety integrity levels (SIL) in IEC61508, Automotive SIL (ASIL) in ISO26262, Software SIL (SSIL) in EN50128 oder IDAL in DO178C sind Beispiele für das gleiche Konzept. Dabei spielen Quantität und Qualität gleichermaßen eine Rolle: Wie stark verringert sich das Risiko für eine Funktion entsprechend der Risiko-Analyse? Und welche Aktionen werden unternommen, um sicherzustellen, dass der Qualitätslevel erreicht wird?

Nahezu alle in der Industrie anerkannten funktionalen Sicherheitsstandards schreiben vor, dass bestimmte Design- und Coding-Standards – abhängig vom jeweiligen SIL – übernommen werden. Einer der wichtigsten ist MISRA – selbst in Bereichen, wo er nicht zwingend vorgeschrieben ist. ISO26262-6 bestätigt für die Programmiersprache C, dass MISRA C viele Methoden abdeckt, die für das Design von Software-Units und deren Implementierung gefordert werden. Und das seine Verbreitung in alle wesentlichen sicherheitskritischen Softwarebereiche reicht, zum Beispiel im Maschinenbau, in der Medizintechnik, in der Kernkraft oder im Schienenverkehr.

Ganz ähnlich ist es bei DO178B/C. Diese Standards fordern eine sorgfältige Definition und Dokumentation des Softwareentwicklungsprozesses. Das Basis-Set aus geforderter Dokumentation und während der Laufzeit erstellten Artefakte beinhaltet umfangreiche und detaillierte Planungen – und ein Coding-Standard gehört mit dazu.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

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.
Kommentar abschicken
copyright

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