Fabrication industrielle
Internet des objets industriel | Matériaux industriels | Entretien et réparation d'équipement | Programmation industrielle |
home  MfgRobots >> Fabrication industrielle >  >> Industrial Internet of Things >> Technologie de l'Internet des objets

Les programmes obscurs et complexes de divulgation des vulnérabilités entravent la sécurité

La plupart des vulnérabilités des produits sont désormais découvertes non par le fournisseur concerné, mais par des sources extérieures comme des chercheurs tiers, et ils sont partout.

Les vulnérabilités qui créent des failles de sécurité potentielles dans les produits de l'Internet des objets (IoT) et des systèmes de contrôle industriel (ICS) ne cessent de croître.

Plus de 600 ont été divulguées au premier semestre de cette année, selon le dernier rapport ICS Risk &Vulnerability de Claroty. La plupart sont de gravité élevée ou critique, peuvent être exploités facilement et à distance et rendent le composant affecté complètement inutilisable. Un quart n'a pas de solution ou ne peut être que partiellement corrigé.

Un exemple de l'épave potentielle qui pourrait être causée par des vulnérabilités inconnues qui se cachent dans la chaîne d'approvisionnement logicielle est le cluster BadAlloc récemment nommé dans RTOS et prenant en charge les bibliothèques de plusieurs fournisseurs. Ceux-ci peuvent être exploités pour des attaques par déni de service ou l'exécution de code à distance.

cliquez pour l'image en taille réelle

(Source :Institut national des normes et de la technologie)

Des millions d'appareils IoT et de technologie opérationnelle (OT) - ainsi que des systèmes grand public comme les voitures et les appareils médicaux - sont potentiellement concernés. Pourtant, les utilisateurs OEM et propriétaires d'actifs ne savaient pas que ces failles existaient jusqu'à ce que Microsoft les dévoile en avril.

Pourtant, la plupart des vulnérabilités des produits sont désormais découvertes non par le fournisseur concerné, mais par des sources externes telles que des chercheurs tiers. C'est pourquoi les programmes de divulgation des vulnérabilités (VDP) existent. Comme l'explique le Guide ultime de la divulgation des vulnérabilités de Bugcrowd 2021, les VDP ont été mis en place pour fournir « un mécanisme d'identification et de correction des vulnérabilités découvertes en dehors du cycle de développement logiciel typique ». Ils sont généralement gérés par des entités fédérales, des organisations sectorielles et certains grands fournisseurs de produits.

Aucune cohérence entre les programmes

En réponse à une directive opérationnelle contraignante de septembre 2020 de la Cybersecurity and Infrastructure Security Agency (CISA), les agences fédérales publient leurs politiques de divulgation des vulnérabilités – ce qui prête à confusion, également indiqué par l'acronyme « VDP ». En juillet, CISA a annoncé sa plate-forme VDP. Fourni par Bugcrowd et EnDyna, il servira aux agences fédérales civiles en tant que site géré de manière centralisée où les chercheurs en sécurité et autres pourront signaler les vulnérabilités sur les sites Web des agences.


Ron Brash

Mais la plupart des VDP régissent les vulnérabilités des produits, pas les processus ou les configurations. Malheureusement, il y a très peu de cohérence entre eux. « Ces programmes sont partout :même les agences fédérales américaines font leur propre truc », a déclaré Ron Brash, directeur des informations sur la cybersécurité pour Verve Industrial Protection, à EE Times . « Aucun d'entre eux n'est configuré pour une efficacité maximale. » Même ceux qui disposent de bons mécanismes, tels que les programmes NIST et ISO/IEC, présentent des disparités entre ces mécanismes :ce qui est signalé et comment, l'application et la manière dont les modifications requises sont apportées par un groupe donné.

Brash a également reproché un manque de transparence dans les rapports. Le gouvernement américain n'a pas développé le code pour les produits de type COTS qu'il achète généralement, de sorte que les agences fédérales n'en ont pas la propriété réelle et doivent agir comme agents de la circulation, a-t-il déclaré. « Les personnes qui devraient faire la « police » n'ont pas les connaissances nécessaires pour vraiment comprendre les problèmes en jeu ou leur impact ; ne peut pas corriger efficacement les vulnérabilités en raison de budgets, d'approbations, d'une plate-forme EoL inadéquate ou de l'incapacité d'inciter un fournisseur à fournir un correctif ; et n'ont pas les moyens d'appliquer des conséquences ou de forcer des améliorations. »

La propriété fait également défaut pour un avis donné et pour la synchronisation de ce qui est fait à ce sujet entre les programmes gouvernementaux et les portails des fournisseurs. "C'est le meilleur effort", a déclaré Brash. « Les grands fournisseurs s'approprient souvent, mais leurs multiples unités commerciales peuvent toutes le faire différemment. Étant donné que chaque produit peut combiner plusieurs produits, le nombre de fournisseurs se multiplie encore plus. »

Le système de rapport CVE a des limites

La CISA parraine les deux VDP américains les plus centraux :la base de données nationale sur les vulnérabilités (NVD), hébergée par le National Institute of Standards and Technology (NIST), et le programme Common Vulnerabilities and Exposures (CVE), un peu plus ancien, géré par MITRE, qui détaille publiquement vulnérabilités connues. CISA héberge également les avis de l'ICS-CERT, qui incluent les exploits et les problèmes.

"Même si nous ignorons l'ensemble du processus de divulgation et des aspects de recherche, le système [de signalement CVE] est obscur et complexe", a déclaré Brash. « La plupart des propriétaires d'actifs n'ont pas les connaissances nécessaires pour bien comprendre les avis de sécurité OT/ICS ou pour y donner suite. Ainsi, ils deviennent paralysés par la quantité d'informations. Cette complexité devient évidente en regardant la présentation YouTube de Brash, un 101 pour les déchiffrer.

Le système CVE n'inclut pas tout :un nombre croissant de vulnérabilités n'y apparaissent pas. Selon Risk Based Security, 2 158 vulnérabilités ont été publiées en juillet, dont 670 sans ID CVE.

« Les CVE sont limités aux vulnérabilités affectant un large éventail de logiciels que de nombreuses entreprises peuvent utiliser », a déclaré à EE Times le chercheur indépendant en sécurité John Jackson, fondateur du groupe de piratage éthique Sakura Samurai. . « [Mais] une vulnérabilité peut être spécifique à la logique d'un logiciel ou d'un serveur détenu par une seule entreprise. »

Les PDV fédéraux ciblent principalement les agences fédérales, a déclaré Brash. Peu de choses sont disponibles pour les entreprises commerciales :quelques industries ont leurs propres régulateurs, comme la North American Electric Reliability Corporation (NERC) pour les services publics d'électricité. Bien que les politiques et procédures des agences fédérales puissent être reproduites pour une utilisation dans le secteur privé, celles-ci peuvent changer à chaque élection présidentielle, a-t-il souligné.

« Certains projets communautaires open source gèrent assez bien les divulgations de vulnérabilités », a déclaré Brash. « Par exemple, certaines parties du noyau Linux sont bien gérées; d'autres pas tellement, et cela ne tient même pas compte de l'écosystème Linux global. Et par rapport à d'autres projets de logiciels libres et open source, ou même à divers produits propriétaires, ils ont également des pratiques de sécurité très variables. »

Signalement, problèmes de divulgation

Le manque de cohérence entre les programmes, en particulier dans les rapports, peut mettre les chercheurs tiers dans une impasse, sans parler des problèmes juridiques potentiels causés par la Computer Fraud and Abuse Act (CFAA).


John Jackson

"Beaucoup de VDP exigent des pirates qu'ils ne discutent pas de leurs découvertes, mais les programmes ne les paient pas et ne les incitent même pas à pirater", a déclaré Jackson. « De plus, ils sont généralement mal gérés ou mal gérés par du personnel n'appartenant pas à la sécurité, ce qui rend la collaboration difficile. Les VDP utilisant Bugcrowd sont un bon début car ils permettent aux pirates de collaborer efficacement et les trieurs peuvent d'abord examiner la vulnérabilité pour la confirmer. Néanmoins, cela n'atténue pas le besoin d'une sécurité régulière. »

Un rapport de 2016 du NTIA Awareness and Adoption Group a déclaré :« La grande majorité des chercheurs (92 %) s'engagent généralement dans une certaine forme de divulgation coordonnée des vulnérabilités. La menace de poursuites judiciaires a été citée par 60% des chercheurs comme raison pour laquelle ils pourraient ne pas travailler avec un fournisseur pour divulguer. Seuls 15 % des chercheurs s'attendaient à une prime en échange de la divulgation, mais 70 % s'attendaient à une communication régulière sur le bogue."

Selon le guide ultime de Bugcrowd 2021, 87% des organisations possédant leur propre VDP ont déclaré en avoir obtenu une vulnérabilité critique. Mais alors que 99 % déclarent envisager de rejoindre leur VDP avec un programme de primes de bogues, seuls 79 % déclarent payer les chercheurs pour des « résultats percutants ».

Parce que le problème devient particulièrement compliqué avec les vulnérabilités des produits IoT intégrés, le processus de divulgation devrait être standardisé, a déclaré Brash. Il doit également y avoir « un bâton pour l'appliquer », à la fois du côté du propriétaire de l'actif et du côté du développeur de produits OEM. Il envisage un registre pour les produits IoT intégrés comme ceux pour les rappels de voitures. « Je pense que le fournisseur et l'intégrateur de système devraient s'assurer qu'un propriétaire d'actif est au moins informé d'une vulnérabilité dans son actif. Comme dans le cas d'un rappel de voiture, le propriétaire peut alors décider d'accepter le risque, de le faire réparer ou d'acheter un produit différent. »

>> Cet article a été initialement publié sur notre site frère, EE Fois.


Technologie de l'Internet des objets

  1. La route vers la sécurité industrielle de l'IoT
  2. Redéfinition de la sécurité du micrologiciel
  3. S'attaquer aux vulnérabilités de sécurité de l'IoT industriel
  4. Sécurité de l'IoT :à qui incombe la responsabilité ?
  5. Tout devient IoT
  6. Sécurité IoT – Un obstacle au déploiement ?
  7. Rénovation de la cybersécurité
  8. Sécuriser l'IoT par la tromperie
  9. Une liste de contrôle de sécurité ICS