Lesson Nineteen

Authorization Models and Access-Control Enforcement

SierraTec Secure CISSP Certification Preparation Course

Lesson Overview

Authentication answers:

Who or what are you?

Authorization answers the next and equally important question:

Now that I know who you are, what are you allowed to do?

A perfectly authenticated user should still be denied access when the requested action exceeds legitimate authority.

For example:

• an HR analyst may view employee records but should not administer firewalls;

• a database administrator may maintain a database but should not automatically approve financial transactions;

• a physician may access assigned patient records but not every record in a national health system;

• an application service may query one database table but should not automatically receive administrator privileges.

Authorization therefore determines the relationship among:

SUBJECT

   +

RESOURCE

   +

REQUESTED ACTION

   +

POLICY

   +

CONTEXT

   =

ALLOW / DENY

The current CISSP Examination Outline places this lesson primarily under Domain 5, Objective 5.4 — Implement and manage authorization mechanisms.

ISC2 currently identifies:

• Role-Based Access Control (RBAC);

• rule-based access control;

• Mandatory Access Control (MAC);

• Discretionary Access Control (DAC);

• Attribute-Based Access Control (ABAC);

• risk-based access control;

• access-policy enforcement, including Policy Decision Points and Policy Enforcement Points.

NIST defines ABAC as an authorization methodology in which attributes associated with subjects, objects, requested operations, and sometimes environmental conditions are evaluated against policy.

NIST Zero Trust Architecture similarly separates the component that makes an access decision from the mechanism that enforces that decision.

The central Lesson Nineteen question is:

Once an identity has been authenticated, how should an organization determine exactly what that subject may access, under what conditions, and how should that authorization decision be enforced?

CISSP Exam Objective Alignment

Learning Objectives

After completing this lesson, you should be able to:

1. Define authorization.

2. Distinguish authentication from authorization.

3. Define subject and object.

4. Define permission.

5. Define right.

6. Define privilege.

7. Define entitlement.

8. Explain an access-control matrix.

9. Explain an Access Control List.

10. Explain capability-based authorization conceptually.

11. Explain default-deny authorization.

12. Explain explicit and implicit denial.

13. Explain least privilege.

14. Explain need to know.

15. Explain separation of duties.

16. Define RBAC.

17. Explain role assignment.

18. Explain permission assignment.

19. Explain role hierarchy.

20. Explain constrained RBAC.

21. Explain static separation of duties.

22. Explain dynamic separation of duties.

23. Explain role explosion.

24. Explain rule-based access control.

25. Distinguish rule-based access control from RBAC.

26. Define MAC.

27. Explain security labels.

28. Explain classification.

29. Explain clearance.

30. Explain categories/compartments.

31. Explain why MAC is centrally administered.

32. Define DAC.

33. Explain object ownership.

34. Explain why DAC is discretionary.

35. Compare MAC and DAC.

36. Define ABAC.

37. Explain subject attributes.

38. Explain object attributes.

39. Explain action attributes.

40. Explain environmental attributes.

41. Develop a basic ABAC policy.

42. Explain ABAC benefits.

43. Explain ABAC complexity.

44. Define risk-based access control.

45. Explain adaptive authorization.

46. Explain contextual access.

47. Explain continuous reevaluation.

48. Define Policy Decision Point.

49. Define Policy Enforcement Point.

50. Define Policy Information Point.

51. Define Policy Administration Point.

52. Explain decision versus enforcement.

53. Explain Zero Trust authorization.

54. Explain session-level authorization.

55. Explain step-up authentication.

56. Explain authorization revocation.

57. Explain access-policy lifecycle management.

58. Apply FIRST/BEST/MOST CISSP reasoning to authorization questions.

59. Compare all major authorization mechanisms.

60. Analyze original CISSP-style authorization scenarios.

Part I — Authentication Versus Authorization

1. Authentication

Authentication establishes confidence in the claimed identity.

Question:

Can you prove who you claim to be?

2. Authorization

Authorization determines whether the authenticated subject may perform the requested action on the resource.

Question:

Are you permitted to do this?

3. Authentication Does Not Imply Authorization

USER

  │

  ▼

AUTHENTICATED

  │

  ▼

REQUEST:

"READ PAYROLL"

  │

  ▼

AUTHORIZED?

 ┌──┴──┐

 YES   NO

  │     │

ALLOW DENY

A legitimate employee can still be denied access.

4. Core CISSP Principle

Authentication establishes identity. Authorization establishes permitted activity.

Never confuse them.

Part II — Subject, Object, and Action

5. Subject

A subject is an active entity requesting access.

Examples:

• employee;

• process;

• application;

• service;

• device.

6. Object

An object is the protected resource.

Examples:

• file;

• record;

• database;

• API;

• server;

• printer;

• application function.

7. Action

The requested operation may include:

• read;

• write;

• execute;

• modify;

• delete;

• approve;

• administer.

8. Authorization Request

SUBJECT

  Alice

    │

    ▼

ACTION

  Modify

    │

    ▼

OBJECT

Payroll Record

The authorization system evaluates whether:

Alice may modify that payroll record.

Part III — Rights, Permissions, Privileges, and Entitlements

9. Permission

A permission describes an allowed operation on a resource.

Example:

Read Report A.

10. Right

The terms right and permission are often used similarly.

At CISSP level:

Focus on the authorized action rather than terminology differences between products.

11. Privilege

A privilege generally represents an authorized capability, often with elevated or system-level significance.

Examples:

• create accounts;

• load drivers;

• modify security configuration.

12. Entitlement

An entitlement represents access granted to an identity.

It may include:

• application access;

• role membership;

• privilege;

• group membership.

Part IV — Access-Control Matrix

13. Matrix Concept

An access-control matrix represents:

• subjects as one dimension;

• objects as another;

• permitted actions at their intersections.

14. Example

15. Why the Matrix Matters

It provides a conceptual model for answering:

Who can do what to which object?

Part V — Access Control Lists

16. ACL

An Access Control List is commonly associated with an object and identifies subjects or groups and their permitted or denied access.

Example:

PAYROLL.DOC

   │

   ├── Finance Group → Read

   ├── Payroll Admin → Read/Write

   └── Guest → Deny

17. Object-Centric View

Think:

For this object, who can access it?

Part VI — Capability Concept

18. Capability-Based View

A capability-oriented representation emphasizes:

Which objects/actions can this subject access?

Example:

ALICE

  │

  ├── Payroll → Read

  ├── Expenses → Approve

  └── HR Portal → Login

19. Matrix Relationship

Conceptually:

ACL

Object-centric view



CAPABILITY

Subject-centric view



ACCESS MATRIX

Complete conceptual relationship

Part VII — Default Deny

20. Authorization Philosophy

A strong security model generally begins with:

Access is denied unless appropriately authorized.

21. Why?

If the policy cannot establish that access is permitted:

the safer result is normally denial.

22. CISSP Exam Logic

When faced with:

• uncertain authorization;

• missing approval;

• unexplained entitlement;

CISSP reasoning generally favors:

restricting access until legitimate authorization is established.

Part VIII — Explicit and Implicit Denial

23. Explicit Deny

An explicit rule may specifically state:

Finance interns cannot approve transactions.

24. Implicit Deny

If no authorization exists for an action, the system may deny it by default.

25. Important Qualification

Actual policy precedence differs across technologies.

Do not memorize one universal ACL evaluation algorithm.

The broader principle is:

Do not grant access merely because a policy failed to address it.

Part IX — Least Privilege

26. Least Privilege

Grant only the privileges necessary to perform legitimate duties.

BUSINESS NEED

     │

     ▼

REQUIRED TASK

     │

     ▼

MINIMUM PRIVILEGE

27. Example

A backup operator needs:

• run backup;

• verify backup.

The operator may not require:

• HR-record access;

• firewall administration;

• domain administration.

Part X — Need to Know

28. Need to Know

Need to know limits information access to subjects with legitimate operational need.

29. Difference

LEAST PRIVILEGE

"What actions do you need?"



NEED TO KNOW

"What information do you need?"

Part XI — Separation of Duties

30. SoD

Separation of Duties divides sensitive responsibilities among different people or roles.

Example:

USER A

Creates vendor



USER B

Approves vendor



USER C

Approves payment

31. Objective

Prevent one individual from controlling an entire high-risk transaction.

Part XII — Role-Based Access Control

32. RBAC

Role-Based Access Control assigns permissions according to organizational roles rather than individually managing every user-to-resource relationship.

NIST describes RBAC as mediating access through roles associated with organizational functions.

33. Basic RBAC Model

USER

  │

  ▼

ROLE

  │

  ▼

PERMISSIONS

  │

  ▼

RESOURCES

34. Example

Alice

   │

   ▼

PAYROLL CLERK

   │

   ├── View Employee Pay

   ├── Enter Payroll Data

   └── Generate Payroll Report

Part XIII — Why RBAC Works Well

35. Business Alignment

Organizations commonly think in terms of jobs such as:

• accountant;

• nurse;

• administrator;

• auditor.

Roles map naturally to these responsibilities.

36. Administrative Advantage

Without RBAC:

1,000 USERS

      ×

200 APPLICATIONS

      =

LARGE PERMISSION COMPLEXITY

With RBAC:

USERS

  ↓

ROLES

  ↓

PERMISSIONS

37. NIST RBAC Principle

NIST describes a core RBAC idea as associating permissions with roles and assigning users to appropriate roles rather than administering every permission directly per user.

Part XIV — User-Role Assignment

38. Role Assignment

ALICE → ACCOUNTANT



BOB → SECURITY ANALYST



CAROL → DATABASE ADMIN

Users receive permissions through their assigned role or roles.

Part XV — Permission-Role Assignment

39. Example

DATABASE ADMIN

     │

     ├── Create Database

     ├── Backup Database

     └── Restore Database

Permissions attach to the role.

Part XVI — Role Hierarchy

40. Hierarchical RBAC

Roles can inherit permissions from other roles.

Example:

SENIOR ACCOUNTANT

       │

       ▼

ACCOUNTANT

       │

       ▼

BASE FINANCE USER

41. Benefit

Common permissions need not be repeatedly assigned.

42. Risk

Poorly designed role inheritance can create:

unintended privilege accumulation.

Part XVII — Constrained RBAC

43. Constraints

RBAC systems can impose restrictions such as:

• mutually exclusive roles;

• separation of duties;

• role activation limits.

NIST's RBAC work recognizes hierarchical and constrained RBAC as important extensions to core role assignment.

Part XVIII — Static Separation of Duties

44. Static SoD

A user cannot be assigned two conflicting roles simultaneously.

Example:

PAYMENT CREATOR



        X



PAYMENT APPROVER

45. Purpose

Prevent the conflict before access is assigned.

Part XIX — Dynamic Separation of Duties

46. Dynamic SoD

A user may be eligible for multiple roles but cannot activate conflicting roles during the same sensitive transaction or session.

47. Example

An employee may perform:

• purchasing duties at one time;

• approval duties in another context;

but may not:

initiate and approve the same transaction.

Part XX — Role Explosion

48. Problem

Organizations sometimes create increasingly specific roles:

FINANCE-READ

FINANCE-READ-LONDON

FINANCE-READ-LONDON-MANAGER

FINANCE-READ-LONDON-MANAGER-Q4

...

This creates:

Role Explosion

49. Result

RBAC can become:

• difficult to administer;

• difficult to review;

• difficult to understand.

This is one reason organizations may combine RBAC with attributes.

Part XXI — Rule-Based Access Control

50. Rule-Based Access Control

Rule-based access control makes decisions using predefined system rules.

Example:

IF

source_network = corporate

AND

time = 08:00–18:00

THEN

permit access

51. Common Examples

Rules can relate to:

• network address;

• time;

• transaction type;

• system condition;

• protocol.

Part XXII — RBAC Versus Rule-Based

52. Important CISSP Distinction

RBAC

Access based primarily on organizational role.

Rule-Based

Access based on defined rules or conditions.

53. Example

RBAC:

Payroll Manager may approve payroll.

Rule-based:

Payroll approvals are allowed only during the authorized processing window.

54. They Can Work Together

ROLE:

Payroll Manager

      +

RULE:

Weekday + approved device

      =

ACCESS

Part XXIII — Mandatory Access Control

55. MAC

Mandatory Access Control uses centrally administered security policy to determine access.

Subjects and objects may have:

• clearances;

• classifications;

• labels;

• compartments.

56. Mandatory Means

The ordinary user does not decide:

“I own this file, so I will give everyone access.”

The system's mandatory policy controls access.

Part XXIV — Security Labels

57. Object Label

An object may have a label such as:

SECRET

or:

SECRET // PROJECT ALPHA

58. Subject Clearance

A subject may hold:

SECRET CLEARANCE

However:

Clearance alone may not be enough.

The subject may also require:

• need to know;

• appropriate compartment/category authorization.

Part XXV — Classification and Clearance

59. Classification

Typically describes sensitivity assigned to information.

60. Clearance

Represents the level at which the subject has been authorized.

61. Concept

SUBJECT

Clearance + Categories

        │

        ▼

MANDATORY POLICY

        │

        ▼

OBJECT

Classification + Categories

Part XXVI — MAC Example

62. Scenario

Alice has:

SECRET clearance.

Document:

TOP SECRET.

Alice cannot simply decide:

“I need it.”

The centralized mandatory security policy controls access.

Part XXVII — MAC Strength

63. Benefit

MAC provides strong centralized control suitable where information classifications and formal policy boundaries are important.

64. Tradeoff

MAC can be:

• administratively rigid;

• less flexible for informal collaboration.

Part XXVIII — Discretionary Access Control

65. DAC

Discretionary Access Control allows an owner or authorized controller of an object to determine who receives access, subject to system policy.

66. Example

Alice creates:

ProjectPlan.docx

Alice may be permitted to grant Bob:

Read access.

Part XXIX — Why It Is Discretionary

67. Discretion

The owner has meaningful control over the access decision.

OBJECT OWNER

     │

     ├── Alice → Read

     ├── Bob → Modify

     └── Guest → No Access

Part XXX — DAC Advantages

68. Flexibility

DAC works well for:

• collaborative systems;

• user-owned files;

• general business computing.

Part XXXI — DAC Risk

69. Owner Error

A user may:

• grant too much access;

• misunderstand sensitivity;

• share information incorrectly.

70. Trojan Horse Concern

Historically, DAC models also raise concern because access rights can potentially be propagated or exploited by software acting with a user's authority.

At CISSP level:

Understand that DAC provides flexibility at the cost of greater reliance on owner discretion.

Part XXXII — MAC Versus DAC

71. Comparison

Part XXXIII — Attribute-Based Access Control

72. ABAC

Attribute-Based Access Control evaluates characteristics associated with:

• subject;

• object;

• requested operation;

• environment;

against policy.

This matches NIST's formal ABAC definition.

73. ABAC Formula

SUBJECT ATTRIBUTES

       +

OBJECT ATTRIBUTES

       +

ACTION

       +

ENVIRONMENT

       +

POLICY

       =

ALLOW / DENY

Part XXXIV — Subject Attributes

74. Examples

Subject attributes might include:

• department;

• employment status;

• job level;

• clearance;

• location;

• device ownership;

• training status.

Part XXXV — Object Attributes

75. Examples

Object attributes may include:

• classification;

• owner;

• data type;

• business unit;

• geographic restriction.

Part XXXVI — Action Attributes

76. Action

Examples:

• read;

• modify;

• approve;

• delete;

• print;

• export.

Different actions can have different policies.

Part XXXVII — Environmental Attributes

77. Context

Examples:

• time;

• location;

• device posture;

• threat level;

• network;

• transaction risk.

Part XXXVIII — ABAC Example

78. Healthcare Scenario

Policy:

Permit physician to view a patient record if the physician is currently assigned to the patient and accesses from an approved managed device.

SUBJECT.role = Physician

       +

SUBJECT.assignment = Patient123

       +

OBJECT.patient = Patient123

       +

DEVICE.managed = True

       =

ALLOW

Part XXXIX — Why ABAC Is Powerful

79. Fine-Grained Decisions

RBAC asks:

What role does Alice have?

ABAC can ask:

What role does Alice have, which patient is assigned to her, what device is she using, where is she, and what action is requested?

80. NIST Perspective

NIST describes ABAC as useful for improving information sharing while retaining control because authorization can reflect multiple attributes and policy relationships.

Part XL — ABAC Challenge

81. Complexity

ABAC depends on trustworthy:

• attributes;

• policies;

• data sources;

• policy processing.

Incorrect attributes can produce incorrect authorization.

82. Example

If HR incorrectly lists:

Alice.department = Finance

then an ABAC policy relying on that attribute may grant inappropriate finance access.

Part XLI — Attribute Quality

83. Principle

Authorization quality cannot exceed attribute quality.

Attributes should have:

• trusted sources;

• defined ownership;

• lifecycle management.

Part XLII — Risk-Based Access Control

84. Risk-Based Access

Risk-based authorization considers current risk indicators when making access decisions.

Example signals:

• new device;

• unusual location;

• abnormal behavior;

• high-risk transaction;

• threat intelligence.

Part XLIII — Risk-Based Example

85. Normal Situation

KNOWN USER

   +

MANAGED DEVICE

   +

NORMAL LOCATION

   +

LOW-RISK ACTION

   =

ALLOW

86. Higher-Risk Situation

KNOWN USER

   +

UNKNOWN DEVICE

   +

UNUSUAL LOCATION

   +

HIGH-VALUE TRANSFER

   =

STEP-UP / RESTRICT / DENY

Part XLIV — Adaptive Authorization

87. Dynamic Decision

Authorization does not always have to remain static for the entire session.

Risk may change.

88. Example

At 9:00:

User accesses normal reports.

At 9:30:

User begins downloading thousands of sensitive records.

System may:

• restrict;

• reauthenticate;

• revoke session.

Part XLV — Continuous Evaluation

89. Modern Model

AUTHENTICATE

     │

     ▼

AUTHORIZE

     │

     ▼

MONITOR

     │

     ▼

CONTEXT CHANGES?

  ┌──┴───┐

 NO     YES

 │       │

KEEP   REEVALUATE

Part XLVI — Access Policy Architecture

90. Two Core Questions

Authorization architecture needs to answer:

1. Who decides?

2. Who enforces?

Part XLVII — Policy Decision Point

91. PDP

The Policy Decision Point evaluates applicable policy and determines whether access should be allowed or denied.

NIST describes the PDP as the access-control component that computes access decisions by evaluating applicable policy.

92. Simple Model

ACCESS REQUEST

      │

      ▼

PDP

Evaluate policy

      │

   ┌──┴───┐

 ALLOW   DENY

Part XLVIII — Policy Enforcement Point

93. PEP

The Policy Enforcement Point enforces the authorization decision.

NIST defines the PEP as the component that enforces access-policy decisions for requests to protected resources.

94. Example

SUBJECT

   │

   ▼

PEP

   │

   ├── Ask PDP

   │

   ▼

DECISION

   │

   ▼

PEP

   │

ALLOW / BLOCK

   │

   ▼

RESOURCE

Part XLIX — Decision Versus Enforcement

95. High-Yield Distinction

PDP

Makes the decision.

PEP

Enforces the decision.

96. Memory Rule

D = Decision

E = Enforcement

Part L — Policy Information Point

97. PIP

A Policy Information Point supplies information needed for policy evaluation.

NIST's Zero Trust implementation glossary describes a PIP as providing telemetry or information that a PDP uses in access decisions.

98. PIP Sources

Examples:

• identity system;

• device management;

• threat intelligence;

• geolocation;

• HR status;

• risk engine.

Part LI — Policy Administration Point

99. PAP

A Policy Administration Point is commonly used to represent the function through which authorization policies are created and managed.

Think:

Where policy is administered.

Part LII — Policy Architecture

100. Complete Concept

POLICY ADMINISTRATION

       PAP

        │

        ▼

      POLICY

        │

PIP ──► PDP

        │

        │ decision

        ▼

       PEP

        │

        ▼

    RESOURCE

Part LIII — Zero Trust Authorization

101. Zero Trust

NIST Zero Trust Architecture states that authentication and authorization of both subject and device occur before establishment of a session to an enterprise resource, without implicit trust based merely on network location.

102. Zero Trust Flow

SUBJECT + DEVICE

       │

       ▼

POLICY ENFORCEMENT POINT

       │

       ▼

POLICY DECISION POINT

       │

   ┌───┼────────────┐

   ▼   ▼            ▼

Identity  Device   Risk

   │      Posture  Context

   └──────┬─────────┘

          ▼

     ALLOW / DENY

Part LIV — Policy Engine and Administrator

103. NIST ZTA Detail

NIST SP 800-207 divides the PDP concept into:

• Policy Engine;

• Policy Administrator.

104. Policy Engine

Determines whether access should:

• be granted;

• denied;

• revoked.

105. Policy Administrator

Establishes or terminates the communication path based on the policy decision.

Part LV — Authorization Is Resource Specific

106. Example

A user may be authorized to:

access SharePoint

but not:

modify payroll.

Authentication can be shared.

Authorization remains resource specific.

Part LVI — Session Authorization

107. Initial Authorization Is Not Forever

A session may need reevaluation when:

• privilege increases;

• resource sensitivity changes;

• risk changes.

Part LVII — Step-Up Control

108. Example

User may:

view account balance

with normal authentication.

But:

wire $100,000

may require stronger verification and authorization.

Part LVIII — Authorization Revocation

109. Access Can Be Withdrawn

Authorization may need immediate revocation when:

• employment ends;

• role changes;

• device becomes compromised;

• suspicious activity occurs.

Part LIX — Access-Control Policy Lifecycle

110. Authorization Rules Require Maintenance

DEFINE POLICY

     │

     ▼

IMPLEMENT

     │

     ▼

TEST

     │

     ▼

MONITOR

     │

     ▼

REVIEW

     │

     ▼

UPDATE / RETIRE

Part LX — Policy Conflict

111. Conflicting Rules

Example:

Rule 1:

Finance may read financial reports.

Rule 2:

Contractors may not read internal financial reports.

User:

Finance contractor.

What happens?

The policy system needs defined conflict-resolution behavior.

112. CISSP Principle

Do not assume ambiguous access should automatically become permission.

Prefer:

clearly defined policy and conservative authorization.

Part LXI — Authorization and Logging

113. Record Access Decisions

Useful authorization logs can include:

• subject;

• resource;

• requested action;

• decision;

• reason/policy;

• timestamp.

114. Why?

Logs support:

• investigation;

• access review;

• compliance;

• anomaly detection.

Part LXII — Authorization Failure

115. Authentication Failure

Wrong password.

116. Authorization Failure

Correctly authenticated user requests:

an action not permitted.

These are different security events.

Part LXIII — Authorization and APIs

117. API Authorization

An API should not assume:

authenticated token = unlimited API rights.

It should verify authorization for:

• requested operation;

• requested object.

118. Example

User can:

GET /users/123

That does not necessarily mean user may:

DELETE /users/123

Part LXIV — Object-Level Authorization

119. Same Function, Different Object

A user may be authorized to:

view their own account

but not:

another customer's account.

Authorization must sometimes evaluate the specific object, not merely the application function.

Part LXV — Privileged Authorization

120. High-Risk Privilege

Administrative permissions should be:

• narrowly scoped;

• separately authorized;

• monitored;

• periodically reviewed.

Part LXVI — Sudo Concept

121. Privilege Elevation

A user may temporarily elevate privilege for an approved administrative action.

This connects to the next lesson's Domain 5.5 privilege-escalation lifecycle objective.

Part LXVII — Combined Authorization Models

122. Real Systems Are Often Hybrid

An organization can combine:

RBAC

  +

ABAC

  +

RULES

  +

RISK

Example:

User must be in the Physician role, assigned to the patient, using a managed device, and not triggering high-risk indicators.

Part LXVIII — Choosing the Model

123. Selection Depends on Requirements

Choose RBAC when:

Access maps strongly to job functions.

Choose MAC when:

Central labels and classifications dominate.

Choose DAC when:

Resource owners need discretionary sharing.

Choose ABAC when:

Fine-grained contextual decisions are required.

Use risk-based controls when:

Access should dynamically adapt to current risk.

Part LXIX — Master Comparison

124. Authorization Models

Part LXX — SierraTec Secure PERMIT Model

125. PERMIT Framework

Use PERMIT when answering authorization questions.

P — Principal

Who or what is the subject?

E — Entitlement Need

What legitimate business access is required?

R — Resource

Which exact object or service is requested?

M — Model

Which authorization model applies?

I — Inspect Context

What attributes, rules, risk, or environmental factors matter?

T — Take and Enforce the Decision

PDP decides; PEP enforces.

126. PERMIT Diagram

P

PRINCIPAL

    │

    ▼

E

ENTITLEMENT NEED

    │

    ▼

R

RESOURCE

    │

    ▼

M

MODEL

    │

    ▼

I

INSPECT CONTEXT

    │

    ▼

T

TAKE & ENFORCE

DECISION

Part LXXI — Worked CISSP Scenarios

127. Scenario 1 — RBAC

An organization grants permissions according to job functions such as Teller, Branch Manager, and Auditor.

Which model is being used?

A. RBAC
B. DAC
C. MAC
D. Risk-based only

Correct Answer

A

128. Scenario 2 — Rule-Based

A firewall permits administration only from the management network between 06:00 and 22:00.

Which model BEST describes this decision?

A. Rule-based access control
B. RBAC only
C. DAC
D. Biometrics

Correct Answer

A

129. Scenario 3 — MAC

A user with Secret clearance cannot access a Top Secret document even though the document's creator wants to share it.

Which model is MOST clearly represented?

A. MAC
B. DAC
C. RBAC
D. SSO

Correct Answer

A

130. Scenario 4 — DAC

The owner of a document chooses which coworkers can read or modify it.

Which model is MOST directly represented?

A. DAC
B. MAC
C. RBAC
D. Kerberos

Correct Answer

A

131. Scenario 5 — ABAC

A doctor may access a medical record only if the doctor is assigned to the patient, is on duty, and uses a compliant device.

Which model BEST fits?

A. ABAC
B. DAC only
C. MAC only
D. Static password access

Correct Answer

A

132. Scenario 6 — Risk-Based

An authenticated customer initiates an unusually large financial transfer from an unknown device in another country. The system requires additional authentication.

Which approach is BEST represented?

A. Risk-based access control
B. DAC
C. Static RBAC only
D. Physical access

Correct Answer

A

133. Scenario 7 — PDP

Which component should determine whether a request satisfies authorization policy?

A. PDP
B. PEP
C. UPS
D. CDN

Correct Answer

A

134. Scenario 8 — PEP

Which component actually blocks the user's request after policy returns DENY?

A. PEP
B. PDP only
C. Certificate Authority
D. KDC

Correct Answer

A

135. Scenario 9 — Separation of Duties

A payment clerk can create and approve the same payment.

What is the PRIMARY problem?

A. Separation-of-duties violation
B. Weak encryption
C. Kerberos failure
D. Network latency

Correct Answer

A

136. Scenario 10 — Least Privilege

A database backup account has Domain Administrator privileges.

What principle has MOST clearly been violated?

A. Least privilege
B. Availability
C. Federation
D. Data retention

Correct Answer

A

Part LXXII — Additional Scenarios

137. Scenario 11 — Access Matrix

Security management wants a conceptual representation showing permissions for every subject against multiple resources.

What model is MOST useful?

A. Access-control matrix
B. Network topology
C. Risk heat map
D. Data-flow diagram only

Correct Answer

A

138. Scenario 12 — ACL

An administrator views a file and sees a list identifying which users and groups may read, write, or modify it.

What is being viewed?

A. ACL
B. TGT
C. OAuth scope
D. VLAN table

Correct Answer

A

139. Scenario 13 — Role Explosion

An organization has created 4,000 roles for 2,500 employees because every slight variation in context requires a different role.

What problem is MOST evident?

A. Role explosion
B. Weak encryption
C. Excessive federation
D. Network convergence

Correct Answer

A

140. Scenario 14 — Bad Attribute

An ABAC policy grants finance access based on the employee's department attribute. HR incorrectly identifies an employee as Finance.

What is the PRIMARY weakness?

A. Attribute quality/integrity
B. Encryption strength
C. Network routing
D. Fire suppression

Correct Answer

A

141. Scenario 15 — Zero Trust

A user was authorized earlier in the day, but endpoint telemetry now reports malware on the user's device.

What is the BEST action?

A. Reevaluate and potentially revoke access.

B. Maintain access forever because authentication succeeded earlier.

C. Disable monitoring.

D. Trust the device because it is corporate-owned.

Correct Answer

A

142. Scenario 16 — Resource Authorization

A user is authorized to read Customer 100's account but changes the URL and accesses Customer 101's record.

What control has MOST clearly failed?

A. Object-level authorization
B. Authentication
C. Encryption
D. Physical access

Correct Answer

A

Part LXXIII — Common CISSP Exam Traps

143. Trap — Authentication Means Access

Incorrect.

Authentication establishes identity.

Authorization determines access.

144. Trap — RBAC Means Rule-Based

Incorrect.

RBAC:

Roles.

Rule-based:

Rules and conditions.

145. Trap — MAC Means MAC Address

Not here.

In access-control discussions:

MAC = Mandatory Access Control.

146. Trap — DAC Means Central Mandatory Policy

No.

DAC gives meaningful access discretion to the object owner or authorized controller.

147. Trap — Clearance Alone Guarantees Access

No.

A subject may also require:

• classification compatibility;

• category/compartment authorization;

• need to know.

148. Trap — RBAC Automatically Provides Least Privilege

Not necessarily.

Poorly designed roles can contain excessive permissions.

149. Trap — ABAC Means User Attributes Only

No.

ABAC may evaluate:

• subject;

• object;

• action;

• environment.

NIST explicitly describes these categories in its ABAC definition.

150. Trap — ABAC Is Always Better Than RBAC

No.

ABAC provides greater flexibility but can increase complexity.

Choose according to requirements.

151. Trap — Risk-Based Means Automatically Deny Risky Users

Risk-based access may:

• allow;

• deny;

• restrict;

• require step-up authentication.

152. Trap — PDP Blocks Traffic

The PDP makes the policy decision.

The PEP enforces it.

153. Trap — Network Location Automatically Authorizes

Zero Trust specifically rejects implicit trust based solely on network location.

154. Trap — ACL Is the Same as an Access Matrix

An ACL is generally an object-oriented implementation view.

The access matrix is a broader conceptual representation.

155. Trap — Owner Can Override MAC

Not ordinarily.

That would contradict the central purpose of Mandatory Access Control.

156. Trap — SSO Determines Permissions

SSO supports authentication.

Authorization remains separate.

Part LXXIV — Knowledge Check

157. Question 1

What does authorization determine?

A. What an authenticated subject may do.
B. Who the subject claims to be.
C. Whether hardware is available.
D. How data is encrypted.

Correct Answer

A

158. Question 2

Which model assigns permissions according to job responsibilities?

A. RBAC
B. MAC
C. DAC
D. Risk-based only

Correct Answer

A

159. Question 3

Which model uses predefined system conditions or rules?

A. Rule-based access control
B. RBAC only
C. DAC
D. SSO

Correct Answer

A

160. Question 4

Which model relies strongly on centrally managed classifications and clearances?

A. MAC
B. DAC
C. SSO
D. OAuth

Correct Answer

A

161. Question 5

Which model commonly allows the object owner to determine access?

A. DAC
B. MAC
C. RBAC only
D. Kerberos

Correct Answer

A

162. Question 6

Which model evaluates subject, object, action, and environmental characteristics?

A. ABAC
B. DAC only
C. SAML
D. RADIUS

Correct Answer

A

163. Question 7

Which model can dynamically use current risk signals?

A. Risk-based access control
B. Static DAC only
C. Physical access only
D. SSO

Correct Answer

A

164. Question 8

Which component makes the authorization decision?

A. PDP
B. PEP
C. Router only
D. Certificate Authority

Correct Answer

A

165. Question 9

Which component enforces the authorization decision?

A. PEP
B. PDP
C. PIP only
D. HR system

Correct Answer

A

166. Question 10

What does a PIP provide?

A. Information needed for policy decisions.
B. Physical power.
C. Encryption keys only.
D. Backups.

Correct Answer

A

167. Question 11

What is least privilege?

A. Providing only permissions required for authorized duties.
B. Giving all users administrator access.
C. Eliminating authorization.
D. Using shared accounts.

Correct Answer

A

168. Question 12

What does need to know primarily limit?

A. Information access.
B. Network bandwidth.
C. CPU capacity.
D. Authentication protocols.

Correct Answer

A

169. Question 13

What is the primary purpose of separation of duties?

A. Prevent one person from controlling an entire sensitive process.
B. Increase password reuse.
C. Remove auditing.
D. Eliminate identity proofing.

Correct Answer

A

170. Question 14

What is role explosion?

A. Excessive proliferation of narrowly defined roles.
B. Failure of a server.
C. A denial-of-service attack.
D. Password compromise.

Correct Answer

A

171. Question 15

What is an ACL?

A. List describing access permissions associated with a resource.
B. Kerberos ticket.
C. Encryption key.
D. Routing protocol.

Correct Answer

A

172. Question 16

Why is attribute integrity important in ABAC?

A. Incorrect attributes can cause incorrect authorization decisions.
B. Attributes determine network speed.
C. Attributes replace authentication entirely.
D. Attributes are always passwords.

Correct Answer

A

173. Question 17

What should happen if authorization cannot establish that access is permitted?

A. Normally deny access.
B. Automatically grant administrator rights.
C. Ignore policy.
D. Disable logging.

Correct Answer

A

174. Question 18

Which model is MOST appropriate when access depends heavily on current device posture and location?

A. ABAC/risk-aware authorization
B. DAC alone
C. Static physical key
D. SSO only

Correct Answer

A

175. Question 19

Which statement is MOST accurate?

A. Real environments can combine RBAC, ABAC, rules, and risk-based decisions.
B. Only one access-control model can ever exist in an organization.
C. Authentication replaces authorization.
D. DAC and MAC are identical.

Correct Answer

A

176. Question 20

Which is the BEST description of authorization?

A. Policy-based determination of whether a subject may perform an action on a resource.
B. Establishing a username.
C. Encrypting data.
D. Backing up accounts.

Correct Answer

A

Part LXXV — Original CISSP-Style Practice Questions

177. Practice Question 1

A company wants employees to receive application permissions automatically according to job function.

Which model is BEST?

A. RBAC
B. DAC
C. MAC
D. Risk-based only

Correct Answer

A

178. Practice Question 2

A research system requires access decisions based on user clearance, project membership, document classification, and geographic location.

Which model BEST supports this level of contextual authorization?

A. ABAC
B. DAC alone
C. Basic RBAC alone
D. Shared accounts

Correct Answer

A

179. Practice Question 3

A military information system prevents document owners from sharing classified information with users lacking required clearance.

Which model is MOST appropriate?

A. MAC
B. DAC
C. SSO
D. OAuth

Correct Answer

A

180. Practice Question 4

A collaboration platform allows document owners to decide which teammates may edit their files.

Which model is MOST clearly represented?

A. DAC
B. MAC
C. Risk-based
D. Kerberos

Correct Answer

A

181. Practice Question 5

A user in the Payroll Manager role can approve payroll, but a policy prohibits approvals outside the approved payroll window.

Which authorization mechanisms are being combined?

A. RBAC and rule-based access control
B. MAC and DAC only
C. SAML and OAuth
D. Kerberos and LDAP

Correct Answer

A

182. Practice Question 6

A Zero Trust gateway sends identity, device-health, and threat information to a component that decides whether access should proceed.

Which component is making the decision?

A. PDP
B. PEP
C. Switch only
D. DNS resolver

Correct Answer

A

183. Practice Question 7

The PDP returns DENY, but a gateway still permits the traffic.

What has failed?

A. Policy enforcement
B. Authentication proofing
C. Identity registration
D. Data classification

Correct Answer

A

184. Practice Question 8

An organization creates an ABAC policy but allows ordinary users to modify their own department and clearance attributes.

What is the GREATEST concern?

A. Untrusted attributes can undermine authorization decisions.

B. ABAC cannot use departments.

C. Authentication becomes impossible.

D. Network latency will rise.

Correct Answer

A

185. Practice Question 9

An employee changes from Accounts Payable to Marketing but retains the Accounts Payable role.

Which risk is MOST directly created?

A. Excessive authorization/access creep
B. Weak encryption
C. Failed authentication
D. Packet loss

Correct Answer

A

The lifecycle correction will be covered in Lesson Twenty.

186. Practice Question 10

An authenticated cloud administrator accesses a highly sensitive resource from a new unmanaged device. Policy allows normal cloud access but requires managed devices for privileged administration.

What should occur?

A. Deny or require remediation/stronger controls for the privileged request.

B. Allow because authentication succeeded.

C. Ignore device condition.

D. Remove all authorization controls.

Correct Answer

A

187. Practice Question 11

A business owner asks security to allow every employee access to a sensitive repository because it will simplify administration.

What is the BEST security response?

A. Define legitimate business roles and apply least privilege.

B. Grant universal access.

C. Disable auditing.

D. Share a common administrator account.

Correct Answer

A

188. Practice Question 12

A payment system permits the same person to create, approve, and release payments.

Which authorization design should be improved FIRST?

A. Separation of duties.

B. Password length.

C. Network topology.

D. Backup retention.

Correct Answer

A

Part LXXVI — Authorization Memory Table

Part LXXVII — Model Memory Table

Part LXXVIII — MAC/DAC/RBAC/ABAC Comparison

Part LXXIX — Policy Architecture Memory

PAP

Policy management

   │

   ▼

PIP ───────► PDP

Information   Decision

               │

               ▼

              PEP

           Enforcement

               │

               ▼

            RESOURCE

NIST's current Zero Trust implementation glossary explicitly distinguishes the PDP, PEP, and PIP functions.

Part LXXX — Key Terms

Authorization

Determination of whether a subject is permitted to perform a requested action on a resource.

Subject

Active entity requesting access.

Object

Protected resource being accessed.

Permission

Authorized operation on a resource.

Privilege

Authorized capability, often associated with elevated system actions.

Entitlement

Access or permission granted to an identity.

Access-Control Matrix

Conceptual representation of subjects, objects, and allowed operations.

ACL

Access Control List associated with a resource.

Capability

Subject-oriented representation of authority to access resources.

Default Deny

Access is denied unless it has been appropriately authorized.

Least Privilege

Granting only permissions necessary for legitimate duties.

Need to Know

Restricting information to individuals with legitimate operational need.

Separation of Duties

Dividing critical responsibilities among multiple entities.

RBAC

Role-Based Access Control.

Role

Organizational function associated with permissions.

Role Hierarchy

Inheritance relationship among roles.

Role Explosion

Excessive creation of narrowly specialized roles.

Rule-Based Access Control

Authorization based on defined rules or conditions.

MAC

Mandatory Access Control.

Security Label

Classification and/or category information used by mandatory policy.

Clearance

Authorization level assigned to a subject.

DAC

Discretionary Access Control.

Object Owner

Entity permitted to exercise discretionary control over an object.

ABAC

Attribute-Based Access Control.

Subject Attribute

Characteristic of the requesting entity.

Object Attribute

Characteristic of the protected resource.

Environmental Attribute

Context such as time, location, device posture, or threat condition.

Risk-Based Access Control

Authorization dynamically informed by current risk.

PDP

Policy Decision Point.

PEP

Policy Enforcement Point.

PIP

Policy Information Point.

PAP

Policy Administration Point.

Policy Engine

Component making grant, deny, or revoke decisions in NIST Zero Trust Architecture.

Adaptive Authorization

Authorization that changes based on current context or risk.

CISSP Exam Focus

When you see an authorization question, use:

WHO IS THE SUBJECT?

        ↓

WHAT IS THE RESOURCE?

        ↓

WHAT ACTION IS REQUESTED?

        ↓

WHAT BUSINESS NEED EXISTS?

        ↓

WHICH ACCESS MODEL APPLIES?

        ↓

WHAT CONTEXT MATTERS?

        ↓

WHO DECIDES?

        ↓

WHO ENFORCES?

Remember:

• Current CISSP Objective 5.4 explicitly includes RBAC, rule-based, MAC, DAC, ABAC, risk-based access control, and PDP/PEP policy enforcement.

• Authentication and authorization are different.

• ACLs are generally object oriented.

• Access matrices provide a conceptual subject/object representation.

• RBAC maps access to organizational roles.

• NIST's RBAC work emphasizes permissions being associated with roles and users being assigned to those roles.

• Role hierarchies can simplify administration but can also cause privilege accumulation.

• Constrained RBAC can enforce separation of duties.

• Rule-based and role-based access control are not the same.

• MAC relies on mandatory centrally administered policy.

• DAC gives resource owners meaningful discretion.

• ABAC evaluates attributes associated with subjects, objects, operations, and environment conditions against policy.

• ABAC depends heavily on trustworthy attributes.

• Risk-based access can adapt according to contextual risk.

• The PDP makes the access decision.

• The PEP enforces the decision.

• PIPs provide information required for decisions.

• Zero Trust does not grant implicit trust based on network location or device ownership.

• Authorization should be reevaluated when meaningful risk or context changes.

• Least privilege applies to every authorization model.

• Need to know limits information exposure.

• Separation of duties reduces concentration of authority.

• Access policies require lifecycle review just like accounts and credentials.

• When authorization is unclear, do not assume permission.

Lesson Summary

Lesson Nineteen moved the IAM discussion from:

Who are you?

to:

What are you allowed to do?

The fundamental authorization relationship is:

SUBJECT

   │

   ▼

REQUESTED ACTION

   │

   ▼

RESOURCE

   │

   ▼

ACCESS POLICY

   │

   ▼

ALLOW / DENY

You examined the major access-control models currently identified by ISC2:

RBAC

   │

RULE-BASED

   │

MAC

   │

DAC

   │

ABAC

   │

RISK-BASED

You learned:

RBAC

USER

  ↓

ROLE

  ↓

PERMISSIONS

NIST describes RBAC as assigning permissions through organizational roles rather than directly to each individual user.

Rule-Based

IF CONDITION

   ↓

THEN DECISION

MAC

CLEARANCE

   +

LABEL

   +

MANDATORY POLICY

DAC

OBJECT OWNER

      ↓

GRANTS ACCESS

ABAC

SUBJECT

   +

OBJECT

   +

ACTION

   +

ENVIRONMENT

   +

POLICY

NIST formally defines ABAC around these attribute and policy relationships.

Risk-Based

IDENTITY

   +

DEVICE

   +

BEHAVIOR

   +

LOCATION

   +

CURRENT RISK

You then examined policy architecture:

PIP

 │

 ▼

PDP

 │

 │ DECISION

 ▼

PEP

 │

 │ ENFORCEMENT

 ▼

RESOURCE

NIST's Zero Trust architecture uses this same distinction between access-policy decision and enforcement and does not grant implicit trust merely because a subject is inside an enterprise network.

The central Lesson Nineteen principle is:

Strong authorization grants only the access required for a legitimate purpose, evaluates the correct policy and context, separates the decision from its enforcement where appropriate, continuously limits privilege, and removes authorization when it is no longer justified.

Exam Readiness Check

Before continuing, make sure you can explain without reviewing:

• Authentication versus authorization.

• Subject versus object.

• Permission versus privilege.

• What an entitlement is.

• What an access-control matrix represents.

• What an ACL is.

• What a capability represents conceptually.

• What default deny means.

• Explicit versus implicit denial.

• Least privilege.

• Need to know.

• Separation of duties.

• What RBAC is.

• How user-role assignments work.

• How role-permission assignments work.

• What role hierarchy means.

• What constrained RBAC means.

• Static versus dynamic separation of duties.

• What role explosion is.

• What rule-based access control is.

• RBAC versus rule-based access control.

• What MAC means.

• What security labels are.

• Classification versus clearance.

• Why need to know still matters in classified environments.

• Why ordinary users cannot freely override mandatory policy.

• What DAC means.

• Why DAC is called discretionary.

• MAC versus DAC.

• What ABAC means.

• Subject attributes.

• Object attributes.

• Action attributes.

• Environmental attributes.

• Why attribute integrity matters.

• What risk-based access control means.

• What adaptive authorization means.

• Why authorization may be reevaluated during a session.

• What the PDP does.

• What the PEP does.

• What the PIP does.

• What the PAP does conceptually.

• The difference between making and enforcing an authorization decision.

• How Zero Trust changes authorization assumptions.

• Why network location does not automatically create authorization.

• Why authorization must be resource specific.

• Why API authentication alone does not establish object-level authorization.

• Why privileged authorization requires stronger control.

• Why access-policy rules must be reviewed over time.

• How RBAC, ABAC, rules, and risk-based controls can work together.

Coming Next

Lesson Twenty: Identity Provisioning, Access Reviews, Privileged Access, and Account Lifecycle

Lesson Twenty will focus on CISSP Domain 5.5 — Manage the identity and access provisioning lifecycle.

The current CISSP outline explicitly includes:

• account-access reviews for users, systems, and services;

• provisioning and deprovisioning;

• onboarding;

• offboarding;

• transfers;

• role definition and transition;

• privilege escalation;

• use of sudo and auditing privileged activity;

• service-account management.

Lesson Twenty will cover:

• Joiner-Mover-Leaver processes;

• identity sources;

• authoritative identity data;

• onboarding;

• account creation;

• initial access;

• access approval;

• birthright access;

• request-based access;

• role assignment;

• group assignment;

• entitlement provisioning;

• access certification;

• access recertification;

• periodic reviews;

• manager reviews;

• data-owner reviews;

• segregation-of-duty reviews;

• transfers;

• role changes;

• access creep;

• privilege accumulation;

• deprovisioning;

• termination;

• emergency termination;

• orphan accounts;

• dormant accounts;

• privileged identities;

• PAM;

• password vaulting;

• privileged session management;

• JIT/JEA concepts;

• privilege escalation;

• sudo;

• administrator accountability;

• break-glass accounts;

• service accounts;

• workload identities;

• machine credentials;

• secret rotation;

• service-account ownership;

• SCIM lifecycle automation;

• access-review evidence;

• original diagrams;

• exam traps;

• CISSP-style scenarios.

The central Lesson Twenty question will be:

How should identities and their privileges be created, reviewed, modified, elevated, and removed throughout the complete access lifecycle so that users, systems, services, and administrators never retain unnecessary access?

Publication and Independence Notice

This lesson is independently developed educational material for the SierraTec Secure CISSP Certification Preparation Course.

CISSP is administered by ISC2. SierraTec Secure's course is independent certification-preparation material and should not be represented as official ISC2 training unless separately authorized.

Current examination alignment was verified against the official ISC2 CISSP Certification Exam Outline. Objective 5.4 currently identifies RBAC, rule-based access control, MAC, DAC, ABAC, risk-based access control, and policy decision/enforcement mechanisms.

ABAC concepts were aligned with NIST SP 800-162, which defines ABAC as evaluating subject, object, operation, and potentially environmental attributes against access-control policy.

RBAC concepts were supplemented by NIST's foundational RBAC model and guidance.

PDP, PEP, and Zero Trust authorization concepts were aligned with NIST SP 800-207 and NIST's current Zero Trust implementation glossary.

The SierraTec Secure PERMIT framework, diagrams, comparisons, scenarios, knowledge checks, and practice questions are original instructional content and are not actual, recalled, leaked, or official CISSP examination questions.