Security, cloud computing

1. M. Pourzandi
1
ESF: AN ELASTIC SECURITY
FRAMEWORK FOR CLOUD
INFRASTRUCTURES
Makan Pourzandi
Ericsson Cloud System Management, Affiliated
Associate Professor Concordia University
Apr 2013

2. M. Pourzandi
Plan
• Background
• Elastic Security Framework
• Elastic Enforcement Layer
• Security Enforcement Optimization
2

3. M. Pourzandi
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. M. Pourzandi
RESEARCH THEMES
4

5. M. Pourzandi
5
Distributed Security Infrastructure: Middle
ware security

6. M. Pourzandi
6
MOdel-Based Framework for the Engineering of Secure
Software and Systems: Software Security

7. M. Pourzandi
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
distributed nodes

8. 8
M. Pourzandi
Smart Grid Communications Security
Threats
Connection-Based:
Device-Based:
- RF Jamming
- Wireless Scrambling
- Eavesdropping
- Message Modification & Injection
- Protocol Failures
- Physical Attacks & Natural
Disasters
- Physical Attacks , Nat. Disasters
- Rogue Access Points
- Man-in-the-middle Attacks
- DoS Attacks, Replay Attacks
- Illegitimate use of services
- Masquerading
- Wardriving
Base
Station
Smart
Meter
Home Area Network
Home
Gateway
Neighborhood Area Network

9. M. Pourzandi
9
Research Themes
• Software security
• Verification and validation of security requirements at design level
• Integration of enforcement mechanisms at the design level
• Distributed security infrastructureApplication–Middleware
Security
• Distributed process based access control
• DDoS and SPAM mitigation mechanisms in Mobile
Telecom networks
• Distributed Architecture for Spam Mitigation on LTE 4G Mobile
Networks
Network & Cloud Computing
• Cloud computing security 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
Smart Grid Security

10. M. Pourzandi
10
WHY AN ELASTIC SECURITY
FRAMEWORK IN CLOUD
INFRASTRUCTURES?

11. M. Pourzandi
Agenda
• Background
• Elastic Security Framework
• Elastic Enforcement Layer
• Security Enforcement Optimization
11

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

13. M. Pourzandi
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. M. Pourzandi
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

15. M. Pourzandi
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
network

16. M. Pourzandi
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

17. M. Pourzandi
Use Cases
•
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
17

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

19. M. Pourzandi
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
migration!
19

20. M. Pourzandi
Current approaches: Solution 1
› Virtual FW
defined for
each VM
› When VM1
migrates to
another data
center, VM1
traffic is redirected back
to the data
20

21. M. Pourzandi
Current approaches: Solution 2
› Different
VFWs are
composed
together
› Creating
multitude of
vFWs
› Benefit from
HW
Firewalling
21

22. M. Pourzandi
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
22

23. M. Pourzandi
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
elastic network security

24. M. Pourzandi
Agenda
• Background
• Elastic Security Framework
• Elastic Enforcement Layer
• Security Enforcement Optimization
24

25. M. Pourzandi
25
ESF: AN ELASTIC SECURITY
FRAMEWORK FOR CLOUD
INFRASTRUCTURES

26. M. Pourzandi
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
26

27. M. Pourzandi
27
Elastic Network Security: Functional Diagram
Automatically generate security
policy for different applications
running in the cloud from their
description
Auditability: Being able to verify
and validate the consistency
and the compliance with predefined security policy
Configure the enforcement
measures to enforce those
security rules in the cloud
Compose/Consolidate
different security rules in order
to implement an efficient
enforcement
Dynamically modify/adapt the
security enforcement measures
based on the security policies

28. M. Pourzandi
Agenda
• Background
• Elastic Security Framework
• Elastic Enforcement Layer
• Security Enforcement Optimization
28

29. M. Pourzandi
29
ELASTIC
ENFORCEMENT LAYER
(EEL)
Sticky Flow Algorithm Case

30. M. Pourzandi
30
Elastic Network Security: Functional Diagram

31. M. Pourzandi
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,
termination, cloning, migration, etc.

32. M. Pourzandi
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. M. Pourzandi
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
• Locality information
33

34. M. Pourzandi
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. 35
M. Pourzandi
State of the art: Policy aware network
enforcement
Sticky Flow
Support Middlebox Isolation
Automatic
Migration
Dynamic
Solution
Policy-aware [Stoica] Y
Y
Y
N
N
NetOdessa
[Bellessa]
N
Y
Y
N
N
FML/FSL [MitchellShenker]
Y
Y
N
N
N

36. M. Pourzandi
Elastic enforcement
36

37. M. Pourzandi
37
Sticky flow design (1)
• 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. M. Pourzandi
38
Sticky flow design (2)
• 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

39. M. Pourzandi
Basic use case
It then matches the Generic Tags
(gTags) to an Instance Tags (iTags)
range
The OpenFlow-Controller (OFC)
extracts the AppID and determine
the chain of gTags to be traversed
The OpenFlow-Switch (OFS)
forwards the rst packet to the
controller
VM1 starts emitting packets. These
packets are intercepted by the
hypervisor that inserts the AppID
into the ip options
39
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. M. Pourzandi
Basic use case
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.
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
40
Elasticity: the
security
appliance
instances can
change as
virtual network
change
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).
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.
Mulitenancy is
enforced
dynamically and
automatically at
layer 2.

41. M. Pourzandi
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
VM migration.

42. M. Pourzandi
Elastic enforcement
42

43. M. Pourzandi
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
appliances are PEPs
43

44. M. Pourzandi
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
44

45. M. Pourzandi
Proof of concept
45

46. M. Pourzandi
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. M. Pourzandi
Agenda
• Background
• Elastic Security Framework
• Elastic Enforcement Layer
• Security Enforcement Optimization
47

48. M. Pourzandi
SECURITY
ENFORCEMENT
OPTIMIZATION
Local-Global Multi-objective Constraint-Based
Path Optimization Algorithm in the cloud
infrastructure (LGCM)
48

49. M. Pourzandi
49
Elastic Network Security: Functional Diagram

50. M. Pourzandi
50
Goal: Build an optimal path based on multiple
factors passing through some predefined set
of security appliances

51. M. Pourzandi
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. 52
M. Pourzandi
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
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
Fig from Wikipedia

53. M. Pourzandi
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
the optimal solution

54. M. Pourzandi
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. M. Pourzandi
55
Bueno approach using SPEA2 for multicast 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. M. Pourzandi
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. M. Pourzandi
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
57

58. M. Pourzandi
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. M. Pourzandi
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 (ktuple) 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
Source VM to destination VM

60. M. Pourzandi
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. M. Pourzandi
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. M. Pourzandi
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