FICommunautés & standards
FIRST
Réseau international d’équipes de réponse aux incidents.
LE PORTAIL CYBER INTERNATIONAL / DIRECTORY
Tout un monde d’expertises.
Recherchez une autorité cyber, un CERT ou CSIRT, un organisme de recherche ou un référentiel technique. Les filtres croisent pays, type d’organisme et sujet pour orienter votre recherche. Consultez ensuite le site officiel afin de vérifier sa mission, son périmètre géographique et ses conditions d’intervention.
Répartition des profils FIRST · 883
Profils dans l’instantané : 883 ·
- Government, Private and Public sectors
252 / 883 252 - Other commercial
207 / 883 207 - Industrial sector
95 / 883 95 - Financial sector
94 / 883 94 - ICT vendor customer base
57 / 883 57 - Secteur non renseigné
50 / 883 50 - Government & military
46 / 883 46 - Research & education
45 / 883 45 - ISP customer base
37 / 883 37
Le pays d’un profil et son secteur ne suffisent pas à établir son périmètre d’intervention. Confirmez les conditions sur la fiche officielle. FIRST ↗
OWCommunautés & standards
OWASP Foundation
Projets ouverts pour la sécurité des applications et de l’IA.
MIRecherche & formation
MITRE ATT&CK
Base publique de tactiques et techniques adverses documentées.
Informations documentaires
- Donnée ou repère vérifié
- ATT&CK est une base de connaissances fondée sur des observations. Ses domaines comprennent notamment Enterprise, Mobile et ICS.
- Comment l’utiliser
- Associez une technique à une trace et à une hypothèse de détection. Distinguez la présence d’une source de journal et la détection effectivement testée.
- Limite à conserver
- Une technique partagée ne suffit pas à attribuer un acteur. Le nombre de techniques couvertes n’est pas une mesure complète de votre sécurité.
Documentation consultée le
MIRecherche & formation
MITRE ATLAS
Base de connaissances sur les menaces visant les systèmes IA.
Informations documentaires
- Donnée ou repère vérifié
- Le dépôt officiel publie les données ATLAS : tactiques, techniques et études de cas. Ces éléments complètent une analyse du système réellement déployé.
- Comment l’utiliser
- Choisissez les scénarios correspondant aux données, interfaces et outils de votre application. Testez les permissions et les conséquences, pas seulement la réponse du modèle.
- Limite à conserver
- Un catalogue de techniques n’est pas une garantie de couverture exhaustive ni un résultat de test sur votre système.
Documentation consultée le
CECommunautés & standards
Center for Internet Security
Contrôles et référentiels de sécurité.
IECommunautés & standards
IETF
Standards ouverts des protocoles Internet.
Sécurité email : identité, alignement et transport
RFC 9989, publié en mai 2026, remplace RFC 7489 et RFC 9091. Les rapports agrégés et d’échec sont séparés dans RFC 9990 et RFC 9991.
La publication d’un RFC ne prouve pas que chaque fournisseur applique déjà cette version. Vérifiez sa documentation, les résultats observés et les exceptions de votre propre flux. Les exemples ici sont pédagogiques ; ils ne proposent aucun enregistrement DNS prêt à déployer.
- SPF · RFC 7208 ·
- DKIM · RFC 6376 ·
- DKIM cryptography · RFC 8301 ·
- DMARC · RFC 9989 ·
- DMARC aggregate reports · RFC 9990 ·
- DMARC failure reports · RFC 9991 ·
- MTA-STS · RFC 8461 ·
- SMTP TLS Reporting · RFC 8460 ·
- DANE for SMTP · RFC 7672 ·
- ARC · RFC 8617 ·
Consulter le comparatif et le simulateur DMARC →
Références et statut consultés le
ETag, cache HTTP et modifications concurrentes
Un ETag est un validateur opaque de la représentation sélectionnée. Il sert à comparer des versions ; il ne constitue ni une autorisation, ni un jeton d’accès, ni nécessairement le hash d’un fichier. Pour une réponse personnalisée, il faut traiter séparément les droits, la clé de cache et la condition HTTP.
If-Match impose une comparaison forte : aucun des deux tags ne doit commencer par W/. If-None-Match utilise une comparaison faible, en comparant les valeurs opaques sans tenir compte de W/. Ces valeurs restent sensibles à la casse. Le joker * teste ici l’existence de la représentation, pas une version précise.
Explorer les comparaisons et le simulateur ETag →
Références primaires et limites
Les normes décrivent les conditions HTTP et le cache. Les dix cas, le laboratoire et le parcours à deux clients sont des illustrations originales. Les résultats affichés sont calculés par ce modèle local, pas des mesures du site ni de votre infrastructure.
- IETF · RFC 9110 — HTTP Semantics · June 2022 · STD 97
§8.8.3.2; §13.1.1–13.1.2; §13.2; §15.3.5; §15.4.5 - IETF · RFC 9111 — HTTP Caching · June 2022 · STD 98
§4.1; §4.3; §5.2.2.4–5.2.2.5; §5.2.2.7 - IETF · RFC 6585 — Additional HTTP Status Codes · April 2012 · Standards Track
§3 · 428 Precondition Required
Références relues le
Retry-After : attente, budget et décision de reprise
Un délai d’attente répond à la question « quand retenter ? », pas à la question « peut-on répéter cette opération ? ». Avant toute reprise, il faut qualifier l’effet demandé, lire le contrat du fournisseur et borner le travail total. Un statut d’erreur ou une réponse perdue ne prouve pas qu’aucune tentative antérieure n’a produit d’effet.
Les durées sont des secondes. Une date absolue doit être interprétée avec une politique d’horloge explicite ; le calcul ci-dessous suppose l’horloge exacte annoncée. Une valeur passée est ramenée à zéro dans le modèle, sans autoriser une boucle immédiate. La syntaxe des entiers ne suffit pas à définir les limites numériques d’un client.
Explorer Retry-After et le modèle de reprise →
Sources primaires et limites
- IETF · RFC 9110 — Retry-After et idempotence HTTP · June 2022 · STD 97
§5.6.7; §9.2.2; §10.2.3; §15.6.4 - IETF · RFC 6585 — 429 Too Many Requests · April 2012 · Standards Track
§4
Références relues le
security.txt et divulgation
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.
Lire la fiche security.txt et les cas de divulgation →
Sources primaires et périmètre
- IETF · RFC 9116 · security.txt · Informational · 2022-04
§2.3–2.5, §3–3.1, §4, §5.1–5.7
Sources vérifiées le
Robots.txt : exploration, indexation et preuves
Une URL découverte, une exploration permise, un contenu indexé et une source citée correspondent à des étapes différentes. Une réponse 200 et une règle Allow ne suffisent pas à établir qu’un moteur a choisi la page. Ce complément montre quelle preuve conserver à chaque étape.
Les trois fichiers et les douze requêtes ci-dessous sont fictifs. IndexBot, PreviewBot et OtherBot ne désignent aucun service réel. Les exemples utilisent des préfixes ASCII et une fin exacte $, sans traitement des encodages, jokers de chemin, redirections ou caches. Le filtre trie des résultats déjà expliqués : il ne teste pas un domaine et ne modifie pas le robots.txt du site.
Examiner les douze cas de robots.txt →
Sources primaires et périmètre
Les règles REP proviennent de la RFC 9309 ; les détails Google sont attribués à ses documents propres. Les exemples et le schéma sont pédagogiques. Le filtre n’effectue aucune exploration et les tableaux ne présentent aucun résultat client.
- IETF · RFC 9309 — Robots Exclusion Protocol · September 2022 · Standards Track
§2.2.1–2.2.3; §2.3–2.5; §3 - Google · Interprétation de robots.txt / robots.txt interpretation · Documentation consultée / accessed 2026-10-22
Group selection; path matching; HTTP errors and caching - Google Search Central · Block indexing with noindex · Documentation consultée / accessed 2026-10-22
Crawler access required to observe noindex - Google Search Central · Canonical URLs · Documentation consultée / accessed 2026-10-22
Signals, best practices and sitemap inclusion
Références relues le
ETCommunautés & standards
ETSI
Standards techniques et cryptographie post-quantique.
ARRecherche & formation
arXiv
Prépublications scientifiques ; évaluation par les pairs non garantie.
HUActeurs privés
Hugging Face
Modèles, jeux de données et outils ouverts d’IA.
MIActeurs privés
Microsoft Security
Recherche et analyses de sécurité publiées par Microsoft.
GOActeurs privés
Google Threat Intelligence
Publications de recherche et de threat intelligence.
UNActeurs privés
Unit 42 · Palo Alto Networks
Recherche sur les menaces et rapports techniques.
CIActeurs privés
Cisco Talos
Analyses des menaces et publications de recherche.
CLActeurs privés
Cloudflare
Analyses sur les réseaux, la sécurité et les infrastructures.
POActeurs privés
PortSwigger Web Security Academy
Apprentissage de la sécurité web dans des laboratoires autorisés.
BECommunautés & standards
Bellingcat
Méthodes et ressources de vérification en sources ouvertes.
FICommunautés & standards
FIRST · EPSS
Modèle de probabilité d’exploitation des vulnérabilités. À confronter à la gravité technique, à l’exposition locale et à l’impact métier.
Informations documentaires
- Donnée ou repère vérifié
- L’horizon du modèle est de 30 jours. Le score exprime une probabilité ; le percentile situe le score par rapport aux autres CVE.
- Comment l’utiliser
- 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.
- Limite à conserver
- Le modèle ne prédit pas le préjudice pour votre organisation. Une probabilité basse n’annule pas une exposition critique.
Documentation consultée le
CVSS, EPSS, KEV et VEX
Quelle est la probabilité estimée d’observer une exploitation de cette CVE dans les trente prochains jours ?
La probabilité ne décrit pas la compromission de votre instance, ses protections ou son préjudice métier.
Consulter la lecture CVSS, EPSS, KEV et VEX →
Sources primaires et périmètre
- FIRST · EPSS Frequently Asked Questions · Living FAQ · reviewed 2026-10-22
What is EPSS? · Reading the score · Percentile · Score changes
Sources vérifiées le
FICommunautés & standards
FIRST · CVSS
Spécification et calculateurs de gravité des vulnérabilités. Le score ne décrit pas à lui seul le risque propre à une organisation.
Informations documentaires
- Donnée ou repère vérifié
- 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.
- Comment l’utiliser
- 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.
- Limite à conserver
- Un score élevé n’est pas une preuve d’exploitation ; un score faible ne signifie pas que le service ne présente aucun risque.
Documentation consultée le
CVSS, EPSS, KEV et VEX
Quelle est la gravité technique selon les métriques retenues ?
Le score ne prouve pas une exploitation et ne remplace pas l’analyse des conséquences pour votre service.
Consulter la lecture CVSS, EPSS, KEV et VEX →
Sources primaires et périmètre
- FIRST · CVSS 4.0 Specification · CVSS 4.0 · document 1.2 · reviewed 2026-10-22
Overview · Assessment · Nomenclature · Supplemental Metrics
Sources vérifiées le
FICommunautés & standards
FIRST · Traffic Light Protocol
Règles de partage d’informations de sécurité selon la désignation retenue par leur source. Consultez la définition avant redistribution.
Informations documentaires
- Donnée ou repère vérifié
- TLP 2.0 utilise RED, AMBER, GREEN et CLEAR ; AMBER+STRICT limite le partage à l’organisation du destinataire. Les libellés ne se traduisent pas.
- Comment l’utiliser
- Conservez le marquage avec l’information et vérifiez les destinataires avant transfert. En cas d’ambiguïté, demandez une clarification à la source.
- Limite à conserver
- TLP n’est ni une classification formelle ni une licence de réutilisation. Il ne garantit pas l’exactitude du contenu.
Documentation consultée le
Indicateurs STIX et partage TLP
La traçabilité d’une note ne donne pas à elle seule le droit de la redistribuer. Le marquage TLP, les restrictions complémentaires et le destinataire prévu doivent accompagner la décision de caviardage ou de publication.
TLP décrit un périmètre de partage ; il ne certifie ni l’exactitude, ni une classification officielle, ni une licence d’utilisation. Les règles de chiffrement et de conservation doivent être définies séparément. Pour élargir le périmètre reçu, demander l’autorisation explicite de la source.
Consulter la fiche STIX, observations et partage TLP →
Références et périmètre de vérification
- FIRST · Traffic Light Protocol 2.0 · TLP 2.0 · 2022-08
§1, §2, §3 · TLP:AMBER+STRICT
Sources vérifiées le
CVCommunautés & standards
CVE Program
Identifiants et fiches publiques de vulnérabilités. Vérifiez le produit, les versions affectées et les liens vers les avis d’origine.
Informations documentaires
- Donnée ou repère vérifié
- 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.
- Comment l’utiliser
- 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.
- Limite à conserver
- Un identifiant CVE n’est ni un score de gravité, ni une preuve que votre installation est affectée.
Documentation consultée le
NIInstitutions
NIST · National Vulnerability Database
Base de données de vulnérabilités et enrichissements techniques. La fiche doit être recoupée avec l’avis de l’éditeur et votre configuration.
NIInstitutions
NIST · Cybersecurity Framework
Cadre de gestion du risque cyber et ressources de mise en pratique. Sert à organiser les résultats attendus ; ce n’est pas une certification.
Informations documentaires
- Donnée ou repère vérifié
- CSF 2.0 comporte six fonctions : Govern, Identify, Protect, Detect, Respond et Recover. Le cadre ne prescrit pas une unique façon d’obtenir les résultats.
- Comment l’utiliser
- Décrivez un profil actuel et un profil cible avec preuves, écarts et responsables. Rattachez chaque priorité aux services qu’elle aide à protéger.
- Limite à conserver
- Une correspondance avec le cadre n’équivaut pas à une certification ni à la preuve que chaque contrôle fonctionne.
Documentation consultée le
Incident cyber : décisions et preuves de reprise
Qualifier un signal, protéger les éléments d’enquête et restaurer un service ne répondent pas à la même question. Le CSF 2.0 distingue notamment la décision de démarrer la reprise, l’intégrité des moyens de restauration, la validation des actifs restaurés et la fin de la reprise. Ce sont des résultats à documenter, pas une certification ni une procédure unique.
Les douze repères ci-dessous sont une sélection du CSF 2.0, reformulée pour la lecture. Les colonnes de preuves, la chronologie et les injects sont des propositions pédagogiques originales. Ils ne remplacent pas le plan local ; aucun délai, niveau de gravité ou autorisation universels n’en sont déduits. La référence SP 800-61 Rev. 3 est finale depuis avril 2025 et remplace la Rev. 2.
Explorer les repères NIST et la chronologie →
Références primaires et limites
Les identifiants et le sens des résultats proviennent du CSF 2.0 ; les recommandations de réponse et de reprise sont précisées dans SP 800-61r3. Les tableaux de preuves, horaires et scénarios sont pédagogiques, sans résultat client, certification ou notification réelle.
- NIST · SP 800-61 Rev. 3 · Final · 2025-04-03
Community Profile CSF 2.0 ; remplace / supersedes Rev. 2 - NIST · SP 800-61r3 — recommandations détaillées / detailed recommendations · April 2025
Pages imprimées / printed pages 27–29, 34–35 : RS.MA, RS.AN, RC.RP, RC.CO - NIST · Cybersecurity Framework 2.0 · 2024-02-26 · NIST CSWP 29
Appendix A, printed pages 22–23 : official outcome identifiers - NIST · SP 800-184 — Guide for Cybersecurity Event Recovery · Final · 2016-12-22
Recovery planning, playbooks, testing and improvement
Références relues le
NIInstitutions
NIST · AI Risk Management Framework
Cadre volontaire et ressources pour documenter les risques de l’IA. Vérifiez la version et le statut des documents consultés.
Informations documentaires
- Donnée ou repère vérifié
- Le cœur de l’AI RMF s’articule autour de Govern, Map, Measure et Manage. Il s’agit d’un cadre volontaire de gestion du risque.
- Comment l’utiliser
- Définissez usage, personnes concernées et conséquences d’erreur. Rapprochez chaque risque d’une évaluation, d’un responsable et d’un moyen d’arrêt ou de reprise.
- Limite à conserver
- Le cadre ne certifie ni un modèle ni une application. Son utilisation ne dispense pas d’examiner les obligations applicables.
Documentation consultée le
OWCommunautés & standards
OWASP · GenAI Security Project
Référentiel ouvert des risques des applications LLM et IA générative : injection de prompt, divulgation et permissions excessives notamment.
Informations documentaires
- Donnée ou repère vérifié
- L’édition 2025 inclut notamment Prompt Injection, Sensitive Information Disclosure et Excessive Agency.
- Comment l’utiliser
- Traduisez un risque en scénario observable : document hostile, donnée réservée ou outil hors périmètre. Notez le comportement attendu et la preuve du refus.
- Limite à conserver
- Une liste de risques n’est pas une évaluation complète. Le filtrage des entrées ne démontre pas à lui seul l’autorisation de chaque action.
Documentation consultée le
RAG : droits, citations et caches
Une réponse correcte peut divulguer un document interdit. La pertinence de recherche, la validité d’une citation et l’autorisation d’accès sont trois contrôles distincts. Le service qui fournit les passages doit appliquer les droits de l’identité courante avant leur exposition au modèle.
- OWASP · LLM08:2025 Vector and Embedding Weaknesses · 2025
- OWASP · LLM01:2025 Prompt Injection · 2025
- OWASP · LLM06:2025 Excessive Agency · 2025
- OWASP · LLM05:2025 Improper Output Handling · 2025
- OWASP · LLM07:2025 System Prompt Leakage · 2025
- OWASP · LLM10:2025 Unbounded Consumption · 2025
- OWASP · API1:2023 Broken Object Level Authorization · 2023
Explorer la matrice de droits RAG et ses cas de test →
Références consultées le