This chapter covers Certified Information Security Manager (CISM) Domain 2, “Information Security Risk Management,” part A, “Information Security Risk Assessment.” The entire Information Security Risk Management domain represents 20 percent of the CISM examination.

Supporting Tasks in the CISM job practice that align with the Information Security Risk Management / Information Security Risk Assessment domain include:

22.   Participate in and/or oversee the risk identification, risk assessment, and risk treatment process.

23.   Participate in and/or oversee the vulnerability assessment and threat analysis process.

26.   Facilitate the integration of information risk management into business and IT processes.

Information security risk management is the practice of balancing business opportunities with potential information security–related losses or negative impacts to business operations. Information security risk management is largely a qualitative effort, because it is difficult to know the probability and costs of significant loss events. Still, several methods for measuring risk have been established that help organizations better understand risks and how they can be handled. These methods include qualitative and quantitative techniques used to contribute to business decisions.

Emerging Risk and Threat Landscape

Risk management is the fundamental undertaking for any organization that desires to be reasonably aware of risks that, if not identified or monitored, could result in unexpected losses or loss of life, and even threaten the survival of the organization. The purpose of risk management is to identify credible threats and determine the best ways to deal with those threats. Organizations using effective risk management processes experience fewer security incidents; any incidents that do occur have lower impact, in part because the organization is better prepared to deal with them.

The Importance of Risk Management

Risk management is the cornerstone of any good information security program. Risk management represents time-proven methods and techniques used to identify risks, understand their probability of occurrence and potential impact on the organization, make decisions about those risks based on established decision criteria, and measure key attributes of security and risk for long-term trending and reporting to executive management.

Risk management provides key information that enables the security manager to prioritize scarce resources to result in the greatest possible risk reduction. Without risk management techniques, security managers would be making prioritization decisions based on gut feelings or other arbitrary means.

Though risk management may seem like a very complex and overwhelming subject, we as humans practice risk management every day. For example, suppose you are driving to work, and you know that the interstate is the fastest route, except not at this time of the day. Also, you know there are more wrecks during this time. What do you do? You use risk management techniques to help you make a risk-based decision and take a different route. There is no guarantee that you will arrive early at work or that you won’t get into a car accident or get a speeding ticket, but the chances of any of these are much lower by taking this route, so you have reduced the risk of arriving late (or worse).

The effectiveness of a risk management program is largely dependent on two factors: support from executive management and an organization’s culture with respect to security awareness and accountability. Additionally, an effective risk management program can serve as a catalyst for making subtle but strategic changes to an organization’s culture.

No two risk management programs are alike; instead, each is uniquely different, based on several factors:

•   Culture

•   Mission, objectives, and goals

•   Management structure

•   Management support

•   Industry sector

•   Market conditions

•   Applicable laws, regulations, and other legal obligations

•   Stated or unstated risk tolerance

•   Financial health

•   Operating locations

Outcomes of Risk Management

An organization that implements an effective risk management program will have heightened awareness about the business use of technology and how that technology can impact the business. The greatest benefit that an organization will derive is a lower probability of security incidents; for incidents that do occur, the organization will be better prepared, and the impact of the incident will be reduced.

An organization with the risk management program will develop a culture of risk-aware planning, thinking, and decision-making. Executives in the organization will be fully aware of information risk, resulting in a more realistic view of the risks associated with the use of information technology (IT) and the Internet. Executives and other decision-makers will begin to develop an instinct for the risk levels of different kinds of business activities.

Risk Objectives

A vital part of strategy development is the determination of desired risk levels. One of the inputs to strategy development is the understanding of the current level of risk, and the desired future state may also have an associated level of risk.

It is quite difficult to quantify risk, even for the most mature organizations. Getting risk to a reasonable “high/medium/low” is simpler, though less straightforward, and difficult to do consistently across an organization. In specific instances, the costs of individual controls can be known, and the costs of theoretical losses can be estimated, but doing this across an entire risk-control framework is tedious, yet uncertain, because the probabilities of occurrence for threat events amounts to little more than guesswork. Spending too much time analyzing risks brings diminishing returns.

Still, in a general sense, a key part of a security strategy may well be the reduction of risk (it could also be cost reduction or compliance improvement). When this is the case, the strategist will need to employ a method for determining before-and-after risk levels that are reasonable and credible. For the sake of consistency, a better approach would be the use of a methodology—however specific or general—that fits with other strategies and discussions involving risk.

Risk Management Technologies

Throughout the risk management process, an organization will identify specific risks and will often choose to mitigate those risks with specific process and technology solutions. The categories and types of solutions include the following:

•   Access governance systems

•   Access management systems

•   Advanced antimalware software (often touted as a replacement for antivirus)

•   Antivirus software

•   Cloud access security brokers (CASBs)

•   Data loss prevention (DLP) systems

•   Dynamic application security testing tools (DASTs)

•   External monitoring and threat intelligence services

•   File activity monitoring systems (FAMs)

•   File integrity monitoring systems (FIMs)

•   Firewalls (including so-called next-generation firewalls)

•   Forensics tools

•   Integrated risk management (IRM) systems, formerly known as governance, risk, and compliance (GRC) systems

•   Intrusion detection systems (IDSs)

•   Intrusion prevention systems (IPSs)

•   Network access controls (NACs)

•   Phishing assessment tools

•   Privileged access management systems (PAMs)

•   Public key infrastructure (PKI)

•   Security information and event management (SIEM) system

•   Security orchestration, automation, and response (SOAR) systems

•   Single sign-on (SSO) systems

•   Static application security testing (SAST) tools

•   Spam filters

•   Third-party risk management (TPRM) systems

•   Threat intelligence platform (TIP)

•   Unified threat management (UTM) systems

•   User behavior analytics (UBA) systems

•   Virtual private network (VPN) systems

•   Vulnerability scanning tools

•   Web application scanning tools

•   Web content filtering

•   Wireless access controls

Organizations without effective risk management programs often acquire many of these capabilities but do so without first identifying specific, relevant risks to their organizations. Instead, they are purchasing these solutions for other reasons, often based on the following:

•   Salespeople who claim their solutions will solve the organization’s security risks (without actually knowing what the specific risks are)

•   Security managers in other organizations who purchase the same or similar solutions (again, in the presence or absence of sound risk management)

•   Articles in trade publications that explain the merits of security solutions

Implementing a Risk Management Program

The implementation of a risk management program is not a straightforward undertaking. There are several risk management frameworks to choose from, and they share common principles, including the concept of risk management being a life-cycle process, periodic assessment, and continuous improvement.

Both internal and external factors will influence what risk management framework should be adopted and how it will be implemented. Applying a risk management framework in an organization requires a keen understanding of the organization’s mission, objectives, strategies, cultures, practices, structure, financial condition, risk appetite, and level of executive management support. External factors that will influence the selection and implementation of a risk management framework include market and economic conditions, applicable regulations, geographical operations, customer base/type, and the social and political climates. Specific frameworks are discussed later in this section.

Once a framework has been selected, the security manager can then start to develop a sound risk management strategy. Security managers will need to perform one or more gap analyses to understand the organization’s current state so that they can develop adequate plans to define, document, and highlight the desired future state. Because no security manager has a complete repertoire of knowledge and skill, many outside resources are available to supplement their knowledge and/or provide direct assistance.

Risk Management Strategy

The objectives of a risk management strategy are to identify all credible risks and to reduce them to a level that is acceptable to the organization. The acceptable level of risk is generally related to these factors:

•   Executive management’s risk appetite

•   The organization’s ability to absorb losses, as well as its ability to build defenses

•   Regulatory and legal requirements

As the organization establishes its acceptable level of risk (also known as risk tolerance), this will drive the implementation and refinement of controls. Then, over time, risk assessments and risk treatment will drive adjustments to its controls. This is because controls are the primary means for mitigating risks by ensuring desired outcomes, whatever they may be.

For organizations with other instances or pockets of risk management, it is important that the strategist consider merging these functions, or at least aligning them so that they are more consistent with one another. For organizations with enterprise risk management (ERM) functions, this may represent an opportunity to feed information risk into the ERM system so that its overall depiction of all business risk will include information risk.

It should be noted that in many small to midsize organizations, risk management programs originate from the IT group. This can be an opportunity for the IT team and security manager to increase the awareness and visibility of issues that could have a negative impact on the organization. An added benefit is the fostering of relationships with business leaders and moving away from the view of IT and security being seen as the “no” group and instead of being viewed as a business enabler.

Several internal and external factors will govern the implementation of risk management objectives, including the following:

•   Culture

•   Organizational maturity

•   Management structure

•   Management support

•   Market conditions

•   Regulatory and legal requirements

Possibly the most important factor that will enable or constrain security managers as they develop a risk management strategy is the development of key relationships throughout the organization. When a security manager develops and implements a risk management strategy, he or she is acting as a change agent in the organization. The security manager is subtly but intentionally driving key changes in the organization through changes in people, processes, and technologies. This role as a security catalyst is an ongoing journey that will become a way of life as the organization becomes a risk-aware culture.

Risk Communication  Risk management cannot be a secret business function; instead, it must be introduced to the organization’s key stakeholders in a way that helps them understand the role of risk management in the organization. Stakeholders need to understand how the risk management program will work and the role they will play in it being an effective program in helping to achieve business objectives. An important factor in the process is helping stakeholders understand the impact that the risk management program will have on their relationships with one another, on their autonomy, and on the organization’s well being and health, including that of their own jobs.

Successful information security risk management requires that the channels of communication be open at all times and operate in all directions. Successful information risk programs operate through transparency so that all stakeholders understand what is happening in the program and why. Certainly, there are some matters of information security that need to be kept confidential, but generally speaking, information about risks should be readily available to all board members, executives, stakeholders, and risk owners.

Risk Awareness  Risk awareness activities help make business leaders, stakeholders, and other personnel aware of the organization’s information risk management program. Similar to security awareness programs, the goal of risk awareness is to ensure that business leaders and decision-makers recognize that all business decisions have a risk component and that many decisions have implications on information risk. Further, they need to be aware of the presence of a formal information risk management program, which includes a process and techniques for making risk-aware decisions.

There is some overlap in the content and audience of security awareness and risk awareness programs. Primarily, security awareness applies to an entire organization, whereas risk awareness encompasses senior personnel who are involved in the risk management process. Also, the methods for communicating this information in these two programs are the same. Ideally, security awareness and risk awareness programs are developed side-by-side, ensuring that all audiences receive useful and actionable information when needed.

Risk Consulting  Security managers often play the role of security and risk consultant in their organizations. As they develop trusted relationships throughout the business, security managers are regarded as technology risk experts who are available to consult with on a wide variety of issues. Though these mini-consulting engagements may seem like ad hoc activities, security managers should treat them as formal service requests, even in the absence of a service request system or formal capability. This includes being mindful of responsiveness and service levels. Here are some of the key attributes that make a good information risk consultant:

•   Ability to listen to business leaders and rephrase the key concepts or information back to the business leaders to gain confirmation of what was heard

•   Ability to assess the information and how it may impact a process or business unit, and to identify other areas in the business that may be affected by the issue

•   Have a good understanding of the business, not just the technology supporting the business

Risk Management Frameworks

When building an information risk management program, the security manager needs to develop processes and procedures, roles and responsibilities, and templates for business records. This can be a lengthy and laborious undertaking that lacks assurance of success. Instead of building a program from scratch, security managers can refer to the multitude of high-quality risk management frameworks, including the following:

•   ISO/IEC 27001, “Information technology — Security techniques — Information security management systems — Requirements,” especially requirements 4 through 10, which describe the structure of an entire information security management system (ISMS), including risk management

•   ISO/IEC 27005, “Information Technology — Security Techniques — Information security risk management”

•   ISO/IEC 31010, “Risk management — Risk assessment techniques”

•   NIST Special Publication 800-37, “Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach”

•   NIST SP 800-39, “Managing Information Security Risk”

•   COBIT 2019 (Control Objectives for Information and Related Technology) framework

•   Risk IT framework

•   RIMS Risk Maturity Model

Risk managers can take two main approaches when considering existing frameworks: use a single framework that has the best alignment with the organization’s practices, or use elements from one or more frameworks to build the organization’s risk management program. As noted earlier in the chapter, several considerations influence the decision.

Framework Components  Risk management frameworks have a common core of components, including the following:

•   Program scope

•   Information risk objectives

•   Information risk policy

•   Risk appetite/tolerance

•   Roles and responsibilities

•   Risk management life-cycle process

•   Risk management documentation

•   Management review

Security managers in regulated industries need to understand legal and regulatory requirements so that they can select a framework and build a program that includes all the required activities and characteristics. If an ERM program is already in place within the organization, the security manager should consult with the ERM team to understand how elements from one or more frameworks will support and share information with one another.

Integration into the Environment  To be efficient and effective, the organization’s information risk management program needs to fit neatly and easily into the organization’s existing policies, processes, and systems. The information risk management program should complement existing structures instead of building separate structures. The principle at work here is one of utilizing existing structures and minimizing impact to the organization. A new or improved information risk management program will already be disruptive to an organization in need of such a program—there is no point in making the componentry of a program disruptive as well.

For instance, a security manager should consider acquiring risk management modules in an existing IRM platform used to manage policies and external vendors, as opposed to purchasing a separate IRM platform for managing risk—even if a new, separate platform might do a better job. In another example, the security manager should consider supplementing an existing security awareness program platform with material about information risk, as opposed to building or acquiring a completely separate security awareness system that deals only with information risk management.

Any risk management program needs to integrate easily into the organization’s existing culture. To the greatest extent possible, a new or improved risk management program should leverage current thinking, vocabulary, customs, and practices to fit seamlessly into the organization. However, if the organization’s culture needs minor adjustments with regard to information risk and information security, the new risk management program should be “eased into” the culture as opposed to being haphazardly imposed upon the organization.

Risk Management Context

When designing and establishing an information risk management program, the information security manager needs to understand the business context in which the program will exist. This includes the scope of the information risk management program along with the entire business environment in which the program will operate, including the organization’s policies, processes, practices, and culture. The information security manager, together with executive management, must define the boundaries within which the risk management program will operate, which may include the following:

•   Business units, lines of business, locations/regions

•   Participants and stakeholders in the information risk management program

•   Roles and responsibilities for participants and stakeholders

•   Risk appetite/tolerance

Internal Environments  While designing an information risk program, the security manager must understand many key aspects of the organization’s internal environment. If a security manager fails to consider these issues, the program may be less effective or may fail altogether. Key aspects include the following:

•   Organization mission, goals, and objectives

•   Existing business strategies, including major initiatives and projects in flight

•   Financial health and access to capital

•   Existing risk practices

•   Organizational maturity

•   Formal and informal communication protocols/relationships

•   Culture

External Environments  It is critical that the security manager and executive management understand the entities that affect the risk environment outside the organization. Although the external environment is not within the scope of an organization’s risk management program, many aspects of the external environment must be well understood by the organization to ensure that it and its risk management program are successful. These aspects include the following:

•   Market conditions

•   Economic conditions

•   Applicable laws and regulations

•   Social and political environments

•   External stakeholders, including regulators, business partners, suppliers, and customers

•   External threats and threat actors

•   Geopolitical factors

By being aware of these external factors, the organization can better understand their potential influences on the organization, which in turn may influence various aspects of the risk management program, including considerations when making risk decisions and overall risk tolerance.

The Three Levels of Risk Management

Modern risk management encounters a broad assortment of issues, ranging from corporate culture to misconfiguration of individual servers. Conceptually, these issues are handled in the same way, with risk identification, analysis, treatment, and closure, but the personnel involved will often vary, and the deliberations will sound quite different.

Risk management is best divided into three tiers:

•   Enterprise-level risks   Risks at this level are generally associated with organization culture and management’s adequate support of cybersecurity capabilities. Risks at this level are conceptual in nature and often are reported to a board of directors. The practice of risk management at this level is known as enterprise risk management, or ERM. An organization’s ERM will often include not only cybersecurity risk, but also risks related to competition, market share, economic, workforce matters, and more.

•   Process-level risks   Risks at this level are usually associated with the effectiveness of business processes, typically those that affect cybersecurity posture. Issues at this level typically involve security policies, standards, process design, workflow, and workload.

•   Asset-level risks   Risks at this level are associated with individual systems or small groups of systems. Generally, asset-level risks involve configuration and small-scale architecture. Analysis is focused on technical vulnerabilities and threats, and remediation is usually tactical.

As depicted in Figure 3-1, these three levels of risk management may be managed by a single group or multiple groups. Though the subject matter varies between levels, the basic principles of risk identification, risk analysis, and risk treatment apply to all.

Figure 3-1  Multitier risk management in NIST SP 800-39 (Source: National Institute for Standards and Technology)

Risks at one tier sometimes inform adjacent tiers. For instance, a surge in asset-level risks may indicate defects in process-level risks, or even a shift in workforce priorities. Similarly, the presence of multiple process-level risks may be an indication of macro issues that should be addressed at the enterprise level.

Gap Analysis

As security managers design the organization’s information risk management program, they envision the desired end state, which is often based on one or more information risk frameworks, as discussed earlier in this section. But when it comes to developing actual plans for implementing components of the program, the security manager must understand the current state of the program, even if there is no formal program at all. To do this, the security manager should conduct a gap analysis to determine which characteristics of the current state can remain, which aspects should be discarded, which should be replaced, and which should be added.

For example, suppose a security manager examines an organization’s existing change control process. She finds only a log of changes and e-mail attachments containing management approvals for changes. Her gap analysis reveals the lack of a change request procedure, change advisory board (CAB) calls, and roles and responsibilities. The existing business record is usable but needs additional fields and annotations. With this information, the security manager can now undertake (or direct) the work required to implement change control process improvements. Or suppose a security manager identifies that the current risk audit is conducted annually with no input from the business and process leaders. The information is kept by the internal audit team and updated by the chief executive officer (CEO). In this case, a gap analysis would identify several opportunities for improvement within the program through the involvement of senior leaders.

External Support

Setting up a new information risk management program involves a great deal of knowledge and details. Even the most experienced information security managers may find themselves lacking in a few areas. For instance, a new security manager may have worked previously in an organization without an existing risk management program, or the security manager may have worked in a different industry sector in the past. Or perhaps the organization may use tools, technologies, or processes that are unfamiliar to the security manager. Fortunately, a wealth of information is available to security managers, which will help to supplement their existing knowledge and skills so that they can proceed with building and running an information risk management program with more confidence and with better assurances of positive outcomes.

Here are some of these information sources:

•   Consultants   Many large and numerous small security professional services firms are equipped to provide professional advice on the establishment of a security strategy, and they can do the actual work of designing and implementing a risk management program. Sometimes, executive management needs affirmation from outside experts on the need for, and the ways to implement and operate, an information security program.

•   Security round tables   Many areas have informal security round tables whose members include chief information security officers (CISOs) and security managers. These local networks of information risk security professionals are invaluable for networking and advice.

•   Organization chapters   Several professional organizations have local chapters, where security professionals can congregate and learn from one another and from event speakers, including the following:

•   Cloud Security Alliance (CSA)

•   Information Systems Security Association (ISSA)

•   InfraGard

•   International Information Systems Security Certification Consortium, (ISC)²

•   International Association of Privacy Professionals (IAPP)

•   ISACA

•   Society for Information Management (SIM)

•   Society of Information Risk Analysts (SIRA)

•   Published information risk management practices   Several organizations, such as the following, publish standards and/or articles describing risk management practices, techniques, and case studies:

•   (ISC)²

•   ISACA

•   SANS Institute

•   Sources for security industry news   Many organizations publish articles and white papers on various information security and risk management topics, including the following:

•   CIO magazine

•   CSO magazine

•   Dark Reading

•   Information Security Media Group (ISMG)

•   Infosecurity Magazine

•   ISACA

•   (ISC)²

•   SANS Institute

•   SC Magazine

•   TechTarget

•   Reports from research organizations   Several organizations conduct research and publish reports on many security-related topics:

•   Ernst & Young (EY)

•   Ponemon Institute

•   PricewaterhouseCoopers (PwC)

•   Symantec

•   Verizon Business

•   Advisory services   Several advisory firms, including the following, publish articles, studies, and advice for security and risk managers:

•   Forrester

•   Frost Sullivan

•   Gartner

•   IDC

•   Ovum

•   Training   Education and training courses tailored for established security and risk professionals are available from many universities, community colleges, and vocational schools, as well as ISACA, (ISC)², and SANS.

•   Books   Some of the titles listed in The Cybersecurity Canon are focused on risk management and go deeper into the topic than is needed for the CISM certification. Originally curated by Palo Alto Networks, The Cybersecurity Canon is now managed by Ohio State University (https://icdt.osu.edu/about-cybersecurity-canon).

•   Conferences   Regional, national, and international conferences on security and risk management attract large numbers of security and risk professionals and include speakers, workshops, and training. Like other events listed here, these conferences provide numerous professional networking opportunities. Conferences include the following:

•   Black Hat

•   Defcon

•   Evanta (hosts several conferences)

•   Gartner Security & Risk Management Summit

•   ISACA Conference

•   ISSA (hosts several conferences)

•   RSA

•   SecureWorld Expo

•   Security Advisor Alliance Summit

•   Intelligence services   Several organizations publish advisories on threat actors, threats, and vulnerabilities. Some are designed to be human-readable, while others are designed as machine-readable and intended to be fed into an organization’s SIEM or TIP. A word of caution: Many organizations are promoting and selling threat intelligence services today. The security manager should fully vet the services and the specific value they will add to the organization.

The Risk Management Life Cycle

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 information risk, but overall, the life cycle for information risk is functionally similar to that for other forms of risk: a new risk is introduced into the process, the risk is studied, and a decision is made about its outcome. Like other life-cycle processes, risk management is formally defined in policy and process documents that define scope, roles and responsibilities, workflow, business rules, and business records.

Several frameworks and standards from U.S. and international sources define the full life-cycle process. Security managers are generally free to adopt any of these standards, use a blend of different standards, or develop a custom framework.

Information risk management relies upon risk assessments that consider valid threats against the organization’s 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 threats.

Risk treatment decisions about risks are made after weighing various risk treatment options. These decisions are typically made by a business owner associated with the affected business activity.

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 geographical or business unit parameters. Scope definition is not part of the iterative portion of the risk management process, although scope may be redefined from time to time.

•   Asset identification and valuation   The organization uses various means to discover and track its information and information system assets. A classification scheme may be used to identify 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 processes. Asset valuation is described in detail in Chapter 5.

•   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 risk is typically expressed in qualitative means; however, organizations in financial services industries often express risk in quantitative terms.

•   Risk identification   In this first step in the iterative risk management process, 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.

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

•   Threat advisory   This is an advisory from a product vendor, threat intelligence feed, or news story.

•   Risk analysis   This is an analysis of risk that is focused on some other matter that may uncover additional risks requiring attention.

•   Risk analysis   In the second step in a typical risk management process, the risk 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 in 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 to 5 or of 1 to 10).

•   Mitigation   The risk analyst studies different available methods for mitigating the risk. Depending upon the type of risk, there are many techniques, 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   In the last step in a typical risk management process, an individual decision-maker or committee makes a decision about a specific risk. The basic options for risk treatment are as follows:

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

•   Mitigate   The organization chooses to mitigate the risk, which can take the form of some action that serves to reduce the probability of a risk event or reduce the impact of a risk event. The actual steps taken may include business process changes, 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 choice 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 that lists risks that have been identified. Typically, a risk register contains many items, including a description of the risk, the level and type of risk, and information about risk treatment decisions. The risk register is discussed in detail later in this chapter.

Figure 3-2 shows the elements of a typical risk management life cycle.

Figure 3-2  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, or they may feel that a specific standard better aligns with their overall information risk program or the business as a whole.

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

NIST SP 800-39   The methodology described in this publication consists of multilevel risk management, at the information systems level, at the mission/business process level, and at the overall organization level. Communications up and down these levels ensure that risks are communicated upward for overall awareness, while risk awareness and risk decisions are communicated downward for overall awareness. Figure 3-1 depicts this approach.

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, 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 this publication 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 later in this section.

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

NIST SP 800-30   This publication describes in greater detail a standard methodology for conducting a risk assessment. The techniques 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, the steps for conducting a risk assessment are as follows:

•   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, 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 standard includes the following sources of threat information. Organizations are advised to supplement these sources with other information as needed.

•   Table D-1: Threat source inputs

•   Table D-2: Threat sources

•   Table D-3: Adversary capabilities

•   Table D-4: Adversary intent

•   Table D-5: Adversary targeting

•   Table D-6: Nonadversary threat effects

•   Table E-1: Threat events

•   Table E-2: Adversarial threat events

•   Table E-3: Nonadversarial threat events

•   Table E-4: Relevance of threat events

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 standard includes the following sources of vulnerability and predisposing condition information that 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: Input—vulnerability and predisposing conditions

•   Table F-2: Vulnerability severity assessment scale

•   Table F-4: Predisposing conditions

•   Table F-5: Pervasiveness of predisposing conditions

C.   Determine likelihood of occurrence The organization determines the probability that each threat scenario identified earlier 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

•   Table G-3: Assessment scale—likelihood of threat event occurrence

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

•   Table G-5: Assessment scale—overall likelihood

D.   Determine 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: Input—determination of impact

•   Table H-2: Examples of adverse impacts

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

•   Table H-4: Identification of adverse impacts

E.   Determine risk 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 for adversarial risk table to be completed by risk manager

•   Table I-6: Column descriptions for nonadversarial risk table

•   Table I-7: Template for nonadversarial risk 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 SP 800-30 is available at https://csrc.nist.gov/publications/sp.

ISO/IEC 27005  This international standard defines a structured approach to risk assessments and risk management. The methodology outlined in this standard is summarized here:

•   Step 1: Establish context   Before a risk assessment can be performed, 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 ISMS, business continuity plan, vulnerability management plan, or incident response plan.

•   Risk evaluation criteria   Determine the means through 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 that 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.

•   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 they could be 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 in this section. Note that a risk analyst may identify additional threats.

•   Control identification   Risk analysts identify existing and planned controls. Those controls that already exist should be examined to see whether they are effective. The criteria for examining a control includes whether it 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 be the loss of confidentiality, integrity, or availability of any asset, as well as a 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. 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 options are not mutually exclusive; sometimes, a combination of risk treatment options is the best option for an organization. For instance, if a business application is 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 as 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.

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.

•   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 6 includes a comprehensive discussion on the types of controls.

•   Risk retention (aka risk acceptance)   The organization chooses to accept the risk and decides not to change anything. Do note that risks should not be accepted in perpetuity, but instead should be periodically reviewed.

•   Risk avoidance   The organization decides to discontinue the activity associated with the risk. For example, suppose 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 instead directly to a payment processor so that the organization will no longer be accepting that data.

•   Risk transfer   The organization transfers risk to another party. The common forms of risk transfer are 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, while an organization may have had reduced costs from a breach because of cyber insurance, the organization may still suffer reputational damage in the form of reduced goodwill.

•   Step 5: Risk communication   All parties involved in information risk—the CISO (or other 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 on 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, vulnerabilities, and likelihood of occurrence should be periodically monitored and reviewed so that the organization’s view of risk continues to be relevant and accurate. Monitoring should include the following:

•   Discovery of new, changed, and retired assets

•   Changes in business processes and practices

•   Changes in technology architecture

•   New threats that have not been assessed

•   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

ISO/IEC 27005 may be purchased from www.iso.org.

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, as well as the probability of threat occurrence and an estimation of loss. FAIR is used to help a risk manager understand the probability of a given threat event and the losses that may occur.

In the FAIR methodology, there are six types of loss:

•   Productivity   Lost productivity caused by the incident

•   Response   The cost expended in incident response

•   Replacement   The 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   Reading data without authorization

•   Misuse   Using an asset differently from intended usage

•   Disclose   Sharing data with other unauthorized parties

•   Modify   Modifying assets

•   Deny use   Preventing legitimate subjects from accessing assets

FAIR is claimed to be complementary to risk management methodologies such as NIST SP 800-30 and ISO/IEC 27005. You can obtain information about FAIR at www.fairinstitute.org.

ISACA’s Risk IT Framework  ISACA developed the Risk IT Framework to align with its COBIT framework. While COBIT is used to manage other aspects of business infrastructure and risk, the Risk IT Framework is explicitly used to enable organizations to identify and manage IT risk. The framework is broken down into three major process areas: Risk Governance (RG), Risk Evaluation (RE), and Risk Response (RR).

The RE processes in the framework cover not only assessment, but overlap with the risk identification areas. In RE processes, business impact is framed and described and risk scenarios are developed. Risks are assessed and analyzed as well as presented to the organization’s management. The RE processes are divided into three areas (numbered RE1–RE3).

Collect Data (RE1)  The data collection process aligns with some of the risk identification processes previously described. During this process, risk management personnel develop a model for data collection, which provides for standardized data formats, measurements, and common data definitions. Data is collected on the various aspects of the organization and risk scenarios, including the business’s operating environment, risk factors, threat sources and events, vulnerability data, and asset data. Data is also collected on the effectiveness of existing controls in the organization.

Analyze Risk (RE2)  In this part of the framework, the organization begins to assess and analyze risk. First, it defines the risk analysis scope. The scope determines how broad and deep the risk analysis efforts will be, what areas the risk analysis will cover, and which assets will be examined for risk. To complete this part of the process, you’ll need to consider all the documentation assembled up to this point: risk scenarios, asset inventories, breakdowns of business processes, prioritization of assets, and so on. This will help frame the risk analysis as well as determine scope.

During this step, IT risk is also estimated. This involves determining likelihood and impact values associated with the developed risk scenarios. In addition, it involves consideration of existing controls and how effective they are as currently installed and functioning. Likelihood and impact values are considered after existing controls are considered.

Although risk response is the subject of Chapter 4, the identification and consideration of possible risk response options are also part of this step of the process. The person assessing the risk may recommend several different response options, based on the identified risk. What risk options an organization will use is determined later in the process and typically with the input and approval of senior management. Risk response options should be recommended that reduce risk to an acceptable level directly based on the risk appetite and tolerance of the organization. Finally, knowledgeable peers should review risk analyses to verify that the analysis process is sound and to validate the results.

Maintain Risk Profile (RE3)  A risk profile is a collection of detailed data on identified IT risks. Risk profiles can cover a single system or asset but are also often seen as describing risks on an organization-wide basis. During this risk evaluation step, a comprehensive document of identified risks and their characteristics, such as details regarding impact, likelihood, and contributing factors, is developed and maintained throughout the asset or system’s life cycle. Remember that system or asset risk profiles are usually rolled up into a more comprehensive risk document that covers systems, assets, and business processes across the entire organization.

IT assets are also mapped to the business and organizational processes they support during this step; this helps translate IT risk to corresponding business risk and enables management to see how the organization would be affected if IT risk were realized on specific assets. It also enables the organization to develop criticality estimates of IT resources from a business perspective. It’s worth noting that this is similar to the same process followed during a business impact assessment (BIA). The key to understanding how IT risk affects business operations at this point is in understanding how the capabilities of IT are provided to the business processes in question and how critical IT is to a particular business process or operation. Maintaining a risk profile also means monitoring and updating risk scenarios and analysis as conditions and risk factors change. This involves keeping the risk register up to date as well. Finally, the organization should develop key risk indicators (KRIs) during this step, specifically focusing on IT resources. While key risk indicators are discussed in Chapter 5, for now, you should know that they enable the organization to monitor changes in risk for given scenarios and to modify its risk profiles as these indicators change. Table 3-1 summarizes some of the different risk assessment methodologies available.

Table 3-1  Summary of Available Risk Assessment Methods and Frameworks

Vulnerability and Control Deficiency Analysis

The identification of vulnerabilities is an essential part of any risk assessment. A vulnerability is any weakness in a system that permits an attacker to compromise a target process or system successfully.

In the security industry, the key terms involved with risk assessments are often misunderstood and misused. These terms are distinguished from one another in this way: a vulnerability is a weakness 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 may have one or more incorrectly set configuration settings that could provide an attacker with opportunities to compromise a system. For example, the authentication settings on a system may enable an attacker to employ a brute-force password-guessing attack that will not be stopped by target user accounts being automatically locked out after a small number of unsuccessful login attempts.

•   Design fault   The relationship between components of a system may be arranged in such 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 it easier for an attacker to identify and attack.

•   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 easily take over an established communications session. There may be a security patch available for the security flaw, but until the security patch is installed, the flaw exists and may be exploited by any individual who understands the vulnerability and available techniques to exploit it.

Sometimes, known weaknesses are made public through a disclosure by the system’s manufacturer or a responsible third party. Even if a patch is unavailable, 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 unpublicized vulnerabilities that are known only to the system’s manufacturer. 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 new techniques have been discovered that involve examining active memory for snippets of sensitive information, system and tool designers can design defense techniques for detecting and even blocking attacks. For example, techniques were developed that would permit an attacker to harvest credit card numbers from PCI-compliant point-of-sale software programs. Soon, effective attacks were 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, and personnel. As a rule, 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 3-2 lists the places where vulnerabilities may exist, with techniques that can be used to discover at least some of them.

Table 3-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 SaaS applications, PaaS, and IaaS environments. Many organizations have the misconception that third parties take care of all security concerns in their services. As a result, they fail to thoroughly understand the security responsibility model for each outsourced service and fail to understand which portions of security are their responsibility and which are managed by the outsourced service.

Regardless of whether security responsibilities for any given aspect of operations are the burden of the organization or the outsourcing organization, vulnerabilities need to be identified and managed. For aspects of security that are the responsibility of the organization, the organization needs to employ normal means for identifying and managing them. For aspects of security that are the responsibility of the outsourced organization, that organization needs to identify and manage vulnerabilities; in many cases, the outsourced organization will make these activities available to their customers upon request.

Further discussion on the risks identified with third parties appears in Chapter 6.

Risk Assessment and Analysis

A risk assessment is intended to discover and identify threats that, if realized, could result in some unwanted event or incident. Two principal portions of a risk assessment are vulnerability identification and analysis (discussed in the preceding section) and threat identification and analysis, discussed next.

Threat Identification

The identification of threats 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 security industry, 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 the actual action that would cause harm, not the person or group (generically known as an actor or threat actor) associated with it. A threat is also not a weakness that may permit a threat to occur; that is known as a vulnerability, discussed earlier in this chapter.

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 out of their awareness. A good security manager can develop a list of threats that are likely (more or less) to occur to any given asset.

When performing a risk assessment, the security manager needs to develop a complete list of threats for use in the risk assessment. Because it’s not always possible for a security 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 security manager may 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 security 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 affected by tsunamis, so this threat source can be eliminated. Similarly, in an organization located in an area not affected by tornados, volcanos, or earthquakes, these threat sources can be removed.

Internal Threats

Internal threats originate within the organization and are most often associated with employees of the organization. Quite possibly, internal employees may be the intentional actors behind these threats.

Security 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 constitute 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

•   Disgruntled personnel deliberately bringing harm to an asset

•   Threat actor acting on behalf of a foreign government or company posing as internal employee to exfiltrate information

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

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

An important concept for a security manager to understand is this: while employees are at the top of a short list of potential threat actors, employees are the same actors who need to be given broad access to sensitive data to do their jobs and for the organization to function. Though there have been marginal improvements in technologies such as data loss prevention (DLP), employers have no choice but to trust employees by giving them access to virtually all of the organization’s information, with the hope that they will not accidentally or deliberately abuse those privileges with potential to cause the organization great harm.

Examples of employees “going rogue” include the following:

•   A network manager in San Francisco locks all other network personnel out of the network on the claim that no others are competent enough to manage it.

•   A securities trader at a U.K.–based brokerage firm bankrupts the firm through a series of large unauthorized trades.

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

•   A Chinese national pleads guilty to conspiracy to commit economic espionage. Despite the employee’s agreements to protect the company’s intellectual property, the employee admits that he stole a trade secret from his employer, transferred it to a memory card, and attempted to take it to the People’s Republic of China for the benefit of the Chinese government.

A significant factor in employees going rogue is an access control policy that results 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.

Access controls are only one of several areas of concern. Table 3-3 contains human-made threats that may be included in an organization’s risk assessment.

Table 3-3  Internal and External Human-Made Threats

It may be useful to build a short list of threat actors (the people or groups that would initiate a threat event), but remember that these 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.

Table 3-4 contains a list of internal and external natural threats.

Table 3-4  Internal and External Natural Threats

External Threats

Like internal threats, threats that originate outside of the organization can include both deliberate and accidental actions. External threats can also be human-made or associated with naturally occurring events.

The security manager performing a risk assessment needs to understand the full range of threat actors, along with their motivations. This is particularly important for organizations where 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.

Table 3-5 contains a list of external threat actors, and Table 3-6 lists the motivations behind these actors.

Table 3-5  External Threat Actors

Table 3-6  Threat Actor Motivations

In a risk assessment, it is essential to identify all threats that have a reasonable likelihood of occurrence. Those threats that are unlikely because of geographical and other conditions are usually excluded. For example, hurricanes can be excluded for locations far from oceans, and volcanoes can be excluded from locations where no volcanoes exist. Threats such as meteorites and space debris are rarely included in risk assessments because of the minute chance of occurrence.

Advanced Persistent Threats

An advanced persistent threat (APT), whether an individual or a cybercrime organization, is known for using techniques that indicate resourcefulness, patience, and resolve. Rather than employing a “hit-and-run” or “smash-and-grab” operation, an APT 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 which 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.

The term “APT” was developed in the early 2000s to describe a new kind of adversary that worked slowly but effectively to compromise a target organization. Prior to APTs, threat actors were unsophisticated and 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, and once an attack began, it would carry on 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 was ever discovered), the security manager would clean up the compromised target, often not knowing that the APT had compromised many other targets, with not all of the compromises using the same technique.

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 theater in which cyberwarfare takes place today is constantly changing and evolving. Several forces are at work, as explained in Table 3-7, that continually “push the envelope” in the areas of attack techniques as well as defense techniques.

Table 3-7  The Cascade of Emerging Threats

Emerging threats will always represent the cutting edge of attack techniques and will be difficult to detect and/or remediate when they are first discovered. For this reason, emerging threats should be viewed as a phenomenon of new techniques, rather than as a fixed set of techniques. Often, the latest attack techniques are difficult to detect because they fall outside the span of techniques that security professionals expect to observe from time to time. Security managers need to understand that, although defensive technologies continuously 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.

Risk Identification

During risk identification, various scenarios are studied for each asset to identify which risks pose the greatest potential for realization. Several considerations are applied in the identification of each risk, including the following:

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

•   Threat actors   The risk manager must understand the variety of threat actors and 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   For all assets, business processes, and staff members being examined, vulnerabilities need to be identified. Then various threat scenarios are examined to determine which ones are more likely as a result of corresponding vulnerabilities.

•   Asset value   The value of each asset is an important factor to include in risk analysis. As described earlier, 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. Other ways to examine asset value is through the revenue derived from the asset’s existence or use.

•   Impact   The risk manager examines vulnerabilities, threats (with threat actors), and asset value and 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 but are instead related to reputation damage. Breaches of privacy data can result in high mitigation costs and reduced business. Breaches of hospital data can threaten patient care. Breaches in almost any IoT 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 transferred to 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. These calculations generally resemble one or more of the following:

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, nonnumeric terms.

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, including vulnerability management, patch management, and system hardening. Organizations that do a poor job in these areas are more likely to suffer incidents simply because they are making it easier for adversaries to break into systems.

•   Visibility   This is related to the organization’s standing, including how large and visible the organization is, and how much the attacker’s prestige will increase after successfully compromising the target.

•   Velocity   This factor is related to the timing of various threat scenarios and whether there is any warning or foreknowledge.

•   Motivation   It is important to consider various types of adversaries to better understand the factors that motivate them to attack the organization: it could be about money, reputation, or rivalry, for example.

•   Skill   For various threat scenarios, what skill level is required to attack the organization successfully? If attackers require a higher skill level to infiltrate an organization’s system, this doesn’t mean that an attack is less likely; other considerations such as motivation come into play as well.

Impact

In the context of information security, an impact is the actual or expected result of some action, such as a threat or disaster. During a risk assessment, impact is perhaps the most important attribute for a risk manager to understand in a threat scenario. A risk assessment can describe all types of threat scenarios, the reasons behind them, and how they can be minimized. If the risk manager fails to understand the impact of these scenarios, he or she cannot determine the level of importance imposed by one threat factor versus another, in terms of the urgency to mitigate the risk.

A wide range of possible impact scenarios include the following:

•   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)

•   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 magnitude of most of these is 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 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 in this way: 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 information security manager understand which processes are the most critical and, therefore, which warrant the most strident protection, all other considerations being equal. Business impact analysis is described in detail in Chapter 7.

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. The risk matrix in Figure 3-3 depicts qualitative risk.

Figure 3-3  Qualitative risk matrix

Risk Analysis Techniques and Considerations

In a risk assessment, the security manager examines assets, together with associated vulnerabilities and likely threat scenarios. This detailed examination, or risk analysis, considers many dimensions of an asset, including the following:

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

Gathering Information

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

•   Interviews with process owners

•   Interviews with application developers

•   Interviews with security personnel

•   Interviews with external security experts

•   Security incident records

•   Analysis of incidents that have occurred in other organizations

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

Qualitative Risk Analysis

Most risk analysis begins with qualitative risk analysis, a rating technique that does not seek to identify exact (or even approximate) asset value or impact or the exact probability of occurrence. Risk items are expressed in levels such as high, medium, and low. The purpose of qualitative risk analysis is to understand each risk relative to other risks, so that higher risks can be distinguished from lower risks. This system enables the organization to focus on risks that are more critical, based on impact in qualitative terms.

Semiquantitative Risk Analysis

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

For example, suppose 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. This system helps the security manager understand that the data theft risk is a larger risk (scored as 20) compared to the source code theft risk (scored as 4). These risk scores do not imply that the larger risk is five times as likely to occur, nor do they imply that protecting against the larger risk is five times as expensive. The scores are used to determine only that one risk is larger than another.

Quantitative Risk Analysis

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

There are two aspects of quantitative risk analysis that 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 nearly every event scenario. Even with better information coming from industry sources, the probability of high-impact incidents is dependent upon many factors, some of which are difficult to quantify.

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

Because of these challenges, quantitative risk analysis should be regarded as an effort to develop estimates, not exact figures. In part, this is 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)   The financial loss that results from the realization of a threat is expressed as a percentage of the asset’s total value. Most threats do not completely 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, the server will still have salvage value, even if that is only 10 percent of the asset’s actual value. In this case, the EF would be 90 percent. Note that different threats have different 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 also 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, then 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 ARO. Depending upon the value of the asset, 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 performing a quantitative risk analysis for a given asset, risk managers can add up the ALEs for all threats. The sum of all ALEs is the annualized loss expectancy for the total array of threats. A particularly 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 off 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, OCTAVE Allegro, is used to assess information security risks so that an organization can obtain meaningful results from a risk assessment.

The OCTAVE Allegro methodology uses eight steps:

•   Step 1: Establish risk measurement criteria   The organization identifies the most important impact areas. The impact areas in the model are reputation/customer confidence, financial, productivity, safety and health, fines/legal penalties, and other. For example, reputation may be the most important impact area for one organization, while privacy or safety may be the most important for other organizations.

•   Step 2: Develop an information asset profile   The organization identifies its in-scope information assets and develops a profile for each asset that describe its features, qualities, characteristics, and value.

•   Step 3: Identify information asset containers   The organization identifies all the internal and external information systems that store, process, and transmit in-scope assets. Note that many of these systems may be operated by third-party organizations.

•   Step 4: Identify areas of concern   The organization identifies threats that, if realized, could cause harm to information assets. Typically, this is identified in a brainstorming activity.

•   Step 5: Identify threat scenarios   This is a continuation of step 4, where threat scenarios are expanded upon (and unlikely ones eliminated). A threat tree may be developed that first identifies actors and basic scenarios and then is expanded to include more details.

•   Step 6: Identify risks   A continuation of step 5, the consequences of each threat scenario are identified.

•   Step 7: Analyze risks   This simple quantitative measurement is used to score each threat scenario based on risk criteria developed in step 1. The output is a ranked list of risks.

•   Step 8: Select mitigation approach   A continuation of step 7, the risks with higher scores are analyzed to determine methods available for risk reduction.

The OCTAVE Allegro methodology includes worksheets for each of these steps, making it easy for a person or team to perform a risk analysis based on this technique. Further information about OCTAVE Allegro is available at www.cert.org/resilience/products-services/octave/.

Bow-Tie Analysis

A bow-tie analysis uses diagrams to analyze and explain relationships between various risk elements, from causes (threats) to events and then to impacts (consequences). It is similar to both the fault-tree analysis and the event-tree analysis (discussed next). It looks at the various causes of a risk event (fault tree) and analyzes the consequences of the event (event tree). The difference, however, is that the bow-tie analysis looks at the intervening characteristics of the events and causes, such as the path by which the cause leads to the event and then the consequences. Figure 3-4 illustrates a bow-tie diagram. In this figure, the adverse event is shown as the center of the bow tie, with potential causes on the left and possible consequences on the right.

Figure 3-4  An example of a bow-tie analysis diagram

Other Risk Analysis Methodologies

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

•   Delphi 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 important risks and mitigation strategies.

•   Bayesian analysis   This technique uses data distribution and statistical inference to determine risk probability values, checklists, scenario analysis, and business impact analysis.

•   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 consequences. A large “tree” diagram can result that depicts many different chains of events.

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

•   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 security manager, together with others in the organization, will begin to analyze the results and begin to develop a strategy going forward.

Risks can be evaluated singly, but the organization will better benefit from an analysis of all the risks together. Many risks are interrelated, and the right combination of mitigation strategies can result in many risks having been 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

•   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 themes of risk treatment that may have broad implications across many risks. For example, an organization may have 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 in a programmatic fashion. Organizations need to consider not just the details in a risk assessment, but the big picture.

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

Risk Ownership

When considering the results of a risk assessment, the organization needs to assign individual risks to individual people, typically middle- to upper-management business leaders. These leaders, who should also have ownership of controls that operate within their span of control, have budget, staff, and other resources used in daily business operations. These are the risk owners, and, to the extent that there is a formal policy or statement 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 that if nobody owns the risk, then nobody is accountable for managing the risk, which will lead to a great probability of the risk becoming an active issue with negative impacts on the business, along with the possible identification of a scapegoat who will be blamed if an event occurs. The scapegoat is usually the person responsible for information security.

Risk Treatment

In risk treatment, management makes a choice regarding the disposition of each identified risk. Management can choose to accept the risk, mitigate the risk, transfer it to another organization, or avoid the activity altogether. Risk treatment is described in detail in Chapter 4.

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 risk that was found. Controls are measures put in place to ensure a desired outcome. Controls can come in the form of procedures, or they can be implemented directly in a system.

Suppose an organization realized that its procedures for terminating access for departing employees were resulting in a lot of user accounts not being deactivated. The existing control was a simple, open-loop procedure, whereby analysts were instructed to deactivate user accounts. Often they were deactivating user accounts too 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 on a daily basis.

There are many categories and types of controls, as well as standard control frameworks. These are discussed in great detail in Chapter 6.

Risk Management and Business Continuity Planning

These two disciplines, risk management and business continuity planning, are focused on identifying risks that may adversely impact the organization’s operations. Risk management and business continuity planning have several common characteristics and goals:

•   Both seek to discover risks and develop remedies for events that threaten business operations and the ongoing viability of an organization.

•   Both rely on risk assessments to identify risks that will require mitigation.

•   Both can rely on the results of a business impact analysis to better understand the criticality of business processes and the interdependency of processes and assets.

Risk management identifies threats that, if unchecked, could unfold into disaster scenarios. Many of the threat scenarios in a risk assessment are disaster situations used in business continuity planning.

Business continuity planning is described in detail in Chapter 7.

The Risk Register

A risk register is a business record that contains information about business risks and information about their origin, potential impact, affected assets, probability of occurrence, and treatment. A risk register is the central business record in an organization’s risk management program. Together with other records, the risk register serves as the focal point of evidence that an organization is at least attempting to manage risk. Other records include evidence of risk treatment decisions and approvals, tracking of projects linked to risks, and risk assessments and other activities that contribute content to the risk register.

A risk register can be stored in a spreadsheet, database, or within a governance, risk, and compliance tool used to manage risk and other activities in the security program. Table 3-8 shows the columns in a typical risk register.

Table 3-8  Sample Risk Register Data Structure

Sources of Information for the Risk Register

Awareness of risks can come from many places and through a variety of events. The information in Table 3-8 provides some hints about the potential sources of information that would lead to the creation of a risk register entry, which include the following:

•   Risk assessment   A prime source for risk register entries, a risk assessment identifies risks in the organization’s staff (such as excessive workload, competency, and training issues), business processes, and technology.

•   Vulnerability assessment   The high-level results of a vulnerability assessment (or penetration test, code review, social engineering assessment, and so on) may indicate overarching problems in staff, business processes, or technology at a strategic level.

•   Internal audit   Internal audits and other internal control self-assessments can identify problems in staff, business processes, or technology.

•   Security incident   The occurrence of a security incident may reveal the presence of one or more risks that require attention. Note that a security incident in another organization may highlight risks in one’s own organization.

•   Threat intelligence   Formal and informal subscriptions or data feeds on threat intelligence may reveal risks that warrant attention.

•   Industry development   Changes in the organization’s industry sector, such as new business activities and techniques, may reveal or magnify risks that require attention.

•   New laws and regulations   The passage of new laws, regulations, and applicable standards and private legal obligations may reveal the presence of risks that require attention. Also, note that compliance risk (the possibility that regulators or others may impose fines or sanctions on the organization) may well be included in one or more risk register entries, if the organization has identified such risks.

•   Consultants   A visit by, or conversation with, an expert security consultant may reveal risks that were previously unknown. The consultant, who may be an auditor or assessor or may be working in the organization on a project, may or may not be expecting to find risks that the organization’s security manager would want to be aware of.

Strategic vs. Tactical Risks

When managing the contents of the risk register, an organization may establish business rules related to the types of content that may be included in the risk register. An important distinction is the matter of strategic versus tactical: strategic risks certainly belong in a risk register, but tactical risks often do not.

For instance, an organization that performs vulnerability scans or application scans would not put all of the contents of the vulnerability scan in the risk register. In even modest-sized organizations, there can be hundreds or thousands of entries in a vulnerability scan that warrant attention (and occasionally immediate action). But these are considered tactical because they are associated with individual assets. However, if, in the course of conducting vulnerability scans, the security manager discovers that there are systemic problems with recurring vulnerabilities, this phenomenon may warrant an entry in the risk register. For example, there may be recurring instances of servers that are not being patched or a problem that results in patches being removed. This could be part of a larger problem that incurs significant risk to the organization, deserving of an entry in the risk register.

Risks identified in third parties in the organization’s third-party risk management program should be included in the risk register.

Risk Analysis Contribution

Note that Table 3-8 includes ratings for mitigated probability, impact, and risk, as well as a description of risk treatment with associated cost and level of effort. The information in those fields should represent the result of more detailed risk analysis for each entry in the risk register.

For example, a security manager may have discovered that the organization’s software development team continues to produce code containing numerous security defects. The security manager would analyze the situation and consider many different potential remedies, each with its own costs, levels of effort, and impact on risk. The security manager may then consider the following:

•   Secure development training

•   An incentive program that rewards developers who produce the fewest security defects

•   Code scanning tools present in each developer’s integrated development environment (IDE)

•   Code scanning tools in the organization’s software build system

•   Periodic application penetration tests performed by a qualified external party

•   Web application firewall appliances

•   Web application firewall in the organization’s content delivery network (CDN) service

In the course of analyzing this situation, the security manager will probably confer with people in various parts of the organization to discuss these and other potential solutions. Depending on the practices and processes that are in place in the organization, the security manager may unilaterally select a decision or bring the array of choices to a security steering committee for discussion. In this example, the security manager may select two or more methods to mitigate the risk. In this case, the security manager may decide to have developers undergo secure development training and also implement a web application firewall.

Ultimately, the ratings in the risk register, as well as the risk mitigation description, will reflect the mitigation technique that is selected.

Residual Risk

Risk treatment rarely eliminates all risk; instead, risk treatment will reduce the probability and/or the impact of a specific threat. The leftover, or residual, risk should be entered into the risk register for its own round of risk treatment. Depending upon the nature of the original risk, an individual risk may undergo two or more cycles of risk treatment, until finally, the residual risk is accepted and the risk matter closed.

Integration of Risk Management into Other Processes

The risk management life-cycle process is not the only place where risk analysis and risk management are performed in an organization. The concept of risk should be integrated into several other IT and business processes in an organization. This section describes the incorporation of security and risk into several processes, including the following:

•   Architecture

•   Software development

•   Change management

•   Configuration management

•   Incident and problem management

•   Physical security

•   Information risk and enterprise risk management

•   Human resource management

•   Project management

Architecture

IT architects and solution architects create macro- and micro-level designs for networks, systems, applications, integrations, and other technology components. These activities should be reviewed by security subject matter experts such as security architects to ensure that the work of IT and solution architects do not introduce new, undesired risk to the organization.

Software Development

Developers, in the creation and maintenance of software programs, sometimes introduce software defects (commonly known as bugs) in their programs, resulting in unexpected behavior. This unexpected behavior may include calculation errors or errors in the way that information is displayed, read from storage, or written to storage. Sometimes, these defects can be exploited by a user or attacker to trick the software program into performing unexpected or unwanted activities.

Unless software developers are specifically aware of the security implications of the use of specific functions and calculations, they may unknowingly introduce benign to serious security defects in their programs. Some of these defects may be easily discovered with scanning programs or other techniques, while others may remain undiscovered for years. Often, a researcher will find security defects associated with a particular coding technique that is present in many programs; this can result in many organizations discovering for the first time that their programs have a particular exploitable defect.

Without specific software development experience, a security manager in a smaller organization may not have specific knowledge of the pitfalls associated with the use of the programming language in that organization. Oftentimes, an outside security expert with experience in software development and insecure coding is needed to assist such an organization in discovering any weaknesses in its coding practices. In a larger organization, assistance may be provided by one or more internal security experts who are familiar with the languages used in development.

In addition to secure coding, organizations need to introduce several security-related steps into their software development process:

•   Threat modeling   These techniques are implemented during the design phase to anticipate potential threats and incorporate design features to block them.

•   Coding standards   These standards specify allowed and disallowed coding techniques, including those more likely to introduce security defects and other defects.

•   Code reviews   Performed by peers, code reviews are part of the program development and maintenance process. A peer is more likely to find defects and security problems than the developer who wrote the code.

•   Code scanning   This is performed in the developer’s IDE or executed separately in the developers’ central software build environments.

•   Application scanning   This is performed on web applications to discover exploitable defects.

•   Application penetration testing   Testing is performed periodically by internal personnel or by qualified security advisory firms.

The concept of security by design is used to incorporate security and risk into every level of product development, from inception to development, testing, implementation, maintenance, and operations. Organizations that incorporate security by design into their development and business processes are less likely to suffer from security incidents than those that do not. They are also less likely to undergo frequent security changes caused by unexpected security incidents.

Change Management

Change management is the IT function used to control changes made to an IT environment. The purpose of change management is to reduce the likelihood that proposed changes will introduce unexpected risks, which could lead to unplanned outages and security incidents.

A basic change management process begins with a formal request for change, which includes several specific pieces of information:

•   Description of the change

•   Reason for the change

•   Who will perform the change

•   When will the change be performed

•   A procedure for making the change

•   A procedure for verifying the change

•   A back-out procedure in case the change cannot be verified

•   Security impact of the change and also of not implementing the change

•   Privacy impact

•   Dependencies

•   Defined change windows

A group of individuals from IT and across the business (a change review board or change control board) can meet periodically to discuss new change requests. After the requestor describes the change, including the elements listed previously, others on the change review board will have an opportunity to ask questions or voice concerns related to the change. In many organizations, one or more security personnel are permanent members of the change review board and will have a voice in the discussion about each change to ensure that security and privacy issues are properly identified, discussed, and managed.

Security professionals overall are maligned by the few who frequently seek to block proposed changes and other activities on account of the risks that may be introduced. Generally, this creates a challenge, where change review boards need to incorporate security concerns and ensure that security managers are included in all discussions. Also, security managers need to be pragmatic and understand that there is no advancement of business without risk.

Configuration Management

Configuration management is the IT function by which the configuration of components in an IT environment is independently recorded. Configuration management is usually supported by the automated tools used to inventory and control system configurations, but sometimes manual means are used. A configuration management database (CMDB) is the repository for this information.

Configuration management can be thought of as the creation of a historical record of the configuration of devices and systems. This historical record can sometimes be useful during troubleshooting, in support of investigations, as personnel need to understand in detail any changes in configuration that may have occurred in a system that could account for an incident or problem.

Security and risk considerations in configuration management are as follows:

•   Protection of configuration management data from unauthorized access

•   Inclusion of security-related information in configuration management data

Looking into the content itself in configuration management, this brings to mind the fact that organizations need to develop server, endpoint, and network device–hardening standards to make them more resilient to attack. Once an organization develops a hardening standard, it is implemented in some manner, such as a golden server or endpoint image, which should also be managed and protected, whether contained in the CMDB or not.

IT and information security need to be aware of the phenomenon of configuration drift, where the configuration of a component or system slowly diverges from its initial or intended state. Configuration drift often occurs in organizations that lack automation for applying configurations to systems.

Incident and Problem Management

The IT service management companion activities, incident management and problem management, are important activities for IT organizations. Incident management is the IT function that is used to analyze service outages, service slowdowns, service errors, security incidents, and software bugs, as well as to restore the agreed-on service as soon as possible. Problem management is the IT function used to analyze chronic and recurring incidents to discover their root cause and prevent further occurrences.

Incident management and problem management need to include the disciplines of security and risk. There are four primary security- and risk-related considerations in incident management.

Security or Risk Component Associated with an Incident  IT personnel analyzing an incident or a problem need to understand the security nature of the incident or problem, including whether the incident or problem has an impact on security. For instance, a malfunctioning firewall may be allowing traffic to pass through a control point that should not be permitted. Further, many security incidents are first recognized as simple malfunctions or outages and recognized later as symptoms of an attack. For example, users complaining of slow or unresponsive servers may be experiencing the effects of a distributed denial-of-service (DDoS) attack on the organization’s servers, which, incidentally, may be a diversionary tactic to an actual attack occurring elsewhere in the organization. In the context of problem management, a server suffering from availability or performance issues may have been compromised and altered by an attacker.

Security or Risk Implication Associated with Actions to Restore Service  IT personnel analyzing an incident and working to restore service need to understand the security and risk impacts that their analysis and corrective actions have on IT systems and associated information. For example, rebooting a security server in an attempt to remedy a situation may result in a temporary loss of visibility and/or protection from events.

Security or Risk Implications Associated with Root-Cause Analysis  Root-cause analysis is defined as the analysis of a problem to identify its underlying origin instead of merely its symptoms and factors. IT personnel analyzing a problem must be aware of the security and risk considerations while performing root-cause analysis. IT personnel need the skills to recognize the security and risk implications of symptoms and origins. For example, a problem with server availability was traced to some file system permissions that were set improperly; those file system permission changes affected the ability of users to directly access sensitive data that should be accessed only by an application.

Security or Risk Implications Associated with Corrective Action  IT personnel analyzing a problem must be aware of the security and risk implications of changes being considered within business processes and technology. For instance, an application malfunction that is corrected by elevating its service account to the privileged (administrative) level may solve the underlying access permission error, but it creates significant risks as well.

Physical Security

Physical security is mainly concerned with the development and management of controls to protect physical assets, workplaces, and personnel. There is significant intersection between information security and physical security: information security relies upon physical security controls for the protection of information processing and communications equipment. While some of this equipment resides in data centers, some also resides in workplaces where an organization’s personnel also work. These common controls make workplace safety a close relative to information security.

Changes in physical security technologies such as video surveillance and building access control systems are bringing information and physical security closer together than they have ever been before. In most organizations, however, information security and physical security are still managed separately. In these cases, because they share many technologies, assets, and overall objectives of protecting the organization from harm, information and physical security personnel can form partnerships.

Information and physical security functions can be integrated together in a number of ways, including the following:

•   Ensuring that organization-wide risk and threat assessments cover both areas adequately

•   Ensuring that business continuity and disaster recovery planning adequately covers both concerns

•   Ensuring that information and physical security risks exist on a common risk register and are managed in a common risk management and risk treatment process

•   Ensuring that information systems with high availability requirements are located in facilities with high availability as part of their design

•   Ensuring that IP-based physical security assets and systems are incorporated into the organization’s overall technology and security architecture, with adequate protection based on risk

•   Incorporating physical facilities into the organization’s information and asset classification program so that facilities and work centers can also be rated and adequately protected based on classification and risk

•   Incorporating physical facility access into the organization’s identity and access management program

•   Ensuring that supervisory control and data acquisition (SCADA) and industrial control systems (ICSs) are supporting, monitoring, and controlling the environmental systems that support information technology such as heating, ventilation, and air-conditioning (HVAC) and that physical access control systems are monitored in a common monitoring platform

Information Risk and ERM

Larger organizations, more mature organizations, and organizations in financial services industries often have an enterprise risk management (ERM) function. Typical ERM programs are developed to identify and manage business-specific risks, and they frequently use a life-cycle process similar (if not identical) to the information risk processes described in this book.

Organizations with ERM and information risk functions have an opportunity to combine or leverage these functions. For example, information risk issues that are placed in the information risk register can also be entered into the ERM risk register. Further, organizations with both functions could decide to use a common risk register for all business and information risks. Often, this makes sense, because information risk is just one form of business risk, and organizations that blend these risks in a register will have a more complete view of all business risks, regardless of the context. For organizations that do not combine their risk registers, there are still opportunities for synergy, including having some personnel involved in both risk processes so that there are people in the organization who have a complete picture of all of its risks.

Human Resource Management

The entire life-cycle process of human resource management (HRM or HR, and increasingly called human capital management, or HCM) is involved in the acquisition, onboarding, care, and termination of permanent, temporary, and contingency workers in an organization. Many aspects of HRM are risk related, as well as related to information security.

An organization’s workers are tasked with the acquisition and management of critical and sensitive information. Thus, there are several practices in HR that contribute to the support of information protection, including the following:

•   Background checks   Prior to hiring an individual, an organization uses various means to verify the background of a candidate and to ensure that the person is free of a criminal history and other undesired matters.

•   Legal agreements   An organization will generally direct new employees to agree to and sign legal documents, including nondisclosure and noncompete agreements, as well as agreements concerning compliance with security and other organization policies.

•   Training   HR organizations are typically responsible for delivering training of all kinds to its workers, including but not limited to security awareness training. This helps workers in the organization better understand the organization’s security policy, the importance of information and asset protection, and practices in place for information protection.

•   Development and management of roles   HR organizations typically create and maintain job descriptions, which should include security-related responsibilities, and a hierarchy of positions in the organization.

•   Management of the human resource information system (HRIS)   Most HR organizations today utilize an HRIS for all official records concerning its workers. Many HRIS systems today are integrated with an organization’s identity and access management (IAM) system: when an employee is hired, transferred, or terminated, a data feed from the HRIS to the IAM platform ensures that access management information and systems are kept up to date. This makes it all the more important that HRIS systems have accurate information in them.

Project Management

Whether a centralized project management office is utilized or project managers are scattered throughout an organization, security and risk are essential elements of program management and project planning. There are several ways in which security and risk should be incorporated into projects, including the following:

•   Risk analyses should be performed at the onset of a project to identify potential risks in the proposed finished project or program. This gives organizations an opportunity to refine project/program objectives, architecture, and requirements.

•   The impact of a project or program on the organization’s security, compliance, and privacy must be established prior to any procurement, development, or implementation.

•   Security requirements need to be included in any activity where requirements are developed. Like other requirements, security requirements must be verifiable.

•   Security should be included as a part of approval gates if they are used in projects.

Chapter Review

Risk management is the core of an organization’s information security program. By using risk management techniques to identify risks and understand the probability of their occurrence and impact upon the organization, risk managers can help the organization prioritize scarce resources to reduce risk effectively. The proper application of risk management helps an organization reduce the frequency and impact of security incidents through improved resilience and preparation.

When implementing a risk management program, the organization must consider several characteristics, including its risk tolerance, management structure, executive management support, culture, and any regulatory and legal obligations.

A risk management program should include several avenues of communication so that business leaders and stakeholders understand the program and how it is integrated into the organization. The program should be transparent with regard to its procedures and practices.

When building or improving a risk management program, security managers may select one of several industry frameworks, such as ISO/IEC 27001, ISO/IEC 27005, ISO/IEC 31010, NIST SP 800-37, NIST SP 800-39, COBIT, Risk IT, RIMS, and FAIR. These and other frameworks offer similar components, including scope, objectives, policy, risk tolerance, roles and responsibilities, the risk management life-cycle process, and management review. To the greatest reasonable extent, a risk management program should be integrated into the business to avoid disruption to the organization while minimizing risk.

When planning a risk management program, the security manager and executive leadership need to understand—and to some extent, define—the context of the program. This includes the program’s scope, participants and stakeholders, and risk tolerance. The security manager must consider many aspects of the organization’s internal environment, as well as external environments such as market and economic conditions, external stakeholders, customers, and external threats. The security manager may need to perform gap analyses to better understand the current state as compared to the desired future state of the program. Security managers can fill gaps in knowledge and experience through networking with other security and risk professionals, training, periodicals, and conferences.

The risk management life cycle consists of a set of activities that enable the discovery and management of risks. The steps in the process include scope definition, asset identification and valuation, risk identification, risk analysis, risk treatment, and risk communication. Periodic risk assessments and other means contribute to continued risk identification.

A key step in risk analysis is the identification of vulnerabilities, or weaknesses, in people, business processes, or technology.

Another key step in risk analysis is the identification and analysis of internal and external threats. Risk management standards such as NIST SP 800-37 contain comprehensive lists of credible threats. Security managers need to recognize that emerging threats often need to be considered in a risk assessment, and some may not yet be included in current standards. Further, there are sometimes threats specific to an industry sector.

After risks are identified, the amount of risk present can be calculated using input from threats, threat actors, vulnerabilities, asset value, and impact. In most cases, risk is calculated in a qualitative way, primarily because it is difficult to know the precise (or even an approximate) probability of threat occurrence and somewhat difficult to know the financial impact of a threat.

In quantitative risk analysis, key values are asset value, exposure factor, single loss expectancy, annualized rate of occurrence, and annualized loss expectancy.

Industry-standard techniques are available for performing risk analysis, including OCTAVE Allegro, bow-tie analysis, Delphi method, Bayesian analysis, event-tree analysis, fault-tree analysis, and Monte Carlo analysis.

Risks identified in a risk assessment or risk analysis need to be evaluated, ranked, categorized, and assigned to a risk owner. Often, an organization will enact a control to address a risk.

Risk management and business continuity planning have several common components and linkages. Both are concerned with business resilience and survival, and both utilize business impact analysis to better understand the organization’s most critical processes.

The risk register is the central business record in a risk management program. A risk register is a catalog of all current and historical risks, along with many pieces of metadata describing each risk in detail. A risk register may be stored in a spreadsheet, in a database, or in a governance, risk, and compliance tool’s risk management module.

Security and risk management are incorporated into many other business activities, including but not limited to software development, change management, configuration management, incident and problem management, physical security, enterprise risk management, and human resource management.

Notes

•   Like other activities in information security, measuring the benefits of an information risk management program can be difficult, mainly because it is difficult to identify security events that did not occur because of the program.

•   Understanding and changing aspects of an organization’s culture is one of the most important success factors and also one of the most difficult. Culture is the collective way that people in the organization think and work. It is documented everywhere and nowhere.

•   Selecting a risk management and risk assessment framework is among the least important decisions in the development of a risk management program. Nevertheless, organizations often get as hung up on choosing management and assessment frameworks as they do on choosing a control framework. Consensus on framework selection is vital for long-term success.

•   The need to minimize the impact of the risk management business process cannot be overstated. Where possible, utilize existing governance, management, control, and communications structures already present in the organization. The impact on decisions made in the risk management program may be significant; the process itself need not be.

•   External factors such as market conditions, competition, and the sentiment of clients or customers are as important as internal factors such as access to capital and culture. Organizations in some industry sectors may have an opportunity to make security a competitive differentiator, in which case it will be more important to establish effective security management and risk management programs. Customers and competitors will notice.

•   Security managers, when their knowledge or skills fall short on any topic, underestimate the value of networking and soliciting advice from industry peers. Many security professionals are willing to help, and plenty of events provide networking opportunities to meet them.

•   In a risk assessment, while listing credible threat events, first obtain the list of threats from a standard such as NIST SP 800-30, and then add other threats that may be relevant for the asset, organization, or geographic location.

•   The term “advanced persistent threats” was developed when such threats were novel. They no longer are new. Although use of the term has diminished, this type of threat has become commonplace.

•   Identifying all reasonable vulnerabilities during a risk assessment is not as easy as identifying threats. You must know more about the asset or process being examined.

•   In qualitative risk assessments, it’s easy to become focused on the risk scores for various risks. Remember that risk scores are the result of basic calculations based on very coarse threat and vulnerability ratings. Risk ratings should serve only to distinguish very high risks from very low ones—and even then, these are just rough approximations.

•   Most organizations that are establishing a risk management program for the first time can use spreadsheets for key business records such as the risk register and the security incident log. As organizations become more mature, they can acquire a governance, risk, and compliance platform that includes risk management modules.

Questions

1.   A risk manager is planning a first-ever risk assessment in an organization. What is the best approach for ensuring success?

A.   Interview personnel separately so that their responses can be compared.

B.   Select a framework that matches the organization’s control framework.

C.   Work with executive management to determine the correct scope.

D.   Do not inform executive management until the risk assessment has been completed.

2.   A security manager has completed a vulnerability scan and has identified numerous vulnerabilities in production servers. What is the best course of action?

A.   Notify the production servers’ asset owners.

B.   Conduct a formal investigation.

C.   Place a single entry into the risk register.

D.   Put individual vulnerability entries into the risk register.

3.   The concept of security tasks in the context of a SaaS or IaaS environment is depicted in a:

A.   Discretionary control model

B.   Mandatory control model

C.   Monte Carlo risk model

D.   Shared responsibility model

4.   A security manager is developing a vision for the future state of a risk management program. Before she can develop the plan to achieve the vision, she must perform a:

A.   Gap analysis

B.   Risk analysis

C.   Risk assessment

D.   Threat assessment

5.   All of the following are techniques to identify risks except:

A.   Penetration tests

B.   Threat modeling

C.   Vulnerability assessment

D.   Risk treatment

6.   The main advantage of NIST standards versus ISO standards is:

A.   NIST standards are considered global standards.

B.   NIST standards are not copyrighted.

C.   NIST standards are available without cost.

D.   NIST standards cost less to implement.

7.   Which of the following statements is true about compliance risk?

A.   Compliance risk can be tolerated when fines cost less than controls.

B.   Compliance risk is just another risk that needs to be understood.

C.   Compliance risk can never be tolerated.

D.   Compliance risk can be tolerated when it is optional.

8.   Misconfigured firewalls, missing antivirus, and lack of staff training are examples of:

A.   Risks

B.   Threats

C.   Vulnerabilities

D.   Threat actors

9.   A phishing attack, network scan, and social engineering are examples of:

A.   Risks

B.   Threats

C.   Vulnerabilities

D.   Threat actors

10.   A security manager has been directed by executive management not to document a specific risk in the risk register. This course of action is known as:

A.   Burying the risk

B.   Transferring the risk

C.   Accepting the risk

D.   Ignoring the risk

11.   A security manager is performing a risk assessment on a business application. The security manager has determined that security patches have not been installed for more than a year. This finding is known as a:

A.   Probability

B.   Threat

C.   Vulnerability

D.   Risk

12.   A security manager is performing a risk assessment on a data center. He has determined that it is possible for unauthorized personnel to enter the data center through the loading dock door and shut off utility power to the building. This finding is known as a:

A.   Probability

B.   Threat

C.   Vulnerability

D.   Risk

13.   Hacktivists, criminal organizations, and crackers are all known as:

A.   Threat actors

B.   Risks

C.   Threats

D.   Exploits

14.   All of the following are core elements used in risk identification except:

A.   Threats

B.   Vulnerabilities

C.   Asset value

D.   Asset owner

15.   What is usually the primary objective of risk management?

A.   Fewer and less severe security incidents

B.   No security incidents

C.   Improved compliance

D.   Fewer audit findings

Answers

1.   C. The best approach for success in an organization’s risk management program, and during risk assessments, is to have support from executive management. Executives need to define the scope of the risk management program, whether by business unit, geography, or other means.

2.   A. Most organizations do not place individual vulnerabilities into a risk register. The risk register is primarily for strategic issues, not tactical issues such as individual vulnerabilities. However, if the vulnerability scan report was an indication of a broken process or broken technology, then that matter of brokenness may qualify as a valid risk register entry.

3.   D. The shared responsibility model, sometimes known as a shared responsibility matrix, depicts the operational model for SaaS and IaaS providers where client organizations have some security responsibilities (such as end user access control) and service provider organizations have some security responsibilities (such as physical access control).

4.   A. The risk manager must perform a gap analysis to understand the difference between the current state of the risk management program and its desired future state. Once the gap analysis is completed, it will become clear what steps must be performed to achieve that desired future state.

5.   D. Risk treatment is not a tool to identify risks. It is the process of making a decision about what to do with an identified risk.

6.   C. One of the main advantages of NIST standards is that they are available free of charge. ISO standards are relatively expensive, ranging from US$100 to $200 for single user copies.

7.   B. In most cases, compliance risk is just another risk that needs to be understood. This includes the understanding of potential fines and other sanctions in relation to the costs required to reach a state of compliance. In some cases, being out of compliance can also result in reputation damage as well as larger sanctions if the organization suffers from a security breach because of the noncompliant state.

8.   C. These are all vulnerabilities, or weaknesses that could potentially be exploited by a threat.

9.   B. These are all threats, which could be more easily carried out if targets are vulnerable.

10.   D. The refusal of an organization to formally consider a risk is known as ignoring the risk. This is not a formal method of risk treatment because of the absence of deliberation and decision-making. It is not a wise business practice to keep some risk matters “off the books.”

11.   C. The absence of security patches on a system is considered a vulnerability, which is defined as a weakness in a system that could permit an attack to occur.

12.   B. Any undesired action that could harm an asset is known as a threat.

13.   A. These are all threat actors, or persons/entities that may carry out threats against targets if sufficiently motivated.

14.   D. The identity of an asset owner does not factor into the risk identification process. Although knowing the asset owner is important in subsequent phases of the risk management process, it is not relevant in identifying the risk. The factors relevant to risk identification are threats, threat actors, vulnerabilities, asset value, and impact.

15.   A. The most common objective of a risk management program is the reduction in the number and severity of security incidents.