Correctifs de sécurité
L’application des correctifs de sécurité sur les postes de travail est au moins aussi
importante que l’installation d’un antivirus.
Les outils ne manquent pas pour les diffuser à tout le parc. Entre ceux proposés par
Microsoft et ceux de la concurrence, le RSSI a l’embarras du choix. Pourtant, il lui
faudra faire preuve de ténacité avant de réussir à mettre en place un processus de
diffusion de correctifs car il rencontrera de fortes résistances. Pour justifier leur
opposition, les responsables de la gestion des postes de travail avancent le risque élevé de
régression de service. Ils redoutent par-dessus tout que, du jour au lendemain, plus aucun
poste de travail ne fonctionne suite à l’application d’un correctif. Cette terreur de la
régression de service doit être prise très au sérieux, d’autant plus qu’il peut être très
difficile de revenir en arrière en cas de problème.
Remarque
Il est curieux de constater que si les responsables ont peur d’une régression de service suite à
l’application des correctifs de sécurité, ils n’exigent aucune validation préalable pour diffuser, de façon
transparente et plusieurs fois par jour, des bases de signatures et des mises à jour d’antivirus qui, elles,
provoquent régulièrement des régressions de service.
La mission du RSSI consiste d’abord à convaincre les exploitants que ce processus peut
être mis en place en réduisant au maximum les risques de régression de service.
Identifier les correctifs à appliquer : Microsoft propose un panel varié de correctifs.
Cela va de la mise à jour de pilote au correctif de sécurité critique. Pour rassurer la
production, le RSSI doit bien faire comprendre que le seul type de correctif qu’il
souhaite déployer est le correctif de sécurité. Cela réduit considérablement le spectre
de la régression de service. De plus, au sein même des correctifs de sécurité, il existe
plusieurs classifications. S’il est indiscutable que les correctifs qualifiés de critiques et
d’importants doivent être appliqués, le RSSI peut renoncer aux correctifs moins
prioritaires, du moins dans un premier temps. Le serveur de mises à jour pourra alors
être configuré.
Expérimenter sur une base de postes : le second levier sur lequel le RSSI peut jouer
pour faciliter l’acceptation du projet consiste à tester les correctifs sur un panel de
postes. Généralement, il choisira les postes des responsables du parc, pour qu’ils
constatent par eux-mêmes que ce processus n’est pas plus risqué qu’un autre.
Préparer la mise en production : ce n’est que dans un troisième temps que l’on
pourra réellement préparer la mise en production des correctifs. La démarche selon
laquelle on divise le parc de postes de travail en différents groupes, puis on applique
successivement les correctifs sur ces groupes a fait ses preuves.
À proprement parler, appliquer des correctifs de sécurité sur tout un parc, cela revient à
modifier l’état du SI. Et qui dit modification du SI, dit qualification préalable. Or, il est
difficile d’effectuer chaque mois toute une batterie de tests pour valider formellement la
non-régression sur les postes. Une approche plus empirique permet de résoudre cette
difficulté. Elle a aujourd’hui amplement prouvé son efficacité et consiste simplement à
diviser le parc de postes de travail en plusieurs groupes, généralement deux ou trois.
L’application des correctifs de sécurité sur les postes de travail est au moins aussi
importante que l’installation d’un antivirus.
Les outils ne manquent pas pour les diffuser à tout le parc. Entre ceux proposés par
Microsoft et ceux de la concurrence, le RSSI a l’embarras du choix. Pourtant, il lui
faudra faire preuve de ténacité avant de réussir à mettre en place un processus de
diffusion de correctifs car il rencontrera de fortes résistances. Pour justifier leur
opposition, les responsables de la gestion des postes de travail avancent le risque élevé de
régression de service. Ils redoutent par-dessus tout que, du jour au lendemain, plus aucun
poste de travail ne fonctionne suite à l’application d’un correctif. Cette terreur de la
régression de service doit être prise très au sérieux, d’autant plus qu’il peut être très
difficile de revenir en arrière en cas de problème.
Remarque
Il est curieux de constater que si les responsables ont peur d’une régression de service suite à
l’application des correctifs de sécurité, ils n’exigent aucune validation préalable pour diffuser, de façon
transparente et plusieurs fois par jour, des bases de signatures et des mises à jour d’antivirus qui, elles,
provoquent régulièrement des régressions de service.
La mission du RSSI consiste d’abord à convaincre les exploitants que ce processus peut
être mis en place en réduisant au maximum les risques de régression de service.
Identifier les correctifs à appliquer : Microsoft propose un panel varié de correctifs.
Cela va de la mise à jour de pilote au correctif de sécurité critique. Pour rassurer la
production, le RSSI doit bien faire comprendre que le seul type de correctif qu’il
souhaite déployer est le correctif de sécurité. Cela réduit considérablement le spectre
de la régression de service. De plus, au sein même des correctifs de sécurité, il existe
plusieurs classifications. S’il est indiscutable que les correctifs qualifiés de critiques et
d’importants doivent être appliqués, le RSSI peut renoncer aux correctifs moins
prioritaires, du moins dans un premier temps. Le serveur de mises à jour pourra alors
être configuré.
Expérimenter sur une base de postes : le second levier sur lequel le RSSI peut jouer
pour faciliter l’acceptation du projet consiste à tester les correctifs sur un panel de
postes. Généralement, il choisira les postes des responsables du parc, pour qu’ils
constatent par eux-mêmes que ce processus n’est pas plus risqué qu’un autre.
Préparer la mise en production : ce n’est que dans un troisième temps que l’on
pourra réellement préparer la mise en production des correctifs. La démarche selon
laquelle on divise le parc de postes de travail en différents groupes, puis on applique
successivement les correctifs sur ces groupes a fait ses preuves.
À proprement parler, appliquer des correctifs de sécurité sur tout un parc, cela revient à
modifier l’état du SI. Et qui dit modification du SI, dit qualification préalable. Or, il est
difficile d’effectuer chaque mois toute une batterie de tests pour valider formellement la
non-régression sur les postes. Une approche plus empirique permet de résoudre cette
difficulté. Elle a aujourd’hui amplement prouvé son efficacité et consiste simplement à
diviser le parc de postes de travail en plusieurs groupes, généralement deux ou trois.