Πανεπιστήμιο Αιγαίου Τμήμα μηχανικών πληροφοριακών & επικοινωνιακών συστημάτων Ασφάλεια Συστημάτων Πολιτικές 1
Overview Access Control Models Security Policy Definition Trust Confidentiality Policy Integrity Policy Other types of Policy Policy Languages 2
3/5 Layers analysis Idealized Enforceable (Approximate) Codeable 3
Types of Access Control Discretionary Access Control (DAC) individual user sets access control mechanism to allow or deny access to an object Mandatory Access Control (MAC, rule-based) system mechanism controls access to object, and individual cannot alter that access Originator Controlled Access Control (ORCON) originator (creator) of information controls who can access information 4
ORCON Problem: organization creating document wants to control its dissemination Example: Secretary of Agriculture writes a memo for distribution to her immediate subordinates, and she must give permission for it to be disseminated further. This is originator controlled (here, the originator is a person). 5
Requirements Subject s S marks object o O as ORCON on behalf of organization X. X allows o to be disclosed to subjects acting on behalf of organization Y with the following restrictions: 1. o cannot be released to subjects acting on behalf of other organizations without X s permission; and 2. Any copies of o must have the same restrictions placed on it. 6
DAC Fails Owner can set any desired permissions This makes 2 unenforceable 7
MAC Fails First problem: category explosion Category C contains o, X, Y, and nothing else. If a subject y Y wants to read o, x X makes a copy o. Note o has category C. If y wants to give z Z a copy, z must be in Y by definition, it s not. If x wants to let w W see the document, need a new category C containing o, X, W. Second problem: abstraction MAC classification, categories centrally controlled, and access controlled by a centralized policy ORCON controlled locally 8
Combine Them The owner of an object cannot change the access controls of the object. When an object is copied, the access control restrictions of that source are copied and bound to the target of the copy. These are MAC (owner can t control them) The creator (originator) can alter the access control restrictions on a per-subject and perobject basis. This is DAC (owner can control it) 9
RBAC Access depends on function, not identity Example: Allison, bookkeeper for Math Dept, has access to financial records. She leaves. Betty hired as the new bookkeeper, so she now has access to those records The role of bookkeeper dictates access, not the identity of the individual. 10
ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE ASSIGNMENT USERS ROLES PERMISSIONS... SESSIONS CONSTRAINTS 11
Definitions Role r: collection of job functions trans(r): set of authorized transactions for r Active role of subject s: role s is currently in actr(s) Authorized roles of a subject s: set of roles s is authorized to assume authr(s) canexec(s, t) iff subject s can execute transaction t at current time 12
Axioms Let S be the set of subjects and T the set of transactions. Rule of role assignment: ( s S)( t T) [canexec(s, t) actr(s) ]. If s can execute a transaction, it has a role This ties transactions to roles Rule of role authorization: ( s S) [actr(s) authr(s)]. Subject must be authorized to assume an active role (otherwise, any subject could assume any role) 13
Axiom Rule of transaction authorization: S)( t T) [canexec(s, t) t trans(actr(s))]. ( s If a subject s can execute a transaction, then the transaction is an authorized one for the role s has assumed 14
Separation of Duty Let r be a role, and let s be a subject such that r auth(s). Then the predicate meauth(r) (for mutually exclusive authorizations) is the set of roles that s cannot assume because of the separation of duty requirement. Separation of duty: ( r 1, r 2 R) [ r 2 meauth(r 1 ) [ ( s S) [ r 1 authr(s) r 2 authr(s) ] ] ] 15
Key Points Hybrid policies deal with both confidentiality and integrity Different combinations of these ORCON model neither MAC nor DAC Actually, a combination RBAC model controls access based on functionality 16
Key Points Is RBAC MAC or DAC or neither? RBAC can be configured to do MAC RBAC can be configured to do DAC RBAC is policy neutral RBAC is neither MAC nor DAC! 17
Attribute Based Access Control (ABAC) Subject Attributes Associated with a subject (user, application, process) that defines the identity and characteristics of the subject E.g. identifier, name, job title, role Resource Attributes Associated with a resource (web service, system function, or data) Environment Attributes Describes the operational, technical, or situational environment or context in which the information access occurs E.g. current date time, current threat level, network security classification 18
ABAC Policy Formulation 1. S, R, and E are subjects, resources, and environments, respectively; 2. SA k (1 k K), RA m (1 m M), and EA n (1 n N) are the pre-defined attributes for subjects, resources, and environments, respectively; 3. ATTR(s), ATTR(r), and ATTR(e) are attribute assignment relations for subject s, resource r, and environment e, respectively: ATTR( s) SA SA... SA ATTR( r ) ATTR( e) RA EA 1 1 1 RA EA 2 2 2... EA K... RA M N 19
ABAC Policy Formulation (Cont d) 4. We also use the function notation for the value assignment of individual attributes. For example: Role(s) = Service Consumer ServiceOwner(r) = XYZ, Inc. CurrentDate(e) = 01-23-2005 5. In the most general form, a Policy Rule that decides on whether a subject s can access a resource r in a particular environment e, is a Boolean function of s, r, and e s attributes: Rule X : can _ access( s, r, e) f ( ATTR( s), ATTR( r ), ATTR( e)) The access control decision process in essence amounts to the evaluation of applicable policy rules in the policy store. 20
Policy Rule Examples Modeling conventional RBAC rules: User with role Manager may access the ApprovePurchase web service Rule 1 : can _ access( s, r, e) Role( s) = ' Manager ' Name( r ) = ' ApprovePurchase' Modeling richer access control semantics A resource may only be accessed by its owners Rule UserID( s) = OwnerID( r ) Modeling mandatory access control Classified files can be accessed by users with equal or higher clearance Rule 3 : can _ access( s, r, e) Clearance( s) 2 : can _ access( s, r, e) Classification( r ) 21
Online Entertainment Store Example Inspired by [Al-Kahtani & Sandhu 2003]: Streams movies to customers for a flat monthly fee Access Control Requirements Basic requirement: access control is based on user s age and the movies content ratings (R, PG-13, G) Advanced requirement: Suppose the store introduces membership classes (Premium, Regular) and would like to enforce a new policy that only Premium users can view New Releases Using RBAC: Basic policy: Need to create roles such as Adult, Juvenile, Child Advanced policy: Roles and permissions need to be doubled (e.g., Adult Premium, Adult Regular, ) I.e., given K subject attributes, total roles could be: K Range(SAk ) 1 22
Online Entertainment Store Example (Cont d) Using ABAC: Basic policy: No need to define explicit roles R1 : can _ access( u, m, e) ( Age( u) 21 Rating( m) { R, PG13, G}) ( 21 Age( u) 13 Rating( m) { PG13, G)} ( Age( u) < 13 Rating( m) { G}) Advanced policy: Only need to add a second rule and combine the two R2 : can _ access( u, m, ( MemberType( u) ( MemberType( u) MovieType( m) {' NewRelease' }) R3 : can _ access( u, m, e) = ' Premium' ) = ' Regular ' e) R1 R2 23
Comparison with (Pure) RBAC Models Inherent limitation in RBAC is the single dimension of roles Finer-grained access control policies often involve multiple subject and object attributes As more attributes are involved, number of roles and permissions needed to encode these attributes will grow exponentially, thereby making User Assignments and Permission Assignments difficult to manage Various research work has tried to extend the basic RBAC model, however most are constrained by the inherent limitations of RBAC Rule-based RBAC [Al-Kahtani & Sandhu 2003], Inclusion of subject-resource relationship [Barkley,Beznosov & Uppal 1999] Use-condition policies specified by stakeholders [Johnston et al. 1998] [Thompson et al. 1999] 24
Comparison with (Pure) RBAC Models (Cont d) RBAC usually needs centralized management of user-to-role and permission-to-role assignments Not well suited for a highly distributed environment Even more difficult when subject and resource belong to different security domains! RBAC doesn t consider environment attributes explicitly E.g., continuing with the previous example, suppose an additional requirement states Regular customers in general may not watch new releases, but may be allowed in promotional periods In ABAC, a new rule can be easily added, involving an environment attribute CurrentDate(e) RBAC doesn t handle MAC In ABAC, security labels can be treated naturally as attributes 25
ABAC Authorization Architecture The XACML authorization architecture readily supports ABAC Agnostic to the actual representation and formulation of policies Subject Resource PEP Subject AA Resource AA PDP ABAC Policy Authority Environment AA AA: Attribute Authority 26
Implementation Scenario Applying ABAC to Secure Web Services SOAP Client SA SOAP Msg 1 3 SOAP Message Handler Service Provider Web Service Identity Store SA EA 2 Policy Decision Service RA Service Registry Policy Admin. Service Policy Store Attribute & Policy Services 27
Towards End-to-End Attribute Based Information Security The ABAC policy and architecture models, though very powerful, only focus on authorization of requests from information consumers to providers The end-to-end security architecture requires more than just the access control model To utilize ABAC to its full potential, we need a systematic methodology around how attributes are managed throughout their life cycle: Attribute definition and provisioning ; Cryptographic mechanisms to bind attributes to subjects and objects they describe; Discovery mechanisms for attribute definitions and attribute assignments; A feedback loop through which attribute usage can be monitored and audited 28
Attribute Management Lifecycle Methodology Attribute Provisioning Attribute Binding Monitor & Feedback Attribute Based Information Security Attribute Discovery Attribute Based Access Control 29
Key points The ABAC model brings many advantages over traditional identity or role based models Intuitive to model and manage real-world access control policies More flexible and more powerful to represent complex, fine-grained access control semantics, which is especially suitable for the dynamic SOA / web services environment Management of security information is spread over a number of Attribute and Policy Authorities, possibly across organizational boundaries suitable for large-scale information sharing Reduces overall system complexity, allowing different system components (user directory, service registry, policy server, etc.) to focus on their respective administrative tasks To utilize the ABAC model to its full potential, many aspects of the entire attribute management life cycle needs to be considered, such as attribute provisioning, binding, discovery, and feedback loop All are potential research and engineering topics to be explored 30
Security Policy Policy partitions system states into: Authorized (secure) These are states the system can enter Unauthorized (nonsecure) If the system enters any of these states, it s a security violation Secure system Starts in authorized state Never enters unauthorized state 31
Confidentiality X set of entities, I information I has confidentiality property with respect to X if no x X can obtain information from I I can be disclosed to others Example: X set of students I final exam answer key I is confidential with respect to X if students cannot obtain final exam answer key 32
Integrity X set of entities, I information I has integrity property with respect to X if all x X trust information in I Types of integrity: trust I, its conveyance and protection (data integrity) I information about origin of something or an identity (origin integrity, authentication) I resource: means resource functions as it should (assurance) 33
Availability X set of entities, I resource I has availability property with respect to X if all x X can access I Types of availability: traditional: x gets access or not quality of service: promised a level of access (for example, a specific level of bandwidth) and not meet it, even though some access is achieved 34
Policy Models Abstract description of a policy or class of policies Focus on points of interest in policies Security levels in multilevel security models Separation of duty in Clark-Wilson model Conflict of interest in Chinese Wall model 35
Types of Security Policies Military (governmental) security policy Policy primarily protecting confidentiality Commercial security policy Policy primarily protecting integrity Confidentiality policy Policy protecting only confidentiality Integrity policy Policy protecting only integrity 36
Integrity and Transactions Begin in consistent state Consistent defined by specification Perform series of actions (transaction) Actions cannot be interrupted If actions complete, system in consistent state If actions do not complete, system reverts to beginning (consistent) state 37
Trust Administrator installs patch 1. Trusts patch came from vendor, not tampered with in transit 2. Trusts vendor tested patch thoroughly 3. Trusts vendor s test environment corresponds to local environment 4. Trusts patch is installed correctly 38
Trust in Formal Verification Gives formal mathematical proof that given input i, program P produces output o as specified Suppose a security-related program S formally verified to work with operating system O What are the assumptions? 39
Trust in Formal Methods 1. Proof has no errors Bugs in automated theorem provers 2. Preconditions hold in environment in which S is to be used 3. S transformed into executable S whose actions follow source code Compiler bugs, linker/loader/library problems 4. Hardware executes S as intended Hardware bugs (Pentium f00f bug, for example) 40
Question Policy disallows cheating Includes copying homework, with or without permission CS class has students do homework on computer Anne forgets to read-protect her homework file Bill copies it Who cheated? Anne, Bill, or both? 41
Answer Part 1 Bill cheated Policy forbids copying homework assignment Bill did it System entered unauthorized state (Bill having a copy of Anne s assignment) If not explicit in computer security policy, certainly implicit Not credible that a unit of the university allows something that the university as a whole forbids, unless the unit explicitly says so 42
Answer Part 2 Anne didn t protect her homework Not required by security policy She didn t breach security If policy said students had to readprotect homework files, then Anne did breach security She didn t do this 43
Mechanisms Entity or procedure that enforces some part of the security policy Access controls (like bits to prevent someone from reading a homework file) Disallowing people from bringing CDs and floppy disks into a computer facility to control what is placed on systems 44
Key Points Policies describe what is allowed Mechanisms control how policies are enforced Trust underlies everything 45
Confidentiality Policies What is a confidentiality model Goals of Confidentiality Model Bell-LaPadula Model Informally Example Instantiation 46
Confidentiality Policy Goal: prevent the unauthorized disclosure of information Deals with information flow Integrity incidental Multi-level security models are bestknown examples Bell-LaPadula Model basis for many, or most, of these 47
Bell-LaPadula Model, Step 1 Security levels arranged in linear ordering Top Secret: highest Secret Confidential Unclassified: lowest Levels consist of security clearance L(s) Objects have security classification L(o) 48
Example security level subject object Top Secret Tamara Personnel Files Secret Samuel E-Mail Files Confidential Claire Activity Logs Unclassified Ulaley Telephone Lists Tamara can read all files Claire cannot read Personnel or E-Mail Files Ulaley can only read Telephone Lists Slide #5-49
Reading Information Information flows up, not down Reads up disallowed, reads down allowed Simple Security Condition (Step 1) Subject s can read object o iff L(o) L(s) and s has permission to read o Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission) Sometimes called no reads up rule 50
Writing Information Information flows up, not down Writes up allowed, writes down disallowed *-Property (Step 1) Subject s can write object o iff L(s) L(o) and s has permission to write o Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission) Sometimes called no writes down rule 51
Basic Security Theorem, Step 1 If a system is initially in a secure state, and every transition of the system satisfies the simple security condition, step 1, and the *-property, step 1, then every state of the system is secure Proof: induct on the number of transitions 52
Bell-LaPadula Model, Step 2 Expand notion of security level to include categories Security level is (clearance, category set) Examples ( Top Secret, { NUC, EUR, ASI } ) ( Confidential, { EUR, ASI } ) ( Secret, { NUC, ASI } ) 53
Levels and Lattices (A, C) dom (A, C ) iff A A and C C Examples (Top Secret, {NUC, ASI}) dom (Secret, {NUC}) (Secret, {NUC, EUR}) dom (Confidential,{NUC, EUR}) (Top Secret, {NUC}) dom (Confidential, {EUR}) Let C be set of classifications, K set of categories. Set of security levels L = C K, dom form lattice lub(l) = (max(a), C) glb(l) = (min(a), ) 54
Levels and Ordering Security levels partially ordered Any pair of security levels may (or may not) be related by dom dominates serves the role of greater than in step 1 greater than is a total ordering, though 55
Reading Information Information flows up, not down Reads up disallowed, reads down allowed Simple Security Condition (Step 2) Subject s can read object o iff L(s) dom L(o) and s has permission to read o Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission) Sometimes called no reads up rule 56
Writing Information Information flows up, not down Writes up allowed, writes down disallowed *-Property (Step 2) Subject s can write object o iff L(o) dom L(s) and s has permission to write o Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission) Sometimes called no writes down rule 57
Basic Security Theorem, Step 2 If a system is initially in a secure state, and every transition of the system satisfies the simple security condition, step 2, and the *- property, step 2, then every state of the system is secure Proof: induct on the number of transitions In actual Basic Security Theorem, discretionary access control treated as third property, and simple security property and *-property phrased to eliminate discretionary part of the definitions but simpler to express the way done here. 58
Problem Colonel has (Secret, {NUC, EUR}) clearance Major has (Secret, {EUR}) clearance Major can talk to colonel ( write up or read down ) Colonel cannot talk to major ( read up or write down ) Clearly absurd! 59
Solution Define maximum, current levels for subjects maxlevel(s) dom curlevel(s) Example Treat Major as an object (Colonel is writing to him/her) Colonel has maxlevel (Secret, { NUC, EUR }) Colonel sets curlevel to (Secret, { EUR }) Now L(Major) dom curlevel(colonel) Colonel can write to Major without violating no writes down Does L(s) mean curlevel(s) or maxlevel(s)? Formally, we need a more precise notation 60
Integrity Policies Overview Requirements Biba s models Clark-Wilson model 61
Requirements of Policies (Lipner 1982) 1. Users will not write their own programs, but will use existing production programs and databases. 2. Programmers will develop and test programs on a nonproduction system; if they need access to actual data, they will be given production data via a special process, but will use it on their development system. 3. A special process must be followed to install a program from the development system onto the production system. 4. The special process in requirement 3 must be controlled and audited. 5. The managers and auditors must have access to both the system state and the system logs that are generated. 62
Basic Principles Separation of duty Separation function Auditing 63
Intuition for Integrity Levels The higher the level, the more confidence That a program will execute correctly That data is accurate and/or reliable Note relationship between integrity and trustworthiness Important point: integrity levels are not security levels 64
Clark-Wilson Integrity Model Integrity defined by a set of constraints Data in a consistent or valid state when it satisfies these Example: Bank D today s deposits, W withdrawals, YB yesterday s balance, TB today s balance Integrity constraint: D + YB W Well-formed transaction move system from one consistent state to another Issue: who examines, certifies transactions done correctly? 65
Entities CDIs: constrained data items Data subject to integrity controls UDIs: unconstrained data items Data not subject to integrity controls IVPs: integrity verification procedures Procedures that test the CDIs conform to the integrity constraints TPs: transaction procedures Procedures that take the system from one valid state to another 66
Certification Rules 1 and 2 CR1 When any IVP is run, it must ensure all CDIs are in a valid state CR2 For some associated set of CDIs, a TP must transform those CDIs in a valid state into a (possibly different) valid state Defines relation certified that associates a set of CDIs with a particular TP Example: TP balance, CDIs accounts, in bank example 67
Enforcement Rules 1 and 2 ER1 The system must maintain the certified relations and must ensure that only TPs certified to run on a CDI manipulate that CDI. ER2 The system must associate a user with each TP and set of CDIs. The TP may access those CDIs on behalf of the associated user. The TP cannot access that CDI on behalf of a user not associated with that TP and CDI. System must maintain, enforce certified relation System must also restrict access based on user ID (allowed relation) 68
Users and Rules CR3 The allowed relations must meet the requirements imposed by the principle of separation of duty. ER3 The system must authenticate each user attempting to execute a TP Type of authentication undefined, and depends on the instantiation Authentication not required before use of the system, but is required before manipulation of CDIs (requires using TPs) 69
Logging CR4 All TPs must append enough information to reconstruct the operation to an append-only CDI. This CDI is the log Auditor needs to be able to determine what happened during reviews of transactions 70
Handling Untrusted Input CR5 Any TP that takes as input a UDI may perform only valid transformations, or no transformations, for all possible values of the UDI. The transformation either rejects the UDI or transforms it into a CDI. In bank, numbers entered at keyboard are UDIs, so cannot be input to TPs. TPs must validate numbers (to make them a CDI) before using them; if validation fails, TP rejects UDI 71
Separation of Duty In Model ER4 Only the certifier of a TP may change the list of entities associated with that TP. No certifier of a TP, or of an entity associated with that TP, may ever have execute permission with respect to that entity. Enforces separation of duty with respect to certified and allowed relations 72
Comparison With Requirements 1. Users can t certify TPs, so CR5 and ER4 enforce this 2. Procedural, so model doesn t directly cover it; but special process corresponds to using TP No technical controls can prevent programmer from developing program on production system; usual control is to delete software tools 3. TP does the installation, trusted personnel do certification 73
Comparison With Requirements 4. CR4 provides logging; ER3 authenticates trusted personnel doing installation; CR5, ER4 control installation procedure New program UDI before certification, CDI (and TP) after 5. Log is CDI, so appropriate TP can provide managers, auditors access Access to state handled similarly 74
Hybrid Policies Chinese Wall Model Focuses on conflict of interest CISS Policy Combines integrity and confidentiality 75
Chinese Wall Model Problem: Tony advises American Bank about investments He is asked to advise Toyland Bank about investments Conflict of interest to accept, because his advice for either bank would affect his advice to the other bank 76
Organization Organize entities into conflict of interest classes Control subject accesses to each class Control writing to all classes to ensure information is not passed along in violation of rules Allow sanitized data to be viewed by everyone 77
Definitions Objects: items of information related to a company Company dataset (CD): contains objects related to a single company Written CD(O) Conflict of interest class (COI): contains datasets of companies in competition Written COI(O) Assume: each object belongs to exactly one COI class 78
Example Bank COI Class Gasoline Company COI Class Bank of America Shell Oil Standard Oil Citibank Bank of the W est Union 76 ARCO 79
Temporal Element If Anthony reads any CD in a COI, he can never read another CD in that COI Possible that information learned earlier may allow him to make decisions later Let PR(S) be set of objects that S has already read 80
CW-Simple Security Condition s can read o iff either condition holds: 1. There is an o such that s has accessed o and CD(o ) = CD(o) Meaning s has read something in o s dataset 2. For all o O, o PR(s) COI(o ) COI(o) Meaning s has not read any objects in o s conflict of interest class Ignores sanitized data (see below) Initially, PR(s) =, so initial read request granted 81
Sanitization Public information may belong to a CD As is publicly available, no conflicts of interest arise So, should not affect ability of analysts to read Typically, all sensitive data removed from such information before it is released publicly (called sanitization) Add third condition to CW-Simple Security Condition: 3. o is a sanitized object 82
Writing Anthony, Susan work in same trading house Anthony can read Bank 1 s CD, Gas CD Susan can read Bank 2 s CD, Gas CD If Anthony could write to Gas CD, Susan can read it Hence, indirectly, she can read information from Bank 1 s CD, a clear conflict of interest 83
CW-*-Property s can write to o iff both of the following hold: 1. The CW-simple security condition permits s to read o; and 2. For all unsanitized objects o, if s can read o, then CD(o ) = CD(o) Says that s can write to an object if all the (unsanitized) objects it can read are in the same dataset 84
Compare to Bell-LaPadula Fundamentally different CW has no security labels, B-LP does CW has notion of past accesses, B-LP does not Bell-LaPadula cannot track changes over time Susan becomes ill, Anna needs to take over C-W history lets Anna know if she can No way for Bell-LaPadula to capture this The Bell-Lpadula model cannot emulate the CW Model 85
Compare to Clark-Wilson Clark-Wilson Model covers integrity, so consider only access control aspects If subject is a specific person and includes all processes the subject executes, then consistent with Clark-Wilson Model 86
S&P Policy Languages A complete policy management framework must support policy specification, policy analysis, verification and validation and enforcement. More precisely it must include a policy specification language that allows the expression of policies, built-in support and authoring tool for policy creation (policy editors and policy definition environments, like syntax checkers), verification, consistency analysis (and redundancy) and conflict detection and resolution (in case of multiple policies, to ensure the correctness and quality of the policies specified). For conflict resolution and detection there are rule and policy combination algorithms. a policy deployment model for the distribution of policies into enforcement points. a policy analysis mechanism for making the correct policy enforcement decisions (this usually a distinct component called decision engine). a policy monitoring and enforcement mechanism that facilitates the identification and execution of policy actions. Generally, there are (at least) two main levels of policy definition: A Low level Policy language that it is specified to match system capabilities. A High level Policy that it depends on the end-goal and it is relatively independent of the underlying technology. 87
High-level policy language Formalism-based Languages A graph-based policy language states the policy in terms of a graph. A petrinet-based policy language expresses the valid (i.e. policy compliant behaviour) of a system by means of a petri net. A logic-based policy language states the policy in terms of formulas of an appropriate logic such as first-order logic or firstorder linear temporal logic. Non-formalism-based languages A rule-based policy language A non-formalism-based property declaration policy language. A programming language based policy language. Passive/active languages. Declarative/imperative languages. 88
S&P Policy Languages - Examples Platform for Privacy Preferences (P3P), A P3P Preference Exchange Language (APPEL), Customer Profile Exchange (CPExchange), Privacy Rights Markup Language (PRML), XML Access Control Language (XACL), Platform for Enterprise Privacy Practices (E-P3P), Security Assertion Markup Language (SAML), Rei, extensible Access Control Markup Language (XACML), Enterprise Privacy Authorization Language (EPAL), X-Path Based Preference Language (XPref), Declarative Privacy Authorization Language (DPAL), Geographic Location / Privacy (Geopriv). 89
S&P Policy Languages - Examples 90