In this chapter, you will learn how to

   Use risk management tools and principles to manage risk effectively

   Explore risk mitigation strategies

   Describe risk models

   Explain the differences between qualitative and quantitative risk assessment

   Use risk management tools

   Examine risk management best practices

Risk management can best be described as a decision-making process. In the simplest terms, when you manage risk, you determine what could happen to your business, you assess the impact if it were to happen, and you decide what you could do to control that impact as much as you or your management deems necessary. You then decide to act or not to act, and, finally, you evaluate the results of your decision. The process may be iterative, as industry best practices clearly indicate that an important aspect of effectively managing risk is to consider it an ongoing process.

An Overview of Risk Management

Risk management is an essential element of management from the enterprise level down to the individual project. Risk management encompasses all the actions taken to reduce complexity, increase objectivity, and identify important decision factors. There has been, and will continue to be, discussion about the complexity of risk management and whether it is worth the effort. Businesses must take risks to retain their competitive edge, however, and as a result, risk management must occur as part of managing any business, program, or project.

Risk management is both a skill and a task that is performed by all managers, either deliberately or intuitively. It can be simple or complex, depending on the size of the project or business and the amount of risk inherent in an activity. Every manager, at all levels, must learn to manage risk. The required skills can be learned.

Example of Risk Management at the International Banking Level

The Basel Committee on Banking Supervision comprises government central-bank governors from around the world. This body created a basic, global risk management framework for market and credit risk. It implemented internationally a flat 8 percent capital charge to banks to manage bank risks. In layman’s terms, this means that for every $100 a bank makes in loans, it must possess $8 in reserve to be used in the event of financial difficulties. However, if banks can show they have very strong risk mitigation procedures and controls in place, that capital charge can be reduced to as low as $0.37 (0.37 percent). If a bank has poor procedures and controls, that capital charge can be as high as $45 (45 percent) for every $100 the bank loans out. See www.bis.org/bcbs/ for source documentation regarding the Basel Committee.

This example shows that risk management can be and is used at high levels—the remainder of this chapter focuses on smaller implementations and demonstrates that risk management is used in many aspects of business conduct.

Risk Management Vocabulary

You need to understand a number of key terms to manage risk successfully. Some of these terms are defined here because they are used throughout the chapter. This list is somewhat ordered according to the organization of this chapter. More comprehensive definitions and other pertinent terms are listed alphabetically in the glossary at the end of this book.

Risk Risk is the possibility of suffering harm or loss.

Risk Management Risk management is the overall decision-making process of identifying threats and vulnerabilities and their potential impacts, determining the costs to mitigate such events, and deciding what actions are cost effective for controlling these risks.

Risk Assessment Risk assessmentis the process of analyzing an environment to identify the risks (threats and vulnerabilities) and mitigating actions to determine (either quantitatively or qualitatively) the impact of an event that would affect a project, program, or business. It’s also referred to as risk analysis.

Asset An asset is any resource or information an organization needs to conduct its business.

Threat A threat is any circumstance or event with the potential to cause harm to an asset. For example, a malicious hacker might choose to hack your system by using readily available hacking tools.

Threat Actor A threat actor (agent) is the entity behind a threat.

Threat Vector A threat vector is a method used to effect a threat—for example, malware (threat) that is delivered via a watering-hole attack (vector).

Vulnerability A vulnerability is any characteristic of an asset that can be exploited by a threat to cause harm. A vulnerability can also be the result of a lack of security controls or weaknesses in controls. Your system has a security vulnerability, for example, if you have not installed patches to fix a cross-site scripting (XSS) error on your web site.

Impact Impact is the loss (or harm) resulting when a threat exploits a vulnerability. A malicious hacker (threat agent) uses an XSS tool (threat vector) to hack your unpatched web site (the vulnerability), stealing credit card information (threat) that is then used fraudulently. The credit card company pursues legal recourse against your company to recover the losses from the credit card fraud (the impact).

Control A control is a measure taken to detect, prevent, or mitigate the risk associated with a threat. It is also called a countermeasure or safeguard.

Qualitative Risk Assessment Qualitative risk assessment is the process of subjectively determining the impact of an event that affects a project, program, or business. Completing the assessment usually involves the use of expert judgment, experience, or group consensus.

Quantitative Risk Assessment Quantitative risk assessment is the process of objectively determining the impact of an event that affects a project, program, or business. Completing the assessment usually involves the use of metrics and models.

Mitigate The term mitigate refers to taking action to reduce the likelihood of a threat occurring and/or to reduce the impact if a threat does occur.

Single Loss Expectancy Single loss expectancy (SLE) is the monetary loss or impact of each occurrence of a threat exploiting a vulnerability.

Exposure Factor Exposure factor (EF) is a measure of the magnitude of loss of an asset. It is used in the calculation of single loss expectancy.

Annualized Rate of Occurrence Annualized rate of occurrence (ARO) is the frequency with which an event is expected to occur on an annualized basis.

Annualized Loss Expectancy Annualized loss expectancy (ALE) is how much a loss is expected to cost per year.

Systematic Risk Systematic risk is the chance of loss that is predictable under relatively stable circumstances. Examples such as fire, wind, or flood produce losses that, in the aggregate over time, can be accurately predicted despite short-term fluctuations. Systematic risk can be diversified away, which gives managers a level of control that can be employed.

Unsystematic Risk Unsystematic risk is the chance of loss that is unpredictable in the aggregate because it results from forces difficult to predict. Examples include, but are not limited to, recession, unemployment, epidemics, war-related events, and so forth. Unsystematic risk cannot be mitigated via diversification, limiting management responses.

Hazard A hazard is a circumstance that increases the likelihood or probable severity of a loss. For example, running systems without antivirus is a hazard because it increases the probability of loss due to malware.

What Is Risk Management?

Three definitions relating to risk management reveal why it is sometimes considered difficult to understand.

   The dictionary defines risk as the possibility of suffering harm or loss.

   Carnegie Mellon University’s Software Engineering Institute (SEI) defines continuous risk management as “processes, methods, and tools for managing risks in a project. It provides a disciplined environment for proactive decision-making to 1) assess continuously what could go wrong (risks); 2) determine which risks are important to deal with; and 3) implement strategies to deal with those risks” (SEI, Continuous Risk Management Guidebook [Pittsburgh, PA: Carnegie Mellon University, 1996], 22).

   The Information Systems Audit and Control Association (ISACA) says, “In modern business terms, risk management is the process of identifying vulnerabilities and threats to an organization’s resources and assets and deciding what countermeasures, if any, to take to reduce the level of risk to an acceptable level based on the value of the asset to the organization” (ISACA, Certified Information Systems Auditor (CISA) Review Manual, 2002 [Rolling Meadows, IL: ISACA, 2002], 344).

These three definitions show that risk management is based on what can go wrong and what action should be taken, if any. Figure 20.1 provides a macro-level view of how to manage risk.

• Figure 20.1    A planning decision flowchart for risk management

Risk Management Culture

Organizations have a culture associated with their operation. Frequently, this culture is set and driven by the activities of senior management personnel. The risk management culture of an organization can have an effect upon actions being taken by others. Table 20.1 illustrates the symptoms and results associated with risk management culture.

Table 20.1 Characteristics of Risk Management Culture

Risk Response Techniques

The presence of risks in a system is an absolute—they cannot be removed or eliminated. Actions can be taken to change the effects that a risk poses to a system, but the risk itself doesn’t really change, no matter what actions are taken to mitigate that risk. A high risk will always be a high risk. However, actions can be taken to reduce the impact of that risk if it occurs. A limited number of strategies can be used to manage risk. The risk can be avoided, transferred, mitigated, or accepted.

Avoiding the risk can be accomplished in many ways. Although threats cannot be removed from the environment, the exposure can be altered. Not deploying a module that increases risk is one manner of risk avoidance.

Another possible action to manage risk is to transfer that risk. A common method of transferring risk is to purchase insurance. Insurance allows risk to be transferred to a third party that manages specific types of risk for multiple parties, thus reducing the individual cost. Another common example of risk transfer is the protection against fraud that consumers have on their credit cards. The risk is transferred to another party, so people can use the card in confidence.

Risk can also be mitigated through the application of controls that reduce the impact of an attack. Controls can alert operators so that the level of exposure is reduced through process intervention. When an action occurs that is outside the accepted risk profile, a second set of rules can be applied, such as calling the customer for verification before committing a transaction. Controls such as these can act to reduce the risk associated with potential high-risk operations.

In addition to mitigating risk or transferring risk, it may be acceptable for a manager to accept risk; in other words, despite the potential cost of a given risk and its associated probability, the manager of the organization will accept responsibility for the risk if it does happen. For example, a manager may choose to allow a programmer to make “emergency” changes to a production system (in violation of good separation of duties and the change management process) because the system cannot go down during a given period of time. The manager accepts that the risk that the programmer could possibly make unauthorized changes is outweighed by the high-availability requirement of that system. However, there should always be some additional controls, such as a management review or a standardized approval process, to ensure the assumed risk is adequately managed.

Understand that risk cannot be completely eliminated. A risk that remains after implementing controls is a residual risk. In this step, you further evaluate residual risks to identify where additional controls are required to reduce risk even more. As stated earlier, the risk management process is iterative.

Security Controls

Security controls are the mechanisms employed to minimize exposure to risk and mitigate the effects of loss. Using the security attributes of confidentiality, integrity, and availability associated with data, it is incumbent upon the security team to determine the appropriate set of controls to achieve the security objectives.

Just as security controls play a role in information security, the proper application of controls can assist in the risk management associated with physical security. Controls can be of a variety of types, as described in this chapter. The different categories of controls do not act as a taxonomy because there are overlapping descriptions and some control categories come from third-party policies and procedures.

Deterrent

A deterrent control acts to influence the attacker by reducing the likelihood of success. An example would be laws and regulations that increase punishment. Note that a deterrent control must be one that has to be known to a person for it to be effective. If it is unknown, it cannot deter. An example of this is a physical control, such as a CCTV or a warning sign. If a potential intruder does not see them, they cannot deter the intruder.

Preventive

A preventative control is one that prevents specific actions from occurring; for example, a mantrap prevents tailgating. Preventative controls act before an event, preventing it from advancing. Unlike a deterrent control (which in itself also acts as a preventative control), a control classified as preventative does not have to be known by a person in order to be effective (e.g., a firewall rule).

Detective

A detective control is one that facilitates the detection of a physical security breach. Detective controls act during an event, alerting operators to specific conditions. Alarms are common examples of detective controls.

Corrective

Corrective controls are used post event, in an effort to minimize the extent of damage. Backups are a prime example of a corrective control because they can facilitate rapid resumption of operations.

Compensating

A compensating control is one that is used to meet a requirement when the requirement cannot be directly met. Fire suppression systems do not stop fire damage, but if properly employed, they can mitigate or limit the level of damage from fire.

Technical

A technical control is the use of some form of technology to address a physical security issue. Biometrics are examples of technical controls.

Administrative

An administrative control is a policy or procedure used to limit physical security risk. Instructions to guards act as administrative controls.

Physical

A physical control is one that prevents specific physical actions from occurring; for example, a mantrap prevents tailgating. Physical controls prevent specific human interaction with a system and are primarily designed to prevent accidental operation of something. Physical controls act before an event, preventing it from actually occurring. Using covers over critical buttons is one example, as is a big red “STOP” button, positioned so it is easily reachable. The former stops inadvertent activation, while the latter facilitates easy activation in an emergency.

Business Risks

No comprehensive identification of all risks in a business environment is possible. In today’s technology-dependent business environment, risk is often simplistically divided into two areas: business risk and, a major subset, technology risk.

Examples of Business Risks

The following are some of the most common business risks:

   Treasury management Management of company holdings in bonds, futures, currencies, and so on

   Revenue management Management of consumer behavior and the generation of revenue

   Contract management Management of contracts with customers, vendors, partners, and so on

   Fraud Deliberate deception made for personal gain, to obtain property or services, and so on

   Environmental risk management Management of risks associated with factors that affect the environment

   Regulatory risk management Management of risks arising from new or existing regulations

   Business continuity management Management of risks associated with recovering and restoring business functions after a disaster or major disruption occurs

   Technology Management of risks associated with technology in its many forms

Examples of Technology Risks

The following are some of the most common technology risks:

   Security and privacy The risks associated with protecting personal, private, or confidential information

   Information technology operations The risks associated with the day-to-day operation of information technology systems

   Business systems control and effectiveness The risks associated with manual and automated controls that safeguard company assets and resources

   Business continuity management The risks associated with the technology and processes to be used in the event of a disaster or major disruption

   Information systems testing The risks associated with testing processes and procedures of information systems

   Reliability and performance management The risks associated with meeting reliability and performance agreements and measures

   Information technology asset management The risks associated with safeguarding information technology physical assets

   Project risk management The risks associated with managing information technology projects

   Change management The risks associated with managing configurations and changes (see Chapter 21)

Business Impact Analysis

Business impact analysis (BIA) is the name often used to describe a document created by addressing the questions associated with sources of risk and the steps taken to mitigate them in the enterprise. The BIA also outlines what the loss of any of your critical functions will mean to the organization. There are a range of terms and concepts used in describing and understanding the nature and role of risk in the business environment, and they are explored in this section.

Mission-Essential Functions

When examining risk and impacts to a business, it is important to separate mission-essential functions from other business functions. In most businesses, the vast majority of daily functions, although important, are not mission essential. Mission-essential functions are those that should they not occur or should they be performed improperly, the mission of the organization will be directly affected. The reason that identifying these functions is vital for risk management is simple: this is where you spend the majority of your effort, protecting the functions that are essential. Other functions may need protection, but their impairment will not cause the immediate impact that a mission-essential function would.

Identification of Critical Systems

A part of identifying mission-essential functions is identifying the systems and data that support the functions. Identification of critical systems enables the security team to properly prioritize defenses to protect the systems and data in a manner commensurate with the associated risk.

Single Point of Failure

A key principle of security is defense in depth. This layered approach to security is designed to eliminate any specific single points of failure. A single point of failure is any aspect that if triggered could result in the failure of the system. Redundancies have costs, but if the alternative cost is failure, then levels of redundancy are acceptable. For mission-essential systems, single points of failure are items that need to be called to management’s attention, with full explanation of the risk and costs associated with them. There may be times that dealing with the single point of failure is not possible or practical, but everyone should understand the nature of the situation and resultant risk profile.

Impact

Risk is the chance of something not working as planned. Impact is the cost associated with a realized risk. Impact can be in many forms, including human life as in injury or death, property loss, safety, financial loss, or loss of reputation. Losses are seldom absolute; they can come in all sizes and combinations. Different levels of risk can result in different levels of impact. Sometimes external events can affect the impact. If everyone in the industry has been experiencing a specific type of loss and your firm had time and warning to mitigate it but didn’t, the environment defined by these outside factors may well indeed increase the impact to your firm from this type of event.

Life

There are IT systems that are involved in medicine, and failures of these systems can and has resulted in injury and death to patients. Other machines in industrial settings can have similar impacts. Injury and loss of life are outcomes that backups cannot address and can result in consequences beyond others.

Property

Property damage can be the result of unmitigated risk. This includes property damage to company-owned property, property damage to the property of others, and even environmental damage from toxic releases in industrial settings. One example is the Shamoon malware that destroyed the computing resources of Saudi Aramco to the point that the company had to buy replacement equipment because reimaging to a clean state was neither a guaranteed nor a timely solution.

Safety

Safety is the level of concern one places on the well-being of people. In a manufacturing environment, with moving equipment and machines that can present a danger to workers, government regulations drive specific actions to mitigate risk and make the workplace as safe as possible. Computers are becoming more involved in all aspects of businesses, and they can impact safety. Unsafe conditions that are the result of computer issues will face the same regulatory wrath that unsafe factories have caused in manufacturing, namely, fines and criminal complaints.

Finance

Finance is in many ways the final arbiter of all activities because it is how people keep score. You can measure the gains through sales and profit and the losses through unmitigated risks. You can take most events, put a dollar price on them, and settle the books. Where this becomes an issue is when the impacts exceed the expected costs associated with the planned residual risks because then the costs directly impact profit.

Reputation

Corporate reputation is important in marketing. Would you deal with a bank with a shoddy record of accounting or losing personal information? How about online retailing? Would your customer base think twice before entering their credit card information after a data breach? These are not purely hypothetical questions; these events have occurred, and corporate reputations have been damaged. Firms have lost customer base and revenue.

Risk Mitigation Strategies

Risk mitigation strategies are the action plans developed after a thorough evaluation of the possible threats, hazards, and risks associated with business operations. These strategies are employed to lessen the risks associated with operations. The focus of risk mitigation strategies is to reduce the effects of threats and hazards. Common mitigation strategies include change management, incident management, user rights and permission reviews, audits, and technology controls.

Change Management

Change management has its roots in system engineering and looks at the overall view of systems components and processes. Configuration management applies to a lower level of detail, specifically, the actual configuration of components, such as hosts, devices, and so forth. Configuration management might be considered a subset of change management, but they are not the same thing. Most of today’s software and hardware change management practices derive from long-standing system engineering configuration management practices. Computer hardware and software development have also evolved to the point that proper management structure and controls must exist to ensure the products operate as planned. It is normal for an enterprise to have a change control board to approve all production changes and ensure the change management procedures are followed before changes are introduced to a system.

Configuration control is the process of controlling changes to items that have been baselined. Configuration control ensures that only approved changes to a baseline are allowed to be implemented. It is easy to understand why a software system, such as a web-based order-entry system, should not be changed without proper testing and control. Otherwise, the system might stop functioning at a critical time. Configuration control is a key step that provides valuable insight to managers. If a system is being changed and configuration control is being observed, managers and others concerned will be better informed. This ensures proper use of assets and avoids unnecessary downtime because of the installation of unapproved changes.

Incident Management

When an incident occurs, having an incident response management methodology is a key risk mitigation strategy. Incident response and incident management are essential security functions and are covered in detail in Chapter 22.

User Rights and Permissions Reviews

User rights and permissions reviews are one of the more powerful security controls. But the strength of this control depends upon it being kept up-to-date and properly maintained. Ensuring that the list of users and associated rights is complete and up-to-date is a challenging task in anything bigger than the smallest enterprises. A compensating control that can assist in keeping user rights lists current is a set of periodic audits of the user base and associated permissions.

Data Loss or Theft

Data is the primary target of most attackers. The value of the data can vary, making some data more valuable and hence more at risk of theft. Data can also be lost through a variety of mechanisms, with hardware failure, operator error, and system errors being common causes. Regardless of the cause of loss, an organization can take various actions to mitigate the effects of the loss. Backups lead the list of actions because backups can provide the ultimate in protection against loss.

To prevent theft, a variety of controls can be employed. Some are risk mitigation steps, such as data minimization, which is the act of not storing what isn’t needed. If it must be stored and has value, then technologies such as data loss prevention can be used to provide a means of protection. Simple security controls such as firewalls and network segmentation can also act to make data theft more difficult.

Risk Management Models

Risk management concepts are fundamentally the same despite their definitions, and they require similar skills, tools, and methodologies. Several models can be used for managing risk through its various phases. Two models are presented here; the first can be applied to managing risks in general, and the second is tailored for managing risk in software projects.

General Risk Management Model

The following five steps can be used in virtually any risk management process. Following these steps will lead to an orderly process of analyzing and mitigating risks.

Step 1: Asset Identification

Identify and classify the assets, systems, and processes that need protection because they are vulnerable to threats. Use a classification that fits your business. This classification leads to the ability to prioritize assets, systems, and processes and to evaluate the costs of addressing the associated risks. Assets can include the following:

   Inventory

   Services

   Buildings

   Documents

   Cash

   Personnel

   Information and data

   Brand recognition

   Hardware

   Organization reputation

   Software

   Goodwill

Step 2: Threat Assessment

After identifying the assets, you identify both the possible threats and the possible vulnerabilities associated with each asset and the likelihood of their occurrence. Threats can be defined as any circumstance or event with the potential to cause harm to an asset. Common classes of threats include the following (with examples):

   Natural disasters These are hurricanes, earthquakes, lightning, and so on.

   Man-made disasters Examples are an earthen dam failure, such as the 1976 Teton Dam failure in Idaho; a car accident that destroys a municipal power distribution transformer; and the 1973 explosion of a railcar containing propane gas in Kingman, Arizona.

   Internal vs. external Internal threats include disgruntled employees, well-meaning employees who make mistakes, or other employees who have an accident. External threats come from outside the organization and by definition begin without access to the system.

   Terrorism Examples are the 2001 destruction of the World Trade Center and the 1995 gas attack on the Shinjuku train station in Tokyo.

   Errors An example is an employee not following safety or configuration management procedures.

   Malicious damage or attacks This could be a disgruntled employee purposely corrupting data files.

   Fraud This could be an employee falsifying travel expenses or vendor invoices and payments.

   Theft This could be an employee stealing from the loading dock a laptop computer after it has been inventoried but not properly secured.

   Equipment or software failure This could be an error in the calculation of a company-wide bonus overpaying employees.

Vulnerabilities are characteristics of resources that can be exploited by a threat to cause harm. Common classes of vulnerabilities include the following (with examples):

   Unprotected facilities Company offices with no security officer present or no card-entry system

   Unprotected computer systems A server temporarily connected to the network before being properly configured/secured

   Unprotected data Not installing critical security patches to eliminate application security vulnerabilities

   Insufficient procedures and controls Allowing an accounts payable clerk to create vendors in the accounting system, enter invoices, and authorize check payments

   Insufficient or unqualified personnel A junior employee not sufficiently securing a server because of a lack of training

Step 3: Impact Determination and Quantification

An impact is the loss created when a threat exploits a vulnerability. When a threat is realized, it creates impact. Impacts can be either tangible or intangible. A tangible impact results in financial loss or physical damage. For an intangible impact, assigning a financial value of the impact can be difficult. For example, in a manufacturing facility, storing and using flammable chemicals creates a risk of fire to the facility. The vulnerability is that flammable chemicals are stored there. The threat would be that a person could cause a fire by mishandling the chemicals (either intentionally or unintentionally). A tangible impact would be the loss incurred (say, $500,000) if a person ignites the chemicals and fire then destroys part of the facility. An example of an intangible impact would be the loss of goodwill or brand damage caused by the impression that the company doesn’t safely protect its employees or the surrounding geographic area.

Tangible impacts include

   Direct loss of money

   Endangerment of staff or customers

   Loss of business opportunity

   Reduction in operational efficiency or performance

   Interruption of a business activity

Intangible impacts include

   Breach of legislation or regulatory requirements

   Loss of reputation or goodwill (brand damage)

   Breach of confidence

Step 4: Control Design and Evaluation

In this step, you determine which controls to put in place to mitigate the risks. Controls (also called countermeasures or safeguards) are designed to control risk by reducing vulnerabilities to an acceptable level. (For use in this text, the terms control, countermeasure, and safeguard are considered synonymous and are used interchangeably.)

Controls can be actions, devices, or procedures. As discussed earlier, they can be deterrent, preventive, detective, or corrective.

Step 5: Residual Risk Management

Understand that risk cannot be completely eliminated. A risk that remains after implementing controls is termed a residual risk. In this step, you further evaluate residual risks to identify where additional controls are required to reduce risk even more. This leads us to the earlier statement that the risk management process is iterative.

Software Engineering Institute Model

In an approach tailored for managing risk in software projects, SEI uses the following paradigm (SEI, Continuous Risk Management Guidebook [Pittsburgh, PA: Carnegie Mellon University, 1996], 23). Although the terminology varies slightly from the previous model, the relationships are apparent, and either model can be applied wherever risk management is used.

1.   Identify—Look for risks before they become problems.

2.   Analyze—Convert the data gathered into information that can be used to make decisions. Evaluate the impact, probability, and timeframe of the risks. Classify and prioritize each of the risks.

3.   Plan—Review and evaluate the risks and decide what actions to take to mitigate them. Implement those mitigating actions.

4.   Track—Monitor the risks and the mitigation plans. Trends may provide information to activate plans and contingencies. Review periodically to measure progress and identify new risks.

5.   Control—Make corrections for deviations from the risk mitigation plans. Correct products and processes as required. Changes in business procedures may require adjustments in plans or actions, as do faulty plans and risks that become problems.

NIST Risk Models

NIST has several informative risk models that can be applied to an enterprise. NIST has published several Special Publications (SPs) associated with risk management. SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View, presents several key insights.

   Establish a relationship between aggregated risk from information systems and mission/business success

   Encourage senior leaders to recognize the importance of managing information security risk within the organization

   Help those with system-level security responsibilities understand how system-level issues affect the organization/mission as a whole

SP 800-39 does this through the use of a model, illustrated in Figure 20.2. This model has two distinct levels of analysis, which work together as one in describing risk management actions.

• Figure 20.2    NIST risk management process applied across the tiers

The first level of analysis is represented by four elements: Frame, Assess, Respond, and Monitor. The second level is related to the tiers represented in the hierarchical triangles: Organization, Mission/Business Processes, and Information Systems.

The Frame element represents the organization’s risk framing that establishes the context and provides a common perspective on how the organization manages risk. Risk framing is central to the model, as illustrated by the arrows to the other elements. Its principal output is a risk management strategy that addresses how the organization assesses risk, responds to risk, and monitors risk. The three tiers represent the different distinct layers in an organization that are associated with risk. Tier 1, representing the executive function, is where the risk framing occurs. At Tier 2, the mission and business process layer, the risk management functions of assess, respond, and monitor occur. Tier 3 is the information system layer where activities of risk management are manifested in the systems of the organization.

This explanation is not completely correct. All steps of the risk management and assessment process can occur at all three layers; you can assess risk at Tier 1 (business or mission risk), Tier 2 (programmatic and cross-functional or aggregate system risk), and Tier 3 (system-level risk).

Model Application

The three model examples define steps that can be used in any general or software risk management process. These risk management principles can be applied to any project, program, or business activity, no matter how simple or complex. Figure 20.3 shows how risk management can be applied across the continuum and that the complexity of risk management generally increases with the size of the project, program, or business to be managed.

• Figure 20.3    Risk complexity versus project size

Qualitatively Assessing Risk

Qualitative risk analysis allows expert judgment and experience to assume a prominent role. To assess risk qualitatively, you compare the impact of the threat with the probability of occurrence and assign an impact level and probability level to the risk. For example, if a threat has a high impact and a high probability of occurring, the risk exposure is high and probably requires some action to reduce this threat (pale green box in Figure 20.4). Conversely, if the impact is low with a low probability, the risk exposure is low, and no action may be required to reduce the likelihood of the occurrence or impact of this threat (white box in Figure 20.4). Figure 20.4 shows an example of a binary assessment, where only two outcomes are possible each for impact and probability. Either it will have an impact or it will not (or it will have a low or high impact), and it will occur or it won’t (or it will have a high probability of occurring or a low probability of occurring).

• Figure 20.4    Binary assessment

In reality, a few threats can usually be identified as presenting high-risk exposure, and a few threats present low-risk exposure. The threats that fall somewhere between (pale blue boxes in Figure 20.4) will have to be evaluated by judgment and management experience.

If the analysis is more complex, requiring three levels of analysis, such as low-medium-high or green-yellow-red, then nine combinations are possible, as shown in Figure 20.5. Again, the pale green boxes probably require action, the white boxes may or may not require action, and the pale blue boxes require judgment. (Note that for brevity in Figure 20.5 the first term in each box refers to the magnitude of the impact, and the second term refers to the probability of the threat occurring.)

• Figure 20.5    Three levels of analysis

Other levels of complexity are possible. With five levels of analysis, 25 values of risk exposure are possible. In this case, the possible values of impact and probability could take on the values very low, low, medium, high, or very high. Also, note that the matrix does not have to be symmetrical. For example, if the probability is assessed with three values (low, medium, high) and the impact has five values (very low, low, medium, high, very high), the analysis would be as shown in Figure 20.6. (Again, note that the first term in each box refers to the impact, and the second term in each box refers to the probability of occurrence.)

• Figure 20.6    A three-by-five level analysis

So far, the examples have focused on assessing likelihood versus impact. Qualitative risk assessment can be adapted to a variety of attributes and situations in combination with each other. For example, Figure 20.7 shows the comparison of some specific risks that have been identified during a security assessment. The assessment identified the risk areas listed in the first column (weak intranet security, high number of modems, Internet attack vulnerabilities, and weak incident detection and response mechanism). The assessment also identified various potential impacts, listed across the top (business impact, probability of attack, cost to fix, and difficulty to fix). Each of the impacts has been assessed as low, medium, or high—depicted using green, yellow, and red, respectively. Each of the risk areas has been assessed with respect to each of the potential impacts, and an overall risk assessment has been determined in the last column.

• Figure 20.7    Example of a combination assessment

Quantitatively Assessing Risk

Whereas qualitative risk assessment relies on judgment and experience, quantitative risk assessment applies historical information and trends to attempt to predict future performance. This type of risk assessment is highly dependent on historical data, and gathering such data can be difficult. Quantitative risk assessment can also rely heavily on models that provide decision-making information in the form of quantitative metrics, which attempt to measure risk levels across a common scale.

It is important to understand that key assumptions underlie any model, and different models will produce different results even when given the same input data. Although significant research and development have been invested in improving and refining the various risk analysis models, expert judgment and experience must still be considered an essential part of any risk assessment process. Models can never replace judgment and experience, but they can significantly enhance the decision-making process.

Adding Objectivity to a Qualitative Assessment

It is possible to move a qualitative assessment toward being more quantitative. Making a qualitative assessment more detailed can be as simple as assigning numeric values to one of the tables shown in Figures 20.4 through 20.7. For example, the impacts listed in Figure 20.7 can be prioritized from highest to lowest and then weighted, as shown in Table 20.2, with business impact weighted the most and difficulty to fix weighted least. This is a semiquantitative method and may use numerical values for the sake of convenience to ease computation and provide a more defined answer, but it is still considered a qualitative method.

Table 20.2 Adding Weights and Definitions to the Potential Impacts

Next, values can be assigned to reflect how each risk was assessed. Figure 20.7 can thus be made more objective by assigning a value to each color that represents an assessment. For example, a red assessment indicates many critical, unresolved issues, and this will be given an assessment value of 3. Green means few issues are unresolved, so it is given a value of 1. Table 20.3 shows values that can be assigned for an assessment using red, yellow, and green.

Table 20.3 Adding Values to Assessments

The last step is to calculate an overall risk value for each risk area (each row in Figure 20.7) by multiplying the weights depicted in Table 20.2 times the assessed values from Table 20.3 and summing the products.

Risk = W₁ * V₁ + W₂ * V₂ + …W₄ * V₄

The risk calculation and final risk value for each risk area listed in Figure 20.7 have been incorporated into Figure 20.8. The assessed areas can then be ordered from highest to lowest based on the calculated risk value to aid management in focusing on the risk areas with the greatest potential impact.

• Figure 20.8   Final quantitative assessment of the findings

You can also add more information via an assignment of values such as shown in Table 20.3.

Risk Calculation

More complex models permit a variety of analyses based on statistical and mathematical models. A common method is the calculation of the annualized loss expectancy. Calculating the ALE creates a monetary value of the impact. This calculation begins by calculating a single loss expectancy.

Asset Value

The asset value (AV) is the amount of money it would take to replace an asset. This term is used with the exposure factor, a measure of how much of an asset is at risk, to determine the single loss expectancy.

Exposure Factor

The exposure factor is a measure of the magnitude of loss of an asset. The exposure factor is the percentage of an asset’s value that is at risk. In some cases, if the risk is realized, the asset is lost; in other cases, it may be impaired. If you have one web server and it breaks, you have 100 percent EF. If you have a farm of five web servers and two of them break, the EF is 40 percent.

For example, to calculate the exposure factor, assume the asset value of a small office building and its contents is $2 million. Also assume that this building houses the call center for a business, and the complete loss of the center would take away about half of the capability of the company. Therefore, the exposure factor is 50 percent.

SLE

The single loss expectancy is calculated using the following formula:

SLE = asset value (AV) × exposure factor (EF)

For our office building example, the SLE is

$2 million × 0.5 = $1 million

ARO

The annualized rate of occurrence is a representation of the frequency of the event, measured in a standard year. If the event is expected to occur once in 20 years, then the ARO is 1/20. Typically the ARO is defined by historical data, either from a company’s own experience or from industry surveys. Continuing our example, assume that a fire at this business’s location is expected to occur about once in 20 years. Given this information, the ALE is

$1 million × 1/20 = $50,000

ALE

The annualized loss expectancy is then calculated simply by multiplying the SLE by the likelihood or number of times the event is expected to occur in a year, which is called the annualized rate of occurrence:

ALE = SLE × ARO

The ALE determines a threshold for evaluating the cost/benefit ratio of a given countermeasure. Therefore, a countermeasure to protect this business adequately should cost no more than the calculated ALE of $50,000 per year.

The examples in this chapter have been simplistic, but they demonstrate the concepts of both qualitative and quantitative risk analysis. More complex algorithms and software packages are available for accomplishing risk analyses, but these examples suffice for the purposes of this text.

Risk Register

A risk register is a list of the risks associated with a system. It also can contain additional information associated with the risk element, such as the category to group like risks, probability of occurrence, impact to the organization, mitigation factors, and other data. There is no standardized form. The Project Management Institute has one format, and other sources have different formats. The reference document ISO 73:2009, Risk management—Vocabulary, defines a risk register to be a “record of information about identified risks.” Note that the NIST Risk Management Framework refers to this document as a Plan of Actions and Milestones and includes target dates for resolution, as well as resources and responsible personnel required.

Likelihood of Occurrence

The likelihood of occurrence is the chance a particular risk will occur. This measure can be qualitative or quantitative. For qualitative measures, it is typically defined on an annual basis to allow use of the measurement with respect to other annualized measures. If defined quantitatively, it is used to create rank order outcomes.

Impact

The impact of an event is a measure of the actual loss when a threat exploits a vulnerability. Federal Information Processing Standards (FIPS) 199 defines three levels of impact using the terms high, moderate, and low. The impact needs to be defined in terms of the context of each organization because what is high for some firms may be low for much larger firms. The common method is to define the impact levels in terms of important business criteria. Impacts can be in terms of cost (dollars), performance (service level agreement [SLA] or other requirements), schedule (deliverables), or any other important item. Impact can also be categorized in terms of the information security attribute that is relevant to the problem: confidentiality, integrity, or availability.

Supply Chain Assessment

The analysis of risk in a supply chain has become an important issue in our connected society. One needs to consider not just the risk associated with a system but the risk embedded in a system as a result of its creation, which includes risks from the supply chain associated with elements inside a system. For instance, if a system has critical components that are not replaceable except from a single source, what happens if that source quits making the component? The term supply chain assessment describes the process where these risks are determined and explored.

Qualitative vs. Quantitative Risk Assessment

It is recognized throughout industry that it is impossible to conduct risk management that is purely quantitative. Usually risk management includes both qualitative and quantitative elements, requiring both analysis and judgment or experience. In contrast to quantitative assessment, it is possible to accomplish purely qualitative risk management. It is easy to see that it is impossible to define and quantitatively measure all factors that exist in a given risk assessment. It is also easy to see that a risk assessment that measures no factors quantitatively but measures them all qualitatively is possible.

The decision of whether to use qualitative versus quantitative risk management depends on the criticality of the project, the resources available, and the management style. The decision will be influenced by the degree to which the fundamental risk management metrics, such as asset value, exposure factor, and threat frequency, can be quantitatively defined.

Testing

Understanding a system’s risk exposure is not, in actuality, a simple task. Using a series of tests, one can determine an estimate of the risk that a system has to the enterprise. Vulnerability tests detail the known vulnerabilities and the degree to which they are exposed. It is important to note that zero-day vulnerabilities will not be known, and the risk from them still remains unknown. A second form of testing, penetration testing, is used to simulate an adversary to see whether the controls in place perform to the desired level.

Penetration Testing Authorization

Penetration tests are used by organizations that want a real-world test of their security. Unlike actual attacks, penetration tests are conducted with the knowledge of the organization, although some types of penetration tests occur without the knowledge of the employees and departments being tested.

Obtaining penetration testing authorization is the first step in penetration testing. This permission step is the time that the testing team, in advance, obtains permission from the system owner to perform the penetration test. This penetration test authorization is used as a communication plan for the test. Penetration tests are typically used to verify threats or to test security controls. They do this by bypassing security controls and exploiting vulnerabilities using a variety of tools and techniques, including the attack methods discussed earlier in this book. Social engineering, malware, and vulnerability exploit tools are all fair game when it comes to penetration testing. Penetration tests actively test security controls by exploiting vulnerabilities and bypassing security controls, and this helps to verify that a risk exists.

Vulnerability Testing Authorization

Vulnerability tests are used to scan for specific vulnerabilities or weaknesses. These weaknesses if left unguarded can result in loss. Obtaining vulnerability testing authorization from management before commencing the test is the step designed to prevent avoidable accidents. Just as it is important to obtain authorization for penetration tests, it is important to obtain permission for penetration tests in the active machines. This permission is usually a multiperson process and involves explaining the risk of these tests and their purpose to the people running the system. The vulnerability tests are then analyzed with respect to how the security controls respond and notify management of the adequacy of the defenses in place.

Vulnerability Scanning Concepts

One valuable method that can help administrators secure their systems is vulnerability scanning. Vulnerability scanning is the process of examining your systems and network devices for holes, weaknesses, and issues and finding them before a potential attacker does. Specialized tools called vulnerability scanners are designed to help administrators discover and address vulnerabilities. But there is much more to vulnerability scanning than simply running tools and examining the results—administrators must be able to analyze any discovered vulnerabilities and determine their severity, how to address them if needed, and whether any business processes will be affected by potential fixes. Vulnerability scanning can also help administrators identify common misconfigurations in account setup, patch level, applications, and operating systems. Most organizations look at vulnerability scanning as an ongoing process because it is not enough to scan systems once and assume they will be secure from that point on.

Passively Test Security Controls

When an automated vulnerability scanner is used to examine a system for vulnerabilities, one of the side effects is the passive testing of the security controls. This is referred to as passive testing because the target of the vulnerability scanner is the system, not the controls. If the security controls are effective, then the vulnerability scan may not properly identify the vulnerability. If the security control prevents a vulnerability from being attacked, then it may not be exploitable.

Identify Vulnerability

Vulnerabilities are known entities; otherwise, the scanners would not have the ability to scan for them. When a scanner finds a vulnerability present in a system, it makes a log of the fact. In the end, an enumeration of the vulnerabilities that were discovered is part of the vulnerability analysis report.

Identify Lack of Security Controls

If a vulnerability is exposed to the vulnerability scanner, then a security control is needed to prevent the vulnerability from being exploited. As vulnerabilities are discovered, the specific environment of each vulnerability is documented. As the security vulnerabilities are all known in advance, the system should have controls in place to protect against exploitation. Part of the function of the vulnerability scan is to learn where controls are missing or are ineffective.

Identify Common Misconfigurations

One source of failure with respect to vulnerabilities is in the misconfiguration of a system. Common misconfigurations include access control failures and failure to protect configuration parameters. Vulnerability scanners can be programmed to test for these specific conditions and report on them.

Intrusive vs. Nonintrusive

Vulnerability scanners need a method of detecting whether a vulnerability is present and exploitable. One method is to perform a test that changes the system state, an intrusive test. The other method is to perform the test in a manner that does not directly interact with the specific vulnerability. This nonintrusive method can be significantly less accurate in the actual determination of a vulnerability. If a vulnerability scan is going to involve a lot of checks, the nonintrusive method can be advantageous because the servers may not have to be rebooted all the time.

Credentialed vs. Noncredentialed

A vulnerability scanner can be programmed with the credentials of a system, giving it the same access as an authorized user. This is assumed to be easier than running the same tests without credentials, widely considered to be a more real-world attempt. It is important to run both because if an attacker is able to compromise an account, they may well have insider credentials. Credentialed scans will be more accurate in determining whether the vulnerabilities exist because they are not encumbered by access controls. Noncredentialed scans demonstrate what the system may be vulnerable to against an outside attacker without access to a user account.

False Results

Tools are not perfect. Sometimes they will erroneously report things as an issue when they really are not a problem, and other times they won’t report an issue at all. A false positive is an incorrect finding—something that is incorrectly reported as a vulnerability. The scanner tells you there is a problem when in reality nothing is wrong. A false negative is when the scanner fails to report a vulnerability that actually does exist; the scanner simply missed the problem or didn’t report it as a problem.

System Testing

Systems can be tested in a variety of manners. One method of describing the test capabilities relates to the information given to the tester. Testers can have varying levels of detail, from complete knowledge of a system and how it works to zero knowledge. These differing levels of testing are referred to as white box, gray box, and black box testing.

Black Box

Black box testing is a testing technique where testers have no knowledge of the internal workings of the software they are testing. They treat the entire software package as a “black box”—they put input in and look at the output. They have no visibility into how the data is processed inside the application, only the output that comes back to them. Test cases for black box testing are typically constructed around intended functionality (what the software is supposed to do) and focus on providing both valid and invalid inputs. Black box software testing techniques are useful for examining any web-based application. Web-based applications are typically subjected to a barrage of valid, invalid, malformed, and malicious input from the moment they are exposed to public traffic.

White Box

White box testing is almost the polar opposite of black box testing. Sometimes called clear-box testing, white box techniques test the internal structures and processing within an application for bugs, vulnerabilities, and so on. A white box tester will have detailed knowledge of the application they are examining—they’ll develop test cases designed to exercise each path, decision tree, input field, and processing routine of the application. White box testing is often used to test paths within an application (if X, then go do this; if Y, then go do that), data flows, decision trees, and so on.

Gray Box

What happens when you mix a bit of black box testing and a bit of white box testing? You get gray box testing. In a gray box test, the testers typically have some knowledge of the software, network, or systems they are testing. For this reason, gray box testing can be efficient and effective because testers can often quickly eliminate entire testing paths, test cases, and toolsets and can rule out things that simply won’t work and are not worth trying.

Pen Testing vs. Vulnerability Scanning

Penetration testing is the examination of a system for vulnerabilities that can be exploited. The key is exploitation. There may be vulnerabilities in a system. In fact, one of the early steps in penetration testing is the examination for vulnerabilities, but the differentiation comes in the follow-on steps, which examine the system in terms of exploitability.

Penetration Testing

A penetration test (or pen test) simulates an attack from a malicious outsider, probing your network and systems for a way in (often any way in). Pen tests are often the most aggressive form of security testing and can take on many forms, depending on what is considered “in” or “out” of scope. For example, some pen tests simply seek to find a way into the network—any way in. This can range from an attack across network links to social engineering to having a tester physically break into the building. Other pen tests are limited—only attacks across network links are allowed, with no physical attacks.

Regardless of the scope and allowed methods, the goal of a pen test is the same: to determine whether an attacker can bypass your security and access your systems. Unlike a vulnerability assessment, which typically just catalogs vulnerabilities, a pen test attempts to exploit vulnerabilities to see how much access that vulnerability allows. Penetration tests are useful in that they

   Can show relationships between a series of “low-risk” items that can be sequentially exploited to gain access (making them a “high-risk” item in the aggregate)

   Can be used to test the training of employees, the effectiveness of your security measures, and the ability of your staff to detect and respond to potential attackers

   Can often identify and test vulnerabilities that are difficult or even impossible to detect with traditional scanning tools

An effective penetration test offers several critical elements. First, it focuses on the most commonly employed threat vectors seen in the current threat environment. Using zero-day exploits that no one else has does not help an organization understand its security defenses against the existing threat environment. It is important to mimic real-world attackers if that is what the company wants to test its defenses against. The second critical element is to focus on real-world attacker objectives, such as getting to and stealing intellectual property. Just bypassing defenses but not obtaining the attacker’s objectives, again, does not provide a full exercise of security capabilities. The objective is to measure actual risk under real-world conditions.

Reconnaissance

Reconnaissance is the first step of performing a penetration test. The objective of reconnaissance is to obtain an understanding of the system and its components that someone wants to attack. There are multiple methods that can be employed to achieve this objective, and in most cases, multiple methods will be employed to ensure good coverage of the systems and to find the potential vulnerabilities that may be present. There are two classifications for reconnaissance activities, active and passive. Active reconnaissance testing involves tools that actually interact with the network and systems in a manner that their use can be observed. Active reconnaissance can provide a lot of useful information; you just need to be aware that their use may alert defenders to the impending attack. Passive reconnaissance is the use of tools that do not provide information to the network or systems under investigation. Google hacking is a prime example; Google and other third parties such as Shodan allow you to gather information without sending packets to a system where they could be observed.

Passive vs. Active Tools

Tools can be classified as active or passive. Active tools interact with a target system in a fashion where their use can be detected. Scanning a network with Nmap (Network Mapper) is an active act that can be detected. In the case of Nmap, the tool may not be specifically detectable, but its use, the sending of packets, can be detected. When you need to map out your network or look for open services on one or more hosts, a port scanner is probably the most efficient tool for the job. Passive tools are those that do not interact with the system in a manner that would permit detection through sending packets or altering traffic. An example of a passive tool is Tripwire, which can detect changes to a file based on hash values. Another passive example is OS mapping by analyzing TCP/IP traces with a tool such as Wireshark. Passive sensors can use existing traffic to provide data for analysis.

Pivot

Pivoting is a key method used by a pen tester or attacker to move across a network. The first step is the attacker obtaining a presence on a machine; let’s call it machine A. The attacker then remotely through this machine examines the network again, using machine A’s IP address. This enables an attacker to see sections of networks that were not observable from the previous position. Performing a pivot is not easy because the attacker not only must establish access to machine A but also must move their tools to machine A and control those tools remotely from another machine, all while not being detected. This activity, also referred to as traversing a network, is one place where defenders can observe the attacker’s activity. When an attacker traverses the network, network security monitoring tools will detect the activity as unusual with respect to both the account being utilized and the actual traversing activity.

Initial Exploitation

A key element of a penetration test is the actual exploitation of a vulnerability. Exploiting the vulnerabilities encountered serves two purposes. First, it demonstrates the level of risk that is actually present. Second, it demonstrates the viability of the mechanism of the attack vector. During a penetration test, the exploitation activity stops short of destructive activity. The initial exploitation is the first step because just being able to demonstrate that a vulnerability is present and exploitable does not demonstrate that the objective of the penetration test is achievable. In many cases, multiple methods, including pivoting (network traversal) and escalation of privilege to perform activities with administrator privileges, are used to achieve the final desired effect.

Persistence

Persistence is one of the key elements of a whole class of attacks referred to as advanced persistent threats (APTs). APTs place two elements at the forefront of all activity: invisibility from defenders and persistence. APT actors tend to be patient and use techniques that make it difficult to remove them once they have gained a foothold. Persistence can be achieved via a wide range of mechanisms, from agents that beacon back out to malicious accounts to vulnerabilities introduced to enable reinfection.

Escalation of Privilege

Escalation of privilege is the movement to an account that enables root or higher-level privilege. Typically this occurs when a normal user account exploits a vulnerability on a process that is operating with root privilege, and as a result of the specific exploit, the attacker assumes the privileges of the exploited process at the root level. Once this level of privilege is achieved, additional steps are taken to provide a persistent access back to the privileged level. With root access, things such as log changes and other changes are possible, expanding the ability of the attacker to achieve their objective and to remove information, such as logs that could lead to detection of the attack.

Tools

Many tools can be used to enhance the risk management process. The following tools can be used during the various phases of risk assessment to add objectivity and structure to the process. Understanding the details of each of these tools is not necessary for the CompTIA Security+ exam, but understanding what they can be used for is important. You can find more information on these tools in any good project management book.

   Affinity grouping A method of identifying items that are related and then identifying the principle that ties them together.

   Baseline identification and analysis The process of establishing a baseline set of risks. It produces a “snapshot” of all the identified risks at a given point in time.

   Cause-and-effect analysis Identifying relationships between a risk and the factors that can cause it. This is usually accomplished using fishbone diagrams developed by Dr. Kaoru Ishikawa, former professor of engineering at the Science University of Tokyo.

   Cost/benefit analysis A straightforward method for comparing cost estimates with the benefits of a mitigation strategy.

   Gantt charts A management tool for diagramming schedules, events, and activity duration.

   Interrelationship digraphs A method for identifying cause-and-effect relationships by clearly defining the problem to be solved, identifying the key elements of the problem, and then describing the relationships between each of the key elements.

   Pareto charts A histogram that ranks the categories in a chart from most frequent to least frequent, thus facilitating risk prioritization.

   Program evaluation and review technique (PERT) charts A diagram depicting interdependencies between project activities, showing the sequence and duration of each activity. When complete, the chart shows the time necessary to complete the project and the activities that determine that time (the critical path).

   Risk management plan A comprehensive plan documenting how risks will be managed on a given project. It contains processes, activities, milestones, organizations, responsibilities, and details of each major risk management activity and how it is to be accomplished. It is an integral part of the project management plan.

Cost-Effectiveness Modeling

Cost-effectiveness modeling assumes you are incurring a cost and focuses on the question of what the value of that cost is. This is a rational means of economic analysis used to determine the utility of a specific strategy. It is a nearly foregone conclusion you will be spending resources on security; it’s just a question of what you get for your money.

The total cost of ownership (TCO) is the set of all costs, including everything from capital costs to operational and exception-handling costs, that is associated with a technology. There are a lot of arguments over how to calculate TCO, typically to favor one solution over another, but that is not important in this instance. It is important to note the differences between normal operational costs and exception handling. Exception handling is always more expensive.

The objective in risk management is to have a set of overlapping controls such that the TCO is minimized. This means that the solution has a measured effectiveness across the risk spectrum. This is where the compliance versus security debate becomes interesting. You establish compliance rules for a variety of reasons, but once established, their future effectiveness depends upon the assumption that the same risk environment exists as when they were created. Should the risk, the value, or the impact change over time, the cost effectiveness of the compliance-directed control can shift, frequently in a negative fashion.

Risk Management Best Practices

Best practices are the best defenses that an organization can employ in any activity. One manner of examining best practices is to ensure that the business has the set of best practices to cover its operational responsibilities. At a deeper level, the details of these practices need to themselves be best practices if you are to get the best level of protection. At a minimum, risk mitigation best practices include business continuity, high availability, fault tolerance, and disaster recovery concepts.

None of these operates in isolation. In fact, they are all interconnected, sharing elements as they all work together to achieve a common purpose: the security of the data in the enterprise, which is measured in terms of risk exposure. Key elements of best practices include understanding the vulnerabilities, understanding the threat vectors and likelihoods of occurrence, and the use of mitigation techniques to reduce residual risk to manageable levels.

System Vulnerabilities

Vulnerabilities are characteristics of an asset that can be exploited by a threat to cause harm. All systems have bugs or errors. Not all errors or bugs are vulnerabilities. For an error or bug to be classified as a vulnerability, it must be exploitable, meaning an attacker must be able to use the bug to cause a desired result. There are three elements needed for a vulnerability to occur.

   The system must have a flaw.

   The flaw must be accessible by an attacker.

   The attacker must possess the ability to exploit the flaw.

Vulnerabilities can exist in many levels and from many causes. From design errors, coding errors, or unintended (and untested) combinations in complex systems, there are numerous forms of vulnerabilities. Vulnerabilities can exist in software, hardware, and procedures. Whether in the underlying system, in a security control designed to protect the system, or in the procedures employed in the operational use of the system, the result is the same: a vulnerability represents an exploitable weakness that increases the level of risk associated with the system.

Threat Vectors

A threat is any circumstance or event with the potential to cause harm to an asset. For example, a malicious hacker might choose to hack your system by using readily available hacking tools. Threats can be classified in groups, with the term threat vector describing the elements of these groups. A threat vector is the path or tool used by an attacker to attack a target. There is a wide range of threat vectors that a security professional needs to understand.

   The Web (fake sites, session hijacking, malware, watering hole attacks)

   Wireless unsecured hotspots

   Mobile devices (iOS/Android)

   USB (removable) media

   E-mail (links, attachments, malware)

   Social engineering (deceptions, hoaxes, scams, and fraud)

This listing is merely a sample of threat vectors. From a defensive point of view, it is important not to become fixated on specific threats but rather to pay attention to the threat vectors. If a user visits a web site that has malicious code, then the nature of the code, although important from a technical view in one respect, is not the primary concern. The primary issue is the malicious site because this is the threat vector.

Probability/Threat Likelihood

The probability or likelihood of an event is a measure of how often it is expected to occur. From a qualitative assessment, using terms such as frequent, occasionally, rare, and the quantitative measure ARO, the purpose is to allow scaling based on frequency of an event. Determining the specific probabilities of security events with any accuracy is a nearly impossible feat. What is important in the use of probabilities and likelihoods is the relationship they have with respect to determining relative risk. Just as an insurance company cannot tell you when you will have an accident, no one can predict when a security event will occur. What can be determined is that over some course of time—say, the next year—a significant number of users will click malicious links in e-mails. The threat likelihood of different types of attacks will change over time. Years ago, web defacements were all the rage. Today, spear phishing is more prevalent.

When examining risk, the probability or threat likelihood plays a significant role in the determination of risk and mitigation options. In many cases, the likelihood is treated as certain, and for repeat attacks, this may be appropriate, but it certainly is not universally true.

Risks Associated with Cloud Computing and Virtualization

When examining a complex system such as a cloud or virtual computing environment from a risk perspective, several basic considerations always need to be observed. First, the fact that a system is either in the cloud or virtualized does not change how risk works. Risk is everywhere, and changing a system to a new environment does not change the fact that there are risks. Second, complexity can increase risk exposure.

There are specific risks associated with both virtualization and cloud environments. Having data and computing occur in environments that are not under the direct control of the data owner adds both a layer of complexity and a degree of risk. The potential for issues with confidentiality, integrity, and availability increases with the loss of direct control over the environment. The virtualization and cloud layers also present new avenues of attack into a system.

Security is a particular challenge when data and computation are handled by a remote party, as in cloud computing. The specific challenge is how to allow data outside your enterprise and yet remain in control over the use of the data. The common answer is encryption. Through the proper use of encryption of data before it leaves the enterprise, external storage can still be performed securely by properly employing cryptographic elements. The security requirements associated with confidentiality, integrity, and availability remain the responsibility of the data owner, and measures must be taken to ensure that these requirements are met, regardless of the location or usage associated with the data. Another level of protections is through the use of service level agreements (SLAs) with the cloud vendor, although these frequently cannot offer much remedy in the event of data loss.