The Autonomous

Erste Präsentation

Im ersten Vortrag gab Nils Abeling von secunet einen Überblick darüber, wie man mit Hilfe einer Public-Key-Infrastruktur (PKI) Vertrauen zwischen den Teilnehmern eines Netzwerks aufbauen und verwalten kann. Die Idee hinter diesem Konzept ist, dass es eine Hierarchie von Instanzen gibt, die Zertifikate für wichtige Teilnehmer im Netz ausstellen. Diese Zertifikate enthalten den öffentlichen Schlüssel (Public Key) eines öffentlich-privaten Schlüsselpaares und können für kryptographische Funktionen wie Signieren und Überprüfen, Ver- und Entschlüsseln und das Austauschen symmetrischer Schlüssel (Schlüsselaustauschalgorithmen) verwendet werden. Damit schließt das Zertifikat die verbleibende Lücke in einem Vertrauensnetz, indem es sicherstellt, dass der Beziehung zwischen einer Entität (d. h. einer Person oder einem Gerät) und einem öffentlichen Schlüssel vertraut werden kann. Nachdem ein Zertifikat in einem genau definierten Verfahren von einer übergeordneten Instanz ausgestellt wurde, durchläuft es einen Lebenszyklus, der von der Veröffentlichung über eine öffentliche Listung bis zum Ablauf der Gültigkeitsdauer reicht. Die Registrierung und der Widerruf von Zertifikaten können von speziellen Komponenten der PKI verwaltet werden.

Betont wurde, dass die Spezifikation des PKI-Systems, d. h. die technischen Details und Algorithmen, alleine nicht ausreichen, um das Vertrauen in den Betrieb des Netzes zu gewährleisten. Ebenso wichtig sei es, dass die Anforderungen und Prozesse für den Betrieb in der Certificate Policy (CP) und im Certification Practice Statement (CPS) genau definiert werden. Die CP macht allgemeine Anforderungen z. B. über Rechte und Rollen oder Schlüsselerneuerungsverfahren öffentlich, so dass jeder Benutzer das Sicherheitsniveau der PKI einschätzen kann. Das CPS dokumentiert dagegen detailliert, wie die Anforderungen des CP erfüllt werden, und bleibt daher im Allgemeinen unter Verschluss. Abschließend unterstrich Nils Abeling, wie wichtig es ist, die Anwendungsfälle, die Umgebung und die Technologie des Netzes zu verstehen, bevor eine PKI definiert werden kann. Nur so kann designseitig eine hohe Cybersicherheit erreicht werden.

Zweite Präsentation

Wenn die Grundstruktur eines Kommunikationsnetzes verstanden und durch eine PKI definiert ist, bleibt noch die Bewertung der Cybersicherheit auf technischer Ebene. Im zweiten Vortrag stellte Dr. Jörg Schepers von Infineon vor, wie verschiedene Angriffsvektoren auf unterschiedlichen Ebenen der Software und Hardware unterschiedliche Gegenmaßnahmen erfordern.

Da die Angriffe von High-Level-Angriffen auf die Software bis hin zur Dekonstruktion einer Hardware reichen, ist es notwendig, die Sicherheit für jede Anwendung von Anfang an sowohl in der Hardware als auch in der Software zu verankern. Beispiele hierfür sind mehrere parallele Kanäle auf Cybersicherheitssatelliten (Cyber Security Satellites, CSS) und Echtzeitmodulen, die so gehärtet sind, dass sie als vertrauenswürdige sichere Hardwareumgebung fungieren. Zu beachten ist, dass nicht für jedes einzelne Gerät ein Höchstmaß an Sicherheit implementiert werden muss. Dies ist nicht nur durch die Leistungsgrenzen bedingt, sondern auch durch die hohen Produktionskosten. Eingebettete Hardwaresicherheit kann eine solide Grundlage für eine ausgewogene Sicherheitsarchitektur mit angemessenen Sicherheitsniveaus für jedes Gerät bilden. Dies muss dann mit geeigneten Sicherheitsmaßnahmen in der Software abgestimmt werden, z. B. für sichere Over-the-air-Softwareupdates.

Dritte Präsentation

Im dritten Vortrag des Workshops erläuterte Nico Vinzenz von ZF, wie die Soft- und Hardware nicht nur vor der Produktion, sondern während der gesamten Lebensdauer im Feld geprüft und validiert werden kann. 

Das technische Verfahren folgt in der Regel dem V-Modell und beginnt mit einer Bedrohungsanalyse und Risikobewertung (TARA). Nachdem das Requirements Engineering abgeschlossen ist, wird ein gründlicher Prüfplan festgelegt, um nach Schwachstellen in der Cybersicherheit zu suchen. Dies reicht von Funktionstests und Schwachstellenscans bis hin zu Penetrationstests. Die grundsätzliche Herausforderung besteht darin, dass das beabsichtigte Verhalten einer Funktion oder eines Teils einer Software nicht immer dem implementierten Verhalten entspricht. Zudem ist es wesentlich einfacher, die planmäßige Ausführung einer Funktion mit positiven Testfällen zu prüfen („Testen gegen das ‚Bekannte‘“), als ein unerwünschtes Verhalten zu erkennen, das von Angreifern ausgenutzt werden könnte („Testen gegen das ‚Unbekannte‘“). Ein wichtiges Hilfsmittel zur Bewältigung dieses Problems ist Fuzz-Testing, bei dem bösartige oder künstlich generierte Eingangsdaten an die Software geschickt werden. Durch die gleichzeitige Überwachung der Ausgangsdaten entsteht so eine Rückkopplungsschleife. Dieses Verfahren kann durch die Berücksichtigung von Teilen des Quelltextes weiter verfeinert werden. Die Ergebnisse des Fuzz-Testings können dazu dienen, die ursprüngliche Bedrohungsanalyse oder andere Aspekte der Prüfstrategie zu verbessern. Dadurch wird der Werkzeugkasten eines jeden Testers durch eine hochleistungsfähige Methode ergänzt.