Gestion de la cybersécurité basée sur le risque : pourquoi moins de cases à cocher apportent plus de sécurité

La plupart des programmes de sécurité se composent de deux types d'activités : des activités visibles comme rédiger des politiques, planifier des campagnes de sensibilisation ou renouveler des certifications, et des activités efficaces. L'intersection est plus petite qu'elle ne devrait l'être. Un manuel SMSI de 140 pages documentant chaque contrôle ISO avec un soin méticuleux ne dit rien sur le point de savoir si cette application legacy avec son stockage de données clients non chiffré est réellement protégée. C'est la différence entre une gestion de la sécurité pilotée par la conformité et une gestion basée sur le risque, et la raison pour laquelle cette distinction devient de plus en plus souvent un facteur de succès décisif pour les PME et grandes entreprises suisses.

Cet article explique ce que signifie concrètement une approche basée sur le risque, pourquoi elle réduit les frais généraux plutôt qu'elle n'en génère, et comment rendre visibles les vrais points critiques de votre organisation, sans avoir à accrocher un certificat de plus au mur.

1 · Le problème du « on fait tout »

Un tableau typique dans de nombreuses organisations : la sécurité informatique a accumulé au fil des années une pile de mesures, un règlement de pare-feu, une gestion des correctifs, une protection des postes de travail, un SIEM, des tests d'intrusion réguliers. Le tout réparti entre plusieurs équipes, documenté dans des outils différents, vérifié lors d'audits différents. Sur le papier, l'ensemble est impressionnant. Mais si l'on demande : « Quels sont nos cinq plus grands risques cyber, et que faisons-nous concrètement contre eux ? », on obtient généralement un long silence ou une liste de contrôles, et non de risques.

La distinction est centrale. Énumérer des contrôles décrit ce qui est fait. Nommer des risques décrit contre quoi on se protège réellement. Un programme de sécurité orienté principalement vers le respect des contrôles produit quatre effets secondaires bien connus :

• Frais généraux sans gain de protection. Les formations obligatoires de sensibilisation pour l'ensemble des collaborateurs sont bon marché à acheter et faciles à rapporter, mais n'offrent plus qu'une protection marginale contre les attaquants modernes, tandis que l'application dans la DMZ avec son framework Java non corrigé reste intacte pendant des années.
• Fausse sécurité par la couverture. Un certificat ISO confirme qu'un SMSI fonctionne, non pas que les systèmes réellement exposés sont protégés de manière adéquate. De nombreuses organisations certifiées ont malgré tout été attaquées avec succès parce que la vulnérabilité était hors périmètre ou noyée dans un « risque moyen » générique.
• Paralysie par l'équipondération. Lorsque les 74 contrôles de l'annexe A de l'ISO 27001 sont tous traités avec la même importance, il ne reste plus de capacité pour pénétrer vraiment en profondeur les trois à cinq domaines véritablement critiques.
• Déconnexion du métier. La sécurité est perçue comme une « affaire de conformité », non comme un sujet business. La direction signe les budgets parce qu'un auditeur l'exige, non parce qu'elle comprend pourquoi ce risque spécifique est menaçant pour cette organisation.

La gestion de la sécurité basée sur le risque renverse cette logique. Le point de départ n'est pas le contrôle, mais le risque. Et tous les risques ne sont pas traités de la même manière.

2 · Ce que « basé sur le risque » signifie vraiment

Le terme « basé sur le risque » est utilisé à l'excès, par des cabinets de conseil qui vendent une nouvelle approche, jusqu'aux outils qui se contentent de rebaptiser des matrices de conformité classiques. Une heuristique simple sépare le marketing de la méthode :

Un programme de sécurité est basé sur le risque lorsque chaque décision d'investissement significative, chaque mesure, chaque priorisation peut être retracée jusqu'à une évaluation concrète du risque, et lorsque cette évaluation est régulièrement réexaminée.

En pratique, une approche basée sur le risque comprend quatre éléments imbriqués :

Premièrement : un registre des risques à jour. Non pas une liste Excel actualisée une fois par an pour l'audit, mais un registre vivant dans lequel les risques sont identifiés, évalués et attribués à un propriétaire. Chaque risque comporte au moins une valeur brute (quelle serait son ampleur sans protection), une valeur résiduelle (quelle est son ampleur avec les mesures mises en œuvre) et un statut.

Deuxièmement : un lien clair entre risque, actif protégé et processus. Un risque ne flotte pas dans le vide. Il affecte un actif concret, un serveur de base de données, une application, un processus métier. Quiconque ne peut pas établir ce lien ne peut ni estimer l'impact d'un incident ni, en cas d'urgence, prioriser ce qui doit être rétabli en premier.

Troisièmement : des mesures avec preuve d'efficacité. Chaque contrôle est rattaché à un ou plusieurs risques. Quiconque demande ce qu'apporte une mesure donnée obtient une réponse sous forme de réduction brut-vers-résiduel. Les mesures qui ne peuvent être rattachées à aucun risque significatif sont remises en question, et souvent supprimées ou consolidées.

Quatrièmement : une réévaluation périodique. Le paysage des menaces, les processus métier et la base technologique évoluent en permanence. Un programme basé sur le risque définit à quelle fréquence quels risques sont réévalués, et qui déclenche cette réévaluation. Un nouveau raccordement à un tiers, un nouveau module ERP, une exigence réglementaire modifiée : autant de déclencheurs pour une mise à jour.

3 · Identifier les joyaux de la couronne

Chaque organisation possède un domaine dans lequel une attaque réussie serait véritablement existentiellement menaçante, et une trentaine d'autres domaines où un incident serait certes désagréable, mais maîtrisable. La première mission d'un programme basé sur le risque est de pouvoir nommer cette différence.

Dans la littérature sur la sécurité, on parle des joyaux de la couronne d'une organisation : ces ensembles de données, systèmes ou processus dont la compromission ou la défaillance porterait une atteinte fondamentale à l'activité. Les joyaux de la couronne ne sont pas identiques à « toutes les données personnelles » ou « tous les systèmes accessibles depuis Internet ». Une entreprise industrielle forte de 30 ans de savoir-faire en développement a des joyaux de la couronne différents de ceux d'un fiduciaire avec des dossiers clients ou d'un hôpital avec des dossiers patients.

L'identification s'articule autour d'une question simple, à laquelle on peut répondre lors d'un court atelier avec la direction : Qu'est-ce qui porterait une atteinte fondamentale à notre organisation dans douze mois si cela était irrévocablement compromis ou supprimé aujourd'hui ? Les réponses sont généralement étonnamment concrètes :

• Le code source du produit phare et les pipelines de build associés
• La base de données clients avec les conditions contractuelles, les moyens de paiement et l'historique
• L'ERP central, sans lequel ni les commandes n'entrent ni les factures ne sortent
• Le tenant M365 avec l'ensemble des communications e-mail et des données OneDrive de l'équipe dirigeante
• Les fichiers CAO des constructions relevant du brevet

Une PME typique ne devrait pas nommer plus de cinq à sept joyaux de la couronne, quiconque produit une liste plus longue a soit une structure d'entreprise très particulière, soit n'a pas encore opéré la distinction avec tous les autres actifs. La valeur de cet exercice réside précisément dans la focalisation qu'il impose.

Une fois les joyaux de la couronne nommés, le travail de sécurité est réordonné : quels contrôles protègent ces actifs concrets ? Quelles mesures apporteraient la plus grande réduction à cet endroit ? Quelle surveillance existe là, et laquelle fait défaut ? De nombreuses organisations découvrent à ce stade que les investissements de sécurité les plus coûteux ont été réalisés aux endroits les moins critiques, tandis que les joyaux de la couronne sont étonnamment peu protégés.

4 · Points critiques plutôt que checklists

Un point critique est un endroit où un seul incident affecte simultanément plusieurs processus critiques. Dans la vision classique de la conformité, les points critiques apparaissent comme un contrôle parmi d'autres. Dans la vision basée sur le risque, ce sont eux qui doivent concentrer l'attention en priorité.

Points critiques typiques dans les organisations suisses :

• Active Directory / Entra ID. Un compte d'administrateur de domaine compromis signifie en règle générale la fin de chaque ligne de défense isolée. Pourtant, le programme de sécurité traite souvent l'identité comme un contrôle parmi d'autres, plutôt que comme le commutateur central qu'elle est réellement.
• Le système de sauvegarde. Les attaques par ransomware de ces dernières années ont montré que la différence entre « récupérable en 4 heures » et « nous payons la rançon » réside presque toujours dans le concept de sauvegarde, non dans le produit antivirus. Pourtant, la sauvegarde est un sujet secondaire dans de nombreux SMSI.
• La plateforme de collaboration centrale. M365, Google Workspace ou leurs équivalents constituent pour beaucoup d'entreprises l'environnement de travail de facto. Une compromission à cet endroit équivaut pratiquement à une compromission de l'ensemble de l'organisation, pourtant, la sécurité de configuration est rarement au niveau que cette situation de risque exige.
• Le fournisseur clé unique sans concept de secours. L'ERP cloud d'un seul prestataire, la seule interface bancaire, l'unique prestataire de paiement : là où il n'existe aucune alternative, un point de défaillance unique se crée, invisible dans la moindre règle de pare-feu.
• L'application legacy avec accès privilégié. Presque chaque organisation ayant grandi organiquement possède au moins une ancienne application tournant sur une pile non maintenue, mais disposant d'un accès aux données critiques pour la production. Tant qu'elle « fonctionne d'une façon ou d'une autre », elle est laissée de côté, jusqu'à ce qu'elle soit exploitée comme vecteur d'attaque.

Identifier de tels points critiques n'est pas une tâche de checklist, mais une tâche d'analyse. Elle exige que quelqu'un ait compris à la fois les processus métier et les dépendances techniques, et que l'organisation soit prête à entendre des réponses inconfortables. Une bonne vue de connectivité, représentant les risques, processus, actifs et fournisseurs sous forme de graphe interconnecté, accélère énormément cette analyse. On voit alors d'un coup d'œil quels nœuds portent le plus de connexions, ce sont les points critiques.

5 · Priorisation par l'écart brut-résiduel

La manière méthodologiquement la plus élégante de prioriser les investissements est d'examiner l'écart brut-résiduel : la distance entre le risque sans mesures de protection et le risque avec les mesures actuellement mises en œuvre. Là où cet écart est faible, les contrôles fonctionnent déjà. Là où il est grand, une action s'impose.

Un exemple simple. Prenons trois risques sur une échelle 5×5 (1 = très faible, 25 = catastrophique) :

• Risque A : Attaque de phishing sur des collaborateurs ordinaires. Brut 12, Résiduel 6. Écart = 6.
• Risque B : Chiffrement par ransomware de la base de données clients. Brut 20, Résiduel 16. Écart = 4.
• Risque C : Compromission d'un compte administrateur de domaine via une vulnérabilité RDP non corrigée. Brut 22, Résiduel 18. Écart = 4.

La vision de conformité marquerait le Risque A comme « bien couvert » (résiduel à 6) et passerait à la suite. La vision basée sur le risque demande : pourquoi les résiduels de B et C sont-ils si élevés ? Et plus important encore : où le prochain investissement sera-t-il le plus rentable ?

Investir davantage de ressources dans l'anti-phishing pourrait abaisser le résiduel du Risque A de 6 à 4. Un gain de 2 points. Investir à la place dans le durcissement des accès privilégiés pourrait faire tomber le résiduel du Risque C de 18 à 10. Un gain de 8 points, sur un risque qui est existentiel en cas d'urgence.

Ceux qui examinent systématiquement les décisions d'investissement de cette manière aboutissent à une feuille de route de sécurité différente de ceux qui cochent des listes. Et la direction comprend soudainement pourquoi le budget va là où il va, parce que l'argument n'est pas « l'ISO l'exige » mais « c'est ainsi que nous réduisons notre plus grand risque résiduel ».

6 · Moins de frais généraux, plus d'impact

L'argument selon lequel un programme basé sur le risque serait plus contraignant qu'un programme piloté par la conformité ne résiste pas à la réalité. C'est le contraire qui est vrai : l'effort se déplace, mais diminue globalement, et l'impact augmente.

Là où l'effort est économisé :

• Plus de pseudo-contrôles. Les mesures n'adressant aucun risque mesurable sont éliminées lors de la revue annuelle. Cela réduit la charge de maintenance, de reporting et d'audit pour tout le reste de l'année.
• Programme de sensibilisation ciblé. Au lieu d'acheter des formations obligatoires génériques pour tous les 700 collaborateurs, un programme spécifique est dispensé aux 40 personnes disposant d'accès privilégiés, et une formation de base plus courte pour tout le reste. Même effet, fraction du coût.
• Réduction de la prolifération des fournisseurs. Ceux qui ont nommé les vrais risques peuvent acheter trois produits de sécurité qui adressent réellement ces risques, plutôt que douze produits aux fonctions qui se chevauchent, dont aucun ne délivre jamais sa pleine valeur.
• Audits plus légers. Un auditeur qui trouve un registre des risques fonctionnel et des évaluations brut-résiduel claires travaille plus rapidement qu'un qui doit parcourir 140 pages de documentation de politique sans contexte.

Là où l'effort s'ajoute :

• Identification et évaluation initiales des risques. Ce n'est pas trivial et nécessite l'implication des métiers. Effort typique pour une entreprise de taille moyenne : deux à quatre ateliers sur six à huit semaines, plus la maintenance continue par un rôle à temps partiel.
• Évaluation continue de l'efficacité. Au lieu de « contrôle mis en œuvre : oui/non », on évalue dans quelle mesure un contrôle fonctionne. Cela demande un peu plus de réflexion par mesure.
• Communication avec la direction. Le langage du risque doit être introduit, ce qui se révèle rapidement rentable, car les décisions peuvent être prises de manière plus transparente et plus rapide.

Au final : l'effort total diminue, et d'autant plus clairement que le programme dure depuis longtemps. L'investissement au départ est l'identification des risques et des joyaux de la couronne ; ensuite le modèle s'amortit chaque année.

7 · Un point de départ pratique

Celui qui souhaite démarrer un programme de sécurité basé sur le risque après avoir travaillé jusqu'ici principalement de manière orientée conformité n'a pas besoin de tout changer d'un coup. Une entrée par étapes fonctionne bien :

Étape 1 : Atelier joyaux de la couronne. Une demi-journée avec la direction, idéalement animée par quelqu'un qui n'a pas besoin de fournir lui-même les détails techniques. L'objectif est une liste de cinq à sept joyaux de la couronne avec une justification claire de leur caractère critique.

Étape 2 : Mettre en place un inventaire des risques. Pour chaque joyau de la couronne, les trois à cinq menaces les plus importantes sont identifiées et évaluées avec des valeurs brutes et résiduelles. Cela produit la première version du registre des risques, pas exhaustive, mais significative.

Étape 3 : Analyse des points critiques. Quels composants d'infrastructure partagée (identité, sauvegarde, plateformes centrales) sont utilisés simultanément par plusieurs joyaux de la couronne ? Ces composants sont traités séparément et priorisés.

Étape 4 : Cartographie des mesures. Les contrôles existants sont rattachés aux risques identifiés. Ce qui ne peut être rattaché à aucun risque est remis en question. Ce qui ne réduit pas suffisamment un risque reçoit des mesures nouvelles ou complémentaires.

Étape 5 : Revue trimestrielle. Le registre des risques est discuté chaque trimestre avec la direction, brièvement, de manière ciblée, avec des points de décision clairs. Les nouvelles initiatives (nouvelle application, nouveau fournisseur, nouvelle réglementation) sont examinées sous l'angle de leur profil de risque avant d'être mises en œuvre.

Une PME suisse réalise typiquement cette phase en trois à six mois avec des capacités internes et un soutien externe ponctuel. Le résultat est un programme de sécurité qui ne cherche plus à tout faire également bien, mais qui fait vraiment bien les quelques domaines véritablement importants, et maintient le reste à un niveau de base approprié.

Perspectives

La gestion de la cybersécurité basée sur le risque n'est ni un nouveau cadre de référence ni un produit. C'est une posture : d'abord comprendre ce qui est en jeu, puis décider ce qui doit être fait. Cette posture a des conséquences pratiques, elle réduit les frais généraux, augmente l'impact, rend les investissements de sécurité compréhensibles pour la direction et place l'organisation dans une situation où elle réagit aux incidents non pas avec surprise, mais avec préparation.

Celui qui démarre aujourd'hui avec un programme piloté par la conformité et y ajoute un prisme basé sur le risque n'a pas besoin de renoncer aux investissements existants. Au contraire : beaucoup de ce qui existe déjà peut être intégré dans le nouveau modèle, les résultats deviendront simplement plus visibles et mieux justifiés. Les vrais points critiques de l'organisation sont adressés, les contrôles non pertinents disparaissent, et il en résulte un programme qui coûte moins, accomplit plus et se présente à l'extérieur, face aux auditeurs, clients et régulateurs, de manière nettement plus solide que n'importe quelle collection de certifications.

Le chemin vers cela commence par une simple question que chaque organisation devrait se poser honnêtement : Qu'est-ce qui nous nuirait réellement dans douze mois, et faisons-nous suffisamment pour l'empêcher précisément ?