1. 11 Restricting key use with XACML* for access control * Zack’-a-mul

2. 22 Introduction  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

3. 33 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.

4. 44 Sample 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.

5. 55 Usage 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. http://docs.oasis-open.org/xacml/2.0/access_control- xacml-2.0-core-spec-os.pdf  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”

6. 66 Common 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: and. A contains actual access control rules.

7. 77 Typical XACML components

8. 88 Factors 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

9. 99 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

10. 10 Implementation 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