{"id":7908,"date":"2025-11-29T07:53:17","date_gmt":"2025-11-29T06:53:17","guid":{"rendered":"https:\/\/web-dev-weissblau.de\/microconsult\/?p=7908"},"modified":"2026-02-13T09:03:59","modified_gmt":"2026-02-13T08:03:59","slug":"security-certification-in-the-iot-context","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/security-zertifizierung-im-iot-kontext\/","title":{"rendered":"Security certification in the IoT context"},"content":{"rendered":"

Effiziente Evaluierung durch komponentenbasiertes Software-Design<\/h2>\n

Autor: Sergey Tverdyshev, SYSGO AG
\n<\/strong><\/p>\n

Beitrag – Embedded Software Engineering Kongress 2017<\/h3>\n

Im Internet der Dinge wird die klassische IT-Sicherheit immer mehr auf eingebettete Komponenten ausgeweitet. Charakteristisch f\u00fcr die Sicherheitsanforderungen vieler IoT-Systeme ist, dass Integrit\u00e4t und Verf\u00fcgbarkeit in st\u00e4rkerem Fokus stehen. Dies schl\u00e4gt sich auch in Zertifizierungsstandards nieder: Die klassischen Common Criteria for Information Technology Security (ISO 14508) werden durch dom\u00e4nenspezifische Sicherheitsstandards erg\u00e4nzt, wie z.B. IEC 62443 f\u00fcr Industrial Control Systems, EDSA (Embedded Device Security Analysis) oder J3061 im Automobilbereich, die von einem starken Fokus von „Security for Safety“ gepr\u00e4gt sind.<\/strong><\/p>\n

Der Erfolg von IoT-Ans\u00e4tzen liegt darin, dass mit Hilfe von offenen Standards und offenen Protokollen eingebettete COTS-Komponenten vergleichsweise lose verkn\u00fcpft werden. Diese Modularit\u00e4t spiegelt sich auch in den Zertifizierungsstandards wider. Wir zeigen auf, wo und wie ein Komponenten-basiertes Softwaredesign es signifikant erleichtert, Zertifizierungsanforderungen zu gen\u00fcgen.<\/p>\n

Inh\u00e4rente Modularit\u00e4t von IoT<\/h2>\n

Das Internet der Dinge (Internet of Things, IoT, [1]) ist extrem heterogen, sehr dynamisch, immer verf\u00fcgbar und damit jederzeit angreifbar. Das IoT besteht aus IoT-Komponenten als modulare Bausteinen.<\/p>\n

Sicherheit ist in der Regel modular<\/h2>\n

Abbildung 1 (siehe\u00a0PDF<\/a>) zeigt das Sicherheitsmodell nach Teil 1 der CC (Abschnitt 7.1), das ebenfalls von IEC 62443-1-1 (Abschnitt 5.1) explizit aufgegriffen wird.<\/p>\n

Abbildung 1 stellt\u00a0alle<\/em>\u00a0Assets, Bedrohungen und Gegenma\u00dfnahmen als jeweils eine Box dar. Bei\u00a0genauerer<\/em>\u00a0Betrachtung sieht unserer Erfahrung nach das Bild hingegen oft eher aus wie in Abbildung 2 (siehe\u00a0PDF<\/a>).<\/p>\n

Tabelle 1 gibt ein Beispiel f\u00fcr eine denkbare Belegung:<\/p>\n\n\n\n\n\n
Nummer\/Farbe<\/td>\nAsset<\/td>\nBedrohung<\/td>\nGegenma\u00dfnahme<\/td>\n<\/tr>\n
1\/rot<\/td>\nMotorsteuerung<\/td>\nVerz\u00f6gerung in Hinderniserkennung\u00a0 \u2192 Personenschaden<\/td>\nEchtzeitgarantien, Separierung<\/td>\n<\/tr>\n
2\/gr\u00fcn<\/td>\nPerformancelogger<\/td>\nVerlust von Operational History<\/td>\nPasswort in der Webschnittstelle<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Tabelle 1: Belegung von Abbildung 2 (siehe\u00a0PDF<\/a>) mit zwei konkreten Assets<\/em><\/p>\n

Im Beispiel von Tabelle 1 sind die Assets und ihre Bedrohungen von sehr unterschiedlicher Kritikalit\u00e4t. Anhand der konkreten Belegung von Abbildung 2 (siehe\u00a0PDF<\/a>) wird auch klar, dass eine\u00a0weitere<\/em>\u00a0Bedrohung darin besteht, dass der Angreifer versucht, die Gegenma\u00dfnahmen zu umgehen (will try to bypass), z.B. k\u00f6nnte ein Ethernet-Zugriff auf den Performancelogger dazu missbraucht werden, auch die Motorsteuerung anzugreifen. Ein Mittel, um komplexe IT-Systeme und insbesondere IoT-Komponenten unterschiedlicher Kritikalit\u00e4t auf einer angemessenen Abstraktionsebene zu beherrschen, ist die Aufteilung in Sicherheitdom\u00e4nen („Teile und herrsche“). Eine Sicherheitsdom\u00e4ne ist eine Zone, in der alle Objekte derselben Sicherheitspolitik unterliegen [8]. Die Grenzen von Sicherheitsdom\u00e4nen werden auch „trust boundaries“ genannt.<\/p>\n

„Teile und herrsche“ (TuH) in der Common-Criteria-Zertifizierung (z.B. security domains, domain separation)<\/h2>\n

Bei der Common Criteria for Information Technology Security Evaluation (CC) arbeitet ein Hersteller zusammen mit einer Pr\u00fcfstelle an der Evaluierung eines vom Hersteller vorgeschlagenen IT-Produktes. Das Produkt kann aus Software oder Software und Hardware bestehen, IoT-Komponenten sind also ausdr\u00fccklich enthalten. Ist die Evaluierung erfolgreich, so erteilt die Zertifizierungsstelle, in Deutschland das BSI (Bundesamt f\u00fcr Informationstechnik), ein Zertifikat.<\/p>\n

Die Common Criteria fordern vom Entwickler als zentralen Bestandteil der der Pr\u00fcfstelle vorzulegenden Dokumentation eine Designdokumentation, in der je nach angestrebter Evaluierungsstufe eine ein- oder zweistufige Unterteilung in Subsysteme (einstufig) oder Subsysteme und Module (zweistufig) vorgenommen werden muss. Die Eigenschaften von Subsystemen und Modulen und ihre Interaktionen m\u00fcssen beschrieben werden. Die Designdokumentation beschreibt auch, inwiefern die Schnittstellen von Subsystemen und Modulen f\u00fcr den Angreifer direkt oder indirekt zug\u00e4nglich sind.<\/p>\n

Eine Sicherheitsarchitektur ist ein Mittel, die Sicherheitseigenschaften eines Systems in Hinblick auf seine Sicherheitsdom\u00e4nen zu analysieren und zu dokumentieren.<\/p>\n

Ein Sicherheitsarchitektur (ADV_ARC) nach Common Criteria hat die folgenden Punkte zu erkl\u00e4ren:<\/p>\n