CBROPS Objective 1.6: Compare Access Control Models

Understanding Access Control Fundamentals

Access control represents fundamental security principle determining who or what can access resources in computing environments. Every time user opens file, application queries database, or system connects to network, access control mechanisms decide whether to permit or deny action based on security policies. Effective access control ensures principle of least privilege where subjects (users, processes, systems) receive minimum access necessary to perform legitimate functions preventing unauthorized disclosure, modification, or destruction of information. Access control models provide frameworks for implementing these policies ranging from simple owner-controlled permissions to complex attribute-based systems evaluating multiple contextual factors.

Organizations typically employ multiple access control models simultaneously using different approaches for various resources and scenarios. File systems might use discretionary access control allowing owners to share files, while classified systems employ mandatory access control enforcing government security policies, corporate applications implement role-based access control managing permissions by job function, and modern cloud platforms leverage attribute-based access control supporting dynamic context-aware decisions. Understanding characteristics, advantages, and limitations of each model enables security professionals to select and implement appropriate access controls protecting organizational assets while supporting business operations and user productivity.

Discretionary Access Control (DAC)

Discretionary Access Control allows resource owners to control access permissions at their discretion deciding who can read, write, modify, or execute their files and resources. In DAC systems, every object (file, directory, database record) has an owner typically the creator who possesses full control including ability to grant or revoke access to other users. DAC provides flexibility enabling collaborative work where file owner shares document with team members, project lead grants folder access to contributors, and administrators delegate permission management reducing central administration burden. Most common operating systems implement DAC through file system permissions where Linux uses owner-group-other permission model and Windows employs Access Control Lists (ACLs) specifying detailed permissions for multiple users and groups.

DAC advantages include user autonomy enabling users to manage their own resources without constant administrative intervention, flexibility adapting quickly to changing collaboration needs and project requirements, ease of use with intuitive permission concepts users understand naturally, reduced administrative overhead since users manage their own resources, and support for collaboration through easy resource sharing. However, DAC presents security challenges including permission sprawl where users grant excessive access over time creating security risks, difficulty enforcing organizational policies since control is decentralized, data leakage from careless or malicious owners sharing sensitive information inappropriately, and privilege creep where permissions accumulate but are rarely removed. DAC suits environments prioritizing flexibility and collaboration such as corporate file servers, development teams sharing code, and general office computing where convenience outweighs need for strict centralized control.

Mandatory Access Control (MAC)

Mandatory Access Control enforces system-wide security policies that users cannot override where central authority assigns security labels to subjects and objects then enforces access rules based on these labels regardless of user preferences. MAC typically implements security clearance levels (Top Secret, Secret, Confidential, Unclassified) and classification labels ensuring users only access information at or below their clearance level. Bell-LaPadula model implements MAC for confidentiality preventing unauthorized disclosure through simple security property (no read up) prohibiting subjects from reading objects with higher classification than their clearance, and star property (no write down) preventing subjects from writing to objects with lower classification preventing classified data from leaking to unclassified systems.

Biba integrity model implements MAC for integrity preventing unauthorized modification through simple integrity axiom (no read down) prohibiting subjects from reading lower-integrity objects preventing contamination from untrusted sources, and star integrity axiom (no write up) preventing subjects from writing to higher-integrity objects protecting high-integrity data from corruption. MAC advantages include strong security through centralized policy enforcement, prevention of unauthorized disclosure even by authorized users, protection against insider threats since users cannot override policies, regulatory compliance meeting government and military security requirements, and consistent enforcement across entire system. MAC disadvantages include rigidity making legitimate information sharing difficult, administrative overhead requiring classification of all resources, complexity in policy creation and management, reduced productivity from strict access limitations, and implementation costs requiring specialized systems.

MAC primarily suits high-security environments including military and defense systems handling classified information requiring strict need-to-know enforcement, government agencies with formal information classification programs, intelligence organizations protecting national security information, financial systems requiring strict data segregation, and healthcare systems protecting patient information under HIPAA. SELinux (Security-Enhanced Linux) provides MAC implementation for Linux systems using security contexts and policies, Windows implements mandatory integrity control using integrity levels (System, High, Medium, Low), and classified systems deploy specialized MAC solutions meeting security certification requirements. Organizations sometimes implement hybrid approaches using MAC for most sensitive assets while employing DAC for general resources balancing security and usability.

Role-Based Access Control (RBAC)

RBAC Fundamentals and Implementation

Role-Based Access Control assigns permissions to roles representing job functions rather than individual users where users assigned to roles inherit associated permissions creating scalable manageable access control. RBAC separates users from permissions establishing indirect relationship through roles enabling administrators to manage access by adjusting role definitions or user assignments rather than modifying individual user permissions. Core RBAC concepts include roles representing job functions (Developer, Manager, Analyst), permissions specifying allowed operations on resources (read file, write database, execute script), user assignment mapping individuals to roles, and role hierarchies enabling inheritance where senior roles inherit junior role permissions.

RBAC implementation begins with role identification analyzing organizational structure and job functions determining common access patterns such as HR staff needing employee records and payroll access, IT administrators requiring system configuration and user management, or sales representatives needing customer data and order systems. Permission assignment maps specific resources and operations to each role precisely defining what role members can do. User assignment places employees into appropriate roles based on job function automatically granting necessary access. Role hierarchies establish inheritance relationships where manager role inherits all employee role permissions plus additional management functions reducing redundancy and simplifying administration.

RBAC Benefits and Challenges

RBAC advantages include simplified administration where managing roles scales better than managing individual permissions for thousands of users, reduced administrative errors through standardized role definitions ensuring consistency, efficient onboarding and offboarding where new hires immediately receive correct access through role assignment and departing employees lose all access when removed from roles, strong audit capabilities through clear documentation of who has what access and why, least privilege enforcement by precisely defining role permissions preventing excessive access, and scalability supporting large organizations efficiently. RBAC enables clear separation of duties by defining mutually exclusive roles preventing same individual from having conflicting responsibilities like approving and executing payments or developing and deploying code.

RBAC challenges include role explosion where organizations create too many specific roles becoming difficult to manage requiring periodic consolidation, static role definitions not adapting to dynamic business needs necessitating regular reviews, difficulty handling exceptions where unique or temporary access requirements don't fit standard roles, initial implementation complexity requiring thorough analysis of job functions, and role assignment errors if users receive inappropriate roles. Best practices include keeping roles coarse-grained representing broad job functions rather than task-specific roles, regular role reviews ensuring roles remain aligned with business needs and removing outdated permissions, comprehensive documentation describing each role's purpose and permissions, effective use of role hierarchies to leverage inheritance, and automated role assignment based on HR data where possible.

RBAC Implementations

Common RBAC implementations include Active Directory groups where group membership represents roles and group permissions define role capabilities, cloud IAM systems (AWS IAM roles, Azure RBAC, Google Cloud IAM) providing role-based access to cloud resources, database roles (SQL Server roles, Oracle roles) managing database permissions, application-specific roles (ServiceNow roles, SAP authorization objects) controlling application access, and enterprise identity management platforms centralizing role management across multiple systems. RBAC variations include core RBAC providing basic role assignment functionality, hierarchical RBAC supporting role inheritance enabling efficient permission management, constrained RBAC enforcing separation of duties through role incompatibility rules, and symmetric RBAC enabling role engineering and user-role review processes.

Attribute-Based Access Control (ABAC)

ABAC Concepts and Architecture

Attribute-Based Access Control makes access decisions based on attributes of subjects, resources, actions, and environment using policies that evaluate attribute combinations enabling fine-grained dynamic access control. ABAC attributes include subject attributes describing requestors (user department, clearance level, job title, citizenship, years of service), resource attributes describing accessed objects (data classification, owner, creation date, sensitivity, project association), action attributes describing operations (read, write, delete, execute, share), and environmental attributes describing context (current time, date, location, network security level, device type, detected threat level).

ABAC policies express access rules as logical expressions combining attributes such as "Employees in Finance department can read financial reports during business hours from corporate network" evaluating subject department, resource type, time, and location attributes. Policy Decision Points (PDP) evaluate policies determining whether to permit or deny access requests, Policy Enforcement Points (PEP) intercept access requests and enforce PDP decisions, Policy Administration Points (PAP) manage policy creation and updates, and Policy Information Points (PIP) provide attribute values from authoritative sources. ABAC request flow begins with subject requesting resource access, PEP intercepting request, PDP retrieving relevant attributes from PIPs, PDP evaluating policies against attributes, and PEP enforcing decision permitting or denying access.

ABAC Advantages and Use Cases

ABAC advantages include fine-grained control enabling precise permissions based on multiple factors, flexibility supporting complex access requirements without role modifications, context awareness considering environmental conditions like time and location in decisions, scalability handling complex scenarios without role explosion since policies scale better than roles, dynamic access control automatically adjusting based on changing attributes without manual intervention, and reduced exceptions since flexible policies accommodate most scenarios eliminating workarounds. ABAC particularly suits multi-tenant environments with complex sharing requirements, healthcare systems implementing HIPAA-compliant access based on patient relationships (treating physician can access patient records), financial systems with transaction amount thresholds (managers approve up to $50,000, directors approve higher), zero trust architectures requiring continuous verification based on multiple factors, and IoT environments with device-type and location-based restrictions.

ABAC challenges include policy complexity requiring careful design and testing to avoid unintended access, performance considerations since evaluating complex policies for every request impacts system responsiveness, attribute management maintaining accurate consistent attributes across systems, implementation difficulty requiring significant infrastructure and planning, and debugging challenges troubleshooting access denials when complex policies interact. ABAC standards include XACML (eXtensible Access Control Markup Language) providing standardized policy language and request/response protocols, ALFA (Abbreviated Language For Authorization) offering human-readable policy syntax, and NIST ABAC reference architecture defining conceptual model. Modern cloud platforms implement ABAC through AWS IAM policy conditions, Azure ABAC using resource tags and user attributes, and Google Cloud IAM conditional role bindings.

Authentication, Authorization, and Accounting (AAA)

Authentication

Authentication verifies user identity ensuring requestor is who they claim to be through various factors and methods. Authentication factors include knowledge factors (something you know like passwords, PINs, security questions), possession factors (something you have like smart cards, security tokens, mobile devices, authenticator apps), inherence factors (something you are like fingerprints, facial recognition, iris scans, voice recognition), location factors (somewhere you are like GPS coordinates, IP address ranges, network location), and behavioral factors (something you do like typing patterns, mouse movements, gait analysis). Single-factor authentication uses only one factor like password providing basic security but vulnerable to theft, while multi-factor authentication (MFA) combines multiple factor types significantly increasing security by requiring attackers to compromise multiple credentials.

Authentication methods include password-based authentication using username-password combinations remaining most common but weakest method requiring strong passwords and protection from phishing, certificate-based authentication using digital certificates providing strong cryptographic verification suitable for systems and privileged users, biometric authentication using physical characteristics like fingerprints or facial recognition providing convenient strong authentication, token-based authentication using hardware tokens (RSA SecurID) or software tokens (Google Authenticator) generating one-time passwords, single sign-on (SSO) authenticating once for access to multiple applications improving user experience and security, and federated authentication trusting external identity providers enabling cross-organization access. Authentication protocols include RADIUS providing centralized AAA for network access, TACACS+ offering enhanced auditing and flexible authentication, Kerberos using tickets for secure distributed authentication, LDAP accessing directory services, SAML enabling web SSO, OAuth 2.0 providing delegated authorization, and OpenID Connect adding identity layer to OAuth.

Authorization

Authorization determines what authenticated users can access defining permissions and privileges for resources and operations. Authorization mechanisms evaluate whether authenticated identity should be permitted to perform requested action on specified resource based on access control policies. Authorization models include discretionary access control where owners control permissions, mandatory access control enforcing system policies, role-based access control using job functions, attribute-based access control evaluating policies with attributes, and capability-based authorization granting tokens representing specific permissions. Authorization decisions answer questions like can this user read this file, should this administrator be allowed to modify this configuration, can this application access this API, and should this request be permitted at this time and location.

Authorization implementation uses access control lists (ACLs) listing specific permissions for users and groups on resources, capabilities providing tokens granting bearer specific permissions, security labels in MAC systems controlling access based on clearance and classification, role assignments in RBAC granting permissions based on role membership, and policy evaluation in ABAC assessing attribute-based rules. Principle of least privilege guides authorization granting minimum access necessary for legitimate functions reducing risk from compromised accounts, insider threats, and accidental damage. Separation of duties requires multiple individuals for sensitive operations preventing fraud and errors through maker-checker controls, approval workflows, and mutually exclusive role assignments.

Accounting

Accounting tracks user activities creating audit trails for security monitoring, compliance, troubleshooting, and billing by recording what users do with their access. Accounting logs capture authentication events (login/logout times, authentication success/failure, source IP addresses, authentication methods), authorization events (resource access attempts, permission grants/denials, privilege escalation, policy changes), resource usage (data transferred, session duration, commands executed, files accessed, API calls made), and security events (policy violations, suspicious activities, multiple failed authentication attempts, unusual access patterns). Accounting purposes include security monitoring detecting suspicious patterns and investigating incidents, compliance meeting regulatory requirements for audit trails (SOX, HIPAA, PCI DSS), troubleshooting diagnosing access issues and system problems, billing calculating usage charges for services, and capacity planning understanding resource utilization trends.

Accounting implementation uses syslog collecting logs from diverse systems, SIEM platforms aggregating and correlating logs for security analysis, audit logging recording detailed activity trails, database audit trails tracking data access and modifications, and API usage tracking monitoring programmatic access. Accounting best practices include comprehensive logging recording sufficient detail for investigation without excessive volume, centralized log management consolidating logs for analysis, tamper-proof storage protecting logs from modification or deletion, appropriate retention maintaining logs for required periods, automated analysis detecting anomalies and generating alerts, and regular review examining logs for suspicious activities ensuring accountability and supporting incident response.

Rule-Based and Time-Based Access Control

Rule-Based Access Control

Rule-based access control enforces access decisions based on specific rules and conditions defined by security policies evaluating circumstances rather than just identity. Rules specify conditions that must be met for access including if-then logic (if user from finance department then allow access to financial reports), Boolean expressions (allow if user has MBA AND tenure greater than 5 years), threshold comparisons (deny if more than 3 failed login attempts), pattern matching (block if user agent matches suspicious pattern), and complex conditions combining multiple factors. Rule examples include firewall rules permitting traffic based on source, destination, port, and protocol, network access rules enforcing policies like "deny access from guest network to production servers", application access rules implementing conditions like "allow database access only from application servers", and conditional access rules combining factors such as "require MFA if accessing from untrusted network".

Rule-based access control often combines with other models creating hybrid approaches where RBAC defines base permissions and rules add conditional restrictions such as "Users in Administrator role can access production servers only from corporate network during business hours" combining role with location and time rules. Rule advantages include flexible conditional access adapting to circumstances, enhanced security through context-aware restrictions, compliance support implementing regulatory requirements, and automation executing consistent policies. Rule challenges include complexity managing many rules, potential conflicts between contradictory rules, performance impact from rule evaluation, and maintenance burden keeping rules current. Common implementations include firewall rules, router ACLs, conditional access policies in identity systems, WAF rules, IPS rules, and DLP rules.

Time-Based Access Control

Time-based access control restricts system access to specific time periods enforcing temporal constraints enhancing security through temporal segregation. Time-based restrictions include business hours access permitting authentication only during work hours preventing after-hours unauthorized access, maintenance windows allowing administrative access during scheduled maintenance blocking administrative functions outside windows, shift-based access restricting employees to assigned shifts, temporary access granting time-limited permissions that automatically expire, and recurring schedules implementing repeating patterns. Time-based implementations include account time restrictions configuring permitted login times, session time limits enforcing maximum session duration with automatic logout, scheduled privilege elevation granting administrative rights only during maintenance windows, time-based firewall rules, and access token expiration.

Time-based access control benefits include reduced attack surface by limiting access to necessary periods, compliance with regulations requiring access segregation, prevention of after-hours attacks during unmonitored periods, support for shift work ensuring employees access only during assigned times, and automatic expiration of temporary access. Use cases include financial systems restricting trading to market hours, healthcare limiting non-emergency access to business hours, manufacturing restricting production system access to operating shifts, remote access limiting VPN to business hours, and privileged access granting administrative access only during approved windows. Implementation methods include Active Directory logon hours, privileged access management (PAM) solutions providing just-in-time access, network access control enforcing time-based admission, and application-level time restrictions. Time-based considerations include time zone management, emergency access procedures, accurate time synchronization using NTP, grace periods for flexibility, and notification systems warning of expiration.

Nondiscretionary Access Control

Nondiscretionary access control encompasses access control models where administrators or system policies determine access rights rather than resource owners making discretionary decisions. Nondiscretionary models include mandatory access control (MAC) where system enforces policies based on security labels, role-based access control (RBAC) where administrators define roles and assign users, rule-based access control where policies specify conditions, and lattice-based access control using mathematical models. In nondiscretionary systems, individual users cannot grant or revoke access to resources they own—instead, central authority controls all permissions ensuring consistent policy enforcement and preventing users from inadvertently or maliciously creating security vulnerabilities.

Nondiscretionary access control advantages include consistent policy enforcement preventing users from violating security policies, stronger security posture through centralized control, easier audit and compliance with clear permission structures, and prevention of insider threats from users granting unauthorized access. Disadvantages include reduced flexibility making resource sharing more difficult, administrative overhead requiring central management of all permissions, and potential productivity impact from rigid access controls. Organizations choose between discretionary and nondiscretionary models based on security requirements where high-security environments prioritize nondiscretionary control while flexible collaborative environments prefer discretionary approaches, often implementing hybrid models using nondiscretionary for sensitive resources and discretionary for general collaboration.

Exam Preparation Tips

Key Concepts to Master

• DAC: Owner controls permissions, flexible, easy to use, suitable for collaboration, risk of permission sprawl
• MAC: System enforces policies using labels/clearances, high security, rigid, suitable for classified environments (Bell-LaPadula, Biba)
• RBAC: Permissions by role/job function, scalable, simplified administration, role explosion risk, supports separation of duties
• ABAC: Policies using subject/resource/action/environment attributes, fine-grained, flexible, complex policies, context-aware (XACML)
• AAA: Authentication (verify identity), Authorization (grant permissions), Accounting (log activities), foundational framework
• Rule-based: Conditions and rules (firewall rules, conditional access), combines with other models, context-aware
• Time-based: Temporal restrictions (business hours, maintenance windows), reduces attack surface, supports compliance
• Nondiscretionary: Central authority controls access (MAC, RBAC), consistent enforcement, reduced flexibility

Practice Questions

Hands-On Practice Lab

Lab Activities

Lab Outcomes

After completing this lab, you'll have hands-on experience with access control models. You'll understand how DAC allows owner control with flexibility but security risks, how RBAC simplifies administration through role-based permissions scaling efficiently, how time-based access control adds temporal restrictions enhancing security, how AAA framework integrates authentication, authorization, and accounting, and how organizations combine models creating hybrid approaches balancing security and usability. These practical skills demonstrate access control concepts tested in CBROPS certification and provide foundation for implementing appropriate access controls in real-world environments.

Frequently Asked Questions