Connecter un logiciel OEE au réseau d'automates programmables industriels (PLC) d'une usine crée une nouvelle voie de données entre les environnements de technologie opérationnelle (OT) et de technologie de l'information (IT).
Dans la plupart des usines, les réseaux OT sont délibérément isolés des réseaux informatiques d'entreprise pour protéger les systèmes de production contre les menaces de cybersécurité, la compromission d'un automate de production constitue un risque pour la sécurité et la continuité des activités, pas seulement un risque pour la sécurité des données.
Tout logiciel franchissant cette frontière OT‑IT, y compris les plateformes OEE, nécessite une évaluation rigoureuse de la sécurité avant son déploiement. Le panorama de la sécurité des logiciels OEE s'est nettement amélioré au cours des cinq dernières années, mais l'écart entre les fournisseurs reste important.
Les plateformes OEE natives cloud, conçues sur des architectures de sécurité modernes, présentent des profils de sécurité fondamentalement différents des systèmes OEE sur site développés dans les années 2000, qui n'ont pas été conçus en tenant compte de la sécurisation de la frontière OT‑IT.
Les questions posées lors d'une évaluation de sécurité doivent faire apparaître ces différences et produire des preuves documentées de la posture de sécurité du fournisseur, que vos équipes de sécurité IT et OT pourront examiner avant d'approuver la connectivité réseau.
Les conséquences d'une évaluation de sécurité OEE insuffisante vont du moindre, accès non autorisé aux données ou problèmes de conformité en matière de confidentialité, au plus grave, un rançongiciel pénétrant le réseau OT via un serveur OEE compromis et perturbant les opérations de production.
Étant donné que le logiciel OEE est connecté aux équipements de production sur chaque ligne, une plateforme OEE compromise dispose d'un accès réseau plus étendu que la plupart des systèmes informatiques qui se connectent à l'environnement OT.
Ce profil de risque accru justifie un examen de sécurité plus approfondi que les évaluations standard des logiciels d'entreprise.
Questions sur l'architecture et le flux de données: (1) La plateforme OEE utilise-t-elle une architecture de flux de données unidirectionnelle de l'OT vers l'IT (lecture seule depuis les automates - PLC), ou dispose-t-elle d'une capacité de communication bidirectionnelle ?
(2) Où les données de production sont-elles stockées, sur site, dans une région cloud spécifique ou dans un cloud partagé multi‑locataire ? (3) Le serveur OEE est-il placé dans une DMZ (zone démilitarisée) entre les réseaux OT et IT, ou nécessite-t-il un accès direct aux deux réseaux simultanément ?
(4) Quels ports et protocoles réseau la plateforme OEE requiert-elle d'ouvrir entre les réseaux OT et IT ? (5) La plateforme OEE prend-elle en charge un déploiement sans aucune connexion entrante depuis Internet (déploiement isolé/air‑gapped ou déploiement sur site) ?
Questions d'authentification et de contrôle d'accès: (6) La plateforme prend‑elle en charge SAML 2.0 ou OIDC pour l'intégration SSO d'entreprise ? (7) L'authentification multifacteur (MFA) est‑elle prise en charge et applicable à tous les rôles utilisateurs ?
(8) La plateforme met‑elle en œuvre un contrôle d'accès basé sur les rôles (RBAC) qui limite l'accès aux données en fonction de l'usine, de la ligne et de la fonction ? (9) Existe‑t‑il des identifiants d'administrateur séparés pour l'application OEE et pour l'infrastructure sous‑jacente (base de données, OS) ?
(10) Comment les clés API et les identifiants des comptes de service sont‑ils gérés et renouvelés ?
Questions sur la sécurité des données: (11) Les données sont‑elles chiffrées en transit en utilisant TLS 1.2 ou supérieur pour toutes les communications ? (12) Les données sont‑elles chiffrées au repos, et quelle norme de chiffrement est utilisée ?
(13) Quelles données de production sont envoyées vers le cloud et lesquelles sont conservées sur site ? (14) La plateforme journalise‑t‑elle tous les événements d'accès utilisateur et toutes les actions d'exportation de données dans un journal d'audit accessible au client ?
(15) Quelle est la politique de conservation des données et le processus de suppression lorsque le client résilie le contrat ?
Questions sur la gestion des vulnérabilités et la réponse aux incidents: (16) Quel est le processus du fournisseur pour la distribution des correctifs de sécurité et quel est le délai typique entre la divulgation d'une vulnérabilité et la disponibilité du correctif ?
(17) Le fournisseur a‑t‑il réalisé un test d'intrusion par un tiers au cours des 12 derniers mois, et le résumé exécutif des conclusions est‑il disponible ? (18) Le fournisseur dispose‑t‑il d'une politique de divulgation des vulnérabilités publiée et d'un contact sécurité dédié ?
(19) Quel est le SLA de réponse aux incidents du fournisseur si une violation de sécurité affectant les données client est détectée ? (20) Le fournisseur détient‑il des certifications de sécurité pertinentes (ISO 27001, SOC 2 Type II) couvrant l'infrastructure de la plateforme OEE ?
Lorsque vous évaluez les réponses des fournisseurs au questionnaire de sécurité, privilégiez la spécificité plutôt que les affirmations. Un fournisseur qui répond à « les données sont-elles chiffrées en transit ?
» par « oui, nous utilisons un chiffrement conforme aux standards de l'industrie » est moins crédible qu'un fournisseur qui répond « oui, toutes les communications utilisent TLS 1.3 avec pinning de certificats sur les clients mobiles.
» Les affirmations vagues et positives sont faciles à formuler; les affirmations techniques précises sont plus difficiles à inventer et plus faciles à vérifier.
Considérez certaines réponses comme des points d'arrêt impératifs qui doivent être résolus avant l'approbation du déploiement. Cela inclut: la communication réseau bidirectionnelle entre les systèmes OT et le cloud du fournisseur (crée une surface d'attaque entrante) l'absence de prise en charge de l'authentification multifactorielle pour l'accès administrateur (inacceptable pour les systèmes connectés à l'OT)
le stockage des données dans une juridiction incompatible avec vos exigences de souveraineté des données l'absence de test d'intrusion par un tiers au cours des 18 derniers mois et l'absence de processus documenté de réponse aux incidents.
Ce ne sont pas des points de négociation, ce sont des bases de sécurité requises par une gestion responsable de la sécurité des réseaux OT.
Intégrez les exigences de sécurité que les fournisseurs doivent respecter dans le contrat d'achat avant signature. Incluez des clauses spécifiques couvrant: les obligations de notification si le fournisseur détecte un incident de sécurité affectant vos données le droit de mener votre propre évaluation de sécurité de la plateforme chaque année
l'obligation du fournisseur de corriger les vulnérabilités critiques dans les 30 jours et le droit du client de résilier le contrat sans pénalité si le fournisseur ne respecte pas ses engagements en matière de sécurité.
Les exigences de sécurité qui ne figurent pas dans le contrat ne sont que des suggestions, les exigences contractuelles en matière de sécurité sont des obligations qui ouvrent des recours en cas de violation.
Connexion
Blog
