Eine Anforderung ist keine Evidenz dafür, dass sich das Produkt sicher verhält. Regulierung kann sichere Update-Mechanismen, Schutz sensibler Daten oder Zugangskontrolle verlangen, aber die Formulierung auf Anforderungsebene stellt nicht her, ob das implementierte Produkt die intendierte Eigenschaft durchsetzt. Ein Produkt kann signierte Firmware-Updates nutzen, und trotzdem angreifbare Legacy-Firmware über einen Recovery-Pfad akzeptieren; Zertifikate verwenden, und trotzdem Credentials über eine Produktlinie teilen.
Die technische Lücke verläuft zwischen „die Anforderung existiert“ und „das implementierte Produkt setzt die intendierte Security-Eigenschaft nachweislich durch“. Diese Lücke zu schließen ist Engineering-Aufgabe: die Anforderung in eine konkrete Security-Eigenschaft übersetzen, auf die Produktarchitektur mappen, in die Komponenten verfolgen, die sie durchsetzen, und testen, ob sie unter Angriff hält.
Das ist bewusst keine Compliance-Beratung. Zertifizierung, rechtliche Auslegung und regulatorische Bewertung liegen außerhalb dieses Scopes. Was die Regulierung erzeugt, ist ein Kaufanlass für technische Arbeit: Der Hersteller braucht Evidenz, und Evidenz kommt aus dem Testen des Produkts, nicht aus dem Dokumentieren von Absichten.
Regulatorische Anforderungen werden zu konkreten technischen Fragen.
- Secure Update Verhindern Firmware-Signierung, Verifikation, Rollback-Schutz, Recovery und Key-Handling tatsächlich die Installation unautorisierter oder angreifbarer Software?
- Authentisierung & Zugangskontrolle Welche Identitäten erreichen Produkt-Funktionen, Management-Schnittstellen und privilegierte Operationen, und werden diese Grenzen konsistent durchgesetzt?
- Geräte-Identität & Credentials Sind Produkt-Identitäten eindeutig, geschützt, sicher provisioniert und bei Kompromittierung ersetzbar?
- Kommunikations-Sicherheit Etablieren Pairing, Protokoll-Authentisierung, Verschlüsselung, Frische und Replay-Schutz die intendierte Trust-Beziehung?
- Produktions-Security-Zustand Sind Debug-Schnittstellen, Readout-Schutz und Lifecycle-Konfiguration konsistent mit dem intendierten Produktions-Zustand?
- Vulnerability-Handling-Evidenz Lassen sich gemeldete Issues reproduzieren, ihr Produkt-Impact ermitteln, betroffene Versionen identifizieren und Fixes unabhängig verifizieren?
Die Anforderung sagte Secure Update. Der Recovery-Pfad war anderer Meinung.
Die technische Dokumentation beschreibt einen signierten Firmware-Update-Mechanismus. Anforderung auf dem Papier erfüllt. Die Implementierung verifiziert Signaturen auf dem Normal-Pfad, während der Recovery-Pfad ein älteres, gültig signiertes Image ohne Versions-Durchsetzung akzeptiert.
Ein technischer Test, der die Anforderung ins Produkt verfolgt, durch Architektur und Implementierung bis zu einem konkreten Angriff, zeigt: Die Eigenschaft hält nicht. Die Dokumentation war über den Mechanismus korrekt; der Mechanismus war nicht das ganze Produkt.
Die Anforderung in etwas übersetzen, das das Produkt beweisen kann.
Wir identifizieren die relevante technische Security-Eigenschaft hinter jeder Anforderung, mappen sie auf die Produktarchitektur und verfolgen sie in die Komponenten, die sie durchsetzen. Je nach Anforderung führt das in Firmware, Identitäts-Systeme, Protokolle, Applikationen oder Backend-Dienste, und endet mit Evidenz aus dem Test, nicht aus der Behauptung.
- CRA-Frist für Ihre Produktkategorie rückt näher
- EN 18031 betrifft Ihre Funkgeräte
- IEC 62443 wird in Industrie-Kundenprojekten verlangt
- Kunde oder Ausschreibung verlangt dokumentiertes Security-Testing
- Conformity- oder Technical File in Vorbereitung
- Entscheidung, welche Anforderungen Testing brauchen versus Dokumentation