Security für das Internet der Dinge Sichere Systeme entwickeln

Dass Sicherheit von Anfang an in einem Systemdesign berücksichtigt werden muss, darüber sind sich alle einig. Aber wie geht man vor? Für funktionale Sicherheit gibt es etablierte Standards und Prozesse. Bei der IT-Sicherheit entwickeln sich diese Dinge gerade erst. Ein Statusbericht.

Damit Systeme sicher im IoT kommunizieren und agieren können, sollten schon bei ihrer Entwicklung folgende Faktoren berücksichtigt werden:

  • Derzeit als sicher eingestufte Komponenten und Verfahren zur Entwicklung von Systemen benutzen.
  • Die Hersteller dieser Komponenten auf ihre Zuverlässigkeit hin überprüfen. Hardware-Unterstützung bei der Absicherung von Kommunikation nutzen.
  • Sich über neue Forschungen und deren Ergebnisse in Bezug auf Security auf dem Laufenden halten.

Neue Angriffszenarien

Im Internet der Dinge (Internet of Things, IoT) treten immer mehr Objekte und Systeme miteinander in Verbindung, sei es, um Daten auszutauschen oder um miteinander zu kommunizieren – oft ohne dass der Mensch daran beteiligt ist. Durch die Verbindung ins IoT, zumeist über Drahtlos-Verbindungen realisiert, ergeben sich neue Angriffsszenarien und Sicherheitsanforderungen. Die Systemdaten müssen gegen Abhören und Veränderung gesichert werden. Dazu werden Signatur- und Verschlüsselungsverfahren angewendet und die Kommunikation darf nur mit authentifizierten Partnern erfolgen.

Wenn nachfolgend von Systemen im IoT gesprochen wird, dann sind eingebettete Systeme gemeint. Eingebettete Systeme enthalten einen elektronischen Rechner, der in einen technischen Kontext eingebunden ist und Überwachungs-, Steuerungs- und Regelungsfunktion übernimmt oder für Daten- und Signalverarbeitung zuständig ist. Durch die Vernetzung von vielen in sich autonomen, eingebetteten Systemen erhält man komplexe Gesamtsysteme. In der Vergangenheit bedeutete Sicherheit bei Systemen meist nur ihre Funktionssicherheit (engl. Safety). Systeme dürfen nicht ausfallen und damit zu einer Gefahr für ihre Umwelt werden. Heute, im Zeitalter des IoT, sind immer mehr Systeme miteinander vernetzt und tauschen Daten untereinander aus. Diese Daten und Informationen gilt es zu schützen, was bedeutet, dass man zusätzlich Sicherheit im Sinne von Daten- und Informationssicherheit braucht. Diese Art von Sicherheit nennt man im Englischen Security. Systeme müssen gegen Angriffe von außen geschützt werden. Dies ist bei vielen ehedem autonomen Systemen noch nicht der Fall.

Ein Beispiel für ein komplexes System, das abgesichert werden muss, ist das Auto. Es besteht aus vielen einzelnen Komponenten mechanischer Art, die von elektronischen Steuergeräten, den ECUs (Electronical Control Unit) gesteuert werden. Diese Steuerelemente sind seit langer Zeit ohne Berücksichtigung der Security untereinander vernetzt. In jüngerer Zeit hinzugekommen sind Infotainment-Komponenten, die ebenfalls mit der Außenwelt kommunizieren, z.B. Navigations- und moderne Unterhaltungssysteme. Um solch ein kompliziertes System wie das Auto im Sinne von Security sicher zu machen, muss schon bei der Entwicklung der Bauteile, wie der Mikrocontroller, die Security berücksichtigt und quasi mit eingebaut werden (Built-in Security).

Was macht ein System im Sinne von Security sicher?

Bei Systemen, die ins IoT eingebunden werden, gilt es vor allem, die Schnittstellen abzusichern, die durch Software realisiert werden. Schon beim Entwurf und der Entwicklung eines Systems und seiner Software muss die Security berücksichtigt werden, wie auch später während seines gesamten Lifecycle. Bisher gibt es noch keine geeigneten Normen, die die Security umfassend berücksichtigen. So wird bei ISO 26262 [1] im Bereich Automotive nur die Safe­ty der Produkte inklusive Software betrachtet. Es lässt sich jedoch anhand des darin gezeigten V-Modells für die Software-Entwicklung unter Safety-Aspekten eine analoge Vorgehensweise auch für die Security-Aspekte konzipieren. 

Das V-Modell ist ein Vorgehensmodell in der Software-Entwicklung, bei dem der Software-Entwicklungsprozess in Phasen organisiert wird (Bild 1). So sollte am Anfang neben der Gefährdungs- und Risikoanalyse aus dem Safe­ty-Prozess, welche die bei einem unerwünschten Systemverhalten entstehenden Gefährdungen und Risiken analysiert, auch eine Bedrohungsanalyse (Bild 1 (1)) stehen, die die Angriffsmöglichkeiten auf das System von außen ermittelt. Der Systementwurf muss ein Security-Konzept (Bild 1 (2)) enthalten. Während der anschließenden Analyse der Software Requirements sollten die Security-Ziele (Bild 1 (3)) erfasst werden, aus denen im nächsten Schritt die Security-Architektur (Bild 1 (4)) erstellt wird. Bei der Implementierung der System-Software müssen Security-Richtlinien (Bild 1 (5)) befolgt werden, die nach neuesten Erkenntnissen Schutz vor Sicherheitslücken im Programmcode bieten. Ebenso helfen Code Reviews (Bild 1 (5)) bei der Aufdeckung von Schwächen in der Programmierung wie z.B. Buffer Overflows. Nach der Fertigstellung von Software-Modulen erfolgt zunächst ihr Funktionstest, der auch Security-Funktionen (Bild 1 (6)) prüft, beispielsweise anhand von Test Frameworks für Eingabevalidierung und Ausgabekodierung. Bei der Verifikation der Requirements wird das Erreichen der Security-Ziele ebenso verifiziert (Bild 1 (7)). Die Systemintegration schließlich enthält Tests für die Security-Integration (Bild 1 (8)). Geeignete Tests sind z.B. Penetrationstests. Dabei wird das System mit Mitteln und Methoden eines möglichen Angreifers auf seine Sicherheit gegen unerwünschtes Eindringen getestet.

Sind zugekaufte Komponenten sicher?

Da es in vielen Fällen nicht möglich ist, alle Komponenten eines Systems selbst zu entwickeln, sollte man beim Einkauf fremder Systemteile auf deren Qualität in Bezug auf die Security achten. Für sichere IT-Komponenten gibt es eine Reihe von Sicherheitsstandards, allen voran die vom BSI (Bundesamt für Sicherheit in der Informationstechnik) empfohlenen Common Criteria (ISO/IEC 15408) [2]. Die Common Criteria for Information Technology Security Evaluation, kurz CC, enthalten international anerkannte Kriterien zur Prüfung und Bewertung der Sicherheit (insbes. Security) von IT-Produkten. Sie sind anwendbar für Software wie z.B. Betriebssysteme, Datenbanken oder Firewalls sowie für Hardware wie z.B. Smart Controller, Gesundheitskarten oder Chipkartenleser.

Die Common Criteria bestehen aus drei Teilen: Teil 1 erläutert die Grundlagen sowie Schutzprofile (Protection Profiles) und Sicherheitsvorgaben (Security Targets) für den zu prüfenden Gegenstand. Teil 2 enthält die funktionalen Sicherheitsanforderungen und Teil 3 die Anforderungen an die Vertrauenswürdigkeit und listet die damit verbundenen Anforderungen an den Prüfaufwand, die Prüftiefe und die Prüfgenauigkeit auf. Je höher die Prüfstufe, desto intensiver ist auch die Prüfung. Common Criteria bieten sieben Prüfstufen (Evaluation Assurance Level = EAL) an, von denen am häufigsten die Stufen EAL2 bis EAL5 verwendet werden (Bild 2). Den Nutzen, den der Benutzer von einem nach CC zertifizierten Produkt hat, sind Transparenz in Bezug auf die Sicherheitsfunktion gegen Bedrohungen, Vertrauenswürdigkeit in den gesamten Entwicklungsprozess und Dokumentation der sachgemäßen Anwendung des Produkts.