Cost-effective Operational Reliable Efficient, C.O.R.E. Technology Security Series

Cost-effective Operational Reliable Efficient CORE Technology Security involves only what is required to manage technology risks specific to each organization, no more and no less. By emphasizing CORE, declare the objectives and build to those objectives. Regarding security, CORE enables organizations to have 100% accurate asset inventories, proactively manage vulnerabilities, detect threats to each technology, respond to exploits (accidental or otherwise), and maintain business operations while recovery activities are underway. After implementing the CORE Technology Security Inventory, Remediation, and Detection, focus on decision-making.

Word to the wise: Organizations should build out their CORE Decision capabilities only after CORE Inventories, Remediation, and Detection capabilities are 100% complete. Decision-making is the first step to technology security operations management and is only possible once these other CORE capabilities are already in place and functioning.

Technology Decisions

Most organizations have realized that technology departments are as essential and critical to business as their finance and legal departments. This is evidenced by an executive-level chief technology officer (CTO) or equivalent. However, making technology decisions remains a challenging function of technology management, and these same organizations aren’t commonly prepared to make them as effective as possible. According to the CORE Technology Security philosophy, making technology decisions should be as easy to perform as possible to be effective.

Standardization is the key to making Cost-effective, Operational, Reliable, and Effective decisions in this CORE process. This comes as a process composed of inputs and steps with predictable outputs. After all, making consistent decisions is only possible with a consistent approach. Fortunately, most security decisions are very similar in composition, including the costs and impacts of each choice. Some have referred to this as a “cost versus benefit” analysis. Therefore, the CORE Decision process is a risk-based methodology focusing on preset inputs, steps, and outcomes.

Creating Preset Outcomes

Developing processes and standards is typically done by analyzing inputs before determining how to proceed. This is the opposite of the CORE approach. With CORE, one looks for foreseeable outputs first. This is why CORE starts by determining the decision outcomes before looking for inputs or how the process should work.

Many have yet to realize this, but all technology security decisions should be Boolean, binary, and with no exception. In a perfect world, technology decisions would always be “yes” or “no.” These examples are what some might expect in this Boolean world.

Yes, lay off employees and use the Managed Service Provider (MSP).
No, do not use that scary Internet of Things (IoT) device instead of a hard-wired sensor.
Yes, use the software as a service (SaaS) instead of the data center application.
No, do not apply critical patches now instead of waiting till the annual maintenance cycle.

Once the security decision is made, the organization can proceed with whatever the next steps are in those processes. In the meantime, technology security personnel appear to have all of the “go” or “no go” control over technologies.

Everyone has to ask, “Should technology security personnel have that much control?”

The answer, of course, would be “no” if the rest of the organization does not trust their process; these personnel do not have the authority.

The Security Decision-Making Flaw

Unfortunately, an apparent major flaw exists in typical decision-making processes. The flaw is that not everyone will be satisfied with these decisions. Think about it. Those who favor the IoT solution would not favor the Internet connection to the thing. Likewise, those not in favor of the MSP would not favor the decision to lay people off. If a decision is made, there will always be a counter-perspective to that decision. Where there is a “yes,” someone will want a “no,” and where there is a “no,” someone else will want a “yes.” The existence of the counter-perspective isn’t the flaw; the ignorance of the counter-perspective is why most technology security decision-making processes are inconsistent in organizations today. Operating with a lack of consideration for the counter-perspective is the flaw.

This point requires more attention. Consider that each example includes other background business processes that have already taken other team members’ time and effort. Therefore, if security could make or break a business case, it must be supported by a business process. That flaw exists because organizations fail to treat security decisions as business decisions and define how to arrive at these decisions clearly to all. The process has to be a business decision; that is, a decision that considers costs and the value or income system that each business operates under.

How to Influence Effective Business Decisions

In the interest of simplification, CORE looks to the top of an organization to clarify the necessary factors that go into business decisions. Each of these factors offers a perspective that carries importance within the organization including executive, financial, legal, technology, and operating. To emphasize their importance, most organizations have dedicated chiefs, the C-suite, to lead them. For example,

The Chief Executive Officer (CEO) represents the core business. This function ensures that the organization's goals and vision are represented in all decisions.
The Chief Financial Officer (CFO) represents the monetary aspects of business. This function ensures that the financial rules within the organization are represented in all decisions.
The Chief Legal Officer (CLO) limits the liability within the organization. This function ensures that agreements are not one-sided and that the organization operates legally in all decisions.
The Chief Technology Officer (CTO) represents the cyber aspects of business. This function manages how the organization utilizes technology and considers cyber risks in all decisions.
The Chief Operating Officer (COO) represents how the necessary daily business activities are enabled. This function ensures that personnel, resources, and logistics are considered in decisions.

To make a CORE Decision, one must consider the organization, monetary rules, liability, technology capabilities, and operations. These factors strengthen the decision process and can be used to present results that the organization, as a whole, can stand behind. With these factors, all of the critical counter-perspectives will be addressed, as well. The process will, therefore, be trustable and rational.

Notice: Each executive officer example states that these functions are considered in “ALL” decisions. This is key. Successful organizations are run by leaders who have strong communication skills, above all else, and that’s a skill. They communicate their rules through conversations and document them in policies that the organization operates under. Without policy, the vision is lost, and chaos ensues.

The Decision-Making Outputs

The decision-making factors are now known, and many might believe they can make informed decisions. This is not the case, not yet. The five factors are only sufficient when considering how to use these factors. Each of these has to be framed in an interpretable and acceptable way to ensure that data are usable and the decision-making process can consume it all to function adequately.

Start by identifying the kinds of outputs. These are the following.

Decision. This is the “yes” or “no” technology security answer that everyone expects.
1. Effective decisions result in clear and actionable results.
2. “Maybe” is not a decision; it’s indecision.
Rationale. This is the reason behind the decision results, including the five business factors.
1. Effective decisions address and clarify the counter-perspective.
2. Unreasonable decisions are not decisions; these are commands.
Actions. These activities are required to ensure the decisions are abided by.
1. Effective decisions guide people to perform effectively.
2. Lack of direction is not a decision; it’s a conversation.

Consider a Risk-Based Approach

Technology security decisions are commonly performed to gain investment for security technologies, reconfigure existing networks, or decide to do nothing at all. Each of these decisions poses a risk. For example, a poor decision in security investment could lead to wasted security funds and unnecessary budget depletion. While doing nothing at all could lead to a massive security breach. Therefore, organizations use a risk-based decision approach.

Most technology security professionals are probably familiar with a form of assessing risks. However, most must comprehend that risk is relative, just like reward. Every relevant risk, just like every reward, must have measurable values for impact and likelihood. These measures are necessary for risk to have decision-making value. Unfortunately, defining technology risks in this form can become very compressive and time-consuming, as the efficient correlation of those risks as practical inputs to decision-making is nearly impossible. CORE Technology Security explains a simple way to make effective risk-based decisions by considering impacts and likelihood without the complexities of traditional processes.

Disclaimer: While this CORE Decision process is risk-based, it does not perform a risk assessment to make technology security decisions. At the heart of these decisions is ensuring they are cost-effective, operational, reliable, and efficient. The CORE Decision process aims to enable the decision process, not a lengthy and unmanageable risk-assessment procedure.

Defining Impacts

In information security today, most organizations have adopted a system of measurement based on information protection objectives that include confidentiality, integrity, and availability (CIA). CIA is an internationally accepted set of security objectives initially published in the ISO/IEC 17799 circa 2000. The United States (US) added values to CIA objectives by defining low, moderate, or high-impact measurements according to FIPS 199. With these FIPS 199 impacts, information systems can now be quickly assessed for how to set security objectives. The drawback is that the CIA only accounts for data or the information being processed, stored, or transmitted on technologies, and it does not account for technologies used to manipulate the physical world. These are industrial control systems that need to be included.

CORE Inventory improves the common security objectives by defining the CORE 3Cs, Criticality, Confidentiality, and Capability, which can be summarized as follows.

Critically. The scale of a given technology impact in an organization by identifying tactical consequences to a technology (system level), a function (business process level), or the organization (enterprise level).
Confidentiality. Strategic impacts on the organization if unauthorized people exploit, breach, and compromise technologies.
Capability. A technology’s ability to Control or Monitor the physical world in addition to processing, storing, transmitting, and receiving data.

Each CORE “C” has various options to simplify choosing the most appropriate impact level. The difference between CORE and typical processes using CIA is that CORE defines values specific to each C and not the same range (i.e., low, moderate, high). It’s all in the context. The option levels for each of the CORE 3Cs are as follows.

CORE Criticality

Critically defines the scale of a given technology impact in an organization by identifying consequences to a technology (system level), a function (business process level), or the organization (enterprise level).

Disclaimer: This criticality rating process is not new and derived as a hybrid of US Department of Defense Mission Assurance Categories (MAC) and the “Organization-Wide Risk Management Approach” in the National Institutes of Standards and Technologies (NIST) Special Publication 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations. These data and the Criticality results align with most business impact analysis processes.

CORE Confidentiality

Confidentiality defines impacts on the organization if unauthorized people exploit, breach, and compromise technologies. Keep this simple by considering personal privacy, trade secrets, intellectual property, financial futures, etc. The Confidentiality rating is directly proportional to an organization’s tolerance for loss due to regulatory fines, potential legal fees, litigation costs, payouts, loss of reputation and shareholder confidence or market share, loss of contract and customer credits, etc.

Confidentiality tolerances will need to be determined by each organization to ensure the loss is completely understood and agreed upon. Each organization may decide its tolerances based on operations revenue, etc.

CORE Capability

Technologies that can manipulate or interact with the physical world might cause health, safety, environmental, quality, or operational impacts with dire consequences such as loss of human life or damage to equipment if compromised. These technologies are often referred to as Operational Technologies (OT) to distinguish them from Information Technologies (IT), which function to manage data instead.

Using these CORE 3Cs as inputs to the decision-making process, organizations will be able to quickly and clearly understand the consequences of each decision.

Disclaimer: Examples of the CORE 3Cs will be further explained later in this text during process examples where these ranges are assigned meaningful values to an example organization. For more details about how each of the 3Cs is captured during technology characterization, refer to the CORE Inventory.

Defining Likelihood

Once the CORE impacts are understood, the likelihood of those impacts occurring must be determined. Likelihood is typically expressed in ranges as well. The National Institute of Standards and Technology (NIST) defines examples of how to measure likelihood in its Guide for Conducting Risk Assessments Special Publication (SP) 800-30r1.

Disclaimer: Be warned, NIST explains a very complex process for determining the likelihood that uses inputs from the organization, mission or business process, and information system and scaled values, including the likelihood of threat event initiation, threat event occurrence, and threat event resulting in adverse impacts to come up with an overall probability. While these likelihood scales do seem to work in theory, in reality, they are all based on assumptions that threat actors will do what NIST thinks they will do.

CORE Technology Security focuses on what threat actors can do to a technology based on how a system is designed instead of what an organization theorizes a threat actor will do. To ensure the meaning is clear, this is defined through the CORE Exploitability Assessment. The basic premise for this assessment methodology is as follows.

All technologies have predisposed conditions that can be exploited, regardless of software vulnerabilities or the threat actors' will and the means to exploit them.
Some technologies are more exploitable than others based on how they are engineered, integrated, and deployed.
To determine levels of exploitability, it must be calculatable using a trusted formula.
Most of the world has a process for measuring exploitability using the method that software vulnerabilities are measured with, A.K.A the Common Vulnerability Scoring System (CVSS).
CVSS vulnerability scoring measures exploitability using a formula and metrics.
The CORE Exploitability Assessment uses the CVSS exploitability metrics to calculate technology exploitability.

To use the CVSS exploitability metrics for technologies versus vulnerabilities, CORE reverse engineers each metric according to a standard set of rules. These rules allow organizations to establish this exploitability rating system as a trusted source for prioritizing assets and activities, which is essential to decision-making.

The CORE Exploitability Rules work as follows.

CORE Connection (CVSS Attack Vector)

The Connection metric is listed in the inventory as a technology characteristic and shall be captured during the CORE Inventory process. As with the others, this metric is required to make informed, risk-based technology decisions. Completing the CORE Inventory is essential in all CORE Technology Security. This CORE Exploitability Rule assumes that technologies designed with no connectivity are less exploitable than those with non-routable connections, which are less than routable connections, and so forth. Connection aligns with the CVSS base metric “Attack Vector,” as explained in the model and table below.

CORE Cloud (CVSS Attack Complexity)

The Cloud metric is listed in the inventory as an organization characteristic and shall be captured during the CORE Inventory process. The Cloud terminology assumes that technologies deployed on-premises require more complexity to exploit than those in the Cloud. This CORE metric aligns with the CVSS base metric “Attack Complexity,” as explained in the model and table below.

CORE Capability (CVSS Privileges Required)

The Capability metric is listed in the inventory as a process characteristic with a dual purpose. CORE technology capabilities describe both impact and exploitability. This CORE Exploitability Rule assumes that technologies that can control the physical world cause more damage and shall be made more difficult to exploit, not necessarily easier to exploit. This increases the priority over those that monitor or process data only. Additionally, there is a modifier to increase further the score for technologies that are not supported or are at the end of life to ensure decisions are made to favor retirement. This metric aligns with the CVSS base metric “Privileges Required,” as explained in the model and table below.

CORE Virtualized (CVSS User Interaction)

The Virtualized metric is listed in the inventory as a technology characteristic and shall be captured during the CORE Inventory process. The Virtualized terminology assumes that technologies deployed in virtual environments do not require human interaction to exploit. Virtual technologies are entirely software-based, allowing exploits to occur directly from the hypervisor to the technology. This CORE metric aligns with the CVSS base metric “User Interaction,” as explained in the model and table below.

CORE Retire (CVSS Scope)

The Virtualized metric is listed in the inventory as a technology characteristic and shall be captured during the CORE Detection process. According to CORE Detection, New technologies are added to the inventory and considered Mature once added with a complete CORE Tag. Technologies that are no longer supported and are at end-of-life shall be marked for retirement on the CORE Tag. This CORE Exploitability Rule assumes technologies that no longer receive security fixes have a non-working security function, provide an infinitely exploitable attack vector to all networked and adjacent technologies, and should receive a higher exploitability score to ensure decisions favor removal. This CORE metric aligns with the CVSS base metric “Scope,” as explained in the model and table below.

The CORE Exploitability Assessment utilizes the CVSS 3.1 formula to define a numerical value for exploitability.

Disclaimer: While CORE Technology Security did reverse-engineer the CVSS metrics to explain technology exploitability instead of vulnerability exploitability, it does not claim the rights to the equation. We at CORE appreciate and are grateful to those who have developed and managed the CVSS and its variants at First.org. First.org has yet to provide approvals to CORE to use this formula directly. However, organizations and technology-responsible persons should be open to using this approach. This CORE approach further enhances the use case for the CVSS in vulnerability scoring and aligns technology security prioritization, especially concerning patch management, directly with the CVSS vision.

Technology Prioritization Scoring

CORE finalizes the risk-based inputs by combining the impacts and likelihoods, again using the CVSS 3.1 as the formula for a CORE Technology Prioritization Score as the final input to the decision-making process. Before proceeding, the final values are listed in the table below.

CORE utilizes these metrics using the following formulas derived from CVSS 3.1.

Impact Calculation:

If Retire <> Not supported then

Impact = 6.42 x (1-((1-Criticality) x (1-Confidentiality)))

Else

Impact = 7.52 x ((1-((1-Criticality) x (1-Confidentiality))) - .029) -3.25 x ((1-((1-Criticality) x (1-Confidentiality))) - .02)15

End if

Exploitability Calculation:

8.22 x Connection x Cloud x Capability x Virtualized

CORE Priority Score:

If Retire <> Not supported then

Roundup (Minimum ((Impact + Exploitability),10)))

Else

Roundup (Minimum ((1.08 x (Impact + Exploitability), 10)))

End if

This completes the CORE Prioritization Score. Now, when a decision is being made, there will be no question about how important the technologies are to the organization, including a numerical ranking system. Continue to learn about the decision-making process and how to align values relevant to the organization to the CORE Prioritization scoring system.

Disclaimer: At this point, the CORE Prioritization Score might be the simplest way to prioritize technologies to make risk-based security decisions, and that one is probably right. However, the executive, financial, legal, technology, and operating officers must still be factored in before deciding. Continue to the CORE Decision Process to ensure cost-effective, operational, reliable, and efficient decision results.

CORE Decision Making Process

Decision-making in CORE utilizes the data points, inputs, and outputs described in this document. Some areas require values and thresholds that are important to organizations. These will be explained following a brief overview of the process.

A request is made that requires a technology security-related decision.
The primary business factor is identified as the point of the request.
The business factor counter-perspective is identified to oppose the request.
Compare perspectives considering the CORE Prioritization Score for the relevant technology.
The decision is made including:
1. A Decision
2. The Rationale
3. Actions to be taken

The CORE Decision process is depicted as follows.

Disclaimer: The CORE Decision process is straightforward but has some slightly complex numeric considerations. These include the CORE Prioritization Score and the values of the business factors. Business factor values will be explained in the example decision to limit duplication.

Example Decision

Most organizations have faced or will face a request to move critical services to the Cloud. This could be one of the most challenging decisions, especially in typical organizations where business drivers and cost-saving frequently take higher priority than security.

Disclaimer: This example includes a fictional organization with fictional business factors, including financial and technological data. Note how the data are collected and rationalized now, as it is only explained here.

The Request

In this hypothetical example, the operations team requests to move their Supervisory Control and Data Acquisition System (SCADA) to the Cloud. The current architecture is depicted below with the SCADA system installed in the Control Room, including the SCADA Server (1), Human Machine Interface (2), and Network Switch (3), as identified in the red box.

The requested updates are depicted in the following architecture.

There is no change to the functionality of the SCADA system or the other systems in the drawings. The only change is migrating the technologies out of the control room and into the Cloud. The tables below explain how the requested changes will be reflected if the migration is approved.

SCADA System on Premises

SCADA System in the Cloud

In addition to those listed in the table above, remember that the CORE Inventory shall include all attributes necessary to manage technology security. The qualities needed for decision-making (i.e., capability, confidentiality, connection, etc.) will be addressed further down in the process.

The Business Factors

Before decisions can be made, organizations shall define what their business factory thresholds are. These thresholds are the associated values, including one that prioritizes the respective factor and one that deprioritizes it. Examples of these are explained in the table below.

In this example, the project team requests to move the SCADA system to the Cloud to save onsite hosting and support costs.

Calculating the CORE Prioritization Scores

Technology scores shall be calculated for each asset in the inventory first. As one will shortly see, these scores can also be calculated for technologies before purchasing decisions. This section calculates the CORE Prioritization Score for each of the three SCADA technologies installed on-premises and in the cloud for comparison.

Impact: (6.42 x (1-((1-1.125) x (1-0)))) = 7.22
Exploitability: (8.22 x .62 x .44 x .85 x .62) = 1.18
CORE Priority Scale: Roundup (Minimum ((7.22 + 1.18),10))) = 8.5

Impact: (6.42 x (1-((1-1.125) x (1-0)))) = 7.22
Exploitability: (8.22 x .85 x .77 x .85 x .85) = 3.89
CORE Priority Scale: Roundup (Minimum ((7.22 + 3.89),10))) = 10

Impact: (6.42 x (1-((1-1.125) x (1-0)))) = 7.22
Exploitability: (8.22 x .62 x .44 x .85 x .62) = 1.18
CORE Priority Scale: Roundup (Minimum ((7.22 + 1.18),10))) = 8.5

Impact: (6.42 x (1-((1-1.125) x (1-0)))) = 7.22
Exploitability: (8.22 x .85 x .77 x .85 x .85) = 3.89
CORE Priority Scale: Roundup (Minimum ((7.22 + 3.89),10))) = 10

Impact: (6.42 x (1-((1-.5) x (1-0)))) = 3.21
Exploitability: (8.22 x .62 x .44 x .27 x .62) = .38
CORE Priority Scale: Roundup (Minimum ((3.21 + .38),10))) = 3.6

Impact: (6.42 x (1-((1-.5) x (1-0)))) = 3.21
Exploitability: (8.22 x .85 x .77 x .27 x .62) = 1.23
CORE Priority Scale: Roundup (Minimum ((3.21 + 1.23),10))) = 4.5

As one can see from the above calculations, the technology scores all increase by moving them to the Cloud. These results indicate that if this move to the Cloud were to occur, a higher risk for exploitation would be the cause. Therefore, the risks of moving these types of systems to the Cloud may outweigh the organization's desired benefits.

Compare Business Factors to Prioritization Scores

Now, the questions must be raised,

“What are the business factors driving this request?”

“What are the enemies of these drivers?”

As a reminder, this request involves moving the SCADA system to the Cloud for potential cost savings. This means that this is a financially drive decision. Next, review each business factor to identify at least one or more counter perspectives to the cost savings.

Increase brand awareness
Save money
Prevent breaking the law
Lower the CORE Prioritization Score
Prevent damage or injury

Based on the above list, the following can be ascertained.

Moving the SCADA system to the Cloud will likely not be accomplished to improve the organization’s brand, nor will moving to the Cloud directly and negatively impact the brand.
Saving money is the primary business factor.
There is no legal requirement to host SCADA systems in the cloud, and it is not illegal to host them.
Moving the SCADA system to the Cloud does increase the CORE Prioritization Score; therefore, this is an enemy of the primary business factor.
Moving the SCADA system to the Cloud may result in damage or injury; therefore, this is an enemy of the primary business driver.

Finally, the business factors analysis can be viewed as the following.

DISCLAIMER: In most scenarios, the CORE Prioritization Score will support either a business benefit or a counter perspective. Once these scores have been assigned to all assets in the CORE Inventory, they can be used as a pure-play Technology Security driver. Continue for the final decision results.

Decision Results

For technology security decisions to be successful, they must include the decision, the rationale, and the actions. In this example, the CORE Decision results are as follows.

Request: Move the SCADA system from the Premises to the Cloud to save hosting and support costs.
Decision: Request Denied
Rationale: Moving the SCADA system to the Cloud increases technology exploitability and the likelihood of operational impact or injury.
Actions: No further action for this request is necessary. Close request.

Summary

CORE Decide is designed to help technology-responsible personnel make cost-effective, operational, reliable, and efficient decisions. These decisions will be made during new equipment purchases, system changes, remediation, and response, as well as in other areas. In contrast to Inventory, Remediation, and Detection, CORE Decide is supplemental, enhancing the other practices. Stay tuned as the prioritization and decision-making processes, including the CORE Prioritization Score, will be further utilized and highlighted in CORE Operations.

Manage Cybersecurity Like a Boss and Make Risk-based Decisions Like a Superhero