Question

What are some of the highlights of NIST's Risk Management Guide for IT Systems?

Answer 1

The information technology system is always associated with some kind of risk, so to determine these kind of risk a good management or guide plays a critical role in protecting an organization's information assets from IT related risk.

An effective risk management is an important component for securing IT-related information in this digital era.

NIST (National Institute of Standards and Technology) provides a foundation for the development of an effective risk management program.It provides practical guidance for assessing and migrating risk identified within IT system.

The main aim is to guide organization to manage IT related risk in better way by securing the IT system that stores, process organizational information.

Three main components of NIST's Risk Management Guide is as below.

1. Risk Assessment
2. Risk Mitigation
3. Evaluation and Assessment

RISK ASSESSMENT

The first process in the NIST's Risk Management methodology is Risk Assessment. Since every IT system development passes through a cycle called SDLC (Software Development Life Cycle). Throughout this cycle organizations use risk assessment to determine the extent of potential threat and risk associated with it. As a result this process helps organizations to identify risk and their controls.

NIST provides nine primary steps for Risk Assessment.

1. System Characterization
2. Threat Identification
3. Vulnerability Identification
4. Control Analysis
5. Likelihood Determination
6. Impact Analysis
7. Risk Determination
8. Control Recommendation
9. Result Documentation

STEP 1: SYSTEM CHARACTERIZATION

In this step the boundaries of the IT system are identified along with the resources and the information that constitute the system. Characterizing an IT system establish the scope of the risk assessment, effort, delineates the operational authorization boundaries and provides information essential to defining the risk.

It contains

1. System Related Information

• Hardware
• Software
• System Interface
• Data and Information
• Person who support and use IT system
• The process performed by IT system
• The system value or importance to the organization
• System and data sensitivity

2. Information gathering Techniques

• Questionnaire
• On-site Interviews
• Document Review
• Use of automated scanning tool

STEP 2: THREAT IDENTIFICATION

A threat is the potential for a particular threat-source to successfully exercise a particular vulnerability. A vulnerability is a weakness that can be accidentally triggered or intentionally exploited.

Threat-Source Identification

The goal of this step is to identify the potential threat-sources and compile a threat statement listing potential threat-sources that are applicable to the IT system being evaluated.

A threat-source is defined as any circumstance or event with the potential to cause harm to an IT system. The common threat sources can be natural, human, or environmental.

Humans can be threat-sources through intentional acts, such as deliberate attacks by malicious persons or disgruntled employees, or unintentional acts, such as negligence and errors. A deliberate attack can be either a malicious attempt to gain unauthorized access to an IT system (e.g., via password guessing) in order to compromise system and data integrity, availability, or confidentiality or a benign, but nonetheless purposeful, attempt to circumvent system security. One example of the latter type of deliberate attack is a programmer’s writing a Trojan horse program to bypass system security in order to get the job done.

STEP 3: VULNERABILITY IDENTIFICATION

The analysis of the threat to an IT system must include an analysis of the vulnerabilities associated with the system environment. The goal of this step is to develop a list of system vulnerabilities (flaws or weaknesses) that could be exploited by the potential threat-sources.

STEP 4: CONTROL ANALYSIS

The goal of this step is to analyze the controls that have been implemented, or are planned for implementation, by the organization to minimize or eliminate the likelihood (or probability) of a threat’s exercising a system vulnerability.

STEP 5: LIKELIHOOD DETERMINATION

To derive an overall likelihood rating that indicates the probability that a potential vulnerability may be exercised within the construct of the associated threat environment, the following governing factors must be considered:

• Threat-source motivation and capability

• Nature of the vulnerability

• Existence and effectiveness of current controls.

STEP 6: IMPACT ANALYSIS

The next major step in measuring level of risk is to determine the adverse impact resulting from a successful threat exercise of a vulnerability. This information can be obtained from existing organizational documentation, such as the mission impact analysis report or asset criticality assessment report. A mission impact analysis (also known as business impact analysis [BIA] for some organizations) prioritizes the impact levels associated with the compromise of an organization’s information assets based on a qualitative or quantitative assessment of the sensitivity and criticality of those assets. An asset criticality assessment identifies and prioritizes the sensitive and critical organization information assets (e.g., hardware, software, systems, services, and related technology assets) that support the organization’s critical missions.

STEP 7: RISK DETERMINATION

The purpose of this step is to assess the level of risk to the IT system. The determination of risk for a particular threat/vulnerability pair can be expressed as a function of

• The likelihood of a given threat-source’s attempting to exercise a given vulnerability
• The magnitude of the impact should a threat-source successfully exercise the vulnerability
• The adequacy of planned or existing security controls for reducing or eliminating risk

STEP 8: CONTROL RECOMMENDATIONS

During this step of the process, controls that could mitigate or eliminate the identified risks, as appropriate to the organization’s operations, are provided. The goal of the recommended controls is to reduce the level of risk to the IT system and its data to an acceptable level. The following factors should be considered in recommending controls and alternative solutions to minimize or eliminate identified risks:

• Effectiveness of recommended options (e.g., system compatibility)
• Legislation and regulation
• Organizational policy
• Operational impact •
• Safety and reliability.

The control recommendations are the results of the risk assessment process and provide input to the risk mitigation process, during which the recommended procedural and technical security controls are evaluated, prioritized, and implemented

STEP 9: RESULTS DOCUMENTATION

Once the risk assessment has been completed (threat-sources and vulnerabilities identified, risks assessed, and recommended controls provided), the results should be documented in an official report or briefing.

A risk assessment report is a management report that helps senior management, the mission owners, make decisions on policy, procedural, budget, and system operational and management changes. Unlike an audit or investigation report, which looks for wrongdoing, a risk assessment report should not be presented in an accusatory manner but as a systematic and analytical approach to assessing risk so that senior management will understand the risks and allocate resources to reduce and correct potential losses. For this reason, some people prefer to address the threat/vulnerability pairs as observations instead of findings in the risk assessment report.

RISK MITIGATION

Risk mitigation, the second process of risk management, involves prioritizing, evaluating, and implementing the appropriate risk-reducing controls recommended from the risk assessment process.

Because the elimination of all risk is usually impractical or close to impossible, it is the responsibility of senior management and functional and business managers to use the least-cost approach and implement the most appropriate controls to decrease mission risk to an acceptable level, with minimal adverse impact on the organization’s resources and mission.

RISK MITIGATION OPTIONS

Risk mitigation is a systematic methodology used by senior management to reduce mission risk. Risk mitigation can be achieved through any of the following risk mitigation options:

• Risk Assumption. To accept the potential risk and continue operating the IT system or to implement controls to lower the risk to an acceptable level
• Risk Avoidance. To avoid the risk by eliminating the risk cause and/or consequence (e.g., forgo certain functions of the system or shut down the system when risks are identified)
• Risk Limitation. To limit the risk by implementing controls that minimize the adverse impact of a threat’s exercising a vulnerability (e.g., use of supporting, preventive, detective controls)
• Risk Planning. To manage risk by developing a risk mitigation plan that prioritizes, implements, and maintains controls
• Research and Acknowledgment. To lower the risk of loss by acknowledging the vulnerability or flaw and researching controls to correct the vulnerability  
• Risk Transference. To transfer the risk by using other options to compensate for the loss, such as purchasing insurance.

EVALUATION AND ASSESSMENT

The risk management process is ongoing and evolving.  

In most organizations, the network itself will continually be expanded and updated, its components changed, and its software applications replaced or updated with newer versions. In addition, personnel changes will occur and security policies are likely to change over time. These changes mean that new risks will surface and risks previously mitigated may again become a concern.

This section emphasizes the good practice and need for an ongoing risk evaluation and assessment and the factors that will lead to a successful risk management program.

GOOD SECURITY PRACTICE

The risk assessment process is usually repeated at least every 3 years for federal agencies, as mandated by OMB Circular A-130. However, risk management should be conducted and integrated in the SDLC for IT systems, not because it is required by law or regulation, but because it is a good practice and supports the organization’s business objectives or mission. There should be a specific schedule for assessing and mitigating mission risks, but the periodically performed process should also be flexible enough to allow changes where warranted, such as major changes to the IT system and processing environment due to changes resulting from policies and new technologies.

KEYS FOR SUCCESS

A successful risk management program will rely on

• Senior management’s commitment.
• The full support and participation of the IT team.
• The competence of the risk assessment team, which must have the expertise to apply the risk assessment methodology to a specific site and system, identify mission risks, and provide cost-effective safeguards that meet the needs of the organization.
• The awareness and cooperation of members of the user community, who must follow procedures and comply with the implemented controls to safeguard the mission of their organization.
• An ongoing evaluation and assessment of the IT-related mission risks.