2
Cyber Security – An Introduction to Assessment and Maturity Frameworks

There are security implications that result from our incorporating computer automation, or cyber, into business systems and industrial control systems that underpin almost everything we do. Assessing these cyber systems, to ensure resilience, is performed through a number of well‐known frameworks to develop an initial understanding, or baseline, of our current system security levels.

Assessments often begin with an asset prioritization, a “Crown Jewels Analysis1” (MITRE) being one example, with more detailed evaluations developed from this initial structure. Figure 2.1 provides an example “Enterprise Risk Analysis” structuring designed to perform this high‐level prioritization, with detailed process modeling showing system dependencies for structural evaluation. Component‐level assessment, or penetration testing, is then used at the technology level to inventory the system’s architecture.

Diagram of assessment levels depicted by boxes labeled enterprise risk, process modeling, and penetration testing with rightward arrows on top.

Figure 2.1 Assessment levels – enterprise risk, process modeling, and vulnerability analysis.

As shown in Figure 2.1, network evaluation spans from an overall key asset prioritization to specific network components. This can include using dependency or attack graphs, during process modeling, to highlight specific scenarios.

2.1 Assessment Frameworks

The standard Confidentiality, Integrity, and Availability (CIA) information security triad, complimented by subject matter expertise and proven use cases, provides a foundation for computer defense operations.

2.2 NIST 800 Risk Framework

The standard NIST SP 800‐30 is used for baseline cyber system security evaluation (Table 2.1).

Table 2.1 NIST SP 800‐30 risk assessment.

System charaterization
Threat identification
Vulnerability identification
Control analysis
Likelihood determination
Impact analysis
Risk determination
Control recommendations
Documentation

Table 2.1’s risk descriptions attempt to capture all of the issues and inconveniences that characterize the precursors of a training event for cyber planning. These are items that help with “designing in” cyber‐protective measures during the development process. For example, there are two primary ways (Gelbstein 2013) to look at current information enterprise analysis:

  1. Business Impact Analysis (BIA) – used for incident response, BIA is quantifiable, relies on credible data, and drives crisis management, including disaster recovery and business continuity:
    1. MITRE Crown Jewels Analysis
  2. Enterprise Risk Management (ERM) – used for incident forecasting is a challenge to quantify, relies on assumptions and drives mitigation plans, the risk register and the return on security investment (ROSI) calculation:
    1. NIST Cybersecurity Framework (CSF)
    2. Risk Management Framework (RMF)
    3. ISO 31000
    4. ISI 27000 series

Figure 2.2 shows how assessment and management approaches are used to help define business impact and enterprise risk analysis categories for information system evaluation.

A cloud shape with labels Business Impact Analysis, Enterprise Risk Analysis, MITRE Crown Jewels Analysis, RMF, ISA 99, COBIT, ISO 31000, ISI 27000, NIST CSF, and FAIR.

Figure 2.2 Information security – business impact and enterprise risk analysis.

As shown in Figure 2.2, information security assessment can take the form of business impact or enterprise risk analysis. In addition, taxonomy information is provided by both the Factor Analysis of Information Risk (FAIR) model (Jones 2005) and the NIST CSF, in further defining the terms used in implementing relevant security policy. Each of the frameworks is designed to improve system security, in the familiar resilience steps2 of:

  • Identify
  • Prevent
  • Detect
  • Respond
  • Reconstitute

Using the “conceptual model” provided by the standard steps of resilience provides the modeler with an approach for modeling cyber defense processes. In addition, this “conceptual model” compliments the standard maturity model assessment.

2.2.1 Maturity Models

The software maturity model, originally developed by Watts Humphrey (1989), was designed to measure the capability of a government contractor’s internal software engineering processes. We are using maturity level, in this case, to look at the security level of a computer‐based information system. This broader Maturity Model applies to any line of effort; software development, project management, and design completion, to name a few. Control Objectives for Information and Related Technologies (COBIT), for example, uses the Maturity Model concept to create maturity levels for each objective (Simonsson et al. 2007), shown in Table 2.2.

Table 2.2 Maturity levels for policy implementation and process assessment.

Maturity level Meaning
1 Initial/Ad hoc
2 Repeatable, but intuitive
3 Defined
4 Managed
5 Optimized

Table 2.2 is commonly used to state the best case (5), worst case (1), something in between (3), and then filling in intermediate maturity levels, as available. A maturity assessment often provides context, in the way of an essay, for additional reasoning about the assessment level. For example, some approaches include filling out an objective assessment, or narrative, for what each of the 1–5 states look like, in order to get an initial assessment. Other approaches (i.e. NIST CSF) use the table to do a detailed system evaluation.

Modeling and simulation becomes a useful tool once the system security is assessed, providing a baseline, around the five steps of defensive cyber operations (Table 2.4). In addition, Table 2.3 overlaps with the Critical Security Controls (SANS Institute 2006) are used to outline the identification and preventive steps necessary to do the initial network identification and protection. Examples are provided in Table 2.4.

Table 2.3 Resilience lines of effort (LOEs).

Resilience step/level 5 4 3 2 1
Identify The draft NIST CSF provides an example of this approach in evaluating the maturity levels for each of the respective resilience steps.
Prevent
Detect
Respond
Recover

Table 2.4 Resilience steps and system security assessment.

Defensive cyber operation System security assessment
Identify
  • Inventory network for key assets
  • Prioritize network assets based on security evaluation
Prevent
  • Percentage of controls in place
  • Cybersecurity policies in place
  • Cyber maturity model assessment level
Detect
  • Internet facing protections in place
  • Internal security process in place
  • Log evaluation process for detecting anomalous events
Respond
  • Readiness level of defensive cyber operation trained team (e.g. similar to Disaster Recovery/Continuity of Operations)
Reconstitute
  • Backups available to install/resume system operation

As shown in Table 2.4, simple yes/no questions, or percentage of satisfaction for standard questions about precautions taken to secure a cyber system, provide the initial “scenarios,” or use cases, to evaluate systems for secure cyber operation. Varying the use cases, to capture the scope of the issue at hand, however, can rapidly become more complicated. Ideally, use cases provide “outer bounds” for the respective system conditions, giving the evaluator an example of system performance at these respective boundaries.

2.2.2 Use Cases/Scenarios

Frameworks, designed for assessing actual systems, give the modeler an understanding of the current system structure, and provides context to describe system behavior. Use cases and/or scenarios are used to show strengths, weaknesses, and performance scaling of the system of interest over its scope of implementation. These use cases could be chosen from any of the people, policy, process, or technology system domains, or their respective combinations, where there is a perceived weakness to be tested against. In addition, specific threat behavior might be modeled to determine our system’s attack susceptibility.

Using modeling and simulation to develop real‐world cyber scenarios, scenarios that incorporate both the scope and scale of networks “in the wild,” includes technologies and configurations that can easily span multiple generations of information technology. It is a challenge to measure risk in these complex systems, where a clear and accurate inventory of the technologies in defended systems is absent. One approach is to inventory a system of interest and compare component‐level system descriptions with well‐known weaknesses and vulnerabilities (Table 2.5) in order to develop in‐depth assessments.

Table 2.5 Standard security description references.

Name Description Link
Common Vulnerabilities and Exposures (CVE) Contains the list of known information security vulnerabilities and exposures. https://cve.mitre.org/
National Vulnerability Database (NVD) Based on CVE dictionary, NVD is the basis for constructing of attack graphs via known vulnerabilities. https://nvd.nist.gov/
Common Vulnerability Scoring System (CVSS) Open and standardized vulnerability scoring system. https://nvd.nist.gov/vuln‐metrics/cvss
Common Weakness Enumeration (CWE) Contains a unified, measurable set of software weaknesses. Usage of the database of weaknesses can improve the quality of the zero‐day‐based attack graph generator module. https://cwe.mitre.org/
Common Platform Enumeration (CPE) Provides a unified description language for information technology systems, platforms, and packages. https://scap.nist.gov/specifications/cpe/
Common Configuration Enumeration (CCE) Gives common identifiers to system configuration issues. https://nvd.nist.gov/config/cce/index
Common Attack Pattern Enumeration and Classification (CAPEC) Helps to capture and use the attacker’s perspective. Usage of attack patterns allows applying sequences of known and zero‐day vulnerabilities in one attack action. https://capec.mitre.org/
Common Remediation Enumeration (CRE) Defines a security‐related set of actions that result in a change to a computer’s configuration. https://scap.nist.gov/specifications/cre/
Repository of Industrial Security Incidents (RISI) RISI, a database of industrial controls anomalies, was developed to share data across the research community to prevent future cyber anomalies on operational technology http://www.risidata.com/About

Security analysis leveraging Table 2.5’s databases is used by tools (e.g. CAULDRON [Jajodia et al. 2015]) to prioritize system updates, thereby increasing overall resilience.

2.3 Cyber Insurance Approaches

In 2015, the Lloyd’s of London study, “Business Blackout,” (Maynard and Beecroft 2015) showed a potential 93 million Americans, across 10 states and the District of Columbia, without power due to a cyberattack; costing an estimated $243 billion; $1 trillion in the most stressing scenario (Figure 2.3).

Photo depicting business blackout due to US east coast grid compromise.

Figure 2.3 Business blackout due to US east coast grid compromise (Maynard and Beecroft 2015).

One reason to look at insurance analyses is because insurers necessarily deal with the “as is,” real, world, where clients want to transfer their cyber risk through an insurance policy. Reading the appendices of “Business Blackout” (Maynard and Beecroft 2015), there was noticeable variety in

  • Countries attacked
  • Facilities attacked
  • Types of attackers
  • Attacker technologies
  • Attack effects

In addition, “Business Blackout” provides a picture that almost any vulnerability is liable to be exploited – a wake‐up call as to what is possible. Expanding on insurance modeling as a template for describing cyber risk, Bohme and Schwartz (2010) provide an excellent background of cyber insurance literature and define a unified model of cyber insurance (i.e. cyber risk description) that consists of five components:

  • the networked environment
  • demand side
  • supply side
  • information structure
  • organizational environment

First, the network topology plays a key role in affecting both security dependencies and failure correlations. For example, independent computers versus a fully connected computing network, two topology extremes, will result in vastly different security assessment and implementation challenges. In addition, system impacts will look very different, should a successful attack occur.

An additional insurance consideration includes using models of the defended network, potential impact, and defense cost estimates for both resilience and potential asset loss.3 One challenge is for cyber insurance companies to price their offerings. Pricing can correlate to risk (Black and Scholes 1973), providing a view as to how well an insurance company believes it understands cyber risk. A recent study (Sasha Romanosky) looks at how insurers do business by evaluating several policies to see how companies evaluate risk. In regard to pricing, or rate schedules, there is a surprising variation in the sophistication of the equations and metrics used to price premiums. Many of the policies examined used a very simple, flat rate pricing (based simply on expected loss), while other policies use more parameters, such as the firm’s asset value (or firm revenue), or standard insurance metrics (e.g. limits, retention, and coinsurance), and industry type. More sophisticated policies include specific information security controls and practices as collected from the security questionnaires.

The seemingly capricious pricing model of cyber insurance is partially due to the seemingly random demand signal that current cyberattacks provide. We are in a new era, with nefarious cyber actors ranging from States to anonymous hackers, where the loss process that an insurance company constructs can only really be based on the business process value at risk4 (Sasha Romanosky).

2.3.1 An Introduction to Loss Estimate and Rate Evaluation for Cyber

In performing quantitative risk assessment, insurance companies often use some form of an a single security incident, with the annualized loss expectancy (ALE) to justify the cost of implementing countermeasures to protect an asset. This may be calculated by multiplying the single loss expectancy (SLE), which is the loss of value based on a single security incident, with the annualized rate of occurrence (ARO), which is an estimate of how often a threat would be successful in exploiting a vulnerability (Equation 2.1).

images

Equation 2.1: Annualized loss expectancy

In addition to traditional insurance assessment approaches, the FAIR model is an international standard5 for computing value at risk, and is a practical framework for understanding, measuring, and assessing information risk, enabling well‐informed decision making. In addition, the FAIR model is supported by a tool (i.e. Risk Lens) and a community for quantifying and managing cyber risk. In addition to the FAIR model, Douglas Hubbard’s “How to measure anything in cyber security risk” (Hubbard et al. 2016) provides background on cyber measurement approaches, along computer‐based approaches,6 for demystifying cyber issues.

2.4 Conclusions

Insurance modeling is used here to provide a baseline for the “as is” of cyber security assessment. While assessments will leverage standard frameworks (e.g. NIST CSF) and risk evaluation approaches (e.g. ISO 31000 based), their goal of estimating system cyber resilience is the same. Leveraging maturity models is used to determine defensive capability across the respective lines of effort, providing a comprehensive approach for understanding an organization’s current cyber security posture.

2.5 Future Work

In addition to the assessment frameworks and tools reviewed here, DoDAF architecture frameworks are an additional tool for documenting systems for cyber security evaluation (Hamilton, 2013; Richards 2014). Leveraging system understanding, through DoDAF architectures, along with threat evaluation, was recently done in a US Air Force system assessment approach (Jabbour and Poisson 2016).

2.6 Questions

  1. 1 Should an organization approach cyber risk, and subsequent insurance, with a different strategy than it approaches standard property and casualty (P&C) and other insurable business risk?
  2. 2 How is cyber risk transferred, now?
  3. 3 How much of cyber risk is usually accepted (vice transferred) by most organizations now?
  4. 4 When would a great resilience process provide a bad assessment?

Notes

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.117.152.251