08/11/2019
Question initiale :
Dans les documents détaillant la méthode, on qualifie les “biens essentiels” de “patrimoine informationnel”. En effet, dans l’étude de cas @rchimed, ne figurent dans le tableau des biens essentiels que des informations telles que le contenu d’un devis, d’une page web, d’un plan, etc.
Mes interrogations sont les suivantes:
Or, dans la nouvelle formation, nous avions qualifié de biens essentiels les activités essentielles, qu’elles reposent ou non sur une source d’information.
– Est-ce une erreur ?
– Quelle est la différence entre biens essentiels et activités essentiels ?
– Comment faire ressortir les biens essentiels d’une prestation effectuée par un administrateur Système, un commercial, etc. ne reposant pas sur une base d’information ?
– En outre, est-ce correct si dans mon tableau de biens essentiels ne figurent que des services et ou activités ?
Quelques éléments de réponse :
Dans EBIOS RM, le terme de biens essentiels a été remplacé par “valeurs métiers”, pour désigner le même concept : Valeur métier = “composante importante pour l’organisation dans l’accomplissement de sa mission. Cela peut être un service, une fonction support, une étape dans un projet et toute information ou savoir-faire associé”.
– Non, les biens essentiels ne sont pas limités au patrimoine informationnel. Il les faut voir comme quelque chose d’immatériel, qui a de la valeur pour le métier considéré – celui qui prend la responsabilité de sa protection.
– Selon la modélisation que l’on utilise, des activités sont en général liées à un ou plusieurs métiers et donc peuvent regrouper un ensemble de biens essentiels comme des processus, des services, des fonctions et/ou des informations. Le niveau d’abstraction (de modélisation) dépend de la finalité de l’étude et de la complexité du périmètre à étudier. Ce qui est important c’est qu’à partir d’un bien essentiel, le métier (la MOA) exprime un besoin de sécurité.
– Un bien essentiel peut être le service rendu dans le cadre d’une prestation : gérer des accès, patcher les systèmes, établir une proposition, gérer une base commerciale, etc. Attention néanmoins, le bien essentiel doit être une valeur métier pour la MOA de l’étude. Donc, gérer des accès est une valeur si la MOA est la DSI. Mais ce n’est pas une valeur métier pour une analyse conduite par la direction commerciale, par exemple.
– Oui on peut avoir uniquement des services ou activités. Mais attention d’être complet pour le périmètre considéré dans l’étude. Donc, il faut vérifier que les services et activités que vous avez choisis couvrent bien tout le cycle de vie – placé sous la responsabilité du métier – des informations essentielles.
10/06/2019
Le document suivant peut être utilisé lors de la détermination du socle de l’atelier 1 d’EBIOS Risk Manager dans le cas où l’objet de l’étude est un traitement de données à caractère personnel :
> Télécharger
Il constitue une déclaration d’applicabilité relative aux principes fondamentaux liés à la protection de la vie privée.
La suite de l’étude permet de satisfaire les obligations du RGPD en matière de sécurité (cf. art. 32) si vous appréciez les impacts sur les personnes concernées en plus de ceux sur l’organisme.
Vous pouvez ainsi utiliser EBIOS Risk Manager pour mener un PIA (cf. art. 35).
17/11/2018
Réponse d’un membre du Club EBIOS : “Attention aux échelles utilisant plusieurs types d’impacts”
Rappel du guide EBIOS : “Cette action [élaboration d’une échelle] consiste à créer une échelle décrivant tous les niveaux possibles des impacts. Tout comme les échelles de besoins, une échelle de niveaux d’impacts est généralement ordinale (les objets sont classés par ordre de grandeur, les nombres indiquent des rangs et non des quantités) et composée de plusieurs niveaux permettant de classer l’ensemble des risques“.Ainsi, il est habituel de voir des utilisateurs de la méthode construire plusieurs échelles ordinales selon la nature de l’impact (financier, juridique, sur les opérations, sur la vie privée…) pour estimer la gravité des évènements redoutés. La construction est alors faite en graduant individuellement chaque type d’impact, sans se préoccuper de la cohérence entre les niveaux.Or, seul un résultat global est utilisé dans les cartographies de risques pour évaluer la gravité des uns par rapport aux autres. L’information sur la nature des impacts est perdue.
Pour éviter de fausses conclusions sur l’importance des risques, il faut donc veiller à vérifier la cohérence transverse de la gradation des impacts dans les échelles. Par exemple, vérifier que l’estimation d’un impact de niveau 3 sur les opérations sera de la même valeur pour l’organisme que les impacts financier et juridique de même niveau.
Lorsque c’est possible, le critère pivot (servant à la cohérence) peut être l’échelle financière. Dans le cas contraire (souvent le cas), il convient de présenter les impacts côte à côte et d’estimer leur importance auprès des responsables en recherchant un consensus. Dans ce cas là, les échelles peuvent avoir des cases vides (niveau n’ayant pas d’équivalence pour toutes les natures d’impacts considérées). Ça peut être le cas lorsque l’on estime par exemple la perte de vies humaines.Il est parfois difficile à des responsables d’établir ces échelles de manière générique. Une bonne solution consiste alors à demander aux parties prenantes de hiérarchiser les événements redoutés après avoir identifié les impacts, et de construire les échelles sur la base de cette estimation.
Réponse d’un membre du Club EBIOS : “il est utile de disposer d’échelles d’impacts hétérogènes, c’est un moyen important de communication avec les métiers”
En complément, l’idéal est selon moi de :
On peut ainsi facilement réaliser une étude à la fois SSI et protection de la vie privée en présentant côte à côte les impacts pour l’organisme et les impacts pour les personnes concernées.
Réponse d’un membre du Club EBIOS : “deux solutions”
Plusieurs propositions sont possibles pour démontrer que les problématiques associées à la traçabilité sont traitées dans une étude EBIOS sans pour autant considérer la traçabilité comme un critère :
Réponse d’un autre membre : “la traçabilité n’est pas un critère de sécurité”
Les critères de sécurité servent à apprécier les impacts en cas d’atteinte de chacun d’eux, et en particulier à étudier les besoins de sécurité. En sécurité de l’information, seules la disponibilité, l’intégrité et la confidentialité sont considérées comme des critères de sécurité (voir notamment les normes ISO/IEC 2700x). Il ne faut pas les confondre ni avec les thèmes de mesures de sécurité, ni avec les références réglementaires. En effet, le (faux) besoin de traçabilité vient du fait qu’on souhaite savoir ce qui s’est passé après un incident (mesure de détection) et/ou d’obligations diverses (légales, réglementaires, sectorielles ou liées à la politique SSI). Il est donc inutile, et même contre-productif d’étudier le besoin de traçabilité.
En outre, il conviendrait de disposer d’une échelle de besoins et d’une échelle d’impacts liées à la traçabilité. C’est souvent en essayant de les construire qu’on se rend compte qu’il s’agit d’une “envie de quelqu’un” qui relève de la mesure de sécurité ou de la couverture d’un “risque” juridique.
Enfin, ceci impliquerait d’étudier toutes les menaces qui mènent à une perte de traçabilité ! Or, ceci relève de la bonne mise en œuvre d’une mesure de sécurité, qu’il n’est pas nécessaire de traiter comme un risque (ou sinon il faudrait le faire pour le chiffrement, le contrôle d’accès, etc.). Toutefois, l’étude des besoins étant un instrument de communication avec les métiers, il est possible d’intégrer la traçabilité dans les critères de sécurité pour que les métiers adhèrent davantage à la démarche en voyant leur point de vue pris en compte…
23/06/2017
12/02/2017
Dans une étude de risques, on constate que les impacts analysés dépendent fortement du point de vue de chaque partie prenante. Partant de ce constat, ce document de réflexion incite à la prise en compte des préoccupations de chaque acteur, dans une logique “by design”, afin que le produit, système ou service soit accepté par tous.
ClubEBIOS-ImpactsDifferencies-2017-02-19-Approuve
> Télécharger