hardMultiple ChoiceObjective-mapped
Combining RBAC with ABAC: Enforcing Branch-Level Access
A large financial institution has deployed a new web application for customer account management. The application uses role-based access control (RBAC) with roles such as Customer, Teller, Manager, and Admin. Recently, an audit revealed that a Teller was able to view and modify account details belonging to customers outside their assigned branch. The application authenticates users via the corporate Active Directory and uses AD groups for role mapping. The Teller's AD group membership was verified to be correct. The security team suspects a flaw in the authorization logic. Which of the following is the MOST likely root cause?
Quick Answer
The root cause here is that the application never checks the teller's branch attribute after Active Directory has already confirmed the user's role, and that distinction matters because RBAC and attribute-based checks solve two different problems. RBAC answers what a role can do, and since the audit confirmed the Teller's AD group membership was correct, the role mapping itself is working exactly as designed. The gap is that the application needs a second, finer-grained check: does this specific teller belong to the same branch as this specific customer's account, which is an attribute comparison, not a role comparison. Because the app never performs that post-authentication validation against an attribute like a branch or office field, every Teller effectively has role-appropriate permissions to every customer record system-wide, regardless of branch. This is a common real-world authorization flaw: a system can have perfectly correct group membership and still leak data horizontally across tellers, departments, or tenants because nobody enforced the attribute-level boundary within the role. When a scenario confirms that group or role assignment is correct but describes access leaking across some other dimension, such as branch, department, tenant, or region, that's a strong signal the missing control is an attribute check layered on top of RBAC, not a role or group misconfiguration.
⚠ Common exam trap
Watch out — candidates often confuse the symptom (horizontal privilege escalation) with the root cause (missing attribute validation), or they incorrectly assume that correct AD group membership guarantees proper authorization without considering contextual attributes like branch.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The application fails to validate the user's branch attribute after authentication.
The Teller's AD group membership was verified correct, so the role mapping (RBAC) is functioning. However, the Teller could access accounts outside their assigned branch, indicating the application lacks a post-authentication check of the user's branch attribute. This is a classic failure of attribute-based access control (ABAC) within an RBAC framework, where the application must validate the user's branch (e.g., from an AD attribute like 'physicalDeliveryOfficeName' or a custom attribute) against the account's branch before allowing read/write operations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The application's role-to-permission mapping is based on group SID rather than group name.
Why it's wrong here
While group SID vs. name could cause mapping errors, it would affect all users in that group, not specifically branch-level access. This is less likely than missing branch validation.
- ✗
The application does not perform proper session management.
Why it's wrong here
Session management issues could allow session hijacking, but the audit found the Teller was using their own session; the problem is authorization, not session integrity.
- ✓
The application fails to validate the user's branch attribute after authentication.
Why this is correct
The application likely uses the Teller role correctly but does not check the user's branch attribute to restrict access to only customers from the same branch, allowing cross-branch access.
- ✗
The application uses a horizontal privilege escalation vulnerability.
Why it's wrong here
Horizontal privilege escalation would allow a Teller to access accounts of another Teller, but the issue is across branches, which may not be horizontal if the role is the same; still, the primary gap is branch-based restrictions.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
This SSCP question is part of Courseiva's 920-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on SSCP
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are a security analyst at a financial institution. The company uses a role-based access control (RBAC) system for its internal banking application. Recently, the compliance team discovered that a teller, who should only have access to customer account information for their branch, was able to view account details for customers in other branches. The RBAC system assigns roles based on job titles. You review the configuration and find that the 'Teller' role has a permission that allows viewing all customer accounts, regardless of branch. The company wants to enforce branch-level restrictions. Which of the following is the best approach to address this issue?
medium- ✓ A.Implement attribute-based access control (ABAC) to incorporate branch location as an attribute.
- B.Use mandatory access control (MAC) with labels for each customer account.
- C.Create separate roles for each branch, such as 'Teller_Branch1', 'Teller_Branch2', etc.
- D.Modify the 'Teller' role to remove the permission to view all accounts.
Why A: ABAC extends RBAC by evaluating attributes (e.g., branch location) at access time, enabling fine-grained per-branch restrictions without role explosion. Option B is incorrect: MAC with labels would require re-labeling all accounts and users, which is complex and less flexible than ABAC for this dynamic requirement. Option C is incorrect because creating separate roles per branch leads to role explosion (many roles to manage) and does not scale well. Option D is insufficient because simply removing the permission to view all accounts would prevent tellers from seeing any branch data; they need branch-specific access, not a global removal.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SSCP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SSCP exam.