Access Control
The access-control model: subject, object, decision
Reading a database row and opening a server-room door look like unrelated problems, yet this subtopic insists they are one kind of event with one structure, and an exam scenario is solved by decomposing it into that structure: a subject that requests, an object that is protected, and a system that decides between them. Get that decomposition automatic and you can place any control, logical or physical, precisely.
Access control is the process of granting or denying specific requests to obtain and use information and related processing services, and to enter specific physical facilities[1]. That single definition is deliberately broad: the request to read a database row and the request to open a server-room door are the same kind of event, evaluated the same way. Reasoning about both under one model is what lets a security leader run one coherent access program instead of two.
The three parts
Every access event has three parts:
- Subject: the active entity making the request. NIST defines a subject as the entity requesting to perform an operation upon the object[2]. A subject is usually a person, but it can be a process or a device acting on a person's behalf.
- Object: the passive entity being protected. NIST defines an object as an entity to be protected from unauthorized use[3]; CNSSI elaborates it as a passive entity (devices, files, records, tables, processes, programs, domains) that contains or receives information.
- Access-control system: what sits between them: a policy that states the allowable operations, a decision point that evaluates each request against the policy, and an enforcement point that admits or blocks the request. NIST SP 800-162 frames the decision as evaluating attributes associated with the subject, object, requested operations, and environment conditions against policy[4].
The word "subject" is a common stumbling block: it is the requester, not the data. The data being requested is the object. Keeping that straight matters because the access models in authorization-mechanisms are defined by who controls the subject-to-object permission (the object's owner under DAC, a central label authority under MAC).
Logical and physical are two surfaces of one model
The model is identical whether the object is logical or physical. A logical object (a record, an application, a service, an API) is reached through software, so its enforcement point is a technical control. A physical object (a building, a cage, a piece of equipment) is reached through space, so its enforcement point is a physical control such as a lock or a badge reader. A server holding regulated data in a colocation facility is protected on both surfaces at once: technical controls gate the data, physical controls gate the cage, and a security leader who manages only one has left the other open.
AAA: how the decision is sequenced
This section explains the order in which the access-control system reaches its decision. The sequence is not arbitrary: each stage depends on the one before it, so getting the order right is itself an exam-tested point.
The four stages, in order, are identification → authentication → authorization → accountability (the first three are the classic "AAA" triad; accountability is the fourth pillar that makes the others auditable):
- Identification: the subject asserts a claimed identity: a username, an account number, a badge ID. This is a claim only; nothing is proven yet.
- Authentication: the subject proves the claim with one or more factors (something you know / have / are). Until this succeeds, the asserted identity is untrusted. Factor selection and assurance levels are developed in identification-authentication; here it is simply the proof step.
- Authorization: now that the identity is proven, the decision point determines what operations this subject may perform on the requested object, by applying the policy. Which policy model governs that determination (DAC, MAC, RBAC, ABAC) is the subject of authorization-mechanisms.
- Accountability: the action is logged and attributed to the subject so it can be reconstructed later. Accountability is the result of the first three done correctly: you can only hold a subject accountable for an action you can attribute, which requires a unique identity that was authenticated before it was authorized.
Why the order is load-bearing
The dependency runs strictly forward. You cannot authorize an identity you have not authenticated: granting permissions to an unproven claim is exactly the failure that impersonation exploits. You cannot achieve accountability without unique identification: this is why shared accounts defeat accountability: when several people use one credential, the logs attribute every action to the account, not to a person. A leader who needs individual attribution (for a privileged operation, for a regulated transaction) must therefore require unique identities, not merely strong passwords on a shared one.
Classifying controls: function and implementation type
This section gives you the vocabulary to label any access control on the two axes a CISSP question expects, and to reason about layering them. It assumes the subject/object model from the first section.
A control is described on two independent axes. Confusing the two (calling a lock "preventive" when the question wants "physical") is a classic distractor, so always read which axis the stem is asking about. The grid below holds the function axis down the side and the implementation-type axis across the top; one mechanism, the door badge, is plotted to show how the same event lands in different cells depending on which control around it you name.
Axis 1: function (what the control does relative to the event)
- Preventive stops the unwanted action before it happens. A deny rule, a locked door, a separation-of-duties policy.
- Detective reveals an action after it happens. An access log, an intrusion-detection alert, a CCTV recording.
- Corrective restores the expected state after an incident. Revoking a compromised credential, restoring from backup.
(Some taxonomies extend this list with deterrent, recovery, compensating, and directive; preventive/detective/corrective are the three a question almost always turns on. Treat the extras as refinements, not a different scheme.)
Axis 2: implementation type (how the control is realized)
- Administrative: policies, procedures, standards, training, background screening. Also called managerial controls in NIST SP 800-53 Rev. 5.
- Technical (logical): software and hardware mechanisms: authentication, access-control lists, encryption, intrusion detection.
- Physical: tangible barriers and devices: locks, fences, mantraps, guards, badge readers, CCTV.
The two axes are independent
Every control carries one label from each axis, and the same mechanism is named differently depending on which axis you are on. A badge reader at a door is a preventive, physical control; the recording it feeds is a detective, physical control; the policy requiring badges is a preventive, administrative control. NIST SP 800-53 Rev. 5 organizes its safeguards into control families (for example the Access Control (AC) family[5]) and tags each as managerial, operational, or technical: the same two-dimensional thinking.
Layering across categories is defense in depth
Because the axes are independent, a single asset can be protected by controls drawn from several cells at once: a preventive technical control (authentication) backed by a detective technical control (logging) and a preventive physical control (a locked room). Deliberately spreading controls across functions and types so that no single failure exposes the asset is defense in depth, and it is why the classification matters in practice. It tells you which cells of the grid you have not yet covered.
Exam-pattern recognition
- A stem describing a control and asking for its category is testing whether you can place it on both axes. Read whether it wants function (preventive/detective/corrective) or type (administrative/technical/physical): the answer set usually mixes the two to catch a misread.
- "Which control would best detect unauthorized access after the fact?" points to a detective control (a log or review), not a stronger lock.
- "A new system has no access policy yet, what is the safest default?" tests default-deny / fail-closed: deny absent an explicit grant, so a policy gap is safe.
- "Users accumulate access as they change roles" is a least-privilege / need-to-know failure (privilege creep), resolved by access reviews and removing access when the task ends, not by adding stronger authentication.
- A stem stressing that an action must be traceable to one individual is testing accountability, which requires unique identification; the correct answer rejects shared accounts regardless of password strength.
Access controls classified on two axes: function and implementation type
| Function \ Type | Administrative (policy/people) | Technical / logical (software/hardware) | Physical (tangible barrier) |
|---|---|---|---|
| Preventive (stop before) | Separation of duties policy, hiring screening | Authentication, access-control list, encryption | Lock, fence, mantrap, badge reader |
| Detective (reveal after) | Audit / access review, supervision | Access log, intrusion detection, SIEM alert | CCTV recording, motion sensor, guard patrol |
| Corrective (restore after) | Incident response procedure, account-review remediation | Credential revocation, restore from backup | Fire suppression discharge, replacing a broken lock |
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.
- Access control is one process governing both information and physical facilities
Access control is the process of granting or denying specific requests to obtain and use information and processing services, and to enter specific physical facilities. The reason it spans both is that a request to read a file and a request to badge into a data center are the same kind of event: each is evaluated against an authorization decision before the resource is reached. So a security leader runs one access program with one control vocabulary, not separate logical and physical regimes that can leave one surface open.
Trap Treating logical access control and physical access control as two unrelated programs governed by separate teams and policies, when CISSP frames them as one access-control process applied to different surfaces.
- A subject is the requester; an object is the thing being protected
The subject is the active entity requesting an operation (usually a user, but possibly a process or device acting for one); the object is the passive entity being protected from unauthorized use: a file, record, device, process, facility, or service. The distinction is load-bearing because the authorization models are defined by who controls the subject-to-object permission, so mislabeling the data as the subject inverts the whole picture.
Trap Treating the data or resource as the subject. The data is the object; the subject is whoever or whatever is requesting access to it.
- Every access reduces to subject, object, and an access-control system between them
Between the subject and object sits the access-control system: a policy stating allowable operations, a decision point that evaluates each request against that policy, and an enforcement point that admits or blocks it. This model is universal: identification, authentication, authorization, and accountability are stages within that decision, and DAC/MAC/RBAC/ABAC are simply different policies the decision point applies. Anchoring every mechanism to a place in this picture is what keeps the IAM domain coherent.
Trap Confusing the policy decision point that evaluates a request with the policy enforcement point that admits or blocks it. The PDP decides, the PEP enforces, and conflating them obscures where a control actually lives.
- AAA runs in fixed order: identify, authenticate, authorize, then account
An access decision proceeds as identification (the subject claims an identity), authentication (it proves the claim with one or more factors), authorization (the now-proven subject is granted specific operations on the object), and accountability (the action is logged and attributed). The first three are the classic AAA triad; accountability is the fourth pillar that makes them auditable. The order is not arbitrary: it is strictly forward-dependent.
Trap Reading the AAA triad as authentication, authorization, accounting and dropping identification, or reordering the stages. Identification must precede authentication, which must precede authorization, which must precede accountability.
- You cannot authorize an identity you have not authenticated
Authorization decides what a subject may do, but only after authentication has proven the subject is who it claims to be. Granting permissions to an unproven claim is precisely the gap that impersonation exploits, which is why authentication always precedes authorization in the sequence. Identification merely asserts an identity; it carries no trust until authentication validates it.
Trap Treating a presented identifier (a username or claimed identity) as sufficient to grant access. Identification asserts who you are but proves nothing, so authorization must wait until authentication validates the claim.
- Accountability requires unique identification, so shared accounts defeat it
Accountability is the ability to tie an action back to one individual through logging, and it depends on each subject having a unique, authenticated identity. When several people share one credential, the logs attribute every action to the account rather than to a person, so attribution (and therefore accountability) is lost. A scenario demanding traceability to an individual must use unique identities, not a strong password on a shared account.
Trap Hardening a shared account with a stronger password or MFA to satisfy an accountability requirement. Strength does not restore attribution; only unique per-person identities do.
- Default-deny means a policy gap is safe, not permissive
A sound access posture starts closed: absent an explicit grant, the request is denied (default-deny, also called fail-closed). The benefit is that a missing or incomplete policy results in no access rather than open access, so gaps fail safe instead of exposing the asset. New systems and new rules should therefore inherit a deny baseline before any allow is added.
Trap Assuming an unconfigured or undefined access rule defaults to allow. A secure access-control system denies by default, so the absence of a grant is a denial.
- Privilege creep is a least-privilege failure fixed by access reviews, not stronger auth
When subjects change roles and keep their old access, permissions accumulate beyond what any current task needs: privilege creep, a direct violation of least privilege. The remedy is periodic access reviews and recertification that strip access no longer justified, plus removing access at role change. Stronger authentication does not help, because the problem is excess authorization, not a weak login.
Trap Reaching for stronger authentication or more frequent password changes to fix privilege creep. The defect is accumulated authorization, remedied by access reviews and recertification, not by a tougher login.
- Controls are classified on two independent axes: function and type
Any access control carries one label for what it does (function) and one for how it is implemented (type), and the two are independent. Function is preventive, detective, or corrective; type is administrative, technical (logical), or physical. A question asking to categorize a control is testing whether you can place it on the correct axis, so read whether the stem wants function or type before answering.
Trap Answering with a function label (e.g. preventive) when the stem asks for the implementation type (e.g. physical), or vice versa. The answer set deliberately mixes the two axes.
- Preventive stops before, detective reveals after, corrective restores after
On the function axis, a preventive control stops an unwanted action before it happens (a lock, a deny rule, separation of duties); a detective control reveals an action after it happens (an access log, IDS alert, CCTV recording); and a corrective control restores the expected state after an incident (revoking a credential, restoring from backup). The defining question is timing relative to the event: before, after-to-reveal, or after-to-restore.
Trap Picking a stronger preventive control (a better lock) when the stem asks what would best detect access after the fact. Detection calls for a log, review, or alert, not prevention.
- Administrative, technical, and physical name how a control is implemented
On the implementation-type axis, administrative (managerial) controls are policies, procedures, standards, training, and screening; technical (logical) controls are software and hardware mechanisms such as authentication, access-control lists, and encryption; physical controls are tangible barriers such as locks, fences, mantraps, guards, and badge readers. NIST SP 800-53 organizes safeguards into families and tags each as managerial, operational, or technical: the same dimension.
Trap Classifying a security-awareness training program or background screening as a technical control because it concerns computer use. Staffing, training, and policy are administrative controls regardless of what they govern.
- One mechanism carries one label per axis, so the same control is named twice
Because the two axes are independent, a single mechanism is described by both at once. A badge reader at a door is a preventive, physical control; the recording it feeds is a detective, physical control; the policy requiring badges is a preventive, administrative control. So the correct answer often depends entirely on which axis the question is probing, not on the mechanism alone.
Trap Assuming a mechanism has only one fixed category, so that a CCTV camera is always just detective. The same device can be deterrent, preventive, or detective depending on which axis and role the stem is asking about.
- Defense in depth layers controls across functions and types
Defense in depth deliberately spreads controls across different functions and implementation types so no single failure exposes the asset: for example a preventive technical control (authentication) backed by a detective technical control (logging) and a preventive physical control (a locked room). The two-axis classification is useful precisely because it shows which cells of the grid are not yet covered. Layering, not any one perfect control, is the goal.
Trap Treating several instances of the same control (more firewalls, more passwords) as defense in depth. Layering means diverse controls across different functions and types, not redundant copies of one mechanism.
- Logical and physical objects need the same access process on different surfaces
A logical object (record, application, service, API) is reached through software, so its enforcement is a technical control; a physical object (building, cage, equipment) is reached through space, so its enforcement is a physical control. An asset with both attack paths (a server holding regulated data in a colocation cage) must be protected on both surfaces at once. Securing only one surface leaves the other fully open.
Trap Assuming strong logical controls (encryption, authentication) on a server make its physical placement irrelevant. An attacker with physical access to the cage bypasses or undermines the logical surface, so both must be enforced.
- RFID asset tracking: metal causes interference, passive tags can't protect data, segment the readers
In metal-dense data centers, detuning and multipath interference cause RFID false positives and negatives, addressed with anti-metal tags plus power-mapping to find dead zones. Passive tags have too little compute/storage to support authentication or encryption, leaving them open to eavesdropping and cloning (replica tags that fool the reader); active tags can carry mutual authentication. NIST advises firewalling RFID databases off from other IT systems so IP-enabled readers can't become a network entry point.
Trap assuming passive RFID tags can be secured with encryption/authentication, or ignoring metal-environment interference
8 questions test this
- A data center manager is evaluating RFID solutions for tracking IT equipment in a metal-dense environment. The security team reports that…
- A security manager is selecting RFID technology for tracking high-value IT equipment in a data center environment. The primary concern is…
- A logistics company needs to track assets across a large warehouse with real-time location capabilities. The security team must balance…
- An organization discovers that an attacker has created replica tags that behave exactly like genuine tags in their RFID asset tracking…
- A security architect is designing an RFID-based asset tracking system for a data center. Which characteristic of passive RFID tags presents…
- An organization is integrating its RFID asset tracking system with its enterprise IT asset management platform. According to NIST…
- According to NIST guidance on securing RFID systems, which control is MOST effective for preventing unauthorized access to an…
- When deploying RFID readers for asset tracking in a data center environment, which challenge is MOST likely to impact tracking accuracy…
Also tested in
References
- NIST CSRC Glossary: access control (FIPS 201-3 / NIST SP 800-53 Rev 5) Whitepaper
- NIST CSRC Glossary: subject (NIST SP 800-162) Whitepaper
- NIST CSRC Glossary: object (NIST SP 800-53 Rev 5 / CNSSI 4009-2015) Whitepaper
- NIST SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations Whitepaper
- NIST SP 800-53 Rev 5: Security and Privacy Controls (Access Control family) Whitepaper