1

Luigi LogrippoKamel Adi

Inconsistency and incompleteness in security policies

luigi@uqo.caadi@uqo.ca

2

Policies

Policies are logical statements that determine the behavior of a system:

Firewalls and routersTelecommunications features, call controlInformation access control systems (e.g. language XACML)Security models (Bell-LaPadula, Chinese Wall, RBAC…)Web services orchestration and choreography (e.g. language BPEL)E-commerce policies and contracts, service-level agreements

3

Different levels of policies

Event-Condition-Action (ECA) level:If an event occurs, and a condition is true, then some actions should be executed

• Examples: firewalls, XACMLEnterprise requirements level:

• Example: employees who have access to the name of the clients should not have access to their acct balances

• Related to privacy considerationsECA level is easily executed by computersEnterprise Requirement will need translation

4

Issues

Translation between levelsConsistency of policies

Interaction between policies

Completeness of policies

5

Translation

Require information on enterprise:Enterprise ontology

6

Consistency

Inconsistency among policies can cause policies to work differently than intendedInconsistencies can easily exist, because

Policies can be complex• A policy may contain thousands of rules

Are subject to maintenance

7

Examples betw. policies at same levelusers must have Role Ausers cannot have Role A

users must have Role Ausers must have Role A or Role B

resource is only accessible on Monday through Wednesday.on Tuesday, Resource is not accessible

8

Example betw. policies at requirement level

RBAC: lawyers in Dept X can access databases A and BChinese Wall: some lawyers in Dept X work for company M, cannot access database BBell-LaPadula: database A requires higher clearance than database B and only department heads have this clearance

9

Feature Interactions example:Bell-LaPadula and delegation

High security personnel can use delegation to transfer access rights to lower security personnel

FI: Delegation defeats BLP

10

Dangers of delegation

Delegation is a common, but dangerous feature It can create inconsistencies with all policiesExample:

• In a hospital, only doctors should have simultaneous access to names and illness information

• Department A has access to names of customers• Department B has a access to illness information• Jack who works in A delegates to Margie who works

in B

11

Completeness

Are all cases considered?Security systems usually have implicit closure rules that take decisions in all cases not considered

Cisco firewalls: all packets not listed will be discardedLinux (IPTables): all packets not listed will be accepted

But is this what user wants or has something been forgotten?

12

Main idea

Many design flaws can be discovered by making the logic precise and thoroughly examining it by the use of logic tools

Formal methods

Policy inconsistencies are logic flawsInconsistency of specs

Application areas:SecurityChecking software requirementsNew VoIP and Web based systemsWhenever any functionalities of any kind are composed

Do this Do that

13

Our Research Group

14

Our research group

Security Research Laboratory with students and uptodate equipment for research in the following areas:

Security protocols and e-commerce protocolsAccess control technologiesMalicious code detectionCode certificationHoneypots techniques

15

Our existing expertise:Intrusion detection systems

Generation of attack scenariosWhy ?

Find global security holes by taking into account the effects of interactions of local vulnerabilities in a network of hosts: offer a global view of the system safetyCan be used to enrich IDS scenarios database Can be used to estimate the severity of an alert raised by a detection tool

How ?Use local vulnerability information along with other information about the network, such as connectivity between hostsApply induction rules capturing intruder behavior to produce an attack graphEach path in the graph leading to an undesirable state is an intruder attackExample of an undesirable state is a state where the intruder has obtained administrative access to a critical host.

16

Intrusion detection systems:Approach

Modeling

Intruder deduction

rules

Formal proof

attack graph

17

Intrusion detection systems:results

A new approach that allows to find global security breaches by taking into account the effects of interactions of local vulnerabilities in a network of hostsThe technique can be used to improve intrusion detection systems:

Generate IDS scenario databaseDetect unknown attack scenariosEvaluate the level of severity of an alert

18

Our existing expertise:Firewalls

Elaborate a formal language (FPSL) for the specification of firewallsElaborate a typing system for the detection of a class of anomalies in firewallsGiven the set of rules in a firewall, we have an algorithm to determine the logical relationships

19

Possible relationships between firewall rules

Disjointness: OKShadowing: second rule never used because it is a particular case of the previous one, with same or different outcome

Generalization: converse situation with different outcome. Correlation: rules with non-empty intersections with different outcomeRedundancy: two intersecting rules with the same outcomeOther possibilities also exist, which could be caused by user errorIn each case, report and prompt user for corrections

20

Our existing expertise:distributed firewalls

An enterprise can have several internal and external sub-networks protected by several firewallsThese have to collaborate to implement locally some part of a global policyHow can it be guaranteed that the collaboration will be correct?

21

Approach for distributed firewall V&V

We defined a formal language inspired by the ambient calculusAn ambient is a delimited space that has a name, an interior and an exterior and can contain processes A process can be provided with capabilities in, out and openOur calculus allows specifying network packets, network topologies and sets of filtering rules (firewalls) We defined an equivalence relation (called compatibility relation) between processes to verify if a local firewall policy is incompatible with the global policy

22

Different network topologies

23

Our existing expertise:XACML

Rule1 : A professor can read or modify the file of course marks

Rule2 : A student can read the file of course marks

Rule3 : A student cannot modify the file of course marks

24

Discovery of inconsistency using Alloy

Both rule1 and rule3 are applied when

A modification request comes from

• A subject with both professor and student role

On the file of course marks• Rule1's response is permit• Rule3's response is deny

25

Enterprise-level policies:Mutual consistency

By using Alloy, we were able to show that:Bell-LaPadulaRBACChinese-Wall

Can coexist without inconsistenciesIf certain conditions are met

26

Enterprise-level policies:a new model

A new model of enterprise level policy is being developed:

Process-based access control• In this model, the authorization of the user is determined

by the process that the subject is executing (rather than by its role)

• E.g. a user that is in the process: credit limit application will have different rights than a user in the process: update address

27

Now for the three cases discussed at the beginning:

Proof of conceptwith the formal method Alloy

28

Users must have Role 0Users cannot have Role 0

Role 0 is both permitted and interdicted

29

User must have Role 0 User must have role 2 Role 2 inherits from 0 (0 has delegated its rights to 2)

User0 can acquire Role0 in two different ways: + via a direct connection and + from Role2 by inheritance

30

Resource is only accessible on Mon, Tue, Wed.On Tue Resource is not accessible

On Day1, Resource is rejected and accessible

31

How Alloy works

Alloy expresses the constraints in terms of boolean expressions and then tries to solve these by invoking off-the-shelf SAT solversThis problem is exponential, however improvements in efficiency of SAT solvers allows many non-trivial problems to be treated Current solvers can handle

thousands of boolean vars, hundreds of expressions

• But much depends on the type of the expressions

32

We have shown a first proof of concept but…

33

Many problems still to be solved

The process we have demonstrated isCircuitous and artificialTranslation into Alloy is requiredAlloy must be coaxed into producing a proof

• No general methods to do this are known

Difficult to interpret resultsComputationally inefficient

34

Feasible part of the curve

Computationally inefficient…

35

Work directions

Experiment with different ways to precisely specify policies

At different levels of policiesClarify how incompleteness and inconsistency occur in practiceExperiment with efficient methods to find themMake these techniques available for practical application

36

Itemized listDefinition of languages and formalisms appropriate for the specification of policies At the enterprise levelAt the rule levelConsistency of policiesAt the enterprise levelAt the rule levelBetween levels – Does the lower level say everything the higher level sayMethods to detect and solve inconsistenciesCompleteness of policies – Within levels and between levelsEquivalence of policiesTranslation between policies at different levelsAnalytical and testing methodsUser interfacesReal case studies – Interact with users