Nous avons vu dans le précédent article (Security Patch Management: problématique et écueils à éviter) les points clés à mettre en oeuvre pour réaliser un processus de gestion des correctifs de sécurité efficace et évolutif.
Le processus qui est décrit dans cet article peut sembler familier par bien des aspects. Ses points forts proviennent de la méthode ITIL et correspondent à la formalisation des passages de responsabilités, des plannings et de la documentation.
Le processus de gestion des correctifs de sécurité est découpé en quatre phases:
- Gestion des configurations: fournir une information actualisée et détaillée sur les configurations des machines.
- Gestion des vulnérabilités: se tenir informé sur les vulnérabilités et les correctifs de sécurité, évaluer les impacts et analyser les risques pour l'entreprise, décider d'un comportement à adopter, communiquer auprès des différentes équipes et initier le déploiement des correctifs.
- Gestion des changements: évaluer les risques et les coûts associés aux changements, autoriser ou non ces derniers, et planifier les déploiements.
- Gestion des versions: tester en profondeur les correctifs de sécurité (installation, dépendance, régression, plans de retour arrière...) et évaluer l'impact de leur déploiement sur le SI de l'entreprise.
Ce processus est exposé dans la figure ci-dessous.
La gestion des configurations s'appuie sur une base de données centralisée, que ITIL nomme base des configurations (Configuration Management Database, CMDB). Correctement configurée, la base des configurations fournit un moyen de visibilité de qualité sur l'état du parc de machines.
Pour la phase de gestion des changements, ITIL définit également deux rôles spécifiques: le responsable des changements (Change Manager) et le comité de gestion des changements (Changes Advisory Board, CAB). Le responsable des changements est chargé d'organiser l'approbation des demandes de changement et de piloter le comité de gestion des changements. Le CAB est chargé d'évaluer les risques liés au déploiement de chaque correctif et décide si ce dernier sera déployé ou non. En cas d'autorisation, le CAB doit également planifier le déploiement de chaque correctif, en fonction de l'importance des vulnérabilités, de l'impact business sur les machines concernées et de la disponibilité des équipes de déploiements.
Pour avoir un processus optimal, le sous-processus lié à la phase de gestion des changements devra distinguer deux cas de figure, suivant le niveau de criticité d'une vulnérabilité évalué dans la phase précédente: en cas de vulnérabilité extrêmement critique pour l'entreprise, l'analyse et le déploiement du correctif de sécurité associé doivent être pilotés par un sous-processus d'urgence (réduction des tests et des délais de déploiement).
La réussite de la bascule du sous-processus normal au sous-processus d'urgence reposera sur les points suivants:
- les critères déclencheurs doivent être clairement définis,
- le décideur d'urgence doit être clairement identifié
- les critères de réduction des tests doivent être clairement définis.
Enfin, la phase de gestion des versions doit, en plus des tests et des déploiements de correctifs, prendre en compte la mise à jour des "masters" d'entreprise en termes de correctifs de sécurité. En effet, tout correctif validé par le CAB doit être présent sur l'ensemble des machines concernées, y compris les nouvelles machines à venir. Il est donc primordial de mettre à jour tous les masters d'entreprise pour inclure par défaut ces correctifs.
En ce qui concerne maintenant les acteurs sollicités pour chacune de ces quatre phases, on identifiera les équipes suivantes:
- Phase de gestion des configurations
- Mise en place de la CMDB et de ses outils: les équipes d'ingénierie systèmes et logiciels
- Exploitation et administration de la CMDB: les équipes opérationnelles
- Phase de gestion des vulnérabilités: l'équipe sécurité en charge de la veille doit prendre en charge toutes les étapes de cette phase.
- Phase de gestion des changements:
- Processus normal:
- Le responsable des changements doit être le responsable opérationnel.
- Le CAB doit être composé des personnes ci-dessous:
- Le RSSI ou un membre de son équipe
- Le responsable opérationnel et ses responsables d'équipes
- Le responsable ingénierie et ses responsables d'équipes
- Le responsable fonctionnel impacté ou un membre de son équipe
- Processus d'urgence:
- Le décideur d'urgence doit être le DSI
- Le responsable des changements doit être le DSI
- Le CAB doit être composé des personnes ci-dessous:
- Le RSSI et un membre de son équipe
- Le responsable opérationnel et ses responsables d'équipes
- Le responsable ingénierie et ses responsables d'équipes
- Le responsable fonctionnel impacté et un membre de son équipe
- Processus normal:
- Phase de gestion des versions:
- Tests techniques: les équipes d'ingénierie systèmes et logiciels
- Tests fonctionnels: les équipes fonctionnelles impactées, ou des scénarios de tests prédéfinis
- Déploiements des correctifs une fois validés: les équipes opérationnelles
Voilà, nous venons de voir dans les grandes lignes un processus idéal de gestion des correctifs de sécurité. Si cet article ne vous permet pas de faire évoluer le processus mis en place au sein de votre entreprise, il vous permettra tout au moins de comprendre les enjeux et la difficulté liés à la gestion des correctifs de sécurité.
Article écrit par Alexandre Lauga
Edit from the Orange Business team: Hervé left the Orange Group since he wrote his last posts.