ISC2 CC Domain 3.2 Logical Access Controls

Learning Objectives

By the end of this module, you should be able to:

Explain the core access control lifecycle from identity to authorization.
Distinguish authentication factors and when MFA is required.
Apply least privilege, need-to-know, and just-in-time access.
Compare DAC, MAC, and RBAC and identify common use cases.
Recognize separation of duties and controls that reduce fraud.
Describe account provisioning, modification, and deprovisioning.
Explain how AI changes access control operations and monitoring.
Answer ISC2-style exam questions about access control models.

Access Control Fundamentals

Logical access controls determine what a user, service, or process can do on a system, application, network, or data set. Physical controls keep people out of a room; logical controls keep them out of data, functions, and systems.

Subject -> Object -> Action Model

The simplest way to understand access control is the subject-object-action model.

Subject: the actor requesting access, such as a user, device, service account, or application.
Object: the resource being accessed, such as a file, database record, API, printer, or system.
Action: what the subject wants to do, such as read, write, execute, delete, or approve.

Example: an employee wants to read a payroll file.

Subject: employee
Object: payroll file
Action: read

This model shows why access control is always about matching identity and permissions to a specific resource and operation.

IAAA

IAAA stands for Identification, Authentication, Authorization, and Accountability.

Step	Meaning	Example
Identification	Claiming an identity	Entering a username
Authentication	Proving the identity claim	Password, token, biometric, certificate
Authorization	Determining allowed actions	Permission to read a folder
Accountability	Linking actions back to the actor	Logs, audit trails, timestamps

Exam tip

Identification is the claim. Authentication is the proof. Authorization is the permission. Accountability is the trace.

Authentication Factors

Authentication factors are the categories of proof used to verify identity.

Factor Type	Category	Examples
Type 1	Something you know	Password, PIN, passphrase
Type 2	Something you have	Smart card, token, phone app, hardware key
Type 3	Something you are	Fingerprint, face, iris, voice

MFA Rules

Multi-factor authentication (MFA) requires different factor types. Two passwords do not count as MFA because they are both Type 1. A password plus a phone app token is MFA because it combines Type 1 and Type 2.

Common valid MFA combinations:

Password + hardware token
PIN + smart card
Password + fingerprint
Passphrase + phone-based code

Real-world example

When you log in to a cloud admin portal using a password and then approve a push notification on your phone, you are using MFA. The second factor lowers the chance that stolen passwords alone can be used to gain access.

Exam tip

If the question asks for MFA, the factors must be different types.

Principle of Least Privilege

Least privilege means giving a subject only the minimum access needed to perform a job. Nothing extra.

This is one of the most important access control principles in security.

Why It Matters

Limits the damage of compromised accounts.
Reduces accidental misuse.
Makes auditing simpler.
Helps contain malware and insider threats.

Need-to-Know

Need-to-know is a related concept, especially for sensitive information. Even if someone has general permission, they should only see the specific data required for their role.

Least privilege answers, "What can this account do?" Need-to-know answers, "What information should this person see?"

Just-in-Time (JIT) Access

JIT access grants elevated permissions only when needed and only for a limited time. It is often used for admin tasks, emergency operations, or approvals.

Real-world example: an engineer requests temporary production access for one hour to fix a deployment issue, after which the privileges expire automatically.

Applies to Humans and Machines

Least privilege applies to human users, but also to AI systems, service accounts, scripts, and automation jobs.

A service account should not have full admin rights if it only reads from one database.
An AI assistant should only be allowed to access the minimum data necessary to complete its task.
API keys should be scoped narrowly and rotated regularly.

Exam tip

If a question mentions automation, bots, scripts, or service accounts, least privilege still applies.

Separation of Duties

Separation of duties means splitting critical tasks among multiple people so one person cannot complete a risky process alone.

Purpose

The main purpose is fraud prevention and abuse reduction. If one role creates a transaction and another approves it, it is harder for a single insider to steal or hide money.

Common Examples

Developer is not the same as deployer.
Requester is not the approver.
Administrator is not the auditor.
Person who creates a vendor record should not be the person who pays the vendor.

Collusion

Collusion is the main way separation of duties can be defeated. If two or more people work together dishonestly, they can bypass the control.

Job Rotation and Mandatory Vacations

Job rotation moves staff between roles periodically. Mandatory vacations force a person to be away from their duties for a time. Both can expose hidden fraud because another person will see the process.

Real-world example

In a finance department, the person who enters invoices should not also approve and pay them. Rotating that role or requiring cross-checks makes fraud harder to hide.

Discretionary Access Control (DAC)

DAC is a model where the owner of an object controls access to it.

Core Idea

The user who owns the file or resource decides who gets access. This makes DAC flexible and easy to share, but it is less secure than more restrictive models.

ACLs

Access Control Lists (ACLs) define which users or groups can access an object and what they can do.

Examples:

Allow Alice to read and write.
Allow HR group to read.
Deny guest accounts.

Windows NTFS and Unix rwx

DAC is common in Windows NTFS permissions and Unix file permissions.

Windows NTFS uses permissions like read, write, modify, and full control.
Unix uses rwx: read, write, execute for owner, group, and others.

Strengths and Weaknesses

Flexible and user-friendly.
Easy to share resources.
Often the default in general-purpose systems.
Less secure because users can grant access too broadly.
Vulnerable to Trojan horse behavior if a trusted user runs malicious code.

Real-world example

If a user has permission to access a file and opens a malicious document, that malware may inherit the user's access. That is one reason DAC is considered more vulnerable than stricter models.

Exam tip

If the question emphasizes owner-controlled sharing, ACLs, or file permissions, think DAC.

Mandatory Access Control (MAC)

MAC is a system-enforced model where users cannot change access rules themselves.

Core Idea

The system enforces labels and clearance levels. Access depends on classification, not owner preference.

Clearance Levels

Common security levels include:

Unclassified
Confidential
Secret
Top Secret

Users and objects are labeled, and the system decides whether access is permitted.

Bell-LaPadula

Bell-LaPadula is a confidentiality model.

No read up
No write down

This means a user cannot read data above their clearance and cannot write data to a lower classification where it could leak.

Biba

Biba is an integrity model.

It focuses on preventing low-integrity subjects from contaminating high-integrity data. While Bell-LaPadula protects confidentiality, Biba protects integrity.

Strengths and Weaknesses

Very secure.
Highly controlled.
Often used in military or classified environments.
Less flexible and harder to manage.

Real-world example

A top-secret document cannot be casually copied to an unclassified location. MAC prevents users from overriding the policy, even if they are the owner of the file.

Exam tip

If the question mentions labels, clearances, or "no read up/no write down," the answer is MAC and Bell-LaPadula.

Role-Based Access Control (RBAC)

RBAC assigns permissions based on roles rather than individual users.

Core Idea

Roles map to permissions, and users are assigned to roles.

Roles -> permissions -> users

Example:

Role: Help Desk Technician
Permissions: reset passwords, unlock accounts
Users: Alice, Ben, Carla

Why It Works Well

Scales well in large organizations.
Easier to manage than individual permissions.
Aligns with job functions.
Supports provisioning and auditing.

Common Enterprise Use

RBAC is the most common enterprise model because organizations naturally organize people by job function.

Real-world example

An HR role may be granted access to employee records, while a finance role may be granted payroll permissions. Each employee gets the role that matches their work.

Exam tip

If the question says permissions are tied to job function, choose RBAC.

Master Comparison Table

Model	Who Controls Access	Flexibility	Security Level	Common Use Cases
DAC	Resource owner	High	Lower	General file sharing, home systems
MAC	System/policy	Low	Highest	Government, military, high-security environments
RBAC	Role assignment by admin	Medium to high	Strong in practice	Enterprise applications, HR, IT, finance

How to Remember the Differences

DAC: owner decides.
MAC: policy decides.
RBAC: job role decides.

Account Management Lifecycle

Account management is not just about creating usernames. It is a lifecycle process.

Provision

Provisioning creates an account, assigns permissions, and sets up required controls such as MFA.

Modify

Modification changes privileges as jobs change. This includes promotions, transfers, team changes, and temporary access.

Deprovision

Deprovisioning removes or disables access when the person leaves or no longer needs the account.

Why It Matters

Reduces orphaned accounts.
Prevents ex-employees from retaining access.
Keeps permissions aligned with the current role.

Real-world example

If an employee moves from sales to support, their CRM access may stay the same but their finance access should be removed. On termination, all access should be disabled promptly.

Exam tip

Orphaned accounts and stale privileges are common security problems. Good lifecycle management prevents both.

AI in Access Controls

AI is now part of many identity and access workflows. The exam may not ask deep technical AI questions, but it may test the security implications.

Service Account Management

AI tools often run under service accounts. Those accounts should be tightly scoped, monitored, and rotated.

Good practice includes:

Separate service identities for separate tasks.
Limited API scopes.
Short-lived secrets where possible.
Logging and monitoring for unusual use.

Behavioral Analytics

AI can analyze normal access patterns and flag anomalies.

Examples:

Logging in at unusual times.
Accessing resources never used before.
Sudden spikes in file downloads.

Impossible Travel Detection

Impossible travel means an account appears to authenticate from two far-apart places in an unrealistic time window.

Example: a user logs in from New York and then five minutes later from Tokyo. That is likely suspicious unless there is a valid explanation such as VPN tunneling, but it still deserves investigation.

Real-world example

An identity platform may block or challenge logins when impossible travel is detected, especially if the user also accesses privileged resources.

Exam tip

AI can improve detection, but it does not replace basic controls like MFA, least privilege, and logging.

Putting It All Together

Logical access control works best when multiple layers reinforce each other:

Strong identification and authentication.
MFA for sensitive systems.
Least privilege and need-to-know.
Separation of duties for critical workflows.
The right access model for the environment.
Account lifecycle management.
Logging, audit trails, and anomaly detection.

The best architecture is not just secure. It is also manageable. A secure system that nobody can administer correctly will fail in practice.

Exam Tips

Subject-object-action is the core mental model.
Identification is not authentication.
MFA must use different factor types.
Least privilege applies to users, service accounts, and AI tools.
Separation of duties helps prevent fraud; collusion can defeat it.
DAC is owner-controlled and flexible but less secure.
MAC is system-enforced and most secure but least flexible.
RBAC maps permissions to job roles and scales well.
Bell-LaPadula is about confidentiality: no read up, no write down.
Biba is about integrity.

Practice Questions

What is the first step when a user claims an identity? ✅ Identification
Which access control model is owner-controlled and uses ACLs? ✅ DAC
Which authentication factor category includes a password? ✅ Type 1, something you know
Why is two passwords not MFA? ✅ Both are the same factor type
Which model uses labels and clearance levels? ✅ MAC
What Bell-LaPadula rule prevents writing classified data to a lower level? ✅ No write down
Which model assigns permissions based on job function? ✅ RBAC
What is the main purpose of separation of duties? ✅ Fraud prevention
What is the term for access granted only when needed and for a short time? ✅ JIT access
What detection concept flags a login from New York and Tokyo minutes apart? ✅ Impossible travel detection

Summary

Logical access controls decide who can access what, under which conditions, and with what level of accountability. The key ISC2 concepts are IAAA, authentication factors, MFA, least privilege, separation of duties, DAC, MAC, RBAC, account lifecycle management, and AI-driven monitoring. On the exam, always identify the model or control from the scenario language. If you can map the story to the right access control principle, you will usually find the right answer.