About this note
This is the expanded reference version of my original CISSP exam notes. The bullet-point original is preserved in Domain 5 - Identity and Asset Management (Original-Stichpunkte) for comparison. Written for readers with several years of hands-on security and networking experience. The heading names for DAC/MAC/RBAC are kept stable because Domain 1 - Security and Risk Management links to them by anchor.
IAAA
Domain 5 takes the IAAA chain introduced in Domain 1 and turns it into implementation detail: the factor types, the protocols, the failure modes. The chain itself, briefly: identification claims, authentication proves, authorization permits, accountability attributes.
Identification
The asserted identity — name, username, ID. Nothing is proven yet; identification is the database key everything downstream hangs on. The requirements that matter operationally: identities must be unique (no shared accounts — they destroy accountability) and their issuance must be controlled (identity proofing at onboarding is where weak registration undermines every later control).
Authentication
The factor taxonomy, extended beyond the classic three:
- Type 1 — something you know: password, PIN, passphrase.
- Type 2 — something you have: token, smart card, phone.
- Type 3 — something you are: biometrics.
- Type 4 — somewhere you are: location as a factor — source network, geofence, GPS.
- Type 5 — something you do: behavior — typing cadence, signature dynamics. (Types 4 and 5 are usually treated as contextual signals augmenting the classic three rather than standalone factors.)
MFA combines two or more different types. The “different” is the whole point: password + PIN is two secrets from the same drawer and falls to the same phishing email. Password + TOTP, or better, password + FIDO2 key, forces the attacker to compromise two unrelated channels.
Type 1 Authentication — Knowledge
The attacks and their controls, as matched pairs:
- Brute force — countered by key stretching (bcrypt/PBKDF2/Argon2, as covered in Domain 3): a deliberately slow hash turns billions of guesses per second into thousands.
- Dictionary attacks — countered by login attempt limits and by rejecting dictionary words at password creation.
- Rainbow tables — countered by salting (which makes precomputation worthless) plus attempt limits.
- Keyloggers — no password policy helps when the input device is compromised; this is the attack class that motivates type-2 factors.
Clipping levels are the operational compromise between security and helpdesk load: tolerate a small number of failed attempts (3–4) before locking the account for a period. The name comes from “clipping” the noise of ordinary typos off the alert stream — you investigate patterns above the threshold, not every failed login.
The classic Microsoft AD password policy defaults the exam expects: password history 24, maximum age 90 days, minimum age 2 days (the anti-cycling control that stops users from burning through 24 changes in five minutes to get back to their favorite), minimum length 8 characters, complexity enabled, and storage using irreversible encryption — i.e. hashed, never reversibly encrypted. Worth knowing alongside: current NIST guidance (SP 800-63B) has moved away from forced periodic rotation and composition rules toward length, breach-list screening, and MFA — expect the exam to test the classic values, but don’t design new systems around them.
Type 2 Authentication — Possession
- Single-use passwords — one-time credentials, historically even paper-based (the German banking TAN list being the canonical example).
- Tokens and smart cards — the cryptographic implementations: HOTP (counter-based one-time codes; RFC 4226) and TOTP (time-based, the familiar 30-second authenticator codes; RFC 6238). Smart cards come as contact and contactless variants and bind a private key to tamper-resistant hardware.
- Magnetic stripe cards — possession in name only: the stripe is static data, trivially cloneable with commodity hardware. Legacy.
The modern footnote: OTP codes are possession factors that a phishing proxy can relay in real time; FIDO2/WebAuthn hardware keys resist exactly that because the signature is bound to the origin. Where the exam says “token”, production says “phishing-resistant token if you can.”
Type 3 Authentication — Biometrics
Two families: physiological characteristics (fingerprint, facial geometry, iris) and behavioral characteristics (keystroke dynamics, signature dynamics — how you type or sign, not what).
The error vocabulary is the exam’s favorite:
- FRR — False Rejection Rate (Type 1 error): a valid subject is denied. Annoying; a usability cost.
- FAR — False Acceptance Rate (Type 2 error): an invalid subject is admitted. Dangerous; a security failure.
- CER — Crossover Error Rate: the point where FRR and FAR are equal — the standard single-number metric for comparing biometric systems; lower CER = better system. Tuning moves you along the curve: tighten matching and FRR rises; loosen it and FAR rises.
Memory hook: Type 1 / FRR — the one legitimate user locked out; Type 2 / FAR — the second, wrong person let in. Type 2 errors are the ones that hurt.
The structural issues with biometrics: they are not secret (fingerprints are left on every glass, faces are photographed at will), not revocable (a leaked template is leaked forever — you cannot rotate your iris), and behavioral traits can be replayed (recorded typing patterns). Which is why biometrics work best as a convenience factor unlocking a possession factor — the smartphone model: the fingerprint releases a hardware-bound key, locally, and the template never leaves the device.
Authorization
The four access control models. The exam’s shorthand pairing of model to primary CIA goal is worth stating up front: DAC → flexibility/availability, MAC → confidentiality, RBAC → integrity.
Discretionary Access Control (DAC)
Access at the data owner’s discretion — the owner of an object decides who gets what, making it identity-based access control. Flexible, universally implemented (Unix permissions, NTFS ACLs), and appropriate where strict confidentiality guarantees are not the driver. Its systemic weakness follows from its definition: protection quality depends on every individual owner’s judgment, forever — the origin of permission sprawl, and the reason DAC environments need the access reviews covered below.
Mandatory Access Control (MAC)
Used where confidentiality is paramount: every subject and object carries a label, access decisions compare clearance to classification (optionally refined by compartments), and enforcement happens at the operating system level — the owner cannot override policy even for their own files. This is Domain 3’s Bell-LaPadula machinery deployed: military and intelligence systems, and in civilian life the mandatory-enforcement corners of SELinux and AppArmor.
Role-Based Access Control (RBAC)
Permissions attach to roles, subjects get roles, never direct grants. The exam associates RBAC with integrity because it operationalizes least privilege and separation of duties structurally: the accounts-payable role simply does not contain the vendor-creation permission (the Clark-Wilson idea from Domain 3, implemented). It’s also what real enterprises actually run — AD groups, IAM roles — because joiner/mover/leaver becomes role assignment instead of permission archaeology. Its failure mode: role explosion, when exceptions breed single-user roles until RBAC quietly degenerates back into DAC with extra steps.
Attribute Based Access Control (ABAC)
The generalization: decisions are policy evaluations over attributes of everything involved —
- subject attributes (department, title, clearance),
- action attributes (view, edit, delete),
- object attributes (classification, project, description),
- contextual attributes (time, location, environmental elements).
A policy reads like a sentence: engineers may edit design documents of their own project during business hours from managed devices. ABAC expresses what RBAC cannot without exploding roles, at the price of policies that are harder to audit (“who can access X?” becomes a computation, not a lookup). Zero-trust architectures are, in engine-room terms, ABAC evaluated per request.
Context-based access control
The subset of ABAC the exam names separately: decisions incorporating location, time, and access history, and step-up mechanics like username/password followed by a challenge/response (such as a CAPTCHA) — or in modern deployments, followed by an MFA prompt only when the context looks anomalous. Conditional-access products are this concept productized.
Accountability
Tracing every action to a subject’s identity — providing non-repudiation. The prerequisites assembled in the previous sections: unique identities, strong authentication, and reliable audit logging with synchronized clocks. Weaken any link (shared accounts, unlogged admin channels, drifting clocks) and accountability degrades to conjecture.
Access Control Systems
Centralized Access Control
One authority makes all access decisions for all systems and locations. The trade-offs:
Pros: a uniform security posture everywhere (one policy, consistently enforced), easier management, administrative access concentrated in few hands, structural support for separation of duties, and the foundation for SSO.
Cons: every authentication crosses the network — traffic overhead and response time — and the availability question: is connectivity to the head office stable? A centralized authority is a dependency; if the WAN link or the identity provider is down, so is authentication everywhere. Local caching (cached AD credentials, read-only domain controllers, RADIUS survivability modes) exists precisely to soften this.
Identity and Access Provisioning Lifecycle
The lifecycle disciplines that keep an access-control system honest over time:
- Provisioning and deprovisioning — access granted promptly and correctly at joining, adjusted at role changes, and — the critical half — revoked completely at departure. Deprovisioning is where the process usually fails; orphaned accounts are standing invitations (the supervisor role from Domain 2 exists to feed these events to the administrators).
- User access review — periodic recertification: does each person still need what they hold? Best done by the data/business owner, not IT, because the owner knows what the role requires.
- System account access review — the same discipline for service and system accounts, which are worse offenders: they accumulate privileges, never leave the company, and their passwords live in config files.
The two pathologies these reviews exist to catch: excessive privilege — an account holding more access than its function requires from day one — and privilege creep — access accumulating over time as people change roles and nobody revokes the old grants. Creep is the more insidious one because every individual grant was once legitimate; only the accumulation is wrong. Ten years of moves without cleanup produces the employee who can quietly do everything.
Federated Identity Management
Federation extends identity management across organizational boundaries: multiple organizations agree to trust each other’s authentication, so a user authenticates at their home identity provider (IdP) and consumes services elsewhere without a separate account.
Pros: dramatically easier account management (one identity per person instead of one per silo), single sign-on across the federation, and increased productivity — one credential to remember, fewer password resets, fewer sticky notes.
Cons: federation doesn’t prevent brute-force attacks — and more generally, it concentrates risk: the IdP becomes the single credential store, so a compromised federated identity opens every connected service at once. SSO is a force multiplier for both sides. The mitigation is making the one login strong: MFA at the IdP protects everything downstream in one move.
The SSO ecosystem: OAuth (authorization delegation — strictly speaking not authentication, which is why OpenID Connect exists on top of it), OpenID, Shibboleth (SAML-based academic federation), Kerberos, ADFS (Active Directory Federation Services), and CAS (Central Authentication Service).
SAML — Security Assertion Markup Language: the XML-based standard for web-based SSO, exchanging signed assertions between IdP and service provider. The security note from the original stands: to protect SAML against eavesdropping and forged assertions, use TLS for transport plus digital signatures on the assertions — the signature is what makes an assertion trustworthy, and XML signature validation bugs have produced a steady history of authentication bypasses (signature wrapping attacks), so libraries matter.
Authentication Protocols
Kerberos
The workhorse of enterprise authentication (and the heart of Active Directory). Properties: mutual authentication (client proves itself to the service and vice versa), client-server model, protection against eavesdropping and replay (timestamps and authenticators), built entirely on symmetric keys, organized into realms (≈ AD domains).
The cast:
- KDC (Key Distribution Center) — the trusted third party maintaining the secret keys of every registered principal. Logically contains the next two roles:
- Authentication Server (AS) — verifies identities and issues/validates tickets based on authenticity and timeliness.
- Ticket Granting Server (TGS) — issues service tickets to already-authenticated users.
- Tickets — encrypted messages serving as proof: the Ticket-Granting Ticket (TGT) (obtained at login, proves “I authenticated recently”) and Service Tickets (obtained from the TGS per target service, prove “the KDC vouches for me to you”).
The flow in one breath: authenticate once to the AS → receive TGT → present TGT to TGS for each service → receive service ticket → present to service. The user’s password never crosses the network; everything runs on keys derived from it and session keys minted by the KDC.
The concerns — each one maps to a real attack class familiar from AD security work:
- Security depends on careful implementation — Kerberos is a protocol with sharp edges, not a product.
- Limited ticket lifetimes minimize replayed credentials — long-lived tickets are why golden-ticket attacks (a forged TGT from a compromised KDC key) are so devastating.
- The KDC must be physically and logically hardened — in AD terms: domain controllers are Tier 0; whoever owns the KDC owns every identity in the realm (the krbtgt key is the kingdom).
- The KDC is a single point of failure — it belongs in the backup and BCP planning from Domain 1; no KDC, no authentication.
- Key lengths must be right — too short invites brute force (the reason RC4-HMAC Kerberos etypes are being retired in favor of AES), too long can overload the system (a dated concern, but the exam keeps it).
- Encryption keys derive from passwords — so password-guessing attacks translate directly: Kerberoasting is precisely offline brute-force against service-account keys derived from weak passwords. Long random service account passwords (or gMSAs) are the fix.
RADIUS
The standard network-access AAA protocol between a NAS client (switch, AP, VPN concentrator) and the authentication server — the AS role in the 802.1X triad from Domain 4. Runs on UDP 1812 (authentication) and 1813 (accounting); modern deployments can run TLS over TCP (RadSec) to fix the protocol’s classic weakness: legacy RADIUS encrypts only the password attribute — the rest of the packet, usernames included, travels in clear.
TACACS+
Cisco’s AAA protocol, on TCP 49, supporting two-factor authentication, and fixing RADIUS’s two structural gripes: it encrypts the entire packet (not just the password), and it separates the AAA functions — authentication, authorization, and accounting can be handled and hosted independently. That separation is why TACACS+ owns the network-device administration niche: per-command authorization (this admin may run show, not configure) is a TACACS+ specialty RADIUS can’t match cleanly. Rule of thumb: RADIUS for network access, TACACS+ for network administration.
Diameter
The intended RADIUS successor — the name is the pun (diameter = twice the radius). Runs on TCP or SCTP port 3868, mandates transport security (IPsec or TLS), and expands the attribute-value-pair address space to 32-bit AVPs against RADIUS’s 8-bit — vastly more extensible. It never displaced RADIUS in the enterprise but won the carrier world: 3G/4G/LTE signaling infrastructure runs on Diameter.
PAP and CHAP
Covered in detail in Domain 4; the one-line recap for this domain’s context: PAP transmits username/password in plain text (acceptable only inside an already-encrypted tunnel); CHAP never transmits the password but requires both sides to store the plain-text shared secret — challenge/response on the wire, cleartext liability in the credential store.
Active Directory
The concrete system where most of this domain converges: AD combines LDAP v2/v3 (directory access), Kerberos (authentication), and DNS (service location — SRV records are how clients find their DCs, which is why AD breaks exactly as thoroughly as its DNS does). Administratively it’s typically operated as RBAC via security groups.
Trust relationships between domains — the vocabulary set:
- One-way trust — domain A trusts B’s users; B does not reciprocate.
- Two-way trust — both directions (the default within an AD forest).
- Trusted vs. trusting domain — the trusted domain holds the accounts; the trusting domain holds the resources and accepts the other’s authentication.
- Transitive trust — the trust extends through chains: A trusts B, B trusts C ⇒ A trusts C (default for intra-forest trusts — convenient, and the reason a compromise in one domain can traverse the forest).
- Intransitive (non-transitive) trust — the trust stops at its two parties; typically used for external trusts precisely to prevent that traversal.
The security reading: every trust is an attack path. Trust design — like network segmentation — is deciding in advance how far a compromise is allowed to travel.
Erstellt: 2026-07-08 — ausformulierte Fassung der Original-Stichpunkte, siehe Domain 5 - Identity and Asset Management (Original-Stichpunkte)