Guide To Security Risk Management For Information Technology Systems

i
Acknowledgments
This guide is a risk management framework for Information Technology (IT)
systems and is the culmination of a tireless effort on the part of an
interdepartmental Risk Management Working Group. Many thanks is extended to
the participating departments who offered their valuable time and expertise to
make this guide a reality.
Points of Contact
Comments, suggestions and inquiries on Security Risk Management for
Information Technology Systems should be directed to the Standards and
Initiatives Unit, Risk Management Coordinator, tel. (613) 991-7446,
Fax (613) 991-7411, Internet address: riskmgmt@cse.dnd.ca. For additional copies
of the document, please contact the ITS Publications Section at
(613) 991-7514/7468 or CSEs WWW site at the following address:
http://WWW.cse.dnd.ca.
1996 Government of Canada, Communications Security Establishment (CSE)
P.O. Box 9703, Terminal, Ottawa, Ontario, Canada, K1G 3Z4
This publication may be reproduced verbatim, in its entirety, without charge, for
educational and personal purposes only. However, written permission from CSE is
required for use of the material in edited or excerpted form, or for any commercial
purpose.
ii
FOREWORD
The aim of this guide is expand on the standards set out in the Government
Security Policy (GSP) and thus provide specific guidance for risk management
within an IT system environment and its life cycle.
Coincident with this effort, CSE funded a project to develop a guide for risk
assessment and safeguard selection as well as a guide for the certification and
accreditation process of an IT system throughout its life cycle. Once the three
documents had sufficiently matured, they were harmonized to present one
cohesive message for risk management throughout an IT system life cycle.
Users are encouraged to apply this guide and its two companion documents, A
Guide to Risk Assessment and Safeguard Selection and A Guide to Certification
and Accreditation in their environment. To this end, CSE invites all users to
comment on these documents, suggest any ways we can improve the guidelines
and any suggestions for further study such as a methodology for risk management
for IT systems.
Furthermore, users are encouraged to use theses guides in concert with the
RCMP, Information Technology Security Branch document, A Guide to Threat and
Risk Assessment for Information Technology.
iii
TABLE OF CONTENTS
ACKNOWLEDGEMENTS.......................................................................................... i
POINTS OF CONTACT............................................................................................. i
FOREWORD............................................................................................................ ii
LIST OF ABBREVIATIONS AND ACRONYMS...................................................... vii
INTRODUCTION......................................................................................................1
1. SECURITY RISK MANAGEMENT FRAMEWORK...............................................3
1.1 Security Risk Management Concept ...............................................................3
1.2 Security Risk Management Process ...............................................................3
1.2.1 Planning..................................................................................................4
1.2.2 Threat and Risk Assessment (TRA) .......................................................5
1.2.2.1 TRA Preparation........................................................................5
1.2.2.2 TRA Analysis.............................................................................6
1.2.2.3 TRA Recommendations ............................................................6
1.2.3 Decision to Reduce, Avoid, Transfer or Accept Risk..............................6
1.2.4 Requirements Definition .........................................................................6
1.2.5 Safeguard Selection ...............................................................................6
1.2.6 Construction and Implementation...........................................................7
1.2.7 Certification.............................................................................................7
1.2.8 Decision for Accreditation.......................................................................7
1.2.9 Accreditation...........................................................................................7
1.2.10 Operations and Maintenance ...............................................................7
1.2.11 Decision for Proposed Changes...........................................................8
1.3 A Model of Risk Management in the System Life Cycle..................................8
1.3.1 Risk Management throughout the System Life Cycle.............................8
2. RISK MANAGEMENT PROCESS GUIDANCE ..................................................10
2.1 System Life Cycle Overview..........................................................................10
2.1.1 System Life Cycle Stages.....................................................................10
2.1.2 Risk Management Process Iteration.....................................................11
2.2 Planning for Change .....................................................................................12
2.2.1 Prepare.................................................................................................12
iv
2.2.1.1 Aim, Scope and Resources.....................................................12
2.2.2 Assess..................................................................................................13
2.2.2.1 Analyzing and Assessing Program Options.............................13
2.2.2.2 Preliminary Certification Plan ..................................................13
2.2.3 Decide ..................................................................................................14
2.2.3.1 Decisions.................................................................................14
2.2.3.2 Documents ..............................................................................14
2.2.4 Planning for Change Summary ............................................................15
2.3 System Requirements Definition...................................................................15
2.3.1 Prepare.................................................................................................15
2.3.1.2 IT System Description .............................................................15
2.3.1.3 Preliminary Statement of Sensitivity (SoS) ..............................16
2.3.2 Assess..................................................................................................16
2.3.2.1 System Specific Security Policy ..............................................16
2.3.2.2 Initial Threat and Risk Assessment .........................................16
2.3.2.3 Functional Security Requirements...........................................17
2.3.3 Decide ..................................................................................................17
2.3.3.1 Final Certification Plan.............................................................17
2.3.3.2 Validation of Security Requirements .......................................17
2.3.3.3 System Design Review............................................................18
2.3.4 System Requirements Definition Summary..........................................18
2.4 Architecture Design.......................................................................................18
2.4.1 Prepare.................................................................................................18
2.4.1.2 Development of System Options.............................................19
2.4.2 Assess..................................................................................................19
2.4.2.1 Threat and Risk Assessment (TRA) of System Options..........19
2.4.2.2 Technical and Operational Security Policies ...........................19
2.4.2.3 Configuration Management Plan (CMP)..................................19
2.4.2.4 Refined Statement of Sensitivity (SoS) ...................................19
2.4.2.5 Security Testing and Evaluation (ST&E) Strategy...................20
2.4.2.6 Security Validation and Verification.........................................20
2.4.3 Decide ..................................................................................................20
2.4.3.1 Architecture Review.................................................................20
2.4.3.2 Requirements Review .............................................................20
2.4.4 Architecture Design Summary..............................................................21
2.5 Detailed Design.............................................................................................21
2.5.1 Prepare.................................................................................................22
2.5.1.2 Development of Detailed Design.............................................22
2.5.2 Assess..................................................................................................22
2.5.2.1 Threat and Risk Assessment (TRA) of Detailed Design..........22
2.5.2.2 Preliminary Security Operating Procedures.............................22
2.5.2.3 Final Statement of Sensitivity (SoS) ........................................23
2.5.2.4 Final Configuration Management Plan (CMP) .........................23
2.5.2.5 Security Testing and Evaluation (ST&E) Plan.........................23
v
2.5.2.6 Security Validation and Verification.........................................23
2.5.3 Decide ..................................................................................................23
2.5.3.1 Detailed Design Review ..........................................................23
2.5.3.2 Requirements Review .............................................................23
2.5.4 Detailed Design Summary....................................................................24
2.6 System Implementation.................................................................................24
2.6.1 Prepare.................................................................................................25
2.6.1.2 System Implementation Schedule...........................................25
2.6.2 Assess..................................................................................................25
2.6.2.1 Security Operations Plan.........................................................25
2.6.2.2 Disposal Plan ..........................................................................25
2.6.2.3 Assessment of Residual Risk..................................................26
2.6.3 Decide ..................................................................................................26
2.6.3.1 Accreditation Decisions ...........................................................26
2.6.4 System Implementation Summary........................................................27
2.7 System Operation .........................................................................................27
2.7.1 Prepare.................................................................................................27
2.7.2 Assess..................................................................................................28
2.7.2.1 Configuration Management .....................................................28
2.7.2.2 Periodic Risk Assessment .......................................................28
2.7.2.3 Update Disposal Plan..............................................................28
2.7.3 Decide ..................................................................................................28
2.7.3.1 Operational Security Audit.......................................................28
2.7.3.2 Operational Review.................................................................29
2.7.4 System Operation Summary ................................................................29
2.8 Summary.......................................................................................................30
ANNEX A STATEMENT OF SENSITIVITY .........................................................31
GLOSSARY............................................................................................................34
BIBLIOGRAPHY.....................................................................................................38
vi
LIST OF TABLES
Table I Six Stage Life Cycle .............................................................................12
Table II Planning for Change Summary............................................................15
Table III System Requirements Definition Summary .........................................18
Table IV Architecture Design Summary.............................................................21
Table V Detailed Design Summary...................................................................24
Table VI System Implementation Summary.......................................................27
Table VII System Operation Summary................................................................29
Table VIII Risk Management Documentation Streams........................................30
Table IX Relationship Between C/I/A and Assets................................................31
LIST OF FIGURES
Figure 1 Relationship between Guidance Documents...........................................2
Figure 2 Risk Management Model .........................................................................5
Figure 3 Risk Management throughout the System Life Cycle..............................9
Figure 4 Risk Management Throughout the System Life Cycle.............................11
vii
LIST OF ABBREVIATIONS AND ACRONYMS
AA Accreditation authority
CCB Configuration Control Board
CMP Configuration Management Plan
CSE Communications Security Establishment
CSSC Canadian System Security Centre
CTCPEC Canadian Trusted Computer Product Evaluation Criteria
DSO Departmental Security Officer
GSP Government (of Canada) Security Policy
IT Information Technology
ITS Information Technology Security
MOU Memorandum of Understanding
NCSC National Computer Security Centre (USA)
OA Operational Authority
SoS Statement of Sensitivity
ST&E Security Testing and Evaluation
TCSEC Trusted Computer System Evaluation Criteria (USA)
TRA Threat and Risk Assessment
TSEG Trusted Systems Environment Guideline (CAN)
1
INTRODUCTION
Purpose
The purpose of this document is to provide guidance for security risk management
for information technology (IT) systems.
Scope
The document provides guidance for the management of security risks throughout
the life cycle of IT systems.
Audience
The document is intended for use by a wide range of personnel, including
managers of programs, systems, and projects; security officials; planners; and
engineers.
Document Structure
The document has two main parts. The first describes a general framework for
security risk management, including a model process. The second provides
detailed guidance for implementation of the framework.
Supporting Documentation
The guidance provided in this document is in the context of risk management
during the life cycle of a IT system. A Guide to Risk Assessment and Safeguard
Selection provides additional guidance for system designers on the technical
factors associated with performing risk assessments and selecting appropriate
safeguards. A Guide to Certification and Accreditation provides additional
guidance on the types of certification documentation required to accredit the IT
system. The relationship between the three documents is illustrated in Figure 1.
Departmental Roles in Security Risk Management
Departmental Security Officer (DSO)
Government Security Policy (GSP) requires that an individual (the DSO) be
responsible for developing, implementing, maintaining, coordinating and
monitoring a departmental security program consistent with the security policy
and standards. Security risk management is an integral part of the
departmental security program.
2
Information Technology Security (ITS) Coordinator
The GSP requires that an ITS Coordinator be appointed and that this position
should have at least a functional relationship to the DSO. The ITS Coordinator
assists the DSO with IT security matters, including being the focal point for IT
security risk management development, implementation and coordination,
consistent with security policy and standards.
Accreditation Authority (AA)
The AA is the departmental security authority who is responsible for approving
and accepting the residual risk from a security point of view. If multiple AAs
are permitted, care must be taken to ensure consistency of accreditations
across the department.
Guide to
Security Risk Management
Guide to
Risk Assessment &
Safeguard Selection
Guide to
Certification &
Accreditation
Figure 1 Relationship between Guidance Documents
3
1. SECURITY RISK MANAGEMENT FRAMEWORK
1.1 Security Risk Management Concept
The government security policy requires departments to manage security risks by
confirming the appropriateness of minimum standards and supplementing these
standards where necessary, and eliminating unnecessary expenditures and
administrative barriers. Managing security risks means defining what is at risk, the
relative magnitude of risk, the causal factors, and what to do about the risk.
Options for managing risk include reduction, transfer, avoidance and acceptance.
Risk can be reduced by implementing a managed system architecture which
includes operational, procedural, physical, personnel, and technical security
components.
Risk management involves planning, organizing, directing and controlling resources
to ensure that risk remains within acceptable bounds, and that the cost is affordable.
It is also a collaborative process where representatives of various interest groups
develop a shared understanding of requirements and options. Increased awareness
will strengthen security and make it more compatible with user needs.
Risk management for IT systems presents some particular difficulties arising from the
dynamic nature of risk factors and rapid evolution of technology. Failure to consider
security risk factors in an adequate and timely fashion may result in ineffective and
unnecessarily costly security measures. Therefore, security risk management must
be considered an integral part of the overall system life cycle process.
1.2 Security Risk Management Process
The risk management process includes the following steps, as shown in figure 2:
a) Planning;
b) TRA Preparation;
c) TRA Analysis;
d) TRA Recommendations;
e) Decision to Reduce, Avoid, Transfer or Accept Risks;
f) Requirements Definition;
g) Safeguard Selection;
h) Construction and Implementation;
i) Certification;
j) Decision for Accreditation;
k) Accreditation;
l) Operations and Maintenance; and
4
m) Decision for Proposed Changes.
The following subsections provide additional detail on each activity within the risk
management process.
1.2.1 Planning
Preparing for the risk management process involves:
a) establishing the aim of the security risk management process;
b) identifying the scope and boundary of the system to be analyzed;
c) gathering information (historical information on failures and
vulnerabilities);
d) describing the system; and
e) establishing a target risk (generally the target risk is the minimum
acceptable risk).
The IT system description should include a thorough description of the system
requirement (or system mission), a concept of operation, and an identification of
the nature of the system assets.
5
Threat and Risk Assessment
Accreditation
Operations and
Maintenance
Planning
- Aim
- Scope
- Boundary
- Gathering
Information
- System
Description
-Target risk
& required
certainty
Requirements
Definition
Safeguard
Selection
- administrative
- personnel
- physical
- technical
Construction
and
Implementation
Certification
Decision
Decision
Decision
Reduce
risk
Accept
risk
Avoid or Transfer risk
Change
Required
Significant
insignificant
TRA Analysis
Threat Analysis:
- Identify threats
- Assess likelihood of a
compromise
- Assess consequence
of a compromise
Risk Analysis:
- Identify vulnerabilities
- Identify safeguards
- Assess Risk
(quantitative and/or
qualitative)
TRA
Preparation
- Identify
assets
- Statement of
Sensitivity
TRA
Recommendations
Risks:
- Avoid
- Transfer
- Reduce
- Accept
Refine System Design
Figure 2 Risk Management Model
The scope of the risk assessment must be defined, in terms of system boundary and
the allowable uncertainty in the assessment of residual risk. This step is fundamental
in determining the level of detail to be included in the threat and risk assessment.
1.2.2 Threat and Risk Assessment (TRA)
The objective of a TRA is to identify sensitive system assets, to identify how these
assets can be compromised by threat agents, to assess the level of risk that the
threat agent poses to an asset, and to recommend how to proceed in the life cycle.
The TRA occurs at various stages of the system development life cycle.
1.2.2.1 TRA Preparation
During the preparation of a TRA, system assets
1
are identified and a Statement of
Sensitivity (SoS) is completed. The SoS documents the system assets, their
confidentiality, integrity and availability requirements, and their replacement value.
The SoS captures the importance of the IT system to the business function which it
supports, and should reflect the criticality of that function.

1
In this document, system assets includes information, hardware, communications equipment, firmware,
documents/publications, environmental equipment, people/staff, infrastructure, goodwill, money, income, organizational
integrity, customer confidence, and organizational image.
6
1.2.2.2 TRA Analysis
In the TRA analysis, vulnerabilities and existing safeguards are identified and
examined to determine how an asset can be compromised by a threat agent. The
level of risk to the asset is a measure of the likelihood of the compromise and the
consequences of the compromise where the consequences are a function of the
assets sensitivity.
1.2.2.3 TRA Recommendations
An assessment of the adequacy of existing or proposed safeguards which protect
system assets forms part of the TRA process. Where the assessment of
safeguards indicates that certain vulnerabilities are not appropriately offset,
appropriate additional safeguards would be recommended in order to reduce the
risk to an acceptable level. Conversely, if safeguards are no longer appropriate,
their removal would be recommended. If additional safeguards can not reduce the
risk to an acceptable level for an acceptable cost, the risk may be avoided or
transferred by moving the location of the system, or removing the asset that is at
risk.
1.2.3 Decision to Reduce, Avoid, Transfer or Accept Risk
The TRA process provides the system manager with an appreciation of the security
status of the system. The TRA recommendations will either suggest possible
changes to the system design or suggest the acceptance of the risk. Each option
will have an associated cost: that is; risk, time, money, people, and equipment.
Management must choose the most appropriate option based on the likelihood of
the undesirable or intolerable consequences of a threat scenario occurring.
1.2.4 Requirements Definition
If it is determined that risks are to be reduced, security requirements can be
defined in terms of the security functionality required to reduce the risk. It should be
possible for the functionality requirement to be satisfied by more than one
safeguard or set of safeguards.
1.2.5 Safeguard Selection
Technical and/or non-technical safeguards must be selected to meet the functional
security requirements and to adequately mitigate the identified risks. Non-technical
safeguards include the establishment of the administrative security structure,
personnel and physical security measures, and the establishment and
documentation of security procedures and practices. The cost of safeguards, in
terms of expense, system performance, user acceptance, schedules and other
potential impacts, must be balanced against the resulting reduction of risk. To
support this type of cost benefit analysis, safeguards must be specified in parallel
with design of the system.
7
1.2.6 Construction and Implementation
Once the system security requirements have been identified, and safeguards have
been selected, the IT system can be constructed and implemented. Security
acceptance procedures ensure that the risk of operating the system, as it has been
implemented, is acceptable. These procedures are usually referred to as
certification and accreditation.
1.2.7 Certification
Certification is a comprehensive assessment of the technical and non-technical
security features of an IT system that establishes the extent to which the system
satisfies the specified security requirements. It should include:
a) validation that security safeguards meet the security requirements and
the security policy;
b) testing of security safeguards;
c) evaluation of technical security measures in terms of functionality and
assurance;
d) verification of physical, personnel and procedural safeguards; and
e) comparison of the system residual risk with the target risk.
Certification results in a set of reports which support the accreditation decision.
1.2.8 Decision for Accreditation
At this point in the process, the system design is reviewed for completeness and
compliance to requirements. If the design is not complete or if the certification
documentation indicates that not all requirements are adequately met by the
design, the risk management process returns to the preparation step in order to
adjust the system design. If the certification documentation is complete and all
requirements are adequately met, the process moves to the accreditation step.
1.2.9 Accreditation
Accreditation represents departmental approval to operate an IT system.
Accreditation is the formal declaration by the responsible manager that an
automated system is approved to process information up to a maximum sensitivity
level, under specified controls and operating procedures. It signifies the official
acceptance of residual risk by responsible organizational management.
1.2.10 Operations and Maintenance
The security objective during the operational stage of the system life cycle is to
ensure that the integrity of the secure system architecture is maintained. This is
accomplished through ongoing risk management activities, including configuration
management, security monitoring, audits, and risk reviews.
8
Prior to becoming operational, plans and procedures are required to address the
risks inherent in the handling and the disposal of sensitive information and assets
produced by, or associated with the system. Ultimately, this also includes disposal of
the system when it is taken out of service. Throughout the operation of the system,
these operational plans and procedures are reviewed to ensure that they continue to
address system risks.
1.2.11 Decision for Proposed Changes
Over the operational lifetime of the system, system design changes will be required
to accommodate departmental growth, equipment upgrades, changes in asset
sensitivity, changes in assessed risk, and changes in the business function of the
system. If the changes do not pose a significant risk, the changes can be made
without having to re-enter the risk management process. If the risk is significant,
the risk management process should be re-entered to ensure that appropriate
safeguards are implemented in the system.
1.3 A Model of Risk Management in the System Life Cycle
The risk management process and life cycle concept outlined in this section is
applicable to all life cycle methodologies. The level of detail applied is dependent
on factors such as the size and complexity of the system, the level of assurance
that is required and the availability of resources, including time, money and
expertise.
1.3.1 Risk Management throughout the System Life Cycle
The risk management process in the previous section can be incorporated into the
life cycle of an IT system. When risk management activities are applied throughout
a systems life cycle, security is built into the system that continues to be relevant to
evolving conditions and requirements.
Figure 3 shows a series of concentric rings depicting the different stages in a
systems life cycle; from planning through to the operational stages. When a
significant change is proposed, the system life cycle moves to the central planning
stage. This spiral model accommodates an arbitrary number of life cycle stages.
Each stage of the life cycle may be broken down into three main activities: prepare,
assess and decide.
Preparation within each life cycle stage involves identifying the scope of risk
management activities within the stage, determining the requisite inputs and
expected outputs, and gathering any relevant information needed to conduct
assessments and make decisions.
Assessment within each life cycle stage involves analyzing options, assessing threats
and risks, assessing the appropriateness of safeguards, and assessing the adequacy
of system documentation to ensure that security requirements are identified and
9
addressed. Assessment criteria are set to fit the scope of the assessment. Such
criteria could include feasibility, functionality, consistency and adequacy.
Decisions must be made at each life cycle stage. The primary decision is whether to
proceed to the next stage. If more than one design option is available, the most cost
effective and efficient solution for a secure system must be chosen. Also, TRA
recommendations for a design option must be considered to determine which
recommendations are to be implemented into the system.
Stage N
Operational
Stage N-1
.
.
Planning
Decide
Prepare
Assess
Figure 3 Risk Management throughout the System Life Cycle
10
2. RISK MANAGEMENT PROCESS GUIDANCE
2.1 System Life Cycle Overview
2.1.1 System Life Cycle Stages
This chapter presents guidance for risk management through a six stage life cycle.
These six stages are as follows as shown in figure 4:
1) planning for change: alternative approaches are reviewed, program risks are
assessed, and a decision to proceed with a particular program is made.
2) requirements definition: based on the assessment of key risk factors,
functional security requirements are developed and a target overall risk level
is established.
3) architecture design: secure system options are identified, and a preferred
option is selected based on an assessment of residual risk.
4) detailed design: design specifications are developed, and specific safeguards
are selected.
5) implementation: the IT system is developed, implemented, installed and
tested.
6) operational: the system is put into operation and is maintained and reviewed.
This six-stage approach is not intended to dictate a particular development process,
but rather to describe a generic process that can be mapped to a preferred life cycle
method.
11
2.1.2 Risk Management Process Iteration
Within each iteration, steps of the risk management process identified in
section 1.2 are observed, as shown in Table I.
The TRA steps are taken in all of the life cycle stages. In addition, the requirements
definition, safeguard selection, construction and implementation, and certification
steps are undertaken during the stages of Architecture Design, Detailed Design, and
System Implementation.
Operational
Planning
Decide
Prepare
Assess
Requirements Definition
Architecture Design
Detailed Design
Implementation
Figure 4 Risk Management Throughout the System Life Cycle
12
Table I Six Stage Life Cycle
LIFECYCLE STAGE RISK MANAGEMENT STEPS
Planning for Change Planning
System Requirements Definition Planning
Architecture Design Planning
Safeguard Selection
Construction and Implementation Certifications
Detailed Design Planning
Safeguard Selection
System Implementation Planning
Safeguard Selection
Accreditation
System Operation Planning
Operations and Maintenance
2.2 Planning for Change
During this stage of the life cycle, the principal objectives of planning for change are
to:
a) review the need for change;
b) examine program options;
c) assess the risks associated with each program option; and
d) decide on whether to proceed with a program of change.
2.2.1 Prepare
2.2.1.1 Aim, Scope and Resources
At this stage of the life cycle, the aim is to establish a program for change which best
meets program requirements at an acceptable level of risk.
13
The preparation activities:
a) define stakeholders
2
, assign roles and responsibilities, and establish
lines of communication (that is, identify departments/organizations
affected by any changes, and draft memorandums of understanding that
describe roles and responsibilities and have the support of the defined
departments/organizations);
b) state the system mission (that is, why is the system required and what
will it do?);
c) describe the system (that is, state where the system is to be located and
the sensitivity of known assets);
d) describe the reason for change (that is, why is the program of change
required?);
e) state the options for mission achievement (that is, options may include
incremental change, minor or major change, or maintaining the status
quo);
f) define the milestones (that is, when are the changes required?).
2.2.2 Assess
2.2.2.1 Analyzing and Assessing Program Options
Once change requirements and program options have been identified, these
should be reviewed from the perspective of risk to the business function and
institutional objectives. A high-level assessment of risk to the known assets should
be made to determine whether the technology required to protect the assets is
available, or is likely to be available during the implementation of the system. This
analysis supports the assessment of overall program risk management outlined in
chapter 2-1 (Risk Management Policy) of the Treasury Board Manual for
Information and Administrative Management Component, Material, Risk and
Common Services.
2.2.2.2 Preliminary Certification Plan
Based on the type of technology to be used in the program option and the level of
required risk reduction, a preliminary certification plan should be drafted in
conjunction with the overall project plan. The certification plan should indicate the
types of certification activities required, the points in the life cycle that the activities
should be performed, and the level of effort required to perform them.

2
System stakeholders includes security, management, operations and administrative representatives from the affected
departments/organizations.
14
2.2.3 Decide
2.2.3.1 Decisions
Based on the security risk assessment, in conjunction with the program risk
assessment, a decision is made. If the decision is positive, the life cycle will
progress to the system requirements definition stage.
2.2.3.2 Documents
1) The concept of change describes program options from an organizational
perspective, and documents:
a) the requirement for change (for example, a statement of deficiency
including any security deficiencies);
b) program options for satisfying the change requirement;
c) assumptions regarding the scope of the change; and
d) relevant system development constraints, including policy, standards,
cost, or time.
2) A preliminary certification plan may be a separate document or it may be
incorporated into the project plan, and should include:
a) a list of certification activities that will be required;
b) a general schedule for the certification activities with reference to points
in the life cycle; and
c) the level of effort required to perform the certification activities.
3) A project plan describes how the project will proceed, and should include:
a) a description of the core project team members (the project team should
include member(s) with IT system security experience);
b) project team member roles and responsibilities (security team members
should be included in system design); and
c) allocation of time and resources to address security issues.
4) A configuration management plan (CMP) that provides project personnel with
the methods and tools to
a) identify the system at any time during its life cycle;
b) control changes to the system; and
c) monitor the status of the system and its components.
5) Memorandums of Understandings that document agreements with other
government departments, private firms, or foreign governments, defining roles
and responsibilities of each department/organization.
15
2.2.4 Planning for Change Summary
The following table highlights the life cycle activities for the planning for change
stage, and the supporting guidance documents.
Table II Planning for Change Summary
Risk Management Life Cycle
Documents
develop Program Options
produce Concept of Change
produce Project Plan
produce CMP
draft MOUs (Memorandums of Understanding)
Guide to Risk Assessment and
Safeguard Selection
perform high level TRA
Guide to Certification and
Accreditation
draft Preliminary Certification Plan
review MOUs
2.3 System Requirements Definition
The principal objectives of the system requirements definition stage are to:
a) define the security policy of the IT system;
b) identify and rank the key risk factors which justify the system security
requirements;
c) develop and baseline the functional, operational and security
requirements for the system; and
d) develop a preliminary certification plan, in particular a security test and
evaluation (ST&E) strategy which will ensure that the required level of
assurance in the systems technical safeguards is achieved.
2.3.1 Prepare
At this point in the development life cycle, analysis is conducted at the functional
level. While detailed technical analysis is not usually required, an understanding of
the proposed systems vulnerabilities is required. Technical resources, including
risk analysts, system and security engineers, and security evaluators, may need to
be added to the project team during this stage.
2.3.1.2 IT System Description
An IT system description that provides the following details for the IT system will be
required:
16
1) Operational Requirement: A statement of the operational requirement
which the system must support, including business objectives, operational
role, functions and performance requirements.
2) Concept of Operation: An overview of how the system will be used to
support the operational requirement, including descriptions of information
handled, types of applications or processing, users, and basic system
configuration.
3) Location: The physical location of the system and the surrounding
geographical area is not to be overlooked. The location influences the
availability and effectiveness of system safeguards. It may also impose
constraints which influence the system.
4) Anticipated modification or expansion: Any future plans for modification or
expansion should also be well documented, as this may have an effect on the
design of the system, in particular on the choice of system safeguards. Future
modifications to the system may compromise the effectiveness of existing
safeguards, if these safeguards are not chosen properly.
In cases where an existing system is being reviewed, the IT System Description
document should be available, and may include information on system topology,
hardware, software and interfaces.
2.3.1.3 Preliminary Statement of Sensitivity (SoS)
A preliminary SoS can be developed based on the IT System Description. It may
not be possible to complete a full SoS at this time, since complete system
specifications and design are usually required to identify sensitive supporting
assets. However, it should be possible to provide details on the sensitivity of the
information handled by the IT system.
2.3.2 Assess
2.3.2.1 System Specific Security Policy
The system specific security policy reflects applicable government or departmental
security policies and standards, and describes the security services to be provided by
the system.
2.3.2.2 Initial Threat and Risk Assessment
Based on the IT System Description and the preliminary SoS, an initial risk analysis
can now be undertaken to identify and rate key risk factors that will influence the
development of the system specific security requirements. Key risk factors will be
driven by the sensitivity of the systems assets, the systems environment and
vulnerabilities, and will identify the threat scenarios which contribute to the risk.
Analyzing the impacts of various threat scenarios is a useful means of identifying key
risk factors.
17
Having identified the risk factors, an acceptable residual risk can be established. This
target residual risk describes the level to which the risk factors should be mitigated.
2.3.2.3 Functional Security Requirements
Functional security requirements can now be developed. The functional security
requirements are high level statements of countermeasures that will mitigate the
risk factors, and do not require fine detail. They will be translated into specific
security requirements during the later stages of the risk management process.
Functional security requirements should, as a minimum, satisfy applicable security
policies and standards which govern the system. The initial risk assessment will help
ensure that applicable standards are applied in a cost-effective manner. System
constraints and operational requirements are always a major factor in the definition of
the security requirements, since these will introduce limitations and trade-offs which
must be considered.
System specific functional security requirements should be subjected to a quality test
to ensure that they are consistent, complete, appropriate, implementable and
verifiable. Assistance in identifying appropriate security requirements is available
from lead government agencies.
2.3.3 Decide
2.3.3.1 Final Certification Plan
A certification plan should be finalized to ensure that the required certification
activities are identified and will be performed at specified times within the system
life cycle.
2.3.3.2 Validation of Security Requirements
As part of the certification process, the security requirements are mapped to the
system specific security policy and to the department/organizations security policy.
The level of effort required for the validation of the security requirements is
determined by the assurance requirements for the system components.
18
2.3.3.3 System Design Review
At this point, the results of the security requirements validation are reviewed and
the proposed system security requirements are examined to determine whether
they appear to be feasible. The system and functional security requirements must
satisfy applicable security policy and standards. The program manager should
verify that the proposed functional, operational and security requirements and
target risk level are acceptable. If no problems are encountered, the process
progresses to the architecture design stage.
2.3.4 System Requirements Definition Summary
The following table highlights the life cycle activities for the system requirements
definition stage, and the supporting guidance documents.
Table III System Requirements Definition Summary
Documents
produce System Specific Security Policy
Safeguard Selection
draft Preliminary SoS
perform initial TRA
produce Functional Security Requirements
Accreditation
validate Functional Security Requirements
produce Final Certification Plan
2.4 Architecture Design
The principal objectives of the architecture design stage are to:
a) develop secure system architecture options; and
b) select the preferred secure system option.
For a large or complex system, design options may correspond to significantly
different architectures. In the case of simpler systems, this step may involve
examining one or two minor design alternatives.
2.4.1 Prepare
At this point, risk assessment activities consider specific safeguards, and include a
greater level of technical detail. System options are identified and analyzed. Similar
expertise as for the System Requirements stage is required.
19
2.4.1.2 Development of System Options
A set of projected system architecture options should be developed, which fulfill the
functional, operational and security requirements. These system architecture
options need only be at a high level, and should include general information on
system configuration and system assets.
The System Options describe the basic system configuration, generic types of
system components which are likely to be used, performance requirements for
system components, as well as system and environmental constraints. From the
security requirements and the concept of operations, a high-level set of technical
security safeguards with proposed levels of assurance should be developed for each
system option. In addition, organizational, operational, physical (including
environmental), procedural and personnel security safeguards should be identified
and documented. Documentation tracing a safeguard to a security requirement
should be included for each proposed option.
2.4.2 Assess
2.4.2.1 Threat and Risk Assessment (TRA) of System Options
A TRA should be performed for each proposed system option, in order to
determine its overall feasibility and effectiveness. The TRA should involve a
projection of characteristic vulnerabilities of each architecture, development of
threat scenarios, a review of proposed safeguards, estimates of the impact and
likelihood associated with each threat scenario, and a measure of the residual risk.
Additional safeguards may be recommended depending on the outcome of the
TRA.
2.4.2.2 Technical and Operational Security Policies
The TRA will have uncovered the areas of highest risk, and this information will
help in developing a specific set of security rules to be enforced by the system (the
technical security policy) and by the operations environment (the operational
security policy). These technical and operational security policies are a refinement
of the system specific policy, and should dictate how the technical and operational
attributes of the system design architecture are to be configured. If these policies
do not reduce the level of risk to an acceptable level, the system options in Section
2.4.1.2 should be adjusted until the risk is acceptable.
2.4.2.3 Configuration Management Plan (CMP)
Once preliminary designs have been completed, the CMP should be updated. The
same CMP might apply for each system option.
2.4.2.4 Refined Statement of Sensitivity (SoS)
Once the TRA has been performed and the technical and operational security
policies have been developed, the SoS should be re-examined and revised, if
20
necessary. Whenever the SoS is adjusted, it should be reviewed and signed off by
the project authority.
2.4.2.5 Security Testing and Evaluation (ST&E) Strategy
A strategies for testing and evaluating implemented technical safeguards should be
developed to ensure that the required certification documentation is available when
the final design is implemented. The strategy should outline a process to:
a) establish whether the technical safeguards have the required security
functionality;
b) establish whether the technical safeguards have any additional
functionality that may introduce unforeseen system vulnerabilities;
c) establish the depth of security testing required for technical safeguards;
and
d) verify the effectiveness of the specified integrated security posture,
including organizational and administrative, operational, procedural,
physical (including environmental) and personnel security measures.
At this point, the strategy may include the creation of a set of procedures that can be
implemented later in the life cycle. The proposed strategy should be reviewed for
adequacy and completeness.
2.4.2.6 Security Validation and Verification
The selected safeguards in the architecture design should be validated by mapping
them to the technical and operational security policies and the security policy
model from the previous life cycle stage. Also, the selected safeguards should be
reviewed to verify that they meet applicable policies and standards.
2.4.3 Decide
2.4.3.1 Architecture Review
The project authority should carefully examine the proposed system options, in
order to decide on the optimal system option to take into the detailed design, or to
determine that more work needs to be done before proceeding to the next stage.
The direction to be taken in correcting any difficulties should be identified by the
project authority. If the preliminary ST&E, certification CMPs are also acceptable,
the process moves to the detailed design stage.
2.4.3.2 Requirements Review
During this life cycle stage, the project authority may find that a security
requirement cannot be met by the system. The impact and risk of not meeting the
requirement should be outlined and brought to the attention of the Accreditation
Authority (AA). A formal or conditional waiver of the requirement may be given by
the AA if the associated risk is acceptable.
21
2.4.4 Architecture Design Summary
The following table highlights the life cycle activities for the architecture design
stage, and the supporting guidance documents.
Table IV Architecture Design Summary
Documents
develop Design Options
develop Technical and Operational Security Policies
select Optimal Design Option
refine CMP
Safeguard Selection
refine SoS
refine TRA
select Safeguards
Accreditation
validate and verify safeguards
validate technical and operational security policies
develop ST&E Strategy
review Requirement Waiver requests (if required)
2.5 Detailed Design
The detailed design stage begins once the optimal system architecture option has
been selected, and results in a complete system specification, suitable for
implementation. The objectives of the detailed design stage are to:
a) develop detailed technical and security specifications for the optimal
option;
b) assess the vulnerabilities and risks associated with the detailed design;
c) develop security operating procedures which support the technical
security mechanisms; and
d) develop detailed security test plans to validate the technical security
mechanisms.
22
2.5.1 Prepare
This stage encompasses the most detailed level of analysis TRAs should consider
specific technical vulnerabilities and threat agent capabilities. Additional technical
expertise and access to specialized threat and vulnerability information may be
required.
2.5.1.2 Development of Detailed Design
Once the architecture design review process has been completed, the high level
architecture and safeguards baselined in the preliminary design should be expanded
to a detailed design.
a) A complete listing and description of all system components, including
hardware, software and firmware;
b) A detailed specification for each of the system (including security)
components;
c) A full description of how the individual system components are to be
interconnected, including information on networking protocols and
security mechanisms;
d) A profile of system users, together with their respective security
clearances, roles and privileges;
e) A detailed description of all technical safeguards, in support of the
technical security policy;
f) A detailed description of the systems expected physical environment;
g) A description of the organizational/administrative, operational, physical
(including environmental), procedural and personnel security
safeguards; and
h) Specifications for construction of computer rooms (IT system
environment).
2.5.2 Assess
2.5.2.1 Threat and Risk Assessment (TRA) of Detailed Design
The TRA should focus on critical threat scenarios, and technical vulnerabilities.
2.5.2.2 Preliminary Security Operating Procedures
A preliminary set of security operating procedures should be developed for the
system. These procedures should include comprehensive contingency plans, in
order to ensure that effective recovery measures are in place.
23
2.5.2.3 Final Statement of Sensitivity (SoS)
Once the detailed design has been completed, the SoS should be expanded to full
detail. The assets should have been completely identified by this point, and the
confidentiality, integrity and availability requirements reviewed during the detailed
TRA. The completed SoS should be reviewed and signed off by the project
authority.
2.5.2.4 Final Configuration Management Plan (CMP)
The CMP should be refined, as necessary, to include:
a) expanded detail on administrative procedures for reviewing and
implementing any proposed changes to the system over time; and
b) complete detail on the documentation that should be provided to the
system authorities, in support of any proposed changes.
2.5.2.5 Security Testing and Evaluation (ST&E) Plan
A ST&E plan should be developed, based on vulnerabilities and threat scenarios
identified in the risk assessment. The ST&E plan should include functional,
penetration and composable system tests, as well as an estimate for the time and
resources required to perform the activities, and a schedule which coincides with
the system implementation plan. It must also provide for the documentation of the
test results. If the system is to incorporate a vendor security product, the security
testing procedures should be reviewed and replicated during the detailed design.
2.5.2.6 Security Validation and Verification
The selected safeguards (including the secure operating procedures) in the
detailed design should be validated by mapping them to the technical and
operational security policies. Also, the selected safeguards should be reviewed to
verify that they meet applicable policies and standards.
2.5.3 Decide
2.5.3.1 Detailed Design Review
Once the analysis is complete, then a decision should be made regarding the
feasibility of the detailed design and other deliverables, and the direction to be
taken in correcting any difficulties.
If it has been determined that the detailed design and other deliverables are feasible
from both a technical security and operational point of view, and require no further
modification, then the process progresses to the implementation stage.
2.5.3.2 Requirements Review
During this life cycle stage, the project authority may find that a security
requirement cannot be met by the system. The impact and risk of not meeting the
24
requirement should be outlined and brought to the attention of AA. A formal or
conditional waiver of the requirement may be given by the AA if the associated risk
is acceptable.
2.5.4 Detailed Design Summary
The following table highlights the life cycle activities for the detailed design stage,
and the supporting guidance documents.
Table V Detailed Design Summary
Documents
develop Detailed Design
Safeguard Selection
refine SoS
refine TRA
select Safeguards
develop Secure Operating Procedures
Accreditation
ST&E Plan
verify safeguards
validate Safeguards
secure Operating Procedures
review Requirement Waivers (if required)
2.6 System Implementation
The system implementation stage puts the designed system and the supporting
mechanisms and procedures in place. From the system perspective, acceptance
testing and evaluation ensures that the functionality which was contracted in the
detailed design phase meets the specification. From the security perspective, the
system is certified to ensure that the security requirements that were specified in
the detailed design stage are met. All aspects of security affecting the system, both
technical and non-technical, are verified and the residual risk is assessed.
The main objectives for the implementation stage of the risk management life cycle
are:
a) verification of the technical and non-technical security measures;
b) determining any discrepancies with respect to the security specifications
and defining a manner in which the discrepancies can be resolved, to
allow for acceptance, partial acceptance, rejection or waiver;
c) determining the residual risk;
d) finalizing the security operations plan; and
e) obtaining operational approval (accreditation).
25
2.6.1 Prepare
The principal focus for security in the implementation stage is that of certification.
Risk management activities will normally be limited to examining any non-
compliance or any newly identified vulnerabilities. The assessment will determine
their effect on the residual risk. Since the certification process tests for deficiencies
in the delivered system, special expertise may be required.
2.6.1.2 System Implementation Schedule
Since system test and evaluation is done as part of the system certification
process, it is important to be cognizant of the delivery schedule. Since security
deficiencies may limit the use of the system under test or delay acceptance of the
system for operation, security concerns should be addressed as early as possible
during this stage. Any deficiencies should be included in and tracked with the CMP.
2.6.2 Assess
2.6.2.1 Security Operations Plan
If the certification test results produce a list of security deficiencies, special
operating procedures will need to be developed to allow operation. Such
procedures should form part of the security operations plan, and be consistent with
the organizations security policy.
2.6.2.2 Disposal Plan
Secure operation of a sensitive IT system also requires secure disposal of the
sensitive byproducts of system operation. This will include sensitive:
a) hard copy;
b) electronic media; and
c) hardware (such as TEMPEST compliant equipment and controlled
cryptographic items).
A disposal plan should be included in the secure operating procedures, and should
address the secure storage and/or destruction of intermediate hard copy, removable
media (including backups) and faulty hardware items. The disposal plan should also
cover taking the IT system out of service.
26
2.6.2.3 Assessment of Residual Risk
Where the certification reports indicate that not all security requirements have been
satisfied, a further TRA will be required to assess the effects of the deficiencies on
the residual risk. The results of the TRA will support the accreditation decisions
discussed in Section 2.6.3.1.
2.6.3 Decide
Once certification is complete, a certification report shall be prepared which will
provide the accreditation authority with enough information to make an informed
decision regarding system accreditation.
Once the certification is complete, the system is ready to become operational.
Depending on the organizational structure, the AA may also be the operational
authority (OA), or the accreditation authority has a further hand-over to the
operational authority. Whichever is the case, the organizational member accepts the
responsibility for operating the system in the manner specified in the accreditation
note and for managing the residual risk (that is, maintaining the secure operating
procedures).
2.6.3.1 Accreditation Decisions
The options available to the accreditation authority are as follows:
a) If security has been properly implemented and the residual risk is as
projected, grant approval to operate the system (operational approval);
b) If security flaws are minor and can be corrected by additional
organizational and administrative, operational, physical (including
environmental), procedural and personnel security measures and if the
residual risk is within acceptable bounds, grant approval to operate the
system (operational approval);
c) If serious security flaws exist but can be corrected within a reasonable
length of time, and if the residual risk can be brought within acceptable
bounds in some manner such as reduced operation, grant an interim
approval allowing restrained operation until the system security flaws are
corrected; and
d) Return to one of the previous stages in the life cycle to refine or
redesign the system so that it may be given approval to operate.
Operational and interim approvals are only valid for a specified system
configuration and for a specified time period. When the approval expires, the
system must undergo a mandatory review to determine if the risk is being
maintained at an acceptable level.
27
2.6.4 System Implementation Summary
The following table highlights the life cycle activities for the system implementation
stage, and the supporting guidance documents:
Table VI System Implementation Summary
Documents
develop Implementation schedule
Safeguard Selection
updated TRA
develop final Secure Operating procedures
develop disposal plan
Accreditation
produce Certification Report including
validation results
safeguard verification results
ST&E results
TRA results
grant Operational/Interim Approval
2.7 System Operation
Secure operation of a sensitive IT system requires ongoing review of the systems
security posture, and operating staff who are aware of relevant security issues and
able to implement the secure operating procedures.
The security objective which should be met during the operational stage of the
system life cycle is to maintain the residual risk within acceptable limits. The following
activities are of critical importance in meeting this objective:
a) Maintenance of configuration control over security-critical aspects of the
system;
b) Adherence to the secure operating procedures;
c) Identification of, and response to breaches in system security;
d) Periodic review of the residual risk; and
e) Update secure disposal plans and procedures, as required.
2.7.1 Prepare
Prior to the system becoming operational, operations and administrative staff
should be trained in the secure operating procedures relating to their job function.
A Configuration Control Board (CCB) should be established to review system
change requests, and to ensure that security-critical aspects of the system are
28
properly managed. Specialized expertise may be periodically required to conduct
security audits and re-assess risk.
2.7.2 Assess
2.7.2.1 Configuration Management
The configuration of security-critical components must be maintained, according to
the CMP. Proposed changes to the system should be reviewed by the CCB.
When proposed changes are likely to impact on security critical components, and
lead to a modification of the residual risk, the CCB should ensure that changes are
carried out by following the risk management process described in this guide.
2.7.2.2 Periodic Risk Assessment
Given the dynamic nature of IT systems, technological advances and the changing
threat environment, a system risk assessment should be undertaken periodically to
ensure that the residual risk remains within acceptable limits. The GSP requires that
TRAs be performed on a regular basis. Risk should also be re-assessed when:
a) a security breach or attempted security breach is detected;
b) the threat assessment changes significantly; or
c) the system requirements change.
2.7.2.3 Update Disposal Plan
During the operation of the system, the disposal plan should be reviewed. If there
are any deficiencies, additional procedures should be included in the secure
operating procedures.
2.7.3 Decide
2.7.3.1 Operational Security Audit
System operation should be regularly audited. Regular auditing should:
a) establish that all required safeguards are in place, invoked and
functioning as specified for the approved system security posture;
b) ensure the secure operating procedures are followed; and
c) provide timely detection of breaches or attempted breaches of security.
In this context, auditing includes regular review of system audit trails and examination
of technical security controls, and periodic auditing of organizational/administrative,
operational, physical (including environmental), procedural and personnel security
measures.
29
2.7.3.2 Operational Review
Sensitive IT systems should be periodically subjected to formal operational
reviews, which consider whether the re-accreditation of the system is required.
These reviews would typically coincide with the formal risk re-assessment process.
2.7.4 System Operation Summary
The following table highlights the life cycle activities for the system operation stage,
and the supporting guidance documents:
Table VII System Operation Summary
Documents
assemble CCB
audit Configuration Management
review System Change Request
Safeguard Selection
update TRA
update disposal plan
Accreditation
maintenance of Certification Documentation
30
2.8 Summary
The following summarizes the main activities in the risk management life cycle, and
the location of guidance in supporting documents.
Table VIII Risk Management Documentation Streams
Guide to Risk
Assessment and
Safeguard Selection
Accreditation
Documents
Plan for Change
High level TRA

Preliminary Certification Plan
Review of Memorandums of
Understanding

Program Options
Concept of Change
Project Plan
CMP
MOUs
System
Requirements
Definition
Preliminary SoS
Initial TRA
Functional Security
Requirements

Validation of Functional
Security Requirements
Final Certification Plan

System Specific Security
Policy
Architecture
Design
Refined SoS
Refined TRA
Safeguard Selection
Safeguard Validation &
Verification
Validation of Technical and
Operational Security Policies
ST&E Strategy
Requirement Waivers (if
required)

Design Options
Technical and Operational
Security Policies
Optimal Design Option
Refined CMP
Detailed Design
Final SoS
Refined TRA
Safeguard Selection
Preliminary Secure
Operating Procedures

ST&E Plan
Safeguard Validation &
Verification
Requirement Waivers (if
required)

Detailed Design
System
Implementation
Updated TRA (residual
risk)
Final Secure Operating
procedures
Secure Disposal Plan

Certification Report
Validation Results
Verification of
Safeguards
ST&E Results
TRA report
Operational/Interim Approval

Implementation schedule
System Operation
Updated TRA (residual
risk)
Updated Secure Disposal
Plan

Maintenance of Certification
Documentation

CCB
Configuration Management
Audit
System Change Request
31
ANNEX A STATEMENT OF SENSITIVITY
This annex is included as a guide for the preparation of a SoS. It is intended for
both existing and new systems. However, for new systems some of the answers
will necessarily be for the system as foreseen, and some may be unanswerable
(e.g.: choice of hardware, security features in place) on the first few passes through
what is an iterative process.
1 Introduction
The sensitivity of IT systems and the information processed by, or stored on them,
needs to be defined and documented in a SoS. The SoS contains descriptions of
confidentiality, integrity and availability asset sensitivity, and an indication of the harm
that would result if the asset was compromised. It also provides, through the
availability assessment, minimum requirements for business resumption planning.
The SoS provides direction for developing a framework for system operation and for
implementing specific system safeguards.
The creation of a SoS consists of the following steps:
1. identify IT assets (including information);
2. assess confidentiality sensitivity;
3. assess integrity sensitivity;
4. assess availability senstivity; and
5. document the findings.
2 Identifying Assets
Assets can be grouped into the following categories:
1. Information;
2. Services;
3. Software;
4. Equipment;
5. Utilities; and
6. Key personnel.
Not all assets can be described in terms of confidentiality, integrity and availability
requirements. For example, the "key person" database administrator need only be
described in terms of their availability requirements. The following table shows the
relationship between the confidentiality, integrity and availability sensitivity and the
types of assets.
Table IX Relationship Between C/I/A and Assets
32
CATEGORY EXAMPLES C I A
Data / Information Data elements, data entities, data facets X X X
Essential Services Cheque issue, employee compensation services, real
property management, central accounting
X X X
Software Proprietary and commercial programs, software tools,
operating systems, database systems
*
3
X X
Equipment Computer hardware, air conditioners, uninterruptable
power supplies
*
3
X X
Utilities Hydro, water, telephone X
Key Personnel Database administrators, LAN administrators, support
personnel
X
3 Assessing Confidentiality
Information processed by, or stored on, IT systems is subject to the same
classification and designation guidelines as is non-IT information. Document the
classification or designation of each asset in the asset inventory and, where
possible, describe the harm that would result from disclosure.
When defining confidentiality sensitivity for an IT system, it is necessary to look at all
the data associated with the system. For instance, a database contains different
types of information, such as application (elements, entities, facets), security
(userIDs, passwords, access permissions), and the database structures (data
dictionaries). Information may also vary in nature and may relate to finance, pay &
benefits, purchasing, etc.
Although individual data elements may not be sensitive, aggregate information may
be more sensitive and could therefore be exempt under the Access to Information
Act or the Privacy Act. It is thus necessary to consider the various relationships
between data elements within the system because aggregate forms of the data may
be more sensitive than individual components. A good example would be a NAME +
DATA OF BIRTH + SIN.
4 Integrity
Integrity is stated in terms of harm that would result if the asset was not accurate,
complete and/or valid. Sensitivity needs to be defined for the data and information,
software and essential services.
Sensitivity can be defined by:

3
Description of confidentiality requirements may be appropriate for certain types of hardware or software components, for
instance encryptors or proprietary software algorithms.
33
1) Determining the types of information, software and services within the
IT system
2) Determining the processing life-cycle and the various information
states: input, storage, processing, communication, transmission, etc.
3) Analyzing each type of information separately and determining the
consequences that would result if the information was not accurate,
complete and/or valid. Special attention should be paid to specific
phases in the information processing life-cycle when integrity
sensitivity may be higher.
5 Availability
IT systems are, for the most part, developed to support essential services and
mission critical functions. It is therefore crucial that information processed by, or
stored on these systems, be available when it is needed.
Availability sensitivity is dependent on a variety of factors, and is defined by:
1) Determining the nature of the service/business functions performed.
2) Determining the criticality of the service/business function which could be
expressed as:
a) High for systems providing services to the Government of Canada
and the Canadian public;
b) Medium for systems providing critical services to the department; and
c) Low for systems providing other non-critical services.
3) Determining, based on 1 and 2 above, the maximum permissible
downtime or: how long the system can be unavailable before the
consequences begin to adversely affect the service delivery or business
operation (expressed in hours or days).
4) Determining the system cycle(s) (daily, weekly, monthly, yearly). This will
help in identifying critical periods where availability may differ.
5) Determining the harm that may result if the system is down longer than the
maximum permissible downtime.
34
GLOSSARY
Sources: Each definition is followed by a corresponding reference from which it was
obtained.
CTCPEC Canadian Trusted Computer Product Evaluation Criteria,
Version 3.0e, January 1993
GSP Government of Canada Security Policy, June 1994
MBW2 Proceedings, Second Risk Management Model Builders
Workshop, Ottawa, June 1989
NEW New definition
TSEG Trusted Systems Environment Guideline, December 1992
Accreditation Formal declaration by the responsible management
approving the operation of an automated system in a
particular security mode using a particular set of safeguards.
Accreditation is the official authorization by management for
the operation of the system, and acceptance by that
management of the associated residual risks. Accreditation
is based on the certification process as well as other
management considerations. (TSEG)
Asset An asset is a component or part of the total system to which
the department directly assigns a value to represent the
level of importance to the "business" or
operations/operational mission of the department, and
therefore warrants an appropriate level of protection. Assets
types include: information, hardware, communications
equipment, firmware, documents/publications,
environmental equipment, people/staff, infrastructure,
goodwill, money, income, organizational integrity, customer
confidence, and organizational image. (EUROPEAN
COMMUNITY)
Assurance The degree of confidence that a product correctly
implements the security policy. (CTCPEC)
Availability The accessibility of systems, programs, services and
information when needed and without undue delay. (NEW)
Certification The comprehensive assessment of the technical and non-
technical security features of an IT system, made in support
of accreditation, that establishes the extent to which a
system satisfies a specified security policy. (CTCPEC)
35
Classified Assets An asset that is important to the national interest and
therefore warrants safeguarding. In terms of Risk
Management, classified information is also an asset that
may qualify for an exemption or exclusion under the Access
to Information Act or Privacy Act and the compromise of
which would cause injury to the national interest. (NEW)
Compromise Unauthorized disclosure, destruction, removal, modification
or interruption. (GSP)
Confidentiality The quality or condition of being sensitive to disclosure.
(GSP)
Designated Assets (1)Assets that have been identified by the institution as
being important to operations by virtue of the function
performed or as being valuable and therefore warranting
safeguarding; (2) Cash and other negotiables; (3) Computer
systems that require protection to ensure the integrity and
availability of the information stored therein, (4) Information
related to other than the national interest that may qualify for
an exemption or exclusion under the Access to Information
Act or Privacy Act. (NEW)
Evaluation The rating of an information technology security (ITS)
product, against an established national or international
criteria, by a lead agency. Both functionality and assurance
are rated. In Canada, evaluations are carried out by
CSE/Canadian System Security Centre (CSSC) against the
CTCPEC. Evaluations by the National Computer Security
Centre (NCSC) in the U.S. against the Trusted Computer
System Evaluation Criteria(TCSEC) are often used in
Canadian specifications. The results of an evaluation are
used as input to the certification process. Products which
have been successfully evaluated are variously referred to
as "rated", "trusted" and as "Trusted Computing Bases"
(TCBs). (TSEG)
Harm (Impact) An expression of the degree and kind of damage, or other
change, caused by a consequence. (MBW2)*
Integrity The quality or condition of being accurate or complete.
(GSP)
Means The mechanism or medium that is used (by a threat agent,
or by the circumstances of an event) in the occurrence of a
threat event. (MBW2)
Motive Something that induces a threat agent to act against a
system. (NEW)
36
Residual Risk The risk that remains after safeguards have been selected
and implemented. (TSEG)
Risk A measure indicating the likelihood and consequence of
events or acts that could cause a compromise of system
asset(s). (NEW)
Risk Assessment An evaluation of risk based on the effectiveness of existing
security safeguards, the likelihood of system vulnerabilities
being exploited and the consequences of the associated
compromise to system assets. (NEW)
Risk Management The process by which resources are planned, organized,
directed, and controlled to ensure the risk of operating a
system remains within acceptable bounds at optimal cost.
(NEW)
Safeguard(s) An approved minimum security measure(s) which, when
correctly employed, will prevent or reduce the risk of
exploitation of specific vulnerability(s) which would
compromise an IT system. (NEW)
Security Evaluation The process of determining whether a system contains
vulnerabilities that could be exploited. (NEW)
Security Testing The process of determining whether technical safeguards are
functioning correctly. (NEW)
Security Validation The process of determining whether the system security
features implement the organizational and system specific
security policy. (NEW)
Security Verification The process of determining whether technical and non-
technical safeguards are implemented correctly and meet
assurance requirements. (NEW)
Statement of Sensitivity A profile of an existing or proposed system, documenting
characteristics of the data (to be) processed, the (proposed)
user community, and the requirements to address
confidentiality, integrity and availability concerns. A
Statement of Sensitivity is used as an input to the risk
analysis. (TSEG)
Threat Assessment An evaluation of threat agent capability and motivation to
carry out threat events that could place sensitive information
and assets at risk. (NEW)
Threat Event An event or occurrence that has the potential to compromise
the security of an asset or information. (MBW2)*
37
Value (attribute of asset) A measure or statement of the utility of an asset or
information, or ( alternatively ) the cost if it is compromised.
Value can be stated in quantitative or qualitative terms.
Utility and cost are contextually dependent, based on the
needs and situation of the organization. Value is therefore
not necessarily an objective term. (MBW2)
Vulnerability (1) An inadequacy related to security that could permit a
threat agent to cause harm, (2) an inherent weakness in IT
that makes it particularly susceptible to compromise;
(GSP)**
* Minor rewording for compatibility with GSP
** Minor change in wording
38
BIBLIOGRAPHY
1) Communications Security Establishment, A Guide to Certification and
Accreditation of Information Technology Systems, 1996, 40 pages.
2) Communications Security Establishment, A Guide to Risk Assessment and
Safeguard Selection for Information Technology Systems, 1996, 65 pages.
3) Communications Security Establishment, Trusted System Environmental
Guideline (TSEG), 1992, 34 pages.
4) Treasury Board Manual, Information and Administrative Management
Component, Material, Risk and Common Services, 1994, Chapter 2-1 (Risk).
5) Treasury Board Manual, Information and Administrative Management
Component, Security, 1994.

Guide To Security Risk Management For Information Technology Systems

Uploaded by

Document Information

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

Guide To Security Risk Management For Information Technology Systems

Uploaded by

Copyright:

Available Formats

i

You might also like