Access Control Matrix and Related Access Control Models (DAC, MAC, RBAC, TBAC, UDM) - Study Notes

Access Control Matrix and Related Access Control Models

  • Information and context

    • Access Control Matrix (ACM) is a protection model used in both operating systems and databases to describe allowed accesses using a matrix.
    • The ACM was first proposed by Butler Lampson (1971); Graham and Denning refined it and the course material follows their version.
    • A protection system describes the conditions under which the system is secure; the ACM is a precise tool to describe the current protection state.

  • Protection state and state transitions

    • The state of a system is the collection of current values of all memory locations, secondary storage, and all registers and components.
    • The protection state is the subset of this collection that deals with protection.
    • An access control matrix is a tool to describe the current protection state.
    • Let P be the set of all possible protection states. A subset Q ⊆ P consists of exactly those states in which the system is authorized to reside.
    • If the system state is in Q, the system is secure; if in P − Q, the system is NOT secure.
    • The security policy characterizes the states in Q; the security mechanism prevents the system from entering states in P − Q.
    • The ACM is the most precise model for describing a protection state, characterizing the rights of each subject with respect to every other entity. As the system changes, protection state changes; state transitions occur when commands change the state. In practice, most real-system operations cause multiple state transitions (reading, loading, altering, execution, etc.).
    • Example: a program that changes a variable to 0 does not usually alter the protection state; if the variable affects privileges of a process, then the program does alter protection state and must be accounted for in transitions.

  • ACM structure and notation

    • Entities in ACM:
    • Objects O: the set of protected resources (files, directories, etc.).
    • Subjects S: active objects such as processes and users.
    • The relationship is captured by a matrix A with rights drawn from a set of rights R in each entry a[s, o], where s ∈ S and o ∈ O.
    • Entry meaning: the subject s has the set of rights a[s, o] over the object o.
    • Notation: a[s,o] ⊆ Ra[s, o] \,\subseteq\, R
    • The set of protection states is represented by the triple (S, O, A).
    • Example: In UNIX, rights include read, write, and execute; their meaning depends on the type of object (file, directory, or process).

  • UNIX rights (example of ACM in practice)

    • Files: read = view contents, write = modify contents, execute = run/execute the file depending on type.
    • Directories: read = list contents; write = create/rename/delete entries; execute = access files or subdirectories within the directory.
    • Processes: read = receive signals; write = send signals; execute = execute process as a subprocess.
    • Superuser (root) can access any local file regardless of owner permissions; however, even the superuser faces limits (e.g., cannot alter a directory using file-operations; must use directory-specific system calls to create, rename, delete).

  • Protection state, policy, and mechanism (recap)

    • The protection state is the current ACM state, i.e., the current (S, O, A) mapping.
    • The security policy defines which states are allowed (Q ⊆ P).
    • The security mechanism enforces and prevents transitions outside the allowed set (P − Q).

  • Access control: basic elements

    • subject: an entity capable of accessing objects (often a process or user).
    • Typically three classes of subjects: owner, group, world.
    • object: the resource to which access is controlled (files, directories, devices, etc.).
    • access right: the way a subject may access an object (e.g., read, write, execute, delete, create, search).

  • Discretionary vs Mandatory vs Role-based vs Task-based models (overview)

    • Discretionary Access Control (DAC): access control is at the discretion of the resource owner.
    • Mandatory Access Control (MAC): access control is enforced by the system mechanism; owners cannot override the controls.
    • Role-Based Access Control (RBAC): access rules are based on roles assigned to users; permissions are tied to roles.
    • Task-Based Access Control (TBAC): access is modeled from a task-oriented perspective rather than subject-object pairs.
    • Unified models and other forms (e.g., lattice-based MAC, etc.) may be used to reason about access decisions in more complex environments.

  • Discretionary – based Model (DAC)

    • Security policy may use two approaches, alone or in combination:
    • Owner-controlled access: access control is left to the discretion of the owner.
    • System-controlled access: OS controls access; the owner cannot override these controls.
    • The first type is based on user identity and is the most widely known.
    • Example: a diary controlled by a child. The child (owner) can allow or deny access to different subjects (e.g., mother) based on identity.
    • DAC highlights flexibility and user-centric control, but can be less secure because owners may not always implement consistent policies.

  • Mandatory Access Control (MAC)

    • Definition: When a system mechanism controls access to an object and an individual user cannot alter that access, the control is MAC (also called rule-based access control).
    • OS enforcement: the operating system enforces MAC; neither the subject nor the object owner can determine access independently.
    • Access decisions are typically based on attributes of both the subject and the object (e.g., clearance, classification).
    • Example: the law allows court access to driving records without the owner's permission; access is controlled by policy rather than owner preferences.
    • MAC is used for high-security environments and relies on a hierarchy of classifications (e.g., Top Secret, Secret, Confidential, Unclassified).

  • What is a MAC System? (hierarchy, integrity, and data flow)

    • MAC categorizes information into levels (ground level, confidential, secret, top-secret, etc.).
    • The system enforces multilevel security via labeling and flow restrictions.
    • A typical layered hierarchy example:
    • Top Secret, Secret, Confidential, Unclassified.
    • Drawbacks: can be too rigid; dominance can restrict legitimate information flows; generally applicable to narrow environments.

  • MAC implementation concepts and models

    • Lattice Model: subjects and objects are assigned a rung on a lattice; multiple lattices can be placed adjacent; defines permissible information flows.
    • Bell-LaPadula (BLP) Model: focuses on maintaining data confidentiality; properties include no read up and no write down (simple security property and *-property).
    • Biba Integrity Model: complements BLP by focusing on data integrity; adds rules to prevent corruption of data.
    • Mandatory Integrity Control (MIC): based on Biba; ensures data integrity by controlling access to securable objects.

  • MAC uses, advantages, and disadvantages

    • Uses: widely used in sectors requiring confidential data protection with minimal supervision (government, military, healthcare, financial, engineering projects).
    • Advantages:
    • High-level data protection (often more secure than DAC or RBAC in certain contexts).
    • Centralized information control: once data is classified, re-categorization is restricted to administrators.
    • Privacy: administrator controls labeling—less risk of improper changes by users.
    • Disadvantages:
    • Careful setup required; rigidity can impede legitimate data sharing among coworkers.
    • Regular updates required as data changes; ACLs must be maintained.
    • Lack of operational flexibility; initial data labeling can be hard and error-prone.

  • Role-Based Access Control (RBAC)

    • RBAC is a method of restricting network access based on roles within an enterprise.
    • Roles reflect authority, competency, and responsibility; access to resources is granted to roles, and users are assigned to roles.
    • RBAC helps manage access when there are many workers, contractors, or third parties (customers, vendors).
    • Benefits include ensuring users access only information they need, improving compliance, and easing administration.
    • RBAC can involve overlapping roles and varying permission levels per role; roles can be specialized (end user, administrator, specialist).

  • RBAC structure (conceptual)

    • Users -> Roles -> Resources
    • Example illustration:
    • Role 1, Role 2, Role 3 mapped to permissions on files, applications, or network resources.

  • Task-Based Access Control (TBAC)

    • TBAC models access control from a task-oriented perspective rather than classic subject-object pairs.
    • Emphasizes workflows, authorizations, dependencies, and task instances.
    • Access decisions are tied to task states and transitions (activate, deactivate, access decisions) and are influenced by types, domains, and roles.
    • High-level view can be summarized as:
    • Protection States: subjects, objects, and permissions; TBAC ties these to tasks and workflows to determine when access is granted.
    • Example notation from slides:
    • A1, A2, A3, A4 denote task-related actions (activate workflows, dependencies, task instances; access decisions; deactivate).

  • Unified Data Model (UDM)

    • What is UDM?
    • The Unified Data Model (UDM) is a Chronicle standard data structure that stores information about data received from sources. It is also called the 'schema'.
    • Chronicle stores the original raw log and a structured UDM record; the raw log is stored as the original, and the UDM record is the structured representation.
    • Ingestion and transformation
    • Customers can transform raw logs into the structured UDM format before sending data to Chronicle using the Ingestion API.
    • Benefits of UDM
    • Consistent semantics across vendors by storing records in a standard format.
    • Easier to write rules against UDM records.
    • Easier to support log types from new devices.
    • Easier to identify relationships between users, hosts, IP addresses when data is normalized into the UDM schema.
    • Logical objects in UDM
    • Each UDM record identifies whether it describes an Event or an Entity.

  • UDM Event data model (structure and fields)

    • UDM Event describes an action that occurred in the environment; the original event log describes the action as recorded by a device (firewall, web proxy, etc.).
    • Event data model components (illustrative):
    • Event metadata: eventtimestamp, eventtype, productname, vendorname, etc.
    • Noun-related data: hostname, ip, network, mac, user, process, etc.
    • User data: userid, userdisplay_name, etc.
    • Process data: pid, command_line, etc.
    • Network data: ipprotocol, sentbytes, received_bytes, etc.
    • Security_result and other fields capturing the outcome.
    • Example event types include: PROCESSLAUNCH, NETWORKHTTP, USER_LOGIN, etc.

  • UDM Entity data model (structure and fields)

    • UDM Entity provides a contextual representation of assets, users, resources, etc., derived from a source of truth data source.
    • Entity data model components (illustrative):
    • EntityMetadata: assetid, hostname, productobjectid, entitytype (e.g., ASSET, USER).
    • Asset fields: productname, ip, natip, vendor_name, etc.
    • User fields: userid, userdisplayname, productobjectid, windowssid, email addresses, groupid, etc.
    • The entity model supports relationships via relations such as owns, administers, member, etc., with directionality and namespace labels.

  • Key takeaways and connections

    • ACM provides a rigorous framework for describing who can access what, under which conditions, and how protections evolve with system state changes.
    • DAC, MAC, RBAC, and TBAC represent different points on the spectrum of flexibility and control, each with strengths and trade-offs for different environments.
    • MAC emphasizes strong, centralized control and formalized labeling/flow policies, suitable for high-security contexts; RBAC emphasizes manageability in large organizations; TBAC emphasizes workflow- and task-driven decision points; DAC emphasizes owner discretion.
    • UDM provides a unified, standard way to represent and analyze logs and events across heterogeneous sources, enabling consistent policy application, rule-writing, and relationship discovery.

  • Summary of key equations and formal notions

    • Access rights entry relation in ACM: a[s,o]⊆Ra[s, o] \subseteq R for each subject s ∈ S and object o ∈ O.
    • Protection state as a triple: (S,O,A)(S, O, A), and the set of all possible states P with a secure subset Q ⊆ P.
    • Security policy and mechanism concepts:
    • Policy defines Q (secure states).
    • Mechanism enforces transitions to stay within Q (prevents P − Q).
    • Classification levels (MAC example):Unclassified,Confidential,Secret,Top Secret{\text{Unclassified}, \text{Confidential}, \text{Secret}, \text{Top Secret}} with multilevel access and labeling.
    • Lattice and integrity notions (BLP, Biba, MIC) govern how information flow and integrity constraints are enforced in MAC implementations.

  • Real-world relevance and implications

    • In modern systems, choosing between DAC, MAC, RBAC, and TBAC depends on security requirements, operational flexibility, and compliance needs.
    • Mac-based policies are critical in government, military, healthcare, and financial sectors due to the need for strict access controls and data integrity.
    • RBAC aligns with organizational structure by mapping permissions to roles, reducing administrative burden and improving compliance reporting.
    • TBAC aligns access decisions with business processes and workflows, potentially reducing risk by tying access to task progression.
    • UDM enables consistent, scalable analysis of security events across diverse data sources, facilitating policy enforcement and incident response.