System Aware Cyber Security Architecture

Transcription

1 System Aware Cyber Security Architecture Rick A. Jones October, 2011

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 ASRR 10/11 October

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 ConfiguraAon Hopping Virtual ConfiguraAon Hopping Adversary SensiAve System ReconstrucAon AutomaAc Control Systems Data ConAnuity Checking via State EsAmaAon System IdenAficaAon TacAcal Forensics ASRR 10/11 October

4 System Aware Security Architecture Internal Controls Inputs System to be Protected Outputs Internal Measurements System-Aware Security Sub-System ASRR 10/11 October

5 System Aware Cyber Security Subsystem System-Aware Security Sub- System Measurements Measurement Analysis System to be Protected Hopping & Restoral Control System Control Signaling Security Control Decisions ASRR 10/11 October

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

7 System Aware Security for Facility Defense ASRR 10/11 October

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 ASRR 10/11 October

9 IllustraAve Architectural Diagram for Candidate Facility Defense System for System Aware Security 9

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 ASRR 10/11 October

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 ASRR 10/11 October

12 IllustraAve System Aware SoluAon Architecture 12

13 Observable Regions / User Fidelity Impacts of 3 Stream ConAnuous VoAng Max Possible # of Observable Regions No VoAng/Single Stream ConAnuous 3 Stream VoAng Stream Fidelity (Kbps) 13

14 Observable Regions / User Fidelity Impacts of 3 Stream ConAnuous VoAng Max Possible # of Observable Regions Loss in User PresentaAon Fidelity No VoAng/Single Stream ConAnuous 3 Stream VoAng Stream Fidelity (Kbps) 14

15 Observable Regions / User Fidelity Impacts of 3 Stream ConAnuous VoAng Max Possible # of Observable Regions ReducAon in Maximum Observable Regions No VoAng/Single Stream ConAnuous 3 Stream VoAng Stream Fidelity (Kbps) 15

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 ASRR 10/11 October

17 IllustraAve System Aware SoluAon Architecture with Duty Cycle VoAng 17

18 IllustraAve System Aware SoluAon Architecture with Duty Cycle VoAng 18

19 IllustraAve System Aware SoluAon Architecture with Duty Cycle VoAng 19

20 Duty Cycle VoAng for Increasing the Possible Number of Observable Regions User 1 User 2 Time Time User 3 Time Wireless Network Time Column Heights = Data / Time Interval 20

21 Observable Regions / User Fidelity Impacts of 3 Stream ConAnuous VoAng Max Possible # of Observable Regions No VoAng/Single Stream ConAnuous 3 Stream VoAng Duty Cycle VoAng Stream Fidelity (Kbps) 21

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 22

23 Scoring Framework 23

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 different 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 ASRR 10/11 October

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 ASRR 10/11 October

26 System Aware Security System Scoring Matrix RelaDve Value Weights k 1 k 2 k 3 k 4 k 5 k 6 k j Value Factors Security Services Diversity (s 1 ) Hopping (s 2 ) Data ConAnuity Checking (s 3 ) TacAcal Forensics (s 4 ) Deterrence Real Time Defense Collateral System Impacts RestoraDon ImplementaDon Cost Life Cycle Cost s 11 s 12 s 1j s 21 s 22 s 2j s 31 s 32 s 3j s 41 s 42 s 4j Other (s i ) s i1 s i2 s ij Other ASRR 10/11 October

27 System Aware Security System Scoring Matrix RelaDve Value Weights k 1 k 2 k 3 k 4 k 5 k 6 k j Value Factors Security Services Diversity (s 1 ) Hopping (s 2 ) Data ConAnuity Checking (s 3 ) TacAcal Forensics (s 4 ) Deterrence Real Time Defense Collateral System Impacts RestoraDon ImplementaDon Cost Life Cycle Cost s 11 s 12 s 1j s 21 s 22 j= 1 s 2j s ij = Assurance Level of s 31 s 32 the ith service as s 3j related to the jth value factor s ij = QuanAzed Assurance Level = 0 M s 41 s p n 42 s 4j Security = k j s ij Score j= 1 i= 1 Other (s i ) s i1 s i2 Max Possible Score = n x M s ij p k j = 1 Other ASRR 10/11 October

28 Example Facility Defense Scoring Matrix RelaDve Value Weights K 1 =0.30 K 2 = 0.20 k 3 =0.10 K 4 = 0.20 K 5 = 0.05 K 6 = 0.15 Value Factors Security Services Diversity (s 1 ) Hopping (s 2 ) Data ConAnuity Checking (s 3 ) TacAcal Forensics (s 4 ) Deterrence Real Time Defense Collateral System Impacts RestoraDon ImplementaDon Cost Max Possible Score = 20 Facility Defense Score = 11.5 Life Cycle Cost Strongest Area is RestoraAon Weakest Area is Life Cycle Cost 28

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 Tradeoffs between scoring simplicity and transparency of results ASRR 10/11 October

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 Specific claims about value factors and the anacipated effects of security services on these factors ExplanaAons of how each security service is anacipated to impact specific value factor claims, including explicitly dividing each service into policy, process, and technology components with corresponding explanaaons of value 30

31 Simplified 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 See later slide Context Risk analysis and scoring guidelines Scoring Assignment Strategy UAlize experts to score service claims with accompanying raaonale Forensics Service Claim Hopping Service Claim 31

32 Simplified DiagrammaAc RepresentaAon of a Structured Argument for Deterrence Scoring (2) Data ConDnuity Service Claim (1) ExploitaAon design requires distributed exploit designers Data ConDnuity Service Claim Improves deterrence Data ConDnuity Service Claim (2) ExploitaAon design requires designers with deep systems knowledge.. Data ConDnuity Service Claim (n) 32

33 Simplified DiagrammaAc RepresentaAon of a Structured Argument for Deterrence Scoring (3) Data ConDnuity Service Claim (1) ExploitaAon design requires distributed exploit designers Red Team Evidence Document Data ConDnuity Service Claim Improves deterrence System Design Team Evidence Document Intelligence Analysis Evidence Document 33

34 Simplified DiagrammaAc RepresentaAon of a Structured Argument for Deterrence Scoring (4) Data ConDnuity Service Claim Improves deterrence Data ConDnuity Service Claim (2) ExploitaAon design requires designers with deep systems knowledge System Design Team Evidence Document 34