MONARC Method Guide Methode

methode-guide

methode-guide

User Manual: Pdf

Open the PDF directly: View PDF PDF.
Page Count: 23

MONARC Method guide
"security made in Lëtzebuerg" (SMILE) g.i.e.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê1
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê1
1.2. Other documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê1
1.3. Syntax used in the document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê1
1.4. Syntax used in MONARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê1
2. Monarc Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê1
2.1. Iterative Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê2
2.2. Qualitative method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê3
2.3. Method broadly based on ISO/IEC 27005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê3
2.4. Access to methodology screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê4
2.5. Details of the stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê5
3. Definition of the risk analysis context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê6
3.1. Risk analysis context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê7
3.2. Assessment of the trends, threats and overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê8
3.3. Risk analysis context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê10
3.4. Definition of the assessment, acceptance and impact criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê11
3.5. Deliverable: Validation of the context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê14
4. Context Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê14
4.1. Identification of assets, vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê15
4.2. Assessment of impact and consequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê15
4.3. Summary of assets/impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê16
4.4. Deliverable: Validation of the context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê17
5. Risk Assessment and processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê17
5.1. Risk assessment and processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê18
5.2. Management of the processing plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê19
5.3. Deliverable: End report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê19
6. Implementation and monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê20
1. Introduction
1.1. Purpose
The purpose of this document is to explain the procedures of the MONARC method by describing
the various steps offered by the tool.
1.2. Other documents
•Quick Start: Provide a quick start with MONARC.
•User guide: Complete documentation of the tool.
•Technical guide: Complete technical documentation.
1.3. Syntax used in the document
All numbers in white on a red background are used on print-screen views to provide additional
explanations. Explanations are always after the view with the corresponding numbering. i.e. 1.
Reference
MONARC Reference
1.4. Syntax used in MONARC
Button that always brings up the menu.
Creating/adding something in context (assets, recommendations, etc.).
Most fields of MONARC display additional information when the pointer stay unmoved some
time.
2. Monarc Method
MONARC “Qualitative” is an iterative method of risk analysis in four stages; broadly inspired by
ISO/IEC 27005.
1
2.1. Iterative Method
MONARC uses an iterative method which enables the pragmatic progression of risk management.
This approach, as recommended by ISO 27005, enables the user to restrict himself to the essentials,
then to carry out successive iterations to broaden the target or further refine it to cover more
technical aspects. The optimised risk models provided as standard with the tool will enable this
type of management to be carried out.
1. Context establishment: Definition of the target of the risk analysis, establishing and describing
the context, defining the risk analysis criteria and the structure of the risk approach.
2. Context modelling: Development phase of the risk model. After having identified the primary
assets, they just need to be broken down into support assets on a priority basis. The most
common assets are present in the MONARC knowledge base and therefore identification of risk
by default is offered. This type of identification may be sufficient in an initial risk iteration;
however, it is the responsibility of the risk expert to provide the comprehensive model.
3. Risk assessment and processing: Risk assessment involves establishing the level of threats and
vulnerabilities of the context type under review. The processing of risk entails proposing
security measures which tend to lower major risks to acceptable levels and to accept low risks.
4. Implementation and monitoring: The current MONARC version provides in Beta version follow-
ups views in terms of the implementation of recommendations. Monitoring involves checking
the major changes to the risk analysis context on a regular basis, as well as any major changes
beyond said context which would imply a redesign of an analysis iteration.
2
2.2. Qualitative method
MONARC is a “Qualitative” method, i.e. the risk parameters are determined on a contextual digital
scale which enables the risks to be prioritised. This approach is based on ISO/IEC 27005 as it is
easier to understand, especially for non-tangible criteria in terms of impact and consequences, such
as "Reputation", "Image", "Legality", etc.
2.3. Method broadly based on ISO/IEC 27005
The illustration above displays the similarities between ISO/IEC 27005 and MONARC.
The sub-stages provided by the method are also in line with ISO/IEC 27005:
3
2.4. Access to methodology screens
Access to the views of the various stages of the method is provided by clicking on the numbers 1 to
4, which are displayed under the Breadcrumbs in the main MONARC view. The ISO/IEC 27005
processes are implemented via the views.
4
2.5. Details of the stages
5
1. Ticking the boxes enables the user to develop the progress status of the method
2. Clicking on the heading provides access to the management contextual sub-
screen
3. Definition of the risk analysis context
By clicking on number 1, the following menu will appear:
6
1. Link to the contextual management pop-ups, see the following chapters
2. Boxes to tick, indicating that the stage selected has closed. This optional
information helps to show the progress of the risk analysis project and display
the risk representation graph of the dashboard
3. Link enabling the “Validation of the context” deliverable to be generated. As
part of a consultancy assignment, for instance, it may be helpful to get the
client to validate it.
3.1. Risk analysis context
This view offers text encoding and formatting functions, enabling the risk analysis target to be
contextualised with well-formatted texts that will be documented in the deliverables.
7
1. Access to the text formatting functions (bold, italics, paragraph, text size, etc.). The quality of the
encoding directly affects that of the deliverable.
2. To display or delete the help area .
3. Help area on the content which is recommended for data entry (see below for more).
4. Chapters recommended by ISO27005. Clicking on the label will place it automatically in the data
entry area.
3.2. Assessment of the trends, threats and overview
This stage is divided into three separate parts which structures the data collection necessary for
understanding the context to analyse. It is advisable to chair a working party of 5 to 10 people
(depending on the organisation), bringing together the members of management, IT, risk
management department (if it exists), the heads of departments or key personnel.
1. Assessment of trends: MONARC provides a series of questions to establish the context from a
very general perspective (for more information, see chapter 3.2.1).
2. Assessment of threats: Enables the threats to be reviewed from a general viewpoint and,
possibly, to evaluate by default in the future model (for more information, see chapter 3.2.2).
3. Textual summary of key points determined during stages 1 and 2 (for more information, see
chapter 3.2.3).
3.2.1. Assessment of trends
The assessment of trends provides a series of questions to establish the context from a very general
perspective. These questions highlight the selection of key assets which must be taken into account
during the analysis, the security criteria, as well as a few indicators concerning the motives of the
attack and the external context of the target. This list is not exhaustive; you can add questions of
your choice at the end of the page.
8
3.2.2. Assessment of threats
The assessment of threats, in similar fashion to the assessment of trends, takes the form of a
meeting involving key personnel in the organisation. The purpose is to review the majority of
threats by gathering information on the past and reviewing the general observations made by the
group. The principle is to obtain a consensus on the probability of the threat on a scale which is
easy to interpret:
•Relatively low: Never occurred, really not likely
•Normal: No clear position, no opinion
•Relatively +: Already occurred
•Relatively ++: Already occurred on one or two occasions The security expert is responsible for
converting the consensus into a probability value of 1 to n which shall be used in the model.
1. Click on the “Assessment of threats” tab.
2. Heading of the threat.
3. Information on the threat.
4. Observation to encode, information gathering from a group of persons.
5. Information on the security criteria affected by the threat.
6. Choice of the trend, obtained by group consensus.
7. Selection of the probability deduced from point by the security expert.
8. Possibility of subsequently running the threats of the model (after they have been developed).
9. Save the information and browse the threats.
3.2.3. Summary of assessments
In similar fashion to the context of the risk analysis, this view enables the user to summarise the
9
pertinent information gathered during the assessment of trends and threats. This text enables the
user to enrich the deliverable.
3.3. Risk analysis context
This view enables the user to encode the information on the context of the risk management, for
instance, with regard to the roles and responsibilities, the stakeholders, etc. For more information,
please see chapter 7.4, of ISO/IEC 27005: 2011
10
3.4. Definition of the assessment, acceptance and
impact criteria
This involves personalising the scales and impact criteria and consequences. MONARC provides
values by default which can be personalised depending on the context. All the scales can be
modified and the levels personalised. However, it is no longer possible to modify the scales when
an assessment has been encoded.
3.4.1. Scale of impact
1. Click to modify the number of scales.
2. Click to “Display or Hide” the criteria not used in the analysis.
3. Click on the symbol to hide an unused column.
4. Click to add a new impact criteria.
5. Click to edit the headings of each scale (the management is similar to an Excel table, by clicking
on a heading, it is possible to edit it; clicking on another, the first heading will save
automatically and so forth).
By default, the impact and consequence scale includes the following criteria:
•C: Confidentiality
•I: Integrity
•A: Availability
•R: Reputation
•O: Operation
•L: Legal
11
•F: Financial
•P: Person (impact on the person)
It is also possible to add personalised consequences as well as impact criteria.
The same scales are used to process information risk and operational risk; there is simply a
difference of interpretation :
•The information risks are evaluated on the CIA criteria by taking into account the ROLFP
consequences.
•Operational risks are directly evaluated on the ROLFP criteria
3.4.2. Scale of threats
The scale of threats is used to calculate information risks and the probability of scenarios relating
to operational risks
1. Click to modify the number of scales
2. Click to edit the heading on each scale (Management identical to the impact scale).
3.4.3. Scale of vulnerabilities
The scale of vulnerabilities is only used for calculating information risks.
12
1. Click to modify the number of scales
2. Click to edit the heading on each scale (Management identical to the impact scale).
3.4.4. Management of acceptability thresholds
There are two separate tables for acceptability thresholds, as operational risk and information risk
are not calculated in the same way. Information risks are calculated using three criteria:
1. Modification of thresholds levels of informations risks. The table displayed above (as well as the
risk analysis tables) is updated automatically.
2. Information risks are calculated using three criteria: Impact x Threat x Vulnerability
3. Modification of thresholds levels of operational risks. The table displayed above (as well as the
risk analysis tables) is updated automatically.
13
4. Operational riks are calculated using two criteria: Impact x Probability
3.5. Deliverable: Validation of the context
This deliverable includes all the information gathered and entered in the context establishment
phase. It can be used to validate the information provided by the client, before beginning the risk
identification. A form has to be filled in. When the user clicks on “Save”, a file in Word format is
generated.
4. Context Modeling
By clicking on number 2, the following menu will appear:
14
4.1. Identification of assets, vulnerabilities
Clicking on the link will generate the main view of MONARC. The purpose is to create the risk
model by using the assets in the library. The principle of the modelling is to place at the root the
analysis of the primary assets, then place the support assets which make up the parts above it. The
context establishment phase is used for determining the primary assets which will be the subject of
the analysis. At this stage of the analysis, certain secondary assets may already be known. By
default, MONARC offers a “Front Office” and “Back Office” structure; however, this is not an
obligation. It is vital that the construction of the model follows a contextual logic, the assets and
terms listed must use the organisation’s terminology. To do this, the user must not hesitate to
rename the assets provided by default by the library.
Principe of the "front office"/"back office" structure
•The “Front Office” represents the “user” side; for example, in the case of a “Human
Resources” department we will find employees and the complete IT system to which
they have access (office, workstation, hardware, software, individuals, etc.).
•The “Back Office” represents the IT and organisational side of the organisation that are
common to all concerned (building, data centre, network, administrators, common
rules, etc.).
4.2. Assessment of impact and consequences
For each primary asset, the impact and consequences which may apply must be defined, if the risks
in the model arise. By default, all the supporting assets will inherit these impacts, but it is also
possible to redefine them. When the primary asset is a service, then the “C” (Confidentiality) and
the “I” (Integrity) refers to the most sensitive information of the service in question. “A”
(Availability) refers to the service and the information, based on the principle that if the
information is available, the service will also be available. When the primary asset is the
15
information, there is no ambiguity regarding the CIA criteria - it refers to all the information. In
certain rarer cases, if the “C” associated with a service conveys the confidentiality of the operating
procedure (e.g. manufacturing process), the user just has to express the assets in the model
separately in the form of an informational asset and a service.
The value of the CIA criteria is deduced automatically according to the ROLFP consequences or
other consequences which have been associated with them (maximum value). For example: In the
case of the abovementioned example, the “3” impact level on confidentiality is explained by the
maximum ROLFP value regarding the confidentiality, which in this case is “3” in terms of
consequence for the person.
4.3. Summary of assets/impact
The summary of the assets will provide editorial content that justifies the choice of assets and
impact for the deliverable.
16
4.4. Deliverable: Validation of the context
This deliverable covers all the significant primary assets of the model, i.e. those on which the
impact is reported as well as the asset summary. A form has to be filled in. When the user clicks on
“Save”, a file in Word format is generated.
5. Risk Assessment and processing
By clicking on number 3, the following menu will appear:
17
Clicking on the link will generate the main view of MONARC.
5.1. Risk assessment and processing
The previous phase provided the impact criteria information; now it is necessary to evaluate
threats and vulnerabilities in order to calculate risk levels.
5.1.1. Assessment of the probability of threats
If the threat assessment made while establishing context provided probabilities, it is necessary to
return to this screen to run all the threats of the model. Then, when reviewing the model’s risks, the
default values may all be revised individually.
5.1.2. Assessment of vulnerabilities
The level of vulnerabilities depends directly on the security measures in place. In order to justify
each value, it is necessary to describe all these measures in a factual manner.
5.1.3. Risk processing
Processing risks in MONARC involves, in similar fashion to ISO/IEC 27005, making a decision so as
to process and not implement the measure in question. There are four ways to process the risk:
1. Accept: The risk is accepted in its current form. No additional action will be initiated.
2. Modify/reduce: Measures are put in place to reduce the risk to an acceptable level. The
reduction level is then evaluated in order to calculate the residual risk.
3. Share: in the case of insurance, for example. This type of processing is specific, as it tends to
reduce the risk impact and not the vulnerability. The residual risk cannot be calculated.
4. Refuse: The cause of the risk is eliminated; after processing, the risk must not longer be present.
18
5.2. Management of the processing plan
All risks covered by one of the four procedures described above are registered in the risk
management plan, irrespective of whether they are information risks or operational risks. The
calculation formula is not the same for both types of risk; therefore, it is the risk acceptance
thresholds which establish the order of risk. Nevertheless, it is possible to reset the order of the risk
processing plan before generating the final deliverable.
5.3. Deliverable: End report
The deliverable contains a complete list of all the information gathered and entered in MONARC,
including that contained in the two previous deliverables. A form has to be filled in. Moreover, it is
possible to add a summary of the analysis which will be appended to the first five risks of the
processing plan. When the user clicks on “Save”, a file in Word format is generated.
19
6. Implementation and monitoring
By clicking on number 4, the following menu will appear:
This view goes beyond the ISO/IEC 27005, as it enables the user to manage the follow-up to the
implementation of the measures.
20
1. This is a recommandation established before.
2. You can put a comment for the implementation of the recommendation.
3. For each recommendation you can set a manager.
4. For each recommenddation you can set a deadline.
5. Click on this part to implement the recommenation and switch on the following view.
1. Set the new control, now in place. It will replace the old one in the risk analysis and also replace
the old current risk by the residual risk.
2. Definitively validate the measure.
Follow the same procedure for each recommendation. After that go to your risk analysis and make
a second iteration.
21

Navigation menu