Différences de sécurité entre OT et IT

Appliquer directement les pratiques de sécurité d’IT à OT cause souvent plus de tort que de bien. Ces deux domaines optimisent des objectifs différents, utilisent des technologies différentes et connaissent des modes de défaillance différents. Un professionnel qui passe à OT doit désapprendre plusieurs réflexes.

Cette leçon compare les priorités, les contraintes et les menaces qui font de la sécurité d’OT une discipline à part entière.

IT donne la priorité à la triade CIA : confidentialité, intégrité et disponibilité. Dans OT, l’ordre est pratiquement inversé.

• Disponibilité en premier — le procédé doit continuer à fonctionner ; un arrêt peut être dangereux ou extrêmement coûteux
• Intégrité en deuxième — les relevés et les commandes doivent être fiables
• Confidentialité en dernier — les valeurs des capteurs sont rarement secrètes

Au-dessus de tout cela se trouve une préoccupation qu’IT ne partage pas : la sûreté. La protection des vies humaines et de l’environnement prime sur tout le reste.

Dans OT, une mesure de cybersécurité qui pourrait amener un procédé à se comporter de manière inattendue peut être pire que la menace. Une action automatisée qui déclenche une turbine ou ferme une vanne au mauvais moment peut blesser des personnes.

• Les changements de sécurité ne doivent jamais compromettre la fonction de sûreté
• Les ingénieurs, et pas uniquement le personnel de sécurité, doivent approuver officiellement les changements
• Le SIS doit rester indépendant et fiable

C’est pourquoi les tactiques IT agressives, comme l’isolation automatique, doivent être adaptées avec précaution dans OT.

Dans IT, l’installation rapide de correctifs est une règle d’or. Dans OT, elle est soumise à des contraintes.

• L’installation de correctifs peut nécessiter un arrêt de l’installation, avec des arrêts planifiés à plusieurs mois d’intervalle
• La certification du fournisseur peut interdire les correctifs non approuvés
• Un correctif défectueux peut interrompre la production ou compromettre un dossier de sûreté

Comme l’installation de correctifs est lente, OT s’appuie davantage sur des mesures compensatoires : segmentation, surveillance et contrôle des accès pour protéger les systèmes qui ne peuvent pas être rapidement mis à jour.

Les équipements OT fonctionnent pendant des décennies. Il est courant de trouver en production des contrôleurs et des systèmes d’exploitation bien après la fin du support du fournisseur, car les remplacer signifie reconstruire la ligne physique.

• Versions non prises en charge d’OS pour lesquelles aucun correctif n’est disponible
• Matériel incapable d’exécuter des agents de sécurité modernes
• Protocoles conçus à une époque où l’on supposait que le réseau était isolé

Vous devez sécuriser ce qui existe, et non ce que vous souhaiteriez voir exister.

De nombreux protocoles industriels ont été créés pour des réseaux fiables et physiquement isolés ; ils ne disposent donc par défaut d’aucune authentification ni d’aucun chiffrement. Sur un tel réseau, tout appareil capable d’atteindre un contrôleur peut lui envoyer des commandes.

• Les commandes sont acceptées sans vérifier l’identité de l’expéditeur
• Le trafic est souvent en clair et facilement falsifiable
• Dans les anciennes versions, il s’agit d’une hypothèse de conception et non d’un bogue réparable

La protection repose sur le contrôle des appareils autorisés à atteindre le réseau, un sujet abordé plus loin.

Dans IT, l’analyse des vulnérabilités est une pratique courante. Dans OT, une analyse agressive peut faire planter des appareils fragiles. Certains automates se mettent en défaut ou s’arrêtent lorsqu’ils reçoivent un trafic inattendu, ce qui peut être dangereux sur un procédé en fonctionnement.

• Privilégiez la surveillance réseau passive à l’analyse active
• Testez tout outil actif dans un laboratoire ou pendant une fenêtre de maintenance
• Coordonnez-vous avec les équipes d’exploitation avant d’intervenir sur les réseaux de production

Le principe à retenir : dans OT, l’évaluation ne doit pas devenir l’incident.

Les boucles de contrôle fonctionnent selon des contraintes temporelles strictes. L’ajout de latence ou de gigue peut déstabiliser un procédé.

• Les dispositifs de sécurité placés en ligne ne doivent pas introduire de délai dangereux
• Des agents lourds peuvent priver les tâches en temps réel de CPU
• Les changements réseau peuvent interrompre des communications étroitement synchronisées

La sécurité doit respecter le déterminisme exigé par le procédé, ce qui exclut souvent des solutions triviales dans IT.

La différence fondamentale est la suivante : les incidents OT ont des effets physiques bien réels. Un serveur IT compromis divulgue des données ; un système OT compromis peut faire déborder un réservoir, endommager une turbine, contaminer l’eau ou mettre des travailleurs en danger.

Les enjeux sont donc plus élevés et l’évaluation des risques est différente. Dans le pire des cas, les conséquences ne sont pas seulement financières ou réputationnelles : elles peuvent entraîner des pertes humaines. La modélisation des menaces dans OT doit prendre en compte les impacts physiques et ceux sur la sûreté, et pas uniquement les données.

OT présente un profil de menace particulier.

• Les États-nations qui cherchent à perturber stratégiquement les infrastructures critiques
• Les attaquants dont l’objectif est une perturbation physique, et non le vol de données
• Même un rançongiciel IT non ciblé peut se propager à OT et interrompre les opérations

Les conséquences étant graves et les attaquants pouvant disposer de moyens importants, la défense d’OT met l’accent sur la résilience et la détection, en plus de la prévention.

Le but n’est pas d’abandonner la sécurité d’IT, mais de l’adapter.

• Privilégiez la surveillance passive et la segmentation plutôt que l’analyse intrusive et l’installation rapide de correctifs
• Faites passer la sûreté et la disponibilité avant la confidentialité
• Impliquez les ingénieurs procédé dans chaque décision de sécurité
• Utilisez des mesures compensatoires pour les systèmes qui ne peuvent pas recevoir de correctifs

Ces principes orientent les leçons suivantes consacrées aux protocoles et à l’architecture.

Appliquez les priorités inversées à une décision concrète.

Vous avez appris pourquoi la sécurité d’OT constitue une discipline à part entière.

• Les priorités s’inversent : la sûreté et la disponibilité d’abord, la confidentialité en dernier
• L’installation de correctifs est contrainte ; il faut s’appuyer sur des mesures compensatoires
• Les équipements anciens et les protocoles non sécurisés par conception sont une réalité
• L’analyse active et les agents intrusifs peuvent endommager des appareils fragiles fonctionnant en temps réel
• Les incidents ont des conséquences physiques ; impliquez les ingénieurs procédé dans chaque décision

Ensuite : les protocoles précis et leurs faiblesses.