DICP : les quatre critères de sécurité de l'information

DICP est l'acronyme des quatre critères de sécurité de l'information : Disponibilité, Intégrité, Confidentialité et Preuve. Évaluer les besoins DICP d'une information ou d'un processus, c'est noter sur une échelle le niveau d'exigence de chacun de ces critères. Ce profil sert ensuite de base à l'analyse de risques et au choix des mesures de sécurité.

Les critères DICP répondent à une question simple : qu'est-ce qui serait grave pour cette information ? Qu'elle soit inaccessible, qu'elle soit fausse, qu'elle tombe entre de mauvaises mains, ou qu'on ne puisse pas prouver qui l'a modifiée. Les trois premiers critères sont définis par la norme de vocabulaire ISO/IEC 27000 ; le quatrième est un usage français répandu.

D comme Disponibilité

La disponibilité est la propriété d'une information ou d'un service d'être accessible et utilisable au moment où une personne autorisée en a besoin. On l'exprime souvent par une durée d'interruption maximale tolérable : quelques jours pour un intranet, moins d'une heure pour un système de régulation des urgences. Ce critère rejoint directement la continuité d'activité.

I comme Intégrité

L'intégrité garantit que l'information est exacte et complète, et qu'elle n'a pas été modifiée sans autorisation, par malveillance ou par erreur. Un virement dont le RIB a été changé, une posologie altérée dans un dossier médical ou un prix modifié sur un site marchand sont des atteintes à l'intégrité.

C comme Confidentialité

La confidentialité assure que l'information n'est accessible qu'aux personnes, entités ou processus autorisés. Elle se décline en niveaux de diffusion : public, interne, restreint, très restreint. C'est le critère le plus intuitif, mais rarement le seul en jeu.

P comme Preuve (ou traçabilité)

La preuve désigne la capacité à retrouver qui a fait quoi, quand, et à le démontrer, y compris face à un tiers. Elle regroupe la traçabilité (les journaux), l'imputabilité (rattacher une action à une personne) et la non-répudiation (empêcher quelqu'un de nier une action). On parle aussi de DICT, le T désignant la traçabilité ; le terme « preuve » est plus large, car une trace qui n'est ni protégée ni horodatée ne prouve pas grand-chose.

Ces sigles désignent la même famille de critères, avec une couverture plus ou moins large. La triade CIA (Confidentiality, Integrity, Availability) est la référence internationale, reprise par l'ISO et par le NIST américain dans sa norme FIPS 199. Le RGPD s'y réfère aussi : son article 32 demande de garantir « la confidentialité, l'intégrité, la disponibilité et la résilience constantes » des systèmes de traitement.

Un besoin DICP n'a de sens que s'il est noté sur une échelle commune, définie avant l'évaluation et identique pour toute l'organisation. Le guide EBIOS Risk Manager de l'ANSSI rappelle que l'objectif n'est pas de trouver une valeur absolue mais de positionner les informations les unes par rapport aux autres. La plupart des organisations retiennent quatre niveaux, qui évitent la tentation du « moyen » au milieu. Voici un exemple d'échelle, à adapter à votre contexte.

Prenons les données de paie d'une entreprise de 300 salariés. Le responsable des ressources humaines, propriétaire de l'information, répond avec le RSSI à quatre questions, en raisonnant sur les conséquences d'une atteinte et non sur les protections déjà en place.

• Disponibilité : 2. Une indisponibilité de deux jours se rattrape, sauf la veille de la paie, signalée comme période critique.
• Intégrité : 4. Une coordonnée bancaire modifiée détourne un salaire ; une erreur de montant a des conséquences sociales et juridiques.
• Confidentialité : 3. Salaires et numéros de sécurité sociale sont des données personnelles réservées au service RH et au prestataire de paie.
• Preuve : 3. Chaque modification de RIB ou de salaire doit pouvoir être rattachée à une personne, en cas de fraude ou de contrôle.

Le profil obtenu, D2 · I4 · C3 · P3, montre immédiatement où porter l'effort : sur les contrôles d'intégrité et la traçabilité des changements de coordonnées bancaires, bien plus que sur la haute disponibilité. Essayez l'évaluateur ci-dessous avec trois actifs d'exemple, puis ajustez les niveaux pour voir les mesures typiques changer.

Le DICP ne mesure pas un risque : il exprime un besoin. Le risque apparaît quand on croise ce besoin avec une menace et une vraisemblance. C'est pourquoi l'évaluation DICP intervient au début de toute analyse de risques.

• Dans EBIOS Risk Manager, l'atelier 1 identifie les valeurs métier (les informations et processus essentiels) et les classe selon leurs besoins de sécurité, comme la disponibilité, l'intégrité ou la confidentialité. Ces besoins orientent la gravité des événements redoutés. Notre page logiciel EBIOS RM présente la méthode outillée.
• Avec ISO 27005, les besoins DICP alimentent les critères de conséquence utilisés lors de l'analyse et de l'évaluation des risques.
• Pour une homologation de sécurité, le profil DICP du système justifie le niveau des mesures retenues devant l'autorité d'homologation (voir notre page logiciel d'homologation de sécurité).

Un point de méthode décisif : on évalue le DICP des valeurs métier (la paie, le dossier patient), puis les biens supports qui les portent (serveur, application, prestataire) en héritent. Le résultat se visualise ensuite dans une matrice des risques.

• Tout coter au maximum. Si tout est critique, rien ne l'est : le budget de sécurité ne peut plus être priorisé.
• Évaluer le serveur plutôt que l'information. Le besoin vient de l'usage métier, pas de la technique.
• Évaluer sans les métiers. Le RSSI anime, mais c'est le propriétaire de l'information qui connaît les conséquences réelles et qui valide.
• Confondre besoin et protection existante. « C'est déjà chiffré, donc C1 » est un contresens : le besoin reste C3 même si la mesure est en place.
• Ne jamais réviser. Une nouvelle réglementation, comme l'obligation d'hébergement de données de santé, ou un nouvel usage peut faire évoluer un besoin.

Dans Phinasoft, les valeurs métier et leurs besoins de sécurité sont saisis dans l'analyse de risques elle-même, avec vos propres échelles, et reliés aux scénarios et au plan d'action. Le logiciel d'analyse de risques invite les contributeurs métier dans l'analyse et les guide étape par étape. Pour le voir sur vos propres actifs, vous pouvez demander une démonstration.