Avec son framework SaaS Security Capability, la Cloud Security Alliance veut aider les fournisseurs cloud à intégrer les principes du zero trust dans leurs environnements et proposer à leurs clients des contrôles de sécurité plus cohérents face à l’augmentation des attaque supply chain.
Des experts en sécurité indépendants ont salué ce « premier ensemble normalisé de contrôles de sécurité SaaS ». Lancé cette semaine et soutenu par la Cloud Security Alliance (CSA), le SaaS Security Capability Framework (SSCF) promet de combler des lacunes persistantes relatives à la gestion des risques liés aux tiers. Essentiellement, le framework apporte une norme industrielle qui définit les capacités techniques minimales de sécurité requises par les applications SaaS, en particulier celles qui relèvent de la responsabilité du client dans le cadre dans ce que l’on appelle communément le modèle de responsabilité de sécurité partagée. Les entreprises ont mis en place des architectures sophistiquées de type « zero trust » autour de leurs environnements sur site et IaaS. Sauf que, depuis longtemps, les contrôles de sécurité des applications SaaS sont restés opaques. Ce décalage crée un risque massif et inutile. C’est ce risque que cherche à combler le SaaS Security Capability Framework.
La publication de ces recommandations fait suite aux récentes attaques ayant ciblé les applications SaaS de Salesforce, qui ont focalisé le secteur sur la question plus générale de la sécurité des applications cloud. Selon Lefteris Skoutaris, vice-président associé chargé des solutions de gouvernance, risque & conformité (GRC) pour la Cloud Security Alliance, « le framework SSCF comble une lacune critique dans la sécurité SaaS en établissant la première norme industrielle pour les contrôles de sécurité des opérations orientées clients. Ce framework illustre la mission de la Cloud Security Alliance qui consiste à réunir divers partenaires industriels (des fournisseurs SaaS aux entreprises clientes) en vue de créer des solutions pratiques qui traduisent les exigences de conformité en capacités de sécurité exploitables que les entreprises peuvent réellement configurer et mettre en œuvre. »
Six domaines de sécurité couverts
Le SaaS Security Capability Framework spécifie les contrôles dans les champs suivants :
• Contrôle des changements et gestion de la configuration ;• Sécurité des données et gestion du cycle de vie de la confidentialité ;• Gestion des identités et des accès ;• Interopérabilité et portabilité ;• Journalisation et surveillance ;• Gestion des incidents de sécurité, investigation informatique et analyse forensic du cloud.
Ces domaines traduisent les exigences métiers de haut niveau en fonctionnalités de sécurité SaaS tangibles que les clients peuvent réellement configurer et sur lesquelles ils peuvent compter, comme la livraison des logs, l’application de l’authentification unique Single Sign-On (SSO), les directives de configuration sécurisée et la notification des incidents. Cette approche complète plutôt qu’elle ne remplace les frameworks de sécurité d’entreprises, comme la norme ISO 27001. « Le SaaS Security Capability Framework représente une avancée significative pour le secteur », a déclaré Brian Soby, cofondateur et directeur technique du fournisseur de solutions de sécurité SaaS AppOmni, et auteur principal du SSCF. « Il fournit une norme claire, cohérente et indispensable qui aidera les entreprises à dépasser les évaluations des risques obsolètes et à véritablement intégrer les principes du zero trust dans leurs environnements SaaS. »
Vers des contrôles de sécurité SaaS plus cohérents
Le secteur est depuis longtemps confronté à un manque de cohérence dans les contrôles de sécurité SaaS. En l’absence de norme sectorielle, les entreprises, les fournisseurs SaaS et les équipes de sécurité ont fini par multiplier leurs efforts ou prendre des risques inutiles. Le SSCF relève ce défi de longue date en proposant un framework pratique de capacités de sécurité pouvant être adopté par les fournisseurs SaaS, ce qui permet d’améliorer la cohérence au sein du secteur tout en réduisant les risques de sécurité potentiels. « Le framework SSCF de la CSA représente une avancée significative pour la gouvernance SaaS, car il définit des attentes plus claires pour les fournisseurs et les acheteurs », a estimé David Brown, vice-président directeur des activités internationales chez FireMon, un fournisseur de solution de gestion des politiques de pare-feu. « Cependant, un framework ne réduit les risques que s’il se traduit par des contrôles opérationnels, notamment une visibilité continue des politiques réseau, des contrôles stricts des sorties et des vérifications automatisées de la conformité », a souligné M. Brown, ajoutant que « les entreprises qui associent les exigences du SSCF à une vérification en temps réel de la posture du réseau peuvent prouver l’efficacité des contrôles et réduire considérablement les risques liés au SaaS. »
Une part croissante du trafic Internet est générée par des acteurs non humains : des robots, des agents, des systèmes automatisés interagissent avec les applications SaaS d’une manière que la surveillance traditionnelle ne détecte souvent pas. « Le SaaS Security Capability Framework fournit une référence indispensable pour définir ce que devrait être la ‘sécurité par défaut’ dans les environnements SaaS », a fait valoir Mayur Upadhyaya, CEO d’APIContext. « L’accent mis sur les contrôles techniques dans le périmètre du client est opportun, d’autant plus que les frontières entre les utilisateurs internes, les intégrations tierces et le trafic généré par les machines continuent de s’estomper », » ajoutant que « un framework comme le SSCF ne peut être efficace que s’il reflète cette surface élargie et encourage une validation continue, et pas seulement des configurations statiques. »
Des lignes directrices de mise en oeuvre et d’audit à venir
S’il est largement adopté, le SSCF apportera aux entreprises des fonctionnalités de sécurité plus cohérentes dans l’ensemble de leur portefeuille SaaS. Les fournisseurs sauront ainsi quels contrôles de sécurité sont attendus par les clients. La prochaine phase du projet consistera à rendre le framework plus pratique en élaborant des lignes directrices de mise en œuvre et d’audit, ainsi qu’un système d’évaluation et de certification. Plutôt que de proposer des listes de contrôle que les fournisseurs sont encouragés à suivre, le SaaS Security Capability Framework s’emploiera à offrir des améliorations de sécurité mesurables.
Selon un rapport présenté lors de la conférence Black Hat Europe 2024, alors qu’ils ont été longtemps considérés comme une boîte noire opaque, les systèmes d’entreprise SAP font l’objet de plus en plus d’attaques de la part des pirates.
A l’occasion de la Black Hat Europe qui s’est tenue à Londres du 9 au 12 décembre, Yvan Genuer, chercheur principal en sécurité chez Onapsis (éditeur de sécurité des ERP), a dévoilé les résultats d’une enquête basée sur quatre années de données de renseignement sur les menaces. Elle montre qu’à partir de 2020, jusqu’à la fin de l’année 2023, les pirates ont manifesté un intérêt persistant pour les systèmes ERP de SAP. La grande majorité (87 %) des entreprises figurant sur la liste Forbes Global 2000 utilisent SAP.
L’étude à réaliser Onapsis et Flashpoint, un partenaire de recherche sur les menaces, ont analysé les activités sur les forums criminels, les incidents, les sites de chat et les sites de groupes de ransomware. Divers groupes, dont des groupes cybercriminels (FIN13 « Elephant Beetle », le groupe cybercriminel russe FIN7 et Cobalt Spider), des équipes de cyber-espionnage (APT10 en Chine) et des ‘script kiddies’, ces pirates néophytes sans compétences informatiques, mais très néfastes, s’attaquent tous activement aux vulnérabilités liées à SAP. Les vastes quantités de données détenues par les systèmes basés sur la firme allemande en font une cible pour les groupes de cyber-espionnage. D’autant que l’énorme volume de transactions attire fortement les cybercriminels avides d’argent.
Les exploits SAP, vendus par des groupes criminels
Sur les forums, les vulnérabilités CVE-2020-6287 (Recon) et CVE-2020-6207 (défaut d’authentification dans SAP Solution Manager) ont alimenté de nombreuses discussions sur la meilleure façon d’exploiter les systèmes SAP. Onapsis a cité un exemple dans lequel un prétendu exploit ciblant SAP Secure Storage a été mis en vente à 25 000 dollars en août 2020. Des acheteurs ont proposé de payer 50 000 dollars pour l’exécution de code à distance avant authentification de NetWeaver ou pour des exploits de contournement d’authentification en septembre 2020. Des messages ultérieurs proposaient jusqu’à 250 000 dollars pour des exploits fonctionnels contre les systèmes SAP.
Selon Onapsis, entre 2021 et 2023, les discussions sur les services cloud et web spécifiques à SAP ont augmenté de 220 % sur les forums de cybercriminels. Ces forums sont utilisés pour discuter de détails sur la manière d’exploiter les failles SAP, mais aussi pour échanger des conseils et des astuces sur la monétisation des compromissions SAP et sur la façon d’exécuter des attaques contre des victimes potentielles. Parallèlement, depuis 2021, le nombre d’incidents liés à des ransomwares impliquant des systèmes SAP a été multiplié par cinq (400 %). Les vulnérabilités SAP non corrigées sont également exploitées et utilisées dans les campagnes de ransomware. Selon Onapsis, les exploits critiques publics datent de quatre ans et perdent donc de leur efficacité, si bien que les acteurs de la menace recherchent des armes « fraîches ». Les brèches divulguées publiquement dans les applications SAP, comme CVE-2021-38163 et CVE-2022-22536, entre autres, sont aussi ciblées.
Les pirates en quête de vulnérabilités résolues, mais non corrigées
De nombreuses attaques exploitent des vulnérabilités connues, mais non corrigées dans les systèmes SAP. Selon Onapsis, la demande de failles SAP non corrigées de la part de divers groupes ne fait que croître, car elles représentent un retour sur investissement potentiellement énorme. « SAP n’est plus une boîte noire, et il faut désormais considérer les applications SAP comme des cibles », a averti Yvan Genuer d’Onapsis, ajoutant que les systèmes exposés à Internet n’étaient pas les seuls à être piratés.
Selon l’éditeur en sécurité, la complexité des systèmes SAP et leur intégration dans des processus d’entreprise plus larges posent des défis uniques en matière de protection. Les entreprises doivent donner la priorité à la gestion régulière des correctifs, à l’évaluation des vulnérabilités et à l’adoption de pratiques avancées de renseignement sur les menaces avant d’avoir une longueur d’avance sur les menaces potentielles.
Des tiers ont la même analyse
Des experts tiers indépendants sont d’accord avec les conclusions d’Onapsis et reconnaissent que les systèmes basés sur SAP intéressent de plus en plus les attaquants. « Les systèmes SAP sont des cibles de choix pour les attaquants en raison de leur rôle essentiel dans la gestion des opérations des grandes entreprises et du stockage de données sensibles comme les transactions financières, la propriété intellectuelle et les informations personnelles », a déclaré Chris Morgan, analyste principal du renseignement sur les cybermenaces chez ReliaQuest. « Le développement d’un exploit capable de déchiffrer le stockage sécurisé et de faciliter le mouvement latéral au sein des systèmes SAP indique un niveau élevé d’expertise technique et d’effort, ce qui justifie un prix élevé. »
Par exemple, sur un forum cybercriminel de premier plan, ReliaQuest a découvert un exploit ciblant les systèmes SAP proposé pour près de 25 000 dollars (payables en bitcoins) et initialement listé en août 2020. L’exploit est censé faciliter les mouvements latéraux au sein des systèmes ciblés. « Le message prétend que l’exploit peut utiliser SAP Secure Storage pour découvrir des identifiants, élever les privilèges et finalement compromettre d’autres systèmes SAP au-delà de la cible initiale », a rapporté ReliaQuest. Secure Storage est essentiel pour la gestion des données sensibles et des informations d’identification dans un environnement SAP, ce qui rend tout exploit visant les systèmes SAP extrêmement précieux pour quiconque cherche à obtenir un accès non autorisé ou à élever ses privilèges.
Les bonnes pratiques de gestion des correctifs restent partiellement respectées, malgré de meilleurs outils et les changements des organisations IT. Comme l’a démontré de façon éclatante la panne Crowdstrike.
Le déploiement des correctifs de sécurité reste un défi en entreprise, malgré les améliorations apportées à la fois à l’évaluation des vulnérabilités et aux technologies de mise à jour. Les priorités divergentes, les défis organisationnels et la dette technique continuent de transformer l’objectif apparemment simple de maintien à jour des systèmes en véritable casse-tête, selon les experts interrogés.À cause de ces difficultés, environ 60 % des applications d’entreprise ne sont pas corrigées six mois après la publication d’une vulnérabilité, selon l’éditeur de solutions de sécurité cloud Qualys. Seules 40% des entreprises corrigent les vulnérabilités critiques dans les 30 premiers jours qui suivent leur divulgation.La prolifération des applications ne rend pas service à l’informatique d’entreprise. Une étude récente de la société Adaptiva, spécialisée dans la gestion des correctifs, a révélé qu’en moyenne, une entreprise gère 2 900 applications. Cela fait beaucoup de correctifs potentiels à apporter, surtout que le nombre de vulnérabilités détectées ne cesse d’augmenter.Autant de facteurs qui contribuent à augmenter la probabilité d’une interruption de l’activité de l’entreprise. « Plus une entreprise doit déployer de correctifs, plus le risque de temps d’arrêt est élevé en raison de redémarrages ou de l’interruption d’une application par un correctif », résume Eran Livne, directeur principal de la gestion des produits chez Qualys.L’automatisation et ses lacunesCes dernières années, la gestion des correctifs est devenue une pratique de réduction des risques, les entreprises alignant les workflows de sécurité et de remédiation et donnant la priorité aux vulnérabilités à corriger en fonction de calculs d’exposition, de la probabilité d’un arrêt dû à la mise à jour et des coûts potentiels d’un tel arrêt.Selon Sanjay Macwan, DSI et RSSI de la plateforme de communication Vonage, « les entreprises doivent s’assurer qu’elles disposent d’un inventaire actualisé de leurs ressources afin de suivre tous les composants nécessitant des correctifs, ainsi que de politiques formelles et rigoureuses que chaque équipe doit suivre afin de coordonner une application efficace et en temps voulu des correctifs. Les correctifs devraient se voir associer des niveaux de risque afin de déterminer l’ordre dans lequel ils sont traités, et les équipes devraient disposer de processus de déploiement clairs, y compris une surveillance post-patch afin de détecter les erreurs critiques » consécutives au déploiement des correctifs.Eran Livne préconise l’utilisation d’outils d’automatisation « pour aider à réduire le travail manuel nécessaire à la gestion d’un grand nombre de vulnérabilités, en particulier celles les plus simples à corriger, et touchant les navigateurs, les lecteurs multimédias et les lecteurs de documents ». Grâce à l’automatisation des patchs de moindre priorité, les équipes chargées des opérations IT et de la sécurité peuvent se concentrer sur les correctifs de sécurité critiques et urgents.
Malgré leurs promesses, les outils automatisés ont leurs limites, prévient toutefois Rich Newton, consultant chez Pentest People : « les priorités de correction recommandées par les outils en fonction de la gravité des vulnérabilités ne correspondent pas toujours à la tolérance au risque spécifique de l’organisation ou à ses objectifs métiers, ce qui souligne la nécessité d’une supervision humaine. S’appuyer uniquement sur une solution de gestion des correctifs, en particulier dans les environnements informatiques complexes, peut s’avérer futile. Tous les systèmes ne peuvent pas être entièrement pris en charge par des outils automatisés, d’où la nécessité de mettre en place des politiques et des procédures de surveillance et d’évaluation continues de l’état des correctifs dans l’ensemble du parc informatique. »
Elie Feghaly, RSSI de l’entreprise de technologie de diffusion Vizrt, reconnaît que, bien que les outils d’évaluation des vulnérabilités et de correction automatisée soient très utiles, ils ne constituent pas la panacée. « Les rôles de remédiation automatisés sur des environnements informatiques compliqués s’accordent rarement avec des environnements très dynamiques et potentiellement sujets à des erreurs », explique-t-il.Le facteur Legacy – et son héritage encombrantEn outre, la grande majorité des environnements informatiques complexes exploitent une grande quantité de logiciels Legacy qui ne sont plus corrigés par leur fournisseur, souligne Martin Biggs, vice-président et directeur général pour la région EMEA chez Spinnaker. « Et lorsque des correctifs sont disponibles, ils peuvent être source de perturbations et nécessitent des tests de régression approfondis avant d’être déployés », souligne-t-il.Pour les environnements sensibles, il peut ainsi s’avérer pratiquement impossible d’appliquer un correctif, même lorsqu’il est disponible. Dans d’autres cas, l’application du correctif ne résout pas la vulnérabilité sous-jacente, qui n’est traitée que dans des mises à jour ultérieures, prévient Martin Biggs. « Il est tout à fait habituel dans le monde Oracle que la même vulnérabilité soit à nouveau corrigée par des correctifs publiés plusieurs trimestres après le correctif original », illustre-t-il. Avec de tels incertitudes et effets, voir de nombreuses entreprises tâtonner dans leur stratégie de gestion des correctifs n’est guère surprenant.Les tests au centre de l’attentionElie Feghaly (Vizrt) souligne un autre problème courant auquel les entreprises sont confrontées en matière de gestion des correctifs : « un correctif fonctionne parfaitement dans le laboratoire de test ou d’essai, mais provoque des dégâts considérables en production en raison d’une dépendance inattendue à l’égard d’une autre application. » Même si les facteurs externes et dépendances sont précisément les raisons principales plaidant pour le renforcement des tests. La panne très médiatisée du mois de juillet, causée par une mise à jour défaillante du contenu de Falcon par CrowdStrike et qui a fait tomber des systèmes dans le monde entier, a permis de remettre en pleine lumière l’importance des tests avant le déploiement des correctifs.« Les outils d’évaluation des vulnérabilités et d’application automatisée des correctifs peuvent considérablement atténuer les difficultés liées à la gestion des correctifs en assurant une surveillance continue, en identifiant les vulnérabilités en temps réel et en automatisant le déploiement des correctifs sans intervention manuelle », souligne Chris Morgan, analyste principal en matière de renseignement sur les cybermenaces chez ReliaQuest. « Toutefois, leur efficacité dépend d’une configuration adéquate, de mises à jour régulières et d’une intégration dans des pratiques de sécurité plus larges. Les correctifs doivent être testés de manière approfondie et déployés initialement sur un sous-ensemble réduit de systèmes, afin de minimiser le risque de pannes dues à des correctifs défectueux. »Thomas Richards, directeur associé du Synopsys Software Integrity Group, explique que les environnements de test automatisés peuvent contribuer à réduire le risque de perturbation. Mais pas si vous n’avez qu’une visibilité limitée sur ce qui doit être corrigé en amont. « Le défi auquel nos clients sont souvent confrontés consiste à configurer correctement les outils pour scanner et patcher tous les systèmes actifs de leur organisation, dit-il. Les raisons pour lesquelles les systèmes ne sont pas couverts par ce processus sont multiples : dispositifs anciens, mauvaises configurations, Shadow IT, systèmes qui devraient être mis hors service mais qui sont restés en ligne, etc. La partie la plus importante d’un programme de correction de vulnérabilités est de s’assurer qu’il couvre bien tous les systèmes sont couverts par ce programme et qu’ils font bien l’objet de mises à jour régulières. »Combler le fossé culturelDave Harvey, directeur de l’équipe de cyber-réponse chez KPMG en Grande-Bretagne, affirme qu’en plus d’une priorisation et d’une remédiation appropriées, une stratégie de gestion des correctifs réussie dépend de « l’intégration de renseignements efficaces sur la menace, d’un examen régulier et d’une collaboration efficace entre les équipes IT et de sécurité ». Sur ce dernier point, Madeline Lawrence, Chief Brand Officer de la société belge de cybersécurité Aikido Security, explique que les équipes d’ingéniérie se sentent souvent « dépassées et agacées » lorsqu’elles traitent des vulnérabilités de sécurité.Car il faut tenir compte du décalage total de mentalité entre les équipes de sécurité, « qui ont appris à envisager toutes les possibilités », et les développeurs, qui aiment « les raccourcis et l’efficacité », ajoute-t-elle. « Pour de nombreux développeurs, les équipes de sécurité qui se présentent avec des demandes s’apparentent à des trouble-fête. Cette différence fondamentale d’approche et de priorités pose des problèmes considérables aux organisations qui tentent d’amener les équipes chargées des opérations IT et de la sécurité à collaborer plus étroitement pour résoudre les failles de sécurité. »Selon Madeline Lawrence, « combler ce fossé ne passe pas seulement par de nouveaux outils ou processus, il faut aussi s’attaquer au fossé culturel et de communication qui sépare ces équipes clefs pour ce sujet, mais souvent mal alignées ». Au coeur de ce fossé se trouve le fait que les équipes chargées des opérations IT accordent la priorité à la disponibilité et aux performances des systèmes, tandis que les équipes chargées de la sécurité se concentrent sur l’atténuation des menaces. Cette tension entraîne souvent des conflits et des retards dans la résolution des problèmes de sécurité.Objectifs communs pour les devs, les ops et la sécurité« Ce défi est encore accentué par la complexité des environnements informatiques modernes, qui couvrent plusieurs plateformes et rendent difficile le maintien de la visibilité et du contrôle », souligne Christiaan Beek, directeur pour l’analyse des menaces chez Rapid7. « Il est également courant de constater des différences de tolérance au risque entre les équipes, ce qui peut conduire à des désaccords sur les vulnérabilités à prioriser, retardant ainsi les actions nécessaires. »Pour que les opérations informatiques, les développeurs de logiciels et les équipes de sécurité soient sur la même longueur d’onde, Eran Livne (Qualys) conseille de se concentrer sur des objectifs communs : « travailler sur des objectifs communs facilite la collaboration, la communication et l’élimination des risques. Cela permet également de renforcer la responsabilité de toutes les équipes concernées, plutôt que de les voir se rejeter la faute entre elles, comme cela s’est produit dans le passé. »Selon Rich Newton, de Pentest People, « il est possible d’améliorer considérablement les pratiques d’application des correctifs en en faisant une propriété conjointe entre les équipes informatiques et les équipes de sécurité. » Un avis que partage Dave Harvey (KPMG), pour qui les entreprises performantes intègrent des pratiques sécurisées dès le début de leurs processus de développement : « l’intégration de la sécurité et de la gestion des risques dans le processus de développement, dès son origine, permet une meilleure compréhension des problématiques, de sorte que les systèmes sont conçus et construits de manière sûre. »Afin de maîtriser leurs risques, les entreprises doivent donc surveiller leurs ressources informatiques en temps réel, ce qui leur permet de détecter les problèmes dans leur infrastructure le plus rapidement possible. Même si tous les problèmes de sécurité ne sont pas identiques. Moins de 1 % des vulnérabilités CVE publiées cette année ont été exploitées, il est donc impératif de se concentrer sur les risques qui comptent pour l’entreprise – et de le faire en se basant sur les données.
6 % des actifs IT sont en fin de vie et près d’un tiers sont mal gérés selon une étude menée par Sevco. Avec à la clé de faire peser un risque toujours plus grand de vulnérabilités non corrigées.
Les actifs informatiques en fin de vie exposent potentiellement les entreprises à des failles connues mais non corrigées. Et il ne faut pas croire qu’elles sont inexistantes : selon une analyse de données brutes agrégées à partir de la visibilité d’1,2 million d’actifs informatiques (serveurs, postes, terminaux…) de ses clients et prospects, Sevco estime qu’ils représentent 6 % de l’ensemble des actifs IT. L’étude du fournisseur en solutions d’analyses des risques cybersécurité a également indiqué que 28 % de tous les actifs IT ne sont pas soumis au moins à un contrôle critique à savoir de protection des endpoints ou de gestion des correctifs. Des experts tiers ont déclaré que les problèmes posés par les logiciels obsolètes et les systèmes informatiques fantômes, c’est-à-dire des technologies non approuvées, utilisées par les employés en dehors de toute administration ou de tout contrôle par le département informatique, sont de plus en plus nombreux.
« Le volume et la disponibilité d’appareils non standard, non gérés, exposés à Internet et configurés par des utilisateurs qui ne se préoccupent pas de la sécurité augmentent de façon exponentielle », a déclaré Rik Ferguson, vice-président de l’activité analyse avancée de la sécurité chez Forescout. « Souvent, ces terminaux ne sont pas aussi bien sécurisés ou aussi visibles que le parc IT traditionnel et ils restent donc particulièrement vulnérables. » Le mois dernier, un acteur malveillant a tenté de vendre un accès à l’entreprise de sécurité dans le cloud Zscaler. Suite à une enquête, ce fournisseur a découvert qu’un serveur de test n’était pas hébergé dans son infrastructure principale. Dans l’attaque Okta de 2023, rendue possible du fait de l’utilisation de systèmes IT non autorisés, des identifiants de l’entreprise avaient été sauvegardés sur un compte Google personnel avant l’infection d’un ordinateur portable professionnel par un logiciel malveillant. Ces évènements montrent comment le shadow IT peut conduire à des accès non autorisés et à des violations potentielles de données.
Une fin de vie à risque pour les logiciels
Les logiciels obsolètes présentent des risques importants car ils augmentent la surface d’attaque et rendent les entreprises plus vulnérables aux exploits. Par exemple, une version obsolète de JavaScript a contribué à une violation très médiatisée contre British Airways en 2018. Le risque posé par les systèmes Windows XP obsolètes dans les hôpitaux britanniques, et ailleurs, a été révélé par le tristement célèbre logiciel malveillant Wannacry en 2017. Les actifs informatiques considérés en fin de vie (End of Life, EOL) par les fournisseurs ne bénéficient plus de mises à jour logicielles régulières ou de correctifs de sécurité dans le cadre des contrats de maintenance standard, même si certains fournisseurs proposent une assistance étendue payante. Par exemple, pour bénéficier de trois ans de mises à jour de sécurité étendues après octobre 2025, date de la fin de support de l’OS, il faut débourser 427 $ pour un seul PC Windows 10, soit un peu moins que les 490 $ demandés par Microsoft pour recevoir des correctifs pour Windows 7 jusqu’en 2023. Même si les entreprises peuvent bénéficier de prix plus avantageux, il n’est pas surprenant que certaines organisations à court d’argent décident de prendre le risque de se passer de ces mises à jour
Selon Javvad Malik, responsable de la sensibilisation à la sécurité chez KnowBe4, « le risque le plus important lié aux logiciels obsolètes se situe dans les secteurs qui n’ont jamais été connectés à Internet, par exemple les hôpitaux ou les infrastructures critiques, souvent équipés de logiciels obsolètes ». Ilia Kolochenko, CEO d’ImmuniWeb, affirme que les problèmes de l’informatique fantôme et des logiciels obsolètes sont « profondément liés ». « Pour lutter contre les risques du shadow IT, les entreprises doivent maintenir et mettre à jour en permanence un inventaire complet de tous leurs systèmes, logiciels, utilisateurs, comptes, données et tiers qui ont accès aux données de l’entreprise », a déclaré Ilia Kolochenko. Comme l’a montré l’étude de Sevco, même les systèmes IT officiellement approuvés ne sont pas toujours tenus à jour, tout comme ceux qui ne disposent pas d’un système approprié de gestion des correctifs. Par exemple, c’est une version non corrigée, mais éminemment corrigible, d’Apache Struts qui a permis le grand vol de données d’Equifax en 2017.
Une réponse humaine, pas seulement technologique
Les experts s’accordent pour dire que les entreprises doivent procéder à des audits et à des évaluations des risques approfondis. Les meilleures défenses impliquent une gestion rigoureuse de la configuration, un suivi de la nomenclature des logiciels, une sensibilisation à la sécurité et une limitation de ce qui peut être installé. « Il est essentiel de bien connaître sa surface d’attaque et de réaliser régulièrement des exercices de cartographie des actifs externes », a expliqué Tim West, directeur de la veille sur les menaces chez With Secure. « Il est important de comprendre que la réponse n’est pas uniquement technologique. Il y a un élément humain derrière le shadow IT et les raisons pour lesquelles elle existe. La formation et la garantie que les processus existants répondent aux besoins du personnel sont tout aussi essentielles », a-t-il poursuivi. « Même des développeurs de logiciels expérimentés peuvent oublier un conteneur qu’ils ont déployé dans un cloud avec des données de production, pour expérimenter de nouvelles fonctionnalités, et ne parlons pas des utilisateurs non techniciens qui utilisent leurs ordinateurs personnels ou leurs appareils mobiles pour des tâches professionnelles », a rappelé Ilia Kolochenko.