Security Policies

1
Security Policies
2
Reading

• For this class
• Denning Chapter 13 Access Controls
• M. Daminaou, N. Dulay, E. Lupu, M. Sloman The
  Ponder Policy Specification Language,
  http//www.doc.ic.ac.uk/mss/Papers/Ponder-summary
  .pdf
• S. De Capitani di Vimercati, P. Samarati, S.
  Jajodia Policies, Models, and Languages for
  Access Control, http//seclab.dti.unimi.it/Papers/
  2005-DNIS.pdf
• S. Jajodia, P. Samarati, M.L. Sapino, and V.S.
  Subrahmanian Flexible Support for Multiple
  Access Control Policies, http//seclab.dti.unimi.i
  t/Papers/tods-logic.ps
• For next class
• Denning Chapter 13 remaining sections
• Look at the Security Services of the NETWORK  AND
  INFORMATION SECURITY SERVICES, USC,
  http//uts.sc.edu/network/

3
Policy, Model, Mechanism

• Policy High-level rules
• Model formal representation proof of
  properties
• Mechanism low-level specifications

Separation of policy from the implementation!
4
System Architecture and Policy

• Simple monolithic system
• Distributed homogeneous system under centralized
  control
• Distributed autonomous systems homogeneous domain
• Distributed heterogeneous system

Complexity Of Policy
5
Traditional Access Control

• Protection objects system resources for which
  protection is desirable
• Memory, file, directory, hardware resource,
  software resources, etc.
• Subjects active entities requesting accesses to
  resources
• User, owner, program, etc.
• Access mode type of access
• Read, write, execute

6
Access Control Models

• See CSCE 522 for details
• Been around for a while
• Discretionary Access Control
• Mandatory Access Control
• Role-Based Access Control
• Relatively new
• Usage-Based Access Control
• Capabilities-Based Access Control

7
Closed vs. Open Systems
Closed system
Open System
(minimum privilege)
(maximum privilege)
Access req.
Access req.
Allowed accesses
Disallowed accesses
Exists Rule?
Exists Rule?
yes
no
yes
no
Access denied
Access permitted
Access permitted
Access denied
8
Negative Authorization

• Traditional systems Mutual exclusion
• New systems combined use of positive and
  negative authorizations
• Support exceptions
• Problems How to deal with
• Incompleteness Default policy
• Inconsistencies Conflict resolution

9
Conflict Resolution

• Denial takes precedence
• Most specific takes precedence
• Most specific along a path takes precedence
• Priority-based
• Positional
• Grantor and Time-dependent
• Single strategy vs. combination of strategies

10
Policy Specification Language

• Express policy concepts
• Required properties of policy languages
• Support access control, delegation, and
  obligation
• Provide structuring constructs to handle large
  systems
• Support composite policies
• Must be able to analyze policies for conflicts
  and inconsistencies
• Extensible
• Comprehensible and easy to use

11
Policy Specification Language Approaches

• Logic-based approach
• Adv Precise and expressive
• Disadv not intuitive, difficulty and complexity
  of implementation
• e.g., Jojodia et al., A logical language for
  expressing authorizations, 1997
• Graphical approach
• Adv supports visual understanding
• Disadv Scope is limited
• E.g., Hoagland et al., Security Policy
  Specification using a Graphical Approach, 1998
• Event-Based language
• Adv clear semantics and architecture
• Disadv limited scope
• E.g.,Lobo et al., A Policy Description Language,
  1999
• Object-Oriented, declarative language
• Adv clear semantics, expressiveness, easy to use
• Disadv support of domain specific semantics
• E.g., Damianou et al., The Ponder Policy
  Specification Language, 2000

12
The following slides are included here with the
approval of Dr. WijesekeraRecent Advances in
Flexible Access Control Models

• Duminda Wijesekera
• dwijesek_at_gmu.edu
• ise.gmu.edu/duminda.html

Author D. Wijesekera
13
Flexible Authorization Framework

• An authorization is of the form s,o,ltsigngta
• An authorization specification AS consists of a
  set of
• authorization cando (base facts, non-recursive
  rules)
• derivation dercando (conditional facts,
  recursive rules)
• conflict resolution do (avoiding over/under
  specification)
• history done
• Hierarchical (hie-) and application specific
  (rel-) predicates
• Integrity error predicate symbols

Author D. Wijesekera
14
Functional Architecture
HistoryTable
AuthorizationTable
DECISION
PropagationPolicy
Conflict Resol.Decision Policy
IntegrityConstraints
USER
o,s,a
Author D. Wijesekera
15
Authorization Rules

• cando(o,s,ltsigngta) ? L1 Ln
• o object
• s subject
• ltsigngta signed action
• L1 Ln are done, hie- or rel- literals

16
Authorization Policy

• Collection of rules
• Closed policy example
• dercando (u,o,a) ???cando(s,o,a) in(u,s).do
  (u,o,a) ???dercando(u,o,a).do (u,o,-a) ???not
  do(u,o,a).
• error(s,o,a) ???cando(s,o,-a).

Author D. Wijesekera
17
Denials-take-precedence

• do (u,o,-a) ???dercando(u,o,a)
  dercando(u,o,-a).
• do (u,o,-a) ???not do(u,o,a).

Author D. Wijesekera
18
Static Separation of Duty

• error() ???do(s,budget,submitting)
  do(s,budget,evaluating) do(s,budget,approvi
  ng) .

Author D. Wijesekera
19
Semantics

• A FAF specification forms a locally stratified
  logic program
• It has a unique stable model
• Stable model well founded model

Author D. Wijesekera
20
Materialization

• Access requests must be decided fast.
• Hence materialize FAF predicates
• Most useful DO
• Materialization algorithm reconstructs the unique
  stable model
• Looking up materialized rules are faster that
  backtracking through logic programs.

Author D. Wijesekera
21
Revoking Permissions

• Granted permissions have to be revoked.
• Semantics of Removal
• dercando(s1,o,a) .
• dercando(s2,o,a) lt- dercando(s1,o,a)
• dercando(s3,o,a) lt- dercando(s2,o,a)
• Remove dercando(s2,o,a).
• Should s3 loose permissions?
• If the following derived rule is present, then s3
  will not loose permission.
• dercando(s3,o,a) lt- dercando(s1,o,a)

Author D. Wijesekera
22
Non-cascading Revoke
A revokes Ds privileges
E
B
A
F
C
23
Cascading Revoke
A revokes Ds privileges
B
A
C
24
Positive and Negative Authorization

• Problem
• Contradictory authorizations
• GRANT ltprivilegegt ON X TO ltusergt
• DENY ltprivilegegt ON X TO ltusergt

25
Negative Authorization
-
Positive authorization granted By A to D becomes
blocked but NOT deleted.
26
Negative Authorization
-

F
What should happen with the privilege given by
D To F? (Blocked but not deleted)
27
Shallow vs. Deep Revoke

• Shallow revoke
• dercando(s1,o,a) .
• dercando(s3,o,a) lt- dercando(s1,o,a)
• Deep Revoke
• dercando(s1,o,a) .
• Representation independent semantics.
• Revoking same permission from logically
  equivalent rules must result in retaining the
  same permission set.

Author D. Wijesekera
28
Resolving Conflicts

• Consider the following rule in FAF
• error() ???do(s,budget,submitting)
  do(s,budget,evaluating) do(s,budget,approvi
  ng) .
• FAF states access control specifications, but
  does not resolve them.

Author D. Wijesekera
29
Provisions and Obligations

• Yes/no response to every request is just not
  enough
• Provisions Conditions to be satisfied before
  permission is considered
• Obligations Conditions to be fulfilled as a
  consequence of accesses

Author D. Wijesekera
30
Example Electronic Loan Application

• Provisions Registered account holder
• Either already registered or register now!
• Some actions need to be taken in order to satisfy
  the obligations
• Conditions
• Have a good credit history
• Makes enough money to pay back
• Then, the bank sells the loan

Author D. Wijesekera
31
Example continued

• Obligations
• Customer needs to make up her mind in a week
• Agree to abide by following conditions
• Have to pay an installment every month by the due
  date
• If not, have to pay installmentsurcharge within
  two weeks grace period
• Failing (2), the loan will be cancelled and
  property re-processed.

Author D. Wijesekera
32
Representation of the Problem

• Use FAF rules decorated with provisions and
  obligations.
• Provisions and obligations are constructed from
  conjunctions and disjunctions of literals.
• Have disjoint sets of atoms for predicates in
  rules and their decorations
• Terms are made of constants and variables shared
  across both kinds of predicates.

Author D. Wijesekera
33
Example Provisions

• 1. canDo(customer,loan,read) lt-
• Prov register(customer)
• 2. canDo(customer,loan,apply) lt-
• canDo(customer,loan,read),
• Prov signedLetterOfIntent(customer,loan)

Author D. Wijesekera
34
References

• A united framework for supporting multiple access
  control polices, Jajodia, Samarati, Sapino,
  Subrahmanian,ACM TODS, June 2001.
• Provisional authorizations, Sushil Jajodia,
  Michiharu Kudo, V. S. Subrahmanian, Proc. 1st
  Workshop on Security and Privacy in E-Commerce,
  Athens, Greece, November 2000
• Removing Permissions in the Flexible
  Authorization Framework, D. Wijesekera, S.
  Jajodia, F. Parise-Preceese and A. Hagestrom. In
  ACM TODS
• Obtaining Constraint Compliant Authorization
  Lists in the Flexible Authorization Framework, D.
  Wijesekera and S. Jajodia in submission
• Obligation Monitoring in Policy management, C.
  Bettini, S. Jajodia, X. S. Wang and D. Wijesekera
  in, Third international workshop on Policies for
  Distributed Systems and Networks, 2002
• Provisions and Obligations in Policy Rule
  Management and Security Applications. C. Bettini,
  S. Jajodia, X. S. Wang and D. Wijesekera. 28th
  VLDB Conference, Hong-Kong, China, 2002.
• Provisions and Obligations in Policy Rule
  Management. C. Bettini, S. Jajodia, X. S. Wang
  and D. Wijesekera. Under review, Journal of
  Systems and Network management

Author D. Wijesekera
35
Ponder

• Comprehensive overview at http//www-dse.doc.ic.ac
  .uk/Research/policies/ponder.shtml
• Developed by the Policy Research Group at
  Imperial College, UK
• Advantages
• Expressive but easy to use notation
• Domain based organisational structure
• Tool support available (?)
• Supports
• Authorization (including obligation)
• Delegation
• Information filtering
• Constraints
• Refrain policies
• Policy composition

36
Ponder Authorization Policy

• Subject users, principals, automated components
• Target accessed by the subject
• Domains grouping of objects and subjects
• Authorization policy defines the activities a
  member of the subject domain is permitted to
  perform on the set of objects in the target
  domain
• Supports negative authorization

37
Ponder Example

• inst (auth auth-) policyName
• subject lttypegt domain-Scope-Expression
• target lttypegt domain-Scope-Expression
• action action-list
• when constraints-Expression

38
Ponder Example cont.
inst (auth auth-) switchPolicyOps subject
/NetworkAdmin target ltPolicyTgt
/Nregion/switches action load(), remove(),
enable(), disable()
39
Delegation Policies

• Supports temporary transfer of access rights
• Must be tightly controlled by security policy
• Always associated with authorization policy
• Not intended for security administrators
• Constraints!
• New area delegation of obligations

40
Policy Development

• Policy maker
• Start with high-level policies
• Refine high-level policies to low-level policy
  specification
• determine resources required to satisfy the
  policy
• translate high-level policies into enforceable
  versions
• support analysis that verifies that lower level
  policies actually meet the needs of higher level
  ones.

41
Policy Refinement

• If there exists a set of policies Prs P1, P2
  .. Pn, such that the enforcement of a combination
  of these policies results in a system behaving in
  an identical manner to a system that is enforcing
  some base policy Pb, it can be said that Prs is a
  refinement of Pb. The set of policies Prs P1,
  P2 .. Pn is called the refined policy set.
  (Bandra)

Modified from slides of A. K Bandara
42
Policy Refinement Properties

• A policy refinement is complete iff
• Correct there is a subset of the refined policy
  set such that a conjunction of the subset is also
  a refinement of the base policy
• Consistent there are no conflicts between any of
  the policies in the refined policy set
• Minimal if removing any policy from the refined
  policy set causes the refinement to be incorrect

Modified from slides of A. K Bandara
43
Policies for Integrated, Heterogeneous Systems

• Providing Security and Interoperation of
  Heterogeneous Systems by S. Dawson, S. Qian, and
  P. Samarati in Distributed and Parallel
  Databases, vol. 8, no 1, January 2000
  (http//homes.dsi.unimi.it/samarati)
• Demand for information sharing
• Heterogeneous systems
• Local access control
• Need interoperation

44
(No Transcript)
45
Federated Databases

• Set of autonomous and (possibly) heterogeneous
  databases participating together
• Loosely coupled
• Tightly coupled
• Logical data storage
• Federated schema, data model, and federated users
  
• Access control
• Full authorization autonomy
• Medium authorization autonomy
• Low authorization autonomy

46
Mediation-based Databases

• Mediator provides controlled accesses to local
  databases (resources)
• No need for federated schema and multi-database
  language

47
Need

• Transparent access
• Autonomy
• Security

48
Mediation-based Interoperation

• Architecture
• Security policy specifications
• Application and source security lattices
• Correctness of specifications consistency,
  non-ambiguity, non-redundancy
• Access control
• Mediator accesses on virtual relation limiting
  the number of applicable rules
• Local sources on local data (labeled) and
  translated application user label