IEC 62443-4-1
Der sichere Entwicklungsprozess hinter Industrieprodukten
IEC 62443-4-1 legt Anforderungen an den sicheren Produktentwicklungsprozess für industrielle Komponenten fest. Sie beschreibt, wie Hersteller ihren Entwicklungsprozess definieren, betreiben und nachweisen; IEC 62443-4-2 behandelt die technischen Sicherheitsfähigkeiten der Komponente.
Warum beides
Die Norm leistet, was die Verordnung nur beschreibt
Der CRA verlangt, dass Schwachstellen identifiziert, unverzüglich behoben, getestet und offengelegt werden. Er sagt nicht, wie ein konformer Prozess aussieht oder welche Aufzeichnungen zu führen sind.
Die IEC 62443-4-1 bietet dafür einen konkreten Prozessrahmen. Die Praktiken DM und SUM weisen enge Bezüge zu Anhang I Teil II auf; SR, SD, SI und SVV können Design- und Testnachweise liefern, die Angaben zu Teil I in der technischen Dokumentation stützen.
Der CRA schreibt keine Zertifizierung vor. Ein zertifizierter Entwicklungslebenszyklus liefert jedoch eine von Dritten geprüfte Antwort auf die schwierigste Frage einer Bewertungsstelle: Belegen Sie das.
Die Norm
Acht Praktiken, siebenundvierzig Anforderungen
Jede Anforderung ist auditierbar und benötigt Nachweise. Bestehende Release-, Qualitäts- und Safety-Prozesse können genutzt werden, soweit sie die Anforderungen erfüllen; alle acht Praktiken brauchen dennoch klare Zuständigkeiten und unterstützende Aufzeichnungen.
- SM13 Anforderungen
Sicherheitsmanagement
Der Entwicklungsprozess ist definiert, verantwortet und mit Ressourcen ausgestattet. Umfasst Abgrenzung, Rollen und Verantwortlichkeiten, Kompetenz, die Sicherheit der Entwicklungsumgebung selbst sowie Kontrollen über Komponenten Dritter.
- SR5 Anforderungen
Spezifikation der Sicherheitsanforderungen
Sicherheitsanforderungen werden aus dem Verwendungszweck und der Bedrohungsanalyse abgeleitet, dokumentiert, geprüft und nachvollziehbar gehalten — nicht implizit angenommen. Umfasst Produktsicherheitskontext und Bedrohungsmodell.
- SD4 Anforderungen
Sicheres Design
Das Design wendet Defense in Depth, geringste Rechte und bewährte Prinzipien sicheren Entwurfs an. Design-Reviews und Bedrohungsmodellierung erfolgen an definierten Punkten, Feststellungen werden bis zum Abschluss verfolgt.
- SI2 Anforderungen
Sichere Implementierung
Die Umsetzung folgt dokumentierten Regeln für sichere Programmierung, und ein Implementierungs-Review prüft, ob das Sicherheitsdesign im Code tatsächlich umgesetzt wurde.
- SVV5 Anforderungen
Sicherheitsverifizierung und -validierung
Funktionale Sicherheitstests, Tests der Bedrohungsminderung, Schwachstellenscans und Penetrationstests werden geplant, von fachkundigen Personen durchgeführt und dokumentiert.
- DM6 Anforderungen
Behandlung sicherheitsrelevanter Meldungen
Gemeldete und selbst entdeckte Probleme werden aufgenommen, triagiert, hinsichtlich Schweregrad bewertet, behoben und offengelegt. Diese Praktik entspricht weitgehend CRA Anhang I Teil II.
- SUM5 Anforderungen
Management von Sicherheitsupdates
Updates werden qualifiziert, dokumentiert, ausgeliefert und innerhalb definierter Fristen kommuniziert — auch für Abhängigkeiten, die Sie nicht selbst entwickelt haben.
- SG7 Anforderungen
Sicherheitsrichtlinien für Anwender
Anwender erhalten die Dokumentation, die sie brauchen, um das Produkt sicher zu installieren, zu betreiben, zu härten und außer Betrieb zu nehmen, einschließlich Hinweisen zu Defense in Depth.
Bewertung
Der Reifegrad bestimmt den Nachweisumfang
Jede Praktik wird eigenständig bewertet. Zertifizierungen zielen üblicherweise auf „Managed“ als Untergrenze, mit „Defined“ für die Praktiken mit dem höchsten Produktrisiko.
- ML 1InitialPraktiken finden statt, aber ad hoc und größtenteils undokumentiert. Ergebnisse hängen von Einzelpersonen ab, nicht vom Prozess.
- ML 2ManagedPraktiken sind dokumentiert, geplant und werden von geschultem Personal mit ausreichenden Ressourcen durchgeführt. Das ist das praktische Minimum für eine Zertifizierung.Üblicher Mindestgrad
- ML 3DefinedPraktiken sind organisationsweit standardisiert und werden einheitlich angewendet; auditierbare Nachweise entstehen als Nebenprodukt der normalen Arbeit.
- ML 4ImprovingPraktiken werden mit Kennzahlen gemessen, und der Prozess selbst wird auf dieser Datengrundlage kontinuierlich verbessert.
Auditpraxis
Was ein Auditor sehen möchte
Nachweise lassen sich nicht glaubwürdig nachträglich erzeugen. Deshalb muss die Prozessarbeit deutlich vor dem angestrebten Audittermin beginnen.
- Dokumentierte Beschreibung des Entwicklungsprozesses und Abgrenzung des Anwendungsbereichs
- Rollendefinitionen, Kompetenznachweise und Schulungsbelege
- Produktsicherheitskontext und Bedrohungsmodelle je Release
- Sicherheitsanforderungen mit Nachvollziehbarkeit zu Design und Test
- Aufzeichnungen zu Design- und Implementierungs-Reviews mit abgeschlossenen Feststellungen
- Regelwerk für sichere Programmierung und Belege seiner Anwendung
- Testpläne und Ergebnisse für SVV, einschließlich Penetrationstestberichten
- Fehlerregister mit Triage, Schweregradbewertung und Abschluss
- Qualifizierungsnachweise für Updates und Release Notes
- Veröffentlichte Offenlegungspolitik und Sicherheitsrichtlinien für Anwender
Nachvollziehbarkeit und ein Zielreifegrad je Praktik
Prüfende müssen ein Sicherheitsrisiko von der Bedrohungsanalyse über Anforderungen, Design, Umsetzung und Test bis zur Freigabe verfolgen und jede Praktik mit ihrem Zielreifegrad vergleichen können.
- Bedrohung im Modell
- Sicherheitsanforderung
- Designentscheidung
- Codeänderung
- Testergebnis
- Release-Aufzeichnung
Eine Maßnahme ist schwer zu belegen, wenn ihre Aufzeichnungen nicht mit der betreffenden Anforderung oder einem Test ihrer Wirksamkeit verbunden sind.
Der Zielgrad wird für jede Praktik nach Zertifizierungsumfang und Produktrisiko festgelegt. Nicht jede Praktik muss denselben Reifegrad erreichen.
Vorbereitungspfad
Was zur Zertifizierungsvorbereitung typischerweise gehört
Die Vorbereitung beginnt meist mit einer Lückenbewertung gegen den Zielreifegrad. Anschließend wird der Entwicklungsprozess definiert oder angepasst, über reale Releases hinweg werden Nachweise aufgebaut und vor dem Audit der Zertifizierungsstelle geprüft. Umfang und Reihenfolge hängen von den vorhandenen Prozessen und dem Zertifizierungsverfahren ab.
Passende Unterstützung
Assessments für dieses Framework
Strukturierte Fragebögen, vollständig in Ihrem Browser ausgewertet — kein Konto, nichts wird übertragen. Jedes Ergebnis wird auf die Anforderung zurückgeführt, die es misst.
Kontakt
Aus der IEC 62443-4-1 einen auditfesten Prozess machen
Eine kurze Beschreibung dessen, was Sie bauen und wie die Entwicklung heute organisiert ist, genügt für den Anfang. Wir nennen Ihnen die wahrscheinlichen Lücken gegenüber der Norm und was deren Schließung für Ihr Team bedeutet.
Wir antworten innerhalb von zwei Werktagen.
Vollständige KontaktdatenÖffnet unsere Terminseite in einem neuen Tab — wählen Sie einen passenden Zeitpunkt.
Nützlich in einer ersten Nachricht
- Was Sie bauen, wie viele Produktlinien im Umfang liegen und welche Plattformen beteiligt sind.
- Wie die Entwicklung heute organisiert ist — Teamgröße, Release-Takt und Ihre Toolchain.
- Ob Sie auf ein Zertifizierungsaudit, eine Kundenanforderung oder eine CRA-Frist hinarbeiten.
Bitte verzichten Sie in einer ersten Nachricht auf vertrauliche technische Details und Geschäftsgeheimnisse. Nach unserer Antwort vereinbaren wir für Sensibles einen verschlüsselten Kanal.