CompTIA CySA+ Cybersecurity Analyst Certification: Compliance and Assessment - Organizational Risk Mitigation

Objective 5.2  Given a scenario, apply security concepts in support of organizational risk mitigation

Organizational Risk Mitigation
This far in your career, you’ve probably already encountered the terms risk, risk management, risk mitigation, and other risk-related concepts.

Risk management is one of the core principles of security. You can’t make everything completely secure without turning all the network hosts off, unplugging them, and putting them in storage.

Security is a balance between protection, functionality, and resources. While you can never completely remove risk, if you’ve ever heard anyone say that you can’t have too much security, they’re wrong. You can have too much security to the extent that you can’t afford it, that the amount of resources you spend on it exceeds the value of the asset, or that the system becomes so limited in functionality that you can’t use it. The trick is finding the balance.

Resources limit exactly how much time, money, labor, and effort you can put into securing systems and data. You also have to balance the value of the asset, such as information or systems, with what you are spending on protection for those assets.

Functionality is typically inversely proportional to the amount of security you apply to a system: the more you secure it, the less functional it usually becomes.

You don’t want to apply so much protection to a system that it can’t be used because that would negate the whole reason for having it in the first place. You will have to trade off on all three of those items to get the right balance of each. Essentially, this is what risk management is all about.
In this module, we’re going to discuss trying to achieve the right amount of security, functionality, and resource management using risk management principles and mitigating risk whenever possible.

We’re going to discuss critical concepts such as business impact analysis, risk identification and calculation, risk factors, risk prioritization, assessing risk, training and exercises, and supply chain risk management. Understand that you’re not going to become an expert on risk management or mitigation from this module, but we’re going to cover the objectives and critical concepts that you need to understand for the exam.

Business Impact Analysis (BIA)
Organizations should ask themselves a few fundamental questions before embarking on any type of risk management process:
- What assets do we have?
- Why are they important to us?
- What business processes do they support?
- What would we do if we lost those assets or the business processes they support?
- What would be our priority for restoring assets and processes in the event of a disaster?

If an organization does not have the answers to these questions, then it can’t figure out what assets it needs to protect and how much protection to give those assets. The organization won’t be able to allocate the resources necessary for that protection.
That’s where a business impact analysis (BIA) comes in. A BIA should be the beginning of all of your risk management activities. So much in risk management, and even security implementation, depends on knowing what you have, why it’s important to you, and how much you should protect it.

A BIA is a process whereby the organization inventories all of its assets and business processes, to determine which of those business processes are critical to continuing its mission and reaching its goals. It also determines how its assets support those business processes. Based on how important those business processes and, by extension, assets, are, it determines the criticality of those assets (in other words, how important they are to keeping the business going).

Let’s define assets: an asset is anything of value to the organization. This could be tangible items, such as servers, workstations, network devices, data, software applications, equipment, facilities, time, and even people. To a large degree, you could assign a monetary value to each of these assets. You can determine how much these items cost initially, how much they would cost to replace, and how much business, in terms of revenue or profit, you would lose if you lost those assets. There are also intangible items that are of value to the organization.

These are hard to place a monetary value on, but they still impact the overall business financial posture. Examples of intangible assets include reputation and consumer confidence. Losing either of these intangible assets would also create a significant tangible business impact.

Assets are important, and our concern with cybersecurity risk management is to protect those assets. But keep in mind that assets support something even more important: business processes.

Business processes are the activities and functions we perform to fulfill our business mission and goals. Ultimately, business processes are the most important aspect of a business. The assets we protect simply support those processes. Business processes can be critical to an organization being productive, competitive in the market, and surviving.

As part of our BIA, we need to identify assets and business processes and determine their criticality to the overall mission of the business. That is the central purpose of performing a BIA. We’re going to discuss the critical activities of conducting a BIA in the upcoming sections.

Business Process Identification and Prioritization
Some business processes are critical to the survival of the organization. Depending on what type of business we are engaged in, these might include manufacturing, production, service management, and knowledge management, and so on. Each of these processes can be broken down or decomposed into many different subprocesses.

Some of these processes may be critical to the overall business activity, and some less so. There are also support processes that can be critical to the business, including financial accounting, human resources management, research, marketing, and so on. Again, each of these business processes can be decomposed into smaller level processes, activities, and tasks.

The organization should break down its business processes into as much detail as possible, based on the function they perform and how they contribute to the overall business mission—whether that mission is manufacturing products or providing services.

The organization should list these processes and describe them in terms of activity and criticality to the overall mission. Some business processes may be so vital to the business that to lose them even for a day would be devastating. Other business processes may be routine or noncritical, such that losing them for a week might be inconvenient but would not seriously degrade the ability of the business to operate. The organization should determine all of these business processes in as much detail as possible. It should also categorize these processes according to criticality or priority. In the event of a disaster, such as a tornado or terrorist attack, which business processes might the organization lose? Which ones could it restore, and what would the restoration priority be to get the business back into operation again? These questions relate very much to business continuity and disaster recovery plans. Without a BIA, developing any kind of business continuity plan or disaster recovery plan would be impossible.

A BIA is critical to those two plans, as well as the overall risk management strategy and operations of the organization.

Asset Identification
Asset identification is also an important step in conducting a BIA. You should inventory all assets, both tangible and intangible in the organization, again to as much detail as possible. Aside from the inventory, you should also map those assets to business processes.

In conducting your inventory and mapping it to business processes, you should answer the following questions:
- Which business processes are supported by which assets?
- Are multiple processes supported by a particular asset?
- How critical is that asset to that process?

Asset identification is not only about counting servers or hosts. You should be determining and documenting details such as original cost, replacement costs, operating costs, how much revenue that asset generates beyond its cost to maintain, how much of it you could lose and still support the business process, and so on. You’ll find that the value of an asset is frequently much more than its original or replacement costs. A critical server that cost $5000 but directly supports a business process that generates $10,000 in revenue per month is much more valuable than what it would cost to replace if it failed or were destroyed in a disaster.

Criticality Determination
Determining the criticality of both assets and business processes is where the BIA becomes valuable. Separately, knowing your business processes and what assets you have is important, but determining how critical both are to the business is the focus of a BIA. Once you determine how critical they are, you can determine your priorities for spending money and other resources on them for protection. Critical assets such as servers and sensitive data require more protection than other assets deemed lower in importance. This is the beginning of how you determine what you’re going to spend on security. You want to spend the right amount of money on security to protect your assets, such that your expenditures don’t exceed the costs of what the assets are worth to the business.
Another important result of a BIA is that you determine which assets and business processes have priority for restoration during a disaster or other incident. Both business continuity and disaster recovery plans are directly informed by the results of a BIA.
Risk management also benefits from a BIA, in that you now know what your critical assets are, so you can focus on determining what the risks are to those assets. You can focus your efforts on determining threats, vulnerabilities, impact to the business in the event a threat is realized, and what the likelihood of that threat materializing is. This information will also help you determine how much protection an asset needs versus the resources you can afford to put toward that protection. Again, that is what risk management is all about.

Exam tip: You should understand the fundamentals of a business impact analysis and how it relates to risk management, business continuity, and disaster recovery. You should also understand the basic steps in performing a BIA.

Risk Identification Process
Risk relates to the potential level of harm an asset could incur if something detrimental happened to it. That level of harm could be minor, or it could be major and destroy the asset or at least render the asset completely unusable. The level of harm to an asset is called the impact. Risk assessment and analysis activities are directly concerned with determining what that level of impact to an asset is, based on variables that affect the level of impact.
Just as identifying business processes and their supporting assets is critical to a business impact analysis, identifying risks is the critical first step in managing them. Several components of risk must be examined. Individually, they are not a risk, but they are part of it. Aggregated together, they present an amount of risk to an asset that you can determine to a degree. Once that risk is identified, you can determine the best way to mitigate or manage it.
Several factors feed into impact. You have to understand the factors that are attempting to harm the asset, such as a threat, and what weaknesses are in an asset that could cause it to come to harm, called vulnerabilities. We’ll discuss threats, vulnerabilities, and other risk factors in the upcoming sections so we can determine how to identify potential risks.

Threats
Threats are negative events that affect assets or the organization. Threats are initiated by threat actors (sometimes also called threat agents or threat sources). Threats affect assets by exploiting vulnerabilities (weaknesses) in those assets. Threats can be classified as intentional or accidental, natural or man-made, internal or external, and various other classifications. For example, a natural threat event could be a tornado that strikes an organization’s data center. A man-made threat would be a terrorist attack or a hacking attack on an organization’s network. Keep in mind that the terms threat, threat actor, and threat vector are sometimes used interchangeably, but they are not the same thing.

A threat vector is a method that a threat will use to exploit a weakness in an asset or the organization. To give a complete example, a hacker is a threat actor, the threat event is an attack on an organization’s firewall, a threat vector might be sending large volumes of malicious network traffic to the firewall, and a weakness in the firewall that does not account for large volumes of malicious network track is what the threat takes advantage of. These weaknesses are called vulnerabilities and are discussed next.

Vulnerabilities
Vulnerabilities are weaknesses. Typically we look at vulnerabilities as weaknesses in an asset, but they can also be weaknesses in the effectiveness of security controls, or the lack of security controls altogether, weaknesses in a security program, or even weaknesses in organizational management. Vulnerabilities by themselves are not of concern unless there is a threat that can take advantage of or exploit a vulnerability. Threats and vulnerabilities should be paired whenever possible; if there is theoretically no threat that can exploit a vulnerability, then there is also, theoretically, no vulnerability. The same applies to threats; if you determine that a threat exists, but there is not a vulnerability that it can take advantage of, then the threat does not apply to your asset or organization.
Threat and vulnerability pairings are critical in determining the “what” and “how” that can happen to an asset. If you perform a vulnerability assessment on the asset and the organization, you can determine which threats apply to those vulnerabilities and, in turn, determine mitigations for those vulnerabilities, based on those threats.

Risk Calculation
Threats and vulnerabilities are what create the conditions for risk. However, they are not directly the factors that we use to calculate risk. Those are the probability and magnitude of impact. Risk cannot be defined in terms of only threats and vulnerabilities; if those threats never materialize, or if those vulnerabilities aren’t sufficiently weak, and we have no other context, then we can’t determine risk. We can only determine risk by calculating the probability of a negative event, and how serious that event would be if it occurred. We’re going to discuss the two key factors in risk calculation—probability and magnitude of impact—next.

Probability
Although technically not the same thing, the terms probability and likelihood are used interchangeably within the risk community and in the various risk methodologies used to manage cybersecurity risk. We will follow suit here; probability and likelihood are the same.
 

Both terms refer to the chances (expressed numerically or qualitatively) that a threat will exploit a vulnerability, causing a defined impact in an asset or the organization. Note that we are not saying that the likelihood of a threat occurring is a risk, because that probability could be 100 percent, but if the threat exploits a vulnerability and it creates very little impact on the asset, the risk could be negligible. You must frame risk in the context of all four of these elements (threat, vulnerability, likelihood, and impact) to completely define risk. Using only one or two of these factors does not adequately define risk.
Likelihood affects risk in that the higher the likelihood of a negative event (a threat) affecting an asset is, the higher the risk. Conversely, the lower the likelihood of a threat exploiting a vulnerability that affects an asset, the lower the risk. Likelihood can be expressed as a statistical calculation, provided you have the quantitative data to make that calculation, or it can be expressed subjectively or qualitatively, on a scale of very low to very high.

Magnitude of Impact
Impact is considered the level of harm to the asset or the organization should a threat exploit a vulnerability in the asset or organization. In other words, impact could be said to be how bad it would be if the threat happened. Impact can be measured in all sorts of ways. It depends on the context the organization wishes to frame it in. You can measure impact in terms of loss of revenue if a business process were interrupted due to the loss of an asset; you could also describe impact in terms of the cost of replacing or repairing that asset if it were lost or damaged.

Just as likelihood can also be described in qualitative terms, such as very low to very high, impact can be described this way if it is difficult to place a monetary value on the impact. An example of this would be expressing the magnitude of impact to an intangible asset, such as damage to consumer confidence.

The loss of customer confidence in the organization would be a very high impact in most cases. And it would directly affect the company financially, causing measurable impacts to revenue, profit, and so on. Most organizations tend to describe the magnitude of impact in multiple terms and aggregate it in some quantifiable fashion.

Impact is related to risk in that the higher the potential magnitude of impact, the higher the risk. And conversely, the lower the potential magnitude of impact, the lower the risk. Note the word potential in those statements. Once an impact has occurred because something has harmed an asset or the organization, it’s no longer risk. It’s called a fact. Remember that risk is related to the possibility that something bad will happen, so we have to describe risk in terms of potential impact.

Communication of Risk Factors
As mentioned earlier, risk is a product of both likelihood and impact. Threats and vulnerabilities cause the conditions for risk to be present, but the actual measurement of risk is solely based on likelihood and impact. Of course, there are mathematical methods of determining a more precise context of threats, as there are methods of determining how serious a vulnerability is in a system. But we only use likelihood and impact to truly determine risk.

The relationships between threats, vulnerabilities, likelihood, impact, and risk can be expressed as follows:
- Threat actors cause or initiate threat events.
- Threats exploit vulnerabilities in an asset or the organization.
- Risk is a product of likelihood and impact.
- The higher the likelihood or impact, the higher the risk.
- The lower the likelihood or impact, the lower the risk.
- Likelihood and impact together inform risk, but likelihood and impact are generally independent of each other.

Exam tip: Remember that risk is the product of likelihood and impact, based on a threat exploiting a vulnerability in an asset.
In addition to the threat, vulnerability, likelihood, and impact elements of risk, there are other influencing factors, called risk factors, that can affect each of these elements in different ways.

In addition to communicating the different elements of risk, and the risk itself, you should also communicate to different stakeholders the various risk factors that could affect the risk to an asset or the organization. First, a discussion of risk factors is in order. Risk factors influence threats and vulnerabilities, in that they can make it easier for a threat to exploit a vulnerability, or increase the level of weakness of a vulnerability in an asset or organization. Risk factors can be both external to the organization and internal to it.

External Risk Factors
External risk factors could include the economy, market conditions, the political or social climate, and the regulatory environment. Most external risk factors cannot be controlled by the organization. They can only be managed in the context of reacting when those factors affect risks to their assets. Any of these factors could influence risk; for example, the economy could affect the organization’s revenue stream, which could in turn determine how much money is allocated for cybersecurity management. The regulatory environment could change and require the organization to change the way it protects certain sensitive data. The organization cannot control external risk factors; it can only react to them. The key to reducing risk influence by external factors is to react to it in a way that reduces the effect of those risk factors on the organization.

Internal Risk Factors
Internal risk factors are those that are inherent to the organization. These are factors that the organization can control to a certain degree. These factors include budget, organizational factors (such as organizational climate, risk tolerance and appetite, and how the organization is structured), personnel qualification, network architecture and design, and anything else that is within the control of the organization to change or improve should it negatively influence risk.

For example, the organizational budget could control how much money is allocated for security controls. How the organization is structured internally could affect the independence of the cybersecurity department from other departments that would wield influence over how they do their job. Both of these two internal risk factors could negatively impact the cybersecurity program within the organization, but both of these could be easily changed if necessary to reduce risk.

Exam tip: External risk factors cannot be controlled by the organization; only the organization’s response to them can be managed. Internal factors can be adjusted to reduce the negative influence they cause on risk.

Risk Prioritization
Once risks to assets and the entire organization have been determined, they are often aggregated for analysis. Individual risk scenarios, however, must be prioritized for mitigation or remediation.

Remember that there are four basic ways to deal with risk:
- Mitigation or remediation: The organization attempts to reduce risk by the application of controls.
- Avoidance: The organization avoids activities that result in risk.
- Transference: The organization transfers risk to a third party, such as a service provider or insurance provider.
- Acceptance: The organization accepts what it considers to be minimal or residual risk that can no longer be dealt with through any of the other risk response methods.

Prioritizing risks for response is a factor of two things: the cost of the risk response and the criticality of the asset incurring the risk. The cost of responding to the risk involves how much it would cost to improve or implement security controls that would significantly reduce the risk to an acceptable level. This is where we go back to the business impact assessment—remember that it tells us how critical our business processes and the assets that support them are. We should expect to spend money and other resources on security controls that would reduce risk affecting critical processes and assets. The less critical a process or asset is, the fewer resources we might be willing to spend to reduce the risk associated with those processes and assets. It is typically not very cost-effective to spend a great deal on security measures to protect assets that are of low value. This is where we must prioritize risk response measures and ensure that only our most critical processes and assets are getting the bulk of our commitment of resources. For those assets that are not deemed as critical, the organization may elect to spend less on risk reduction measures, or simply accept the risk if it is already at a minimal level. The organization could also elect to outsource or transfer risk by purchasing insurance on its assets, thus reducing the impact if a catastrophic event were to happen to those assets, degrading its ability to operate its business. In any case, prioritizing risk is a function of management that relies heavily on accurate, complete risk assessments as well as a business impact assessment.

Exam tip: Risk prioritization depends on two factors: the cost of risk response and the criticality of the asset or business process it supports.

Security Controls
Security controls are the measures taken to protect an asset and reduce the risk to that asset. Examples of security controls might be strong authentication technologies, the use of encryption, well-formulated policies and procedures, and physical controls such as gates, guards, and CCTVs. Security controls should be implemented to meet a particular risk scenario, such as a concrete threat and vulnerability pairing. While some security controls might span and protect the entire organization, other security controls might be specific to a critical asset or process. Prioritizing resources for security controls involves understanding the value and criticality of those processes and assets.

Core foundations of cybersecurity state that there are essentially three types of controls:

Managerial (sometimes referred to as administrative controls), technical controls (also called logical controls), and physical or operational controls.

Note that there is some disagreement on the categorization and definition of physical and operational controls. Typically, most security foundations state that physical controls are the measures put in place to physically protect an organization and its facilities, equipment, and personnel. These might include gates, guards, fencing, hidden cameras, alarms, barriers, and locked doors. Operational controls are often defined as the actual procedures in place that personnel must abide by to secure organizational assets. However, you will often see these two types of controls intermixed together, so it’s important to look for context when either of these types of controls are described.

The following further describes these three control types:
- Managerial controls: Administrative policies, procedures, plans, and management programs
- Technical controls: Technologies such as NAC, encryption, firewalls, IDS, anti-malware software, and so on
- Physical/operational controls: Fences, alarms, armed guards, gates, CCTVs, access badges, and so on

Exam tip: Although most classical security theories define control types as managerial, technical, and physical, the CompTIA CySA+ objectives state that the three control types are managerial, technical, and operational. You should be familiar with the definitions for all three of those control types.

In addition to the three control types, there are also control functions. These functions define how controls are categorized according to what they do.

The following six different control functions are generally recognized in basic security theory:
- Deterrent: Controls designed to deter individuals from performing malicious acts or violations of policy
- Preventative: Controls designed to prevent malicious acts or violations of policy
- Detective: Controls implemented to detect malicious acts or violations of policy
- Compensating: Controls implemented to temporarily strengthen or supplement faulty or weak controls
- Corrective: Controls implemented to correct a condition resulting in higher risk
- Recovery: Controls used to recover systems, data, and equipment after an incident or disaster

If you are thinking that some security controls might span multiple functions, you are correct. For example, you could consider system backups a recovery control because they could help you recover a system after it has been attacked and compromised. You could also consider system backups a preventative control, so that data is not lost if something catastrophic were to happen to the server. Many controls span different areas, and it depends on the context you’re referring to as to which function the control is fulfilling in a given instance.

Note that the difference between a deterrent and preventative control is that a deterrent control must be known for it to deter personnel from performing a malicious act or violating security policy. A preventative control, on the other hand, does not have to be known to perform the same function. Consider that a CCTV is a deterrent control if a would-be intruder is aware that it is there and decides not to break into a controlled access area because of it. A firewall rule, on the other hand, may not be known by someone who attempts to access a prohibited site, but it will still prevent them from doing so. In the examples given, a CCTV is not a preventative control because the would-be intruder may decide to still break into the controlled access area despite being seen by the camera. The firewall rule is not a deterrent control because the user doesn’t necessarily have to know about it for it to still work.

Engineering Trade-Offs
Risk management is not about absolutes. Managing risk is an effort to reduce the likelihood of a negative event occurring or the impact to the organization if it does happen. Risk can never be eliminated; there will at least always be some small level of risk. Because managing risk is a balancing act between reducing risk and still maintaining security and functionality, while applying the right amount of resources, there will have to be trade-offs.
Trade-offs mean that you must strike a balance between the right amount of security, the right amount of functionality, and the right amount of resources. It also means that to strike that balance, you may have a trade-off in the requirements, design, architecture, or implementation of a system. For example, to maintain functionality with existing systems, you may have to compromise on designing or architecting a system with the very latest technologies during the system engineering process. The same is true for security. If you need to maintain compatibility with legacy systems, you may have to allow for less than state-of-the-art security technologies in your engineering processes. Risk management is extremely important during the engineering process. With each compromise or trade-off you make, you will have to assess the risk of that trade-off. If you decide to include older or legacy security technologies, such as encryption algorithms, for example, then you have to assess the risk of that decision.

Is increasing the risk necessary to ensure functionality with older systems? Can older systems be upgraded? If not, are there mitigations you could put in place to reduce the risk of using older technologies?

As you can see, in every aspect of managing information technology and security, you must account for risk, even in the systems engineering lifecycle.

Systems Assessment
Risk can be assessed at different levels of the organization. You can assess at the top-level management tier by assessing program management risk, such as the risks incurred from budgeting, policies, governance, compliance, organizational structure, and so on. You can also assess the middle tier of the organization, where you are assessing the risk of processes used across the organization, such as human resources processes, security processes, training, and so on. Most cybersecurity analysts, however, more often than not assess risk at a lower tier—the system level. For this discussion, assessing risk at the system level also means assessing network infrastructure risk, security controls, data flows and usage, and so on.
There are many different risk methodologies that discuss assessing system risk. A few of the major ones, such as OCTAVE, ISO/IEC, and NIST, are explained in the following sections.

OCTAVE
The U.S. Government, in conjunction with Carnegie Mellon University, developed the Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) methodology to help organizations identify, assess, and manage cybersecurity risk. OCTAVE has several iterations, and its methodology essentially consists of four phases, divided into eight total steps, as follows:
- Phase 1: Establish Drivers
- Step 1: Establish risk management criteria
- Phase 2: Profile Assets
- Step 2: Develop an information asset profile
- Step 3: Identify information asset containers
- Phase 3: Identify Threats
- Step 4: Identify areas for concern
- Step 5: Identify threat scenarios
- Phase 4: Identify and Mitigate Risks
- Step 6: Identify risks
- Step 7: Analyze risks
- Step 8: Select mitigation approach

OCTAVE requires that an organization identify its assets, its threats, and its risks before selecting a mitigation approach. While OCTAVE is not specific about identifying vulnerabilities, these are considered as part of Phase 3 Step 4: Identify areas of concern. Typically, likelihood is also considered in Phase 3, as part of the threat scenario, since likelihood may be factored in as the likelihood that a threat will exploit a vulnerability in a given scenario.

ISO/IEC Standards
The International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) are two organizations engaged in developing and implementing international standards for engineering, information technology, and many other endeavors. In this discussion, we are concerned with their standards for risk management.

Two standards in particular are of interest here:
- ISO/IEC 27005:2018, “Information technology — Security techniques — Information security risk management” covers information security risk assessment and treatment.
- ISO 31000:2018, “Risk management — Guidelines” describes general risk management and processes.

Both of these publications, along with other ISO/IEC 27000-series standards, provide for cybersecurity controls implementation and risk management. Organizations using this methodology are typically required to be assessed and certified by an independent assessor qualified in those standards.

NIST Risk Assessment Methodology
The National Institute of Standards and Technology (NIST) is a comprehensive risk management and assessment methodology that is used in the U.S. federal government but can also be employed by public and private organizations.

The NIST risk assessment methodology is found in Special Publication (SP) 800-30 and consists of four primary steps, broken down into a total of nine activities, as follows:
- Step 1: Prepare for assessment
- Step 2: Conduct assessment
- Identify threat sources and events
- Identify vulnerabilities and predisposing conditions
- Determine likelihood of occurrence
- Determine magnitude of impact
- Determine risk
- Step 3: Communicate results
- Step 4: Maintain assessment

Note that most of the aforementioned risk assessment methodologies provide steps for identifying the basic elements of risk as part of the assessment: threats, vulnerabilities, likelihood, and impact.

While all these different methods provide a framework for assessing risk, there are certain methods you should use to gain a complete picture of system risk:
- Interviews with system personnel (system, network, and security administrators)
- Documentation reviews (operating procedures, security documentation, architecture diagrams, and so on)
- Technical testing (that is, vulnerability assessments)
- System observations (actually observing security controls in operation on a system)
These methods used together can give a more complete picture of system vulnerabilities, and by extension system risk, than any of the individual methods would.

Exam tip: You will not be required to know the steps of any particular risk assessment methodology; they are described here to give you a context and understanding of how risk assessments are generally conducted.

Documented Compensating Controls
Very often we assess risk and discover there are security controls that are not functioning as effectively as they should or that have controls missing. Our first impulse is to go ahead and improve our controls, upgrade them, or implement new ones. That’s not always possible, for various reasons. There can be organizational constraints, time sensitivity, system criticality, budget issues, and even governance or compliance issues that prevent us from using controls we deem as ideal for the situation. As part of our risk mitigation strategy, however, we may determine that we can implement compensating controls to reduce the risk associated with ineffective or missing controls. Compensating controls are those that are not the ones we would like to use but rather those we must “settle for” to quickly reduce risk. Ideally, compensating controls are temporary, until we can overcome the constraints preventing us from using better solutions.
For instance, suppose you are trying to reduce the risk from a legacy financial database that can only communicate using an older encryption algorithm. Because that’s the only way it can communicate with your other line-of-business applications, and it is a critical database the organization cannot afford to upgrade for various reasons, all other applications on the network must “talk down” to that encryption level. What could you do to compensate for this risk? You could isolate that database and limit the applications it communicates with. You do this either logically or physically, placing it on a dedicated subnet via a VLAN and then restricting access to that VLAN from other devices. You can also encrypt its communications via a tunnel with a stronger algorithm, if possible (for example, using IPSec), by sending its communications through another intermediary device before they are sent to any hosts with which it communicates. None of these situations is ideal, of course, but they might help compensate for the inability of the database to encrypt its communications using a stronger algorithm.
When responding to risk, you want to use the best mitigations at your disposal, such as the strongest controls. But when you can’t do that, due to the constraints we previously mentioned, you may have to use compensating controls that might not be ideal. When this happens, you must document the use of these controls. Using less-than-ideal controls should be something that’s approved by senior management, once you have communicated the risks to them. There should be a strong, well-thought-out justification for using compensating controls, and there should be a path forward for eventually finding a solution to use stronger, more permanent controls. You should document any processes and procedures used, as well as any unique requirements for the compensating controls.
The reason for documenting these compensating controls is that you might have to justify them to an auditor, an inspector, a customer, a business partner, or a regulatory agency. Documenting a control shows that you have done your due diligence and care and have assessed the risk of using the control. You must be able to demonstrate that it reduces risk while taking into account constraints that prevent you from using ideal controls. These constraints could include budget or other resources, backward compatibility, system criticality, time sensitivity, and so on.

Exam tip: Remember that compensating controls should be temporary, only until an organization can implement more desirable, permanent controls.

Training and Exercises
Personnel across the organization, including cybersecurity professionals, managers, and even end users, must be trained on proper security processes and procedures. Beyond that, the entire organization should adopt a culture that is focused on security. This can only come through intensive training and indoctrination. That’s why training should be accomplished when individuals first join an organization, and periodically thereafter. It’s also why training shouldn’t focus only on general security procedures but should also target an individual’s role and responsibility in the organization. Cybersecurity professionals, for example, should be trained on the security technologies they are required to support. Managers should be trained on topics such as due diligence and care, privacy, legal liability, incident response management, business continuity and disaster recovery, and investigations. Ordinary users should be trained on things like how to respond to phishing attempts and malware.
In addition to solid training, the organization has to produce detailed policies and procedures on security-relevant issues. This includes incident response policy and plans, business continuity and disaster recovery, and risk management. It is not simply enough to formulate these plans and put them on a shared drive or in a binder and declare them complete. These plans must be exercised so that the organization can determine if they are effective, if they address all issues, if they are properly resourced with personnel and equipment, and to ensure that personnel are well-versed on their responsibilities, processes, and procedures.

Red Team
Results from a vulnerability assessment are purely theoretical; those are weaknesses that could be exploited by a malicious entity such as a hacker. Exploiting those vulnerabilities, however, moves from the theoretical to the actual. An organization would rather not have a malicious hacker determine if their vulnerabilities are truly exploitable. That’s why they hire a red team. A red team is composed of professional ethical hackers. Their job is not only to discover vulnerabilities on systems but to attempt to exploit those vulnerabilities. Of course, they do this with the full permission of the organization; typically that comes from a senior executive who is knowledgeable about the red team and their activities. The most important aspect of engaging a red team is that the team has legal authorization from someone in a position to grant it to attempt to exploit vulnerabilities on the target network. Without this authorization, they are simply malicious hackers.
While being “threat faithful” is the best way to perform a red team assessment, rules of engagement are understandably involved to prevent any permanent harm or damage to the network or its assets.

Rules of engagement may include the following:
- Only attacking the network during specified hours or days of the week
- Only attempting to exploit certain vulnerabilities and ignoring others
- Only attempting exploits on certain systems
- Documenting all attempted and successful exploits
- Signing a nondisclosure agreement to keep any sensitive information about the security posture of the network from unauthorized personnel
- Agreeing to only use certain tools or tactics
- Assisting network defenders after the attack in mitigating any vulnerabilities that were exploited

Blue Team
If the red team is composed of cybersecurity professionals playing the role of the malicious attacker and attempting to exploit vulnerabilities discovered on an organization’s infrastructure, then the blue team is the exact opposite. A blue team is composed of cybersecurity personnel who are network defenders. They are the ones tasked with detecting an attack, containing it, mitigating it, and responding to the incident. In some types of exercises, the blue team is aware that the red team is attempting to attack the network, so they are more vigilant in paying attention to intrusion detection and prevention systems in hopes of detecting evidence of an attack. In some exercises, however, the network defenders do not know that a red team has been employed to test the network. This is as much a test of their vigilance and ability to detect an attack as their ability to contain and mitigate it.

White Team
A white team (often called a white cell) is the group of cybersecurity experts in charge of conducting an exercise, acting as a liaison between the teams and the organization, enforcing the rules of engagement, and intercepting any problems that might arise from the exercise. They are also considered trusted agents, in that they are trusted with sensitive information regarding the red team’s strategy and tactics as well as those of the blue team. They are also there to protect the overall interests of the organization. They serve as referee, subject matter expert, and arbiter as well as provide oversight for the exercise. The white cell team may consist of key experienced members of the blue team, red team, and organizational management, none of whom are playing in the exercise; instead, they are there to lend their expertise.

Note: Don’t confuse a red, blue, or white team with the concept of a white, black, or grey hat hacker. These are completely different terms and concepts. Whereas the color of the team indicates their role in the exercise, the color of the hat denotes whether a hacker is an ethical hacker (white hat), a malicious hacker (black hat), or someone who could go either way, depending on the circumstances (grey hat).

Tabletop Exercise
While there are many different types of exercises, depending upon the overall goal of the exercise or test, the one conducted requires different efforts. A tabletop exercise is normally a paperwork type of exercise, where the participants sit around a table in a conference room and react to written scenarios by stating what the reactions or actions should be to meet the goals of the exercise. If it is a disaster recovery tabletop exercise, then the participants react to a natural disaster and each, in turn, participates by saying what they would do to respond to the disaster, saving lives and equipment, and recover from it. If the exercise is an incident response exercise, then the participants would respond to a scenario by putting forward different response actions appropriate to the scenario. In any case, no actual equipment is used and no actual activities are performed during the exercise; it is all theoretical and based on the organization’s plans and procedures. A tabletop exercise is very effective in determining if your procedures are sound and if the plan covers all of the bases it should. A tabletop exercise can show any conflicts between activities or resources, prioritization issues, and organizational problems, and it can simply point out issues that may have been overlooked or forgotten.

Supply Chain Assessment
Risk assessments can span an entire organization, or they can be focused on a particular program, a set of processes used across the organization, or even a particular asset. Yet another type of risk assessment can be used to assess the risk involved with supply chain management. The supply chain is composed of many different elements, all focused on getting the organization the needed supplies, equipment, services, and other products it needs to perform its mission. However, malicious entities have discovered that sometimes it can be just as effective to attack an organization by subverting the same needed supplies and equipment with malware, counterfeit parts, and compromised firmware as it would be to directly attack the organization’s infrastructure through the network. It simply requires a bit more planning and patience on the part of the attacker.
It should be noted that attacking the organization isn’t always the goal of someone who poisons the supply chain. It could be just opportunistic criminals looking to sell cheap counterfeit parts to anyone who will buy them, to make money off of the purchasers. It can also, at the other end of the spectrum, be a calculated attack from an advanced persistent threat, such as the government of a nation-state, to subvert security hardware so that they may more easily attack a target undetected. No matter the motivation, supply chain risk is real and can cost organizations millions of dollars in equipment purchases and in implementing security measures that aren’t effective because of compromised systems bought from a poisoned supply chain, never mind the costs of the attack itself in terms of lost data and systems.
Supply chain risk management looks at securing every link in the chain. This includes the purchasers, vendors, buyers, contracting functions, and any other entity involved in the acquisition process. A risk assessment of the supply chain looks at any possible risks at every stage of the process; purchasers may be required to buy from only certified sources, vendors may have to certify that their systems meet certain security standards, hardware components may have to have traceability by serial number right back to their manufacturers, firmware may have to be tested for integrity, and sources may have to certify that their equipment is genuine and has not been compromised. Two elements that we will discuss involving supply chain risk management include vendor due diligence and verifying the authenticity of hardware and its sources.

Exam tip: Understand that supply chain risks must be assessed and mitigated throughout every link in the chain.

Vendor Due Diligence
Vendors and other providers must offer assurances that their equipment, supplies, and services are genuine, have not been compromised in any way, and meet full security and functional requirements specified by the organization. Often vendors are required to maintain a high level of insurance against potential issues with their products to help ensure that they are performing due diligence and due care in maintaining their portion of the supply chain. Third-party assurances and certifications may also be used to assure potential customers that their manufacturing processes, parts sourcing, and security assurance programs meet expectations. Most vendors offer warranties or guarantees against counterfeit products or any that may be found to be compromised. Additionally, vendors will often provide documented traceability of a product, particularly an expensive or critical one, for the customer to ensure that the supply chain has not been compromised in any way.

Hardware Source Authenticity
Hardware authenticity is particularly troublesome. Expensive specialized equipment, such as routers, switches, firewalls, and so on, have often been compromised with counterfeit components, which will fail more often than their genuine counterparts, or software or firmware that has been compromised in some way before it even arrives at the customer’s facilities. Hardware traceability is important to a vendor so that they can provide their customers with some assurance that the hardware is genuine, secure, and meets all of its security and functionality requirements. Hardware is often traced by part and serial number for the overall assembly, but even the individual components, such as circuit boards and even chips, are also traced this way, typically by serial number, part number, and manufacturing batch. A vendor will offer documentation to support the integrity of the entire supply chain responsible for getting the product from the manufacturer to customer.

REVIEW
Objective 5.2: Given a scenario, apply security concepts in support of organizational risk mitigation In this module, we discussed risk concepts and their relationship to security. The organization has to navigate risk management along with balancing security, functionality, and resources to achieve the best risk reduction possible.
One of the first things organizations should do is perform a business impact analysis. A BIA can tell an organization what its critical business processes are, as well as the assets that support them. Then the organization can prioritize these assets and processes for protection, restoration, risk reduction, and resource expenditure.
As part of the risk management process, the organization should identify its risk elements, including threats, vulnerabilities, and assets. The organization also has to determine what the probability is that a threat will exploit a vulnerability in an asset. The magnitude of impact is the level of harm that is done to an asset when this happens. Risk is a product of both the probability of occurrence and magnitude of impact.
Risk factors can influence the different elements of risk in different ways. There are external risk factors that the organization cannot control, including the economy, socio-political environment, market conditions, and so on. Internal risk factors are those the organization can exert some control over, including internal organizational structures and allocation of resources.
Risk prioritization is what the organization must do when it assesses risk and determines how it will respond to different risks. Organizations can respond in different ways, including risk mitigation, risk acceptance, risk transfer, and risk avoidance. Prioritization is a decision based on the criticality of assets and the number of resources the organization is willing to commit to reducing risk for those assets.
Security controls are measures the organization takes to protect assets and reduce risks. Generally, there are three categories of controls: managerial, operational, and technical. There are also different types of functions the controls fulfill, sometimes concurrently. These can include detective, deterrent, preventative, corrective, compensating, and recovery.
Risk management is a balance struck between reducing risk and security, functionality, allocation of resources. Trade-offs have to be made during the entire systems engineering lifecycle, particularly in the requirements, design, architecture, and implementation phases of the lifecycle. Any engineering trade-offs should be documented and justified. Risk assessments also have to be performed on security control trade-offs, and any increased risk incurred should have a plan for mitigation.
Assessing risk to the system can use one or several different standard methodologies, including OCTAVE, ISO/IEC standards, and the NIST risk assessment methodology. Four key ways an organization can get a complete picture of risk are interviewing key personnel, reviewing system and security documentation, technical vulnerability testing, and observing system security controls in operation.
Compensating controls are used when a more preferred control cannot be implemented for various reasons, including system and organizational constraints. These constraints could be resource constraints, system criticality, or even governance constraints. The use of compensating controls should be justified and documented accordingly.
Training personnel and exercising response capabilities are important ways not only to ensure that personnel understand their roles and responsibilities with regards to various security issues but also to perform tasks in the event of an incident or disaster. Different types of tests and exercises are performed to assess the security of an organization as well as its resiliency. Three particular types of teams involved in assessing an organization’s security posture are the red team, the blue team, and the white cell team. These teams are concerned with participating in an adversarial assessment exercise, whereby vulnerabilities are not only discovered but also exploited. Tabletop exercises are documentation-based exercises where participants answer various written scenarios with proposed documented action plans and procedures. These exercises serve to ensure the adequacy of response plans and improve an organization’s response capability.
Supply chain risk management involves examining every link along the chain that provides organizations with services, equipment, supplies, and systems. This includes vendors, purchasers, contractors, and the technical processes used along the way. Supply chain integrity depends on the due diligence of vendors who must document their processes and ensure that they are providing genuine systems and parts that have not been compromised in any way. Hardware source authentication means that a piece of hardware must be able to be traced back to its component manufacturers, via part number, serial number, and even batch number. The end user must have an assurance that the hardware has not been compromised in any way and that it is not counterfeit.