SIM3 v2 interim : 45 paramètres pour monter en maturité

SIM3 est le modèle de mesure de la maturité de la gestion des incidents de sécurité. Il appartient à l’OCF (2), qui en autorise et en encourage l’usage gratuit pour un emploi interne et non lucratif. La version de référence est la v2 interim, publiée le 1er janvier 2023 et toujours en vigueur à la date de rédaction. Elle est signée de Don Stikvoort, Klaus-Peter Kossakowski et Mirosław Maj.

Le modèle a été écrit pour les CSIRT (3), dénomination identique au terme plus ancien de CERT (4). Il est aujourd’hui employé au-delà de ce périmètre, et la version 2 complète, attendue dans le courant de 2026, couvrira explicitement quatre familles d’équipes, dont les SOC (5). Les équipes de gestion des vulnérabilités, souvent appelées VOC (6), ne figurent pas sous ce nom dans la typologie annoncée, mais le modèle leur est lisible, pour la raison exposée plus bas.

• Une seule échelle de cinq niveaux, de 0 à 4, valable pour les quarante-cinq paramètres, sans variante par domaine.
• Quatre quadrants, Organisation, Humain, Outils et Processus, choisis pour que les paramètres soient aussi indépendants que possible les uns des autres.
• Quatre piliers couverts, la prévention, la détection, la résolution, le contrôle qualité et le retour.
• Huit paramètres portent une exigence minimale écrite dans le modèle, le reste étant laissé à l’appréciation de l’équipe.
• Un outil d’auto-évaluation en ligne, gratuit, qui reprend le modèle paramètre par paramètre.
• Des baselines publiques qui disent où viser selon le contexte, de onze paramètres pour l’adhésion au FIRST (7) à quarante-cinq pour les référentiels de l’ENISA (8).
• Une typologie de quatre types d’équipes, CSIRT, SOC, PSIRT (9) et ISAC (10), arrêtée avec le FIRST en 2023 et destinée à la version 2 complète.

Le modèle repose sur trois éléments, et rien d’autre. Des paramètres de maturité, au nombre de quarante-cinq, qui sont les grandeurs mesurées. Des quadrants, au nombre de quatre, qui sont les catégories auxquelles appartiennent les paramètres. Des niveaux, au nombre de cinq, qui expriment la valeur mesurée sur chaque paramètre.

Le sujet annoncé n’est pas la réponse à incident seule, mais la gestion des incidents dans son ensemble, qui compte quatre piliers : la prévention, la détection, la résolution, le contrôle qualité et le retour. Le périmètre premier est celui des incidents de cybersécurité, ceux qui touchent les ordinateurs de toute nature, les équipements réseau y compris les objets connectés, les réseaux eux-mêmes et les informations qu’ils portent. Le modèle précise que ce périmètre peut être élargi ou restreint, le plus souvent sans conséquence notable sur la mesure.

Le découpage en quadrants n’est pas cosmétique. Il a été construit pour que deux paramètres d’un même quadrant se recouvrent le moins possible, ce qui évite de mesurer deux fois la même chose et rend la lecture du profil exploitable.

La même échelle s’applique aux quarante-cinq paramètres. Cette simplicité est un choix assumé par les auteurs, qui la jugent plus utile que la précision qu’apporterait une échelle propre à chaque paramètre.

Ce que vaut le niveau 2

Le modèle recommande explicitement de se doter d’un espace documentaire interne de type wiki, pour deux raisons. La première est que les processus, les outils et les politiques deviennent accessibles à ceux qui traitent les incidents. La seconde est que les liens hypertextes permettent de relier les paramètres entre eux, la liste des sources d’information renvoyant par exemple vers les processus qui les exploitent.

Un cas fréquent mérite d’être connu. Lorsqu’un outil porte une information qui relève d’un paramètre sans que le responsable de l’équipe l’ait validée, le paramètre est au niveau 2. Le modèle donne l’exemple du système de suivi des incidents, qui embarque presque toujours une liste déroulante de catégories d’incidents : tant que cette liste n’a pas été approuvée formellement, le paramètre de classification des incidents plafonne au niveau 2.

Les trois conditions du niveau 4

Le niveau 4 est le seul qui sorte du périmètre de décision de l’équipe. Il implique le niveau 3, plus une attention active d’un niveau de gouvernance supérieur au responsable de l’équipe, dont il faut pouvoir apporter la preuve. Trois éléments sont exigés.

• Il existe un processus de contrôle, d’évaluation ou d’audit du paramètre, conduit sur l’autorité d’un niveau de gouvernance supérieur au responsable de l’équipe.
• Ce processus est suivi régulièrement. Le modèle ne fixe pas encore de règle, et retient comme bonne pratique au moins une fois tous les deux ans, et en général une fois par an.
• Ce processus est actif, c’est à dire qu’un mécanisme de retour vers le responsable de l’équipe et vers l’équipe accompagne le contrôle et le rapport qui en découle.

Deux cas donnent une preuve nette. Le premier est celui d’un paramètre dont le sujet figure sans ambiguïté dans la législation cyber d’un pays : le paramètre obtient alors le niveau 4, étant entendu que l’équipe doit tout de même le mettre en œuvre en interne pour que la loi produise ses effets. Le second est celui d’une charte d’équipe qui comporte un paragraphe sur les évaluations et les audits dont l’équipe fait l’objet. Une auto-évaluation interne, seule, ne suffit jamais à établir le niveau 4.

La liste complète est la meilleure porte d’entrée dans le modèle, parce qu’elle montre immédiatement ce qui est déjà en place dans une équipe qui fonctionne. La plupart des paramètres décrivent des pratiques ordinaires, dont la seule question posée est de savoir si elles sont écrites et approuvées.

Quadrant O, Organisation, onze paramètres

Deux paramètres de ce quadrant méritent une lecture attentive. L’écart entre O-3 et O-4 est naturel, une équipe étant presque toujours plus responsable qu’elle n’est autorisée. Le modèle prévient que cet écart ne doit pas devenir trop grand, faute de quoi l’équipe est attendue sur des sujets qu’elle n’a pas le pouvoir de traiter. Quant à O-6, il est l’ajout de la v2 interim : la v1 comptait donc quarante-quatre paramètres, et ce paramètre est écarté de la notation lorsque l’évaluation porte sur la v1.

Quadrant H, Humain, sept paramètres

Le modèle est explicite sur un point souvent négligé : un code d’éthique générique porté par l’organisation hôte ne suffit pas à satisfaire H-1, parce qu’il ne traite pas de ce que fait l’équipe. Deux textes sont proposés comme base, le code de pratique du Trusted Introducer et EthicsFIRST.

Quadrant T, Outils, dix paramètres

Pour les trois derniers paramètres, le modèle ne demande pas que l’équipe exploite elle-même les outils. Elle peut en être l’architecte, l’utilisatrice, ou seulement la destinataire des résultats, à condition que son rôle soit défini pour chacun d’eux. La même souplesse vaut pour T-1 : l’équipe n’a pas à gérer la CMDB (11), elle doit y avoir accès.

Quadrant P, Processus, dix-sept paramètres

Le quadrant P est le plus fourni, et c’est aussi celui qui se prête le mieux à une progression rapide. Deux paramètres peuvent être portés par un seul document : P-5 et P-6 sont souvent réunis dans un processus unique de gestion des incidents, ce que le modèle accepte à condition que la détection et la résolution y soient traitées l’une comme l’autre, et que le même niveau soit retenu pour les deux. P-7 peut de la même façon être intégré à P-6 sous la forme de variantes de traitement.

Les huit exigences minimales inscrites dans le modèle

Sur les quarante-cinq paramètres, huit portent une exigence minimale explicite. Ce sont les seuls endroits où le modèle impose un contenu plutôt qu’un niveau de formalisation, et ils constituent une liste de départ utile.

• O-5 : coordonnées, plages de service, description concise des services, politique de traitement et de divulgation de l’information, le tout disponible publiquement en anglais.
• O-7 : la vitesse de réaction aux signalements entrants, avec une réaction humaine sous deux jours ouvrés pour les équipes pairs.
• O-10 : la charte décrit la mission et les paramètres O-1 à O-9, par référence à d’autres documents ou en les réunissant.
• H-2 : trois membres au minimum, à temps plein ou à temps partiel.
• T-5 : un mécanisme de repli en cas de panne des moyens de voix.
• P-10 : les adresses cert@ et security@ sont suivies par l’équipe, une présence web existe au moins en interne, une politique sur les réseaux sociaux est écrite.
• P-11 : le processus prend en charge le TLP (12).
• P-17 : le processus définit qui sont les pairs et garantit avec eux une communication de confiance à double sens.

Deux références externes sont citées par le modèle pour aller plus loin sans réinventer. La RFC (13) 2350 est la façon normalisée de publier la description de service attendue par O-5, avec une version anglaise publique. La RFC 2142 liste les boîtes aux lettres normalisées à suivre au titre de P-10, celles du postmaster et du webmaster méritant une attention particulière.

La question revient à chaque présentation du modèle : SIM3 parle de CSIRT, est-il utilisable par une équipe qui n’en porte pas le nom. La réponse tient dans le texte lui-même et dans l’usage qui en est fait aujourd’hui.

Le texte d’abord. Le mot CSIRT y désigne toute capacité de gestion des incidents de sécurité à laquelle le modèle est appliqué, que cette capacité soit une équipe constituée, un service ou une fonction. Rien dans les quarante-cinq paramètres ne suppose une organisation particulière : un mandat, un périmètre servi, des sources, un outillage et des processus existent dans un SOC comme dans un VOC.

L’usage ensuite. Trois faits publics montrent que la question est déjà tranchée en pratique.

• La baseline développée en 2023 par le FIRST et l’OCF pour l’adhésion au FIRST porte sur onze des quarante-cinq paramètres, et s’applique à tout type d’équipe candidate, CSIRT, SOC, ISAC ou PSIRT.
• La baseline de certification du Trusted Introducer, qui date de 2010, est utilisée avec succès pour tous les types d’équipes accréditées, et pas seulement pour les CSIRT.
• La typologie de quatre types d’équipes, CSIRT, SOC, PSIRT et ISAC, a été arrêtée avec le FIRST en 2023 et structure la version 2 complète du modèle.

Le VOC n’est pas nommé dans cette typologie de quatre. Cela ne le met pas hors du modèle : son activité se retrouve dans des paramètres qui existent déjà, en particulier T-8 et P-4, ce dernier citant explicitement la publication d’avis de vulnérabilité et de correctifs parmi les processus de prévention.

Où chaque type d’équipe se reconnaît en premier

Le modèle n’impose aucun ordre de lecture. Le tableau ci-dessous propose un point d’entrée par type d’équipe, à partir des paramètres où son activité quotidienne se retrouve directement. Cette correspondance est une lecture, elle ne figure pas dans le standard.

Le bénéfice d’un modèle commun apparaît ici. Quand un SOC, un VOC et un CERT sont évalués avec la même échelle et les mêmes paramètres, leurs profils deviennent comparables, et les recouvrements comme les trous entre eux se voient. C’est particulièrement vrai des paramètres d’escalade, P-1 à P-3, qui ne se partagent pas et se découvrent souvent en crise.

Une baseline est un ensemble de valeurs minimales définies pour tout ou partie des paramètres, dans un contexte donné. Elle peut porter en plus des exigences propres, indépendantes de SIM3. Elle répond à la question que pose toute équipe après sa première auto-évaluation : quel niveau viser sur quel paramètre.

Toutes ces baselines sont représentées dans l’outil d’auto-évaluation en ligne. Depuis le début de l’année 2026, un sélecteur permet de n’afficher que celles qui intéressent l’équipe, les autres restant masquées.

L’OCF assume de garder ce nombre bas, un catalogue trop fourni finissant par brouiller la lecture. Il recommande les trois baselines ENISA Basic, Intermediate et Advanced pour un usage général, y compris hors de l’Union européenne, une équipe nationale d’un pays n’étant pas fondamentalement différente d’une équipe nationale d’un autre. Plusieurs équipes commerciales s’en sont d’ailleurs saisies.

Le chemin décrit ci-dessous suit l’ordre des niveaux et ne suppose aucun préalable, ni budget, ni outil particulier.

• Faire l’auto-évaluation. L’outil en ligne de l’OCF reprend le modèle paramètre par paramètre, avec la formulation du standard et les explications complémentaires. Une équipe qui le parcourt à plusieurs obtient en une séance de travail son premier profil.
• Choisir une cible. Une baseline, choisie selon le contexte, transforme le profil en liste d’écarts. Les trois baselines ENISA conviennent à la plupart des situations, celle du FIRST si l’adhésion est visée.
• Traiter d’abord les huit exigences minimales. Elles sont peu nombreuses, elles sont explicites, et leur absence se voit immédiatement dans tout audit.
• Passer les niveaux 1 en niveaux 2. Écrire ce que l’équipe sait déjà faire, dans un espace documentaire interne qui autorise les liens entre paramètres. C’est le gain le plus rapide du modèle.
• Passer les niveaux 2 en niveaux 3. Faire approuver par le responsable de l’équipe ce qui fait consensus. Le modèle recommande fortement d’y ajouter un mécanisme d’expiration et de maintenance des pages, que plusieurs moteurs de wiki savent gérer.
• Ouvrir le chemin du niveau 4. Construire P-8, le processus d’audit et de retour, et inscrire dans la charte O-10 un paragraphe sur les évaluations et les audits. Le modèle conseille de reconnaître l’indépendance de l’auditeur tout en demandant un socle minimal de sujets sur lesquels l’équipe souhaite être auditée, la plupart des paramètres du quadrant O, plus H-2, P-1 et P-2.
• Utiliser les standards compagnons. Le CSIRT Services Framework du FIRST pour cartographier les services au titre de O-5, le document CSIRT Roles and Competences pour les compétences au titre de H-3, la RFC 2350 pour la publication, le code de pratique du Trusted Introducer ou EthicsFIRST pour H-1, une taxonomie d’incidents établie pour O-8.

Assessment ou audit

Les deux démarches existent et ne répondent pas à la même question. L’assessment a l’amélioration pour objet. Il peut être interne, accompagné par un consultant ou lié à une adhésion, et la preuve peut y être demandée sans être obligatoire. L’audit est une autre exigence : il ne mérite ce nom, au sens de l’OCF, que si tous les paramètres sont testés et si chaque niveau attribué repose sur une preuve. Seul un auditeur SIM3 certifié peut le conduire, avec un rapport et un certificat valables au maximum trois ans, et il doit déclarer l’audit à l’OCF, nom de l’équipe et date, sans le contenu.

La v2 interim porte son nom pour une raison. Elle est une étape, et la version 2 complète est annoncée dans le courant de 2026. Elle optimisera le modèle non seulement pour les CSIRT, quelle que soit leur dénomination, mais aussi pour les ISAC, les SOC et les PSIRT.

Le travail engagé aujourd’hui n’est pas perdu pour autant. Pour les CSIRT, la v1 et la v2 interim sont compatibles, à la seule exception du paramètre O-6 absent de la v1. Les autres différences ne sont pas de fond : des noms de paramètres mis à jour, et de nombreuses améliorations de texte. Une équipe qui documente ses paramètres aujourd’hui construit un patrimoine qui survivra au changement de version.

L’adoption est par ailleurs large et continue de s’étendre. Au-delà de l’OCF, le FIRST, l’ENISA et le réseau des CSIRT de l’Union européenne, l’association japonaise des CSIRT et la communauté mondiale du Global Forum on Cyber Expertise ont adopté la v2 interim ou sont en chemin pour le faire.

L’essentiel de cet article provient du standard lui-même et des pages publiées par l’organisation qui le détient. Le niveau de preuve est élevé, avec deux réserves de portée limitée.

1. SIM3 (1) : Security Incident Management Maturity Model, modèle de mesure de la maturité de la gestion des incidents de sécurité.
2. OCF (2) : Open CSIRT Foundation, fondation qui détient et publie SIM3.
3. CSIRT (3) : Computer Security Incident Response Team, équipe de réponse aux incidents de sécurité informatique.
4. CERT (4) : Computer Emergency Response Team, dénomination plus ancienne, identique à CSIRT selon le modèle.
5. SOC (5) : Security Operations Center, équipe de supervision et de détection.
6. VOC (6) : Vulnerability Operations Center, équipe dédiée à la gestion des vulnérabilités.
7. FIRST (7) : Forum of Incident Response and Security Teams, organisation mondiale des équipes de réponse aux incidents.
8. ENISA (8) : Agence de l’Union européenne pour la cybersécurité.
9. PSIRT (9) : Product Security Incident Response Team, équipe de réponse aux incidents de sécurité d’un produit, chez son éditeur ou son constructeur.
10. ISAC (10) : Information Sharing and Analysis Center, structure de partage d’information sectorielle.
11. CMDB (11) : Configuration Management Database, base de gestion des configurations du parc informatique.
12. TLP (12) : Traffic Light Protocol, protocole de marquage qui encadre la rediffusion d’une information partagée.
13. RFC (13) : Request for Comments, série de documents de référence publiés par la communauté Internet.
14. NIS2 (14) : directive de l’Union européenne sur la sécurité des réseaux et des systèmes d’information, deuxième version.

1. Open CSIRT Foundation, SIM3 v2 interim, Security Incident Management Maturity Model, Full Standard, 1er janvier 2023. opencsirt.org
2. Open CSIRT Foundation, SIM3 Model & References, consultée le 15 septembre 2026. opencsirt.org
3. Open CSIRT Foundation, SIM3 Baselines, consultée le 15 septembre 2026. opencsirt.org
4. Open CSIRT Foundation, SIM3 Online Tool, consultée le 15 septembre 2026. opencsirt.org
5. Open CSIRT Foundation, outil d’auto-évaluation SIM3, consulté le 15 septembre 2026. sim3-check.opencsirt.org
6. Open CSIRT Foundation, Audits, consultée le 15 septembre 2026. opencsirt.org
7. Open CSIRT Foundation, Assessments, consultée le 15 septembre 2026. opencsirt.org
8. Open CSIRT Foundation, Certified SIM3 Auditors, consultée le 15 septembre 2026. opencsirt.org
9. Open CSIRT Foundation, SIM3 v1, ancien standard, consulté le 15 septembre 2026. opencsirt.org
10. FIRST, CSIRT Services Framework v2.1, consulté le 15 septembre 2026. first.org
11. FIRST, CSIRT Roles and Competences, consulté le 15 septembre 2026. first.org
12. FIRST, Traffic Light Protocol, consulté le 15 septembre 2026. first.org
13. FIRST, EthicsFIRST, consulté le 15 septembre 2026. ethicsfirst.org
14. Trusted Introducer, CSIRT Code of Practice, consulté le 15 septembre 2026. trusted-introducer.org