10 1 1 195 6831

MAGERIT
VERSION 1.0
RISK ANALYSIS AND MANAGEMENT METHODOLOGY FOR

INFORMATION SYSTEMS
PROCEDURES HANDBOOK
TABLE OF CONTENTS
1 INTRODUCTION
1.0 How to use the Procedures Handbook

1.1 Introduction to MAGERIT
1.2 Objectives of MAGERIT
1.3 Elements of MAGERIT
1.4 Organization of the Procedures Handbook
1.5 Function and description of this Handbook within MAGERIT
1.6 Objectives of the Procedures Handbook
1.7 About the Users of the Procedures Handbook
2. THE MAGERIT MODEL
2.1 The role of MAGERIT in Information Systems (IS) security management

2.2 MAGERIT in medium and high complexity projects
2.3 Structure of the Risk Analysis and Management Phase
2.4 A practical example
3. ELEMENTS SUBMODEL
3.1 Assets
3.2 Threats
3.3 Vulnerabilities
3.4 Impacts
3.5 Risk
3.6 Safeguard Functions, Services and Mechanisms
4. EVENTS SUBMODEL
4.1 Introduction to the submodel
4.2 Relational static view of the Events Submodel
4.3 Organizational dynamic view of the Events Submode l
4.4 “Physical” dynamic view of the Events Submodel
5 PROCESSES SUBMODEL

5.2 Structure of the Submodel
5.3 Stages within MAGERIT
5.4 Overview of the Stages of the MAGERIT process
6 STAGE 1: PLANNING RISK ANALYSIS AND MANAGEMENT
6.0 Location of Stage 1 within the MAGERIT model

6.1 Structure of Stage 1
6.2 Overview of Stage 1
6.3 Activity 1: Appropriateness of implementation
6.4 Activity 2: Definition of domain and objectives
6.5 Activity 3: Project organization and planning
6.6 Activity 4: Project launching
6.7 Summarizing the stage
6.8 Role of the participants
6.9 Application of Stage 1 to the case study
7 STAGE 2: RISK ANALYSIS

7.3 Activity 1: Gather information
7.4 Activity 2: Identify and group ASSETS
7.5 Activity 3: Identify and evaluate THREATS
7.6 Activity 4: Identify and estimate VULNERABILITIES
7.7 Activity 5: Identify and assess IMPACTS
7.8 Activity 6: Evaluate RISK
8. STAGE 3: RISK MANAGEMENT

8.3 Activity 1: Interpret RISK
8.4 Activity 2: Identify and estimate safeguard functions and services
8.5 Activity 3: Select safeguard functions and services
8.6 Activity 4: Achieve objectives
8.9 Application of the Stage 3 to the case study
9. STAGE 4: SAFEGUARDS SELECTION

9.3 Activity 1: Identify safeguard mechanisms
9.4 Activity 2: Select safeguard mechanisms
9.5 Activity 3: Specify mechanisms to be implemented
9.6 Activity 4: Plan implementation
9.7 Activity 5: Integrate results
9.10 Application of stage 4 to the case study
APPENDIX 1: SUMMARY-CHARTS OF ELEMENTS
APPENDIX 2: GLOSSARY
APPENDIX 3: BIBLIOGRAPHY
APPENDIX 4: PROJECT TEAM
1. INTRODUCTION
1.0 How to use the Procedures handbook
This Handbook has been conceived as a simple reference manual to identify the Assets of a Domain,
assess the Assets’ Vulnerability to Threats and Impacts, and to propose Safeguard decisions based
on the identification of Risks.
In order to apply this Handbook’s recommendations correctly, it is necessary to take into account
specific situations and the existence of potential technological contradictions. Thus:
• Except for very complex or unclear situations that require the assistance of a specialized
consultant, a non-specialized security technician can apply the measures described in this
Handbook.
• The measures found in this Handbook are not necessarily appropriate for all situations. The
procedures must be adapted to each situation in order to be able to use this Handbook for high
level corporate policy concerning security issues.
Due to its organized structure, this Handbook may serve as a tool for harmonizing the exchange of
information between different people or entities. In other words, it may serve as a common reference
document for people involved in information systems security who must exchange information
between entities, since it provides clear methods for establishing mutual agreements on information
security and systems between entities, providers and users.
This Handbook has two functions that are not always easy to harmonize:
the first reading must be explanatory and even pedagogical; subsequent
readings must be procedural (it must describe the practical steps for
conducting a security project). The boxes like this, which follow, will help
clarify the parts of the text that complete each one of the functions with
useful suggestions.
1.1 Introduction to MAGERIT
The “Consejo Superior de Informática” (Information Technology Council) has prepared the Risk
Analysis and Management Methodology for the information systems of the Public Administrations,
MAGERIT (the Spanish acronym). The Council recommends the use of this methodology as a
response to the growing dependence of the Public Administrations (and of society as a whole) on
information technology. MAGERIT’s purpose is directly related to the extensive and generalized use
of information technology. While information technology provide obvious benefits to citizens, they
also give rise to certain risks that must be minimized through security measures that guarantee the
authenticity, confidentiality, integrity and availability of the information systems (these concepts are
precisely defined in this Procedures Handbook) and which generate confidence among users.
1.2 Objectives of MAGERIT
MAGERIT has two immediate objectives:
• to study the risks that affect a specific information system (IS) and its related environment; risk
is understood by it’s most common meaning, as the possible occurrence of damage.
• to recommend the appropriate measures that must be adopted in order to discover, prevent,
impede, reduce or control the investigated risks.
As a longer term objective, MAGERIT is preparing evaluation and certification mechanisms for
information systems security. To program it, MAGERIT uses as a systematic reference:
• The ITSEC (Information Technologies Security Evaluation Criteria), approved by the SOGIS
(Senior Officer Group of Information Systems) of the EU Commission and subject to the
7/4/1995 Recommendation of the EU Council; as well as the Information Technologies Security
Evaluation Manual (ITSEM).
• The concepts and terms coined by the Evaluation Criteria for Information Technology Security
(ISO/IEC IS 15408).
Both criteria stipulate that the applicants for a security evaluation or certification first must define their
“Domain” (Target of Evaluation, TOE), their Environmental Threats together with the requested
Target of Security (TOS). They also establish that this prior definition must be made with the support
of a Risk Analysis and Management Method such as MAGERIT.
1.3 Elements of MAGERIT
In order to achieve these objectives, the structure of MAGERIT is composed of two types of
elements:
• A set of Handbooks, mainly consisting of:
- An Introductory Handbook.
- A Procedures Handbook.
- A Techniques Handbook.
- A Handbook for application developers.
- A Handbook for persons in charge of the protected domain.
- A Reference Guide for legal and technical standards.
• A series of support tools with their respective Handbooks and with the information architecture
and interface specifications for data exchange data.
This MAGERIT structure lets you carry out:
• risk analysis to identify the threats to the different components belonging to or related to the
Information System (known as “assets”); to assess the system’s vulnerability to such threats and
to estimate the impact or level of damage that an inadequate security can have on the
organization, thereby obtaining a certain awareness of the risk incurred.
• risk management is based on the results obtained in the previous analysis, and lets you select
and implement the appropriate security measures or “safeguards” in order to discover, prevent,
impede, reduce or control the identified risks, thereby reducing possible damages to a minimum.
1.4 Organization of the Procedures Handbook

In addition to this introduction, the Procedures Handbook contains eight chapters related to the
following issues:
1. Introduction.
2. The MAGERIT Model.
3. Elements Submodel.
4. Events Submodel.
5. Processes Submodel.
6. Planning Risk Analysis and Management
7. Risk Analysis.
8. Risk Management.
9. Safeguards Selection.
These chapters describe the main concepts and how the MAGERIT model works. The three
submodels construct the method architecture starting with its components (Elements), and moving on
to the relationships among them (Events) and with the help of construction plans (Processes).
Chapters 2, 3 and 4 lay the foundations for this methodology, which is then developed in the
common procedural way from chapter 5 on.
1.5 Function and description of the Procedures Handbook within MAGERIT
MAGERIT’s Procedures Handbook represents the core of the method.
The contents of the Procedures Handbook, aimed at managing the detected risks, takes into account
the scientific, regulatory and standardization advances in information systems security.
1.6 Objectives of the Procedures Handbook
The objectives of this Procedures Handbook are:
1. To provide an adequate comprehension of the MAGERIT model and of the procedures

used to improve the security of information systems (IS) of organizations and their
departments or units.
2. To offer a solid foundation for adopting, developing and implementing high level
measures that are both effective and practical, and that let you achieve greater security in
the organization’s information systems.
3. To help create the optimum conditions for acquiring security products, systems and
services for your information systems.
4. To establish a common reference for the information systems security sector, which will
foster the exchange of products, systems and services among providers, users,
subcontractors and other players in the industry.
1.7 About the Users of the Procedures Handbook
This Handbook is geared toward people with experience in security processes for information
systems, be they security administrators or not and regardless of whether they belong to the public
sector (although some concepts of MAGERIT are better adapted to this sector). However, it also
has been written so as to facilitate comprehension of the Risk Analysis and Management process by
non-specialized managers and technicians in information systems security.
This Handbook should encourage users to get involved in the comprehension, implementation or
maintenance of the security conditions for the information systems within their organizations.
2. THE MAGERIT MODEL
2.1 The role of MAGERIT in Information Systems (IS) security management.
As a method for Risk Analysis and Management, MAGERIT covers only one Phase in the
comprehensive security management of a given information system. Comprehensive security
management (represented in the next diagram) is a permanent, cyclical and reoccurring process (in
other words, it must be restarted continually due to changes in the system and its environment). The
other Phases have only been listed and will not be examined in detail by MAGERIT, except for its
interface with the Risk Analysis and Management Phase.
MAGERIT
OBJECTIVES, STRATEGY and
è RISK ANALYSIS & ç è POLICY
MANAGEMENT
for
ê ê
SECURITY ORGANIZATION of
Information Systems
PLANNING for
çè
Information Systems Security
ê ê
IMPLEMENTATION OF
SAFEGUARDS çè SECURITY AWARENESS
& OTHER SECURITY
MEASURES
in Information Systems
ê ê
Monitoring and REACTION to incidents

Management of çè
Configuration & Changes Incident REPORTING
in the Information Systems
Security RECOVERY of Security
é
• Risk Analysis and Management: This is the central Phase for “measurement” and calculation
within the security management cycle. It is the starting point of security management, and requires
special process techniques (within the scope of security). For these reasons, the Phase will be
subject to a special MAGERIT method, while the remaining Phases of the cycle are supported
by more generic and better known techniques.
• Objectives, Strategy and Policy for Information Systems Security: This Phase builds on and
contributes to the Risk Analysis and Management Phase. In the initial cycle of security
management, a comprehensive Risk Analysis and Management helps to determine the
objectives, strategy and policy, which in turn will affect the more detailed Risk Analysis and
Management of subsequent cycles.
• Security Planning for Information Systems: This Phase is the most immediate functional
consequence of the Risk Analysis and Management Phase. It uses general planning techniques
(results, progression, and decision milestones) adapted to the area of security.
• Security Organization for Information Systems: This Phase is the most immediate organic
consequence of the Risk Analysis and Management Phase. It uses general organization
techniques (managerial commitment, roles, responsibilities, regulatory documentation) adapted to
the area of security.
• Implementation of Safeguards and Other Security Measures in Information Systems: This

Phase results from the planning and organization Phases and uses general techniques for project
management and configuration management adapted to the area of security.
• Awareness about Security in Information Systems: This Phase stems from the planning and
organization Phases. It takes into account the essential role of the internal human resources in any
security project, and uses general techniques for project management and training,
communications and human resources management, adapted to the security environment.
• Reaction to Incidents, Handline and Reporting of Incidents, and Recovery of

Acceptable Security States: This Phase is basically operational and thus uses general day to
day management techniques and emergency services, adapted to the area of security.
• Monitoring and Management of Configuration and Changes in the Security of Information
Systems: This Phase is basically one of maintenance and uses general monitoring techniques,
configuration management and change management, adapted to the area of security.
2.2 MAGERIT in medium and high complexity projects
Medium and high complexity projects in security require more than one comprehensive security
management cycle (next diagram). The first management cycle application covers the whole
system under study. It starts with the Phase of Risk Analysis and Management, using a broad
approach in order to obtain an initial separation or classification of the system components into two
large blocs:
• components involving minor risks, to which basic “common sense” security measures can
be broadly applied.
• components involving major risks. For each of these it will be necessary to apply a new and
more detailed Risk Analysis and Management.
The first application offers an initial synthetic view of security with the help of the other Phases of the
security management cycle, in other words:
- Setting comprehensive security objectives, strategy and policy.

- Establishing initial security planning.
- Establishing an initial definition of the organization necessary for security.
- Implementing general safeguards in low risk components.
- Security awareness.
- Training people to participate in the security of low risk components.
- Training people to react to each event, to handle and record incidents and to recover
acceptable security states related to the low risk components.
è Comprehensive Analysis and çè Information Systems Security-
Management of Minor Risks Objectives, Strategy & Planning
ê ê ê ê ê
Major Risk 1 Analysis & Major Risk 2 Analysis &
Management by MAGERIT Management by MAGERIT
ê ê ê
Planning, Organization, Planning, Organization, Planning, Organization,
Implementation, & Implementation, & Implementation, &
Awareness Awareness Awareness
in Information Systems Security in Information Systems Security in Information Systems Security
ê ê ê
Reaction to events, filing, recovery, Reaction to events, filing, recovery, Reaction to events, filing, recovery,
monitoring, security configuration/ monitoring, security configuration/ monitoring, security configuration/
change management change management change management
in Information Systems Security in Information Systems Security in Information Systems Security
ê ê ê
The subsequent applications of the security management cycle for major risks components start at
the Risk Analysis and Management Phase. The approach is proportionate to the detected risk and
relates the expected benefit to the implementation cost of all the Phases of the security management
cycle.
2.3 STRUCTURE of the Risk Analysis and Management Phase
The Procedures Handbook methodically describes the Risk Analysis and Management Phase,
using the MAGERIT method as its main reference.
The MAGERIT method begins by defining the most general level (so that it can be adapted to any
specific situation). MAGERIT considers a comprehensive strategic view of the information systems
security of the Public Administrations. The view begins with a Risk Analysis and Management
model comprised of 3 sub-models (next diagram):
· Elements submodel
· Events submodel
· Processes submodel
The elements submodel provides the “components” that the events submodel will interrelate among
each other and in time, while the processes submodel is the functional description (“explanatory
chart”) of the security project under construction.
When building a specific security project, the processes submodel helps, on the one hand, to follow
the general procedure and, on the other, to adapt it to the specific problem at issue, taking into
account the security policy established by the organization’s management. If this adaptation is
complex or presents uncertain elements, it must be carried out with the help of an IS security
specialist.
The procedure tailored to requirements of a specific security project determines the functions and
safeguard services appropriate for the problems detected when applying the method, and points out
types of safeguard mechanisms to solve them. Although they are not part of MAGERIT, this
methodology prepares the planning, organization and subsequent phases necessary for implementing
and operating such mechanisms.
MAGERIT Model
ELEMENTS Submodel EVENTS Submodel PROCESSES

6 basic entities 3 main types Submodel
4 defined stages
· Assets · Static
· Threats · Organizational dynamic · Planning
· Vulnerabilities · Physical dynamic · Risk analysis
· Impacts · Risk management
· Risk · Safeguards selection
· Safeguards
Those familiar with the risk analysis and management methods in the process of being
standardized in fact or by law (European projects such as INFOSEC S2014,
Evaluation Criteria for IT Security, guideling for the management of IT Security by
ISO/IEC, etc.) can go to Chapter 6, after a superficial reading of Chapters 2 to 5 to
check the points they share in common with the aforementioned standards.
2.4 A practical example
To help you better understand the abstract concepts of a model and its submodels, let us use the
example of the income tax return that we all must file. We start with an initial “study” of our personal
tax situation in order to determine the level of our liabilities and the type of return that we must file
(normal, simplified, joint, etc.).
The comprehensive model of the tax return would be the “envelope” containing all the parts or
submodels, all of which are abstract even though they are printed on paper. Thus the explanatory
booklet (called “Guide for Filling Out Your Tax Return”) would be the equivalent of the Procedures
Handbook.
The “Guide for Filling Out Your Tax Return” includes the elements submodel, which would be the
final Chapter with the “glossary of the most used terms” defined exactly as in the tax legislation. It
also includes a processes submodel, which are the general “rules” to follow in filling out the forms
and for resolving each specific problem.
The set of blank “forms” to fill out (which are called form “models”) would be the events
submodel, which attempts to reflect the “fiscal cycle” of the taxpayer and relates the different
elements of the submodel (taxpayer, amounts due, interest, period, income, deductible expenses,
returns, withholdings, tax rate schedule, etc.).
The fiscal problem underlying the return may be simple or complex. The procedure may be
“simplified” and easy to execute (with the help of an appropriate tool. Or, if more complex, the
taxpayer will need help of an expert. The full process of completing the tax return is completed by
other “Phases” (planning dates, organizing, executing, keeping receipts, etc.).
3. ELEMENTS SUBMODEL
MAGERIT model
ELEMENTS
ELEMENTSsubmodel
submodel EVENTS submodel PROCESSES submodel
6 basic entities
6 basic entities 3 main types 4 defined stages
- Assets
- Assets - Static - Planning
- Threats
- Threats - Organizational dynamic - Risk analysis
- Vulnerabilities
- Vulnerabilities - Physical dynamic - Risk management
- Impacts
- Impacts - Safeguards selection
- Risk
- Risk
- Safeguards
- Safeguards
MAGERIT’s Elements Submodel includes the following six basic entities, as well as their
acquisition and updating processes:
- Assets.
- Threats.
- Vulnerabilities.
- Impacts.
- Risk.
- Safeguards functions, services and mechanisms.
The relationships among these entities constitute part of the events submodel and thus, will be
analysed in the chapter regarding the “operation” of the MAGERIT model
Each entity is described according to the following plan:
1. Definition.
2. Characteristics.
3. Types.
4. Attributes.
5. Metrics.
6. Other information, if any.
3.1. Assets
MAGERIT Model
ELEMENTS submodel EVENTS submodel PROCESSES submodel


- Risk
- Safeguards
3.1.1. DEFINITION
Assets are resources of the information system or related to the information system, and are
necessary for the organization to work properly and reach the objectives proposed by
management.
MAGERIT does not limit itself to information systems security. It should be borne in mind that the
aforementioned systems affect the proper operation of the supported organizational systems and in
turn are affected by the organization’s decision-making. Therefore, from the risk point of view, it
does not make sense to talk of an “isolated” information system.
A security project organized with the help of MAGERIT includes a “security target” implemented on
a set of assets that constitute the “target” under study or the project’s domain (an asset can be
considered as a “unitary domain”). The marking of the boundaries of the set of domain assets does
not prevent us from considering the security relationships between the assets and the environment
(anything outside the project domain that affects its security).
3.1.2. CHARACTERISTICS
Any asset (or a homogeneous set of assets, or the domain under study) is characterized by its state
of security. This state is determined by estimating the 4 substates of authentication,
confidentiality, integrity, availability (A - C - I - Av), which MAGERIT defines and assesses
through simple scales defined in the following paragraph 3.1.5, Metrics:
• Substate A (authentication): This substate is defined as the characteristic of giving and
recognizing the authenticity of the domain assets (information) and/or the identity of the actors
and/or the authorization by those in charge of authorizing, as well as the verification of the three
aforementioned issues.
• Substate C (confidentiality): This substate is defined as the characteristic that prevents the
unauthorized disclosure of the domain assets. It refers above all to information assets, and
frequently relates to intimacy or “privacy” when the information has to do with individuals
protected under the Spanish Law regulating the automated processing of personal data. The term
“disclosure” should be understood in its strictest meaning: simple physical or logical access to the
asset changes this substate, although there are no apparent modifications or later disclosures.
• Substate I (integrity): This substate is defined as the characteristic that prevents the
unauthorized modification or destruction of the domain assets. Integrity is linked to the
functional reliability of the information system (in other words, its effectiveness in fulfilling the
functions of the organization system supported by the information system) and it usually has to do
with information assets (although not always). A typical example is the problems caused to the
integrity of the data stored in the PC hard disk by the threat of a virus (from an external disk or
from the network).
• Substate Av (availability): This substate is defined as the characteristic that prevents

unauthorized access denial to the domain assets. Availability is linked to the technical
reliability (failure rate) of the information system components.
Instead of characterizing assets by their security states and substates, MAGERIT could have
characterized them by their “risk states and substates”, complementary to security (that is, the
higher the level of security substates, the lower the level of risk substates, and vice versa). Security
and risk are antithetical concepts and so are security state and risk state. The entire Risk Analysis
and Management Model could have been developed around the single concept of risk, but then this
concept of risk would have to include two completely different meanings, one as the “state” of the
asset and the other as the “result” of a process of calculation based on a decision (incorporating
safeguard actions to modify the state), as concluded from paragraph 4.4.3 (physical interpretation of
the security elements). MAGERIT avoids this ambiguity by using “security” and “risk” as terms with
different meaning, following the international trend in this area.
3.1.3. TYPES
MAGERIT considers five main types or categories of assets:
1. The environment of the information system includes the assets needed to guarantee the
following levels.
2. The information system itself.
3. The information processed by the applications of the information system.
4. The organization’s functionalities that justify the existence of information systems and give
them a purpose.
5. Other assets, as the treatment of assets in a method of risk assessment should allow the
inclusion of any asset, whatever its nature (this broad concept of asset follows the ISO/IEC
Guidelines for the management of IT Security, in which asset is anything that an organization has
or uses.
These five categories or levels imply a classification according to the nature of the assets. The first
three levels constitute the strict domain, generic in any type of project on information systems
security. The last two categories are external or extrinsic to the information system, but still have
security implication. The following examples help explain the types of assets included in each of the
five domain levels.
1. Assets related to the environment level:
- Equipment and supplies (power, air conditioning, communications).

- Personnel (at managerial, operational, development and other levels).
- Tangible assets (buildings, furniture, physical layout).
2. Assets related to the information system level:
- Hardware (processing, storage, interfaces, servers, firmware, others).

- Software (systems’ software, software products, software applications, developed changes in
the firmware).
- Communications (company networks, services, connecting elements, etc.).
3. Assets related to the information level:
- Data (computerized, concurrent or resulting from the information system).

- Meta-information (structure, formas, codes, ciphering keys).
- Mediums (computer based, non-computer based).
4. Assets related to the organization’s functionalities level:
- The organization’s targets and objectives.

- The goods and services produced.
- Users and/or clients of the produced goods or services.
5. Other assets not related to the previous levels:
- Credibility (ethic, legal, etc.) or good individual or corporate image.

- Knowledge accumulated over time.
- Independent criteria or performance.
- Individual or personal privacy.
- People’s safety, etc.
A security project articulates five types or levels of assets from according to the potential chains of
“vertical” failures among the different layers. Thus, failures in the environment assets (1) would
cause other failures in the information system (2). These would affect information (3), which
support the organization’s functionalities (4) and these, in turn affect the other assets (5).
The quality of the MAGERIT implementation depends on the careful characterization of

the assets and their proper adaptation to the project at hand. Security problems could appear
in any level, but their consequences overflow the initial level and end up affecting all the other layers
that depend on it. The hierarchical characterization of the “vertical” chains is not obvious, but is an
essential step in order not to forget the assets that can be affected by problems on other levels.
3.1.4. ATTRIBUTES
Each asset or set of assets has, as essential attributes, two indicators regarding two types of
assessments, which help you calibrate the impact that a threat can have on the asset:
• The asset’s intrinsic assessment has two aspects:
- The first is qualitative: the asset’s use value. This attribute lets you determine what the
asset is for and supports the previous classification.
- The other is quantitative: the exchange value. In other words, how much is it worth?
This attribute is valid for certain types of assets and useful both in terms of indirect effects
for assessing the impact caused by the threats, as well as for supporting the decision
between the risk assessment and that of the safeguards to reduce it.
• The assessment of the considered asset’s security state, formerly stated as characteristic
due to its significance, it is defined through its four (A - C - I – Av) substates: authentication,
confidentiality, integrity and availability.
3.1.5. METRICS
The personnel responsible for the protected domain - the project’s sponsor and the users of
the considered domain and the end-users of the MAGERIT Handbook should identify, define
and assess their assets (this is the main contribution requested by MAGERIT)
The previous assessments are based on metrics.
The intrinsic metrics assessment of the assets are based on the following cases:
• Some assets can be inventoried: an important part of the assets in level 1 (Environment) and 2
(Information System) can be taken from the organization’s preestablished inventories, and
consequently they will follow the classification of these inventories (frequently related to the
accounting of ownership)
• Other assets may or may not be inventoried: the existing applications that allow you to gather
specific information (level 3) or some of the organization’s functionalities (level 4) are
usually inventoried if they are bought in the market or if they can be valued, for example by their
production costs.
• Parts of the system assets under study are not inventoried in the strict accounting sense of the
word, in other words at their “exchange value” (for example, replaceable in case of
depreciation). Nonetheless they do have a “use value” for the organization, which usually
increases in qualitative value when it is missing.
MAGERIT does not recommend the mixture of inventoried and non-inventoried asset assessments,
because this mixture usually underestimates the latter, mainly those assets specifically associated with
Public Administration. As we will see in paragraph 7.4.3. (“asset assessment”), the procedure
recommended by MAGERIT for valuing assets can be summarized by a double effort:
• The asset’s “exchange value” should be calculated as it replacement value, either directly
(inventory value) or indirectly (the cost of recovering it after an impact).
• If this valuation is impossible or inconvenient (the “replacement” value of a person after an

accident due to the lack of asset security), this asset (with its possible impacts and resulting risks)
should be treated as an environmental element of the domain included in the security project. It
should be treated as an element that influences the project as a restriction partially external to the
MAGERIT, but which nonetheless is capable of conditioning the result (for this reason, the asset
or its derivatives should appear in the intermediate reports, and if necessary, in the process’ final
report).
The metrics assessment of the considered asset’s security state lets you estimate the levels of
its four substates A - C - I - Av (authentication, confidentiality, integrity and availability).
• Substate A, authentication: Its scale is linked to the lower or higher need for evidentiary
formalization, authorization and responsibility in the knowledge or communication of the domain
assets. MAGERIT establishes a four level scale (for each of them an example of the traditional
mail is attached, whose terminology is usually maintained):
- Low, when it is not required to know the author or the person in charge of the information (in a
mail form, the authorization by the sender-origin, the recipient-destination or the responsibility
for the content is not that important);
- Normal, if, for example, you need to know the author to prevent the rejection of the origin (in
a certified “letter” it is important to know the data regarding the sender and the origin, for
example, if you have to certify the date for a tender).
- High, when it is also necessary to prevent the rejection by the recipient (in a letter with
“acknowledgment of receipt,” the recipient and destination data are important, for example, to
certify the date of a notification);
- Critical, when it is also necessary to certify the “author” and frequently the content (an
administrative notification, to guarantee that the recipient receives specific information, for
purposes of a judicial summons).
• Substate C, confidentiality of information: MAGERIT uses a four level scale (each is

associated with a type of data taken from the implicit categories of the Spanish Law regulating
the automated processing of personal data):
- Free, its disclosure is unrestricted (NON-personal data).
- Restricted, with normal restrictions (personal data).
- Protected, with high restrictions (specially protected or “sensitive” data, for example, on
ideology, religion, health or ethnic group).
- Confidential, its disclosure is not allowed due to its critical nature.
• Substate I, integrity: It uses a four level scale, each level relates to a practical characteristic,
depending on how easy it is to recover an asset of sufficient quality, in other words, a complete
“unspoiled” asset, with regard to its intended use.
- Low, when it can be easily replaced by an asset of equal quality (for example, redundant or
imprecise information).
- Normal, when it can be replaced with little inconvenience, by an asset of similar quality.
- High, when it is difficult and expensive to recover the needed quality.
- Critical, when it is not possible to recover the same quality.
• Substate Av, availability. It uses a scale of levels defined by the maximum period of time
without the asset that the organization can function without severe consequences or impacts.
MAGERIT uses a four level scale for the management systems which is common in the
public and private sectors:
- Less than an hour, the asset is easily recoverable.
- Up to one working day, the normal period for recovering an asset with the help of outside
telephone experts or with spare parts from local inventories.
- Up to one week, the normal period for recovering a serious asset with the on-site help of
outside experts, with spare parts from outside suppliers, or to reboot it from an alternative hot
site.
- More than one week, a catastrophic breakdown.
Other systems use different maximums for the time without an asset. For example, less than one
hundredth of a second for a computer in a satellite, or one tenth of a second for the controller of a
hospital Intensive Care Unit, or one second in the stock exchange’s electronic control room, or ten
seconds in any commercial transaction, etc. In some systems the asset’s absence is less acceptable in
some periods than in others (payroll at the end of each month, the balance sheets at the end of the
year, etc.).
If it is necessary, a security expert can easily adapt the scales and levels of these security substates to
any specific domain.
3.1.6. OTHER INFORMATION

For the specific objectives of some projects, MAGERIT can develop lists of assets different from
those mentioned above, or more detailed breakdowns within the aforementioned types, levels or
layers. The following groups are also usually used.
• Hierarchical Groups of Assets: These are different according to the case under study and the
level of detail appropriate for the “granularity” planned for the MAGERIT application stage. This
breakdown lets you directly identify and define the specific assets and/or components to be
studied, thereby easing the collaboration between security experts and users.
• Groups of Assets According to the Threat: Assets vulnerable to a common threat; as well as
Groups of Assets According to the Safeguards , which let you apply a common safeguard.
• Non-Typified Assets: MAGERIT facilitates the inclusion of any asset, regardless of its nature.
This allows for a very flexible but well structured treatment of organization’s functionalities and
other non-tangible resources.
3.2. Threats
MAGERIT model


- Risk
- Safeguards
3.2.1. DEFINITION
Threats are events that can set off an incident within the organization, causing material
damages or immaterial losses in its assets.
The above definition encompasses the dynamic essence of the threat: that is, a potential event (i.e.
an action, interruption or lack of action beyond the control of the security actors, as compared to
human decision-making actions). The consequence of a threat, if materialized, is an incident that
modifies the security state of the threatened assets, in other words, it goes from a state prior to
the event to another subsequent state (potential or real, depending on whether the threat or the
aggression materializes).
The definition of threat also assumes that there are a variety of consequences that must be taken
into account when examining the impact.
The distance between the potential threat and its materialization as a real aggression is measured by
the historical frequency or by the potentiality of materialization. In MAGERIT this materialization is
only relevant as part of the relationship between the aggression and the attacked asset (as we will be
seen in the section dealing with vulnerabilities). Symmetrically, as will be seen in the events submodel,
that what really matters is the materialized aggression, and the threats will be treated as non-
materialized or potential aggressions.
3.2.3. TYPES
The diverse causes of threats allows us to classify them according to their type (which, in turn,
orients us regarding the measures to be taken to neutralize them with some autonomy from their
consequences). MAGERIT considers four types of threatening causes: non-human (accidents),
human but accidental (errors), intentional human that require a physical presence, and intentional
human that have a remote origin. Thus, there are 4 groups:
Group A, accidents:
A1: Industrial accidents: fire, explosions, flooding due to water-pipe breakages, pollution from
nearby factories or radioelectric emissions.
A2: Breakdowns: either physical or logical, due to a flaw at origin or which arises during the
operation of the system
A3: Natural physical accidents: floods, seismic or volcanic phenomena, meteors, lightning,
landslides, avalanches, buildings collapses, etc.
A4: Interruptions in essential services or supplies: power, water, telecommunications, fluids

and other types of supplies.
A5: Mechanical or electromagnetic accidents: shocks, falls, alien bodies, radiation,

electrostatics, etc.
Group E, errors:
E1: Usage errors , occurring during the collection and transmission of data or when operating the
system.
E2: Design flaws , existing from the time of the development processes of the software (including
sizing flaws due to the possible saturation of system flows).
E3: Routing, sequence or delivery errors of the information flow.
E4: Inadequate monitoring, tracing and registering of the information flow.
Group P, On-site intentional threats (that require a physical presence):
P1: Unauthorized physical access with destruction or theft (of equipment, accessories or
infrastructure).
P2: Unauthorized logical access with the passive interception of information (only reading is
necessary).
P3: Unauthorized logical access with changes or theft of the information flow or its
configuration (reading and writing are necessary). In other words, the system’s confidentiality is
reduced in order to obtain usable assets or services (programs, data, etc.).
P4: Unauthorized logical access with corruption or destruction of the information flow or its
configuration.
P5: Unavailability of resources, whether human (strike, neglect, shift work), or technical
(diversion of the use of the system, blockades).
Group T: Intentional remote threats:
T1: Unauthorized logical access with passive interruption (for flow analysis, etc.)
T2: Unauthorized logical access with corruption or destruction of the information flow or its
configuration (reading and writing are necessary), whether using a remitter or “middle
man”. In other words, a reduction in system integrity and/or availability without direct benefit
(immaterial sabotage, virus infection, etc.).
T3: Unauthorized logical access with changes (insertion, repetition) in the information flow.
T4: Origin or identity replacement (of the emitter, remitter or “middle man”)
T5: Rejection of the origin or reception of the information flow.
The classification criteria used (by type and according to the causes) let us show the CASRI
(“Commission Assurance et Securité des Risques Informatiques”) threat categories, harmonized and
updated by the delegates of the main countries of the European Union and the European Free Trade
Association. The evolution of the types of threats and the explosive increase in intentional threats
have made it necessary to split the old block of CASRI threats into two blocks, according to the
methods devised to access assets: an on-site intentional threat block (of threats which require a
physical human presence) and another remote origin block (of threats which require communication).
3.2.4. ATTRIBUTES
The threat element does not have any significant attributes that are useful for Risk Analysis and
Management.
3.2.5. METRICS
The intrinsic occurrence of threats is only of generic interest unless it is associated with a materialized
aggression. The attacked asset can help to assess the vulnerability that specifies the association by
default (that is, if there were not a specific assessment of such vulnerability), in this case it is
expressed according to the following scale:
Mean time between occurrences Value in the subjective scale

Less than once a week Very high frequency
Less than every two months High frequency
Less than one year Medium frequency
Less than once every 6 years Low frequency
More than every 6 years Very low frequency
The selected scale is not based on objective considerations, but rather attempts to counteract the
effect of uncertainty when determining the periods based on exponentially increasing intervals.
For the specific objectives of some projects, MAGERIT can develop lists of assets different from
those mentioned above, or more detailed breakdowns within the aforementioned types, levels or
layers. The following groups are also usually used.
• Group of possible events or threats in scenarios. Each scenario has a set of threats that can
attack a group of assets and cause certain types of impacts.
• Hierarchical groups of threats/ aggressions , These are different according to the case under
study and the level of detail appropriate for the “granularity” planned for the MAGERIT
application stage. This breakdown lets you directly identify and define the agressions at the same
level of detail as the assets and/or components to be studied, thereby easing the collaboration
between security experts and users.
• Groups of threats/aggressions according to the security substates mentioned in the assets.

Some threats attack exclusively or predominantly the authentication substate (for example, the
replacement of a message’s origin). Others attack the confidentiality substate (for example, an
unauthorized consultation), the availability substate (unreadiness of essential personnel) or the
integrity substate (loss of data in a transmission).
• Groups of cohesive types of threats/aggressions and safeguards which are form the basis of
the graphic representations (e.g. Kiviat type) of security states of the asset or group of assets.
3.3. Vulnerabilities
MAGERIT model


- Risk
- Safeguards
3.3.1. DEFINITION
The vulnerability of an asset is the potential or possible occurrence of the materialization of a threat
to the asset.
Vulnerability is a feature of the relationship between an asset and a threat. Vulnerability has been
linked to an asset more as a “non-quality” of the asset, but can be linked to the threat when it is
considered useful (in any case, vulnerability is not just a “weakness”, that is, a “negative feature” of
the asset element). Vulnerability is a two-fold concept:
• Vulnerability carries out a mediation function (or predicate from the linguistic point of view)
between a threat as an action and the asset as an object changing the security state. Due to this
static aspect, vulnerability is a part of the asset’s security state.
• Vulnerability in its dynamic aspect is the compulsory mechanism that changes a threat into a
materialized aggression on an asset.
In this way, as an example, the threat of a flood due to the overflowing of a stream together with the
asset “computer site” placed in an easily flooded zone is materialized in the vulnerability of that asset
to that threat. That vulnerability depends on the “occurrence cycle” (frequency) of floods in that area
and the location of the computer site (closeness to the streambed, location of the basement, etc.).
A very common misunderstanding is the assimilation of vulnerability as a probability, used as a

scientific and technical term related to the theory of probabilities. We are not talking about the
quotient of a number of specific cases (real) as opposed to a number of total cases (possible), as the
denominator would not make any sense. MAGERIT carefully avoids the terms probable and
probability, using the concepts potential and potentiality in general as something closer to the
materialization of a threat into an aggression. Potentiality becomes frequency in those cases of
defined calculation, and possibility in those cases of “fuzzy” calculation.
THREAT
VULNERABILITY
aggression
t
ASSET
3.3.3. TYPES
MAGERIT considers two main meanings:
· The asset’s intrinsic vulnerability, as regards the type of threat, only depends on these two
entities: asset and threat.
· The asset’s effective vulnerability takes into account the safeguards applied to the asset at any
moment and also the ways a factor estimates the safeguards’ global effectiveness.
3.3.4. ATTRIBUTES
Intrinsic vulnerability can be broken down, if necessary, to carry out detailed analyses (on
intentional threats) according to the following groups of attributes:
Autonomous potentiality, as regards the asset threatened by the occurrence of a threat (e.g.
frequency of floods in a specific place).
Derived potentiality in the relationship between asset and threat (mainly intentional).
Subjective factors generating more or less “strength” (motivation, dissuasion).
Opportunity of access to the domain with capability and resources according to four aspects:
· Physical access: the number of authorized people or entities that, due to their duties, have access
to the asset’s environment, with a four level scale:
- A single person or entity.

- A few people belonging to an entity.
- Many people from a few different entities.
- Many people from many different entities.
· Qualified physical access: qualification (general training and experience) of the users authorized
to have physical access to the asset’s environment, with the following scale:
- Without training.
- Low level of training to handle technical documents.
- Some experience to handle technical documents.
- High level of training and experience to handle technical documents.
· Competent logical access: the specific technical knowledge of the attackable asset, with a four
level scale:
- Without special knowledge.

- User friendly.
- Developer’s know-how.
- Qualified expert.
· Instrumental logical access: the availability of tools corresponding to the technology of the
threatened asset, with a four level scale:
- No tools required or tools are very accessible.

- No special tools are required but access is restricted (cost, etc.)
- Special tools are required, although they are accessible with the studied technology.
- Special tools are required and access is very difficult.
3.3.5. METRICS
The vulnerability metrics are based on the “distance” between the threat (potential) and its
materialization as an aggression (real) on the asset.
MAGERIT measures vulnerability when it is feasible, due to its historical frequency or to the
possibility of the threat materialization on that asset.
We have specific quantitative data (reliability of a hardware component, number of software failures,
etc.) for some assets and metric [0.1] is used, where 0 means that the threat does not affect the asset
and 1 is not reachable as it would mean a permanent aggression.
But as that measure is not usually available, a first qualitative approach to the frequency or possibility
of the threat materialization leads us to use the scale shown in potential threats (considered now as
real, that is, aggressions).
The scale of levels could be “objective” when comparing the mean time between occurrences in a
unit. In some cases it is advisable that this period be longer (one year for accounting purposes) and in
others shorter (e.g. one day, a daily occurrence of an asset failure is too high a psychological and
material limit, unacceptable in normal productivity conditions, but acceptable in incident research).
So, MAGERIT’s support tools can easily handle several objective “scales”.
Mean time between occurrences Subjective scale Objective scales

At day At year
Less than one week Very high frequency ≅ 0,2 ≅ 50
Less than two months High frequency ≅ 0,02 ≅5
Less than one year Medium frequency ≅ 0,002 ≅1
Less than six years Low frequency ≅ 0,0002 ≅ 0,2
More than six years Very low frequency ≅0 ≅ 0,02
This vulnerability metric is not only unfeasible in many instances but also can be inconvenient for
some types of industries, assets, or threats. For example, industries such as defence, nuclear energy,
transport of people, etc. carry out their tasks as “missions” and work with assets that require critical
security due to their nature. In these cases vulnerability for a threat is nothing (it is not affected) or
all (risk is the full impact) mechanism.
The breakdown of intrinsic vulnerability into generic potentiality of the threat occurrence, and the
accessibility of the threat to the domain has a vulnerability metric that combines the former
metrics (for the generic possibility) with correction for increasing factors that take into account
access (factors that can be seen in the help tools when applying MAGERIT to complex security
problems).
Vulnerability is classified according to its own factors. In any case, it is classified according to the
asset and the threat to which it is closely linked. Only in order to prevent the unmanageable increase
of possible combinations of all possible threats on all assets, it is advisable to organize both entities
into groups or to focus on the threats easy to materialize, and/or on those that have more impact on
the threatened assets.
3.4. Impacts
MAGERIT model

6 basic entities 3 main types 4 defined sta ges

- Risk
- Safeguards
3.4.1. DEFINITION
The impact on an asset is the consequence of the threat’s materialization on the asset.
From a dynamic point of view, the impact is the difference when considering the asset’s security
state before and after an aggression, or the materialization of a threat on the asset. In other words,
the threat event (materialized in aggression) produces in the asset’s former security state (before the
threat) a change to a new state (after the threat), and the impact measures the difference between
both states.
State 1 of the asset
Threat
í aggression
IMPACT
ê
State 2 of the asset
3.4.3. TYPES
MAGERIT uses an impact typology related to the nature of the consequences of the asset-threat
combinations (these combinations are so numerous that it would not be useful to treat them as causes
or “nature” of the impacts in order to classify them as we did with threats).
Normally, a simple asset’s malfunction does not constitute an impact unless it implies some sensible
damage or loss as a change in its state. For example, the disruption of an application in a system due
to a power cut-off or the automatic re-delivery of a message by a service that has self-recovery
mechanisms (although this even involves more or less degraded ways of operation, but normally
taken into account) are not impacts.
MAGERIT considers three main sets of impacts depending on whether their consequences directly
or indirectly (and in this latter case quantitatively or qualitatively) restrict the threatened
assets’ A - C - I - Av security substates.
Impacts will be qualitative with functional losses (in the security substates), qualitative with
organic losses (goodwill, people injuries, etc.), and quantitative if losses can be translated directly
or indirectly into money. MAGERIT has taken a part of the CASRI impact types (paragraph 3.2.3.
on threats) due to the fact that this Commission publishes statistics on quantitative losses classified by
impacts (until international agreements on statistics on this matter are reached). MAGERIT has
completed these types with the impacts that have consequences on the analysed asset’s substates.
Impacts with functional qualitative consequences
· Damages in the authentication substate (AS) are not evolutional (chain multiplication), but
directly produce the cancellation of documents and procedures and indirectly create legal insecurity
(very important in the public administration).
· Damages in the confidentiality substate (CS) are not evolutional and have consequences at
different levels, some direct (the dissemination of information that should not be disseminated or
disclosed too early, specific or massive theft) and others indirect (distrust, troubles, blackmail, etc.).
- Damages in the Integrity substate (IS) could be evolutional and have direct consequences such
as changes in vital or sensible information in a higher or lower level, and indirect consequences such
as the possible contamination of programs (losses, incorrect processing, etc.).
- Damages in the availability substate (AS) could be evolutional and cause immediately the
degradation of the asset’s productivity as a resource or the interruption of its operation in a more or
less lasting and profound way (of data, of an application, of a service, or of a whole system).
Indirectly this causes a margin fall due to the lack of results, as well as additional expenses in order to
recover or maintain its operation at levels previous to the threat.
A part of the previous damages has impacts with different types of quantitative
consequences:
- N1: economic losses linked to real state assets or inventory assets that encompass all costs
related to the recovery of operation, including the expenses of valuing, replacing, repairing, or
cleaning the damages: buildings and works, facilities, computers, networks, complements, etc.
- N2: indirect losses, economically assessed and linked to intangible assets generally not in
the inventory: appraisal expenses and the system’s restoration or replacement of non-material
elements: data, programs, documents, procedures, etc.
- N3: indirect losses economically assessed and linked to tangible malfunctions: they are
seen in the cost of delay or interruption in the organization’s functional operations; in the disorder or
interruption of productive flows and cycles (e.g.: of products, services or files), including damages in
their quality; and the inability to fulfill the contractual or statutory obligations.
- N4: economic losses related to legal liabilities (civil, criminal or administrative) of the
information system’s “owner” due to damages caused to third parties (including, for example, the
Data Protection Agency’s sanctions).
Other damages in the security substates have impacts with different types of organic
qualitative consequences:
- L1: Loss of intangible patrimonial funds: non-recoverable knowledge (documents, data or

programs), confidential information, “know-how”, etc.
- L2: Criminal liability due to the breach of the legal obligations (in relation to personal data,
etc.).
- L3: Disturbances or embarrassing politic-administrative situations (code of practice,

credibility, prestige, political competence, etc.).
- L4: Harm to persons.
3.4.4. ATTRIBUTES
From the point of view of the direct consequences on the asset security states, the impact combines
two attributes or factors, the intrinsic seriousness of the result and the aggravating (or extenuating)
circumstances.
Both attributes change at least one of the four asset’s security substates: authentication,
confidentiality, integrity and availability.
From the point of view of the indirect consequences, an impact has two important attributes:
· The quantitative aspect of the provoked consequence, that is, material (e.g. the economic loss
of the replacement) or immaterial (the loss of data, programs, documents or procedures).
· The qualitative aspect (e.g. loss of business goodwill, loss of or danger to life, embarrassing
political-administrative situations, breaches of personal privacy).
3.4.5. METRICS
Differences in the attributes involve differences in the way to measure and process impacts, although
all of them are generally qualitative (due to the lack of quantitative statistical data).
MAGERIT indicates two basic ways of assessing impacts supported by two qualitative scales:
· An assessment in time of the unavailability of an important asset.
· An assessment in monetary units of a scale with levels guidelines that represent the quantities to
be employed in order to remedy the damages caused by a threat materialized within an organization.
Value (in monetary units) Impacts

Less than 100,000 Very low
Less than 1,000,000 Low
Less than 10,000,000 Medium
Less than 100,000,000 High
More than 100,000,000 Very high
Quantifying impacts is not only one of the most difficult processes in risk analysis, but also it is one of
the most influential when estimating your own risk. As we will see in the events model, the level of
risk depends directly on vulnerability and impact, but all specialists stress the impacts to the decision-
making process that underlies risk assessment. A classical example of ranking, as minor risks goes
from a low impact with a very high vulnerability o potentiality (e.g. to lose money in lottery) to a high
impact with low potentiality or vulnerability (e.g. to risk your own life).
Although the aim of MAGERIT is to measure impacts in pesetas or in any other similar objective
indicators, this is not always possible, unless indirect, and frequently subjective, methods are used.
Therefore, in a first attempt the cost of the damaged asset’s replacement will be taken as a measure
of the impact.
When this measure is not feasible or does not make any sense, the cost of the replacement of the
function carried out by the damaged asset will be assessed starting from the damage to one of the
security substates. For example:
- The high loss of an information asset’s availability substate (available with great difficulty) affects
total or partially one of the organization’s functionalities for a specific period of time (e.g. if
information on orders is lost, a month’s turnover is lost).
- The same high loss of the confidentiality substate does cause a loss in current turnover, but could
have given the order list to a competitor that will use it to provoke the loss of clients and future
turnover, a much higher loss if the appropriate measures are not taken in the meantime.
3.5. Risk
MAGERIT model


- Risk
- Safeguards
3.5.1. DEFINITION
Risk is the possibility of a specific impact affecting an asset in a domain or in the organization.
Risk is the result of risk analysis, a complex process that starts with the determination of independent
elements (the domain’s asset and the threats acting on it) and goes on with the assessment of the
derived elements of both (vulnerabilities and impacts).
MAGERIT allows us to carry out this complex analysis with the aim of reaching a specific goal: a
value of estimated risk that allows us to make the decision to go on to the following stage in the
process. This decision can be taken by the explicit comparison of the estimated risk with the
previously fixed risk (risk threshold).
The estimated risk is only an indicator linked to the estimated values of vulnerability and impact, both
stemming from the relationship between asset and threat/aggression to which the estimated risk
refers.
ASSET THREAT
é
ê í î ê frequency of its materialization
IMPACT VULNERABILITY
î í
RISK
3.5.3. TYPES
MAGERIT distinguishes different types of risks:

· Intrinsic estimated risk, defined or estimated before applying safeguards (submodel element,
see next section of this chapter).
· Residual estimated risk, considered as that occurring after the application of safeguards in a
simulated scenario or in the real world.
· Risk threshold is the value established as a basis to compare and decide whether the estimated
risk is acceptable or can be assumed.
3.5.4. ATTRIBUTES
MAGERIT considers two attributes, each individual risk and the relationship between the risks:
· Restriction on each type of feasible impact given the vulnerability of the asset (or group of
assets) to a threat (or set of threats).
· Risk spreading for assets depending on each other.
3.5.5. METRICS
In the simplest case, vulnerability has been estimated as a frequency (e.g. of failures in a component)
and impact has also been estimated as the monetary value of the replacement (of the component).
Thus, the estimated risk can be assessed by the accumulated impact over a period of time, for
example, one year. Risk is the replacement cost of that component over the year, and it can be
compared both to a specific threshold and to the annual cost of the safeguards used to reduce it. If
the component fails each month as an average and its replacement costs is 100,000 monetary units,
then the annual risk will be the multiplication of the two, that is, 1,200,000 monetary units. In this
simple case (vulnerability as frequency and impact in money), the risk metrics will be:
Annual cost of the risk (in monetary units) Risk

Less than 50,000 Very low
Around 500,000 Low
Around 5,000,000 Medium
Around 50,000,000 High
More than 100,000,000 Very high
In the most complex cases, when vulnerability cannot be treated as a frequency or impacts do not
have a monetary value, MAGERIT estimates the risk metrics with the help of a qualitative table or
equivalent matrix with the following levels:
Risk level Impact Vulnerabilities (frequencies)

Very low Very low Very low, low, medium, high
Low Very low Very high
Low Very low, low, medium
Medium Very low, low
Medium Low High, very high
Medium Medium, high, very high
High Very high
High High Low, medium, high, very high
Very high Very low
Very high Very high Low, medium, high, very high
Impact RISK
Very high High Very high Very high Very high Very high
High Medium High High High High

Medium Low Low Medium Medium Medium
Low Low Low Low Medium Medium
Very low Very low Very low Very low Very low Low
Vulnerability Very low Low Medium High Very high

If the project’s objective is to implement an initial and generic Risk Analysis and Management, the
risk estimation technique is aimed at separating the risks into two groups. In this generic application,
there are few elements for discriminating the vulnerabilities and the impacts in a high number of levels.
Thus, reducing the matrix above to, for example, the three levels, low, medium and high is not only
sufficient but logical.
The metrics are the same for the different classifications of stimated risks, be they intrinsic or residual
risks, threshold risks or acceptable risks, are irrelevant for purposes of their metrics.
3.6. Safeguard Functions, Services and Mechanisms
MAGERIT model


- Risk
- Safeguards
3.6.1. DEFINITION
MAGERIT defines the safeguard function or service as an action that reduces risk.
MAGERIT defines the safeguard mechanism as the physical or logical procedure or device that
reduces the risk.
In order to reduce risk, the existing safeguards should be improved or new ones should be
implemented. MAGERIT distinguishes between the most abstract entity, called safeguard function
or service, and the specific entity called safeguard mechanism.
The distinction between “safeguard function” and “safeguard service” reflects the fact that
terms have been coined by different standards, although they embrace a similar concept. MAGERIT
maintains both terms to facilitate the association with the original regulatory standards. Service is
used in the ISO International Standard 7498-2 on the Security Architecture of the basic reference
Model for the Open Systems. Function is used in the Information Technology Security Evaluation
Criteria (ITSEC).
IMPACT VULNERABILITY
é é
î í
RISK
reduces decision reduces

ê
SAFEGUARD
FUNCTION/SERVICE
“corrective” “preventive”
SAFEGUARD
MECHANISMS
The safeguards function or service is an action-type action (or non-action-type action, by

omission), as it is the result of a decision taken to reduce a risk (it is not an event-type action). This
action-type action is materialized in a corresponding safeguard mechanism which works in two
possible ways, either by:
· “Neutralizing” or “blocking” another action, which is the event of the threat materialization in
the form of aggression, with the reduction of the vulnerability prior to the vulnerability event
of that materialization.
· Modifying the security state of the attacked asset (which has already been modified by the
impact resulting from the materialized threat), with the reduction of the impact subsequent to the
event causing that impact.
3.6.3. TYPES
The safeguard functions, services and mechanisms are classified, according to the way they act,
into two main types:
• Preventive functions or services that act on the vulnerability (before the aggression) and
reduce the potentiality of the materialization of the threat (not the generic possibility of the
threat, which is independent from the attacked asset). This type of function or service acts, in
general, against human threats.
• Corrective or reestablishing functions or services that act on the impact (after the
aggression) and reduce its seriousness. This type of function or service acts, in general, on all
types of threats.
The safeguard functions or services classified according to the way they act can also be classified
by the following:
• Threats that generate vulnerabilities for the preventive functions or services.
• Impacts for the corrective functions or services.
These two complementary classifications according to vulnerabilities, threats and impacts have the
advantage of facilitating significantly the functioning of the processes submodel, as we will see in
chapter 9 of this Handbook.
The safeguard functions and services can be broken down further within the two main preventive or
corrective groups:
Preventive Safeguards
- The awareness, information and training of the personnel of the organization and of those
persons who have a stable labor relationship with the company are treated as a type of “structural”
safeguard (linked to the company’s global structure and not just to its information systems). The
importance of this aspect is justified by the essential role played by the human factor.
- Deterrence is a type of safeguard that makes the potential intentional human aggressor think twice
before starting an aggression, and consider the adverse personal consequences. This type of
safeguard normally requires wide, but at the same time selective publication. One of the better
known examples of this type of dissuasive safeguard is the exemplary sentencing or punishment of
the guilty aggressor.
- Prevention is a type of protective safeguard that does not prevent the initiation of the
materialization of the threat, but rather its completion and consequently its full impact. An example of
preventive safeguards is the control of access.
- Preventive detection can be dissuasive (if its installation is known by the potential aggressor, who
is aware that he can be caught).
Corrective or Reestablishing Safeguards
- Corrective safeguards prevent the spread of an impact. For example, an impact on the integrity of
a piece of information detected because of its anomalous nature will lead you to take measures to
stop the spread of that information and to verify its source.
- Recovery safeguards repair damages or reconstruct elements damaged in order to recover the
security state previous to the aggression. When the recovery of functional capacity is not enough,
other safeguards can be adopted such as the transfer of the risk to third parties (e.g. insurance
companies) or the filing of a lawsuit.
- The Corrective Detection, “Monitoring” or Corrective Follow-up of the impact in the event
of a threat that has already materialized, is the necessary first step of an effective corrective safeguard
(many aggressions are detected either too late or never). Information matching is a good example of
a detection safeguard.
The safeguard mechanisms, classified according to whether they are preventive or corrective, are
broken down further depending on the “resource” used by the organization (organizational or
physical mechanisms, specific software, insurance policies). These resources in turn can be
associated to assets or groups of assets classified in this submodel (environment, information system,
information, functionality, other assets), providing the types of mechanisms related to basic
architecture, supports, communications, operation, package procurement, applications development,
etc.
The classification of mechanisms according to the resources used has the advantage of facilitating the
operation of the Procedures Submodel’s, as we will see in chapter 9 of this Handbook.
3.6.4. ATTRIBUTES
Generic effectiveness is an attribute of a safeguard function or service that goes from the intrinsic
vulnerability and the full impact of an asset, to an effective vulnerability and impact (which
the function or service take into account).
Specific effectiveness is an attribute of a safeguard mechanism. This effectiveness usually is non-

specific (it reduces the risk of different assets) and thus is associated to the effectiveness of other
safeguard mechanisms. It also changes the intrinsic vulnerability and full impact, of the asset
depending on the type of threat, effective vulnerability and impact, respectively (which the
safeguard mechanism takes into account).
3.6.5. METRICS
The safeguard functions or services do not have their own metrics, but use a metrics derived from
the reducing power of the risk. The generic effectiveness value of a safeguard function or service
is determined by the experience of the security analysts and depends on the type of safeguard
function or service (the way it acts) and on the type of threat.
The safeguard mechanisms have a metric directly linked to their technical or organizational cost
translated into pesetas.
The new types of threats (particularly the intentional threats, whether on-site or remote, in other
words, depending on whether they require a physical presence or a telecommunications system)
require new types of safeguards. MAGERIT has begun to overcome the static protective model,
often represented as a “fortress” protecting assets and whose specific “breaches” or vulnerabilities
should be made impermeable with specific safeguards.
The safeguards for the current information systems are almost like “open cities,” and belong to a
dynamic and flexible security model. This model treats the safeguard mechanisms as dynamic
“agents” (as they grow, “patrol” and transmute in order to outwit the aggressor’s intelligence) in
each group of assets (that is, in the basic architecture, supports, communications, operation and
development of applications). The new model offers a greater approximation between the types of
safeguard mechanisms and the types of assets.
4. EVENTS SUBMODEL
As we have already mentioned, the MAGERIT method is based on a Risk Analysis and
Management Model that is comprised of three Submodels:
· Elements Submodel
· Events Submodel
· Processes Submodel
MAGERIT MODEL
ELEMENTS Submodel EVENTS Submodel PROCESSES Submodel

· Assets · Static · Planning

· Threats · Organizational dynamic · Risk analysis
· Vulnerabilities · Physical synamic · Risk management
· Impacts · Safeguard selection
· Risk
· Safeguards
The Events Submodel establishes the relationships over time of the “components” provided by the
Elements Submodel, which we studied above. The Processes Submodel provides the functional
description (explanatory scheme) of the security project that is going to be established.
As we mentioned in the previous chapter, the structure and operation of Risk Analysis and
Management models typically has been presented as a “fortress”. In this conceptual framework the
assets are inside, the threats are the enemy outside, the safeguards are the walls and the
vulnerabilities are “breaches” in the wall. The attacking threats take advantage of the breaches and
impact the assets. The fortification of the safeguard walls reduces the breaches-vulnerabilities and
permits the repair of impacts.
This static view of security is becoming more and more outdated due to the new types of threats
(more intentional) and assets (information systems as “open cities”). These require new types of
safeguards: in every “development” we must “embed” dynamic agents that will grow with the
development, will “patrol” it and will camouflage themselves in order to deceive ever more intelligent
attackers.
In a changing model situation such as that described above, it is especially important to accurately
describe the aforementioned conceptual framework. MAGERIT provides a method for the Events
Submodel with three “views” associated with the tools that help to automate the methodology:
• The relational static view of the Events Submodel shows the general relationships among the
Entities described in the Elements Submodel (with Safeguards that can be broken out into
Function/Service and Mechanism). This view is needed to establish the Logical Model of data,
which is required for all support tools for the MAGERIT application.
• The organizational dynamic view of the Submodel represents the operation of the interaction
of the MAGERIT Elements in detail and is needed to:
- support the MAGERIT logical Processes Submodel,

- structure the Procedures Handbook for users,
- articulate the techniques for risk identification and safeguards selection,
- construct support tools for the MAGERIT application.
• The physical dynamic view of the Submodel offers another way of articulating the operation of
the MAGERIT elements with an intermediate level of detail or “granularity” between the two
aforementioned views. This view is needed to:
- support certain techniques for risk calculation and safeguards selection, such as simulation
(and, in this context, to the support tools of the MAGERIT application),
- provide consistent elements based on state-action models which have been widely tested in
the physical world.
To summarize, the simple relational static view is essential for understanding MAGERIT and
shows the “Data Modeling” technique that is recommended, for instance, in Metric v.2.1. The
organizational dynamic view is helpful for a deep understanding the operation of the MAGERIT
stages. The physical dynamic view is a complementary and more complex approximation to the
reality described by the two other views, although it is not essential for understanding MAGERIT
and is only necessary in certain situations (for instance, as a “skeleton” for advanced supporting
products or tools of MAGERIT).
4.2 Relational static view of the Events Submodel
MAGERIT MODEL


· Threats · Risk analysis
· Vulnerability · Organizational dynamic · Risk management
· Impacts · Physical dynamic · Safeguard selection
· Risk
· Safeguards
The relational static view of the Events Submodel depicts the scheme of general relationships
among the entities described in the previously analyzed Elements Submodel. MAGERIT depicts the
basic scheme of the relationships according to the following diagram:
Asset Threat
frecuency of materialization
Impact Vulnerability
Risk
reduces reduces
decision
Safeguard
‘corrective’ Function/Service ‘preventive’
Safeguard
Mechanisms
The static Events Submodel simply shows the direct relationships among the entities
(represented by the arrows in the above diagram).
• Direct relationships of the asset; the asset:

- can be a component of or dependent on another asset
- can have vulnerabilities with regard to different threats
- can be affected by accumulative impacts from different threats
- can be protected by a safeguard mechanism
• Direct relationships of the threat (if it materializes); the threat:

- can be a component of or dependent on another threat
- must exploit a vulnerability in order to affect an asset
- can cause an impact on the asset.
• Direct relationships of the vulnerability; the vulnerability:

- is related to an asset
- can be exploited by a threat and materialize as an attack
- can be affected by a safeguard function or service
- contributes to the risk
• Direct relationships of the impact; the impact:

- is related to an asset
- can be caused by the materialization of a threat
- can be affected by a safeguard function or service
- contributes to the risk
• Direct relationships of the risk; the risk:

- is the vulnerability of an asset with regard to a threat
- is the impact caused by the vulnerability of an asset
- can be related to a safeguard function or service.
• Direct relationships of the safeguard function or service; these

-are related to a risk
- can complement another safeguard function or service
- can affect the impact of a threat
- can affect the vulnerability of a threat
- allow to choose among different safeguard mechanisms
• Direct relationships of the safeguard mechanism; the safeguard mechanism

- materializes a safeguard function or service
- protects an asset
- can affect the impact of a threat
- can affect the vulnerability of a threat
4.3 Organizational dynamic view of the Events Submodel
MAGERIT MODEL


· Vulnerability · Risk management
· Risk
4.3.1. ORGANIZATION, DOMAIN AND ENVIRONMENT
This view of the Submodel, which is more detailed and complex than the previous view, is shown in
the following diagram. It starts with an initial demarcation the Domain Information, which MAGERIT
helps to analyze from the perspective of security, as well as from the perspective, within the
demarcated Domain Environment, of the difference between the parts that are internal and external
to the organization. The Domain is made up of assets, organized so as to facilitate the analysis of their
security and assurance management.
This Domain, which always is defined by its security “state”, can be subject to materializable threats,
which are “event” type actions that modify this security state. The existing safeguards permit other
“performing” type actions, which also modify the security state and which respond in advance or
with delay, but in “real” time (in other words, in order to influence the event).
The main Actor of this Domain is the person Responsible for the Domain or for the Assets to
be protected. This person determines their value and security requirements translating them into
targets, decision criteria or decisions.
ORGANIZATION
(ENVIRONMENT)
DOMAIN
COMMUNICATIONS
CONDITIONS
ASSET
affec
RESPONSIBLE THE THREAT
FOR OR ATTACK
ASSET have ANALYSIS
VULNERABILITY
INT. EXT.
SUBSCENARIO
exploi
THREAT
AGRESSION
ATTACKER
execute
IMPACT
decide
ACCEPTABLE
RIESK ESTIMATE
propone RISK
THRESHOLD
THE SAFEGUARDS
SECURITY
compariso MANAGEMENT
OR
ADMINISTRATOR analyze
DEFENSE
ANALYSIS
SAFEGUARD ACCEPTABLE SUBSCENARIO
propose FUNCTION RESIDUAL RISK
decide
SAFEGUARD
MECHANISM
4.3.2 THE MATERIALIZATION OF THE THREAT AS A TRIGGERING EVENT
The threat event triggers one or more possible malfunctions in the studied domain, according to an
intrinsic distribution of frequencies, which are imprecise and generally small, (whether historical or
foreseeable), and are linked to the vulnerabilities of the domain assets.
Each malfunction can remain in a latent state until it becomes active as a new event or can produce
one or more disasters, which in turn can act as new events triggering other disasters, following an
“infection” analogy. This recurring process is usually represented as a “fault tree” or “events-
disasters” techniques. The tree can also be followed in the opposite direction (to determine the
triggering factors and its probable occurrence frequencies of the potential disasters).
Depending on the triggering “materialization”, the Submodel works dynamically as an “assurance”

scenario (action to obtain security) with two subscenarios:
• the threat or “attack” analysis subscenario relates to risk analysis. It starts with a
“sequence”, i.e. an “event-malfunction-disaster” chain or tree branch; and analyzes the real or
simulated consequences of this “attack” on one or more types of domain assets, whether they be
components of the information system or other kinds of assets (infrastructure, personnel, income,
credibility, image, etc.).
• the safeguards management or “defense” analysis subscenario relates to risk

management and describes, in view of each “attack” sequence, the articulation and management
of the appropriate safeguard functions or services (which operate in a more or less specific
manner).
4.3.3 THE THREAT ANALYSIS SUBSCENARIO
The main actor of the attack subscenario is the attacker, which can be personalized or not
depending on the needs of the analysis and the nature of the threat (accidental or deliberate, resulting
from an active error or from a passive negligence).
For each asset, the analysis of the attack subscenario considers whether the virtual or potential
threat has materialized into an attack due to the vulnerability of the asset and specific to the threat.
The attack triggers different levels of impact (i.e. deterioration of the asset), which can be valued in
economic terms depending on the nature of the asset.
The vulnerability, which is common to the threat and the asset (or belongs to the relationship
between the two, depending on one’s preference and the needs of the analysis), can be understood
as the forecasted potentiality or “proximity” of the materialization of the threat into an attack. As we
have seen in the Elements Submodel, the vulnerability as an inherent potentiality of the asset mostly
depends on the “isolation” of the asset, i.e., its physical (presential or qualified) or logical
(competential or instrumental) accessibility.
The impact, which is considered as a characteristic of the asset that reduces its security state, lets us
measure the “seriousness” of the consequence generated by the attack in terms of “critical” levels
related to the security substates of the affected asset (A-C-I-Av, authentication, confidentiality,
integrity, availability).
The vulnerability and its impact on the asset together determine the estimated risk resulting from the
subscenario of the “attack” on the asset. Both factors are combined in an “asymmetrical” risk
metric. In other words, if risk is represented in this scenario by a simple technical matrix relating the
levels of impact and vulnerability, we consider that the impact has a greater influence on the risk than
on the vulnerability.
This risk measurement underlies all possible classifications and/or prioritizations of the different
consequences of the attack subscenarios. This prioritization is helpful for arguing the alternative
potential decisions that will permit the systematic neutralization of the attack in the most cost effective
fashion.
4.3.4. SUBSCENARIO OF SAFEGUARD ANALYSIS AND MANAGEMENT
The determination of the risk on account of the threats to the assets concludes the previous
subscenario with the determination of the estimated risk and opens a next “defense” or safeguard
analysis and management subscenario, which is characterized by decision making.
The defense subscenario there begins by comparing the risk estimated in the previous attack
subscenario to an acceptable risk threshold, which characterizes the security state of the domain
as a minimum target.
The residual risk is obtained after the safeguard implementation by re-evaluating the estimated risk
calculated through all the processes of the attack subscenario (thus, the residual risk takes them
into account). The subsequent development depends on the scenario in which the real or simulated
model is used.
• If the residual risk is lower than the acceptable risk threshold we consider that the defense
subscenario has fulfilled its goal and the process continues as follows:
- if the scenario of the process is real, we have returned to the situation previous to the
triggering of the event, and the domain is ready to face new threatening new events;
- if the scenario of the process is simulated, (for instance, after carrying out the Risk
Analysis and Management using MAGERIT), we can move on to other stages of the
information systems security management.
• If the residual risk is higher than the acceptable risk threshold we consider that the
defense subscenario has NOT fulfilled its goal and the process continues as follows:
- if the scenario of the process is real, the domain has suffered a deterioration and the
process must be interrupted in order to introduce the appropriate safeguards before an
attack subscenario with new threatening events reappears.
- if the scenario of the process is simulated (for instance, in an application stage of the
Risk Analysis and Management with MAGERIT), MAGERIT proposes including new
safeguards for simulating the entire threat analysis of the previous subscenario, until the
residual risk is lower than the acceptable risk threshold (or until it changes).
4.3.5 SAFEGUARDS MANAGEMENT
The inclusion of safeguards depends on the risk, in other words, in the short term on the immediate
impact on the asset and the asset’s vulnerability to the threat, and in the medium term on the types of
assets and threats themselves.
The safeguards operate at different times and in different ways. Some of them act prior to the
materialization of the threat (awareness, dissuasive and preventive safeguards). Others are a
consequence of or consecutive to the materialization (corrective and restoring safeguards), while
other safeguards operate before or after depending on the circumstances (detection safeguards).
The defense subscenario incorporates two levels of safeguards:
• the functional incorporation of safeguard functions or services helps in the aforementioned

decision-making process;
• the material incorporation of safeguard mechanisms is characterized by its efficacy: the same
safeguard mechanism will be more or less effective depending on the scope of the attack (i.e. the
materializability of the threat) and also:
- for the “attack” stages with an already materialized threat, the efficacy of the “corrective” or
“restoring” safeguards measures the degree of impact reduction on the asset;
- for the “attack” stages with a non-materialized threat, the efficacy of the “preventive”
safeguards measures the degree of vulnerability reduction as the potential of threat
materializing on the asset.
The main actor of this safeguard analysis and management or “defense” subscenario is the person in
charge of security administration functions opposed to the attacker. His/her performance depends
to some extent on the criteria and decisions made by the person in charge of the protectable
assets of the domain (adopted during the previous attack subscenario), and in the ultimate instance
depends on the person in charge of the operation of the domain. The security administrator role
can be personalized or not depending on the nature of the domain to be protected and if the security
management process requires it.
4.4 “Physical” dynamic view of the Events Submodel
MAGERIT MODEL

6 basic entities 3 main types 4 typified stages

· Vulnerabilities · Risk management
· Risk
· Safeguards
The study of the “physical” dynamic view of the Events Submodel

is not indispensable for understanding MAGERIT so, you can
go directly to Chapter 5 “Processes Submodel”.
The physical dynamic view is another way of articulating the operation scenarios of the MAGERIT
elements. It relates the Submodel of the specific security elements to the more abstract entities and
relationships used in other physical models whose operation is widely tested and which have
numerous analysis and simulation techniques, as well as management tools. This view can be
necessary to support certain sophisticated risk calculation and safeguards selection techniques and
tools. It can also support specialists who use the MAGERIT in order to solve critical problems that
need specific simulation models to observe their operation and determine the optimal strategic
parameters for the security management.
4.4.1 A VIEW BASED ON STATE CHANGES
MAGERIT allows you to identify the “security state” of the assets domain by selecting for each type
of threat and for different potential situations:
• At any time in the life of the organization (a risk audit).

• The initial security state specification of the domain to obtain the Processes Submodel
(“known” initial state).
• The final security state characterization of the domain, which must be done at least
twice during the security study and management cycle:
- when starting the assurance process (“intended” final state of the domain)
- when the process is completed (“reached” final state of the domain);
• the comparison between both final states (“intended” and “reached”) allows you to
make decisions on the “quality evaluation” (on security matters) about the obtained
“product,” as well as the “process” to obtain it.
In this “view” of the Submodel, the security entities are identified with variables and parameters,
whether of state or of action.
4.4.2 A SUPPORT VIEW OF THE SIMULATION MODELS
However, the security entities also can be identified with variables and parameters of the level
(equivalent to state parameters) and flow (equivalent to action parameters) which characterize the
dynamic systems models and determine their simple simulation (based on the qualitative cause-effect
relationship).
Thus, this view of the Submodel is essential for MAGERIT to be able to describe the operation of
the aforementioned scenarios with enough detail to handle them with known simulation languages and
tools.
The following diagram shows the variables and parameters of level (of state) and flow (of action)
with the help of the main classic symbols of the system dynamic technique used by Forrester. In
these models it is necessary to represent:
- “flows” (as a level variation),

- levels (as a flow accumulation),
- transmission channels of information or materials (arrows),
- certain auxiliary variables (quantities that contribute to the flow calculation),
- relationship among variables
- constants or parameters.
For purposes of simplicity, the diagram does not show two symbols: the “clouds,” i.e. the process
start and finish inputs and outputs, interpretable as practically inexhaustible and lacking in interest;
and the delays in the communication channels which are only necessary for more complex simulation
models.
(Relationship) (Exogenous Variable)
SECURITY
ESTADO (nivel) 1
STATE OF THE
DE SEGURIDAD
ASSET
DEL ACTIVO
THREAT / AGRESSION
VULNERABILITY
Action (flow)
That reduces
The Impact (Parameter)
(Auxiliary Variable)
ACCEPTABLE RISK
SECURITY REDUCED THRESHOLD
ESTADO (nivel) 2
STATE OF THE
DEL ACTIVO
ASSET
ESTIMATED RISK
Action (flow)
That extends
The SAFEGUARD
(FORRESTER TECHNICAL
SECURITY RECOVERED
ESTADO (nivel) 3
STATE OF THE
ACEPTABLE
DE SEGURIDAD
ASSET
4.4.3 “PHYSICAL” INTERPRETATION OF THE SECURITY ELEMENTS
In a security domain previously delimited and made up of the complete set of its assets, what really
matters in this view of the Events Submodel is the materialized attack (threats are only non
materialized or potential attacks).Keeping this in mind, the physical dynamic view of the Submodel
interprets each one of the security elements as follows:
• Each attack is presented under this dynamic approach (instantaneous) as an action (or lack of
action) of the event type (beyond the decision-making of the person in charge of the assets and
of the security administrator). This attack modifies the “real security state” (its “level”). In other
words, it leads it from a state 1, before the event, to a subsequent state 2 (real in case of an
attack and potential if it is only a threat).
• Vulnerability is a characteristic or feature of the relationship between an asset and a threat

and acts as a “mediator” or “predictor” between the threat and the asset subject to a change in
its security state.
• Impact is the measure of the result of the attack on the asset, i.e., the measure of the flow of
the change of level-state of security of the asset.
• Risk is a level indicator of the domain security state that allows you to make a decision by
comparing it with another predetermined state level (acceptable risk threshold). The decision
making process can lead to two options:
- either to incorporate a new value for the action/flow variable called safeguard function or
service and to repeat the previous cycle;
- or to consolidate the Submodel results, since the analysis and management cycle has
concluded and a new security stage is started, focused on selecting and incorporating
specific security mechanisms .
• The safeguard function or service is an action or flow type action (or omission) resulting
from a decision aimed at reducing a risk. It materializes (through a “safeguards selection”) in the
corresponding safeguard mechanism, which operates in two possible, and generally
alternative, ways:
- “neutralizing” or “blocking” another action/flow, the materialization of the threat into
an attack;
- modifying the new security state/level of the attacked asset, reducing the impact caused
by the aggression (from the level 2 state to the new level 3 state).
5. PROCESSES SUBMODEL
MAGERIT Model


· Vulnerabilities · Physical dynamic · Risk management
· Impacts · Safeguards selection
· Risk
· Safeguards
MAGERIT is based on a Risk Analysis and Management Model that is comprised of three
submodels:
· Elements Submodel
· Events Submodel
· Processes Submodel
Of the two submodels that we have already studied, the Events Submodel establishes the
relationships of the “components” provided by the Elements Submodel over time. The Processes
Submodel provides the functional description (“explanatory scheme”) of the security project that is
going to be established.
When designing a specific security project, the explanatory scheme, i.e., the Processes Submodel
helps on the one hand, to follow the general procedure and on the other, to adapt it to the specific
problem, always taking into account the security policy established by the management of the entity
concerned. If this adaptation is complex or consists of uncertain elements, the project must count on
the assistance of an expert in information systems security.
5.2 Structure of the Submodel
The Processes Submodel of the MAGERIT model groups together and orders the actions to be
taken over the course of the Risk Analysis and Management project. This working framework
defines:
• A structure for the project that helps guide the working group and allows you to involve in the
project the persons responsible for the domain to be protected and the users.
• A collection of products to be obtained.
• A collection of techniques to obtain the products.
• The functions and responsibilities of the different “actors” in the project.
MAGERIT’s Processes Submodel formalizes and describes in detail the successive actions and is
structured in three levels: stages, composed of activities, which are in turn broken down into
tasks.
• The STAGES are comprised of a set of activities and correspond to the term phase used in
Metric V.2.1. The use of the stages is similar to the phases in Metric V.2.1. In other words, it
establishs the decision-making milestones and the delivery of products, requires a formal
acceptance of its results at the end of each stage, and uses the final product of each stage as the
beginning of the following one.
• The ACTIVITIES have the same meaning as in Metric V.2.1 and are comprised of a set of
tasks, which are generally functional.
• The TASKS have the same meaning as in Metric V.2.1. The description of each task specifies
the following:
- actions to be carried out

- actors (who take part in or who is affected by execution of the actions)
- products and documents to be obtained as a product of the actions
- validations and approvals of the obtained results
- wording of the techniques to be used (taken form MAGERIT’s Techniques Handbook).
As in Metric V.2.1., the term “unities” is used in a broad sense so as to include different areas within
an Administration or Entity (General Secretaries, Independent Agencies, Under Secretaries, etc.).
For the Processes Submodel, the Procedures Handbook systematically

establishes the practical way to carry out a Risk Analysis and Management
project. In each Stage and for some Activities these comments signal the
milestones about what to do and the potential difficulties that can arise in the
process.
5.3 Stages within MAGERIT
MAGERIT proposes the four following stages:
Stage 1. Planning Risk Analysis and Management
This stage establishes the considerations necessary to initiate the Risk Analysis and Management
Project; and allows you to investigate the appropriateness of carrying it out; to define the objectives
to be met and the domain (scope) to be included; to plan the material and human resources needed
to carry it out; and to launch the project.
Stage 2. Risk analysis
This stage allows you to identify and assess the elements involved in the risk; to obtain an evaluation
of the risk in the different areas of the domain; and to estimate the desirable risk thresholds.
Stage 3. Risk management
This stage allows you to identify the potential safeguard functions or services that reduce the
detected risk; to select the acceptable safeguards depending on those that are already in place and
the constraints; to simulate different combinations and to specify those finally selected.
Stage 4. Safeguard selection

This stage allows you to select the safeguard mechanisms to be implemented; to design an approach
to the implementation of the selected safeguards; to establish the follow-up mechanisms for its
implementation; to compile the working documents for the Risk Analysis and Management Process;
to obtain the final documents of the project; and to give presentations of the results at different levels.
5.4 Overview of the Stages of the MAGERIT process
STAGE 1:
PLANNING
Activities:
1.1: Appropriateness of
implementation
1.2: Definition of domain and ïð Objectives, strategy, security policy
objectives
1.3: Project organization and
ò
planning
1.4: Project launching Planning & other
phases of IS security
ò
STAGE 2: STAGE 3: ñ
STAGE 4:
RISK ANALYSIS RISK MANAGEMENT
Activities: Activities: SAFEGUARD SELECTION
ð 2.1: Gather information 3.1: Interpret RISK Activities:
ð ð 4.1: Identify safeguard
2.2: Identify & group ASSETS 3.2: Identify & estimate
2.3: Identify & evaluate safeguard functions and mechanisms
THREATS services 4,2: Select safeguard mechanism
2.4: Identify & estimate 3.3: Select safeguard 4.3: Specify mechanisms to be
VULNERABILITIES functions and services implemented
2.5: Identify & assess IMPACTS 3.4: Achieve objectives 4.4: Plan implementation
The above diagram represents the (repetitive) cycle of the stages of the process covered by
MAGERIT, which include the Risk Analysis and Management stage within the security
management of information systems. Likewise, it shows the links of this MAGERIT cycle with the
“objectives, strategies and security policy” stage (which is prior to a previous and concomitant with
MAGERIT) and with the “safeguard mechanism planning” stage (which starts the rest of the security
management).
Each stage includes a variable number of activities and each activity a variable
number of tasks. Each task has a specific content and shares with the others a
panoply of techniques. In general, all the tasks must be executed and the
execution must follow an order: when describing them, you must specify, if
applicable, the special situations that entail a modification in their action (either
The complete outline for the Stages, Activities and Tasks of the MAGERIT Processes Submodel is
as follows:
STAGE 1: PLANNING RISK ANALYSIS AND MANAGEMENT
• Activity 1.1: Appropriateness of implementation

- Task 1.1.1: (single) Clarify the appropriateness of implementation.
• Activity 1.2: Definition of domain and objectives

- Task 1.2.1: Specify project objectives.
- Task 1.2.2: Define domain and project limits.
- Task 1.2.3: Identify environment and general constraints.
- Task 1.2.4: Estimate size, cost and returns of the project.
• Activity 1.3: Project organization and planning

- Task 1.3.1: Evaluate loads and plan interviews.
- Task 1.3.2: Organize the participants
- Task 1.3.3: Work planning.
• Activity 1.4: Project Launching

- Task 1.4.1: Adapt questionnaires.
- Task 1.4.2: Select evaluation criteria and techniques for the project.
- Task 1.4.3: Allocate the necessary resources.
- Task 1.4.4: Create awareness (information campaign).
STAGE 2. RISK ANALYSIS
• Activity 2.1: Gather information

- Task 2.1.1: Prepare the information.
- Task 2.1.2: Conduct interviews.
- Task 2.1.3: Analyze the gathered information.
• Activity 2.2: Identify and group assets

- Task 2.2.1: Identify assets and groups of assets.
- Task 2.2.2: Identify existing safeguard mechanisms.
- Task 2.2.3: Assess assets.
• Activity 2.3: Identify and evaluate threats

- Task 2.3.1: Identify and group threats.
- Task 2.3.2: Establish the fault-trees resulting from threats.
• Activity 2.4: Identify and estimate vulnerabilities

- Task 2.4.1: Identify vulnerabilities.
- Task 2.4.2: Estimate vulnerabilities.
• Activity 2.5: Identify and assess impacts

- Task 2.5.1: Identify impacts.
- Task 2.5.2: Define impacts
- Task 2.5.3: Assess impacts.
• Activity 2.6: Evaluate Risk

- Task 2.6.1: Evaluate intrinsic risks.
- Task 2.6.2: Analyze existing safeguards functions.
- Task 2.6.3: Evaluate the effective risk.
STAGE 3. RISK MANAGEMENT
• Activity 3.1: Interpret Risk

- Task 3.1.1: (single) Interpret risks.
• Activity 3.2: Identify and estimate safeguards functions and services

- Task 3.2.1: Identify safeguard functions and services.
- Task 3.2.2: Estimate the effectiveness of safeguard functions and services.
• Activity 3.3: Select safeguards functions and services
- Task 3.3.1: Apply selection parameters.
- Task 3.3.2: Reevaluate the risk.
• Activity 3.4: Achieve objectives

- Task 3.4.1 (single): Determine the objectives achievement.
STAGE 4. SAFEGUARDS SELECTION
• Activity 4.1: Identify safeguard mechanisms

- Task 4.1.1: Identify potential mechanisms.
- Task 4.1.2: Study the implemented mechanisms.
- Task 4.1.3: Incorporate constraints.
• Activity 4.2: Select safeguard mechanisms

- Task 4.2.1: Identify mechanisms to be implemented.
- Task 4.2.2: Evaluate the risk (of the selected mechanisms).
- Task 4.2.3: Select mechanisms to be implemented.
• Activity 4.3: Specify mechanisms to be implemented

- Task 4.3.1 (single): Specify mechanisms to be implemented.
• Activity 4.4: Plan Implementation

- Task 4.4.1: Prioritize mechanisms.
- Task 4.4.2: Evaluate the necessary resources.
- Task 4.4.3: Produce tentative time charts.
• Activity 4.5: Integrate results

- Task 4.5.1 (single): Integrate results.
STAGE 1: PLANNING RISK ANALYSIS AND MANAGEMENT
MAGERIT Model

· Planning
· Assets · Static · Risk analysis
· Threats · Organizational dynamic · Risk management
· Vulnerabilities · Physical dynamic · Safeguards selection
· Impacts
· Risk
· Safeguards
STAGE 1:
PLANNING
Activities:
implementation
objectives
planning ò
1.4: Project launching

Planning & other
ò
STAGE 2: STAGE 3: ñ
STAGE 4:
ð 2.1: Gather information 3.1: Interpret RISK Activities:
2.2: Identify & group ASSETS ð 3.2: Identify & estimate ð 4.1: Identify safeguard
THREATS services 4,2: Select safeguard mechanism
6.2.1 Objectives
The main objective of the Planning Stage is to establish and define the general reference framework
for every Risk Analysis and Management Project.
The other complementary objectives are the following:
- To encourage the management of the unit involved.
- To demonstrate the appropriateness of carrying out Risk Analysis and Management
- To transmit Management’s commitment to carry out Risk Analysis and Management
- To create the conditions for the proper development of the project
6.2.2 Contents
As is the case with any other specific planning, the Risk Analysis and Management Stage falls within
the short and medium term strategic planning of the organization. It is not only logical, but also helpful
that many of the concepts of this MAGERIT Stage take up and adapt the elements of Phase 0 of
“Information Systems Planning” from Metric V.2.1.
Thus, the main aim of the organization’s strategic planning is to define the strategic long term
goals (regarding future functionalities and services, prospects for growth and/or forecasts of
evolution), as well as to estimate the information needs depending on the goals (considering the
environment in which the organization operates, and the vision of the organization’s directors).
For a better understanding of the chapter, we must distinguish between three concepts:
aim, goal, and objective. The organization has goals, and their respective subdivisions
(units, deparments, domains, etc.); the functions have aims (inherent motives), the
projects and their components (stages, activities, tasks, etc.) have objectives (which
cannot conflict with the broader goals of the organization or its subdivisions or the
logic aims of their functions, but which are distinguishible from both).
The Planning Stage specifies the “tactical” execution of the strategic goals defined in the Strategic
Planning, with two relevant results:
• The precise definition of the Risk Analysis and Management Project and its domain.
• The tight scheduling of the project, taking account of the necessary priorities and resources, in
other words:
- Defining milestones to consider in the development of the project
- Obtaining results that serve as a spring board for the development of the project
As a logical consequence, the Planning Stage requires:
• A more restricted organizational scope and a shorter time span.
• An ongoing refinement and review of the project’s development, in order to assess the fulfillment
of the schedule within the framework of the goals established in the strategic planning (and
keeping in mind that the planning of the implementation of the security measures is part of another
Stage of this Processes Submodel).
• The indispensable participation of the persons in charge of the units involved as they must define
the objectives and strategies for the evolution of their units, and promoter all the work aimed at
obtaining the security of their systems. This is one of the basic challenges of a constantly evolving
environment.
In summary and as a general framework, this Stage covers the following issues:
• Justification and appropriateness of undertaking the project.
• Definition of project objectives and domain.

• Project planning, taking account of the participants, the necessary resources and the schedule for
carrying it out.
• Customization of the techniques to use in the project activities.
This Stage, which launches the project, common to all projects, is important and tends to be undervalued. It is generally
the responsibility of those in charge of directing the project since the results involve contractual commitments, with
economic and even legal consequences. In Public Administration, the content of this stage reflects the development of
the contract’s technical conditions to execute and launch the project.
6.2.3 Summary of the Activities’ contents
MAGERIT defines four activities for the Planning Stage of a Risk Analysis and Management Project:
1. Appropriateness of implementation
We study the basic aspects for carrying out a Risk Analysis and Management Project in order to
determine the appropriateness of implementation. We initiate a first approach to the project’s
objectives, the domain - or scope - and the resources necessary for executing the project.
2. Definition of domain and objectives
We define the project’s final objectives, domain and limits. We do and initial identification of the
environment and general constraints to be considered. We establish different groups of personnel
(managers, technicians, users, etc.) who will gather information.
3. Project organization and planning
We determine the workload that the execution of the project entails and the characteristics of the
working group. We plan interviews for gathering information. We establish who the rest of the
participants are, as well as their modus operandi. We draft a working for the execution of the
project.
4. Project launching
We customize questionnaires for gathering information, depending on the selected environment. We

select the main techniques to be used for assessing risk, and assign the resources necessary to start
the project. We launch an awareness raising campaign to those affected regarding the aims and
requirements of the participants in the project.
The final result of this Stage is the set of issues to be developed for the specific risk
analysis and management project including a specification of priorities, and an initial
scheduling of these issues. We will fine-tune the schedule as the project unfolds and as
we pass through successive the control milestones that coincide with the completion of
the different stages and activities of the MAGERIT methodology.
6.3 Activity 1: Appropriateness of implementation
The objective of activity 1 is to arouse the interest of the organization’s management in a Risk
Analysis and Management Project.
The management is often aware of the advantages that the electronic, computer and telematic
techniques offer, but tend not to appreciate the security problems that they entail.
According to the Spanish Law, the Government Administration must abide by Decree 263/1996, of
February 16, which regulates the use of electronic, computer and telematic techniques by the
Government Administration (BOE (Official State Bulletin) No 52, Thursday February 29, 1996),
and establishes the need for guarantees and requirements with enough security for the use of
electronic, computer and telematic supports, resources and applications, for communication, storage
and access. This Decree has transformed the concern about security into specific “Administrative
Action”. Below is a summary of Article 9 regarding “Approving and Publishing Applications”:
1. The applications... to be used in the exercise of the responsibilities of a Ministry or a public

law entity related to or dependent on the Government Administration shall be passed by
resolution of the Administrative Department that is held accountable for solving the
procedure, being mandatory the previous request of the issuance of the technical reports
that are considered appropriate.
In the event that the applications are to be used in the exercise of responsibilities shared by
several public law entities of the Government Administration related to or dependent on the
same Ministry, the applications shall be passed by a Ministerial Order of the Ministry in
question, being mandatory the previous request of the issuance of the technical reports that
are considered appropriate.
2. The applications referred to in section 5 of this Decree to be used in the exercise of the
responsibilities shared by several Departments or public law entities of the Government
Administration related to or dependent on different Departments must be passed by an Order
of the Prime Minister’s Office, upon the proposal of the heads of the affected Departments,
being mandatory the previous request of the issuance of the technical reports that are
considered appropriate.
3. The technical reports referred to in the previous paragraphs shall decide on the following
issues: (...)
b) Secure application: preserving availability, confidentiality and integrity of the data

dealt with by the application.”
Not only in the Government Administration, but also in any public or private organization, it is
important to take specific measures to face the increasing concern about the lack of security in
information systems their supports and environments. This is because the effects of a lack of security
affects not only the systems themselves, but also the organization’s operation, and in critical
situations, the mission and even the existence of the organization.
6.3.1 Single task: Clarify the appropriateness of implementation
Description and objective:
The initiative for carrying out a Risk Analysis and Management Project comes from a promoter,
either from inside or outside the organization, and who is aware of the problems related to
information systems security, such as:
- Ongoing incidents related to security.

- Lack of foresight in questions related to evaluation of needs and means to reach an
acceptable level of security in the information systems, compatible with the correct fulfillment
of the mission and functions of the organization.
- Restructurings of products or services provided.
- Change in technology used.
- Development of new information systems.
Based on the aforementioned points, the promoter can draft a questionnaire-framework (a unique
document that does not belong to the core products of MAGERIT) in order to elicit thoughtful
reflection about security issues by the following types of people:
• Persons in charge of units. The questionnaire allows for a superficial examination of the
information systems security situation. They should have the chance to express their view on
previous security projects (expressing their degree of satisfaction, pointing out limitations), and
their expectations regarding a Risk Analysis and Management Project. This high level overview
provides an initial vision of the specific objectives and the policy options that must underlie the
Risk Analysis and Management Project.
• Persons in charge of information systems. The questionnaire provides a technical overview

for producing the Risk Analysis and Management Project and helps to undertake an examination
of the appropriateness of implementing the project, integrating the aforementioned policy options.
Based on the answers to questionnaire-framework and the interviews with the

aforementioned personnel, the promoter obtains an initial idea regarding the functions,
services and products involved in the security of the information systems, their physical
location, technical and human resources, etc.. A preliminary report should synthesize
this task.
With these elements the promoter drafts the preliminary report, recommending the Risk Analysis
and Management Project, and including the following elements:
• Presentation of essential ideas.
• Specification of the information systems security background (for example, a strategic plan of the
organization, a plan of action from the Ministry, the Department, the Unit, etc.)
• Initial ideas on the domain that will be included in the project depending on:
- the aims of the units

- the existing policy approaches and selected techniques
- the organizational structure
- the technical environment
• Initial ideas on the human and material resources to carry out the risk analysis and management
(RAM).
The promoter presents this preliminary report to the management who will decide:
- To approve the project, or

- To modify its domain and/or objectives, or
- To delay the project.
Products:
• Preliminary report recommending that the RAM project.
• Management’s awareness and support of the RAM project.
Techniques (presented in the Techniques Handbook):
• Questionnaires drafting technique
• Interviewing technique
• Delphi Technique
6.4 Activity 2: Definition of domain and objectives
Having confirmed the appropriateness of carrying out the Risk Analysis and Management Project,
and the support of Management, this Activity identifies the objectives the project must meet and
defines its domain and limits.
APPROPRIATENESS OF
IMPLEMENTATION
DEFINITION OF DOMAIN AND OBJECTIVES
Specify project
objectives
Define
Domain & Project Limits
Identify enviroment &

general constraints
Estimate size, cost and

returns of the Project
ò
PROJECT ORGANIZATION &
PLANNING
6.4.1 Task 1: Specify project objectives
This task allows us to determine the project’s scope and objectives of, differentiated according to
short and medium term deadlines.
We specify the project’s objectives according to the aim of the strategic planning, the starting point
of the organization, and the considerations of management, resulting from the previous activity.
The objectives specification might state, for instance, that the project seeks to determine the highest
risk areas of the organization (narrow objective); or that the project intends to use risk management
as a means of carrying out a comprehensive management of information systems security (broad
objective).
Products:
• Compilation of documentation belonging to the organization.
• Detailed specification of the project’s objectives.
Techniques (stated in the Techniques Handbook):
• Interviewing technique.
• Critical success factors technique.
6.4.2 Task 2: Define domain and project limits

This task identifies the units subject to the Risk Analysis and Management and specifies the general
characteristics of those units as far as personnel, services and physical locations are concerned. It
also identifies the main relationships of the project units with other entities - for instance, the
exchange of information in different supports, the access to common computer resources, etc.
The task starts with a basic principle: Risk Analysis and Management (RAM) must focus on a
restricted domain, which may include several units or remain within one organic unit (depending on
the complexity and the type of the problem being dealt with). This is because too broad project can
prove unattainable due to its excessive generality or extended time period, negatively affecting the
Risk Analysis and Management estimations.
The recommended procedure goes from the general to the particular (top-down). As
stated in Chapter I, the first comprehensive application of MAGERIT to a broad domain
can and often must be followed-up by successive applications to more restricted areas,
either because major risk areas have been delimited or (to be considered in more detail)
or because organic subdivisions are examined in greater detail.
Products:
• General profile of unites included in the project domain
• Diagram of domain-environment relationships
• List of personnel responsible for identifying the environment.
Techniques (explained in the Techniques Handbook):
• Interviewing techniques.
6.4.3 Task 3: Identify environment and general constraints

This task involves a comprehensive study of the information systems of the units included in the
project domain in order to identify their main functions and aims, their relationship to the context, as
well as their evolutionary trends. The general profile of the units, obtained from the previous task, is
enlarged with the information given by the personnel responsible for the different areas of the units.
The task also identifies the persons who will be interviewed so as to obtain detailed information,
which will facilitate the Stage 2 of “Risk Analysis,” and identify potential general constraints that must
be taken into account.
In order to include the constraints into the Risk Analysis and Management, they are grouped into
different concepts.
In this task, we adopt the following classification of constraints into six groups: temporal, financial,
technical, sociological, environmental, and legal.
MAGERIT takes into account the constraints of the different tasks of the project (as
you can see in the asset valuation of Stage 2 “Risk Analysis” and in the risk
interpretation of Stage 3 “Risk Management”). These constraints are comprehensively
reconsidered in Task 4.1.3, incorporate constraints (Activity 4.1 “Identify Safeguard
Mechanisms”) of the last Stage 4 of “Safeguards selection”.
Products:
· Enlargement of the profile of units involved in the project domain.
· Identification of the personnel who will form the team of users.
• Questionnaire drafting technique
• Interviewing technique (with functional and technical managers of the units).
• Critical success factors technique.

• Data flow-charts
• Entity-Relationship Models.
6.4.4 Task 4: Estimate size, cost and returns of the project
The task makes it possible to size the project (size, complexity, uncertainty areas) based on the
knowledge of the project objectives, the domain, and the profile of the units included in the study.
Depending on both the estimated size and the project objectives, we chose techniques for the Risk
Analysis and Management. For example, if the objective of the project is an initial and generic Risk
Analysis and Management, the risk calculation technique is oriented toward differentiating the risks
into two groups, depending on whether they require further detailed Risk Analysis and Management
applications.
Additionally, the task also sizes the project in terms of its cost and returns or profits, so that the
management may take a well-founded decision as to whether to undertake the project and allocate
the resources necessary for its undertaking.
• The study of the project’s cost can be done easily by estimating the time and the profiles of the
personnel assigned to the Stages of the project sized above.
• The study of returns is imprecise at this initial Stage. It is impossible to account for real return of
a security project, which is precisely the cost of not having the security in the studied domain, i.e.
the result of the Risk Analysis and Management Project itself.
Products:
• Definition of the size of the project
• Definition of the costs and benefits of the project

Techniques (presented in the Techniques handbook):
• Situational factors technique, adapted from Euromethod version 1.
• Cost-benefit analysis technique
We emphasize the importance of this non-routine Activity, because it conditions all

the follow-up work, as well as its quality. This Activity must be resumed again ans
again during the course of the project in order to test whether the decisions
underlying the launching must be maintained or modified (which implies the review of
the following Activity 1.3: Project organization and planning)
6.5 Activity 3: Project organization and planning
This activity estimates the project’s planning elements, i.e., workloads, group of users, participants
and their modus operandi, and the work schedule for executing the project.
This estimation must take into account the possible existence of other plans (for instance, a strategic
plan for information systems or general security in the units that may be affected, or in the
organization) and the deadline for the start up of the Risk Analysis and Management Project. In
particular, the existence of an information systems strategic plan for the units that may be affected
within the organization can to a large degree determine the extent of the activities carried out in this
activity.
DEFINITION OF
DOMAIN & OBJECTIVES
ò
PROJECT ORGANIZATION AND PLANNING
Evaluate loads
and Organize the participants
plan interviews
ø ÷
Work Planning
Project launching
6.5.1 Task 1: Evaluate loads and plan interviews
To evaluate the time and resources necessary to carry out the Risk Analysis and Management, the
task establishes the parameters to be studied depending on the aims of the units and the scope of
their activity. The degree of detail useful for quantifying the parameters is established as a function of
the matrix of the selected study. Thus, the task allows you to:
• Identify the affected users, by scopes and topics.
• Plan the composition, role, and contributions of the groups of users.
• Evaluate the workload and deduce the composition of the project team, taking into account
technical competence and resources.
• Plan interviews with the users to gather information.
Products:
• Detailed plan of interviews
• Report on Load evaluation
Gantt diagrams
Matrix techniques
6.5.2 Task 2: Organize the participants
The objectives of this task are to:
• Determine the bodies participating in the management, execution, follow-up, and updating of the
Risk Analysis and Management Project.
• Define the functions and responsibilities of the participating bodies.
• Establish the rules and modus operandi.
The participants in a Risk Analysis and Management Project are grouped into these bodies
(matching to the extent possible the operational orientation of Metric V.2.1):
• Steering Committee
The Steering Committee is made up of the persons in charge of the units affected by the Risk
Analysis and Management Project, as well as the persons in charge of information systems, and
the managers within these units. Similarly, the participation of the common services of the
organization (programming and budgeting, human resources, administration, etc.) is also
important. In any case the composition of the Committee will depend on the characteristics of the
affected units.
• Project Manager
The Project Manager must be a senior executive, in charge of the information systems
security, or if not at least responsible for planning, coordination, or similar matters, services
or areas.
• Project Team
The Project Team is made up of a team of experts in information technologies and systems, as
well as technical personnel qualified in the affected domain, with knowledge on security
management in general, and the application of the Risk Analysis and Management methodology
in particular. If project is carried out with the technical assistance of outsourced personnel, the
technical experts in information systems security will join the project team.
• Operational Liaison
The Operational Liaison will be a person from the organization and with a good knowledge
of the persons and the units involved in the Risk Analysis and Management Project. He/She
must have the ability connect the project team with the group of users.
• Group of Users
The Group of Users is made up of users representative of the units affected by the Risk
Analysis and Management Project. There may be various possible subgroups:
• Computer experts (analysts, designers, programmers, administrators...)
• Users (managers, end-users...)
• Others (physical security, quality, maintenance, purchases...)
It is helpful to keep in mind that a risk analysis and management project is, by its
nature, “mixed.” In other words, it requires the permanent cooperation of experts
and users in the project’s defining stages, as well as in its development,
implementation, and effective operation. In projects related to information systems
security, the role of an “operational liaison” takes on a permanent character, which
is not required in more “technical” and less “organizational” projects.
The formation of a Quality Group, different from the Group of Users, and the relative size of the
participating groups will depend upon the project’s objectives and scope, as well as the domain
under consideration.
Products:
• Report on the composition and acting rules of the participating teams.
• Project direction and management technique.

6.5.3 Task 3: Work planning
This task involves the following functions:
• Producing a specific schedule with the different stages, activities and tasks of the specified Risk
Analysis and Management Project depending on the objectives and characteristics previously
defined.
• Specifying the human and material resources considered necessary for completion of each stage.
• Establishing a follow-up schedule defining tentative dates for meetings of the Steering Committee,
the delivery schedule for the different products of the project, the possible changes in the
established objectives, etc.
Products:
• Project schedule.
• Time devoted by participants.
• Specification of necessary material resources and their characteristics.
• Description of milestones.
• Gantt Charts.
• Matrix techniques.
• Project planning techniques adapted from Euromethod version 1.
6.6 Activity 4: Project launching
This activity completes the preparatory tasks prior to the launching of the Risk Analysis and
Management Project. It begins by selecting and adapting the questionnaires to gather data, and
specifying the criteria and techniques to use in the Risk Analysis and Management. It ends by
assigning the resources needed to carry out the project, and conducting campaign to inform and
sensitize those involved in the project.
PROJECT ORGANIZATION AND PLANNING
ò
PROJECT LAUNCHING
Select evaluation criteria

Adapt and techniques for the
questionaires project
ø ÷
Allocate the
necessary
ò
Create awareness
(information campaign)
ò
RISK ANALYSIS
6.6.1 Task 1: Adapt Questionnaires
This task involves adapting the questionnaires for gathering information for the following stage,
depending on the project’s objectives, the domain, and the issues to be explored with the users.
The questionnaires are adapted to the objective of correctly identifying the main elements and other
conditioning factors of the Risk Analysis and Management (assets, threats, vulnerabilities, impacts,
existing safeguards, constraints...).
There is always a need for adapting the questionnaires (due to the wide range of security problems
that MAGERIT can and must deal with). However, the extent of this adaptation also depends on the
conditions under which questionnaires are treated. The degree of adaptation will differ. Interviews
carried out by the expert in security (using MAGERIT’s basic questionnaire, provided in the
Techniques Handbook) will not go into the same depth as the questionnaires self administered by the
person in charge of the domain, or by information systems users.
In risk analyses, just as in medical diagnoses, a case history (or amanuensis) cannot
be obviated. However there is no (nor does it appear that there will be in the short
term) single form of questionnaire that goes beyond an inventory in order not to
forget the basic aspects.
Products:
• Adapted questionnaires (based on basic questionnaires provided in the Techniques Handbook).

• Making questionnaires.
6.6.2 Task 2: Select evaluation criteria and techniques for the project
This task, which is preparatory to Stage 2 “Risk Analysis,” establishes the selection, if appropriate,
of criteria and techniques for the entire process of Risk Analysis and Management. Actually, the risk
analysis of Stage 3 of MAGERIT is conditioned by the type of risk analysis carried out in Stage 2.
We recommend applying the same techniques to evaluate risk reduction when implementing the
proposed safeguards. The choice of these criteria and techniques depends on:
• Project objectives
• Project domain
• Project type
Products:
• Report on the selected criteria and techniques.
• Experience of the working group in the application of MAGERIT.
6.6.3 Task 3: Allocate the necessary resources
This task involves assigning the necessary resources (human, organizational, technical, etc.) for
executing the Risk Analysis and Management.
Products:
• Communications to the participating personnel about their project assignment.
• Availability of the necessary material resources
• Budget allocation and personnel recruitment techniques.
6.6.4 Task 4: Create awareness (information campaign)
This task involves informing the affected units about the launching of the Risk Analysis and
Management Project, through diverse channels. As a minimum it will provide:
• An informative communication from management to the implicated units declaring its support for
the project.
• The presentation by the work group of the project, its objectives and methodology to the
implicated units.
Products:
• An informative communication from management.
• Report and material presenting the project.
• Presentation techniques.
6.7 Summarizing the Stage
6.7.1 Control milestones
• Control Milestone 1-A: Management will approve or reject the Risk Analysis and
Management Project, based on an appropriateness study carried out by the promoter.
• Control Milestone 1-B: The Steering Committee will endorse the “Risk Analysis and
Management Planning” report, which will include a summary of the products obtained from the
activities of the Stage.
6.7.2 Results
Intermediate documents
• Interview results
• Documents from other sources: statistics, expert and analyst observations.
• Additional documents: plans, organizational charts, requirements, specifications, functional

analyses, load books, user’s manuals, operation manuals, information and processes flow-charts,
data models, etc.
• Analysis of results, detecting key critical areas.
• Existing information useful for the project (for example, inventory of assets).
• Results of prior applications of Risk Analysis and Management (for example, the cataloguing,
grouping and valuation of assets, threats, vulnerabilities, impacts, risks, safeguard mechanisms,
etc.).
Final Documents:
• A report on “Risk Analysis and Management Planning,” which contains a summary of the
products obtained in the activities of this Stage.
6.8.1 Role of the Risk Analysis and Management Team
• Executing the tasks of the Stage.
6.8.2 Role of the Liaison Groups
• Providing the required documents.
• Availability for interviews.
6.8.3 Role of the Steering Committee
• Backing the project.
• Approving the resources proposed for carrying out the project.
For a full understanding of the MAGERIT procedure, a real case will be presented
and developed at the end of the sections on each Stage. We have adapted the
terminology only when essential, not only so as to maintain the consistency and
freshness of the case, but also as a way of showing the need for adapting MAGERIT
to each individual case (not vice-versa), a result of the broad applicability of the
method.
6.9.1 Activity 1.1: Appropriateness of implementation
Task 1.1.1. (single): Clarify the appropriateness of implementation
A Local Public Administration (hereafter LPA), which is large and well computerized, charges an
auditor to audit its recently completed third Computer Plan and issue a diagnostic-analysis of the
information system attained. Among its conclusions, the diagnosis emphases two points related to
security.
- there is little control of the environmental systems in the computer room, and
- there are no emergency plans.
The first point is easy to solve, but the second one requires a relatively in depth study. The LPA
invites tenders for the study after having established the criteria for the new information system Plan
but before having undertaken it.
These strategic planning criteria are important for establishing the aims of the security study. Thus, the
scope of the new Plan encompasses both the technological strategy and the execution plan, and
covers all the administrative unit of the LPA regarding information system development and support.
The 44 computer experts of the LPA work with a large host that runs the corporate management
systems and centralizes 250 terminals; three departmental computers, each one being a different
brand, with around 75 terminals connected; 6 local networks and around 200 PCs.
These networks support sophisticated logic resources which cover various types of large
applications: an integrated economic information and purchasing system; personnel and payroll
management; the population census geographically coded for managing different services and
information to citizens; computer-based maps planning and management; and an integrated system
for registries and files.
A part of the basic objectives of the new Plan (one of which is their intent to guarantee
consistency between the management objectives and LPA’s policies, the information systems, the
organizational structure and technological trends) is to try to “generate an integrated information
system for the LPA, making a special effort to ensure information security, following a coherent
design”, and defining a communications network whose “design characteristics make it capable of
addressing three fundamental conditions: inward logic security (local net); outward logic security; and
criticality (physical security)”.
6.9.2 Activity 1.2: Definition of domain and objectives
Task 1.2.1: Specify project objectives
The LPA invites tenders for a Contingency Plan Preliminary Study. The basic objective is to
determine the set of actions LPA should take in case of disaster (fire, flood...) to ensure computer
services to users, until everything has been restored to the normal situation.
In addition to the technical conditions sheet, the Study should include a background with the
“diagnostic analysis of the LPA’s information system”, and the information system plan recently
approved by the Corporation.
The bidder may decide to run the project as a particularized Risk Analysis and Management to
obtain the Contingency Plan as an especially important safeguard mechanism (in addition to other
cooperating mechanisms that also contribute to information system security). Thus, the project has
three major objectives, to be systematized in three Stages:
- Comprehensive security planning.
- Analysis of the current situation and specification of the functional security needs.
- Detailed design of the Contingency Plan as a comprehensive safeguard mechanism.
Task 1.2.2: Define domain and project limits
The project domain is the entire LPA, from the point of view of information system security in its
broadest sense, i.e., with all the repercussions on the organization’s functionalities and abstract assets
that affect the its mission.
The scope of the preliminary study, limited by the technical conditions, does not give rise to a
complete computer security plan, although it allows you to establish a consistent and cohesive
technical foundation for generating a complete plan when the LPA deems it appropriate.
Task 1.2.3: Identify environment and general constraints
The technical specifications sheet and the first interviews with the person in charge of information
systems help to shape a first description of the information systems of the units included in the project
domain, identifying their main functions and aims; their relationships with the environment; and their
evolutionary trends. This task identifies the people to interview to get detailed information for Stage 2
“Analysis and Risks,” and points out the potential constraints that the project must take into account.
The project interviews two groups: the directors of the main functional departments of the LPA
(once the information systems applications are known, with the help of the analysts that develop
them), and the directors of the computer departments: systems, operation and studies.
We must keep in mind the Risk Analysis and Management constraints, which come from the
technical specifications sheet and the aforementioned conversations. In this way, we can accurately
calculate the deadline and cost of the project. Likewise, from the start we should take into account
certain other constraints - sociological, technical or legal. For example, there are no commercial
back-up centers within hundreds of miles, but the solution of a back up solutions shared with other
corporations with similar systems is not advisable. Nor is it possible to offer international solutions,
regardless of their appropriateness, cost or guarantees may be.
Task 1.2.4: Estimate size, cost and returns of the project
The technical specification sheet assumes a previous appraisal of the size, cost and return of the
project, although these are not explicitly stated.
The size and cost of a MAGERIT project depends basically on the intellectual work underlying the
acquisition of information about the domain, and thus frequently on the number and depth of the
interviews.
The project’s returns are predetermined in this case by the double recommendation of the diagnostic
analysis and by compliance with Article 9 of the Organic Law 5/1992 LORTAD, which is stated in
the questionnaire on the declaration of personal data files issued by the Data Protection Agency.
6.9.3 Activity 1.3: Project organization and planning
Task 1.3.1: Evaluate loads and plan interviews
This task is usually comes from the bidding process and is carried out by the bidders, who specify in
their offers the time and resources that they will need for the Risk Analysis and Management, based
on the data from the technical specification and the requested interviews, if necessary.
The most delicate issue has to do with matching the work structure explicitly or implicitly required by
the technical specification, with work procedures of the bidders and those of MAGERIT. In the
security area, the immaturity of the sector accounts for the need to use MAGERIT’s standardized
terminology to interpret heterogeneous formulations of problems. In the case of the LPA and the
bidder, this matching gave rise to a 5 phase project:
Phase 1. Preparing the study. Phase 1 is preparatory and begins with a detailed specification of
the working plan, a mutual adaptation of the consulting and client teams, and the formation of groups
that will participate in the project - particularly the Study Follow-up Committee. The results of
Phase 1 are the clear and concise specification of impact criteria and the extent of the LPA’s “risk
aversion”, using impact metrics and aggression potentialities.
Phase 2. Analysis of the major risks. Phase 2 consists of several types of scenarios, ranging from
set off mechanisms of threatening events to impacts their, including the primary scenario description
(threat, aggression, vulnerability, deterioration) and the average estimate of impact and risk
potentiality. The results are on the one hand a set of standard dossiers on major types of risks,
and on the other hand an audit report for common risks, done by sectors (general organization,
physical resources management, development management, operation management,
telecommunications administration, access rights management, etc.). Phase 2 covers two parts of the
requests detailed in the technical specification: prevention procedures (possible changes to be made
in the installations and working procedures to prevent possible disasters), and a study of the currently
existing back-up centers, which are compatible with the computer installations of the LPA, including
their different modus operandi and tariffs, in order to best select the back-up center.
Phase 3. Analysis of risks and current safeguard mechanisms. This Phase consists of a
detailed analysis of the current situation in order to find out the existence and efficiency of the
installed safeguards, especially those related to back-ups, and above all from the point of view of the
real recovery of execution processes after a serious or catastrophic accident. The detailed analysis of
risks also seeks to evaluate the potentiality of the aggression and its impact on each risk scenario, on
the level of applications and basic computer resources - physical or logical. The results of Phase 3
are: on the one hand, the analysis of present safeguards, particularly back-up measures and data
storage, as well as procedures for improvement; and on the other hand, the analysis of potentialities
of aggression and their impact, detailed to the level of main application groups, which will allow the
identification of critical application groups and resources. Phase 3 covers two other requirements of
the technical specifications sheet: the detail of all the elements necessary for the LPA to work under
emergency circumstances (particularly, the identification of critical applications, the base software
necessary for its operation and the communications services necessary during an emergency, such as
terminals, lines, etc.) and the review of the current back-up and storing procedures, and their
physical storage.
Phase 4. Drafting proposals. Phase 4 starts with establishing general solutions against major risks
in order to limit their impact, continuing with solutions against ordinary risks, described in relation to
their relative weight. Installing general constraints (organizational, budgetary, technical) permits a final
cohesive analysis prior to the drafting of the Master Plan, which moreover includes the decision
elements necessary for the operability of the Contingency Plan (structures, organization, context,
budgets, planning). Setting functional specification, in the aforementioned cohesive context, permits
the optimization of the most characteristic solutions with a final residual risk analysis and the
establishment of specification notebooks, including procedures. Phase 4 covers two parts of the
study, detailed in the specifications sheet: a study of the changes that the LPA must make in its
installations so that the Contingency Plan can be viable, quantifying these changes in monetary terms,
and description of the procedure to follow so that the Contingency Plan can become fully
operational.
Phase 5. Final Contingency Plan. Phase 5 consolidates the final results.
Task 1.3.2. Organize the participants
A project of this scope must be based on a well-defined structure, made up of the following bodies:
Follow-up Committee. This Committee must be composed of representatives of senior executives

of the Organization (there is already a regular information system Commission) and has the authority
to take decisions over the course of the project. It is essential that the decisions be make quickly in
order to ensure efficiency of the work groups
Operational Liaison. In this project, the person of the LPA in charge of information systems is both
the Project Director and the operational liaison.
LPA Study Team. This team is comprised of the people responsible for systems, operation,
development, and microcomputers. Their primary mission is to provide the team of the successful
bidder with the information and technical documents needed to conduct the study.
Team of the Successful Bidder. In this case, the team consists of a Project Director (who devotes
50% of his/her time to the project), a full-time Senior Consultant, an Expert Consultant in
communications (who works part-time, depending on the project needs) and a Senior Executive
who works in the areas of consulting, quality control and oversight.
Group of Users. This group includes the present and future users of the information system. In
theory, it is comprised of 16 managers from different areas and services of the LPA, going down the
appropriate level according to the information needs detected during the development of the study.
Task 1.3.3: Work Planning
PHASES
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
22222
1. PREPARING THE STUDY
2. ANALYSIS OF MAJOR RISKS
22222 22222 22222
3. ANALYSIS OF
CURRENT SITUATION....
4. DRAFTING PROPOSALS...
22222 22222 22222 22222 22222
5. FINAL CONTINGENCY 22222 22222 22222 22222 22222
PLAN..........
22222
6.9.4 Activity 1.4: Project Launching
Task 1.4.1: Adapt Questionnaires
We adapted the questionnaires dramatically due to the specificity of this project and the ample
participation of the successful bidder’s security experts in the direct collection of information from the
executives and in the potentially vulnerable sites. The survey questionnaires must be seen more as a
reminder for analysis of a document than a document to be filled out by the persons in charge of the
protected domain.
The survey of the services that use the computerized information systems is divided into two
groups: a specific group about the vulnerabilities inherent to the functions of the system of the service
(and consequently with unstructured answers); and another general group, based on a series of
questions that let you to place each service within an homogeneous table. This generic group, the
only one that can by synthesized from the answers is summarized below:
ORGANIZATIONAL VULNERABILITIES
• ACCURACY AND CONSISTENCY OF THE INFORMATION

• ACCESS TO THE SYSTEM BY OUTSIDERS.
• TRANSFER OF INFORMATION FROM THE SYSTEM TO THE OUTSIDE
• ACCESS AVAILABILITY TO THE SYSTEM (CRASHES, SLOW RUNNING...)
• OBTAINING OF PRODUCTS FROM THE SYSTEM.
• ACCESS BY OUTSIDERS TO THE TERMINALS’ SITE.
TECHNICAL VULNERABILITIES
• TERMINAL/PRINTER BREAKDOWNS: FREQUENCY/SOLUTION.

• POWER CUTS.
• LOCATION OF TERMINALS AND PRINTERS.
• USER’S APPROVAL OF DESIGN AND TESTS.
• CONTROL OF THE PAPER SUPPORT. STORING PAPER.
“HUMAN” VULNERABILITIES
• PHYSICAL POSSIBILITY OF THEFT/DESTRUCTION THE RESOURCES

• ERRORS IN DATA INPUTTING
• SIGNIFICANT PERSONNEL ABSENTEEISM
• DEPENDENCE ON CERTAIN PEOPLE/PERSONNEL SHIFTS
• INFORMATION GATHERING BY OUTSIDERS
• KNOWLEDGE OF THE APPLICATIONS
• IMPROPER USE OF USER’S PASSWORDS. DELETING OLD PASSWORDS.
• PERIODIC CHANGING OF PASSWORDS.
• USING SECURITY MEASURES IN THE TERMINALS (KEYS...)
• INVOLVEMENT OF COMPUTER EXPERTS TO CHANGE REAL DATA.
TASK 1.4.2: Select evaluation criteria and techniques for the project
The security situation of the LPA’s information systems is the result of the inclusion of safeguards to
prevent or reduce risks that up until now have not been analyzed systematically. Up until now the
LPA has not experienced significant computer operational failures, which might have forced them to
take drastic precautions (they also would have been difficult to adopt due to economic reasons). A
healthy and ever increasing awareness of preventive security has led to the implementation of
different types of defensive techniques:
• Utilization by the development teams of applications of database security routines.

• Prevention measures at computer sites (fire prevention, continuous power supply, exits, physical
access).
• Acquisition of software packages for authorization and logical access control to applications by
users.
• Acquisition of packages and organization of planning and operational management techniques.
• Organization of applications and tasks recovery techniques (back-ups).
• Acquisition of security packages for microcomputer systems (virus protection, back-ups).
Nonetheless, up until now the lack of risk analysis has not allowed for a prioritization of the many
measures acquired. In many cases they are even underutilized because of the lack of any cost-benefit
criteria for using them. Risk analysis will permit rationalization of the current measures and the their
completion with others. The Preliminary Study is partially based on this paradoxical situation of the
simultaneous abundance and lack of security measures. It proposes the rationalization of the current
measures and the study of new ones (mainly and because of its importance, the hiring of a back-up
center). Rationalizing requires a comprehensive risk analysis, for which certain important elements
currently are missing (for example, a historic record of past contingencies).
The adaptation of the general method regards the situation dynamically, and starts with an initial M1
Model, which is basically qualitative and very simplified.
The initial M1 Model offers the whole range of simplifying hypothesis in order to be able to consider,
in the short term, the enrichment of this M1 Model, capable as the M2 Model of including the first
quantitative elements that the operation of the basic computer security system established by the
initial M1 Model. To meet these objectives, the Model M1 must have four features:
• Use metrics and techniques compatible with the currently available parameters
• Collect the Phases and Stages of the process that allow consecutive evaluations of the
applications already developed
• Prepare evaluations concurrently with the applications to be developed.
• Generate control mechanisms (such as historical contingency records)
The initial M1 Assurance Model stems from a first definition of possible ACCIDENT
SCENARIOS. In each scenario there are four elements:
• Type of THREAT (and its POTENTIALITY)

• Type of ATTACKER (real or virtual) and its MOTIVE, using two parameters (exposure and
force)
• Type of DETERIORATION
• ASSET to be affected by the THREAT
Task 1.4.3: Allocate the necessary resources
The successful bidder makes available and uses the resources proposed in its offer and negotiated
with the LPA. This implies trips, availability of equipment and tools, transfer of documents and
manuals, etc.
Task 1.4.4: Create awareness (information campaign)
As established, the first session of the Committee consists in the general appreciation of the risks,
and the adoption of a common language for intercommunication. Also, the Committee includes the
customer’s general objectives (statistical prospects, constraints, structure, organization, budgets) and
the specific security objectives.
The first step in getting to know the users of the information systems is a plenary meeting in the
second phase of the project, which is attended by the users, the managerial liaison and the LPA
study team. The meeting held with the group of users and technicians follows the following agenda:
- Definitions and comprehensive security problem

- Processing and flow of information. Attack areas. Example from the expense system.
- Types of threats to the assets
- Examples of types of threats and safeguards to prevent them
- Assessment of the impact on the assets
- Vulnerability or potentiality of threats
- Risk assessment
- Risk classification
- Expected contribution of the users to the study
- Closure of presentation
7. STAGE 2: RISK ANALYSIS
7.0 Location of the Stage 2 within the MAGERIT model
MAGERIT Model


· Threats · Organizational dynamic
· Vulnerabilities · Physical dynamic · Risk analysis
· Safeguards
STAGE 1:
PLANNING
Activities:
implementation
objectives
ò
planning
ò
ñ
STAGE 2: STAGE 3:
STAGE 4:

ð Activities:
2.1: Gather information 3.1: Interpret RISK
THREATS services 4.2: Select safeguard mechanism
7.2.1 Objectives
This Stage has the following objectives:
• To evaluate the risk of the system under study, both the intrinsic risk (without safeguards) and the
effective risk (including the effect of the implemented safeguards if we are dealing with a current
system one rather than a planned system).
• To show the Steering Committee the areas of the system the greatest risk.
• To present and obtain the approval for the acceptable or assumable risk thresholds.
7.2.2 Contents
The starting point for this Stage of the MAGERIT process cycle is the documentation from the
previous Stage regarding the objectives of the project, the plans for interviews, the loads evaluation,
the rules to be followed by the participants, the work plan and the project’s presentation report.
The Risk Analysis identifies, evaluates and combines the elements defined in the corresponding
Submodel. The result is an evaluation of the risk in the domain that can be used to identify and
manage the safeguards for counteracting the non-acceptable risk.
This Stage is the core of MAGERIT and its correct application conditions the validity and
usefulness of the whole procedure. The identification and estimation of the assets and of the
potential threats to the assets is a complex, although relatively routine, task. The estimation
of impacts and vulnerabilities is not only complex, but much more indeterminate and thus,
requires creative decision-making by experts due to the decisive influence of both elements:
impact and vulnerability, in the determination of risk.
The Risk Analysis Stage follows, to a certain extent, the subscenario of attack of the “organizational”
dynamic view of the Events Submodel, combining in each of the “steps” of the subscenario
operations related to the security elements. Thus, after defining in greater detail the content of the
domain (i.e., a group of assets), the Stage considers the potential “events” (threats), their potential
materialization and the consequences of such a materialization (impacts).
With the help of these materials, adequately identified and evaluated accordingly, the calculation or
the estimation of the different types of risk is a fairly routine task, the results of which (types of risk)
should be appropriately interpreted in the Stage 3.
7.2.3 Summary of the Activities’ contents
1. Gather information
Collection of information about the system, its components, and the factors that might have an
influence on security.
2. Identify and group ASSETS
A thorough study of the identification, characterization, interrelationships, dependencies and

assessments of the assets with regard to their contribution to the risk evaluation.
3. Identify and evaluate THREATS

assessment of the threats with regard to their contribution to the risk evaluation.
4. Identify and estimate VULNERABILITIES

assessment of the vulnerabilities with regard to their contribution to the risk evaluation.
5. Identify and assess IMPACTS

assessment of the impacts with regard to their contribution to the risk evaluation.
6. Evaluate RISK
Evaluation of the intrinsic and effective risks based on the results of the previous Activities.
7.3 Activity 1: Gather information
This Activity is intended to collect information on the system and on factors that
could influence on security
PLANNING
ò
GATHER INFORMATION
ò
Prepare the information
ò
Conduct
interviews
ò
Analyze the gathered
information
ò
IDENTIFY AND GROUP ASSETS
This Activity is especially important for two reasons: the information gathered conditions
the knowledge of the project team (in part removed from the operation of the domain or
dependent on those familiar with its day to day functioning); and the information
collection itself is a sensitive operation that requires a high degree of mutual trust (the
information exchange is always a sensitive process, especially if it concerns security).
7.3.1 Task 1: Prepare the information
This Task includes the following actions aimed at preparing the information gathering:
• To compile the customized questionnaires distributed in the previous Stage.

• To locate the interviewees in order to optimize the interviews, both spatially and temporaly.
• To confirm that each interview, advising regarding the documents that will be needed in the
interview in order to make sure that they are available.
• To remind the interviewee about the objectives of each interview.
• To have an accrediting document issued by the Management.
Products:
• Work documentation.
7.3.2 Task 2: Conduct interviews
This Task delves into the following areas with the interviewees:
• Definition of the functions and objectives of the interviewee.

• Description of the modus operandi.
• Identification of the resources available to carry out the functions and the staff in charge of them.
• Identification of the processes carried out and the information handled
• Description of the environment.
• Identification of potentially conflictive situations (internal or external, accidental or deliberate).
During the interview, it is usually necessary to inform the interviewee of the main security concepts
regarding information systems, depending on his/her knowledge or experience in the matter.
After these preparations, the interview allows for the first acquisition of concepts and data regarding
security elements such as the following:
• Demarcation of assets.
• Cost of the asset replacement, if it makes sense or is feasible.
• Importance of the assets for the interviewee’s organizational system.
• Existing safeguards.
• Potential threats.
• Incidents, and if they have occurred, their consequences (material and non-material losses, etc.).
• Relevant plans and geographical location related to risks.
Likewise, the interview allows the appraisal of other elements:
• Risk threshold and security aspects to focus on.

• Constraints to be considered (financial, deadlines, etc.)
• Organizational aspects.
• Use of development methodologies (such as Metric V.2.1)
• Specification of regulations and standards.
• Operation procedures.
Products
• Interviews held.
7.3.3 Task 3: Analyze the gathered information
This Task makes it possible to synthesize the information gathered from the different interviews. This
information is recorded in the corresponding minutes of the meetings, and then given to the
interviewees in order to check the collected data. The minutes are updated with the proposed
changes to obtain the final minutes.
The information gathered through interviews is complemented, when necessary with:
• The comments of the security auditor or analyst, if there have been operational inspections.
• The comments of experts in information systems security so as to detect unclear issues, hidden
assets, and the frequency of threats coming from new technologies.
• The compilation of information from other sources, such as statistical studies on the occurrence
of natural disasters (that could affect the system), statistics on components failures (MTBF or
mean time between failures that can be possibly found in the technical specifications manuals of
the component), number of errors per million in program instructions, etc.
It will be necessary to reschedule additional interviews, following procedures similar to the those
mentioned above, if so requested by the interviewee or in order to fill any gaps or to clarify the
gathered information.
A recapitulation report is drafted which includes all the aspects of the information gathered from
the different units and the comments of the security analyst. The minutes of the interviews held will be
included as an appendix.
Products:
A recapitulation report the information obtained from the interviews (including the analysis).
• Report technique
• Flow charts
• Data modeling
7.4 Activity 2: Identify and group ASSETS
In the domain definition Stage there is a description of functions, weighted according to their
importance for the mission of the organization. The objective of this Activity is to identify the assets
that make up the processes and to define the dependencies between them. Thus, according to the
information compiled in the previous Activity, this Activity studies the assets in greater depth in order
to achieve the information necessary to make the risk estimates.
GATHER
INFORMATION
ò
Identify assets and Identify existing

groups of assets safeguard mechanisms
ø ÷
Assess
assets
ò
IDENTIFY AND
EVALUATE THREATS
7.4.1 Task 1: Identify assets and groups of assets
The objective of this task is to identify the assets that make up the domain, determine
their features, and classify them according to the types defined in the MAGERIT’s
Elements Submodel. A proper identification of the assets is important because the
success of the subsequent process depends on it.
For a great part of the material and some of the immaterial assets (the so-called inventoriable assets),
this Task can begin with inventories made for other purposes (for example, for the obligatory
annual valuation of the organization). This “official” valuation of many of the corporate assets also
helps to start up the subsequent Task, which focuses on assessing the assets identified in the current
Task.
This Task classifies the identified assets into the types offered by MAGERIT and groups them
according to an organizational hierarchy, as well as other considerations:
• Security substates (authentication, confidentiality, integrity and availability, known as A-C-I-Av).

• Threats that can attack them
• Safeguards that can protect them.
This Task is completed by including in the record of each asset other fields pertinent for subsequent
processing: description, location, person in charge, number or quantity, etc.
This Task groups assets assigning them to groups defined by a common specific function (which is in
turn a component of the system’s mission). The most practical grouping of assets from the point of
view of risk analysis is the classification into the 5 layers considered in the MAGERIT submodel of
elements:
1. Environment;
2. Information system;
3. Information;
4. Functionalities of the Organization
5. Other assets.
A specific “vertical chain” or “assets tree” taken from these layers groups together the assets that
could be affected by a potential threat. For example, the threat of a thief takes advantage of the fact
that the cleaning staff has left open the door of the financial manager’s office after office hours. The
thief steals a PC (environment, layer 1) with its programs (information system, layer 2), which leads
to a lack of information (information, layer 3) critical to the maintenance of the organization
(functionalities, layer 4). Although information can be restored (requesting information from the banks
with which the organization operates), the resulting bad image is inevitable. There is also the
possibility of the falsification of data, not to mention the potential disclosure of the contents robbed, if
the robbery has been deliberate (other assets, layer 5).
Moreover, the Task may prepare another type of grouping based on the nature of the assets, in
order to facilitate the study of the safeguard mechanisms already implemented or to be implemented.
For instance, a personal computer composed of different assets such as a screen, a keyboard, a
CPU, peripherals, operative system, applications, data, etc. can be attacked by certain threats and
requires safeguard mechanisms customized for each asset and for the whole PC. This type of asset
grouping includes broad traditional areas such as:
• Information and data.

• Hardware.
• Operative software.
• Communications.
• Documents.
• Environmental equipment.
• Internal and external personnel.
• Infrastructure.
• Organizational assets.
Products:
• Report on the assets of the domain and of its hierarchical groupings.

• Definition of the dependencies among assets, processes and functions of the domain.
• Flow charts.
7.4.2 Task 2: Identify existing safeguard mechanisms
In parallel with the previous Task of identifying assets, this Task permits the identification of the
safeguard mechanisms associated with or implemented in the assets, describing them and revealing
their contribution to the different security substates (A-C-I-Av). Moreover, the Task gathers
information on the annual implementation and maintenance costs of the aforementioned mechanisms.
Products:
• A report on the existing safeguard mechanisms.
• Report drafting technique.
7.4.3 Task 3: Assess assets
The quality of the MAGERIT application depends on a careful execution not only of
Task 1 to identify assets and their groups, but also of Task 3 in order to assess the
assets, especially non-inventoriable assets. This Task rests on sensitive metrics that
should be applied carefully and creatively.
This Task begins with the inventories assessed in the previous Task and permits two asset
assessments, one intrinsic and another associated with the security substates A-C-I-Av
(authentication, confidentiality, integrity and availability).
• Intrinsic assessment. The inventoriable assets can be valued in monetary terms based on the
inventory value from the official accounting as a means of quantifying potential impacts
(replacement cost, exchange value, production cost in man hours and by price/hour, etc.) The
non-inventoriable assets cannot be value in this way. However, this does not prevent the
estimation of their use value in the majority of cases, for example based on the economic
consequences of their non-availability according to their “asset tree”. This kind of intrinsic
assessment will be maintained when the assessment of the corresponding impact is made.
MAGERIT does not recommend mixing the assessment of inventoriable and non-inventoriable
assets because a mixing tends to undervalue the latter, above all the immaterial ones and
especially those related to public Administration. The procedure recommended by MAGERIT to
assess assets can be summarized in two steps:
- It tries to assess the “exchange value” of the asset as the replacement cost, either directly
(inventory value) or indirectly (cost of regeneration after an impact).
- If such an assessment is impossible or is not useful (replacement cost of a person after an

accident due to a lack of security in an asset), it treats this asset (together with the possible
impacts and the consequent risk) as an element of the domain environment included in the
security project. This element influences the domain as a constraint partially alien to MAGERIT
process, but which conditions its result (therefore, the asset or its derivatives should be present in
the intermediate reports and in the final report of the process).
• Assessment related to the security substates. This assessment provides a qualitative value
of the security substates of the asset (authentication, confidentiality, integrity and availability, A-
C-I-Av) taking as a reference the degree of completion of the function and the importance of the
asset for the system’s mission. This kind of “assessment related to security substates” also
provides the first alternative estimate to the “intrinsic assessment” during the impact assessment
study.
This Task also gives us the comprehensive levels for the whole domain of the security substates A-
C-I-Av, substates based on the levels of the A-C-I-Av substates for each element and with the
assistance of the groups established in the previous Task.
Products:
• Report on asset assessments.

7.5 Activity 3: Identify and evaluate THREATS
ò
IDENTIFY AND EVALUATE THREATS
Identify and group threats
Establish the fault-trees resulting from

threats
ò
IDENTIFY AND ESTIMATE
VULNERABILITIES
This Activity allows you to identify and evaluate the threats to the system assets. Each threat is an
event that can potentially trigger other threats. Together, they constitute a “threat scenario” that
produces a “fault tree” as subscenario of a real attack on an “asset tree” (determined in the previous
Activity). The vulnerability related to the “asset tree” and specific to the “threat scenario,” induces
the triggering of threats that produce impacts (i.e. damage) to the affected assets with varying
degrees of severity.
The adequate determination of the threats to each asset of the analyzed domain requires
the supervision of security specialists and the case by case association of the pertinent
threats and assets.
This Activity simplifies the complex and recurrent “fault trees” subscenario and affects the “asset
trees.” It divides subscenario into two semi-independent analysis which are broken down into the
following two successive Tasks.
7.5.1 Task 1: Identify and group threats
This Task identifies threats and categorizes them as well as their principal or secondary sources and
objectives.
• The categories relate to the type of threats (accidents, errors, deliberate threats, either in situ or
remote-controlled ones)
• With regard to the sources, it is important to identify agents of the threats and other aspects the
capability and timeliness, as well as their motivation in the case of deliberate threats.
• The objectives of the threats are the “assets trees.”
Products:
• Report on the threats and groups of threats.
Report drafting technique.
7.5.2 Task 2: Establish the fault-trees resulting from threats
This Task establishes the dependencies between the threats identified in the previous Task,
disregarding for the time being, the “assets trees” affected, so that we can determine groups of
threats, the common denominator of which is a triggering effect and joint action, in the event that one
of them materializes.
Products:
• Report on “fault-trees” generated by threats.
7.6 Activity 4: Identify and estimate VULNERABILITIES
This Activity focuses on vulnerability, a feature common of the threat and the asset (or a feature of
the relationship, depending on what is best or preferable in the analysis) that can be viewed as the
foreseeable potentiality or the closeness of the threat materializing into an attack. MAGERIT
evaluates the vulnerability as the frequency of the threat to the corresponding asset.
IDENTIFY AND EVALUATE THREATS
ò
VULNERABILITIES
Identify vulnerabilities
ò
Estimate
vulnerabilities
ò
IDENTIFY AND ASSESS
IMPACTS
7.6.1 Task 1: Identify vulnerabilities
This Task identifies and establishes vulnerabilities as relationships between the assets and threats,
treated either individually or as a group, based on the classifications made in the previous Tasks.
Three types of vulnerabilities are considered:
• Intrinsic vulnerability if no safeguard is implemented (excluding vulnerabilities that are natural

or implicit to the asset).
• Effective vulnerability results from implementation of existing safeguards.
• Residual vulnerability results from the implementation of supplementary safeguards
recommended in the Risk Analysis and Management.
Products:
• Report on relationships between assets and threats.
Techniques (presented in the Techniques Handbook)
Report drafting technique.

Matrix techniques.
7.6.2 Task 2: Estimate vulnerabilities
The estimation can be made in different ways:
• Whenever possible, by calculating the frequency based on statistics of incidents or empirical

series. In this case, MAGERIT establishes as the metric unit the number of potential threats per
day. For instance, one occurrence per working week means a frequency of 1:5 = 0,2; one
occurrence per working month means a frequency of 1:20 = 0,05, etc. This Task uses the
following interval table:
Frequency range Vulnerability “Objectified” scales (per day) per year
Greater than 6 years Very low (≅ 0) ≅ 0,01
Less than 6 years Low (≅ 0,0002) ≅ 0,1
Around 1 year Medium (≅ 0,002) ≅1
Less than 2 months High (≅ 0,02) ≅ 10
Less than 1 week Very high (≅ 0,2) ≅ 100
• For deliberate threats, estimating the frequency as a compound of the qualitative appraisals of
factors such as the agent’s capability, motivation and opportunity.
• When only the users’ subjective estimation can be obtained, MAGERIT envisages a two-stage
inquiry supported by an analysis based on fuzzy logic and the Bayesian probability technique.
In order to estimate the vulnerability or potential frequency of the threats that affect each
asset or group of assets, the person in charge of the asset should take part in the
estimation survey. A specialist should advise him/her so that he/she can objectively
understand or imagine the potential threats actions.
Products:
• Report on vulnerabilities
• Report drafting techniques

• Advanced techniques (diffuse logic, Bayesian probability technique)
7.7 Activity 5: Identify and assess IMPACTS

The objective of this Activity is to determine the extent of the harm suffered by the domain as a
consequence of the materialization of the threats to the assets.
The impact, viewed as a reflection of the security state of the asset, lets us appraise the “severity” of
the consequence generated by the attack as a reduction of levels of the security substates (A-C-I-
Av) of the affected asset.
IDENTIFY AND
ESTIMATE
VULNERABILITIES
ò
IDENTIFY AND ASSESS IMPACTS
Identify impacts
ò
Define impacts
ò
Assess impacts
ò
EVALUATE RISK
7.7.1 Task 1: Identify impacts
This Task identifies the impact as the result of the attack of a threat on an asset, in the form of loss of
value, need for replacement (with its cost) or reduction of the levels of one or more A-C-I-Av
security substates.
Taking into account the dependencies among assets, this Task considers whether the impact caused
to an asset can cause other indirect impacts or losses to dependent assets and/or increase the
vulnerability of the dependent assets to new threats.
Products:
• Report on impact identification.
7.7.2 Task 2: Define impacts
This Task classifies impacts according to the kind of consequences that threats can have on the
affected assets:
• Impacts with quaNtitative consequences
- N1: Financial losses
- N2: Immaterial losses
- N3: Legal, civil or criminal responsibility
• Impacts with quaLitative consequences for the organization
- L1: Loss of net worth.

- L2: Breach of legal duties.
- L3: Upsetting or embarrassing situation from the political-administrative point of view.
- L4: Harm to persons.
• Impacts with functional qualitative consequences (decline in substates)
- AS. Authentication
- CS. Confidentiality
- IS. Integrity
- AvS. Availability
Products:
• Report on impact groups.
7.7.3 Task 3: Assess impacts
Based on the information provided by the previous Tasks, this Task assesses the impact that the
materialization of a threat can have on the asset.
Assessing the impact of the threat and how it affects the asset is a crucial task. The
person responsible for each asset, who is consequently very knowledgeable about
the asset, adequately informed by the specialist so that he/she can objectively
comprehend or imagine the potential action of the threats, should take part in the
This assessment will be quantitative if the asset can be assessed with the following table:
Value range Impact

Up to 100,000 pesetas Very low.
Between 100,000 and 1,000,000 pesetas Low.
Between 1,000,000 and 10,000,000 pesetas Medium.
Between 10,000,000 and 100,000,000 pesetas High.
More than 100,000,000 pesetas Very high.
In many cases, the impact can only be estimated subjectively by the users. In order to appreciate it
with as many guarantees as possible, MAGERIT envisages a two-stage interrogation process
supported by refined techniques diffuse logics techniques and Bayesian probability analysis
(techniques that are briefly addressed in the Techniques Handbook and more deeply addressed in
the specific Tools Handbook).
Products:
• Report on impact assessment.
• Report drafting techniques.

• Advanced techniques (diffuse logics, Bayesian probability)
7.8 Activity 6: Evaluate RISKS
The information on vulnerability or impact gained from the previous Activities permit this Activity to
establish and estimate different kinds of risk, using the evaluation criterion selected in the Task 1.4.2
“Select evaluation criteria and techniques for the project” of Stage 1.
The vulnerability and its impact on the asset determine the calculated risk. Both factors are
combined in an “asymmetrical” risk metrics.
This can best be seen when the risk is presented in a matrix. This technique relates vulnerability levels
(arranged in rows) and impact levels (in columns). The risk level values increase with the levels of
both factors, but will be systematically higher above the diagonal as the impact will have a greater
affect on the risk level than on the vulnerability.
IDENTIFY AND
ASSESS IMPACTS
ò
EVALUATE RISK
Evaluate intrinsic risk
ò
Analyze existing safeguards
functions
ò
Evaluate the effective risk
ò
RISK MANAGEMENT
7.8.1 Task 1: Evaluate intrinsic risk
This Task calculates the risk of assets subject to threats as intrinsic risk, as it does not take into
account the possible safeguard mechanisms. This type of intrinsic risk is taken as a benchmark to
evaluate the effectiveness of the implementation of safeguards.
The simplest estimation is for a financially measurable impact and a vulnerability that can be
estimated as frequency; in other words, the risk for an inventoriable asset for which a threat
materializes according to a known or calculable frequency or potentiality of incidences. The
estimated risk will be the sum of the asset’s replacement cost throughout the year and can be
compared either to a specific threshold or to the annual cost of the safeguards to reduce it.
Therefore, if a printer fails every two months (or has a MTBF or average time between failures of
two months) and a repair cost of 100,000 pesetas, the annual risk will be 600,000 pesetas.
The extreme values of the metric levels of the risk in this simple case (i.e., with a known vulnerability
frequency and a financially measurable impact) do not follow a lineal scale in order to offset both the
distortion caused by the multiplier effect and small likelihood of extreme combinations (very high or
very low impact or vulnerability). Therefore, the range of risk values, as an annual cost, would be the
following:
Annual cost value range Risk
Up to 50,000 pesetas/year Very low.
Around 500,000 pesetas/year Low.
Around 5,000,000 pesetas/year Medium.
Around 50,000,000 pesetas/year High.
More than 100,000,000 pesetas/year Very high.
In more complex cases, when the frequency of the vulnerability can not be measured or the impact
cannot be measured in financial terms, MAGERIT estimates the risk metrics using a qualitative table
or its equivalent matrix with the following levels:
Risk range for impact and vulnerabilities (frequency)

Very low.................................. Very low.................................. Very low. Low. Medium. High.
Low ........................................ Very low ................................ Very high.
Low ........................................ Very low. Low. Medium
Medium .................................. Very low. Low.
Medium................................... Low......................................... High. Very high.
Medium................................... Medium. High. Very high
High........................................ Very low.
High ....................................... High ....................................... Low. Medium. High. Very high.
Very high ............................... Very low.
Very high ............................... Very high .............................. Low. Medium. High. Very high.
Impact RISK
Very high High Very high Very high Very high Very high
High Medium High High High High
Medium Low Low Medium Medium Medium
Low Low Low Low Medium Medium
Very low Very low Very low Very low Very low Low
Vulnerability Very low Low Medium High Very high
Applying this table or matrix to the previous example, for a high asset vulnerability (without a precise
frequency) and a low impact (with no financial value), we get a low annual risk (around 500,000
pesetas). This value close to the previously calculated annual risk of 600,000 pesetas based on the
frequency and the impact value.
If the project is oriented towards an initial and generic Risk Analysis and Management, the risk
estimation technique presents a dichotomous discrimination (into two groups) of the risks, depending
on whether they require more detailed Risk Analysis and Management applications. This generic
application also has few elements to discriminate vulnerabilities and impacts into many levels. Thus, it
may not only be sufficient but also logical to reduce the previous matrix to 3 levels: low, medium and
high.
Products:
• Report on intrinsic risks in the system.
• Matrix techniques
• Algorithm techniques
7.8.2 Task 2: Analyze existing safeguards functions
This Task identifies the safeguard functions currently implemented in the asset, based on the existing
safeguard mechanisms detected in previous Tasks and assessing the degree of implementation in
order to estimate their effectiveness, with the help of the procedures from Tasks 8.3.1 “Identify
safeguards functions” and 8.3.2 “Estimate safeguard function effectiveness” in the following
Stage 3.
Products:
• Report on the existing safeguard functions, with an indicator of their effectiveness..
7.8.3 Task 3: Evaluate the effective risk
This Task calculates the effective risk, taking into account the existing safeguard functions detected
during the previous Task.
There are some safeguard functions that reduce the frequency of the threats (decrease vulnerability)
and others reduce the impact. The new levels of vulnerability and impact are identified and estimated
by redoing the procedure established by the Activities “Identify and estimate vulnerabilities” and
“Identify and assess impacts” of this Stage.
The new levels of vulnerability and impact let us calculate the effective risk applying the risk
evaluation presented in the Task 1 of this same Activity.
Products:
• Report on effective risks in the system.
• Algorithm techniques.
7.9 Summarizing the Stage
• Control milestone 2-A: The Steering Committee must establish the risk thresholds, defining the
acceptable residual risk to be used in the following Stage as a means for selecting the risk
reducing safeguards in the selected level.
• Control milestone 2-B: The Management will decide whether to approve the results of the
Stage presented by the Project Manager.
7.9.2 Results
Intermediate documents
• Results of the interviews.
• Documents from other sources: statistics, experts’ and analysts’ observations.
• Auxiliary documents: plans, organizational charts, requirements, specifications, functional

analyses, load books, user’s manuals, information and processes flow-charts, data models,
etc.
• Results from classification and assessment of assets, existing safeguards, threats, vulnerabilities,
impacts and risks.
• Analysis of results, detection of key critical areas.
Final documents:
• Global risk, risk broken down by areas, critical areas and risk thresholds.
7.10.1 Role of the Risk Analysis and Management Team
· To execute the Stage.
7.10.2 Role of the Liaison Groups
• To provide the required documents.

• To be available for interviews
• To back the project.

• To control results.
• To select risk thresholds.
7.11.1. Activity 2.1: Gather information
Task 2.1.1 – Information Preparation - involves gathering the recent, formalized data from the last
computer and Analysis-Diagnostic Plan mentioned above.
Task 2.1.2 - Interview Conducting - includes all the Department Heads of the LPA related to
information systems (the names are fictitious):
Dª Mª Dolores López................................................ Expenses

D. Fernando Pérez ................................................... Treasury
D. Vicente García..................................................... Accounting
Dª Concha Gómez .................................................... Revenues
D. José Fernández..................................................... Real estate Tax
Dª Soledad Cuenca ....................................................Other taxes
D. Manuel Madrid ..................................................... Supplies
Dª M. Pilar Sevilla..................................................... Personnel
Dª Cristina Tortosa.................................................... Records
D. Fernando Palma ................................................... Files
Dª Inés Almería.......................................................... Census
D. Carlos Roma ......................................................... Cemeteries
D. Francisco París....................................................... Statistics
Dª Pilar Londres .........................................................Vaccinations
D. Emilio León............................................................ Cartography
Task 2.1.3 – Information Analysis - takes into consideration not only the results of the previous
interviews but also inspection visits to the work place at critical times (for during non office hours) as
well as document handling, operation and development of the systems used by the LPA.
7.11.2 Activity 2.2: Identify and group assets
Task 2.2.1 - Identifying Assets and Groups of Assets, comes after analyzing the information
gathered directly and indirectly, according to the premises of MAGERIT, tailored for the LPA as a
specific entity belonging to the Public Administration.
Due to the particularity of this case, this Task focuses on two big groups, user services and
processing services, of the LPA information systems. Both groups are broken down into 5 layers
specified in the MAGERIT Elements Submodel:
1. Environment
2. Information system
3. Information
4. Organization’s functionalities
5. Other assets
• User services are responsible for the three “dependent” types of assets (the functioning of the
assets that support them), i.e. the layers 3 for Information, 4 for Functionalities of the
Organization and 5 for Other Assets.
• Processing services are responsible for layers 2 and 1.
During the interviews and inspections information necessary for completing Task 2.2.2 - Identifying
Existing Safeguards - is also gathered.
Task 2.2.3 – Assessing Assets - is not essential for the purposes of this project (to carry out the
Risk Analysis and Management necessary to organize a rational contingency Plan, without the need
to justify the cost due to the returns obtained). Therefore, the important effort that asset assessment
represents has not been undertaken.
7.11.3 Activity 2.3: Identify and evaluate threats
Task 2.3.1 - Identifying and Grouping Threats – is limited to regrouping the types of threats identified
by MAGERIT in order to establish a reduced number of easily manageable disaster scenarios, which
are composed of an interrelated threat-vulnerability-impact group. As the Activity 2.6 will show, the
scenarios contemplate the following threat groups:
1. NATURAL OR INDUSTRIAL ACCIDENTS

2. DIRECT ATTACK WITHOUT A DIRECT BENEFIT.
3. TEMPORARY LOSS OF SERVICE
4. ERRORS OR DESIGN SHORTCOMINGS.
5. SOFTWARE AND DATA THEFT.
6. ATTACK ON SOFTWARE.
Task 2.3.2, which lets us establish the fault-trees generated by threats is included in the groups of
threats in scenarios above.
7.11.4 Activity 2.4: Identify and estimate vulnerabilities

Task 2.4.1 – Identifying Vulnerabilities for Each Threatened Asset of the user services or the
processing services - is carried out by the expert at the same time as Task 2.4.2 – Estimating
vulnerabilities – and within the application of a threat-vulnerability-impact scenario for each asset.
7.11.5 Activity 2.5: Identify and assess impacts
Task 2.5.1 - identifying impacts for each vulnerable asset of the user services or the processing
services - is carried out the expert at the same time as Task 2.5.2 – Classifying Impacts - and Task
2.5.3 – Assessing Impacts - within the application of a threat-vulnerability-impact scenario for each
asset.
7.11.6 Activity 2.6: Evaluate risk
In MAGERIT, the three Tasks of this Activity are abbreviated and carried out simultaneously. Thus,
the Task 2.6.1 – Assessing the Intrinsic Risk – is overlooked and we go directly to Task 2.6.3 –
Assessing the Effective Risk – after carrying out Task 2.6.2 – Analyzing the Existing Safeguards. The
project’s objectives do not require the separation of the existing safeguards or the isolation of the
intrinsic risk. During the description of each asset, it is sufficient for the expert to apply one of the
following scenarios, which are described below in the form of explanatory index cards:
DISASTER SCENARIO INDEX CARD DS1
· Type of threat: Natural or industrial accident

Includes MAGERIT accident types A1 and A3:
- A1: Physical accident of industrial origin: fire, explosion, flood from a burst pipe, pollution,...
- A3: Physical accident of natural origin: Flood, lighting, earthquake, landslide, ...
· Affectable assets: Data Processing Center CU’s physical system and environment.
· Vulnerability: While A3 can be considered exceptional, A1 has a higher occurrence frequency. Even taking
into account the vulnerability reduction obtained, for instance, by the fire protection measures in the
organization’s processing center, this is still considered a high risk (a basement surrounded by boilers
and highly flammable files) without the possibility of changing the location in the short term. The
“attacker” in this case is nature or the industrial environment, which obviously act without a motivation,
are random (although this does not exclude certain a degree of predictability and as a result the possible
reduction of risk exposure) and very powerful.
· Type of impact: Major losses:

- N1 Financial: Appraisal, replacement, repair o cleaning costs.
- N2 Non-material: Appraisal, replacement or repair costs of non-material elements of the system: data,
DISASTER SCENARIO DS2
· Type of threat: Physical attack without a direct benefit.
· Affectable assets: Data Processing Center CU’s physical system and environment.
· Vulnerability: Is directly related to the facility of physical access to the asset (controls are clear deterrents).
This type of attack can be devastating if the core of the system is affected (i.e. the CU). The attacker will be
a person with little technical knowledge, motivated by ideological or psychological factors rather than
financial reasons. The exposure is directly linked to the lack of physical access controls, since the attacker
takes a low risk (his/her non-economic motivation will not be deterred by severe penalties). A low level of
force will be enough for the attacker, since he/she does not need technical ability or sophisticated
resources.
· Type of impact: Major losses:

- N1, economic: Appraisal, replacement, repair o cleaning costs
- N2, non-material: Appraisal, replacement or repair costs of non-material system elements: data, programmes,
documents, procedures.
· Type of threat: temporary loss of service due to:

- A2: Physical or logical breakdown.
- A4: Temporary loss of essential services or supplies: power, water, telecommunications, different
types of fluids and supplies.
- A5: Mechanical or electromagnetic accidents: crashes, drops, foreign bodies.
-P5: Unavailability of human or technical resources (use diversion, blockage).
· Vulnerability: Although less frequently, these 3 types of accident are still possible, especially in
peripheral posts, due to power shortages from the lack of uninterrupted power supply or problems in
communication lines due to the lack of preventive maintenance or spare terminals, or to a faulty
installation. The “attackers” are the shortcomings in internal services or installations or deficient
preventive maintenance, and thus, lack a motivation. The natural exposure is medium and depends on
specific (such as electrical network overload) random situations. The force required for the attack is low
(no technical ability or special means are needed).
· Type of threat: design errors or shortcomings:

Includes MAGERIT’s whole E errors group:
- E1: Usage errors during the data gathering and transmission or processing.
- E2: Design errors in the software development procedures.
- E3: Wrong path/wrong sequence of message handling.
- E4: Inadequate traffic monitorization/traceability/registry
· Vulnerability: In spite of their apparently different origins, all these errors are attributable to problems in
design, defined in its broadest sense. Therefore, error E1 is more easily detected than E2 (it can be due to
a lack of internal verification routines or matching against other external information) while errors E3 and
E4 depend on the communication software. In all cases and for competent, well-equipped development
and operation teams, the possibility of error will be lower (higher for E1 than for the rest). In terms of the
attacker, development technicians do not have reason for making this type of mistakes. In complex
applications, the exposure is medium. The “attacker” needs only a low level of force since he/she lacks
responsibility, but his/her work can be traced and the probability of error increases as technical ability
decreases.
· Affectable assets: The application with errors and the dependent service.
· Type of impact: Minor losses due to:

- SD. Unavailability: lower margin or expenses to maintain operation.
- L2. Breach of legal duties.
- L3. Upsetting or embarrassing political-administrative situation (for example: loss of credibility, prestige...)
· Type of threat: logical theft, which includes:

- P3 and T1: Logical access with theft (from inside the organization or remote-controlled): using the
system, reducing its confidentiality in order to obtain usable goods or services (programs, data...).
· Vulnerability: In general, this type of threat depends on the intrinsic value of the material that can be
stolen. The value of the information is the attacker’s main motivation. The attacker must have a high
accessibility to the asset and requires a high level of force if we take into account the technical ability
required and the traceability of the attack. All of the above indicate that the potential attacker most
likely will be someone from inside the institution.
· Affectable asset: stolen information.
· Type of impact: Medium losses of:

- SC. Confidentiality.
- L3. Upsetting or embarrassing political-administrative situation.
· Type of threat: logical attack, including:

- P4 and T2: Logical access with destruction (from inside the organization or remote-controlled): using the
system to reduce its integrity and/or availability without a direct benefit (non-material sabotage,
viruses...)
· Vulnerability: Direct vulnerability to the central system’s programs is low, since it requires a great
technical ability to break the access defences. However, the vulnerability can be high for the central
system data or the programs of the PCs (either due to incompetence or lack of precautions in checking
inputs). The lack of an economic motivation combined with a high natural accessibility from outside the
programs of the central system and the low force necessary (given the relative impunity due to the
difficult traceability and the low required technical ability) indicate that the potential attacker will be an
unmotivated or uninformed.
· Affectable assets: They are more numerous than the attacked asset, and include the programs affected by
the viruses or the data affected by the attack or negligence.
· Type of impact: many minor losses due to:
- N1, economic: Appraisal, replacement, repair o cleaning costs

- N2, non-material: Appraisal, replacement or repair costs of non-material system elements: data, programs,
documents, procedures.
- L3. Upsetting or embarrassing political-administrative situation (loss of credibility, prestige, political
competence...)
- SD. Unavailability: lower margins due to a decline in profits; or additional expenses to maintain the
functionality existing before the threat.
Example of a user service’s asset
The application of the previous scenarios for the risk analysis of an asset (information system) in a
typical user service such as the Registry and Follow-up of Proceedings. The risk analyst (in this case,
an external consultant) had already made an approach to the Department taking into consideration
the answers given by the user to a questionnaire previously handed to him.
In this Task, one of the 6 previous scenarios is “embedded” where appropriate in the report. At the
same time or subsequently, the analyst deduces the levels of risk criticality in each “encrustation”,
therefore, the initial report becomes a “report on assessed effective risks”.
Taking the selected asset, the report should state, in the first place, that the mission of the
proceedings Department is to control and follow up their evolution inside the organization. This
answers to a two-fold requirement: the legal obligation (Law 30/1992 LRJ/PAC) of informing the
affected citizen of the situation of the proceedings related to him and to the interest of the
Administration itself in knowing the state of its production.
• In case this mission is not fulfilled, the proceedings will come to a halt and this will prejudice the
citizen, with an impact L2 - breach of legal duties - and an impact L3 - upsetting or
embarrassing political-administrative situation.
As far as risk assessment is concerned, and although no statistic data are still available, the
organization attends to more than 30,000 proceedings per year. The application has 100 users
(included around 40 Heads of Department with their corresponding terminals).
• As they are linked to the host where the application is installed, if DS1 or DS2 take place, they
can cause the unfulfillment of the Service mission with a very high impact, and low and high risks
respectively.
The proceedings are started either by the organization itself or by requests that arrive to the input
registry (through which other documents incorporate to the proceedings already started.) The
registered documents are entered in the system so as to be “sent” to the corresponding unit. This unit
conducts them using computers and when the proceedings are finished, it closes them in the host and
send them to the receiving unit asking for acknowledgment of receipt. After a period of 10 days
without a reply, an “alarm” sets off in the system as a reminder.
This “open” chain of proceedings as they pass through the adequate units is simplest than a
“predetermined” chain, however, the whole process stops if a units interrupts it (the system allows
knowing which is the interrupting unit).
• A potential DS1 or DS2 could provoke non-compliance with the Department’s mission with a
very severe impact, with the corresponding vulnerabilities and medium and high risks
respectively.
Certain proceedings considered critical entail problems due to the Administration silence (that can
have a “positive” effect under Law 30/1992 LRJ/PAC).
• A potential DS1 or DS2 could provoke non-compliance with the Department’s mission with a
very severe impact with the corresponding vulnerabilities and a high and very high risks
respectively.
The main mission of the General Registry, which uses part of the information system which is
related to proceedings (input and output registries) is to register every document coming into and
going out of the organization.
• The non-compliance with this mission would result in a serious harm both for the Corporation
and for the citizen due to the potential failure to meet the terms established by the Law, with a L2
impact, as well as the freezing of activities in the remaining administrative units (with SD and
possibly SI impacts) and a loss of prestige for the organization (with L3 impact).
As far as assessment is concerned, the input Registry receives a daily average of 1,000 forms (with
peaks of 2,000) from which 10 per cent are considered urgent. Although there are no time limits to
register them, the documents must be conducted and sent to the proceedings circuit as soon as
possible, because until they do not arrive to the Register, proceedings cannot be opened; therefore,
the materialization of threats in the Registry and the risk criticality assessed according to the
application of the disaster scenarios in the Registry is transmitted to the proceedings circuit (not
opened) and to the criticality of the risks mentioned in the previous paragraphs.
In every of the 8 input registry centers (the central one and the others) the information included in
the documents presented by the citizens is recorded and entered into the system. The documents are
grouped according to their destination (the internal handling units or the Registries of other centers) in
packages and sent with duplicated shipment lists produced by the host aimed at the different handling
units (around 70) of the Departments. The 17 Registry terminals are linked to the host where the
software is installed.
• In case of a DS1 or DS2 in the central system, a non-compliance with the service mission of
very severe impact, with the corresponding vulnerabilities and with medium and high risks
respectively.
The output Registry process is automatically generated since the proceedings circuit is
computerized (although the handling unit does not allocate an output number in the proceedings) and
therefore, it does not entail a problem of time limits or sensitive risk.
• On the other hand, the fact that the information existing in the system is not fully exploited (the
application would allow to enter precodified repeated texts) can reflect a DS4, with a low
impact and a high vulnerability, that is to say, with a low risk.
• The lack of experience in the use of passwords (only the civil servant’s number is used) entails a
DS5 and DS6 that, taken as a group, pose a low probability threat and SC and L3 impacts; in
both cases there is a low risk.
• Likewise, the possibility or the will to change the input dates in the registry imply a DS5 with a
medium impact, a low vulnerability and a low risk.
• Access by non-authorized persons to the terminal sites in the morning and in the afternoon, when
the premises are without vigilance implies a potential DS2 with medium impact and high
vulnerability, that is to say, with a low risk.
Example of a processing service’s asset
The risk analysis of assets of processing services is made in the traditional areas:
- Organizational environment
- Physical environment
- Hardware and software
- Communications
- Operation
- Applications development
Only the “assets” whose security is relevant for the Contingency Plan as the project’s objective are
included here.
For instance, the location of the main hardware (CPU, disks, printers, hubs ...) in the basement
implies a potential DS1, with critical impact and insignificant potentiality, resulting in a high risk; and
a potential DS2, with a very severe impact and low potentiality, resulting in a high risk.
In the processing central unit there is no computer material redundancy, although one of the
objectives of the present study is to prevent redundancy through an off-site center. There are several
hubs, although currently they are located in the basement, near the computer. The central printers are
also redundant, although both of them are located in the basement.
The concentration of the above-mentioned elements in the computer site (in the basement) cancels
out the security of these redundancies and implies that a potential DS1 or DS2 could have a very
severe impact, since it would provoke the disruption of service, with an insignificant or low
potentiality respectively, resulting in a low or high risk, respectively.
As for the location of the communication devices, that is to say: hubs connected to the computer
channel, the communication processor, multiplexors, etc., are located in the computer site. This
implies a potential disaster scenario DS1 -natural/industrial disaster- with a critical impact and an
insignificant potentiality resulting in a high risk; and a potential disaster scenario DS2 -physical
attack- with a critical impact and a low potentiality which results in a very high risk.
Backup container. This area is located in the computer site, thus implying a potential disaster
scenario DS1, with very serious impact and insignificant potentiality, which results in a low risk. and a
potential DS2 with a severe impact and a low potentiality resulting in a high risk.
Backup copies. Backup copies of data, software and the whole environment of development are
made on a regular basis, keeping a number of version numbers in certain storing places. These
aspects will be thoroughly studied in the IV part. However, the backup copies stored in the CIM
building (Systems Department) are stored on a weekly basis, entailing a potential disaster scenario
DS1 -natural/industrial disaster- with a critical impact and insignificant potentiality, thus resulting in a
high risk; and a potential disaster scenario DS2 -physical attack- with a critical impact and a low
potentiality, thus resulting in a very high risk.
Operation documentation. The documents for exploitation, both the manual of exploitation
operation and the manuals for exploitation of the different applications, are not updated and this
entails a potential DS4, design errors, with a medium impact and high potentiality resulting in a low
risk. In some cases, the documents on applications, or on modifications to applications, are scarce
for the exploitation process, entailing a potential DS4, with a medium impact and high potentiality
resulting in a low risk.
Operation follow-up. There is an exploitation plan, and the work is carried out according to that
plan. The operators produce an Activity report on a daily basis including the fulfilled tasks, results
and incidents. There is a procedure of visual control and record of such Activity reports.
In the case of incidents, they are written down on a notebook and their features and the measures
adopted are reflected. The request of batch by the users is automatically made, since it includes
parameters in on line processes that, when the batch starts, provide the necessary data and execute
the request. However, in outdated applications or in special cases, it is established the filling in of a
standardized form to make the request. Periodically, summaries of the computer usage are made
(CPU times, transactions rate by terminal, deviations from the mean...). Transition of programs from
the development Stage to the production one (exploitation) is made through an intermediate Stage -
the integration one-, where the sources to update the pointers to files are re-compiled. There are one
or two authorized persons by application in the transition from development to integration. Only the
executable programs can access the production Stage. This entails a potential disaster scenario DS6,
with a medium impact and insignificant potentiality, resulting in a very low risk.
Material maintenance. The maintenance of the software and hardware is made by external
contractors, who are in charge of the preventive and corrective maintenance. No problem has been
detected in the discharge of their duties, but they do not keep a daily record. This is connected to a
potential disaster scenario DS3, with a medium impact and insignificant potentiality resulting in a very
low risk. The installment of computer material (terminals, printers, hubs,...) is usually made by the
personnel of the LPA’s Department of Systems. The maintenance of the software is carried out by
the providers. Malfunctions, and the corrective measures taken to solve them are recorded in a PC.
If the gathered information is not exploited, this could be related to a disaster scenario ES3, of
temporary loss of service, with a medium impact and insignificant potentiality, resulting in a very low
risk.
Configuration management. Currently, there is no control over changes that allows to monitor
modifications in applications. Currently, there is no thorough monitoring of the configurations that
allows controlling the current version of every application and of the previous ones. This implies a
potential disaster scenario DS4, with a very serious impact and medium potentiality, resulting in a
high risk.
Development documentation. User’s manuals for the new applications are produced, although
they are not updated to include subsequent modifications, thus leading to a potential disaster scenario
DS4, design errors, with a very severe impact and medium potentiality, leading to a high risk. The
applications’ operating instructions are not very complete (design/1 is partially used), they are not
always updated thus leading to a potential disaster scenario DS4, with a very severe impact and
medium potentiality, resulting in a high risk.
Development methodologies. The lack of a specific development methodology and its

corresponding support tool implies a possible ES4 disaster scenario. Design errors, with a severe
impact and a medium potentiality, resulting in a high risk.
8. STAGE 3: RISK MANAGEMENT
8.0 Location of the stage 3 within the MAGERIT model
MAGERIT Model


· Threats · Organizational dynamic
· Vulnerabilities · Physical dynamic
· Risk analysis
· Safeguards
STAGE 1:
PLANNING
Activities:
implementation
objectives
1.3: Project organization and ò
planning
ò
ñ
STAGE 2: STAGE 3:
STAGE 4:

SAFEGUARD SELECTION
Activities: Activities:
ð Activities:
mechanisms
2.3: Identify & evaluate safeguard functions and
4.2: Select safeguard mechanism
THREATS services
4.3: Specify mechanisms to be
2.4: Identify & estimate 3.3: Select safeguard
implemented
VULNERABILITIES functions and services
4.4: Plan implementation
2.5: Identify & assess IMPACTS 3.4: Achieve objectives
8.2.1 Objectives
The objectives of this stage are identifying and selecting the appropriate safeguard functions to
reduce the risk to an acceptable level.
8.2.2 Contents
The starting points of this stage include the documents of the previous stage, related to the
description of the risk components (assets, existing safeguard functions and mechanisms, threats,
vulnerabilities and impacts), to the calculated risk levels and to the risk thresholds agreed by the
Steering Committee.
The risk metrics underlies any possible estimation of the different safeguard functions with or without “prioritization”
among them to deduce, among the alternative decisions, those which neutralize the risks as cost -effectively as possible.
Thus, the security expert is the protagonist of this stage.
8.2.3 Summary of the Activities’ content
1. Interpret RISK
Interpretation of the results generated in previous activities aiming at finding out the main critical
areas.
2. Identify and estimate safeguards functions and services
To identify and estimate the effectiveness of the safeguard functions or services necessary to reduce
the risk to the agreed thresholds.
3. Select safeguards functions and services
To select optimal safeguard functions or services able to reduce risk.
4. Achieve objectives
To study the residual risks obtained after implementing the selected safeguard functions and services
in order to determine whether they are within the selected risk thresholds.
8.3 Activity 1: Interpret RISK
The starting points of this activity include the documents of the previous state, which describes the
risk components (assets, existing safeguard functions and mechanisms, threats, vulnerabilities and
impacts) and the calculated risk levels.
8.3.1 Single Task: Interpret risk
The results of the effective and intrinsic risk calculation have to be interpreted before using them,
grouping them in order to identify the areas with a higher risk which need higher protection. Thus,
• The risk threshold is a value set as a base to decide -by comparison- whether the calculated
effective risk is acceptable. The used risk thresholds can be the result of an initial estimation,
ratified by the decision of the Steering Committee and proposed considering its similitude with
other cases. These risk thresholds can be fine tuned by implementing Risk Analysis and
Management in a scenario of balance simulation between risk costs and safeguards costs within
an environment with certain constraints (for example, the organization’s Tasks or its short-term
budgetary capability).
• If the calculated effective risk is considered as non-acceptable, MAGERIT proposes to
develop the following activities: “identification, effectiveness estimation and selection of
safeguard functions” of this stage.
• When the calculated effective risk is considered as acceptable, it will remain as residual risk.
The Task also includes the collection of statistical indicators on the threat occurrence frequencies
(vulnerability), threats with higher impact, areas affected by higher risks, and so on.
Products:
• Reports on risk interpretation.
• Statistical estimators
• Charts (Kiviat or bar diagrams).
• Statistical Techniques
8.4 Activity 2: Identify and estimate safeguards functions and services.
This activity identifies the safeguard services and functions which reduce the risk and estimates their
effectiveness in achieving such reduction.
RISK ANALYSIS

SAFEGUARD FUNCTIONS
Identify safeguard functions

and services
ò
Estimate effectiveness
of safeguard
functions and services
ò
SELECT SAFEGUARDS
FUNCTIONS AND
SERVICES
8.4.1 Task 1: Identify safeguard functions and services
This Task proposes, without considering any constraint, a list of safeguard functions and services
which can reduce the risk over the threshold in the subdomains identified in the stage 2 “Risk
Analysis”.
The proposed functions or services are determined with the help of the groups assets/threats where a
higher risk is detected. The organization or classification of safeguard functions and services is based
on the types included in the elements submodel:
- assets or groups of assets (environment, information system, functionality, others);
- threats (accidents, errors, deliberate inside the organization, deliberate remote);
- the functionality of functions and services (oriented towards: detection, deterrence,

prevention, correction, recovery, awareness/information).
The list includes a description of the safeguard functions and services, for example: type of threat,
type of protected asset, which security substate they are oriented towards (A-C-I-Av), result
(vulnerability or impact reduction), etc.
Products:
• Report on proposed safeguard functions.
• Matrix techniques
8.4.2 Task 2: Estimate the effectiveness of safeguard functions and services
Starting from the function and service safeguard list specified for the selected subdomains of the
project, this Task estimates their effectiveness in reducing the elements the risk is made up of
(vulnerability and impact).
This effectiveness, that can be measured by an expert, depends on objective

conditions (the complementarity or contradiction with other installed
safeguards) or subjective ones (the constraints that have not been taken
into account in the previous Task).
Products:
• Report on the proposed safeguard functions or services and effectiveness estimation.
• Cost-benefit analysis.
8.5 Activity 3: Select safeguards functions and services
The activity selects the adequate safeguard functions and services which are justified as
proportionate to the risks they have to cover.

SAFEGUARD FUNCTIONS
AND SERVICES
SELECT SAFEGUARD FUNCTIONS AND SERVICES
Apply selection parameters
Evaluate
the residual risk
SAFEGUARDS
SELECTION
8.5.1 Task 1: Apply selection parameters
Based on the list of proposed safeguard functions and services, and keeping in mind the maximum
risk thresholds that can be assumed or accepted according to the previous tasks and decisions, the
task ranks the safeguards according to their risk reduction effectiveness.
From the established ranking, the task selects the functions or services that reduce the risk to the
threshold level required by the established security objective.
Products:
• A list of safeguard functions or services organized by asset/threat and ranked according to their
effectiveness.
• Matrix Techniques
8.5.2 Task 2: Reevaluate the risk
The task applies the selected safeguard functions and services to reducing the frequency of threat
occurrence (reducing the vulnerability) and their impact. The new vulnerability and impact levels are
identified and estimated by redoing the procedure established by the Stage 2 Activities “Identify and
estimate VULNERABILITIES and Identify and evaluate IMPACTS.”
The new vulnerability and impact levels allow for the calculation of the effective risk applying the
same method of risk evaluation presented earlier in the single task of Activity 1 of this Stage.
This effective risk value that has been calculated must be saved, as it will be the residual risk if the
Risk Analysis and Management project objectives are reached in the following Activity 4.
Products:
• Report on the residual risk in the system.
• Matrix Techniques.
• Algorithm
8.6 Activity 4: Achieve objectives
The activity assesses whether the effective risks resulting from the implementation of the selected
safeguard functions and services are under the selected risk thresholds.
8.6.1 Single Task: Determine the objectives achievement
If the effective risks calculated in the previous Task are not reduced under the fixed risk thresholds,
the Task will:
- provisionally save the achieved partial results (there can be “retrocessions” in this
simulation process);
- repeat activity 3 (select safeguard functions and services), this is to say, reconsider the
selection and reevaluate the risk before re-checking the achievement of the objectives.
Products:
• Approval of the list of selected safeguard functions
• Simulation
• Control Milestone 2-A: The Steering Committee must approve the set of proposed safeguard
functions and services.
• Control Milestone 2-B: The Management will proceed to approve or not the results of the
stage presented by the Project Manager.
8.7.2 Results
Interim documents
• List of safeguard functions and services ordered according their effectiveness and with a
description of their characteristics.
• Report on the existing safeguard functions and services and an estimation of their effectiveness.
• Report on selected safeguard functions and services with the adequate justification.
• New values of the risk when applying the proposed safeguard functions and services.
• Report on the comparative study of the simulations’ results.
Final documents
• Final list of proposed safeguard functions and services.
8.8.1 Role of the Risk Analysis and Management Project Team

• Executing the stage.
• Controlling results.
• Selecting safeguard functions.
8.9.1 Activity 3.1: Interpret risk
The disaster scenarios which have served as a model to describe the concrete combinations threat-
vulnerability-impacts are the subscenario of attacks of the dynamic organizational submodel of events
which, combined with the subscenario of defense adequate to each IS implement a vulnerability
scenario which will be reduced by applying the two aspects of the subscenario of defense:
effectiveness and strength.
The previous study of the example, aiming at preparing a Contingency Plan, intends to establish a
first categorization of scenarios of vulnerability (threats and defenses) and focuses only on high or
very high risks, determining the most adequate combination threat-safeguard for each of them.
As a result of the risk analysis, the different areas and functions of the processing services, the
proportion of high or very high risks is higher than those reflected in the analysis in the user services.
This result is logical, consistent and even helpful. The LPA’s computer environment is centralized,
which entails an accumulation of computer risks assumed by the processing Center. Thus, it is clear
that it is necessary to consider carefully the operation of its elements which contribute to the final
result and also to make more prospective efforts to imagine potential attack scenarios and
vulnerability situations, even in the cases where the normal operation of the services does not cause
any problem. Thus, it should not surprise anybody the high percentage of high risks -in fact more
potential than real- since they are the logical basis of the intense security measures as, for example,
the two requirements, specified in the stage 4: contracting an external supporting center and assuring
the coinciding measures to achieve an efficient work in emergence situations.
8.9.2 Activity 3.2: Identify and estimate safeguard functions and services
The Tasks 3.2.1 – Identifying Safeguard Functions - and 3.2.2 - Estimating the Effectiveness of
Safeguard Functions - have to be developed by an expert. The detailed design of the safeguards
necessary to transform a scenario of disaster into a scenario of vulnerability starts from an initial set
of specific safeguard measures which considers the traditional groups according to the computer
services’ environment:
- Organizational measures
- Physical measures
- Basic architecture measures
- Measures in security software
- Measures in the mediums
- Measures in the communications
- Measures in the development of applications
- Measures in the operation.
The previous survey carried out with MAGERIT does not intend to replace a security handbook
which will be the objective of the global security Plan. It will only address the high or very high risk
disaster scenarios, particularizing for each area the most appropriate safeguard measures and making
a short comment on them.
In every user services, the disaster scenarios DS1 and DS2 which lead to a critical situation, usually
“transfer” this situation to the Data Processing Center of the LPA, within its centralized computer
system. This chapter includes the adequate general safeguard measures, which will reduce the risk to
appropriate levels. The analysis of these safeguard functions is described as “recommendations”
and is included in the areas addressed in previous chapters:
- Organizational environment
- Physical environment
- Software and hardware
- Communication
- Operation
- Applications development
RECOMMENDATIONS FOR THE ORGANIZATIONAL ENVIRONMENT
The location of the main hardware (CPU, diskettes, printers, hubs...) in the basement and
surrounded by spotlights and combustible material implies a potential disaster scenario DS1 -
natural/industrial disaster- with a critical impact and with insignificant potentiality which leads to a high
risk and a potential disaster scenario DS2 -physical attack- that cause a very serious impact with a
low potentiality which implies a high risk. To reduce the potentiality in these scenarios, several
structural, preventive and dissuasive measures have been outlined. Should these measures are not
effective (the threat materializes and the attack is carried out) it will be necessary to apply palliative
measures to reduce the impact caused by the attack and to have the computer system into operation.
It will be essential to have an alternative center available as well as the procedures necessary to
assure the right operation of the critical applications of the computer system.
Regarding the duplication of the computer equipment, there are several hubs, although they are
all located in the basement, besides the computer. The central printers are also duplicated and are
also in the basement. The location of this equipment in the computer site, in the basement, diminishes
the security of these duplications and gives rise to a potential disaster scenario DE2 -physical attack-
that can cause a very serious impact -since it will lead to the disruption of the activities- with a low
potentiality which implies a high risk. To reduce the impact in this scenario, it will be necessary to
move this equipment to another place.
RECOMMENDATIONS FOR COMMUNICATIONS
Location of the communication devices. The hubs connected to the computer channel, the
communication processor, the multiplexors, etc., are located in the computer site. This implies a
potential disaster scenario DS1 -natural/industrial disaster- with a critical impact and a worthless
potentiality which leads to a high risk; and a potential disaster scenario DS2 -physical attack- with a
critical impact and a low potentiality which results in a very high criticality 4. Should any of the
above-mentioned scenarios materializes, the palliative measure (to find an alternative location) will
not be effective since the communication devices are the basis of the teleprocessing which is
necessary for the operation of the critical applications. From all above we can infer that it is
necessary to locate the communication devices outside the basement.
RECOMMENDATIONS FOR OPERATION
Backup container. This area is located in the computer site (as we have already mentioned), thus
implying a potential disaster scenario DS2 -physical attack- with very serious impact and low
potentiality which results in a high risk. The reduction of the impact in this scenario makes it
necessary to implement measures aimed at separating the file area from the tape library, installing
access controls and other security measures.
Backup copies. Information is stored in the backup copies on a weekly basis outside the LPA
building. This implies a potential disaster scenario DS1 -natural/industrial disaster- with a critical
impact and worthless potentiality, thus resulting in a high risk and a potential disaster scenario DS2 -
physical attack- with a critical impact and a low potentiality, thus resulting in a very high risk. The
above-mentioned palliative measures -an alternative center- would not be effective anymore if
updated backup copies are not available. Although in the stage 4 the backup issue is analyzed in
detail, it is advisable to take the following aspects into consideration:
• There will be a written backup plan including for each file the version numbers, the periodicity,
the storing site and the length of the storage period.
• This plan will be systematically updated when any application is created or modified,
taking into account the integration scheme of the information circulation and the new files-
processing.
• The backup copies must be loaded on a regular basis, in a separate virtual environment, to check
whether they are complete.
8.9.3 Activity 3.3: Select safeguard functions and services
Tasks 3.3.1 - Apply Selection Criteria - and 3.3.2 - Risk Assessment - are not relevant to the goal
pursued by the example project.
8.9.4 Activity 3.4: Achieve objectives
Task 3.4.1 has not been carried out, since it is not relevant to the goal pursued by the project shown
as an example.
9. STAGE 4: SAFEGUARDS SELECTION
MAGERIT model


- Risk
- Safeguards
STAGE 1:
PLANNING
Activities:
implementation
objectives
ò
planning
1.4: Project launching
Planning & oth er
ò
ñ
STAGE 2: STAGE 3:
STAGE 4:

SAFEGUARD SELECTION
Activiti es: Activities:
ð Activities:
mechanisms
2.3: Identify & evaluate safeguard functions and
4.2: Select safeguard mechanism
THREATS services
4.3: Specify mechanisms to be
2.4: Identify & estimate 3.3: Select safeguard
implemented
VULNERABILITIES functions and services
4.4: Plan implementation
2.5: Identify & assess IMPACTS 3.4: Achieve objectives
9.2. Overview of Stage 4
9.2.1.Objectives
The Objective of the stage is to select safeguard mechanisms that materialize the safeguards’
functions and services, to respect the constraints and to reduce the risks below the desired
thresholds.
9.2.2 Contents
This stage stems from the previous stages’ results:
• Identification of the safeguard mechanisms currently in force, and the safeguard functions and
services they cover, as well as their degree of implementation.
• The selected safeguard functions and services, able to reduce risks reaching the previously
selected thresholds (or those updated if necessary).
In this stage, the specialist selects the safeguard mechanisms that materialize
the selected functions and services by their effectiveness. Once the mechanisms
have been selected, their relationships, costs, types and other characteristics
are studied. After analyzing the possible contradictions or inconsistencies in its
application, the stage establishes a priority ranking for its implementation
(excluded from MAGERIT), reflected in chronological charts (chronograms)
for implementation.
Finally, this stage makes possible the compilation of all the gathered reports to draw up the Risk
Analysis and Management Final Report, as well as the documents showing the results at the
organization’s different levels.
9.2.3. Summary of the Activities’ contents
The Activities in this stage are the following:
1. Identify safeguard mechanisms
This Activity identifies the mechanisms that can materialize the safeguard functions and services.
2. Select safeguard mechanisms
This Activity selects and studies the safeguard mechanisms that fulfill the constraints and reach
enough effectiveness to reduce the risk level.
3. Specify mechanisms to be implemented
The Task specifies some important characteristics for the selected safeguard mechanisms.
4. Plan implementation
The prioritization of the selected mechanisms together with estimation the needed resources lets us
carry out an approximation of the implementation time chart (chronogram).
5. Integrate results
In this final Activity we recompile the Stage reports in order to draw up the final report and the
corresponding documents for the presentation of the different levels.
9.3. Activity 1: Identify safeguard mechanisms
After selecting, in the previous stage, the safeguard functions and services able to maintain the risks
below the selected thresholds, this Activity seeks to identify and analyze the possible safeguard
mechanisms that materialize the mentioned functions.
RISK MANAGEMENT
ê
IDENTIFY SAFEGUARD MECHANISMS

ê
Identify potential mechanisms
ê
Study the implemented mechanisms
ê
Incorporate constraints
ê
SELECT SAFEGUARD MECHANISMS
9.3.1. Task 1: Identify potential mechanisms
This Task establishes a list of possible safeguard mechanisms that materialize the selected safeguard
functions and services or part of those safeguard functions and services. These safeguard functions
and services are habitually associated to the assets’ impacts and vulnerabilities when facing threats,
and let us identify the possible set of safeguard mechanisms.
In this Task the analysis of the cost, effectiveness, maintenance needs, etc. of the possible
mechanisms for the safeguard functions and services’ materialization is not taken into account.
Products:
• Report on the potential safeguard mechanisms.
• Drafting reports.
• Matrices
9.3.2. Task 2: Study the implemented mechanisms
Some safeguard mechanisms identified in the previous Task could be already implemented in the
domain under study.
This Task recovers the information gathered while collecting the domain’s data, which identified the
already implemented mechanisms and their characteristics. These mechanisms are divided into two
groups:
• Mechanisms that coincide with one of the contents in the list of the potential mechanisms from the
previous Task.
• Mechanisms not included in that list.
The mechanisms included in both groups are analyzed according to several criteria:
• Their degree of implementation
• The cost of their initial implementation as well as their maintenance costs.
• Their effectiveness
Products:
• Report on the implemented mechanisms
• Drafting reports
• Matrices
9.3.3. Task 3: Incorporate constraints
This Task sets the identified constraints in the information gathering Activities of stage 1. The
Executive Director could have modified the set of constraints as a consequence of the results of the
risk analysis in the second stage.
In order to add the constraints to the Risk Analysis and Management, their grouping by concepts is
respected. In this Task the same classification as that of stage 1 is maintained: in six groups of
constraints: temporary, financing, technical, sociological, environmental and legal.
Products:
• Report on constraints.
9.4. Activity 2: Select safeguard mechanisms
This Activity allows us to identify and select the mechanisms to be implemented, considering the
previous Task’s detected and included constraints. The identified and selected mechanisms are
provisionally studied regarding their effectiveness when reducing risks.
This Activity is iterative as it can be repeated as many times as necessary to establish the set of
mechanisms to be implemented definitively.
IDENTIFY SAFEGUARD MECHANISMS
ê
SELECT SAFEGUARD MECHANISMS
ê
Identify mechanisms to be implemented
ê
Evaluate risk
ê
Select mechanisms to be implemented
ê
SPECIFY MECHANISMS TO BE IMPLEMENTED
9.4.1. Task 1: Identify mechanisms to be implemented
In this Task the specialist seeks to “filter” the potential list of mechanisms
determined in the previous tasks, taking into account the set of constraints that
have been detected and included (it is a very sensitive and repetitive task).
We get a new set of mechanisms that considers the set of constraints, reducing the risk levels up to
the selected thresholds.
Products:
• Report on the selected mechanisms.
9.4.2. Task 2: Evaluate risk (of the selected mechanisms)
This Task studies the risk reducing power of the selected mechanisms by means of the safeguard
functions and services that the risk materializes.
Products:
• Report on the risk evaluation with the selected mechanisms.
• Matrices
• Algorithm techniques
9.4.3. Task 3: Select mechanisms to be implemented
This Task marks and selects the set of mechanisms obtained in the previous Task as reducing the
risk, without being subjected to the imposed constraints.
Products:
• Report on the selected mechanisms
9.5. Activity 3: Specify mechanisms to be implemented
9.5.1. Single Task: Specify mechanisms to be implemented
This Task specifies some important characteristics for the selected safeguard mechanisms, such as:
• Type of mechanism
• Approximate cost
• Protected assets
• Dependence on other mechanisms
• Implementation mode
• Others
Products:
• Report on the mechanisms to be implemented
• Matrices
9.6. Activity 4: Plan implementation
The objective of this Activity is to carry out a sketch of the implementation planning of the
mechanisms considered in the previous Activities.
SPECIFY MECHANISMS TO BE IMPLEMENTED
PLAN IMPLEMENTATION
ê
Prioritize mechanisms
ê
Evaluate the necessary resources
ê
Produce tentative time charts
INTEGRATE RESULTS
9.6.1. Task 1: prioritize mechanisms
This Task orders logically and structurally the mechanisms considered and puts them into the
framework of potential projects for implementation, based on their interdependencies, taking into
account the constraints and the accepted risk levels.
The mechanisms’ classification in safeguard functions and services favors this list of priorities.
Products:
• Report on the mechanisms for implementation.

9.6.2. Task 2: Evaluate the necessary resources
This Task assesses and estimates the resources, both human and material, needed for the
mechanisms’ implementation.
The mechanisms’ classification by types of resources to be mobilized (organizational, technical,

material, financial, etc.) favors the assessment and estimation.
Products:
• Report on the resources’ evaluation.
9.6.3. Task 3: Produce tentative time charts
Once the measures to be carried out for the mechanisms’ implementation and their implementation
deadline have been defined, this Task schedules them and elaborates the tentative time charts for the
mechanisms’ implementation.
Products:
• Time charts (chronograms).
Gantt techniques.
9.7. Activity 5: Integrate results
9.7.1. Single Task: Integrate results
This final Activity compiles the reports drawn up in the different project’s stages and Activities to
write down the “Risk Analysis and Management’s final report”.
This Task also makes the documents that present the project’s results, which are delivered to the
management levels and to the users affected by the Risk Analysis and Management’s project.
Products:
• Risk Analysis and Management’s final report.

• The project presentation documents.
• Presentation techniques.
9.8. Summarizing the stage
9.8.1. Control milestones

Control milestone 2-A: the Steering Committee should approve the set of safeguard mechanisms
proposed for implementation, the needed resources, as well as the way to carry out that
implementation.
Control milestone 2-B: the Management may or may not approve the stage’s results presented by
the project Director.
9.8.2. Results
Interim documents:
• Documents related to the selected mechanisms and their characteristics, their way of
implementation and the needed resources for the latter.
Final document:
• The main document of the project: “the Risk Analysis and Management Final Report .”
9.9. Role of the participants
9.9.1. Role of the Risk Analysis and Management Project Team
• The stage’s implementation
9.9.2. Role of the Liaison Groups
• To provide information on the existing mechanisms and their constraints.
9.9.3. Role of the Steering Committee

• To approve the selected safeguard mechanisms, the resources needed and the way to implement
them.
9.10. Application of Stage 4 to the case study
9.10.1. Activity 4.1: Identify safeguard mechanisms
In the example, the three first Tasks of this Activity are implemented at the same time as the following
Activity, as the central mechanism has been identified “a priori” (“Contingency Plan” together with
“Back-up Centers”), and its development imposes additional mechanisms that will appear in the
study.
9.10.2. Activity 4.2: Select safeguard mechanisms
The study is focused on the analysis of the back-up needs and on the characteristics that the
possible back-up center, as safeguard mechanism, has to fulfill in order to maintain the computer
service for the applications considered as critical, in case of a disaster in the LPA. The detected
critical applications, depending on the risk and applying the different disaster scenarios, are analyzed
in terms of their needs, if they have to be exploited in the back-up center. Those needs are structured
as follow:
• The functions’ criticality

• The needed hardware (terminals, printers, tapes/cartridges)
• Software
• Communications
• Documents
• Dependency on other applications
The individual vision of each of the critical applications’ needs allows us to integrate the
comprehensive back-up needs regarding software, hardware and communications.
The availability of all these can only be achieved through updated data, thus, as safeguard
mechanism, the procedure to get a back-up copy should be explained. This procedure is not
described here, but any study should include the guidelines to implement a test of the back-up center
and its use in case of a contingency.
Therefore, the critical systems or applications will be selected among those affected by a high or very
high risk level in any of the scenarios. Based on the vulnerability analysis reflected in the previous
reports, the critical systems and applications reflected in the following chart are considered:
-----------------------------------------------------------------------------------------------------
CRITICAL SYSTEMS AND APPLICATIONS
· REVENUES
- Real estate tax
- Capital gains tax
- Motor vehicle tax
- Business tax
- Tax on economic activity
- Fiscalization of revenues
• EXPENSES
• TREASURY
• ACCOUNTING
- Register of payment orders
• POPULATION CENSUS
- Population
- Territory (coded geographically)
• INPUT AND OUTPUT REGISTER
• FOLLOW-UP OF FILES
• PERSONNEL MANAGEMENT
- Previous month transfers.
• OTHERS
- Executive collection.
- Budget.
- Applications maintenance.
--------------------------------------------------------------------------------------------------------------
BACKUP NEEDS
The critical applications are analyzed according to three main criteria:
• Main critical functions.

• Back-up needs.
- Hardware (terminals, printers, tapes/cartridges).

- Software.
- Communications.
- Documents.
• Dependence on other applications.
For example, in the expense system all processes are in real time except for the gathering of lists at
the end of the day. The main mechanized functions are the following:
• Expense proposal management. The different services propose the opening of expense files
that would be supervised (checks on the items, credits, credit reserves, ...) and authorized. Once
the expenses are allotted to a supplier, a proposal is made and the supplier’s data are updated.
• Invoice management. The provided services or the delivered goods are charged to the
suppliers, thus that obligation is acknowledged. The originator services produce the invoices
corresponding to the expended amounts (invoices’ checks).
• Payment orders. Once the obligation is acknowledged, the payment orders are issued and sent
to the Treasury for payment.
• Register and refund of deposits
• Endorsements
The back-up needs are:

• Hardware. Currently, in the mechanized processes twelve terminals are used (not including the
expense managing centers), that have a high level of activity as each terminal has an average of
10,500 transactions/month (one of the terminals has a low activity). Regarding printers, the
deferred processes generate a lot of lists at the end of the day. Tapes/cartridges are not used.
• Software. The expense application is in the host, in the central database manager.
• Communications. At peak hours the connection of 8 terminals at the same time is planned.
• Documents. The application’s documents, conveniently updated, should be there, specially the
operation handbook.
Dependence on other applications
The credit modifications managed through the budget application are the only necessary application in order to exploit the
expense application.
Expense decentralization. Currently, the expense proposals are introduced in the expense system
through different services. In case of disaster, the terminals that use the 35 expense centers with low
activity should be analyzed (they are used to include the expense proposals and the invoices). Ten of
these terminals should be simultaneously connected.
SUMMARY OF THE CRITICAL APPLICATIONS
In the list each critical application would be detailed:
- Terminals currently in use.

- Current activity regarding transactions/month by terminal.
- Availability of the needed terminals in case of contingency.
- Terminals’ estimated simultaneous connection.
- Volume of the currently deferred data printing, both in habitual and exceptional situations.
- Use of tapes/cartridges.
The terminals’ simultaneous connection is the needed one in the applications’ “peak” periods.
Bearing in mind that those periods do not coincide in time (for example, the real state taxes are
collected the second term and the others the fourth term of the year), the terminals simultaneous
activity is much lower than the one considered.
CURRENT PROCESS FOR BACK-UPS
The production of back-ups of the data and programs used in the LPA is carried out automatically
(JCL included in the scheduler) and in cartridges with the exception of the residents (primary
software) that are saved in magnetic tapes. In terms of the back-ups periodicity, there are four
groups of information:
• Production database (PDB), that includes the real data and the programs executable in the
Adabas environment’s production and document database.
• Development database (DDB), which includes test data and source programs used in the
Adabas environment’s test and development.
• Residents (RES), which include the corresponding programs for the primary software.
• Rest (REST), that includes the Cobol environment’s data and programs, plus working files.
The production database is integrally copied every day and this process takes around one hour.
The back-up occupies 12 cartridges as they use 3480 devices with 18 tracks. If the 3490E with 36
tracks and double length were used, the back-up would occupy 3 cartridges. The back-up is kept in
the strong box in the operation facilities (basement), in a room next to the computer site, just
separated by a bearing wall. The week’s last day back-up will be taken to the System Area (in
another building).
The development database is integrally copied once a week, with daily incremental back-ups at
program level. It is stored in the same place that the production database.
The residents are copied once a week on magnetic tapes and they are stored in the same place that
the production database.
The rest is copied once a month, with daily incremental copies, and is stored in the operation
facilities.
Every month all volumes but the “spool” and the already copied databases are copied. This back-up
goes to the System Area (in another building) and it is kept in a strong box (non fire-resistant),
whose key will be in the System Area and in the Operation Area.
Therefore, the following copies will be kept in both Areas:
Operation Area (basement of the computer site):
- PDB: daily copy.

- DDB: weekly copy plus daily incremental copy.
- RES: weekly copy.
- REST: monthly copy plus daily incremental copy.
· Systems Area (another building):
- PDB, DDB and RES: weekly copy.

- REST: monthly copy.
PROPOSED PROCEDURE FOR BACK-UPS
With the aforementioned procedure a possible disaster scenario SC1, of a natural or industrial
accident, or a possible disaster scenario SC2, of a physical attack, could involve the non-availability
of the magnetic means stored in the Operation Area. In this case, we should seek the copies stored
in the Systems Area to reboot from an alternate center. This will involve a loss of information in every
group:
• PDB: a week’s work will be lost, since the last weekly back-up, that is, five working days at a
maximum.
• DDB: as in the PDB.
• RES: as in the PDB.
• REST: as it is a monthly copy, the work lost would be up to a month.
The following proposed process for the back-ups is based on daily guaranteeing the information
in the databases (in case of disaster the loss of information would correspond to one day), and on
weekly guaranteeing the remaining information. Also three generations of back-ups are proposed,
two periodically and another when requested.
The first generation for each group will be formed by:
• PDB: daily integral back-up.

• DDB: weekly back-up with daily incremental back-ups of programs.
• RES: weekly back-up.
• REST: monthly back-up with weekly incremental back-ups.
This first generation will be stored in the Systems Area (in another building), and that means the daily
transfer of the PDB back-ups and the incremental DDB back-ups; the weekly transfer of the
DDB and RES back-ups, and the incremental back-ups of the rest; and the monthly transfer of the
rest.
The second generation, to be stored in the Operation Area, will be formed by:
• PDB: no back-up will be made, but the previous day back-up of the Systems Area will be taken
to the Operation Area.
• DDB: no back-up will be made. The first generation back-up will be copied tape to tape.
• RES: integral back-up once a month with daily incremental back-ups.
• REST: first generation tape to tape back-up (monthly), with daily incremental back-ups.
The third generation will be made at request, with PDB back-up coinciding with key dates as:
when the voluntary tax collection period starts as well as that of the executive tax collection, that is, in
the set periods. That back-up could be stored in the future communications site.
The transfer of back-ups from a building to another must be carried out with the maximum security
measures and in special containers. There must be someone in charge of preparing the back-ups to
be transferred in the Operation Area as well as someone to receive them. They must have substitutes
in case of the responsible person’s absence. Although this system involves a very high level of
information to be copied, the future use of 3490 cartridges and the robotization of back-ups will
make easier the back-up reproduction and will lighten the time spent in the process.
9.10.3 Activity 4.3: Specify mechanisms to be implemented

Task 4.3.1 - Specification of the mechanisms to be implemented - is focused on the aspects that are
linked to the back-up center and the additional safeguard mechanisms that guarantee success.
OVERALL NEEDS IN THE BACK-UP CENTER
The back-up needs detected in the critical application analysis allow us to set the overall back-up
needs in case of contingency, as well as to assess the capacity to be rented.
The software needed to back up the critical applications is:
• The operating system.

• The database manager.
• The tools and utilities currently in use.
• The critical applications.
The need of space and working files also should be considered when configuring the need of memory. In case of contingency, an
updated and available back-up is necessary. That back-up shall contain the integral information; the reduction of the memory
space by avoiding the non critical applications would be difficult and irrelevant.
The hardware back-up needs for the critical applications are:
• Availability of a PC compatible with the LPA system.

• Processing capacity: 16 MIPS.
• Disk storing capacity: 25 GB.
• Availability of compatible tape units.
• Availability of compatible cartridge units.
• Simultaneous connection up to 115 terminals.
• The needed communications elements to connect the current terminal network and the future
LPA to the alternate center. This issue is tackled later on.
PRINTING NEEDS. The critical applications produce a high volume of lists in deferred time
(currently, 15,000 pages/day non decentralized). In case of contingency, the optimum solution would
be to print these lists through the LPA printers, which means the connection of at least a printer to
the LPA network, instead of the computer channel as currently. Moreover, the selected printer
should be placed in a “safe” place. If this solution could not be implemented, there are two
alternatives:
• The back-up service supplier should have a compatible printer with the ones in the LPA. In this
case, the back-up center would get a deferred print that should be taken to the applications’
users every day.
• Otherwise, the information in the lists would be recorded in tapes after having reached an
agreement with a supplier to print those lists. The supplier should be as close as possible to the
LPA; an advantage would be the possibility of transmitting the information in the lists through the
communications lines to the supplier center.
COMMUNICATIONS
In case of contingency, the communications between the LPA terminal network and the alternate
computer must be guaranteed. In the short term, the planned situation for the communications
network in the LPA is based on the connection of the different elements through Ethernet. The
communications Front-end is connected to that network, and is in a safe “place” (as it was explained
in the previous reports), so the connection between the LPA network and the alternate center could
be made through it. A hypothetical emergency service would be:
• 115 terminals working simultaneously.
• 700 bps for each terminal - as average and in periods of maximum service the total speed
capacity of the needed communications would be 80,500 bps in order for the back-up center to
back up the terminals in back-up states - speed that could be fixed in 64 kbps if there are not
“peak” periods in the critical applications.
There are several alternatives in the communications networks to be implemented to connect the Front-end to the back-up center:
a) Point-to-point lines, whose cost - monthly fixed - is independent from distance and use. In this
case there are two possibilities: permanent rent or request in case of emergency.
b) Switched telephone network (STN), simulating point-to-point lines.
c)Access to a public packet switching network with protocol X.25.

d) Access to an Integrated Services Digital Network (ISDN).
e) There are other alternatives that require to mobilize more resources and they are more complex
to implement. For example, part of the communications capacity could be rented to a private
network belonging to an organization that has nodes in the LPA city and in the place where the
back-up center is (these networks could be ground lines or use VSAT satellite-type or teleports).
Mixed alternatives: evolution in the communications network. An alternative approach is to

follow the stages set by the technology or the network in which the back-up telecommunications
network is based, that is, going from the STN to the ISDN when the access offer is guaranteed.
This approach has some advantages:
• It allows to strengthen the implementation of the organizational procedures in back-up situations

as well as the implementation of the local software and hardware needed in the DPC (data
processing center), and the needed changes without being too concerned by the
telecommunications network as the latter is easy to implement and use.
• It allows to reduce the costs at the beginning as the STN is a low cost solution. If in the first
back-up test the network does not run properly, another network can be used with a relatively
low outlay.
• It allows to save time: the existing lines, e.g. ISDN, can consolidate their service offer, or even
new possibilities can appear.
SUMMARY OF COMMUNICATIONS COST
Depending on the traffic estimations linked to the LPA exploited applications and considering 64
kbps as the needed speed, the usage costs in the most feasible alternatives are the following:
Alternatives Monthly availability costs Monthly usage costs

STN 8,400 3,720,000
Point-to-point 339,500 -
X.25 104,600 4,156,250
ISDN 8,000 3,720,000
BACK-UP SERVICES
In case a disaster happens, the main component in the computer system’s recovery is the
information, that is, the important thing is to recover the information from the back-ups.
The computer systems are based on files:
• Data/information on business and environment.

• Programs/procedures/applications.
• Operating systems/monitors/tools.
The remaining components can be recovered with more or less difficulty:
• Hardware is easily found; it is just a question of money.

• Wire (for communications) is also easily found, it is a question of money and planning.
However, if the files are not updated and protected from any contingency, they invalidate any back-
up situation.
In case of a disaster involving the unexpected and lasting interruption of the computing service, the
tendency is to back up that service through an external supplier, that is, to guarantee the service
continuity through a “hot back-up” or active back-up, which means:
• The back-up center fully assumes the data processing during the contingency.
• Relatively immediate access to the back-up center in case of contingency.
• The system’s rebooting and customizing in the back-up center in a short time.
• Effective availability of data and applications in the back-up center in case of disaster.
• Recovery and operational starting of the client’s data and process.
• Operational return to the original data center once the contingency is solved.
IN CASE OF DISASTER
In the normal running of the LPA, in a specific moment some back-ups of the information are made to save the data and
programs’ modifications. In case of a disaster, a contingency that involves an unexpected and lasting interruption in the service,
the data and the changes introduced in the system since the last back-up copy are lost, and have to be recovered from the original
sources, if possible.
When the computer service is interrupted, due to a disaster, the first step is to diagnose the cause
that provokes it and to assess the consequences, in order to decide whether or not to transfer it to
the alternate center.
Once the transfer decision is taken, the planning and the recovery in the back-up center start to
operate until the original center is working again. The recovery from the back-up center means:
• To empty the data of the back-ups.
• To re-enter the data obtained after the back-ups were made.
The users should have planned the actions to be implemented to recover the lost data from the original source from the moment
the last back-up was made. In this way, the computer systems would recover their operating state, while the existing problems in
the main DPC are solved in order for the main DPC to provide the service again.
STAGES WHEN RECOVERING FROM A BACK-UP CENTER
When we have available a back-up center, the following four stages can be seen:
A) Pre-contingency (normal situation). During the normal operation of any entity and regarding
the back-up center the following Activities can be implemented:
• Regular storage of the entity’s data and programs, residents in cartridges in the back-up center
itself or in another safe place at the client’s proposal.
• Annual checks, it is advisable to carry out one compulsory check and another optional. Each
check will involve the massive back-up and its transfer to the back-up center, the test booting,
verification, approval and the client’s re-sizing, if necessary.
B) Contingency. Once the contingency arises, the Activities to be implemented are the following:
• Announcement of the emergency situation to the back-up service manager.
• Request for the immediate availability of the back-up center.
• Back-up center’s configuration as the client’s center. The client should provide the software and
the needed licenses for its recovery.
• Down load of the client’s data from the cartridges to the disk.
• Activation of the communications with the client’s center.
• The service is restored from the alternate site.
The length of the alternate service’s operation will depend on the client and on the contingency. It is advisable to consider the
supplier strategy regarding the simultaneousness of contingencies in its clients’ entities, as the alternate service can be unavailable
C) Process. In this stage the following must be guaranteed:
• The back-up center’s resources when providing its clients’ service.
• The contingency’s monitoring and follow-up.
• The plans to recover the previous normal state.
D) Recovery of the previous normal state. The main Activities in this stage are:
• Advanced planning for a long weekend.
• Interruption of the alternate site service and massive back-up in cartridges.
• Transfer to the client’s center.
• Client center’s rebooting and recovery decision.

• Drafting the report on the retrospective analysis of the causes and steps taken.
CONTINGENCY PROCEDURE
The back-up center’s service in case of contingencies entails the establishment of perfectly defined
working structures in order to guarantee its success and efficiency, as well as a clear and full
definition of the measures to be implemented. The structures are indeed differentiated by the number
of people and the number and complexity of the measures to be implemented. The participants in the
contingency team and those in the contingency board, if possible, should be the same people that
have taken part in the implementation of tests. The proposed working structures that should
intervene in the LPA in contingency cases are the following:
• A Contingency Board, body in charge of transferring the data and programs to the back-up
center and their later transfer to the original center, and of maintaining relations with the people in
charge of the back-up center. The board shall have a coordinator and a deputy, in case of the
coordinator is absent. This office should be occupied by a person with wide executive powers in
the town council.
• A Contingency Managing Team, formed by the computer Director of the LPA and senior
members of the different areas (Development, Operation and Systems) and by those responsible
of critical applications.
• A Contingency Technical Team, that includes the LPA technicians in the different areas
(Development, Operation and Systems).
• A Contingency User Team, formed by the users of each of the critical applications.
The procedure to be implemented in case of contingencies follows the following Tasks:
1) Detection of contingencies:
• Once a disaster is detected by the CIM personnel, the contingency managing team is informed,
and the cause that has provoked the disaster is diagnosed, the team will assess its effects and will
inform the coordinator.
• The contingency board, after having been informed by the coordinator, should decide whether or
not to transfer it to the back-up center.
2) Declaration of the contingency state:
• The computer Director of the LPA, having taken the decision of transferring the original center to
the back-up center, will inform the ones in charge of the back-up center, will activate the
contingency procedures, and will inform the software suppliers.
3) Preparation and recovery:
• The computer Director of the LPA will inform the contingency technical team of the contingency
state.
• The contingency technical team will transfer the information copies to the back-up center, will
download the resident information in the cartridges in the back-up computer, and will activate the
LPA terminal network communications with the back-up center’s help. It will also deactivate the
operation possibilities of the non critical applications, reporting this to the affected users by
means of the screen.
• The contingency user team, once the critical applications are operating again through the back-up
center, will re-entry the data introduced after the carrying out of the back-up copies (normally,
the copies will be those of the day in which the disaster happened). The technical team will
monitor and follow up the data introduction, assisting the user team.
4) Process in the alternate site:
• The contingency user team will exploit the critical applications. The technical team will monitor
and follow up that operation, assisting the user team.
• The contingency managing team will permanently inform the contingency board, in order to take
the appropriate measures. When the recovery of the LPA computer center is almost achieved,
this team will be responsible of planning the measures for the applications and data of the original
center to start.
5) Return to the LPA center:

• The LPA computer Director, once the contingency board has taken the decision of returning to
the original center, will inform the other teams.
• The contingency technical team will carry out the information back-ups in the back-up center,
will take them to the original center and will recover them there. It will also erase the information
from the back-up center’s computer hard disk.
• The technical team will reboot the applications in the LPA computer site, implementing the
measures needed to connect again the terminal network to the host.
• The LPA computer Director will inform the users of all the applications of the computer service
availability.
6) Contingency results:
• The test managing team, advised by the technical team and by the user team, will draw up a
report on the retrospective analysis of the causes and steps taken, that will allow to improve and
adapt the procedures used.
9.10.4. Activity 4.4: Plan implementation
The example does not include these Tasks.
9.10.5. Activity 4.5: Integrate results
The example does not include these Tasks.

APPENDICES
APPENDIX 1: SUMMARY-CHARTS OF ELEMENTS
ELEMENT: ASSETS
Definition The assets are the resources of the information system, or those related with it,
necessary for a right operation of the organization and the achievement of the
goals proposed by the Executive Board.
Characteristics Each asset (or an homogeneous set of assets or the domain under study) is
characterized by its security state; this state is defined by estimating the levels of 4
substates of authentication, confidentiality, integrity, availability (A-C-I-Av).
Types MAGERIT considers 5 types or categories of assets:
1. Environment
2. Information system
3. Information
4. Organization’s functionalities
5. Other assets
Attributes Each asset or group of assets has two main attributes: two indicators of two kinds
of assessments: the assessment intrinsic to the asset and the assessment of the
security state of the asset.
Metrics The metrics of intrinsic assessment of the assets are based on these situations:
certain assets can be inventoried, others can or cannot be inventoried, and part of
the system assets are not inventoriable.
The security state assessment metrics allow estimating the levels of the four
substates A-C-I-Av (authentication, confidentiality, integrity, availability).
For specific purposes, MAGERIT may require other classification of assets
Additional different from the already mentioned, for example: hierarchical groups of assets,
information groups of assets depending on the threat, non-typified assets.
ELEMENT: THREATS
Definition Threats are events that can trigger off an incident within the organization, causing
material or non-material damages in the assets.
Characteristics The definition shown above envisages the dynamic essence of the threat: that is to
say, it is a potential event (an action, interruption or lack of action out of the
security actor’s control in contrast to human-decision actions). The consequence
of the threat, should it materialize, is an incident that modifies the security state of
the threatened assets, it turns it from a state previous to the event into other state
posterior after the event (potentially or actually, being it a threat or an attack
respectively).
Types Threats can be classified according to their causes. MAGERIT considers four
types of causes: non-human (accidents); human non-deliberate (errors); human
and deliberate which require physical presence; and human deliberate remote
controlled.
Attributes The threat has not remarkable attributes to be useful to the risk analysis and
management.
Metrics The intrinsic occurrence of the threat is only interesting if it is not associated to the
affected asset as a materialized attack. However, it can help us to value the
vulnerability related with the association by default (if an specific assessment of
such vulnerability is not made); in this case, a scale that depends on the mean time
between occurrences.
Additional To achieve specific goals, MAGERIT may require other classifications different
information from the already mentioned ones or more detailed enumerations of the already
mentioned types, levels or layers, for instance: to group the potential events or
threats in scenarios, threat/attacks hierarchical groups, groups of threat/attacks
depending on the security substates, groups of cohered types of threats/attacks
and safeguards.
ELEMENT: VULNERABILITIES
Definition The vulnerability of an asset is the potentiality of occurrence of the
materialization of a threat against this asset.
Characteristics The vulnerability is a characteristic of the relation between an asset and a
threat.
The vulnerability has a mediating function between the threat (as an

action) and the asset (as the subject of the change of security state) Due
to this static aspect, the vulnerability is part of the asset security state.
The vulnerability, according to its dynamic aspect, is an intermediate

mechanism between the threat and the materialized attack on the asset.
Types MAGERIT considers two main types:
The intrinsic vulnerability of the asset with regard to the kind of threat
only depends on these two entities.
The effective vulnerability of the asset takes into account the safeguards
applied to the asset and is considered as a factor, which estimates the
global efficiency of such safeguards.
Attributes For analysis purposes (especially for deliberate threats) the intrinsic
vulnerability can be divided into two groups of attributes:
- Autonomous potentiality of threat occurrence with regard to the

threatened asset (for example, the frequency of flooding in a specific
place).
- Potentiality derived from the relation between asset and threat (mainly
deliberate): subjective factors and opportunity to access the domain.
Metrics The vulnerability metrics considers the “distance” between the potential
threat and its materialization as real attack on the asset. When it is
possible, MAGERIT measures the vulnerability considering the historical
frequency or the possibility of threat materialization.
Additional Information The vulnerability is classified according to the asset and the threat to
which it is closely linked.
ELEMENT: IMPACTS
Definition The impact on an asset is the consequence of the materialization of a
threat on it.
Characteristics From a dynamic point of view, the impact is the difference of the
estimations of the security state of the asset before and after the attack
or threat materialization. In other words, the threat (materialized into
attack) produces in the asset security state (previous to the threat) a
change to a new state (after the threat); the impact measures the
difference between both states.
Types MAGERIT uses types of impacts related to the nature of the
consequences of the combination asset-threat.
MAGERIT considers three main groups of impacts according to the

following hypothesis: their consequences directly reduce the security
substates of the asset (A-C-I-Av); or their consequences indirectly
reduce the security substates of the asset (qualitatively or quantitatively).
Attributes Considering the direct consequences on the asset security state, the
impact has two attributes or factors: the intrinsic severity of the result
and the aggravating (or mitigating) circumstances.
Considering the indirect consequences of the impact, its main attributes

are the quantitative and qualitative aspects of the consequence.
Metrics MAGERIT has two basic ways of assessing impacts, based on
qualitative scales: assessment (in time) of the lack of availability of an
important asset and assessment in a scale with merely guiding levels.
Additional Information The quantification of Impacts is one of the most difficult processes in the
risk analysis and essential for the risk calculation. Thus, although the goal
of MAGERIT is to measure the impacts in pesetas or other similar
objective indexes, it is only possible when using indirect and often
subjective methods. So, in a first attempt, the impact will be measured
as the replacement cost of the damaged asset. When this measure is not
feasible or makes no sense, the replacement cost of the function carried
out by the damaged asset will be assessed taking into account the
deterioration of some of its security substates.
ELEMENT: RISK
Definition Risk is the likelihood of an impact taking place on an asset, on a domain
or on the organization.
Characteristics The risk is the result of the risk analysis, a complex process which starts
identifying the autonomous elements (domain assets and threats) and then
estimates the elements stemming from the domain assets and threats
(vulnerabilities and impacts). MAGERIT makes this complex analysis in
order to get a specific result.: a risk calculated value which allows making
decisions to implement the following stage of the process. This decision
can be made by comparing the calculated risk with a risk established
level (risk threshold).
Types MAGERIT considers several types of risk: The intrinsic calculated risk,
the residual calculated risk and the risk threshold.
Attributes MAGERIT considers two attributes, one for each risk and another for
the relation among risks: the constraint to each type of feasible impact
given the vulnerability of an asset (or group of assets) and a threat (o
group of threats) and the risk spreading for interdependent assets.
Metrics In the most simple case, the vulnerability has been estimated as a
frequency (for example of a component failure) and the impact as a
replacement monetary value (of that component). Thus, the calculated
risk can be estimated through the impact accumulated during a period of
time, for example, one year. The risk will be the replacement cost of the
component during one year and it will be compared with an specific
threshold or with the annual cost of the safeguards to reduce it. In the
most complex cases, when vulnerability cannot be assessed as a
frequency or when the impact cannot be measured in money, MAGERIT
estimates the risk metrics with the help of a qualitative chart or its
equivalent matrix.
Additional Information The following classification: calculated, intrinsic or residual risks; risk
thresholds and acceptable risks does not affect the metrics.
ELEMENT: SAFEGUARD FUNCTIONS, SERVICES AND MECHANISMS

Definition MAGERIT defines the safeguard function or service as the action which
reduces risk and the safeguard mechanism as the physic or logic
procedure or device which reduces risk.
Characteristics To reduce risks it is necessary to improve the existing safeguards or to
install new ones. MAGERIT distinguishes between the most abstract
entity called safeguard function or service and the concrete entity called
safeguard mechanisms. The safeguard function is an action-type action
(or non-action, that is to say, omission), since it is the result of a decision
made to reduce a risk (it is not an event-type action). Such action
materializes into the corresponding safeguard mechanism.
Types The safeguard functions, services and mechanisms are classified
according to their modus operandi: preventive functions or services and
corrective or restoring functions or services.
Attributes The generic effectiveness is an attribute of a safeguard function or service
which turns the intrinsic vulnerability and the full impact on the asset into
an effective impact and vulnerability.
The concrete effectiveness is an attribute of a safeguard mechanism. This

effectiveness is usually non-specific (it reduces the risk of different assets)
and it is usually associated to the efficacy of other safeguard mechanisms.
It also turns the intrinsic vulnerability and the full impact on the asset into
an effective impact and vulnerability.
Metrics A safeguard function or service does not have its own metrics but one
deriving from its risk reduction power. The value of the generic
effectiveness of a safeguard function or service is determined by the
experience of security analysts and depends on the kind of safeguard
function or service (that is to say, its modus operandi) and on the kind of
threat. The safeguard mechanisms’ metrics is directly linked to its
organizational cost in pesetas.
Additional Information MAGERIT is upgrading the protection static model which was based on
a “fortress” whose “breaches” or vulnerabilities must be protected with
specific safeguards. The safeguards for the current information systems
similar to - “open cities” with “no borders” - are based on a dynamic
and flexible security model.
APPENDIX 2: GLOSSARY
Activity Concept used in MAGERIT processes submodel, that groups tasks

using functional criteria.
Assets Resources of the information system or related to it, which are

necessary for the organization to operate properly and to reach the
objectives proposed by the Management.
Attack Threat materialized on a domain asset.
Threats Events that may provoke an incident in the organization, resulting in

material damage or non-material losses in their assets.
Analysis of Risks It identifies the threats that may affect the components belonging or
related to the information system (known as “assets”). It determines
the system’s vulnerability, and estimates the impact that an
inadequate security may have for the organization, that in turn
becomes aware of the risk it may be exposed to.
Risk Analysis
(MAGERIT Stage) It is a MAGERIT stage that allows to identify and evaluate the
elements of the risk; to assess the risk in the domain areas; and to
estimate the desirable risk thresholds.
Assurance Action to gain security.
Authentication To provide with and recognize the authenticity of the domain assets
(information type); and/or the identity of the actors; and/or the
authorization on the part of those who give the authorization; and
finally, the verification of them all.
Certification It confirms the result of an evaluation; it also confirms that the

evaluation criteria used were correctly applied (Handbook on
Security for Public Administration Executives).
COMMON CRITERIA Common Criteria on Security Evaluation of Products and Information
Systems. Criteria used by the European Union, the United States,
and Canada.
Awareness,
Information &
Training Type of “structural” safeguard (related to the organization’s
comprehensive structure). Its relevance comes from the key role that
the human factor plays in security (regarding the person himself, and
the person’s stable relationship with the organization).
Confidentiality It prevents from non-authorized dissemination of domain assets.
Correction Type of safeguard that prevents the threat from spilling over, and
limits its effects.
Corrective Detection,
or “Monitoring” Type of safeguard that starts to operate before any other safeguard
does (many attacks are late or never detected).
Preventive Detection Type of preventive safeguard that can even become deterrent, if the
potential attacker is aware of its installation, and hence is aware of
the fact that he could be discovered.
Availability It prevents non authorized denial to access domain assets.
Deterrence Type of safeguard that may persuade the potential intentional human
attacker to reconsider the attack from the very start, based on the
consequences that may affect his own interests.
Domain Set of assets that form the “object” of the study or project. A unit or
number of units under the risk analysis and management.
Stage Concept used in the MAGERIT Processes Submodel, grouping a set
of activities, that will depend on decision milestones and products to
deliver and validate.
Safeguard Function Action that mitigates the risk.
Corrective Safeguard
Function It acts upon the impact (after the attack) and reduces its
seriousness.
Preventive Safeguard
Function It acts upon the vulnerability (before the attack) and reduces the
potentiality for the threat to take place (not in a general sense; it
does not depend on the threatened asset).
Management
of the Risks It selects and implements the security measures or “safeguards” to
get to know, prevent, impair, reduce or control the identified risks,
and hence brings their potentiality to a minimal state. The
management of risks is based on the results obtained from the
analysis of risks.
Risk Management
(MAGERIT Stage) This is a MAGERIT Stage that allows us to determine the possible
safeguard functions or services which will mitigate the detected
risk; to select the acceptable safeguards, based on the already
existing safeguards and the constraints; to simulate several
combinations; and to finally specify those chosen.
Impact Consequence resulting from a threat acting on an asset.
Integrity It prevents non-authorized modification or destruction of domain

assets.
ITSEC Information Technologies Security Evaluation Criteria. Criteria
approved by the Senior Officers’ Group on Information Security
(SOGIS) from the EU Commission.
ITSEM Handbook on application of ITSEC criteria.
LORTAD Organic Law on Regulation of Personal Data Automated Treatment.
MAGERIT Risk Analysis and Management Methodology for information

systems and the Public Administration.
Safeguard
Mechanism Physical or logical device that mitigates the risk.
Risk Analysis &

Management Planning
(MAGERIT Stage) It is a MAGERIT Stage that establishes the necessary considerations
to boot the risk analysis and management project; it helps to find out
whether it is possible to carry out the project; to define the objectives
to meet and the domain to cover; to plan the material and human
means; and to initialize the project launching.
Corporate Security
Policy Set of laws, rules and practices, regulating how to manage, protect,
and disseminate those goods containing sensitive information, within
an organization (ITSEC).
Set of rules to establish security services (ISO 7598-2).
Prevention Type of protection safeguard which does not prevent initializing the
implementation of a threat, but its complete implementation - hence
its full impact.
Recovery Type of restoring safeguard that fixes any damages or rebuilds the
damaged elements to restore the asset to its normal state as before
the attack.
Risk Possibility for a specific impact to take place on an asset, a domain
or the whole organization.
Intrinsic Risk Defined or calculated risk before applying any safeguards.
Residual Risk Risk after the application of safeguards on a simulation scenario or

the real world.
Safeguard Selection
(MAGERIT Stage) It is a MAGERIT Stage that selects the safeguard mechanisms to
implement; helps to create an implementation planning for safeguard
mechanisms; establishes the follow-up mechanisms for
implementation; collects working documents from the risk analysis
and management process; obtains the final project documents; and
presents the results of the different levels.
Safeguard Service It is an action that mitigates the risk (equivalent to the safeguard
function).
Corrective Safeguard
Service It acts on the impact (after the attack) and reduces its seriousness.
Preventive Safeguard
Mechanism It acts on the vulnerability (before the attack) and mitigates the
potentiality of implementing the threat (not in a general sense; it
does not depend on the threatened asset).
Information System Group of physical, logical elements, communications elements, data

and personnel that allow the storage, transmission and information
process. (Handbook on Security for Executives of the Public
Administration and Information Systems).
MAGERIT Elements
Submodel Description of basic MAGERIT components, and their procurement
and updating processes.
MAGERIT Events
Submodel Description of the relationships between the elements, and between
the elements and the time.
MAGERIT Processes
Submodel Functional description (“explicative chart”) of the security project.
Task Concept used in the MAGERIT Processes Submodel. It covers the

activities to do, the products and documents to obtain, the necessary
validations/approvals, and the techniques to be used for
implementation.
TOE Target of Evaluation. Security objective under ITSEC criteria.
TOS Target of Security. Application domain under ITSEC criteria.
Risk Threshold Value established as the basis to decide by comparison if the

calculated risk is acceptable.
Administrative Units Different fields in an organization within the Administration or an

Entity (General Departments, Autonomous Bodies, Deputy
Departments, etc.).
To value the assets To find the asset’s “Change value” as a repository value, in a direct
(inventory value) or indirect (regeneration cost after the impact) way.
If the valuation were impossible (“repository” value of a person after
an accident due to the lack of security of some asset), the asset must
be treated as an element of the domain context under the security
project. What has just been mentioned corresponds to an intrinsic
valuation, but we could as well carry out a valuation associated
to security substates, providing a qualitative value of the asset’s
security substates (authentication, confidentiality, integrity, availability,
A-C-I-Av), having as a reference the degree of compliance of the
function, and the asset’s relevance for the system’s mission.
Vulnerability Potentiality of threat occurrence.

Effective
Vulnerability It is the asset’s vulnerability with respect to the type of threat, having
in mind the safeguards applied to that asset each time.
Intrinsic
Vulnerability It is the asset’s vulnerability with respect to the type of threat, without
considering the implemented or existing safeguards.
Residual
Vulnerability It is the vulnerability of the asset that results from the application of
complementary safeguards, under the recommendation of the risk
analysis and management.
APPENDIX 3: BIBLIOGRAPHY
BOOK/DOCUMENT TITLE AUTHOR & DATE

BSI 1993
A CODE OF PRACTICE FOR INFORMATION SEC. MANAG
A GUIDE TO SECURITY MANAGEMENT FOR IT SYSTEMS GOBIERNO CANADA 1994
A KNOWLEDGE BASED METHOD OF MANAGING RISKS BONYUN - JONES IFIP 1991
A STRATEGIC APPROACH TO INFORMATION T.SECURITY GOVERNMENT OF CANADA-1995
APPROACH TO INFORMATION SYSTEMS RISKS ANALISIS AND MAN. GUARRO (COMPUTER&SECURITY) 1987
COMMON CRITERIA ON IT SECURITY EVALUATION V 1.0 CEC-EUA-CANADA 1996
COMPUTER AND NETWORK SECURITY IEEE 1987
COMPUTER CONTROL AND SECURITY PERRY 1981
COMPUTER CRIME AND BUSSINESS INFORMATION SCHWEITZER 1986
COMPUTER SECURITY AND INFORMATION INTEGRITY IFIP 1991
COMPUTER SYSTEM EVALUATION CRITERIA DoD 1985
CRAMM EVALUACIÓN XP CONSEIL 1993
CRAMM HISTORIA Y CRAMM 3 CCTA-WATTS-1994
CRAMM- AN OVE RVIEW CCTA 1991
CRAMM- VISIÓN DETALLADA CCTA- MOSES
DATA SECURITY AND CONTROL BUCK 1991
DATABASE SECURITY CASTANO 1994
FUNDAMENTALS OF COMPUTER SECURITY TECHNOLOGY AMOROSO - 1994-
GLOSARY OF IT SEC. TERMINOLOGY ISO/IEC JTC1/SC 27 N566 ISO- 1992
GUIA DE LA SEGURIDAD DE LOS SI PARA DIRECTIVOS AAPP COAXI 1994
GUIDE FOR SELECTING AUTOMATED R.A. TOOLS NIST -1990
GUIDE TO OPEN SYSTEMS SECURITY ISO/IEC JTC1/SC 27 N519 ISO- 1992
GUIDELINES FOR MANAGEMENT OF IT SEC. ISO 1994
PART 1 CONCEPTS AND MODELSN777 ISO 1993
PART 2 MANAGING AND PLANINGS IT SEC. N720 ISO 1993
PART 3 TECHNIQUES FOR THE MANAGING N 689 ISO 1993
PART 3 TECHNIQUES FOR THE MANAGING N 359 ISO 1993
PART 3 TECHNIQUES FOR THE MANAGING N 780
GUIDELINES FOR DIRECTING INF. TECHNOLOGY SECURITY CCTA 1991
INFORMATION SYSTEMS SECURITY DESIGN METHODS BASKERVILLE - ACM- 1993
INFOSEC 1992 S2014 FINAL AND STRATEGIC REPORT CEC 15-2-1993
INTEGRATING SECURITY ACTIVITIES INTO DE SOFT.DEVEL. CICLE TOMPKINS COMPUTER&SECURITY 1986
CEC - 1991
¡Error!Marcador no definido.ITSEC
ITSEM V 0.2 CEC 1992
LA SEGURIDAD INFORMATICA SANCHEZ- IGNOTO 1991
LA SEGURIDAD INFORMATICA METODOLOGIA LAMERE 1985

LE RISQUE INFORMATIQUE JOUAS HARRARI LAMERE 1992
LES PRINCIPES DE LA SECURITE INFORMATIQUE IFACI 1990
LIBRO VERDE SOBRE LA SEGURIDAD DE LOS SI V.4.2.1 (ESPAÑOL) CEC - 1994
MANAGEMENT INFORMATION SECURITY SCHWEITZER 1990'
MANAGING CRAMM REVIEWS USING PRINCE CCTA 1993
MANUAL DE FORMACION Y SENSIBILIZACIÓN DE USUARIOS V0.1 MAP -1994
NETWORK SECURITY SECRETS STANG Y MOON 1993
PORTFOLIO TECHNIQUES TO SUPPORT RISK MANAG. AND SEC. BAUKNECHT - STRAUSS IFIP -1991
PROTECCIÓN DE INFORMACION SENSIBLE AFNOR 1992
PROTECCION DE LA INFORMACION RODRIGUEZ PRIETO -1985
RAMEX: A PROTOTIPE EXPERT SYSTEM FOR COMPUTER SECURITY RISK ANALYSIS AND COMPUTER&SECURITY 14 1995
MANAGEMENT
RISK MANAGEMENT&AND CORPORATE SECURITY COMPUTER&SECURITY 14 1995
SECURITE ET QUALITE DES SI GUINIER 1992
SECURITE ET QUALITE DES SISTEMES D´ INFORMATION HANOUZ
SEGURIDAD EN LOS SISTEMAS INFORMATICOS FISHER 1984
SEGURIDAD Y PROTECCION DE LA INFORMACIÓN MORANT, RIBAGORDA 1994
THE DATA CENTER DISASTER CONSULTANT KENNISTON 1986
TOPM: A FORMAL APPROACH TO THE OPTIMIZATION OF INF. TEC. RISK MANAGEMENT COMPUTER&SECURITY 13 1994
USER REQUIREMENTS FO IT SECURITY STANDARS BSI- SEMA GROUP 1992
USING CRAMM WITH SSADM CCTA 1994
APPENDIX 4: PROJECT TEAM
Project Coordinator:
Don Víctor M. Izquierdo Loyola
Deputy Director General for Computer Coordination - MAP
Project Manager
Don Francisco López Crespo
Chief of the Technical Assistance Department - MAP
Project Secretary
Don Miguel A. Amutio Gómez
Senior Civil Servant specialized in Information Technologies- MAP
Group of Experts
Doña María Dolores Hernández Maroto
Ministry for the Public Administrations (MAP)
Don Andrés Barreiro Pérez
Ministry of Economy and Treasury
Don Carlos López Martín
Ministry of Defence
Don Emilio Lorenzo Gil
Spain Postal Service
Doña Clara Cala Rivero
Ministry of Industry and Energy
Don Carlos García Codina
Ministry of Health and Consumption
Don Arturo Ribagorda Garnacho
University Carlos III, Madrid
Don Cecilio Salmerón Giménez
Bank of Spain
Doña Rosa María García Ontoso
Computer Expert, Autonomous Community of Madrid
The Ministry of Defence has translated to English language the Magerit-Procedures Handbook. The
Secretariat of SSITAD has prepared this edition, with the support of the Technical Secretariat-
International Unit of the Ministry of Public Administrations.

10 1 1 195 6831

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

10 1 1 195 6831

Uploaded by

Copyright:

Available Formats

MAGERIT

RISK ANALYSIS AND MANAGEMENT METHODOLOGY FOR

1.0 How to use the Procedures Handbook

2. THE MAGERIT MODEL

2.1 The role of MAGERIT in Information Systems (IS) security management

5.1 Introduction to the submodel

6 STAGE 1: PLANNING RISK ANALYSIS AND MANAGEMENT

6.0 Location of Stage 1 within the MAGERIT model

7 STAGE 2: RISK ANALYSIS

7.0 Location of Stage 2 within the MAGERIT model

8. STAGE 3: RISK MANAGEMENT

8.0 Location of Stage 3 within the MAGERIT model

9. STAGE 4: SAFEGUARDS SELECTION

9.0 Location of Stage 4 within the MAGERIT model

1.0 How to use the Procedures handbook

1.2 Objectives of MAGERIT

MAGERIT has two immediate objectives:

1.3 Elements of MAGERIT

• A set of Handbooks, mainly consisting of:

This MAGERIT structure lets you carry out:

1.4 Organization of the Procedures Handbook

1.5 Function and description of the Procedures Handbook within MAGERIT

MAGERIT’s Procedures Handbook represents the core of the method.

1.6 Objectives of the Procedures Handbook

The objectives of this Procedures Handbook are:

1. To provide an adequate comprehension of the MAGERIT model and of the procedures

1.7 About the Users of the Procedures Handbook

2.1 The role of MAGERIT in Information Systems (IS) security management.

Monitoring and REACTION to incidents

• Implementation of Safeguards and Other Security Measures in Information Systems: This

• Reaction to Incidents, Handline and Reporting of Incidents, and Recovery of

2.2 MAGERIT in medium and high complexity projects

- Setting comprehensive security objectives, strategy and policy.

2.3 STRUCTURE of the Risk Analysis and Management Phase

ELEMENTS Submodel EVENTS Submodel PROCESSES

2.4 A practical example

Each entity is described according to the following plan:

ELEMENTS submodel EVENTS submodel PROCESSES submodel

- Assets - Static - Planning

• Substate Av (availability): This substate is defined as the characteristic that prevents

MAGERIT considers five main types or categories of assets:

2. The information system itself.

3. The information processed by the applications of the information system.

1. Assets related to the environment level:

- Equipment and supplies (power, air conditioning, communications).

- Hardware (processing, storage, interfaces, servers, firmware, others).

3. Assets related to the information level:

- Data (computerized, concurrent or resulting from the information system).

4. Assets related to the organization’s functionalities level:

- The organization’s targets and objectives.

5. Other assets not related to the previous levels:

- Credibility (ethic, legal, etc.) or good individual or corporate image.

The quality of the MAGERIT implementation depends on the careful characterization of

• The asset’s intrinsic assessment has two aspects:

The previous assessments are based on metrics.

• If this valuation is impossible or inconvenient (the “replacement” value of a person after an

• Substate C, confidentiality of information: MAGERIT uses a four level scale (each is

- Free, its disclosure is unrestricted (NON-personal data).

- Restricted, with normal restrictions (personal data).

- Confidential, its disclosure is not allowed due to its critical nature.

- High, when it is difficult and expensive to recover the needed quality.

- Critical, when it is not possible to recover the same quality.