La technologie opérationnelle dans l'IoT industriel ne peut pas tolérer les correctifs de style informatique. « Analyse des menaces » est une solution sûre et puissante

Parlant de l'Internet industriel des objets - (IIoT). La technologie opérationnelle dans l'Internet des objets industriel (IoT) ne peut pas tolérer les correctifs de style informatique. L'utilisation de « l'analyse des menaces » est une solution sûre et puissante. Au sein des entreprises et dans le monde entier, l'écosystème IIoT est une fusion étroitement liée et négociée de l'informatique et de l'OT. Les systèmes OT ne sont pas seulement critiques pour l'entreprise, ils peuvent être critiques pour la nation ou critiques pour la vie ou la mort.

Chaque client de l'Internet des objets industriel (IIoT) à qui je parle souhaite la sécurité la plus élevée possible. Pas l'Internet des objets – Internet des objets industriel (IIoT).

Qui, au sein de l'organisation du client, exécutera et possédera ce processus ? En rencontrant après avoir rencontré des clients qui développent des capacités IIoT, je rencontre une incertitude naturelle mais parfois tendue entre les professionnels de l'informatique et de l'OT/LOB en ce qui concerne la sécurité de l'IIoT.

Cette incertitude capitale – est en elle-même – une vulnérabilité de sécurité car elle retarde le déploiement essentiel de la sécurité.

Une récente enquête de Forrester auprès des responsables informatiques et OT/LOB a montré que les responsables informatiques et OT étaient également divisés sur la question de savoir si l'informatique ou l'OT était responsable de la sécurité, selon DARKReading d'InformationWeek. Comme résultat alarmant de cette impasse, rapporte Forrester, un nombre inacceptable d'entreprises - 59% - sont prêtes à « tolérer un risque moyen à élevé en ce qui concerne la sécurité de l'IoT ».

Je pense que c'est incorrect et mauvais pour les entreprises de laisser cette négligence se poursuivre - ainsi que dangereux pour l'ensemble de leurs opérations.

Considérez les différences entre l'informatique d'entreprise et l'OT :

• Disponibilité  :
  Le service informatique considère qu'un temps de disponibilité de 99 % est acceptable, tandis que l'OT nécessite un temps de disponibilité de 99,999 %, soit la différence entre 8,76 heures et 5,25 minutes de temps d'arrêt annuel.
  • Durée de vie du système :
  Les systèmes informatiques sont renouvelés, en moyenne, tous les trois à cinq ans. Les systèmes OT, en revanche, durent 10 à 15 ans.
  • Correction  :
  Les correctifs/mises à jour informatiques peuvent être effectués chaque fois que des mises à jour sont disponibles, mais les correctifs/mises à jour OT risquent d'interrompre les opérations industrielles stratégiques génératrices de revenus.

Il existe également de nombreuses autres différences IT/OT, telles que différentes approches du cloud.

Cependant, toutes les différences sont subsumées par le besoin universel de la sécurité IIoT la plus résiliente disponible.

Une approche que je privilégie consiste à aider les entreprises industrielles à utiliser les leçons durement acquises et longtemps disputées de l'informatique pour passer à un état avancé de sécurité IIoT. L'IIoT est conçu et déployé de manière experte pour répondre aux exigences différenciées d'OT. Certains pensent que les systèmes OT sont une autre forme de centre de données, le cœur fortement protégé de l'informatique d'entreprise.

Il existe des idées prometteuses que l'on peut adapter à partir de décennies d'expérience en informatique. Utiliser ces idées, puis les ajouter pour fournir de nouveaux niveaux de sécurité IIoT, tout en respectant les besoins spécifiques de l'OT. Parmi ces adaptations figurent la séparation des réseaux de point de terminaison, la micro-segmentation et l'analyse du comportement des utilisateurs (UBA). J'en discuterai dans les prochains articles.

Avec correctifs , IT et OT parlent des langues différentes. Saisissez « analyse des menaces ».

Nous comprenons que le processus de correction vise à mettre à jour, corriger ou améliorer un logiciel. Habituellement, une solution rapide – et souvent aléatoire, en plus. Lorsqu'il s'agit d'appliquer des correctifs, il n'est toutefois pas toujours possible de transférer directement la pratique informatique quotidienne vers l'OT.

Quand il s'agit de patcher, l'IT et l'OT parlent des langages différents.

Il est essentiel que l'industrie IIoT - IT et OT se réunissent au profit de leurs entreprises. Cela nécessitera une réflexion plus approfondie et avec plus d'imagination pour développer des techniques de cybersécurité robustes. Par nécessité, ces opérations devront être plus agiles et efficaces que les correctifs réflexifs.

Les correctifs peuvent créer des problèmes pour OT. Comme nous le voyons avec les correctifs pour les vulnérabilités du processeur Meltdown et Spectre, un correctif peut parfois aggraver les choses. Les premiers correctifs pour Meltdown et Spectre ont eu un impact sur les performances de l'ensemble du système.

La dure vérité est que le ventre mou de l'économie industrielle moderne est en grande partie de vieilles machines OT. Dans le monde de l'informatique, si quelque chose est infecté, le premier réflexe est de l'arrêter rapidement et de le corriger (ou de le remplacer). Mais en OT, c'est souvent le contraire qui est vrai :continuez à fonctionner.

Certains systèmes OT cruciaux sont installés dans les usines depuis 15 à 25 ans ou plus. Ces bébés ne peuvent pas être facilement démontés et rapiécés. Même si un correctif approprié était disponible, ces systèmes n'ont généralement pas assez de mémoire ou de bande passante CPU pour accepter les correctifs.

Enfin, se pose le problème de la complexité et de la fragilité relatives des systèmes OT par rapport aux systèmes informatiques.

Les systèmes informatiques peuvent être démontés, corrigés et redémarrés pour fournir un service identique. Le service informatique peut exécuter des racks chargés de serveurs identiques, et si l'un tombe en panne ou brûle, le suivant prend le relais sans accroc. Mais les systèmes OT sont souvent des combinaisons hautement orchestrées de logiciels et de matériel qui ont des « personnalités ».

Même lorsque les entreprises peuvent démonter des machines pour les corriger – lorsqu'elles redémarrent – ​​les résultats peuvent être imprévisibles. Ce n'est pas le même système car le patch a introduit des wild cards qui peuvent proliférer via d'autres éléments du système.

En OT, l'imprévisibilité n'est pas acceptable.

Résumé : il doit y avoir un meilleur moyen de protéger les systèmes IIoT que d'appliquer des correctifs par réflexe OU d'ignorer une menace de sécurité, car l'application de correctifs n'est tout simplement pas faisable - pour toutes les raisons que je viens de décrire.

LA MEILLEURE MÉTHODE :« ANALYSE DES MENACES »

La meilleure approche dans OT est d'examiner les défis de sécurité d'une manière beaucoup plus granulaire qu'actuellement. Je propose que nous utilisions l'ancienne approche d'analyse des menaces pour appliquer des correctifs.

Première étape de l'analyse des menaces :

Ne prenez aucune mesure immédiate. Cela signifie qu'il faut retenir le patch, pas le patch, quoi que ce soit d'autre. Attendez une seconde jusqu'à ce que nous validions si une vulnérabilité du système existe réellement - et si c'est le cas - comment peut-elle être exploitée ?

Il y a plusieurs facteurs à considérer.

Certains systèmes qui opèrent au plus profond des entreprises peuvent en effet présenter des vulnérabilités. Parce que le système est si isolé au sein de l'entreprise, le risque de sécurité réel est moins que le risque d'arrêter les systèmes pour appliquer des correctifs - en supposant qu'un correctif existe même.

Le calcul change lors de l'évaluation des systèmes qui sont exposés au Cloud ou à Internet - c'est là que le risque de sécurité est évidemment beaucoup plus grand.

Analyse des menaces :

Analyse des menaces : identifierait alors rapidement quels systèmes peuvent probablement continuer à fonctionner sans correctifs, et quels systèmes doivent être arrêtés pour le correctif.

Analyse des menaces : validerait également une vulnérabilité. Il est important de poser une autre question :si cette vulnérabilité peut être exploitée par certaines menaces, y a-t-il un moyen d'arrêter ce à moins de patcher ?

Par exemple, les experts en sécurité peuvent créer un ensemble de scripts prédéterminés au sein du réseau ou sur le périphérique lui-même. Cela aiderait à identifier la réponse appropriée à un certain nombre de menaces différentes. Ces scripts serviraient de modèle « si/alors » pour formaliser, automatiser et accélérer les réponses aux menaces. Le but est de penser avec plus de sophistication qu'une décision binaire patch/ne pas patcher.

Les éditeurs de logiciels doivent soutenir le développement de l'analyse des menaces en informant les clients sur les correctifs qu'ils publient. Les informations clés que nous aimerions voir sont la manière dont les vulnérabilités peuvent être exploitées et les moyens possibles de s'en protéger.

Cette transparence supplémentaire donnerait aux clients plus d'informations pour prendre des décisions sur les bonnes mesures de sécurité pour les systèmes concernés. Les experts en sécurité doivent être sûrs qu'un correctif conservera, à tout le moins, le même niveau de risque qu'avant la découverte d'une vulnérabilité.

Analyse des menaces : doit être extrêmement granulaire. Si une entreprise a 100 appareils en cours d'exécution, chacun nécessite sa propre analyse des menaces, qui inclurait une comparaison des vulnérabilités par rapport aux avantages des correctifs, ainsi qu'un « menu » résultant d'options de sécurité.

L'objectif principal, bien sûr, est d'améliorer la sécurité tout en maximisant la disponibilité de l'OT.

Analyse des menaces : est plus nuancé et multidimensionnel que les décisions d'application de correctifs go/no-go.

Mais il y a un défi que l'industrie doit résoudre pour arriver d'où nous sommes à là où nous devrions être :à l'heure actuelle, suivre le processus décrit ci-dessus prend du temps, coûte de l'argent, nécessite des professionnels hautement qualifiés - et même alors, ce n'est pas facile à faire.

La communauté des fournisseurs doit commencer à agir sur un ensemble de normes convenu. Nous avons besoin de normes, voire d'une législation, sur la manière dont les rapports et les vulnérabilités seront traités. Signification – non dissimulé. Tout ce processus peut être automatisé.

Ce qui a si bien fonctionné dans l'informatique ne correspond tout simplement pas à l'OT.

Il est temps d'innover à l'échelle de l'industrie au-delà du choix entre patch, patch, patch - ou de laisser les systèmes non patchés fonctionner vulnérables.

Notre objectif doit être de créer des processus puissants et efficaces, puis d'automatiser eux de mettre cette nouvelle approche. Tout cela peut être à la portée des entreprises industrielles et des nations à l'échelle mondiale.

Ce n'est pas parce que nous pouvons clairement voir cet avenir meilleur qu'il est proche.

Mais commençons maintenant à y arriver, ensemble.