5.4 Authorization & Access Control Models
5.4 Authorization & Access Control Models
Authentication establishes who or what an identity is.
Authorization determines what that authenticated identity is allowed to do.
Access control models provide different ways of translating organisational security policy into actual decisions about subjects, objects, actions and conditions.
Subject
The user, service, process or device requesting access.
WHO?Object
The information, system, application or resource being accessed.
WHAT?Policy
Determines whether the requested operation should be permitted.
ALLOW OR DENY?Implement and Manage Authorization Mechanisms
Access through organisational roles.
Access according to defined rules and conditions.
Centrally enforced access based on labels and formal policy.
Resource owners have discretion over access to their objects.
Evaluate attributes of subjects, objects, actions and environment.
Incorporate risk into the authorization decision.
Separate policy decision-making from policy enforcement using components such as PDP and PEP.
The Big Idea
Every authorization model is trying to answer the same basic question:
Authorization Question
Authentication vs Authorization
Establish confidence in the identity.
WHO ARE YOU?
Determine what the authenticated identity may access and which operations it may perform.
WHAT MAY YOU DO?
Alice successfully authenticates to an online banking application.
Authentication confirms:
"This is Alice."
Authorization determines whether Alice may:
AuthN vs AuthZ
Access Control Models at a Glance
| Model | Decision Mainly Based On | Memory |
|---|---|---|
| RBAC | Organisational role | JOB |
| Rule-Based | Defined rules / conditions | RULE |
| MAC | Labels and centrally enforced policy | LABEL |
| DAC | Object owner's discretion | OWNER |
| ABAC | Subject, object, action and environmental attributes | ATTRIBUTES |
| Risk-Based | Risk and operational context | RISK |
Master Model Memory
RBAC - Access Based on Job Function
Role-Based Access Control assigns permissions to roles rather than managing every permission directly against individual users.
Alice is assigned:
Customer Service Adviser.
That role permits:
It does not permit:
RBAC
👔 Why Use RBAC? Roles simplify access administration in organisations
Thousands of users can inherit permissions through a smaller number of organisational roles.
Employees performing the same function can receive a consistent permission set.
Access reviews can focus on whether users have the correct roles and whether roles contain appropriate permissions.
Well-designed roles can correspond closely to legitimate job responsibilities.
Access can change by modifying role assignment when job responsibilities change.
Incompatible functions can be placed into separate roles.
Rather than asking: "What permissions should Alice have?"
ask: "Which legitimate business role is Alice performing?"
🪜 Role Hierarchies Roles can inherit permissions from other roles
Complex role hierarchies should be reviewed carefully so users do not inherit unexpected permissions.
🚧 RBAC Constraints Roles can enforce separation of duties
A user is prevented from being assigned two incompatible roles.
A user may hold multiple roles but cannot activate conflicting roles within the same relevant context or transaction.
No employee may simultaneously hold:
A senior employee can perform either function when appropriate but cannot both:
create and approve the same transaction.
💥 Role Explosion Too much specialisation can make RBAC difficult to manage
RBAC works well when meaningful and reasonably stable organisational roles exist.
Problems occur when every small combination of conditions creates a separate role.
Thousands of combinations can become difficult to maintain.
Access According to Defined Rules
Rule-based access control uses predefined conditions to determine whether access should be permitted.
- Deny remote administrative access outside approved hours.
- Permit traffic from the application subnet to the database only on the required port.
- Reject access when a device does not meet required security conditions.
Rule-Based
Role-Based asks which organisational function the user performs.
Rule-Based applies defined access rules or conditions.
Role-Based vs Rule-Based
| Role-Based | Rule-Based | |
|---|---|---|
| Main Question | What job/function do you perform? | Which rule applies? |
| Example | Payroll Administrator | Deny access after 22:00 |
| Memory | ROLE = JOB | RULE = CONDITION |
MAC - Centrally Enforced Policy
Mandatory Access Control uses centrally defined security policy rather than allowing ordinary resource owners to decide freely who may access protected information.
MAC is strongly associated with security labels, classifications and formal authorizations.
A document is classified:
SECRET.
An employee cannot simply change its permissions and send it to anyone they choose.
Access is controlled by centrally enforced policy.
MAC
🔔 MAC and Security Models Connect Domain 5 back to Bell-LaPadula and Biba
Mandatory access control can enforce information-flow policies based on security classifications and labels.
Protects confidentiality.
No Read Up · No Write Down
Protects integrity.
No Read Down · No Write Up
Remember
DAC - Owner Controls Access
Discretionary Access Control gives the owner or another authorised controller of an object discretion over who may access that object.
Alice creates a file.
The system allows Alice to decide that:
This reflects discretionary control by the resource owner.
DAC
MAC vs DAC
| MAC | DAC | |
|---|---|---|
| Authority | Central security policy | Object owner / authorised controller |
| Typical Basis | Labels, classifications, clearances | User/group permissions |
| User Can Freely Grant? | Generally no | Potentially yes, subject to system policy |
| Memory | Mandatory = centrally imposed | Discretionary = owner's discretion |
MAC vs DAC
📋 Access Control Lists - ACL Look at an object and ask who can access it
An Access Control List associates an object with entries describing which subjects have which permissions.
| Subject | Permission |
|---|---|
| Alice | Read |
| Bob | Read + Write |
| Finance Group | Read |
ACL
🎫 Capability-Based View Look at a subject and ask what it can access
A capability-oriented representation associates the subject with the objects and operations it is permitted to use.
| Object | Permission |
|---|---|
| customer.db | Read |
| payments.app | Create |
| payroll.xlsx | No Access |
ACL vs Capability
▦ Access Control Matrix Subjects, objects and permissions represented together
| Subject | Customer DB | Payment App | Payroll |
|---|---|---|---|
| Alice | Read | Create | - |
| Bob | Read / Write | Approve | - |
| Carol | - | - | Read / Write |
ACLs and capability-style structures are different ways of viewing or implementing portions of the subject-object-permission relationship.
ABAC - Evaluate Attributes
Attribute-Based Access Control evaluates characteristics associated with the request rather than relying only on a static user identity or role.
ABAC
S · O · A · E
🧬 ABAC Example Authorization can respond dynamically to context
Allow access if:
- user.department = Finance
- AND document.classification = Internal
- AND action = Read
- AND device.managed = True
- AND location.country = UK
🧠 Why ABAC Is Powerful It can express dynamic policy without creating endless roles
Decisions can consider individual resources and operations.
Access can vary according to device, location, time or other environmental conditions.
Policies can use attributes that describe identities and resources rather than requiring every subject-object relationship to be configured manually.
A decision can change when an attribute changes even though the underlying identity remains the same.
Alice's role remains:
Database Administrator.
But production access is denied because:
device.managed = false.
Her job did not change.
The context changed.
RBAC vs ABAC
| RBAC | ABAC | |
|---|---|---|
| Main Basis | Role | Attributes + policy |
| Example | Payroll Administrator | Finance + managed device + UK + business hours |
| Strength | Simple organisational administration | Fine-grained dynamic decisions |
| Challenge | Role explosion / stale roles | Attribute quality and policy complexity |
| Memory | JOB | ATTRIBUTES |
A role itself can be one attribute evaluated as part of a broader ABAC policy.
🏷️ Attribute Quality A perfect policy cannot compensate for incorrect attributes
ABAC depends heavily on reliable identity and resource attributes.
Policy:
Finance department users may access finance reports.
Bob transferred from Finance to Marketing six months ago.
His identity attribute still says:
department = Finance.
The authorization engine may make the correct decision using incorrect data.
Attribute Governance
Change Access According to Risk
Risk-based authorization incorporates security risk and operational context into access decisions.
Who is requesting access?
How strongly was the identity authenticated?
Is the endpoint managed and healthy?
Is the request coming from an expected location?
What is the consequence of inappropriate access?
Are current conditions increasing the likelihood of compromise?
Alice normally accesses payroll:
from a managed corporate workstation in London.
A new request arrives:
A risk-aware system may:
Risk-Based Access
📈 ABAC vs Risk-Based Access They can work together
Evaluates attributes about subjects, objects, actions and environment.
Incorporates assessed risk or risk-related context into the authorization decision.
ABAC policy evaluates:
The risk score itself can become an attribute used by the authorization policy.
Who Decides and Who Enforces?
Modern authorization architectures can separate the component that makes the access decision from the component that actually enforces it.
PDP vs PEP
D = Decision · E = Enforcement
🧠 Policy Decision Point - PDP Evaluate policy and make the authorization decision
The Policy Decision Point evaluates relevant policy and information to determine whether the requested access should be allowed.
Alice requests:
DOWNLOAD payroll.csv
The PDP evaluates:
Decision:
DENY.
🚧 Policy Enforcement Point - PEP Carry out the authorization decision
The Policy Enforcement Point sits in the access path and enforces the authorization decision.
The PDP returns:
DENY.
The PEP:
blocks Alice's payroll download.
PDP / PEP
Its main role is enforcement of the access decision.
⚙️ Supporting Policy Components PAP and PIP are useful architectural concepts
Where authorization policy is defined or managed.
MANAGES POLICY
Provides information or attributes needed to evaluate the access request.
PROVIDES DATA
Evaluates policy and produces the authorization decision.
DECIDES
Enforces the resulting authorization decision.
ENFORCES
Policy Architecture
A User Requests a Sensitive Document
🎯 Connection to Zero Trust Authorization can become continuous and context-aware
Modern access architectures increasingly evaluate identity, device and contextual information when granting access to resources.
When relevant conditions change, access can be reassessed.
Alice initially receives access from a managed device.
Endpoint security later reports that the device has become compromised.
A dynamic access architecture may restrict or terminate the session.
Good Authorization Policy
Grant only the access required for the legitimate task.
Require a genuine need for access to sensitive information.
Reject access unless policy explicitly permits it.
Prevent one identity from controlling an entire sensitive process.
Relevant access requests should consistently pass through the authorization mechanism.
Authorization events should be attributable where appropriate.
⛔ Default Deny Access requires an explicit reason to be permitted
A safer access-control posture is to permit the access justified by legitimate policy.
⚔️ Policy Conflicts What happens when several rules apply?
Complex authorization environments can produce several applicable rules with different outcomes.
Rule 1:
Finance role → permit report access.
Rule 2:
Unmanaged device → deny confidential data.
Alice is in Finance but is using an unmanaged device.
The system requires a defined method for resolving the policy result.
Ambiguous or conflicting policies can create security failures even when the enforcement technology works correctly.
⚖️ Permit and Deny Logic Security-sensitive systems often favour conservative outcomes
Policy systems need deterministic handling for situations such as:
Sensitive authorization systems should avoid turning missing information or processing errors into unintended broad access.
📈 Authorization Drift & Privilege Creep Correct access today can become excessive tomorrow
Alice works in:
Customer Service.
She later moves to:
Finance.
New Finance permissions are added, but old Customer Service permissions remain.
She later moves to Security and gains even more permissions.
🔍 Authorization Reviews Verify that effective access remains appropriate
Access reviews should consider more than the user account itself.
Review
A user's final privileges may result from several overlapping mechanisms rather than one visible role.
A Banking Payment Application
Consider a bank that needs to control payment approvals.
The exam may present a single model for identification, but enterprise systems can combine roles, attributes, rules and risk.
Classified Government Information
A User Shares a File
One User - Different Decision
User = Finance
Device = Managed
Location = London Office
Time = 10:00
PERMIT
User = Finance
Device = Unmanaged
Location = Unknown
Time = 03:00
DENY / RESTRICT
🎓 CISSP Scenarios Identify the authorization mechanism
A user's permissions are determined by their job as a Payroll Administrator.
Which model?
RBAC.
An employee changes from Customer Service to Finance and receives a different permission set because their organisational function changed.
Which model?
RBAC.
Access is denied after 22:00 according to a centrally configured condition.
Which concept?
Rule-based access control.
Management describes Role-Based Access Control and Rule-Based Access Control as identical.
Is this correct?
No.
Role-based access is centred on organisational roles; rule-based access applies defined rules and conditions.
Access to classified information is based on a user's clearance and the object's security label.
Which model?
MAC.
A document owner cannot change a centrally imposed classification rule.
Which model?
MAC.
A user creates a file and decides which other users may read it.
Which model?
DAC.
The object's owner can grant their permissions to another user.
Which concept is most relevant?
Discretionary Access Control.
Access depends on department, document classification, device state, requested action and location.
Which model?
ABAC.
The user's role remains unchanged but access is denied because the device is unmanaged.
Which model is particularly suitable?
ABAC.
A policy uses department, location, resource sensitivity and current security risk to make the decision.
Which models may be combined?
ABAC and risk-based access control.
A user's identity, business need and current risk level determine whether sensitive access is granted.
Which approach?
Risk-based / risk-adaptive access control.
An authorization component evaluates policy and returns PERMIT.
Which component?
Policy Decision Point - PDP.
A gateway blocks the request after receiving a DENY authorization decision.
Which component?
Policy Enforcement Point - PEP.
A system supplies the user's department and device status to the authorization engine.
Which component concept?
Policy Information Point - PIP.
Security administrators create and maintain the authorization rules used by the decision engine.
Which component concept?
Policy Administration Point - PAP.
A policy engine returns DENY, but the application ignores the result and serves the data anyway.
Which function failed?
Policy enforcement.
A user's role is Finance, but the underlying identity attribute incorrectly says Marketing.
Authorization decisions rely on the incorrect attribute.
Primary problem?
Attribute quality / identity-data governance.
Thousands of roles have been created solely to represent combinations of location, shift and device state.
Which RBAC problem?
Role explosion.
A system replaces dozens of location-specific roles with a location attribute evaluated dynamically.
Which model?
ABAC.
A user cannot be assigned both Payment Creator and Payment Approver roles.
Which control?
Static separation of duties.
A user may hold two roles but cannot use both roles in the same transaction.
Which control?
Dynamic separation of duties.
Security wants to know every identity that can access payroll.xlsx.
Which view is especially useful?
Access Control List - ACL.
Security wants to know every resource Alice is permitted to access.
Which conceptual view?
Capability-oriented view.
No policy rule explicitly permits a request.
What should a default-deny architecture do?
Deny access.
A policy engine is unavailable and the application grants unrestricted access so users are not inconvenienced.
Which design principle is violated?
Fail securely.
A user had legitimate access in three previous roles and retains all permissions after changing jobs.
Which issue?
Privilege creep.
Security reviews a user and checks roles, groups, direct permissions and inherited access.
What is being assessed?
Effective authorization / effective access.
An employee is permitted to view customer information but not export it.
What does this demonstrate?
Authorization can distinguish between operations on the same object.
The same authenticated user receives access from a compliant device but is denied from a compromised device.
What principle?
Context-aware / dynamic authorization.
A network component sits directly in the access path and implements authorization decisions.
Which architectural role?
PEP.
The system asks a central service whether a request from Alice to download a confidential document should be permitted.
Which architectural role makes the decision?
PDP.
Alice's role grants report access, but a security rule denies access from unmanaged endpoints.
What lesson?
Different authorization mechanisms can operate together.
A user has a Top Secret clearance but does not have the required compartment authorization for a particular document.
Primary lesson?
Clearance alone does not necessarily satisfy every mandatory access-control requirement.
Recognise the Clue Words
Job Function
Permission follows organisational responsibility.
RBACIF / THEN Condition
Global or defined rule.
Rule-BasedClassification + Clearance
Centrally enforced labels.
MACObject Owner Decides
User controls permissions.
DACSubject + Object + Context
Dynamic characteristics.
ABACThreat / Risk Score
Decision adapts to risk.
Risk-BasedEvaluates Policy
Makes access decision.
PDPBlocks or Allows
Implements decision.
PEPProvides Attributes
Supplies decision data.
PIPCreates Policy
Policy administration.
PAPWho Can Access This File?
Object-centred permissions.
ACLWhat Can Alice Access?
Subject-centred view.
CapabilityToo Many Roles
Combinatorial complexity.
Role ExplosionCannot Hold Conflicting Roles
Assignment restriction.
Static SoDCannot Use Conflicting Roles Together
Runtime restriction.
Dynamic SoDNo Matching Permit
Secure baseline.
Default DenyWrong Department Attribute
Correct policy, bad data.
Attribute QualityOld Roles Accumulate
Permissions no longer match job.
Privilege Creep⚠️ Common CISSP Mistakes The model names are deliberately easy to confuse
Knowing who the identity is does not determine what the identity may do.
Role = organisational function.
Rule = defined condition.
In IAM, MAC means Mandatory Access Control.
Mandatory controls are centrally imposed.
DAC gives authorised object owners discretion over permissions.
The model's value comes from assigning permissions through roles.
ABAC can consider subject, object, action and environmental attributes.
Role can itself be an attribute in a wider policy.
Authorization depends on trustworthy information.
PDP decides.
PEP enforces.
A correct DENY decision provides no protection if the enforcement point ignores it.
An ACL is a common mechanism for expressing permissions associated with an object.
Risk can influence authorization after identity has already been established.
Context and risk can change after a session begins.
Sensitive systems should fail securely rather than grant broad access because policy evaluation failed.
Effective access may also come from groups, inherited permissions, direct grants and other policy mechanisms.
Quick Reference
| If you see... | Think... |
|---|---|
| Permissions follow job function | RBAC |
| Access according to defined condition | Rule-Based |
| Clearance + classification | MAC |
| Owner decides who accesses file | DAC |
| Subject/object/environment characteristics | ABAC |
| Decision changes according to risk | Risk-Based Access |
| Make policy decision | PDP |
| Enforce policy decision | PEP |
| Supply attributes/context | PIP |
| Manage authorization policy | PAP |
| Object → identities and permissions | ACL |
| Subject → resources and permissions | Capability View |
| Users, objects and permissions in grid | Access Matrix |
| Too many specialised roles | Role Explosion |
| Cannot be assigned two incompatible roles | Static Separation of Duties |
| Cannot activate conflicting functions together | Dynamic Separation of Duties |
| No explicit permission | Default Deny |
| Authorization engine fails | Fail Securely |
| Old permissions accumulate | Privilege Creep |
| Same user, different device/location result | Dynamic / Context-Aware Authorization |
Access Model Memory Aid
Role = Job · Rule = Condition · MAC = Label · DAC = Owner · ABAC = Attributes · Risk = Context
Policy Architecture Memory Aid
Policy → Information → Decision → Enforcement
Which Model? Ask This
5.4 Master Memory Aid
Authenticate → Authorise → Decide → Enforce → Review
The Authorization Architect's Questions
Key Takeaways
Authorization determines what an authenticated identity is permitted to access and which operations it may perform.
Authentication answers "who are you?" while authorization answers "what may you do?"
The current CISSP 5.4 objective covers RBAC, rule-based access control, MAC, DAC, ABAC, risk-based access control and policy enforcement.
Role-Based Access Control assigns permissions according to organisational roles or job functions.
Users receive roles and roles contain permissions, simplifying administration at scale.
RBAC memory: ROLE = JOB.
Role hierarchies can simplify permission inheritance but may make effective access more difficult to understand.
RBAC can enforce static and dynamic separation-of-duties constraints.
Role explosion occurs when too many specialised roles are created to represent every possible combination of conditions.
Rule-based access control applies defined rules or conditions to determine whether access should be permitted.
Role-based and rule-based access control are not the same: ROLE = JOB, RULE = CONDITION.
Mandatory Access Control uses centrally enforced policy and is strongly associated with security labels, classifications and formal authorization.
Users do not normally have discretion to override mandatory classification policy.
MAC memory: LABEL + CLEARANCE + CENTRAL POLICY.
Discretionary Access Control allows an object's owner or another authorised controller to determine who receives access.
DAC memory: OWNER DECIDES.
Access Control Lists provide an object-centred view of which subjects possess which permissions.
Capability-oriented structures provide the opposite perspective by considering which resources a subject can access.
An access-control matrix conceptually represents subjects, objects and permissions together.
Attribute-Based Access Control evaluates characteristics of the subject, object, requested action and environment against policy.
ABAC memory: Subject · Object · Action · Environment.
ABAC is useful for fine-grained and dynamic decisions because conditions such as device health, location and time can influence authorization.
RBAC and ABAC do not have to be mutually exclusive; a role can itself be one of the attributes evaluated by policy.
Attribute-based systems depend on reliable attributes.
A correct policy using incorrect identity or resource attributes can still produce an incorrect access decision.
Risk-based access control incorporates security risk and operational context into authorization.
Risk signals may include authentication assurance, device state, location, resource sensitivity and current threat conditions.
Risk can also be represented as an attribute within an ABAC policy.
Modern policy architectures can separate policy decision-making from policy enforcement.
The Policy Decision Point - PDP - decides.
The Policy Enforcement Point - PEP - enforces.
A Policy Information Point can provide attributes and contextual information required for authorization decisions.
A Policy Administration Point can represent where authorization policy is created or managed.
A correct DENY decision has no security value if the enforcement point fails to enforce it.
Default deny means that access is rejected unless policy provides a legitimate reason to permit it.
Authorization systems should fail securely rather than turn missing policy information or decision-system failures into broad access.
Dynamic authorization can reassess access when contextual conditions change during a session.
Authorization reviews should consider effective access resulting from roles, groups, direct permissions, inherited permissions and other access mechanisms.
Privilege creep occurs when historical permissions accumulate instead of being removed when responsibilities change.
The CISSP approach is to identify the subject, object, requested action and applicable context; apply the appropriate authorization policy; make a clear decision; enforce that decision consistently; and periodically verify that access remains appropriate.
📚 Sources & Further Reading Authorization and access-control references
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-162 - Guide to Attribute Based Access Control
View NIST ABAC guidance - NIST SP 800-192 - Verification and Test Methods for Access Control Policies/Models
View NIST access-control model guidance - NIST - Role-Based Access Control
View NIST RBAC resources - NIST - Role-Based Access Control Glossary
View the NIST RBAC definition - NIST - Mandatory Access Control Glossary
View the NIST MAC definition - NIST - Discretionary Access Control Glossary
View the NIST DAC definition - NIST - Risk Adaptive Access Control Glossary
View the NIST RAdAC definition - NIST - Policy Enforcement Point Glossary
View the NIST PEP definition - NIST SP 800-207 - Zero Trust Architecture
View NIST Zero Trust Architecture