CISSP ALL-IN-ONE-9e Cap 2.pdf

Risk Management CHAPTER 2 This chapter presents the following: Risk management (assessing risks, respond...

Risk Management CHAPTER 2 This chapter presents the following: Risk management (assessing risks, responding to risks, monitoring risks) Supply chain risk management Business continuity A ship in harbor is safe, but that is not what ships are built for. —William G.T. Shedd We next turn our attention to the concept that should underlie every decision made when defending our information systems: risk. Risk is so important to understand as a cybersecurity professional that we not only cover it in detail in this chapter (one of the longest in the book) but also return to it time and again in the rest of the book. We start off narrowly by focusing on the vulnerabilities in our organizations and the threats that would exploit them to cause us harm. That sets the stage for an in-depth discussion of the main components of risk management: framing, assessing, responding to, and moni- toring risks. We pay particular attention to supply chain risks, since these represent a big problem to which many organizations pay little or no attention. Finally, we’ll talk about business continuity because it is so closely linked to risk management. We’ll talk about disaster recovery, a closely related concept, in later chapters. Risk Management Concepts Risk in the context of security is the likelihood of a threat source exploiting a vulner- ability and the corresponding business impact. Risk management (RM) is the process of identifying and assessing risk, reducing it to an acceptable level, and ensuring it remains at that level. There is no such thing as a 100-percent-secure environment. Every environ- ment has vulnerabilities and threats. The skill is in identifying these threats, assessing the probability of them actually occurring and the damage they could cause, and then taking the right steps to reduce the overall level of risk in the environment to what the organiza- tion identifies as acceptable. Risks to an organization come in different forms, and they are not all computer related. As we saw in Chapter 1, when a company acquires another company, it takes on a lot of risk in the hope that this move will increase its market base, productivity, 53 CISSP All-in-One Exam Guide 54 and profitability. If a company increases its product line, this can add overhead, increase the need for personnel and storage facilities, require more funding for different materials, and maybe increase insurance premiums and the expense of marketing campaigns. The risk is that this added overhead might not be matched in sales; thus, profitability will be reduced or not accomplished. When we look at information security, note that an organization needs to be aware of several types of risk and address them properly. The following items touch on the major categories: Physical damage Fire, water, vandalism, power loss, and natural disasters Human interaction Accidental or intentional action or inaction that can disrupt productivity Equipment malfunction Failure of systems and peripheral devices Inside and outside attacks Hacking, cracking, and attacking Misuse of data Sharing trade secrets, fraud, espionage, and theft Loss of data Intentional or unintentional loss of information to unauthorized parties Application error Computation errors, input errors, and software defects Threats must be identified, classified by category, and evaluated to calculate their damage potential to the organization. Real risk is hard to measure, but prioritizing the potential risks in the order of which ones must be addressed first is obtainable. Holistic Risk Management Who really understands risk management? Unfortunately, the answer to this question is that not enough people inside or outside of the security profession really get it. Even though information security is big business today, the focus all too often is on applica- tions, devices, viruses, and hacking. Although these items all must be considered and weighed in risk management processes, they should be considered pieces of the overall security puzzle, not the main focus of risk management. Security is a business issue, but businesses operate to make money, not just to be secure. A business is concerned with security only if potential risks threaten its bottom line, which they can in many ways, such as through the loss of reputation and customer base after a database of credit card numbers is compromised; through the loss of thousands of dollars in operational expenses from a new computer worm; through the loss of proprietary information as a result of successful company espionage attempts; through the loss of confidential information from a successful social engineering attack; and so on. It is critical that security professionals understand these individual threats, but it is more important that they understand how to calculate the risk of these threats and map them to business drivers.  Chapter 2: Risk Management 55 To properly manage risk within an organization, you have to look at it holistically. Risk, after all, exists within a context. The U.S. National Institute of Standards and PART I Technology (NIST) Special Publication (SP) 800-39, Managing Information Security Risk, defines three tiers to risk management: Organization view (Tier 1) Concerned with risk to the organization as a whole, which means it frames the rest of the conversation and sets important parameters such as the risk tolerance level. Mission/business process view (Tier 2) Deals with the risk to the major functions of the organization, such as defining the criticality of the information flows between the organization and its partners or customers. Information systems view (Tier 3) Addresses risk from an information systems perspective. Though this is where we will focus our discussion, it is important to understand that it exists within the context of (and must be consistent with) other, more encompassing risk management efforts. These tiers are dependent on each other, as shown in Figure 2-1. Risk management starts with decisions made at the organization tier, which flow down to the other two tiers. Feedback on the effects of these decisions flows back up the hierarchy to inform the next set of decisions to be made. Carrying out risk management properly means that you have a holistic understanding of your organization, the threats it faces, the countermeasures that can be put into place to deal with those threats, and continuous monitoring to ensure the acceptable risk level is being met on an ongoing basis. Figure 2-1 The three tiers of risk management (Source: NIST SP 800-39) CISSP All-in-One Exam Guide 56 Information Systems Risk Management Policy Proper risk management requires a strong commitment from senior leaders, a docu- mented process that supports the organization’s mission, an information systems risk management (ISRM) policy, and a delegated ISRM team. The ISRM policy should be a subset of the organization’s overall risk management policy (risks to an organization include more than just information security issues) and should be mapped to the organiza- tional security policies. The ISRM policy should address the following items: The objectives of the ISRM team The level of risk the organization will accept and what is considered an acceptable level of risk Formal processes of risk identification The connection between the ISRM policy and the organization’s strategic planning processes Responsibilities that fall under ISRM and the roles to fulfill them The mapping of risk to internal controls The approach toward changing staff behaviors and resource allocation in response to risk analysis The mapping of risks to performance targets and budgets Key metrics and performance indicators to monitor the effectiveness of controls The ISRM policy provides the foundation and direction for the organization’s security risk management processes and procedures and should address all issues of information security. It should provide direction on how the ISRM team communicates information on the organization’s risks to senior management and how to properly execute management’s decisions on risk mitigation tasks. The Risk Management Team Each organization is different in its size, security posture, threat profile, and security budget. One organization may have one individual responsible for ISRM or a team that works in a coordinated manner. The overall goal of the team is to ensure that the organi- zation is protected in the most cost-effective manner. This goal can be accomplished only if the following components are in place: An established risk acceptance level provided by senior management Documented risk assessment processes and procedures Procedures for identifying and mitigating risks Appropriate resource and fund allocation from senior management Security awareness training for all staff members associated with information assets The ability to establish improvement (or risk mitigation) teams in specific areas when necessary  Chapter 2: Risk Management 57 The mapping of legal and regulation compliancy requirements to control and implement requirements PART I The development of metrics and performance indicators so as to measure and manage various types of risks The ability to identify and assess new risks as the environment and organization change The integration of ISRM and the organization’s change control process to ensure that changes do not introduce new vulnerabilities Obviously, this list is a lot more than just buying a new shiny firewall and calling the organization safe. The ISRM team, in most cases, is not made up of employees with the dedicated task of risk management. It consists of people who already have a full-time job in the organization and are now tasked with something else. Thus, senior management support is necessary so proper resource allocation can take place. Of course, all teams need a leader, and ISRM is no different. One individual should be singled out to run this rodeo and, in larger organizations, this person should be spending 50 to 70 percent of their time in this role. Management must dedicate funds to making sure this person receives the necessary training and risk analysis tools to ensure it is a successful endeavor. The Risk Management Process By now you should believe that risk management is critical to the long-term security (and even success) of your organization. But how do you get this done? NIST SP 800-39 describes four interrelated components that comprise the risk management process. These are shown in Figure 2-2. Let’s consider each of these components briefly now, since they will nicely frame the remainder of our discussion of risk management. Frame risk Risk framing defines the context within which all other risk activities take place. What are our assumptions and constraints? What are the organizational priorities? What is the risk tolerance of senior management? Assess risk Before we can take any action to mitigate risk, we have to assess it. This is perhaps the most critical aspect of the process, and one that we will discuss at length. If your risk assessment is spot-on, then the rest of the process becomes pretty straightforward. Respond to risk By now, we’ve done our homework. We know what we should, must, and can’t do (from the framing component), and we know what we’re up against in terms of threats, vulnerabilities, and attacks (from the assess component). Responding to the risk becomes a matter of matching our limited resources with our prioritized set of controls. Not only are we mitigating significant risk, but, more importantly, we can tell our bosses what risk we can’t do anything about because we’re out of resources. CISSP All-in-One Exam Guide 58 Figure 2-2 The components Assess of the risk management process Frame Monitor Respond Monitor risk No matter how diligent we’ve been so far, we probably missed something. If not, then the environment likely changed (perhaps a new threat source emerged or a new system brought new vulnerabilities). In order to stay one step ahead of the bad guys, we need to continuously monitor the effectiveness of our controls against the risks for which we designed them. You will notice that our discussion of risk so far has dealt heavily with the whole framing process. In the preceding sections, we’ve talked about the organization (top to bottom), the policies, and the team. The next step is to assess the risk, and what better way to start than by understanding threats and the vulnerabilities they might exploit. Overview of Vulnerabilities and Threats To focus our efforts on the likely (and push aside the less likely) risks to our organiza- tions, we need to consider what it is that we have that someone (or something) else may be able to take, degrade, disrupt, or destroy. As we will see later (in the section “Assessing Risks”), inventorying and categorizing our information systems is a critical early step in the process. For the purpose of modeling the threat, we are particularly interested in the vulnerabilities inherent in our systems that could lead to the compromise of their confidentiality, integrity, or availability. We then ask the question, “Who would want to exploit this vulnerability, and why?” This leads us to a deliberate study of our potential adversaries, their motivations, and their capabilities. Finally, we determine whether a given threat source has the means to exploit one or more vulnerabilities in order to attack our assets. NOTE We will discuss threat modeling in detail in Chapter 9.  Chapter 2: Risk Management 59 Vulnerabilities Everything built by humans is vulnerable to something. Our information systems, in PART I particular, are riddled with vulnerabilities even in the best-defended cases. One need only read news accounts of the compromise of the highly protected and classified systems of defense contractors and even governments to see that this universal principle is true. To properly analyze vulnerabilities, it is useful to recall that information systems consist of information, processes, and people that are typically, but not always, interacting with computer systems. Since we discuss computer system vulnerabilities in detail in Chapter 6, we will briefly discuss the other three components here. Information In almost every case, the information at the core of our information systems is the most valuable asset to a potential adversary. Information within a computer information system (CIS) is represented as data. This information may be stored (data at rest), transported between parts of our system (data in transit), or actively being used by the system (data in use). In each of its three states, the information exhibits different vulnerabilities, as listed in the following examples: Data at rest Data is copied to a thumb drive and given to unauthorized parties by an insider, thus compromising its confidentiality. Data in transit Data is modified by an external actor intercepting it on the network and then relaying the altered version (known as a man-in-the-middle or MitM attack), thus compromising its integrity. Data in use Data is deleted by a malicious process exploiting a “time-of-check to time-of-use” (TOC/TOU) or “race condition” vulnerability, thus compromising its availability. Processes Most organizations implement standardized processes to ensure the consistency and efficiency of their services and products. It turns out, however, that efficiency is pretty easy to hack. Consider the case of shipping containers. Someone wants to ship something from point A to point B, say a container of bananas from Brazil to Belgium. Once the shipping order is placed and the destination entered, that information flows from the farm to a truck carrier, to the seaport of origin to the ocean carrier, to the destination seaport, to another truck carrier, and finally to its destination at some distribution center in Antwerp. In most cases, nobody pays a lot of attention to the address once it is entered. But what if an attacker knew this and changed the address while the shipment was at sea? The attacker could have the shipment show up at a different destination and even control the arrival time. This technique has actually been used by drug and weapons smuggling gangs to get their “bananas” to where they need them. This sort of attack is known as business process compromise (BPC) and is commonly targeted at the financial sector, where transaction amounts, deposit accounts, or other parameters are changed to funnel money to the attackers’ pockets. Since business processes are almost always instantiated in software as part of a CIS, process vulnerabilities can be thought of as a specific kind of software vulnerability. As security professionals, however, CISSP All-in-One Exam Guide 60 it is important that we take a broader view of the issue and think about the business processes that are implemented in our software systems. People Many security experts consider humans to be the weakest link in the security chain. Whether or not you agree with this, it is important to consider the specific vulnerabilities that people present in a system. Though there are many ways to exploit the human in the loop, there are three that correspond to the bulk of the attacks, summarized briefly here: Social engineering This is the process of getting a person to violate a security procedure or policy, and usually involves human interaction or e-mail/text messages. Social networks The prevalence of social network use provides potential attackers with a wealth of information that can be leveraged directly (e.g., blackmail) or indirectly (e.g., crafting an e-mail with a link that is likely to be clicked) to exploit people. Passwords Weak passwords can be cracked in milliseconds using rainbow tables and are very susceptible to dictionary or brute-force attacks. Even strong passwords are vulnerable if they are reused across sites and systems. Threats As you identify the vulnerabilities that are inherent to your organization and its systems, it is important to also identify the sources that could attack them. The International Organization for Standardization and the International Electrotechnical Commission in their joint ISO/IEC standard 27000 define a threat as a “potential cause of an unwanted incident, which can result in harm to a system or organization.” While this may sound somewhat vague, it is important to include the full breadth of possibilities. When a threat is one or more humans, we typically use the term threat actor or threat agent. Let’s start with the most obvious: malicious humans. Cybercriminals Cybercriminals are the most common threat actors encountered by individuals and organizations. Most cybercriminals are motivated by greed, but some just enjoy breaking things. Their skills run the gamut, from so-called script kiddies with just a basic grasp of hacking (but access to someone else’s scripts or tools) to sophisticated cybercrime gangs who develop and sometimes sell or rent their services and tools to others. Cybercrime is the fastest-growing sector of criminal activity in many countries. One of the factors that makes cybercrime so pervasive is that every connected device is a target. Some devices are immediately monetizable, such as your personal smartphone or home computer containing credentials, payment card information, and access to your financial institutions. Other targets provide bigger payouts, such as the finance systems in your place of work. Even devices that are not, by themselves, easily monetizable can be hijacked and joined into a botnet to spread malware, conduct distributed denial-of- service (DDoS) attacks, or serve as staging bases from which to attack other targets. Nation-State Actors Whereas cybercriminals tend to cast a wide net in an effort to maximize their profits, nation-state actors (or simply state actors) are very selective in  Chapter 2: Risk Management 61 who they target. They use advanced capabilities to compromise systems and establish a persistent presence to allow them to collect intelligence (e.g., sensitive data, intellectual PART I property, etc.) for extended periods. After their presence is established, state actors may use prepositioned assets to trigger devastating effects in response to world events. Though their main motivations tend to be espionage and gaining persistent access to critical infrastructure, some state actors maintain good relations with cybercrime groups in their own country, mostly for the purposes of plausible deniability. By collaborating with these criminals, state actors can make it look as if an attack against another nation was a crime and not an act of war. At least one country is known to use its national offensive cyber capabilities for financial profit, stealing millions of dollars all over the world. Many security professionals consider state actors a threat mostly to government organizations, critical infrastructure like power plants, and anyone with sophisticated research and development capabilities. In reality, however, these actors can and do target other organizations, typically to use them as a springboard into their ultimate targets. So, even if you work for a small company that seems uninteresting to a foreign nation, you could find your company in a state actor’s crosshairs. Hacktivists Hacktivists use cyberattacks to effect political or social change. The term covers a diverse ecosystem, encompassing individuals and groups of various skillsets and capabilities. Hacktivists’ preferred objectives are highly visible to the public or yield information that, when made public, aims to embarrass government entities or undermine public trust in them. Internal Actors Internal actors are people within the organization, such as employees, former employees, contractors, or business associates, who have inside information concerning the organization’s security practices, data, and computer systems. Broadly speaking, there are two types of insider threats: negligent and malicious. A negligent insider is one who fails to exercise due care, which puts their organization at risk. Sometimes, these individuals knowingly violate policies or disregard procedures, but they are not doing so out of malicious intent. For example, an employee could disregard a policy requiring visitors to be escorted at all times because someone shows up wearing the uniform of a telecommunications company and claiming to be on site to fix an outage. This insider trusts the visitor, which puts the organization at risk, particularly if that person is an impostor. The second type of insider threat is characterized by malicious intent. Malicious insiders use the knowledge they have about their organization either for their own advantage (e.g., to commit fraud) or to directly cause harm (e.g., by deleting sensitive files). While some malicious insiders plan their criminal activity while they are employees in good standing, others are triggered by impending termination actions. Knowing (or suspecting) that they’re about to be fired, they may attempt to steal sensitive data (such as customer contacts or design documents) before their access is revoked. Other malicious insiders may be angry and plant malware or destroy assets in an act of revenge. This insider threat highlights the need for the “zero trust” secure design principle (discussed in Chapter 9). It is also a really good reason to practice the termination processes discussed in Chapter 1. CISSP All-in-One Exam Guide 62 In the wake of the massive leak of classified data attributed to Edward Snowden in 2012, there’s been increased emphasis on techniques and procedures for identifying and mitigating the insider threat source. While the deliberate insider dominates the news, it is important to note that the accidental insider can be just as dangerous, particularly if they fall into one of the vulnerability classes described in the preceding section. Nature Finally, the nonhuman threat source can be just as important as the ones we’ve previously discussed. Hurricane Katrina in 2005 and the Tohoku earthquake and tsunami in 2011 serve as reminders that natural events can be more destructive than any human attack. They also force the information systems security professional to consider threats that fall way outside the norm. Though it is easier and, in many cases, cheaper to address likelier natural events such as a water main break or a fire in a facility, one should always look for opportunities to leverage countermeasures that protect against both mild and extreme events for small price differentials. Identifying Threats and Vulnerabilities Earlier, it was stated that the definition of a risk is the probability of a threat exploiting a vulnerability to cause harm to an asset and the resulting business impact. Many types of threat actors can take advantage of several types of vulnerabilities, resulting in a variety of specific threats, as outlined in Table 2-1, which represents only a sampling of the risks many organizations should address in their risk management programs. Other types of threats can arise in an environment that are much harder to identify than those listed in Table 2-1. These other threats have to do with application and user errors. If an application uses several complex equations to produce results, the threat can be difficult to discover and isolate if these equations are incorrect or if the application is using inputted data incorrectly. This can result in illogical processing and cascading errors as invalid results are passed on to another process. These types of problems can lie within application code and are very hard to identify. Threat Actor Can Exploit This Vulnerability To Cause This Effect Cybercriminal Lack of antimalware software Ransomed data Nation-state actor Password reuse in privileged Unauthorized access to accounts confidential information Negligent user Misconfigured parameter in the Loss of availability due to a system operating system malfunction Fire Lack of fire extinguishers Facility and computer loss or damage, and possibly loss of life Malicious insider Poor termination procedures Deletion of business-critical information Hacktivist Poorly written web application Website defacement Burglar Lack of security guard Breaking windows and stealing computers and devices Table 2-1 Relationship of Threats and Vulnerabilities  Chapter 2: Risk Management 63 User errors, whether intentional or accidental, are easier to identify by monitoring and auditing users’ activities. Audits and reviews must be conducted to discover if employees PART I are inputting values incorrectly into programs, misusing technology, or modifying data in an inappropriate manner. After the ISRM team has identified the vulnerabilities and associated threats, it must investigate the ramifications of any of those vulnerabilities being exploited. Risks have loss potential, meaning that the organization could lose assets or revenues if a threat agent actually exploited a vulnerability. The loss may be corrupted data, destruction of systems and/or the facility, unauthorized disclosure of confidential information, a reduction in employee productivity, and so on. When performing a risk assessment, the team also must look at delayed loss when assessing the damages that can occur. Delayed loss is secondary in nature and takes place well after a vulnerability is exploited. Delayed loss may include damage to the organization’s reputation, loss of market share, accrued late penalties, civil suits, the delayed collection of funds from customers, resources required to reimage other compromised systems, and so forth. For example, if a company’s web servers are attacked and taken offline, the immediate damage (loss potential) could be data corruption, the man-hours necessary to place the servers back online, and the replacement of any code or components required. The company could lose revenue if it usually accepts orders and payments via its website. If getting the web servers fixed and back online takes a full day, the company could lose a lot more sales and profits. If getting the web servers fixed and back online takes a full week, the company could lose enough sales and profits to not be able to pay other bills and expenses. This would be a delayed loss. If the company’s customers lose confidence in it because of this activity, the company could lose business for months or years. This is a more extreme case of delayed loss. These types of issues make the process of properly quantifying losses that specific threats could cause more complex, but they must be taken into consideration to ensure reality is represented in this type of analysis. Assessing Risks A risk assessment, which is really a tool for risk management, is a method of identify- ing vulnerabilities and threats and assessing the possible impacts to determine where to implement security controls. After parts of a risk assessment are carried out, the results are analyzed. Risk analysis is a detailed examination of the components of risk that is used to ensure that security is cost-effective, relevant, timely, and responsive to threats. It is easy to apply too much security, not enough security, or the wrong security controls and to spend too much money in the process without attaining the necessary objectives. Risk analysis helps organizations prioritize their risks and shows management the amount of resources that should be applied to protecting against those risks in a sensible manner. EXAM TIP The terms risk assessment and risk analysis, depending on who you ask, can mean the same thing, or one must follow the other, or one is a subpart of the other. Here, we treat risk assessment as the broader effort, which is reinforced by specific risk analysis tasks as needed. This is how you should think of it for the CISSP exam. CISSP All-in-One Exam Guide 64 Risk analysis has four main goals: Identify assets and their value to the organization. Determine the likelihood that a threat exploits a vulnerability. Determine the business impact of these potential threats. Provide an economic balance between the impact of the threat and the cost of the countermeasure. Risk analysis provides a cost/benefit comparison, which compares the annualized cost of controls to the potential cost of loss. A control, in most cases, should not be implemented unless the annualized cost of loss exceeds the annualized cost of the control itself. This means that if a facility is worth $100,000, it does not make sense to spend $150,000 trying to protect it. It is important to figure out what you are supposed to be doing before you dig right in and start working. Anyone who has worked on a project without a properly defined scope can attest to the truth of this statement. Before an assessment is started, the team must carry out project sizing to understand what assets and threats should be evaluated. Most assessments are focused on physical security, technology security, or personnel security. Trying to assess all of them at the same time can be quite an undertaking. One of the risk assessment team’s tasks is to create a report that details the asset valuations. Senior management should review and accept the list and use these values to determine the scope of the risk management project. If management determines at this early stage that some assets are not important, the risk assessment team should not spend additional time or resources evaluating those assets. During discussions with management, everyone involved must have a firm understanding of the value of the security CIA triad—confidentiality, integrity, and availability—and how it directly relates to business needs. Management should outline the scope of the assessment, which most likely will be dictated by organizational compliance requirements as well as budgetary constraints. Many projects have run out of funds, and consequently stopped, because proper project sizing was not conducted at the onset of the project. Don’t let this happen to you. A risk assessment helps integrate the security program objectives with the organization’s business objectives and requirements. The more the business and security objectives are in alignment, the more successful both will be. The assessment also helps the organization draft a proper budget for a security program and its constituent security components. Once an organization knows how much its assets are worth and the possible threats those assets are exposed to, it can make intelligent decisions about how much money to spend protecting those assets. A risk assessment must be supported and directed by senior management if it is to be successful. Management must define the purpose and scope of the effort, appoint a team to carry out the assessment, and allocate the necessary time and funds to conduct it. It is essential for senior management to review the outcome of the risk assessment and to act on its findings. After all, what good is it to go through all the trouble of a risk assessment and not react to its findings? Unfortunately, this does happen all too often.  Chapter 2: Risk Management 65 Asset Valuation PART I To understand possible losses and how much we may want to invest in preventing them, we must understand the value of an asset that could be impacted by a threat. The value placed on information is relative to the parties involved, what work was required to develop it, how much it costs to maintain, what damage would result if it were lost or destroyed, how much money enemies would pay for it, and what liability penalties could be endured. If an organization does not know the value of the information and the other assets it is trying to protect, it does not know how much money and time it should spend on protecting them. If the calculated value of your company’s secret formula is x, then the total cost of protecting it should be some value less than x. Knowing the value of our infor- mation allows us to make quantitative cost/benefit comparisons as we manage our risks. The preceding logic applies not only to assessing the value of information and protecting it but also to assessing the value of the organization’s other assets, such as facilities, systems, and even intangibles like the value of the brand, and protecting them. The value of the organization’s facilities must be assessed, along with all printers, workstations, servers, peripheral devices, supplies, and employees. You do not know how much is in danger of being lost if you don’t know what you have and what it is worth in the first place. The actual value of an asset is determined by the importance it has to the organization as a whole. The value of an asset should reflect all identifiable costs that would arise if the asset were actually impaired. If a server cost $4,000 to purchase, this value should not be input as the value of the asset in a risk assessment. Rather, the cost of replacing or repairing it, the loss of productivity, and the value of any data that may be corrupted or lost must be accounted for to properly capture the amount the organization would lose if the server were to fail for one reason or another. The following issues should be considered when assigning values to assets: Cost to acquire or develop the asset Cost to maintain and protect the asset Value of the asset to owners and users Value of the asset to adversaries Price others are willing to pay for the asset Cost to replace the asset if lost Operational and production activities affected if the asset is unavailable Liability issues if the asset is compromised Usefulness and role of the asset in the organization Impact of the asset’s loss on the organization’s brand or reputation Understanding the value of an asset is the first step to understanding what security mechanisms should be put in place and what funds should go toward protecting it. A very important question is how much it could cost the organization to not protect the asset. CISSP All-in-One Exam Guide 66 Determining the value of assets may be useful to an organization for a variety of reasons, including the following: To perform effective cost/benefit analyses To select specific countermeasures and safeguards To determine the level of insurance coverage to purchase To understand what exactly is at risk To comply with legal and regulatory requirements Assets may be tangible (computers, facilities, supplies) or intangible (reputation, data, intellectual property). It is usually harder to quantify the values of intangible assets, which may change over time. How do you put a monetary value on a company’s reputation? This is not always an easy question to answer, but it is important to be able to do so. Risk Assessment Teams Each organization has different departments, and each department has its own function- ality, resources, tasks, and quirks. For the most effective risk assessment, an organization must build a risk assessment team that includes individuals from many or all depart- ments to ensure that all of the threats are identified and addressed. The team members may be part of management, application programmers, IT staff, systems integrators, and operational managers—indeed, any key personnel from key areas of the organization. This mix is necessary because if the team comprises only individuals from the IT depart- ment, it may not understand, for example, the types of threats the accounting department faces with data integrity issues, or how the organization as a whole would be affected if the accounting department’s data files were wiped out by an accidental or intentional act. Asking the Right Questions When looking at risk, it’s good to keep several questions in mind. Raising these questions helps ensure that the risk assessment team and senior management know what is important. Team members must ask the following: What event could occur (threat event)? What could be the potential impact (risk)? How often could it happen (frequency)? What level of confidence do we have in the answers to the first three questions (certainty)? A lot of this information is gathered through internal surveys, interviews, or workshops. Viewing threats with these questions in mind helps the team focus on the tasks at hand and assists in making the decisions more accurate and relevant.  Chapter 2: Risk Management 67 Or, as another example, the IT staff may not understand all the risks the employees in the warehouse would face if a natural disaster were to hit, or what it would mean to their PART I productivity and how it would affect the organization overall. If the risk assessment team is unable to include members from various departments, it should, at the very least, make sure to interview people in each department so it fully understands and can quantify all threats. The risk assessment team must also include people who understand the processes that are part of their individual departments, meaning individuals who are at the right levels of each department. This is a difficult task, since managers sometimes delegate any sort of risk assessment task to lower levels within the department. However, the people who work at these lower levels may not have adequate knowledge and understanding of the processes that the risk assessment team may need to deal with. Methodologies for Risk Assessment The industry has different standardized methodologies for carrying out risk assessments. Each of the individual methodologies has the same basic core components (identify vul- nerabilities, associate threats, calculate risk values), but each has a specific focus. Keep in mind that the methodologies have a lot of overlapping similarities because each one has the specific goal of identifying things that could hurt the organization (vulnerabili- ties and threats) so that those things can be addressed (risk reduced). What make these methodologies different from each other are their unique approaches and focuses. If you need to deploy an organization-wide risk management program and integrate it into your security program, you should follow the OCTAVE method. If you need to focus just on IT security risks during your assessment, you can follow NIST SP 800-30. If you have a limited budget and need to carry out a focused assessment on an individual system or process, you can follow the Facilitated Risk Analysis Process. If you really want to dig into the details of how a security flaw within a specific system could cause negative ramifications, you could use Failure Modes and Effect Analysis or fault tree analysis. NIST SP 800-30 NIST SP 800-30, Revision 1, Guide for Conducting Risk Assessments, is specific to infor- mation systems threats and how they relate to information security risks. It lays out the following steps: 1. Prepare for the assessment. 2. Conduct the assessment: a. Identify threat sources and events. b. Identify vulnerabilities and predisposing conditions. c. Determine likelihood of occurrence. d. Determine magnitude of impact. e. Determine risk. 3. Communicate results. 4. Maintain assessment. CISSP All-in-One Exam Guide 68 The NIST risk management methodology is mainly focused on computer systems and IT security issues. It does not explicitly cover larger organizational threat types, as in succession planning, environmental issues, or how security risks associate to business risks. It is a methodology that focuses on the operational components of an enterprise, not necessarily the higher strategic level. FRAP Facilitated Risk Analysis Process (FRAP) is a second type of risk assessment methodology. The crux of this qualitative methodology is to focus only on the systems that really need assessing, to reduce costs and time obligations. FRAP stresses prescreening activities so that the risk assessment steps are only carried out on the item(s) that needs it the most. FRAP is intended to be used to analyze one system, application, or business process at a time. Data is gathered and threats to business operations are prioritized based upon their criticality. The risk assessment team documents the controls that need to be put into place to reduce the identified risks along with action plans for control implementation efforts. This methodology does not support the idea of calculating exploitation probability numbers or annualized loss expectancy values. The criticalities of the risks are determined by the team members’ experience. The author of this methodology (Thomas Peltier) believes that trying to use mathematical formulas for the calculation of risk is too confusing and time consuming. The goal is to keep the scope of the assessment small and the assessment processes simple to allow for efficiency and cost-effectiveness. OCTAVE The Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) meth- odology was created by Carnegie Mellon University’s Software Engineering Institute (SIE). OCTAVE is intended to be used in situations where people manage and direct the risk evaluation for information security within their organization. This places the people who work inside the organization in the power positions of being able to make the decisions regarding what is the best approach for evaluating the security of their organization. OCTAVE relies on the idea that the people working in these environments best understand what is needed and what kind of risks they are facing. The individuals who make up the risk assessment team go through rounds of facilitated workshops. The facilitator helps the team members understand the risk methodology and how to apply it to the vulnerabilities and threats identified within their specific business units. OCTAVE stresses a self-directed team approach. The scope of an OCTAVE assessment is usually very wide compared to the more focused approach of FRAP. Where FRAP would be used to assess a system or application, OCTAVE would be used to assess all systems, applications, and business processes within the organization. The OCTAVE methodology consists of the seven processes (or steps) listed here: 1. Identify enterprise knowledge. 2. Identify operational area knowledge. 3. Identify staff knowledge.  Chapter 2: Risk Management 69 4. Establish security requirements. 5. Map high-priority information assets to information infrastructure. PART I 6. Perform infrastructure vulnerability evaluation. 7. Conduct multidimensional risk analysis. 8. Develop protection strategy. FMEA Failure Modes and Effect Analysis (FMEA) is a method for determining functions, iden- tifying functional failures, and assessing the causes of failure and their failure effects through a structured process. FMEA is commonly used in product development and operational environments. The goal is to identify where something is most likely going to break and either fix the flaws that could cause this issue or implement controls to reduce the impact of the break. For example, you might choose to carry out an FMEA on your organization’s network to identify single points of failure. These single points of failure represent vulnerabilities that could directly affect the productivity of the network as a whole. You would use this structured approach to identify these issues (vulnerabilities), assess their criticality (risk), and identify the necessary controls that should be put into place (reduce risk). The FMEA methodology uses failure modes (how something can break or fail) and effects analysis (impact of that break or failure). The application of this process to a chronic failure enables the determination of where exactly the failure is most likely to occur. Think of it as being able to look into the future and locate areas that have the potential for failure and then applying corrective measures to them before they do become actual liabilities. By following a specific order of steps, the best results can be maximized for an FMEA: 1. Start with a block diagram of a system or control. 2. Consider what happens if each block of the diagram fails. 3. Draw up a table in which failures are paired with their effects and an evaluation of the effects. 4. Correct the design of the system, and adjust the table until the system is not known to have unacceptable problems. 5. Have several engineers review the Failure Modes and Effect Analysis. Table 2-2 is an example of how an FMEA can be carried out and documented. Although most organizations will not have the resources to do this level of detailed work for every system and control, an organization can carry it out on critical functions and systems that can drastically affect the organization. FMEA was first developed for systems engineering. Its purpose is to examine the potential failures in products and the processes involved with them. This approach proved to be successful and has been more recently adapted for use in evaluating risk management priorities and mitigating known threat vulnerabilities.  70 CISSP All-in-One Exam Guide Prepared by: Approved by: Date: Revision: Failure Effect on... Component Failure Failure Failure or Functional Next Higher Detection Item Identification Function Mode Cause Assembly Assembly System Method IPS application Inline Fails to Traffic Single point of IPS blocks IPS is Health check content filter perimeter close overload failure Denial of ingress traffic brought status sent protection service stream down to console and e-mail to security administrator Central antivirus Push updated Fails to Central Individual Network is Central Heartbeat signature update signatures to provide server node’s antivirus infected with server can status check engine all servers and adequate, goes software is not malware be infected sent to central workstations timely down updated and/or console, protection infect other and e-mail against systems to network malware administrator Fire suppression Suppress fire Fails to Water None Building 1 Fire Suppression water pipes in building close in pipes has no suppression sensors tied 1 in 5 zones freezes suppression system pipes directly into agent break fire system available central console Etc. Table 2-2 How an FMEA Can Be Carried Out and Documented  Chapter 2: Risk Management 71 FMEA is used in assurance risk management because of the level of detail, variables, and complexity that continues to rise as corporations understand risk at more granular levels. PART I This methodical way of identifying potential pitfalls is coming into play more as the need for risk awareness—down to the tactical and operational levels—continues to expand. Fault Tree Analysis While FMEA is most useful as a survey method to identify major failure modes in a given system, the method is not as useful in discovering complex failure modes that may be involved in multiple systems or subsystems. A fault tree analysis usually proves to be a more useful approach to identifying failures that can take place within more complex environments and systems. First, an undesired effect is taken as the root or top event of a tree of logic. Then, each situation that has the potential to cause that effect is added to the tree as a series of logic expressions. Fault trees are then labeled with actual numbers pertaining to failure probabilities. This is typically done by using computer programs that can calculate the failure probabilities from a fault tree. Figure 2-3 shows a simplistic fault tree and the different logic symbols used to represent what must take place for a specific fault event to occur. When setting up the tree, you must accurately list all the threats or faults that can occur within a system. The branches of the tree can be divided into general categories, such as physical threats, network threats, software threats, Internet threats, and component failure threats. Then, once all possible general categories are in place, you can trim them and effectively prune from the tree the branches that won’t apply to the system in question. In general, if a system is not connected to the Internet by any means, remove that general branch from the tree. Top-level failure event is broken down into possible Failure Event A contributory failure events. OR symbol means that event A happens when one or more of events B, C, or D happen. Failure Event B Failure Event C Failure Event D AND symbol means that event D happens only when both events E and F happen. Failure Event E Failure Event F Figure 2-3 Fault tree and logic components CISSP All-in-One Exam Guide 72 Some of the most common software failure events that can be explored through a fault tree analysis are the following: False alarms Insufficient error handling Sequencing or order Incorrect timing outputs Valid but unexpected outputs Of course, because of the complexity of software and heterogeneous environments, this is a very small sample list. EXAM TIP A risk assessment is used to gather data. A risk analysis examines the gathered data to produce results that can be acted upon. Risk Analysis Approaches So up to this point, we have accomplished the following items: Developed a risk management policy Developed a risk management team Identified organizational assets to be assessed Calculated the value of each asset Identified the vulnerabilities and threats that can affect the identified assets Chosen a risk assessment methodology that best fits our needs The next thing we need to figure out is if our risk analysis approach should be quantitative or qualitative in nature. A quantitative risk analysis is used to assign monetary and numeric values to all elements of the risk analysis process. Each element within the analysis (asset value, threat frequency, severity of vulnerability, impact damage, safeguard costs, safeguard effectiveness, uncertainty, and probability items) is quantified and entered into equations to determine total and residual risks. It is more of a scientific or mathematical approach (objective) to risk analysis compared to qualitative. A qualitative risk analysis uses a “softer” approach to the data elements of a risk analysis. It does not quantify that data, which means that it does not assign numeric values to the data so that it can be used in equations. As an example, the results of a quantitative risk analysis could be that the organization is at risk of losing $100,000 if a buffer overflow were exploited on a web server, $25,000 if a database were compromised, and $10,000 if a file server were compromised. A qualitative risk analysis would not present these findings in monetary values, but would assign ratings to the risks, as in Red, Yellow, and Green. A quantitative analysis uses risk calculations that attempt to predict the level of monetary losses and the probability for each type of threat. Qualitative analysis does not  Chapter 2: Risk Management 73 use calculations. Instead, it is more opinion and scenario based (subjective) and uses a rating system to relay the risk criticality levels. PART I Quantitative and qualitative approaches have their own pros and cons, and each applies more appropriately to some situations than others. An organization’s management and risk analysis team, and the tools they decide to use, will determine which approach is best. In the following sections we will dig into the depths of quantitative analysis and then revisit the qualitative approach. We will then compare and contrast their attributes. Automated Risk Analysis Methods Collecting all the necessary data that needs to be plugged into risk analysis equations and properly interpreting the results can be overwhelming if done manually. Several automated risk analysis tools on the market can make this task much less painful and, hopefully, more accurate. The gathered data can be reused, greatly reducing the time required to perform subsequent analyses. The risk analysis team can also print reports and comprehensive graphs to present to management. EXAM TIP Remember that vulnerability assessments are different from risk assessments. A vulnerability assessment just finds the vulnerabilities (the holes). A risk assessment calculates the probability of the vulnerabilities being exploited and the associated business impact. The objective of these tools is to reduce the manual effort of these tasks, perform calculations quickly, estimate future expected losses, and determine the effectiveness and benefits of the security countermeasures chosen. Most automatic risk analysis products port information into a database and run several types of scenarios with different parameters to give a panoramic view of what the outcome will be if different threats come to bear. For example, after such a tool has all the necessary information inputted, it can be rerun several times with different parameters to compute the potential outcome if a large fire were to take place; the potential losses if a virus were to damage 40 percent of the data on the main file server; how much the organization would lose if an attacker were to steal all the customer credit card information held in three databases; and so on. Running through the different risk possibilities gives an organization a more detailed understanding of which risks are more critical than others, and thus which ones to address first. Steps of a Quantitative Risk Analysis If we choose to carry out a quantitative risk analysis, then we are going to use mathemati- cal equations for our data interpretation process. The most common equations used for this purpose are the single loss expectancy (SLE) and the annualized loss expectancy (ALE). The SLE is a monetary value that is assigned to a single event that represents the organi- zation’s potential loss amount if a specific threat were to take place. The equation is laid out as follows: Asset Value × Exposure Factor (EF) = SLE CISSP All-in-One Exam Guide 74 The exposure factor (EF) represents the percentage of loss a realized threat could have on a certain asset. For example, if a data warehouse has the asset value of $150,000, it can be estimated that if a fire were to occur, 25 percent of the warehouse would be damaged, in which case the SLE would be $37,500: Asset Value ($150,000) × Exposure Factor (25%) = $37,500 This tells us that the organization could potentially lose $37,500 if a fire were to take place. But we need to know what our annual potential loss is, since we develop and use our security budgets on an annual basis. This is where the ALE equation comes into play. The ALE equation is as follows: SLE × Annualized Rate of Occurrence (ARO) = ALE The annualized rate of occurrence (ARO) is the value that represents the estimated frequency of a specific threat taking place within a 12-month timeframe. The range can be from 0.0 (never) to 1.0 (once a year) to greater than 1 (several times a year), and anywhere in between. For example, if the probability of a fire taking place and damaging our data warehouse is once every 10 years, the ARO value is 0.1. So, if a fire within an organization’s data warehouse facility can cause $37,500 in damages, and the frequency (or ARO) of a fire taking place has an ARO value of 0.1 (indicating once in 10 years), then the ALE value is $3,750 ($37,500 × 0.1 = $3,750). The ALE value tells the organization that if it wants to put in controls to protect the asset (warehouse) from this threat (fire), it can sensibly spend $3,750 or less per year to provide the necessary level of protection. Knowing the real possibility of a threat and how much damage, in monetary terms, the threat can cause is important in determining how much should be spent to try and protect against that threat in the first place. It would not make good business sense for the organization to spend more than $3,750 per year to protect itself from this threat. Clearly, this example is overly simplistic in focusing strictly on the structural losses. In the real world, we should include other related impacts such as loss of revenue due to the disruption, potential fines if the fire was caused by a violation of local fire codes, and injuries to employees that would require medical care. The number of factors to consider can be pretty large and, to some of us, not obvious. This is why you want to have a diverse risk assessment team that can think of all the myriad impacts that a simple event might have. Uncertainty In risk analysis, uncertainty refers to the degree to which you lack confidence in an estimate. This is expressed as a percentage, from 0 to 100 percent. If you have a 30 percent confidence level in something, then it could be said you have a 70 percent uncertainty level. Capturing the degree of uncertainty when carrying out a risk analysis is important, because it indicates the level of confidence the team and management should have in the resulting figures.  Chapter 2: Risk Management 75 Single Loss Annualized Rate of Annualized Loss Asset Threat Expectancy (SLE) Occurrence (ARO) Expectancy (ALE) PART I Facility Fire $230,000 0.1 $23,000 Trade secret Stolen $40,000 0.01 $400 File server Failed $11,500 0.1 $1,150 Business data Ransomware $283,000 0.1 $28,300 Customer Stolen $300,000 3.0 $900,000 credit card info Table 2-3 Breaking Down How SLE and ALE Values Are Used Now that we have all these numbers, what do we do with them? Let’s look at the example in Table 2-3, which shows the outcome of a quantitative risk analysis. With this data, the organization can make intelligent decisions on what threats must be addressed first because of the severity of the threat, the likelihood of it happening, and how much could be lost if the threat were realized. The organization now also knows how much money it should spend to protect against each threat. This will result in good business decisions, instead of just buying protection here and there without a clear understanding of the big picture. Because the organization’s risk from a ransomware incident is $28,300, it would be justified in spending up to this amount providing ransomware preventive measures such as offline file backups, phishing awareness training, malware detection and prevention, or insurance. When carrying out a quantitative analysis, some people mistakenly think that the process is purely objective and scientific because data is being presented in numeric values. But a purely quantitative analysis is hard to achieve because there is still some subjectivity when it comes to the data. How do we know that a fire will only take place once every 10 years? How do we know that the damage from a fire will be 25 percent of the value of the asset? We don’t know these values exactly, but instead of just pulling them out of thin air, they should be based upon historical data and industry experience. In quantitative risk analysis, we can do our best to provide all the correct information, and by doing so we will come close to the risk values, but we cannot predict the future and how much future incidents will cost us or the organization. Results of a Quantitative Risk Analysis The risk analysis team should have clearly defined goals. The following is a short list of what generally is expected from the results of a risk analysis: Monetary values assigned to assets Comprehensive list of all significant threats Probability of the occurrence rate of each threat Loss potential the organization can endure per threat in a 12-month time span Recommended controls CISSP All-in-One Exam Guide 76 Although this list looks short, there is usually an incredible amount of detail under each bullet item. This report will be presented to senior management, which will be concerned with possible monetary losses and the necessary costs to mitigate these risks. Although the report should be as detailed as possible, it should also include an executive summary so that senior management can quickly understand the overall findings of the analysis. Qualitative Risk Analysis Another method of risk analysis is qualitative, which does not assign numbers and mon- etary values to components and losses. Instead, qualitative methods walk through differ- ent scenarios of risk possibilities and rank the seriousness of the threats and the validity of the different possible countermeasures based on opinions. (A wide-sweeping analysis can include hundreds of scenarios.) Qualitative analysis techniques include judgment, best practices, intuition, and experience. Examples of qualitative techniques to gather data are Delphi, brainstorming, storyboarding, focus groups, surveys, questionnaires, checklists, one-on-one meetings, and interviews. The risk analysis team will determine the best technique for the threats that need to be assessed, as well as the culture of the organization and individuals involved with the analysis. The team that is performing the risk analysis gathers personnel who have knowledge of the threats being evaluated. When this group is presented with a scenario that describes threats and loss potential, each member responds with their gut feeling and experience on the likelihood of the threat and the extent of damage that may result. This group explores a scenario of each identified vulnerability and how it would be exploited. The “expert” in the group, who is most familiar with this type of threat, should review the scenario to ensure it reflects how an actual threat would be carried out. Safeguards that would diminish the damage of this threat are then evaluated, and the scenario is played out for each safeguard. The exposure possibility and loss possibility can be ranked as high, medium, or low on a scale of 1 to 5 or 1 to 10. A common qualitative risk matrix is shown in Figure 2-4. Once the selected personnel rank the likelihood of a threat happening, the loss potential, and the advantages of each Consequences Likelihood Insignificant Minor Moderate Major Severe Almost certain M H H E E Likely M M H H E Possible L M M H E Unlikely L M M M H Rare L L M M H Figure 2-4 Qualitative risk matrix: likelihood vs. consequences (impact)  Chapter 2: Risk Management 77 The Delphi Technique PART I The Delphi technique is a group decision method used to ensure that each member gives an honest opinion of what he or she thinks the result of a particular threat will be. This avoids a group of individuals feeling pressured to go along with others’ thought processes and enables them to participate in an independent and anony- mous way. Each member of the group provides his or her opinion of a certain threat and turns it in to the team that is performing the analysis. The results are compiled and distributed to the group members, who then write down their comments anon- ymously and return them to the analysis group. The comments are compiled and redistributed for more comments until a consensus is formed. This method is used to obtain an agreement on cost, loss values, and probabilities of occurrence without individuals having to agree verbally. safeguard, this information is compiled into a report and presented to management to help it make better decisions on how best to implement safeguards into the environment. The benefits of this type of analysis are that communication must happen among team members to rank the risks, evaluate the safeguard strengths, and identify weaknesses, and the people who know these subjects the best provide their opinions to management. Let’s look at a simple example of a qualitative risk analysis. The risk analysis team presents a scenario explaining the threat of a hacker accessing confidential information held on the five file servers within the organization. The risk analysis team then distributes the scenario in a written format to a team of five people (the IT manager, database administrator, application programmer, system operator, and operational manager), who are also given a sheet to rank the threat’s severity, loss potential, and each safeguard’s effectiveness, with a rating of 1 to 5, 1 being the least severe, effective, or probable. Table 2-4 shows the results. Threat = Hacker Effectiveness Accessing Probability Potential of Intrusion Confidential Severity of Threat Loss to the Effectiveness Detection Effectiveness Information of Threat Taking Place Organization of Firewall System of Honeypot IT manager 4 2 4 4 3 2 Database 4 4 4 3 4 1 administrator Application 2 3 3 4 2 1 programmer System 3 4 3 4 2 1 operator Operational 5 4 4 4 4 2 manager Results 3.6 3.4 3.6 3.8 3 1.4 Table 2-4 Example of a Qualitative Analysis CISSP All-in-One Exam Guide 78 This data is compiled and inserted into a report and presented to management. When management is presented with this information, it will see that its staff (or a chosen set) feels that purchasing a firewall will protect the organization from this threat more than purchasing an intrusion detection system (IDS) or setting up a honeypot system. This is the result of looking at only one threat, and management will view the severity, probability, and loss potential of each threat so it knows which threats cause the greatest risk and should be addressed first. Quantitative vs. Qualitative Each method has its advantages and disadvantages, some of which are outlined in Table 2-5 for purposes of comparison. The risk analysis team, management, risk analysis tools, and culture of the organization will dictate which approach—quantitative or qualitative—should be used. The goal of either method is to estimate an organization’s real risk and to rank the severity of the threats so the correct countermeasures can be put into place within a practical budget. Table 2-5 refers to some of the positive aspects of the quantitative and qualitative approaches. However, not everything is always easy. In deciding to use either a quantitative or qualitative approach, the following points might need to be considered. Quantitative Cons: Calculations can be complex. Can management understand how these values were derived? Without automated tools, this process is extremely laborious. More preliminary work is needed to gather detailed information about the environment. Standards are not available. Each vendor has its own way of interpreting the processes and their results. Attribute Quantitative Qualitative Requires no calculations X Requires more complex calculations X Involves high degree of guesswork X Provides general areas and indications of risk X Is easier to automate and evaluate X Used in risk management performance tracking X Allows for cost/benefit analysis X Uses independently verifiable and objective metrics X Provides the opinions of the individuals who know the X processes best Shows clear-cut losses that can be accrued within one X year’s time Table 2-5 Quantitative vs. Qualitative Characteristics  Chapter 2: Risk Management 79 Qualitative Cons: The assessments and results are subjective and opinion based. PART I Eliminates the opportunity to create a dollar value for cost/benefit discussions. Developing a security budget from the results is difficult because monetary values are not used. Standards are not available. Each vendor has its own way of interpreting the processes and their results. NOTE Since a purely quantitative assessment is close to impossible and a purely qualitative process does not provide enough statistical data for financial decisions, these two risk analysis approaches can be used in a hybrid approach. Quantitative evaluation can be used for tangible assets (monetary values), and a qualitative assessment can be used for intangible assets (priority values). Responding to Risks Once an organization knows the amount of total and residual risk it is faced with, it must decide how to handle it. Risk can be dealt with in four basic ways: transfer it, avoid it, reduce it, or accept it. Many types of insurance are available to organizations to protect their assets. If an organization decides the total risk is too high to gamble with, it can purchase insurance, which would transfer the risk to the insurance company. If an organization decides to terminate the activity that is introducing the risk, this is known as risk avoidance. For example, if a company allows employees to use instant messaging (IM), there are many risks surrounding this technology. The company could decide not to allow any IM activity by employees because there is not a strong enough business need for its continued use. Discontinuing this service is an example of risk avoidance. Another approach is risk mitigation, where the risk is reduced to a level considered acceptable enough to continue conducting business. The implementation of firewalls, training, and intrusion/detection protection systems or other control types represent types of risk mitigation efforts. The last approach is to accept the risk, which means the organization understands the level of risk it is faced with, as well as the potential cost of damage, and decides to just live with it and not implement the countermeasure. Many organizations will accept risk when the cost/benefit ratio indicates that the cost of the countermeasure outweighs the potential loss value. A crucial issue with risk acceptance is understanding why this is the best approach for a specific situation. Unfortunately, today many people in organizations are accepting risk and not understanding fully what they are accepting. This usually has to do with the relative newness of risk management in the security field and the lack of education and experience in those personnel who make risk decisions. When business managers are charged with the responsibility of dealing with risk in their department, most of the time CISSP All-in-One Exam Guide 80 they will accept whatever risk is put in front of them because their real goals pertain to getting a project finished and out the door. They don’t want to be bogged down by this silly and irritating security stuff. Risk acceptance should be based on several factors. For example, is the potential loss lower than the countermeasure? Can the organization deal with the “pain” that will come with accepting this risk? This second consideration is not purely a cost decision, but may entail noncost issues surrounding the decision. For example, if we accept this risk, we must add three more steps in our production process. Does that make sense for us? Or if we accept this risk, more security incidents may arise from it, and are we prepared to handle those? The individual or group accepting risk must also understand the potential visibility of this decision. Let’s say a company has determined that it is not legally required to protect customers’ first names, but that it does have to protect other items like Social Security numbers, account numbers, and so on. So, the company ensures that its current activities are in compliance with the regulations and laws, but what if its customers find out that it is not protecting their full names and they associate this with identity fraud because of their lack of education on the matter? The company may not be able to handle this potential reputation hit, even if it is doing all it is supposed to be doing. Perceptions of a company’s customer base are not always rooted in fact, but the possibility that customers will move their business to another company is a potential fact your company must comprehend. Figure 2-5 shows how a risk management program can be set up, which ties together many of the concepts covered thus far in this chapter. PLAN COLLECT INFORMATION DEFINE 1. Identify team 1. Identify assets RECOMMENDATIONS 2. Identify scope 2. Assign value to assets 1. Risk mitigation 3. Identify method 3. Identify vulnerabilities and threats 2. Risk transference 4. Identify tools 4. Calculate risks 3. Risk acceptance 5. Understand acceptable 5. Cost/benefit analysis 4. Risk avoidance risk level 6. Uncertainty analysis MANAGEMENT RISK MITIGATION RISK AVOIDANCE Control selection Discontinue activity Implementation Monitoring RISK TRANSFERENCE RISK ACCEPTANCE Purchase insurance Do nothing Figure 2-5 How a risk management program can be set up  Chapter 2: Risk Management 81 Total Risk vs. Residual Risk PART I The reason an organization implements countermeasures is to reduce its overall risk to an acceptable level. As stated earlier, no system or environment is 100 percent secure, which means there is always some risk left over to deal with. This is called residual risk. Residual risk is different from total risk, which is the risk an organization faces if it chooses not to implement any type of safeguard. An organization may choose to take on total risk if the cost/benefit analysis results indicate this is the best course of action. For example, if there is a small likelihood that an organization’s web servers can be compromised and the necessary safeguards to provide a higher level of protection cost more than the potential loss in the first place, the organization will choose not to implement the safeguard, choosing to deal with the total risk. There is an important difference between total risk and residual risk and which type of risk an organization is willing to accept. The following are conceptual formulas: threats × vulnerability × asset value = total risk (threats × vulnerability × asset value) × controls gap = residual risk You may also see these concepts illustrated as the following: total risk – countermeasures = residual risk NOTE The previous formulas are not constructs you can actually plug numbers into. They are instead used to illustrate the relation of the different items that make up risk in a conceptual manner. This means no multiplication or mathematical functions actually take place. It is a means of understanding what items are involved when defining either total or residual risk. During a risk assessment, the threats and vulnerabilities are identified. The possibility of a vulnerability being exploited is multiplied by the value of the assets being assessed, which results in the total risk. Once the controls gap (protection the control cannot provide) is factored in, the result is the residual risk. Implementing countermeasures is a way of mitigating risks. Because no organization can remove all threats, there will always be some residual risk. The question is what level of risk the organization is willing to accept. Countermeasure Selection and Implementation Countermeasures are the means by which we reduce specific risks to acceptable levels. This section addresses identifying and choosing the right countermeasures for computer systems. It gives the best attributes to look for and the different cost scenarios to investi- gate when comparing different types of countermeasures. The end product of the analy- sis of choices should demonstrate why the selected control is the most advantageous to the organization. CISSP All-in-One Exam Guide 82 NOTE The terms control, countermeasure, safeguard, security mechanism, and protection mechanism are synonymous in the context of information systems security. We use them interchangeably. Control Selection A security control must make good business sense, meaning it is cost-effective (its benefit outweighs its cost). This requires another type of analysis: a cost/benefit analysis. A com- monly used cost/benefit calculation for a given safeguard (control) is (ALE before implementing safeguard) – (ALE after implementing safeguard) – (annual cost of safeguard) = value of safeguard to the organization For example, if the ALE of the threat of a hacker bringing down a web server is $12,000 prior to implementing the suggested safeguard, and the ALE is $3,000 after implementing the safeguard, while the annual cost of maintenance and operation of the safeguard is $650, then the value of this safeguard to the organization is $8,350 each year. Recall that the ALE has two factors, the single loss expectancy and the annual rate of occurrence, so safeguards can decrease either or both. The countermeasure referenced in the previous example could aim to reduce the costs associated with restoring the web server, or make it less likely that it is brought down, or both. All too often, we focus our attention on making the threat less likely, while, in some cases, it might be less expensive to make it easier to recover. The cost of a countermeasure is more than just the amount filled out on the purchase order. The following items should be considered and evaluated when deriving the full cost of a countermeasure: Product costs Design/planning costs Implementation costs Environment modifications (both physical and logical) Compatibility with other countermeasures Maintenance requirements Testing requirements Repair, replacement, or update costs Operating and support costs Effects on productivity Subscription costs Extra staff-hours for monitoring and responding to alerts  Chapter 2: Risk Management 83 Many organizations have gone through the pain of purchasing new security products without understanding that they will need the staff to maintain those products. Although PART I tools automate tasks, many organizations were not even carrying out these tasks before, so they do not save on staff-hours, but many times require more hours. For example, Company A decides that to protect many of its resources, purchasing an intrusion detection system is warranted. So, the company pays $5,500 for an IDS. Is that the total cost? Nope. This software should be tested in an environment that is segmented from the production environment to uncover any unexpected activity. After this testing is complete and the security group feels it is safe to insert the IDS into its production environment, the security group must install the monitoring management software, install the sensors, and properly direct the communication paths from the sensors to the management console. The security group may also need to reconfigure the routers to redirect traffic flow, and it definitely needs to ensure that users cannot access the IDS management console. Finally, the security group should c