5 indices pour détecter l’obsolescence de votre programme de sécurité

Comment détecter l’obsolescence de votre programme de sécurité ?

En général, la durée de vie d’un produit classique dépasse rarement cinq ans, tandis que d’autres font constamment leur apparition. Il en va de même pour les programmes et les méthodes de cyber-sécurité qui n’échappent pas à la règle. Que peut donc bien signifier le terme « bestvpractices » sur un marché jeune d’une vingtaine d’années où la technologie ne cesse de prendre des virages à 180° à intervalles régulier ? Concrètement, si des interruptions de service dues à des malwares, des échecs lors d’audit de sécurité ou encore des fuites de données ne sont pas des indicateurs suffisants pour vous alerter, voici six indications supplémentaires que votre programme de sécurité est obsolète.

Indice n°1 : Pour vous, la mise à jour de vos systèmes est un exercice ponctuel extrêmement pénible ?

C’est que vous n’avez pas de politique de sécurité fiable. Pour les directions informatiques, traiter des failles de sécurité massives comme Heartbleed, Shellshock et Poodle impliquait de rester tard le soir, toutes affaires cessantes, pour déployer des correctifs à la dernière minute. Or, dans une organisation saine, ce type de mises à jour devrait être une opération de routine. C’est pour cela qu’une politique de contrôle robuste des mises à jour est indispensable. Par ailleurs, votre DSI doit pouvoir anticiper et planifier ces mises à jour.

Indice n°2 : Vous ne savez pas localiser précisément votre parc informatique ?

Vous ne pouvez pas garantir vos actifs critiques si vous ne savez pas où ils sont… Un inventaire à jour doit toujours être disponible. Un bon inventaire doit aussi répertorier tous les logiciels et les données de chaque système. Un système clair de classification de l’information, parallèlement à un programme de gestion des actifs, devrait également être mis en place. Les inventaires devraient enfin s’étendre au-delà du poste de travail et inclure tous les supports amovibles, les appareils mobiles ainsi que ce qui est déployé dans le Cloud. Une parfaite connaissance de ses actifs est un élément indispensable d’une gestion des risques efficace.

Indice n°3 : Pour vous, l’analyse de risques se résume à analyser les écarts entre vos méthodes et les bonnes pratiques ?

Même en supposant que vous connaissiez l’emplacement de chacun de vos actifs, vous avez aussi besoin de savoir ce qui peut arriver de nouveau. L’analyse de risque ne consiste pas seulement à passer en revue des listes de contrôle mais doit aussi être un processus collaboratif, dynamique et aussi réaliste que possible. Un autre indicateur d’une gestion des risques défaillante se manifeste par le blocage unilatéral d’initiatives commerciales « parce qu’elles ne sont pas sûres », sans d’avantage de justifications rationnelles ou quantifiables. Il existe un grand nombre de bonnes méthodologies d’analyse de risques – parmi lesquelles mes favorites sont FAIR et NIST Special Publication 800-30. Lorsque vous faites une analyse de risques, pensez à documenter toutes vos hypothèses, à chercher des dépendances, et tentez ensuite de garder à l’esprit qu’un système fermé est une chimère. L’analyse de risques devrait constituer le fondement des politiques de sécurité de votre organisation.

Indice n°4 : Chez vous, les politiques de sécurité sont des pavés que personne ne lit ?

Alors les collaborateurs ne comprendront jamais ce que l’on attend d’eux. Les politiques de sécurité doivent décrire de manière simple et claire comment une entreprise gère ses risques. N’importe quel collaborateur de l’entreprise doit pouvoir non seulement la lire, mais également en comprendre facilement les enjeux. Les détails techniques et les procédures détaillées doivent être laissés hors du document principal, pour ne pas gêner la mise en oeuvre opérationnelle. Dans l’idéal, les politiques de sécurité devraient être modifiées uniquement lorsque les risques ou les tolérances aux risques évoluent dans l’organisation. Les objectifs de cette politique devraient être liés à la résolution des problèmes de l’entreprise et correspondre à l’activité de l’organisation. Le jargon technique est à réserver aux départements IT et Sécurité.

Indice n°5 : Votre DSI gère l’IT, et votre département Sécurité intervient uniquement après coup ?

C’est que vous considérez la sécurité comme accessoire. Elle doit faire partie intégrante de votre IT, basée sur l’orientation claire donnée par votre politique de sécurité. Le rôle premier de l’IT est de soutenir l’ensemble des départements de l’entreprise, ce qui passe par la satisfaction de toutes les demandes utilisateurs, la résolution dans l’urgence des problèmes majeurs, et la mise en oeuvre des projets. La sécurité est l’une de ses nombreuses priorités, mais devrait être en réalité la plus importante. Les équipes informatiques ont besoin de comprendre l’importance d’une politique de sécurité robuste et non pas se référer à elle uniquement au cas par cas.

Il faut donc une équipe en charge de la sécurité qui ne se contente pas de résoudre les problèmes de sécurité, mais qui guide l’ensemble des opérations IT. Idéalement, ce devrait être deux groupes distincts, ayant chacun sa propre structure de management indépendante. Indice n°6 : Vous vous concentrez principalement sur les contrôles opérationnels et vous sous-estimez le travail quotidien sur la sécurité ?

Le personnel en charge de la sécurité peut souvent être distrait par la gestion quotidienne des pare-feu, des solutions anti-virus, des mots de passe et des scanneurs de vulnérabilité. En réalité, la sécurité requiert l’exécution de taches difficiles, fastidieuses et répétitives, telles que l’inventaire, l’intervention en cas d’incident, la gestion du risque et l’analyse des menaces. Elle nécessite aussi de mettre en place une architecture de sécurité mûrement réfléchie, des systèmes d’analyses adéquats tout en répondant aux besoins courants de l’entreprise. Le mieux est d’adopter une approche ascendante pour l’architecture de sécurité, en utilisant des sous-systèmes bien compris. Si l’équipe de sécurité passe ses journées sur les filtres anti-spam, elle n’aura plus de temps pour l’analyse de risques et ira droit dans le mur. Tandis que la plupart de ces six pratiques étaient auparavant considérées comme normales pour la cybersécurité, elles n’ont que peu de valeur dans l’entreprise d’aujourd’hui. Les pratiques obsolètes sont susceptibles d’aboutir à un programme de sécurité en mode gestion de crise, réglant de manière ponctuelle les problèmes dans l’urgence. Les paniques d’avant audit, la paralysie de l’analyse, et la course d’un incident à l’autre risquent de mener vos équipes à l’épuisement et à passer à côté de quelque chose de vital qui peut amener à une crise majeure.