Modelling and Analysis of Network Security Policies VALENZA_presentation.pdf · Modelling and...

Doctoral Dissertation

Doctoral Program in Computer Engineering (29th cycle)

Modelling and Analysis ofNetwork Security Policies

Fulvio Valenza

Supervisor: Prof. Antonio Lioy

Co-Supervisor: Ing. Cataldo Basile

1/40

ScenarioIntroduction

Large-sized Networks:

• hundreds of nodes• different security technologies

• many network services• policy-based management

Modelling and Analysis of Network Security Policies Fulvio Valenza

2/40

Problem StatementIntroduction

• specification of security policies requires several technical details• security properties, protocols, cipher-suites and timeouts

• security administrators’ (hard) tasks: write correct policies andavoid network errors

• e.g. blocking legitimate traffic or sending insecure data

The literature confirms1:% 60% of security breaches and breakdowns are attributable to

administrators’ responsibilities

1Data breach investigation 2016


3/40

PhD ObjectivesIntroduction

1 deep investigation on the limitations of the currentstate of the art on network security policies

2 improvements of the analysis of policy types less addressedin the literature (i.e. communication protection policy)

3 definition of a unified model for policy analysis


3/40

ContentNetwork Security Policy

Network Security Policy

Communication Protection Policy

Unified Model for Policy Analysis


4/40

Definitions (RFC-3198)Network Security Policy

• policy: a set of rules to administer, manage, and control accessto network resources

• policy rule: a set of actions to a set of conditions - where theconditions determine whether the actions are performed

• network security policy: a policy that specify the securityrequirements of network communications

• e.g., forward, filter, translate, protect and monitoring network traffic

packet filter policy

src_IP src_Port dst_IP dst_Port protocol action

192.168.1.* 0-1024 192.168.3.* 0-1024 TCP allow


5/40

Research TopicsNetwork Security Policy

• Policy Analysis: process to analyze and check some propertiesagainst a set of policies

• Anomaly Analysis, Reachability Analysis, Policy Comparison

• Anomaly Analysis checks the policy specification to preventerrors, conflicts and sub-optimization (i.e. anomalies) in thenetwork


6/40

Policy AnomalyNetwork Security Policy

• Conflicts are triggered when the effect of one security policy isinfluenced or altered by another one

• e.g., the actions of two rules contradict each other

• Errors occur when the enforcement of the policy actions fails• e.g., a mismatch between the policy actions and the device

capabilities

• Sub-optimizations arise when other more efficient policyimplementations are available

• e.g., redundant rules are present in policy specification


7/40

Anomaly Analysis: State of the ArtNetwork Security Policy

Filtering

� several works mostly related to packet filtersÀ few works on stateful and application firewalls

Communication protection policyÀ few works in literature and only on IPsec policy anomalies� no policy analysis over many technologies (e.g. TLS vs SSH)

OtherÀ few and limited works on other policy types� no analysis among different policy types


8/40

PhD ContributionsNetwork Security Policy

Inter-domain

Inter-technology

Inter-policy

Intra-policy

Intra-rule

novel

literature


9/40

ContentCommunication Protection Policy





9/40

Communication Protection PolicyCommunication Protection Policy

• specify the security requirements to apply on a communication

• difficult to manage• enforced by several security controls• use different protocols at different layers of the OSI stack

• e.g. IPsec, TLS, SSH, WS-Security

% incorrect implementations produce faulty and redundantconfigurations, leading information disclosure, violationsof the users’ privacy, monetary losses, etc


10/40

DefinitionsCommunication Protection Policy

• Channel is a directional data exchange between two entities at aspecific ISO/OSI layer

• Secure channel is a channel with some security properties• e.g., header integrity, payload integrity and (payload) confidentiality

• Communication is all directional data exchanges between nodes• a communication is a set of several channels

• Policy Implementation (PI) is a formal representation of a channel• a communication is represented by a set of PIs


11/40

Policy ImplementationCommunication Protection Policy

i = (s,d , t ,C,S,G)

• represent the source and destination of the channel

data link layer ↔ layer 2 addressesnetwork layer ↔ IP addressessession layer ↔ port numbers

application layer ↔ URIs


11/40


i = (s,d , t ,C,S,G)

• the requested security technology

data link layer ↔ WPA2 and MACsecnetwork layer ↔ IPsecsession layer ↔ TLS and SSH

application layer ↔ WS-Security

NULL


11/40


i = (s,d , t ,C,S,G)

• the requested security coefficients

C = (chi , cpi , cc)

• non-negative values to indicate a required security levelfor a specific property

• i.e. confidentiality, header and payload integrity

• estimated by the administrators based on some metrics• key length, encryption/hash algorithms, cipher mode

if t = NULL =⇒ C = (0,0,0)


11/40


i = (s,d , t ,C,S,G)

• a set of network fields (selectors) to identify the traffic to protect• e.g. IPsec packet headers

S = (ipsrc , ipdst ,psrc ,pdst ,proto)


11/40


i = (s,d , t ,C,S,G)

• the list of the gateways involved in the communication


12/40

ExampleCommunication Protection Policy

Internet

ga1ca2

ca1

ca3

gb1cb1

cb2

gc1

gc3

gc2

sc1

sc2

db

web1

cc2

web2

cc1

cc3

A

B

C


12/40

ExampleCommunication Protection Policy

Internet

ga1ca2

ca1

ca3

gb1cb1

cb2

gc1

gc3

gc2

sc1

sc2

db

web1

cc2

web2

cc1

cc3

A

B

C

• i1 = (ca1, sc1,NULL, (0,0,0), ∗, (ga1,gc1,gc2))

• i2 = (ga1,gc2, IPsec, (3,3,3), ipca1 , ∗, ipsc1 , ∗, ∗), (gc1))


13/40

AnomaliesCommunication Protection Policy

InadequacyMonitorabilitySkewed channelAsymmetric channelNon-enforceabilityOut of placeFilteredL2ShadowingExceptionCorrelationAffinityContradictionRedundancyInclusionSuperfluousInternal loopAlternative pathCyclic path

Insecure communications

Unfeasible communications

Suboptimal implementations

Potential errors

Suboptimal walks

Anomalies


13/40






Potential errors

Suboptimal walks

Anomalies

“An insecure communication occurs when the communicationsecurity level is lower than the expected one”


13/40






Potential errors

Suboptimal walks

Anomalies

“An unfeasible communication is a communication that cannot beestablished because of a hard misconfiguration”


13/40






Potential errors

Suboptimal walks

Anomalies

“A potential error occurs where the original intent of administrators isunclear and is required a thorough human inspection”


13/40






Potential errors

Suboptimal walks

Anomalies

“A suboptimal implementation arises when extra PIs can decreasethe network throughput by producing some overhead in nodes”


13/40






Potential errors

Suboptimal walks

Anomalies

“A group of PIs can produce a suboptimal walk whenthe path taken by the data is unnecessarily long”


13/40






Potential errors

Suboptimal walks

Anomalies


14/40

Monitorability anomalyCommunication Protection Policy

InadequacyMonitorabilitySkewed channelAsymmetric channel

Insecurecommunication

• a monitorability anomaly is when some nodes at the channeljunctions can “see” the exchanged data

sc1 gc1 ca1


15/40

Skewed channel anomalyCommunication Protection Policy

InadequacyMonitorabilitySkewed channelAsymmetric channel

Insecurecommunication

• a skewed channel anomaly1 is when a wrong tunneloverlapping removes the confidentiality in a part of thecommunication

gc3 gc1 ga1

Double tunnel

Single tunnel

No tunnel

1Al-Shaer et al. “Modeling and Verification of IPSec and VPN Security Policies”


16/40

Filtered anomalyCommunication Protection Policy

Non-enforceabilityOut of placeFilteredL2

Unfeasiblecommunication

• a filtered anomaly is when the packets of a channel are droppedby a firewall that lies on the path between source and destination

• external info: the filtering policy


17/40

Contradiction anomalyCommunication Protection Policy

ShadowingExceptionCorrelationAffinityContradiction

Potential error

• a contradiction anomaly is when two PIs respectively expressthat the same communication should be protected andunprotected


18/40

Superfluous anomalyCommunication Protection Policy

RedundancyInclusionSuperfluousInternal loop

Suboptimalimplementation

• a superfluous anomaly is when a tunnel encapsulates othertunnels with a higher security level


19/40

Anomaly analysisCommunication Protection Policy

1 algebraic model• based on First Order Logic (FOL) formulas

• one formula for each anomaly to check

2 multi-graph representation• a user-friendly representation of the anomalies

• based on multi-graph theory


20/40

Algebraic modelCommunication Protection Policy

• Filtered

Afi(i1)⇔ ∃e : e ∈ G1 ∧ Fe(i1) = true

• Skewed

Ask (i1, i2)⇔ s1 ∈ S2|ipsrc×psrc×... ∧ (|G∗1 ∩G∗

2 |) > 2∧

∧(G∗2 \G∗

1 6= 0) ∧ cc1 > 0 ∧ cc

2 > 0 ∧ i1 6= i2

• Superfluous

Asu(i1)⇔ @ ik : sk ∈ S1|ipsrc×psrc×... ∧G∗k ⊃ G∗

1 ∧ Ck ≺ C1


21/40

Multi-graph representationCommunication Protection Policy

end-to-end

ca1

2

3

5

7

browser

sc1

2

3

5

db

5′

7′

web1

(3, 3, 3)

IPsec

(3, 3, 3)

IPsec


22/40


site-to-site

cc1

2

3

5

7

browser

gc3

2

3

2′

3′

gc2

2′

3′

2

3

sc1

2

3

5

db

5′

7′

web1

(1, 1, 1)

IPsec:(cc1, ∗, sc1, ∗, . . . )

IPsec:(sc1, ∗, cc1, ∗, . . . )

(1, 1, 1)


23/40


monitorability anomaly

cb1

2

3

4

7

browser

gc1

2′

3′

2

3

sc1

2

3

4′

db

4

7

web1

(3, 3, 3)

IPsec

(3, 3, 3)

IPsec


24/40


skewed channel anomaly

cc1

2

3

5

7

browser

gc3

2

3

2′

3′

gc2

2′

3′

2

3

sc1

2

3

5

db

5′

7′

web1

(3, 3, 3)

IPsec:(cc1, ∗, sc1, ∗, . . . )

(3, 3, 3)

IPsec:(cc1, ∗, sc1, ∗, . . . )


25/40


filtered anomaly

cc1

2

3

5

7

browser

gc3

2

3

2′

3′

gc2

2′

3′

2

3

sc1

2

3

5

db

5′

7′

web1

(3, 3, 3)

IPsec


26/40

Model validationCommunication Protection Policy

1 Model usefulness• an empirical assessment with 30 different subjects

2 Model feasibility• testing of a implementation prototype


27/40

Empirical assessmentCommunication Protection Policy

subjects• recruiting a set of 30 administrators

• split into 3 categories of experience (high, medium, low)

questionnaire• translate five high-level CPPs into a set of PIs• no limits on the time and number of PIs

results• all the anomaly types have been introduced by

the administrators when configuring the CPPs• the number of anomalies decrease when

administrator expertise grows


28/40

Implementation and TestingCommunication Protection Policy

• Java-based prototype relying on:• an ontology-centric core (OWL)• a powerful rule-based language (SWRL)

• All tests are executed on my workstation• 16 GB RAM• an Intel [email protected] GHz processor• running on Windows 10


29/40

Implementation and TestingCommunication Protection Policy

pre-computation analysis total time

100 200 300 400 500

0

20

40

60

80

100

entity count500 PI

time[s]

100 200 300 400 5000

20

40

60

80

100

PI count500 entities

time[s]


30/40

ContentUnified Model for Policy Analysis





30/40

MotivationUnified Model for Policy Analysis

Define a unified model for policy analysis able to:

1 represent network security policies of different domains• filtering, transformation and communication policies

2 detect intra- and inter-domain anomalies• current literature limits its analysis to a single domain

3 extend the capabilities of policy analysis• detect any irregular network conditions and events that an

administrator wants to monitor• i.e., no errors and conflicts


31/40

Inter-domain anomaly exampleUnified Model for Policy Analysis

• a CPP is defined to encrypt all traffic sent to the Internet

• a filtering policy is configured to drop all the encrypted traffic


32/40

UMPA ModelUnified Model for Policy Analysis

The Unified Model for Policy Analysis (UMPA) is composedof five element:

• network fields

• policy actions

• policy implementations

• detection rules

• policy anomalies


33/40


network fields• identify the traffic flows or the events an administrator wants to

manage through a set of actions• e.g., packet headers, network node ID, traffic label,...

policy actions• represent either the action performed by a network node, the

parameters and information that characterize that action• e.g., firewall’s “deny" or “allow", algorithms, protocols,..


34/40


Policy Implementations• the formal definition of policy rule

• a sequential set of network fields (n) and policy actions (a):

pii = (ni1,ni2, ...,nin,ai1,ai2, ...,ain)

• e.g., packet filtering policy

pifp = (f , r , ip_src, ip_dst , t ,p_src,p_dst ,a)


35/40


Relations R:

• equivalence: ni and nj areequivalent if they have the samevalue

ni1 = 1.1. ∗ .∗,nj1 = 1.1. ∗ .∗ → ni1 = nj1

• disjointness: ni and nj aredisjoint if they do not share anyvalue

ni1 = [1, 75],nj1 = [100, 50]→ ni1 ⊥ nj1

• dominance: ni dominates nj , if ni

is a generalization of nj

ni1 = 1.1. ∗ .∗,nj1 = 1.1.1.∗ → ni1 � nj1

• correlation: ni and nj arecorrelated if they share somevalues, but none of themdominates the other

ni1 = [1, 75],nj1 = [50, 100]→ ni1 ∼ nj1

• non-disjointness ni 6⊥ nj : if ni and nj are not disjoint, they canbe equivalent, correlated or one can dominate the other


36/40

UMPA modelUnified Model for Policy Analysis

Detection Rules

• set of conditions applied on fields and actions of one or more PIs• expressed using Horn clauses

C1 ∧ C2 ∧ ... ∧ Cn =⇒ I

Ci := (nik R1 nih) or (nik R2 njh) or (nik R3 njk ) or(aik R4 aih) or (aik R5 ajh) or (aik Rn ajk ) or ...

Anomaly• arises when all the conditions are satisfied

• e.g., Intra-Firewall Shadowing anomalyfi = fj ∧ rj � ri ∧ ip_srci � ip_srcj ∧ ti � tj ∧ ip_dsti � ip_dstj∧p_srci � p_srcj ∧ p_dsti � p_dstj ∧ ai 6= aj ⇒ Intra-Shadowing(pii ,pij)


37/40

Model validationUnified Model for Policy Analysis

Validation of the capability of UMPA model by using:

1 three types of policy• packet filtering2

• communication protection• traffic flow (novel)

2 rule detection of• well-know intra-domain anomalies• new types of intra- and inter-domain anomalies

2Al-Shaer et al. “Discovery of policy anomalies in distributed firewalls”


38/40

ConclusionConclusion

Contributions

! deep literature review on policy types and analysis approaches

! definition of inter-technology and inter-domain anomalies

! application anomaly analysis on communication protection policy

! formalization of a unified model for policy analysis


39/40

ConclusionConclusion

Future works

1 extend the expressiveness and capabilities of the UMPA model• improvements with policy reachability and reconciliation

2 integrate the policy anomaly analysis in NFV and SDN• policy analysis over Service Function Chains


40/40

PapersConclusion

policy conflict analysis

qCRISIS2014

qRTSI2015

qWFCS2017

qSNS2017

NIJNM 2016

NTON2017

policy refinement

qNETSOFT2015

�CSP2015

NTON

policy comparison

qMIST2016

NJOWUA2017

policy reachability

NCAEE2017

others

qSPRO2015

qWFCS2017

� Accepted � Review qConference N Journal �Book chapter


Thanks for yourattention!

Modelling and Analysis of Network Security Policies VALENZA_presentation.pdf · Modelling and...

Documents

Transcript of Modelling and Analysis of Network Security Policies VALENZA_presentation.pdf · Modelling and...