Secure Mission-Centric Operations in Cloud Computing

Transcription

1 Secure Mission-Centric Operations in Cloud Computing Massimiliano Albanese, Sushil Jajodia, Ravi Jhawar, Vincenzo Piuri George Mason University, USA Università degli Studi di Milano, Italy ARO Workshop on Cloud Security George Mason University, USA March 11-12, /39

2 Outline Motivation System overview Mission and Cloud infrastructure Mission deployment framework Secure mission deployment Static mission deployment Dynamic mission deployment Incremental vulnerability analysis Mission protection Dependability in the mission interpreter 2/39

3 Motivation (1) Cloud computing is becoming increasingly popular + Flexibility in obtaining and releasing computing resources + Lower entry and usage costs + Effective for applications with high scalability requirements Growing interest among users to leverage Cloud-based services to execute critical missions Exacerbate the need to ensure high security and availability of the system and the missions 3/39

4 Motivation (2) Cloud computing infrastructure is highly complex Vulnerable to various cyber-attacks Subject to a large number of failures Outside the control scope of the user s organization Existing solutions individually focus on the security of the infrastructure and the mission Do not take into account the interdependencies between them Techniques to securely operate missions in vulnerable Cloud environments are necessary 4/39

5 Secure Mission Deployment and Protection Deploy mission tasks such that their exposure to vulnerabilities in the infrastructure is minimum Static and dynamic versions of the problem Protect the hosts and network links used by the mission Static protection hardens all the resources for entire duration of mission execution Dynamic protection hardens resources corresponding to computation still to be executed Response to incidents 5/39

6 System Overview Mission A mission is a composition of a set of tasks M={τ 1,...,τ m } Replicate critical tasks to improve the fault tolerance and resilience of the mission A replicated task set for τ k is the set R k ={τ l k }={τ1 k,...,τ r k k } Mission is then a composition of all the tasks in the replicated task sets T = {t i } = τ k M R k R 1={τ 1 1, τ 2 1 } R 2={τ 1 2, τ 2 2, τ 3 2 } t 3 t 4 t 1 t 2 t 5 t 6 R 3={τ 1 3 } 6/39

7 System Overview Cloud Infrastructure h 12 h 13 h 14 h 15 Subnet 3 h 8 h 7 Router B Internet Router A Subnet 2 h 9 h 10 h 1 Subnet 1 h 6 h 11 h 2 h 3 h 4 h 5 Data center 1 Data center 2 7/39

8 System Overview Cloud Infrastructure h 12 h 13 h 14 h 15 t 1 t 2 Subnet 3 h 8 h 7 Router B Internet Router A Subnet 2 h 9 h 10 h 1 Subnet 1 h 6 h 11 h 2 h 3 h 4 h 5 Data center 1 Data center 2 Hosts may be vulnerable to various cyber-attacks (e.g., Subnet 1: compromised, Subnet 2: vulnerable, Subnet 3: highly secure) 7/39

9 System Overview Cloud Infrastructure h 12 h 13 h 14 h 15 t 1 t 2 Subnet 3 h 8 h 7 Router B Internet Router A Subnet 2 h 9 h 10 h 1 Subnet 1 h 6 h 11 h 2 h 3 h 4 h 5 Data center 1 Data center 2 Tasks may have vulnerability tolerance capability (e.g., Task 1 can handle buffer overflow attacks using memory management mechanisms) 7/39

10 Mission Deployment Framework Overview τ 1 τ 2 τ 3 Abstract tasks High level task models t 1 t 2 t 3 t 4 t 5 Task instances t 1 h 1 t 2 t 3 t 4 t 5 h 2 h 3 h 4 Allocation 8/39

11 Mission Deployment 9/39

12 Static Mission Deployment Each host h H is associated with a vulnerability value V h tol(t) provides an estimate of the maximum level of vulnerability the task can be exposed to Task allocation problem with two sub-problems Map each task to an appropriate VM image in the repository Allocate VMs on suitable physical hosts in the Cloud t 1 t 2 t 3 t 4 t 5 I 1 I 2 I 3 I 4 I 5 h 1 h 2 h 3 h 4 T VM Image a:t H H 10/39

13 Selecting VM Images Challenge: Develop techniques to assess security of VM images at run-time and an automated security-driven search scheme to deploy mission tasks VM images encapsulate the entire software stack and determine the initial state of running VM instances Most Cloud IaaS require users to manually select VM images; in public Cloud services, VM images have critical vulnerabilities Objective: Select VM images that satisfy both functional requirements and security policy of mission tasks 11/39

14 Allocating VMs on Cloud Infrastructure (1) Challenge: Develop approximation algorithms to find suboptimal allocation solution in a time-efficient manner Objective is to minimize exposure of mission tasks to the vulnerabilities in the Cloud infrastructure Satisfy additional dependability constraints (e.g., host s capacity and task s vulnerability tolerance constraint) 12/39

15 Allocating VMs on Cloud Infrastructure (2) Root Root Task t1 (t1, h1) (t1, h4) Task t2 (t2, h1) (t2, h2) (t2, h3) (t2, h4) (t2, h1) (t2, h2) (t2, h3) (t2, h4) Task t3 h1 h2 h3 h4 h1 h2 h3 h4 h1 h2 h3 h4 h1 h2 h3 h4 h1 h2 h3 h4 h1 h2 h3 h4 h1 h2 h3 h4 h1 h2 h3 h4 Possible solution: Use A -based state-space search approach State is a possible choice for allocating a task on a host (t i,h j ) Root state is the initial state where no task is allocated Operation generates child states for a given state s Goal state is a state in which all the tasks have been allocated (leaf) Solution path is the path from root state to any goal state 13/39

16 Allocating VMs on Cloud Infrastructure (3) Objective is to find the solution path with minimum vulnerability value Cost function is the vulnerability measure of complete allocation fvul(s) = gvul(s) + hvul(s) gvul(s) is the total minimum vulnerability due to task allocation from the root state to the current state s hvul(s) is the lower-bound vulnerability estimate of the allocation from the current state to any goal state hvul(s) is computed using an admissible heuristic Improves search performance while not compromising optimality 14/39

17 Allocating VMs on Cloud Infrastructure (4) Traversal scheme expands the states and generates the solution path starting from the root state The state with minimum fvul(s) value is considered and its successors are generated (unless s corresponds to the goal state) For each successor s of s Vulnerability cost gvul is calculated If s is already visited, and if its real cost is less than that of the current successor, it is dropped, and hvul(s ) value is estimated The fvul(s )=gvul(s )+hvul(s ) value is determined and stored The parent state s is marked as visited 15/39

18 Example - Allocating VMs on Cloud Infrastructure (5) Host Network Residual CPU capacity, Vulnerability level Task Application CPU Requirement, Vulnerability tolerance h 1 0.5, 0.3 t 1 0.4, 0.2 h 2 0.7, 0.1 t 2 0.4, 0.2 h 3 0.3, 0.2 t 3 0.3, 0.4 h 4 0.5, 0.2 V ti,hj h 1 h 2 h 3 h 4 t t t root t 1, h 2 t 1, h t 2, h t 3, h t 3, h t 3, h State-space tree nodes expansion sequence 16/39

19 Allocating VMs on Cloud Infrastructure (6) Number of search steps with and without the estimation heuristic 5 10 tasks (with heuristic) 5 10 tasks (uniform cost) 200 Search steps Number of hosts 17/39

20 Allocating VMs on Cloud Infrastructure (7) Quality of the solution wrt the (i) mission and (ii) globally across the Cloud infrastructure tasks Approximation ratio Number of hosts Approximation ratio Number of hosts 18/39

21 Allocating VMs on Cloud Infrastructure (8) Scalability of the proposed approach tasks 15 Time (s) Number of hosts hosts 20 Time (s) Number of tasks 19/39

22 Dynamic Mission Deployment (1) Each task is associated with temporal constraints (e.g., a task may only run after another task) Critical missions must complete within a certain amount of time Possible solution: Complex task scheduling solution that takes into account the capability of the VM while computing the solution 20/39

23 Dynamic Mission Deployment (2) Challenge: Schedule mission tasks on the hosts 1 To minimize their exposure to the vulnerabilities in the network 2 To ensure their deadlines are met task t 1 Mission execution timeline task 2 (2s) t 2 t 3 t time s 0 task 1 task 4 s 1 s 2 (3s) (4s) s 3 task 3 (3s) Critical tasks (e.g., task t 3 ) must be placed on highly reliable host Adopt scheduling schemes such as greedy heuristics, genetic algorithms, tabu search, A to solve the scheduling problem 21/39

24 Incremental Vulnerability Analysis (1) Challenge: Develop a scalable scheme to estimate the increase V ti,h j in vulnerability level of host h j due to deployment of task t i An allocation introduces new services (tasks, VMs) on a host and increases its vulnerability by V Perform what-if analysis during mission deployment 22/39

25 Incremental Vulnerability Analysis (2) Possible solution: Instead of recomputing the vulnerability from-scratch, apply an incremental algorithm on attack graph 1 Event-based approach 2 Identify the changed parts of the graph and calculate the changed vulnerability 3 Combine the results with already computed results c 2 e 2 c 3 e 3 c 1 e 1 Conditions Exploits c 4 23/39

26 Incremental Vulnerability Analysis (2) Possible solution: Instead of recomputing the vulnerability from-scratch, apply an incremental algorithm on attack graph 1 Event-based approach 2 Identify the changed parts of the graph and calculate the changed vulnerability 3 Combine the results with already computed results c 2 e 2 Conditions c 3 c 5 c 1 Exploits e 3 e 5 e 1 c 4 23/39

27 Mission Protection 24/39

28 Static Network Hardening Challenge: Given a mission is deployed in the Cloud, protect the resources used by the mission tasks In the static version, all the hosts and network links are protected for the entire duration of mission execution h12 h13 h14 h15 t1 t2 Subnet 3 h8 h7 Router B Internet Router A Subnet 2 h9 h10 h1 Subnet 1 h6 h11 h2 h3 h4 h5 Possible solution: Build on top of previous work for network hardening 25/39

29 Dynamic Mission Protection Challenge: At any point in time, find a cost-optimal time-varying strategy to harden the resources not yet used by the mission Dynamic protection minimizes the disruption that hardening strategy causes to legitimate users Possible solution: Efficient technique that analyzes huge streams of security threats at real-time For example, use of attack graphs to track where the attacker is going (the penetration path) 26/39

30 Dependability in the Mission Interpreter 27/39

31 Dependability Support for Mission Interpreter Realize the notion of Dependability as a Service Dependability schemes based on the virtualization technology (e.g., checkpointing virtual machine instances) + introduce dependability in a transparent manner + offers high level of generality + Possible to change dependability properties based on business needs Construct dependability mechanisms at runtime Mission centric Service Level Agreement (SLA) 28/39

32 Dependability as a Service Build and deliver the service by orchestrating a set of micro-protocols Realize dependability techniques as independent, stand-alone, configurable modules (web services) Operate at the level of virtual machine instances VM instance replication technique h 1 h 2 h 3 h 4 F T M 29/39

33 Dependability as a Service Build and deliver the service by orchestrating a set of micro-protocols Realize dependability techniques as independent, stand-alone, configurable modules (web services) Operate at the level of virtual machine instances VM instance replication technique h 1 h 2 h 3 h 4 F T M 29/39

34 Dependability as a Service Build and deliver the service by orchestrating a set of micro-protocols Realize dependability techniques as independent, stand-alone, configurable modules (web services) Operate at the level of virtual machine instances Failure detection using hearbeat test 29/39

35 Example of a comprehensive dependability solution A fault tolerance policy: ft_sol[ invoke:ft_unit(vm-instances replication) invoke:ft_unit(failure detection) do{ execute(failure detection ft_unit) }while(no failures) if(failure detected) invoke:ft_unit(masking mechanism) invoke:ft_unit(recovery mechanism) ] 30/39

36 Example of a comprehensive dependability solution A fault tolerance policy: ft_sol[ invoke:ft_unit(vm-instances replication) invoke:ft_unit(failure detection) do{ execute(failure detection ft_unit) }while(no failures) if(failure detected) invoke:ft_unit(masking mechanism) invoke:ft_unit(recovery mechanism) ] Replica Group h 1 h 2 h 3 h 4 30/39

37 Example of a comprehensive dependability solution A fault tolerance policy: ft_sol[ invoke:ft_unit(vm-instances replication) invoke:ft_unit(failure detection) do{ execute(failure detection ft_unit) }while(no failures) if(failure detected) invoke:ft_unit(masking mechanism) invoke:ft_unit(recovery mechanism) ] Replica Group h 1 h 2 h 3 h 4 30/39

38 Example of a comprehensive dependability solution A fault tolerance policy: ft_sol[ invoke:ft_unit(vm-instances replication) invoke:ft_unit(failure detection) do{ execute(failure detection ft_unit) }while(no failures) if(failure detected) invoke:ft_unit(masking mechanism) invoke:ft_unit(recovery mechanism) ] Replica Group h 1 h 2 h 3 h 4 30/39

39 Example of a comprehensive dependability solution A fault tolerance policy: ft_sol[ invoke:ft_unit(vm-instances replication) invoke:ft_unit(failure detection) do{ execute(failure detection ft_unit) }while(no failures) if(failure detected) invoke:ft_unit(masking mechanism) invoke:ft_unit(recovery mechanism) ] Replica Group h 1 h 2 h 3 h 4 30/39

40 Configuration of a Dependability Solution (1) Based on the affect of failures on mission s tasks Using Fault trees and Markov chains ToR Top of Rack Switch AccR Access Router AggS Aggregate Switch LB Load Balancer 31/39

41 Configuration of a Dependability Solution (2) Analyze the properties of typical dependability mechanisms For example, semi-active replication Primary, Backup (λ failure rate, µ recovery rate, k constant) (1 k)µ (1 k)µ 2λ λ 1,1 1,0 0,0 kµ kµ 32/39

42 Identify possible deployment levels Based on data published by Kim et al. in PRDC 09, Smith et al. in IBM Systems Journal 08, Undheim et al. in Grid 11 Availability values for each replication mechanism at different deployment levels Same Cluster Same Data center, Diff. Data centers diff. clusters Semi-Active Semi-Passive Passive /39

43 Replica Placement Constraints Location and performance requirements of replicas can be specified using constraints Global constraints Resource Capacity Infrastructure oriented constraints Forbid, Count Application oriented constraints Restrict, Distribute, Latency 34/39

44 Example - Distribute Constraint To avoid single points of failure among replicated tasks Two tasks are never located on the same physical host h 1 h 10 v 1 h 2 h 5 h 6 h 7 v 3 v 2 h 3 h 4 h 8 h 9 35/39

45 Example - Distribute Constraint To avoid single points of failure among replicated tasks Two tasks are never located on the same physical host h 1 h 10 v 1 h 2 h 5 h 6 h 7 v 3 v 2 h 3 h 4 h 8 h 9 35/39

46 Example - Distribute Constraint To avoid single points of failure among replicated tasks Two tasks are never located on the same physical host h 1 h 10 v 1 h 2 h 5 h 6 h 7 v 3 v 2 h 3 h 4 h 8 h 9 35/39

47 Example - Distribute Constraint To avoid single points of failure among replicated tasks Two tasks are never located on the same physical host h 1 h 10 v 1 h 2 h 5 h 6 h 7 v 3 v 2 h 3 h 4 h 8 h 9 35/39

48 Conclusions Mission-centric techniques to improve the security and fault tolerance in Cloud computing Secure mission deployment techniques (allocation and scheduling) Static and dynamic mission protection by network hardening Provide complementary dependability support to the mission interpreter as a service 36/39

49 Acknowledgments This work is supported by the Army Research Office under award number W911NF , and by the Office of Naval Research under award number N /39

50 Publications Chapters in Books R. Jhawar, V. Piuri, "Fault Tolerance and Resilience in Cloud Computing Environments" in Computer and Information Security Handbook, 2nd Edition, J. Vacca (ed.), Morgan Kaufmann, 2013 (to appear) International Journals Articles R. Jhawar, V. Piuri, M. Santambrogio, "Fault Tolerance Management in Cloud Computing: A System-Level Perspective," Systems Journal, IEEE, vol.pp, no.99 C. A. Ardagna, R. Jhawar, V. Piuri, "Dependability Certification of Services: A Model-Based Approach", (under submission) International Conferences and Workshops M. Albanese, S. Jajodia, R. Jhawar, V. Piuri, "Secure Mission Deployment in Vulnerable Networks", (under submission) 38/39

51 Publications C.A. Ardagna, E. Damiani, R. Jhawar, and V. Piuri, "A Model-Based Approach to Reliability Certification of Services," in Proc. of the 6th IEEE Int l Conference on Digital Ecosystem Technologies - Complex Environment Engineering, Campione d Italia, Italy, June, 2012 R. Jhawar, and V. Piuri, "Fault Tolerance Management in IaaS Clouds," in Proc. of the 1st IEEE-AESS Conference in Europe about Space and Satellite Telecommunications, Rome, Italy, October 2-5, 2012 R. Jhawar, V. Piuri, and P. Samarati, "Supporting Security Requirements for Resource Management in Cloud Computing," in Proc. of the 15th IEEE Int l Conference on Computational Science and Engineering, Paphos, Cyprus, December 5-7, 2012 R. Jhawar, V. Piuri, and M. Santambrogio, "A Comprehensive Conceptual System-Level Approach to Fault Tolerance in Cloud Computing," in 2012 IEEE Int l Systems Conference, Vancouver, BC, Canada, March 19-22, /39