Technologies

Gestion des patchs : ce caillou dans la chaussure des DSI et RSSI

Gestion des patchs : ce caillou dans la chaussure des DSI et RSSI
Même après sa disponibilité, il peut s’avérer pratiquement impossible d'appliquer un correctif. En particulier sur des environnements sensibles, comme dans l’industrie. (Photo : Msumuh/Pixabay)

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.

Publicité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 lacunes

Ces 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.

Publicité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 encombrant

En 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'attention

Elie 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é culturel

Dave 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.

Partager cet article

Commentaire

Avatar
Envoyer
Ecrire un commentaire...

INFORMATION

Vous devez être connecté à votre compte CIO pour poster un commentaire.

Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire

    Publicité

    Abonnez-vous à la newsletter CIO

    Recevez notre newsletter tous les lundis et jeudis