X
Le jeu du patch et de la souris
Nina Cercy / mardi 3 mars 2020 / Thèmes: Dossier, Sécurité

Le jeu du patch et de la souris

L'art du patch management

Maintenez vos systèmes à jour : voilà bien le seul conseil de sécurité universel que l’on peut donner aux départements IT. Une règle de plus en plus difficile à appliquer alors que les systèmes d’information se complexifient sans que les effectifs ne suivent.

Zero days, vulnérabilité exploitée par un hacker de génie, intrusion dans un système et fuite de données : telle est l’image d’Épinal que le grand public se fait de la cyberattaque. La réalité est plus nuancée – et bien souvent moins spectaculaire. Lorsqu’une faille de sécurité est découverte ou rendue publique, c’est rarement la réactivité de l’éditeur de la solution qui pose problème : la mise à disposition d’un correctif est généralement rapide, et la vulnérabilité est labellisée et référencée afin de permettre aux utilisateurs de la solution d’avoir de la visibilité sur la gravité et le risque associés. Reste à appliquer le correctif sur les systèmes concernés, et voilà une affaire rondement menée.

Et c’est là que le bât blesse. « La majorité des cyberattaques exploitent des vulnérabilités connues, pour lesquelles un correctif est déjà disponible, nous déclare Maxime Bollia, consultant en cybersécurité chez EY. L’attaquant est rarement le découvreur de la vulnérabilité en question : il se préoccupe surtout de passer les murailles du système pour y déposer le payload qui lui permettra, au choix, de mettre en péril la disponibilité, l’intégrité ou la confidentialité des informations de l’entreprise. Son pari : quoique le correctif existe, il est probable qu’il n’ait pas été appliqué sur les systèmes concernés. »

 

“ Patch fatigue ”

Les raisons sont multiples : le responsable de la gestion des correctifs a parfois des airs de Sisyphe au pied de sa montagne. Le nombre de correctifs appliqués chaque année par une entreprise est conséquent et les ressources qui y sont consacrées sont souvent insuffisantes. L’étude Combating Patch Fatigue de Tripwire sur plus de 450 entreprises apporte un éclairage intéressant sur cette dissymétrie : les équipes interrogées déployaient une moyenne de 188 correctifs par an en 2015, sur un nombre de terminaux qui variait entre 500 et 5 000, en dépit de ressources faibles : moins de cinq personnes dédiées à la gestion et à l’application des correctifs pour plus des deux tiers de ces entreprises.

De fait, la gestion des correctifs est porteuse d’incertitudes pour toute DSI qui gère un parc informatique conséquent : • le périmètre des actifs est en constante évolution : serveurs, middlewares, terminaux des collaborateurs et collaboratrices, la visibilité nécessaire à l’exhaustivité de la politique de gestion des correctifs ne tolère pas l’approximation ;

• l’efficacité de l’application des correctifs est difficile à déterminer : comment vérifier que le déploiement des correctifs a effectivement fonctionné ? Quels terminaux ont été patchés, lesquels sont en attente de patch ?

• quels correctifs doivent être déployés de manière urgente ?, quitte à interrompre la continuité des activités et risquer des régressions sur le système, et lesquels peuvent supporter une phase de test longue et de la flexibilité dans le déploiement.

L’interdépendance des différents composants du système d’information est également un obstacle à une politique cohérente de patch management, comme a pu le constater Maxime Bollia au cours de ses interventions en tant que consultant. « On constate globalement deux freins lorsque l’on analyse la politique de patch en entreprise. Le premier, et certainement le plus important, est lié à l’obsolescence de certains programmes métier qui ne sont plus maintenus par leurs éditeurs. Nous rencontrons régulièrement des systèmes reposant sur des versions obsolètes afin d’utiliser tel ou tel logiciel non maintenu et dont la dernière mise à jour de sécurité date d’il y a plusieurs années. Le second frein est le coût du patch. Il arrive qu’un patch nécessite une refonte applicative ou une migration système ; dans ces cas, le motif financier est souvent avancé afin de justifier l’acceptation du risque. » Que faire dans ce cas là ? « Lorsque le patch est impossible, il est conseillé d’isoler les systèmes au maximum. » Au risque qu’un attaquant parvenant à s’introduire dans le système d’information ait les mains libres sur des vulnérabilités critiques.

Déployer ou ne pas déployer, that is the question

La question de l’urgence du correctif est centrale : l’arbitrage entre les risques liés à l’application et la non application du correctif nécessite une excellente connaissance de son SI et des besoins des collaborateurs et des clients. Matthias Dugué, tech evangelist chez l’hébergeur Alwaysdata, nous explique ainsi que son entreprise doit gérer deux types de déploiements : ceux qui sont propres à la plate-forme d’hébergement développée en interne, et dont Alwaysdata maîtrise le cycle de release, et ceux qui sont propres à la stack (PHP, MySQL, Debian), dont le cycle de releases est maîtrisé par les vendeurs. « Nos clients nous font confiance pour assurer la disponibilité de leurs sites et de leurs applications, et nous devons gérer un arbitrage fin entre répondre à notre promesse de disponibilité et assurer la sécurité de leurs actifs. En cas de découverte d’une faille de sécurité sur la plate-forme, nous commençons par patcher la plate-forme Alwaysdata que nous utilisons en interne, et dont nous sommes les seuls utilisateurs : en fonction de la criticité, la phase de test dure quelques heures à quelques semaines avant le déploiement du patch sur toutes les machines mutualisées, puis sur les clients en VPS ou en dédié. Nous patchons donc progressivement le système existant et une fois que nous avons l’assurance qu’il n’y a pas de régression, nous intégrons le patch à la codebase. C’est une approche hétérodoxe, très inspirée du DevOps, mais qui fonctionne depuis 14 ans ! » La gestion des outils externes se fait également sur un souci de priorisation : « Pour la distribution et le noyau, nous privilégions la stabilité, mais nous sommes sur les rolling releases sur PHP ou Python qu’on compile et qu’on déploie, car les besoins clients sont forts sur l’hébergement. »

Patcher le patch management

Alors, comment dompter intelligemment sa gestion des correctifs ? La réponse tient en deux grands principes : anticipation et automatisation. L’anticipation est un aspect clef : les équipes ne doivent pas avoir à se poser les mêmes questions à chaque sortie de correctif – comment et sur qui le correctif va-t-il être testé ?, combien de temps ?, comment mesurer son impact ?, quelle flexibilité laisser sur les terminaux invididuels ?

Une discussion avec vos équipes vous permettra de faire émerger les questions qui se posent en permanence afin de formaliser des réponses et définir des processus de travail robustes et reproductibles.

L’automatisation, quant à elle, permet d’améliorer la productivité des équipes IT et de diminuer la réticence au patch management. La dimension manuelle de la gestion des correctifs est aujourd’hui la cause principale du découragement des équipes, malgré les nombreux outils d’automatisation de gestion des correctifs sur le marché. Ces outils automatisent le téléchargement des correctifs et leur déploiement par le réseau, répondant ainsi au besoin de visibilité, de traçabilité des actions effectuées, et de rapidité de déploiement des équipes IT. Une dernière piste prometteuse : les services de predictive patching : ils permettent d’anticiper le taux de réussite de l’application d’un correctif en analysant en amont les causes habituelles d’échec (terminaux déconnectés, licences expirées, identifiants invalides…) et font gagner un temps précieux aux équipes.

Maxime Bollia nous rappelle cependant la limite de toute automatisation de processus. « On ne peut patcher que ce dont on connaît l’existence. La cartographie exhaustive de son SI et la maîtrise de la shadow IT restent des prérequis que la mise en place d’un système d’automatisation ne doit pas faire oublier. » Une leçon à garder en tête à l’heure où les SI se complexifient pour répondre aux nouveaux besoins des collaborateurs et collaboratrices.


Tous dans le Cloud ?

Parmi les nombreuses promesses du passage au Cloud – rapidité de déploiement, maîtrise des coûts, paiement indexé à l’usage réel –, la diminution des efforts et du temps consacrés au maintien de l’infrastructure a été un argument de taille. Désormais dévolu au vendeur, le déploiement des correctifs ne devait plus peser sur les ressources de la DSI, au moins en ce qui concerne l’architecture. Mais avec le retour à une architecture hybride qui semble s’imposer comme modèle de référence, le besoin de formaliser une politique de gestion des correctifs a fait son grand retour. Difficile de donner la recette gagnante qui conviendra à toutes les entreprises, mais les experts sont unanimes : la connaissance du périmètre du SI et le suivi de l’ensemble des applications – Cloud ou on-premise – dans une solution unique est la seule façon de ne pas se laisser déborder par la multiplicité et la variété des actifs du SI moderne.

Print
4220

x
Rechercher dans les dossiers
Les derniers dossiers...
Réduire

Actuellement à la Une...
Le conflit autour des tweets du président américain escalade. Donald Trump avait promis un “BIG DAY” pour les réseaux sociaux, voici donc un décret présidentiel levant l'immunité de “bonne foi” des plateformes en ligne pour leur politique de modération. Malgré le ton martial de l’Executive Order, ce dernier pourrait bien n’être qu’une coquille vide. 

La filiale d'investissement de SAP dans les startups, SAP.iO Fund, a investi dans la seconde phase de financement d’Andjaro.

L’éditeur de solutions de sécurité et le fournisseur de CDN s’allient autour d’une approche Zéro Trust des identités des accès.

L’éditeur de la plate-forme de gestion des services par abonnements revoit sa plateforme et y ajoute des workflows préconfigurés.

Entreprise encore jeune, ThousandEyes fournit à ses clients des données sur l’état des réseaux et d’Internet, leur apportant de la visibilité en temps réel sur les performances de leurs applications. Un mets de choix pour le géant des réseaux et sa branche spécialisée dans la performance applicative, AppDynamics, sur les solutions de laquelle ThousandEyes s’appuyait déjà.

Toutes les autres News
LIVRES BLANCS

Malgré des investissements massifs dans le développement à hauteur de près de 4 milliards de dollars l'année dernière, près de la moitié du temps consacré au DevOps est perdu dans la répétition des tâches et dans la logistique. Ceci fait que 90% des entreprises qui ont adopté ces pratiques sont déçues par les résultats, selon une étude publiée par le Gartner.


Découvrez dans ce livre blanc, les avantages des toutes nouvelles solutions NETGEAR, pour simplifier et rentabiliser vos déploiements, et gérer votre réseau à distance, où que vous soyez, au bureau ou en télé-travail.


OneTrust est une plateforme logicielle innovante de gestion de la confidentialité, de la sécurité des données personnelles et des risques fournisseurs. Plus de 4 000 entreprises ont choisi de faire confiance à cette solution pour se conformer au RGPD, au CCPA, aux normes ISO 27001 et à différentes législations internationales de confidentialité et de sécurité des données personnelles.

OneTrust vous propose de télécharger le texte officiel du Règlement Général sur la Protection des Données (RGPD). Vous aurez également la possibilité de recevoir la version imprimée de ce texte, sous forme de guide pratique au format A5, spiralé, en complétant le formulaire.


Le présent guide d'achat vous aidera à améliorer l'efficacité de votre cloud hybride, en mettant l'accent sur les stratégies de gestion des données dédiées aux applications correspondantes.


Les entreprises et les organismes publics se focalisent aujourd’hui sur la transformation numérique. En conséquence, les DevOps et l’agilité sont au premier plan des discussions autour des stratégies informatiques. Pour offrir ces deux avantages, les entreprises travaillent de plus en plus avec les fournisseurs de services de cloud public et développent désormais des clouds sur site à partir d’une infrastructure qui répond à trois exigences de base:
1. Agilité sans friction des ressources physiques
2. Systèmes de contrôle optimisant l'utilisation des ressources physiques et offrant un retour sur investissement maximal
3. Intégration des divers composants de l'infrastructure pour un provisionnement et une gestion des ressources automatisés.


Tous les Livres Blancs
0123movie