One of the early themes in this book so far has been risk management, but we haven’t quite gotten into risk management mitigations, strategies, and controls—until now. Information security has become an exercise in risk management. Using the tools and techniques of risk management has improved organizations’ ability to secure the information assets they use in business operations. Securing information assets leads to a detailed examination of security models, of which the CIA triad (confidentiality, integrity, and availability) has proven to be a simple and effective way of describing basic security needs. This chapter takes a look at a variety of risk mitigation strategies and controls given the requirements stemming from business objectives, management, standards, and even worse-case scenarios.

Categorize Data Types by Impact Levels Based on CIA

The three most commonly used objectives for information security are confidentiality, integrity, and availability—commonly referred to as the CIA triad. These three attributes define different protection requirements for information in the enterprise. Although some similar tools and techniques may be used to achieve these objectives, each must be ensured separately. Besides simply determining the CIA attributes, it is also necessary to define the level of protection. There are many ways to define the level; the most common is a triad of high, moderate, and low.

Federal Information Processing Standard (FIPS) 199 offers definitions for the security impacts of confidentiality, integrity, and availability as well as examples of high, moderate, and low impacts. The definitions for CIA come from the Federal Information Security Management Act (FISMA) directly.

Confidentiality

The FISMA definition for confidentiality is as follows: “Preserving authorized restrictions on access and disclosure, including means for protecting personal privacy and proprietary information…” [44 U.S.C., Sec. 3542].

A failure to ensure confidentiality can result in the unauthorized disclosure of information. This means that information should only be accessible to authorized users. In one respect, this is an easy aspect: simply restrict the data using access control lists. In practical terms, it becomes more complex. Printed reports can disclose information. Aggregate elements such as averages, which may be releasable, can fail when aggregate quantities can be reversed. A report that has sales data by region, products, and other categories can be rearranged, potentially resulting in de-aggregated values and thus in data disclosure.

Confidentiality is typically provided by the following controls:

•   Cryptography

•   Steganography

•   Access control/permissions

•   Authentication

•   Physical security

Integrity

The FISMA definition for integrity is as follows: “Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity…” [44 U.S.C., Sec. 3542].

An integrity violation is the unauthorized modification or destruction of information. This means that only authorized users are allowed to modify data, including writing, changing, deleting, and creating it. The creation of data where none was previously can result in integrity errors. Modification can occur even without confidentiality failures, because deletion can occur without revealing the specific data elements.

Integrity is typically provided by the following controls:

•   Cryptographic hashes

•   Digital signatures

•   File integrity monitoring

•   Log analysis

•   Code testing

•   Separation of duties

•   Rotation of duties

•   End-user training

Availability

The FISMA definition for availability is as follows: “Ensuring timely and reliable access to and use of information…” [44 U.S.C., Sec. 3542].

A failure of availability is the disruption of access to or use of information or an information system with respect to an authorized user. Here are the most common examples of availability failures:

•   Denial of service (DOS) attacks

•   Power failures

•   Equipment failures

•   Data corruption

•   Human error

•   Software/OS crash

•   Natural disasters

In retrospect, here are the most common availability controls to mitigate or prevent the failures:

•   Fault tolerance (redundant hard drives, power supplies, servers, clusters, ISPs, and even data centers)

•   Data center location/design (A/C, UPS, fire suppression, raised floor)

•   Patch management

•   Antimalware

•   Preventative maintenance

•   Backup/restoration procedures

•   Disaster recovery plan (DRP)

•   Business continuity plan (BCP)

CIA Tradeoffs

The role of the three CIA attributes in securing information in the enterprise depends on the security requirements. Passwords have a high need for confidentiality, pricing data has a high need for integrity, and database servers have a high need for availability. In an e-commerce system, there are numerous elements of data to consider. The pricing data has no confidentiality requirement since it needs to be shared, yet the validity of the data is paramount, thus making integrity the primary concern. For a given order, the credit card information requires confidentiality, both during the transaction and afterward. In a distributed server environment, the determination of user rights may depend on credentials stored and maintained in a separate system, making availability an issue. In this last case, the use of redundant directory services servers—such as Active Directory domain controllers—could provide availability of authentication and authorization services should one domain controller fail.

In the e-commerce pricing example, confidentiality is not needed, integrity is high, and availability is high. In the password example, the confidentiality is high, but the other two attributes raise interesting questions. If availability is compromised, the use is delayed. This raises the question, what is the cost of failure? Failure of confidentiality potentially has a lasting effect because credentials may be lost to an unauthorized party. Failure of integrity and/or availability may result in something as simple as another attempt or may be more serious in the event of an automated batch-type system. The bottom line is that all aspects need to be examined, including from the point of view of what the cost of failure is.

Determine the Aggregate Score of CIA

To use the three elements of CIA along with the impact factors (high, moderate, and low) requires some method of expressing these values. FIPS 199 defines the term “security category” (SC) to express the security attributes. These values assist in determining the appropriate set of security controls needed to provide the desired elements of protection with respect to the three security attributes. Security categories can be calculated for information types and information systems.

The first step of establishing the aggregate score of CIA is the determination of the potential impact of each type of risk. These impacts are typically categorized as high, moderate, and low. These values and their explanations are expressed in Table 3-1, which shows the potential impact definitions for the security objectives from FIPS 199.

Table 3-1    FIPS 199 Potential Impact Definitions for Security Objectives

In order for the information presented in this table to be useful, the terms limited, serious, and severe impact or consequence need to be defined for the organization. If one is looking at financial measures, organization size and resources can make a large difference in how things are scored. For a small organization, a loss of $10,000 may be catastrophic, whereas for a large multinational organization, the same value would be considered insignificant. The definitions of the financial and personnel issues associated with these levels are presented in Table 3-2.

Table 3-2    Enterprise-Specific Definitions for Security Objectives

Nomenclature

FIPS 199 provides a nomenclature to define security categories in the form of a list of paired values:

SC_{information type} = {(confidentiality, impact), (integrity, impact), (availability, impact)}

For public information that is placed on a web server, with no risk impact from confidentiality, and medium impact for integrity and availability, the form is as follows:

SC_{public data} = {(confidentiality, NA), (integrity, moderate), (availability, moderate)}

The scoring of an information system is more complicated because it requires all information types associated with the system to be scored, and the high-water mark of all the individual elements to be determined.

Another name for the form SC_{information type} = {(confidentiality, impact), (integrity, impact), (availability, impact)} is the calculated aggregate CIA score. In one simple expression, the requirements for protection with respect to all three elements of CIA can be expressed for an information dataset or information system.

Incorporate Stakeholder Input into CIA Impact-Level Decisions

Policies are developed in response to a perceived need of guidance due to some driving force. This driving force can be in the form of requirements from either an internal or external source. Requirements may stem from senior management in an effort to communicate corporate goals and objectives. Policies don’t “just happen.” There is a source of the policies, and it should primarily stem from organizational stakeholders.

Policies can be drafted in a top-down fashion, where senior management provides guidance on a specific topic. For many policies, such as the security policy, this is important because buy-in by senior management is essential. For other policies, such as a remote access policy, the source may be the security department because the required level of technical knowledge will not be readily available from senior executives. The challenge for policies drafted from the bottom up is to get senior management buy-in. When the wording of a policy is presented in a form that makes sense in business terms, is clearly aligned with the organization’s overall goals and objectives, and can be seen to specifically support these goals and objectives, the policy is a better candidate for senior executive buy-in.

The primary objective of policies is to communicate the goals and objectives with respect to some particular aspect of the business. There can be many policies in an organization, and security is no different from any other business function—if there are issues that need to be communicated, policies are a useful tool.

Determine Minimum-Required Security Controls Based on Aggregate Score

Operational security is achieved through the implementation of security controls in the enterprise. The set of required controls depends on the aggregate score of security requirements as defined by the security category. Different security controls provide different types of coverage with respect to confidentiality, integrity, and availability. As each piece of data that flows through, or get stored on, a system is analyzed with respect to its security requirements, a set of minimum-security controls can be determined that will provide the required level of security. The security categorization (SC) of an information system defines the minimum-security requirements.

Select and Implement Controls Based on CIA Requirements and Organizational Policies

Security controls are the primary toolset for security practitioners to apply in the effort to meet security requirements. The challenge for security professionals is to employ the correct set of security controls to provide the level of protection required. Because there are numerous individual data elements in a system with differing security categories, this rapidly can be seen as a stubborn problem. To the rescue comes the SC value for the system as a whole. Using this set of values reduces the security control selection process to a very manageable level. This fits with the direction of NIST SP 800-53, “Recommended Security Controls for Federal Information Systems and Organizations,” which provides guidance on the application of security controls in the enterprise. This structured methodology reduces the complexity of layering controls in the enterprise.

Extreme Scenario Planning/Worst-Case Scenario

A critical perspective to have with information security is the anticipation that what can go wrong will go wrong. Although extreme scenarios are unlikely, organizations must still plan for extreme or worst-case scenarios before they occur. Some examples of worst-case scenarios include the following:

•   Trade secret breach

•   DDOS attack

•   Private encryption key breach

•   Financial data breach

•   Natural disasters

•   Terrorism

Central to any discussion about worst-case scenario planning is an understanding of the various internal and external threat actors. Although natural disasters can occur, the most likely threat source will be human related. Threat actors are individuals or groups that are responsible for actions—whether intentional or accidental—that lead to losses for other individuals or organizations. Here’s a list of internal and external threat actors:

•   Internal threat actors   Individuals and groups inside the organization

•   Disgruntled personnel

•   Government or corporate spy

•   Internal spy

•   Partner

•   Reckless or uncaring personnel

•   Thief

•   Untrained personnel

•   Vendor

•   Script kiddie

•   External threat actors   Individuals and groups outside the organization

•   Activist

•   Competitor

•   Government/political

•   Data miner

•   Hacker

•   Nation-state attacker

•   Terrorist

•   Vandal

Not all internal and external threat actors are created equal. Some have bad intentions (hostile) and deliberately cause harm, whereas others don’t have bad intentions (non-hostile) yet accidentally cause harm.

According to NIST, threat actors are evaluated according to criteria based on skill level, resources, limits, visibility, objective, and outcome. Here’s a breakdown:

•   Skill level   Threat actor’s capabilities

•   None

•   Minimal

•   Operational

•   Adept

•   Resources   Threat actor’s scope

•   Individual

•   Team

•   Large team

•   Organization

•   Nation-state/government

•   Limits   Threat actor’s rules of engagement

•   Code of conduct

•   Legal

•   Extra-legal (Minor)

•   Extra-legal (Major)

•   Visibility   Threat actor’s visibility risk appetite

•   Overt

•   Covert

•   Clandestine

•   Doesn’t care

•   Objective   Threat actor’s short-term goal

•   Copy

•   Destroy

•   Injure

•   Take

•   Doesn’t care

•   Outcome   Threat actor’s long-term goal

•   Acquisition/theft

•   Business advantage

•   Damage

•   Embarrassment

•   Technical advantage

Organizations can address the worst-case scenarios that can arise from these threats by conducting an analysis of all threats—particularly for the preceding threat actors. After determining all possible threat criteria for internal and external threat actors, organizations will then need to determine, from the most to least important, the assets that need protection. They will then craft a variety of scenarios regarding threats exploiting those assets. Then they must create models for each scenario to cross-examine the threats, exploits, vulnerabilities, and assets for a fuller understanding. Finally, they will determine which security controls will be implemented to mitigate the threats. Details on which security controls to implement based on the most to least important risks are described throughout this chapter.

Conduct System-Specific Risk Analysis

Information systems are composed of applications and data. To examine the risk associated with a system, one must examine the information flows and respective security requirements for each. These can be expressed as security categories or in other forms that allow appropriate determination of mitigation strategies. Risk analysis can be performed in one of two manners: qualitative or quantitative. In most cases, risk management and analysis activities include elements from both quantitative and qualitative models. Either of these models can be used to determine the appropriate security measures to prioritize actions and meet the desired security requirements.

Risk analysis provides upper management with the details necessary to determine how threats should be addressed. This information assists in the determination of the risks that should be avoided, mitigated, transferred, or accepted. The risk analysis process recognizes risks, quantifies the impact of threats, and supports budgeting for security. The following are the stages in the risk analysis process:

•   Inventory

•   Threat assessment

•   Evaluation

•   Management

•   Monitoring

The inventory phase involves the inventorying of the threats, whereas the threat assessment phase involves examining the impact of each threat. The evaluation phase is where controls are chosen and evaluated, and the management and monitoring phases relate to the operational steps for implementing specific risk management actions.

Qualitative Risk Analysis

Qualitative risk analysis uses expert judgment and experience to assess the elements of occurrence and impact. To assess risk qualitatively, you compare the impact of the threat with the probability of occurrence and then assign an impact level and probability level to the risk. As previously examined, it is common to use levels such as high, moderate, and low when assigning values to probability and impact factors. Figure 3-1 illustrates the combinations of the three levels, with the shading of the box indicating the final risk level. Heavy shading indicates high risk, slight shading moderate risk, and no shading low 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 (dark shaded box in Figure 3-1). Assigning the levels of high, moderate, and low can be tricky in some cases, but in reality, a few threats can usually be identified as presenting high-risk exposure and a few threats as presenting low-risk exposure. The threats that fall somewhere in between are probably moderate in level.

Figure 3-1    Qualitative risk assessment

The primary purpose of a risk assessment is to make a determination of the prioritization of responses to threats. Because resources are limited with respect to the opportunities to apply security controls, prioritization based on risk reduction ensures the best result for a given level of expenditure.

Quantitative Risk Analysis

Quantitative risk assessment uses calculations based on historical data associated with risk. This method is used in industries such as insurance, where large quantities of data occur and provide a solid basis for trending. A common method of quantitative assessment is the calculation of the annualized loss expectancy (ALE).

As for most certification exams, know the definitions and formulas:

•   SLE = asset value * exposure factor

•   ALE = SLE * ARO

•   SLE: Single loss expectancy

•   ARO: Annualized rate of occurrence

•   ALE: Annualized loss expectancy

Calculating the ALE creates a monetary value of the impact. Begin by calculating the single loss expectancy (SLE) with the following formula:

SLE = asset value * exposure factor

The asset value is the dollar value of the asset being placed at risk. The exposure factor is the percentage of the asset that would be lost by the risk. The value of SLE equates to the monetary loss expected from a risk occurring. To calculate the ALE, multiply the SLE by the likelihood that the risk will materialize during a year, which is referred to as the annualized rate of occurrence (ARO):

ALE = SLE * ARO

A second method that is frequently used is to assign point values to high, moderate, and low and then multiply them together to determine a final risk value.

Calculate the Risk

Let’s take a look at an example. A company has a single, centralized web-based order-entry system. Orders are fulfilled from a series of five regional warehouses. What is the expected loss if there is a 1 percent chance of a hacker bringing the order-entry system down, requiring a server restore? The mean time to restore the server is six hours. Orders come in an average of 12 hours a day, bringing in $500,000 a day in average revenue across a 364-day sales calendar. It is expected that the attacks occur daily.

The asset value = $500,000

The exposure factor is 0.5 (6 hours/12 hours)

SLE = $500,000 * 0.5 = $250,000

ARO = 0.01 * 364 = 3.64 times

ALE = SLE * ARO = $250,000 * 3.64 = $910,000

Another form of quantitative analysis is when numeric values are assigned to the levels of the qualitative analysis. Using numeric values opens up a variety of potential analysis options. Rather than just two factors, a third factor is sometimes included. The three-factor model for risk, with its roots in failure mode effects analysis (FMEA), uses the factors’ severity, occurrence, and detection to score risk.

•   Severity   Scores the potential effect of the threat

•   Occurrence   Rates the likelihood that a threat will manifest as a loss

•   Detection   Captures the likelihood that the threat will be detected and mitigated prior to resulting in a loss

These three values can then be multiplied together to create a risk priority number (RPN).

Two types of scales are commonly used: one is 1–5, and the other is 1–10. On both scales, the higher number represents more likely or severe. The 1–5 scale makes it easier to agree on values, whereas the 1–10 scale provides for wider variation in RPN scores. Tables 3-3 through 3-5 are sample scoring tables for severity, occurrence, and detection. Keep in mind that these should be modified to meet your organization’s specific requirements.

Table 3-3    Sample Severity Rating Scale

Table 3-4    Sample Occurrence Rating Scale

Table 3-5    Sample Detection Rating Scale

One of the distinct advantages of this quantitative method is its ability to distribute values across a range. Using a five-point scale, the range of RPN values is from 1 to 125. For the 10-point scale, it is 1 to 1000. Of further value is the fact that distribution is not linear, but is skewed, with the vast majority of combinations occurring in the lower scores. On the 1–1000 distribution for the three 10-point scales, over 85 percent of the combinations yield an RPN of less than 360. This tends to allow issues with high values to stand out.

Make Risk Determination Based on Known Metrics

Risk management is an essential element of business management in today’s competitive environment. Security management can be viewed as a form of risk management. One definition of risk is the possibility and effect of suffering a loss. Two components are associated with measuring loss: the possibility of an event occurring and the impact of the event. The primary purpose behind making a risk determination is to provide management with the information needed to make decisions on which threats to address and with what level of resources. If you consider the risk calculations described earlier regarding SLE, ARO, ALE, severity, occurrence, and detection scales, organizations will be in a prime position to not only make accurate risk determinations, but also to be able to organize said risks into a priority order for mitigation.

Magnitude of Impact Based on ALE and SLE

The magnitude of impact is a measure of how much damage a particular threat would cause if it manifested itself. A threat can have an impact of zero, meaning it has no effect on the system, or it can have a catastrophic effect. And a wide range of values can occur between the two extremes. The challenge of risk management analysis is the determination of the magnitude of impact, as described in the previous section. Impacts are typically scored as high, moderate, and low. High-level impacts result in significant loss, whereas low-level impacts represent negligible losses. Moderate losses fall between these two levels.

Likelihood of Threat

The likelihood of a threat is a measure of the chance that the threat will actually impact a system. The distribution of values for likelihood can vary based on the causal nature of the threat. In the case of environmental issues such as disasters, storms, and so on, the distribution of likelihoods is random with no memory function. Hence, the chance of a flood or hurricane may vary by location, but is not based on previous events. This concept fits well with insurance models, where distributions are typically normal and based on a wide range of factors. Other threats, such as hackers, follow a different distribution. Once it becomes known that a firm is vulnerable in a specific manner or fashion, repeat attacks become more common, thus forcing a memory aspect to the distribution function. This can introduce a significant fat-tail aspect to the distribution, skewing the likelihood to higher levels once the first incident is successful.

Motivation

To better understand the likelihood of threats, we must also ascertain their motivation. Malicious hackers, being human, have one or more motivations for conducting their nefarious acts. These things don’t happen in a vacuum; therefore, you should consider the following motivations:

•   Financial gain through information theft

•   Espionage (competitor/enemy states)

•   Ego or fun (challenge)

•   Ideology (religious/political)

•   Grudge (former employee/customer/partner)

Knowledge of a threat’s motivation is important for developing a fuller understanding of the threat. The more information we have about a threat, the better decisions we can make on implementing the appropriate security controls to resolve the threat.

Source

As discussed earlier in the chapter, threat sources originate from internal and external threat actors who may be either hostile or non-hostile in nature. Such individuals may be intelligent and intentionally attack the organization, or uninformed and don’t realize they’re causing real or potential damage to the organization. Attackers might be relatively inept script kiddies taking advantage of an easy opportunity, or they could be adept hackers targeting the organization for a deeper reason. Competitors may hire hackers to look into company trade secrets, products, and plans. Some organizations may be the unfortunate target of a local or foreign intelligence agency or an organized cybercrime terrorist group.

Although less likely, threat sources may include natural disasters such as tornados, hurricanes, earthquakes, volcanos, floods, tsunamis, blizzards, and wildfires. An organization’s region, proximity to a threat source, emergency procedures, awareness training, and facility structure as well as the time of year will play key roles in exposures caused by natural disasters.

ARO

As discussed earlier, the annualized rate of occurrence (ARO) is a prediction of how often a threat instance will materialize in one year. For another example, suppose an asset’s value (AV) is valued at $75,000 and the exposure factor (EF) for the asset is 20 percent. If you multiply the AV by EF, you get a single loss expectancy (SLE) of $15,000. Put differently, AV * EF = SLE.

Now, if we can reasonably predict that the asset will be exploited/exposed once a year, we’ll say the ARO is 1. Take the ARO of 1 and multiply it by the SLE, and the asset’s annualized loss expectancy (ALE) is expected to be $15,000. Put differently, ARO * SLE = ALE. If the ARO is changed to 2 in this scenario, then the ALE for the asset will be $30,000.

Trend Analysis

Trend analysis is an important way to help reduce risk for an organization. We’ll cover trend analysis in greater detail in Chapter 17, but for now just know that it involves performing ongoing research on emerging industry trends to determine the potential and impact of threats that organizations may face. For example, a new trend involves hackers utilizing artificial intelligence and machine learning to augment their data collection and subsequent attacks. Other hackers are employing more evasive malware that escapes VMs and attacks the physical host, hypervisor, or even network resources. According to Symantec, here are the predicted trends in cybersecurity for 2018:

•   Blockchain will find uses outside of cryptocurrencies.

•   Cybercriminals will use Artificial Intelligence and Machine Learning to conduct attacks.

•   Supply chain attacks will become mainstream.

•   File-less and file-light malware will increase.

•   Organizations will have difficulty securing software as a service (SaaS) tools.

•   More breaches will occur due to design, error, and compromise.

•   Trojans will still generate more financial losses than ransomware.

•   Home Internet of Things (IoT) devices will be held ransom, hacked, and used against us, and will provide access to home networks.

Others are predicting trends in increasingly intelligent bots, hivenets, and swarmbots. Cybercriminals are expected to make better use of automated attacks via the dark web. Cyberwarfare between nations is expected to go from the “underground” to the “mainstream,” which we’re already seeing with recent attacks on political networks.

Return on Investment (ROI)

Let’s face it: security solutions can be expensive. Getting broken into and having customers’ credit cards/medical records/personal information stolen is expensive, too, but the mere threat of this happening is often not enough to justify the cost to prevent it from happening. C-level staff increasingly ask, “How likely is this to happen?” and “What’s the cost if we get hit once? Twice?” Security may be a cost of doing business, but increasingly the question that needs to be answered is, at how much cost?

To help address those questions, CSOs are turning toward methods C-level staff and most MBA graduates understand—ROI and TCO. Return on investment (ROI) is essentially the efficiency of an investment. The “return” or benefit of the investment (minus the cost) is divided by the cost of the investment (see Figure 3-2). This formula works fairly well for manufacturing processes because any increase in productivity will likely generate a positive ROI—but what about security spending? How does one see a “return” from purchasing a new firewall? Or deploying an IPS? It is a bit trickier to show an ROI with security solutions, but it can be done. The obvious case is where spending helps reduce headcount or manpower costs—a new log consolidation tool allows one person to do the work of two people. In other cases, we will need to look at risk analysis calculations for soft numbers that can be used in ROI calculations. Let’s use a simple example: let’s say the risk of a break-in is 100 percent with no security and the cost of said break-in would be $500,000. Let’s say a firewall costing $50,000 would reduce that risk by 80 percent (theoretically providing $400,000 of risk mitigation). So, for $50,000, we could achieve $400,000 of risk mitigation. In theory, we’re “saving” $350,000 by purchasing the firewall. That’s an extremely simplistic example, but you get the idea. Take a few minutes to google “security ROI” and you’ll see entire papers written on calculating ROI for security products.

Figure 3-2    Simple ROI formula

Total Cost of Ownership (TCO)

So, what about total cost of ownership (TCO)? Much like owning a car, purchasing a security product isn’t a one-time expense. Cars have fuel, insurance, and maintenance costs; security products usually have maintenance agreements, require someone to operate and manage them, upgrades, and so on. Calculating the TCO of a security product involves factoring in all the expected costs over the life cycle of that product. Some are simple to calculate, such as purchase price and maintenance contracts; yet the hardest to calculate is often the largest number that factors into TCO—personnel. A security tool doesn’t run completely on its own—in almost every case, there’s a human sitting at a keyboard interacting with the security tool. The challenge is trying to estimate how many people will be needed to operate and maintain that tool. How many hours will it take? How much does that type of person get paid? What types of training classes will they need?

Translate Technical Risks in Business Terms

Chapter 19 will deep-dive into the topic of technical risks; therefore, this section provides a more cursory level of coverage.

One of the reasons why organizations sometimes hire relatively nontechnical people to chief information officer (CIO) and chief security officer (CSO) roles is due to their unique ability to “bridge the gap” between their subordinates and executives. Although extensive technical/security knowledge is often a requirement for these roles, the one unmistakable quality in all cases is the role of “translator.” The CIO and CSO not only oversee their respective departments, but they must also effectively communicate the technical and security desires of their teams into the business language spoken by decision-makers. In some cases, you’ll report various risks, threats, and budgeting requests directly to the CSO; you might actually be the CSO—or you might work for an organization that does not have a CSO at all. In the latter case, you’ll need to be the translator of technical risks to various departments and users.

As you can imagine, being a company-wide translator can be quite challenging due to the variation in employee roles, tenure, experience, intelligence, and business vocabulary of the individuals you’ll interact with. When talking about technical and security risks, you must first understand your audience. Are they a technical, nontechnical, or semi-technical employee? Are they an end user, manager, executive, board member, regulatory representative, or auditor? Here are some general guidelines for communicating technical information:

•   Don’t say too much   Communicate just enough information to make your point. Overselling dilutes the message and can create confusion.

•   Focus on their world   Communicate what matters to them first before what matters to you. People are drawn to those that seemingly care more about others than themselves.

•   Humility   Rather than coming across as the smart technical person talking to a nontechnical person, find a way to reverse the roles. Perhaps volunteer your own ignorance about the end-user’s individual’s knowledge, skills, and abilities so that they can teach you a few things. This puts both sides on the same plane.

•   Visuals   Charts and graphs certainly have their place, but what works especially well is more visually stimulating visual content such as infographics showing graphics, percentages, and predictions.

In the final chapter of this book, we’ll get into proper communication and interaction techniques with stakeholders from all levels of the organization, including the end user all the way up to the executive and legal levels.

Recommend Which Strategy Should Be Applied Based on Risk Appetite

All organizations have a certain risk appetite or risk level that they’re willing to accept when it comes to the protections required to fulfill their security requirements. This will drive the level of urgency or lack thereof regarding investment into security controls.

Security controls are the primary toolset for security practitioners to apply in the effort to meet security requirements. The challenge for security professionals is to design the correct set of security controls to employ to provide the level of protection required. Because there are numerous individual data elements in a system with differing security categories, this rapidly can be seen as an inflexible problem. To the rescue comes the SC value for the system as a whole. Using this set of values reduces the security control selection process to a very manageable level.

Avoid

Risk avoidance is a mechanism where the enterprise avoids a particular threat. It can do this through actions that avoid exposure, such as removing a feature that increases exposure. Risk avoidance seems like a simple method to remove exposure, but this method cannot be employed against all threats. All business activity involves a level of risk, and avoiding all risk means avoiding all rewards as well. Avoidance is a powerful tool for threats that have significant impacts. For instance, the positioning of backup data centers in a separate location, and one sheltered from items such as hurricanes and other threats to the primary location, avoids the risk of a storm taking out both primary and backup systems.

Transfer

Risk transference can be most easily explained with a single word: insurance. Analyzing risk transference in detail illustrates that the threat is not transferred, nor is the impact, but rather some form of post-event compensation is employed to cover the impact. If a firm outsources its security management to a managed security provider, the risk still falls to the original firm, and it becomes a contractual issue with respect to settling how the loss will be covered.

Mitigate

Risk mitigation is the most common form of risk management. The use of security controls to reduce the impact of an attack is a form of mitigation. An intrusion detection system acts like a burglar alarm, limiting the time an adversary has to create loss. The use of logs to determine a security issue also works to limit the exposure. Firewalls and access control mechanisms both act to limit the breadth of exposure to a threat. The concept of defense in depth acts to reduce exposure.

Accept

After all the risks have been addressed and reduced, there is still a level of risk remaining known as residual risk. This risk is handled by acceptance. If a firm does not completely address any specific risk, it must accept the consequence and the loss. This mechanism is used all the time for extremely rare events and items with small exposures.

Risk Management Processes

Chapter 1 discussed the high-level recurring risk management process of identification, assessment, analyzation, and mitigation of risks. Taking a more detailed approach here, we’ll reiterate an important risk management framework that stems from NIST SP 800-39, “Managing Information Security Risk.” For more information on each of the stages in this framework, refer to the FIPS or special publications provided within the parentheses of each stage:

•   Categorize   the information systems and data (FIPS 199 and SP 800-60).

•   Select   security controls (FIPS 200 and SP 800-53).

•   Implement   security controls (SP 800-34, SP 800-61, and SP 800-128).

•   Assess   the effectiveness of the security controls (SP 800-53A).

•   Authorize   the information system and data (SP 800-37).

•   Monitor   the security controls (SP 800-37, SP 800-53A, and SP 800-137).

Exemptions

Although risk management processes should account for all opportunities of risk, some products or systems may require exemptions from them. These exemptions can exist for many reasons, such as the age, attrition, or lack of functionality from legacy products. In other cases, state or federal regulations might stipulate an exemption.

As per the ISO/IEC 27001 standard, exemptions are authorized noncompliances with mandatory requirements. For example, if a hospital mandates a 10-character minimum password for all healthcare systems, yet a specialty computer has an overriding requirement to use a smaller eight-character password due to software constraints, this is an example of an exemption. On the other hand, if another computer is not authorized to have an eight-character password at this same hospital, this is an example of an exception. Exceptions are different because they are unauthorized noncompliances with mandatory requirements.

Understand that although exemptions may be required, it opens up the organization to some risk in itself. Be sure to consider any and all repercussions of exemptions to risk management processes, and consider how you might be able to trim out some of that risk without violating the exemption requirements.

Deterrence

There will be some risks that cannot be outright mitigated, and in some cases too expensive to be practical. While deterrence does not prevent, detect, or mitigate risk, it can still reduce risk through more indirect mechanisms.

Deterrence is the process of discouraging threat actors from performing unauthorized actions through warnings or through the threat of consequences. This could be as simple as a sign that says, “Private property. No trespassing. Violators will be prosecuted.”

In most company computers, users are confronted at sign-in with a login banner that provides one or more paragraphs of warnings, including the following:

•   Who are considered appropriate users of the system

•   What is considered appropriate usage of the system

•   That the system is being monitored for inappropriate usage

•   That privacy should not be expected while using company systems

•   That disciplinary action, criminal charges, or sanctions can be implemented if inappropriate usage is discovered

Inherent

Inherent risk is the risk that an incident will pose if no security controls are put into place. It is because of inherent risk that we have to implement security controls in the first place. Early on in the risk assessment process, we will discover how much inherent risk exists for any potential adverse event. Equipped with that information, we can respond with the appropriate security controls to reduce the risk.

Residual

Residual risk is the risk that remains after all security controls and countermeasures have been implemented. This is to be expected because no matter what you do, you cannot eliminate all risk. The important thing is that the residual risk is low enough to be acceptable to the organization.

Continuous Improvement/Monitoring

Continuous monitoring in any system takes place after initial system security implementation. It involves tracking changes to the information system that occur during its lifetime and then determining the impact of those changes on the system security controls. Continuous monitoring reduces the latency between system changes and security changes to a minimal period. This requires greater intervention on the part of security professionals, but is built around the idea of a bunch of small changes rather than major implementations described by the certification and accreditation process. The true goal of continuous monitoring is the maintenance of an ongoing understanding of the exact security posture of the organization.

Continuous monitoring requires a significant level of automation to facilitate the level of monitoring and decision-making required to keep abreast of the myriad changes a system faces in use. As the threat environment changes, this can lead to security changes. As the system is adapted through minor changes or interconnected to other systems, system-level interactions can result in security changes.

To manually subject a system to complete reviews through a certification and accreditation process is neither feasible nor desirable. The business requirement is to maintain levels of risk commensurate with the reward associated with the system, and this business decision requires analysis of how a system stands as it is being operated, not just at static intervals. The continuous monitoring process involves the following three activities:

1.   Configuration management and control

a.   Documentation of information system changes

b.   Security impact analysis

2.   Security control monitoring and impact analysis of changes to the information system

a.   Security control selection

b.   Selected security control assessment

3.   Status reporting and documentation

a.   System security plan update

b.   Plan of action and milestones update

c.   Status reporting

The objective of these tasks is to observe and evaluate the information system security controls during the system life cycle. These tasks determine whether the changes that have occurred in the information system will negatively impact the system security.

Business Continuity Planning

Also known as continuity of operations planning (COOP) in the U.S., business continuity planning is a collection of processes that permit an organization to preserve or quickly recover its business functions in the event of a serious business disruption. Not to be mixed up with disaster recovery planning since it focuses on technology recovery, business continuity planning encompasses the functionality of the overall organization and is therefore more significant. Disruptions to business continuity have many causes, including internal and external threat sources such as natural disasters, environmental failures, and man-made (intentional and accidental) threats.

Central to business continuity planning is the development of the business continuity plan (BCP). The business continuity plan is a policy that documents all possible disasters and solutions ahead of time to quickly return the business to normal functionality within a promised timeline. Building a comprehensive list of disasters involving everything from technological failures, supply chain failures, natural disasters, and human causes requires soliciting feedback from various department stakeholders. A BCP document can be constructed in many ways, which might contain some of the following components:

•   Decision-making authority (also known as the business continuity team)   This is a team of individuals and may include the COO, CIO, VPs, directors, and other IT, security, and facilities stakeholders. Such individuals share responsibility in maintaining, communicating, and executing the provisions of the BCP.

•   Emergency response plan   Indicates the immediate communication plan should an adverse event take place. In other words, the COO (or other senior member) will determine if present circumstances call for invoking the provisions of the BCP, which includes notifying a few other key players. If the COO isn’t available, the CIO might take over.

•   Operations center locations   This component stipulates the need for the business to relocate to another site should the main site no longer be available for business operations.

•   Communications   Indicates the presiding communication policy during disaster events, which includes provisions for if or when communications with certain outsiders (such as the media, law enforcement, and so on) are warranted.

•   Service and system recovery   Indicates the most-to-least critical business functions and processes to be restored and the required timelines. The most critical functions might require restoration in one hour, whereas addition business functions might come with, say, 24-hour, two-day, or one-week requirements.

•   Plan maintenance   Contains the requirement and frequency for reviewing the BCP, which might be quarterly, biannually, or annually.

BCPs will often incorporate important metrics to help guide and set expectations for recovery operations. Knowledge of these metrics will help keep recovery efforts focused and on schedule. Shown here are the most important BCP metrics:

•   Recovery time objective (RTO)   Preferred period of time it should take for normal business operations to be restored after a disaster.

•   Recovery point objective (RPO)   Maximum period of time that an organization can tolerate a data loss.

•   Mean time to repair (MTTR)   Measure of how long it takes before something can be restored to normal functionality.

•   Mean time between failures (MTBF)   Measure of how long a device is expected to operate before failure. Take a look at Figure 3-3 to see how MTBF can be calculated.

•   Maximum tolerable downtime (MTD)   Maximum time a business function can remain unavailable before it causes total and irrecoverable business failure.

Figure 3-3    Formula for calculating MTBF

IT Governance

IT governance is the implementation of processes where executive management actively ensures that IT is being used in the most effective and efficient manner by those responsible for it. This is not to say that upper management is taking responsibility away from IT management but rather they are carefully overseeing the overall effectiveness of IT and whether it is bringing value to the organization through the fulfillment of business objectives. Ultimately, IT governance seeks to bring strong alignment of IT with business objectives to ensure value is consistently brought to the organization. Better cohesion of IT and company objectives will not only provide better top-down oversight, but also provide a clear path for IT personnel to implement IT solutions that work toward the organization’s objectives.

Another thing to consider is that IT governance also helps reduce organizational risk. By using a common risk management framework, IT and upper management can work synergistically toward mutually beneficial goals. More on that in the next section.

Adherence to Risk Management Frameworks

IT governance sounds great, but what’s a good way for an organization to formalize it and get the most out of it? As indicated in the previous section, risk management frameworks are the answer. Control Objectives for Information and Related Technology 5 (COBIT 5) is a well-known framework for IT management and governance created by the ISACA. COBIT 5 delivers on five principles:

•   Meeting stakeholder needs

•   Covering the enterprise end-to-end

•   Applying a single integrated framework

•   Enabling a holistic approach

•   Separating governance from management

The ISO/IEC 38500 standard was created for corporate governance of IT. It empowers upper management to provide assurances that IT is fulfilling all legal, regulatory, and ethical obligations while remaining aligned with organizational objectives. ISO/IEC 38500 has six principles:

•   Responsibility

•   Strategy

•   Acquisition

•   Performance

•   Conformance

•   Human behavior

Another framework (and quite a popular one at that) is the Information Technology Infrastructure Library (ITIL) framework. ITIL provides best practices for the alignment of IT services with organizational objectives. At the time of this writing, the latest version of ITIL is the 2011 version. There are five “volumes” of ITIL publications, as listed here:

•   Service Strategy   Focuses on organizational objectives and customer needs

•   Service Design   Converts service strategy into business objective deliverables

•   Service Transition   Creates and improves capabilities for new services

•   Service Operation   Manages services in environments

•   Continual Service   Improves upon services incrementally and on a larger scale

Enterprise Resilience

Enterprise resilience consists of an organization’s ability to adapt to short-term and long-term changes. Like an organism’s immune system, enterprise resilience must be able to fight off current threats while also strengthening itself for future ones. This should not be mistaken with disaster recovery or business continuity because enterprise resilience focuses more on general risks and disruptions as opposed to large-scale disasters.

Since enterprise resilience is focused on change adaptation, risk management is incorporated into the overall strategy of improving an enterprise’s resilience. For an enterprise to be resilient, it must be able to withstand changes and adversity from top to bottom—from the technological all the way through operational levels. Consider the following resiliency tactics:

•   Resiliency within servers, including disk arrays, redundant power supplies, and NICs.

•   Resiliency across servers, including server clusters/farms, NAS/SAN, and UPSs.

•   Resiliency of LAN/WAN networks and connections, including redundant ISP links.

•   Resiliency of data centers, including redundant data centers through remote sites, outsourcing through cloud computing provider, and generators.

•   Resiliency of stakeholders through leadership contingency plans. Who is in charge when someone is unavailable?

•   Resiliency of the organization during economic downturns as well as changes to laws and regulations.

•   Resiliency of the organization to changes in the industry, with competition, vendors, and customer demands.

Chapter Review

This chapter covered the execution of risk mitigation strategies and controls given various scenarios. We started off with categorizing data types by impact levels based on CIA. We also introduced the three pillars of security—confidentiality, integrity, and availability—in addition to their various tradeoffs.

The next section talked about determining the aggregate score of CIA, which involves scoring the impact of risks through low, moderate, and high severities.

We then went into a section on incorporating stakeholder input into CIA impact-level decisions. The primary output resulting from the input from stakeholders will be security policies.

The next section branched off of the security categories section by discussing the determination of minimum-required security controls based on aggregate score.

We then covered the selection and implementation of controls based on CIA requirements and organizational policies. This section briefly touched on avoiding, transferring, mitigating, and accepting the risk.

Extreme scenario planning/worst-case scenarios were the topics of the next section. We went into all the bad things that could theoretically happen as a result of human and non-human threats.

Conducting system-specific risk analysis was the topic of the next section, which highlighted inventory, threat assessment, evaluation, management, and monitoring. We then went into qualitative risk analysis, which uses designations such as low, moderate, and high to measure risk. The next topic was quantitative risk analysis, which typically uses monetary values and formulas to assign meaning to risk.

Making risk determinations based on known metrics was the topic of the next section. It talked about interpreting the outcome of quantitative and qualitative risk analysis in order to arrange various risks into a priority order. This included determining the magnitude of impact based on ALE and SLE, in addition to developing a deeper understanding of threat likelihood, motivations, sources, and analyzing any applicable trends regarding those threats. The end of the section talked about determining return on investment in addition to calculating the total cost of ownership for risk controls to counter the various threats.

The next section briefly discussed translating technical risks into business terms by catering your security messages according to the target audience.

We moved into another new section on recommending which strategy should be applied based on risk appetite. Here, we went into more detail on strategies for avoiding, transferring, mitigating, and accepting risk.

We then went into a new section on risk management processes, which reintroduced several risk management frameworks along with NIST special publications. We touched on exemptions to risk management processes, in addition to risk deterrence, inherent risk, and the residual risk left over after security controls are implemented.

We had a brief section on continuous improvement and monitoring practices, which highlighted the importance of automation of various elements for optimization.

Business continuity planning had its own section, which covered the benefits, components, and strategies of BCPs. This section also included coverage of BCP topics such as RTO, RPO, MTTR, MTBF, and MDT.

The next section of the chapter discussed IT governance and the role that upper management plays in ensuring that IT solutions are meeting company objectives in a way that adheres to risk management frameworks.

The final section of the chapter discussed enterprise resilience as well as various tactics to ensure an organization is able to maintain business operations regardless of short-term and long-term changes.

Quick Tips

The following tips should serve as a brief review of the topics covered in more detail throughout the chapter.

Categorize Data Types by Impact Levels Based on CIA

•   The three most commonly used objectives for information security are confidentiality, integrity, and availability—commonly referred to as the CIA triad.

•   The FISMA definition for confidentiality is “preserving authorized restrictions on access and disclosure, including means for protecting personal privacy and proprietary information.”

•   The FISMA definition for integrity is “guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.”

•   The FISMA definition for availability is “ensuring timely and reliable access to and use of information.”

Determine the Aggregate Score of CIA

•   The first step of establishing the aggregate score of CIA is to determine the potential impact of each type of risk.

•   Impacts are typically categorized as high, moderate, and low.

Incorporate Stakeholder Input into CIA Impact-Level Decisions

•   Security policies are developed in response to a perceived need of guidance due to some driving force, typically in the form of upper management.

•   Policies can be drafted in a top-down fashion, where senior management provides guidance on a specific topic.

•   When the wording of a policy is presented in a form that makes sense in business terms, is clearly aligned with the organization’s overall goals and objectives, and can be seen to specifically support these goals and objectives, the policy is a better candidate for senior executive buy-in.

•   The primary objective of policies is to communicate the goals and objectives with respect to some particular aspect of the business.

Determine Minimum-Required Security Controls Based on Aggregate Score

•   The set of required controls depends on the aggregate score of security requirements as defined by the security category.

•   Different security controls provide different types of coverage with respect to confidentiality, integrity, and availability.

•   The security categorization (SC) of an information system defines the minimum security requirements.

Select and Implement Controls Based on CIA Requirements and Organizational Policies

•   Security controls are the primary toolset for security practitioners to apply in an effort to meet security requirements.

•   The challenge for security professionals is to employ the correct set of security controls to provide the level of protection required.

•   Security controls reduce the risk associated with a threat to the enterprise in one of four ways: enterprises can avoid the impact, transfer the impact to another party, mitigate the effect of the threat, or accept the risk.

Extreme Scenario Planning/Worst-Case Scenario

•   Although extreme scenarios are unlikely, organizations must still plan for extreme or worst-case scenarios before they occur.

•   Central to any discussion about worst-case scenario planning is an understanding of the various internal and external threat actors.

•   Although natural disasters can occur, the most likely threat source will be human related.

•   Threat actors are individuals or groups that are responsible for actions—whether intentional or accidental—that lead to losses for other individuals or organizations.

Conduct System-Specific Risk Analysis

•   To examine the risk associated with a system, one must examine the information flows and respective security requirements for each system.

•   Risk analysis can be performed in one of two manners: qualitative or quantitative.

•   In most cases, risk management and analysis activities include elements from both quantitative and qualitative models.

•   Qualitative risk analysis uses expert judgment and experience to assess the elements of occurrence and impact.

•   To assess risk qualitatively, you compare the impact of the threat with the probability of occurrence and then assign an impact level and probability level to the risk.

•   Quantitative risk assessment uses calculations based on historical data associated with risk.

Make Risk Determination Based on Known Metrics

•   The primary purpose behind making a risk determination is to provide management with the information needed to make decisions on which threats to address and with what level of resources.

•   The magnitude of impact is a measure of how much damage a particular threat would cause if it manifested itself.

•   The challenge of risk management analysis is the determination of the magnitude of impact.

•   The likelihood of a threat is a measure of the chance that a threat will actually impact a system.

•   Knowledge of a threat’s motivation is important for developing a fuller understanding of the threat.

•   Threat sources originate from internal and external threat actors who may be either hostile or non-hostile in nature.

•   Threat sources may include natural disasters such as tornados, hurricanes, earthquakes, volcanos, floods, tsunamis, blizzards, and wildfires.

•   An organization’s region, proximity to threat source, emergency procedures, awareness training, and facility structure, as well as the time of year, will play key roles in exposures caused by natural disasters.

•   Trend analysis involves performing ongoing research on emerging industry trends to determine the potential and impact of threats that organizations may face.

•   Return on investment (ROI) is essentially the efficiency of an investment.

•   Calculating the TCO of a security product involves factoring in all the expected costs over the life cycle of that product.

•   The TCO may be simple to calculate (for example, purchase price and maintenance contracts), yet the hardest item to calculate is often the largest number that factors into TCO—personnel.

Translate Technical Risks in Business Terms

•   Security professionals must effectively communicate the technical and security desires of their teams into the business language spoken by decision-makers.

•   Being a company-wide translator can be quite challenging due to the variation in employee roles, tenure, experience, intelligence, and business vocabulary of the individuals you’ll interact with.

Recommend Which Strategy Should Be Applied Based on Risk Appetite

•   All organizations have a certain risk appetite or risk level that they’re willing to accept when it comes to the protections required to fulfill a company’s security requirements.

•   Risk avoidance is a mechanism where the enterprise avoids a particular threat.

•   Risk transference involves transferring the risk to a third party such as an insurance company.

•   Risk mitigation is the use of security controls to reduce the impact of an attack.

•   Risk acceptance involves accepting the risk because it would not be cost-effective to further reduce the risk.

Risk Management Processes

•   Risk management is the high-level and recurring process of identification, assessment, analyzation, and mitigation of risks.

•   Although risk management processes should account for all opportunities of risk, some products or systems may require exemptions from them.

•   Exemptions can exist for many reasons, such as the age, attrition, lack of functionality from legacy products, and requirements from regulations.

•   Deterrence is the process of discouraging threat actors from performing unauthorized actions through warnings or the threat of consequences.

•   Inherent risk is the risk that an incident will pose if no security controls are put into place.

•   Residual risk is the risk that remains after all security controls and countermeasures have been implemented.

Continuous Improvement/Monitoring

•   Continuous monitoring involves tracking changes to the information system that occur during its lifetime and then determining the impact of those changes on the system security controls.

•   Continuous monitoring requires a significant level of automation to facilitate the level of monitoring and decision-making required to keep abreast of the myriad changes a system faces in use.

•   Once changes occur that reduce the organization’s security posture, new or modified security controls will be implemented to “improve” the security posture. Continuous monitoring solutions are instituted in order to continuously improve security.

Business Continuity Planning

•   Business continuity planning is a collection of processes that permit an organization to preserve or quickly recover its business functions in the event of a serious business disruption.

•   Disruptions to business continuity have many causes, including internal and external threat sources such as natural disasters, environmental failures, and man-made (intentional and accidental) threats.

•   The business continuity plan is a policy that documents all possible disasters and solutions ahead of time to quickly return the business to normal functionality within a promised timeline.

•   BCPs will often incorporate important metrics to help guide and set expectations for recovery operations.

IT Governance

•   IT governance is the implementation of processes where executive management actively ensures that IT is being used in the most effective and efficient manner by those responsible for it.

•   IT governance seeks to bring strong alignment of IT with business objectives to ensure value is consistently brought to the organization.

•   Control Objectives for Information and Related Technology 5 (COBIT 5) is a well-known framework for IT management and governance that was created by the ISACA.

•   The ISO/IEC 38500 standard was created for corporate governance of IT.

•   ITIL provides best practices for the alignment of IT services with organizational objectives.

Enterprise Resilience

•   Enterprise resilience consists of an organization’s ability to adapt to short-term and long-term changes.

•   Enterprise resilience must be able to fight off current threats while also strengthening itself for future ones.

•   For an enterprise to be resilient, it must be able to withstand changes and adversity from top to bottom—from the technological all the way through operational levels.

Questions

The following questions will help you measure your understanding of the material presented in this chapter. Read all the choices carefully because there might be more than one correct answer. Choose all correct answers for each question.

1.   There are multiple options for dealing with risk. Which of the following are appropriate risk management options? (Choose all that apply.)

A.   Evaluation

B.   Transfer

C.   Deferral

D.   Mitigation

2.   Which of the following are the stages in the risk analysis process? (Choose all that apply.)

A.   Asset control

B.   Threat assessment

C.   Monitoring

D.   Budgeting

3.   What is the following formula used for?

SC_{information type} = {(confidentiality, impact), (integrity, impact), (availability, impact)}

A.   To calculate qualitative risk

B.   To calculate aggregate CIA score

C.   To calculate the system risk consequence

D.   To calculate SLE

4.   Which of the following federal regulations requires federal agencies to be able to monitor activity in a “meaningful and actionable way”?

A.   HIPAA

B.   Gramm-Leach-Bliley

C.   FISMA

D.   Sarbanes-Oxley

5.   Which of the following refers to the act of maintaining an ongoing awareness of information security effectiveness?

A.   Security policy

B.   Incident response

C.   Threat assessment

D.   Continuous monitoring

6.   As the system administrator, you are tasked with assessing the various risks to your network. Which of the following is not a category associated with risk assessment?

A.   Risk determination

B.   Likelihood determination

C.   Cost determination

D.   Risk analysis

7.   Which level of impact is characterized by a significant level of loss to an enterprise?

A.   Catastrophic

B.   High

C.   Moderate

D.   Accepted risk

8.   Which of the following levels of likelihood is defined by a threat source that’s highly motivated and sufficiently capable, and the security controls used to prevent the vulnerability from being exercised are ineffective.

A.   Accepted

B.   Medium

C.   Normal

D.   High

9.   You have been contracted to secure the confidential informants’ database for the local police department. What would be an appropriate SC attribute formula?

A.   SC_CIs = {(confidentiality, high), (integrity, high), (availability, high)}

B.   SC_CIs = {(confidentiality, moderate), (integrity, moderate), (availability, moderate)}

C.   SC_CIs = {(confidentiality, high), (integrity, high), (availability, moderate)}

D.   SC_CIs = {(confidentiality, moderate), (integrity, low), (availability, high)}

10.   As part of your job, you are to keep the system protected from new threats. What is an important step you would take to ensure this occurs?

A.   Apply new controls for the threat.

B.   Implement end-user awareness training.

C.   Apply all current patches in a timely manner.

D.   Perform a risk assessment.

11.   Which of the following refers to the element of security associated with the unauthorized deletion of data?

A.   Integrity

B.   Confidentiality

C.   Data retention policy

D.   Privacy policy

12.   Minimum security control determination requires which step to be completed?

A.   Pen testing

B.   Compute aggregate CIA score

C.   Fuzz testing

D.   Vulnerability assessment

13.   What factors should be part of determining an overall likelihood rating for a particular issue? (Choose all that apply.)

A.   Threat-source motivation

B.   Threat-source capability

C.   Asset value

D.   ALE

14.   Which of the following elements of security states that only authorized users are able to modify or delete data?

A.   Integrity

B.   Availability

C.   Confidentiality

D.   Authorization

15.   A hacker gains unauthorized access to your system and deletes data. This is an example of what type of failure?

A.   Confidentiality

B.   Availability

C.   Authorization

D.   Integrity

16.   Which of the following processes can be involved in continuous monitoring? (Choose all that apply.)

A.   Network flow analysis

B.   Configuration management and control

C.   Security control monitoring

D.   Security budget

17.   An asset under attack has a potential loss amount of $135,000, and it is expected that successful attacks could occur every 18 months. What is the ALE?

A.   $135,000

B.   $100,000

C.   $90,000

D.   $45,000

18.   A firm is unaware of an attack and the resulting losses caused. Which risk management technique is employed with respect to this threat?

A.   Acceptance.

B.   Risk transfer.

C.   Risk deferral.

D.   There isn’t sufficient information to answer this question.

19.   MTTR stands for:

A.   Mean time to reboot

B.   Mean time to reimage

C.   Mean time to repair

D.   Mean time to reinitialize

20.   Total cost of ownership (TCO) should include:

A.   Cost of hardware

B.   Cost of maintenance contracts

C.   Cost of personnel

D.   All of the above

Answers

1.   B, D. The four options for risk treatment are avoid, mitigate, transfer, and accept.

2.   B, C. The steps of the risk analysis process are inventory, threat assessment, evaluation, management, and monitoring.

3.   B. SC_{information system} = {(confidentiality, impact), (integrity, impact), (availability, impact)} is an expression of the calculation of an aggregate CIA score for the information system.

4.   C. The Federal Information Systems Management Act (FISMA) requires federal agencies to monitor security-related activities.

5.   D. Maintaining an ongoing awareness of one’s security posture is a key element in defining continuous monitoring.

6.   C. Cost determination is a management step that is needed but is not part of the risk assessment.

7.   B. The typical three levels are high, moderate, and low. The fact that the loss is assessed as “significant” makes the value high.

8.   D. Again, the typical levels are high, moderate, and low. The fact that the threat source is assessed as “highly motivated” and the controls are assessed as “ineffective” makes the value high.

9.   C. Confidential informants’ information is extremely sensitive. Simple disclosure or alteration of the records could result in injury or death.

10.   D. A risk assessment is the best process for determining new threats and required countermeasures.

11.   A. This is the definition of integrity.

12.   B. The minimum security controls must address the complete security requirements by level, which is present in the aggregate CIA scores.

13.   A, B. Threat-source motivation and capability are driving factors as to whether an attack is likely, and both impact the likelihood component.

14.   A. Unauthorized alteration or deletion of data is an integrity violation.

15.   D. The unauthorized deletion of data is an integrity failure.

16.   B, C. Configuration management and control as well as security control monitoring directly affect system security status and are part of a continuous monitoring solution.

17.   C. The SLE = $135,000, the ARO = 12/18 = .666, and the ALE = 135,000 * 0.666 = $90,000

18.   A. By default, the risk is accepted because this action occurs without any management action.

19.   C. MTTR is the abbreviation for “mean time to repair” (how quickly the system can be brought back online).

20.   D. When calculating total cost of ownership, you should always include all the expenses associated with an item, including the cost of hardware, the cost of any maintenance agreements, and the cost of the personnel to run/maintain the system.