Activité 1.2 – Étude du système cible 

Liens pour Naviguer dans ce module

Accueil  Module 1  Activité 1.1  Activité 1.2  Activité 1.3  Module 2 Exercices

Le système d'information (SI) contribue, en partie, à la réalisation des objectifs stratégiques de l'organisation. Une compréhension suffisamment claire du SI et de son fonctionnement est nécessaire pour extraire tous les éléments utiles à l'élaboration des besoins de sécurité du système cible. Pour cela, il convient de replacer le système cible dans le SI de l'organisation.

Cette activité a pour but de préciser le contexte d'utilisation du système à concevoir ou existant. Pour cela, il est nécessaire de préciser le sous-ensemble du système d'information de l'organisation constituant le système cible de l’étude et ses enjeux. Le système cible est alors décrit et sont recensées les hypothèses, les règles de sécurité et ses contraintes.

Préalables

• Activité 1.1.

Données en entrée

• Données concernant le système cible.
• Présentation de l'organisation.
• Liste des contraintes générales pesant sur l'organisation.
• Liste des références réglementaires générales applicables à l'organisation.
• Architecture conceptuelle du système d'information.

Actions

• Présenter le système cible.
• Lister les enjeux.
• Lister les éléments essentiels.
• Faire une description fonctionnelle du système cible.
• Lister les hypothèses.
• Lister les règles de sécurité.
• Lister les contraintes pesant sur le système cible.
• Lister les références réglementaires spécifiques au système cible.

Données en sortie

• Présentation du système cible.
• Liste des éléments essentiels.
• Description fonctionnelle du système cible.
• Liste des enjeux du système cible.
• Liste des hypothèses.
• Liste des règles de sécurité.
• Liste des contraintes spécifiques au système cible.
• Liste des références réglementaires spécifiques au système cible.

Conseils pratiques

• Le nombre et la granularité des éléments essentiels dépendra du but de l'étude et de la nature du système cible. En effet, l'étude d'un système d'information global visant à obtenir une vision générale des risques ne requerra pas la même finesse que l'étude d'un système précis devant être homologué formellement.
• L'absence de spécifications du système peut remettre en cause la poursuite de l'étude de sécurité. En effet, il est peu utile de chercher à sécuriser un système mal connu. En revanche, il est envisageable de poursuivre une étude rapide, globale, qui devra ensuite être affinée à mesure que les spécifications s'enrichissent.
• Le découpage en sous-systèmes peut être envisagé dans le cas de systèmes complexes. Dans ce cas, il conviendra de mener plusieurs études en parallèle.

L'activité 1.2

Concepts principaux

L'activité 1.2 (Étude du système cible) est composé de sous-activités représentés par les parallélogrammes verts sur la figure ci-dessous. Il y a huit sous-activités à cette activité:

• Présentation;

• Éléments essentiels

• Description fonctionnelle

• Enjeux

• Hypothèses

• Règles de sécurité

• Contraintes

• Référentiel règlementaire

L'activité 1.2 correspond au dossier Étude du système cible dans le dossier ÉTUDE DU CONTEXTE dans le logiciel EBIOS, tel qu'illustré dans la figure ci-dessous. Chacune des sous-activités correspond à l'un des éléments composants du dossier.

Présentation du système cible

Le système cible doit faire l'objet d'une description synthétique qui met clairement en évidence son périmètre, ses relations avec les autres domaines ou acteurs externes et ses finalités au sein du système d'information global.

Enjeux

À ce stade de la réflexion, les objectifs stratégiques sont censés être connus (cf. schéma directeur informatique, étude d'opportunité), les besoins fonctionnels ciblés et définis, les contraintes informationnelles et organisationnelles du système cible répertoriées. Il convient dès lors d'analyser les enjeux et le contexte dans lequel se situe le système cible.

Cette analyse permet d'identifier le poids stratégique relatif du système cible pour l'organisation et d'évaluer le niveau d'importance des fonctions dans le système cible. Elle consiste à mettre en évidence l'impact de la réalisation ou de l'exploitation du système, les attentes des utilisateurs ou de leur hiérarchie, l'apport attendu… Les enjeux peuvent être, par exemple, d'ordre technique, financier ou politique.

Éléments essentiels

Pour décrire plus précisément le système cible, l'opération suivante consiste à identifier les éléments essentiels. Cette sélection est effectuée par un groupe de travail hétérogène et représentatif du SI (responsables, informaticiens et utilisateurs).

Les éléments essentiels sont généralement les fonctions et informations au cœur de l'activité du système cible. Il est aussi possible de considérer d'autres éléments essentiels tels que les processus de l'organisation. Cette seconde approche sera plus appropriée dans le cadre d’élaboration d’une politique de sécurité des systèmes d'information, d’un schéma directeur de sécurité des systèmes d'information ou d’un plan de continuité. Les éléments essentiels constituent le patrimoine informationnel ou les "biens immatériels" que l'on souhaite protéger. Selon leur finalité, certaines études ne mériteront pas une analyse exhaustive de l’ensemble des éléments composant le système cible. Dans ce contexte, le périmètre de l’étude pourra être limité aux éléments vitaux du système cible.

La sélection des éléments essentiels s'effectue auprès d'un responsable utilisateur du système (existant ou futur). Il indique, après une première analyse, ceux qui présentent un caractère de sensibilité. Les éléments essentiels sont généralement des fonctions ou informations pour lesquelles le non respect de la disponibilité, de l'intégrité, de la confidentialité, voire d'autres critères de sécurité, mettrait en cause la responsabilité du propriétaire ou du dépositaire, ou causerait un préjudice à eux-mêmes ou à des tiers.

Les fonctions (ou sous fonctions) essentielles sont principalement :

• les fonctions dont la perte ou la dégradation rendent la réalisation de la mission du système impossible ;

• les fonctions qui contiennent des traitements secrets ou des procédés technologiques de haut niveau ;

• des fonctions dont la modification peuvent affecter fortement la réalisation de la mission du système.

Le caractère de sensibilité des informations à retenir peut provenir des cas suivants :

• les informations relevant du secret défense définies dans l'[IGI 900] et pour lesquelles le niveau d'exigence de sécurité n'est pas négociable ;

• les informations sensibles non classifiées de défense telles que définies dans une norme ou une politique et pour lesquelles le niveau d'exigence sont négociables en fonction des considérations environnementales propres à l'organisation.

Plus généralement les informations essentielles comprennent principalement :

• les informations classifiées qu'elles relèvent ou non du secret d'état;

• les informations vitales pour l'exercice de la mission de l'organisation ;

• les informations personnelles, notamment les informations nominatives au sens de la loi sur l'accès au Québec ou la loi française informatique et libertés ou d'un règlement similaire applicable;

• les informations stratégiques nécessaires pour atteindre les objectifs correspondants aux orientations stratégiques ;

• les informations coûteuses, dont la collecte, le stockage, le traitement ou la transmission nécessitent un délai important et/ou un coût d'acquisition élevé.

Les fonctions et informations qui n'auront pas été retenues à l'issue de cette activité ne feront l'objet dans la suite de l'étude d'aucun besoin de sécurité. Cela signifie que leur compromission éventuelle n'a pas de conséquence dans le bon déroulement de la mission remplie par le système. Cependant, souvent ces fonctions et informations hériteront des mesures prises pour protéger les fonctions et informations retenues.

Les fiches d'expression des besoins de sécurité vont permettre aux utilisateurs d'exprimer leur appréciation de la sensibilité pour les fonctions et informations essentielles.

Description fonctionnelle du système cible

À ce niveau les finalités du système cible sont clairement exprimées et sa place est établie par rapport à l'existant, il convient dès lors de préciser pour chaque fonction essentielle identifiée :

• les informations en entrée et en sortie (résultats attendus) ;

• les traitements à réaliser (en indiquant aussi les interfaces permettant au système cible d’échanger des informations avec les autres SI).

Une fonction pourra être décomposée en sous fonctions, la sous fonction étant un ensemble cohérent de traitements (agrégat de tâches élémentaires) et d'informations.

Pour un système à concevoir, on utilise pour réaliser la modélisation du système cible la méthode générale de conception retenue (Exemples : MERISE, SADT, UML…). Pour un système existant ou dans le cas d'absence de modélisation lors de sa conception, il est proposé d'utiliser la représentation suivante : les fonctions sont représentées par un diagramme, selon une approche descendante, faisant apparaître la relation entre les sous fonctions, et des informations en entrée et sortie des fonctions (voir l'exemple à la figure présentée ici). Il est aussi possible de faire un découpage du système cible, tel que présenté ici.

Hypothèses

Il s'agit de formaliser les hypothèses relatives au système cible. Les hypothèses sont le plus souvent imposées par l’organisation responsable de l’étude, pour des raisons de politique interne ou externe de l’organisation, financières ou de calendrier.

Les hypothèses peuvent aussi constituer un risque accepté a priori sur un environnement donné.

Dans le cas de la rédaction d'un profil de protection ou d'une cible de sécurité, qui doivent démontrer la parfaite complétude des menaces par les objectifs de sécurité, il peut s'agir de vulnérabilités qui ne peuvent être couvertes par un objectif de sécurité dans les étapes suivantes. Dans ce même cas, il peut s'agir de la prise en compte formalisée de contraintes identifiées, alors que les autres ne constitueront que des aides à la compréhension du contexte.

Il est suggéré d'adopter la nomenclature suivante pour les hypothèses : H.xx (H pour hypothèse et xx étant le nom de l'hypothèse).

Détermination du mode d'exploitation de sécurité

La détermination du mode d'exploitation de sécurité du système consiste à indiquer comment le système permet aux utilisateurs de catégories différentes de traiter, transmettre ou conserver des informations de sensibilités différentes. Elle permet de prendre connaissance de la problématique sécuritaire générale car le mode d'exploitation de sécurité définit le contexte de gestion de l'information d'un système d'information.

De manière générale, le mode d'exploitation de sécurité du système appartient à l'une des catégories suivantes :

• Catégorie 1 : mode d'exploitation exclusif
  • Toutes les personnes ayant accès au système sont habilitées au plus haut niveau de classification et elles possèdent un besoin d'en connaître (ou équivalent) identique pour toutes les informations traitées, stockées ou transmises par le système.
• Catégorie 2 : mode d'exploitation dominant
  • Toutes les personnes ayant accès au système sont habilitées au plus haut niveau de classification mais elles n'ont pas toutes un besoin d'en connaître (ou équivalent) identique pour les informations traitées, stockées ou transmises par le système.
• Catégorie 3 : mode d'exploitation multi niveaux
  • Les personnes ayant accès au système ne sont pas toutes habilitées au plus haut niveau de classification et elles n'ont pas toutes un besoin d'en connaître (ou équivalent) identique pour les informations traitées, stockées ou transmises par le système.

Pour choisir le mode d'exploitation de sécurité du système, il est important de savoir s'il existe ou doit exister :

• une classification des informations hiérarchique (ex : confidentiel, secret…) et/ou par compartiment (médical, société, nucléaire…),
• des catégories d'utilisateurs,
• une notion de besoin d'en connaître, d'en modifier, d'en disposer…

Le choix du mode d'exploitation de sécurité peut être reconsidéré au vu des risques identifiés lors des étapes suivantes. Il est cependant important de s'interroger sur cet aspect au plus tôt car sa mise en œuvre a de fortes conséquences sur l'architecture du SI et de la SSI.

Règles de sécurité

La sécurité des systèmes d'information peut avoir fait l'objet d'un référentiel d'études et de documents ; bien qu'une analyse détaillée ne soit pas utile à ce stade, des renseignements peuvent être recherchés : priorités, résultats, consignes…

L'objectif est de recenser les principales règles et mesures de sécurité, formalisées ou non en place dans l'organisation. Le recueil pourra se faire à partir des documents suivants :

• politique de sécurité du système d'information ;
• plans de continuité des applications ;
• consignes de sécurité des développements ;
• résultats d'audits sécurité ;
• projets de sécurité.

Il est proposé d'adopter la nomenclature suivante pour les règles de sécurité : P.xx (P pour politique et xx étant le nom de la règle de sécurité).

Contraintes pesant sur le système cible

L'identification des contraintes permet de recenser celles qui ont un impact sur le système cible et de déterminer celles sur lesquelles il est toutefois possible d'agir. Elles complètent et amendent les contraintes de l'organisation déterminées précédemment. Une liste non exhaustive de types de contraintes qui peuvent être envisagées est disponible ici.

Références réglementaires spécifiques au système cible

La prise en compte des lois, règles ou règlements peut limiter le choix de solutions matérielles ou procédures et modifier l'environnement ou les habitudes de travail.

Il convient par conséquent de recenser l'ensemble des références réglementaires applicables au système cible.

Activité 1.3

Liens pour Naviguer dans ce module

Accueil  Module 1  Activité 1.1  Activité 1.2  Activité 1.3  Module 2 Exercices

mise à jour: 27/05/2008 09:01:15 AM -0400