Accueil/Guides pratiques/Cybersécurité

Cybersécurité

Les fondamentaux d’une défense cyber solide

Comment construire une défense cyber utile ? En reliant les actifs à protéger, les chemins d’accès, les signaux de détection et la capacité réelle de restauration. Ce guide propose six contrôles pour passer d’un inventaire à un plan d’action. Le livrable attendu est un registre daté : actif, exposition, conséquence métier, mesure, preuve, responsable et prochain contrôle. Les exemples sont des protocoles de travail, pas des résultats d’audit réalisés.

CVECERTZero Trust
Salle nocturne d’opérations de renseignement cyber, sans personnel
Illustration éditoriale générée par IA

Votre checklist d’action

  1. 01

    Recenser ce qui doit être protégé

    Inventoriez comptes, terminaux, applications, données et dépendances externes. Nommez un responsable pour chaque actif et identifiez les services dont une interruption aurait le plus d’impact. Distinguez actif découvert et actif attribué : un domaine ressemblant à votre marque ne prouve pas que vous l’administrez. Pour chaque service, notez propriétaire, environnement, données manipulées et dépendance métier. Conservez la date et la méthode de découverte pour reproduire l’inventaire.

  2. 02

    Protéger les identités

    Activez une authentification résistante au phishing lorsque disponible, séparez les comptes d’administration et retirez les accès inutiles. Testez la récupération des comptes avant une perte de terminal. Examinez aussi les comptes de service, jetons API et procédures d’assistance. Une authentification forte perd de son intérêt si une récupération non contrôlée la contourne. La preuve attendue associe test de connexion, refus d’un accès interdit et récupération supervisée.

  3. 03

    Prioriser les correctifs

    Croisez exposition Internet, criticité des actifs et informations d’exploitation active. Les catalogues d’alertes et le KEV de CISA aident à prioriser ; un score CVSS seul ne décrit pas votre risque. Le CVSS décrit une gravité technique ; l’EPSS estime une probabilité d’exploitation dans son cadre propre. Aucun ne remplace l’examen de l’exposition locale. Documentez la raison de chaque priorité et vérifiez la correction sur le service effectivement utilisé.

  4. 04

    Prouver la restauration

    Conservez des sauvegardes isolées et surveillées. Restaurez un service représentatif dans un environnement contrôlé, mesurez le temps réel et consignez ce qui manque pour reprendre. Une sauvegarde annoncée réussie ne démontre pas qu’un service redémarre. Vérifiez accès aux clés, dépendances, intégrité des données restaurées et fonctionnement d’un parcours métier. Séparez durée technique de restauration et temps total de retour au service.

  5. 05

    Rendre les événements observables

    Centralisez les journaux utiles, synchronisez les horloges et vérifiez une alerte de bout en bout. Définissez qui reçoit le signal, qui décide et combien de temps conserver les traces selon votre contexte. Déclenchez un événement de test autorisé, suivez son arrivée dans la collecte et vérifiez qu’une personne peut prendre une décision. Consignez les angles morts : source absente, horloge décalée, alerte sans destinataire ou rétention insuffisante pour l’enquête.

  6. 06

    Répéter la réponse

    Préparez les contacts, les décisions de confinement et les moyens de communication alternatifs. Faites un exercice sur table, préservez les preuves et vérifiez les obligations locales auprès des autorités compétentes. Choisissez un scénario limité, par exemple la compromission supposée d’un compte de messagerie. Rejouez qui autorise le confinement, qui conserve les traces et qui confirme la reprise. Une action n’est close qu’après contrôle de son résultat.

    Exemple pédagogique : une passerelle Internet possède une vulnérabilité signalée, mais la version installée et le composant activé restent inconnus. Vérifiez d’abord ces deux points avec l’administrateur. Si le service est concerné, consignez réduction d’exposition, correctif et test de retour au fonctionnement. L’absence d’alerte dans les journaux ne permet pas de conclure à l’absence de compromission lorsque la collecte ne couvrait pas la période utile.

Références : données, usages et limites

Documentation consultée le .

Vulnérabilité : trois lectures complémentairesCVE · Identifier. CVSS · Gravité technique. EPSS · Probabilité. KEV · Exploitation recensée. Version et produit concernés. Score de 0,0 à 10,0. Horizon de 30 jours. Catalogue officiel CISA. Décision locale : exposition, impact, preuves et contrôle de correction.Vulnérabilité : trois lectures complémentairesCVE · IdentifierVersion et produit concernésCVSS · Gravité techniqueScore de 0,0 à 10,0EPSS · ProbabilitéHorizon de 30 joursKEV · Exploitation recenséeCatalogue officiel CISADécision locale : exposition, impact, preuves et contrôle de correction
Vulnérabilité : trois lectures complémentaires
Références : données, usages et limites
Source et objetDonnée ou repère vérifiéComment l’utiliserLimite à conserver
FIRST · CVSS

Décrire la gravité technique d’une vulnérabilité avec une méthode et un vecteur explicites.

CVSS 4.0 produit des scores de 0,0 à 10,0. Les groupes Base, Threat, Environmental et Supplemental n’ont pas tous la même fonction. Conservez la version, le vecteur et la date du score. Rapprochez le résultat de la version installée, des chemins d’accès et des conséquences métier avant d’ordonner les correctifs.

Approfondir la méthode →

Un score élevé n’est pas une preuve d’exploitation ; un score faible ne signifie pas que le service ne présente aucun risque.
FIRST · EPSS

Estimer la probabilité d’exploitation d’une CVE publiée.

L’horizon du modèle est de 30 jours. Le score exprime une probabilité ; le percentile situe le score par rapport aux autres CVE. Notez la date des données et distinguez probabilité et percentile. Complétez avec l’exposition de l’actif et les informations d’exploitation confirmée.

Approfondir la méthode →

Le modèle ne prédit pas le préjudice pour votre organisation. Une probabilité basse n’annule pas une exposition critique.
CISA · Known Exploited Vulnerabilities

Repérer les vulnérabilités recensées par CISA comme exploitées.

Le catalogue relie notamment CVE, produit, date d’ajout et action requise. Son dépôt officiel propose aussi le schéma des données. Vérifiez l’applicabilité à vos produits et conservez la date de consultation. Examinez la mesure demandée et le bulletin du fournisseur avant de conclure à la correction.

Approfondir la méthode →

L’absence d’une CVE dans le catalogue n’établit pas son innocuité. Les échéances administratives du catalogue ne sont pas automatiquement une obligation pour toute organisation.
CVE Program

Relier les échanges à un même enregistrement de vulnérabilité.

Le format des enregistrements CVE est défini par un schéma JSON. Un identifiant et le contenu publié de son enregistrement sont deux éléments distincts. Ouvrez l’enregistrement et ses références ; vérifiez son état, les versions affectées décrites et les informations du fournisseur. Gardez l’identifiant dans le suivi des actions.

Approfondir la méthode →

Un identifiant CVE n’est ni un score de gravité, ni une preuve que votre installation est affectée.

Identités : facteurs, sessions et récupération

Une identité se protège aussi après la connexion

Un facteur résistant au phishing ne règle pas à lui seul l’ajout d’un nouveau moyen, la récupération ou les sessions déjà ouvertes. Décrivez ces chemins pour les comptes qui commandent les services critiques.

  • Séparer preuves de présence (UP) et de vérification utilisateur (UV).
  • Documenter les moyens synchronisables et leur compte de récupération.
  • Tester perte, révocation et session existante avec des résultats observables.

Ouvrir le comparatif des facteurs et de la récupération →

Sources consultées le · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3

Incident cyber : décisions et preuves de reprise

Préparer les décisions qui relient réponse et reprise

Une capacité de réponse se vérifie dans le passage entre signal, autorité, preuves et service utilisable.

  • Relier la qualification provisoire à des faits et à une prochaine réévaluation.
  • Exercer le déclenchement de la reprise et les deux validations d’intégrité, avant et après restauration.
  • Conserver les critères de clôture, le décideur et les actions résiduelles.

Explorer les repères NIST et la chronologie →

Références relues le · NIST SP 800-61r3 · pp. 27–29, 34–35 · CSF 2.0 · Appendix A

security.txt et divulgation

Vérifier qu’un signalement externe trouve une équipe

L’exposition cyber comprend aussi la capacité à recevoir un signalement utile. Un fichier security.txt peut rendre le contact visible, mais sa présence seule ne démontre pas la disponibilité du canal ni le suivi du dossier.

  • Vérifier l’emplacement /.well-known/security.txt, HTTPS, les Contact et l’unique Expires.
  • Conserver l’hôte exact, les redirections et le lien vers la politique ; ne pas étendre le périmètre aux sous-domaines par défaut.
  • Attribuer un propriétaire à la publication et un responsable au traitement des rapports ; distinguer réception, qualification et correction.

Lire la fiche security.txt et les cas de divulgation →

Sources vérifiées le · IETF · RFC 9116 · §2.5, §3, §5

CVSS, EPSS, KEV et VEX

Conserver les faits qui justifient l’ordre de traitement

Une revue d’exposition devient plus utile lorsque chaque vulnérabilité est reliée à une instance et à une décision. Les scores génériques doivent rester identifiables et datés, puis être rapprochés du service réellement exposé.

  • Séparer gravité CVSS, probabilité EPSS, présence dans KEV et déclaration d’applicabilité VEX.
  • Établir produit, version, chemins d’accès et propriétaire avant de conclure à une exposition locale.
  • Documenter décision, mesure transitoire et preuve de validation ; un correctif disponible n’est pas une correction déployée.

Consulter la lecture CVSS, EPSS, KEV et VEX →

Sources vérifiées le · FIRST · CVSS 4.0 Specification · FIRST · EPSS Frequently Asked Questions · CISA · KEV official data schema · OpenVEX · Specification v0.2.0

Chronologies : UTC et fuseaux

Rapprocher les journaux sans inventer leur ordre

Un journal reçu après un autre peut décrire une activité plus ancienne. Les changements d’heure et les reprises de collecte ajoutent d’autres ambiguïtés ; un tri de chaînes locales ne fournit pas une chronologie d’incident fiable.

  • Rapprocher les instants UTC tout en conservant les représentations reçues.
  • Tester heure répétée, heure absente et décalage incohérent.
  • Isoler les identifiants contradictoires et conserver chaque état daté de l’analyse.

Lire les 12 cas et les trois états datés →

Sources relues le · IETF · RFC 3339 · Python · PEP 495 · Python 3.12 · zoneinfo · IANA · Time Zone Database 2026e · IANA · 2026e Europe rules · OpenTelemetry · Logs Data Model

Fichiers : quarantaine et retrait

Inclure les traitements tardifs dans la recette des fichiers

Une recette doit provoquer le retrait ou le remplacement pendant qu’une analyse reste en cours. Le résultat attendu porte sur l’état final et les accès réels, au-delà du seul statut de réussite du traitement.

  • Tester la panne, le contrôle non terminé et la reprise.
  • Changer version ou politique pendant un traitement et vérifier son refus.
  • Retirer l’accès avant le retour d’un dérivé et rejouer les lectures autorisées ou interdites.

Voir les trois parcours et les retours tardifs →

Sources relues le · OWASP · File Upload Cheat Sheet · OWASP · Authorization Cheat Sheet · WHATWG · HTML input accept · PostgreSQL 18 · Transaction isolation