IEC 62443-4-1 : le cycle de développement sécurisé des produits industriels

Qu'est-ce que l'IEC 62443-4-1 ?

IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, a été publiée en janvier 2018. Son domaine d'application précise qu'elle définit des exigences de processus pour le développement sécurisé des produits utilisés dans les systèmes d'automatisation et de contrôle industriels. Le cycle de vie qu'elle décrit couvre la définition des exigences de sécurité, la conception sécurisée, l'implémentation sécurisée, la vérification et la validation, la gestion des défauts, la gestion des correctifs et la fin de vie du produit.

Elle s'applique à celui qui développe et maintient un produit : le fournisseur de contrôleurs, d'appareils embarqués, d'équipements réseau, de logiciels hôtes ou d'applications. Elle ne s'applique pas à l'intégrateur ni à l'utilisateur du produit, qui ont leurs propres parties de la série. L'ISA publie la série sous le nom ISA/IEC 62443.

La norme décrit des exigences de processus, des politiques et des procédures, et non des fonctions de sécurité techniques. Les exigences techniques applicables aux composants figurent dans IEC 62443-4-2.

Les huit pratiques d'IEC 62443-4-1

Les exigences sont regroupées en huit pratiques, chacune dotée d'une courte abréviation qui préfixe les identifiants de ses exigences. L'ISA Global Cybersecurity Alliance recense 47 exigences au total :

Pratique	Exigences	Ce qu'elle couvre
1. Gestion de la sécurité (SM)	SM-1 à SM-13	Planifier et conduire le processus de sécurité : responsabilités, expertise, sécurité de l'environnement de développement, clés privées, composants fournis de l'extérieur et composants tiers, vérification du processus, amélioration continue
2. Spécification des exigences de sécurité (SR)	SR-1 à SR-5	Contexte de sécurité du produit, modèle de menaces, exigences de sécurité du produit et leur revue
3. Sécurité dès la conception (SD)	SD-1 à SD-4	Principes de conception sécurisée, conception selon la défense en profondeur, revue de conception, bonnes pratiques de conception
4. Implémentation sécurisée (SI)	SI-1 à SI-2	Revue de l'implémentation de la sécurité et normes de codage sécurisé
5. Tests de vérification et de validation de la sécurité (SVV)	SVV-1 à SVV-5	Tests des exigences, tests d'atténuation des menaces, tests de vulnérabilité, tests d'intrusion, indépendance des testeurs
6. Gestion des problèmes liés à la sécurité (DM)	DM-1 à DM-6	Réception, examen, évaluation, traitement et divulgation des problèmes de sécurité du produit
7. Gestion des mises à jour de sécurité (SUM)	SUM-1 à SUM-5	Qualification, documentation et livraison des mises à jour de sécurité, dans les délais
8. Lignes directrices de sécurité (SG)	SG-1 à SG-7	Documentation utilisateur sur la défense en profondeur, le durcissement, l'exploitation sécurisée, la gestion des comptes et la mise au rebut

Pratique 6 : gestion des problèmes liés à la sécurité (DM)

DM est la pratique qu'un PSIRT reconnaît comme la sienne. Selon l'ISAGCA, ses processus servent à traiter les problèmes de sécurité d'un produit configuré conformément à sa stratégie de défense en profondeur. Ses six exigences suivent un problème du signalement à la clôture :

• DM-1 : Réception des notifications de problèmes liés à la sécurité
• DM-2 : Examen des problèmes liés à la sécurité
• DM-3 : Évaluation des problèmes liés à la sécurité
• DM-4 : Traitement des problèmes liés à la sécurité
• DM-5 : Divulgation des problèmes liés à la sécurité
• DM-6 : Revue périodique de la pratique de gestion des défauts de sécurité

En clair : recevoir les signalements, les vérifier, les évaluer, les corriger, informer les utilisateurs et revoir le processus lui-même.

Cette séquence est le cycle de vie de la gestion des vulnérabilités sous un autre nom, et c'est en DM-1 et DM-5 qu'intervient la divulgation coordonnée des vulnérabilités. La divulgation peut prendre la forme d'un avis CSAF, avec une déclaration VEX pour les versions non touchées.

Pratique 7 : gestion des mises à jour de sécurité (SUM)

SUM prend le relais lorsque DM décide d'une correction. Ses processus, selon le résumé de l'ISAGCA, garantissent que les mises à jour de sécurité du matériel, du logiciel ou du firmware du produit sont soumises à des tests de non-régression et mises à la disposition des utilisateurs en temps utile. Les cinq exigences sont :

• SUM-1 : Qualification des mises à jour de sécurité
• SUM-2 : Documentation des mises à jour de sécurité
• SUM-3 : Documentation des mises à jour de sécurité des composants dépendants ou du système d'exploitation
• SUM-4 : Livraison des mises à jour de sécurité
• SUM-5 : Livraison en temps utile des correctifs de sécurité

SUM-3 est celle qui touche à votre chaîne d'approvisionnement : les mises à jour des composants et des systèmes d'exploitation dont dépend votre produit. Pour un produit embarqué bâti sur une distribution Linux, cela peut représenter l'essentiel des correctifs que vous livrez.

Niveaux de maturité

IEC 62443-4-1 ne demande pas si un processus existe, mais quel est son degré de maturité. Elle utilise quatre niveaux de maturité, fondés sur CMMI for Development :

Niveau	Signification
ML1 Initial	Les processus sont exécutés au cas par cas ou ne sont pas documentés
ML2 Géré	Les processus sont documentés et décrivent comment l'activité est réalisée et gérée
ML3 Défini (pratiqué)	Les processus sont documentés, exécutés et reproductibles
ML4 En amélioration	Les processus sont améliorés dans le temps à l'aide de métriques de performance et d'efficacité

La différence entre ML2 et ML3, c'est la pratique. Un processus DM écrit peut relever de ML2. ML3 signifie que le processus a été exécuté et répété : problèmes reçus, évalués et clôturés, mises à jour livrées, avec les traces pour le prouver.

Certification

• ISASecure SDLA. Le programme Security Development Lifecycle Assurance certifie le processus de cycle de vie d'une organisation de développement selon IEC 62443-4-1. Les évaluations sont réalisées par des laboratoires SDLA agréés, accrédités comme organismes d'évaluation de la conformité.
• Organismes de certification et IECEE CB Scheme. Des organismes d'essai et de certification tels que Applus+ et TÜV Rheinland évaluent les fournisseurs au regard de 62443-4-1 et indiquent le niveau de maturité atteint, y compris dans le cadre de l'IECEE CB Scheme, applicable dans plus de 50 pays.

Un certificat 62443-4-1 couvre le processus de développement du fournisseur, pas un produit en particulier. Les produits sont évalués séparément au regard de 62443-4-2.

Le lien entre 62443-4-1 et le reste de la série

• IEC 62443-4-2, exigences de sécurité techniques pour les composants IACS : ce que le produit doit être capable de faire. La partie 4-1 porte sur la façon de le construire et de le maintenir.
• IEC 62443-3-3, exigences de sécurité système et niveaux de sécurité : les exigences techniques équivalentes au niveau du système.
• IEC 62443-2-4, exigences de programme de sécurité pour les prestataires de services IACS : les intégrateurs et les prestataires de maintenance qui installent et entretiennent votre produit sur le site du propriétaire de l'actif, et qui dépendent de vos mises à jour et lignes directrices de sécurité.

IEC 62443-4-1 et le travail d'un PSIRT

Activité du PSIRT	Correspondance dans 62443-4-1
Réception des signalements de vulnérabilités	DM-1
Tri et analyse	DM-2, DM-3
Remédiation	DM-4, SUM-1
Avis de sécurité et divulgation	DM-5, SUM-2
Correctifs pour les composants tiers	SUM-3, avec SM-9 et SM-10 sur les composants fournis de l'extérieur et les composants tiers
Publication de la correction	SUM-4, SUM-5
Métriques et revue du processus	DM-6, SM-13

Cette correspondance est la nôtre, établie à partir des intitulés des exigences. La norme ne mentionne pas les PSIRT nommément ; le même travail est décrit dans le PSIRT Services Framework de FIRST et dans ISO/IEC 30111.

Les SBOM comme preuves pour DM et SUM

Les intitulés des exigences de 2018 ne mentionnent pas les SBOM. Mais une grande partie des problèmes de sécurité d'un produit industriel se trouvent dans des composants que son fournisseur n'a pas écrits : le noyau Linux, OpenSSL, BusyBox, une pile de protocoles. Répondre à DM-2 et DM-3 pour un nouvel avis suppose de savoir quels produits et versions contiennent le composant touché. Documenter les mises à jour SUM-3 suppose de savoir avec quelles versions de composants chaque release a été livrée. Au niveau ML3, ces réponses doivent reposer sur des traces.

Une liste de composants rédigée à la main, ou une analyse de l'arborescence source, devient vite obsolète. Une SBOM issue du build qui a produit la release ne le devient pas, tant que le build lui-même est enregistré.

La place de CRACI

CRACI ne certifie rien au titre d'IEC 62443 et ne gère pas votre processus de développement. Ses enregistrements peuvent servir de preuves pour certaines parties de celui-ci : l'inventaire des composants de chaque release et la surveillance des builds livrés face aux nouvelles vulnérabilités.

CRACI exécute les builds GitHub Actions, builds Yocto compris, sur ses propres runners et enregistre les paquets réellement récupérés par chaque job, y compris les dépendances transitives, les paquets restaurés depuis les caches et les dépendances qu'aucun lockfile ne liste. Chaque SBOM porte un état de complétude et s'exporte en CycloneDX ou SPDX. Les SBOM surveillées sont réévaluées en continu, l'historique des builds indique quels builds passés contenaient une dépendance vulnérable, et la vue d'inventaire montre quelles versions sont déployées sur quels produits. Les SBOM fournisseurs des composants achetés sont surveillées aux côtés de vos propres builds. Consultez le suivi des vulnérabilités et CRACI pour les PSIRT.

IEC 62443-4-1 : questions fréquentes

Qu'est-ce que l'IEC 62443-4-1 ?

IEC 62443-4-1:2018, Secure product development lifecycle requirements, est la partie de la série IEC 62443 qui fixe des exigences de processus pour les fournisseurs qui développent des produits utilisés dans les systèmes d'automatisation et de contrôle industriels. Elle couvre les exigences de sécurité, la conception sécurisée, l'implémentation, la vérification et la validation, la gestion des défauts, la gestion des correctifs et la fin de vie du produit.

Quelles sont les huit pratiques d'IEC 62443-4-1 ?

La gestion de la sécurité (SM), la spécification des exigences de sécurité (SR), la sécurité dès la conception (SD), l'implémentation sécurisée (SI), les tests de vérification et de validation de la sécurité (SVV), la gestion des problèmes liés à la sécurité (DM), la gestion des mises à jour de sécurité (SUM) et les lignes directrices de sécurité (SG). Ensemble, elles regroupent 47 exigences.

Quelle est la différence entre IEC 62443-4-1 et 62443-4-2 ?

La partie 4-1 porte sur le processus qu'un fournisseur utilise pour développer et maintenir ses produits. La partie 4-2 fixe des exigences de sécurité techniques pour les composants eux-mêmes, comme les appareils embarqués, les équipements réseau, les appareils hôtes et les applications logicielles. Un fournisseur est généralement évalué selon 4-1 pour son processus de développement et selon 4-2 pour un produit donné.

Quelles pratiques d'IEC 62443-4-1 couvrent la gestion des vulnérabilités ?

Principalement la pratique 6, gestion des problèmes liés à la sécurité (DM-1 à DM-6), qui couvre la réception, l'examen, l'évaluation, le traitement et la divulgation des problèmes de sécurité, et la pratique 7, gestion des mises à jour de sécurité (SUM-1 à SUM-5), qui couvre la qualification, la documentation et la livraison des mises à jour de sécurité dans les délais. C'est le travail d'un PSIRT.

Quels sont les niveaux de maturité d'IEC 62443-4-1 ?

Quatre niveaux, fondés sur CMMI for Development : ML1 Initial (au cas par cas ou non documenté), ML2 Géré (processus documentés), ML3 Défini ou pratiqué (documenté, exécuté et reproductible) et ML4 En amélioration (processus améliorés dans le temps à l'aide de métriques de performance).

Comment obtenir la certification IEC 62443-4-1 ?

Par l'intermédiaire d'un organisme de certification accrédité. Le programme SDLA d'ISASecure certifie les organisations de développement selon IEC 62443-4-1 par le biais de laboratoires agréés, et des organismes de certification tels que TÜV Rheinland et Applus+ délivrent des certificats 62443-4-1 qui indiquent le niveau de maturité atteint, y compris dans le cadre de l'IECEE CB Scheme.

IEC 62443-4-1 exige-t-elle une SBOM ?

Les intitulés des exigences de 2018 ne mentionnent pas les SBOM. Plusieurs exigences portent sur les composants fournis de l'extérieur et sur les mises à jour des composants dépendants et des systèmes d'exploitation, et une liste fiable des composants de chaque release est le moyen pratique de montrer comment vous les gérez.