Cyber Resiliency Metrics & Assessment

Track Outbrief, 1 June 2012

Desired Outcomes

• List of topics on which we have consensus• List of topics for which we have proposed alternatives

• List of hard problems needing more work to understand the underlying issues to achieve eventual consensus

• A plan to move forward

Topics on Which We Have Consensus (1 of 2)

• Metrics: Quantitative or qualitative? Both!• General process can be drawn from security domain• Need a broad scope – resilience is not just a system 

property– Organization, mission / business process, network / system, 

information• Goal‐question‐metric approach applies – but need to know 

whose goal, whose questions• Metrics need to be justified

– How much does it cost to gather the metric? What does evaluation entail?

– What’s the value of the metric? Does the metric provide value?– What kind of behavior are you trying to drive?

Topics on Which We Have Consensus (2 of 2)

• Need to address multiple stakeholders– Mission / business process owners / executives– Architects & systems engineers– Resource owners (with very strong concern for cost & ROI)

– Cyber defenders and system/network operators• Scenario / use case driven approach can provide a means– To engage & broker communications among different stakeholders

– To motivate the definition of metrics 

Topics for Which We Have Identified Resources 

• Metrics process (Practical Measurement Framework for Software Assurance and Information Security)

• Operational Resilience Management Model (RMM) and measurement approach (CMU)

• Adversary modeling (MIT/LL / Firemon & other commercial tools, MIT/LL, Raytheon)

• Work on characterizing resiliency and metrics (JHU/APL)

• Use case‐driven analytic approach (MORS 2006 RIST presentation)

[References to be included in workshop report]

Overlay of Resources on Use Case‐Driven Analytic Approach

Campaign

Mission

Engagement

Engineering

Science / Empirical 

Evidence and Theories

Databases

Scenarios

Intelligence

Consider blue for losses –MOEs apply here

Many‐on‐many – issue of lack of capacity, need for 

prioritization

Consider One‐on‐one engagement with adversary

Instantiate in form of design

Decision Support Products

Consider opposing designs

Metrics at higher levels:• MOE• MOP• TPM

MIT/LL MIT/LL

RMM

Security Controls

Security metrics• Raytheon• JHU/APL• MITRE 

Resiliency Metrics

Questions to Drive Metric Definition(Defining Metrics in the Context of a Set of Scenarios)

• Campaign• Mission / cyber support element of mission

– What is critical for the mission to be performed? (mission‐critical, mission‐essential) (how to represent dynamically, how to account for non‐cyber support)

– What if the mission is subverted? What is the mission impact of subversion of cyber support elements? (integrity / accountability)

– What if mission cannot be performed? What is the mission impact of loss or degradation of capacity for a given time? (availability / quality of service)

– What if results of cyber support elements of missions cannot be trusted? (integrity)

– In the context of the scenarios, what are the mission impacts of the adversary knowing specific information? How does this affect future mission capability? (confidentiality)

– How can cost / benefits / ROI be represented in the scenarios / model? 

[Issue for cyber: We don’t have good models for synergistic or multiple attacks]

Cyber metrics must be linked to mission MOEs, MOPs … and thus to contingency planningCan also be related to cost to mission –impact includes cost

Set of scenarios should reflect different adversary motivations:• Deny• Degrade• Destroy• Disrupt• Usurp

Questions to Drive Metric Definition• Engagement (one attack at a time)

– Damage assessment: • How far has the adversary gotten? • What damage has occurred, and how bad is it? • If the damage occurred in the past, how can we discover / account for it?

– Recovery:• How well do we understand what constitutes a good state? How do we assess trust? How confident are we in our assessment of trust?

• How quickly can we restore to a known good state?• Engineering

– How well have we implemented a specific resilience technique? Or, for a to‐be architecture, how well could we? (properties)

– How well have we defined courses of action, standard operating procedures, defender TTPs, etc., 

• To take advantage of engineered‐in techniques?• To compensate for weaknesses?

– How effective is our implementation? (performance)• Science

Hard Problems (1 of 3)• What metrics can help system operators optimize the 

mixture of resilience courses of action?• Metrics need to support mission decisions. In what ways 

can we map cyber resources to missions, so that we can link cyber resilience metrics to mission MOEs/MOPs? 

• How do we quantify cyber as a source of risk to mission?– How do we account for scenarios in which we don’t see 

immediate mission effects (e.g., exfiltration)?– Which impacts should be considered first, in posing questions to 

be answered using metrics?• Immediate vs. long‐term vs. potential? • Focus on availability, or include integrity & confidentiality?

• Scenarios provide a motivation for defining metrics. What should we include in adversary scenarios?– Can we take supply chain off the table for initial analysis?– How do we account for non‐owned assets?

Hard Problems (2 of 2)• How do we assess costs?

– Costs of what? • Implementing resiliency techniques / solutions (including remediation)

• Not implementing resiliency techniques / solutions • Sustainment

– How to represent costs to different stakeholders?– How to represent different types of costs?– Can we perform some sort of retrospective assessment of 

costs?• How do we account for uncertainty

– In our models?– In our data?

• How do we validate & verify our approach? Our metrics?– What is a large enough sample size?

Hard Problems (3 of 3)• How do we know that / to what extent the system is trustworthy? – How do we define a baseline?– How do we measure change? Particularly given the constant change in our systems?

• How can we leverage work in big data?– What data is big?

• Sensor data, fused or correlated• Historical data about system behavior

– How do we address privacy problems?– How do we address prediction challenges?

• How do we define the boundaries / contexts? How do we know whether we’ve defined them properly?– Some things will be invisible if we define the context improperly?

Way Forward• Workshop report

– Share with this community– Socialize more broadly

• Write articles for ACM and IEEE departments, as a common touchpoint for future participants – based on workshop report

• Workshop outbriefs• On‐line sharing venue for us to continue our discussions• Build connections with OR community – particularly with 

metrics group• MITRE to revise Metrics paper

• dbodeau@mitre.org bartol_nadya@bah.com

BACKUP

AgendaJune 1, 2012

Start Length Topic Plan7:45 0:15 Pastries & Coffee

8:00 1:45 Breakout for tracks

8-8:15 – Introduction / Plan8:15-8:45 – Level-setting – what can we agree on or understand our points of disagreement8:45-9:45 – Panel – experience & lessons-learned

9:45 0:30 BREAK

10:15 1:45 Breakout for tracks

10:15-10:45 – Discuss and validate initial topics / questions / hypotheses10:45-12 – Answer initial topics and identify really hard problems

12:00 1:00 LUNCH

13:00 1:30 Breakout for tracks 1-2 – Discuss hard problems2-2:30 – Way-ahead planning

14:30 0:15 BREAK14:45 0:50 Readouts and Closing Comments

Presentations & Responses

Response to Panel: Nadya Bartol• Group resonates with general process from Practical Measurement Framework for Software Assurance and Information Security – Works as long as feedback is considered– Need methods to ensure we have the data we need to evaluate metrics

• Tools, processes, and thus data– What they say they need and what they actually use are two different things

• Process must change as needs and values change• Framework team needs to provide us with measurable controls, requirements, or objectives

Response to Panel: Nadya Bartol• Need to articulate the questions stakeholders need answers to, e.g.,– How do I know I need to restore?– What should I expect in a given set of circumstances? In particular, will the mission be accomplished?

• Are we doing measurement for assessment or for prediction? – If for assessment, don’t need to know distribution over time

– If for prediction, need a prediction model –• Raytheon, MIT/LL work on attack‐based measurement• Framework group needs to work on this

– Could use the same data for prediction & assessment

Response to Panel: Nadya Bartol

• Success factors generally reasonable, but are more managerially‐oriented– Long‐term management commitment– Common vocabulary– Realistic data collection

• Need to inform automated processes

Response to Panel: Julia Allen• Types of measures: implementation, effectiveness, performance 

measures – Effectiveness measures are most important– In security we do a lot for implementation measures, very little for 

effectiveness• We don’t have the underlying science – in the absence of good 

understanding, don’t have good choices to do anything / manage risk

• Example of questions metrics can answer– What does defense‐in‐depth mean? How deep do we need to go? 

How many levels?• Would like a reference model for metrics that are indifferent to 

specific environment – but when metric is applied in context, need to take context into consideration

• CERT looking at two measures – time to restore & effort to restore

Panel: Roberta EwartRequirements

Campaign

Mission

Engagement

Engineering

Science

Databases

Scenarios

Intelligence

Consider blue for losses –MOEs apply here

Many‐on‐many – issue of lack of capacity, need for 

prioritization

Consider One‐on‐one engagement with adversary

Instantiate in form of design

Decision Support Products

Consider opposing designs

Metrics:MOEMOPTPM

Concept

$

Pareto efficient frontier – when not smooth, need R&D / S&T to fill gaps

General process for DoD M&S tools – rather than space threats, can consider cyber threats

POM

Response to Panel: Roberta Ewart

• Need to generate positive upward spiral for decision support tools

• Applies to most but not all stakeholders– Takes an engineer to translate into scientific / researcher terms

– Mission folks think in terms of MOE, MOP, TPM– Get OR folks down to mission/engagement level, and engineers/scientists up to that level

Response to Panel: Roberta Ewart• What if we don’t have the science or engineering?

– Start at engagement level, use that to drive development of engineering, identification of gaps to be filled by science

– Terrestrial networks share many of the problems our space networks have– However, software engineering is less mature than the hardware engineering of space systems –

engagement level can drive questions for science & engineering. Do measurement to understand who’s attacking, what the nature of the attack is; use measurement to answer what are the minimum sets of capabilities we need to continue to function?

– If you don’t have scenarios, don’t have data to propagate up to higher layers• Nadya: MIT/LL work on attack‐based / CAG can serve as starting point for scenarios

– “We’ve completely lost the bubble on complexity”• In cyber world, we have so many unknowns• If you can write down a few behaviors / rules, you can handle large size

– System effectiveness analysis simulation / brawler• Scenario‐based approach is very appealing. 

– Have distinction between scenarios in which something is attacked vs. those in which something is attacked in a specific way. Top‐down scenarios require us to have global metrics.

– We have some of this already– We haven’t made links well between damage to cyber and effects on missions / people – haven’t invested in 

representation of impacts• Problem of mirroring – hard not to model blue‐on‐blue• Applicable to critical infrastructure – if not dealing with nation‐state adversary, may be able to omit 

the campaign layer

MIT/LL – Firemon• Key assumption: 

– Work with known vulnerabilities / exploits – Have an architecture that includes a DMZ, firewall with router running ACLs, proxy with CMS

• Tool will– Enumerate enclaves, IP addresses– Based on knowledge of configuration + vulnerabilities, exploits

• Calculate active vector or point of entry into system– Least path of resistance

• Show escalation, to reach targets within enterprise• Department of State using this to prioritize resources for remediation

MIT/LL Research on Attacker Scenarios 

• 15 scenarios• What does an organization need, at the engineering level? – What must the architecture include? – How should capabilities be used? E.g., scanning frequency, scanning coverage

Critical Questions

• How do we map cyber resources to missions? How do we include cyber as a source of risk to mission?– And how do we account for scenarios in which we don’t see immediate mission effects (e.g., exfiltration)?

– Which impacts should be considered – immediate vs. long‐term vs. potential? Focus on availability, or include integrity & confidentiality?

• What should we include in adversary scenarios?– Can we take supply chain off the table for initial analysis?– How do we account for non‐owned assets?

Scenario‐Driven or Use Case‐Driven Metrics

• Identify full range of stakeholders– Mission owners / end users, …– Include adversary as a stakeholder / player

• Define multiple scenarios / use cases

Questions Related to Cost

• How to represent costs to different stakeholders?

• How to represent different types of costs?• Can we perform some sort of retrospective assessment of costs?

Process• Set the stage

– What are general principles of resiliency measurement? – What topics should be included in our discussion?  – Where do we agree?  – Where do we disagree?

• Share experiences and lessons‐learned• Refine of initial set of topics/hypotheses• Discuss identified topics/hypothesis and:

– Develop consensus– Identify alternatives that need further discussion– Define hard problems that need further research

• Plan for way ahead 

Key Questions for Resilience Metrics

• How can we tell how resilient something (e.g., a system) is?

• What’s the quality of the decisions users of the system make?

Set the Stage: General Principles

• Resiliency: Do we need to agree on a definition in order to define metrics?

• No

Set the Stage Discussion: Questions Related to Metrics

• Quantitative or qualitative? Both!• What are they for? Decision support• Who are they for? Many different stakeholders can be 

identified. Top categories:– Operators – from end users to mission commanders– Architects & systems engineers – throughout the life‐cycle– Resource managers – follow the moneyWhere should we start? Who needs resiliency metrics soonest?

• How much does it cost to gather the metric? What does evaluation entail?

• What’s the value of the metric? Does the metric provide value?

• What kind of behavior are you trying to drive?• Is there some delta from security metrics?

• Scope: organization, process, mission, systems• Goal for this team: List of hard problems for future research or pilot efforts – burning needs are for these questions

Very Basic Process

1. What are the bad things that can happen2. How can those bad things be mitigated

1. Specific actions2. Generic categories of actions3. Are they different from security controls, how, what 

is similar3. What do the stakeholders need to know about 

their ability to understand these generic bad things

4. How do we measure these things?  What are the operation limits, e.g., thresholds?

Thought from Yesterday

• Assets to be protected can be organized in a stack

• Layers in a stack interact and impact each other

• Does this tell is anything about how metrics should be structured to have as little duplication as possible?

Metrics

Understanding

DecisionMaking

Compliance Checking

AssessingCost

UsesStakeholders

…

Mission Commander

Program Manager

CyberDefender

Vendor

…

Researcher

Technical Operational

Cost

Performance

35Approved for Public Release: 12‐2397. Distribution Unlimited

Metrics can be characterized in multiple ways …

Page  36

Metric Users

Mission commanders (or business function heads).  Cyber defenders. Officials responsible for mission continuity, business continuity, or contingency planning.   Senior IT/ICT providers (e.g., the manager of a data center which provides resources to multiple missions or users, the 

provider of a common infrastructure such as a network or of a set of shared services such as identity management). Senior information security or information assurance (IA) staff (e.g., Chief Information Security Officer).  Program managers (as informed by systems engineers and architects).  Architects and systems engineers  Researchers.  Product vendors and solutions providers.

Uses Support decisions – operational, engineering, cost Improve understanding

Notional Layers 

Notional layers include: Organization Mission or Line of Business  Mission or Business Process Support for Mission Task or Capability – e.g., 

System‐of‐systems Network System, Service or application

Information Asset – e.g., data store, message, data item Node – e.g., computing platform

Approved for Public Release. Distribution unlimited. Case # 12‐2226.

• How closely do cyber resiliency metrics relate to mission metrics?– What mission metrics are most meaningful & useful?

– How do cyber resiliency metrics relate to risk? How can they inform intelligent risk‐taking on the part of mission owners / business process owners?

Additional questions

Page  37

Some Possible Examples – are these good, useable, cost‐effective, feasible?

Examples of Metrics

% systems properly configured / hardened# attempted intrusions deflected to a honeypot% mission‐essential capabilities for which two or more different instantiations are availableTime between initial disruption and availability (at minimum level of acceptability) of mission‐essential functions% data value assertions in a mission‐essential data store for which two or more  different data feeds are available% mission‐essential functions for which a procedural work‐around is availableTime between initial adversary act and its detection% degradation of mission‐essential functions

Planning to Move Forward• What is the desired level of participation / review by participants in 

the conference report?• How do we continue discussion (e.g., move to agreement on 

additional topics)?– E.g., email, series of conference calls, follow‐on workshop

• What opportunities do we have for information sharing and collaboration?

• What synergies or dependencies exist among activities in which we are engaged?

• How do we make the topics on which we agree actionable?– E.g., produce a NIST IR or other document on cyber resiliency metrics 

that• Captures lessons‐learned and recommendations• Identifies the hard problems

Panel

Discussion

Initial Set of Topics (1 of 2)• Purposes and intended uses of resiliency metrics

– What types of decisions should metrics inform (e.g., operational, engineering, research)?

– Who are the stakeholders for / intended users of metrics?– What do we want to find out from resiliency metrics?

• Are there any good examples, case studies, or lessons‐learned?

• Scope of resiliency metrics – Should metrics be defined for all aspects of cyber resiliency?– Should the scope of metrics be narrowed to a given domain 

(e.g., organization, network, mission / business process, system)? 

Initial Set of Topics (2 of 2)

• Focus of resiliency metrics – Should cyber resiliency metrics focus on processes, properties, or performance?

• Role of resiliency metrics in a metrics program– Should cyber resiliency metrics be viewed as (a special flavor of) security or performance metrics?

– How should data gathered and metrics evaluated for one purpose be repurposed for cyber resiliency?

– To what extent and how should resiliency metrics and risk metrics  be used in concert?

Is there anything else we should discuss today?

Hypotheses: Can We Provide Evidence to Confirm or Refute? Can We Identify Research Topics? (1 of 2)

• At the process level there is little difference between – Cyber security and cyber resiliency metrics– Cyber resiliency and performance metrics

• Cyber resiliency is well enough understood that rigorous / well‐founded metrics can be defined

• Cyber resiliency is in a sufficiently nascent stage that the focus needs to be on feasible‐to‐evaluate metrics that improve our understanding

Hypotheses: Can We Provide Evidence to Confirm or Refute? Can We Identify Research Topics? (2 of 2)

• How should cyber resiliency metrics be organized for maximum impact?– Defined for all aspects of resiliency– Defined for multiple domains (e.g., organization, network, mission / business process, system) 

• Cyber resiliency metrics should focus on– Process– Properties– Performance

Wrap Up and Next Steps

Planning to Move Forward• What is the desired level of participation / review by participants in 

the conference report?• How do we continue discussion (e.g., move to agreement on 

additional topics)?– E.g., email, series of conference calls, follow‐on workshop

• What opportunities do we have for information sharing and collaboration?

• What synergies or dependencies exist among activities in which we are engaged?

• How do we make the topics on which we agree actionable?– E.g., produce a NIST IR or other document on cyber resiliency metrics 

that• Captures lessons‐learned and recommendations• Identifies the hard problems

Backup