Humain et machine : qui doit authentifier qui ?

Cybelius vous propose une nouvelle série d’articles qui ont pour objectifs d’apporter notre éclairage et notre vision de la cybersécurité des systèmes industriels. Dans ce premier document, nous revenons sur l’authentification et nous posons une question controverser : pourquoi est-ce l’humain qui doit s’authentifier plutôt que la machine ?

Un des derniers rapports sur la cybersécurité qui vient d’arriver est le BakerHostetler « 2018 Data Security Incident Response Report». Il promeut en titre la cyber résilience, l’un des mots les plus répandus ces temps-ci. Bien qu’il ne soit pas ciblé sur la cyber sécurité industrielle, il présente des statistiques intéressantes sur les temps de détection, de remédiation, assorti d’une batterie de recommandations plutôt intéressantes, et en phase avec les discours ambiants.


Un point retient l’attention : celui du MFA, Multiple Factor Authentication. De fait, le rapport indique que les solutions cloud (l’exemple est Office 365) sans MFA font monter les attaques par phishing. Le rapport en conclut logiquement que le MFA devrait être utilisé plus largement.

Appliquer l’authentification forte aux systèmes industriels ?

Sans parler des solutions cloud qui ne sont pas, à ce jour, utilisées par Cybelius, et ce pour des raisons de sécurité et de PRA, cette tendance à durcir l’authentification pose des questions et ne se transmet pas en l’état à l’informatique industrielle.


D’abord c’est une mesure qui complexifie les systèmes. Pour ajouter de la sécurité, les systèmes d’authentification doivent être distincts. Nous devons déjà cloisonner soigneusement l’administration de sécurité par rapport à l’exploitation ; le MFA imposerait de cloisonner des services à l’intérieur de l’administration de sécurité, voire à l’intérieur du sous-ensemble « authentification et droits ».

Ensuite, c’est une mesure d’hygiène informatique préventive, qui utilise des technologies elles-mêmes faillibles. Les mesures de sécurité génériques sont une cible plus attractive. L’informatique industrielle ne développera pas de technologie d’authentification en propre – encore qu’une réflexion sur ce point puisse aboutir à une conclusion inverse. Elle utilisera donc les technologies de l’informatique cyber usuelle. Nous importons dans les systèmes industriels une mesure de sécurité avec ses vulnérabilités, nous condamnant aux mises à jour fréquentes et urgentes : précisément ce qui nous pose des problèmes avec le « patch management », pierre angulaire du Maintien en Conditions de Sécurité.

De manière générale, cette critique s’applique à toute mesure d’hygiène informatique importée dans l’informatique industrielle : on apporte de la complexité, souvent de la gêne opérationnelle, et le contexte de gestion de ces technologies pose des problèmes bien plus importants qu’en informatique de gestion. Or les voix pour le dire explicitement sont trop peu nombreuses. Implicitement par contre, la contestation et le rejet de l’approche des informaticiens par les exploitants et automaticiens vient de ce genre d’expérience. Nous n’avons pas encore une grille de critères sur l’import de technologies de sécurité IT dans le monde OT qui rende compte objectivement du rapport coûts / bénéfi

Authentifier les machines

Enfin, le principe même de l’authentification pourrait lui-même être remis en perspective dans un renversement paradoxal : pourquoi est-ce l’humain qui doit s’identifier devant la machine plutôt que l’inverse ? Lorsque la machine est compromise, c’est elle qui porte le danger, pas les opérateurs qui se connectent régulièrement. Le pré-supposé de l’authentification est que les machines sont saines, et que l’attaquant, en direct ou caché derrière un utilisateur compromis, ne doit pas y avoir accès ; si il a accès, ce doit être de manière limitée. Cette rhétorique est applicable à la compromission initiale. L’est-elle pour autant pour toute la suite ?


La Kill Chain développée par Lockheed Martin fournit un cadre intéressant d’étude. Dans quelles étapes l’authentification apporte une protection ? Dans deux étapes sur 8 : l’intrusion initiale et l’escalade de privilège. Outre que cela montre bien la nécessité absolue de se doter d’un système de détection d’intrusion tel que Cypres, cela relativise la barrière apportée par l’authentification, et affaiblit la recommandation de la complexifier et la durcir.


Plus généralement encore, la révélation quotidienne des vulnérabilités montre que nos systèmes sont tous vulnérables et qu’une partie significative de ces vulnérabilités sont exploitées. Comme le mentionne le rapport BakerHostetler mentionné plus haut, le temps de découverte est long : 66 jours en moyenne. Pour les systèmes industriels, nous estimons que le temps est bien plus important, de l’ordre de l’année. Donc, lorsqu’un utilisateur se connecte, la probabilité la plus forte de compromission est du côté de la machine, pas de l’utilisateur.

Identifier les sytèmes

Pour aller plus loin dans l’idée d’une authentification des machines – du système – par l’humain, il faut revenir aux deux points fondamentaux de cette mesure de sécurité : une identité et une confiance dans cette identité. L’identité des systèmes informatiques suppose un travail qui, précisément, est complexe et peut-être impossible dans une vision SI de gestion qui n’a pas exactement de limites et qui fait l’objet d’évolutions quasi incessantes ; il serait utile d’ailleurs de voir si l’origine de cette évolution n’est pas majoritairement liée à la sécurité.


L’identification des machines d’un système industriel n’est pas insurmontable. Comme utilisé dans les systèmes de protection d’intégrité de CyFence, la description statique des programmes est une nomenclature, certes riche, mais usuelle dans le monde du contrôle-commande. Elle va plus loin que la cartographie demandée par les normes. La cartographie est un usage second : une vérification des hosts soit parce qu’il n’existe pas de référentiels, ou que le référentiel est douteux, soit parce que les flux sont à surveiller, dans la perspective de découvrir essentiellement des protocoles dangereux. A notre avis, le premier point est le plus important : disposer d’une nomenclature intégrale, et vérifiable. Nous revenons là à des process d’ingénierie de projet, et à leur qualité. Nous estimons que cette connaissance, à jour, vérifiable, apporte une sécurité considérablement plus forte qu’un apport technologique exogène et, partiellement, inadapté.


Les protocoles dangereux sont faciles à détecter et sont en effet une signature de vulnérabilité, voire de compromission. Cependant, ce sont les protocoles standards dans leur dynamique qui apportent une information d’identification « courante », au moins sur la constitution du système. Nul doute que les systèmes industriels sont bien plus compromis du fait de leur utilisation de briques logicielles standard (TCP IP, Windows, … même TLS) que des protocoles spécifiques tels que Modbus ou Profinet.


La description dynamique est également faisable. Outre les métriques sur les conversations entre hosts que Cypres fait automatiquement, les paramètres de fonctionnement des machines, à commencer par les taux de CPU et mémoire occupés, les flux réseaux, sont aujourd’hui disponibles, archivables, et comparables d’un jour sur l’autre. Posez-vous la question à votre prochain login : si nous vous présentions les machines, les évolutions dans la composition statique (les mises à jour des programmes, bases de données et paramètres), et un comparatif des flux et mesures dynamiques, n’auriez-vous pas plus confiance dans votre machine ? Ne rendrions-nous pas la vie bien plus difficile pour les attaquants ?


Une nouvelle voie pour l’authentification des systèmes

Ce renversement appelle évidemment un outillage spécifique de contrôle, il n’est pas question de faire ces vérifications manuellement (encore que c’est bien ce que l’on fait dans les analyses post-incident). A Cybelius, nous avons commencé ce travail, notamment par une gestion de la contextualisation qui permet d’associer la dynamique des flux à un contexte : c’est un point de passage obligé pour un IDS, sous peine de faux positifs. Nous pensons que cette approche est, en soi, une hygiène qui dépasse largement la cyber-sécurité, et qu’elle est porteuse de confiance dans les machines. Car l’humain peut être vecteur, mais le caractère opératif d’une attaque est dans les machines.


Ce travail se poursuivra à l’avenir. Nous estimons qu’il pourrait permettre de ré-équilibrer la relation de l’humain à la machine en terme de confiance. La qualité de l’ingénierie d’une part, des outils d’analyse qui tracent les évolutions statiques et dynamiques dans le temps, une véritable administration des systèmes industriels qui en manquent : ce sont des directions nécessaires, bien plus à notre avis que le MFA à court terme.

A vrai dire, il n’y a pas beaucoup d’alternatives avec l’arrivée des IoT et des IIoT. L’informatique industrielle est à une croisée des chemins. Soit on continue d’importer des technologies de sécurité, avec la complexification et la mutation des process de mise à jour qui lui sont nécessaires. Soit on revient aux fondamentaux de l’ingénierie des systèmes, de la connaissance de leur composition et comportement, en rapprochant leur intégrité à leur fiabilité de fonctionnement. Les deux voies sont utiles.

Nous veillerons, à Cybelius, que la première n’occulte pas la deuxième, dans les solutions que nous proposons.
.