Comment choisir entre une alerte, un score et une preuve de compromission ? Une alerte ouvre une vérification ; un score aide à classer ; une preuve relie une observation à un actif, une période et une activité. Documentez ces éléments séparément pour éviter de traiter une vulnérabilité théorique comme un incident confirmé. La priorité dépend aussi des données accessibles et du service interrompu.
Pour une revue de direction, présentez les accès exposés, les mesures temporaires et les contrôles de fermeture. Le nombre de correctifs appliqués ne suffit pas : indiquez quels services ont été vérifiés, quelles exceptions restent ouvertes et qui décide du risque résiduel. Les références NIST et FIRST ci-contre servent à préciser les méthodes et le vocabulaire.
Dans ce dossier
Vulnérabilités · Ransomwares · Identités · Réponse à incident · Sécurité cloud
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.
Lire le guideLe fil de veille
Toute la veille internationale →Titres en cache · actualisation des sources indisponible · Dernière récupération réussie : 22 oct. 2026, 23:31
Failles critiques dans PHP : l'alerte de Sophos aux entreprises - Presse Agence
via Google Actualités · agrégateurCybersécurité : à quoi bon automatiser la défense sans réduire les risques ? - Solutions-Numeriques
via Google Actualités · agrégateurCybersécurité : le SITIV et Secuserve protègent 35 000 comptes - Presse Agence
via Google Actualités · agrégateurFailles PHP sur Internet : « C’est le pire en matière de cybersécurité» - La Croix
via Google Actualités · agrégateurRéférences : données, usages et limites
Documentation consultée le .
| Source et objet | Donnée ou repère vérifié | Comment l’utiliser | Limite à 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. | 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. | 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. | 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. | 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