Auteur : Thierry Julien, PDG et fondateur, TJC Group
Le 17 octobre, la Commission européenne a dévoilé une section supplémentaire, connue sous le nom d' »annexe », à son règlement d’exécution régissant la mise en œuvre de la directive (UE) 2022/2555. La directive NIS2 est une loi de l’Union européenne (UE) qui vise à améliorer la cybersécurité dans la région. En termes simples, les entreprises telles que les fournisseurs de services de cloud computing doivent se conformer aux exigences mises à jour dans le cadre de la directive NIS2 révisée.
Le NIS2 s’applique aux entités des secteurs public et privé qui fournissent certains services ou infrastructures critiques, qui sont des entreprises de taille moyenne ou grande et qui fournissent leurs services ou exercent leurs activités dans l’UE.
Le paragraphe 6.6 de l’annexe susmentionnée traite de la gestion des correctifs de sécurité. Il n’est pas surprenant que le paragraphe 6.6.1 mentionne que ces correctifs doivent, lorsqu’ils sont disponibles, être appliqués assez rapidement, à partir de sources fiables et après avoir été testés au préalable. S’ils ne sont pas disponibles, des solutions de contournement doivent être appliquées. Ce qui est intéressant, c’est le deuxième paragraphe (6.6.2), que je cite textuellement :
« Par dérogation au point 6.6.1. a), les entités concernées peuvent choisir de ne pas
appliquer des correctifs de sécurité lorsque les inconvénients de l’application des correctifs de sécurité
l’emportent sur les avantages en matière de cybersécurité. Les entités concernées doivent dûment documenter et
justifier les raisons d’une telle décision. »
Quand cette dérogation peut-elle s’appliquer ?
Certains soutiennent que la continuité du service peut être un argument dans le contexte de la gestion du risque NIS2. Cependant, le paragraphe 6.6.1 ne demande pas un correctif immédiat, mais une approche raisonnablement rapide et testée. Par conséquent, la continuité du service ne devrait pas nécessiter de dérogation.
D’autres supposeront des dépendances de systèmes critiques, où un correctif dans un système peut avoir des conséquences plus importantes (pensez aux industries de l’énergie, des soins de santé et des transports). Un bon exemple pourrait être la vulnérabilité Meltdown en 2018 (CVE-2017-5754) affectant les processeurs. La raison pour laquelle le correctif n’a pas été appliqué était une baisse significative des performances (5 à 30 %) dans certaines applications (comme dans la recherche ou la finance). Nous pourrions également penser à la mise à jour de Windows 10 (KB4524244) en 2020.
Un autre exemple dont la plupart d’entre nous ont entendu parler est l’incapacité de Windows XP à corriger d’innombrables dispositifs médicaux. Alors que Microsoft a officiellement mis fin au support de Windows XP en 2014, nombre de ces appareils sont restés opérationnels en raison de leur coût élevé et de la longueur des cycles de remplacement. Non seulement l’application de correctifs sur ces systèmes pourrait les rendre hors d’usage (avec un risque potentiel pour la vie des patients), mais ces correctifs pourraient également invalider les certifications réglementaires.
S’agit-il d’un bar ouvert aux vulnérabilités ?
Il est assez facile de dresser une liste des violations de données dues, ou partiellement dues, à un manque de correctifs. Un cas célèbre est la violation de données à Equifax qui a commencé le 12 mai 2017, quand Equifax n’avait pas encore mis à jour son site web de contestation de crédit avec la nouvelle version de struts.
La possibilité de dérogation ne donne pas un laissez-passer, mais plutôt une approche structurée dans laquelle les entités doivent évaluer, documenter et justifier les décisions de ne pas appliquer des correctifs spécifiques.
En outre, NIS2 n’est pas la seule réglementation à prendre en compte. Prenons un seul exemple. ke RGPD, par exemple : bien qu’il n’oblige pas les organisations à appliquer tous les correctifs, il impose une norme élevée en matière de protection des données à caractère personnel. Sous RGPD, si le fait de ne pas appliquer un correctif entraîne une violation des données, l’organisation peut être confrontée à des conséquences juridiques. Les régulateurs peuvent interpréter le fait de ne pas appliquer de correctifs sur des vulnérabilités critiques – en particulier si elles étaient connues et n’ont pas été corrigées – comme un manquement à l’obligation de protéger les données à caractère personnel (article 32 – Sécurité du traitement).
Cela s’applique-t-il aux systèmes legacy de SAP ?
Oui, c’est peut-être une question étrange à poser, car les systèmes ERP SAP étaient, et sont toujours, au cœur des systèmes informatiques intégrés de la plupart des grandes entreprises dans le monde.
Tout d’abord, les systèmes legacy SAP doivent être conservés pour des raisons de contrôle fiscal, même en cas de transition vers S/4HANA par le biais d’une migration » lift and shift » (brownfield). En outre, la conservation de données commerciales historiques détaillées peut s’avérer précieuse, car elle fournit des éléments essentiels pour les modèles d’intelligence artificielle. Pourtant, de nombreux systèmes SAP sont des systèmes legacy non corrigés. Pourquoi? J’ai entendu toutes sortes de justifications, telles que…
- Oui, mais il s’agit d’une ancienne version.
- Oui, mais c’est sur une machine virtuelle, ce n’est donc pas un problème.
- Oui, les systèmes legacy ne sont pas corrigés, mais notre système actuel l’est.
- Oui, mais il est déconnecté de notre réseau externe (comme si les employés n’avaient jamais piraté leur propre entreprise).
Au moment où il est mis hors service, un système legacy ERP contient généralement une mine d’informations sensibles : informations détaillées sur les clients et les fournisseurs, dossiers des employés, actifs, détails des projets, noms des produits, détails des ventes, et même des informations propriétaires telles que les nomenclatures, les itinéraires, les coûts des produits et les marges de profit. Ces données présentent un risque élevé pour la sécurité, même si elles datent de deux à cinq ans. Si vous envisagez d’appliquer la dérogation 6.6.1, voici quelques raisons qui pourraient servir de justification « dûment documentée » à l’absence de correctifs :
- Je n’ai pas apporté de correctif au système avant de le mettre hors service.
- Les frais de maintenance n’étant plus payés, il n’était pas possible d’appliquer des correctifs. La maintenance des bases de données a également été arrêtée, ce qui peut coûter jusqu’à un quart de million de dollars par an pour une entreprise de taille moyenne.
… n’hésitez pas à en ajouter d’autres à la liste.
Oui, il est moins coûteux de laisser les systèmes non corrigés, non sécurisés et de ne pas appliquer les règles relatives à la protection de la vie privée que de se conformer aux exigences réglementaires. Mais l’article 6.6.1 suggère de ne pas appliquer de correctifs lorsque « les inconvénients de l’application des correctifs de sécurité
l’emportent sur les avantages en matière de cybersécurité » … Il ne s’agit pas de « compenser les coûts ».
Je suppose donc que les entreprises auront du mal à documenter le décommissionnement des systèmes legacy SAP, surtout maintenant qu’il existe des solutions de décommissionnement. Par exemple, consultez le siteEnterprise Legacy System Application.
Conclusion
En conclusion, le paragraphe 6.6.2 de la section 6 reconnaît qu’une approche unique des correctifs peut être peu pratique ou contre-productive dans certains contextes, mais il ne s’agit pas d’une échappatoire à la cyberhygiène responsable. Il s’aligne sur l’objectif de NIS2 d’améliorer la résilience globale sans imposer d’exigences rigides qui pourraient compromettre par inadvertance des services critiques. Il ne s’agit certainement pas d’une carte « sortie de prison ».
Plus d’informations
L’IMPÉRATIF STRATÉGIQUE : LE DÉCOMMISSIONNEMENT DES SYSTÈMES LEGACY POUR UNE MEILLEURE CYBERSÉCURITÉ
LES MACHINES VIRTUELLES POUR LES SYSTÈMES LEGACY : BON OU MAUVAIS ?
