Dans beaucoup d’organisations, la cybersécurité commence encore par une question technologique : Quel firewall devons-nous acheter ? Faut-il un SIEM ? Devons-nous déployer un EDR ? Avons-nous besoin d’un PAM, d’un DLP, d’un WAF ou d’une nouvelle solution de sauvegarde ?
La question paraît légitime. Elle est pourtant souvent posée trop tôt.
Un firewall, un SIEM, un EDR ou une plateforme de gestion des vulnérabilités ne constitue pas, en soi, une stratégie de cybersécurité. Ce sont des mesures de traitement qui n’ont de sens que lorsqu’elles répondent à des scénarios de risque identifiés, évalués et priorisés.
Une organisation peut disposer d’équipements de sécurité coûteux, de solutions réputées et d’une architecture techniquement impressionnante, tout en restant fortement exposée. À l’inverse, une organisation disposant d’un budget plus limité peut réduire significativement son niveau de risque si elle investit dans les contrôles réellement adaptés à ses activités, à ses menaces et à ses dépendances.
La différence entre les deux approches tient essentiellement à une question :
Quel risque cherchons-nous exactement à réduire ?
C’est cette question qui devrait précéder tout investissement significatif en cybersécurité.
La gouvernance, la gestion des risques et la conformité couvrent naturellement un champ beaucoup plus large que la seule question des investissements technologiques. Pour celles et ceux qui souhaitent reprendre ces fondamentaux dans leur ensemble, j’ai structuré une Académie GRC Cyber.
Avec cet article, j’ai volontairement voulu faire un zoom sur un sujet plus précis, mais déterminant : la manière dont une organisation devrait relier ses décisions d’investissement en cybersécurité à ses risques réels.
Le problème : transformer la cybersécurité en catalogue de technologies
Le marché de la cybersécurité encourage naturellement une lecture technologique des problèmes. Les entreprises sont exposées à une succession permanente de nouvelles solutions : EDR, XDR, NDR, SIEM, SOAR, SASE, CASB, CSPM, CNAPP, PAM, DLP, deception technology, threat intelligence platforms, solutions de microsegmentation ou encore plateformes de simulation d’attaque.
Chacune peut répondre à de véritables besoins.
Le problème apparaît lorsque l’organisation commence à construire son dispositif de sécurité en partant de ces technologies plutôt que de ses risques.
Une décision telle que « nous devons acheter un SIEM » devrait immédiatement provoquer plusieurs questions.
Quels scénarios de risque nécessitent cette capacité de détection ? Quels événements devons-nous détecter ? Sur quels systèmes ? Quelles sources de journaux sont disponibles ? Qui analysera les alertes ? Quelles procédures seront déclenchées lorsqu’une compromission sera détectée ? Avons-nous les ressources humaines nécessaires pour exploiter la plateforme ? Et surtout : quel niveau de risque cette solution doit-elle permettre de réduire ?
Sans réponses claires à ces questions, le SIEM risque de devenir un simple collecteur de logs particulièrement coûteux.
Le même raisonnement vaut pour toutes les autres technologies.
Un EDR ne remplace pas une politique de privilèges correcte. Un firewall ne corrige pas une architecture réseau incohérente. Un PAM ne résout pas automatiquement une mauvaise gouvernance des comptes administrateurs. Un DLP ne compense pas l’absence de classification de l’information. Un scanner de vulnérabilités n’a que peu de valeur si aucune capacité de remédiation n’existe derrière lui.
La technologie peut renforcer une architecture de sécurité.
Elle ne remplace jamais la compréhension du risque.
Partir de la mission de l’organisation
La cybersécurité ne protège pas des firewalls, des serveurs ou des bases de données pour eux-mêmes.
Elle protège la capacité de l’organisation à fonctionner.
Prenons une entreprise fictive que nous appellerons Sahel Distribution & Services, SDS.
L’entreprise décide de renforcer sa cybersécurité.
Une première proposition technique prévoit l’acquisition de nouveaux firewalls, d’un SIEM, d’un EDR, d’une solution DLP et d’un outil PAM. L’investissement total envisagé dépasse 180 millions de FCFA sur plusieurs années, licences et maintenance comprises.
Sur le papier, le projet semble sérieux.
Pourtant, aucune analyse de risque structurée n’a encore été réalisée.
Autrement dit, SDS connaît déjà les solutions qu’elle souhaite acheter alors qu’elle n’a pas encore clairement établi les risques qu’elle cherche à traiter.
C’est exactement l’ordre qu’il faut inverser.
Avant de parler d’outils, comprendre ce qui pourrait réellement faire mal
L’analyse commence par les activités critiques.
Pour SDS, l’arrêt du système de gestion des stocks pendant quelques minutes est probablement acceptable. Une indisponibilité de trois jours pendant une période de forte activité pourrait en revanche bloquer les livraisons, perturber la facturation, désorganiser les agences et provoquer des pertes financières importantes.
De même, la compromission du compte de messagerie d’un collaborateur n’a pas nécessairement le même impact que celle du directeur financier ou d’un administrateur du domaine.
Il faut donc quitter progressivement la logique de l’actif technique pour construire des scénarios de risque.
Un scénario pertinent pourrait être formulé ainsi :
Cette formulation change radicalement la discussion.
Nous ne demandons plus : « Avons-nous besoin d’un nouvel antivirus ? »
Nous demandons : « Quelles conditions permettraient à ce scénario de réussir, quelles seraient ses conséquences et quelles mesures peuvent interrompre la chaîne d’attaque ? »
C’est là que commence véritablement la gestion du risque cyber.
Le risque est un scénario, pas simplement une vulnérabilité
Une vulnérabilité technique n’est pas nécessairement un risque majeur.
Une version logicielle obsolète, une mauvaise configuration ou un port exposé constitue une faiblesse. Pour déterminer son importance, il faut comprendre comment elle pourrait être exploitée, contre quel actif, dans quel contexte et avec quelles conséquences.
Dans notre exemple, l’analyse menée chez SDS met en évidence plusieurs éléments :
- le VPN permet encore certaines authentifications sans MFA ;
- plusieurs comptes administrateurs disposent de privilèges excessifs ;
- certains administrateurs utilisent le même compte pour les opérations courantes et les opérations privilégiées ;
- certaines sauvegardes restent accessibles depuis l’environnement Active Directory ;
- les journaux de plusieurs serveurs critiques ne sont pas centralisés ;
- la capacité de détection des mouvements latéraux est faible ;
- aucune procédure formalisée de restauration massive après ransomware n’a réellement été testée.
Pris indépendamment, chacun de ces constats peut sembler être un simple problème technique.
Mis ensemble dans un scénario d’attaque cohérent, ils décrivent une trajectoire réaliste pouvant conduire à l’arrêt de l’entreprise.
La valeur de l’analyse de risque est précisément là : elle relie les faiblesses techniques aux conséquences métier.
Évaluer avant de traiter
Après l’identification du scénario vient son évaluation.
Il faut apprécier au minimum deux dimensions : la vraisemblance du scénario et la gravité de ses conséquences.
Mais une analyse mature ne devrait pas s’arrêter à une multiplication mécanique de deux notes.
L’impact peut être financier, opérationnel, réglementaire, juridique, contractuel ou réputationnel. Il peut également affecter la sécurité physique dans certains secteurs.
Dans le cas de SDS, une attaque ransomware immobilisant l’ERP et le système logistique pendant cinq jours pourrait provoquer une interruption des livraisons, l’impossibilité d’émettre certaines factures, des pénalités contractuelles, des coûts de reconstruction du système d’information et une dégradation de la confiance de certains partenaires.
L’entreprise estime, à titre d’hypothèse de travail, que l’impact global d’un incident majeur de cette nature pourrait dépasser plusieurs centaines de millions de FCFA.
À partir de ce moment, la discussion budgétaire change.
Un investissement de 20 millions de FCFA n’est plus évalué parce que « la technologie est intéressante ». Il est analysé par rapport à sa contribution au traitement d’un scénario dont l’impact potentiel est nettement supérieur.
Cette relation entre risque métier, mesure de sécurité et coût du traitement devrait apparaître dans toute décision importante d’investissement cyber.
Examiner d’abord les contrôles existants
Une autre erreur fréquente consiste à considérer chaque risque comme s’il fallait nécessairement acheter quelque chose pour le traiter.
Avant toute acquisition, il faut examiner les contrôles déjà présents.
SDS possède déjà un firewall capable de supporter une authentification forte. Son environnement Microsoft permet certaines fonctions avancées de protection des identités. Des mécanismes de segmentation existent mais sont mal exploités. La plateforme de virtualisation permet d’améliorer certaines stratégies de sauvegarde et de restauration.
L’entreprise découvre alors qu’une partie du risque peut être réduite par de la configuration, de l’architecture, de la procédure et de la gouvernance.
Cela change profondément la stratégie d’investissement.
Le premier plan de traitement ne commence finalement pas par l’achat de nouveaux firewalls. Il commence par la généralisation du MFA sur les accès distants, la séparation des comptes d’administration, la réduction des privilèges, l’isolation des sauvegardes, le durcissement de l’Active Directory, l’amélioration de la segmentation réseau et l’organisation d’exercices de restauration.
Certaines mesures coûtent peu financièrement.
Elles demandent en revanche de la compétence, de la discipline opérationnelle et parfois une transformation de l’architecture existante.
C’est un point fondamental : le contrôle le plus efficace n’est pas nécessairement celui qui coûte le plus cher.
La technologie doit apparaître comme conséquence de l’analyse
Après l’application de ces premières mesures, SDS réévalue son scénario ransomware.
Le risque a diminué, mais certaines faiblesses persistent.
L’entreprise reste notamment limitée dans sa capacité à détecter rapidement l’utilisation anormale des comptes privilégiés, les mouvements latéraux ou certains comportements malveillants sur les postes et serveurs.
À ce stade, le déploiement d’un EDR ou d’une capacité équivalente devient cohérent.
La logique est désormais claire :
Scénario de risque → insuffisance des contrôles existants → capacité de sécurité nécessaire → solution technologique.
Et non :
Solution disponible sur le marché → recherche d’un problème permettant de justifier son achat.
La différence peut sembler subtile. Elle change pourtant toute la gouvernance de la cybersécurité.
Le cas du SIEM : acheter une capacité plutôt qu’un produit
L’exemple du SIEM illustre particulièrement bien cette logique.
Une organisation peut décider qu’elle souhaite « avoir un SIEM ». Cette formulation est insuffisante.
Ce dont elle a réellement besoin est peut-être la capacité de détecter :
- une modification anormale des groupes administrateurs ;
- une succession inhabituelle d’échecs d’authentification ;
- l’utilisation d’un compte privilégié depuis une machine inhabituelle ;
- la désactivation d’un agent de sécurité ;
- une connexion depuis une zone géographique incohérente ;
- une création massive de comptes ;
- une exfiltration potentielle de données.
Une fois ces cas d’usage identifiés, il devient possible de déterminer quelles sources de logs doivent être collectées, combien de temps elles doivent être conservées, quelles règles de détection doivent être développées, qui doit analyser les alertes et quelle procédure de réponse doit être déclenchée.
Le SIEM cesse alors d’être un équipement.
Il devient l’un des composants d’une capacité de détection et de réponse.
Cette distinction est essentielle.
Une organisation n’achète pas réellement un EDR. Elle cherche une capacité de détection sur les endpoints.
Elle n’achète pas réellement un PAM. Elle cherche une capacité de contrôle des accès privilégiés.
Elle n’achète pas réellement un DLP. Elle cherche à réduire le risque de divulgation ou d’exfiltration d’informations sensibles.
Elle n’achète pas réellement une solution de sauvegarde. Elle cherche à garantir une capacité de restauration compatible avec les objectifs de continuité de ses activités.
La technologie n’est donc qu’une composante de la capacité recherchée.
Un contrôle qui ne peut pas être opéré est un mauvais investissement
La gestion du risque doit également intégrer une réalité souvent négligée : l’organisation doit être capable d’exploiter les solutions qu’elle achète.
Imaginons que SDS déploie un SIEM capable de générer plusieurs milliers d’événements de sécurité par jour.
Qui qualifiera les alertes ?
Qui assurera l’investigation ?
Existe-t-il une astreinte ?
Les administrateurs savent-ils produire les informations nécessaires lors d’un incident ?
Existe-t-il des procédures d’escalade ?
Le SOC, s’il existe, dispose-t-il des accès nécessaires ?
Les journaux critiques sont-ils réellement disponibles ?
Les règles de détection ont-elles été adaptées au contexte de l’entreprise ?
Une technologie sophistiquée exploitée à 10 % de ses capacités peut produire moins de valeur qu’un dispositif beaucoup plus simple correctement intégré dans les opérations.
Le coût réel d’un contrôle doit donc inclure son acquisition, ses licences, son intégration, son exploitation, sa maintenance, les compétences nécessaires, la formation, la supervision et éventuellement les ressources humaines supplémentaires.
Le bon indicateur n’est pas le prix d’achat.
C’est le coût total de possession mis en regard de la réduction du risque obtenue.
Construire une matrice de décision d’investissement
C’est ici que le raisonnement peut être poussé plus loin.
Identifier les risques et proposer des contrôles ne suffit pas. Il faut encore disposer d’un mécanisme permettant d’arbitrer les investissements.
Pour SDS, la direction décide donc de construire une matrice de décision d’investissement cyber.
L’objectif n’est pas de produire une vérité mathématique. Une notation quantitative ne doit jamais donner l’illusion d’une précision que l’analyse ne possède pas. La matrice sert avant tout à rendre les hypothèses visibles, comparer les priorités et documenter les décisions.
Pour cet exercice, SDS utilise une échelle de vraisemblance et d’impact allant de 1 à 5. Le score de risque présenté ci-dessous est volontairement simplifié afin d’illustrer le raisonnement. Dans une organisation réelle, les critères, seuils et règles d’acceptation doivent être définis selon son propre contexte et son appétence au risque.
Matrice de décision simplifiée de SDS
| Scénario de risque | Risque inhérent | Faiblesse principale | Traitement prioritaire | Investissement envisagé | Coût indicatif sur 3 ans | Risque cible | Décision |
|---|---|---|---|---|---|---|---|
| Compromission d’un accès distant puis prise de contrôle de l’AD | 4 × 5 = 20 | MFA incomplet, privilèges excessifs, comptes admin mal séparés | Généralisation MFA, durcissement AD, séparation des comptes, réduction des privilèges | PAM après mesures organisationnelles et techniques initiales | 12 M FCFA | 8 | Traiter immédiatement |
| Propagation d’un ransomware aux serveurs critiques | 4 × 5 = 20 | Visibilité endpoint insuffisante, segmentation perfectible | Durcissement, segmentation, EDR, procédures de confinement | EDR sur actifs critiques | 24 M FCFA | 8 | Traiter immédiatement |
| Chiffrement ou destruction des sauvegardes | 4 × 5 = 20 | Sauvegardes accessibles depuis le domaine, tests insuffisants | Isolation, immutabilité, comptes dédiés, restauration régulière | Renforcement architecture de sauvegarde | 18 M FCFA | 5 | Priorité critique |
| Détection trop tardive d’une compromission | 4 × 4 = 16 | Logs dispersés, corrélation faible | Définir cas d’usage, centraliser les logs, organiser la réponse | SIEM ciblé et montée en puissance progressive | 28 M FCFA | 8 | Déploiement par phases |
| Exfiltration d’informations sensibles | 3 × 5 = 15 | Classification des données insuffisante | Classification, règles d’accès, revue des partages, journalisation | DLP uniquement après structuration de la gouvernance des données | 20 M FCFA | 9 | Différer l’achat du DLP |
| Compromission du portail partenaire | 3 × 4 = 12 | Tests applicatifs irréguliers, exposition Internet | Secure SDLC, tests de sécurité, gestion des vulnérabilités, durcissement | WAF si le risque résiduel le justifie | 9 M FCFA | 6 | Traiter d’abord sans acquisition majeure |
Les montants sont purement illustratifs. Les scores le sont aussi. Ce qui importe ici n’est pas le chiffre exact, mais le mécanisme de décision.
Cette matrice produit déjà plusieurs enseignements intéressants.
Le DLP est techniquement pertinent, mais l’achat est prématuré
Le risque d’exfiltration de données est réel.
Pourtant, SDS ne dispose pas encore d’une classification suffisamment mature de ses informations. Elle maîtrise mal certains partages et n’a pas totalement défini les règles de manipulation des données sensibles.
Acheter immédiatement une solution DLP reviendrait donc à automatiser des règles qui ne sont pas encore clairement établies.
La décision n’est pas : « le DLP est inutile ».
La décision est :
« Le contrôle technologique n’est pas encore la première mesure à mettre en œuvre. »
C’est très différent.
Le PAM peut être pertinent sans être la première dépense
Le risque associé aux comptes privilégiés est critique.
Mais SDS constate qu’une partie importante de l’exposition provient de pratiques élémentaires : comptes partagés, privilèges excessifs, absence de séparation entre compte bureautique et compte administrateur, mauvaise gestion de certains accès.
Avant de déployer un PAM complexe, l’entreprise peut déjà supprimer une partie significative du risque.
Le PAM devient alors un outil venant consolider une gouvernance des privilèges déjà structurée, et non une technologie chargée de masquer son absence.
Le SIEM devient un projet progressif
La matrice montre également que le besoin de détection est élevé.
Mais au lieu de lancer immédiatement un projet de collecte massive de tous les journaux disponibles, SDS choisit de commencer par les risques prioritaires.
Elle identifie d’abord une dizaine de cas d’usage critiques : modification des groupes privilégiés, création de comptes administrateurs, authentifications anormales, désactivation des protections endpoint, mouvements latéraux suspects, activités inhabituelles sur les serveurs sensibles et événements liés aux sauvegardes.
Les sources de journaux sont ensuite sélectionnées en fonction de ces cas d’usage.
Cette approche réduit les coûts, améliore la qualité de la détection et évite de transformer le SIEM en dépôt de logs sans finalité opérationnelle.
Comparer le budget initial au budget piloté par le risque
Le premier projet de SDS dépassait 180 millions de FCFA et reposait essentiellement sur une liste de technologies.
Après analyse, certaines dépenses sont maintenues, d’autres sont réduites, certaines sont reportées et plusieurs mesures non technologiques deviennent prioritaires.
L’entreprise peut ainsi construire un programme en plusieurs étapes.
La première vague porte sur les identités, les privilèges, la sauvegarde, le durcissement et la segmentation.
La deuxième renforce la capacité de détection sur les endpoints et les actifs critiques.
La troisième construit progressivement une capacité centralisée de surveillance et de corrélation.
Le DLP, le PAM dans sa forme la plus avancée ou certaines briques supplémentaires restent conditionnés à l’évolution du niveau de maturité et au risque résiduel observé après les premières actions.
Ce séquencement est fondamental.
Il ne s’agit pas nécessairement de dépenser moins. Il s’agit de dépenser dans le bon ordre.
Une matrice d’investissement ne doit pas devenir un simple tableau Excel
Il faut toutefois éviter un autre piège.
Une matrice de risque très détaillée peut donner une impression de maîtrise sans produire de décision réelle.
Une organisation peut parfaitement disposer de vingt colonnes, de scores colorés, de formules complexes et de plusieurs centaines de risques sans être capable de répondre à une question simple :
Quel scénario devons-nous traiter en premier et pourquoi ?
La matrice doit donc rester un support d’arbitrage.
Pour chaque investissement majeur, quelques informations devraient être immédiatement compréhensibles par la gouvernance :
Risque concerné → exposition actuelle → contrôles existants → déficit de maîtrise → options de traitement → coût total → réduction attendue → risque résiduel → décision.
Si l’une de ces relations est impossible à expliquer, la justification de l’investissement mérite probablement d’être retravaillée.
Toutes les décisions ne conduisent pas à un achat
La gestion du risque offre plusieurs possibilités.
Une organisation peut décider de réduire un risque en mettant en œuvre de nouveaux contrôles. Elle peut éviter certaines activités à l’origine du risque. Elle peut transférer une partie des conséquences, par exemple à travers certains mécanismes contractuels ou assurantiels. Elle peut également accepter le risque lorsqu’il se situe dans les limites définies par la gouvernance.
L’achat d’une technologie n’est donc qu’une possibilité parmi plusieurs.
Plus encore, un même scénario peut être traité par une combinaison de mesures préventives, détectives, correctives et organisationnelles.
Prenons le ransomware chez SDS.
Le MFA contribue à réduire la probabilité d’une compromission initiale.
La réduction des privilèges limite les possibilités d’escalade.
La segmentation réduit la capacité de propagation.
L’EDR augmente les possibilités de détection et de confinement.
L’isolation des sauvegardes réduit l’impact potentiel.
Le PRA et les tests de restauration renforcent la capacité de reprise.
Aucun de ces contrôles ne résout seul le scénario.
C’est leur articulation qui construit la résilience.
Le risque résiduel doit revenir dans la décision
Une fois les contrôles déployés, la matrice ne doit pas être archivée.
Le scénario doit être réévalué.
Prenons le premier risque de SDS, initialement évalué à 20.
Après généralisation du MFA, durcissement Active Directory, réduction des privilèges, séparation des comptes d’administration et amélioration de la surveillance, l’organisation estime que son exposition est ramenée à 8.
La vraie question devient alors :
Ce niveau résiduel de risque est-il acceptable ?
Si la réponse est oui, des investissements supplémentaires peuvent avoir une priorité moindre.
Si la réponse est non, l’organisation doit déterminer quel contrôle complémentaire pourrait réduire l’exposition.
C’est précisément à ce niveau qu’un investissement plus important, comme un PAM avancé, peut devenir justifiable.
Le risque résiduel empêche ainsi la cybersécurité de tomber dans une logique d’accumulation infinie de technologies.
Il faut également mesurer le coût de ne rien faire
La réflexion économique ne doit pas porter uniquement sur le prix d’une solution.
Ne rien faire a également un coût potentiel.
Supposons que SDS hésite à investir 18 millions de FCFA dans le renforcement de son dispositif de sauvegarde.
Pris isolément, le montant peut paraître important.
Mais le scénario associé pourrait provoquer plusieurs jours d’interruption, des coûts de reconstruction, des pertes de revenus, des pénalités contractuelles et des conséquences réputationnelles largement supérieures.
Cela ne signifie pas qu’il suffit de comparer mécaniquement 18 millions à plusieurs centaines de millions pour conclure que l’investissement est rentable.
La fréquence du scénario reste incertaine. L’efficacité réelle du contrôle doit être évaluée. Le coût total de possession doit être pris en compte. D’autres options de traitement peuvent exister.
Mais cette mise en perspective permet de replacer l’investissement dans le bon cadre :
le coût du contrôle doit être analysé face au risque qu’il contribue à réduire, et non isolément.
Le cas du ROI cyber mérite de la prudence
La tentation est grande de vouloir calculer un retour sur investissement classique pour chaque mesure de cybersécurité.
Cette approche doit être utilisée avec prudence.
Une machine industrielle supplémentaire peut produire un volume supplémentaire mesurable. Une solution de sécurité produit souvent une valeur différente : elle réduit la probabilité ou l’impact d’un événement que l’organisation espère précisément ne jamais subir.
Certaines méthodes utilisent des notions telles que la perte annuelle attendue ou le ROSI, le Return on Security Investment. Elles peuvent être utiles pour structurer une décision lorsque des données suffisamment fiables existent.
Mais une pseudo-précision mathématique peut être dangereuse.
Dire qu’un ransomware coûtera exactement 437 250 000 FCFA et qu’il se produira une fois tous les 3,7 ans n’apporte aucune rigueur si les données utilisées pour produire ces nombres sont extrêmement incertaines.
Dans de nombreux contextes, une combinaison cohérente d’analyse qualitative, semi-quantitative et financière sera plus défendable qu’un calcul très sophistiqué construit sur des hypothèses fragiles.
La maturité consiste aussi à savoir ce que l’on sait, ce que l’on estime et ce que l’on ignore.
Cartographier chaque investissement à un risque
Une discipline simple permet d’améliorer considérablement les décisions :
aucun investissement cyber significatif ne devrait être présenté à une direction sans rattachement explicite à un ou plusieurs risques.
Pour chaque projet, la fiche de décision devrait permettre de retrouver au minimum :
- le scénario de risque concerné ;
- les actifs ou processus métier affectés ;
- le niveau de risque actuel ;
- les contrôles existants ;
- les lacunes observées ;
- les options de traitement étudiées ;
- la solution retenue et les raisons du choix ;
- le coût total prévisionnel ;
- la réduction attendue du risque ;
- le risque résiduel cible ;
- le responsable du risque ;
- les indicateurs qui permettront de vérifier l’efficacité du traitement.
Cette discipline modifie complètement la conversation avec la direction.
La question n’est plus :
« Pourquoi voulez-vous encore acheter une solution cyber ? »
Elle devient :
« Quel risque prioritaire ce financement permet-il de réduire et dans quelle proportion ? »
Le risque résiduel : la sécurité absolue n’existe pas
Même après traitement, aucun risque sérieux ne disparaît totalement.
Le scénario ransomware de SDS reste possible après le renforcement des contrôles. Sa vraisemblance et son impact ont simplement été ramenés à un niveau jugé plus acceptable.
C’est le risque résiduel.
Cette notion est essentielle parce qu’elle replace la décision au bon niveau.
Le RSSI ou les équipes techniques peuvent analyser et recommander des traitements. Ils ne devraient pas être seuls à décider du niveau de risque que l’entreprise accepte.
Lorsqu’un risque significatif subsiste, son acceptation appartient normalement au propriétaire du risque ou à l’autorité disposant du mandat correspondant.
Cette gouvernance évite une situation très fréquente dans laquelle la direction croit avoir « transféré » le problème au service informatique simplement parce qu’un budget de cybersécurité a été approuvé.
Acheter des technologies ne transfère pas la responsabilité du risque.
Mesurer la réduction du risque, pas le nombre d’équipements installés
Une stratégie pilotée par le risque change également les indicateurs.
Dire que « 100 % des firewalls ont été remplacés » constitue un indicateur de déploiement.
Cela ne prouve pas que l’organisation est mieux protégée.
Des indicateurs plus utiles chercheraient à mesurer l’évolution des capacités réellement associées aux scénarios prioritaires : couverture MFA des comptes sensibles, proportion de comptes privilégiés correctement séparés, délai moyen de révocation d’un compte compromis, taux de couverture EDR des actifs critiques, délai de détection d’un comportement anormal, fréquence et succès des restaurations testées, nombre de vulnérabilités critiques dépassant le délai de correction ou encore capacité à restaurer un service essentiel dans les objectifs fixés.
Cette approche permet progressivement de répondre à la seule question qui intéresse réellement la gouvernance :
Notre niveau de risque diminue-t-il ?
Les équipements ne doivent pas dicter l’architecture de sécurité
Une organisation mature devrait être capable de décrire son architecture de sécurité avant même de citer les marques et les produits utilisés.
Elle devrait pouvoir expliquer où se trouvent ses actifs critiques, quelles frontières de confiance existent, comment les identités sont gérées, comment les accès privilégiés sont contrôlés, quelles données sont sensibles, comment les systèmes sont segmentés, comment les attaques sont détectées, comment les incidents sont contenus et comment les activités sont restaurées.
Les technologies viennent ensuite matérialiser certaines de ces fonctions.
Lorsque l’architecture est construite autour des produits, chaque renouvellement technologique devient un bouleversement.
Lorsque l’architecture est construite autour des risques et des capacités de sécurité, les technologies deviennent remplaçables.
C’est une différence majeure en matière de maîtrise des coûts, de résilience et d’autonomie technologique.
Le budget cyber devrait lui aussi être piloté par le risque
Cette logique doit finalement se retrouver dans le budget.
Un budget de cybersécurité ne devrait pas être une collection de lignes telles que « firewall », « antivirus », « SIEM », « licences » ou « scanner de vulnérabilités ».
Il devrait être possible de relier ces dépenses à des objectifs de réduction du risque.
Par exemple :
Risque : compromission des identités privilégiées.
Le budget associé peut financer du MFA, du durcissement Active Directory, de la journalisation, une solution PAM, de la formation administrateur et des audits périodiques.
La direction peut alors comprendre ce qu’elle finance.
Elle ne finance plus « un PAM ».
Elle finance la réduction du risque de compromission des comptes disposant des privilèges les plus élevés de l’entreprise.
Ce changement de langage est particulièrement important lorsque les décisions arrivent au comité de direction.
La direction générale n’a pas nécessairement besoin de comprendre toutes les différences entre EDR, XDR ou NDR.
Elle doit en revanche comprendre ce qui pourrait interrompre l’activité, exposer des données sensibles, provoquer des pertes financières, engager la responsabilité de l’organisation ou porter atteinte à sa réputation.
C’est dans ce langage que la cybersécurité devient véritablement une fonction de gestion du risque.
Une question simple à poser avant chaque achat
Avant toute nouvelle acquisition importante, une organisation devrait être capable de répondre clairement à quelques questions.
Quel scénario de risque cherche-t-on à traiter ? Quel actif ou processus métier est concerné ? Quelle faiblesse rend aujourd’hui ce scénario possible ? Quels contrôles existent déjà ? Pourquoi sont-ils insuffisants ? Quelle réduction du risque attendons-nous de la nouvelle mesure ? Comment cette efficacité sera-t-elle mesurée ? Qui exploitera la solution ? Quel risque subsistera après son déploiement ?
Et j’ajouterais une dernière question, probablement l’une des plus importantes :
Si nous n’achetions pas cette solution aujourd’hui, quel risque accepterions-nous réellement ?
Si ces réponses ne sont pas disponibles, la décision d’achat est probablement prématurée.
Conclusion : n’achetez pas une technologie, traitez un risque
Le problème n’est pas d’acheter des équipements de sécurité.
Les organisations en ont besoin.
Le problème est de commencer par eux.
Une stratégie de cybersécurité solide part de la mission de l’organisation, identifie les activités et les actifs dont elle dépend, construit des scénarios de risque crédibles, évalue les contrôles existants, décide du traitement approprié puis seulement détermine les capacités techniques nécessaires.
Dans cette logique, un firewall, un EDR, un SIEM, un PAM ou un DLP n’est jamais une finalité.
C’est une réponse possible à une partie d’un risque.
Et parfois, l’analyse montrera que la meilleure réponse n’est pas un nouvel équipement, mais une meilleure architecture, une configuration corrigée, une suppression de privilèges, une procédure mieux conçue, une restauration réellement testée ou une responsabilité enfin clairement attribuée.
La maturité cyber d’une organisation ne se mesure donc pas au nombre de solutions présentes dans son datacenter ou dans son portefeuille de licences.
Elle se mesure à sa capacité à expliquer, pour chaque contrôle important :
voici le risque que nous avons identifié, voici pourquoi nous avons choisi cette mesure, voici ce qu’elle coûte, voici comment elle réduit notre exposition et voici le risque que nous acceptons encore après son déploiement.
C’est à ce moment-là que la cybersécurité cesse d’être une succession d’achats technologiques.
Elle devient une véritable discipline de gestion du risque.