Inutile de rappeler les erreurs des éditeurs de solutions antivirales ( !…), de systèmes d’exploitation quels qu’ils soient : ils ont presque tous distribué des correctifs insuffisamment ou mal testés. Restons positifs : les leçons et leurs conséquences permettent finalement de progresser vers une sécurisation de nos Systèmes d’Information, (… mais quelquefois dans la douleur ! …) d’autant que la gestion maitrisée des correctifs logiciels et la surveillance des nouvelles vulnérabilités sont prévues dans les Bonnes Pratiques de la norme ISO 27002.
Si l’objectif de la Veille est de détecter tout ce qui peut nuire à l’actif logiciel d’une entreprise et de générer les alertes correspondantes, la Gestion des correctifs logiciels, (ou « patch management »), permet de s’assurer que les remèdes sont biens appliqués et qu’ils ne seront pas pires que le mal.
Comme il est plus facile de faire référence à une situation idéale, (celle décrite par la norme) que de la mettre en œuvre en Production, je souhaite vous décrire ce que j’ai vu sur le terrain, (bien sûr les moyens utilisés sont différents suivant le contexte technique, le domaine d’activité et les contraintes Métier).
Tout d’abord la Veille : elle peut se décomposer en 3 activités cruciales :
- connaitre son actif logiciel et en tenir un catalogue détaillé,
- détecter les vulnérabilités potentielles, en collectant tout ce qui peut avoir un rapport avec les logiciels figurant dans notre catalogue et les indices d’Exploits réalisés.
- identifier les contres mesures nécessaires et les moyens de leur mise en œuvre.
Comme vous l’avez compris : la Veille est un métier complexe qui demande une réelle expertise et des moyens humains et informatiques importants.
Les sociétés qui proposent ces services emploient souvent plusieurs dizaines d’experts en exploitation des vulnérabilités et qui ont pour tâche de parcourir le Net à la recherche d’informations techniques sur des sites généralistes ou sensibles fréquentés par les Hackers du monde entier.
Ils synthétisent les informations qu’ils vont recueillir sous forme de bulletins indiquant au moins la vulnérabilité, la gravité potentielle, les contres mesures éventuelles et ce en 24/7.
L’exploitation possible d’une vulnérabilité va donc être signalée dés son identification même si son exploitation n’a pas encore eu lieu de façon industrialisée et même si il n’y a pas encore de contre mesure connue, (c’est d’ailleurs le principal différenciateur de performance entre les cabinets qui proposent de la Veille).
L’idéal pour le Veilleur, reste de débusquer des informations échangées à propos d’attaque « Zero-day » (vulnérabilité logicielle encore inconnue de l’éditeur) : on imagine facilement le niveau technique requis pour ce type de profil capable d’utiliser le rétro engineering pour comprendre la vulnérabilité et maitrisant plusieurs langues afin de s’intégrer ou plutôt de se fondre dans les forums écoutés.
Dans le Cabinet pour lequel je travaillais on entendait parler russe, chinois, anglais, espagnol, polonais, japonais … et quelques autres langues.
Comme il est important de pouvoir détecter très rapidement les nouvelles failles et vulnérabilités, l’implantation d’une représentation physique du service de Veille sur plusieurs continents, (par exemple l’Europe, l’Asie et le Canada …) est un gage de performance. Cette efficacité et cette mobilisation de moyens peuvent conférer au centre d’alertes (C.E.R.T pour Computer Emergency Readiness Team), une reconnaissance au niveau européen.
Par ailleurs, certains Cabinets proposent des services personnalisés par le biais de logiciels d’alerte indexés sur l’actif logiciel du client ou même, (le Top du Top), des Veilleurs dédiés à la surveillance de leur parc.
Voilà pourquoi il est plus raisonnable de s’adresser à un service de Veille externe spécialisé plutôt que de vouloir le gérer soi même.
A l’inverse, l’exploitation et la mise en œuvre des contre-mesures en Production doivent rester sous contrôle et si elles font l’objet d’un contrat d’assistance externalisée ce dernier doit être très précis dans la définition de son mode de fonctionnement, (règles précises d’application des patchs de sécurité, …).
Il faut avoir à l’esprit que le Métier et le business doivent primer mais sans mettre l’entreprise en péril …
Maintenant, je peux vous parler de l’exploitation des informations en provenance de la Veille : avant tout il est impératif de faire un catalogue précis et à jour des logiciels que l’on utilise et c’est un travail … énorme...
Les systèmes d’exploitation et leurs outils, les applicatifs, les systèmes de bases de données, les environnements de développement ainsi que l’ensemble du middleware, les outils fournis par les constructeurs et les O.S embarqués sur les éléments actifs réseaux en font partis.
C’est à partir de ce catalogue et de l’activité de Veille que l’on va pouvoir protéger les logiciels de son S.I en mettant en œuvre une activité complexe et consommatrice de ressources : la Gestion des Correctifs Logiciels.
Le « patch management » est exigeant dans sa définition et sa mise en place : il faut établir avec précision qui fait quoi ? (décisionnaires et propriétaires des données et des traitements) ? Quels sont les faits déclencheurs du Patch ? Les précautions à prendre ? Comment sont gérés les retours arrière ? Qui vérifie l’intégrité des processus métiers impactés ? Qui peut décider de corriger un environnement complexe de type O.S/base de données/applicatifs et Spécifiques et quand peut-il le faire ? …
Nous avons aujourd’hui l’opportunité d’utiliser des outils pour identifier les besoins de correctifs spécifiques de nos parcs. Ils permettent de rapatrier une seule fois les patchs en interne et de les partager : heureusement car c’était beaucoup plus fastidieux et difficilement gérable il y a quelques années !
Certaines entreprises ont limité le nombre des logiciels permis en construisant des masters par profils Métier. Cependant il est toujours nécessaire de mettre en place une procédure de modification de ces masters au risque de constater des ajouts de logiciels exotiques par les utilisateurs, (les Politiques de Sécurité qui régissent les privilèges des utilisateurs sur leur poste de travail ont toujours des zones « floues » dans leur application !)
Ces outils de mise à jour permettent d’avoir une liste exhaustive des logiciels non autorisés mais pour lesquels on tente de télécharger la mise à jour : c’est très positif car cela permet de recenser un besoin des utilisateurs pour un logiciel absent des masters, (par exemple, une visionneuse pour un format bureautique récent).
Ce qui serait moins positif c’est l’absence de réaction en cas de détection d’une anomalie ou d’un incident de sécurité, parce que la réaction n’est pas prévue ou que la procédure n’existe pas …
Ces outils de mise à jour ont tous un point commun quand ils sont matures : ils permettent une gestion totalement manuelle, pas à pas et une validation très précise des correctifs par les Administrateurs.
Le but est d’anticiper la régression des logiciels installés et l’absence de risques pour les environnements déjà utilisés.
Par exemple, lors de l’installation d’un Service Pack qui comprendrait un pilote d’imprimante réactualisé pour une imprimante partagée par des milliers d’utilisateurs : elle pourrait ne plus fonctionner parce que son niveau de firmware ne lui permet pas de comprendre ce nouveau pilote, (si c’est l’imprimante de la DRH lors du traitement de la Paie je vous laisse deviner l’urgence de la correction ...).
De même, laisser un technicien, (maintenance externe) installer un nouveau firmware sur toutes les imprimantes d’un type précis sans avoir testé l’impact en interne, (pilotes en libre service, serveurs d’impression, …) se révèle souvent être une vraie catastrophe et par ailleurs, les imprimantes supportent rarement le « downgrade » de leur firmware.
Il est donc nécessaire de tester les correctifs sur un environnement suffisamment déconnecté de la Production, (totalement déconnecté reste l’idéal …), pour valider leur absence de nocivité en interne.
La virtualisation et le choix d’une population d’utilisateurs tests, (prévenus et gérés comme tels) sont deux possibilités pour apporter une réponse concrète à ce principe de la norme ISO 27002.
En synthèse, il ne suffit pas d’avoir un service de Veille pour être garanti, ni d’appliquer rapidement les correctifs pour protéger son parc et son Métier : il est impératif de maitriser l’application des correctifs qu’ils soient proposés par les éditeurs ou imposés pour des raisons de Sécurité car même dans ce dernier cas, il est souvent possible de trouver une alternative.
A l’inverse, un applicatif en haute disponibilité (production en flux tendu dans l’Agro Alimentaire, gestion des livraisons de matériels pour le B.T.P …), peut être rendu inutilisable par l’application d’un simple correctif.
La Veille et la gestion des correctifs sont des mécanismes de Sécurité réellement incontournables mais que l’on peut mettre en œuvre à des degrés différents. Ce degré reste à définir suivant l’activité de son entreprise et la criticité de son Système d’Information pour le Métier et la Production. Il restera à bien penser leur intégration et à utiliser réellement leur potentiel bénéfique …
Article proposé par Tony BLAS - Consultant en Sécurité de l’Information (20 ans d’expérience en informatique, culture élargie des S.I, des architectures, des entreprises et des domaines, Master en Sécurité Informatique de l’EPITA, Formé à la fonction de RSSI, certifié MCSE et Citrix CCA). - Consultez son profil Viadéo.
