La gestion des mises à jour : Une ligne de défense négligée
Gestion des mises à jour: EternalBlue (MS17 – 010) est un exploit utilisant une faille de sécurité présente dans la première version du Protocole SMB.
Cette vulnérabilité a permis au ransomware ‘WannaCry’ de se propager. En cause, le fait que des utilisateurs Windows n’avaient toujours pas installé le correctif de sécurité publié le 14 mars 2017.
Cette cyber-attaque met en lumière une réalité simple : la gestion des mises à jour est encore trop souvent négligée.
C’est un élément récurrent que nous rencontrons sur le terrain, lors d’audits ou de projets.
Cette situation soulève une problématique : pourquoi subsiste-il autant de vulnérabilités non corrigées ?
Il existe bien des réponses, mais dans cet article je vais me focaliser sur trois sources majeures :
Le cas des postes de travail
Pour le cas des postes de travail, si les mises à jour systèmes sont généralement appliquées de manière régulière, les applications tierces mises en œuvre dessus le sont beaucoup moins.
A cela, deux raisons, la première étant encore trop souvent liée à la liberté laissée aux utilisateurs de déployer les applications qu’ils souhaitent.
La seconde, est généralement liée à une absence, ou une mise en œuvre défaillante des outils de mise à jour.
Bien entendu, à la base, il y a toujours une absence, ou une non-application, de politique et procédures de sécurité. Enfin nous sommes toujours confrontés à la gestion de l’obsolescence.
Si les postes sous Windows 7 sont, sans surprise, encore légion, il ne faut pas oublier les générations plus anciennes, et notamment Windows XP. Cela est d’autant plus vrai dans le monde industriel.
Le cas des serveurs
Dans le cas des serveurs, la situation se complique quelque peu. En effet, la raison majeure de non mise à jour de composants reste l’obsolescence. Et cela concerne toutes les couches, Systèmes d’exploitations, middlewares et applications. En cause ?
Tout simplement que de nombreux projets de mise en œuvre de solutions ne posent pas les bases de suivi de version.
Pourtant, les contrats sont bien présents, tout le monde s’assure que l’éditeur proposera bien les mises à jour pour la durée de vie initiale de la solution.
Hélas, il n’est que trop peu souvent prévu les cycles de mise à jour, et on ne compte plus les outils business que l’on ne peut surtout pas toucher, plantés au milieu des SI, et identifiés comme composants critiques.
Et puis au milieu de tout cela, des outils intégrés aux masters, ou utilisés par un admin, laissés à l’abandon.
Il est quand même rageant de se voir fournir une machine dédiée à la mise en œuvre d’une solution de sécurité, équipée d’un célèbre lecteur de fichiers PDF vieux de cinq ans.
Affligeant de constater que deux ans après une campagne de patch urgente et massive, ayant mobilisée de nombreuses ressources, on nous livre une machine vulnérable à EternalBlue.
Oui la mise à niveau des masters, et des composants installés par défaut, sont également trop souvent négligés.
La gestion des mises à jour: par où commencer ?
Alors que faire, surtout quand on se retrouve au pied du mur de l’existant.
Avant tout, il est nécessaire d’établir une politique de sécurité qui posera le cadre de l’attendu, et qu’il faudra ensuite décliner au niveau des procédures. Ensuite, traiter la nouveauté.
Introduire dans les cycles de vie produit, les cycles de mises à jour, se poser la question de la mise en œuvre de celles-ci.
Enfin le point primordial : identifier celui, ou celle, qui sera propriétaire de cette application, et donc garant de son maintien en condition opérationnelle et de sécurité.
Une fois que le nouveau est traité, l’existant pourra concentrer votre attention. Il faudra identifier les éléments obsolètes, qui devront faire l’objet d’un projet de remplacement. Appliquer les mises à jour de sécurité qui peuvent l’être sans montée de version logicielle. Enfin, planifier les montées de version des applications et de leurs middlewares. Pour vous aider dans tout cela, iDNA peut vous proposer du conseil et des outils adaptés.