Access Control Models PDF

Access Control Models SIO André Zúquete Access types Physical access ꟷ Physical contact between a subject and the object of interest Facility, room, network, computer, storage device, authentication token, etc. ꟷ Out of scope of this course … Informatic or electronic access...

Access Control Models SIO André Zúquete Access types Physical access ꟷ Physical contact between a subject and the object of interest Facility, room, network, computer, storage device, authentication token, etc. ꟷ Out of scope of this course … Informatic or electronic access ꟷ Information-oriented contact between a subject and the object of interest Contact through request-response dialogs ꟷ Contact is mediated by Computers and networks Operating systems, applications, middleware, devices, etc. João Paulo Barraca, André Zúquete SIO 2 Access control policies Access Control Monitor Subject or Object Reference Monitor Definition log ꟷ Policies and mechanisms that mediate the access of a subject to an object Normal requirements ꟷ Authentication With some Level of Assurance (LoA) ꟷ Authorization policies AAA ꟷ Accountability → logging João Paulo Barraca, André Zúquete SIO 3 Access control: Subjects and Objects Both are digital entities Subjects are something exhibiting activity: ꟷ Processes ꟷ Computers Objects are targets of actions (resources): ꟷ Network elements ꟷ Stored data ꟷ CPU time ꟷ Memory ꟷ Processes ꟷ Computers ꟷ Networks An entity can be both subject & object João Paulo Barraca, André Zúquete SIO 4 Least privilege principle “Every program and every user of the system should operate using the least set of privileges necessary to complete the job” J. H. Saltzer, M. D. Schroeder, Proc. of The protection of information in computer systems, IEEE, 63(9) 1975 Privilege: ꟷ Authorization to perform a given task ꟷ Similar to access control clearance Subjects should have, at any time, the exact privileges required to their assigned tasks ꟷ Less privileges than the required create unsurpassable barriers ꟷ More privileges than the required create vulnerabilities Damage resulting from accidents or errors Potential interactions among privileged programs Misuse of a privileges Unwanted information flows "need-to-know" military restrictions João Paulo Barraca, André Zúquete SIO 5 Access control models Access control matrix ꟷ Matrix with all access rights for subjects relatively to objects ꟷ Conceptual organization João Paulo Barraca, André Zúquete SIO 6  O1 O2 … Om-1 Om Access control models S1 Access rights S2 ACL-based mechanisms … ꟷ ACL: Access Control List Sn-1 ꟷ Matrix column Sn List of access rights for specific subjects ꟷ Access rights can be positive or negative ꟷ Default subjects may often be used Usually, ACLs are stored along with objects ꟷ e.g., for file system objects João Paulo Barraca, André Zúquete SIO 7  O1 O2 … Om-1 Om Access control models S1 Access rights S2 Capability-based mechanisms … ꟷ Capability: unforgeable authorization token Sn-1 ꟷ Matrix row Sn ꟷ Contains object references and access rights Access granting ꟷ Transmission of capabilities between subjects ꟷ Mediated / non-mediated Usually, capabilities are kept by subjects ꟷ e.g., OAuth 2.0 access tokens João Paulo Barraca, André Zúquete SIO 8 Access control models: MAC and DAC Mandatory access control (MAC) ꟷ Fixed access control policy implemented by the access control monitor ꟷ Access control rights cannot be tailored by subjects or object owners Discretionary access control (DAC) ꟷ Some subjects can update rights granted or denied to other subjects for a given object ꟷ Usually this is granted to object owners and system administrators João Paulo Barraca, André Zúquete SIO 9 Access control models: Role-Based Access Control (RBAC) D.F. Ferraiolo and D.R. Kuhn, "Role Based Access Control“, 15th National Computer Security Conference, Baltimore, Oct. 1992 Not DAC or MAC ꟷ Roles are dynamically assigned to subjects ꟷ For access control what matters is the role played by the subject And not the subject’s identity Identity is mostly relevant for role access and logging Access control binds roles to (meaningful) operations ꟷ Operations are complex, meaningful system transactions Not the ordinary, low-level read/write/execute actions on individual objects ꟷ Operations can involve many individual, lower-level objects João Paulo Barraca, André Zúquete SIO 10 Access control models: RBAC role assignment All subject activity on the system is conducted through transactions ꟷ And transactions are allowed to specific roles ꟷ Thus, all active subjects are required to have some active role A subject can execute a transaction iff it has selected or been assigned a role which can use the transaction João Paulo Barraca, André Zúquete SIO 11 Access control models: RBAC role authorization A subject's active role must be authorized for the subject ꟷ In that case, the subject may assume the role Transaction authorization: ꟷ A subject can execute a transaction iff the transaction is authorized through the subject's role memberships ꟷ and there are no other constraints that may be applied across subjects, roles, and permissions João Paulo Barraca, André Zúquete SIO 12 RBAC rules 3 - Transaction 1 - Role authorization assignment 2 - Role authorization Transaction execution request (on behalf of a given role) From http://www.clker.com/clipart-24011.html From http://www.123rf.com/photo_12115593_three-dimensional-colored-toothed-wheels.html From http://www1.yorksolutions.net/Portals/115255/images/MyRoleIs.jpg João Paulo Barraca, André Zúquete SIO 13 RBAC variants RBAC 3 RBAC 0 ꟷ No role hierarchies RBAC 1 RBAC 2 ꟷ No role constraints RBAC 1 RBAC 0 ꟷ RBAC 0 w/ role hierarchies (privilege inheritance) RBAC 2 ꟷ RBAC 0 w/ role constraints (separation of duties) RBAC 3 ꟷ RBAC 1 + RBAC 2 João Paulo Barraca, André Zúquete SIO 14 NIST RBAC model Flat RBAC User-role review ꟷ Simple RBAC model w/ user-role review Which users can have a role? ? Role ՜ users Hierarchical RBAC Which roles can a user have? ? ꟷ Flat RBAC w/ role hierarchies (DAG or tree) User ՜ roles ꟷ General and restricted hierarchies Constraint RBAC Permission-role review ꟷ RBAC w/ role constraints for separation of duty Which permissions has a role? ? Role ՜ permissions Symmetric RBAC Which roles have a permission? ? ꟷ RBAC w/ permission-role review Permission ՜ roles João Paulo Barraca, André Zúquete SIO 15 Access control models: Context-Based Access Control (CBAC) Access rights have an historical context ꟷ The access rights cannot be determined without reasoning about past access operations Example: Stateful packet filter firewall D.F.C. Brewer and M.J. Nash, Example: Chines Wall policy "The Chinese Wall Security Policy “, ꟷ Conflict groups IEEE Symposium on Security and Privacy, 1989 ꟷ Access control policies need to address past accesses to objects from members of conflict groups João Paulo Barraca, André Zúquete SIO 16 Access control models: Attribute-Based Access Control (ABAC) Access control decisions are made based on attributes associated with relevant entities OASIS XACML architecture ꟷ Policy Administration Point (PAP) Where policies are managed ꟷ Policy Decision Point (PDP) Where authorization decisions are evaluated and issued ꟷ Policy Enforcement Point (PEP) Where resource access requests are intercepted and confronted with PDP’s decisions ꟷ Policy Information Point (PIP) Where the PDP gets external information João Paulo Barraca, André Zúquete SIO 17 XACML big picture João Paulo Barraca, André Zúquete SIO 18 XACML: Access control with PEP and PDP A subject sends a request ꟷ Which is intercepted by the Policy Enforcement Point (PEP) The PEP sends an authorization request to the Policy Decision Point (PDP) ꟷ With some subject’s attributes The PDP evaluates the authorization request against its policies and reaches a decision ꟷ Which is returned to the PEP ꟷ Policies are retrieved from a Policy Retrieval Point (PRP) ꟷ Useful attributes are fetched from Policy Information Points (PIP) ꟷ Policies are managed by the Policy Administration Point (PAP) João Paulo Barraca, André Zúquete SIO 19 Access control models: Break-the-glass In some scenarios it may be required to overcome the established access limitations ꟷ e.g., in a life-threatening situation In those cases, the subject may be presented with a break-the- glass decision upon a deny ꟷ Can overcome the deny at their own responsibility ꟷ Logging is fundamental to prevent abuses João Paulo Barraca, André Zúquete SIO 20 Separation of Duties R.A. Botha, J.H.P. Eloff, “Separation of duties for access control enforcement in workflow environments”, IBM Systems Journal, 2001 Fundamental security requirement for fraud and error prevention ꟷ Dissemination of tasks and associated privileges for a specific business process among multiple subjects ꟷ Often implemented with RBAC Damage control ꟷ Segregation of duties helps reducing the potential damage from the actions of one person ꟷ Some duties should not be combined into one position João Paulo Barraca, André Zúquete SIO 21 Segregation of duties ISACA (Inf. Systems Audit and Control Ass.) matrix guideline João Paulo Barraca, André Zúquete SIO 22 Information flow models Authorization is applied to data flows ꟷ Considering the data flow source and destination ꟷ Goal: avoid unwanted/dangerous information flows SL? SL? data flow src dst Src and Dst security-level attributes ꟷ Information flows should occur only between entities with given security level (SL) attributes ꟷ Authorization is given based on the SL attributes João Paulo Barraca, André Zúquete SIO 23 Multilevel security Subjects (or roles) act on different security levels ꟷ Levels do not intersect themselves ꟷ Levels have some partial order Hierarchy Lattice Levels are used as attributes of subjects and objects ꟷ Subjects: security level clearance ꟷ Objects: security classification Information flows & security levels ꟷ Same security level → authorized Still, restricted to a “need to know” ꟷ Different security levels → controlled João Paulo Barraca, André Zúquete SIO 24 MS levels: Military / Intelligence organizations U Typical levels R EU example ꟷ Top secret ꟷ EU TOP SECRET C ꟷ Secret S sensivity ꟷ EU SECRET ꟷ Confidential TS ꟷ EU CONFIDENTIAL ꟷ Restricted grows ꟷ EU RESTRICTED ꟷ Unclassified ꟷ EU COUNCIL / COMMISSION Portugal (NTE01, NTE04) NATO example ꟷ Muito Secreto ꟷ COSMIC TOP SECRET (CTS) ꟷ Secreto ꟷ NATO SECRET (NS) ꟷ Confidencial ꟷ NATO CONFIDENTIAL (NC) ꟷ Reservado ꟷ NATO RESTRICTED (NR) João Paulo Barraca, André Zúquete SIO 25 Security categories (or compartments) Top Secret C1 Self-contained information environments Secret ꟷ May span several security levels C2 Confidential Military environments ꟷ Military branches, military units C3 Restricted Civil environments Unclassified ꟷ Departments, organizational units An object can belong to different compartments and have a different security classification in each of them ꟷ (top-secret, crypto), (secret, weapon) João Paulo Barraca, André Zúquete SIO 26 Security labels Label = Category + Level Lv2, C2 Lb2 Relative order between labels ꟷ Lb1 ≤ Lb2  C1  C2  Lv1 ≤ Lv2 Lv1, C1 Lb1 Labels form a lattice TS, all TS, C1 TS, C2 S, all S, C1 S, C2 C, all C, C1 C, C2 U, all João Paulo Barraca, André Zúquete SIO 27 Bell-La Padula MLS Model D. Elliott Bell, Leonard J. La Padula, "Secure Computer Systems: Mathematical Foundations”, MITRE Tech. Report 2547, Vol. I, 1973 Access control policy for controlling information flows ꟷ Addresses data confidentiality and access to classified information ꟷ Addresses disclosure of classified information Object access control is not enough One needs to restrict the flow of information from a source to authorized destinations Combines access control matrixes with MLS João Paulo Barraca, André Zúquete SIO 28 Bell-La Padula MLS Model: secure state transitions O5 Simple security condition (no read up) W W ꟷ S can read O iff L(S)  L(O) O4 SB R R *-property (no write down) ꟷ S can write O iff L(S) ≤ L(O) O3 ꟷ aka confinement property W W Discretionary Security Property O2 R SA ꟷ DAC-based access control within the same security level R O1 João Paulo Barraca, André Zúquete SIO 29 Biba Integrity Model K. J. Biba, "Integrity Considerations for Secure Computer Systems", MITRE Technical Report 3153, The Mitre Corporation, April 1977 Access control policy for enforcing integrity control over data flows ꟷ Uses integrity levels, not security levels ꟷ Similar to Bell-La Padula, with inverse rules O3 R Simple Integrity Property (no read down) R ꟷ S can read O iff I(S) ≤ I(O) O2 S W W Integrity *-Property (no write up) O1 ꟷ S can write O iff I(S)  I(O) 30 João Paulo Barraca, André Zúquete SIO 30 Windows mandatory integrity control Allows mandatory (priority and critical) access control enforcement prior to evaluate DACLs ꟷ If access is denied, DACLs are not evaluated ꟷ If access is allowed, DACLs are evaluated João Paulo Barraca, André Zúquete SIO 31 Windows mandatory integrity control: integrity labels Untrusted Low (or AppContainer) Medium Medium Plus High System Protected Process João Paulo Barraca, André Zúquete SIO 32 Windows mandatory integrity control: users and processes User integrity level ꟷ Medium: standard users ꟷ High: elevated users Process integrity level ꟷ The minimum associated to the owner and the executable file ꟷ User processes usually are Medium or High Except if executing Low-labeled executables ꟷ Service processes: High João Paulo Barraca, André Zúquete SIO 33 Windows mandatory integrity control Securable objects mandatory label ꟷ NO_WRITE_UP (default) ꟷ NO_READ_UP ꟷ NO_EXECUTE_UP João Paulo Barraca, André Zúquete SIO 34