Deterministische Cybersicherheit Zwei Methoden – ein Erfolg

Das Thema der Cybersicherheit gewinnt gerade beim Absichern von Embedded-Systemen zunehmend an Bedeutung.
Das Thema der Cybersicherheit gewinnt gerade beim Absichern von Embedded-Systemen zunehmend an Bedeutung.

Beim Absichern von Embedded-Systemen muss der Entwickler verschiedene Hindernisse überwinden. Um zum Erfolg zu gelangen, hat er mehrere Möglichkeiten zur Auswahl. Doch nur zwei führen zum Erfolg.

Beim Thema »Cybersicherheit« befinden sich die Hersteller von Fahrzeugen und industrieller Fertigungstechnik in einer schwierigen Ausgangslage. Viele eingebettete Systeme im Automobil und in der Automation sind deterministische, geschlossene Systeme (Contained Systems), die vom Benutzer nicht veränderbar sind. Ähnlich wie bei Fahrzeugen schreitet das Vernetzen industrieller Systeme immer stärker voran. Viele Unternehmen verbinden ihre Controller mit dem Unternehmensnetzwerk, manchmal sogar direkt mit der Cloud. Hiermit setzen sie ihre Systeme mehreren neuen Angriffsvektoren aus und zwar in einer für beide Branchen unbekannten Größenordnung. Hinzu kommen einige organisatorische Besonderheiten, die beide Bereiche teilen. Sie sind kostengetrieben, arbeiten mit geringen Bandbreiten und: In beiden finden sich Insellösungen.

Die Anfälligkeit eingebetteter Systeme hat neben der steigenden Vernetzung und damit einhergehender externer Einfallstore eine weitere Ursache: den kleinteiligen Software-Entwicklungsprozess. Ein Embedded-System ist hochkomplex und besteht in der Regel aus Millionen von Code-Zeilen, die von vielen Entwicklern zu erstellen und über eine komplexe Lieferkette bereitzustellen sind. Fehler (Bugs) im Code lassen sich in dem langwierigen Entwicklungsprozess nicht vermeiden, für Cyberkriminelle sind sie jedoch ein willkommenes Einfallstor in hochsensible Fertigungsanlagen.

Mit zunehmender Komplexität der Systeme steigen die formalen Anforderungen. So müssen sowohl vernetzte Fahrzeuge als auch Fertigungsanlagen den Normen der funktionalen Sicherheit (FuSi) entsprechen. Die Cybersicherheit (Security) muss – mit zunehmender Vernetzung – Teil einer funktionalen Sicherheit sein und ist in das interne Entwicklungsprogramm zu integrieren (Bild 1). Ohne eine angemessene Sicherheit bleiben die entworfenen Mechanismen unter Umständen wirkungslos, und der Zustand verletzt die strengen FuSi-Anforderungen. Lediglich ein sehr spezifischer und proaktiver Security-Ansatz kann die Anforderungen erfüllen.

Sichern eines eingebetteten Systems

Neben den hohen gesetzlichen Standards gibt es zusätzliche organisatorische Anforderungen an eine proaktive Cyberabwehr, den Betrieb nicht einzuschränken. Folgende Hindernisse sind dabei zu überwinden:

A. Betriebs- oder Produktionsunterbrechungen aufgrund von Verzögerungen beim Beheben von Problemen ausschließen (die Anwendung muss schnell arbeiten).
B. Zero-Day- und Day-One-Angriffe verhindern (Schutz vor bekannten und unbekannten Angriffen).
C. Fehlalarme, sogenannte „False Positives“, eliminieren (die Prävention muss unabdingbar sein und das Erkennen darf keinen großen Overhead verursachen).
D. Die Leistung nicht beeinträchtigen (die Anwendung darf das Echtzeit- oder Laufzeitverhalten des Systems nicht herabsetzen).

A. »Sanierungsverzögerungen« ausschließen

Wenn Hacker Schwachstellen ausnutzen, verursachen sie für den Kunden eine Betriebsunterbrechung. Im schlimmsten Fall führt der Vorfall zum Stillstand. Laut einer Studie des Ponemon-Institutes im Auftrag von IBM kostet eine solche Betriebsunterbrechung durchschnittlich 3,86 Millionen US-Dollar. Der Begriff Sanierungsverzögerung bezieht sich auf das Zeitfenster, in dem ein Sicherheitsverstoß oder eine Sicherheitslücke zu identifizieren und zu beheben ist. Für Hacker ist diese Zeit sehr wertvoll. Sie können das Zeitfenster nutzen und Angriffe starten, die die gleiche Schwachstelle auf weltweit eingesetzten, nicht gepatchten Geräten ausnutzen. Eine Vielzahl von Angriffen in dem Zeitraum kann zu erheblichen Schäden für die Endnutzer führen und den Ruf des jeweiligen Systemanbieters schädigen.

B. Zero-Day- und Day-One-Angriffe verhindern

Um die Folgen der Verzögerung bei der Fehlerbehebung zu vermeiden, ist es wichtig, Exploits von unbekannten oder bekannten (aber nicht gepatchten) Angriffen zu verhindern. Unbekannte Angriffe werden auch als Zero-Day-Angriffe und bekannte Angriffe als Day-One-Angriffe bezeichnet. Exploits sind Schadprogramme, die Sicherheitslücken in Programmen ausnutzen. Im IT-Bereich beinhalten gängige Schutzstrategien für Zero-Day-Angriffe statistische Heuristiken (prädikative Algorithmen) oder Signaturen, die zum Einsatz kommen, um Malware zu identifizieren.

Die Schwierigkeit beim Verwenden der Technik zum Bekämpfen von Zero-Day- und Day-One-Attacken sind Fehlalarme (False Negatives und False Positives). Der Grund ist, dass sie heuristische Security-Anwendungen und das Blockieren unbekannter Malware häufig nicht erkennen. Sie sind effektiver, wenn sie in Kombination zum Einsatz kommen. Aufgrund ihrer Fehlerquote können sie jedoch neue Angriffe nicht immer identifizieren.

Darüber hinaus sind Zero-Day-Schutztechniken für Unternehmen rechenintensiv. Sie benötigen starke Server oder Serverfarmen für Quarantäne-, Sandboxing- und Analyseprozesse. Die Techniken stehen im Widerspruch zu den Anforderungen an Netzwerke und Anwendungen mit niedriger Latenz und hoher Bandbreite. Aufgrund begrenzter CPU- und Speicherkapazitäten sind sie auf vielen Embedded-Systemen nicht ausführbar.

C. False Positives eliminieren

In sicherheitskritischen Systemen, wie sie in vernetzten Fahrzeugen oder in der Fertigungsindustrie verkommen, sind Fehlalarme nicht zu tolerieren. Mögliche Folgen eines versehentlichen Annullierens der legitimen Übertragung können sehr ernst sein. Eine heuristische Security-Anwendung, die Signaturdateien mit einer ständig aktualisierten Datenbank abgleicht, erzeugt Fehlalarme (False Positives). Obwohl sich die Heuristiken und Techniken zur Signatur-Identifizierung stetig verbessern, lassen sich False Positives in heuristischen Modellen nicht vermeiden. Das ist ein inakzeptables Szenario für jedes System, das nach Safety-Standards funktioniert. Außerdem gibt es ein »falsch-positives Paradoxon«. So kann die Wahrscheinlichkeit eines Fehlalarms größer sein als die einer echten Bedrohung.

D. Leistungsreduzierung vermeiden

Bei den I/O- und Rechenanforderungen von geschlossenen Systemen ist die Leistungsaufnahme immer ein wichtiger Aspekt. Es ist nötig, die Rechen- und RAM-Anforderungen (Random Access Memory) zu bestimmen, um zu verstehen, wie stark die Security-Anwendung die CPU, die I/O-Verbindung und den Speicher des Geräts belastet. Ein erheblicher Overhead kann dazu führen, dass zusätzliche Hardware nötig wird, um die Leistungsanforderungen zu erfüllen, was die Security-Anwendung sehr teuer oder sogar unmöglich macht.