Topics in this domain
- Security Governance and Roles
- Data Classification and Ownership
- Security Policies
- Privacy Principles and GDPR
- Identity Management
- Authentication Factors
- Biometrics
- Access Models: DAC, MAC, RBAC
- Logical and Privileged Access
- Cryptography Basics
- Symmetric Encryption
- Asymmetric Encryption
- Hashing and Integrity
- Digital Signatures
- PKI and Certificates
- Firewalls
- IDS/IPS
- VPN, SSL/TLS, IPsec
- Wireless Security
- Endpoint and Mobile (BYOD)
- Cloud and Virtualization Security
- Physical Access Controls
- Environmental Controls: Fire, Power, HVAC
- Social Engineering
- Malware
- Network Attacks: DoS, Spoofing, Sniffing
- Application Attacks: SQLi, XSS
- Vulnerability Management and Pen Testing
- Incident Response
- Digital Forensics and Chain of Custody
- Security Awareness Training
- Logging, SIEM, and Auditing Security
Access Models: DAC, MAC, RBAC
Who decides who gets in?
Think about the doors in your life. You decide who gets a copy of your house key. A military base admits you only if your clearance matches the area’s classification. A hospital lets every nurse see patient charts. A shopping centre closes to everyone at 10pm. A smart office lets managers in, on company laptops, during office hours.
Every access model answers one question: who or what decides? Find the decider in the exam scenario and you’ve found the model.
| Model | How access is decided | Strengths | Weaknesses |
|---|---|---|---|
| Discretionary (DAC) | The resource’s owner grants access at their discretion, usually through access control lists | Flexible, simple | Inconsistent; owners over-share; malware running as the user inherits their rights |
| Mandatory (MAC) | The system compares the user’s clearance with the object’s label | Strong, central; nobody can override | Rigid, complex to run |
| Role-based (RBAC) | Permissions go to roles; users get roles based on their job | Consistent; easier to administer; supports SoD | Role design effort; role explosion; toxic combinations inside roles |
| Rule-based | Global rules apply to everyone, such as “no access outside business hours” | Simple, consistent | Coarse |
| Attribute-based (ABAC) | Policies weigh attributes of the user, resource, action and environment | Fine-grained, dynamic | Complex policies; harder to audit |
A file whose creator sets its permissions is DAC. MAC is called non-discretionary: neither users nor data owners can change the rules. It’s associated with formal models such as Bell-LaPadula (confidentiality: no read up, no write down) and Biba (integrity: no read down, no write up).
Principles for every model
- Least privilege: users and processes get only the rights they need for their tasks.
- Need-to-know: access to information is limited to what the job requires. (Least privilege covers all rights; need-to-know is about information.)
- Default deny: anything not explicitly allowed is blocked.
- Segregation of duties: incompatible permissions aren’t given to one person.
RBAC in practice
RBAC is the most common model in organisations. Good practice:
- build roles from job functions, with business owners approving what each role contains
- check each role for internal SoD conflicts before using it
- assign users to roles, not directly to permissions
- review roles and role membership regularly
- avoid role explosion: hundreds of narrow, overlapping roles become unmanageable
RBAC doesn’t guarantee segregation of duties by itself. A badly designed role can contain a toxic combination.
Example. An ERP role called “Accounts Payable Clerk” includes both “create vendor” and “release payment”. Every user with that role has a segregation of duties conflict, even though each was given only one role. The fix is in the role design, not the user assignments.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Model where the owner decides access | DAC |
| Model enforced by labels, users can’t change | MAC |
| Model assigning permissions based on job function | RBAC |
| Time-of-day restrictions applied to all users | Rule-based |
| Model using user, resource and context attributes | ABAC |
| Principle of granting only rights needed | Least privilege |
In short
- Discretionary access control (DAC): the owner of a resource decides who can access it.
- Mandatory access control (MAC): the system enforces access based on security labels and clearances; users can't change it.
- Role-based access control (RBAC): permissions are assigned to roles, and users get access through their roles.
- Rule-based access control applies system-wide rules, such as time-of-day restrictions or firewall rules.
- Attribute-based access control (ABAC) evaluates attributes of the user, resource and context.
- Least privilege and need-to-know apply whatever the model.
- RBAC simplifies administration and supports segregation of duties when roles are designed carefully.
Exam traps
- MAC is non-discretionary: even the data owner can't override the labels.
- File permissions set by the file's creator = DAC.
- Roles can contain toxic combinations; RBAC doesn't guarantee segregation of duties by itself.
- Role explosion (too many narrow roles) undermines RBAC's benefits.
- Need-to-know limits information access; least privilege limits all rights.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Who decides who gets in?
Every access model answers one question: who or what decides? The owner of the thing? A label stamped on it? Your job title? A rule that applies to everyone? A mix of facts about you, the data and the situation?
Find the decider in the exam scenario and you've found the model.
Principles for every model