System Aware Cyber Security Architecture

(1)

System‐Aware Cyber Security

Architecture

Rick A. Jones

(2)

Research Topic DescripAon

• System‐Aware Cyber Security Architecture

–

 

Addresses supply chain and insider threats

–

 

Embedded into the system to be protected

–

 

Includes physical systems as well as informaAon systems

• Requires system engineering support tools for

evaluaAng architectures factors

• To facilitate reusability requires establishment of

candidate Design PaMern Templates and iniAaAon of

a design library

–

 

Security Design

–

 

System Impact Analyses

2 ASRR 10/11 October 2011

(3)

IncorporaAng

Recognized Security FuncAons into an

Integrated System‐Aware Security SoluAon

• Fault‐Tolerance

–  Diverse ImplementaAons of Common FuncAons

–  Data ConAnuity Checking via VoAng

• Cyber Security

–  Moving Target with Diversity

•  Physical ConﬁguraAon Hopping

•  Virtual ConﬁguraAon Hopping

–  Adversary‐SensiAve System ReconstrucAon

• AutomaAc Control Systems

–  Data ConAnuity Checking via State EsAmaAon

–  System IdenAﬁcaAon •  TacAcal Forensics

(4)

System‐Aware Security Architecture

System to be Protected

Inputs _Outputs

Internal Measurements System-Aware

Security Sub-System Internal Controls

(5)

System‐Aware Cyber Security Subsystem

System-Aware Security

Sub-System

System Control Signaling Measurement

Analysis

Security Control Decisions Measurements

System to be

Protected

Hopping & Restoral

(6)

System‐Aware Security Analysis

6 ASRR 10/11 October 2011 Mission-Risk Ranked System Functions (1) (2) (3) (4) … (N) Selected set for hopping Number of hopped functions System Latency Delay in compromise detection Mission Risk Rate of hopping System Latency

(7)

System‐Aware Security for

Facility Defense

(8)

Facility Defense System to be Secured

• We consider a facility defense system

consisAng of:

–

 

Streaming sensors conAnuously monitoring

discrete areas

–

 

Streaming Servers distribuAng sensor data,

received over a wired network, to mobile users

over a wireless broadcast network

–

 

Mobile users receiving alerts and streaming data

regarding potenAal problems

(9)

IllustraAve Architectural Diagram for Candidate Facility

Defense System for System‐Aware Security

(10)

PotenAal Cyber AMacks

• Replay aMacks masking malicious acAvity iniAated

through

–

 

Sensor system

–

 

Streaming servers

–

 

User devices

• DoS aMacks addressed through redundancy

–

 

Sensor system

–

 

Streaming servers

–

 

OperaAonal procedures and redundancy regarding user

devices

(11)

System‐Aware SoluAon for Securing

the Facility Defense System

• Replay aMack defense

–  Diversely Redundant Streaming Sensors, with VoAng (Data ConAnuity Checking)

–  Diversely Redundant, Virtually Hopped Streaming Servers

–  Diverse User Devices, with RotaAng User Surveillance Assignments and Device Use

–  Mobile User based Data ConAnuity Checking

• DoS defense

–  Redundancy at the Sensor and Streaming server levels

–  Streaming servers / User feed back loops to enable redistribuAon of data and job responsibiliAes

(12)

IllustraAve System‐Aware SoluAon Architecture

(13)

0 10 20 30 40 50 60 70 80 90 100

100 150 200 250 500

Max Possible # of Observable Regions

Stream Fidelity (Kbps)

No VoAng/Single Stream ConAnuous 3 Stream VoAng

Observable Regions / User Fidelity Impacts of 3

Stream ConAnuous VoAng

(14)

0 10 20 30 40 50 60 70 80 90 100

100 150 200 250 500

Observable Regions / User Fidelity Impacts of 3

Stream ConAnuous VoAng

Loss in User PresentaAon Fidelity

(15)

0 10 20 30 40 50 60 70 80 90 100

100 150 200 250 500

Observable Regions / User Fidelity Impacts of 3

Stream ConAnuous VoAng

ReducAon in Maximum Observable Regions

(16)

Duty Cycle VoAng for Increasing the Possible

Number of Observable Regions

• Concept – Use of Ame division for voAng permits an increase

in the number of possible surveillance points

–  User compares streams concurrently received from mulAple diversely redundant servers to discover disconAnuiAes

–  3 parameters can be uAlized to govern voAng

•  Number of Observed Regions

•  Deemed acceptable VoAng Interval for data conAnuity checking

across all regions

•  Streaming period Ame alloMed for conAnuity checking (VoAng

Time), which can be less than the VoAng Interval

–  Given the VoAng Time can be a subset of the VoAng Interval, the use of Ame division can be uAlized to manage informaAon distribuAon over the broadcast network, interleaving mulAple streams for voAng users with single streams for other users who are not voAng

(17)

IllustraAve System‐Aware SoluAon Architecture with

Duty Cycle VoAng

(18)

IllustraAve System‐Aware SoluAon Architecture with

Duty Cycle VoAng

(19)

IllustraAve System‐Aware SoluAon Architecture with

Duty Cycle VoAng

(20)

Duty Cycle VoAng for Increasing the Possible

Number of Observable Regions

User 3

Time

Wireless Network

Time

User 2 User 1

Column Heights = Data / Time Interval

(21)

Observable Regions / User Fidelity Impacts of 3 Stream

ConAnuous VoAng

0 10 20 30 40 50 60 70 80 90 100

100 150 200 250 500

No VoAng/Single Stream ConAnuous 3 Stream VoAng Duty Cycle VoAng

(22)

AddiAonal Collateral System Impacts

• Common Cause Failures are reduced

• MTBF increases in relaAonship to the individual diverse

component reliabiliAes

• Development cost increases based on the cost to develop

voAng and duty cycle management components, as well as to

resolve lower level technical issues that may arise

–  SynchronizaAon needs

–  Sohware integraAon

–  Performance impact measurements and enhancement needs (e.g. CPU uAlizaAon, memory, and energy usage)

• One Ame and life cycle cost increase in relaAonship to the

increased complexity

(23)

Scoring Framework

(24)

Need: Methodology for EvaluaAng AlternaAve Security

SoluAons for a ParAcular System

• A methodology is required in order to clarify

reasoning and prioriAzaAons regarding unavoidable

cyber security vagaries:

–

 

RelaAonships between soluAons and adversarial responses

–

 

MulAdimensional contribuAons of individual security

services to complex aMributes, such as deterrence

• Scores can be derived in many diﬀerent forms

–

 

Single scalar value where bigger is beMer

–

 

2 scalar values: (1) security value added, (2) system‐level

disvalues

–

 

MulA‐objecAve component scores providing more

transparency

(25)

Metrics

• AMack phase‐based security value factors:

–

 

Pre‐AMack (Deterrence)

–

 

Trans‐AMack (Defense)

–

 

Post‐AMack (RestoraAon)

• Would include collateral system impact

metrics for the security architecture:

• Performance

• Reliability, Safety

• Complexity, Costs

(26)

ASRR 10/11 October 2011 26

System‐Aware Security System Scoring Matrix

Value

Factors Deterrence Time Real Defense

Restor‐

aDon Collateral System Impacts

Implemen‐

taDon Cost Cycle Life Cost

Other Security

Services

Diversity

(s₁) s11 s12 s1j

Hopping

(s₂) s21 s22 s2j

Data ConAnuity

Checking (s₃)

s₃₁ s₃₂ s_3j

TacAcal Forensics

(s₄)

s₄₁ s₄₂ s_4j

Other (s_i) s_i1 s_i2 s_ij

RelaDve Value Weights

(27)

ASRR 10/11 October 2011 27

System‐Aware Security System Scoring Matrix

Value

Restor‐

Implemen‐

taDon Cost Cycle Life Cost

Other Security

Services

Diversity

(s₁) s11 s12 s1j

Hopping

(s₂) s21 s22 s2j

Data ConAnuity

Checking (s₃)

s₃₁ s₃₂ s_3j

TacAcal Forensics

(s₄)

s₄₁ s₄₂ s_4j

Other (s_i) s_i1 s_i2 s_ij

k₁ k ₂ k ₃ k ₄ k ₅ k ₆ k _j

s_ij = Assurance Level of the ith service as related to the jth value factor

∑∑

= = = p j n i ij js k 1 1

s_ij = QuanAzed Assurance Level = 0…M

∑

= = p j j k 1 1 Security Score Max Possible Score = n x M

(28)

28

Example Facility Defense Scoring Matrix

Value

Restor‐

Implemen‐

taDon Cost Cycle Life Cost Security

Services

Diversity

(s₁) 4 3 4 4 2 2

Hopping

(s₂) 3 4 3 1 2 3

Data ConAnuity

Checking (s₃)

2 4 3 1 4 3

TacAcal Forensics

(s₄)

3 0 4 5 4 2

K₁=0.30 K₂= 0.20 k₃=0.10 K₄= 0.20 K₅= 0.05 K₆= 0.15

(29)

On Going ExploraAon

• A pracAcal methodology for determining Assurance

Level Values

• Methodology for addressing uncertainty in assigning

Assurance Level Values

• Methodology for uAlizing RelaAve Value Weights

• Tradeoﬀs between scoring simplicity and

transparency of results

(30)

Structured Arguments for System Scoring

•  Builds upon the legacy of work developed for safety and informaAon assurance case evaluaAons

•  UAlizes Goal Structuring NotaAon (GSN) for communicaAng

arguments to support assigned scores in a repeatable and clear manner

•  System‐Aware security scoring arguments for a parAcular system architecture include:

–  Context supplied by the system owner and includes an available risk

analysis for the system being protected and scoring guidelines

–  System supplier provides the list of security services to be applied and

characterizes the purposes expected of security services that are deemed as most perAnent to reducing risk

•  Speciﬁc claims about value factors and the anAcipated eﬀects of security

services on these factors

•  ExplanaAons of how each security service is anAcipated to impact speciﬁc

value factor claims, including explicitly dividing each service into policy, process, and technology components with corresponding explanaAons of

(31)

Simpliﬁed DiagrammaAc RepresentaAon of a

Structured Argument for Deterrence Scoring (1)

Architectural Deterrence Claim Assigned suitable scores for deterrence Service SelecDon Strategy Decompose the Architecture to isolate, for the purposes of scoring, security services that address deterrence Data ConDnuity Service Claim Improves deterrence Diversity Service Claim Forensics Service Claim Hopping Service Claim See later slide Scoring Assignment Strategy UAlize experts to score service claims with accompanying raAonale Context Risk analysis and scoring guidelines 31

(32)

Simpliﬁed DiagrammaAc RepresentaAon of a

Structured Argument for Deterrence Scoring (2)

Data ConDnuity Service Claim

Improves deterrence

Data ConDnuity Service Claim (1)

ExploitaAon design requires distributed

exploit designers

ExploitaAon design requires designers with deep systems

knowledge

Data ConDnuity Service Claim (n)

…..

(33)

Simpliﬁed DiagrammaAc RepresentaAon of a

Structured Argument for Deterrence Scoring (3)

Improves deterrence

ExploitaAon design requires distributed

exploit designers

Red Team Evidence Document

System Design Team Evidence Document

Intelligence Analysis Evidence Document

(34)

Simpliﬁed DiagrammaAc RepresentaAon of a

Structured Argument for Deterrence Scoring (4)

Improves deterrence

ExploitaAon design requires designers with deep systems

knowledge

System Design Team Evidence Document