Like other life-cycle processes, risk management is a cyclical, iterative activity that is used to acquire, analyze, and treat risks. This book focuses on privacy risk, but overall the life cycle for privacy risk is functionally similar to that for information risk or even business risk: a new risk is introduced into the process, the risk is studied, and a decision is made about how to deal with it.

Like other life-cycle processes, risk management is formally defined in policy and process documents that define the scope, roles and responsibilities, workflow, business rules, and business records. Several frameworks and standards from US and international sources define the full life-cycle risk process. Privacy and security managers are generally free to adopt any of these standards, use a blend of different standards, or develop a custom framework.

Both privacy and information risk management rely upon risk assessments that consider valid threats against the organization’s information assets, considering any present vulnerabilities. Several standards and models for risk assessments can be used. The results of risk assessments are placed into a risk register, which is the official business record containing current and historic information risk items.

Risk treatment is the activity in which decisions about risks are made after weighing various options. Risk treatment decisions are typically made by a business owner associated with the affected business activity and ratified by an executive steering group.

The Risk Management Process

The risk management process consists of a set of structured activities that enable an organization to manage risks systematically. Like other business processes, risk management processes vary somewhat from one organization to the next, but generally they consist of the following activities:

•   Scope definition The organization defines the scope of the risk management process itself. Typically, scope definitions include geographic or business unit parameters. The scope definition is not part of the iterative portion of the risk management process, although scope may be redefined from time to time. In an organization’s privacy program, the scope should include

•   Business processes related to the collection, use, and transfer (or sale) of personal information

•   Information systems that support these processes

•   The work centers and processing centers supporting the information systems

•   Information security in support of these systems and processes

•   All of the aforementioned items that are outsourced to third parties

•   Asset identification and valuation The organization uses various means to discover and track its stored information (including personal information) and information system assets. A classification scheme may be present that identifies risk and criticality levels. Asset valuation is a key part of asset management processes, and the value of assets is appropriated for use in the risk management process.

•   Risk appetite Developed outside of the risk management life-cycle process, risk appetite is an expression of the level of risk that an organization is willing to accept. A risk appetite that is related to information and privacy risk is typically expressed in qualitative means.

•   Risk identification This is the first step in the iterative portion of the risk management process, when the organization identifies a risk that comes from one of several sources, including the following:

•   Risk assessment This includes an overall risk assessment or a focused risk assessment.

•   Privacy impact assessment (PIA) This is an analysis of how personally identifiable information (PII) is collected, used, shared, and maintained as part of planned changes to a business process or information system to identify any changes in privacy risk.

•   Data protection impact assessment (DPIA) This is an analysis of how planned changes to a business process or information system will impact an organization’s ability to protect specific types of data (such as PII).

•   Vulnerability assessment This may be one of several activities, including a security scan, a penetration test, or a source code scan.

•   Threat advisory An advisory may be issued from a product vendor, threat intelligence feed, or news story.

•   Internal audit A routine internal audit may reveal a weakness in a business process that warrants attention in the risk management process.

•   Control self-assessment (CSA) The self-assessment of an internal control may identify a weakness that needs to be managed in the risk management process.

•   Change in regulations A new privacy regulation, a change in an existing regulation, or a precedent set in the enforcement or in legal proceedings may compel organizations to see their processes in a new light. Occasionally, this means that a process or control once thought to be compliant (or secure) may need to be revised.

•   Risk analysis This analysis is focused on information that may uncover additional risks that require attention.

•   Incident A security or privacy incident may reveal risks, whether associated with the incident or not. Though this is sometimes a matter of risk identification in hindsight, such risks cannot be overlooked.

•   Risk analysis This is the second step in a typical risk management process, including a PIA or DPIA. After the risk has been identified, it is analyzed to determine several characteristics, including the following:

•   Probability of event occurrence The risk analyst studies event scenarios and calculates the likelihood that an event associated with the risk will occur. This is typically expressed as the number of likely events per year.

•   Impact of event occurrence The risk analyst studies different event scenarios and determines the impact of each. This may be expressed in quantitative terms (dollars or other currency) or qualitative terms (high–medium–low or a numeric scale of 1–5 or 1–10).

•   Mitigation The risk analyst studies different available methods for mitigating the risk. Depending upon the type of risk, there are many techniques to choose from, including changing a process or procedure, training staff, changing architecture or configuration, or applying a security patch.

•   Recommendation After studying a risk, the risk analyst may develop a recommended course of action to address the risk. This reflects the fact that the individual performing risk analysis is often not the risk decision-maker.

•   Risk treatment This is the last step in a typical risk management process. Here, the privacy steering committee (or appropriate authoritative group) makes or approves a decision about a specific risk. The basic options for risk treatment are

•   Accept The organization elects to take no action related to the risk.

•   Mitigate The organization chooses to mitigate the risk, which takes the form of some action that serves to reduce the probability or impact of a risk event. The actual steps taken may include business process changes, system configuration changes, the enactment of a new control, or staff training.

•   Transfer The practice of transferring risk is typically achieved through an insurance policy, although other forms are available, including contract assignment.

•   Avoid The organization chooses to discontinue the activity associated with the risk. This is typically selected for an outdated business activity that is no longer profitable or for a business activity that was not formally approved in the first place.

•   Risk communication This takes many forms, including formal communications within risk management processes and procedures, as well as information communications among risk managers and decision-makers.

In addition to business processes, a risk management process has business records associated with it. The risk register, sometimes known as a risk ledger, is the primary business record in most risk management programs. A risk register is a listing of risks that have been identified and typically contains many items, including a description of each risk, the level and type of each risk, and information about risk treatment decisions.

Figure A-1 shows the elements of a typical risk management life cycle.

Figure A-1 The risk management life cycle

Risk Management Methodologies

Several established methodologies are available for organizations that want to manage risk using a formal standard. Organizations select one of these standards for a variety of reasons: they may be required to use a specific standard to address regulatory or contractual terms, they may believe that a specific standard better aligns with their overall information risk program or the business as a whole, or they may want to start with a known standard process as opposed to creating one from scratch.

NIST Standards

The National Institute for Standards and Technology (NIST) develops standards for information security and other subject matter. NIST Special Publication (SP) 800-39, Managing Information Security Risk: Organization, Mission, and Information, System View, describes the overall risk management process. NIST SP 800-30, Guide for Conducting Risk Assessments, is a detailed, high-quality standard that describes the steps for conducting risk assessments. The NIST Risk Management Framework (RMF) is a process framework that encompasses the entire risk management life cycle.

NIST SP 800-39

The methodology described in NIST SP 800-39 consists of multilevel risk management, at the information systems level, at the mission/business process level, and at the overall organization level. Risks are communicated up the levels for overall awareness, while risk awareness and risk decisions are communicated downward for overall awareness. Figure A-2 depicts this approach.

Figure A-2 Multi-tier risk management in NIST SP 800-39 (Source: National Institute for Standards and Technology)

The tiers of risk management are described in NIST SP 800-39 in this way:

•   Tier 1: Organization view This level focuses on the role of governance, the activities performed by the risk executive, and the development of risk management and investment strategies.

•   Tier 2: Mission/business process view This level is all about enterprise architecture and enterprise security architecture, and ensuring that business processes are risk-aware.

•   Tier 3: Information systems view This level concentrates on more tactical things such as system configuration and hardening specifications, vulnerability management, and the detailed steps in the systems development life cycle.

Other concepts discussed in NIST SP 800-39 include trust, the trustworthiness of systems, and organizational culture.

The overall risk management process defined by NIST SP 800-39 consists of several steps:

•   Step 1: Risk framing This consists of the assumptions, scope, tolerances, constraints, and priorities—in other words, the business context that is considered prior to later steps taking place.

•   Step 2: Risk assessment This is the actual risk assessment, where threats and vulnerabilities are identified and assessed to determine levels and types of risk.

•   Step 3: Risk response This is the process of analyzing each risk and developing strategies for reducing it through appropriate risk treatment for each identified risk. Risk treatment options are accept, mitigate, avoid, and transfer. This step is defined in more detail in NIST SP 800-30, described next.

•   Step 4: Risk monitoring This is the process of performing periodic and ongoing evaluation of identified risks to determine whether conditions and risks are changing.

NIST SP 800-30

NIST SP 800-30 describes in greater detail a standard methodology for conducting a risk assessment. The techniques included in this document are quite structured and essentially involve setting up a number of worksheets where threats and vulnerabilities are recorded, along with the probability of occurrence and impact if they occur.

In this standard, these are the steps for conducting a risk assessment:

•   Step 1: Prepare for assessment The organization determines the purpose of the risk assessment. Primarily, it is important to know the purpose of the results of the risk assessment and the decisions that will be made as a result of the risk assessment. Next, the scope of the assessment must be determined and known. This may take many forms, including geographic and business unit boundaries or specific business processes, as well as the range of threat scenarios that are to be included. Also, any assumptions and constraints pertaining to the assessment should be identified. Further, the sources of threat, vulnerability, and impact information must be identified. (NIST SP 800-30 includes exemplary lists of threats, vulnerabilities, and impacts in its appendixes.)

•   Step 2: Conduct assessment The organization performs the actual risk assessment. This consists of several tasks.

a)   Identify threat sources and events. The organization identifies a list of threat sources and events that will be considered in the assessment. The following sources of threat information are included in the standard and can be used. Organizations are advised to supplement these sources with other information as needed.

•   Table D-1: Inputs—threat source identification

•   Table D-2: Taxonomy of threat sources

•   Table D-3: Assessment scale—characteristics of adversary capabilities

•   Table D-4: Assessment scale—characteristics of adversary intent

•   Table D-5: Assessment scale—adversary targeting

•   Table D-6: Assessment scale—non-adversarial threat effects

•   Table D-7: Template—Identification of adversarial threat sources (organization-specific table to be completed by risk manager)

•   Table D-8: Template—Identification of non-adversarial threat sources (organization-specific table to be completed by risk manager)

•   Table E-1: Inputs—Threat event identification

•   Table E-2: Representative examples—adversarial threat events

•   Table E-3: Representative examples—non-adversarial threat events

•   Table E-4: Relevance of threat events

•   Table E-5: Template—Identification of threat events (organization-specific table to be completed by risk manager)

b)   Identify vulnerabilities and predisposing conditions. The organization examines its environment (people, processes, and technology) to determine what vulnerabilities exist that could result in a greater likelihood that threat events may occur. The following sources of vulnerability and predisposing condition information are included in the standard and can be used in a risk assessment. Like the catalog of threats, organizations are advised to supplement these lists with additional vulnerabilities as needed.

•   Table F-1: Inputs—vulnerability and predisposing conditions

•   Table F-2: Assessment scale—vulnerability severity

•   Table F-3: Template—Identification of organization-specific vulnerabilities

•   Table F-4: Taxonomy of predisposing conditions

•   Table F-5: Assessment scale—pervasiveness of predisposing conditions

•   Table F-6: Template—Identification of predisposing conditions (organization-specific table to be completed by risk manager)

c)   Determine the likelihood of occurrence. The organization determines the probability that each threat scenario identified will occur. The following tables guide the risk manager in scoring each threat:

•   Table G-1: Inputs—determination of likelihood

•   Table G-2: Assessment scale—likelihood of threat event initiation (adversarial)

•   Table G-3: Assessment scale—likelihood of threat event occurrence (non-adversarial)

•   Table G-4: Assessment scale—likelihood of threat event resulting in adverse impacts

•   Table G-5: Assessment scale—overall likelihood

d)   Determine the magnitude of impact. In this phase, the risk manager determines the impact of each type of threat event on the organization. These tables guide the risk manager in this effort:

•   Table H-1: Inputs—determination of impact

•   Table H-2: Examples of adverse impacts

•   Table H-3: Assessment scale—impact of threat events

•   Table H-4: Template—Identification of adverse impacts (organization-specific table to be completed by risk manager)

e)   Determine the risk level. The organization determines the level of risk for each threat event. These tables aid the risk manager in this effort:

•   Table I-1: Inputs—risk

•   Table I-2: Assessment scale—level of risk (combination of likelihood and impact)

•   Table I-3: Assessment scale—level of risk

•   Table I-4: Column descriptions for adversarial risk table

•   Table I-5: Template—adversarial risk (organization-specific table to be completed by risk manager)

•   Table I-6: Column descriptions for non-adversarial risk table

•   Table I-7: Template—non-adversarial risk (organization-specific table to be completed by risk manager)

•   Step 3: Communicate results When the risk assessment has been completed, the results are communicated to decision-makers and stakeholders in the organization. The purpose of communicating risk assessment results is to ensure that the organization’s decision-makers make decisions that include considerations for known risks. Risk assessment results can be communicated in several ways, including the following:

•   Publishing to a central location

•   Briefings

•   Distributing via e-mail

•   Distributing hard copies

•   Step 4: Maintain assessment After a risk assessment has been completed, the organization will maintain the assessment by monitoring risk factors identified in the risk assessment. This enables the organization to maintain a view of relevant risks that incorporates changes in the business environment since the risk assessment was completed. NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations, provides guidance on the ongoing monitoring of information systems, operations, and risks.

NIST Risk Management Framework (RMF)

The NIST RMF is a high-level, repeatable process for managing the entire risk management life cycle. The methodology described in NIST RMF consists of these seven activities:

•   Prepare Participate in activities and take steps to help the organization prepare to identify and manage security and privacy risks.

•   Categorize Determine the security categorization of information systems, based upon the nature of the information they store, process, or transmit. This is akin to the concept of system classification.

•   Select Identify, tailor, and document controls required to protect information and information systems based on risk. These controls may be selected from NIST SP 800-53 or another control framework as needed.

•   Implement Implement the controls identified in the Select step. Update security plans accordingly.

•   Assess Determine the effectiveness of controls. Often this is accomplished through control self-assessment, internal audit, or an assessment performed by an outside party. Remediation plans are developed and assigned for identified deficiencies.

•   Authorize This is a formal management sign-off on risks and risk mitigation identified in earlier steps.

•   Monitor Continually monitor risks, threats, and controls to remain aware of the system’s security and privacy postures.

ISO/IEC 27005

ISO/IEC 27005, Information technology – Security techniques – Information security risk management, is an international standard that defines a structured approach to risk assessments and risk management. The methodology outlined in this standard is summarized here:

Step 1: Establish Context

Before the risk analyst can perform a risk assessment, a number of parameters need to be established, including the following:

•   Scope of the risk assessment This includes which portions of an organization are to be included, based on business unit, service, line, geography, organization structure, or other means.

•   Purpose of the risk assessment Reasons include legal or due diligence or support of an information security management system (ISMS), business continuity plan, vulnerability management plan, or incident response plan.

•   Risk evaluation criteria Determine the means by which risks will be examined and scored.

•   Impact criteria Determine how the impact of identified risks will be described and scored.

•   Risk acceptance criteria Specify the method the organization will use to determine risk acceptance.

•   Logistical plan This includes which personnel will perform the risk assessment, which personnel in the organization need to provide information such as control evidence, and what supporting facilities are required, such as office space.

Step 2: Risk Assessment

The risk assessment is performed with the following tasks:

•   Asset identification Risk analysts identify assets, along with their value and criticality.

•   Threat identification Risk analysts identify relevant and credible threats that have the potential to harm assets, along with their likelihood of occurrence. There are many types of threats, both naturally occurring and human-caused, and accidental or deliberate. Note that some threats may affect more than one asset. ISO/IEC 27005 contains a list of threat types, as does NIST SP 800-30 (in Table D-2), described earlier.

•   Control identification Risk analysts identify existing and planned controls. Those controls that already exist should be examined to determine whether they are effective. The criteria for examining a control includes whether it adequately reduces the likelihood or impact of a threat event. The results of this examination will conclude whether the control is effective, ineffective, or unnecessary. Finally, when identifying threats, the risk analyst may determine that a new control is warranted.

•   Vulnerability identification Vulnerabilities that can be exploited by threat events that cause harm to an asset are identified. Remember that a vulnerability does not cause harm, but its presence may enable a threat event to harm an asset. ISO/IEC 27005 contains a list of vulnerabilities. Note that a risk analyst may need to identify additional vulnerabilities.

•   Consequences identification The risk analyst will identify consequences that would occur for each identified threat against each asset. Consequences may include the loss of confidentiality, integrity, or availability of any asset, as well as the loss of human safety. Depending on the nature of the asset, consequences may take many forms, including service interruption or degradation, reduction in service quality, loss of business, reputation damage, or monetary penalties, including fines. Note that consequences may be a primary result or a secondary result of the realization of a specific threat. For example, the theft of sensitive financial information may have little or no operational impact in the short term, but legal proceedings over the long term could result in financial penalties, unexpected costs, and loss of business.

Step 3: Risk Evaluation

Levels of risk are determined according to the risk evaluation and risk acceptance criteria established in step 1. The output of risk evaluation is a list of risks, with their associated threats, vulnerabilities, and consequences.

Step 4: Risk Treatment

Decision-makers in the organization will select one of four risk treatment options for each risk identified in step 3:

•   Risk reduction (aka risk mitigation) The organization alters something in information technology (such as security configuration, application source code, or data), business processes and procedures, or personnel (such as training).

In many cases, an organization will choose to update an existing control or enact a new control so that the risk reduction may be more effectively monitored over time. The cost of updating or creating a control—as well as the impact on ongoing operational costs of the control—will need to be weighed alongside the value of the asset being protected, as well as the consequences associated with the risk being treated. A risk manager remembers that a control can reduce many risks, and potentially for several assets, so the risk manager will need to consider the benefit of risk reduction in more complex terms. Chapter 2 covers a brief discussion of the types of controls. A more complete discussion of controls appears in CISM Certified Information Security Manager All-In-One Exam Guide.

•   Risk retention (aka risk acceptance) The organization chooses to accept the risk and decides not to change anything.

•   Risk avoidance The organization decides to discontinue the activity associated with the risk. For example, an organization assesses the risks related to the acceptance of credit card data for payments and decides to change the system so that credit card data is sent directly to a payment processor so that the organization will no longer be accepting credit card data.

•   Risk transfer The organization transfers risk to another party. Common forms of risk transfer are securing insurance and outsourcing security monitoring to a third party. When an organization transfers risk to another party, there will usually be residual risk that is more difficult to treat. For example, although an organization may have reduced the costs of a breach because it had previously secured cyber insurance, the organization may still suffer reputational damage in the form of reduced goodwill.

Decision-makers weigh the costs and benefits associated with each of these four options and decide the best course of action for the organization. These four risk treatment options are not mutually exclusive; sometimes, a combination of risk treatment options may be the best choice for a specific situation. For instance, if a business application was found to accept weak passwords, the chosen risk treatment may be a combination of security awareness training (mitigation) and acceptance (the organization elected not to modify the application because this would have been too expensive).

Further, some treatments can address more than one risk. For example, security awareness training may reduce several risks associated with end-user computing and behavior.

Often, after risk treatment, some risk—known as residual risk—remains. When analyzing residual risk, the organization may elect to undergo additional risk treatment to reduce the risk further, or it may accept the residual risk as is. Note that residual risk cannot be reduced to zero—there will always be some level of risk.

Because some forms of risk treatment (mainly, risk reduction and risk transfer) may require an extended period of time to be completed, risk managers usually track ongoing risk treatment activities to completion.

Step 5: Risk Communication

All parties involved in information risk—the chief information security officer (CISO) or another top-ranking information security official, risk managers, business decision-makers, and other stakeholders—need channels of communication throughout the entire risk management and risk treatment life cycle. Examples of risk communication include the following:

•   Announcements and discussions of upcoming risk assessments

•   Collection of risk information during risk assessments (and at other times)

•   Proceedings and results from completed risk assessments

•   Discussions of risk tolerance

•   Proceedings from risk treatment discussions and risk treatment decisions and plans

•   Educational information about security and risk

•   Updates to the organization’s mission and strategic objectives

•   Communication about security incidents to affected parties and stakeholders

Step 6: Risk Monitoring and Review

Organizations are not static, and neither is risk. The value of assets, impacts, threats, and vulnerabilities and the likelihood of risk occurrence should be periodically monitored and reviewed so that the organization’s view of risk continues to be relevant and accurate. Monitoring should include

•   Discovery of new, changed, and retired assets

•   Change in business processes and practices

•   Changes in technology architecture

•   Presence of new threats that have not been assessed

•   Presence of new vulnerabilities that were previously unknown

•   Changes in threat event probability and consequences

•   Security incidents that may alter the organization’s understanding of threats, vulnerabilities, and risks

•   Changes in market and other business conditions

•   Changes in applicable laws and regulations

Factor Analysis of Information Risk

Factor Analysis of Information Risk (FAIR) is an analysis method that helps a risk manager understand the factors that contribute to risk, the probability of threat occurrence, and an estimation of potential losses. In the FAIR methodology, there are six types of loss:

•   Productivity Loss of productivity caused by the incident

•   Response Cost expended in incident response

•   Replacement Expense required to rebuild or replace an asset

•   Fines and judgments All forms of legal costs resulting from the incident

•   Competitive advantage Loss of business to other organizations

•   Reputation Loss of goodwill and future business

FAIR also focuses on the concept of asset value and liability. For example, a customer list is an asset because the organization can reach its customers to solicit new business; however, the customer list is also a liability because of the impact on the organization if the customer list is obtained by an unauthorized person.

FAIR guides a risk manager through an analysis of threat agents and the different ways in which a threat agent acts upon an asset:

•   Access Threat agent reads data without authorization

•   Misuse Threat agent uses an asset differently from its intended usage

•   Disclose Threat agent shares data with other unauthorized parties

•   Modify Threat agent modifies asset

•   Deny use Threat agent prevents legitimate subjects from accessing assets

FAIR is considered to be complementary to risk management methodologies such as NIST SP 800-30 and ISO/IEC 27005.

Asset Identification

After a risk assessment’s scope has been determined, the initial step in a risk assessment is the identification of assets and a determination of each asset’s value. In a typical information risk assessment, assets will consist of various types of information (including intellectual property, internal operations, and personal information), the information systems that support and protect those information assets, and the business processes that are supported by these systems.

Hardware Assets

Hardware assets may include server and network hardware, user workstations, office equipment such as printers and scanners, and Wi-Fi access points. Depending on the scope of the risk assessment, assets in storage and replacement components may also be included.

Because hardware assets are installed, moved, and eventually retired, it is important to verify the information in the asset inventory periodically by physically verifying the existence of the physical assets. Depending upon the value and sensitivity of systems and data, this inventory “true-up” may be performed as often as monthly or as seldom as annually. Discrepancies in actual inventory must be investigated to verify that assets have not been stolen or moved without authorization.

Subsystem and Software Assets

Software applications such as software development tools, drawing tools, security scanning tools, and subsystems such as application servers and database management systems are all considered assets. Like physical assets, these assets often have tangible value and should be periodically inventoried.

Cloud-Based Information Assets

One significant challenge related to information assets lies in the nature of cloud services and how they work. An organization may have a significant portion of its information assets stored by other organizations in their cloud-based services. Unless an organization has exceedingly good business records, some of these assets will be overlooked, mainly because of the ways in which cloud services work. It’s easy to sign up for a zero-cost or low-cost service and immediately begin uploading business information to the service. Unless the organization has advanced tools such as a cloud access security broker (CASB), it will be next to impossible for an organization to know all of the cloud-based services that are used.

Virtual Assets

Virtualization technology, which enables an organization to employ multiple, separate operating systems to run on one server, is a popular practice for organizations, whether on their own hardware servers located in their own data centers or in hosting facilities. Organizations employing infrastructure as a service (IaaS) are also employing virtualization technology.

Information Assets

Information assets are less tangible than hardware assets, as they are not easily observed. Information assets take many forms:

•   Personal information Most organizations store information about people, whether they are employees, customers, constituents, beneficiaries, or citizens. This data may include sensitive information such as contact information and personal details, transactions, order histories, and other items.

•   Intellectual property This type of information can take the form of trade secrets, source code, product designs, policies and standards, and marketing collateral.

•   Business operations This generally includes merger and acquisition information and other types of business processes and records.

•   Virtual machines Most organizations are moving their business applications to the cloud, thereby eliminating the need to purchase hardware. Organizations that use IaaS have virtual operating systems, which are another form of information. Even though these operating systems are not purchased but instead are rented, there is nonetheless an asset perspective: they take time to build and configure and therefore have a replacement cost. The value of assets is discussed more fully later in this section.

Asset Classification

Asset classification is an activity whereby an organization assigns an asset to a category that represents usage or risk. The purpose of asset classification is to determine, for each asset, its level of criticality to the organization. In an organization with a formal privacy program, asset classification will include one or more classifications for assets related to personal information.

Criticality can be related to information sensitivity. For instance, a database of customers’ personal information that includes contact and payment information would be considered highly sensitive and, in the event of compromise, could result in significant impact to present and future business operations.

Criticality can also be related to operational dependency. For example, a database of virtual server images may be considered highly critical. If an organization’s server images were to be compromised or lost, this could adversely affect the organization’s ability to continue its information processing operations.

These and other measures of criticality form the basis for information protection, system redundancy and resilience, business continuity planning, and access management. Scarce resources in the form of information protection and resilience need to be allocated to the assets that require it the most. It doesn’t usually make sense to protect all assets to the same degree—the more valuable, sensitive, and critical assets should be protected more securely than those that are less valuable and critical.

Data Classification

Data classification is a process whereby different sets and collections of data in an organization are analyzed for various types of sensitivity, criticality, integrity, and value. There are different ways to understand these characteristics. These are some examples:

•   Personal information This type of information is most commonly associated with natural persons. Examples include personal contact information, employment records, medical records, and personal financial data such as credit card and bank account numbers.

•   Sensitive information Information other than personal information can also be considered sensitive, including intellectual property, nonpublished financial records, merger and acquisition information, and strategic plans.

•   Operational criticality In this category, information must be available at all times, or perhaps the information is related to some factors of business resilience. Examples of information in this category include virtual server images, incident response procedures, and business continuity procedures. Corruption or loss of this type of information may have a significant impact on ongoing business operations.

•   Accuracy or integrity Information in this category is required to be highly accurate. If altered, the organization could suffer significant financial or reputational harm. Types of information include exchange rate tables, product or service inventory data, machine calibration data, and price lists. Corruption or loss of this type of information impacts business operations by causing incomplete or erroneous transactions.

•   Monetary value This information may be more easily monetized by intruders who steal it. Types of information include credit card numbers, bank account numbers, gift certificates or cards, and discount or promotion codes. Loss of this type of information may result in direct financial losses.

Most organizations store information that falls into all of these categories, with degrees of importance within them. Although this may result in a complex matrix of information types and degrees of importance or value, the most successful organizations will build a fairly simple data classification scheme. For instance, an organization may develop four levels of information classification, such as Public, Confidential, Regulated, and Secret.

Asset Valuation

A key part of a risk assessment is the identification of the value of an asset. In the absence of an asset’s value, it is more difficult to calculate risks associated with an asset, even when qualitative risk valuation is employed. Without a known valuation, the impact of loss is more difficult to determine.

Qualitative Asset Valuation

Because many risk assessments are qualitative in nature (as discussed later in the section “Qualitative Risk Analysis”), establishing asset valuation in qualitative terms is common. Instead of assigning a dollar (or other currency) value figure to an asset, the value of an asset can be assigned to a low–medium–high scale or to a numeric scale such as 1–5 or 1–10.

The objective of qualitative asset valuation is to establish which assets have more value than others. Qualitative valuation enables an organization to determine which assets have greater value and which have less value. This can be highly useful in an organization with a lot of assets, because it can provide a view of its high-value assets without the “noise” of comingled lower valued assets. In a privacy program, qualitative valuation can help identify assets associated with the processing of personal information.

Quantitative Asset Valuation

Many organizations opt to surpass qualitative asset valuation and assign a dollar (or other currency) valuation to assets. This is common in larger or more mature organizations that want to understand the actual costs that may be associated with loss events.

In a typical quantitative valuation, an asset’s value may be determined by one of the following:

•   Replacement cost If the asset is a hardware asset, its valuation may be determined by the cost of purchasing (and deploying) a replacement. If the asset is a database, its cost may be determined by the operational costs required to restore it from backup or the costs to recover it from its source, such as a service provider.

•   Book value This represents the value of an asset in the organization’s financial system, typically the purchase price less depreciation.

•   Net present value (NPV) If the asset directly or indirectly generates revenue, this valuation method may be used.

•   Redeployment cost If the asset is a virtual machine, its valuation may be determined by the cost of setting it up again. This is typically a soft cost if it is set up by internal staff, but it could be a hard cost if another company is hired to redeploy it.

•   Creation or reacquisition cost If the asset is a database, its cost may be determined by the cost of re-creating it. If the asset is intellectual property such as software source code, its valuation may be determined according to the effort required for developers to re-create it.

•   Consequential financial cost If the asset is a database containing personal information, its valuation may be measured in the form of financial costs that result from its theft or compromise. Although the cost of recovering that database may be relatively low, the consequences of its compromise could cost hundreds of dollars per record. This is a typical cost when measuring the full impact of a privacy breach.

Risk managers must carefully determine the appropriate method for setting the value of each asset. Determining the value may be fairly straightforward or difficult. In many cases, an individual asset will have more than a single valuation category. For example, a credit card database may be valued primarily on its consequential cost (because of the potential fines plus remediation costs associated with consumers who may have been harmed) and also on redeployment costs, although this may be a small fraction of the total valuation.

Risk managers should document their rationale and method of valuation, particularly for sensitive and personal information assets whose valuations could vary widely depending on the method used. Better yet, larger and more mature organizations will have guidelines that specify methods and formulas to be used in information asset valuation.

Threat Identification

Threat identification is a key step in a risk assessment. A threat is defined as an event that, if realized, would bring harm to an asset and, thus, to the organization.

In the privacy and cybersecurity industries, the key terms involved with risk assessments are often misunderstood and misused. These terms are distinguished from one another in this way: A threat is an actual action that would cause harm, not the person or group (generically called an actor or threat actor) associated with it. A threat is not a weakness that may permit a threat to occur; this is known as a vulnerability.

Threats are typically classified as external or internal, as intentional or unintentional, and as human-made or natural. The origin of many threats is outside the control of the organization but not necessarily outside of its awareness. A good privacy or security manager can develop a list of privacy- and security-related threats that are likely (more or less) to occur to any given asset.

When performing a risk assessment, the risk manager needs to develop a complete list of threats for use in the assessment. Because it’s not always possible for a risk manager to memorize all possible threats, the security manager may turn to one or more well-known sources of threats, including the following:

•   ISO/IEC 27005, Appendix C, “Examples of Typical Threats”

•   NIST SP 800-30, Appendix E, “Threat Events”

Upon capturing threat events from one or both of these sources, the risk manager may well identify a few additional threats not found in these lists. These additional threats may be specific to the organization’s location, business model, or other factors. A risk manager will typically remove a few of the threats from the list that do not apply to the organization. For instance, an organization located far inland is not going to be directly affected by tsunamis or hurricanes, so this threat source can be eliminated.

Internal Threats

Internal threats originate within the organization and are most often associated with employees. Quite possibly, internal employees may be the intentional actors behind these threats. This is generally known as an insider threat.

Privacy managers need to understand the nature of internal threats and the interaction between personnel and information systems. A wide range of events can take place that constitutes threats, including the following:

•   Well-meaning personnel making errors in judgment

•   Well-meaning personnel making errors in haste

•   Well-meaning personnel making errors because of insufficient knowledge or training

•   Well-meaning personnel being tricked into doing something harmful

•   Disgruntled personnel being purposefully negligent or reckless

•   Disgruntled personnel deliberately bringing harm to an asset

•   A trusted individual in a trusted third-party organization doing any of these

After understanding all the ways that something can go wrong, privacy and security managers may sometimes wonder whether things can ever proceed as planned!

A privacy manager must understand this important concept: While employees are at the top of a short list of potential threat actors, employees also need to be given broad access to sensitive data so that they can do their jobs and help the organization function. Although there have been marginal improvements in technologies such as data loss prevention (DLP), employers must trust their employees by giving them access to large sets of valuable information, with the hope that the employees will not accidentally or deliberately abuse those privileges with potential to cause the organization great harm.

Here are some examples of “employees gone rogue”:

•   A disgruntled internal auditor discloses salary and other personal information relating to 100,000 staff members at a large supermarket chain in an attempt to frame a colleague.

•   A consulting firm for a large insurer finds that one of its consultants, who was discovered to be involved in identity theft, has e-mailed a file with more than 18,000 Medicare member details to his personal e-mail account.

•   An engineer at a cloud services company breaks into and exposes millions of customer records at a large bank.

•   A systems administrator at an intelligence agency acquires and leaks thousands of classified documents to the media.

A significant factor in employees gone rogue is access control policy and access management practices, which result in individual employees having access to more information than is prudent. That said, increasing the granularity of access controls is known to be time-consuming and costly, and it increases the friction of doing business; few organizations tolerate this despite identified risks.

The following list includes internal and external threats caused by humans that may be included in an organization’s risk assessment:

It may be useful to build a short list of threat actors (the people or groups that may initiate a threat event), but remember that these actors are not the threats themselves. Building such a list may help the security manager identify additional threat events that may not be on the list.

The following list shows internal and external natural threats:

External Threats

External threats originate outside of the organization. Like internal threats, they can include both deliberate and accidental actions and can be manmade or associated with naturally occurring events.

The security manager performing a risk assessment needs to understand the full range of threat actors, along with motivations. This is particularly important for organizations in which specific types of threat actors or motivations are more common. For example, certain industries such as aerospace and weapons manufacturers attract industrial espionage and intelligence agencies, and certain industries attract hacktivists.

The following lists show external threat actors:

Here are some of their motivations:

In a risk assessment, the assessor must identify all threats that have a reasonable likelihood of occurrence; this is critical. Threats that are unlikely because of geographic and other conditions are usually excluded. For example, hurricanes can be excluded in locations far from oceans, and earthquakes and volcanos can be excluded in locations where these are not known to occur. Threats such as falling meteorites and space debris are rarely included in risk assessments because of the minute chance of their occurrence.

Advanced Persistent Threats

An advanced persistent threat (APT) is a particular type of threat actor, so named in the early 2000s to describe a new kind of adversary that worked slowly but effectively to compromise a target organization. Whether perpetrated by an individual or a cybercriminal organization, an APT involves techniques that indicate resourcefulness, patience, and resolve. Rather than employing a “hit-and-run” or “smash-and-grab” operation, an APT actor will patiently perform reconnaissance on a target and use tools to infiltrate the target and build a long-term presence there.

APT is defined by NIST SP 800-39 as follows:

An APT is an adversary that possesses sophisticated levels of expertise and significant resources that allow it to create opportunities to achieve its objectives using multiple attack vectors (e.g., cyber, physical, and deception). These objectives typically include establishing and extending footholds within the IT infrastructure of the targeted organizations for purposes of exfiltrating information, undermining or impeding critical aspects of a mission, program, or organization; or positioning itself to carry out these objectives in the future. The advanced persistent threat: (i) pursues its objectives repeatedly over an extended period of time; (ii) adapts to defenders’ efforts to resist it; (iii) is determined to maintain the level of interaction needed to execute its objectives.

Prior to APTs, threat actors primarily conducted operations that ran for short periods of time—a few days at most. But as more organizations put more valuable information assets online, threat actors became craftier and more resourceful; they resorted to longer term campaigns to study a target for long periods of time before attacking it. Once an attack began, it would persist for months or longer. APTs would compromise multiple systems inside the target organization and use a variety of stealthy techniques to establish and maintain a presence using as many compromised targets as possible. Once an APT was discovered (if it is ever discovered), the security manager would clean up the compromised target, often unaware that the APT had compromised many other targets using different techniques.

This cat-and-mouse game could continue for months or even years, with the adversary continuing to compromise targets and study the organization’s systems—all the while searching for specific targets—while the security manager and others would continually chase the adversary around like the carnival game of “whack a mole.”

Emerging Threats

The cyberwarfare theater of today is constantly changing and evolving. Several forces (see Table A-1) are at work and continually push the envelope in the areas of attack techniques as well as defense techniques.

The subject of emerging threats should be considered a continuing phenomenon of new techniques rather than as a fixed set of techniques. Often, the latest techniques are difficult to detect because they fall outside the span of attack techniques that one expects to observe from time to time. Emerging threats represent the cutting edge of attack techniques that are difficult to detect and/or remediate when they are discovered. But these threats will eventually become routine, and even newer threat techniques will emerge. Privacy and security managers need to understand that, even as defensive technologies improve to help prevent and/or detect attacks of increasing sophistication, attack techniques will continuously improve in their ability to evade detection by even the most sophisticated defense techniques.

Table A-1 The Cascade of Emerging Threat

Vulnerability Identification

The identification of vulnerabilities is an essential part of any risk assessment. A vulnerability is any weakness in a process or system that permits an attack to compromise a target process or system successfully. In the privacy and security industries, two key terms involved with risk assessments are often misunderstood and misused: vulnerability and threat. These terms are distinguished from one another in this way: A vulnerability is the weaknesses in a system that could permit an attack to occur. A vulnerability is not the attack vector or technique—this is known as a threat.

Vulnerabilities usually take one of these forms:

•   Configuration fault A system, program, or component with configuration settings has been configured incorrectly, which could provide an attacker with additional opportunities to compromise a system. For example, the authentication settings on a system may permit an attacker to employ a brute-force password-guessing attack that will not be blunted by target user accounts being automatically locked out.

•   Design fault The relationship between components of a system may be arranged in a way that makes it easier for an attacker to compromise a target system. For instance, an organization may have placed a database server in its DMZ network instead of in its internal network, making the server easier for an attacker to identity and attack.

•   Business process weakness A business process related to the processing of personal information may fail to prevent or detect unwanted activities in certain circumstances. For instance, an end user who extracts a large volume of personal information from a customer application and saves it directly to a personal cloud drive may bypass controls that would detect or prevent this if the file were saved locally.

•   Known unpatched weakness A system may have one or more vulnerabilities for which security patches are available but not yet installed. For example, a secure communications protocol may have a flaw in the way that an encrypted session is established, which could permit an attacker to take over an established communications session. A security patch may be available for the flaw, but until the security patch is installed, the flaw exists and may be exploited by anyone who understands the vulnerability and has techniques to exploit it. Sometimes, known weaknesses are made public through a disclosure by the system’s manufacturer or a responsible third party. Although a patch may not yet be offered, other avenues may be available to mitigate the vulnerability, such as a configuration change in the target system.

•   Undisclosed unpatched weakness A system may have vulnerabilities that are known only to the system’s manufacturer and that are not publicized. Until an organization using one of these systems learns of the vulnerability via a security bulletin or a news article, the organization can do little to defend itself, short of employing essential security techniques such as system hardening, network hardening, and secure coding.

•   Undiscovered weakness Security managers have long accepted the fact that all kinds of information systems have security vulnerabilities that are yet to be discovered, disclosed, and mitigated. New techniques for attacking systems are constantly being developed, and some of these techniques can exploit weaknesses no one knew to look for. As newly discovered techniques involve examining active memory for snippets of sensitive information, system and tool designers continue to design defense techniques for detecting and even blocking attacks. At one point, for example, new techniques were developed that enabled an attacker to harvest credit card numbers from point-of-sale software programs that were compliant with the Payment Card Industry Data Security Standard (PCI DSS). Unfortunately, effective attacks were soon developed that enabled cybercriminal organizations to steal tens of millions of credit card numbers from global retail companies.

Vulnerabilities exist everywhere—in software programs, database management systems, operating systems, virtualization platforms, business processes, encryption algorithms, business processes, and personnel. As a rule, privacy and security managers should consider that every component of every type in every system has both known and unknown vulnerabilities, some of which, if exploited, could result in painful and expensive consequences for the organization. Table A-2 contains the places where vulnerabilities may exist, together with techniques that can be used to discover at least some of them.

Table A-2 Vulnerabilities and Detection Techniques

Third-Party Vulnerability Identification

Most organizations outsource at least a portion of their software development and IT operations to third parties. Mainly this occurs through the use of cloud-based applications and services such as software as a service (SaaS) applications and platform as a service (PaaS) and infrastructure as a service (IaaS) environments. Many organizations have the misconception that third parties take care of all security concerns in their services. Instead, organizations should thoroughly understand the security responsibility model for each outsourced service to understand which portions of security are the organization’s responsibility and which are managed by the outsourced service.

Whether security responsibilities are the burden of the organization or the outsourcing organization, all vulnerabilities need to be identified and managed. If the organization is responsible for particular aspects of privacy and security, it needs to employ normal means for identifying and managing them. For aspects of privacy and security that are the responsibility of the service provider, the provider needs to identify and manage vulnerabilities. In many cases, a service provider will make these activities available to their customers upon request.

Risk Identification

Risk identification is the activity during a risk assessment in which various scenarios are studied for each asset. Several considerations are applied in the analysis of each risk, including these:

•   Threats All realistic threat scenarios are examined for each asset to determine which are reasonably likely to occur.

•   Threat actors It is important to understand the variety of threat actors and to know which ones are more motivated to target the organization and for what reasons. This further illuminates the likelihood that a given threat scenario will occur.

•   Vulnerabilities Vulnerabilities need to be identified for each asset (both information and information systems), business process, and staff member being examined. Then various threat scenarios are considered to determine which vulnerabilities are most likely.

•   Asset value The value of each asset is an important factor to include in risk analysis. As described in the earlier section on asset value, assets may be valued in several ways. For instance, a customer database may have a modest recovery cost if it is damaged or destroyed; however, if that same customer database is stolen and sold on the black market, the value of the data may be much higher to cybercriminals, and the resulting costs to the organization to mitigate the harm done to customers may be higher still. Another way to examine asset value is through the revenue derived from its existence or use. The financial consequences of a ruined reputation are not included here but are a part of the impact, discussed in the next item.

•   Impact The risk manager examines vulnerabilities, threats (with threat actors), and asset values, and then estimates the impact of the different threat scenarios. Impact is considered separately from asset value, because some threat scenarios have minimal correlation with asset value and are related to reputation damage instead. Breaches of privacy data, for example, can result in high mitigation costs and reduced business. Breaches in hospital data systems can threaten patient care. Breaches in almost any IoT or industrial control system (ICS) context can result in extensive service interruptions and life-safety issues.

Qualitative and quantitative risk analysis techniques help to distinguish higher risks from lower risks. These techniques are discussed later in this section.

Risks above a certain level are often recorded in a risk register where they will be processed through risk treatment.

Risk, Likelihood, and Impact

During risk analysis in a risk assessment, the risk manager will perform some simple calculations to stratify all of the risks that have been identified. Calculations generally resemble one or more of these:

Risk = threats × vulnerabilities

Risk = threats × vulnerabilities × asset value

Risk = threats × vulnerabilities × probabilities

ISO/IEC Guide 73, Risk management – Vocabulary, defines risk as “the combination of the probability of an event and its consequence.” This is an excellent way to understand risk in simple, qualitative terms. ISO/IEC Guide 73 is available for purchase from https://iso.org/.

Likelihood

In risk assessments, likelihood is an important dimension that helps a risk manager understand several aspects related to the unfolding of a threat event. The likelihood of a serious security incident has less to do with technical details and more to do with the thought process of an adversary.

Considerations related to likelihood include the following:

•   Hygiene This is related to an organization’s security operations practices. Organizations that do a poor job in vulnerability management, patch management, and system hardening, for example, are more likely to suffer incidents simply because they are making it easier for adversaries to gain access to their systems.

•   Data management Relevant in a privacy program, the quality and effectiveness of an organization’s data management program will have a bearing on the probability of a privacy breach. If an organization has mature data management capabilities, it likely will be aware of anomalous behavior indicating a potential breach. On the other hand, an organization paying little attention to its data is more likely to have the data compromised without the organization being aware.

•   Visibility This factor is related to the organization’s standing: how broad and visible the organization is and how much the attacker’s prestige will increase as a result of a successfully compromised target.

•   Velocity The timing of various threat scenarios and whether there is any warning or foreknowledge are factors. For example, an adversary who is determined to exfiltrate a large volume of data without detection is likely to do so very slowly; on the other hand, ransomware can destroy an organization’s information in minutes.

•   Motivation It is essential to consider various types of adversaries to understand the factors that would motivate them to attack the organization. It could be about money, reputation, or rivalry.

•   Skill For various threat scenarios, what skill level is required to attack the organization successfully? A higher skill level does not always mean an attack is less likely; other considerations such as motivation come into play as well.

Impact

During risk assessments, a risk manager needs to understand the impact of each threat scenario. In the context of privacy, the definition of impact is the actual or expected result from some action, such as a breach. Impact is perhaps the most critical attribute to understand for a threat scenario. A risk assessment can describe all types of threat scenarios, the reasons behind them, and how they can be minimized. Still, without understanding the impacts of these scenarios, a risk manager cannot determine the importance of each threat in terms of the urgency to mitigate the risk.

A wide range of impact scenarios is possible:

•   Direct cash losses

•   Reputation damage

•   Loss of business—decrease in sales

•   Drop in share price—less access to capital

•   Reduction in market share

•   Diminished operational efficiency (higher internal costs)

•   Diminished operational capacity (lower revenue)

•   Civil liability

•   Legal liability

•   Compliance liability (fines, censures, and so on)

•   Interruption of business operations

Some of these impact scenarios are easier to analyze in qualitative terms than others, and the magnitudes of most of these potential impacts are difficult to quantify except in specific threat scenarios.

One of the main tools in the business continuity and disaster planning world, the business impact analysis (BIA) is highly useful for privacy and information security managers. A BIA can be conducted as part of a risk assessment or separate from it.

A BIA differs from a risk assessment. Although a risk assessment is used to identify risks and, perhaps, suggested remedies, a BIA is used to identify the most critical business processes, together with their supporting IT systems and dependencies on other processes or systems. The value that a BIA brings to a risk assessment is the understanding of which business processes and IT systems are the most important to the organization. The BIA helps the security manager better understand which processes are the most critical and therefore warrant the most protection, all other considerations being equal.

In qualitative risk analysis, where probability and impact are rated on simple numeric scales, a risk matrix is sometimes used to portray levels of risk based on probability and impact. Figure A-3 shows a risk matrix.

Figure A-3 Qualitative risk matrix

Risk Analysis Techniques and Considerations

As part of a risk assessment, the risk manager examines assets, together with associated vulnerabilities and likely threat scenarios. The risk analysis is the detailed examination that takes place here. Risk analysis considers many dimensions of an asset, including these:

•   Asset value

•   Threat scenarios

•   Threat probabilities

•   Relevant vulnerabilities

•   Existing controls and their effectiveness

•   Impact

Risk analysis can also consider business criticality if a BIA is available.

Various risk analysis techniques are discussed in the remainder of this section.

Information Gathering

A risk manager needs to gather a considerable amount of information so that the risk analysis and the risk assessment are valuable and complete. Several sources are available, including

•   Interviews with process owners

•   Interviews with application developers

•   Interviews with privacy and security personnel

•   Interviews with external privacy and security experts, including legal counsel

•   Privacy and security incident records

•   Analysis of incidents that occur in other organizations

•   Prior risk assessments (however, caution is advised to stop the propagation of risk calculation errors from one assessment to the next)

Qualitative Risk Analysis

Most risk analysis begins with qualitative risk analysis. This technique does not seek to identify exact (or even approximate) asset value or impact or the exact probability of occurrence. Instead, these items are expressed on a scale such as high, medium, or low or as a numeric range such as 1 to 5. The purpose of qualitative risk analysis is to understand risks relative to one another so that higher risks can be distinguished from lower risks. This is a valuable pursuit, because it gives an organization the ability to focus on more critical risks, based on impact in qualitative terms.

Semiquantitative Risk Analysis

In qualitative risk analysis, the probability of occurrence can be expressed as a numeric value, such as in the range 1 to 5 (where 5 is the highest probability). Impact can also be expressed as a numeric value, also in the range 1 to 5. Then, for each asset and each threat, risk is calculated as probability × impact.

Suppose, for example, that an organization has identified two risk scenarios. The first is a risk of data theft from a customer database; the impact is scored as a 5 (highest), and probability is scored as a 4 (highly likely). The risk is scored as 5 × 4 = 20. The second is a risk of theft of application source code; the impact is scored as a 2 (low), and probability is scored as a 2 (less likely). This risk is scored as 2 × 2 = 4. The risk manager understands that the data theft risk is more significant (scored as 20) as compared to the source code theft risk (scored as 4). These risk scores do not indicate that the larger risk is five times as likely to occur; neither do they mean that the larger risk is five times as expensive. They simply indicate that one risk is rated higher than the other. The scores also do not directly indicate whether the probability or the impact alone is high or low—analysis of the detailed scores is necessary to know that.

Note that some risk managers consider this a qualitative risk analysis, because the results are no more accurate in terms of costs and probabilities than the qualitative technique.

Quantitative Risk Analysis

In quantitative risk analysis, risk managers are attempting to determine actual costs and probabilities of events occurring. This technique provides more specific information to executives about the costs they can expect to incur in various security event scenarios.

Two aspects of quantitative risk analysis prove to be a continuing challenge:

•   Event probability It is difficult to come up with even an order-of-magnitude estimate on the probability of occurrence for nearly every event scenario. Even with better information from industry sources, the probability of high-impact incidents depends on many factors, some of which are difficult to identify or even quantify.

•   Event cost It is difficult to put an exact cost on any given privacy or security incident scenario. Privacy and security incidents are complex events that involve many parties and have unpredictable short- and long-term outcomes. Despite ever-improving information from research organizations on the cost of breaches, event costs are still rough estimates and may not take into account all aspects of the costs.

Because of these challenges, quantitative risk analysis should be regarded as an effort to develop estimates, not exact figures. This is in part because risk analysis is a measure of events that may occur, not a measure of events that do occur.

Standard quantitative risk analysis involves the development of several figures:

•   Asset value (AV) The value of the asset is usually (but not necessarily) the asset’s replacement value. Depending on the type of asset, different values may need to be considered.

•   Exposure factor (EF) This is the financial loss that results from the realization of a threat, expressed as a percentage of the asset’s total value. Most threats do not eliminate the asset’s value; instead, they reduce its value. For example, if an organization’s $120,000 server is rendered unbootable because of malware, it will still have salvage value, even if that is only 10 percent of the asset’s total value. In this case, the EF would be 90 percent. Note that different threats will have various impacts on EF, because the realization of different threats will cause varying amounts of damage to assets.

•   Single loss expectancy (SLE) This value represents the financial loss when a threat scenario occurs one time. SLE is defined as AV × EF. Note that different threats have a varied impact on EF, so those threats will have the same multiplicative effect on SLE.

•   Annualized rate of occurrence (ARO) This is an estimate of the number of times that a threat will occur per year. If the probability of the threat is 1 in 50 (one occurrence every 50 years), ARO is expressed as 0.02. However, if the threat is estimated to occur four times per year, ARO is 4.0. Like EF and SLE, ARO will vary by threat.

•   Annualized loss expectancy (ALE) This is the expected annualized loss of asset value due to threat realization. ALE is defined as SLE × ARO.

ALE is based upon the verifiable values AV, EF, and SLE, but because ARO is only an estimate, ALE is only as good as the ARO. Depending upon the asset’s value, the risk manager may need to take extra care to develop the best possible estimate for ARO, based upon whatever data is available. Sources for estimates include the following:

•   History of event losses in the organization

•   History of similar losses in other organizations

•   History of dissimilar losses

•   Best estimates based on available data

When the risk manager performs a quantitative risk analysis for a given asset, the ALE for all threats can be added together. The sum of all ALEs is the annualized loss expectancy for the complete array of threats. An unusually high sum of ALEs would mean that a given asset is confronted with a lot of significant threats that are more likely to occur. But in terms of risk treatment, ALEs are better left as separate and associated with their respective threats.

OCTAVE

Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) is a risk analysis approach developed by Carnegie Mellon University. The latest version is known as OCTAVE FORTE (For the Enterprise) and is used to help organizations identify, evaluate, prioritize, and mitigate privacy and security risks that are relevant to them.

The OCTAVE FORTE methodology consists of ten steps:

1.   Establish risk governance and appetite. The organization establishes a governance structure that enables determination of how much risk the organization is willing to tolerate and defines policies for how it will manage risk.

2.   Scope critical services and assets. The organization identifies its in-scope information assets and develops a profile for these assets that describe its features, qualities, characteristics, and value. Noting whether regulated personal information is included is of particular use for an organization’s privacy program.

3.   Identify resilience requirements of assets. The organization identifies the minimum capabilities acceptable to maintain continuity of critical services. This step is concerned with business continuity and managing concepts such as maximum allowable downtime, recovery point objective (RPO), and recovery tie objective (RTO).

4.   Measure current capabilities. The organization identifies, reviews, and evaluates controls that are currently in place to protect the organization and enable resilience.

5.   Identify risks, threats, and vulnerabilities to assets. The organization evaluates “what could go wrong” using various techniques such as vulnerability assessments and threat modeling and analyzes the business consequences of an impact.

6.   Analyze risks against capabilities. The organization creates a risk register to evaluate residual risk based on the organization’s capabilities to detect, mitigate, and respond to identified risks.

7.   Plan for response. The organization identifies how it responds to risks and establishes response plans that are expected to disrupt, reduce, or avoid risk occurrences or consequences.

8.   Implement the response plan. The organization implements projects and activities to execute the response plans.

9.   Monitor and measure for effectiveness. The organization defines metrics and performance indicators intended to evaluate how well the program is performing steps 2–8.

10.   Review, update, and repeat. The organization’s risk governance leadership reviews the performance of the risk management program and develops any needed improvement plans.

The OCTAVE FORTE methodology provides many examples for each of the steps described here, making it easy for a person or team to perform a risk analysis based on this technique.

Other Risk Analysis Methodologies

Additional risk analysis methodologies provide more complex approaches that may be useful for certain organizations or in selected risk situations:

•   Delphi method With this method, questionnaires are distributed to a panel of experts in two or more rounds. A facilitator will anonymize the responses and distribute them to the experts. The objective is for the experts to converge on the most critical risks and mitigation strategies.

•   Event tree analysis (ETA) Derived from the fault tree analysis method (described next), ETA is a logic modeling technique for analysis of success and failure outcomes given a specific event scenario—in this case, a threat scenario.

•   Fault tree analysis (FTA) This logical modeling technique is used to diagram all the consequences for a given event scenario. FTA begins with a specific scenario and proceeds forward in time with all possible outcomes. A large “tree” diagram can result, which depicts many different chains of events.

•   Monte Carlo analysis Derived from Monte Carlo computational algorithms, this analysis begins with a given system with inputs, where the inputs are constrained to minimum, likely, and maximum values. Running the simulation provides some insight into actual likely scenarios.

Risk Evaluation and Ranking

Upon completion of a risk assessment, when all risks have been identified and scored, the risk manager, together with others in the organization, will analyze the results and begin to develop a strategy for going forward. Risks can be evaluated singly, but the organization will better benefit from analysis of all the risks together. This is because many risks are interrelated, and the right combination of mitigation strategies can result in many risks being adequately treated.

The results of a risk assessment should be analyzed in several different ways, including the following:

•   Looking at all risks by business unit or service line

•   Looking at all risks by asset type (in particular, personal information)

•   Looking at all risks by activity type

•   Looking at all risks by type of consequence

Because no two organizations (or their risk assessment results) are alike, this type of analysis is likely to identify risk treatment themes that may have broad implications across many risks. For example, an organization may identify several tactical risks all associated with access management and vulnerability management. Rather than treating individual tactical risks, a better approach may be to improve or reorganize the access or vulnerability management programs from the top down, resulting in many identified risks being mitigated programmatically. Organizations need to consider not just the details in a risk assessment, but the big picture.

Another type of risk to look for is one with a low probability of occurrence and high impact, which is typically the type of risk treated by transfer. Risk transfer most often comes in the form of cyber insurance, but it is also relevant to privacy and security monitoring when it includes indemnification.

Risk Ownership

When considering the results of a risk assessment, the organization needs to assign individual risk management tasks to individual people, typically middle- to upper-management leaders. These leaders, who should also have ownership of controls that operate within their span of oversight, use a budget, staff, and other resources in daily business operations. These are the risk owners, and, to the extent that a formal policy or statement is in place on risk tolerance or risk appetite, they should be the people making risk-treatment decisions for risks in their domain. To the extent that these individuals are accountable for operations in their part of the organization, they should also be responsible for risk decisions, including risk treatment, in their operational areas. A simple concept to approach risk ownership is this: if nobody owns the risk, then nobody is accountable for managing the risk, which will lead to a higher probability of the risk becoming an ongoing, unresolved issue with negative impacts on the business, along with the possible identification of a scapegoat who will be blamed if an event occurs.

Risk Treatment

To determine the best risk treatment plan, management can view reports and other information about risks that have been identified, assessed, and analyzed. At this stage, the organization has completed identifying risks and begins to determine what should be done about them. Risk treatment comprises the decisions and the activities that follow. A key element in deciding the appropriate risk treatment is ensuring that the right people at the right level of the organization are actively involved in determining the appropriate risk treatment. This is achieved by having a formalized risk management program that includes all the key elements of an effective program outlined in this appendix.

In a general sense, risk treatment represents the actions that the organization undertakes to reduce risk to an acceptable level. More specifically, for each risk identified in a risk assessment, an organization can consider four responses, or actions:

•   Risk acceptance

•   Risk mitigation

•   Risk avoidance

•   Risk transfer

These four actions are explained in more detail in the following sections.

There is a fifth potential action—or, rather, inaction—related to risk treatment, known colloquially as ignoring the risk. A potentially dangerous undertaking, ignoring a risk amounts to an organization pretending that the risk does not exist. In this case, the organization has unofficially accepted the risk and is responsible if the risk becomes an issue later on. By unofficially accepting the risk and not assigning a risk owner, the organization is possibly increasing the impact and likelihood of the risk evolving into an incident.

Ignoring a known risk is different from an organization’s ignoring an unknown risk and is usually a result of a risk assessment or risk analysis that is not sufficiently thorough in identifying all relevant risks. The best solution for these “unknown unknowns” is to have an external, competent firm perform an organization’s risk assessment every few years or examine an organization’s risk assessment thoroughly to discover opportunities for improvement, including expanding the span of threats, threat actors, and vulnerabilities so that there are fewer or no unknown risks.

Risk Acceptance

In deciding to accept a risk, the organization determines that the risk requires no reduction or mitigation. If only risk acceptance were this simple!

Further analysis of risk acceptance shows that there are conditions under which an organization will elect to accept risk:

•   The cost of risk mitigation is higher than the value of the asset being protected.

•   The impact of compromise is low, or the value or classification of the asset is low.

Organizations may elect to establish a framework for risk acceptance, such as the one shown in Table A-3.

Table A-3 Framework for Risk Acceptanc

When an organization accepts a risk, instead of closing the matter for perpetuity, the organization should review it at least annually for the following reasons:

•   The value of the asset may have changed during the year.

•   The way that the asset is used may have changed during the year.

•   The value of the business activity related to the asset may have changed during the year.

•   The potency of threats may have changed during the year, potentially leading to a higher risk rating.

•   The cost of mitigation may have changed during the year, potentially leading to greater feasibility for risk mitigation or transfer.

As with other risk treatment activities, detailed recordkeeping helps the risk manager better track matters such as risk assessment review.

Risk Mitigation

In risk mitigation, the organization decides to reduce the risk through some means, such as by changing a process or procedure, by improving a privacy or security control, or by adding a privacy or security control.

Risk mitigation is generally chosen when management understands that performing risk mitigation costs less than the value of the asset being protected. Sometimes, however, an asset’s value is difficult to measure, or there may be a high degree of goodwill associated with the asset. For example, a customer database that contains personal information including bank account or credit card information may be of low value to the organization, but the impact of a breach of this database may be substantial because of the fines, loss of business, or adverse publicity that may result.

Risk mitigation may result in a task that can be carried out in a relatively short time. However, risk mitigation may also involve one or more major projects that start in the future, perhaps in the next budget year or many months or quarters in the future. Further, such a project may be delayed, its scope may change, or it may be canceled altogether. Thus, the risk manager needs to monitor risk mitigation activities carefully to ensure that they are completed as originally planned so that the risk mitigation is not forgotten or set aside.

Risk Avoidance

In risk avoidance, the organization decides to discontinue an activity that precipitates the risk. Often, risk avoidance is selected in response to an activity that was not formally approved in the first place. For example, a risk assessment may have identified a department’s use of an external service provider that represented a measurable risk to the organization. The service provider may or may not have been formally vetted in the first place. Regardless, after the risk is identified in a risk assessment (or by other means), the organization may choose to end its association with that service provider to avoid the risk.

Risk Transfer

After deciding to transfer a risk, the organization will employ an external organization to accept the risk. In this case, the organization does not have the operational or financial capacity to accept the risk, and risk mitigation is not the best choice. In risk transfer, an organization may have identified a significant financial risk related to a breach of its stores of personal information, for example. The risk transfer decision, in this case, may involve the purchase of cyber insurance that would offset the costs associated with such a breach. A risk transfer decision may also include the purchase of an incident response retainer, which is essentially a pre-purchase of incident response services in the event of a breach.

A risk assessment may reveal the absence of security monitoring of a critical system. Another form of risk transfer involves using an external security services provider to monitor the critical system.

Residual Risk

When an organization undergoes risk treatment for identified risks, the treatment usually does not eliminate the risk but reduces it to some degree. Residual risk is what remains after risk treatment is applied.

Some organizations approach risk treatment and residual risk improperly. They identify a risk, apply some risk treatment, and then fail to understand the residual risk and close the risk matter. A better way to approach residual risk is to analyze it as though it were a new risk and apply risk treatment to the residual risk. This iterative process provides organizations with an opportunity to revisit residual risk and make new risk treatment decisions. Ultimately, after one or more iterations, the residual risk will be accepted, and then the matter can be closed.

For instance, suppose a privacy manager identifies a risk in the organization’s access management system where multifactor authentication is not used. This is considered high risk, so the IT department implements a multifactor authentication solution. When the privacy manager reassesses the access management system, she finds that multifactor authentication is required in some circumstances but not in others. A new risk is identified, at perhaps a lower level of risk than the original risk. But the organization once again has an opportunity to examine the risk and make a decision about it. This may improve the access management system by requiring multifactor authentication in additional cases, further reducing risk, which should be examined again for further risk treatment opportunities. Finally, the risk will be accepted as is when the organization is satisfied that the risk has been sufficiently reduced.

In addition to the risk treatment life cycle, subsequent risk assessments and other activities will identify risks that represent residual risk from earlier risk treatment activities. Over time, the nature of residual risk may change, based on changing threats, vulnerabilities, or business practices, resulting in an initially acceptable residual risk that is no longer acceptable.

Controls

A common outcome of risk treatment, when mitigation is chosen, is the enactment of controls. Put another way, when an organization identifies a risk in a risk assessment, the organization may decide to develop (or improve) a control that will mitigate the identified risk.

Suppose, for example, that an organization determined that its procedures for terminating access for departing employees were resulting in many user accounts not being deactivated. The existing control was a simple, open-loop procedure, in which analysts were instructed to deactivate user accounts. Often, they were deactivating user accounts late or not at all. To reduce this risk, the organization modified the procedure (updated the control) by introducing a step in which a second person would verify all account terminations daily.

Controls are measures put in place to ensure desired outcomes. Controls can come in the form of procedures, or they can be implemented directly in a system. There are many categories and types of controls, as well as standard control frameworks. You can find a thorough discussion of controls in the book CISM Certified Information Security Manager All-In-One Exam Guide, in Chapter 4.

Costs and Benefits

As organizations ponder options for risk treatment (and in particular, risk mitigation), they generally will consider the costs of the mitigating steps and the expected benefits they may receive. When an organization understands the costs and benefits of risk mitigation, this helps them develop strategies that are more cost effective or that result in greater cost avoidance.

When weighing mitigation options, an organization needs to understand several cost- and benefit-related considerations, including these:

•   Change in threat probability Organizations need to understand how a mitigating control changes the probability of threat occurrence and what that means in terms of cost reduction and avoidance.

•   Change in threat impact Organizations need to understand the change in the impact of a mitigated threat in terms of an incident’s reduced costs and avoided costs versus the cost of the mitigation.

•   Change in operational efficiency Aside from the direct cost of the mitigating control, organizations need to understand the impact on the mitigating control on other operations. For instance, adding code review steps to a software development process may mean that the development organization may complete fewer fixes and enhancements in a given time period.

•   Total cost of ownership (TCO) When an organization considers a mitigation plan, the best approach is to understand its TCO, including the following costs:

•   Acquisition

•   Deployment and implementation

•   Recurring maintenance

•   Testing and assessment

•   Compliance monitoring and enforcement

•   Reduced throughput of controlled processes

•   Training

•   End-of-life decommissioning

•   Compliance-related fines and penalties The matter of compliance with privacy and security laws and regulations often involves fines and penalties when there are findings of noncompliance. Fines and penalties need to be considered as potential consequences for failing to mitigate some risks.

While weighing costs and benefits, organizations need to keep in mind several things:

•   Estimating the probability of a specific threat or event is difficult—particularly infrequent, high-impact events such as large-scale data thefts.

•   Estimating the impact of any particular threat is difficult, especially those rare, high-impact events.

Thus, the precision of cost–benefit analysis is no better than estimates of event probability and impact.

An old adage in information security states that an organization would not spend $20,000 to protect a $10,000 asset. Although that may be true in some cases, there is more to consider than just the asset’s replacement (or depreciated) value. For example, loss of the asset could result in an embarrassing and costly public relations debacle, or the asset may play a key role in the organization’s earning hundreds of thousands of dollars in revenue each month.

Still, the principle of proportionality is valid and is often a good starting point for making cost-conscious decisions on risk mitigation. The principle of proportionality is described in NIST’s generally accepted security systems principles (GASSP) and section 2.5 of its generally accepted information security principles (GAISP).