6.3 Rule-Based, Attribute-Based, and Privileged Access Management
Key Takeaways
- Rule-based access control evaluates if-then policy on request context such as time, source network, and protocol, and can deny a user who is already in the correct role.
- Attribute-based access control combines user, resource, environment, and action attributes. Stale HR, device, or classification attributes make the policy lie.
- PAM vaulting stores and rotates privileged secrets. Just-in-time access time-boxes admin roles. Session recording supports accountability. Break-glass is an alarmed emergency path, not a nightly login.
- Least privilege applies to administrative identities and to AI service accounts: unique IDs, vaulted secrets, named owners, and no standing Owner on production data.
- Lifecycle (2.3) decides when identities appear and die. Models (2.4) decide each request while they live. De-provisioning must unwind roles, rules, attributes, and vault accounts together.
Continuing 2.4: decisions that are not only labels, owners, or roles
MAC, DAC, and RBAC decide from labels, owners, or roles. Real infrastructure also decides from rules ("deny after 18:00") and attributes ("contractor + managed device + this API"). Privileged Access Management (PAM) is how you keep the people and machines who can bypass those models from holding standing power. Outline 2.4 lists rule-based and attribute-based control next to the classical models; PAM appears in the role-based examples because privileged roles are RBAC with extra machinery. This section is that machinery.
Rule-based access control
Rule-based access control evaluates an if-then policy against the request, often independently of who the user is. Classic operations examples:
- Firewall and router ACLs: permit TCP 443 from subnet A to subnet B; deny the rest.
- Time-of-day rules: contractors may VPN only 07:00–19:00 local.
- Location or path rules: interactive admin is allowed only from the jump-host subnet.
- Account lockout: five failed logons disables the identity for thirty minutes.
- Proxy categories: guest VLAN cannot reach social media or command-and-control sites.
Rule-based control is usually global or attached to a resource, not negotiated by the object owner. It complements RBAC: you can be in VPN-Contractors (role) and still be denied at 02:00 (rule). Exam stems that mention time, source IP, protocol, or "the firewall denied it even though the user is in the right group" are pointing at rule-based control.
Do not confuse rule-based with MAC. MAC is about labels and a lattice. Rule-based is about conditional policy. A proxy that blocks social media from the guest VLAN is rule-based, not Bell-LaPadula. Do not confuse it with DAC either: the file owner does not write the firewall rule.
Maintenance matters. A time rule that still says "COVID remote-access exception 2020" is a stale grant. Shadowed ACL lines (a broad permit above a specific deny) are rule-based failures that look like they work in the lab and fail in production. Rule reviews belong in the same recertification culture as group membership.
Attribute-based access control
Attribute-Based Access Control (ABAC) decides from attributes of the subject, the resource, the action, and the environment, combined in a policy (often Boolean). Roles can be one attribute among many; they are not the whole decision. ABAC is how you avoid role explosion. Instead of RN-4West-nights-managed-laptop-only, you keep RN and put unit, shift, and device into attributes.
The four attribute bags SSCPs should be able to name:
| Attribute class | What it describes | Operations examples |
|---|---|---|
| User (subject) | Who or what is asking | Department, clearance, contractor versus employee, training-complete flag, device posture of the bound endpoint, AI-agent owner, identity-assurance level |
| Resource (object) | What is requested | Data classification, application, record type (protected health information versus a public directory), vault path, cloud project |
| Environment | Context of the request | Time, geolocation, network zone, risk score, threat level, whether the session is already privileged |
| Action | What they want to do | Read, write, approve, delete, invoke, download, train a model |
Example policy: allow if user.role is Clinician and user.training.HIPAA is current and resource.patient.unit equals user.unit and action is read and environment.device is managed and environment.time is shift hours; else deny, unless a break-glass ticket is open.
ABAC costs: attributes must be accurate and fresh. If HR never updates department, the policy lies. If device posture is stale, a compromised laptop still matches managed. Attribute sources — HR, mobile-device management, the configuration-management database, the identity provider — become part of the trusted computing base. Recertification for ABAC includes recertifying the attribute pipeline, not only the human's role.
Adaptive and AI-assisted access (behavioral biometrics, impossible-travel scores) are environment or user attributes feeding ABAC. They do not replace unique identities or recertification. An AI that silently grants Owner because "the user looks busy" is not ABAC; it is unaccountable automation.
Putting the models next to each other
| Model | Decision basis | Strength | SSCP watch-out |
|---|---|---|---|
| MAC | Labels and clearance | Owner cannot leak by grant | Do not "fix" with NTFS ownership |
| DAC | Owner ACL | Flexible collaboration | Oversharing, inherited ACEs |
| RBAC | Role membership | Scales jobs | Role explosion, copy-user |
| Rule-based | If-then on request context | Time, IP, protocol gates | Stale exceptions, rule shadowing |
| ABAC | User, resource, environment, action attributes | Fine-grained without a role per case | Stale or missing attributes |
| PAM | Vaulted, time-boxed privileged roles | Least privilege for admins and bots | Standing admin, unlogged break-glass |
Privileged Access Management in operations
PAM is the operational control plane for identities that can change security state: domain and cloud administrators, root, database sa, firewall admins, secret-zero continuous-integration identities, and AI or service accounts that can disable users or read entire data stores. Help-desk MFA-reset is privileged relative to a standard user even when it is not Domain Admin.
Vaulting
Credential vaulting stores privileged passwords, keys, and tokens in a hardened repository. Check-out issues a secret, or injects it into a session, without showing it to the user. Rotation happens on check-in. The admin never keeps a standing password in a laptop password manager, and the service-account secret is not in a Git repository.
Vaulting without rotation is a locked copy of a still-static password. Unique secrets per target and breaking shared root are the point. A vault that everyone can export is a shared spreadsheet with an API.
Just-in-time access
Just-in-time (JIT) privilege is time-boxed role membership or credential issue. The engineer is a standard user until a ticket or an approval policy adds them to Firewall-Admins for ninety minutes; then IAM removes them. JIT implements least privilege across time, not only across objects.
JIT for AI service accounts means the training job gets read on the dataset for the job duration, not a standing Owner on the project. Short-lived cloud tokens are JIT even when no human clicks "checkout."
Session recording
Session recording captures privileged interactive sessions — keystrokes, video, command logs — on jump hosts or through the PAM proxy. It supports accountability and non-repudiation from Domain 1.2. Privileged users must not be local administrators of the recorder. Recordings are evidence: retain them, restrict playback, and treat tampering as an incident. Recording does not replace unique identities. A shared fwadmin session that is recorded still cannot tell you which engineer typed the command unless the PAM proxy bound the session to a named checkout.
Break-glass
Break-glass is the emergency path when PAM, the identity provider, or MFA is down: a sealed admin account, a physically stored hardware token, a dual-control safe. Using it must page the SOC or on-call automatically, be logged (even if the log is a camera on a safe plus a ticket opened after), be time-limited, and be followed by credential rotation. Recertify the control: if break-glass is used weekly, it is standing admin with extra paperwork.
Break-glass that is the daily login of the night-shift sysadmin is not break-glass. Neither is an undocumented local admin on every server "in case PAM is slow."
Least privilege for admin and AI service accounts
Standing Domain Admin for people who "might need it" is the opposite of PAM. So is an AI ticket-bot with directory-wide write because the first demo needed it.
Inventory non-human privileged identities the same way you inventory Domain Admins:
- Unique identity per function, not
svc-all. - Secret in the vault, rotated.
- Named owner; recertified on the same cycle as human admins.
- Network path restricted (the backup account cannot remote-desktop interactively).
- No interactive logon for pure service accounts.
- JIT or short-lived tokens for cloud APIs.
- Training data and inference APIs scoped so the agent cannot reach data tiers outside its task.
ISC2's Domain 2 AI integration is this dual job: secure the agent's access with least privilege, and you may use AI-assisted adaptive authentication as an attribute — not as a reason to skip unique IDs.
Scenario: PAM checkout for a firewall change
A network engineer needs to push an ACL. They request Firewall-Admins in the PAM portal with the change ticket. Policy checks: the engineer is on the network team, the ticket is approved, the time is inside the change window, the source device is the managed jump host (rule-based and ABAC sitting on top of RBAC). The vault injects the firewall admin credential into a recorded session. Ninety minutes later the role expires, the password rotates, and the recording is stored. If the engineer instead used a shared fwadmin password from a spreadsheet, you have DAC-quality control over a network-wide privilege and no idea who pushed the rule.
If the identity provider is down during an outage, the engineer uses the break-glass token from the safe. The door sensor and vault alarm notify the SOC. After the incident the break-glass secret is rotated. That is PAM as an operations system, not as a product logo.
How 2.3 and 2.4 fit together
Lifecycle (2.3) is when identities appear, change, and die. Models (2.4) are how each request is decided while they live. A joiner is proofed and provisioned into an RBAC role; a rule denies them after hours; ABAC checks device posture; MAC would have blocked an owner grant in a lab; PAM wraps the admin role they should not hold standing. When they leave, de-provisioning must unwind every model: role membership, rules that whitelist their IP, ABAC attributes, vault accounts, and recorded-session rights. The terminated contractor still in the VPN group failed 2.3 and also failed the rule-based and PAM layers that should have expired the certificate.
CAT items mix these on purpose. Read the stem for the decision engine (label, owner, role, rule, attribute, vault) and for the lifecycle stage (proof, provision, recertify, deprovision). The operational answer is still least privilege, unique IDs, evidence, and no standing admin for people or for bots.
Which set of inputs does attribute-based access control use to allow or deny a request?
A firewall engineer needs privileged access to push an approved ACL change. Which PAM pattern implements least privilege for that work?
A contractor is a member of VPN-Contractors but the concentrator still rejects the tunnel at 02:00 from an unmanaged home network. Which access-control model is primarily enforcing that denial?