Download a printable version Information Security Risk Assessment Guidelines rtf format of it_security_risk_assessment_guidelines.rtf file size 1MB  

Introduction and Overview

Information security risk assessment is an on-going process of discovering, correcting and preventing security problems. The risk assessment is an integral part of a risk management process designed to provide appropriate levels of security for information systems. Information security risk assessments are part of sound security practices and are required by the Commonwealth Enterprise Information Security Policy. Risk assessments and related documentation are also an integral part of compliance with HIPAA security standards (see below).

The risk assessment will help each agency determine the acceptable level of risk and the resulting security requirements for each system. The agency must then devise, implement and monitor a set of security measures to address the level of identified risk. For a new system the risk assessment is typically conducted at the beginning of the System Development Life Cycle (SDLC). For an existing system, risk assessments may be conducted on a regular basis throughout the SDLC and/or on an ad-hoc basis in response to specific events such as when major modifications are made to the system's environment or in response to a security incident or audit.

This risk assessment methodology is based on the CMS Information Security RA Methodology, developed by the federal Department of Health and Human Services, Centers for Medicare and Medicaid Services (CMS), which is available at www.cms.hhs.gov/it/security/docs/RA_meth.pdf. It is presented in three phases:

  • System Documentation Phase
  • Risk Determination Phase
  • Safeguard Determination Phase

The risk assessment report:

  • Summarizes the system architecture and components, and its overall level of security;
  • Includes a list of threats and vulnerabilities, the system's current security controls, and its risk levels;
  • Recommends safeguards, and describes the expected level of risk that would remain if these safeguards were put in place;
  • Shows where an organization needs to concentrate its remedial work;
  • Can be used as input to the agency's business continuity plan;
  • Presents these findings to management.

 

Note on HIPAA Security

Commonwealth agencies defined as Covered Entities (CE's), and those who are Business Associates of CE's, must comply with the HIPAA security rule, 45 CFR parts 160, 162 and 164. The HIPAA security framework calls for due diligence based on good business practices, for systems handling electronic protected health information (EPHI). Creating an Information Risk Assessment Report satisfies the Rule's requirements to analyze risks, formulate appropriate safeguards, and document the risk management decision-making process (45 CFR part 164.308(a)(1)(ii)(A)(B)) and informs the agency's actions in complying with other parts of the rule.

Team Members

A sample representative risk assessment team may include the functions listed below. Each team member may perform more than one function. HIPAA-affected agencies should secure the involvement of their HIPAA security officer. Some functions overlap, for functions where team members review each other's work. See Appendix C for more detail on these roles.

Risk assessment manager

System or network administrator

Technical reviewer

System business owner

System technical owner

Executive sponsor

Information security officer

The Risk Assessment Report

A Risk Assessment (RA) Report applies to a selected information system. An information system is a group of computing and network components that share a business function, under common ownership and management. The Report will include:

  • A documented system inventory, listing all system components and establishing the system boundary for the purposes of the Report;
  • Documentation of the system's policies and procedures, and details of its operation;
  • List of threat / vulnerability pairs, with severity of impact and likelihood of occurrence;
  • List of safeguards for controlling these threats and vulnerabilities;
  • List of recommended changes, with approximate levels of effort for each;
  • For each recommended change, the resulting reduction in risk;
  • The level of residual risk that would remain after the recommended changes are implemented.

The Report will reflect the security policies and objectives of the agency's information technology management. It will be presented in a face-to-face meeting with the system business and technical owners, the risk assessment manager, and other project team members.

A Risk Assessment Report is not intended to create or include the following, however it should be used as input for:

  • A system security plan, new security architecture, audit report, or system accreditation;
  • System security policies, or assignment of staff responsibility for system security;
  • Detailed dataflows;
  • Exact dollar cost estimates or justifications;
  • Assignment or acceptance of legal responsibility for the security of the system;
  • In-depth analysis or resolution of specific security incidents or violations;
  • Contract review.

Appendix D provides a template for the documentation of the Risk Assessment report.

Tasks

This chart shows the sequence of high-level tasks. The complete list of tasks and durations will be created, estimated and scheduled by the team.

risk assessment chart

System Documentation Phase

  • Document system identification
  • Document system purpose and description
  • Document the system security level

The team must make a decision about where to draw the boundaries of the system to be assessed.

Risk Determination Phase

  • Identify threats
  • Identify vulnerabilities
  • Describe risks
  • Identify existing controls
  • Determine likelihood of occurrence
  • Determine severity of impact
  • Determine risk level

The team must decide whether to include only controls that are currently implemented, or to include controls that are budgeted and scheduled for implementation.

Safeguard Determination Phase

  • Recommend controls and safeguards
  • Determine residual (remaining) likelihood of occurrence if controls and safeguards are implemented
  • Determine residual severity of impact if candidate controls and safeguards are implemented
  • Determine residual risk levels

 

Risk Assessment Process

1.0 System Documentation Phase

The System Documentation Phase provides a description of the system and the data it handles, as computing assets used to fulfill the organization's business mission. This phase establishes a framework for subsequent risk assessment phases.

The system owner provides the system identification, including the system description, business

function and assets. For new systems, these are defined when the system is first conceived and developed during the SDLC's design and implementation phases (see Appendix B).

 

Phase 1:

Set the boundaries for the set of components that constitute the information system. An information system is a group of computing and supporting components that share a business function, under common ownership and management.

Key Team Members:

System administrator

Technical reviewer

System technical owner

Output:

High-level documentation and network diagram showing the system and adjacent systems, with a line showing the cut-off for the scope of this risk assessment.

 

1.1 System Identification

List the system name, other related information, and the responsible organization. See the System Identification table in Appendix D.

 

Task 1.1:

Complete and verify system identification and responsible contacts.

Key Team Members:

System administrator

Technical reviewer

System technical owner

Risk assessment manager

Output:

Complete 1.1 System Identification table in Appendix D.

 

1.2 System Purpose and Description

To identify the assets covered by the RA, provide a brief description of the function and purpose of the system and the organizational business processes it supports, including functions and processing of data.

Technical Description and Environmental Factors

  • General description of function and purpose the system
  • General functional requirements
  • Business processes supported
  • Applications supported, services running
  • General information flow
  • Network diagram with system boundaries
  • Description of physical components
  • Physical component asset and tag numbers
  • Physical location, environmental controls in place
  • Environmental factors that give rise to security concerns
  • Technical and business users, list of system user accounts
  • System ownership: Shared or dedicated

System Connections and Information Sharing

  • Connected components
  • LAN and WAN connections and topology, firewall configurations
  • Software dependencies
  • Interfaces

 

Task 1.2:

Document the system's business function, components, environment, connections.

Key Team Members:

System administrator

Technical reviewer

System technical owner

System business owner

Information security officer

Output:

Complete 1.2 System Purpose and Description table in Appendix D.

 

1.3 System Security Level

Describe and document the information handled by the system, and identify the overall system security level. The classification levels and the categories assigned to different types of information should correspond to the agency's information classification designations. Information security levels and designations should be part of the agency's information security policy. Appendix A, Information Security Levels, provides examples of security levels and how they can be assigned to different categories of information.

For this step, the team will document the sensitivity of the information handled by the system, then classify the resulting level of security requirements for the system itself.

This element includes a general description of the information, the information's sensitivity, and system criticality. It includes requirements for confidentiality, integrity, availability, auditability and accountability as dictated by the agency's information security policy.

 

Task 1.3:

Document the criticality and sensitivity of the information the system handles, with brief references to the agency's information security policy, and the overall system security requirements.

Key Team Members:

Technical reviewer

System business owner

System technical owner

Output:

Complete 1.3 Information Security Levels and Overall System Security Level table in Appendix D.

 

2.0 Risk Determination Phase

The goal of the Risk Determination Phase is to calculate the level of risk for each threat / vulnerability pair based on the likelihood of a threat exploiting a vulnerability, and the severity of impact that the exploited vulnerability would have on the system, its data and its business function. Consider the impact in terms of loss of confidentiality, integrity or availability of the data classified in Task 1.3.

Information will be collected in the form of questionnaires, interviews, documentation review, and automated scanning tools.

The Risk Determination Phase is comprised of six steps:

 

  1. Identify potential dangers to information and system (threats).
  2. Identify the system weakness that could be exploited (vulnerabilities) associated to generate the threat / vulnerability pair.
  3. Identify existing controls to reduce the risk of the threat exploiting the vulnerability.
  4. Determine the likelihood of occurrence for a threat exploiting a related vulnerability given the existing controls.
  5. Determine the severity of impact on the system by an exploited vulnerability.
  6. Determine the risk level for a threat/vulnerability pair given the existing controls.

This six-step process for Risk Determination is conducted for each identified threat / vulnerability pair. Use the Risk Determination Table in Appendix D to document the analysis performed in this phase.

2.1 Identify Threats and Vulnerabilities

First, identify threats that could exploit system vulnerabilities. Refer to the CMS Threat Identification Resource (www.cms.hhs.gov/it/security/docs/Threat_ID_resource.pdf) for possible environmental, physical, human, natural, and technical threats. Using the output of task 1.2, consider the system's connections, dependencies with other systems, inherited risks and controls, risks from software faults and staff errors and malicious intent, and such factors as proximity to the Internet, incorrect file permissions, risks from maintenance procedures and personnel changes.

Next, consider the potential vulnerabilities associated with each threat, to produce a pair. A vulnerability can be associated with one or more threats. Collect input from previous risk assessments, audits, system deficiency reports, security advisories, scanning tools, security test results, system development testing, industry and government listings, such as sans.org, securityfocus.com, vendor advisories, and the NIST vulnerability database at icat.nist.gov.

 

Task 2.1:

Descriptions of threat/vulnerability pairs.

Key Team Members:

System administrator

Technical reviewer

System technical owner

Output:

Complete the "Item No.", "Threat Name" and "Vulnerability Name" columns in 2.0 Risk Determination table in Appendix D.

 

2.2 Describe Risks

Describe how each vulnerability creates a risk to the system in terms of confidentiality, integrity, availability, auditability or accountability elements that may result in a compromise of the system.

 

Task 2.2:

Describe risks in relation to threat/vulnerability pairs.

Key Team Members:

System administrator

Technical reviewer

System technical owner

Output:

Complete the "Risk Description" column of the 2.0 Risk Determination table in Appendix D.

2.3 Identify Existing Controls

Identify existing controls that reduce the likelihood or probability of a threat exploiting a system vulnerability, and/or reduce the magnitude of impact of the exploited vulnerability on the system. Existing controls may be management, operational or technical controls depending on the threat / vulnerability and the risk to the system.

 

Task 2.3:

Description of system controls, cross-referenced with threat / vulnerability pairs.

Key Team Members:

System administrator

Technical reviewer

System technical owner

Output:

Complete the "Existing Controls" column of 2.0 Risk Determination table in Appendix D.

2.4 Determine Likelihood of Occurrence

Estimate the likelihood that a threat will exploit a vulnerability. Likelihood of occurrence is based on a number of factors that include system architecture, system environment, information system access and existing controls; the presence, motivation, tenacity, strength and nature of the threat; the presence of vulnerabilities; and the effectiveness of existing controls.

Refer to this table to when estimating the likelihood that the threat will be realized and exploit the vulnerability on the system.

 

Likelihood of Occurrence Levels

Likelihood

Description

Negligible

Unlikely ever to occur

Very Low

Likely to occur two/three times every five years

Low

Likely to occur once every year or less

Medium

Likely to occur once every six months or less

High

Likely to occur once per month or less

Very High

Likely to occur multiple times per month

Extreme

Likely to occur multiple times per day

 

 

Task 2.4:

Threat / vulnerability pairs with likelihood of successful exploitation.

Key Team Members:

System administrator

Technical reviewer

System technical owner

Output:

Categorize threat / vulnerability pairs by likelihood of occurrence, complete the "Likelihood of Occurrence" column of 2.0 Risk Determination table in Appendix D.

2.5 Determine Severity of Impact

Determine the magnitude or severity of impact on the system's operational capabilities and the information it handles, if the threat is realized and exploits the associated vulnerability. Determine the severity of impact for each threat / vulnerability pair by evaluating the potential loss in each security category (confidentiality, integrity, availability, auditability, accountability) based on the system's information security level as explained in Appendix A.

 

Impact Severity Levels

Insignificant

Little or no impact

Minor

Minimal effort to repair, restore or reconfigure

Significant

Small but tangible harm, maybe noticeable by a limited audience, some embarrassment, some effort to repair

Damaging

Damage to reputation, loss of confidence, significant effort to repair

Serious

Considerable system outage, loss of connected customers, business confidence, compromise of large amount information

Critical

Extended outage, permanent loss of resource, triggering business continuity procedures, complete compromise of information

 

 

Task 2.5:

Threat / vulnerability pairs with severity of successful exploitation.

Key Team Members:

System administrator

Technical reviewer

System technical owner

System business owner

Output:

Categorize threat / vulnerability pairs by severity or magnitude of impact, and complete the "Impact Severity" column of 2.0 Risk Determination table in Appendix D.

 

2.6 Determine Risk Levels

Risk level is the likelihood of occurrence multiplied by the severity of impact. The final value is subject to the system business and technical owners' discretion.

Risk determination

For each threat / vulnerability pair, assess the following:

  • Likelihood of the threat attempting to exercise the vulnerability;
  • Magnitude of impact if the threat / vulnerability exploit is successful;
  • Adequacy of planned or existing security controls for reducing or eliminating risk;
    Note: The project team must decide whether to use only currently implemented controls for this analysis, or to include controls that are budgeted and scheduled for installation, and document that decision in the Report.
  • Resulting risk to the information on the system from the threat and vulnerability.

 

This table shows the resulting risk level, for each degree of likelihood and each level of severity.

 

Risk Levels

Likelihood of Occurrence

Impact Severity

 

Insignificant

Minor

Significant

Damaging

Serious

Critical

Negligible

Low

Low

Low

Low

Low

Low

Very Low

Low

Low

Low

Low

Moderate

Moderate

Low

Low

Low

Moderate

Moderate

High

High

Medium

Low

Low

Moderate

High

High

High

High

Low

Moderate

High

High

High

High

Very High

Low

Moderate

High

High

High

High

Extreme

Low

Moderate

High

High

High

High

 

 

Task 2.6:

Threat / vulnerability pairs with assigned risk levels.

Key Team Members:

System administrator

Technical reviewer

System technical owner

System business owner

Output:

Combine the likelihood of occurrence with magnitude of impact to derive the risk level for each threat / vulnerability pair. Consider the risks to the information on the system, and complete the "Risk Level" column of 2.0 Risk Determination table in Appendix D.

 

3.0 Safeguard Determination Phase

 

The safeguard determination phase involves identification of additional controls, safeguards or corrective actions to minimize the threat exposure and vulnerability to exploitation for each threat/ vulnerability pair with a moderate or high risk level. The residual risk level is the amount of risk that would remain if the recommended control or safeguard were implemented.

Safeguard determination steps:

  1. Identify controls and safeguards to reduce the risk level of each risk-threat pair, if the risk level is moderate or high.
  2. Determine the residual likelihood of occurrence of the threat if the recommended safeguard is implemented.
  3. Determine the residual impact severity of the exploited vulnerability once the recommended safeguard is implemented.
  4. Determine the residual risk level for the system.

Consider safeguards related to testing and maintenance, improved audit capability, and restricting physical access.

3.1 Recommend Controls and Safeguards

Identify controls and safeguards to reduce the risk presented by each threat / vulnerability pair with a moderate or high risk level as identified in the Risk Determination Phase. When identifying a control or safeguard, consider:

 

  1. Security area where it belongs, such as management, operational, technical.
  2. Method it employs to reduce the opportunity for the threat to exploit the vulnerability.
  3. Its effectiveness in mitigating the risk to information.
  4. Policy and architectural parameters required for its implementation in the environment.
  5. Information security category (confidentiality, integrity, availability, access control, audit, etc.) to which the safeguard applies.
  6. Whether the cost of the safeguard is commensurate with its reduction in risk.

 

If more than one safeguard is identified for the same threat / vulnerability pair, list them in this column in separate rows and continue with the analysis steps. The residual risk level must be evaluated during this phase of the assessment and may be further evaluated in risk management activities outside the scope of this project.

If the recommended safeguard cannot be completely implemented in the environment due to cost, management, operational or technical constraints, document the circumstances and continue with the analysis.

Consider control elements implemented as policies and procedures, training, and improved policy enforcement.

 

Task 3.1:

Create a list of current, planned or available safeguards and controls suitable for protecting the information

Key Team Members:

System administrator

System technical owner

Technical reviewer

Output:

List of safeguards and controls, with implementation considerations. Complete the "Recommended Safeguard" column in 3.0 Safeguard Determination table in Appendix D.

3.2 Determine Residual Likelihood of Occurrence

Follow the directions in section 2.4 of the Risk Determination phase, while assuming the selected safeguard has been implemented.

 

Task 3.2:

Categorize threat / vulnerability pairs by likelihood of occurrence, assuming the selected safeguard has been implemented.

Key Team Members:

System administrator

Technical reviewer

System technical owner

Output:

Complete the "Residual Likelihood of Occurrence" column of 3.0 Safeguard Determination table in Appendix D.

3.3 Determine Residual Severity of Impact

Follow the directions in section 2.5 of the Risk Determination phase while assuming the selected safeguard has been implemented.

 

Task 3.3:

Categorize threat / vulnerability pairs by severity or magnitude of impact of a successful exploitation, assuming the selected safeguard has been implemented.

Key Team Members:

System administrator

Technical reviewer

System technical owner

System business owner

Output:

Complete the "Residual Impact Severity" column of 3.0 Safeguard Determination table in Appendix D.

3.4 Determine Residual Risk Levels

Determine the residual risk level for the threat/vulnerability pair and its associated risk once the recommended safeguard is implemented. The residual risk level is determined by examining the likelihood of occurrence of the threat exploiting the vulnerability and the impact severity factors in categories of Confidentiality, Integrity and Availability.

Follow the directions in Section 2.6 of the Risk Determination phase to determine the residual risk level once the recommended safeguard is implemented.

Depending on the nature and circumstances of threats and vulnerabilities, a recommended safeguard may reduce the risk level to "Low." Make a note of the situation with a description below the table, if needed, if such special conditions exist.

For new systems, the next steps would include creating a sensitivity assessment, system security requirements, risk assessment report, and system security plan in the SDLC.

 

Task 3.4:

Repeat the derivation the risk level for each threat / vulnerability pair from task 2.6, this time assuming the selected safeguard has been implemented.

Key Team Members:

System administrator

Technical reviewer

System technical owner

System business owner

Output:

Complete the "Residual Risk Level" column of 3.0 Safeguard Determination table in Appendix D.

 

Appendix A: Information Security Levels

 

System business and technical owners must determine the appropriate security levels based on the organization's confidentiality, integrity and availability requirements for the information, as well as its criticality to the organization's business mission. These requirements are usually contained in the agency's statutory, regulatory and policy frameworks. This is the basis for assessing the risks to business operations and assets and in selecting appropriate security controls and techniques.

Below are sample information security levels that establish common criteria for security by information category. The first table defines the information security levels. The second table provides security level examples for the various information categories. In cases where information of varying security levels are combined in one system, the highest security level takes precedence.

It is each agency's responsibility to determine information security levels for each information category based on its particular business and legal requirements. The examples below are provided for illustration purposes only.

Examples of Information Security Levels

 

Security Level

Description

Explanation

Low

Moderately serious

Noticeable impact on an agency's missions, functions, or reputation. A breach of this security level would result in a negative outcome; or would result in damage, requiring repairs, to an asset or resource.

Moderate

Very serious

Severe impairment to an agency's missions, functions, image, and reputation. The impact would place an agency at a significant disadvantage; or would result in major damage, requiring extensive repairs to assets or resources.

High

Catastrophic

Complete loss of mission capability for an extended period; or would result in the loss of major assets or resources and could pose a threat to human life.

 

Examples of Information Security Levels by Information Category

 

Information Category

Explanation and Examples

System Security Level*

Law enforcement and state security information

Information related to investigations for law enforcement purposes; security plans, contingency plans, emergency operations plans, incident reports, reports of investigations, risk or vulnerability assessments certification reports; does not include general plans, policies, or requirements.

High

Life-critical information

Information critical to life-support systems (i.e., information where inaccuracy, loss, or alteration could result in loss of life).

High

Information about persons

Information related to personnel, medical, and similar data (e.g., salary data, social security information, passwords, user identifiers (IDs), EEO, personnel profile (including home address and phone number), medical history, employment history (general and security clearance information), and arrest/criminal investigation history).

Moderate

Financial, budgetary, commercial, proprietary and trade secret information

Information related to financial information and applications, commercial information received in confidence, or trade secrets (i.e., proprietary, contract bidding information, sensitive information about employees or citizens). Also included is information about payroll, automated decision making, procurement, inventory, other financially related systems, and site operating and security expenditures.

Moderate

Public information

Any information that is declared for public consumption by official authorities. This includes information contained in press releases. It also includes information placed on public access world-wide-web servers.

Low

 

Appendix B: Security in the System Development Life Cycle

(From CMS Information Security RA Methodology)

Although information security must be considered in all phases of the life of a system, the System Development Life Cycle identifies four specific steps that are needed to ensure that information at CMS is properly protected. These include the Information Sensitivity Assessment (Section 10.5 of the Business Case Analysis), System Requirements Document, the RA Report and the System Security Plan.

Step 1 - The Information Sensitivity Assessment (ISA)

Prior to project initiation, the system owner prepares a Business Case Analysis (BCA), which includes the ISA (section 10.5 of the BCA). In this step, the system owner categorizes the data according to sensitivity and identifies high-level security requirements that apply to the system under consideration for development. Information from the ISA is one of the factors considered in determining if the system will go forward into development and what level of information security will be needed. Elements from the ISA provide the initial input to the RA.

Step 2 -System Requirements Document (specifically Security Requirements)

As an initial step of the development process, system requirements are documented for every system. The security requirements serve as a baseline for security within the system. The CMS Minimum Information Security Standards is a tool to assist in defining security requirements. Other requirements may be determined by business or functional requirements.

Step 3 - Risk Assessment Report

During the development process, a risk assessment is conducted and the result RA Report documents the vulnerabilities that have been identified in the system, the risks to the system resulting from the vulnerabilities and the efforts designed to reduce those risks, through the use of safeguards. The RA Report provides input to the System Security Plan and other risk management activities.

Step 4 - System Security Plan

The System Security Plan incorporates all of the elements required for the system owner to determine if the system should be certified as meeting both CMS policy and business requirements. Information from the RA Report is incorporated into the System Security Plan in Section 2 - Management Controls.

Security steps also correspond to phases in the Integrated IT Investment Management Road Map (ROADMAP) for system development. The ROADMAP is CMS's implementation standard for SDLC and Investment Management. In Figure B-1, the system development life cycle and ROADMAP are shown on the right and left sides with the information security deliverables and tools entered in the center section between them. This format illustrates the relationship of the information security tasks to both processes.


 

Figure B-1. Security in the System Development Life Cycle and CMS's Roadmap

security in the system development life cycle and CMS roadmap

 

The following text describes Figure B-1.

System Security in the SDLC

Pre-Development

1. Express need for system

2. Assess/determine data sensitivity

3. Define initial security requirements

Development

1. Identify detailed system security requirements during system design.

2. Develop appropriate security controls with evaluation & test procedures prior procurement actions

3. Develop solicitation documents to include security requirements & evaluation/test procedures

4. Update security requirements as technologies are implemented

5. Identify security requirements for procurement of COTS applications components

6. Perform design review to ensure security controls are considered prior to production

7. Ensure security features are configured, enables, tested, and documented during development

8. Update, design, perform and document newly developed security controls

9. Document system security tests and risk assessment

10. Ensure compliance with Federal laws, regulations, policies and standards

11. Certify system and obtain system accreditation

12. Provide security training

Post-Development

1. Document all security activities

2. Perform security operations and administration

a. Perform backups

b. Provide security training

c. Maintain & review user admin & access privileges

d. Update security software as required

e. Update security procedures as required

3. Perform operational assurance

a. Perform & document periodic security audits

b. Perform & document monitoring of system security

c. Evaluate & document results of security monitoring

d. Perform & document corrective actions

e. Test contingency plans on a regular basis

f. Perform Risk Assessment and update Security Plan, as needed, with each configuration change or every year

4. Document disposal of information

5. Use controls to ensure confidentiality of information

IT Investment Management Road Map

Acquisitions

- BCA 10.5 - Information Sensitivity Assessment

Requirements Definition

- Define System Requirements

- Information Security Risk Assessment

Design and Engineering

- Security Test Plan/Cases

Development

- Software Test Plan

- Program Software Unit and Integration

- Test Case Scenarios

- Test Data

Testing and Implementation

- Perform System Acceptance Testing

- Test or Validation Result Report

- Security Test Results

Implementation

- System Security Risk Assessment

- System Security Plan

Operations & Maintenance

- Updated Risk Assessment

- Updated System Security Plan

Security Deliverables & Resources

Business Case Analysis

10.5 - Information Sensitivity

Minimum Security Standards

System Requirements Document (includes security)

Threat Identification Resource

Identify Vulnerabilities

Risk Assessment (Risk Determination and Safeguard Evaluation)

System Security Plan

Risk Assessment and System Security Plan

Appendix C: Assessment Team Members and Functions

Functional Role

Background

Organization

Email

Phone

Risk Assessment Manager

Drives the risk assessment process, coordinates tasks, deliverables and schedule, composes the report with input from all team members.

 

 

 

System or network administrator

Operates and maintains the system from a technical, day-to-day standpoint; usually the "Primary System Contact" in the System Identification table.

 

 

 

Technical Reviewer

Understands the technical components of the system, but was not involved in designing, building or operating the system being assessed.

 

 

 

System business owner

Responsible for the system, or the services it provides, from a business or customer standpoint; understands the system's purpose but not necessarily the details of its technical implementation.

 

 

 

System technical owner

Has supervisory responsibility for the operation of the system.

 

 

 

Executive sponsor

Executive management-level responsibility for the system.

 

 

 

Information security officer

Responsible for the agency's security policies and objectives, and its overall risk profile.

 

 

 

 

Appendix D: Information Security Risk Assessment Template

1.0 System Documentation

1.1 System Identification

Agency Name

 

Official System Name

 

System Acronym

 

System Business Owner

 

System Technical Owner

 

System Security Owner

 

Additional System Stakeholders

 

 

 

 

System Location Full Address

 

Contract Number, Contractor names,

phone numbers and emails, if applicable

 

System type(s) (mainframe, application /

database / network / file server, workstation)

 

 

 

Primary System Contact(s), Name and Title

(usually the system administrator)

 

Organization Name

 

Full Address

 

Email Address

 

Phone and pager numbers

 

 

 

1.2 System Purpose and Description

Function and purpose of the system

 

 

 

General functional requirements

 

 

 

Business processes, applications and services supported

 

 

System components

 

 

Environmental factors

 

 

Network diagram with system boundaries (attach)

 

General information flow

 

 

Technical and business users (list)

 

 

System ownership (shared or dedicated)

 

 

 

 

 

 

1.3 Information Security Levels and Overall System Security Level

 

Information Category

 

 

Information Security Level

 

 

 

 

Information Category

 

 

Information Security Level

 

 

 

 

Information Category

 

 

Information Security Level

 

 

 

 

Overall System Security Level

 

 

 

2.0 Risk Determination

2.0 Risk Determination Table

Item No.

Threat Name

Vulnera-bility Name

Risk Descrip-tion

Existing Controls

Likeli-hood of Occur-rence

Impact Severity

Risk Level

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.0 Safeguard Determination

3.0 Safeguard Determination Table

Item No.

(from Risk Determination Table)

Recommended Safeguard Description

Residual Likelihood of Occurrence

Residual Impact Severity

Residual Risk Level

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Signatures

 

 

Submitted by: _______________________ Date: _________

Risk Assessment Manager

 

 

Reviewed by: _______________________ Date: _________

[Title]

 

 

Approved by: _______________________ Date: _________

[Title]