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 aninterdepartmental Risk Management Working Group. Many thanks is extended tothe participating departments who offered their valuable time and expertise tomake this guide a reality.

Points of Contact

Comments, suggestions and inquiries on Security Risk Management forInformation Technology Systems should be directed to the Standards andInitiatives Unit, Risk Management Coordinator, tel. (613) 991-7446, Fax (613) 991-7411, Internet address: [email protected]. For additional copiesof the document, please contact the ITS Publications Section at (613) 991-7514/7468 or CSE’s 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, foreducational and personal purposes only. However, written permission from CSE isrequired for use of the material in edited or excerpted form, or for any commercialpurpose.

ii

FOREWORD

The aim of this guide is expand on the standards set out in the GovernmentSecurity Policy (GSP) and thus provide specific guidance for risk managementwithin an IT system environment and its life cycle.

Coincident with this effort, CSE funded a project to develop a guide for riskassessment and safeguard selection as well as a guide for the certification andaccreditation process of an IT system throughout its life cycle. Once the threedocuments had sufficiently matured, they were harmonized to present onecohesive message for risk management throughout an IT system life cycle.

Users are encouraged to apply this guide and its two companion documents, AGuide to Risk Assessment and Safeguard Selection and A Guide to Certificationand Accreditation in their environment. To this end, CSE invites all users tocomment on these documents, suggest any ways we can improve the guidelinesand any suggestions for further study such as a methodology for risk managementfor IT systems.

Furthermore, users are encouraged to use theses guides in concert with theRCMP, Information Technology Security Branch document, A Guide to Threat andRisk 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 ...............................................................31.2.1 Planning..................................................................................................41.2.2 Threat and Risk Assessment (TRA) .......................................................5

1.2.2.1 TRA Preparation........................................................................51.2.2.2 TRA Analysis .............................................................................61.2.2.3 TRA Recommendations ............................................................6

1.2.3 Decision to Reduce, Avoid, Transfer or Accept Risk ..............................61.2.4 Requirements Definition .........................................................................61.2.5 Safeguard Selection ...............................................................................61.2.6 Construction and Implementation...........................................................71.2.7 Certification.............................................................................................71.2.8 Decision for Accreditation.......................................................................71.2.9 Accreditation...........................................................................................71.2.10 Operations and Maintenance ...............................................................71.2.11 Decision for Proposed Changes...........................................................8

1.3 A Model of Risk Management in the System Life Cycle..................................81.3.1 Risk Management throughout the System Life Cycle.............................8

2. RISK MANAGEMENT PROCESS GUIDANCE ..................................................10

2.1 System Life Cycle Overview..........................................................................102.1.1 System Life Cycle Stages.....................................................................102.1.2 Risk Management Process Iteration.....................................................11

2.2 Planning for Change .....................................................................................122.2.1 Prepare.................................................................................................12

iv

2.2.1.1 Aim, Scope and Resources.....................................................122.2.2 Assess..................................................................................................13

2.2.2.1 Analyzing and Assessing Program Options.............................132.2.2.2 Preliminary Certification Plan ..................................................13

2.2.3 Decide ..................................................................................................142.2.3.1 Decisions.................................................................................142.2.3.2 Documents ..............................................................................14

2.2.4 Planning for Change Summary ............................................................15

2.3 System Requirements Definition...................................................................152.3.1 Prepare.................................................................................................15

2.3.1.1 Aim, Scope and Resources.....................................................152.3.1.2 IT System Description .............................................................152.3.1.3 Preliminary Statement of Sensitivity (SoS)..............................16

2.3.2 Assess..................................................................................................162.3.2.1 System Specific Security Policy ..............................................162.3.2.2 Initial Threat and Risk Assessment .........................................162.3.2.3 Functional Security Requirements...........................................17

2.3.3 Decide ..................................................................................................172.3.3.1 Final Certification Plan.............................................................172.3.3.2 Validation of Security Requirements .......................................172.3.3.3 System Design Review............................................................18

2.3.4 System Requirements Definition Summary..........................................18

2.4 Architecture Design.......................................................................................182.4.1 Prepare.................................................................................................18

2.4.1.1 Aim, Scope and Resources.....................................................182.4.1.2 Development of System Options .............................................19

2.4.2 Assess..................................................................................................192.4.2.1 Threat and Risk Assessment (TRA) of System Options..........192.4.2.2 Technical and Operational Security Policies ...........................192.4.2.3 Configuration Management Plan (CMP)..................................192.4.2.4 Refined Statement of Sensitivity (SoS) ...................................192.4.2.5 Security Testing and Evaluation (ST&E) Strategy ...................202.4.2.6 Security Validation and Verification .........................................20

2.4.3 Decide ..................................................................................................202.4.3.1 Architecture Review.................................................................202.4.3.2 Requirements Review .............................................................20

2.4.4 Architecture Design Summary..............................................................21

2.5 Detailed Design.............................................................................................212.5.1 Prepare.................................................................................................22

2.5.1.1 Aim, Scope and Resources.....................................................222.5.1.2 Development of Detailed Design .............................................22

2.5.2 Assess..................................................................................................222.5.2.1 Threat and Risk Assessment (TRA) of Detailed Design..........222.5.2.2 Preliminary Security Operating Procedures.............................222.5.2.3 Final Statement of Sensitivity (SoS) ........................................232.5.2.4 Final Configuration Management Plan (CMP).........................232.5.2.5 Security Testing and Evaluation (ST&E) Plan .........................23

v

2.5.2.6 Security Validation and Verification .........................................232.5.3 Decide ..................................................................................................23

2.5.3.1 Detailed Design Review ..........................................................232.5.3.2 Requirements Review .............................................................23

2.5.4 Detailed Design Summary....................................................................24

2.6 System Implementation.................................................................................242.6.1 Prepare.................................................................................................25

2.6.1.1 Aim, Scope and Resources.....................................................252.6.1.2 System Implementation Schedule ...........................................25

2.6.2 Assess..................................................................................................252.6.2.1 Security Operations Plan.........................................................252.6.2.2 Disposal Plan ..........................................................................252.6.2.3 Assessment of Residual Risk ..................................................26

2.6.3 Decide ..................................................................................................262.6.3.1 Accreditation Decisions ...........................................................26

2.6.4 System Implementation Summary........................................................27

2.7 System Operation .........................................................................................272.7.1 Prepare.................................................................................................27

2.7.1.1 Aim, Scope and Resources.....................................................272.7.2 Assess..................................................................................................28

2.7.2.1 Configuration Management .....................................................282.7.2.2 Periodic Risk Assessment .......................................................282.7.2.3 Update Disposal Plan..............................................................28

2.7.3 Decide ..................................................................................................282.7.3.1 Operational Security Audit.......................................................282.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 .............................................................................12Table II – Planning for Change Summary............................................................15Table III – System Requirements Definition Summary .........................................18Table IV – Architecture Design Summary .............................................................21Table V – Detailed Design Summary ...................................................................24Table VI – System Implementation Summary.......................................................27Table VII – System Operation Summary................................................................29Table VIII – Risk Management Documentation Streams........................................30Table IX – Relationship Between C/I/A and Assets................................................31

LIST OF FIGURES

Figure 1 – Relationship between Guidance Documents...........................................2Figure 2 – Risk Management Model .........................................................................5Figure 3 – Risk Management throughout the System Life Cycle ..............................9Figure 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 managementfor information technology (IT) systems.

Scope

The document provides guidance for the management of security risks throughoutthe life cycle of IT systems.

Audience

The document is intended for use by a wide range of personnel, includingmanagers of programs, systems, and projects; security officials; planners; andengineers.

Document Structure

The document has two main parts. The first describes a general framework forsecurity risk management, including a model process. The second providesdetailed guidance for implementation of the framework.

Supporting Documentation

The guidance provided in this document is in the context of risk managementduring the life cycle of a IT system. A Guide to Risk Assessment and SafeguardSelection provides additional guidance for system designers on the technicalfactors associated with performing risk assessments and selecting appropriatesafeguards. A Guide to Certification and Accreditation provides additionalguidance on the types of certification documentation required to accredit the ITsystem. 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) beresponsible for developing, implementing, maintaining, coordinating andmonitoring a departmental security program consistent with the security policyand standards. Security risk management is an integral part of thedepartmental security program.

2

• Information Technology Security (ITS) Coordinator

The GSP requires that an ITS Coordinator be appointed and that this positionshould have at least a functional relationship to the DSO. The ITS Coordinatorassists the DSO with IT security matters, including being the focal point for ITsecurity 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 approvingand accepting the residual risk from a security point of view. If multiple AA’sare permitted, care must be taken to ensure consistency of accreditationsacross the department.

Guide to Security Risk Management

Guide toRisk Assessment &Safeguard Selection

Guide toCertification &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 byconfirming the appropriateness of minimum standards and supplementing thesestandards where necessary, and eliminating unnecessary expenditures andadministrative barriers. Managing security risks means defining what is at risk, therelative 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 whichincludes operational, procedural, physical, personnel, and technical securitycomponents.

Risk management involves planning, organizing, directing and controlling resourcesto ensure that risk remains within acceptable bounds, and that the cost is affordable.It is also a collaborative process where representatives of various interest groupsdevelop a shared understanding of requirements and options. Increased awarenesswill strengthen security and make it more compatible with user needs.

Risk management for IT systems presents some particular difficulties arising from thedynamic nature of risk factors and rapid evolution of technology. Failure to considersecurity risk factors in an adequate and timely fashion may result in ineffective andunnecessarily costly security measures. Therefore, security risk management mustbe 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 riskmanagement 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 andvulnerabilities);

d) describing the system; and

e) establishing a target risk (generally the target risk is the minimumacceptable risk).

The IT system description should include a thorough description of the systemrequirement (or system mission), a concept of operation, and an identification ofthe nature of the system assets.

5

Threat and Risk Assessment

AccreditationOperations andMaintenance

Planning

- Aim- Scope- Boundary- Gathering Information- System Description -Target risk & required certainty

RequirementsDefinition

Safeguard Selection

- administrative- personnel- physical- technical

Constructionand

Implementation

Certification

Decision

Decision

Decision

Reducerisk

Acceptrisk

Avoid or Transfer risk

ChangeRequired

Significant

insignificant

TRA AnalysisThreat Analysis:- Identify threats- Assess likelihood of a compromise- Assess consequence of a compromiseRisk Analysis:- Identify vulnerabilities- Identify safeguards- Assess Risk (quantitative and/or qualitative)

TRAPreparation

- Identify assets- Statement of Sensitivity

TRARecommendations

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 andthe allowable uncertainty in the assessment of residual risk. This step is fundamentalin 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 theseassets can be compromised by threat agents, to assess the level of risk that thethreat 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 assets1 are identified and a Statement ofSensitivity (SoS) is completed. The SoS documents the system assets, theirconfidentiality, integrity and availability requirements, and their replacement value.The SoS captures the importance of the IT system to the business function which itsupports, 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, organizationalintegrity, customer confidence, and organizational image.

6

1.2.2.2 TRA Analysis

In the TRA analysis, vulnerabilities and existing safeguards are identified andexamined to determine how an asset can be compromised by a threat agent. Thelevel of risk to the asset is a measure of the likelihood of the compromise and theconsequences of the compromise where the consequences are a function of theasset’s sensitivity.

1.2.2.3 TRA Recommendations

An assessment of the adequacy of existing or proposed safeguards which protectsystem assets forms part of the TRA process. Where the assessment ofsafeguards indicates that certain vulnerabilities are not appropriately offset,appropriate additional safeguards would be recommended in order to reduce therisk to an acceptable level. Conversely, if safeguards are no longer appropriate,their removal would be recommended. If additional safeguards can not reduce therisk to an acceptable level for an acceptable cost, the risk may be avoided ortransferred by moving the location of the system, or removing the asset that is atrisk.

1.2.3 Decision to Reduce, Avoid, Transfer or Accept Risk

The TRA process provides the system manager with an appreciation of the securitystatus of the system. The TRA recommendations will either suggest possiblechanges to the system design or suggest the acceptance of the risk. Each optionwill have an associated cost: that is; risk, time, money, people, and equipment.Management must choose the most appropriate option based on the likelihood ofthe 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 bedefined in terms of the security functionality required to reduce the risk. It should bepossible for the functionality requirement to be satisfied by more than onesafeguard or set of safeguards.

1.2.5 Safeguard Selection

Technical and/or non-technical safeguards must be selected to meet the functionalsecurity requirements and to adequately mitigate the identified risks. Non-technicalsafeguards include the establishment of the administrative security structure,personnel and physical security measures, and the establishment anddocumentation of security procedures and practices. The cost of safeguards, interms of expense, system performance, user acceptance, schedules and otherpotential impacts, must be balanced against the resulting reduction of risk. Tosupport this type of cost benefit analysis, safeguards must be specified in parallelwith design of the system.

7

1.2.6 Construction and Implementation

Once the system security requirements have been identified, and safeguards havebeen selected, the IT system can be constructed and implemented. Securityacceptance procedures ensure that the risk of operating the system, as it has beenimplemented, is acceptable. These procedures are usually referred to ascertification and accreditation.

1.2.7 Certification

Certification is a comprehensive assessment of the technical and non-technicalsecurity features of an IT system that establishes the extent to which the systemsatisfies the specified security requirements. It should include:

a) validation that security safeguards meet the security requirements andthe security policy;

b) testing of security safeguards;

c) evaluation of technical security measures in terms of functionality andassurance;

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 andcompliance to requirements. If the design is not complete or if the certificationdocumentation indicates that not all requirements are adequately met by thedesign, the risk management process returns to the preparation step in order toadjust the system design. If the certification documentation is complete and allrequirements 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 anautomated system is approved to process information up to a maximum sensitivitylevel, under specified controls and operating procedures. It signifies the officialacceptance 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 toensure that the integrity of the secure system architecture is maintained. This isaccomplished through ongoing risk management activities, including configurationmanagement, security monitoring, audits, and risk reviews.

8

Prior to becoming operational, plans and procedures are required to address therisks inherent in the handling and the disposal of sensitive information and assetsproduced by, or associated with the system. Ultimately, this also includes disposal ofthe 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 toaddress system risks.

1.2.11 Decision for Proposed Changes

Over the operational lifetime of the system, system design changes will be requiredto accommodate departmental growth, equipment upgrades, changes in assetsensitivity, changes in assessed risk, and changes in the business function of thesystem. If the changes do not pose a significant risk, the changes can be madewithout having to re-enter the risk management process. If the risk is significant,the risk management process should be re-entered to ensure that appropriatesafeguards 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 isapplicable to all life cycle methodologies. The level of detail applied is dependenton factors such as the size and complexity of the system, the level of assurancethat is required and the availability of resources, including time, money andexpertise.

1.3.1 Risk Management throughout the System Life Cycle

The risk management process in the previous section can be incorporated into thelife cycle of an IT system. When risk management activities are applied throughouta system’s life cycle, security is built into the system that continues to be relevant toevolving conditions and requirements.

Figure 3 shows a series of concentric rings depicting the different stages in asystem’s life cycle; from planning through to the operational stages. When asignificant change is proposed, the system life cycle moves to the central planningstage. 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 riskmanagement activities within the stage, determining the requisite inputs andexpected outputs, and gathering any relevant information needed to conductassessments and make decisions.

Assessment within each life cycle stage involves analyzing options, assessing threatsand risks, assessing the appropriateness of safeguards, and assessing the adequacyof system documentation to ensure that security requirements are identified and

9

addressed. Assessment criteria are set to fit the scope of the assessment. Suchcriteria could include feasibility, functionality, consistency and adequacy.

Decisions must be made at each life cycle stage. The primary decision is whether toproceed to the next stage. If more than one design option is available, the most costeffective and efficient solution for a secure system must be chosen. Also, TRArecommendations for a design option must be considered to determine whichrecommendations 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 areassessed, 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 levelis established.

3) architecture design: secure system options are identified, and a preferredoption is selected based on an assessment of residual risk.

4) detailed design: design specifications are developed, and specific safeguardsare selected.

5) implementation: the IT system is developed, implemented, installed andtested.

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 cyclemethod.

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 requirementsdefinition, safeguard selection, construction and implementation, and certificationsteps are undertaken during the stages of Architecture Design, Detailed Design, andSystem 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 Threat and Risk Assessment

System Requirements Definition Planning Threat and Risk Assessment Requirements Definition

Architecture Design Planning Threat and Risk Assessment Requirements Definition Safeguard Selection Construction and Implementation Certifications

Detailed Design Planning Threat and Risk Assessment Requirements Definition Safeguard Selection Construction and Implementation Certifications

System Implementation Planning Threat and Risk Assessment Requirements Definition Safeguard Selection Construction and Implementation Certifications Accreditation

System Operation Planning Threat and Risk Assessment Operations and Maintenance

2.2 Planning for Change

During this stage of the life cycle, the principal objectives of planning for change areto:

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 bestmeets program requirements at an acceptable level of risk.

13

The preparation activities:

a) define stakeholders2, assign roles and responsibilities, and establishlines of communication (that is, identify departments/organizationsaffected by any changes, and draft memorandums of understanding thatdescribe roles and responsibilities and have the support of the defineddepartments/organizations);

b) state the system mission (that is, why is the system required and whatwill it do?);

c) describe the system (that is, state where the system is to be located andthe sensitivity of known assets);

d) describe the reason for change (that is, why is the program of changerequired?);

e) state the options for mission achievement (that is, options may includeincremental change, minor or major change, or maintaining the statusquo);

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, theseshould be reviewed from the perspective of risk to the business function andinstitutional objectives. A high-level assessment of risk to the known assets shouldbe made to determine whether the technology required to protect the assets isavailable, or is likely to be available during the implementation of the system. Thisanalysis supports the assessment of overall program risk management outlined inchapter 2-1 (Risk Management Policy) of the Treasury Board Manual forInformation and Administrative Management Component, Material, Risk andCommon Services.

2.2.2.2 Preliminary Certification Plan

Based on the type of technology to be used in the program option and the level ofrequired risk reduction, a preliminary certification plan should be drafted inconjunction with the overall project plan. The certification plan should indicate thetypes of certification activities required, the points in the life cycle that the activitiesshould be performed, and the level of effort required to perform them.

2 System stakeholders includes security, management, operations and administrative representatives from the affecteddepartments/organizations.

14

2.2.3 Decide

2.2.3.1 Decisions

Based on the security risk assessment, in conjunction with the program riskassessment, a decision is made. If the decision is positive, the life cycle willprogress to the system requirements definition stage.

2.2.3.2 Documents

1) The concept of change describes program options from an organizationalperspective, and documents:

a) the requirement for change (for example, a statement of deficiencyincluding 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 beincorporated 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 pointsin 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 shouldinclude member(s) with IT system security experience);

b) project team member roles and responsibilities (security team membersshould 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 withthe 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 othergovernment departments, private firms, or foreign governments, defining rolesand 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 changestage, and the supporting guidance documents.

Table II – Planning for Change Summary

Risk Management Life CycleDocuments

− develop Program Options− produce Concept of Change− produce Project Plan− produce CMP− draft MOUs (Memorandums of Understanding)

Guide to Risk Assessment andSafeguard Selection

− perform high level TRA

Guide to Certification andAccreditation

− 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 securityrequirements;

c) develop and baseline the functional, operational and securityrequirements for the system; and

d) develop a preliminary certification plan, in particular a security test andevaluation (ST&E) strategy which will ensure that the required level ofassurance in the system’s technical safeguards is achieved.

2.3.1 Prepare


At this point in the development life cycle, analysis is conducted at the functionallevel. While detailed technical analysis is not usually required, an understanding ofthe proposed system’s vulnerabilities is required. Technical resources, includingrisk analysts, system and security engineers, and security evaluators, may need tobe 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 berequired:

16

1) Operational Requirement: A statement of the operational requirementwhich the system must support, including business objectives, operationalrole, functions and performance requirements.

2) Concept of Operation: An overview of how the system will be used tosupport the operational requirement, including descriptions of informationhandled, types of applications or processing, users, and basic systemconfiguration.

3) Location: The physical location of the system and the surroundinggeographical area is not to be overlooked. The location influences theavailability and effectiveness of system safeguards. It may also imposeconstraints which influence the system.

4) Anticipated modification or expansion: Any future plans for modification orexpansion should also be well documented, as this may have an effect on thedesign of the system, in particular on the choice of system safeguards. Futuremodifications to the system may compromise the effectiveness of existingsafeguards, if these safeguards are not chosen properly.

In cases where an existing system is being reviewed, the IT System Descriptiondocument 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 maynot be possible to complete a full SoS at this time, since complete systemspecifications and design are usually required to identify sensitive supportingassets. However, it should be possible to provide details on the sensitivity of theinformation 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 departmentalsecurity policies and standards, and describes the security services to be provided bythe system.

2.3.2.2 Initial Threat and Risk Assessment

Based on the IT System Description and the preliminary SoS, an initial risk analysiscan now be undertaken to identify and rate key risk factors that will influence thedevelopment of the system specific security requirements. Key risk factors will bedriven by the sensitivity of the system’s assets, the system’s environment andvulnerabilities, and will identify the threat scenarios which contribute to the risk.Analyzing the impacts of various threat scenarios is a useful means of identifying keyrisk factors.

17

Having identified the risk factors, an acceptable residual risk can be established. Thistarget 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 securityrequirements are high level statements of countermeasures that will mitigate therisk factors, and do not require fine detail. They will be translated into specificsecurity requirements during the later stages of the risk management process.

Functional security requirements should, as a minimum, satisfy applicable securitypolicies and standards which govern the system. The initial risk assessment will helpensure that applicable standards are applied in a cost-effective manner. Systemconstraints and operational requirements are always a major factor in the definition ofthe security requirements, since these will introduce limitations and trade-offs whichmust be considered.

System specific functional security requirements should be subjected to a quality testto ensure that they are consistent, complete, appropriate, implementable andverifiable. Assistance in identifying appropriate security requirements is availablefrom 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 certificationactivities are identified and will be performed at specified times within the systemlife cycle.

2.3.3.2 Validation of Security Requirements

As part of the certification process, the security requirements are mapped to thesystem specific security policy and to the department/organization’s security policy.The level of effort required for the validation of the security requirements isdetermined 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 andthe proposed system security requirements are examined to determine whetherthey appear to be feasible. The system and functional security requirements mustsatisfy applicable security policy and standards. The program manager shouldverify that the proposed functional, operational and security requirements andtarget risk level are acceptable. If no problems are encountered, the processprogresses to the architecture design stage.

2.3.4 System Requirements Definition Summary

The following table highlights the life cycle activities for the system requirementsdefinition stage, and the supporting guidance documents.

Table III – System Requirements Definition Summary


− produce System Specific Security Policy


− draft Preliminary SoS− perform initial TRA− produce Functional Security Requirements


− 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 significantlydifferent architectures. In the case of simpler systems, this step may involveexamining one or two minor design alternatives.

2.4.1 Prepare


At this point, risk assessment activities consider specific safeguards, and include agreater level of technical detail. System options are identified and analyzed. Similarexpertise 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 thefunctional, operational and security requirements. These system architectureoptions need only be at a high level, and should include general information onsystem configuration and system assets.

The System Options describe the basic system configuration, generic types ofsystem components which are likely to be used, performance requirements forsystem components, as well as system and environmental constraints. From thesecurity requirements and the concept of operations, a high-level set of technicalsecurity safeguards with proposed levels of assurance should be developed for eachsystem option. In addition, organizational, operational, physical (includingenvironmental), procedural and personnel security safeguards should be identifiedand documented. Documentation tracing a safeguard to a security requirementshould 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 todetermine its overall feasibility and effectiveness. The TRA should involve aprojection of characteristic vulnerabilities of each architecture, development ofthreat scenarios, a review of proposed safeguards, estimates of the impact andlikelihood associated with each threat scenario, and a measure of the residual risk.Additional safeguards may be recommended depending on the outcome of theTRA.

2.4.2.2 Technical and Operational Security Policies

The TRA will have uncovered the areas of highest risk, and this information willhelp in developing a specific set of security rules to be enforced by the system (thetechnical security policy) and by the operations environment (the operationalsecurity policy). These technical and operational security policies are a refinementof the system specific policy, and should dictate how the technical and operationalattributes of the system design architecture are to be configured. If these policiesdo not reduce the level of risk to an acceptable level, the system options in Section2.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. Thesame 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 securitypolicies 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 bythe project authority.

2.4.2.5 Security Testing and Evaluation (ST&E) Strategy

A strategies for testing and evaluating implemented technical safeguards should bedeveloped to ensure that the required certification documentation is available whenthe final design is implemented. The strategy should outline a process to:

a) establish whether the technical safeguards have the required securityfunctionality;

b) establish whether the technical safeguards have any additionalfunctionality 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 beimplemented later in the life cycle. The proposed strategy should be reviewed foradequacy and completeness.

2.4.2.6 Security Validation and Verification

The selected safeguards in the architecture design should be validated by mappingthem to the technical and operational security policies and the security policymodel from the previous life cycle stage. Also, the selected safeguards should bereviewed 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, inorder to decide on the optimal system option to take into the detailed design, or todetermine 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 theproject 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 securityrequirement cannot be met by the system. The impact and risk of not meeting therequirement should be outlined and brought to the attention of the AccreditationAuthority (AA). A formal or conditional waiver of the requirement may be given bythe 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 designstage, and the supporting guidance documents.

Table IV – Architecture Design Summary


− develop Design Options− develop Technical and Operational Security Policies− select Optimal Design Option− refine CMP


− refine SoS− refine TRA− select Safeguards


− 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 hasbeen selected, and results in a complete system specification, suitable forimplementation. The objectives of the detailed design stage are to:

a) develop detailed technical and security specifications for the optimaloption;

b) assess the vulnerabilities and risks associated with the detailed design;

c) develop security operating procedures which support the technicalsecurity mechanisms; and

d) develop detailed security test plans to validate the technical securitymechanisms.

22

2.5.1 Prepare


This stage encompasses the most detailed level of analysis TRAs should considerspecific technical vulnerabilities and threat agent capabilities. Additional technicalexpertise and access to specialized threat and vulnerability information may berequired.

2.5.1.2 Development of Detailed Design

Once the architecture design review process has been completed, the high levelarchitecture and safeguards baselined in the preliminary design should be expandedto a detailed design.

a) A complete listing and description of all system components, includinghardware, 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 beinterconnected, including information on networking protocols andsecurity mechanisms;

d) A profile of system users, together with their respective securityclearances, roles and privileges;

e) A detailed description of all technical safeguards, in support of thetechnical security policy;

f) A detailed description of the system’s expected physical environment;

g) A description of the organizational/administrative, operational, physical(including environmental), procedural and personnel securitysafeguards; and

h) Specifications for construction of computer rooms (IT systemenvironment).

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 thesystem. These procedures should include comprehensive contingency plans, inorder 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 fulldetail. The assets should have been completely identified by this point, and theconfidentiality, integrity and availability requirements reviewed during the detailedTRA. The completed SoS should be reviewed and signed off by the projectauthority.

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 andimplementing any proposed changes to the system over time; and

b) complete detail on the documentation that should be provided to thesystem 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 scenariosidentified in the risk assessment. The ST&E plan should include functional,penetration and composable system tests, as well as an estimate for the time andresources required to perform the activities, and a schedule which coincides withthe system implementation plan. It must also provide for the documentation of thetest results. If the system is to incorporate a vendor security product, the securitytesting 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 thedetailed design should be validated by mapping them to the technical andoperational security policies. Also, the selected safeguards should be reviewed toverify 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 thefeasibility of the detailed design and other deliverables, and the direction to betaken in correcting any difficulties.

If it has been determined that the detailed design and other deliverables are feasiblefrom both a technical security and operational point of view, and require no furthermodification, 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 securityrequirement 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 orconditional waiver of the requirement may be given by the AA if the associated riskis 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


− develop Detailed Design


− refine SoS− refine TRA− select Safeguards

• develop Secure Operating Procedures


− 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 supportingmechanisms and procedures in place. From the system perspective, acceptancetesting and evaluation ensures that the functionality which was contracted in thedetailed design phase meets the specification. From the security perspective, thesystem is certified to ensure that the security requirements that were specified inthe detailed design stage are met. All aspects of security affecting the system, bothtechnical and non-technical, are verified and the residual risk is assessed.

The main objectives for the implementation stage of the risk management life cycleare:

a) verification of the technical and non-technical security measures;

b) determining any discrepancies with respect to the security specificationsand defining a manner in which the discrepancies can be resolved, toallow 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 determinetheir effect on the residual risk. Since the certification process tests for deficienciesin 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 certificationprocess, it is important to be cognizant of the delivery schedule. Since securitydeficiencies may limit the use of the system under test or delay acceptance of thesystem for operation, security concerns should be addressed as early as possibleduring 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, specialoperating procedures will need to be developed to allow operation. Suchprocedures should form part of the security operations plan, and be consistent withthe organization’s security policy.

2.6.2.2 Disposal Plan

Secure operation of a sensitive IT system also requires secure disposal of thesensitive byproducts of system operation. This will include sensitive:

a) hard copy;

b) electronic media; and

c) hardware (such as TEMPEST compliant equipment and controlledcryptographic items).

A disposal plan should be included in the secure operating procedures, and shouldaddress the secure storage and/or destruction of intermediate hard copy, removablemedia (including backups) and faulty hardware items. The disposal plan should alsocover 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 beensatisfied, a further TRA will be required to assess the effects of the deficiencies onthe residual risk. The results of the TRA will support the accreditation decisionsdiscussed in Section 2.6.3.1.

2.6.3 Decide

Once certification is complete, a certification report shall be prepared which willprovide the accreditation authority with enough information to make an informeddecision 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 operationalauthority (OA), or the accreditation authority has a further hand-over to theoperational authority. Whichever is the case, the organizational member accepts theresponsibility for operating the system in the manner specified in the accreditationnote and for managing the residual risk (that is, maintaining the secure operatingprocedures).

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 asprojected, grant approval to operate the system (operational approval);

b) If security flaws are minor and can be corrected by additionalorganizational and administrative, operational, physical (includingenvironmental), procedural and personnel security measures and if theresidual risk is within acceptable bounds, grant approval to operate thesystem (operational approval);

c) If serious security flaws exist but can be corrected within a reasonablelength of time, and if the residual risk can be brought within acceptablebounds in some manner such as reduced operation, grant an interimapproval allowing restrained operation until the system security flaws arecorrected; and

d) Return to one of the previous stages in the life cycle to refine orredesign the system so that it may be given approval to operate.

Operational and interim approvals are only valid for a specified systemconfiguration and for a specified time period. When the approval expires, thesystem must undergo a mandatory review to determine if the risk is beingmaintained at an acceptable level.

27

2.6.4 System Implementation Summary

The following table highlights the life cycle activities for the system implementationstage, and the supporting guidance documents:

Table VI – System Implementation Summary


− develop Implementation schedule


− updated TRA− develop final Secure Operating procedures− develop disposal plan


− 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 system’ssecurity posture, and operating staff who are aware of relevant security issues andable to implement the secure operating procedures.

The security objective which should be met during the operational stage of thesystem life cycle is to maintain the residual risk within acceptable limits. The followingactivities are of critical importance in meeting this objective:

a) Maintenance of configuration control over security-critical aspects of thesystem;

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 staffshould be trained in the secure operating procedures relating to their job function.A Configuration Control Board (CCB) should be established to review systemchange requests, and to ensure that security-critical aspects of the system are

28

properly managed. Specialized expertise may be periodically required to conductsecurity 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 tothe CMP. Proposed changes to the system should be reviewed by the CCB.

When proposed changes are likely to impact on security critical components, andlead to a modification of the residual risk, the CCB should ensure that changes arecarried 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 changingthreat environment, a system risk assessment should be undertaken periodically toensure that the residual risk remains within acceptable limits. The GSP requires thatTRAs 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 thereare any deficiencies, additional procedures should be included in the secureoperating 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 andfunctioning 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 examinationof technical security controls, and periodic auditing of organizational/administrative,operational, physical (including environmental), procedural and personnel securitymeasures.

29

2.7.3.2 Operational Review

Sensitive IT systems should be periodically subjected to formal operationalreviews, 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


− assemble CCB− audit Configuration Management− review System Change Request


− update TRA− update disposal plan


− maintenance of Certification Documentation

30

2.8 Summary

The following summarizes the main activities in the risk management life cycle, andthe location of guidance in supporting documents.

Table VIII – Risk Management Documentation Streams

Guide to RiskAssessment andSafeguard Selection



Plan for Change − High level TRA − Preliminary Certification Plan− Review of Memorandums of

Understanding

− Program Options− Concept of Change− Project Plan− CMP− MOUs

SystemRequirementsDefinition

− Preliminary SoS− Initial TRA− Functional Security

Requirements

− Validation of Functional

Security Requirements− Final Certification Plan

− System Specific Security

Policy

ArchitectureDesign

− Refined SoS− Refined TRA− Safeguard Selection

− Safeguard Validation &Verification

− Validation of Technical andOperational 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

SystemImplementation

− Updated TRA (residualrisk)

− Final Secure Operatingprocedures

− Secure Disposal Plan

− Certification Report

• Validation Results• Verification of

Safeguards• ST&E Results• TRA report

− Operational/Interim Approval

− Implementation schedule

System Operation − Updated TRA (residualrisk)

− Updated Secure DisposalPlan

− 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 forboth existing and new systems. However, for new systems some of the answerswill 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 throughwhat 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 ofconfidentiality, integrity and availability asset sensitivity, and an indication of the harmthat would result if the asset was compromised. It also provides, through theavailability assessment, minimum requirements for business resumption planning.The SoS provides direction for developing a framework for system operation and forimplementing 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 availabilityrequirements. For example, the "key person" database administrator need only bedescribed in terms of their availability requirements. The following table shows therelationship between the confidentiality, integrity and availability sensitivity and thetypes 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, realproperty 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, uninterruptablepower supplies

*3 X X

Utilities Hydro, water, telephone X

Key Personnel Database administrators, LAN administrators, supportpersonnel

X

3 Assessing Confidentiality

Information processed by, or stored on, IT systems is subject to the sameclassification and designation guidelines as is non-IT information. Document theclassification or designation of each asset in the asset inventory and, wherepossible, describe the harm that would result from disclosure.

When defining confidentiality sensitivity for an IT system, it is necessary to look at allthe data associated with the system. For instance, a database contains differenttypes of information, such as application (elements, entities, facets), security(userIDs, passwords, access permissions), and the database structures (datadictionaries). 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 maybe more sensitive and could therefore be exempt under the Access to InformationAct or the Privacy Act. It is thus necessary to consider the various relationshipsbetween data elements within the system because aggregate forms of the data maybe 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, forinstance encryptors or proprietary software algorithms.

33

1) Determining the types of information, software and services within theIT system

2) Determining the processing life-cycle and the various informationstates: input, storage, processing, communication, transmission, etc.

3) Analyzing each type of information separately and determining theconsequences that would result if the information was not accurate,complete and/or valid. Special attention should be paid to specificphases in the information processing life-cycle when integritysensitivity may be higher.

5 Availability

IT systems are, for the most part, developed to support essential services andmission critical functions. It is therefore crucial that information processed by, orstored 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 beexpressed as:

a) High for systems providing services to the Government of Canadaand 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 permissibledowntime or: how long the system can be unavailable before theconsequences begin to adversely affect the service delivery or businessoperation (expressed in hours or days).

4) Determining the system cycle(s) (daily, weekly, monthly, yearly). This willhelp in identifying critical periods where availability may differ.

5) Determining the harm that may result if the system is down longer than themaximum permissible downtime.

34

GLOSSARY

Sources: Each definition is followed by a corresponding reference from which it wasobtained.

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 BuildersWorkshop, Ottawa, June 1989

NEW New definition

TSEG Trusted Systems Environment Guideline, December 1992

Accreditation Formal declaration by the responsible managementapproving the operation of an automated system in aparticular security mode using a particular set of safeguards.Accreditation is the official authorization by management forthe operation of the system, and acceptance by thatmanagement of the associated residual risks. Accreditationis based on the certification process as well as othermanagement considerations. (TSEG)

Asset An asset is a component or part of the total system to whichthe department directly assigns a value to represent thelevel of importance to the "business" oroperations/operational mission of the department, andtherefore warrants an appropriate level of protection. Assetstypes include: information, hardware, communicationsequipment, firmware, documents/publications,environmental equipment, people/staff, infrastructure,goodwill, money, income, organizational integrity, customerconfidence, and organizational image. (EUROPEANCOMMUNITY)

Assurance The degree of confidence that a product correctlyimplements the security policy. (CTCPEC)

Availability The accessibility of systems, programs, services andinformation 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 supportof accreditation, that establishes the extent to which asystem satisfies a specified security policy. (CTCPEC)

35

Classified Assets An asset that is important to the national interest andtherefore warrants safeguarding. In terms of RiskManagement, classified information is also an asset thatmay qualify for an exemption or exclusion under the Accessto Information Act or Privacy Act and the compromise ofwhich would cause injury to the national interest. (NEW)

Compromise Unauthorized disclosure, destruction, removal, modificationor interruption. (GSP)

Confidentiality The quality or condition of being sensitive to disclosure.(GSP)

Designated Assets (1)Assets that have been identified by the institution asbeing important to operations by virtue of the functionperformed or as being valuable and therefore warrantingsafeguarding; (2) Cash and other negotiables; (3) Computersystems that require protection to ensure the integrity andavailability of the information stored therein, (4) Informationrelated to other than the national interest that may qualify foran exemption or exclusion under the Access to InformationAct or Privacy Act. (NEW)

Evaluation The rating of an information technology security (ITS)product, against an established national or internationalcriteria, by a lead agency. Both functionality and assuranceare rated. In Canada, evaluations are carried out byCSE/Canadian System Security Centre (CSSC) against theCTCPEC. Evaluations by the National Computer SecurityCentre (NCSC) in the U.S. against the Trusted ComputerSystem Evaluation Criteria(TCSEC) are often used inCanadian specifications. The results of an evaluation areused as input to the certification process. Products whichhave been successfully evaluated are variously referred toas "rated", "trusted" and as "Trusted Computing Bases"(TCBs). (TSEG)

Harm (Impact) An expression of the degree and kind of damage, or otherchange, 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 athreat event. (MBW2)

Motive Something that induces a threat agent to act against asystem. (NEW)

36

Residual Risk The risk that remains after safeguards have been selectedand implemented. (TSEG)

Risk A measure indicating the likelihood and consequence ofevents or acts that could cause a compromise of systemasset(s). (NEW)

Risk Assessment An evaluation of risk based on the effectiveness of existingsecurity safeguards, the likelihood of system vulnerabilitiesbeing exploited and the consequences of the associatedcompromise to system assets. (NEW)

Risk Management The process by which resources are planned, organized,directed, and controlled to ensure the risk of operating asystem remains within acceptable bounds at optimal cost.(NEW)

Safeguard(s) An approved minimum security measure(s) which, whencorrectly employed, will prevent or reduce the risk ofexploitation of specific vulnerability(s) which wouldcompromise an IT system. (NEW)

Security Evaluation The process of determining whether a system containsvulnerabilities that could be exploited. (NEW)

Security Testing The process of determining whether technical safeguards arefunctioning correctly. (NEW)

Security Validation The process of determining whether the system securityfeatures implement the organizational and system specificsecurity policy. (NEW)

Security Verification The process of determining whether technical and non-technical safeguards are implemented correctly and meetassurance requirements. (NEW)

Statement of Sensitivity A profile of an existing or proposed system, documentingcharacteristics of the data (to be) processed, the (proposed)user community, and the requirements to addressconfidentiality, integrity and availability concerns. AStatement of Sensitivity is used as an input to the riskanalysis. (TSEG)

Threat Assessment An evaluation of threat agent capability and motivation tocarry out threat events that could place sensitive informationand assets at risk. (NEW)

Threat Event An event or occurrence that has the potential to compromisethe security of an asset or information. (MBW2)*

37

Value (attribute of asset) A measure or statement of the utility of an asset orinformation, 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 theneeds and situation of the organization. Value is thereforenot necessarily an objective term. (MBW2)

Vulnerability (1) An inadequacy related to security that could permit athreat agent to cause harm, (2) an inherent weakness in ITthat 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 andAccreditation of Information Technology Systems, 1996, 40 pages.

2) Communications Security Establishment, A Guide to Risk Assessment andSafeguard Selection for Information Technology Systems, 1996, 65 pages.

3) Communications Security Establishment, Trusted System EnvironmentalGuideline (TSEG), 1992, 34 pages.

4) Treasury Board Manual, Information and Administrative ManagementComponent, Material, Risk and Common Services, 1994, Chapter 2-1 (Risk).

5) Treasury Board Manual, Information and Administrative ManagementComponent, Security, 1994.

Guide to Security Risk Management for Information Technology Systems

Documents

Transcript of Guide to Security Risk Management for Information Technology Systems