Model-driven Extraction and Analysis of Network Security Policies (at MoDELS'13)

Model-driven Extraction and Analysis of
Network Security Policies
MODELS 2013
Salvador Mart´ınez1
, Joaqu´ın Garc´ıa-Alfaro2
, Frédéric Cuppens2
,
Nora Cuppens-Boulahia2
, Jordi Cabot1
1
AtlanMod, INRIA / Ecole de Mines de Nantes
2
Télécom Bretagne ; LUSSI Department Université Européenne de Bretagne
October, 2013

Introduction
Security is a critical concern. . .
c AtlanMod – atlanmod-contact@mines-nantes.fr 2/31

Introduction
Security is a critical concern. . . At the network level, ﬁrewalls play a key role

Introduction
Why so?

Introduction
Why so?
They implement access control policies in networks

Introduction
Why so?
Subjects = Hosts (acting as message senders)
Objects = Hosts (acting as message receivers)
Actions = Message sending to hosts with certain characteristics:
Port
Protocol

Introduction
Why so?
Port
Protocol
Conﬁdentiality

Introduction
Why so?
Port
Protocol
Conﬁdentiality
Integrity

Introduction
Implementation of a network security policy:
Done generally by hand
Low-level and vendor-speciﬁc rule ﬁltering languages
Topology: Policy enforcement distributed.

Introduction
CONSEQUENCES:
Knowing which policy is actually being enforced is a challenge
Possible security ﬂaws
Hampers evolution

Introduction
CONSEQUENCES:
Knowing which policy is actually being enforced is a challenge
Possible security flaws
Hampers evolution
Solution? Raise abstraction level
Abstracts from low-level system specificities
Abstracts from topology
Simplifies management of the policy

Motivation
Intranet: private hosts + administrator
DMZ providing: HTTP/HTTPS, FTP, SMTP and SSH
Public Hosts
2 firewalls controlling:
Firewall 1: traffic between public hosts and DMZ
Firewall 2: traffic between intranet and DMZ

FW1 Conf.
iptables −P INPUT DROP
iptables −P FORWARD DROP
iptables −P OUTPUT DROP
iptables −N Out_SMTP
iptables −A FORWARD −s 1 1 1 . 2 2 2 . 1 . 1 7 −d 0 . 0 . 0 . 0 / 0 −p tcp −−dport 25 −j Out_SMTP
iptables −A Out_SMTP −d 111.222.0.0/16 −j RETURN
iptables −A Out_SMTP −j ACCEPT
iptables −N In_SMPT
iptables −A FORWARD −s 0 . 0 . 0 . 0 / 0 −d 1 1 1 . 2 2 2 . 1 . 1 7 −p tcp −−dport 25 −j Out_SMTP
iptables −A Out_SMTP −s 111.222.0.0/16 −j RETURN
iptables −N NetWeb_HTTP
iptables −A FORWARD −s 0 . 0 . 0 . 0 / 0 −d 1 1 1 . 2 2 2 . 1 . 1 7 −p tcp −−dport 80 −j NetWeb_HTTP
iptables −A NetWeb_HTTP −s 111.222.0.0/16 −j RETURN
iptables −A NetWeb_HTTP −j ACCEPT
Netﬁlter iptables conf. ﬁle using custom chains

FW1 Conf.
1 Default policy

FW1 Conf.
1 Default policy
2 Controls outcoming SMTP messages.

FW1 Conf.
1 Default policy
3 Controls incoming SMTP messages to the server

FW1 Conf.
1 Default policy
4 Controls the HTTP requests from the public hosts

FW1 Conf.
1 Default policy
4 Controls the HTTP requests from the public hosts
5 Local hosts are not allowed to use services!!!

Fw2. Conf
access−list eth1_acl_in remark Fw2Policy 0 (global)
access−list eth1_acl_in deny tcp host 1 1 1 . 2 2 2 . 2 . 5 4 1 1 1 . 2 2 2 . 1 . 1 7 eq 25
access−list eth1_acl_in permit tcp 1 1 1 . 2 2 2 . 2 . 0 255.255.255.0 1 1 1 . 2 2 2 . 1 . 1 7 eq 25
access−group eth1_acl_in in interface eth1
Cisco PIX conf. ﬁle

Fw2. Conf

Fw2. Conf
2 Controls the HTTP requests

Fw2. Conf
2 Controls the HTTP requests
3 Add rules to the interface

Example: Evaluation
Expert knowledge about netfilter iptables and Cisco PIX is required:
Its syntax
Its execution semantics
The topology has to be known to ease the understanding on the policy of
the individual firewalls.
All the firewalls have to be taken into account to derive a global policy.

Example: Evaluation
Its syntax
Some numbers: M: Number of ﬁrewalls and N: Number of rules
Big companies M >> N example BNP network: M ≈ 1000, N ≈ 100
Small companies N >> M

Example: Evaluation
Its syntax
Some numbers: M: Number of ﬁrewalls and N: Number of rules
Big companies M >> N example BNP network: M ≈ 1000, N ≈ 100
Small companies N >> M
Manual approach?
for corporate networks, M (potentially from diﬀerent vendors) and N are big
enough to make the task very hard.

Approach

Approach
Our proposal
Model-driven extraction process towards a network access-control model
representing the global policy of the system.

Approach

Approach: Injection
Mere translation between technical spaces:
No information-loss
Same abstraction level

Approach: Injection
No information-loss
Requirements: For each diﬀerent rule-ﬁltering language we need
A PSM
A parser
An injector

Approach: Injection
No information-loss
Requirements: For each diﬀerent rule-ﬁltering language we need
A PSM
A parser
An injector
We can obtain this by providing the language grammar to XTEXT

Implementation: XTEXT
Model:
rules += Rule∗;
Rule:
AccessGroup | AccessList;
AccessGroup:
’access−group’ id=ID ’in’ ’interface’
interface=Interface;
Interface:
id=ID;
AccessList:
( ’no ’ ) ? ’access−list’ id=ID
decision=( ’deny’ | ’permit ’ )
protocol=Protocol
protocolObjectGroup=ProtocolObjectGroup
serviceObjectGroup=ServiceObjectGroup
networkObjectGroup=NetworkObjectGroup;
ProtocolObjectGroup:
(pogId=ID) ? sourceAddress=IPExpr
sourceMask=MaskExpr;
ServiceObjectGroup:
targetAddress=IPExpr targetMask=IPExpr;
NetworkObjectGroup:
operator=Operator port=INT;
Operator:
name=( ’eq’ | ’lt’ | ’gt ’ ) ;
Protocol:
name= ( ’tcp’ | ’udp’ | ’ip ’ ) ;
IPExpr:
INT ’ . ’ INT ’ .
Figure: Cisco Metamodel excerpt

Implementation: XTEXT
Model:
rules += Rule∗;
Rule:
declaration=ChainDeclaration |
filter=FilterDeclaration;
FilterDeclaration:
filter=FilteringSpec;
FilteringSpec:
FilterSpec;
FilterSpec:
’iptables’ option=(’−A’ | ’−D’ | ’−P ’ )
chain=Chain ((’−src’ | ’−s ’ ) ip=IPExpr) ?
(’−i’ interface=Interface) ?
(’−d’ ipDst=IPExpr) ?
(’−p’ protocol=Protocol) ?
(’−m’ matches=Protocol) ?
(’−−sport’ sourcePort=INT) ?
(’−−dport’ destinationPort=INT) ?
(’−j ’ ) ? target=Target;
Interface:
name=ID;
Protocol:
Tcp | Udp | Icmp;
Target:
ID;
Chain:
chainName = ID;
CustomChain:
name=[ChainName ] ;
ChainDeclaration:
’iptables’ ’−N’ ChainName;
ChainName:
name=ID;
IPExpr:
INT ’ . ’ INT ’ .
Figure: Iptables Metamodel excerpt

Approach

Approach: PSM2PIM
Simplest PIM: Ri : {conditions} → {decision}
i: order within the the conf ﬁle
condition: a set of rule matching attributes like ip source address
decision: accept or deny

Approach: PSM2PIM
Simplest PIM: Ri : {conditions} → {decision}
i: order within the the conf ﬁle
condition: a set of rule matching attributes like ip source address
decision: accept or deny
Problems?
Highly redundant and disperse
Not suited to represent exception oriented access-control
Anomalies (positive-negative logic conﬂicts + execution algorithm)

Metamodel
Network Access-control Metamodel
Platform-independent
Supports the representation of exceptions
Supports the identiﬁcation of anomalies

PSM2PIM
First step: Transform the PSM into the corresponding PIM
Rule shadowing: a rule R is shadowed when it never applies because another
rule with higher priority matches all the packets it may match.
Rule redundancy: a rule R is redundant when it is not shadowed and removing
it from the rule set does not change the security policy.
Rule irrelevance: a rule R is irrelevant when it is meant to match packets that
does not pass by a given ﬁrewall.
Second step: PIM reﬁnement
Improves internal organization: Representation of exceptions
Detection of anomalies

PSM2PIM reﬁning algorithm 1
Algorithm 1
1: C← All Connections
2: Caccept ← Ci ∈ C (Ci .decision = Accept)
3: for each Ci ∈ Caccept do
4: Cdeny ← CJ ∈ C (Cj .decision = Deny and Matched of Cj ⊆ matched Ci )
5: for each Cj ∈ Cdeny do
6: if Cj .order < Ci .order then
7: Create Exception
8: Remove Cj
9: else
10: Cj .IsShadowed ← true
11: end if
12: end for
13: end for
14: Cdeny ← Cj ∈ C (Cj .decision=Deny and Cj .isShadowed=false)
15: for each Ci ∈ Cdeny do
16: Cj .IsRedundant ← true
17: end for

PSM2PIM reﬁning algorithm 1
Algorithm 1
2: Caccept ← Ci ∈ C (Ci .decision = Accept)
3: for each Ci ∈ Caccept do
4: Cdeny ← CJ ∈ C (Cj .decision = Deny and Matched of Cj ⊆ matched Ci )
5: for each Cj ∈ Cdeny do
6: if Cj .order < Ci .order then
7: Create Exception
8: Remove Cj
9: else
10: Cj .IsShadowed ← true
11: end if
12: end for
13: end for
14: Cdeny ← Cj ∈ C (Cj .decision=Deny and Cj .isShadowed=false)
15: for each Ci ∈ Cdeny do
16: Cj .IsRedundant ← true
17: end for

Implementation: ATL
r u l e deleteDeny{
from
s : NetworkAC ! Connection (
s . decision = #Deny and
thisModule .
→TotalExceptionRules
→ . includes ( s ) )
to
drop
t : NetworkAC ! Exception (
decision <− s . decision ,
dstPort <− s . dstPort ,
firewall <− s . firewall ,
order <− s . order ,
protocol <− s . protocol ,
source <− s . source ,
srcPort <− s . srcPort ,
target <− s . target
)
}
r u l e MarkShadowed{
from
thisModule . ShadowedRules .
→includes ( s ) )
to
t : NetworkAC ! Connection (
isShadowed <− true
)
}
r u l e MarkRedundant{
from
thisModule . ShadowedRules .
→excludes ( s )
and
thisModule .
→TotalExceptionRules
→ . excludes ( s ) )
to
t : NetworkAC ! Connection (
isRedundant <− true
)
}

Approach

PIM Aggregation
An individual firewall gives only a partial vision of the security enforced in the
whole network.
E.g., The access to the SMTP service is managed by both firewalls, one
allowing the access from the public host and one allowing the access from the
intranet.
We need to aggregate the individual models!!
REVERSIBLE: Each Connection keeps original firewall and rule ordering.
GlobalModel = Mi ∪ Mj . . . ∪ Mn
Refinement to assign types to Network Elements

Approach

Applications: Refinement
Individual firewalls may contain only locally relevant information.
We need to discern between locally and globally relevant information!!
The global model is easier to understand
Isolate the policy from the enforcement topology
Algorithm 2
2: E← All Exceptions
3: for each Ei ∈ E do
4: L← Ci ∈ C (Ci .firewall = Ei .firewall and Matched of Ci ⊆ matched Ei )
5: if L = ∅ then
6: Ei .IsLocal ← true
7: for each Ci ∈ L do
8: Ci .IsLocal ← true
9: end for
10: end if
11: end for

Applications:Metrics & queries
We query our model for the existence of any connection allowing the
administrator host (111.222.2.54) to connect to the server (111.222.1.17):

Applications:Metrics & queries
We query our model for the existence of any connection allowing the
administrator host (111.222.2.54) to connect to the server (111.222.1.17):
E v a l u a t i n g :
s e l f . c o n n e c t i o n s −>e x i s t s (
e | e . s o u r c e . i p A d d r = ’111.222.2.54 ’
a n d e . t a r g e t . i p A d d r = ’111.222.1.17 ’)
R e s u l t s :
f a l s e

Applications:Visualization
Figure: Extracted network topology

Approach

Applications:PIM 2 XACML
XACML PIM Metamodel
PolicySet A PolicySet containing a Policy is created for each firewall
in the PIM
Policy All the Connections and Exceptions belonging to a given
firewall
Rule A single connection or Exception
Subject Source NetworkElement address and source port of a given
Connection or Exception
Resource Target NetworkElement address and target port a given
Connection or Exception
Action Not mapped. The action is always the ability of sending a
message.
Condition Protocol field
Table: PIM to XACML Mappings

Applications:PIM 2 XACML
<Rule Effect=”Deny” RuleId=”1”>
<Description />
<Target>
<Subjects>
<Subject>
<SubjectMatch MatchId=””>
<AttributeValue DataType=”http://www. w3. org/2001/XMLSchema#string”>
111.222.2.54 </AttributeValue>
<SubjectAttributeDesignator />
</SubjectMatch>
</Subject>
</Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId=”urn: oasis: names: tc: xacml : 1 . 0 : function: string−equal”>
<AttributeValue DataType=”http://www. w3. org/2001/XMLSchema#string”>
111.222.1.17 </AttributeValue>
<ResourceAttributeDesignator />
</ResourceMatch>
</Resource>
</Resources>
</Target>
<Condition>
<SubjectAttributeDesignator AttributeId=”protocol”
DataType=”http://www. w3. org/2001/XMLSchema#string” />
</Condition>
</Rule>

Implementation
Eclipse-based implementation

Implementation
EMF as modelling framework

Implementation
XTEXT as DSL deﬁnition framework

Implementation
ATL as transformation framework

Implementation
XPAND as Model to Text framework

Implementation
XPAND as Model to Text framework
http://www.emn.fr/z-info/atlanmod/index.php/Firewall_Reverse_
Engineering

Conclusions & Future Works
MDE succeeds to isolate the policy from low-level speciﬁcities

Easier to understand

Easier to manipulate (reusability of proved MDE tools)

Enables migration and evolution.

Future Works

Future Works
Extend to other network components such as MPLS routers, IDS, etc

Future Works
Extend XACML with network-speciﬁc attributes

Future Works
Extend XACML with network-speciﬁc attributes
Apply our approach to real corporation networks

Thank you!
Thank you!
Contact:
Salvador Mart´ınez
AtlanMod, INRIA and ´Ecole des Mines de Nantes
salvador.martinez perez@inria.fr

Model-driven Extraction and Analysis of Network Security Policies (at MoDELS'13)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Model-driven Extraction and Analysis of Network Security Policies (at MoDELS'13)

Similar to Model-driven Extraction and Analysis of Network Security Policies (at MoDELS'13) (20)

More from Jordi Cabot

More from Jordi Cabot (20)

Recently uploaded

Recently uploaded (20)

Model-driven Extraction and Analysis of Network Security Policies (at MoDELS'13)