Startseite > Embedded > IT-Security noch nicht Embedded

Problem Bot-Netze

IT-Security noch nicht Embedded

11. Dezember 2017, 14:56 Uhr | Von Klaus-Dieter Walter, CEO SSV Software Systems

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Update-Möglichkeiten für IT-Security

Hinzu kommen noch unzählige Smartphones mit sehr geringem Sicherheitsniveau, für die praktisch keine Updates mehr zur Verfügung stehen. Es ist daher davon auszugehen, dass wir bis 2020 noch den ersten Botnet-Angriff durch ein ferngesteuertes Verbundnetz mit zig Millionen einzelnen Embedded-Systemen und Smartphones erleben werden. Die Auswirkungen einer solchen Attacke könnten durch die fortschreitende Digitalisierung sehr dramatisch ausfallen und Folgeschäden verursachen, die sich im Moment noch nicht einmal ansatzweise abschätzen lassen.

Es ist aus technischer Sicht eigentlich unverständlich, warum zum Beispiel die Linux-basierte Firmware eines Telekom-Routers es nicht bemerkt, dass über den Internetzugang eine Veränderung vorgenommen wurde, um eine Botnet-Integration zu ermöglichen. In einem solchen Fall würde eine simple Software-Change-Meldung an einen zentralen Maintenance-Server im Internet ausreichen, um die Manipulation zu identifizieren und die Router-Betreiber zu benachrichtigen. Dafür muss die Firmware des Embedded-Systems im Router lediglich erkennen, dass eine „unbekannte“ Software installiert oder gestartet wurde. Für ein Embedded Linux wäre eine solch einfache Root-of-Trust-Erkennung mit relativ wenig zusätzlichen Codezeilen realisierbar.

Des Weiteren sollten alle Systeme, die eine Netzwerkschnittstelle haben, auch eine zeitgemäße Vor-Ort-Software-Update-Möglichkeit besitzen. Besonders einfach ist ein Update wenn – wie bei einem Router – eine Internetverbindung besteht. In diesem Fall könnten die eingebetteten Mikrorechner von Zeit zu Zeit auf dem Maintenance-Server nach Updates schauen oder sich per Subscribe-Nachricht über ein anstehendes Update benachrichtigen lassen.

Die erfolgreichen Angriffe auf die Embedded-Systeme in Smart-Home-Anwendungen, Telekom-Routern, Überwachungskameras und anderen IoT-Devices machen deutlich, dass „Security-by-Design“-Regeln in diesem Umfeld bisher nahezu unbeachtet bleiben. Die Ursachen dafür sind vielfältig. Teilweise fehlt es an dem erforderlichen Fachwissen und an systembezogenem Denken. Vielfach geht man aber wohl auch davon aus, dass IT-Security ein Anwenderthema sei, zumal die rechtliche Seite sich hier bisher auch noch nicht eindeutig positioniert hat. Sinnvoll wäre auf der Herstellerseite – analog zur Entwicklung der Funktionen und Gerätesicherheit – aber auf jeden Fall der Einsatz professioneller Methoden und Werkzeuge, um die IT-Security eines Produktes zu gewährleisten.

Baugruppen und Systeme mit einem Embedded-Betriebssystem sollten mit Sicherheitserweiterungen ausgestattet sein, die dem jeweiligen Stand der Technik entsprechen. Da dieser Stand der Technik sich laufend verändert, müssen Update-Möglichkeiten vorgesehen werden. Für „kleine“ Embedded-Systeme ohne Betriebssystem muss zumindest eine statische Codeanalyse in der Entwicklung erfolgen, um die Anwendungssicherheit zu gewährleisten. Darüber hinaus ist ein professionelles System-Security-Assessment empfehlenswert. Was nutzt ansonsten die beste Verschlüsselung für die Übertragungswege, wenn der Diebstahl einer digitalen Identität noch nicht einmal bemerkt wird oder ein „geheimer“ Hersteller-Servicezugang mit werksseitig eingestelltem Standardpasswort existiert.