Über das neue CPSA® – Advanced Level Modul EMBED­DEDSEC: Embedded Security for Architects

Am 19. November 2025 hat das iSAQB das neue Advanced-Level-Modul „EMBED­DEDSEC: Embedded Security for Archi­tects“ vorgestellt.

Das Modul EMBED­DEDSEC vermittelt Teilneh­menden Methoden zur Gestaltung einer einge­bet­teten System­ar­chi­tektur, die ihre Sicher­heits­ziele berück­sichtigt. Aufbauend auf den Konzepten des Foundation Levels führt das Modul Teilneh­mende in Analy­se­me­thoden ein, um schüt­zens­werte Werte (Assets) zu identi­fi­zieren und daraus Sicher­heits­ziele für einge­bettete Systeme abzuleiten. Es stellt Quali­täts­merkmale, Entwurfs­muster und Techno­logien vor, die zur Errei­chung dieser Sicher­heits­ziele beitragen, und macht die Teilneh­menden mit gängigen Angriffs­arten vertraut.
Abschließend werden Techniken zur Verifi­kation und Validierung von Sicher­heits­merk­malen vorge­stellt. Nach Abschluss des Moduls kennen die Teilneh­menden Ansätze zur Gestaltung einge­bet­teter Archi­tek­turen mit Security als Quali­täts­merkmal und sind in der Lage, Sicher­heits­ri­siken zu identi­fi­zieren und geeignete Gegen­maß­nahmen auszuwählen.

Wir haben ein Interview mit den Kuratoren Felix Bräunling und Isabella Stilkerich geführt, in dem sie tiefere Einblicke in das Modul geben.

Warum hat sich das iSAQB entschieden, ein eigenes Advanced-Level-Modul zum Thema Embedded Security zu entwickeln?

Einge­bettete Geräte finden sich im Herzen unseres alltäg­lichen Lebens – sei es in Unter­hal­tungs­elek­tronik, intel­li­genten Heimsys­temen oder in kriti­schen Anwen­dungen wie Medizin- oder Automo­bil­technik. Deren sichere Funkti­ons­weise schützt die Privat­sphäre und Gesundheit ihrer Nutzer:innen. Sicherheit lässt sich jedoch nicht im Nachhinein in ein System integrieren, sondern muss von Anfang an berück­sichtigt werden. Wir sprechen hier gerne von „Security by Design“. Für Architekt:innen ist es daher wichtig zu verstehen, wie Sicher­heits­ri­siken erkannt und angemessen mitigiert werden können. Genau dies soll durch Trainings auf Basis des EMBED­DEDSEC-Lehrplans erreicht werden.

Was sind die zentralen Unter­schiede zwischen Embedded Security und klassi­scher IT-Security?

Je nach Grad der Einbettung verschwimmen die Grenzen zunehmend – etwa beim High-Perfor­mance-Controller eines Fahrzeug-Infotainment-Systems. Dennoch bestehen wichtige Unter­schiede, unabhängig von der System­größe: beschränkte Ressourcen, spezielle bzw. proprietäre Schnitt­stellen, einge­schränkte Nutzer­schnitt­stellen sowie teilweise eine stark begrenzte oder fehlende Inter­net­ver­bindung. Zudem werden einge­bettete Systeme für einen spezi­fi­schen Zweck entworfen, auf dessen Erfüllung sie optimiert sind.

Diese Unter­schiede erfordern angepasste Lösungen, z. B. ressour­cen­scho­nende Verschlüs­se­lungs­me­cha­nismen, nutzer­un­ab­hängige Authen­ti­fi­zie­rungs­ver­fahren oder sichere und resiliente Update-Strategien.

Gerade bei sicher­heits­kri­ti­schen einge­bet­teten Systemen muss zudem gewähr­leistet sein, dass Angreifer:innen nicht in der Lage sind, Nutzer:innen zu schädigen. Dies führt dazu, dass Schutz­ziele wie Verfüg­barkeit häufig höher priori­siert werden als Vertrau­lichkeit – im Gegensatz zur klassi­schen IT-Security. Im Notfall ist es für ein medizi­ni­sches System wichtiger, verfügbar zu bleiben, als dass ein komplexes Authen­ti­fi­zie­rungs­ver­fahren die Nutzung verzögert.

Warum ist die Verbindung von Funktio­naler Sicherheit und Security gerade bei einge­bet­teten Systemen so entscheidend?

Einge­bettete Systeme sind per Definition in ihre Umwelt integriert und beein­flussen diese direkt – oft sogar in sensiblen Bereichen unseres Lebens. Das reicht von der Steuerung eines Roboters in einer Indus­trie­anlage bis zum mit Kamera ausge­stat­teten Staub­sauger­ro­boter. Angriffe auf solche Systeme können daher sowohl die Privat­sphäre als auch die körper­liche Unver­sehrtheit von Personen gefährden.

Funktionale Sicherheit und Security ergänzen sich häufig und können gemeinsam dazu beitragen, solche Szenarien zu verhindern. Aller­dings kann es zu Zielkon­flikten kommen: Typische Security-Mecha­nismen wie Zugriffs­kon­trollen oder Verschlüs­selung können Anfor­de­rungen der funktio­nalen Sicherheit entge­gen­stehen, etwa wenn hohe Verfüg­barkeit oder strenge Echtzeit­an­for­de­rungen bestehen. Daher ist es essen­ziell, beide Aspekte und ihre Wechsel­wir­kungen zu betrachten. Diese Abwägung unter Berück­sich­tigung von Quali­täts­an­for­de­rungen ist ein zentraler Bestandteil der Architekturarbeit.

Welche typischen Sicher­heits­ri­siken treten in einge­bet­teten Systemen auf und wie hilft das Modul, sie zu erkennen und zu bewerten?

Typische Sicher­heits­ri­siken ähneln häufig denen klassi­scher IT-Systeme. Die OWASP IoT Top 10 listet etwa „schwache, erratbare oder hardco­dierte Passwörter“ oder die „Nutzung unsicherer oder veral­teter Kompo­nenten“. Hinzu kommt die physische Ebene: Die Hardware muss gegen Angriffe wie Seiten­ka­nal­at­tacken, Glitching und ähnliche Manipu­la­tionen gehärtet sein. Außerdem werden einge­bettete Systeme oft in C oder C++ entwi­ckelt – Sprachen mit hoher Perfor­mance, aber geringen Garantien hinsichtlich Speicher- und Typsi­cherheit. Viele Schwach­stellen entstehen genau hier.

Im Training werden daher nicht nur typische Angriffe behandelt, sondern auch physische Attacken, sichere Imple­men­tie­rungs­tech­niken und moderne Alter­na­tiven zu C/C++ wie Rust.

Ein zentraler Bestandteil ist zudem ein syste­ma­ti­scher Ansatz zur Risiko­iden­ti­fi­kation – die Grundlage aller weiter­füh­renden Sicherheitsmaßnahmen.

Das Curri­culum behandelt auch Krypto­grafie und Hardware­aspekte. Welche Kompe­tenzen erwerben Teilneh­mende in diesen Bereichen?

Das Modul vermittelt keine vollständige Ausbildung in der Imple­men­tierung von Krypto­grafie. Statt­dessen geht es darum, grund­le­gende Opera­tionen zu verstehen und beurteilen zu können, welcher krypto­gra­fische Mecha­nismus für welches Schutzziel geeignet ist – etwa warum nicht jede Verschlüs­selung die Integrität von Daten gewähr­leisten kann oder warum Update­si­gna­turen notwendig sind. Dazu erhalten Teilneh­mende einen Überblick über empfohlene Algorithmen, einschließlich solcher, die speziell für ressour­cen­be­schränkte Systeme entwi­ckelt wurden.

Auch bei den Hardware­aspekten liegt der Fokus nicht auf einer vollstän­digen Hardware­ent­wicklung, sondern auf dem Verständnis typischer physi­scher Angriffe sowie gängiger Hardware­si­cher­heits­me­cha­nismen wie Physical Unclonable Functions, Redun­danzen oder Hardware Security Modules. Gerade bei einge­bet­teten Systemen entsteht Sicherheit oft durch das Zusam­men­spiel von Hardware und Software.

Was sollen Teilneh­mende nach Abschluss des EMBED­DEDSEC-Moduls praktisch anwenden können – und welchen Mehrwert bringt das für ihre Arbeit als Softwarearchitekt:in?

Nach Abschluss des Moduls sollen Teilneh­mende in der Lage sein, einen vorläu­figen System­entwurf hinsichtlich poten­zi­eller Sicher­heits­ri­siken zu analy­sieren, diese zu bewerten und passende Maßnahmen auszu­wählen sowie an die funktio­nalen und quali­ta­tiven Anfor­de­rungen des Systems anzupassen.

Sie erlernen zudem Grund­lagen der Verifi­ka­tions- und Validie­rungs­tech­niken in der Security, sodass sie Tester:innen unter­stützen und die Testbarkeit eines Systems einordnen können. Dadurch werden sie befähigt, einge­bettete Systeme sicherer zu entwerfen, ohne andere Archi­tek­tur­qua­li­täten aus dem Blick zu verlieren. Zudem können sie ihr Wissen auf Basis der vermit­telten Methoden und Referenzen selbst­ständig weiter ausbauen.