Domain 3B: Introduction to Risk Management

Vulnerability

A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.

Low Risk

A low risk to the organization exists. An evaluation should be performed to determine if the risk should be reduced or if it will be accepted. If it is determined that the risk should be reduced, corrective actions should be performed to reduce risk to an acceptable level.

Medium Risk

A moderate risk to the organization and to the organizational mission exists. There is a need for corrective actions that include reevaluation of existing controls and may include implementation of additional controls. Corrective actions should be implemented within a reasonable time frame to reduce risk to an acceptable level.

Security Auditing Overview

A security audit is an evaluation of how well the objectives of a security framework are met and a verification to ensure the security framework is appropriate for the organization. Nothing that comes out of an audit should surprise security practitioners if they have been doing their continuous monitoring. Think of it this way. Monitoring is an ongoing evaluation of a security framework done by the folks who manage the security day-to-day, while an audit is an evaluation of the security framework performed by someone outside of the day-to-day security operations. Security audits serve two purposes for the security practitioner. First, they point out areas where security controls are lacking, policy is not being enforced, or ambiguity exists in the security framework. The second benefit of security audits is that they emphasize security things that are being done right. Auditors, in general, should not be perceived as the "bad guys" that are out to prove what a bad job the organization is doing. On the contrary, auditors should be viewed as professionals who are there to assist the organization in driving the security program forward and to assist security practitioners in making management aware of what security steps are being correctly taken and what more needs to be done.

Business Flow Documentation

Although not exactly related to IT security, documentation that shows how business data flows through the network can be a great aid to auditors trying to understand how everything works. For example, how does order entry data flow through the system from when the order is taken until it is shipped out to the customer? What systems do data reside on, and how do data move around the network?

Ordered Audit

Although rare, there are times when a company is ordered by the courts to have a security audit performed.

Risk Avoidance

Another alternative to mitigate risk is to avoid the risk. Risk can be avoided by eliminating the entire situation causing the risk. This could involve disabling system functionality or preventing risky activities when risk cannot be adequately reduced. In drastic measures, it can involve shutting down entire systems or parts of a business.

Asset

Anything of value that is owned by an organization. Assets include both tangible items such as information systems and physical property and intangible assets such as intellectual property.

Baseline Security Configuration Documentation for Each Type of Host

As with the host configuration, this documentation does not just reflect the standard configuration data but specifically what steps are being done related to security.

Host Configuration Documentation

Auditors are going to want to see the documentation on how hosts are configured on the organization's network both to see that everything is covered and to verify that the configuration documentation actually reflects what is being done.

ISO/IEC 27002:2013

Code of Practice for Information Security Management." ISO/IEC 27002:2013 gives guidelines for organizational information security standards and information security management practices including the selection, implementation, and management of controls taking into consideration the organization's information security risk environment(s). It is designed to be used by organizations that intend to Select controls within the process of implementing an Information Security Management System based on ISO/IEC 27001 Implement commonly accepted information security controls Develop their own information security management guidelines

Communicating and Sharing Risk Assessment Information

Communicate the risk assessment results. Share information developed in the execution of the risk assessment to support other risk management activities.

Identifying Threat Sources

Determine sources for obtaining threat information Determine what threat taxonomy may be used Provide input or determine what threat information will be used in the overall assessment

Maintaining the Risk Assessment

Determine the effectiveness of risk responses. Identify risk-impacting changes to organizational information systems and the environments in which those systems operate. Verify compliance. includes the following specific tasks: Monitor risk factors identified in risk assessments on an ongoing basis and understand subsequent changes to those factors. Update the components of risk assessments reflecting the monitoring activities carried out by organizations.

Threat Source

Either intent and method targeted at the intentional exploitation of a vulnerability or a situation or method that may accidentally trigger a vulnerability.

CobIT (Control Objectives for Information and related Technology)

From the Information Systems Audit and Control Association (ISACA). With COBIT 5, ISACA introduced a framework for information security. It includes all aspects of ensuring reasonable and appropriate security for information resources. Its foundation is a set of principles upon which an organization should build and test security policies, standards, guidelines, processes, and controls: Meeting stakeholder needs Covering the enterprise end-to-end Applying a single integrated framework Enabling a holistic approach Separating governance from management

NIST SP 800-37 R1

Guide for Applying the Risk Management Framework to Federal Information Systems," which can be retrofitted for private industry. This publication provides guidelines for applying the Risk Management Framework (RMF) to federal information systems. The six-step RMF includes security categorization, security control selection, security control implementation, security control assessment, information system authorization, and security control monitoring. The RMF promotes the concept of near real-time risk management and ongoing information system authorization through the implementation of robust continuous monitoring processes; provides senior leaders the necessary information to make cost-effective, risk-based decisions with regard to the organizational information systems supporting their core missions and business functions; and integrates information security into the enterprise architecture and system development life cycle. Applying the RMF within enterprises links risk management processes at the information system level to risk management processes at the organization level through a risk executive (function) and establishes lines of responsibility and accountability for security controls deployed within organizational information systems and inherited by those systems (i.e., common controls).

Data Classification Documentation

How are data classified? Are there some data the organization should spend more effort on securing than others? Having data classification documentation comes in handy for justifying why some hosts have more security restrictions than others do.

Preparing for the Assessment

Identify the purpose of the assessment. Identify the scope of the assessment. Identify the assumptions and constraints associated with the assessment. Identify the sources of information to be used as inputs to the assessment. Identify the risk model and analytic approaches (i.e., assessment and analysis approaches) to be employed during the assessment.

Conducting the Assessment

Identify threat sources that are relevant to organizations. Identify threat events that could be produced by those sources. Identify vulnerabilities within organizations that could be exploited by threat sources through specific threat events and the predisposing conditions that could affect successful exploitation. Determine the likelihood that the identified threat sources would initiate specific threat events and the likelihood that the threat events would be successful. Determine the adverse impacts to organizational operations and assets, individuals, other organizations, and the Nation resulting from the exploitation of vulnerabilities by threat sources (through specific threat events). Determine information security risks as a combination of likelihood of threat exploitation of vulnerabilities and the impact of such exploitation, including any uncertainties associated with the risk determinations.

The risk register addresses risk management in four key steps:

Identifying the risk Evaluating the severity of any identified risks Applying possible solutions to those risks Monitoring and analyzing the effectiveness of any subsequent steps taken

Annual Audit

Most businesses perform a security audit on an annual basis as dictated by policy.

Risk Visibility and Reporting

Once assessed and quantified or qualified, risk should be reported and recorded. Organizations should have a way to aggregate risk in a centralized function that combines information security risk with other risk such as market risk, legal risk, human capital risk, and financial risk. The organizational risk executive function serves as a way to understand total risk to the organization. Risk is aggregated in a system called a risk register or, in some cases, a risk dashboard. The SSCP must ensure only risk information (not vulnerability or threat information) is reported to the risk register. The risk register serves as a way for the organization to know their possible exposure at a given time. The risk register will generally be shared with stakeholders, allowing them to be kept aware of issues and providing a means of tracking the response to issues. It can be used to flag new risks and to make suggestions on what course of action to take to resolve any issues. The risk register is there to help with the decision-making process and enables managers and stakeholders to handle risk in the most appropriate way. The risk register is a document that contains information about identified risks, analysis of risk severity, and evaluations of the possible solutions to be applied. Presenting this in a spreadsheet is often the easiest way to manage things so that key information can be found and applied quickly and easily.

Acceptable Use Documentation

Organizations often spell out acceptable use policies under the user responsibilities policy and the administrator use policy. Some also include it for particular hosts. For example, a company may say that there is to be no transfer of business confidential information over the FTP (File Transfer Protocol) server within the user policies and reiterate that policy both in an acceptable use policy for the FTP server as well as use it as a login banner for FTP services. As long as the message is the same, there is no harm in repeating it in several places.

What Does an Auditor Do?

Providing independent assurance to management that security systems are effective Analyzing the appropriateness of organizational security objectives Analyzing the appropriateness of policies, standards, baselines, procedures, and guidelines that support security objectives Analyzing the effectiveness of the controls that support security policies Stating and explaining the scope of the systems to be audited

Risk Acceptance

Residual risk can also be accepted by an organization. A risk acceptance strategy indicates that an organization is willing to accept the risk associated with the potential occurrence of a specific event. It is important that when an organization chooses risk acceptance, it clearly understands the risk that is present, the probability that the loss related to the risk will occur, and the cost that would be incurred if the loss were realized. Organizations may determine that risk acceptance is appropriate when the cost of implementing controls exceeds the anticipated losses.

Risk Treatment

Risk mitigation Risk transference Risk avoidance Risk acceptance

Risk Management Concepts

Risk, Likelihood, Threat Source, Threat, Vulnerability, Impact

High Risk

Significant risk to the organization and to the organizational mission exists. There is a strong need for corrective actions that include reevaluation of existing controls and implementation of additional controls. Corrective actions should be implemented as soon as possible to reduce risk to an acceptable level.

ISO/IEC 27001:2013

Specification for Information Security Management." ISO/IEC 27001:2013 specifies the requirements for establishing, implementing, maintaining, and continually improving an information security management system within the context of the organization. It also includes requirements for the assessment and treatment of information security risks tailored to the needs of the organization. The requirements set out in ISO/IEC 27001:2013 are generic and are intended to be applicable to all organizations, regardless of type, size, or nature.

Risk Determination

The likelihood of a threat source attempting to exploit a specific vulnerability The magnitude of the impact that would result if an attempted exploit were successful The effectiveness of existing and planned security controls in reducing risk

Impact

The magnitude of harm that could be caused by a threat's exercise of a vulnerability.

Determining Likelihood

The nature of the vulnerability, including factors such as: The operating system, application, database, or device affected by the vulnerability Whether local or remote access is required to exploit the vulnerability The skills and tools required to exploit the vulnerability The threat source's motivation and capability, including factors such as: Threat source motivational factors (e.g., financial gain, political motivation, revenge) Capability (skills, tools, and knowledge required to exploit a given vulnerability) The effectiveness of controls deployed to prevent exploit of the given vulnerability

Threat

The potential for a threat source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability.

Likelihood

The probability that a potential vulnerability may be exercised within the construct of the associated threat environment.

Identifying Vulnerabilities and Predisposing Conditions

The step allows for the identification of both technical and nontechnical vulnerabilities that, if exploited, could result in a compromise of system or data confidentiality, integrity, and availability. A review of existing documentation and reports is a good starting point for the vulnerability identification process. This review can include the results of previous risk assessments. It can also include a review of audit reports from compliance assessments, a review of security bulletins and advisories provided by vendors, and data made available via personal and social networking. NIST SP 800-30 R1 Appendix F provides a set of tables for using in identifying predisposing conditions and vulnerabilities. Vulnerability identification and assessment can be performed via a combination of automated and manual techniques. Automated techniques such as system scanning allow a security practitioner to identify technical vulnerabilities present in assessed IT systems. These technical vulnerabilities may result from failure to apply operating system and application patches in a timely manner, architecture design problems, or configuration errors. By using automated tools, systems can be rapidly assessed and vulnerabilities can be quickly identified.

Change Management Documentation

There are two different types of change management documentation needed to produce for auditors. The first one would be the policy outlining the change management process. The other would be documentation reflecting changes made to a host.

Event-Triggered Audit

These audits are often conducted after a particular event occurs, such as an intrusion incident. They are used both to analyze what went wrong and, as with all audits, to confirm due diligence if needed.

Merger/Acquisition Audit

These audits are performed before a merger/acquisition to give the purchasing company an idea of where the company they are trying to acquire stands on security in relation to their own security framework.

Regulation Compliance Audit

These audits are used to confirm compliance with the IT security-related portions of legislated regulations such as Sarbanes-Oxley and HIPAA.

What is the Audit Going to Cover?

User Domain—The users themselves and their authentication methods Workstation Domain—Often considered the end-user systems System/Application Domain—Applications that you run on your network, such as e-mail, database, and web applications LAN Domain—Equipment required to create the internal LAN LAN-to-WAN Domain—The transition area between your firewall and the WAN, often where your DMZ resides WAN Domain—Usually defined as things outside of your firewall Remote Access Domain—How remote or traveling users access your network Cloud and Outsourced Domain—In what areas has the organization outsourced data, processing, or transmission to other entities?

Disaster/Business Recovery Documentation

While some IT practitioners and auditors do not see this as part of a security audit, others feel that because the recovery process involves data recovery and system configuration, it is an important and often overlooked piece of information security.

Risk

a function of the likelihood of a given threat source's exercising a potential vulnerability, and the resulting impact of that adverse event on the organization.

Risk Assessment

assess threats to information systems, system vulnerabilities, and weaknesses, and the likelihood that threats will exploit these vulnerabilities and weaknesses to cause adverse effects. For example, a risk assessment could be conducted to determine the likelihood that an un-patched system connected directly to the Internet would be compromised. The risk assessment would determine that there is almost 100% likelihood that the system would be compromised by a number of potential threats such as casual hackers and automated programs. Although this is an extreme example, it helps to illustrate the purpose of conducting risk assessments.

Determining Impact

defines the impact to an organization that would result if a vulnerability were successfully exploited. An impact analysis cannot be performed until system mission, system and data criticality, and system and data sensitivity have been obtained and assessed. The system mission refers to the functionality provided by the system in terms of business or IT processes supported. System and data criticality refer to the system's importance to supporting the organizational mission. System and data sensitivity refer to requirements for data confidentiality and integrity. In many cases, system and data criticality and system and data sensitivity can be assessed by determining the adverse impact to the organization that would result from a loss of system and data confidentiality, integrity, or availability. Remember that confidentiality refers to the importance of restricting access to data so that they are not disclosed to unauthorized parties. Integrity refers to the importance that unauthorized modification of data is prevented. Availability refers to the importance that systems and data are available when needed to support business and technical requirements. When a person assesses each of these factors individually and aggregates the individual impacts resulting from a loss of confidentiality, integrity, and availability, the overall adverse impact from a system compromise can be assessed. Impact can be assessed in either quantitative or qualitative terms. A quantitative impact analysis assigns a dollar value to the impact. The dollar value can be calculated based on an assessment of the likelihood of a threat source exploiting a vulnerability, the loss resulting from a successful exploit, and an approximation of the number of times that a threat source will exploit a vulnerability over a defined period.

Annualized Loss Expectancy (ALE)

epresents the expected annual loss because of a risk to a specific asset. ALE is calculated by determining the SLE and then multiplying it by the Annualized Rate of Occurrence (ARO) as indicated by the formula: Annualized = Single Loss Expectancy x Annualized Rate of Occurrence

Identifying Potential Threat Events

needs to define these threat events with sufficient detail to accomplish the purpose of the risk assessment. Multiple threat sources can initiate a single threat event. Conversely, a single threat source can potentially initiate any of multiple threat events. Therefore, there can be a many-to-many relationship among threat events and threat sources that can potentially increase the complexity of the risk assessment. For each threat event identified, organizations need to determine the relevance of the event. The values selected by organizations have a direct linkage to organizational risk tolerance. The more risk averse, the greater the range of values considered. Organizations accepting greater risk or having a greater risk tolerance are more likely to require substantive evidence before giving serious consideration to threat events. If a threat event is deemed to be irrelevant, no further consideration is given. For relevant threat events, organizations need to identify all potential threat sources that could initiate the events.

Risk Mitigation

reduces risks to the organization by implementing technical, managerial, and operational controls. Controls should be selected and implemented to reduce risk to acceptable levels. When controls are selected, they should be selected based on their cost, effectiveness, and ability to reduce risk. Controls restrict or constrain behavior to acceptable actions. To help understand controls, look at some examples of security controls.

Single Loss Expectancy (SLE)

represents the expected monetary loss to an organization from a threat to an asset. SLE is calculated by determining the value of a particular asset (AV) and the approximated exposure factor (EF). EF represents the portion of an asset that would be lost if a risk to the asset was realized. EF is expressed as a percentage value where 0% represents no damage to the asset and 100% represents complete destruction of the asset. SLE is calculated by multiplying the AV by the EF as indicated by the formula: Single Loss Expectancy = Asset x Exposure Factor

Annualized Rate of Occurrence

represents the expected number of exploitations by a specific threat of a vulnerability to an asset in a given year.

Risk Management Process

the process of identifying risks, assessing their potential impacts to the organization, determining the likelihood of their occurrence, communicating findings to management and other affected parties, and developing and implementing risk mitigation strategies to reduce risks to levels that are acceptable to the organization. The first step in the risk management process is conducting a risk assessment.

Risk Transference

transfers risk from an organization to a third party. Some types of risk such as financial risk can be reduced by transferring it to a third party via a number of methods. The most common risk transference method is insurance. An organization can transfer its risk to a third party by purchasing insurance. When an organization purchases insurance, it effectively sells its risk to a third party. The insurer agrees to accept the risk in exchange for premium payments made by the insured. If the risk is realized, the insurer compensates the insured party for any incurred losses.