Security Operations Concepts
Two access principles, two anti-fraud goals
Hold one mental model with two halves: the first half decides how much access to grant, the second half decides how to stop or surface abuse of access already granted. Beyond knowing what authentication and authorization are, the page turns on telling apart the two access principles (least privilege, need-to-know) from the two operational anti-fraud goals (separation of duties, which prevents, and rotation, which detects), because exam stems describe a mechanism and ask you to name the right one.
Least privilege and need-to-know
Least privilege is the foundational rule: grant every subject (user, process, or service) only the minimum access required to perform an assigned task, and revoke it when the task ends. NIST SP 800-53 defines it[1] as restricting access to the minimum necessary to accomplish assigned tasks. Need-to-know is least privilege applied specifically to information: a clearance or role sets the ceiling of what a subject could ever access, and need-to-know is the gate that decides which specific records within that ceiling they actually require right now. The relationship matters because the exam tests it directly: a person can hold the correct clearance and still be denied a particular file because they have no job-related need for it. Hold the canonical framing in mind: clearance/role sets the ceiling; need-to-know decides the contents.
Separation of duties: the collusion requirement
Separation of duties (SoD) divides a single sensitive process across different people so that no one individual can both perform a critical action and conceal it. NIST SP 800-53 AC-5[2] frames the objective as reducing the risk of malevolent activity without collusion: that phrase is the heart of the concept. The classic example is that the person who prepares or requests a payment must not also be the person who approves it; subverting the process then requires two people to conspire. SoD is preventive and administrative: it does not catch wrongdoing after the fact, it structurally removes the ability of any one person to act alone. A frequently tested corollary is that the staff who administer access controls must not also administer the audit logs, otherwise the one person could both misuse access and erase the evidence.
Rotation and vacation: detecting what prevention misses
The access principles and SoD are all preventive: they shape who can do what. The second anti-fraud goal is detective: assume access was legitimately granted and create conditions under which a hidden, ongoing abuse comes to light. Job rotation and mandatory vacation serve this goal and are explained in the next section (Enforcing SoD); they are named here only as the detective counterpart so the page's spine is clear: prevention limits access, detection surfaces misuse of access already held.
Enforcing SoD: dual control, M-of-N, split knowledge
This section covers the concrete mechanisms that turn the SoD goal (no one person can act alone) into an enforced control, plus the privileged-account and personnel mechanics that operationalize the rest of the page. It matters because exam stems rarely ask 'what is SoD'; they describe a mechanism and ask you to name it or pick it for a scenario. The figure groups those mechanics into the three families this section walks through: the SoD-enforcement techniques, the personnel detective controls, and the privileged-account discipline.
Dual control, two-person integrity, and M-of-N
Dual control (also called two-person control or two-person integrity) requires two authorized individuals to approve and (often) be present before a sensitive action executes. NIST SP 800-53 AC-3(2) calls this dual authorization[3] and notes it reduces insider-threat risk by requiring the approval of two authorized individuals to execute. M-of-N control generalizes the idea: any M of N trusted holders must agree (for example 3 of 5) so the process still works if one or two holders are unavailable, trading a little exclusivity for resilience. Use plain two-person control when exactly two parties suffice; reach for M-of-N when you need the action to survive an absent holder.
Split knowledge divides a single secret (an encryption key, a master password, a safe combination) so that no one person holds the whole thing and reconstructing it requires the parties to combine their parts. Distinguish it cleanly from dual control: dual control governs an action (two people must approve an event), whereas split knowledge governs a secret (two people each hold a fragment). They are frequently combined: split a key into parts (split knowledge) and require M of the N part-holders to reconstruct it (M-of-N).
Rotating dual-control duties, job rotation, and mandatory vacation
To keep the same two people from quietly colluding forever, AC-3(2) explicitly suggests rotating dual authorization duties[3], and that is the authoritative basis for job rotation as an anti-collusion personnel control. Job rotation moves staff between roles so a successor eventually performs a predecessor's duties and would notice an irregularity, and it reduces any one person's long-term lock on a sensitive position. Mandatory vacation forces an employee out of their function for a continuous period (commonly one to two weeks) so a substitute must cover the work; a fraud that depends on the perpetrator's daily presence to stay hidden tends to surface while they are away. Both are administrative detective controls: they assume access was legitimate and create the conditions under which a concealed abuse becomes visible.
Privileged access management and monitoring
Privileged accounts (administrator, root, domain admin, service, and emergency 'break-glass' accounts) can override the other controls, so they get extra management. Privileged access management (PAM) replaces always-on standing admin rights with access that is requested, time-bound, approved, and logged; a reference implementation grants just-in-time, time-bound role activation requiring approval and MFA, with audit history[4]. The control objective is to remove standing privilege: assigning a named human owner to each admin or service account fixes attribution but, on its own, still leaves the account permanently privileged. Monitoring privileged use is the inseparable second half: every privileged session and every break-glass activation should raise logs and alerts that are actually reviewed, because the entire reason to compromise such an account is to act unseen. (The day-to-day provisioning lifecycle of these accounts is owned by the identity-and-access-management subtopic; here the focus is the operational discipline of constraining and watching privilege.)
SLA vs OLA vs UC, and the metrics they carry
This section covers service level agreements and their two siblings, because CISSP stems routinely test whether you can tell apart who each agreement faces. It matters operationally: agreements are how you hold accountable the services you do not directly control. The figure below shows the support structure the prose builds toward: the customer-facing SLA on top, held up by an internal OLA and an external UC.
What an SLA is and the metrics it carries
A service level agreement (SLA) is a documented, measurable commitment about how a service will perform: uptime/availability, response and resolution times, breach-notification windows, and patch timelines, with remedies when targets are missed. The SLA is the enforcement mechanism for anything you cannot configure yourself, because you cannot directly control a third party's systems, the contract and its service-level requirements carry the measurable security obligations[5], such as breach-notification windows, patch timelines, and a right-to-audit clause. For continuity specifically, external dependencies must be bound by SLAs aligned to the dependent process's recovery time objective (RTO)[6]: the vendor's promised response-after-notification has to fit inside the time you have to recover.
OLA and UC: who each agreement faces
Keep three related agreements straight by who they face:
| Agreement | Faces | Purpose |
|---|---|---|
| SLA | The customer / business consumer | The externally-visible promise about service performance |
| OLA (operational level agreement) | Internal supporting teams | Internal commitments that enable the SLA to be met |
| UC (underpinning contract) | An external supplier | A vendor's contractual commitments backing the SLA |
The distinction is the whole point of the exam item: an OLA is internal (one team to another inside your organization), while a UC is external (your organization to a third-party supplier). Both exist to make the customer-facing SLA achievable: if an internal team or an upstream vendor cannot meet its targets, the SLA cannot hold.
Exam-pattern recognition
These stems reward matching the property to the concept rather than recalling a definition. Recurring patterns:
- 'Holds the correct clearance but is still denied a file.' The missing element is need-to-know, not least privilege in general: the clearance is the ceiling, need-to-know is the gate.
- 'A clerk can both create a vendor and approve its invoices.' The control to impose is separation of duties, enforced with dual control on the approval step.
- 'Two of five custodians must combine their parts to restore the master key.' This is M-of-N; if the stem says no one person knows the whole key, it is also split knowledge.
- 'A long-tenured employee never takes time off and resists any reassignment.' The detective controls are mandatory vacation and job rotation: they surface a scheme that needs the person's daily presence.
- 'An administrator account is named after a specific person but is always on.' Naming gives attribution but not control; the fix is PAM (just-in-time, time-bound, monitored), because a named-but-permanent admin still has standing privilege.
- 'How fast must the vendor respond after we report an outage?' That number belongs in the SLA, aligned to your RTO; if the question is about an internal team's commitment it is an OLA, and if about the supplier's contractual backing it is a UC.
Foundational secops concepts: what each control does and the trap it guards against
| Concept | Control type | Goal it serves | Requires collusion / multiple parties? |
|---|---|---|---|
| Least privilege (AC-6) | Preventive, administrative | Minimize access to the minimum needed for the task | No. A per-entity ceiling |
| Need-to-know | Preventive, administrative | Restrict specific information within the clearance ceiling | No. A per-information gate |
| Separation of duties (AC-5) | Preventive, administrative | No one person can complete and conceal a sensitive task | Yes. Abuse needs collusion |
| Dual control / two-person (AC-3(2)) | Preventive, administrative | Two approvers required to execute one action | Yes. Two parties |
| M-of-N control | Preventive, administrative | Any M of N holders must agree; survives an absent holder | Yes. M parties |
| Split knowledge | Preventive, administrative | No one holds a complete secret/key | Yes. Parts must be combined |
| Privileged access management (PAM) | Preventive + detective | Remove standing admin rights; monitor privileged use | No, per-account, but adds approval |
| Job rotation | Detective, administrative | A successor surfaces a predecessor's hidden abuse | No. Exposes solo fraud |
| Mandatory vacation | Detective, administrative | Absence forces coverage that uncovers concealed schemes | No. Exposes solo fraud |
| SLA / OLA / UC | Administrative agreement | Make service performance measurable and enforceable | N/A. Contractual obligation |
Decision tree
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.
- Least privilege grants the minimum access a task needs, then revokes it
Least privilege restricts every subject (user, process, or service) to the minimum access required to accomplish an assigned task, and removes that access when the task ends (NIST SP 800-53 AC-6). It is a preventive administrative control: by keeping grants small and temporary, it limits the blast radius of a compromised account or a malicious insider. Think of it as the default posture for every access decision, not a one-time configuration.
Trap Picking 'need-to-know' when the stem only describes holding access down to what a task requires; that broad minimum-access posture is least privilege, while need-to-know is its narrower information-level application.
- Need-to-know is least privilege applied to specific information, not to roles
Need-to-know narrows least privilege to information: a clearance or role sets the ceiling of what a subject could access, and need-to-know decides which specific records within that ceiling they actually require for the job at hand. So a person with the correct clearance can still be denied a particular file because they have no job-related need for it. The exam phrasing 'has the clearance but not the need' is asking for need-to-know, not least privilege in general.
Trap Answering 'least privilege' when a stem says someone with the right clearance is denied a specific file. The precise control being tested is need-to-know, the information-level gate under the clearance ceiling.
2 questions test this
- Separation of duties means no one person can complete and conceal a sensitive task
Separation of duties (SoD) splits a critical process across different people so that abusing it requires collusion. Its defining objective (NIST SP 800-53 AC-5) is reducing malevolent activity without collusion. The textbook case is that whoever requests or prepares a payment must not also approve it. SoD is preventive and administrative; it structurally removes any single person's ability to subvert the process alone, rather than detecting abuse afterward.
Trap Calling separation of duties a detective control. It is preventive: it stops a solo actor up front rather than discovering misuse after the fact.
- The access-control administrators must not also administer the audit logs
A specific SoD requirement is that the staff who administer access-control functions must not also administer the audit functions that would catch their misuse (NIST SP 800-53 AC-5). If the same person controls both, they can grant themselves access and then erase the evidence. CISSP stems that put log administration and access administration in one role are testing this exact conflict-of-duties split.
Trap Accepting one person holding both access administration and audit administration as long as their actions are logged; those very logs are what such a person can alter, so the duties themselves must be separated.
- SoD can be static (roles never co-held) or dynamic (enforced at execution)
Static separation of duties bars conflicting roles from ever being assigned to the same person, while dynamic separation of duties allows the assignments but blocks the conflicting actions at execution time. For example a two-person rule that prevents one user from performing both halves of a transaction in the same session (NIST SP 800-192). Static is simpler to audit; dynamic is more flexible where one person may hold both roles but must never exercise them together.
Trap Labeling the variant that lets one person hold both conflicting roles but blocks using them together as 'static'; that runtime enforcement is dynamic SoD, whereas static forbids the conflicting assignments outright.
- Dual control requires two authorized people to approve one sensitive action
Dual control (also called two-person control or two-person integrity, and named dual authorization in NIST SP 800-53 AC-3(2)) requires the approval of two authorized individuals before a sensitive action executes, which reduces insider-threat risk. It governs an action: two people must agree for the event to happen. It is the most common concrete mechanism used to enforce a separation-of-duties requirement on an approval step.
Trap Reaching for 'split knowledge' when the stem requires two people to authorize an action; split knowledge fragments a secret, whereas dual control gates an action behind two approvals.
- M-of-N control needs any M of N holders so the process survives an absent holder
M-of-N control generalizes dual control: instead of requiring all holders, it requires any M of N trusted parties to agree, for example 3 of 5. This trades a little exclusivity for resilience, because the action still proceeds if one or two holders are unavailable. Reach for M-of-N over plain two-person control when you need the protected action to keep working despite a missing custodian.
Trap Picking plain two-person dual control when the requirement is that the action still proceed despite an unavailable custodian; strict dual control stalls if either holder is absent, which is exactly what M-of-N is built to survive.
- Split knowledge divides a secret so no one person holds the whole thing
Split knowledge divides a single secret (an encryption key, a master password, a safe combination) into parts so that no individual holds the complete value and reconstructing it requires the parties to combine their fragments. It protects a secret, which is what distinguishes it from dual control's protection of an action. The two are often combined: split a key into N parts and require M of them to reconstruct it.
Trap Confusing split knowledge with dual control. Split knowledge fragments a secret so no one holds it whole, while dual control requires two people to approve an action; the stem's noun (a key/combination vs. an approval) tells you which.
- Job rotation is a detective personnel control that surfaces a predecessor's hidden abuse
Job rotation moves staff between roles so a successor eventually performs the predecessor's duties and would notice an irregularity, and it reduces any one person's long-term lock on a sensitive position. NIST SP 800-53 AC-3(2) explicitly suggests rotating dual-authorization duties to reduce collusion, which is the authoritative basis for rotation as an anti-collusion control. It is administrative and detective: it assumes access was legitimate and creates conditions that expose ongoing misuse.
Trap Classifying job rotation as a preventive control; it does not block the abuse up front, since a successor inheriting the role is what later surfaces it, making it detective.
- Mandatory vacation forces coverage that uncovers a scheme needing daily presence
Mandatory vacation requires an employee to be out of their function for a continuous period (commonly one to two weeks) so a substitute must perform the work. A fraud that depends on the perpetrator's daily presence to stay concealed tends to unravel while they are away and someone else handles the duties. Like job rotation it is an administrative detective control, aimed at exposing abuse of access rather than restricting the access itself.
Trap Treating mandatory vacation as merely an employee-wellbeing or HR perk. On the exam it is a fraud-detection control whose security value is forcing a substitute to cover the role.
- Privileged accounts get extra controls because they can override the others
Privileged accounts (administrator, root, domain admin, service, and emergency break-glass accounts) can bypass or disable normal security controls, so they require management beyond ordinary users. The two operational goals are constraining when that privilege is active and watching every use of it. This is why privileged access management and privileged-session monitoring exist as a distinct discipline rather than being folded into routine account administration.
- PAM removes standing admin rights with just-in-time, time-bound, approved activation
Privileged access management (PAM) replaces always-on standing admin rights with access that is requested, time-bound (a defined start and end), approved, and often MFA-gated, so privilege exists only while a task is being performed. The control objective is to eliminate standing privilege: the window an attacker or insider can exploit. A reference implementation grants role activation just-in-time with approval, notifications, and downloadable audit history.
Trap Believing strong passwords and MFA on an always-on admin account remove standing privilege; they harden authentication but the rights stay permanently active, and only just-in-time, time-bound activation eliminates the standing window.
4 questions test this
- A security operations manager at a hosting company finds that a dozen systems administrators all share a single built-in root credential to…
- A security architect is designing access controls for a system that must enforce the principle that users should only access the minimum…
- A security administrator is implementing a privileged access management solution for a financial services organization. The administrator…
- An organization has identified that several database administrators retain elevated privileges continuously, even when performing routine…
- Naming an admin account fixes attribution, not standing privilege
Assigning a named human owner to an administrator or service account improves accountability because you know who acted, but on its own it does nothing about the account being permanently privileged. A named-but-always-on admin still carries standing privilege and remains a prime attacker target. Removing standing privilege requires PAM's just-in-time activation, not just a better name on the account.
Trap Choosing 'give each admin account a named owner' as the fix for standing privilege. Naming solves attribution only; the account is still always-on until just-in-time PAM activation is applied.
- Monitoring privileged use is the inseparable second half of managing it
Constraining privilege is only half the job; every privileged session and every break-glass activation must generate logs and alerts that are actually reviewed, because the whole reason to misuse such an account is to act unseen. Break-glass emergency accounts in particular should alert on every sign-in and get a post-use review to confirm the access was authorized. An unmonitored privileged or break-glass account is standing admin under another name.
Trap Assuming just-in-time PAM activation alone secures privileged accounts; constraining when privilege is active still leaves its use invisible unless every session and break-glass event is logged, alerted, and reviewed.
- An SLA is a measurable, enforceable commitment about how a service will perform
A service level agreement (SLA) documents measurable service commitments (uptime, response and resolution times, breach-notification windows, patch timelines) with remedies when targets are missed. Because you cannot directly configure a third party's systems, the SLA is how security and recovery obligations are enforced on services you do not control. For continuity, external dependencies must carry SLAs aligned to the dependent process's recovery time objective (RTO), so the vendor's promised response fits inside your recovery window.
Trap Accepting a vendor SLA whose response time merely exists, without checking it fits inside the dependent process's RTO; a promised response longer than your recovery window leaves the SLA unable to meet continuity needs.
- SLA faces the customer, OLA faces internal teams, UC faces the supplier
Keep three agreements straight by who each one faces: an SLA is the externally-visible promise to the customer about service performance, an operational level agreement (OLA) commits internal supporting teams to the targets that let the SLA be met, and an underpinning contract (UC) holds an external supplier to commitments backing the SLA. The distinguishing axis the exam tests is internal versus external: an OLA is internal team-to-team, a UC is your organization to a third party.
Trap Swapping OLA and UC. An OLA is an internal commitment between teams in your own organization, while an underpinning contract (UC) is the external agreement with a third-party supplier.
References
- NIST CSRC Glossary: Least Privilege Whitepaper
- NIST CSRC Glossary: Separation of Duty Whitepaper
- NIST CSRC Glossary: Dual Authorization Whitepaper
- Microsoft Entra Privileged Identity Management: Configure
- NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices Whitepaper
- NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems Whitepaper