11

Restricting key use with XACML* for access controlRestricting key use with XACML* for access control

* Zack’-a-mul

22

IntroductionIntroduction

Hardware based encryption protects mostly against physical theft or HW repurposing.

I don’t think XACML is natural for storage hardware, as most context attributes are not available.

Insider protection may require access control at O/S and/or application layers.

There is a trend to externalize access rules from the application image to allow central change without requiring repackaging/reinstalling the app. Reduce cost of changes Consistent application Combining these with encryption keys is a natural

association Enable audit

33

Example Use case - EKM client on host acts as a local key services provider

Example Use case - EKM client on host acts as a local key services provider

Manages EKM server communication Manages Key caching, discovery and use of any

onboard capabilities (HSM, crypto accelerator, etc.)

Manages Logs and events for uploading May assume responsibility for other key policies XACML might be used to express restrictions

which start beyond the EKM client. May provide keys or crypto services to apps Could shim in, or expose simple API for local

apps While it is the authorized recipient of keys from

EKM, subsequent distribution or use of them is restricted by local context only available at request time.

44

Sample access controlSample access control

Patient medical care application has PII encrypted by a key from the EKM “The primary physician can have any of her patients'

medical records sent to a specialist in the same practice.”

“Anyone can view their own encrypted 401K information, but nobody else’s”

Only oracle.exe with DataVault can read .dbs files

Only abc.exe can access particular band on particular encrypting device.

55

Usage policies for end point access controlUsage policies for end point access control

XACML is Oasis standard to express enterprise security policies with a common XML based policy language

http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf 103 pgs.

Example: Provide this key if the running exe is backup.exe and its signature is in this set of signatures and the user id is Sysadmin and attribute “dept” [obtained from backup.exe] = “HRbackup”

66

Common termsCommon terms

PAP – Policy Administration Point. This would be the EKM

PDP - Policy Decision Point. An entity that evaluates an access request against one or more policies to produce an access decision. This is essentially a rules engine.

PEP – Policy Enforcement Point. An entity that enforces access control for one or more resources. When a resource access is attempted, a PEP sends an access request describing the attempted access to a PDP. The PDP returns an access decision that the PEP then enforces.

Policy – A set of rules indicating which subjects are permitted to access which resources using which actions under which conditions. XACML has two different schema elements used for policies: <Policy> and <PolicySet>. A <Policy> contains actual access control rules.

77

Typical XACML componentsTypical XACML components

PEP

contexthandler

4. requestnotification

PIP

6. attributequery

11. responsecontext

1. policy

8. attribute

environment

resource

subjects

7b. environmentattributes

PAP

obligationsservice

13. obligations

PDP

accessrequester

2. access request

9. resourcecontent

3. request 12. response

7c. resourceattributes

7a. subjectattributes

5. attributequeries

10. attributes

88

Factors in rulesFactors in rules

Common notion of SUBJECT, RESOURCE, ACTION Attributes used in rules

Must be able to define factors applicable to end points

Rules have different combination algorithms, such as first applicable [IMHO, Sufficient], or deny-overrides.

When a rule fires, the PEP must execute the rule’s “Obligations”. From our focus, may be things such as Decrypt Audit

If you can’t execute an obligation, service denied

99

Basic role of a PEP (Policy Enforcement Point)Basic role of a PEP (Policy Enforcement Point)

An application functions in the role of the PEP if it guards access to a set of resources and asks the PDP for an authorization decision.

Recommend “Deny-biased” PEP approach If the decision is "Permit", then the PEP SHALL permit access. If obligations accompany the decision, then the PEP SHALL permit access only if it understands and it can and will discharge those obligations.

All other decisions SHALL result in the denial of access. Note: other actions, e.g. consultation of additional PDPs,

reformulation/resubmission of the decision request, etc., are not prohibited..

PEP might be a consuming application or the EKM client

1010

Implementation issuesImplementation issues

Five open source implementations available – Two announced in the last month

Numerous Product Statements We may want to define a subset more easily

implemented without full blown PDP Federated Policy Administration may be overkill

– Multiple policies applicable to same situation – Combining rules to resolve conflicts Evaluating complex rules against raw XML is slow

Many optimization opportunities – Policy encoding – Request context – Partial evaluation – Decision Caching