ESF: AN ELASTIC SECURITY FRAMEWORK FOR CLOUD INFRASTRUCTURES

(1)

ESF: AN ELASTIC SECURITY

FRAMEWORK FOR CLOUD

INFRASTRUCTURES

Makan Pourzandi

Ericsson Cloud System Management, Affiliated Associate Professor Concordia University

(2)

Plan

• Background

• Elastic Security Framework

• Elastic Enforcement Layer

• Security Enforcement Optimization

(3)

Contributions

• Publications:

• 16 patent applications issued by US and European patent offices • 3 Book chapters, 7 Journal papers

• 31 papers in international conferences with peer review

• Standardizations:

• June 2005-Dec 2009: Leader for Service Availability Forum

Security working group, Co-editor for Service Availability Forum Security service specifications version A.0.1, released Sept, 2007.

• June 2002-Sept 2003: Editor for security requirements of Carrier

Grade Linux Release 2.0 for Open Source Development Lab, released July 2003.

• Open Source:

• Main software architect and project leader for Distributed Security

Infrastructure 2001 – 2006

• Team leader for "Model-Based Engineering of Secure Software and

Systems", Development of Java based plug-ins for IBM Rational Software Architect

(4)

RESEARCH THEMES

4

(5)

Distributed Security Infrastructure: Middle

ware security

(6)

MOdel-Based Framework for the Engineering of Secure

Software and Systems: Software Security

6

(7)

Telecom networks security: SPAM

Mitigation on LTE 4G Mobile Networks

• Distributed

architecture on the LTE network for SPAM mitigation

• Solving the over

dimensioning problem

• Using ‘of-the-shelf’

hardware in

(8)

Home Area Network Neighborhood Area Network Threats Connection-Based: - RF Jamming - Wireless Scrambling - Eavesdropping

- Message Modification & Injection - Protocol Failures

- Physical Attacks & Natural Disasters

Device-Based:

- Physical Attacks , Nat. Disasters - Rogue Access Points

- Man-in-the-middle Attacks - DoS Attacks, Replay Attacks

- Illegitimate use of services

- Masquerading - Wardriving Home Gateway Base Station Smart Meter

Smart Grid Communications Security

(9)

Research Themes

• Software security

• Verification and validation of security requirements at design level • Integration of enforcement mechanisms at the design level

• Distributed security infrastructure

• Distributed process based access control

• DDoS and SPAM mitigation mechanisms in Mobile

Telecom networks

• Distributed Architecture for Spam Mitigation on LTE 4G Mobile

Networks

• Cloud computing security

• Security and privacy of user-generated data in the cloud storage • Self-protecting elastic security frameworks for large IT systems

• Communication Security for Smart Grid Distribution

Networks

Application–Middleware Security

Smart Grid Security Network & Cloud Computing Security

(10)

WHY AN ELASTIC SECURITY

FRAMEWORK IN CLOUD

INFRASTRUCTURES?

10

(11)

Agenda

• Background

(12)

Cloud Computing: Infrastructure As A

Service (IaaS)

• Enhanced by massive virtualization • Shared pool of configurable computing resources • Elasticity: On-demand resource, auto-scaling • Self provisioning, Flexibility M. Pourzandi 12 Servers Physical Infrastructure Virtual Infrastructure Internet Physical Infrastructure Virtualization

(13)

Target systems: Large IT systems such as

cloud infrastructure

• Cloud infrastructure build on top of large data centers

• Several thousands to hundreds of thousands of servers

• Cloud approach is based on pay for the resources that

you need

• You just turn off the extra resources when there is no need • Massive virtualization to provide elasticity and flexibility

(14)

Cloud Computing Security: Status

• Security is a major concern for the industry when moving to

Cloud Computing

• 72% of organizations are "extremely concerned" or "very concerned"

about security in the cloud environment (2010 research firm TheInfoPro)

• Many of the cloud security issues are the same for

enterprise security

• Some differences though

14

(15)

Background

• Complexity of the application behaviour and sheer number

of them make it difficult, costly and error prone to write

down by hand different network security enforcement rules for the data centers

• Cloud elastic nature makes it necessary to be able to

adapt security rules in an agile and fast way

• This makes a human intervention too slow and not

realistic given the pace of changes

• An old problem: enforcing security in a complex

(16)

New dimensions for an old problem

• Scalability and elasticity in the cloud make it

impossible to use old methods

• Multi Tenancy/Compartmentalization: Need to isolate

communications/resources between different customers

• Scalability: Need to support tens of thousands of virtual

machines, running on thousands of physical servers

• Flexibility: Need to support many different types of

applications with different network topologies and security needs

• Elastic security: Need to maintain security policy as data

and virtual machines migrate in the cloud, and auto-scale

16

(17)

• Consider security mechanisms for a 3-tier application

• Assume a deployment in the cloud: 6 instances of web server, 2 instances

of business tier and 1 instance of database

Use Cases

(18)

18 Possible mapping of virtual machines into a physical network M. Pourzandi

(19)

Consequences of VM Migration on

Security Rules

• If in the previous example WS6 migrates from PS2 to PS4

then:

1. WS6 rules should be removed from FW1 and added to FW2

2. WS3 – WS6 rules in AppFW1 should be removed and added to

AppFW2

3. Security policy of FW1, AppFW1, FW2, and AppFW2 should be

verified and validated

• This means all FWs in the previous scenario are affected by this

(20)

Current approaches: Solution 1

› Virtual FW defined for each VM › When VM1 migrates to another data center, VM1 traffic is re-directed back to the data M. Pourzandi 20

(21)

Current approaches: Solution 2

› Different VFWs are composed together › Creating multitude of vFWs › Benefit from HW Firewalling

(22)

Challenges remain

› When VM1

migrates, there is need for

maintaining the same sec policy

› Validate that

inserted rules do not introduce any anomalies in other FWs › Security policy orchestration › Topology based optimization M. Pourzandi 22

(23)

How to address these challenges?

•

Need for automatic and dynamic generation of

security rules

•

Maintenance and enforcement of security rules

for a large number of components, e.g. virtual

machines in the cloud infrastructure

•

For an elastic network there is need for an

(24)

Agenda

• Background

(25)

ESF: AN ELASTIC SECURITY

FRAMEWORK FOR CLOUD

INFRASTRUCTURES

(26)

ESF High Level overview

• ESF presents a framework to

implement security vertically through different layers of the cloud infrastructure

• Few steps involve human

intervention: Developers describe their distributed application

security policies

• Remaining steps are transparent

to the developers and are

generated automatically from the description

(27)

Elastic Network Security: Functional Diagram

Automatically generate security policy for different applications running in the cloud from their description

Compose/Consolidate

different security rules in order to implement an efficient

enforcement

Configure the enforcement measures to enforce those security rules in the cloud

Dynamically modify/adapt the security enforcement measures based on the security policies Auditability: Being able to verify and validate the consistency and the compliance with pre-defined security policy

(28)

Agenda

• Background

(29)

ELASTIC

ENFORCEMENT LAYER

(EEL)

(30)

Elastic Network Security: Functional Diagram

(31)

EEL

• Virtual security architecture is anchored in the physical

architecture

• As the applications evolve/migrate in the cloud, the

enforcement measures should be adapted to enforce the security policies

• All life stages of VM must be taken into account: launch,

(32)

EEL functionality

• Dynamic and automatic enforcement of security

mechanisms

• L3-L7 Firewalling, Secure connections establishment,

e.g. IPSec tunnels, DPI, IDS/IPS, etc.

• Rapid scaling of protection mechanisms

• When one or several tenants are under attack, for

example DDoS, mitigation mechanisms can be scaled up

• As the tasks performed by the cloud are Agile, Scalable,

Elastic, their security policy enforcement should also be the same: Agile, Scalable, Elastic

(33)

EEL flexible design

• EEL enforces security

policies through different nodes in the cloud data center, Policy

Enforcement Point (PEP)

• Policy Decision Points (

PDP) decide how and what PEPs enforce

• Based on resource

availability (Bandwidth, CPU, Specialized HW, e.g. network processors)

• Latency

(34)

EEL design application principles to the

network layer: Sticky flow

• Network security is applied through different network

middle boxes/security appliances, e.g. Firewall, IDS/IPS, Web App Firewall

• Different network traffic must traverse a pre-defined

sequence of security appliances

• Automatic and Transparent Enforcement in consideration

of multi-tenancy, elastic networking and VM cloning and migration

• Particularly, traffic should traverse security appliances in

the sequence required by the tenant and should not traverse unnecessary security appliances

(35)

State of the art: Policy aware network

enforcement

Support Solution

Middlebox Isolation Automatic Migration Dynamic

Policy-aware [Stoica] Y Y Y N N NetOdessa [Bellessa] N Y Y N N FML/FSL [Mitchell-Shenker] Y Y N N N

Sticky Flow

(36)

Elastic enforcement

(37)

• Application ID (AppID) for each vAPP inserted at

hypervisor layer, e.g. IP options

• Each AppID is associated to some security sequence

• AppID is used for control level in SDN

(38)

• EEL-tags added at Ethernet layer:

• Generic Tags (gTags) • Instance Tags (iTags)

• EEL tags are used for forwarding layer

• Appliance types are not redundant in the sequence

• ∀ , in the security sequence then ∶

• Reasonable as a sequence is applied to a communication between

two VMs in the network

Sticky flow design (2)

(39)

Basic use case

VM1 starts emitting packets. These packets are intercepted by the hypervisor that inserts the AppID into the ip options

The OpenFlow-Switch (OFS) forwards the rst packet to the controller

The OpenFlow-Controller (OFC) extracts the AppID and determine the chain of gTags to be traversed

It then matches the Generic Tags (gTags) to an Instance Tags (iTags) range

It then chooses the middebox instances to send the packet to (based on cloud resource availability). In our example, let's assume the chosen instances of IDS, AppFW and DPI correspond to iTags 2070, 1045 and 3093 respectively

(40)

Basic use case

M. Pourzandi 40

The OFC adds a two new ow-entries into the VM1's edge OFS :

{ Packets from VM1 (to VM2) must be tagged with EEL-tag 2070.

{ Packets with EEL-tag 2070 must be routed to the next switch towards the IDS 2070 instance. Similar rules to the previous ones are to be set into

all the middleboxes edge's OFS. Note that for the egress switch of the last middlebox in the chain, the packet should only be routed to the next switch towards the destination VM

Along the path, the controller adds a rule to forward the packet to the next

switch towards the middlebox instance, based on the EEL-tag.

The OFC also adds three new ow-entries into the IDS's ingress and egress

OFS :

{ Packets tagged with EEL-tag 2070 must have their tag popped and be forwarded to the IDS (ingress).

{ Packets out of the IDS, from VM1 and to VM2 must have the EEL-tag 1045 pushed (egress).

{ Packets with EEL-tag 1045 must be routed to the next switch towards the AppFW 1045 instance (egress).

Mulitenancy is enforced dynamically and automatically at layer 2. Elasticity: the security appliance instances can change as virtual network change

(41)

Migration use case: intra data center

VM1' starts emitting packets. These packets are intercepted by the hypervisor

that inserts the AppID into the ip options

Similar rules to the previous ones are to be set into all the middleboxes edge's OFS.

Same as previous. Note that the IDS iTag is now 2080. Only the AppFW egress switch rules may be modifed, for example if VM1 and VM1' don't have the same MAC address.

Network Security Policy is maintained

dynamically and automatically after

(42)

Elastic enforcement

(43)

Sticky Flow

Algorithm

• Traffic is steered

inside the DC network based on App ID

• Open Flow controller

is the PDP

• Open Flow switches

and Security

(44)

Implementation

• OpenFlow :

• NOX Openflow controller

• Python code added to support sticky flow functionality

• EEL-tags

• Usage of VLAN tag support

• Network :

• Mininet

• Custom topology

• Implemented as Python

• Sender, receiver, middlebox

• Implemented as Python processes

(45)

(46)

Sticky flow conclusions

• Automatic and transparent enforcement • Isolation

• At switch level, L2 enforce the security isolation between tenants’

networks

• Maintaining security policies in an elastic environment

• VM migration/cloning

• Security policy can be maintained at network layer

through different data centers

• Delegating the choice of security appliances instances according to

data center resources

• No need for centralized decision making/resource management • Better resiliency and efficiency in resource consumption

(47)

Agenda

• Background

(48)

SECURITY

ENFORCEMENT

OPTIMIZATION

Local-Global Multi-objective Constraint-Based Path Optimization Algorithm in the cloud

infrastructure (LGCM)

(49)

(50)

M. Pourzandi 50

Goal: Build an optimal path based on multiple

factors passing through some predefined set

of security appliances

(51)

Multi-objective Optimization (1)

• Need for multiple criteria optimization algorithms

• Ex: cost, delay/latency, capacity, ownership for each network link

• Typically, there is no unique optimal solution for such

problems

• Necessary to use decision maker’s preferences to

differentiate between solutions

• Difficulty comes from the presence of more than one

criterion

• No longer a unique optimal solution to the problem that

can be obtained without incorporating preference information

(52)

Multi-objective Optimization (2)

• Concept of an optimal solution is often replaced by a set

of non-dominated solutions

• A non-dominated solution has the property that it is not

possible to move away from it to any other solution without sacrificing in at least one criterion

M. Pourzandi 52

The boxed points represent feasible

choices, and smaller values are preferred to larger ones. Point C is not on the Pareto Frontier because it is dominated by both point A and point B. Points A and B are not strictly dominated by any other, and hence do lie on the frontier

(53)

Solving Multi-objective Optimization: State

of the art

• Scalarization: convert the original problem into one single

problem

• Ex: Assign weights to different objectives in a linear scalarization • Difficulty is to come up with “right” weights

• Human expert

• Difficult to be used in the cloud context, i.e. dynamic changes, large

scale, elastic networks, short answer times needed

• Evolutionary Multi-objective Optimization

• Find all valid paths

• Low complexity comparative to other approaches, i.e. cost

• Difficult in cloud environment to define the convergence factor to

(54)

Evolutionary Multi-objective Optimization

• Start from a set of initial individuals

• Iterate over generations

• Select the fittest individuals • Mate the fittest

• Mutate over to create new individuals

• Converge toward a set of non-dominated individuals

(55)

Bueno approach using SPEA2 for

multi-cast flow routing

• Bueno algorithm* addresses building a multi-factor

optimal multicast using SPEA2

• An heuristic proposed to reduce the problem • Mating selection

• Step 1: Fitness based on Pareto dominance: dominated by, dominating • Dominance rank, dominance count

• Step 2: Refining through density, select individuals in less dense area to improve the diversity

• KNN density

[*] Bueno, M.L.P.; Oliveira, G.M.B.; , "Multicast flow routing: Evaluation of heuristics and multiobjective evolutionary algorithms," Evolutionary Computation (CEC), 2010 IEEE Congress on , vol., no., pp.1-8, 18-23 July 2010

(56)

Supporting sequence of security appliances

• In Bueno Algo, there is no concept of sequence of middle

boxes to respect

• Need for improving Bueno’s algorithm with the concept of

sequence

(57)

LGMC: Illustrating Step

by Step paradigm

• One step is defined

to be an edge in the sequence diagram • Bueno is used at each step • Objective function

must minimize link utilization, total

cost, end-to-end delay, hops count

(58)

LGMC Pseudo Code: define global paths

• Pre-defined security sequence of K middle boxes, i.e. K

steps

• // Find Pareto front local paths for each step

• For each step do

• For every step I in the pre-defined sequence of middleboxes do

• According to step I for valid instances of middle box types then • Assign Src and Dst to be two valid instance of the middle boxes • Apply Bueno between Src → Dst

• Find the Pareto front of local-paths between Src and Dst, i.e. local-path . . • Assign Pareto front local-paths . . to step-paths . .

• // Build global paths from local steps

• Assign to Global-paths[m] the K-tupe

(step-paths[1]…step-paths[K])

(59)

LGMC Pseudo code: finding Pareto front

among global paths

• // Re-apply MOEA to the k-tuples while keeping the

precedence of local-paths in the k-tuple

• Apply SPEA2 MOEA to the k-tuples

• Mating: fill mating pool through binary tournament with new

(k-tuple) individuals

• Mutation: Mutate new individuals by changing the local-paths

respecting the sequence, i.e. mutation in step I from local-paths[I]

• End result: Pareto Front in the global paths, i.e. from

(60)

LGCM: Complexity

• LGCM is based on SPEA2 with the complexity

log where M is number of individuals at each generation

• LGCM complexity is then K ∗ log ≅

where K is the number of elements in the security sequence

• LGCM complexity is independent from N number of nodes in the

network

• We cannot really compare an evolutionary algorithm with

exact algorithmic methods

• Chen and Nahrstedt showed on a paper that a similar

kind of problem, i.e. Multi-constrained paths can be

solved in complexity where N is the number of nodes in the graph and x is large enough (e.g. 10)

(61)

Future work

• LGCM is our first attempt at using MOEA in a network with

a pre-defined set of constraints

• First results are encouraging

• Theoretical complexity is comparatively low

• Proof of concept program results in valid graphs

• Need to validate approach through more complete set of

examples

• Need for new improve current LGCM algorithm by

extending our work to create virtual security appliances in the cloud infrastructure

(62)

ESF conclusions

• ESF targets developing a homogeneous approach around

complex problems

• Several problems have been addressed so far

• Elastic enforcement: Sticky Flow Algorithm • Enforcement optimization: LGCM

• Verification and validation of security rules: Cloud Calculus

• Need to extend these results to a wider use cases