Risques cybersécurité : de quoi parle-t-on vraiment

Risque, menace, vulnérabilité : ne pas confondre les trois

Le vocabulaire est mélangé partout, y compris dans des rapports d'audit facturés. Une menace, c'est un acteur ou un événement capable de nuire : un groupe de rançongiciel, un prestataire négligent, une coupure électrique, un salarié qui part avec un export client. Une vulnérabilité, c'est une faiblesse exploitable : une version d'OpenSSL non corrigée, un mot de passe réutilisé sur quatre services, l'absence de sauvegarde hors ligne. Le risque naît de la rencontre des deux, pondérée par ce que vous perdez si ça arrive. La formulation utilisée par l'ISO/IEC 27005 et le NIST SP 800-30 rev.1 revient au même produit : vraisemblance multipliée par impact.

Une vulnérabilité sans menace ne coûte rien. Une menace sans vulnérabilité non plus.

Prenez un serveur de recette avec une injection SQL notée 9,8 sur l'échelle CVSS. Il tourne sur un VLAN isolé, sans donnée réelle, éteint le week-end. Le score de la faille reste 9,8, le risque réel est faible. Déplacez la même machine derrière une IP publique avec la base de production à l'intérieur : pas une ligne de code n'a changé, et le risque a été multiplié. Le score décrit la faille, pas votre situation.

Conséquence pratique : un scanner de vulnérabilités ne produit jamais une analyse de risque. Il produit une liste d'entrée, que quelqu'un doit ensuite confronter au contexte métier.

Les familles de risques que vous rencontrerez réellement

Classer sert à ne rien oublier, pas à faire joli en comité de direction. Le découpage le plus utile sépare les origines (externe, interne, accidentelle, fournisseur), parce que les contre-mesures ne se ressemblent pas d'une origine à l'autre : un pare-feu ne fait rien contre un administrateur qui supprime la mauvaise base.

La panne bête reste largement sous-estimée. Un certificat TLS expiré à deux heures du matin coupe un service aussi net qu'un déni de service, sauf que personne ne vous a attaqué. Let's Encrypt délivre des certificats valides 90 jours : sans renouvellement automatique et sans supervision de ce renouvellement, l'incident revient quatre fois par an. Le même raisonnement vaut pour un nom de domaine non renouvelé ou un enregistrement DNS pointant vers un bucket cloud supprimé, cas classique de prise de contrôle de sous-domaine.

Le risque fournisseur mérite une ligne à part. Log4Shell (CVE-2021-44228, score CVSS 10,0, décembre 2021) n'a touché presque personne directement : la bibliothèque Log4j était embarquée dans des produits tiers, souvent sans que l'exploitant sache qu'elle était là. Sans inventaire des composants, vous ne pouvez même pas répondre à la question « suis-je concerné ».

Famille	Cas concret	Ce qui aggrave
Rançongiciel	Accès RDP ouvert sur le port 3389 avec un mot de passe réutilisé	Sauvegardes stockées sur le même annuaire Active Directory
Compromission de compte	Hameçonnage sur une boîte pro sans second facteur	Domaine sans SPF, DKIM ni DMARC, donc usurpable
Fuite de données	MongoDB (27017) ou Elasticsearch (9200) exposé sans authentification	Instance montée pour un test, jamais démontée
Indisponibilité	Certificat expiré, DDoS volumétrique, panne d'hébergeur	Aucune supervision externe : c'est le client qui alerte
Chaîne d'approvisionnement	Dépendance vulnérable tirée par le build (Log4j, paquet npm compromis)	Aucun inventaire logiciel, aucune veille sur les composants

Évaluer un risque : CVSS, EPSS et KEV ne disent pas la même chose

Trois référentiels circulent et beaucoup d'équipes les confondent. Le CVSS, maintenu par le FIRST (version 3.1, puis version 4.0 publiée en novembre 2023), note la gravité intrinsèque d'une faille de 0 à 10 : de 0,1 à 3,9 faible, de 4,0 à 6,9 moyenne, de 7,0 à 8,9 élevée, de 9,0 à 10,0 critique. Il ignore totalement votre architecture, votre exposition et vos données.

L'EPSS répond à une autre question : quelle probabilité que cette faille soit exploitée dans les trente prochains jours. Le résultat est un nombre entre 0 et 1, mis à jour quotidiennement. Une faille notée 9,1 en CVSS avec un EPSS de 0,002 attendra le prochain cycle de correctifs ; une faille notée 7,5 avec un EPSS de 0,7 se traite le jour même.

Le catalogue KEV de la CISA, lui, ne prédit rien : il liste ce qui est observé en exploitation active. Ordre de grandeur au moment où ces lignes sont écrites, un peu plus d'un millier d'entrées, face à un référentiel CVE qui dépasse les 250 000 identifiants publiés. Ces deux volumes évoluent chaque semaine, vérifiez-les à la source plutôt que de citer un chiffre figé.

Pour la partie méthode, EBIOS Risk Manager (ANSSI, 2018) et l'ISO/IEC 27005 travaillent sur des scénarios métier, pas sur des CVE. Les deux approches se complètent : l'une dit ce que vous avez à perdre, l'autre ce qui traîne comme trou technique.

• CVSS : gravité théorique, 0 à 10, stable dans le temps
• EPSS : probabilité d'exploitation à 30 jours, 0 à 1, recalculée chaque jour
• KEV (CISA) : exploitation constatée sur le terrain, liste binaire
• EBIOS RM / ISO 27005 : scénarios de risque au niveau métier, avec vraisemblance et impact
• OWASP Top 10 (édition 2021) : catégories applicatives, avec A01 sur le contrôle d'accès défaillant en tête

Ce qui vous expose vraiment côté réseau

Toute adresse IPv4 publique est scannée en permanence, sans exception et sans intention particulière vous concernant. L'outil ZMap, présenté à USENIX Security en 2013, balaye l'intégralité de l'espace IPv4 routable sur un port donné en moins de 45 minutes depuis une seule machine reliée en gigabit. Autrement dit, un service ouvert par erreur est découvert en moins d'une heure, pas en trois semaines. La discrétion n'est pas une mesure de sécurité.

Vérifiez depuis l'extérieur, jamais depuis le LAN. Le résultat n'est pas le même.

Une commande suffit pour la première passe : nmap -Pn -sS -p 22,445,3389,5432,6379,9200,27017 --open 203.0.113.10. Complétez avec dig pour repérer les enregistrements DNS orphelins, par exemple dig +short CNAME vieux-site.exemple.fr, et regardez si la cible existe encore. Un CNAME qui pointe vers une ressource cloud libérée se reprend par n'importe qui, et le sous-domaine sert ensuite à héberger une page d'hameçonnage sous votre nom.

Le rappel historique vaut la peine : WannaCry, en mai 2017, s'est propagé via SMBv1 sur le port TCP 445 en exploitant EternalBlue, alors que le correctif Microsoft MS17-010 était disponible depuis mars. Le facteur limitant n'était pas la sophistication de l'attaque, mais le délai de déploiement des correctifs.

• 22 (SSH) : à filtrer par IP source ou à placer derrière un VPN
• 445 (SMB) : n'a rien à faire sur Internet, jamais
• 3389 (RDP) : porte d'entrée numéro un des rançongiciels sur PME
• 3306 / 5432 (MySQL, PostgreSQL) : bases exposées par une mauvaise règle de groupe de sécurité
• 6379 (Redis) : sans mot de passe par défaut sur beaucoup d'installations
• 9200 / 27017 (Elasticsearch, MongoDB) : historiquement à l'origine de fuites massives

Réduire le risque, et ce que la réglementation impose

L'ordre compte plus que l'exhaustivité. Traitez d'abord ce qui est exposé publiquement et présent dans le KEV, ensuite ce qui touche les comptes à privilèges, ensuite le reste.

Sur les sauvegardes, la règle 3-2-1 tient toujours : trois copies, sur deux types de supports, dont une hors site et déconnectée. Le point de contrôle qui manque presque partout, c'est la restauration. Une sauvegarde jamais restaurée est une hypothèse, pas une protection, et un rançongiciel qui chiffre aussi le NAS de sauvegarde monté en permanence transforme cette hypothèse en sinistre complet. Testez une restauration complète au moins une fois par an, chronomètre en main, et notez le temps obtenu : c'est votre vrai délai de reprise, pas celui du contrat.

Côté obligations, deux textes structurent la contrainte en France. Le RGPD impose la notification d'une violation de données à la CNIL dans les 72 heures après en avoir pris connaissance (article 33), avec information des personnes concernées si le risque pour leurs droits est élevé. La directive NIS2 (UE 2022/2555), dont l'échéance de transposition était fixée au 17 octobre 2024, ajoute pour les entités essentielles et importantes une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final sous un mois.

La transposition française est intervenue après cette échéance, et le périmètre exact des entités concernées relève des textes d'application. Vérifiez votre statut auprès de l'ANSSI avant de bâtir un calendrier interne dessus.

Aucune de ces mesures ne ramène le risque à zéro, et un prestataire qui vous le promet vend autre chose que de la sécurité. L'objectif réaliste est de rendre l'attaque plus coûteuse que ce qu'elle rapporte, et de réduire le temps entre l'incident et sa détection.

• Second facteur d'authentification sur les accès distants, la messagerie et les consoles d'administration
• Correctifs sur les services exposés sous 48 h quand la faille figure au KEV
• Comptes d'administration nominatifs, séparés des comptes de travail quotidien
• Journalisation centralisée avec rétention d'au moins six mois, sinon l'investigation est impossible
• SPF, DKIM et DMARC en politique de rejet sur tous vos domaines, y compris ceux qui n'envoient pas d'e-mail

Questions fréquentes

Quelle différence entre un risque et une menace ?

La menace est l'acteur ou l'événement capable de nuire (un groupe criminel, un incendie, une erreur humaine). Le risque est ce qui se produit quand cette menace rencontre une faiblesse exploitable, multiplié par ce que vous perdez. Deux entreprises face à la même menace n'ont pas le même risque si l'une a des sauvegardes hors ligne testées et l'autre non.

Un score CVSS de 9,8 signifie-t-il qu’il faut corriger immédiatement ?

Pas mécaniquement. Le CVSS mesure la gravité théorique, hors contexte. Croisez-le avec l'exposition réelle du service, la présence de la faille dans le catalogue KEV de la CISA et son score EPSS. Une faille à 9,8 sur une machine coupée du réseau passe après une faille à 7,5 activement exploitée sur votre serveur web public.

Une petite structure est-elle vraiment visée ?

Rarement visée nommément, souvent touchée quand même. Les campagnes de rançongiciel fonctionnent par balayage automatisé : un service RDP ouvert sur le port 3389 est trouvé par scan en quelques dizaines de minutes, indépendamment de votre chiffre d'affaires. Le ciblage manuel intervient après, quand l'attaquant évalue ce qu'il a récupéré.

Faut-il payer une rançon ?

L'ANSSI recommande de ne pas payer. Le paiement ne garantit ni la restitution des données, ni la destruction de la copie exfiltrée, et il finance directement la campagne suivante. Certaines victimes payent et récupèrent un outil de déchiffrement lent ou partiel. Dans tous les cas, déposez plainte et conservez les journaux avant toute réinstallation, sinon l'analyse post-incident devient impossible.

Changer d’adresse IP publique réduit-il le risque ?

Marginalement, et pour peu de temps. Une nouvelle adresse IPv4 est redécouverte par les scanners en moins d'une heure. C'est utile pour couper une attaque en cours ou sortir d'une liste noire de réputation, pas comme mesure de fond. Ce qui réduit durablement le risque, c'est de fermer les services qui n'ont pas à être joignables depuis Internet.

Testez vos connaissances

À lire aussi

attaque ddos · cheval de troie · authentification a deux facteurs 2fa · chiffrement