Connect981 – Content Dev

RSC Topic : Cybersécurité et alignement réglementaire

Gestion pratique des contextes CMMC, NIST 800-171, DFARS et ITAR.

  • Devons-nous mettre en œuvre les 93 mesures de l’Annexe A ?

    Non, vous n’êtes pas tenu de mettre en œuvre les 93 mesures de l’Annexe A exactement telles qu’elles sont rédigées. Dans le cadre d’ISO/IEC 27001, l’Annexe A est un catalogue de mesures possibles que vous sélectionnez en fonction du risque. Ce qui est requis, c’est une décision structurée et justifiée sur les mesures applicables, la manière dont elles sont mises en œuvre et les raisons pour lesquelles certaines sont exclues.

    Ce que la norme exige réellement

    ISO/IEC 27001 exige que vous :

    En pratique, cela se rattache à la défense et à la fabrication réglementée lorsque les équipes doivent transformer la réponse en habitudes d’exécution répétables.

    • Définissiez le périmètre de votre SMSI, y compris les sites, systèmes et processus inclus dans ce périmètre.
    • Réalisiez une appréciation formelle des risques couvrant les actifs informationnels, les menaces, les vulnérabilités et les impacts.
    • Sélectionniez des mesures appropriées et proportionnées aux risques identifiés.
    • Compariez les mesures choisies à l’Annexe A et décidiez, pour chaque mesure de l’Annexe A, si elle est :
      • Mise en œuvre telle que décrite, ou
      • Mise en œuvre de manière équivalente ou compensatoire, ou
      • Non applicable, avec une justification claire.
    • Documentiez l’ensemble dans une Déclaration d’applicabilité (SoA) et la mainteniez sous maîtrise des modifications.

    La SoA constitue l’élément probant clé. Elle doit démontrer que vous avez examiné toutes les mesures de l’Annexe A et que vous pouvez expliquer vos choix. Les auditeurs se concentrent généralement sur votre raisonnement et sa cohérence, et non sur une mise en œuvre un pour un de toutes les mesures.

    Quand vous pourriez effectivement adopter la plupart ou la totalité des mesures

    Dans de nombreux environnements industriels et réglementés, le résultat d’une appréciation des risques est qu’une grande partie des mesures de l’Annexe A sont pertinentes, par exemple :

    • Des usines disposant de systèmes critiques pour la sécurité ou soumis au contrôle des exportations.
    • Des installations traitant des données client ou de défense au titre de clauses contractuelles faisant référence à ISO/IEC 27001 ou à des cadres connexes.
    • Des écosystèmes fournisseurs complexes avec une connectivité externe vers des réseaux OT.

    Dans de tels cas, vous pouvez finir par mettre en œuvre la plupart des mesures de l’Annexe A sous une forme ou une autre, mais cela découle toujours d’une analyse des risques et de faisabilité plutôt que d’une règle systématique. Certaines mesures seront appliquées différemment entre les environnements IT d’entreprise et les environnements OT.

    Réalités des environnements brownfield et OT

    Dans les sites existants avec des MES historiques, des PLC, des SCADA et des équipements à longue durée de vie, certains contrôles de l’Annexe A sont difficiles ou perturbateurs à mettre en œuvre tels qu’ils sont formulés. Exemples typiques :

    • Contraintes techniques : les contrôleurs hérités peuvent ne pas prendre en charge l’authentification moderne, le rythme de déploiement des correctifs ou le chiffrement sans remplacement du matériel.
    • Risque d’arrêt : l’application de contrôles qui exigent des modifications de firmware, des mises à niveau d’OS ou une nouvelle segmentation réseau peut créer un risque d’indisponibilité ou de requalification inacceptablement élevé.
    • Dépendance vis-à-vis du fournisseur : certains contrôles dépendent de capacités fournisseur ou de cycles de publication que vous ne maîtrisez pas.
    • Charge de validation : dans les environnements de type GMP ou aérospatiaux, chaque changement pertinent pour la sécurité apporté à des systèmes validés peut déclencher une revalidation, l’exécution de tests et des mises à jour documentaires.

    Dans ces cas, vous vous appuyez généralement sur une combinaison de :

    • Contrôles compensatoires (par exemple, ségrégation physique, zonage réseau, surveillance).
    • Contrôles procéduraux (par exemple, gestion stricte des changements et vérifications manuelles).
    • Acceptation explicite du risque, avec validation par la direction et cycles de revue.

    L’important est que votre SoA et votre registre des risques rendent ces contraintes et décisions traçables et défendables.

    Comment décider quels contrôles de l’Annexe A mettre en œuvre

    Une approche pratique, fondée sur les risques, comprend généralement :

    1. Cartographier les actifs et les processus
      Identifier les actifs critiques : équipements de production, données de procédé, recettes, programmes CN, enregistrements qualité, données soumises au contrôle des exportations et systèmes liés à la sécurité.
    2. Mener une évaluation des risques structurée
      Utiliser une méthode cohérente pour évaluer l’impact et la probabilité, et tenir compte de scénarios propres à l’OT, tels que la perte de disponibilité, l’intégrité des consignes et la contamination croisée entre les réseaux OT et les réseaux d’entreprise.
    3. Prioriser les risques à fort impact
      Se concentrer d’abord sur les contrôles qui réduisent les risques d’incidents de sécurité, d’arrêts de production, de non-conformités produit passées au travers et de manquements réglementaires.
    4. Évaluer la faisabilité dans votre environnement actuel
      Identifier où un contrôle peut être mis en œuvre directement, où il doit être adapté, et où un contrôle compensatoire est plus réaliste en raison des contraintes liées aux systèmes hérités.
    5. Documenter les décisions dans la déclaration d’applicabilité
      Pour chaque contrôle de l’Annexe A :
      • Le marquer comme applicable/non applicable.
      • Décrire comment il est mis en œuvre ou l’approche compensatoire retenue.
      • Consigner les justifications, les dépendances et tout risque résiduel.
    6. Intégrer avec la maîtrise des changements et la validation
      S’assurer que toute modification de contrôle touchant des systèmes validés, des fonctions de sécurité ou des flux de données réglementés passe par votre processus de maîtrise des changements ainsi que par les essais/vérifications requis.

    Pourquoi « tout mettre en œuvre » est souvent impraticable

    Un déploiement obligatoire et uniforme de l’ensemble des 93 mesures échoue généralement dans la fabrication réglementée pour plusieurs raisons :

    • Charge de qualification et de validation : la modification des fonctionnalités OT, MES ou QMS pour satisfaire à des mesures de sécurité spécifiques peut déclencher une requalification des protocoles, une validation logicielle et des changements documentaires.
    • Arrêts de production et coûts : les arrêts d’usine nécessaires pour repenser l’architecture des réseaux, migrer des systèmes hérités vers de nouvelles plateformes ou remplacer du matériel de contrôle peuvent être prohibitifs.
    • Complexité d’intégration : des mesures qui semblent simples sur le papier (par exemple, journalisation centralisée, gestion unifiée des accès) deviennent complexes dans des environnements multi-fournisseurs et multigénérationnels.
    • Traçabilité et gestion de configuration : un déploiement rapide et large peut dépasser votre capacité à maintenir des inventaires, des référentiels de base et des enregistrements de configuration exacts, ce qui affaiblit à la fois la cybersécurité et la préparation aux audits.

    Ce ne sont pas des raisons d’éviter entièrement les mesures ; ce sont des raisons de prioriser, d’échelonner la mise en œuvre et d’utiliser des mesures compensatoires pendant que vous introduisez progressivement des changements plus profonds.

    Coexistence avec les systèmes IT, OT et qualité existants

    Les mesures de l’Annexe A sont généralement mises en œuvre au moyen de combinaisons de :

    • Outils de sécurité IT existants (identité, journalisation, protection des terminaux, sauvegarde).
    • Segmentation des réseaux OT, pare-feu et solutions d’accès distant sécurisé.
    • Configuration et procédures MES, ERP et QMS (par exemple, contrôle des accès, pistes d’audit, maîtrise documentaire).
    • Procédures et formation en atelier (par exemple, gestion des supports amovibles, règles d’accès des fournisseurs).

    Dans la plupart des environnements industriels existants, vous ajoutez les mesures de l’Annexe A par couches à ce qui existe déjà, plutôt que de remplacer les systèmes centraux. Les stratégies de remplacement qui ignorent les implications en matière de validation, d’intégration et d’arrêts de production ont tendance à se bloquer ou à être réduites lorsqu’elles atteignent des actifs complexes et à forte valeur.

    Ce que les auditeurs recherchent généralement

    Bien que les attentes varient selon les auditeurs, ils vérifieront généralement que :

    • Votre évaluation des risques est méthodique, reproductible et alignée sur votre périmètre.
    • Votre Déclaration d’applicabilité couvre toutes les mesures de l’Annexe A et présente une cohérence interne.
    • Les mesures que vous déclarez avoir mises en œuvre existent réellement et fonctionnent efficacement, avec des preuves à l’appui.
    • Les exclusions et les mesures compensatoires sont justifiées au regard de vos risques et de vos contraintes.
    • Les modifications apportées aux mesures suivent une maîtrise des changements définie et sont reflétées dans la documentation à jour.

    Ils n’exigent pas que chaque mesure de l’Annexe A soit mise en œuvre de manière identique sur tous les sites ou systèmes, dès lors que votre justification fondée sur les risques est documentée et appliquée de façon cohérente.

    En résumé, vous êtes tenu de prendre en compte les 93 mesures de l’Annexe A, de documenter leur applicabilité et de mettre en œuvre les mesures appropriées en fonction du risque et de la faisabilité. Vous n’êtes pas tenu de mettre en œuvre chaque mesure exactement telle qu’elle est rédigée, en particulier lorsque les contraintes liées à l’OT existant, à la validation et à l’intégration rendent cela impraticable, à condition que vos justifications soient claires, fondées sur des preuves et maintenues sous maîtrise des changements.

  • Comment concilier les politiques d’application des correctifs IT avec les exigences de disponibilité OT ?

    Concilier les politiques de correctifs IT avec les exigences de disponibilité OT consiste généralement à remplacer une règle générique du type « appliquer tous les correctifs chaque mois » par une approche conjointe, fondée sur les risques. Vous n’obtiendrez pas un calendrier unique satisfaisant les deux parties ; il faut un compromis structuré qui traite l’OT différemment de l’informatique bureautique tout en prenant en compte le risque cyber.

    1. Mettre en place une gouvernance conjointe, et non un contrôle uniquement IT

    Commencez par faire de l’application des correctifs une responsabilité partagée entre l’IT, l’OT/ingénierie et la qualité, plutôt qu’une activité pilotée par l’IT :

    En pratique, cela se rattache aux preuves de sécurité industrielle lorsque les équipes doivent transformer la réponse en habitudes d’exécution répétables.

    • Créer un forum transverse sur les correctifs (sécurité IT, ingénierie OT, opérations, qualité/validation le cas échéant).
    • Définir qui peut approuver, reporter ou refuser des correctifs sur des systèmes réglementés ou validés.
    • Documenter les critères de décision et conserver les enregistrements pour l’auditabilité et les revues d’incidents futures.

    Sans gouvernance conjointe explicite, l’IT optimisera la posture cyber et l’OT optimisera la disponibilité ; chacun aura « raison » dans son propre cadre, et l’usine se retrouvera avec un risque non maîtrisé et des conflits.

    2. Élaborer une politique de correctifs propre à l’OT

    Appliquer telle quelle la politique IT d’entreprise dans les environnements de production fonctionne rarement. Il faut une politique spécifique à l’OT, alignée sur l’IT mais non identique :

    • Périmètre : Préciser que les règles de correctifs OT s’appliquent aux PLC, HMI, SCADA, systèmes d’historisation, nœuds MES, systèmes de laboratoire et contrôleurs d’équipement, et pas seulement aux clients Windows/Linux standard.
    • Approche fondée sur les risques : Relier l’urgence d’un correctif à l’exploitabilité, à l’exposition (p. ex. DMZ ou cellule isolée) et à l’impact sur la sécurité et la qualité, et pas seulement aux niveaux de sévérité indiqués par les fournisseurs.
    • Contraintes de validation : Pour les systèmes réglementés et validés, définir quand un correctif nécessite une revalidation ou des essais de régression, ainsi que les preuves acceptables pour conclure à une absence d’impact.
    • Règles de report : Définir explicitement quand et comment les correctifs peuvent être reportés, pour quelle durée, et quels contrôles compensatoires sont requis.

    Cette politique doit reconnaître que certains actifs OT ne peuvent pas être corrigés selon les calendriers IT en raison de la charge de validation, des limites de support fournisseur ou d’un impact élevé sur les arrêts de production.

    3. Classer les actifs et la criticité des correctifs

    Tous les systèmes n’ont pas besoin de la même cadence d’application des correctifs. Créez un modèle de base des actifs et de leur criticité, puis alignez les attentes de correctifs par classe :

    • Niveau 1 : actifs de cybersécurité exposés ou critiques (pare-feu, serveurs de rebond, passerelles d’accès distant, Active Directory, serveurs DMZ). Ils doivent suivre les cycles de correctifs IT aussi étroitement que possible, avec un niveau élevé de rigueur dans les tests.
    • Niveau 2 : serveurs et infrastructure OT (MES, historiseurs, serveurs batch, serveurs OPC) ayant un impact sur la production mais pouvant être redémarrés dans des fenêtres planifiées. Utilisez des cycles mensuels ou trimestriels, avec approbation de l’usine et possibilités de retour arrière.
    • Niveau 3 : IHM au niveau ligne, postes d’ingénierie et contrôleurs, pour lesquels les arrêts et la requalification sont coûteux. L’application des correctifs peut être trimestrielle, semestrielle ou alignée sur les grandes opérations de maintenance, selon le risque et les recommandations du fournisseur.
    • Niveau 4 : systèmes anciens ou verrouillés par le fournisseur, pour lesquels les correctifs ne sont pas disponibles ou compromettraient le support.

    L’essentiel est que les politiques IT reconnaissent explicitement ces niveaux, au lieu de traiter tous les systèmes comme un ordinateur portable d’entreprise.

    4. Utiliser des fenêtres de maintenance et des vagues de correctifs

    Pour concilier disponibilité et sécurité, formalisez quand et comment vous intervenez sur les systèmes OT :

    • Fenêtres de maintenance standard : Convenez de fenêtres fixes hebdomadaires ou mensuelles par zone ou par ligne, même si elles ne sont pas toujours utilisées. Cela permet à l’IT de planifier les travaux sans gestion permanente des urgences.
    • Vagues de correctifs : Déployez d’abord sur des systèmes de test ou de criticité moindre, puis sur les actifs à forte criticité une fois la stabilité confirmée. Par exemple, appliquez d’abord les correctifs aux équipements de laboratoire ou pilotes, puis aux lignes de production.
    • Contraintes saisonnières : Respectez les périodes d’interdiction connues (par exemple, pic de production, campagnes de qualification), documentées dans le plan d’application des correctifs.

    Les fenêtres de maintenance resteront néanmoins limitées dans de nombreuses usines, en particulier dans les sites à forte utilisation ou à procédés continus ; les attentes quant à ce qui peut réellement être corrigé à chaque fenêtre doivent donc rester réalistes.

    5. Toujours tester et prévoir des plans de retour arrière

    Dans les environnements OT, des correctifs non testés peuvent provoquer des non-qualités passées au travers des contrôles ou des arrêts prolongés, et pas seulement des réclamations utilisateurs. Réduisez ce risque en :

    • Testant dans un environnement représentatif : idéalement un système de préproduction ou une copie virtualisée du MES/SCADA où vous pouvez tester les principaux flux de travail avec des images corrigées.
    • Coordonnant avec les fournisseurs : utilisez des listes de correctifs ou des images approuvées par les fournisseurs lorsqu’elles existent. Gardez à l’esprit que certains fournisseurs accusent un retard important par rapport aux cycles de correctifs IT.
    • Assurant les sauvegardes et les snapshots : effectuez des sauvegardes complètes ou des snapshots système avant d’appliquer les correctifs. Validez que les restaurations sont effectivement réalisables dans votre fenêtre d’arrêt.
    • Standardisant les décisions de retour arrière : définissez les conditions qui déclenchent un retour arrière (par exemple, échec au démarrage, problèmes d’intégrité des données, régressions de performance) et qui peut l’autoriser sur un système en production.

    Lorsque les systèmes font partie de processus validés, consignez les preuves issues des tests et du déploiement des correctifs dans les enregistrements de maîtrise des changements.

    6. Utiliser des mesures compensatoires lorsque vous ne pouvez pas appliquer de correctifs

    Certains systèmes OT ne peuvent pas être corrigés du tout, ou seulement très rarement, en raison de contraintes fournisseur, de matériel ancien ou de l’impact sur la validation. Reconnaissez-le ouvertement et appliquez des mesures compensatoires au lieu de prétendre être conforme à la politique IT :

    • Segmentation et isolation réseau pour les systèmes hérités à haut risque.
    • Contrôles d’accès stricts et hôtes bastion au lieu d’un accès RDP/SSH direct depuis les réseaux bureautiques.
    • Liste d’autorisation des applications et configurations verrouillées sur les anciens hôtes Windows.
    • Surveillance et journalisation renforcées sur les systèmes non corrigés et leurs zones réseau.
    • Acceptation du risque documentée avec un calendrier de remédiation ou de remplacement à terme.

    Cela n’élimine pas le risque, mais rend le risque résiduel visible et maîtrisé, plutôt que dissimulé derrière des indicateurs nominaux de conformité aux correctifs.

    7. Intégrer l’application des correctifs à la maîtrise des changements et à la validation

    Dans les environnements réglementés, les correctifs sont des changements susceptibles d’affecter l’état validé, l’intégrité des données et les pistes d’audit. La conciliation avec la disponibilité OT doit respecter ces contraintes :

    • Faire passer les correctifs concernés par un processus formel de maîtrise des changements, avec des analyses d’impact, des approbations et des revues post-mise en œuvre documentées.
    • Définir quels types de composants nécessitent une revalidation (p. ex., les serveurs applicatifs MES) par opposition à ceux qui, en général, n’en nécessitent pas (p. ex., les hyperviseurs d’infrastructure, sous réserve de certaines précautions).
    • Utiliser les enregistrements de changement pour consigner ce qui a été corrigé, où et comment cela a été testé, afin d’assurer la traçabilité lors d’audits ou d’investigations futurs.

    Cela peut ralentir les cycles d’application des correctifs, en particulier pour les systèmes cœur. Reconnaissez cette contrainte dans la politique IT plutôt que de chercher à la contourner de manière informelle.

    8. Tenir compte de la complexité des environnements existants et des longs cycles de vie des actifs

    Dans de nombreuses usines, remplacer ou mettre à niveau les plateformes OT uniquement pour faciliter l’application des correctifs n’est pas réaliste. Les raisons incluent :

    • Des MES/SCADA et des contrôleurs existants avec un support fournisseur limité et des correctifs de nouveaux OS incompatibles.
    • Des dépendances d’intégration entre ERP, PLM, QMS, historiens de données et intergiciels spécifiques, qui rendent les mises à niveau de plateformes risquées et coûteuses.
    • La charge de qualification et de validation pour chaque changement logiciel ou matériel significatif.
    • Des fenêtres d’arrêt limitées en raison d’opérations 24/7 ou de séquences de redémarrage complexes.

    Étant donné qu’un remplacement complet est souvent irréalisable à court terme, une conciliation pragmatique repose largement sur la segmentation, les configurations durcies, l’application sélective des correctifs et une maîtrise des changements rigoureuse, plutôt que sur des stratégies consistant à « tout moderniser ».

    9. Rendre les arbitrages explicites

    Concilier l’application des correctifs IT et la disponibilité OT consiste essentiellement à rendre les arbitrages explicites, et non à accepter des compromis cachés :

    • Documenter quels systèmes suivent les cycles de correctifs IT et lesquels suivent des cycles spécifiques à l’OT, avec la justification associée.
    • Suivre les correctifs différés et les risques associés, y compris les vulnérabilités connues et les contrôles compensatoires.
    • Réexaminer périodiquement ces décisions dans l’instance transversale, en particulier après des incidents ou des événements évités de justesse.

    Cela permet à la direction de voir où le risque est assumé pour protéger la disponibilité, au lieu de supposer une conformité uniforme qui n’existe pas en pratique.

    Synthèse

    Concilier les politiques de correctifs IT avec les exigences de disponibilité OT nécessite une stratégie de correctifs OT dédiée, et non une version allégée d’une stratégie IT. Les éléments clés sont une gouvernance conjointe, des niveaux de criticité des actifs, des fenêtres de maintenance réalistes, des tests et des retours arrière robustes, des contrôles compensatoires lorsque l’application de correctifs est impossible, ainsi qu’une intégration étroite avec la gestion des changements et la validation. Les résultats dépendront fortement de l’inventaire actuel de vos systèmes, du support des fournisseurs, de la qualité de l’intégration, ainsi que de la maturité de vos processus de changement et de validation.

  • Dois-je mettre en œuvre chaque contrôle 800-53 pour être aligné sur le NIST CSF ?

    Non. Vous n’avez pas besoin de mettre en œuvre tous les contrôles NIST SP 800-53 pour être aligné sur le NIST Cybersecurity Framework (CSF). Les deux documents répondent à des objectifs différents et opèrent à des niveaux de détail différents.

    Comment le NIST CSF et le NIST SP 800-53 s’articulent

    Le NIST CSF est un cadre de haut niveau organisé autour de fonctions, de catégories et de sous-catégories. Il décrit les résultats attendus en cybersécurité (« ce que » vous devez atteindre), et non des configurations techniques spécifiques. Il est couramment utilisé pour la stratégie, la communication avec la direction et la planification des feuilles de route.

    En pratique, cela se rattache aux preuves de sécurité industrielle lorsque les équipes doivent transformer la réponse en habitudes d’exécution répétables.

    Le NIST SP 800-53 est un catalogue détaillé de contrôles de sécurité et de confidentialité (« comment » vous pourriez atteindre ces résultats). Il a été rédigé principalement pour les systèmes d’information fédéraux américains, mais de nombreuses organisations de fabrication réglementée l’utilisent comme bibliothèque de contrôles ou comme référentiel de référence.

    Le NIST fournit des correspondances entre les sous-catégories du CSF et les contrôles 800-53, mais ces correspondances ne constituent pas une obligation de mettre en œuvre l’ensemble du catalogue 800-53.

    Ce que signifie généralement « alignement sur le NIST CSF »

    En pratique, « aligné sur le NIST CSF » signifie généralement :

    • Vous avez défini votre périmètre de cybersécurité (par exemple, réseaux OT, MES, QMS, interfaces ERP, postes d’ingénierie).
    • Vous vous êtes évalué par rapport aux fonctions/catégories/sous-catégories du CSF et avez noté les profils actuels et cibles.
    • Vous pouvez montrer quelles politiques, quels contrôles techniques et quelles procédures soutiennent chaque sous-catégorie pertinente du CSF.
    • Vous gérez les changements et les améliorations au moyen de processus documentés de gouvernance et de gestion des risques.

    De nombreuses organisations utilisent 800-53 comme l’une des sources de contrôles mises en correspondance avec le CSF, aux côtés d’autres normes (par exemple IEC 62443 pour l’OT, ISO 27001 pour l’IT d’entreprise, ou des référentiels de base propres aux fournisseurs).

    Utiliser 800-53 de manière sélective dans le cadre du NIST CSF

    Pour la plupart des environnements industriels et réglementés, l’approche praticable est la suivante :

    1. Définir le périmètre et les contraintes. Identifiez les systèmes et les données inclus dans le périmètre (par exemple les réseaux de production, les systèmes d’historisation, MES, QMS, PLM, les ordinateurs portables d’ingénierie) ainsi que les régimes réglementaires applicables (par exemple les contrôles à l’exportation, les clauses de cybersécurité client, les contrats fédéraux).
    2. Réaliser une évaluation fondée sur le CSF. Évaluez votre état actuel par rapport aux résultats attendus du CSF, en tenant compte spécifiquement des facteurs de risque OT tels que les impacts sur la sécurité, le coût des arrêts et les longs cycles de vie des équipements.
    3. Sélectionner un socle de contrôles. Choisissez un sous-ensemble de contrôles 800-53 (et éventuellement IEC 62443 ou d’autres normes axées sur l’OT) qui répondent aux risques et aux obligations de votre environnement. Il s’agit souvent d’un socle « adapté » ou « allégé » par rapport au catalogue fédéral complet.
    4. Mapper les contrôles au CSF. Documentez la manière dont les contrôles sélectionnés soutiennent des sous-catégories spécifiques du CSF, ainsi que les cas où vous choisissez délibérément de ne pas mettre en œuvre certains contrôles 800-53 parce qu’ils sont inapplicables ou disproportionnés au regard des contraintes OT.
    5. Documenter l’acceptation des risques et les écarts. Pour les contrôles que vous choisissez de ne pas mettre en œuvre, consignez la justification, les contrôles compensatoires (le cas échéant) et les décisions d’acceptation du risque. Dans la fabrication réglementée, cette traçabilité est souvent examinée de plus près que le choix de la norme lui-même.

    Pourquoi vous ne mettez généralement pas en œuvre l’ensemble des contrôles 800-53

    La mise en œuvre de l’intégralité du catalogue 800-53 est généralement peu praticable pour des sites industriels existants, en particulier lorsque les actifs OT ont des cycles de vie longs et des possibilités de mise à niveau limitées. Les contraintes courantes incluent :

    • OT existant et limites fournisseurs. De nombreux PLC, DCS et IHM héritées ne peuvent pas prendre en charge des agents de sécurité modernes, une authentification forte ou des correctifs fréquents. Certains contrôles 800-53 seront techniquement irréalisables sans rénovations majeures ni remplacement de systèmes.
    • Charge de qualification et de validation. Dans la fabrication réglementée, chaque modification apportée à des systèmes validés (par exemple MES, QMS, SCADA liés aux dossiers de lot) peut nécessiter une revalidation, des mises à jour documentaires et des arrêts. Mettre en œuvre chaque contrôle potentiel n’est pas efficace au regard du risque ni des coûts.
    • Arrêts et risques pour la sécurité. Pour les systèmes OT critiques pour la production, un durcissement ou une refonte d’architecture agressifs peuvent créer plus de risques opérationnels qu’ils n’en suppriment s’ils ne sont pas soigneusement phasés et testés.
    • Complexité d’intégration. Les sites combinent souvent des fournisseurs multiples et des piles partiellement intégrées. Certains contrôles 800-53 supposent une gestion homogène des identités, de la journalisation et de la segmentation réseau qui, en pratique, demandent des années à mettre en place.

    En raison de ces facteurs, les organisations priorisent généralement les contrôles qui réduisent le mieux le risque réel tout en préservant la sécurité, la qualité produit et la disponibilité. L’alignement sur le CSF vise à atteindre les résultats attendus et à pouvoir démontrer des décisions rationnelles fondées sur le risque, plutôt qu’une mise en œuvre exhaustive de chaque contrôle du catalogue.

    Ce que les auditeurs et les clients attendent généralement

    Dans de nombreux environnements de l’aérospatiale, de la défense et des sciences de la vie, les auditeurs et les clients recherchent généralement :

    • Un cadre cohérent, tel que le NIST CSF, pour organiser votre programme de cybersécurité.
    • Des preuves que vous avez utilisé un référentiel de contrôles reconnu (comme 800-53 et/ou IEC 62443) pour définir des mesures spécifiques.
    • Des correspondances claires entre les résultats attendus du CSF, les contrôles mis en œuvre et les procédures au niveau de l’usine.
    • Une maîtrise des changements, des essais et une validation pour les changements de cybersécurité affectant des systèmes réglementés.
    • Une acceptation des risques documentée lorsque vous ne mettez pas en œuvre certains contrôles du catalogue en raison de contraintes techniques, de sécurité ou opérationnelles.

    Ils ne s’attendent généralement pas à une mise en œuvre un pour un de tous les contrôles 800-53, sauf si un contrat ou une réglementation spécifique l’exige explicitement.

    Points clés pour les environnements industriels

    • L’alignement sur le NIST CSF ne nécessite pas la mise en œuvre complète de tous les contrôles NIST SP 800-53.
    • Vous devez utiliser 800-53 (et les normes adaptées à l’OT) comme bibliothèque de contrôles, puis l’adapter en fonction du risque, des réalités de l’usine et des exigences réglementaires.
    • Pour les systèmes à long cycle de vie et validés, une documentation, une cartographie et une maîtrise des changements rigoureuses sont souvent plus réalisables qu’une couverture complète du catalogue.
    • Assurez-vous que vos décisions, écarts et contrôles compensatoires sont traçables, en particulier lorsque la sécurité, la qualité ou des données soumises au contrôle des exportations sont concernées.

  • Faut-il interroger les fournisseurs sur ISO 27002 ainsi que sur ISO 27001 ?

    Dans les contextes industriels et manufacturiers réglementés, il ne suffit généralement pas d’interroger les fournisseurs uniquement sur ISO 27001. Vous devez également examiner comment ils utilisent ISO 27002 pour sélectionner et mettre en œuvre des contrôles de sécurité spécifiques, en particulier lorsqu’ils traitent vos conceptions, vos données de fabrication ou des informations produit réglementées.

    Différences entre ISO 27001 et ISO 27002 pour les évaluations fournisseurs

    • ISO 27001 définit les exigences relatives à un système de management de la sécurité de l’information (SMSI) : gouvernance, évaluation des risques, objectifs et amélioration continue. La certification est délivrée par rapport à ISO 27001.
    • ISO 27002 est un catalogue de contrôles et de recommandations de mise en œuvre. Elle aide à répondre aux questions suivantes : quels contrôles ont été sélectionnés, pourquoi, et comment sont-ils appliqués en pratique.

    Un certificat ISO 27001 seul ne vous indique pas quels contrôles sont réellement en place, quel est leur niveau de robustesse, ni dans quelle mesure ils sont alignés sur vos obligations spécifiques en matière de fabrication, de protection de la propriété intellectuelle ou de réglementation.

    Ce qu’il faut demander aux fournisseurs en pratique

    Au lieu de demander seulement « Êtes-vous certifié ISO 27001 ? », élargissez votre due diligence afin d’inclure ISO 27002 en demandant :

    • Statut ISO 27001 : Périmètre de certification, sites couverts et validité du certificat. Confirmez si les sites clés de production ou de traitement des données sont effectivement inclus dans le périmètre.
    • Déclaration d’applicabilité (SoA) : Une liste de contrôles issus d’ISO 27002 (ou équivalent), avec la justification de leur inclusion ou de leur exclusion. C’est un élément critique ; il montre comment le fournisseur a traduit les recommandations d’ISO 27002 dans son référentiel de contrôles.
    • Couverture des contrôles clés : Des preuves ou une description de la manière dont des contrôles ISO 27002 spécifiques sont mis en œuvre pour :
      • Le contrôle d’accès aux données de conception et de procédés
      • La ségrégation réseau entre OT et IT lorsque c’est pertinent
      • La sauvegarde et la restauration des données de production et de qualité
      • La gestion des changements autour des systèmes de fabrication et de qualité
      • Les processus de journalisation et de réponse aux incidents
    • Adaptation fondée sur les risques : La manière dont le fournisseur utilise l’évaluation des risques pour décider quels contrôles ISO 27002 sont renforcés ou allégés pour les données critiques de fabrication et les données réglementées.

    Quand approfondir le questionnement

    Il est particulièrement important d’aller au-delà d’une simple question sur ISO 27001 lorsque les fournisseurs :

    • hébergent ou exploitent votre MES, QMS, PLM ou des services cloud associés ;
    • disposent d’un accès à distance à votre réseau OT, à vos équipements ou à vos données d’usine ;
    • traitent des données de conception soumises au contrôle des exportations, critiques pour la sécurité ou hautement sensibles ;
    • fournissent des équipements à longue durée de vie pour lesquels les mises à jour logicielles et de micrologiciels se poursuivront pendant de nombreuses années.

    Dans ces cas, vous devez vous aligner sur des attentes précises en matière de contrôles ISO 27002 et sur la manière dont les preuves seront fournies dans la durée, et pas seulement lors de l’intégration initiale.

    Réalités des environnements existants et de la coexistence

    Dans des environnements mixtes avec MES/ERP/PLM existants et fournisseurs externes, vos questions sur ISO 27001 et ISO 27002 doivent tenir compte du fait que :

    • certains fournisseurs peuvent avoir une couverture ISO 27001 partielle (par exemple, l’IT bureautique, mais pas l’OT ni les plateformes hébergées) ;
    • les contrôles guidés par ISO 27002 peuvent être mis en œuvre différemment selon les usines, les systèmes et les fournisseurs, en particulier lorsqu’il existe des actifs existants ou des contraintes d’intégration ;
    • le remplacement complet de systèmes non conformes est souvent peu réaliste en raison de la charge de validation, du risque d’arrêt et de la qualification de nouvelles plateformes. Vous pouvez avoir besoin à la place de contrôles compensatoires et d’une supervision renforcée.

    Pour cette raison, les questions doivent porter sur la manière dont les contrôles fondés sur ISO 27002 coexistent avec les systèmes existants, sur la manière dont les changements sont maîtrisés, et sur la manière dont la traçabilité et les preuves de validation sont maintenues.

    Comment formuler les exigences sans s’engager excessivement

    Dans les contrats et questionnaires fournisseurs, vous pouvez :

    • faire référence à la certification ISO 27001 comme attente de base lorsqu’elle est proportionnée au risque ;
    • exiger une Déclaration d’applicabilité alignée sur ISO 27002 ou sur un référentiel de contrôles équivalent ;
    • préciser les domaines de contrôle ISO 27002 les plus critiques pour votre cas d’usage (par exemple, le contrôle d’accès, la sécurité des opérations, les relations avec les fournisseurs, ainsi que l’acquisition et le développement de systèmes) ;
    • demander des mises à jour périodiques et des preuves lorsque des changements majeurs sont apportés aux systèmes traitant vos données, en les rattachant aux exigences de maîtrise des changements et de validation.

    En résumé

    Vous ne devez pas vous limiter à demander si un fournisseur est certifié ISO 27001. Pour les environnements de fabrication réglementés et à cycle de vie long, vous devez également comprendre comment il applique ISO 27002 en pratique : quels contrôles sont inclus dans le périmètre, comment ces contrôles coexistent avec les systèmes hérités et les systèmes OT, et comment il maintient la traçabilité, la validation et la maîtrise des changements dans le temps.