Access Control Models: DAC, MAC, RBAC, ABAC, and Choosing the Right One

Title

CISSP Lens: Pick answers that align business risk, governance intent, and practical control execution.

Access Control Models: DAC, MAC, RBAC, ABAC, and Choosing the Right One

Hook / Why this matters

Access control models determine who can grant access, how policies are enforced, and how well security scales as your environment grows. Pick the wrong model and you either drown in administrative work or end up with far more access than is safe. For the CISSP exam and real world design, you must be able to choose the right model for each context.

Core concept explained simply

An access control model is a conceptual way of deciding who can access which resources under what conditions. It defines who makes the decision and what rules they follow.

The main models you need for CISSP are:

Discretionary Access Control (DAC)

In DAC, the resource owner decides who gets access. Typical characteristics:

• Each file or object has an owner
• Owners can grant or revoke access for others at their discretion
• Access decisions are often implemented with access control lists

DAC is flexible and familiar. Most desktop operating systems use DAC for local files. The downside is that owners may grant access too broadly, creating over sharing and weakening confidentiality.

Mandatory Access Control (MAC)

MAC is used where strict confidentiality is required, such as military or some government systems. In MAC:

• Objects and subjects are given security labels, such as classifications and clearances
• The system enforces access rules based on these labels
• Users cannot change labels or override policy

The key idea is that the system, not the user, decides. This provides strong control but is less flexible and harder to manage for general business environments.

Role Based Access Control (RBAC)

RBAC organizes access around job functions instead of individuals.

• Roles represent job duties, such as "HR Analyst" or "Database Administrator"
• Permissions are assigned to roles
• Users are assigned to roles based on their job

This model scales well in enterprises, because you change role permissions or user role memberships instead of managing access object by object. RBAC supports least privilege when roles are carefully designed.

Attribute Based Access Control (ABAC)

ABAC goes further by making decisions based on attributes of subjects, objects, actions, and context. Attributes might include:

• User department, clearance level, or employment status
• Resource classification or data owner
• Action type such as read or modify
• Context, including location, device posture, or time of day

Policies in ABAC express rules such as, "Allow doctors to view patient records for patients they are assigned to during scheduled shifts." This provides very granular and dynamic control, but requires well managed attribute data and a capable policy engine.

Rule based access control

Rule based access focuses on conditions instead of identity. Firewalls are a classic example, using rules like "allow HTTP outbound from this subnet".

Rule based logic also appears inside RBAC or ABAC systems when policies refer to time, location, or other conditions.

Combining models

Most organizations do not use a single model everywhere. Common combinations include:

• RBAC for application roles, with DAC permissions inside personal workspaces
• ABAC layered on top of RBAC to enforce context sensitive rules
• MAC applied only to particularly sensitive systems while business apps use RBAC

CISSP lens

From an exam perspective, focus on the defining characteristic of each model:

• DAC: owner decides who gets access
• MAC: system enforces access based on labels, users cannot override
• RBAC: access determined by role memberships tied to job function
• ABAC: access based on attributes and policies, often context aware

Exam questions often describe a scenario and ask which model is most appropriate. Pay attention to:

• Regulatory or military confidentiality? MAC is likely
• Large enterprise mapping access to job titles and duties? RBAC fits
• Highly dynamic, context based decisions? ABAC is your candidate
• User controlled file sharing and flexibility? DAC is a clue

Also remember that RBAC is the dominant enterprise model, and MAC is the most restrictive, least flexible approach.

Real world scenario

A healthcare provider originally used DAC file shares for patient records. Department heads controlled access to shared folders and often granted access broadly for convenience.

An internal review found that more than 40 percent of staff had access to records for patients they had no relationship with. This violated privacy regulations and internal policy.

The organization redesigned access using RBAC and ABAC:

• RBAC roles were created for doctors, nurses, administrative staff, and billing
• Permissions to core systems were tied to these roles
• ABAC policies restricted access to patient records to staff assigned to a patient's care team and only during active episodes of care

Ownership based sharing was removed for regulated data. Users still had DAC style control for low risk collaboration folders, but sensitive health information moved to centralized, policy based access.

Common mistakes and misconceptions

• Using DAC for highly sensitive or regulated data. Owner discretion can lead to over sharing that violates confidentiality.
• Confusing MAC labels with RBAC roles. MAC labels reflect classification and clearance. RBAC roles reflect job functions.
• Creating too many roles in RBAC. Role explosion makes administration complex and undermines the benefits of the model.
• Thinking ABAC is a product you buy. ABAC is a model that requires accurate attributes and well designed policies.
• Assuming one model must fit everything. Mixing models by system and data type is normal and often necessary.

Actionable checklist

• List your most critical applications and data stores and identify which access control model each one uses today.
• For systems handling regulated or highly sensitive data, assess whether DAC based sharing is appropriate or whether RBAC or MAC style controls are needed.
• Review your RBAC implementation for role explosion. Consolidate or remove roles that overlap or are rarely used.
• Identify where ABAC style policies could reduce over provisioning, for example limiting access based on department, project, or patient relationship.
• Document which stakeholders can change access rules in each model and ensure those responsibilities match governance expectations.
• Include access control model choices and rationales in your architecture documentation so future changes stay aligned with strategy.

Key takeaways

• Access control models define who decides and how access decisions are made, and each model has strengths and trade offs.
• DAC is flexible but risky for sensitive data because owners may over share.
• MAC provides strong, centrally enforced control based on labels, but is rigid and best suited for high security environments.
• RBAC scales well in enterprises by mapping permissions to job roles, while ABAC enables fine grained, context aware policies when attribute data is mature.
• Most organizations mix models across systems, and the CISSP exam expects you to choose the best fit for each scenario.

Optional exam style reflection question

Question: A government agency handles top secret data and must prevent users from downgrading or sharing information outside approved channels. Which access control model best fits this requirement, and why

Answer: Mandatory Access Control. MAC assigns classification labels to data and clearance labels to users, and the system enforces access rules centrally. Users cannot change labels or bypass policy, which protects against unauthorized downgrading or sharing of classified information.