Lorsqu’une organisation est informée d’une alerte de sécurité sur son système d’information, une course contre-la-montre s’enclenche.

Les questions à se poser sont relativement simples :  Est-on concernés ? Dans quelle mesure ? Où ? Peut-on corriger rapidement ? La faille est-elle déjà en phase d’exploitation ?

Pourtant, les réponses sont souvent difficiles à apporter …

La complexité ? Des défis à plusieurs niveaux :

  • Capacité à identifier l’utilisation, la localisation du composant ;
  • Capacité à identifier les adhérences, à mesurer l’impact de la montée de version nécessaire ;
  • Capacité à gérer les dettes technologiques avant de pouvoir agir.

Pourquoi ces défis sont souvent des obstacles ?

L’expérience montre que peu d’entreprises possèdent la maturité SSI suffisante dans la gestion de leur système d’information leur permettant d’avoir un Maintien en Conditions de Sécurité (MCS) complet et efficace.

Un MCS opérationnel et efficace devrait leur permettre d’avoir à disposition une cartographie suffisamment fine de leurs actifs (matériel/logiciel) comprenant l’applicatif et la version pour identifier ceux affectés. De plus, une dette technologique maitrisée permet une montée de version et un passage de correctif probablement plus rapide et certainement moins.

Qu'est ce que le MCS ?

Le Maintien en Conditions de Sécurité (ou MCS) est une partie intégrante du Maintien en Conditions Opérationnelles (ou MCO).  Si le MCO assure à l’utilisateur un système opérationnel et fonctionnel dans le temps, sa brique MCS permet d’assurer le maintien dans le temps de son niveau de sécurité ou niveau de risque acceptable.

Parmi ces évènements, nous retrouvons par exemple :

  • Faille de sécurité ;
  • Obsolescence ;
  • Changements/évolutions sur le système d’informations ;
  • Montée de version ;
  • Etc.

Le processus de MCS a ainsi pour objectif de maintenir conforme (ce terme est important et nous y reviendrons plus tard) le niveau de sécurité des composants d’un système d’information par rapport aux besoins exprimés par Cela doit permettre d’anticiper et de réagir efficacement aux menaces et aux vulnérabilités.

Le processus complet de MCS comprend quatre sous-parties permettant de garantir un maintien dans le temps :

  1. La connaissance du système d’informations et des besoins de sécurité ;
  2. La sécurisation et la maintenance des systèmes (Préventive, corrective, évolutive) ;
  3. Le contrôle régulier de la conformité du niveau de sécurité au regard des besoins exprimés ;
  4. La révision régulière des besoins de sécurité ;

Une bonne stratégie de MCS permettra la maîtrise des risques de sécurité tout au long de la vie du système considéré et le maintien dans le temps du niveau de conformité avec les exigences de sécurité, celles initialement définies ainsi que leurs évolutions.

La mise en conditions de sécurité d’un système

Cela peut sembler évident, mais avant de vouloir maintenir son système en conditions de sécurité, il convient d’abord de s’assurer qu’il est déjà sécurisé.

Cette mise en conditions de sécurité initiale se fait à trois moments clés de la vie d’un projet :

1- La conception ou acquisition d’un système

Cette thématique est un sujet à part entière, cependant voici les principaux points à prendre en compte :

  • Avant le démarrage, tout système doit faire l’objet d’une expression de besoins de sécurité au moyen d’une analyse de risque, en tenant compte des besoins de conformité à des exigences légales, réglementaires, contractuelles, métier, … ;
  • Le processus projet va alors suivre le processus d’Intégration de la Sécurité dans les Projets (ISP), dont l’expression des besoins de sécurité est une des toutes premières phases ;
  • En cas d’acquisition, c’est le processus « achat » qui va prendre en compte cette partie sécuritaire avec le processus de « sécurité dans les achats » (Sécurité des fournisseurs, sécurité dans les contrats, …).

2- Le déploiement du système

Les phases préalables au déploiement et la phase de déploiement en elle-même sont des phases importantes dans la mise en conditions de sécurité initiale :

  • En préalable au déploiement il convient de vérifier la conformité au regard des exigences de sécurité. Le terme conformité a ici toute son importance car finalement le MCS consistera à s’assurer de maintenir le système dans cet état de conformité. Cette phase peut porter différents noms en fonction du contexte de l’organisation comme “homologation de sécurité”, “revue sécurité”, “recette sécurité” mais l’objectif reste le même ;
  • Le déploiement peut amener son lot de risques (souvent dus à de la précipitation, à des délais trop courts pour tenter de rattraper les dérives de planning, ou simplement à de mauvaises pratiques) et doit faire l’objet d’une attention particulière.

3- La validation du système avant de rendre le service opérationnel.

Bien entendu, une fois déployé, le système fait l’objet de contrôles de sécurité dans son environnement définitif. Ces contrôles peuvent couvrir de nombreux aspects comme à titre d’exemple :

  • Le contrôle de configuration au regard des règles de durcissement ;
  • Le contrôle de la bonne intégration avec les systèmes de sécurité comme le SIEM ;
  • Les contrôles de cloisonnement, de filtrage des flux ;
  • Les contrôles des accès logiques.

Ces contrôles peuvent ensuite être confirmés/validés par un pentest.

Le système est alors déclaré apte au service, conforme à l’attendu et aux exigences. Il est désormais en conditions de sécurité. A partir de ce moment, on entre dans la phase de maintien en conditions de sécurité.

Comment maintenir les conditions de sécurité dans le temps ?

Connaître son système d’information

Avant d’envisager de pouvoir maintenir le niveau de sécurité de son système d’information et donc de tous les systèmes le composant, il est nécessaire de connaitre et maitriser ces systèmes. Il n’y a pas de “bon” MCS sans “bonne” cartographie et l’outillage qui va avec, la CMDB (ou Configuration Management DataBase).

La CMDB va permettre d’avoir une référence – plus ou moins – fiable des composants du SI avec, en fonction de sa maturité, une granularité assez fine. De nombreux enjeux technologiques et humains se présentent pour la mise en place et le maintien opérationnel d’une bonne CMDB dans le temps :

  • Identifier l’outillage et le modèle de données adaptés à l’entreprise ;
  • Impliquer les opérationnels dans son maintien à jour ;
  • Revoir et améliorer en cohérence avec le développement des SI de l’entreprise ;
  • Adapter la solution au service de l’Humain (design, accompagnement au changement, transfert de connaissance, formation).

Attention cependant, certains pièges sont à éviter lors de sa construction et de sa mise en place :

  • Partir dans sa construction sans objectif défini ;
  • Concevoir une CMDB sans avoir la compréhension des métiers ;
  • Ne pas inclure le processus de gestion des changements ;
  • Attendre d’avoir une CMDB parfaite et complète pour la déployer.

Maintenir son système d’informations à jour

Une fois le système d’information maîtrisé, son maintien à jour peut être effectué efficacement.

La gestion des mises à jour ou Versioning

1- La gestion des mises à jour ou Versioning

Le processus de mise à jour doit permettre des montées de version régulières, suffisamment fréquentes pour éviter les dettes techniques trop importantes avec le lot de problèmes que cela peut engendrer : impossibilité d’effectuer une montée de version “directe” du fait de l’ancienneté de la version installée, incompatibilité entre composants, etc.

Une bonne planification doit permettre de prendre en compte les contraintes et obligations opérationnelles tout en permettant ces montées de version régulières.

2- La gestion des correctifs de sécurité ou Patch Management

Qu’elle soit basée sur les alertes des éditeurs/constructeurs, les alertes du CERT, des outils de type scanner, d’autres systèmes ou idéalement sur toutes ces sources, une politique proactive de gestion des correctifs et l’adoption de bonnes pratiques présentent plusieurs avantages :

  • Être en mesure de traiter au fil de l’eau, sans backlog à gérer ;
  • Multiplier les sources pour avoir une information exhaustive sans se laisser envahir par les doublons ;
  • Qualifier et donc prioriser la prise en compte puis traiter les alertes ;
  • Adresser les alertes/actions uniquement aux entités concernées ;
  • Maîtriser les déploiements dans un processus de gestion du changement ;
  • Suivre puis contrôler efficacement les actions de remédiation.

Le système est alors déclaré apte au service, conforme à l’attendu et aux exigences. Il est désormais en conditions de sécurité. A partir de ce moment, on entre dans la phase de maintien en conditions de sécurité.

La gestion des correctifs de sécurité ou Patch Management

3- La gestion de l’obsolescence

Un actif obsolète est un actif qui ne dispose plus de support de la part de son constructeur/éditeur, de mises à jour régulières ni de correctifs de sécurité. Progressivement des failles de sécurité apparaissent et la compatibilité avec les autres logiciels ou équipements n’est plus assurée. Cette obsolescence impacte donc inévitablement la capacité à assurer ses fonctions de manière sécurisée.

Une politique proactive de gestion de l’obsolescence est essentielle. Elle va consister à anticiper la fin de vie de ces actifs en effectuant, en avance de phase, leur remplacement ou leur migration vers des versions supportées. La connaissance et la maîtrise de son SI est une fois de plus cruciale pour identifier et anticiper.

Contrôler le niveau de sécurité

Comme le dit l’adage “la confiance n’exclue pas le contrôle”. Quand bien même l’ensemble de ces processus sont mis en œuvre et rodés, des contrôles réguliers et de différents niveaux doivent être effectués.

Leur objectif est de vérifier la conformité du niveau de sécurité “effectif” avec ce qui est attendu. Ces contrôles, réalisés dans le cadre du plan de contrôle, peuvent être de différents types : audits de configuration, pentests, etc.

Les résultats de ces contrôles font l’objet, si nécessaire, de plans d’actions visant à supprimer les non-conformités observées et contribuer à ramener le système dans un niveau de conformité acceptable.

Gérer les cas de non-conformité

Puisque maintenir un système en conditions de sécurité c’est s’assurer que son niveau de sécurité demeure conforme à une exigence de sécurité, tout système possédant une faille de sécurité non-corrigée, une mise à jour non déployée, une obsolescence confirmée, ou encore un défaut de configuration devra être considéré comme non conforme.

Un processus de gestion des non-conformités devra alors permettre de traiter celles-ci dans des délais acceptables, que ce soit par une correction complète, des solutions palliatives, une dérogation…etc.

Gérer les cas de non-conformités

Revoir régulièrement ses objectifs de sécurité

Les conditions de sécurité sont fixées initialement au regard du risque à couvrir au moment de la mise en service du système. Cependant, avec le temps, le risque peut – très certainement – évoluer. Il peut évoluer du fait de l’évolution de tout un tas de critères comme l’évolution du contexte commercial de l’entreprise, du contexte géopolitique, de nouvelles réglementations, de faiblesses intrinsèques au système … Maintenir un système en conditions de sécurité ne consiste donc pas simplement à le maintenir sécurisé au regard de risques qui ont été identifiés et évalués des années auparavant.

En conséquence, les systèmes et surtout ceux ayant une longue durée de vie, doivent faire l’objet d’une révision des besoins de sécurité. Cette révision consiste, à échéance régulière, à réévaluer le risque et de s’assurer que les mesures mises en œuvre à l’origine permettent toujours de maintenir le risque à un niveau acceptable.

Si cela est nécessaire, les mesures de sécurité sont revues généralement à la hausse ou, plus rarement, à la baisse.

Conclusion

Il ne fait aucun doute que maintenir ses systèmes en conditions de sécurité est un enjeu majeur.

Comme nous l’avons vu, maintenir son Système d’Information en conditions de sécurité est bien plus complexe que simplement « patcher » régulièrement, (bien que ce point revête une importance cruciale à lui seul. Si vous souhaitez vous lancer dans la mise en œuvre d’un processus de MCS complet, nous attirons votre attention à ne pas sous-estimer les ressources humaines et budgétaires nécessaires pour mettre en œuvre mais surtout maintenir dans le temps ce processus. Un fort sponsoring du top management ne sera certainement pas de trop.

VONA a accompagné plusieurs de ses clients (Industrie, Ministères, …) dans la définition puis la mise en œuvre de leurs processus de MCS et peut vous aider dans votre projet. VONA a également développé une solution de gestion des vulnérabilités et des versions à destination des PMEs/ETIs. Pour en savoir plus sur cette solution, cliquez ici

Autres articles utiles :

https://www.gartner.com/smarterwithgartner/how-to-set-practical-time-frames-to-remedy-security-vulnerabilities

https://www.cyber.gc.ca/fr/orientation/les-10-mesures-de-securite-des-ti-no2-appliquer-les-correctifs-aux-systemes-dexploitation-et-aux-applications-itsm10096