Systemsicherheit: ein paar Thesen zu sicheren Kommunikationsleitungen & Updates

 

Während Dinge wie TPM und ein sicherer/vertrauenswürdiger Boot gut sind, um das zu sichern, was sich „in der Box“ befindet, kann es auch hilfreich sein, ein System vor physischen Angriffen zu schützen. Angriffsszenarien in der industriellen Umgebung stellen sich jedoch oft ganz anders dar. 

 

In den meisten Fällen gibt es keinen öffentlichen Zugang zu den Systemen, und selbst wenn dies der Fall sein sollte, werden die Systeme in einer Art Schaltschrank oder Gehäuse weggeschlossen. Weitaus problematischer ist aber, dass zunehmend Systeme, die noch nie zuvor verbunden waren, vernetzt werden. Dies kann sie allen möglichen potentiellen Bedrohungen aussetzen, die über eine Ethernet-Schnittstelle eindringen können. Egal ob es sich um ein traditionelles LAN-Kabel oder WIFI oder G5 handelt – über die Verbindung dringen die meisten Bedrohungen ein.

 

Wenn also Embedded Industries für grundlegende Sicherheit sorgen wollen: Solange es sich nicht um ein Verbrauchergerät handelt, sollten sie anfangen, ein individuelles Zertifikat pro Gerät zu verwenden (das vielleicht nur auf dem internen Laufwerk gespeichert ist), anstatt einfach einen zusätzlichen Mechanismus zur Sicherung des Boot-Prozesses hinzuzufügen. Verstehen Sie mich nicht falsch, ein sicherer Schlüsselspeicher ist ein wichtiges Werkzeug aber es gibt noch andere wichtige Aspekte.

 

Wie KontronOS den Updateprozess vereinfacht

Genauer: Für die meisten Anwendungsfälle ist es wichtiger, dass die Kommunikationsleitung zum Server gesichert ist, als dass der Schlüssel, der zur Verschlüsselung verwendet wird, an einem sicheren Ort gespeichert wird. Sicherlich könnte jemand das Gerät knacken und den Schlüssel aus dem internen Laufwerk extrahieren, aber Embedded Systeme sind normalerweise nicht so einfach zugänglich, so dass dies nicht der vorrangige Angriffsvektor ist, den man im ersten Schritt ausschalten muss.

 

Und ja, wir haben alle von Microsoft gelernt (vielen Dank), dass Updates ein wichtiger Mechanismus sind, um Bedrohungen zu verhindern. Im industriellen Umfeld brauchen wir sie also auch, aber der Fokus ist etwas anders:

 

  • Nutzer wollen keine Updates, sie wollen nur, dass ihr System sicher läuft.
  • Industrierechner werden wie eine Tischleuchte ein- und ausgeschaltet, niemand wartet auf ein Herunterfahren, bis etwas geupdated wird.
  • Alle Geräte im Portfolio sollten sich gleich verhalten
  • Sie sollten eine Laufzeit von 15-20 Jahren haben.
  • Die meisten Geräte sind sehr kundenspezifisch und können kein standardisiertes Betriebssystem verwenden

 

Bei Kontron Technologies gehen wir dies mit unserem KontronOS an. Für unsere Kunden schneiden wir dafür ein robustes Yocto-Betriebssystem auf die speziell benötigte HW und Software zu. Yocto ist hier ein wichtiger Faktor, weil es uns erlaubt, alle nötigen Prozesse zu kontrollieren und zu patchen. Für stetige Aktualisierungen haben wir einen atomic Updateprozess implementiert. Vor einem Roll-Out überprüfen wir, dass alle Geräte auf dem gleichen Update-Level sind. Leider sehe ich oft das Gegenteil, wenn Standard-Linux-Distributionen verwendet werden. Das funktioniert, beim POC oder mit einem Produkt mit geringem Volumen, aber wenn es um mehrere hundert Geräte pro Jahr oder mehr geht, sollten Sie einen anderen Ansatz in Betracht ziehen.

 

Natürlich haben wir auch einen Fallback-Mechanismus integriert, so dass das System oder der Betreiber immer auf die letzte funktionierende Version zurückschalten kann und so Ausfallzeiten verhindert werden.

 

Geräteindividualisierung für Mischkulturen

Dies ist im Kern unser KontronOS-Angebot, aber natürlich ist jeder Kunde anders - er benötigt Updates zu unterschiedlichen Zeitplänen, Bedrohungsszenarien und Exposition und will natürlich selbst bestimmen, wann ein Update ausgerollt werden soll – hier nehmen wir in der Regel 10-20%ige kundenspezifische Anpassung vor.

 

Zusammenfassend kann man also sagen: Wenn Sie viele Steuergeräte in einem Bereich sichern wollen, z.B. vernetzte Kaffeeautomaten, haben Sie ein gutes Szenario für eine Monokultur, bei der alle Geräte genau die gleiche Software und Programme installiert haben. Wenn Sie Ihre Geräte mit unterschiedlichen Programmpaketen ausstatten und diese von einem zentralen Backend aus verwalten wollen, brauchen Sie einen anderen Ansatz. Deshalb bieten wir zusätzlich eine Geräteindividualisierung an, die berücksichtigt, welche Programme auf welcher Maschine laufen. Dafür brauchen wir natürlich ein größeres Backend, um die Distribution zu steuern, das möchte ich aber in meinem nächsten Blog erklären.

 

Möchten Sie sich weiter über unsere Sicherheitslösungen Informieren? Dan besuchen Sie uns auf https://www.kontron.com/products/solutions/security

Herzlichen Dank!

Ihr Kommentar wurde übermittelt.

Es ist ein Fehler beim Anmelden aufgetreten!:
{{cCtrl.addCommentSubscribeErrorMsg}}

{{comment.name}}
{{comment.date.format('MMMM DD, YYYY')}}

{{comment.comment}}

Bisher gibt es noch keine Kommentare.
Kontakt Sales 1-888-294-4558 / 858-623-3094 Sales kontaktieren Support 888-835-6676 / +1 450-437-5682 Support kontaktieren
Kontaktmöglichkeiten