Activité 2.1 – Réalisation des fiches de besoins

Liens pour Naviguer dans ce module

Accueil  Module 2 Activité 2.1  Activité 2.2  Module 3  Exercices

Cette activité a pour but de créer les tableaux nécessaires à l'expression des besoins de sécurité par les utilisateurs. Ils permettront aux utilisateurs d'exprimer les besoins de sécurité des éléments qu'ils manipulent habituellement dans le cadre de leur activité, d'une manière objective et cohérente. Il s'agit d'une activité contribuant à l'estimation des risques et à la définition des critères de risques dans le processus de gestion des risques.

Cette page présente l'activité 2.1, première activité de l'étape 2 (Expression des besoins de sécurité). Les étudiants devraient d'abord se familiariser avec les concepts présentés sur cette page. Les étudiants débutant devraient ensuite compléter l'exercice proposé.

Préalables

Données en entrée

  • Liste des enjeux du système cible.
  • Liste des éléments essentiels.

Actions

  • Choisir les critères de sécurité à prendre en compte
  • Déterminer l'échelle de besoins.
  • Déterminer les impacts pertinents.

Données en sortie

  • Liste de critères de sécurité.
  • Échelle de besoins.
  • Liste d'impacts.

Conseils pratiques

  • L'échelle de besoins est l'un des instruments de discussion les plus importants de l'étude. Elle doit être déterminée par le groupe de travail et servira non seulement aux discussions au sujet des besoins de sécurité mais aussi aux discussions concernant les objectifs de sécurité.
  • L'échelle de besoins doit être objective et cohérente. Elle comprendra des pondérations et des valeurs de référence et s'appuiera sur la liste des critères de sécurité à considérer et une liste d'impacts avec des exemples représentatifs.
  • Pour les impacts, une représentation sous la forme d'un arbre de causes permet de mieux présenter l'idée au groupe de travail.
  • Afin de déterminer leurs besoins de sécurité, une fiche sera réalisée pour chaque élément essentiel et par personne interrogée. La création d'une fiche par fonction ou sous-fonction est justifiée dans la mesure où les besoins de sécurité d'une fonction ne sont pas directement déduits des informations qu'elle traite.
Une fonction peut être confidentielle, non pas du fait qu'elle manipule des informations confidentielles mais uniquement par la nature du traitement qu'elle effectue.

L'accès à un service peut ne pas demander une forte disponibilité, par contre, le fonctionnement de ce service peut nécessiter la disponibilité maximale des informations qu'il utilise.

L'activité 2.1

Concepts principaux

Critères de sécurité

Les besoins de sécurité associés à des fonctions et informations s'expriment selon des critères de sécurité. Trois critères de sécurité sont incontournables selon EBIOS:

Disponibilité (D) : propriété d'accessibilité au moment voulu des éléments essentiels par les utilisateurs autorisés.

  • Pour une fonction : garantie de la continuité des services de traitement ; absence de problèmes liés à des temps de réponse au sens large.
  • Pour une information : garantie de la disponibilité prévue pour l'accès aux données (délais et horaires) ; il n'y a pas de perte totale de l'information ; tant qu'il existe une version archivée de l'information, l'information est considérée comme disponible ; pour étudier la disponibilité d'une information, on suppose l'existence d'une version archivée, et on évalue la disponibilité qui correspond à la fonction d'archivage de cette information.

Intégrité (I) : propriété d'exactitude et de complétude des éléments essentiels.

  • Pour une fonction : assurance de conformité de l'algorithme ou de la mise en oeuvre des traitements automatisés ou non par rapport aux spécifications ; absence de résultats incorrects ou incomplets de la fonction.
  • Pour une information : garantie d'exactitude et d'exhaustivité des données vis-à-vis d'erreurs de manipulation ou d'usages non autorisés ; non-altération de l'information.

Confidentialité (C) : propriété des éléments essentiels de n'être accessibles qu'aux utilisateurs autorisés.

  • Pour une fonction : protection des algorithmes décrivant les règles de gestion et les résultats dont la divulgation à un tiers non autorisé porterait préjudice ; absence de divulgation d'un traitement ou mécanisme à caractère confidentiel.
  • Pour une information : protection des données dont l'accès ou l'usage par des tiers non autorisés porterait préjudice ; absence de divulgation de données à caractère confidentiel.

Les besoins peuvent être également exprimés en termes de Preuve (imputabilité), de Contrôle (audibilité), d'Anonymat ou tout autre critère de sécurité dont l'atteinte pour une fonction ou une information peut mettre en péril les enjeux du système :

  • preuve, contrôle : garantie de ne pas pouvoir réfuter l'émission ou la réception d'une information, avec possibilité de pouvoir auditer les résultats fournis (exemple : un virement de fonds et la vérification du journal comptable à partir des informations d'entrée).

  • anonymat : disposition par laquelle toute personne créant une information (un vote par exemple) et / ou effectuant une action (un appel téléphonique par exemple) qui fait l'objet d'un traitement informatique, ne puisse pas être identifiée.

  • fiabilité : propriété de cohérence entre un comportement attendu et un résultat

 

Échelle de besoins

Les besoins de sécurité devront s'exprimer pour chaque critère de sécurité sélectionné. Une graduation des besoins de sécurité doit être élaborée sous la forme de niveaux de besoins. Pour cela, une définition doit être formulée pour chaque niveau de besoins de chaque critère de sécurité.

L'échelle présente généralement des niveaux entre 0 (aucune atteinte) et 4 (atteinte très importante). Il est néanmoins envisageable de définir une échelle comprenant un nombre de niveaux différent.

Il est préférable que le nombre de niveaux soit le même pour chaque critère de sécurité.

Dans la mesure du possible, les valeurs de références doivent être explicites et comprendre un ensemble de valeurs bornées. Ce travail est généralement réalisé dans un tableau à double entrée, avec les critères de sécurité en colonnes et les niveaux en lignes, les définitions devant être indiquées à chaque intersection. Le tableau ci-dessous présente un exemple d'échelle pour les critères de sécurité disponibilité, d'intégrité et confidentialité, et une échelle à 5 niveaux.

Besoins de sécurité

Disponibilité

Intégrité

Confidentialité

0

Aucun besoin de disponibilité

Aucun besoin d'intégrité

Public

1

Long terme

(à préciser)

[valeur non utilisée]

Restreint

2

Moyen terme

(à préciser)

Besoin moyen d'intégrité

Confidentiel (partenaires)

3

Court terme

(à préciser)

[valeur non utilisée]

Confidentiel (interne)

4

Très court terme

(à préciser)

Parfaitement intègre

Secret

Cette échelle doit être adaptée au contexte de l'étude avec la participation des personnes qui vont déterminer les besoins. Ainsi, chaque valeur aura une réelle signification pour eux et les valeurs seront cohérentes.

 

Impacts

Les conséquences de la réalisation d'un sinistre peuvent être appréciées selon différents points de vue. Les impacts significatifs pour l'organisme doivent être identifiés par le responsable utilisateur. Ils permettront d'envisager différents domaines pouvant être impactés et d'apporter des éléments de justification des besoins de sécurité. Les impacts peuvent être choisis parmi ceux proposés bien qu'il soit souvent nécessaire de l'adapter

Une fois les critères de sécurité et les impacts déterminés, il est possible de réaliser les fiches d'expression des besoins de sécurité pour chaque élément essentiel.

 

Les étudiants débutant devraient ensuite
compléter l'exercice 4

Liens pour Naviguer dans ce module

Accueil  Module 2 Activité 2.1  Activité 2.2  Module 3  Exercices

mise à jour: 27/05/2008 09:00:39 AM -0400