CySA+ · Chapter 26 · Identity & Access Management

IAM Fundamentals — Subjects, Tasks & Account Risk

Identity and Access Management (IAM) is the security process that provides identification, authentication, and authorization mechanisms for users, computers, and other entities to interact with organisational assets (networks, operating systems, applications). When you log in to a computer, you're participating in the IAM process: presenting credentials (identification), being verified (authentication), and being granted access (authorisation).

Five types of unique subjects

Personnel

People — employees, contractors, visitors. Most common IAM subject. Also the biggest risk area: people write passwords down, share credentials, and fall for phishing. User accounts are the primary attack vector for account compromise.

Endpoints

Desktops, laptops, tablets, mobile phones. The device itself has credentials for accessing the network — separate from the user's credentials. Each endpoint is its own unique IAM subject that must be managed and audited.

Servers

Back-end infrastructure supporting machine-to-machine communication. Server trust relationships and certificates create their own IAM identity — managed separately from user accounts. Mission-critical systems require tighter IAM controls.

Software

Applications that interact with users and systems. Software often authenticates using digital certificates rather than passwords. API keys, service accounts, and application certificates all fall under software IAM.

Roles

Not a person or device — a function. Roles define what resources an asset can access based on its function. Can be assigned to any other subject type. In Windows: groups implement roles by giving a set of permissions to everyone with that job function.

Account risk spectrum

👤 User Accounts

Standard accounts — basic user permissions. Least risky, but still a risk. Phishing and credential theft most commonly target standard users. Require MFA and strong passwords.

🔑 Privileged Accounts

Administrators, root users, super users. Can install/uninstall software, change passwords, create accounts. Higher blast radius on compromise. Require additional auditing and MFA.

⚠ Shared Accounts

Multiple people using one account. Loses audit trail — can't determine which individual took an action. Strongly discouraged. Use role-based individual accounts instead.

Password Policies — NIST SP 800-63B Changes

NIST Special Publication 800-63B (Digital Identity Guidelines) has deprecated several traditional password policy elements. If you learned from an older Security+ curriculum, some of these will contradict what you previously memorised. These changes will appear on the CySA+ exam.

NIST SP 800-63B — What Changed (and Why)

Enforce complexity rules (uppercase + symbols + numbers)

✗ Complexity rules should NOT be enforced

Users write down complex passwords they can't remember → worse security, not better. A long simple passphrase is more secure than a short complex one.

Mandatory password expiry every 60–90 days

✗ Aging/expiry policies should NOT be enforced

Forced rotation leads to password reuse or predictable patterns (Password1 → Password2). Rotate only when compromise is suspected.

Password hints to help users remember

✗ Password hints should NOT be used

Hints help attackers guess passwords too. Use challenge questions or 2-step verification for resets instead.

Memorised passwords across multiple accounts

✓ Use a password manager for unique per-site passwords

Password reuse across sites means one breached site compromises all accounts. A password manager generates unique 8–64 char random passwords per site — one master password controls access.

Current NIST guidance for passwords

Password length

8 to 64 ASCII characters. Length is the primary security driver — not complexity. A 20-character passphrase of random words is more secure than P@ssw0rd! of 9 characters.

Password manager

Should be implemented and enforced in policy. Generates pseudo-random unique passwords per site. Removes the cognitive burden of remembering many passwords, eliminating reuse. Examples: LastPass, 1Password, Bitwarden.

Password reset — challenge questions

Use personal information only the user should know (first school, first car, first pet). Selected at account creation. Provides verification without a hint that helps attackers.

Password reset — 2-step verification

Send a one-time code to a secondary channel (registered email or phone number). User proves identity by receiving the code on their registered device. More secure than challenge questions alone.

Exam critical point: The old Security+ 501 guidance said: enforce complexity, require 60-day rotation. NIST 800-63B says: don't enforce complexity, don't enforce rotation. The CySA+ exam follows the current NIST guidance, not the old rules. When a question asks about modern password policy best practices, choose the NIST 800-63B answers.

SSO & MFA — Single Sign-On and Five Factors

Single Sign-On (SSO) enables a user to authenticate once and receive authorisation for multiple services. Windows domain login using Kerberos is SSO in action. One strong credential opens everything.

SSO Advantage

One strong, memorable password covers access to all systems. Reduces password fatigue and the temptation to reuse weak passwords across services. One credential = one attack surface to protect well.

SSO Risk

One compromised credential = all systems compromised. An attacker who steals the SSO password instantly has access to everything the user is authorised for. This is why SSO should always be combined with MFA.

MFA — Five authentication factor categories

🧠

Something you KNOW

Password, PIN, security question answer

🔑

Something you HAVE

Token/fob, smart card, phone receiving OTP

👆

Something you ARE

Fingerprint, retinal scan, facial recognition, voice

✍

Something you DO

Signature style, typing rhythm, gesture pattern

📍

Somewhere you ARE

GPS location, IP address geolocation (easily spoofed)

MFA requires at least two different factor categories. Password + PIN = NOT MFA (both are "something you know"). Password + fingerprint = MFA (know + are). Password + phone OTP = MFA (know + have). 2FA uses exactly two factors. Location-based authentication alone is weak (VPNs spoof IP location) — use GPS coordinates and combine with other factors.

MFA implementation methods

Passwordless Authentication & Biometric Impersonation

Passwordless authentication removes the knowledge factor (password) entirely. Instead, it relies on ownership factors (what you have) or inherence factors (what you are). Typically backed by public key cryptography with the private key stored on the user's device.

Ownership factors

Smartphone (OTP app or push notification), one-time PIN token/fob, smart card, hardware key (e.g. YubiKey). Something you physically possess.

Inherence factors

Fingerprint, retinal scan, facial recognition, voice recognition. Something about your physical body — always with you and hard to steal.

Benefits

Greater security (no password to steal/guess). Better UX (no memorisation, no forced resets). Reduced IT cost (no password management infrastructure). Better visibility (credentials tied to specific device). Better scalability (single token works across many systems).

Downsides

Higher implementation cost. Additional training needed. Single point of failure if the factor is compromised (lost token, spoofed biometric). Requires strong anti-impersonation design.

Biometric impersonation: An attacker pretending to be another user to bypass a biometric-based authentication system. Hollywood version: lift fingerprints from a glass, recreate the fingerprint ridges, bypass the scanner. Real mitigation: ensure the biometric system has a very low false positive rate. Always combine biometrics with a second factor (MFA) — a single-factor biometric system is a single point of failure.

Certificate Management — sigcheck, OpenSSL, certutil

Certificate management is the practice of issuing, updating, and revoking digital certificates. Certificates provide the primary means of assuring the identity of machines and application code — they underpin HTTPS, email signing, code signing, and 802.1X network authentication.

sigcheck

Sysinternals utility

Verifies root certificates in the local Windows store against Microsoft's master trust list. Confirms that OS-level certificates are signed by Microsoft and haven't been tampered with. First line of certificate health check on Windows.

OpenSSL

Cross-platform library

Library of functions supporting SSL/TLS protocols. Commands for: creating/viewing digital certificates, generating private keys, testing SSL/TLS handshakes, inspecting certificate chains. Available on Linux, Mac, Windows. The underlying engine for most certificate operations.

certutil

Windows built-in

Windows utility using OpenSSL components. Displays CA configuration, configures certificate services, backs up/restores CA components, verifies certificates, key pairs, and certificate chains. No additional install needed on Windows Server/workstation.

Certificate management tasks

Root certificates

Install, update, and validate trusted root certificates. A compromised root invalidates everything below it in the chain. Monitor the root CA closely — it's the most critical certificate in your PKI.

Subject certificates

Deploy, update, and revoke user and machine certificates. User certs: email signing, authentication. Machine certs: RADIUS/802.1X, VPN. Revocation via CRL or OCSP is critical — an unrevoked stolen cert is still valid.

Prevent self-signed certs

Self-signed certificates are not signed by a trusted CA — they bypass the trust chain. Malware signs itself to appear legitimate. MITM attackers create self-signed SSL certs to intercept traffic. Policy should prohibit self-signed certs on production systems.

SSH key management

SSH uses cryptographic key pairs for authentication. These keys must be managed like certificates — generated securely, rotated periodically, and revoked when an employee leaves. Unmanaged SSH keys are a significant insider threat risk.

Federation — Identity Provider, Service Provider & Provisioning

A federation provides shared login capability across multiple systems and enterprises. It allows a company to trust accounts created and managed by a different organisation. When you "Sign in with Google" on a third-party website, you're using federation.

Identity Provider (IdP)

The organisation that creates and manages the identity — performs the actual authentication. Examples: Google, Facebook, LinkedIn, Microsoft Azure AD. The IdP vouches for the user to the service provider.

Service Provider (SP) / Relying Party (RP)

The organisation that consumes the identity — accepts the IdP's authentication assertion. Example: your website accepting Google logins. The SP never sees the user's password — it trusts the IdP's authentication result.

Federation vs. SSO — the key difference

Single Sign-On (SSO)

Authentication is done internally. The service provider verifies the credentials itself, then passes a cryptographic hash token between its own systems. You still have one credential, but the SP controls the verification process.

Federation

Authentication is outsourced to the IdP. The SP never verifies the user — it trusts the IdP's assertion. Google says "John Smith is authenticated" and the SP accepts that. The SP has no visibility into how the IdP authenticated the user.

Account provisioning in federation

Manual provisioning

An administrator creates the account on the service provider. More time-consuming, error-prone, and labour-intensive. Used as a fallback when automated provisioning fails or when special configurations are needed.

Automatic provisioning

User registers on the SP without human intervention. An account is automatically created based on the IdP's identity assertion. Faster and more scalable. Standard for modern web services. Changes to the IdP account must propagate back to the SP quickly.

Federation risk: By accepting a federation relationship, your organisation takes on risk from the partner's security posture. If the IdP is compromised, attackers can gain access to your systems using valid assertions. Extending trust boundaries beyond your organisation is a significant security decision — choose federation partners carefully and review the security posture of any IdP you trust.

Access Control Models — DAC, MAC, RBAC, ABAC

Two key principles underpin all access control: Least Privilege (do everything with the minimum rights needed) and Separation of Duties (no single person can perform a complete sensitive transaction alone — requires dual authorisation). These principles are implemented through four access control models.

DAC

Discretionary Access Control

Owner-controlled ACLs

Resources are protected by ACLs managed by the resource owner. The owner decides who can access their resource and what they can do. Most flexible and most common in commercial operating systems.

Example: Windows NTFS — right-click → Properties → Security → set permissions

MAC

Mandatory Access Control

System-enforced labels

Resources are labelled with a classification level. Users are assigned a clearance level. The system automatically enforces access — if your clearance ≥ label, you can access it. No owner discretion. Very rigid, very secure.

Example: Military classifications (Unclassified/Confidential/Secret/Top Secret). Implemented in SELinux (developed by NSA).

RBAC

Role-Based Access Control

Job function groups

Resources are protected by ACLs managed by administrators. Permissions are assigned to roles (groups), and users are placed into roles. Easy to manage — change someone's role to update all their permissions at once.

Example: Windows AD groups — Accounting group gets accounting share access; IT group gets server management access.

ABAC

Attribute-Based Access Control

Per-subject attributes

Access is granted based on a set of attributes evaluated for each subject — not just their group or label. Most complex and most flexible. Enables fine-grained control down to the individual user. Also supports separation of duties through attribute combinations.

Example: Access allowed only if: (department=Finance) AND (location=HQ) AND (clearance≥Confidential) AND (time=business-hours).

Access control model quick-select: Windows default = DAC. Military/classified environments = MAC (SELinux). "Users in groups with permissions" = RBAC. "Complex attribute-based rules per user" = ABAC. Most complex to implement: ABAC > MAC > RBAC > DAC. Most flexibility: ABAC. Most rigid/secure: MAC.

IAM Auditing — Logs, Reviews & Re-Certification

IAM auditing detects compromised legitimate accounts, rogue account use, and insider threats. The primary method is log monitoring and review. Audit logs record all file access and authentication events — but they're only useful if someone actually reads them.

What to look for in log reviews

Multiple consecutive authentication failures — likely brute force or credential stuffing. A single failure = forgetting a password. A sequence of A, AA, AB, AC attempts = brute force attack. Disable the account and investigate.

Unscheduled configuration changes — a system modified outside change management windows may be infected with malware or compromised by an insider.

Sequencing errors or gaps in logs — missing log entries could indicate tampering. Attackers cover their tracks by deleting or modifying log files. Hash logs to detect integrity violations.

Login at unusual hours — an employee whose account logs in at 3 AM from an unusual location when they're known to be on holiday is an IOC. Use login time restrictions (logon hours) to limit risk.

Access to resources outside normal scope — an accounting employee accessing HR file shares is suspicious. Compare access logs to expected role-based access patterns.

Logging challenges

Volume

More events logged = more analysis needed. Logging everything can produce gigabytes per hour. Be selective — log only events that provide actionable security value. Microsoft's audit policy recommendations are a good starting point.

Overwriting

Logs have maximum file sizes. Once full, old logs are overwritten. Since many intrusions take months to detect, logs that only keep 7 days of history will never capture the full attack chain. Offload logs to a SIEM with longer retention.

Log security

Encrypt logs at rest (confidentiality). Hash logs (integrity — so you can detect tampering). Attackers modify logs to cover tracks — immutable log storage (write-once, offsite SIEM) prevents this.

Manual review and re-certification

Manual review

Periodically review user accounts to verify permissions still match current job roles. People accumulate permissions as they change roles — old permissions are rarely revoked. Use RBAC groups to make this easier: removing from a group removes all associated permissions at once.

Re-certification

A formal scheduled review of all accounts, permissions, configurations, and clearances. Frequency varies by risk appetite — monthly/quarterly/annually. Confirms: does this account still need to exist? Does this person still need these permissions? Is this clearance still appropriate?

Conduct & Use Policies — Code of Conduct, AUP, PUA

Security policies direct employee behaviour. Three specific policies govern how employees interact with systems, data, and their own access privileges. Each targets a different audience.

Code of Conduct

All employees in specific roles

Defines the rules, ethics, and expectations for employees in a given job role. Specifies what they are allowed to do with their access — even if they technically have the ability to do more. Example: a sysadmin can technically read anyone's emails, but the code of conduct prohibits this. Governs ethical behaviour beyond what system controls enforce.

Privileged User Agreement (PUA)

Administrators and privileged users

A formal contract for employees with elevated access. Documents specific prohibited uses of their elevated privileges. Creates legal accountability for misuse. Required because admin accounts have the technical ability to cause enormous harm — the PUA establishes the consequences if privileges are abused.

Acceptable Use Policy (AUP)

All users of company systems

Governs employee use of company equipment and internet services. Specifies what is and isn't permitted: prohibited sites (gambling, social media, adult content), permitted sites (company-specific need), and approved uses of equipment. Not one-size-fits-all — a social media company's AUP differs from a hospital's. Exam: if a question asks about what employees can/can't do with company equipment → AUP.

Exam shortcut for policies: "What employees can/can't do with company internet and equipment" = AUP (Acceptable Use Policy). "Ethics and expected conduct for a specific role" = Code of Conduct. "Contract for admins about their elevated privileges" = Privileged User Agreement. All three work together — the AUP applies to everyone, the code of conduct applies to roles, and the PUA applies specifically to admins.

Exam

Quick Reference Cheat Sheet

IAM fundamentals

IAM = identification + authentication + authorisation. 5 subject types: personnel (highest risk), endpoints, servers, software, roles. 3 account risk levels: user (basic), privileged (admin/root — more risk), shared (no audit trail — avoid). IAM tasks: create/deprovision, manage, audit, evaluate threats, maintain compliance.

NIST 800-63B password policy

❌ Don't enforce complexity rules (people write down complex passwords). ❌ Don't enforce aging/expiry (leads to predictable patterns). ❌ Don't use password hints (helps attackers too). ✓ Use password managers. ✓ 8–64 ASCII characters. ✓ Reset via challenge questions or 2-step verification. Exam: these replace the old Security+ 501 rules.

SSO vs. MFA

SSO = authenticate once → access all (Kerberos on Windows domain). Advantage: one strong password. Risk: one compromised credential = all systems. MFA = at least 2 different factor categories. 5 factors: know (password), have (token), are (biometric), do (signature), where (location). 2FA = exactly 2 factors. Combine SSO + MFA for strong security.

Passwordless & biometrics

Passwordless = ownership (phone/token) or inherence (biometric) factors, no password. Benefits: more secure, better UX, less IT cost. Risk: single point of failure, biometric impersonation. Touch ID: 1-in-50,000 false positive. Face ID: 1-in-1,000,000. Always combine with second factor for best security.

Access control models

DAC = owner-controlled ACLs (Windows default). MAC = system-enforced labels + clearances (military, SELinux). RBAC = role/group-based permissions (most common enterprise). ABAC = per-subject attribute evaluation (most flexible, most complex). Complexity order: DAC < RBAC < MAC < ABAC. Windows = DAC. Military = MAC. Enterprise groups = RBAC.

Certificate management tools

sigcheck (Sysinternals) = verify Windows root certificates against Microsoft trust list. OpenSSL = cross-platform: create/view certs, generate keys, test SSL/TLS. certutil (Windows built-in) = display CA info, backup/restore, verify certs. Self-signed certs = dangerous (malware signs itself, MITM attackers use them) — block in policy.

Federation

IdP (Identity Provider) = authenticates the user (Google, Facebook). SP/RP (Service Provider/Relying Party) = consumes the identity, trusts IdP's assertion. SSO = SP does own verification + token. Federation = IdP does verification, SP trusts result. Provisioning: manual (admin creates account) vs. automatic (self-registration). Risk: IdP compromise = SP compromise.

IAM auditing

Audit logs = file access + authentication events. Look for: consecutive auth failures (brute force), unscheduled config changes, log gaps (tampering), unusual login hours, out-of-scope resource access. Log risks: volume (don't log everything), overwriting (offload to SIEM), integrity (hash logs). Manual review: verify permissions match current role. Re-certification: formal scheduled review (monthly/quarterly/annually).

Conduct and use policies

Code of Conduct = ethics for a specific role (sysadmin doesn't read others' emails even though technically able). AUP = Acceptable Use Policy — what all employees can/can't do with company equipment and internet. PUA = Privileged User Agreement — formal contract for admins about elevated privilege use and consequences. Exam: AUP = company internet/equipment rules.