MEHARI 2010 Fundamental concepts and functional specificationsmeharipedia.x10host.com/wp/wp-content/.../12/MEHARI... · METHODS MEHARI 2010 Fundamental concepts and functional specifications

METHODS

MEHARI 2010 Fundamental concepts and functional specifications

August 2010

Methods Commission

Please post your questions and comments on the forum:

http://mehari.info/

CLUB DE LA SECURITE DE L’INFORMATION FRANÇAIS

11, rue de Mogador, 75009 PARIS

Tél. : +33 1 53 25 08 80 – Fax : +33 1 53 25 08 88 – e-mail : [email protected] Web : http://www.clusif.asso.fr

MEHARI is a registered trademark of CLUSIF. The law of March 11th, 1957 only permits "copies or reproductions strictly reserved for the private usage of a copyist not intended for collective use", or analyses and short quotations used as examples or illustrations (Article 41, paragraphs 2 and 3). Therefore, "any representation or reproduction, whether partial or complete, made without the approval of the author, of entitled parties or of the legal successors is prohibited" (Article 40, paragraph 1). Any form of representation or reproduction would therefore constitute an infringement of copyright, a punishable offence under Articles 425 and following of the French Penal code.

MEHARI 2010: Fundamental concepts 3/66 © CLUSIF 2010 and functional specifications

Acknowledgment The CLUSIF would like to thank specially Jean-Philippe Jouas for his outstanding contribution and the members of the « Methods space » who participated to the realization of this document.

Jean-Louis Roule and Jean-Philippe Jouas have effected the English translation.


Summary

Introduction .................................................................................................................................................. 7

1. Purpose of this document ................................................................................................................ 7

1.1 Fundamental objectives of a methodology for direct management of risks..................... 7 1.2 Document outline...................................................................................................................... 8

2. Normative references........................................................................................................................ 8

3. Terms and definitions ....................................................................................................................... 9

3.1 Security stake.............................................................................................................................. 9 3.2 Impact (Risk impact)................................................................................................................. 9 3.3 Intrinsic impact .......................................................................................................................... 9 3.4 Threat .......................................................................................................................................... 9 3.5 Likelihood (Risk likelihood)..................................................................................................... 9 3.6 Intrinsic likelihood..................................................................................................................... 9 3.7 Risk scenario............................................................................................................................... 9 3.8 Security service........................................................................................................................... 9 3.9 Intrinsic vulnerability ................................................................................................................ 9 3.10 Contextual vulnerability............................................................................................................ 9

4. Risk assessment................................................................................................................................10

4.1 Introduction .............................................................................................................................10 4.2 Identifying risks .......................................................................................................................10

4.2.1 The characteristic elements of risks.................................................................................10 4.2.1.1 The asset ......................................................................................................................10 4.2.1.2 Intrinsic vulnerability and contextual vulnerability ...............................................12 4.2.1.3 Asset damage ..............................................................................................................13 4.2.1.4 The threat leading to risk occurrence......................................................................13 4.2.1.5 Risk scenarios .............................................................................................................14

4.2.2 The risk identification process .........................................................................................15 4.2.2.1 Listing the characteristic elements of risks.............................................................15 4.2.2.2 Listing the risks that are theoretically possible ......................................................15 4.2.2.3 Development of a knowledge base of typical risks...............................................16 4.2.2.4 Selecting risks to take into account .........................................................................16

4.2.3 Summary of risk identification .........................................................................................17 4.3 Estimating risks........................................................................................................................17

4.3.1 Measurable elements and risk metrics.............................................................................18 4.3.1.1 Intrinsic impact...........................................................................................................18 4.3.1.2 Intrinsic likelihood .....................................................................................................19 4.3.1.3 The effect of security measures: risk reduction factors ........................................20 4.3.1.4 Influence of the quality of existing security measures ..........................................22


4.3.1.5 Using a risk knowledge base.....................................................................................22

4.3.2 The risk estimation process ..............................................................................................23 4.3.2.1 Developing reference material .................................................................................23 The impact scale ............................................................................................................................23 The likelihood scale.......................................................................................................................24 4.3.2.2 Estimating risks ..........................................................................................................24 4.3.2.3 Global assessment for each risk (managed) ...........................................................26

4.3.3 Summary of risk scenario assessment .............................................................................27 4.4 Evaluating risks........................................................................................................................27

5. Risk treatment ..................................................................................................................................29

5.1 Retaining the risk .....................................................................................................................29 5.2 Reducing the risk .....................................................................................................................30

5.2.1 Choosing which security services to implement to increase certain risk reduction factors ..................................................................................................................................30

5.2.1.1 Security services relevant or adapted to a given risk.............................................30 5.2.1.2 Choosing the target quality level for the security service to be implemented...30 5.2.1.3 Evaluating the combined effect of multiple security services .............................31 5.2.1.4 Decision-making process for reducing risks ..........................................................31

5.2.2 Using structural measures .................................................................................................31 5.3 Transferring the risk................................................................................................................32 5.4 Avoiding the risk .....................................................................................................................32

6. Risk management.............................................................................................................................33

6.1 Developing action plans .........................................................................................................33

6.1.1 Choosing priority objectives and optimization..............................................................33 6.1.2 Choosing solutions: organizational and technical mechanisms...................................34 6.1.3 Choosing structural measures and risk avoidance measures .......................................34 6.1.4 Approval and decision-making ........................................................................................35 6.2 Implementing action plans.....................................................................................................35 6.3 Monitoring and steering direct management of risks.........................................................35

6.3.1 Service quality verification ................................................................................................35 6.3.2 Verifying implementation of the security services ........................................................36 6.3.3 Overall steering for direct management of risks ...........................................................36

Appendix A1 MEHARI 2010 knowledge base classification of primary assets ..................................37

Appendix A2 Mehari 2010 knowledge base classification of supporting assets ...............................38

Appendix B MEHARI 2010 knowledge base classification of intrinsic vulnerabilities......................39

Appendix C1 MEHARI 2010 knowledge base classification of events................................................41

Appendix C2 MEHARI 2010 knowledge base classification of actors ................................................42

Appendix D MEHARI 2010 standard scales for impact and likelihood levels ...................................43


Appendix E1 MEHARI 2010 standard scales for likelihood reduction factors ..................................45

Appendix E2 MEHARI 2010 standard scales for impact reduction factors .......................................46

Appendix F1 MEHARI 2010 standard decision grids ............................................................................47

Appendix F2 MEHARI 2010 standard decision grids ............................................................................48

Appendix G1 Specification of the security services......................................................................49

Security services.....................................................................................................................................49 Security services and sub-services ......................................................................................................49 Security mechanisms and solutions ....................................................................................................49 Security services typology ....................................................................................................................49 Mandatory parameters..........................................................................................................................50 Security service quality evaluation using Mehari questionnaires....................................................51

Contributive measures .......................................................................................................................51 Major or “sufficient” measures.........................................................................................................52 Essential measures..............................................................................................................................53 Inapplicable questions........................................................................................................................54

Appendix G2 List of the security services of MEHARI 2010 knowledge base .................................55

Appendix G3 Scale used for the evaluation of the quality level of security services .......................64


Introduction

For many years, numerous security publications have been considering risk analysis to be the foundation of security actions and referring to it as such.

This is still true for the most recent standards in the domain of information security management, in particular ISO/IEC 27001, which explicitly refers to risks identifying, evaluating and treating processes.

Necessity of a methodology to complement the standards

These standards that explicitly call on the idea of "risk" and the need to evaluate and control risks do not propose any methodology for analyzing risks, stating simply that organizations must choose their own methodology.

Even the ISO/IEC 27005 standard, which provides a general framework for risk management leaves considerable room for interpretation and may lead to numerous risk management approaches and processes.

In this context, the need for a formal risk management methodology is clear. It is also obvious that this methodology must meet certain requirements, themselves a function of the type of risk management an organization is seeking.

It seems that even the expression "risk management" can be interpreted differently from one organization to another, and that the supporting methodologies can be significantly different depending on the objectives targeted.

1. Purpose of this document

This document is intended for organizations looking to select, set up, define or develop a process for directly managing their risks. As such, its main purpose is to specify the principles that should be respected by a supporting methodology and to highlight the functional specifications arising from these principles.

MEHARI was developed for these purposes, and complies with these specifications. This document explains how to comply with these specifications.

1.1 Fundamental objectives of a methodology for direct management of risks

The fundamental objectives of directly and individually managing the risks, which a company or an organization is exposed to, are:

− Identify all the risks that the company is exposed to.

− Quantify the level of each risk.

− For each risk deemed inadmissible, take measures to reduce the level of that risk to an acceptable one.

− Implement, as a management tool, permanent tracking of both risks and their level.

− Make sure that each individual risk is dealt with following a decision to accept, reduce, avoid or transfer that risk.


In order to meet these objectives, the processes and steps described in the ISO/IEC 27005 standard need to be detailed and specified. That is precisely the goal of this document, to describe the principles and functional specifications arising from the fundamental objectives listed above, and to explain why they are necessary in that purpose.

1.2 Document outline

These various topics shall be examined by this document in an order that more or less reflects the outline of ISO/IEC 27005:

− Risk assessment

− Risk treatment

− Risk management processes

The overall outline and different topics addressed are illustrated below.

2. Normative references

The documents referenced below may prove useful for the purposes of this document:

ISO/IEC 27001:2005, Information technology – Security techniques – Information security management systems - Requirements

ISO/IEC 27005:2008, Information technology – Security techniques – Information security risk management

IdentificationWhich risks ?

EstimationSeriousness ?

EvaluationAcceptability ?

Risk assessment

Retention Reduction Transfer Avoidance

Risk Treatment

Actionplans Implementation Monitoring

and steering

Risk management


3. Terms and definitions

The terms below are defined specifically for this document and are necessary to the understanding of this document.

3.1 Security stake The consequences of a security incident on the organization's objectives.

3.2 Impact (Risk impact) The consequence, for the organization concerned, if the risk in question occurs.

3.3 Intrinsic impact The consequence, for the organization concerned, if the risk in question occurs in the absence of all security measures.

3.4 Threat A description of all the factors leading to occurrence of the risk, including the initiating event and whether it is voluntary or accidental, the doer and the circumstances in which the event occurs.

3.5 Likelihood (Risk likelihood) The probability that the risk in question will occur, in the context of the organization concerned.

3.6 Intrinsic likelihood The probability that the risk in question will occur, in the context of the organization concerned, in the absence of any security measure.

3.7 Risk scenario A description of all the characteristics of a risk, including the asset concerned, the intrinsic vulnerability of the affected asset, and the threat leading to occurrence of the risk.

3.8 Security service A description of a security function that fulfills a need.

3.9 Intrinsic vulnerability The intrinsic characteristic of a system, object or asset that may be susceptible to threats.

3.10 Contextual vulnerability The shortcoming or flaw in a security mechanism that could be exploited by a threat to strike a targeted system, object or asset.


4. Risk assessment

4.1 Introduction

Assessing risks consists in identifying, as exhaustively as possible, all the risks which a company or organization is exposed to, estimating the seriousness of each risk and judging whether each risk is evaluated as acceptable or not.

Each step in this process must be performed with a view to ensuring an accurate evaluation of the seriousness of each risk, according to the context and especially the existing security measures.

The three steps constituting the overall process of assessing risks are:

− Identifying risks,

− Estimating risks,

− Evaluating risks.

4.2 Identifying risks

This step aims not only to look for and recognize risk situations, which is to say situations presenting certain types of risks, but also to characterize each of these risks accurately enough to be able to estimate how serious it is.

This raises two questions:

− What characteristic elements of risks must be highlighted, and in how much detail must they be described?

− What is the best way to do this?

4.2.1 The characteristic elements of risks The following paragraphs define and describe the elements that must be included in risks descriptions, and justify why. These elements are:

− The asset,

− The intrinsic vulnerability of the asset damaged by the risk,

− The asset damage,

− The threat.

4.2.1.1 The asset

Rationale

Assets are the main objects of the risk. They are what will be damaged, and a risk comes from the fact that a certain form of asset is susceptible to some particular damage.




Risk assessment


Clearly, the consequences and seriousness of occurrence of a risk depend on the nature of the assets threatened, which must therefore be included when characterizing a risk.

Describing assets

a. Primary assets

Asset descriptions will be used to evaluate the consequences of the risks that the asset is exposed to. Consequently, the key features should refer to the needs of organizations, which may be divided into three main categories:

− Services (IT Services and general),

− Data necessary for the services to function,

− Management processes.

Within each category, different types of primary assets must be distinguished based on:

− The type of needs,

− The type of service providers.

And possibly:

− The field of activity and different areas of responsibility,

− The technology used,

− The users concerned.

These classifications must correspond to types of needs, and be described on a functional level.

Specification

The primary assets shall be described according to categories of services, data and management processes and, within each category, according to types corresponding to functional needs.

MEHARI complies with this specification. The classification of primary assets from which the MEHARI 2010 knowledge base was created is provided in Appendix A1.

Note: Because primary assets correspond to the needs of organizations, this is the level on which the importance of these needs should be evaluated (see below). The importance of these needs is a factor in determining the level of risk.

b. Secondary or supporting assets

Assets have vulnerabilities, and it is the exploitation of these vulnerabilities that causes the risk.

To find these vulnerabilities, it is crucial to distinguish the following for each primary asset:

− The different forms that asset may take,

− The different contingencies on which that asset may depend.

These forms and contingencies may be grouped under the label of "secondary" or "supporting" assets.

Primary assets correspond to functional needs, while secondary assets correspond, on a physical and concrete level, to the means required to meet functional needs.


Specification

Secondary assets shall be described by types of means required to meet the functional needs described by the primary assets.

MEHARI complies with this specification. The classification of secondary assets from which the MEHARI 2010 knowledge base was created is provided in Appendix A2.

c. Characterizing the asset concerned by the risk

To meet the objective of direct risk management, each risk must be characterized by an asset, and each asset according to its category, its primary asset type and its secondary asset type.

Examples from the MEHARI 2010 asset tables provided in Appendices A1 and A2 include:

− Application service support server,

− Email support software configuration,

− User account required to access office services.

Specification

Each risk identified shall include a description of the asset in question. This description shall specify both the primary asset type and the secondary asset type.

4.2.1.2 Intrinsic vulnerability and contextual vulnerability

Risks arise from the fact that a given asset has one or more vulnerabilities.

Defining what "vulnerability" means is therefore important. Two different definitions may be used.

The first one consists in defining vulnerability as an intrinsic feature of a system, object or asset that may be susceptible to threats (e.g. the fact that the material on which a document is written is degradable).

This will be referred to as an 'intrinsic' vulnerability.

Vulnerability can also be defined in terms of security processes and their potential shortcomings. In this case, it is defined as a shortcoming or flaw in a security system that could be exploited by a threat to strike a targeted system, object or asset (e.g. lack of protection against storms).

This will be referred to as a 'contextual' vulnerability.

This second definition is not particularly suitable for identifying risks due to the major disadvantage it has of making identified and managed risks dependent on security measures, and therefore on knowledge of these measures, which is not always the case.

Intrinsic asset vulnerabilities, on the other hand, are central to describing risks and must therefore be looked for and identified.

Intrinsic vulnerabilities depend on the type of secondary asset, as they are essentially caused by the nature of the asset (e.g. hardware medium, software medium), which is defined by the secondary asset type.

It is also important to note that the intrinsic vulnerability of an asset may be described as a specific susceptibility to asset damage. Consequently, describing the asset damage or the intrinsic vulnerability comes down to the same thing.

The list of intrinsic vulnerabilities from which the MEHARI 2010 knowledge base was created is provided in Appendix B. This list indicates, for each type of secondary asset, the type of asset damage and, more literally but strictly equivalent, the type of vulnerability.


Only one intrinsic vulnerability is implicated for each risk.

Functional specification

Each risk identified shall include a description of the intrinsic vulnerability implicated.

MEHARI is compliant with this specification.

4.2.1.3 Asset damage

The type of consequence can be inferred from the vulnerability exploited, but there are times when it is still necessary to specify the consequence (e.g. in the event of theft, the anticipated consequence may be loss of availability or loss of confidentiality).

For assets belonging to the Data or Services categories, it is important to specify at least one of the consequence criteria (Availability, Integrity or Confidentiality), referring to other consequence criteria such as evidence value if necessary.

For Management Process assets, there is not always a specific list of criteria to identify, as it is directly specified by the asset damage.

In all cases, though, the asset damage must be indicated.

Functional specification

Each risk identified shall specify the type of asset damage.


4.2.1.4 The threat leading to risk occurrence

There can be no risk without a cause that leads to the intrinsic vulnerability actually being exploited. Security standards and references, including ISO/IEC 27005, use the idea of a "threat" to describe this cause.

It remains necessary, however, to include more than just the simple cause when describing the threat.

Rationale

Anything that can be used to describe how the damage may occur and, most importantly, anything that may influence the likelihood of the risk occurring should also be indicated.

Consequently, the following must be described:

− The event originating the risk occurring (this event is often already described by the type of vulnerability),

− Whether this event is voluntary or accidental,

− The actor,

− The circumstances in which this event occurs.

Each of these parameters clearly has an influence on the probability of the risk occurring.

Description

The first two categories are often combined in the same description, as is the case in this document.

a. Events

Events can be described by categories and then by type within each category.

At least three categories should be considered:


− Accidents,

− Errors,

− Voluntary acts, whether malicious or not.

Within each category, types of events must be defined and described based on aspects such as:

− Whether the cause is internal or external to the entity,

− Whether the event is material or immaterial,

− Any other factor that may influence the probability of the event occurring.

The categories and types of events from which the MEHARI 2010 knowledge base was created is provided in Appendix C1.

b. Actors

In the case of threats that are originated by people, it is important to distinguish categories of people according to their rights and privileges.

According to these rights:

− Actors may be more or less capable of originating the threat, which means the probability of the risk occurring will be greater or smaller,

− The security measures that should be implemented will be different, which means, depending on which measures are actually implemented, the probability of the risk occurring will be greater or smaller.

The table provided in Appendix C2 highlights the categories of actors from which the MEHARI 2010 knowledge base was created.

c. Circumstances in which the risk occurs

Circumstances can include factors such as:

− Process or process steps: for example, modification of files during maintenance operations,

− Location: for example, theft of media from one location or another, inside or outside the company,

− Time: for example, actions occurring during or outside working hours.

Specific circumstances that merit extra attention should be identified to finalize the description of each risk.

Specification

Each risk identified shall include a detailed description of the threat, including:

− The originating event and whether it is voluntary or accidental,

− The actor originating this event,

− The circumstances in which this event occurs.


4.2.1.5 Risk scenarios

The different elements required to describe a risk can be used to create a risk scenario, which reiterates the various aspects listed above in a less structured format.


As such, the knowledge base of risk scenarios in the MEHARI 2010 knowledge base contains a free description of each scenario.

4.2.2 The risk identification process The process of identifying risks is crucial because no risk that is ignored by this process can be analyzed or addressed in an action plan.

Of course, it is possible to refer to a list of generic risks described in a database, such as MEHARI, but the principles on which such a list is based must be known before it can be relied upon.

Consequently, the process used to identify risks must be specified.

Three steps must be followed to ensure that the list of risks is as exhaustive as possible:

− Listing the characteristic elements of risks,

− Listing the risks that are theoretically possible,

− Selecting all the risks from this list that are possible within the specific context of risk management already in place.

Each of these steps is described in more detail below.

4.2.2.1 Listing the characteristic elements of risks

This involves identifying and detailing the classifications of each category of elements mentioned earlier in this document:

− Types of primary assets,

− Types of secondary assets,

− The intrinsic vulnerabilities linked with each type of secondary asset,

− Types of triggering events,

− Types of actors.

It will be easier to describe the circumstances in which risks occur in the next step on determining possible risks.

Rationale

When establishing the list of risks, it is important to list each of the basic components separately to ensure that all possible combinations are taken into account in the next step.

Specification

Categorizations shall be established for each type of element of risk, as listed above.


4.2.2.2 Listing the risks that are theoretically possible

This involves looking for all the possible and plausible combinations of elements and completing them, if need be, with circumstances in which the risk may occur.

It is best to create this list starting with the assets.

More often than not, referring to the primary or secondary assets makes it possible to highlight the specific risk circumstances, such as process steps, times of the year or periods in time, or even specific geographical situations.


Specification

All "possible" combinations shall be listed and, wherever necessary, completed with circumstances in which the risk may occur.


The overall process is illustrated below.

4.2.2.3 Development of a knowledge base of typical risks

The majority if not entirety of the process described above is very general and may produce the same result for many entities. As such, it makes sense to carry out this process in a generic way to develop a knowledge base of typical risks that can be used by numerous entities either as is or with a few adjustments.

Such a knowledge base provides the advantages of sharing development tools and enriching the knowledge base with input from a community of users.

MEHARI includes a knowledge base of typical risks, the "risk scenarios" knowledge base.

4.2.2.4 Selecting risks to take into account

The last step in identifying risks involves striking from the list above all risks deemed impossible in the specific context of the organization concerned or that are irrelevant to the risk management concerned.

This is especially applicable in the case of typical risk knowledge bases such as the one provided by MEHARI.

Vulnerability

Threat

Risk description

Originatingevent Actor

Occurrence circumstances

IntrinsicVulnerability

Riskslist

Assetdamage

Primary asset Secondaryasset

Asset


4.2.3 Summary of risk identification Identifying risks is a process that includes multiple steps, each having well-defined deliverables and contributing to the development of a list of risk scenarios to evaluate, as illustrated in the diagram below.

Activity needs analysis :• services

• data• management process

Primary assets typology and list

Primary assets analysis:• forms

• contingencies

Secondary assetstypology and list

Secondary assets analysis :• intrinsic vulnerabilities

List of secondary assets vulnerabilities

Threat analysis :• originating events

Analysis of actors potentially at the origin of the event

Analysis of occurrence conditions: process, location, etc.

Originating eventstypology and list

Typology of actors in relation with originating events

Typology of conditions parameters to be considered

Typology of potential damages

List

of

Risk

Scenarios

to

evaluate

4.3 Estimating risks

This step aims at estimating the seriousness of each risk previously identified, while taking into account the different security measures implemented.

That said, the list of risk scenarios may be long, in which case it may be desirable to go through and select a limited number of risks, namely those deemed to be "major", so as to reduce the number of risks to manage.

It may also be a good idea to select the risks that may be kept under control and "managed" without taking into account the security measures to avoid, in particular, losing control of a risk situation currently reduced to an acceptable level but that may, as the context or technology changes, become critical again.

Consequently, it is necessary to define and be able to estimate:

− The "intrinsic" seriousness of the risk, that is without taking into account the security measures,




Risk assessment


− The "residual" seriousness of the risk, taking into account the security measures in place.

This raises two questions:

− What are the measurable elements of the risks, and what overall measurement system is required to estimate the intrinsic and residual seriousness of the risks?

− What is the best way to do this?

4.3.1 Measurable elements and risk metrics Traditionally, risk is measured based on two parameters:

− The degree of seriousness of the consequences, or "impact",

− The probability of the occurrence, or "likelihood".

Global and direct assessment of these two parameters is usually difficult; as such, it is preferable to use a more analytical approach that breaks these parameters down into multiple levels and individually evaluates:

− The intrinsic impact, excluding all security measures,

− The intrinsic likelihood, excluding all security measures,

− The effect of security measures on these two parameters.

The principles underlying these evaluations are described below.

4.3.1.1 Intrinsic impact

The intrinsic impact of a risk is defined by the maximum level of consequence the organization may incur, in the absence of any security measure designed specifically to reduce these consequences.

Rationale

It is possible to evaluate the level of impact directly, taking into account the security measures, but it is easier to evaluate the intrinsic impact. Furthermore, there are two other factors that also make it preferable to evaluate the intrinsic impact first:

− Measures taken or envisaged to reduce consequences may end up not lasting or being inoperable; the intrinsic impact makes it possible to evaluate the level of consequences in such a case,

− Managers sometimes tend to underestimate risks by overestimating the effect of existing security measures; they will be better able to judge the risk situation and its seriousness if they start by considering that there are no security measures.

More precisely, if the intrinsic impact of a risk is significant, the question of the quality and effectiveness of the means used to reduce it will inevitably be raised, whereas if the residual impact was evaluated directly only the existence of relevant means would be evoked.

Complementary considerations to take into account

Two other points should also be considered:

− Once an incident has occurred, the organization will have "natural" defense reactions that, even without "organized" and planned measures, will make it possible to minimize the consequences of the incident,


− There may also be measures that limit the consequences and cannot be called into question because they are external or tied to a permanent context.

In these specific cases, and only in these cases, these security measures may be taken into account when evaluating the intrinsic impact of a risk.

Specification

The intrinsic impact of a risk shall be evaluated without taking into account the security measures designed to reduce this impact. It shall refer to a type of asset, primary or secondary, and a type of consequence.


4.3.1.2 Intrinsic likelihood

The intrinsic likelihood is defined as the maximum probability that the risk will occur, in the absence of any security measure designed specifically to reduce this probability.

Rationale

It is possible to evaluate the level of likelihood directly while taking into account security measures. However, as with the intrinsic impact, evaluating the intrinsic likelihood is preferable for the simple reason that it is easier to do, as well as for the two other complementary reasons already mentioned:

− Measures taken or envisaged to reduce the probability of the risk occurring may end up not lasting or being inoperable, and the intrinsic likelihood makes it possible to evaluate the probability in such a case,

− Managers sometimes tend to underestimate risks by overestimating the effect of existing security measures; they will be better able to judge the risk situation and its probability if they first examine the position under the assumption that that there are no security measures.

More precisely, if the intrinsic likelihood of a risk scenario is significant, the question of the quality and effectiveness of the means used to reduce the likelihood that it will occur will inevitably be raised, whereas if the residual likelihood was evaluated directly only the existence of relevant means would be evoked.

The actors and conditions in which the risk occur will be important when taking into account the security measures (the effectiveness of these measures depends on those factors), but measures already implemented should not be considered for the intrinsic likelihood because, by definition, no security measure is to be considered at this stage.

Description

The activities of each organization, as well as factors such as economic, social and geographic context, all influence the extent to which each organization is exposed to different types of risk, independently of any measures implemented:

− A market-leading high-tech company is more exposed to hacking and industrial espionage than others,

− A company located on the banks of a river is more exposed to the risk of flooding than others,

− An organization handling many financial transactions is more exposed to the possibility of fraud.


The possible existence of factors that could expose the organization to a given type of risk, and therefore to the event triggering that risk, must therefore be examined.

The intrinsic likelihood of an event can depend on a number of factors:

− Where the organization is located and its environment, for natural risks,

− The potential stakes, for the perpetrator, of a voluntary act such as theft, embezzlement and intellectual satisfaction,

− The probability that a voluntary act will specifically target the organization (inversely proportional to the number of potential targets: idea of targeting).

Specification

The intrinsic likelihood of a risk is the same as that of the event that triggers it. It shall be evaluated exclusive of existing security measures that would reduce the probability of the event occurring.


Note: Intrinsic likelihood may also be referred to as the "natural exposure" to the risk in question.

4.3.1.3 The effect of security measures: risk reduction factors

The security measures implemented may act as risk reduction factors. To manage risks, it is necessary to understand how, in what way and to what degree these measures reduce the risk level.

Certain measures influence the likelihood, while others affect the consequence level (or impact); in both cases, they work in several ways that must be identified.

Likelihood reduction factors

Suitable measures can reduce risk likelihood through diverse mechanisms that may act independently or cumulatively and do not all apply to the same actors.

It is possible to identify different kinds of measures, for example those that:

− completely prevent an event from occurring;

− may or may not prevent an event from occurring, depending on the severity of the event;

− make it more difficult to carry out a malicious act (thereby making that act feasible by fewer people);

− forbid human actions;

− forbid and check;

− forbid, check and severely punish violation of a rule.

The above measures can be divided into two types:

− Dissuasive measures, which target human actions and aim at making it less likely that an actor will actually perform the action

− Preventive measures, which aim at making it less likely that any action, whether by a human or not, leads to the occurrence of the risk.

Dissuasive measures

Dissuasion is based on three principles:


− The fact that an action can be attributed to the perpetrator (the actor), which brings into play measurable technical and organizational mechanisms (e.g. existence of traces, user authentication, strength of evidence),

− The existence of penalties, the severity of which may also be measured,

− Awareness on the part of the actor that their actions may be attributed to them and of the penalties incurred in such a case.

The effectiveness of dissuasive measures may therefore be evaluated and quantified by referring to a scale that each organization should define or at least validate, as discussed later in this document.

Preventive measures

Prevention depends, of course, on the events that the organization is trying to avert. Most often, prevention involves technical measures and monitoring mechanisms whose effectiveness and robustness may be evaluated.

The effectiveness of preventive measures may therefore be evaluated and quantified by referring to a scale that each organization should define or at least validate, as discussed later in this document.

Specification

Dissuasion and prevention constitute the likelihood reduction factors. These factors shall be evaluated and quantified by referring to effectiveness scales that shall be defined in advance.


Impact reduction factors

Suitable measures can reduce risk impact (the level of its consequences) through diverse mechanisms that may act independently or cumulatively and do not all apply to the same types of consequences.

It is possible to identify different kinds of measures, for example those that:

− Limit, in absolute terms, the maximum direct impact possible,

− Prevent the propagation of an initial incident,

− Anticipate reparation of equipment following a material incident,

− Anticipate restoration of the original state following an immaterial incident,

− Anticipate backup facilities.

The above measures can be divided into two types:

− Confinement measures, which aim to limit the magnitude of direct consequences,

− Palliative measures, which aim to minimize the indirect consequences of a risk by anticipating crisis management.

Confinement measures

Confinement is based on several types of mechanisms that all impose limits on the consequences of a risk:

− Setting limits on events that can be propagated, such as physical limits on certain types of incidents (e.g. firewalls),


− Determining intermediary checkpoints in processes to prevent the propagation of errors or faults,

− Monitoring process execution to limit the consequences of a mishap that may lead to more severe consequences,

− Setting limits on parameter variations allowed (e.g. limits on amounts transferred or on differences between two states, with control procedures being triggered when these limits are exceeded).

The effectiveness of confinement measures may be evaluated and quantified by referring to a scale that each organization should define or at least validate, as discussed later in this document.

Palliative measures

These measures, sometimes called palliation, do not in any way change the direct consequences, which is to say the incident itself, but may minimize the indirect consequences of the incident. These measures are based on different types of mechanisms:

− Hardware or software maintenance plans,

− Data restoration and backup plans,

− Activity continuity and recovery plans,

− Crisis management and communication plans.

The effectiveness of palliative measures may be evaluated and quantified by referring to a scale that each organization should define or at least validate, as discussed later in this document.

Specification

Confinement and palliation constitute the impact reduction factors. These factors shall be evaluated and quantified by referring to effectiveness scales that shall be defined in advance.


4.3.1.4 Influence of the quality of existing security measures

It is clear that these risk reduction factors do not solely depend on the type of existing security measures, but also on their quality. Certain implementations may include mechanisms that are more effective than others, and this must be taken into account.

Specification

The process for evaluating risk reduction factors shall take into account the quality of the security measures relevant to each risk.

In practice, measuring the quality comes down to looking for possible weaknesses not only in the mechanisms implemented but also in the conditions and context in which they are implemented.

This simply means evaluating the level of contextual vulnerability1 associated with each risk.

4.3.1.5 Using a risk knowledge base

If risks are identified using a knowledge base of typical risks, as described in section 4.2.2.3, this knowledge base may be completed to include, besides the simple description of the characteristic elements of each risk, information on the relevant security measures for each type of risk, the

1 See the definition of this term in sections 3.9 and 4.2.1.2.


criteria used to evaluate the quality of these measures and the relationship between the quality of these measures and the effectiveness of risk reduction factors.

MEHARI and its knowledge base include all these elements and, in particular:

− A specification of the "security services" including criteria for evaluating quality and a measurement system for evaluating the measures (provided in Appendix G1),

− A security services reference manual,

− An expert knowledge base of questionnaires for diagnosing the quality of security services,

− The reference, for each risk reduction factor for each risk in the knowledge base, of relevant security services and formulas for evaluating the combined effects of these services.

Note: the questionnaires for diagnosing the quality of the security services may also be called vulnerability audit questionnaires (contextual vulnerabilities).

4.3.2 The risk estimation process The process for estimating risks involves two phases:

− A phase that could be considered "strategic" in that it involves setting up evaluation references and knowledge bases,

− A more operational phase that involves actually estimating the risks using the knowledge bases and references put into place in the first phase.

4.3.2.1 Developing reference material

This involves defining the levels that will be used to evaluate the various parameters of each risk, as previously mentioned, and defining in particular:

− The impact scale,

− The likelihood scale,

− Effectiveness scales for the different risk reduction factors.

The impact scale

The impact scale is designed to organize the consequence levels into a hierarchy.

Rationale

As impact is a key factor in estimating risks, it is essential that this scale be defined as clearly and unambiguously as possible.

Description

The level cannot be "measured", per se, only estimated; consequently, it would be misleading to include too many impact levels. Defining four levels is a reasonable compromise.

Specification

A number of impact levels shall be decided upon, and each level shall be defined. Definitions shall refer to the seriousness of the consequences.

Definitions referring to anything other than the seriousness of the consequences would be inappropriate for directly managing risks.


Comments and explanations are desirable to facilitate decisions regarding the seriousness that may be reached.

MEHARI is compliant with this specification and includes the additional comments.

Appendix D contains definitions of the standard four-level scale proposed by MEHARI 2010.

The likelihood scale

The likelihood scale is designed to organize the probability levels into a hierarchy.

Rationale

As risk likelihood is a key factor in estimating risks, it is essential that this scale be defined as clearly and unambiguously as possible.

Description

Likelihood cannot be "measured", per se, only estimated; consequently, it would be misleading to include too many likelihood levels. Defining four levels is reasonable in this case as well.

Specification

A number of likelihood levels shall be decided upon, and each level shall be defined. Definitions shall refer to the likelihood of the risks.

Definitions referring to anything other than risk likelihood would be inappropriate for directly managing risks.

Comments and explanations are desirable to facilitate decisions regarding the likelihood that may be reached.

MEHARI is compliant with this specification and includes the additional comments.

Appendix D contains definitions of the standard four-level scale proposed by MEHARI 2010.

Defining effectiveness scales for the different risk reduction factors

Each risk reduction factor may be evaluated according to an effectiveness scale that must be defined in advance.

As for the impact and likelihood scales, defining four levels is a good compromise between excessive and insufficient precision. The most important point is that each level be defined such that it is easy to choose between one level and another.

The standard scales proposed by MEHARI 2010 are provided in Appendices E1 and E2.

Specification

For each risk reduction factor, different levels shall be defined for the effectiveness of the corresponding measures: dissuasive measures, preventive measures, confinement measures and palliative measures.


4.3.2.2 Estimating risks

Estimating risks, which relies on references defined in advanced as described above, includes evaluating the following for each risk:

− Intrinsic impact and intrinsic likelihood,

− Risk reduction factors,


− Impact and likelihood, taking into account the existence and value of these reduction factors.

Evaluating intrinsic impact and intrinsic likelihood

These characteristics should both be evaluated based on the definitions of the different levels, disregarding all security measures, as specified above.

For MEHARI, the corresponding processes are described in detail in the stakes analysis guide and the risk analysis and treatment guide.

Evaluating risk reduction factors

Each risk reduction factor should be evaluated using the following process:

− Look for security measures (or services) relevant to each risk scenario,

− Determine the effects (dissuasive, preventive, confinement, palliative) resulting from each security measure or service,

− Determine the level for each effect and each measure using the scales previously defined,

− For each effect, determine the maximum level for all measures selected as relevant to this risk,

− These maximum levels are what determine the level of each risk reduction factor (for the risk analyzed).

For this process, it is highly recommended, if not necessary, to use a risk knowledge base such as the one mentioned in section 4.3.1.5. Arguments supporting the use of such a knowledge base include:

− Identifying relevant security measures capable of reducing the number of risk reduction factors must take into account a precautionary principle: only those measures that are guaranteed to have an effect should be taken into account. To this end, obtaining assistance from the experts that developed a knowledge base of security measures and associated audit questionnaires would be useful,

− The way in which multiple security measures may be combined, complement each other or depend on each other is a question for experts, who are not necessarily on hand during the evaluation of risk reduction factors,

− Taking into account the quality of the security measures (or the contextual vulnerability levels) requires questionnaires capable of evaluating these levels, the creation of which is not part of an evaluation process,

− The relationship between the levels of the security measures and of the risk reduction factors is also a question for the experts.

To take into account all of these aspects, MEHARI makes use of a knowledge base that includes a section on "security services", questionnaires for evaluating the quality of these services, and formulas that can be used to evaluate the risk reduction factors based on results from a contextual vulnerability audit of the security services.

As such, using the MEHARI knowledge base after assessing the quality of the security services makes it possible to evaluate the level of the risk reduction factors for each risk scenario presented in the knowledge base.

Evaluating the residual impact and likelihood of risks


Evaluating residual risk impact and residual risk likelihood is based on evaluations of the intrinsic impact, intrinsic likelihood and risk reduction factors.

Evaluating likelihood

This evaluation determines the likelihood of a risk given the risk scenario factors, and basically asks one question:

Given the intrinsic likelihood (or natural exposure to the risk), the effectiveness of dissuasive measures (for a human action) and the effectiveness of preventive measures, what is the actual likelihood of this risk?

This evaluation comes down to simply deciding, but it is recommended that the decision tables (that should have been created during the strategic phase, with the four-level scales) be used so that the corresponding assessments may be reproduced.

Such tables should be based on the type of scenario: accident, error or voluntary human action.

The standard decision tables proposed by MEHARI 2010 are available in Appendix F1. This appendix indicates the likelihood for different types of scenarios and for each level of natural exposure (EXPO), based on the effectiveness of dissuasive (DISS) and preventive (PREV) measures.

Evaluating impact

This evaluation determines the impact of a risk given the risk scenario factors, and basically asks one question:

Given the intrinsic impact, the effectiveness of confinement measures (for scenarios that can be confined) and the effectiveness of palliative measures, what is the actual impact of this risk?

This evaluation comes down to simply deciding, but it is recommended that the decision tables (that should have been created during the strategic phase, with the four-level scales) be used so that the corresponding assessments may be reproduced.

In this case, such tables should be based on the type of scenario: affecting availability, confidentiality or integrity. They may need to include a special case for scenarios where the impact can be limited but palliative measures are not possible.

The standard decision tables proposed by MEHARI 2010 are available in Appendix F2. This appendix indicates the impact for different types of scenarios and for each level of intrinsic impact (II), based on the effectiveness of confinement (CONF) and palliative measures (PALL).

4.3.2.3 Global assessment for each risk (managed)

Risks are assessed based on evaluations of their likelihood and of their impact.

Risks shall be evaluated according to these two parameters, using the procedures described below.


4.3.3 Summary of risk scenario assessment Each risk scenario is assessed in multiple stages, each of which contributes to independently evaluating the likelihood and the impact of each risk scenario, as illustrated in the diagram below.

Analysis of consequences of the damage to the concerned asset

(primary and secondary)Intrinsic Impact

Analysis of all the parameters of the threat

(event, actor, conditions) Intrinsic likelihood

Analysis of dissuasive and preventive effects resulting from

actual security measures

likelihood reduction factors

Residual

likelihood

Analysis of confinement and palliative effects resulting from

actual security measures

Impact reduction factors

Residual

impact

Estimated risk

4.4 Evaluating risks

The seriousness of each risk scenario or situation is a function of its residual likelihood and impact.

That said, it is not a simple mathematical calculation based on these two values, but rather a judgment on the acceptability (or unacceptability) of the situation.

Based on the likelihood and impact of the risk analyzed, the only question that needs to be asked is:

Is this risk situation acceptable as it stands or, if not, what should be done?

The decision to accept a risk or deem it unacceptable should be made using a process that ensures reliability of the decision.

To this end, developing a decision table that will guarantee consistency across decisions made at different times or by different people is essential.

These decision tables can be represented using a "risk acceptability" table that indicates, according to the estimated impact and likelihood, whether the risk is acceptable or not.

As an example, three categories of risk can be defined:

− Intolerable risks, which require emergency measures outside of normal budget cycles,

− Inadmissible risks, which must be reduced or eliminated at some point in time. This should be integrated into a planning cycle (security plan),




Risk assessment


− Accepted risks.

The first two categories correspond to what had previously been called unacceptable risks.

The standard risk acceptability table from MEHARI 2010 is provided below. In this example, S is the global seriousness evaluated as a function of the impact (I) and likelihood (L). Level 4 corresponds to an intolerable risk, level 3 to an inadmissible risk and the lower levels to acceptable risks.

I = 4 S = 2 S = 3 S = 4 S = 4

I = 3 S = 2 S = 3 S = 3 S = 4

I = 2 S = 1 S = 2 S = 2 S = 3

I = 1 S = 1 S = 1 S = 1 S = 2

L = 1 L = 2 L = 3 L = 4

Risk acceptability table


5. Risk treatment

Different options are available for treating risks once they have been identified, listed and evaluated, which is to say once each risk has been deemed acceptable or not.

These options are not described in detail here, the goal being instead to highlight what each option may require in terms of management methodologies for information risks, in order to specify what each of these methodologies must contain to be able to directly and individually manage risks.

This section will look at the four main options available for treating risks, which are described in the ISO/IEC 27005 standard and represented in the diagram below. These options are:

− Retaining the risk,

− Reducing the risk,

− Transferring the risk,

− Avoiding the risk.

5.1 Retaining the risk

Retaining a risk means accepting the risk situation described by the risk scenario, as explained earlier in this document.

It would be more correct and more general to say that it means the company or organization accepts to not do anything to change the situation.

This option may be chosen for two reasons:

− It covers all cases where the risk was evaluated as acceptable in terms of the risk acceptability table because its combined impact/likelihood was deemed acceptable,

− It also covers the case where, though theoretically unacceptable, it was deemed impossible to attenuate the risk with a different solution or all other solutions were rejected for economic reasons.

In all cases, and especially the second, there must be a consensus to accept the risk, and acceptance must be communicated.

However, this communication does not require anything more than a detailed description of the risk situation, which is already provided by the specifications described in the preceding chapters.

Consequently, there are no additional requirements for accepting a risk except, most likely, setting up monitoring indicators to ensure that any conditions for accepting this risk remain valid over time.

Retention Reduction Transfer Avoidance

Risk Treatment


5.2 Reducing the risk

Reducing a risk means reducing one of the two characteristic parameters of that risk, likelihood or impact, or both simultaneously using specific actions. Such actions are determined for each risk identified as unacceptable.

These actions basically aim to improve certain risk reduction factors by implementing suitable security measures.

Directly choosing concrete solutions would be inappropriate for the risk-reduction decision-making process because it would make the relevance of the solution dependent on technological evolution. At this point, then, it is important to specify a functional need with regard to both the targeted purposes and the desired level of performance. This leads to the idea of "security services", which is a fundamental concept in risk treatment. The security services, as used by MEHARI, are defined in Appendix G1.

5.2.1 Choosing which security services to implement to increase certain risk reduction factors

5.2.1.1 Security services relevant or adapted to a given risk

The first step in the decision-making process used in relation to reducing risks is choosing the security services suitable for both the risk scenario in question and the risk reduction factor that is to be improved.

To do this, decision-makers have to be able to rely on a knowledge base of security services that should include at least:

− A list of the security services,

− The purpose (or objectives) of each service,

− The technical and organizational mechanisms that may be envisaged for implementing the service.

Specification

A risk management methodology shall propose a knowledge base of security services defined both functionally and in terms of the results expected from each service.


The list of security services for MEHARI 2010 is provided in Appendix G2.

Given that this knowledge base exists, decision-makers simply have to choose the risk reduction factors and relevant services to meet this requirement.

The corresponding process is not unique, and there may be several different ways to present the main strategic options. This document is not intended to specify a specific process for choosing.

5.2.1.2 Choosing the target quality level for the security service to be implemented

There is no doubt, however, that the degree to which the risk reduction factors in question are improved is highly dependent on the performance of the security services selected, which means it is necessary to define the quality level of the security services.

The best way to do this is to define a quality scale, similar to the scales established for the different risk parameters.


Specification

A number of quality levels shall be decided upon, and each level shall be defined. These definitions shall reflect the level of force or competency required to breach, bypass or short-circuit the service, and/or to inhibit or render useless detection of service neutralization.


The MEHARI 2010 scale of security service quality levels is provided in Appendix G3.

5.2.1.3 Evaluating the combined effect of multiple security services

Evaluating the combined effect of multiple security services, whether anticipated or already existent, remains an important step in choosing which services to implement for risk management.

This requires the provision of aids, which is the goal of a risk knowledge base such as the one discussed in sections 4.2.2.3, 4.3.1.5 and 4.3.2.2.

Specification

A knowledge base of risks and their characteristic elements, security services, security service quality evaluation questionnaires, and aids for evaluating risk reduction factors based on the quality of security services shall be included in the risk analysis and treatment methodology.

If such a knowledge base is not provided, or is not applicable in a given context, the methodology shall provide all the elements and guides required to establish such a knowledge base.

MEHARI contains a knowledge base adapted to information systems. A guide for developing knowledge bases is in progress.

5.2.1.4 Decision-making process for reducing risks

The decision-making process for reducing risks involves:

− Selecting suitable security services,

− Selecting a target level for these services,

− Deducing new values for the risk reduction factors,

− Verifying that these new values reduce the risk to an acceptable level of seriousness.

5.2.2 Using structural measures Certain measures, called "structural" measures for the purposes of this document, can influence the intrinsic likelihood or the intrinsic impact of a risk.

These measures "structurally" change certain aspects of the company’s context or of its relationship to its surroundings. Two examples can help illustrate this idea:

A given company may be exposed to environmental risks such as floods or earthquakes. It may reduce these risks by implementing suitable security measures, or it may simply decide to move. This would constitute a "structural" measure because it can "structurally" change the nature or level of the risk.

A bank may be exposed to the risk of a hold-up. It can limit this risk with suitable security services, but it may also use the structural measure of limiting the amount of cash available.


5.3 Transferring the risk

Transferring a risk means, in practical terms, looking at the risk from a financial standpoint and transferring part of the financial burden incurred, should the risk materialize, to a third party.

In most cases, this means obtaining insurance, but it can also mean transferring the burden to a third party (the one responsible) through legal proceedings.

This decision, while not calling on the same evaluation mechanisms, still requires that specific security measures be implemented (especially in terms of collecting evidence). All that precedes this section still applies, and there are no additional requirements.

5.4 Avoiding the risk

Avoiding a risk is similar to reducing a risk through structural measures.

The difference lies in the fact that, rather than changing the relationship between a company or organization and its surroundings, internal processes are changed so that the risk no longer exists at all.

This is best illustrated through an example.

A given company may be exposed to the serious risk of information disclosure when developing its strategic plan containing a lot of information that, taken together, is extremely sensitive. One solution consists in not developing this sort of strategic plan: this is a risk-avoidance solution.

In general, risk avoidance plays on the detailed-description parameters of the risk scenario by changing these parameters.

Logically, then, this solution is not really possible unless scenarios describe the risks in minute detail, as specified earlier in this document.

Consequently, detailed characterization of the scenarios, as previously specified, is sufficient to make avoiding the risk a viable option.


6. Risk management

Managing risks involves all the processes that facilitate implementing the decisions previously made regarding the treatment of risks, monitoring the effect of these decisions, and improving them if necessary.

In light of the purpose of this document, the question here becomes whether these processes call for any specific requirements that must be detailed to guarantee effective management of information risks.

This section analyzes the requirements of each phase of the overall process illustrated in the diagram first presented at the beginning of this document and recalled below.

6.1 Developing action plans

After analyzing the risks and making decisions on how to treat these risks, the company or organization decided to go ahead with a certain number of actions that, according to the type of treatment chosen, are based on:

− Implementing security services, each with a quality level objective,

− Structural measures designed to reduce the exposure to certain risks,

− Organizational measures designed to avoid certain risks.

That said, it should be obvious that not all of these actions will be carried out simultaneously, nor will they all be implemented immediately, for various reasons such as limited budgets or lack of available human resources.

As such, action plans should be developed according to the following steps:

− Choose priority objectives in terms of security services to implement, and optimize this choice,

− Transform the choice(s) of security services into concrete action plans,

− Choose potential structural measures and risk avoidance measures,

− Validate the preceding decisions.

6.1.1 Choosing priority objectives and optimization If it is impossible to deploy all actions simultaneously, due to economic reasons, lack of available resources or any other reason, a choice must be made as to which measures should be implemented first.

To establish the order of priority for these actions, certain factors should be taken into account:

− The seriousness of the risks that the priority measures are designed to reduce (more serious risks should be treated first),

Actionplans

Implementation Monitoring and steering

Risk management


− The number of risks that will be treated, and the number of risks that will have to be treated at a later date,

− The speed with which the first results will be observed,

− The effects of these choices on personnel awareness,

− Etc.

Depending on the importance attributed to the different criteria, optimization tools may prove useful.

MEHARI 2010 proposes an optimization algorithm for prioritizing the measures.

6.1.2 Choosing solutions: organizational and technical mechanisms Choosing concrete solutions to deploy, whether they are based on organizational or technical mechanisms, is the responsibility of specialized teams such as the IT department, network managers, physical security managers and CISOs.

Nevertheless, the fact remains that transferring responsibilities between the risk management managers who selected the security services to implement at a certain quality level and the managers in charge of defining and deploying the mechanisms is highly dependent on the degree of precision with which the security services were defined.

A security services reference manual should be developed for these definitions.

The security services reference manual

A security services reference manual should describe, for each security service:

− The purpose of the service,

− The results expected from implementing the service,

− A description of the mechanisms associated with the service, including both organizational and technical aspects,

− The elements that can be used to evaluate the quality of the service according to the three assessment criteria: efficiency, robustness and permanence over time.

Rationale

The security services reference manual guarantees consistency and agreement between the functionalities expected by the risk managers, on which their objective risk reduction factor estimates are based, and the functionalities that will actually be deployed.

Specification

The mechanisms to deploy to implement the security services selected and specified by the risk managers shall be chosen using a security services reference manual such as the one described above.

MEHARI is compliant with this specification, and includes a security services reference manual in its methodology documentation.

6.1.3 Choosing structural measures and risk avoidance measures These choices essentially based on the specific details of situations or operating processes, do not entail any particular requirements in terms of risk management methodologies, and have no direct impact on MEHARI knowledge bases or principles.


6.1.4 Approval and decision-making The different choices described above must be quantified and integrated into a planning cycle before being presented to the decision-makers for approval. This step is not specific to direct management of risks, and does not entail any particular requirements in terms of the risk management methodology.

6.2 Implementing action plans

Implementing the action plans may pose application challenges in specific contexts.

In this case, it is important to be able to refer to the risks that each action plan was supposed to reduce in order to determine the best response.

Specification

The risks addressed by an action plan shall be referenced in that action plan to facilitate the best response in the event of problem.

Aside from this precaution, implementing the action plans does not give rise to any particular requirements with regard to the risk management methodology.

6.3 Monitoring and steering direct management of risks

Numerous verifications must be carried out to steer the direct management of risks, as illustrated in the diagram below.

The first level of monitoring involves verifying that the security solutions and mechanisms planned and selected do indeed correspond to the service quality levels chosen during the risk treatment phase.

The second verification is related to implementation compliance.

6.3.1 Service quality verification More often than not, this should be self-imposed. This raises the question of knowing how technical personnel responsible for defining the mechanisms and solutions to implement will be able to do so with sufficient knowledge as to the impact their decisions will have on the service quality level ultimately obtained.

Risk treatmentSecurity services to be

implemented andquality level objectives

Choice ofmechanisms and

solutions

Quality level check : solutions vs objectives

Solutions implementation

Implementation anddeployment check


Furthermore, post-control testing will be necessary, and will have to be performed by personnel who are not necessarily senior, experienced technicians.

Consequently, it is necessary to have a knowledge base of expertise or security services audit knowledge base that will facilitate making suitable choices when defining the mechanisms and solutions to implement, as well as post-control testing.

Why a security services audit knowledge base is needed (Rationale)

As we have seen, there are three facets to security service quality: efficiency, robustness and how the services are operationally monitored.

To verify each of these aspects, specific questions must be asked.

As such, it is essential to have a guideline and an inventory of questions to ask, as well as an associated system for scoring the answers to these questions, so that the quality of each security service can be evaluated in a reliable and consistent way.

Specification

The definition and verification of security service quality shall rely on a knowledge base of questionnaires for each security service and on an associated weighting system.

MEHARI 2010 includes a knowledge base of questionnaires and a weighting system described in the "Evaluation Guide for security services".

6.3.2 Verifying implementation of the security services For obvious reasons, it is crucial to verify the actual implementation of the security services previously defined.

Often, security services are only partially deployed, or implemented in a way that does not completely comply with decisions previously made.

In terms of risk management, the response(s) to such situations must be defined.

Specification

How to respond to and report on incomplete deployment of security services, as well as how to incorporate this into the risk management system, shall be specified.

6.3.3 Overall steering for direct management of risks Overall steering of the direct management of risks is similar to all project steering, and includes:

− Indicators and a scoreboard,

− A reporting system,

− A system for periodic reviews and decision-making regarding necessary corrective actions.


Appendix A1 MEHARI 2010 knowledge base classification of primary assets


Appendix A2 Mehari 2010 knowledge base classification of supporting assets

The following table presents the list of MEHARI 2010 knowledge base supporting (or secondary) asset types by category of primary asset.

SECONDARY ASSET TYPES

Asset category: Services

Service support hardware equipment

Software configurations

Software support media

Accounts and means necessary to access the service

Security services associated with the service

Ancillary means necessary for the service

Premises

Personnel and service providers necessary for the service (internal and external)

Asset category: Data

Logical entities: files or databases

Logical entities: transiting data packets or messages

Physical entities: media and devices

Means for accessing data: keys and other means, physical or logical, required to access the data

Asset category: Management processes

Internal guidelines and procedures (organizational tools)

Physical resources necessary for management processes

Personnel and service providers necessary for management processes


Appendix B MEHARI 2010 knowledge base classification of intrinsic vulnerabilities

List of intrinsic vulnerabilities

Type of supporting asset

Type of damage

Type of vulnerability Criteria

AICE

Category: Service

Destruction Possibility of destruction of equipment A

Failure Possibility of failure of equipment A

Hardware (Equipment)

Not operable Possibility of non operable equipment A

Alteration Possibility of alteration of software configurations (software and parameters) A and I

Failure Possibility of software failure (bug) A

Erasure Possibility of erasure of software configurations A

Unauthorized use

Possibility of denial to use (due to lack of license) I

Pollution Possibility of pollution of software configurations I

Software Configuration

Disclosure of software

Possibility of disclosure of a software file A

Destruction Possibility of destruction of media containing software A

Not operable Possibility of non operable media containing software A

Loss Possibility of loss of media containing software A

Media containing software

Exchange Possibility of loss of media containing software I

Lock Possibility of user accounts to be blocked A

Account or means to access the service

Loss Possibility of loss of capability to connect to the service

A

Auxiliary means or facility equipments Unavailability

Possibility of unavailability of auxiliary means or Possibility of unavailability of facility equipments I

Premises Unavailability Possibility of premises to be not accessible A

Category: data

File containing data Erasure Possibility of erasure of data files A


Pollution Possibility of pollution (slow evolution) of data in a file A

Alteration Possibility of alteration of files containing data I

Disclosure Possibility of duplication or diffusion (and disclosure) of a file containing data

C

Destruction Possibility of destruction of media containing data A

Unavailability Possibility of unavailability of media containing data A

Loss Possibility of loss of media containing data A and C

Duplication Possibility of duplication and disclosure of media containing data

A and C

Media containing data

Exchange Possibility of exchange of media containing data A and C

Loss Possibility of loss of data in transit or messages A and C

Disclosure Possibility of duplication and disclosure of data in transit, messages, screens

C

Data in transit, messages, screens

Alteration Possibility of alteration of data in transit or messages I

Means to access data Loss Possibility of loss of means allowing to access data (physical or logical keys)

A

Category: management process

Procedures and

instructions Inefficiency Possibility that procedures observed be inefficient

(towards laws, regulations or contractual commitments)

E


Appendix C1 MEHARI 2010 knowledge base classification of events


Appendix C2 MEHARI 2010 knowledge base classification of actors

Table of actors

Category Typology authorized user legitimately

Member of personnel, user of IT system authorized user illegitimately

member of operations personnel member of development team Personnel with specific

rights member of maintenance personnel

member of service personnel (upkeep, general services, security, etc.)

Personnel authorized within the establishment

member of personnel (internal or not) (permanent or not)

Visitor

third party not authorized Personnel not authorized within the establishment Vandal or terrorist


Appendix D MEHARI 2010 standard scales for impact and likelihood levels

Scale of impact

Level 4: Vital

At this level, the impact is very serious, and even the existence and survival of the entity (or at least one of its main activities) is in danger.

Should the organization survive such a malfunction, there would be serious and durable consequences.

Level 3: Very Serious

The impact is considered very serious at the level of the entity, although its future would not be at risk.

In financial terms, this would have a seriously negative impact on the profits for the period, although there would not be a massive pull-out by shareholders.

In terms of public image, this level of malfunction often damages the organization’s reputation to such an extent that it would take several months to restore it, even if the financial impact cannot be precisely evaluated.

Accidents that lead to months of organizational disorder for an enterprise would also be evaluated at this level.

Level 2: Serious

Malfunctions at this level would have a clear impact on the entity’s operations, results or image, but are globally manageable.

Level 1: Not significant

At this level, any resulting damage would have no significant impact on the results or image of the entity, even if some staff members were deeply involved in re-establishing the original status


Scale of likelihood

Level 4: Very likely

At this level, it is wise to consider that the scenario is likely to happen almost certainly and probably in the short term. When the risk occurs, nobody shall be surprised.

Level 3: Likely

This corresponds to scenarios that are bound to happen in the more or less short term. One may still hope they will not happen but it is rather optimistic.

The environment and context of the enterprise are such that, if nothing is done to avoid it, the given scenario is bound to happen in the more or less short term.

Level 2: Unlikely

It is reasonable to think that these scenarios should not occur.

The past experience shows that they have not occurred.

However they are to be listed as not unrealistic.

Level 1: Very unlikely

At this level, the potentiality of the risk appears to be very low.

But these scenarios are not strictly impossible as there is always a tiny probability of occurrence


Appendix E1 MEHARI 2010 standard scales for likelihood reduction factors

Efficiency of dissuasion measures

Level 4: The effect of dissuasive measures is very high.

The potential attacker can logically consider that he or she should abandon any idea of performing the action. They should realize that they will certainly be identified, and that the resulting punishment will well outweigh any potential gain.

Level 3: The effect of dissuasive measures is high.

The potential attacker can logically consider that he or she runs a high risk. They should realize that they will undoubtedly be identified, and that punishment will be serious.

Level 2: The effect of dissuasive measures is medium.

The potential attacker can logically consider that he or she runs only a small risk. In any case, any potential personal prejudice will be supportable.

Level 1: The effect of dissuasive measures is low or nil.

The potential attacker can logically consider that he or she runs no personal risk. They can consider that they will not be identified, or will have the possibility of using strong arguments to refute any accusations concerning actions performed, or that any punishment will be very light.

Efficiency of prevention measures.

Level 4: The effect of the preventive measures is very high.

Only a few determined experts, with exceptional means, could succeed. Only the conjunction of very rare or extremely exceptional circumstances would permit this scenario to happen.

Level 3: The effect of the preventive measures is high.

Only a specialist, or a professional with special tools or means, or a group of professionals in collusion and using their collective means and tools could succeed. This is usually the result of the conjunction of rare or exceptional circumstances.

Level 2: The effect of the preventive measures is medium.

A professional can set off the scenario, without the need for special means or tools outside of those available in the profession. Rare natural circumstances can produce the same result.

Level 1: The effect of the preventive measures is low or nil.

Any person in the organization, or close to it, or even someone, who knows something about it, is capable of setting this scenario in motion, with the means at their disposal (or easy to obtain). Perfectly ordinary circumstances can be the cause of this scenario (misuse, error, ordinary unfavorable conditions).


Appendix E2 MEHARI 2010 standard scales for impact reduction factors

Efficiency of the protective or confinement measures Level 4: The measures have a very strong effect. Direct consequences will be very limited. The residual impact will be low or even not significant.

Level 3: The confinement measures have an important effect to limiting the direct consequences.

The limits imposed to the scenario will decrease the consequences and the event will be rapidly detected, with immediate reaction. The protective measures that are used will have a real influence on the direct impact, which remains limited in scope, and manageable.

Level 2: The effect of the confinement and the limitation of the direct consequences is medium.

The damage may be feebly limited in its direct consequences if it is detected, but the time to detect and react will be long. The protective measures that are used have a real influence on the result, but the direct consequences are still very big.

Level 1: The effects of the confinement and the limitation of the direct consequences are very low or nil.

Either the damage and its direct consequences cannot be limited, because of the delay of detection or it will not be detected for some time. The measures will only have a very restricted influence on the level of the direct consequences.

Efficiency of the Palliative measures Level 4: The effects of the limitation of the indirect consequences are very high indeed.

Normal operations continue without any noticeable interruption.

Level 3: The effects of the limitation of the indirect consequences are high.

The palliative measures have not only been finely planned and organized, but also tested and validated. The time to re-establish normal operations can be precisely estimated or known, and is such that it will measurably reduce the gravity seriousness of the indirect consequences of the scenario.

Level 2: The effects of the limitation of the indirect consequences are medium.

The relief or palliative solutions have been broadly planned, but the fine detail is missing. It can be considered that, due to the lack of detail, there will be a corresponding lack of efficiency of the palliative measures. The time to re-establish normal operations cannot be precisely predicted, or will not fundamentally change the nature of the damage caused.

Level 1: The effects of the limitation of the indirect consequences are very low or nil.

Either totally improvised measures are used, or it is considered that their effect will be low.


Appendix F1 MEHARI 2010 standard decision grids

Grids of evaluation of STATUS-P

1. Scenarios resulting from an Accident

D D D D

I I I I

S S S S

S 1 1 1 1 1 S 1 2 2 2 1 S 1 3 3 2 1 S 1 4 4 2 1

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

P R E V P R E V P R E V P R E V

2. Scenarios resulting from an Error

D D D D

I I I I

S S S S

S 1 1 1 1 1 S 1 2 2 2 1 S 1 3 3 2 1 S 1 4 4 2 1

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4


3. Scenarios resulting from a Voluntary action

D 4 1 1 1 1 D 4 1 1 1 1 D 4 2 2 1 1 D 4 2 2 2 1

I 3 1 1 1 1 I 3 2 2 1 1 I 3 2 2 1 1 I 3 3 3 2 2

S 2 1 1 1 1 S 2 2 2 2 1 S 2 3 3 2 1 S 2 4 4 3 2

S 1 1 1 1 1 S 1 2 2 2 1 S 1 3 3 2 1 S 1 4 4 3 2

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4


E X P O = 1 E X P O = 2 E X P O = 3 E X P O = 4




Appendix F2 MEHARI 2010 standard decision grids

Grids of of evaluation of STATUS-IThe non evolutionary scenarios are represented on the nc line

1. Scenarios affecting Availability

C 4 1 1 1 1 C 4 2 2 1 1 C 4 2 2 1 1 C 4 2 2 2 1

O 3 1 1 1 1 O 3 2 2 1 1 O 3 3 2 2 1 O 3 3 3 2 1

N 2 1 1 1 1 N 2 2 2 2 1 N 2 3 3 2 1 N 2 4 3 2 1

F 1 1 1 1 1 F 1 2 2 2 1 F 1 3 3 2 1 F 1 4 3 2 1

nc 1 1 1 1 nc 2 2 2 1 nc 3 3 2 1 nc 4 3 2 1

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

P A L L P A L L P A L L P A L L

2. Scenarios affecting Integrity

C 4 1 1 1 1 C 4 1 1 1 1 C 4 1 1 1 1 C 4 1 1 1 1

O 3 1 1 1 1 O 3 2 2 1 1 O 3 2 2 1 1 O 3 2 2 2 1

N 2 1 1 1 1 N 2 2 2 2 1 N 2 3 3 2 1 N 2 3 3 2 1

F 1 1 1 1 1 F 1 2 2 2 1 F 1 3 3 2 1 F 1 4 3 2 1

nc 1 1 1 1 nc 2 2 2 2 nc 3 3 2 2 nc 4 4 4 4

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4


3. Scenarios affecting Confidentiality

C 4 1 C 4 2 C 4 2 C 4 2

O 3 1 O 3 2 O 3 2 O 3 2

N 2 1 N 2 2 N 2 3 N 2 3

F 1 1 F 1 2 F 1 3 F 1 4

nc 1 nc 2 nc 3 nc 4

1 1 1 1


4. Type L (limitable) scenarios

C 4 1 C 4 1 C 4 1 C 4 1

O 3 1 O 3 2 O 3 2 O 3 2

N 2 1 N 2 2 N 2 3 N 2 3

F 1 1 F 1 2 F 1 3 F 1 4

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4


II = 1 II = 2 II = 3 II = 4

II = 1 II = 2 II = 3 II = 4

II = 1 II = 2 II = 3 II = 4

II = 1 II = 2 II = 3 II = 4


Appendix G1 Specification of the security services

Definitions

Security services A security service is an answer to a security need, expressed in general and functional terms, which describes the purpose of the service, usually in reference to certain types of threats.

A security service ensures a security function.

This function is independent from the actual mechanisms and solutions used to effectively provide the service.

Example: the “Access control” service, the purpose or function of which, as the name implies, is to control access; in other words, only let authorized people ‘in’.

Security services and sub-services The function of a security service can itself require several components, which can be considered ‘sub-services’. In the example above, access control requires knowledge of who is authorized, which implies an authorization function, the recognition of a person, which in turn implies an authentication function, and access filtering, which then implies a third filtering function.

A security service can itself be made up of several other security services to meet a specific need or purpose. Each component is a security sub-service of the service in question, although with respect to an individual function, it retains the characteristics of a service as defined above.

Security mechanisms and solutions A “mechanism” is a particular mean to ensure, totally or partially, a function for a service or sub-service. It may consist of a specific procedure, algorithm, technology, etc.

For the user authentication sub-service (e.g. to an operating system) above mentioned, possible mechanisms might be passwords, tokens, smart cards, biometric systems, etc.

For a given sub-service, several mechanisms are generally possible; whose selection has often a direct consequence on the quality that the sub-service will attain.

A security solution is the concrete realization of a security mechanism and may be composed of hardware, software, procedures and operational support, together with the necessary organizational structures required.

Security services typology Some services may be considered as “general measures” and others as technical services:

— General measures are definitely useful, even mandatory, for information systems security, though their benefit is more effective at the level of the organization, the management of security or awareness rather than on risk situations themselves.

— Technical measures have a clear role, a direct purpose and a direct effect on several risk situations that may be specified.


Criteria for evaluating security service quality Security services may vary in performance. They will be more or less efficient in their function, and more or less robust in their ability to resist direct attacks, depending on the mechanisms used and organizational aspects.

Mandatory parameters To measure security service performance, a number of parameters must be taken into account:

— Efficiency,

— Robustness, — Permanence.

Security service efficiency For services of a technical nature, efficiency is a measure of their ability to effectively ensure the required function faced with more or less competent personnel or more or less usual circumstances.

Let us take, as an example, the sub-service “Information system access authorization management”, which involves the attribution of users’ access rights. The function of this service is to ensure that only those people who have their management’s authorization actually get the appropriate information system access. In practice, the efficiency of the service depends on the strictness of the controls on the authenticity of the request, and on the correlation of the hierarchical relationship between the requestor and the new user. If all that is required is a simple mail, without any signature or certificate, anybody who knows a little about the authorization process would be able to unduly allocate themselves access rights, and the quality of the sub-service would be considered poor.

The efficiency of a service that manages human actions is thereby the measure of the competence required to let someone pass through the checks in place, or even to abuse them.

For those services that treat natural events (such as fire detection, fire extinction.), the efficiency is a measure of the “strength” of the event for which their intervention remains effective.

If this concerns, for example, a dam that is intended to prevent a river from overflowing due to heavy rains, the efficiency is directly linked to the height of the water (the flood’s strength) which it resists to. In practice, the strength will often be measured as a function of the exceptional character of the event.

Services providing general coverage cannot, in principle, be evaluated on the basis of their direct effect, but only on their indirect role.

The efficiency of general measures is the result of their ability to create action plans or significant behavioral changes.

How robust is a security service? The robustness of a security service measures its ability to resist an action that is intended to short-circuit the service, or to restrict its efficiency.

Robustness only concerns those services that are considered technical.

In the preceding example (access management), the robustness of the sub-service depends – in particular – on how easy it is to directly access the user access rights table, and thereby allow


someone to attribute themselves access rights without need to follow the normal control processes.

When we are dealing with services for managing accidents or natural events (such as fire detection, automatic fire extinction, and so on), their robustness will also cover their ability to avoid being short-circuited or bypassed (whether accidentally, or on purpose).

Permanence The global quality of a security service requires that the service be guaranteed over time.

For this, any service interruption must be detected and palliative measures applied. Everything depends, therefore, on the speed of detection and the capacity to react.

For general measures, surveillance of the solutions themselves is important to show that they can be really measured, in terms of implementation and effectiveness, but also that there are effective quality of service indicators and control points in place.

Security service quality evaluation using Mehari questionnaires Mehari methodology is containing a set of elements, the method itself and knowledge bases among others. One of the knowledge bases allows auditing security services.

The quality evaluation system comprises a set of questions for which a yes/no answer is required, with an associated scoring and weighting system that we shall examine later in this document.

The questionnaires comprise questions of different kinds. These may be questions oriented towards the efficiency of security measures (e.g.: backup frequency, type of physical access control: card reader, digital code, etc., existence of fire detectors, etc.), questions oriented towards the robustness of security measures (e.g.: where backups are stored, and how access is protected, whether there is a double door, and how well built the doors are, how the fire detection system is protected, etc.). Generally, there are also one or two questions on the monitoring, control and audit of the functions expected of the service.

Types of questionnaires Mehari knowledge bases are composed of several questionnaires, associated to technical domains corresponding to different operational managers;

The weighting system Questions concerning a security service depend on the useful or necessary security measures of that service. However, not all measures have the same role to play, and a distinction must be made between contributive measures, major or sufficient measures, and essential measures.

Contributive measures Certain questions have to do with measures that have a certain role in contributing to the quality of service, without their full implementation being necessarily required.

In quantitative terms, a classic weighting applied to these measures reflects this idea of contribution. In this case, certain measures – more important than others – would have a different weighting. The MEHARI knowledge base shows the weighting applied to each question.

The table below enhances the earlier example. In it, V12 column is reserved for the answers to the questions (1 for yes, 0 for no); the next column shows the weighting applied to the responses.

2 At this stage, it is considered that there is only one variant for this domain, as expressed by the value “1” on top of column V1.


Audit Questionnaire: Domain: Security of Systems Ar chitecture (07) A - Control of access to systems and applications A02 Management of access authorizations and privile ges (granting, delegation, revocation) 1

Quest. Nr Question V1 W 07A02-01 Does the procedure of granting access authorization require the formal approval of

line management (at a sufficiently high level)? 0 4

07A02-02 Are authorizations granted to named individuals only as a function of their profile? 1 2 07A02-03 Is the procedure for granting (or changing or revocation) authorization to an individual

(either directly or via his profile) strictly controlled? 1 4

07A02-04 Is there a systematic process of updating the table of authorizations at the time of departure of personnel or at the end of contract for external personnel or change of function?

0 2

07A02-05 Is there a strictly controlled process (as above) which allows to delegate his/her own authorizations, in part or in whole, to a person of choice for a determined period (in case of absence)?

0 4

07A02-06 Is it possible to control at any time, for all users, the rights, authorizations and privileges in force?

1 1

07A02-07 Is there a regular audit, at least once a year, of the profiles and authorizations granted to all users and of the procedures for management of attributed profiles?

0 1

The weighted mean value is simply the sum of the weighted active measures (those whose answer is “1” for “yes”), over the sum of the possible weight, with the result being normalized on a scale of 0 to 4.

So, if V1ii contains the response to question i, Wi is the weighting of i and Mw the weighted mean value:

Mw = 4 * Σ Ri * Wi / Σ Wi

So, for the answers shown in the example questionnaire above, the weighted mean value is:

Mw = 4 * 7/18 = 1,6

And the service quality, Q = Mw = 1,6

Major or “sufficient” measures Some measures could be considered sufficient to ensure a certain level of quality of service. For example, a fire detection system can be considered sufficient in providing level 2 for the corresponding sub-service.

We have therefore added a minimum threshold, which is the minimum service quality score if the measure is active.

The column "Min" shows that if a positive answer is given to a question for which a minimum threshold has been fixed, then that threshold has been reached or surpassed by the sub-service.

Another view of the earlier table is shown below, this time with the “Min” column added.


Audit Questionnaire: Domain: Security of Systems Ar chitecture (07) A - Control of access to systems and applications A02 Management of access authorizations and privile ges (granting, delegation, revocation) 1

Quest. Nr Question V1 W Min 07A02-01 Does the procedure of granting access authorization require the formal approval of line

management (at a sufficiently high level)? 0 4

07A02-02 Are authorizations granted to named individuals only as a function of their profile? 1 2 07A02-03 Is the procedure for granting (or changing or revocation) authorization to an individual (either

directly or via his profile) strictly controlled? 1 4 3


0 2


0 4

07A02-06 Is it possible to control at any time, for all users, the rights, authorizations and privileges in force? 1 1 07A02-07 Is there a regular audit, at least once a year, of the profiles and authorizations granted to all

users and of the procedures for management of attributed profiles? 0 1

In the example, the fact that the process for allocation, modification or removal of rights (question -03) is strictly managed was considered sufficient to increase the quality of service score to the threshold minimum of 3.

Essential measures On the other hand, certain measures may be considered mandatory in ensuring a certain level of quality of service.

MEHARI associates with the questions concerning those measures considered mandatory in ensuring a certain quality level, a quality threshold. If this threshold is to be surpassed, the implementation of the measure is obligatory.

In other words, the threshold shown in the "Max" column is the maximum quality level that the sub-service can obtain if the measure is not implemented.

When there is clash between the minimum and maximum thresholds, it is the max value that takes priority.

With this addition to the previous table we get the following view:

Audit Questionnaire: Domain: Security of Systems Ar chitecture (07) A - Control of access to systems and applications

A02 Management of access authorizations and privile ges (granting, delegation, revocation)

1

Quest. Nr Question V1 W Max Min 07A02-01 Does the procedure of granting access authorization require the formal approval of line

management (at a sufficiently high level)? 0 4 2

07A02-02 Are authorizations granted to named individuals only as a function of their profile? 1 2 07A02-03 Is the procedure for granting (or changing or revocation) authorization to an individual (either

directly or via his profile) strictly controlled? 1 4 2 3


0 2


0 4

07A02-06 Is it possible to control at any time, for all users, the rights, authorizations and privileges in force? 1 1 07A02-07 Is there a regular audit, at least once a year, of the profiles and authorizations granted to all users

and of the procedures for management of attributed profiles? 0 1 2

In the above example, expert opinion says that negative responses to questions 1 and 7 mean that the service quality level cannot be higher than 2. This limit has priority over the level 3 value proposed earlier.


This triple system of quality of service measurement avoids the risk of seeing a series of inefficient measures being given an over-evaluated quality level when the essential measures are not active or, on the contrary, a series of poorly weighted measures under-evaluating the quality of service when an essential measure is implemented. This approach is one of the distinctive features of MEHARI, providing real value based on the expertise of the people who maintain the knowledge bases.

Inapplicable questions Certain questions can be considered inapplicable for some organizations. In this case, entering a “X” in the answer column will make that question not taken into account in the service evaluation process.

Attention must be paid to ensure that an inapplicable question remains so, whatever the planned evolution of the IT system and the security services.


Appendix G2 List of the security services of MEHARI 2010 knowledge base

SECURITY SERVICES & SUB-SERVICES

DOMAINS

SERVICES

SUB-SERVICES

01 Organization of security

01A Roles and structures of security

01A01 Organization and piloting of general security

01A02 Organization and piloting of Information Systems security

01A03 General reporting system and incident management system

01A04 Organization of audits and audit program

01A05 Crisis management related to information security

01B Security Reference Guide

01B01 Obligations and responsibilities of personnel and management

01B02 General directives related to information protection

01B03 Classification of resources

01B04 Asset management

01B05 Protection of assets having value of evidence

01C Human Resource Management

01C01 Staff involvement, contractual clauses

01C02 Management of strategic personnel, partners and providers

01C03 Staff screening procedure

01C04 Awareness and training in security

01C05 Third Parties Management (partners, suppliers, clients, public, etc.)

01C06 People Registration

01D Insurance

01D01 Insurance against property (or material) damages

01D02 Insurance of consequential losses (non-material damages)

01D03 Personal Liability Insurance (PLI)

01D04 Insurance against loss of Key Personnel

01D05 Management of insurance contracts

01E Business continuity

01E01 Taking into account the need for business continuity

01E02 Business continuity Plans

01E03 Workplace Recovery Plans (WRP)

02 Sites security

02A Physical access control to the site and the buildin g

02A01 Management of access rights to the site or building

02A02 Management of access authorizations granted to the site or the building

02A03 Access control to the site or the building


02A04 Intrusion detection to the site or the building

02A05 Access to the loading and unloading areas (goods receipt and consignment) or to areas open to public

02B Protection Against Miscellaneous Environmental Risk s

02B01 Analysis of Miscellaneous Environmental Risks

02C Control of access to office areas

02C01 Partitioning of office areas into protected zones

02C02 Physical access control to the protected office zones

02C03 Management of access authorizations to protected office area

02C04 Detection of intrusions into protected office areas

02C05 Monitoring of protected office areas

02C06 Control of movement of visitors and occasional service providers required to work in the offices

02D Protection of written information

02D01 Conservation and protection of important commonly used documents

02D02 Protection of documents and removable support media

02D03 Paper-bin collection and destruction of documents

02D04 Security of post mail

02D05 Security of faxes (traditional)

02D06 Conservation and protection of important documents (to be preserved during a long period)

02D07 Management of archived documents

03 Security of Premises 03A General Maintenance

03A01 Quality of energy supply

03A02 Continuity of energy supply

03A03 Air conditioning security

03A04 Quality of cabling

03A05 Lightning protection

03A06 Dependability of service equipment

03B Control of access to sensitive locations (excep t office zones)

03B01 Access rights management to sensitive locations

03B02 Management of access authorizations granted to sensitive locations

03B03 Access control to sensitive locations

03B04 Intruder detection in sensitive locations

03B05 Perimeter monitoring (surveillance of entry points and surroundings of sensitive locations)

03B06 Surveillance of sensitive locations

03B07 Cabling access control

03B08 Location of sensible premises.

03C Security against water damage

03C01 Prevention of risk of water damage

03C02 Detection of water damage

03C03 Water evacuation

03D Fire security

03D01 Fire risk prevention

03D02 Fire detection

03D03 Fire extinguishing

04 Extended Network (intersite) 04A Security of the extended network architecture a nd service continuity

04A01 Functional security of the extended network architecture


04A02 Management of extended network equipment maintenance

04A03 Procedures and Business Contingency Planning following incidents on the extended network

04A04 Backup plan of extended network configurations

04A05 Business Contingency Planning (BCP) of the Extended Network

04A06 Management of critical suppliers as regards a permanent maintenance service

04B Control of connections on the extended network

04B01 Security profiles for entities connected to the extended network

04B02 Authentication of the entity for an incoming access from the extended network

04B03 Authentication of the entity accessed for an outgoing access across the extended network

04C Security during data exchanges and communicatio n

04C01 Encryption of exchanges on the extended network

04C02 Integrity control of exchanges on the extended network

04D Control, Detection and Handling of incidents on the extended network

04D01 Real-time monitoring of the extended network

04D02 Offline analysis of traces, log files and event journals on the extended network

04D03 Management of incidents on the extended network

05 Local Area Network (LAN) 05A Security of the architecture of the local area network

05A01 Partitioning of the local area network into security domains

05A02 Security of the functioning of the local area network architecture

05A03 Organization of the maintenance of local area network equipment

05A04 Procedures and Recovery Plans following incidents on the local area network

05A05 Save and Restore plans of local area network configurations

05A06 Save and Restore plans of local area network configurations

05A07 Management of critical suppliers as regards a permanent maintenance service

05B Access control to the local area network

05B01 Management of access profiles on the local area network

05B02 Management of privileges and access authorizations (granting, delegation, revocation)

05B03 User or entity authentication for access requests to the local area network from an internal access point

05B04 User or requestor authentication before access to the local area network from a remote site via the extended network

05B05 User or requestor authentication for outside access to the local area network (e.g. from the switched telephone network (POTS), X25, ISDN, broadband, Internet, etc.)

05B06 User or requestor authentication for access requests to the local area network from a WiFi sub-network

05B07 General filtering of access to the local area network

05B08 Routing control of outgoing access

05B09 Authentication of the external entity accessed for outgoing access to sensitive sites

05C Security of data exchange and communication on the local network

05C01 Encryption of exchanges on the local area network

05C02 Integrity control of exchanges on the local area network

05C03 Encryption of exchanges in the case of remote access to the local area network

05C04 Protection of the integrity of exchanges in the case of remote access to the local area network

05D Control, detection and resolution of incidents on the local network

05D01 Real-time monitoring of the local area network

05D02 Offline analysis of traces, log files and event journals on the local area network

05D03 Management of incidents on the local area network

06 Network operations 06A Security of operations procedures

06A01 Security in the relationship with operational personnel (employees, suppliers or service providers)


06A02 Control of the implementation or upgrade of software or hardware

06A03 Control of maintenance operations

06A04 Control of Remote Maintenance

06A05 Management of Operating Procedures for Network Operation

06A06 Management of service providers relating to networks

06A07 Taking into account the confidentiality during maintenance operations on network equipment.

06A08 Contract Management of Network Services

06B Parameters setting and control of hardware and software configurations

06B01 Network equipment customizing and compliance control of configurations

06B02 Control of the network access configurations of user equipment

06C Control of administrative rights

06C01 Control of special access rights to network equipment

06C02 Authentication of administrators and operational personnel

06C03 Surveillance of administrative actions on the network

06C04 Control of networking operational tools and utilities

06D Audit and Network Control Procedures

06D01 Audit Control Operation

06D02 Protection of Tools and Audit Results

07 Security and architecture of systems 07A Control of access to systems

07A01 Management of access profiles (rights and privileges granted by functional profile)

07A02 07A02

07A03 Authentication of the access requestor (user or entity)

07A04 Access filtering and management of associations

07A05 Authentication of the server for access to sensitive servers

07B Containment of environments

07B01 Control of access to residual data

O7C Management and saving of logs

07C01 Recording access to sensitive resources

07C02 Recording privileged system calls

07D Security of the architecture

07D01 Service continuity of the architecture and of its components

07D02 Isolation of Sensitive Systems

08 IT Production environment 08A Security of operational procedures

08A01 Consideration of security in relation with operational personnel (permanent and temporary staff)

08A02 Control of the operational tools and utilities

08A03 Acceptance control of systems introduction or modification Systems here include operating systems, applications and associated middleware


08A05 Confidentiality considerations during maintenance of the production systems

08A06 Control of remote maintenance

08A07 Protection of sensitive printed documents and reports

08A08 Management of Operating Procedures for IT production

08A09 Management of service suppliers and providers relating to IT operations

08B Control of hardware and software configurations

08B01 Conformity control of systems parameters and configurations

08B02 Conformity control of operational software configurations (including packages)


08B03 Conformity control of reference programs (source code and executables)

08C Management of storage media for data and progra ms

08C01 Management of storage media

08C02 Labeling of storage media (live, backups and archives)

08C03 Physical security of media kept on site

08C04 Physical security of storage media (kept in an external site)

08C05 Verification and turnover of archive storage media

08C06 Security of storage networks (SAN : Storage Area Network and NAS)

08C07 Physical Security of Transiting Medias

08D Service continuity

08D01 Organization of hardware maintenance (for operational equipment)

08D02 Organization of software maintenance (systems, middleware and applications)

08D03 Application recovery procedures and plans following incidents during operation

08D04 Backup of software configurations (system, applications and configuration parameters)

08D05 Backup of application data

08D06 Disaster Recovery Planning for IT operations

08D07 Anti virus protection for production servers

08D08 Management of critical systems (regarding maintenance continuity)

08D09 Off site emergency (recourse) backups

08D10 Maintaining user accounts

08E Management and handling of incidents

08E01 Online detection and treatment of IT related abnormal events and incidents

08E02 Offline management of traces, logs and event journals

08E03 Management of system and application incidents

08F Control of administrative rights

08F01 Control of administrative access rights granted on systems

08F02 Authentication of administrators and operational personnel

08F03 Surveillance of system administrators' actions

08G Audit and control Procedures relative to Inform ation Systems

08G01 Operation of Audit Control

08G02 Protection of Tools and Audit Results

08H Management of IT related archives

08H01 Organization of the management for IT archives

08H02 IT Archives access management

08H03 Management of IT archive safety

09 Application security 09A Application access control

09A01 Management of application data access profiles

09A02 Management of access authorizations to application data (granting, delegation, revocation)

09A03 Authentication of the access requestor

09A04 Access filtering and management of associations

09A05 Authentication of the application for access to sensitive applications

09B Control of data integrity

09B01 Sealing of sensitive data

09B02 Protection of integrity of exchanged data

09B03 Control of data entry

09B04 Permanent checks (accuracy, etc) relating to data

09B05 Continuous (plausibility, …) checks on data processing


09C Control of data confidentiality

09C01 Encryption of data exchanges

09C02 Encryption of stored data

09C03 Anti electromagnetic radiation protection

09D Data availability

09D01 Very high security recording

09D02 Management of access to data files

09E Service continuity

09E01 Hardware reconfiguration

09E02 Application service continuity plans

09E03 Management of critical applications (with regard to maintenance continuity)

09F Control of origin and receipt of data

09F01 Proof of origin, electronic signature

09F02 Prevention of message duplication and replay (numbering, sequencing)

09F03 Acknowledgements of receipt

09G Detection and management of application inciden t and anomalies

09G01 Detection of application anomalies

09H Security of the e-commerce Sites

09H01 Security of the e-commerce Sites

10 Security of application projects and developments 10A Security of application projects and developmen ts

10A01 Consideration of security in application development

10A02 Change management

10A03 Externalization of software development

10A04 Organization of application maintenance

10A05 Modification of software packages

10B Ensuring security in the development and mainte nance processes

10B01 Ensuring security in the organization of application developments

10B02 Ensuring confidentiality in application developments

10B03 Security within Internal Processing of Applications

10B04 Protection of Data during tests

10B05 Security of application maintenance

10B06 Hot Maintenance

11 Protection of users' work equipment 11A Security of the operational procedures for the whole set of users' equipment

11A01 Control of the installation of new software or system versions on the users' equipment

11A02 Control of the compliance of user configurations

11A03 Control of software and software package licenses

11A04 Conformity control of the reference programs (source and executable) for user software

11A05 Management of service suppliers and providers relating to the operation and handling of the user workstations base

11B Protection of workstations

11B01 Control of access to workstations

11B02 Work effected off company premises

11B03 Use of personal equipment or external equipment (not owned by the organization)

11C Protection of data on the workstation

11C01 Protection of the confidentiality of data on the workstation or on a data server (logical disk for the workstation)

11C02 Protection of the confidentiality of data stored on removable media


11C03 Confidentiality considerations during maintenance operations on user workstations

11C04 Protection of the integrity of files stored on workstations or on data servers (logical disk for workstations)

11C05 Security of Email and Electronic Information Exchanges

11C06 Protection of documents printed on shared printers

11D Service continuity of the work environment

11D01 Organization of user hardware maintenance

11D02 Organization of user software maintenance (system, middleware and application)

11D03 Users' configurations backup plans

11D04 Backup plans for user data stored on data servers

11D05 Backup plan for data stored on user workstations.

11D06 Anti virus (malware, unauthorized executable code, etc.) protection for user workstations.

11D07 Recovery Plans for the users' workstations

11D08 Access management to office data and files

11E Control of administrative rights

11E01 Management of privileged access rights granted on user workstations (administrative rights)

11E02 Authentication and control of the access rights of administrators and operational personnel

11E03 Surveillance of system administrators' actions over the users' workstations

12 Telecommunications operations 12A Security of operational procedures

12A01 Consideration of security in relation with operational personnel (permanent and temporary staff)

12A02 Control of the implementation of new equipments or upgrade of existing systems


12A04 Control of Remote Maintenance

12A05 Management of Operating Procedures for Telecommunication Operation

12A06 Management of service providers relating to telecommunication

12B Control of hardware and software configurations

12B01 Network equipment customizing and compliance control of configurations

12B02 Conformity control of operational software to a reference version

12C Service continuity

12C01 Organization of operational equipment maintenance

12C02 Organization of software maintenance (systems and attached services)

12C03 Backup of software configurations (system, services and configuration parameters)

12C04 Disaster Recovery Plans

12C05 Management of critical systems (regarding maintenance continuity)

12D Use of end-user telecommunication equipment

12D01 Control of the compliance of user configurations

12D02 Training and awareness setting for users

12D03 Use of cryptographic equipment

12E Control of administrative rights

12E01 Management of privileged access rights granted on equipments and systems (administrative rights)

12E02 Authentication and control of the access rights of administrators and operational personnel

12E03 Surveillance of system administrators' actions over the equipments and systems

13 Management processes 13A Protection of personal information (PPI)

13A01 Policy and instructions related to PPI

13A02 PPI training and awareness program

13A03 Applicability of the PPI policy


13A04 Monitoring the implementation of the PPI policy

13B Communication of financial data

13B01 Policy and instructions related to Communication of financial data

13B02 Communication of financial data training and awareness program

13B03 Applicability of the Communication of financial data policy

13B04 Monitoring the implementation of the Communication of financial data policy

13C Respect of regulations concerning the verificat ion of computerized accounting (VCA)

13C01 Preservation of accounting data and treatments

13C02 Documentation of accounting data, procedures and treatments

13C03 Verification of computerized accounting data training and awareness program

13C04 Applicability of the VCA policy

13C05 Monitoring the implementation of the VCA policy

13D Protection of intellectual property rights (IPR )

13D01 Policy and instructions relative to the Protection of intellectual property rights

13D02 Intellectual property rights training and awareness program

13D03 Applicability of the intellectual property rights policy

13D04 Monitoring the implementation of the intellectual property rights policy

13E Protection of computerized systems

13E01 Policy and instructions relative to the Protection of computerized systems

13E02 Protection of computerized systems training and awareness program

13E03 Applicability of the protection of computerized systems policy

13E04 Monitoring the implementation of the protection of computerized systems policy

13F Human safety and protection of the environment

13F01 Policy and instructions relative to Human safety and protection of the environment

13F02 Human safety and protection of the environment training and awareness program

13F03 Applicability of the Human safety and protection of the environment policy

13F04 Monitoring the implementation of the Human safety and protection of the environment policy

13G Rules related to the use of encryption

13G01 Policy and instructions relative to the use of encryption

13G02 Use of encryption training and awareness program

13G03 Monitoring the implementation of the use of encryption policy

14 Information security management 14A Establish the management system

14A01 Define the boundaries of the ISMS

14A02 Define the ISMS policy

14A03 Define the risk assessment approach and associated metrics

14A04 Identification of the risks

14A05 Analysis and evaluation of the risks

14A06 Selection of risk treatment options

14A07 Selection of the measures (controls) for risk reduction

14A08 Selection of the security measures in accordance to the statement of applicability (SOA)

14B Implement the management system

14B01 Formulation of a risk treatment plan

14B02 Implementation of the risk treatment plan

14B03 Selection and implementation of ISMS indicators

14B04 Implementation of training and awareness plan

14B05 Incident detection and response

14C Monitor the management system


14C01 Monitoring execution of the security procedures and measures

14C02 Steering the audit program

14C03 Review of risks and security measures

14D Improve the management system

14D01 Continuous improvement

14D02 Actions to correct nonconformities

14D03 Actions to prevent nonconformities

14D04 Communication to stakeholders

14E Documentation

14E01 Documentation management

14E02 Document approval

14E03 Updates

14E04 Document naming and versioning management

14E05 Documentation disposal

14E06 Withdrawing of obsolete documents


Appendix G3 Scale used for the evaluation of the quality level of security services

Though this scale may be continuous, it is useful to give some reference values for the quality of service.

Evaluated service quality level of 4

This is the highest level, and the security service will remain active and efficient in the face of all aggressions described above. It could however be breached in exceptional circumstances: the world’s best code breakers with the world’s best code breaking tools (which is possible if some countries want it to happen) or an exceptional combination of exceptional circumstances.


The service is more efficient and resists against attacks and events described above, but could be insufficient against specialized attacks (well equipped and experienced hackers, specialized system engineers, particularly if they have tools or expertise applied to the domain, professional spies, and so on), or really exceptional natural disasters. A generalized solution would have some effect across a large number of circumstances. However, it would certainly not provide any guarantees for very serious problems or attacks.


The service is generally efficient and remains resistant to the average hacker or event. However, it is certainly insufficient when faced with an experienced professional in the specific domain (this could be an IT professional, a well equipped burglar, or an expert in physical break-ins). As far as natural events are concerned, it is rarely sufficient to cover serious events – though these are rare. Generally, such services would only improve day-to-day situations.


This service has a minimum level. It could be totally inefficient (or not resist) faced with an ordinary user, without any particular qualification, or slightly learned. In natural events, it is likely to be of no use in day-to-day problems. Generally, it will have little or no effect on the behavior or efficiency of the organization.

L ’ E S P R I T D E L ’ É C H A N G E

CLUB DE LA SÉCURITÉ DE L'INFORMATION FRANÇAIS 11, rue de Mogador

75009 Paris

� + 33 1 53 25 08 80

[email protected]

Download CLUSIF productions from

www.clusif.asso.fr

Documents

MEHARI 2010 Fundamental concepts and functional specificationsmeharipedia.x10host.com/wp/wp-content/.../12/MEHARI... · METHODS MEHARI 2010 Fundamental concepts and functional specifications