Logical Access Controls

Two principles: least privilege and separation of duties

A new hire on the help desk needs to reset passwords. Should that account also be able to open the company's payroll file? The answer the whole of logical access control turns on is no, and the reason has a name: least privilege. A logical access control is a technical safeguard, enforced by software or firmware, that decides whether a subject (a user, process, or device) may use an object (a file, database, application, or system). Before we look at the three competing models for writing those decisions, learn the two principles that say how generous any decision should be. The principles apply no matter which model you run; keep them on a separate shelf from the models.

Least privilege

Least privilege means restricting every subject to the minimum access its assigned task requires^[1], and nothing beyond that. The help-desk technician gets password-reset rights and not the salary database, because the salary database is not part of the job. The benefit is a smaller blast radius. If that account is phished or misused, the attacker inherits only the handful of permissions it actually held, not the keys to everything.

Need-to-know is least privilege applied to information rather than to systems. The two are easy to confuse, so separate them by what they grant. A clearance or a job title can make you eligible to see a whole category of data; need-to-know^[2] is the narrower decision that you actually require these specific records to do your work. An analyst cleared for Secret material still cannot pull a Secret file that has nothing to do with the current case, because the need-to-know is missing.

Separation of duties

Separation of duties (also written segregation of duties) splits a sensitive process so that no single person holds enough privilege to misuse the system alone^[3]. The textbook case is payments: the person who requests a payment must not be the same person who approves it, because one individual controlling both steps could quietly pay themselves. Dual control is the strictest form, requiring two authorized people to act together to complete one action, like two officers each turning a key to launch. Separation of duties is a preventive administrative control. It reduces the chance of fraud by one insider acting alone, though it does not stop two people colluding, which is why sensitive duties are also rotated.

The two governing principles: least privilege grants only what the task needs; separation of duties splits one sensitive process across two people.

The three access-control models: who gets to decide

Once you know how much access to grant, the next question is who writes the rule. The CC outline teaches three access-control models, and the cleanest way to keep them straight is a single question that each one answers differently: who decides access? With that one axis you never mix them up.

DAC: the owner decides

Under discretionary access control (DAC), access is left to the discretion of the object's owner^[4], who can grant permissions to other subjects and even let them pass those permissions along. The everyday example is sharing a file on your laptop or a shared drive: whoever created the document picks who else may read or edit it. DAC is flexible and is the default in most commercial operating systems, which is also its weakness. Because owners re-share at will, permissions drift in ways no central administrator planned.

MAC: the system decides

Mandatory access control (MAC) is a policy uniformly enforced across all subjects and objects by the system itself^[5]. Each object carries a sensitivity label (for example Confidential, Secret, Top Secret) and each subject holds a formal clearance. The system grants access only when the subject's clearance is high enough for the object's label and a need-to-know exists. The defining trait, and the delta from DAC, is that an ordinary user cannot change a label or hand access to anyone else; the decision belongs to the system, not the owner. That rigidity is exactly why MAC is used in military, government, and intelligence systems where confidentiality must be guaranteed.

RBAC: the role decides

Role-based access control (RBAC) grants access based on the role a user holds in the organization^[6] rather than on individual identity. Permissions attach to roles such as Nurse, Cashier, or Database Administrator, and a user gains those permissions by being placed in the role. When someone changes jobs you move them to a new role instead of editing dozens of individual grants, so RBAC scales cleanly and maps naturally onto least privilege. It sits between the other two: more controlled than DAC because an administrator, not the end user, defines the roles, and lighter than MAC because it needs no clearance hierarchy. RBAC is the common choice for ordinary businesses.

Notice the one shared axis at work. DAC puts the decision with the owner, MAC puts it with the system, and RBAC puts it with the role an administrator defines. Read any scenario by asking who holds the decision, and the model names itself.

One axis, three answers: DAC leaves the decision to the owner, MAC to the system via labels and clearances, RBAC to a role an administrator defines.

Choosing a model, and how MAC checks a request

Picking a model is a trade between flexibility and control, and the same single axis from the last section, who decides, drives the choice. Walk three questions in order and the model falls out.

First, must access be tightly and uniformly controlled, with no user able to over-share? If yes, and the data is classified or highly sensitive, choose MAC, because only MAC takes the decision away from people entirely. If that level of rigidity is not required, move on. Second, do users map cleanly onto well-defined jobs, with many people sharing the same access? If yes, choose RBAC, the scalable middle ground for hospitals, banks, and large enterprises. Third, if neither pressure applies and the priority is letting owners share their own resources conveniently, DAC is the natural fit, which is why ordinary file sharing uses it.

How MAC evaluates one request

MAC is the model most worth seeing step by step, because its check is mechanical and exam-friendly. When a subject asks to read an object, the system compares two things it controls, not the user. It reads the object's label and the subject's clearance, then applies two tests. The clearance must be high enough to dominate the label (a Secret clearance can reach Confidential and Secret data, but not Top Secret), and a need-to-know must exist for that specific object. Only when both tests pass does the system allow access; if either fails, it denies. The user is never consulted and cannot grant an exception, which is the whole point of "mandatory."

This is also where a security label differs from a security marking^[7]. A marking is human-readable text that tells a person how to handle a document; a label is machine-readable metadata bound to the object so the system can parse and enforce it automatically. MAC depends on labels, because a person reading a marking is back to discretion, and MAC's purpose is to remove discretion.

MAC checks one request against two system-held facts, clearance versus label then need-to-know; either failure denies, and the user is never asked.

Exam-pattern recognition

CC questions on this topic reward one habit: read the scenario for who holds the decision, then name the model. The wording is consistent enough that a few patterns cover most items.

Spotting the model from the stem

If the stem says a file owner or user sets or shares permissions on their own resource, the answer is DAC. Trigger words: owner, at their discretion, the user grants access, shared folder.
If the stem mentions labels, classifications, clearances, or sensitivity levels, and stresses that users cannot change the rules, the answer is MAC. Trigger words: Top Secret/Secret/Confidential, security label, clearance, system-enforced, military or government.
If the stem assigns access by job title or function and talks about moving people between groups, the answer is RBAC. Trigger words: role, job function, Nurse/Cashier/Administrator, assign users to groups.

Principle versus model

Another family of questions tests the two principles against each other. A stem where one person can both create and approve a payment, and the fix is to split those duties, is separation of duties, not least privilege. A stem where an account simply has more access than its job needs, and the fix is to trim it, is least privilege. When the scenario is specifically about eligibility versus the specific data required, the answer is need-to-know: a cleared user still being blocked from an unrelated file is the classic tell.

Why the distractors are wrong

The wrong answers usually swap the decider. "The owner assigns clearances" is wrong because clearances are a MAC idea and owners do not assign them. "RBAC lets each user set their own permissions" is wrong because that is DAC's owner-discretion, not RBAC's administrator-defined roles. "MAC is the most flexible model" is wrong because MAC is the most rigid by design; DAC is the most flexible. Anchor every choice to the single axis, who decides access, and the distractors that move the decision to the wrong party fall away.

From stem to answer: match the trigger words to the decider, and the model names itself.

Who decides access: DAC vs MAC vs RBAC

Question	DAC (discretionary)	MAC (mandatory)	RBAC (role-based)
Who decides access	The object's owner	The system, from a central policy	An administrator, by defining roles
Decision is based on	Owner's choice (permissions on the object)	Security labels and user clearances	The user's assigned job role
Can a user re-share access	Yes, owners can grant and pass on rights	No, users cannot change labels or grant access	No, only role membership grants access
Flexibility	Highest, but hardest to control centrally	Lowest, rigid and uniformly enforced	Moderate, controlled yet scalable
Typical use	Personal computers, shared drives, most commercial OSes	Military, government, classified systems	Hospitals, banks, large enterprises

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

A logical access control is a technical safeguard that gates a subject's use of an object

Logical access controls are enforced by software or firmware, and they decide whether a subject (a user, process, or device) may use an object (a file, database, application, or system). They are the technical, or logical, type of control, separate from physical controls like locks and from administrative controls like policies. Every access decision answers two questions: how much access to grant, set by the principles least privilege and need-to-know, and who writes the rule, set by the model DAC, MAC, or RBAC.

Least privilege grants only the access a task needs, shrinking the blast radius

Least privilege restricts every user, process, or device to the minimum permissions its assigned job requires, and nothing more. The benefit is containment: if the account is phished or misused, the attacker inherits only the few permissions it actually held rather than the keys to everything. A help-desk technician who resets passwords should not also reach the payroll file, because reading payroll is not part of that job.

Trap Granting broad access for convenience and planning to trim it later; the standing extra permissions are exactly what an attacker inherits if the account is compromised.

18 questions test this

Need-to-know is least privilege applied to information, separate from clearance

Clearance or job title sets eligibility to see a whole category of data; need-to-know is the narrower decision that a person actually requires these specific records to do their work. The two are independent, so a user cleared for Secret material still cannot pull an unrelated Secret file because the need-to-know is missing. Need-to-know limits which data within an eligibility level a person may touch.

Trap Treating a high clearance as automatic permission to read every file at that level; clearance is eligibility, but need-to-know must also exist for the specific object.

Separation of duties splits a sensitive process so no one person can finish it alone

Separation of duties (also called segregation of duties) divides a critical process across two or more people, so no single individual holds enough privilege to misuse the system by themselves. The classic case is payments: whoever requests a payment must not also approve it, since one person controlling both steps could pay themselves. It is a preventive administrative control aimed at fraud by a lone insider.

Trap Calling it least privilege when the real fix is splitting one over-powered process across two people; least privilege trims one account's access, separation of duties divides the steps.

6 questions test this

Dual control requires two authorized people to act together for one action

Dual control is the strictest form of separation of duties: a single action cannot complete unless two authorized people act together, such as two officers each turning a key. Where ordinary separation of duties splits a multi-step process across people, dual control binds two people to the very same step. Both reduce single-insider abuse but do not stop two people colluding, which is why sensitive duties are also rotated.

Three access-control models differ on one axis: who decides access

DAC, MAC, and RBAC are the three access-control models, and the clean way to tell them apart is a single question each answers differently: who decides access. DAC puts the decision with the object's owner, MAC puts it with the system, and RBAC puts it with a role an administrator defines. Read any scenario by asking who holds the decision and the model names itself.

4 questions test this

DAC lets the object's owner decide and re-share access

Under discretionary access control (DAC), access is left to the discretion of the object's owner, who can grant permissions to other subjects and even let them pass those permissions along. Sharing a file on a laptop or shared drive is the everyday example, and DAC is the default in most commercial operating systems. Its flexibility is also its weakness, because owners re-share at will and permissions drift in ways no central administrator planned.

Trap Believing DAC permissions are centrally controlled; owners can grant and pass on access themselves, which is why DAC is the least centrally controlled model.

6 questions test this

MAC is enforced by the system from labels and clearances, and users cannot override it

Mandatory access control (MAC) is a policy uniformly enforced across all subjects and objects by the system itself. Each object carries a sensitivity label and each subject holds a formal clearance, and the system grants access only when the clearance is high enough for the label and a need-to-know exists. The defining trait is that an ordinary user cannot change a label or grant access to anyone else, because the decision belongs to the system, not the owner.

Trap Assuming an owner can grant an exception or relabel data under MAC; only the system decides, so users have no discretion to override the policy.

RBAC grants access by job role, not by individual identity

Role-based access control (RBAC) attaches permissions to roles such as Nurse, Cashier, or Database Administrator, and a user receives those permissions by being assigned to the role. When someone changes jobs you move them to a new role instead of editing dozens of individual grants, so RBAC scales cleanly and maps naturally onto least privilege. An administrator, not the end user, defines the roles.

Trap Saying RBAC lets each user set their own permissions; that is DAC owner-discretion, while RBAC access comes only through administrator-defined role membership.

16 questions test this

Choose the model by trading flexibility against control

DAC is the most flexible but hardest to control centrally, MAC is the most rigid and uniformly enforced, and RBAC sits in the middle as the scalable, administrator-controlled choice. Pick MAC when access must be tightly and uniformly controlled for classified or highly sensitive data, RBAC when many users map cleanly onto well-defined jobs, and DAC when owners should conveniently share their own resources.

Trap Calling MAC the most flexible model; MAC is the most rigid by design, while DAC is the most flexible because owners control sharing.

MAC fits classified and government systems; RBAC fits ordinary businesses

MAC is used in military, government, and intelligence systems where confidentiality must be guaranteed and individual discretion is too risky to allow. RBAC is the common choice for hospitals, banks, and large enterprises because access maps onto job functions and scales without per-user editing. DAC suits personal computers, shared drives, and most commercial operating systems where convenience matters more than tight central control.

A model alone does not enforce the principles; apply least privilege and separation of duties on top

Choosing DAC, MAC, or RBAC decides who writes the access rule, but it does not by itself guarantee that the rule grants only what each task needs or that sensitive processes are split. Least privilege and separation of duties are principles applied on top of whichever model is in force. A system can run RBAC and still over-grant if its roles bundle more access than the job requires.

An ACL lists which identities may access a resource and what they may do, one access control entry per identity

An access control list (ACL) is a mechanism attached to a resource that enumerates the identities permitted or denied access along with their specific rights (read, write, execute). Each individual line is an access control entry (ACE), which names one trustee (user or group) and the operations allowed, denied, or audited for it.

Trap Treating the ACL as the single entry rather than the whole list; the ACE is the per-identity line inside the ACL.

13 questions test this

In Windows a DACL decides who gets access; a SACL decides whose access attempts get logged

A Windows security descriptor holds two ACL types: the Discretionary Access Control List (DACL) lists the trustees allowed or denied access, while the System Access Control List (SACL) tells the system which access attempts to record in the security event log. Configure the SACL when the goal is auditing access rather than granting it.

Trap Reaching for a DACL to capture an audit trail of access attempts; auditing is the SACL's job.

8 questions test this

An empty DACL denies everyone; a missing (NULL) DACL grants everyone full access

An empty DACL contains no entries, so no access is granted and the system denies all requests. A NULL DACL (no DACL assigned at all) is the opposite and dangerous default: the object has no protection, so everyone gets full access. The same logic applies to ACLs generally: if no entry grants the request, access is denied.

Trap Assuming an empty DACL and a NULL DACL behave the same; the empty one locks everyone out, the missing one lets everyone in.

7 questions test this

Anything not explicitly allowed is denied by default (implicit deny)

Implicit deny, also called default deny, means a request that matches no rule granting it is automatically blocked. It is the safe default for ACLs, firewall rules, and file permissions: access is granted only when a rule explicitly permits it, so a missing entry results in denial.

Trap Expecting traffic or a subject to pass because no rule explicitly blocks it; with implicit deny the absence of an allow rule is itself the block.

9 questions test this

MFA requires factors from two different categories: something you know, have, or are

Multi-factor authentication combines factors from at least two of the three categories: something you know (password, PIN), something you have (token, badge, phone), and something you are (biometric). The point is that compromising one category does not give an attacker the others, so the factors must be of different kinds.

Trap Counting a password plus a PIN (or password plus a security question) as MFA; both are "something you know," so it is still one factor category.

19 questions test this

Modern NIST guidance favors long passwords over forced complexity and drops scheduled expiration

NIST SP 800-63B treats length as the primary driver of password strength and advises against mandatory composition rules, because complexity requirements push users toward predictable patterns. It also recommends against fixed periodic password changes, requiring a change only when there is evidence of compromise.

Trap Mandating character-mix rules and a routine 90-day reset; current guidance calls for length instead and changes only on evidence of compromise.

6 questions test this

Store passwords salted and hashed so a stolen database resists offline cracking

Passwords should be stored using a one-way hash with a unique random salt per password, never in plaintext or reversible form. The salt makes identical passwords hash differently and defeats precomputed rainbow tables, while a deliberately slow hashing scheme makes brute-force guessing of a stolen hash database expensive.

Trap Relying on hashing alone without a per-password salt; without salt, identical passwords share a hash and rainbow tables still work.

5 questions test this

End sessions with an idle timeout, an absolute timeout, and an easy logout

An idle (inactivity) timeout ends a session after a period of no activity, limiting the risk of an unattended workstation being hijacked, while an absolute (overall) timeout caps total session length regardless of activity. Applications should also give users a readily accessible logout to terminate a session on demand.

Trap Confusing the idle timeout with the absolute timeout; the idle one triggers on inactivity, the absolute one fires after a fixed duration even on an active session.

8 questions test this

Enforce authentication and session timeouts server-side where the client cannot tamper with them

Session timeout, expiration, and authentication enforcement must live on the server, not the client. If timing or authorization is tracked in client-controlled data such as cookies, an attacker can manipulate it to extend a session indefinitely, so security controls belong where the user cannot reach them.

Trap Trusting client-side cookie values to enforce session timeout; an attacker edits them, so the server must track inactivity itself.

6 questions test this

Review access periodically and on every role change to stop privilege creep

Privilege creep is the gradual accumulation of access rights beyond what a user's current job needs, typically when someone changes roles but keeps old permissions. Counter it with periodic (regular) access reviews plus event-driven reviews triggered by transfers, removing rights that are no longer required to keep least privilege intact.

Trap Granting new access on a role change without removing the old; keeping both is exactly how privilege creep accumulates.

9 questions test this

Disable a leaver's access immediately so no orphan accounts remain

When an employee is terminated, the first and most critical step is to immediately disable or revoke all of their access, ideally driven by an HR-initiated lifecycle event. Accounts left active after someone departs become orphan accounts that former staff, contractors, or attackers can still use to reach internal systems and data.

Trap Deleting the leaver's data or escalating to legal before cutting access; revoking the credentials comes first to close the window for unauthorized entry.

10 questions test this

RBAC grants access by role so administration scales, and senior roles can inherit junior permissions

Role-Based Access Control assigns permissions to roles and users to roles, so admins manage stable roles instead of editing each user individually, which is its main advantage at scale. A role hierarchy lets senior roles automatically inherit the permissions of junior roles, further reducing duplication.

Trap Assigning permissions directly to each individual user; that does not scale and is the very overhead RBAC's role layer removes.

3 questions test this

Two principles: least privilege and separation of duties

Least privilege

Separation of duties

The three access-control models: who gets to decide

DAC: the owner decides

MAC: the system decides

RBAC: the role decides

Choosing a model, and how MAC checks a request

How MAC evaluates one request

Exam-pattern recognition

Spotting the model from the stem

Principle versus model

Why the distractors are wrong

Who decides access: DAC vs MAC vs RBAC

Decision tree

Cheat sheet

Also tested in

References