1 Luigi Logrippo Kamel Adi Inconsistency and incompleteness in security policies

2 Policies Policies are logical statements that determine the behavior of a system: Firewalls and routers Telecommunications features, call control Information 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, XACML Enterprise requirements level: Example: employees who have access to the name of the clients should not have access to their acct balances Related to privacy considerations ECA level is easily executed by computers Enterprise Requirement will need translation

4 Issues Translation between levels Consistency 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 intended Inconsistencies 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 level users must have Role A users cannot have Role A users must have Role A users 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 B Chinese Wall: some lawyers in Dept X work for company M, cannot access database B Bell-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 delegatio n 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 policies Example: 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 discarded Linux (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 flaws Inconsistency of specs Application areas: Security Checking software requirements New VoIP and Web based systems Whenever 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 protocols Access control technologies Malicious code detection Code certification Honeypots techniques

15 Our existing expertise: Intrusion detection systems Generation of attack scenarios Why ? 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 safety Can 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 hosts Apply induction rules capturing intruder behavior to produce an attack graph Each path in the graph leading to an undesirable state is an intruder attack Example 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 hosts The technique can be used to improve intrusion detection systems: Generate IDS scenario database Detect unknown attack scenarios Evaluate the level of severity of an alert

18 Our existing expertise: Firewalls Elaborate a formal language (FPSL) for the specification of firewalls Elaborate a typing system for the detection of a class of anomalies in firewalls Given the set of rules in a firewall, we have an algorithm to determine the logical relationships

19 Possible relationships between firewall rules Disjointness: OK Shadowing: 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 outcome Redundancy: two intersecting rules with the same outcome Other possibilities also exist, which could be caused by user error In 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 firewalls These have to collaborate to implement locally some part of a global policy How 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 calculus An 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 open Our 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-LaPadula RBAC Chinese-Wall Can coexist without inconsistencies If 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 concept with the formal method Alloy

28 Users must have Role 0 Users 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 solvers This 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 is Circuitous and artificial Translation into Alloy is required Alloy must be coaxed into producing a proof No general methods to do this are known Difficult to interpret results Computationally inefficient

34 Feasible part of the curve Computationally inefficient…

35 Work directions Experiment with different ways to precisely specify policies At different levels of policies Clarify how incompleteness and inconsistency occur in practice Experiment with efficient methods to find them Make these techniques available for practical application

36 Itemized list Definition of languages and formalisms appropriate for the specification of policies At the enterprise level At the rule level Consistency of policies At the enterprise level At the rule level Between levels – Does the lower level say everything the higher level say Methods to detect and solve inconsistencies Completeness of policies – Within levels and between levels Equivalence of policies Translation between policies at different levels Analytical and testing methods User interfaces Real case studies – Interact with users