Une transfo réussie dans l'industrie !

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.