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
Identity Management
Who are you, and what may you do?
Checking into a hotel: you give your name (identification), show your passport (authentication), get a key card that opens your room and the gym but not the kitchen (authorisation), and the card system logs every door you open (accountability).
Identity management does the same for systems.
| Step | Question | Examples |
|---|---|---|
| Identification | Who are you claiming to be? | User ID, account name, badge number |
| Authentication | Can you prove it? | Password, token, fingerprint |
| Authorisation | What are you allowed to do? | Roles, permissions, access control lists |
| Accountability | What did you do? | Audit logs tied to your unique ID |
Logging in successfully (authentication) doesn’t mean you should see everything (authorisation).
Unique user IDs are fundamental. Without them, nobody can tell who did what. Shared or generic accounts should be removed, or tightly controlled through a privileged access tool that records who used them and when.
The identity life cycle
- Joiners: access is requested, approved by the manager and the data owner, and granted by role, following least privilege.
- Movers: when someone changes job, access they no longer need is removed. Otherwise it piles up as access creep, often creating segregation of duties conflicts.
- Leavers: accounts are disabled promptly, triggered by HR, and later deleted according to policy. Leavers’ accounts that stay active are orphan accounts, a classic finding.
- Periodic reviews (recertification): data owners review who has access and confirm it’s still needed. Anything not confirmed is removed. Reviews by IT alone don’t confirm business need.
Non-human identities (service accounts, API keys, machine identities) need owners, minimal rights and credential rotation too.
Tools: directories, SSO and federation
- Directory services (such as Active Directory or LDAP) hold identities centrally.
- Identity governance tools automate provisioning, approval workflows and access reviews.
- Single sign-on (SSO) lets users log in once for many applications. It cuts password fatigue and makes removing leavers easier, but a stolen SSO credential opens everything, so MFA is essential.
- Federation lets identities be trusted across organisations, using standards such as SAML and OpenID Connect. OAuth 2.0 delegates authorisation: it lets an app act on your behalf without being given your password.
Testing user access
- Compare HR leaver lists with active accounts to find orphans.
- Sample new and changed accounts for approval evidence.
- Review periodic access reviews: were they done by owners, and was excess access actually removed?
- Find shared, generic and default accounts.
- Review privileged and service accounts.
- Check SSO and federation configuration, including MFA.
Example. An access review is “completed” every quarter, but the evidence shows IT administrators approved all accounts in bulk without involving business owners. In one system, 40% of users still have rights from previous roles. The review exists in form but not in substance.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Process of proving a claimed identity | Authentication |
| Determining what a user may do | Authorisation |
| Why unique user IDs matter | Accountability |
| Main risk of SSO | Single credential compromise gives wide access; use MFA |
| Best test for leaver controls | Match HR terminations to active accounts |
| Who should perform access recertification | Data / system owners |
In short
- Identification claims an identity, authentication proves it, authorisation decides what it can do, and accountability records what it did.
- Each user should have a unique ID so actions can be traced; shared IDs destroy accountability.
- The identity life cycle: joiner (provisioning), mover (change of role), leaver (deprovisioning), with periodic access reviews.
- Access is granted on approval by the data owner, based on least privilege and need-to-know.
- Single sign-on improves usability and reduces password sprawl, but makes the single credential a high-value target; protect it with MFA.
- Federation (SAML, OpenID Connect) lets identities be trusted across organisations.
- Periodic access recertification by data owners detects access creep and orphan accounts.
Exam traps
- Authentication is not authorisation. Logging in successfully doesn't mean you should see everything.
- Shared or generic accounts prevent accountability; replace with named accounts or controlled check-out.
- Leavers' accounts should be disabled promptly; orphan accounts are a common finding.
- SSO without MFA concentrates risk on one password.
- Access reviews by IT alone don't confirm business need; owners must review.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Who are you, and what may you do?
Checking into a hotel: you give your name (identification), show your passport (authentication), get a key card that opens your room and the gym but not the kitchen (authorisation), and the card logs every door you open (accountability).
Identity management does the same for systems.
The identity life cycle
SSO and federation