View
216
Download
1
Category
Preview:
Citation preview
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
Recommended