Access Controls practice questions

Bell-LaPadula with no read-down

Why it fails: Again, confidentiality focus.

Biba with no read-up

Why it fails: Biba's no read-up (read from higher integrity) is for integrity, but the primary rules are no write-up and no read-down.

Bell-LaPadula with no write-up

Why it fails: Bell-LaPadula focuses on confidentiality, not integrity.

Biometrics

Why it fails: Biometrics is an authentication method, not an SSO technology.

Public Key Infrastructure (PKI)

Why it fails: PKI supports encryption and digital signatures, but is not an SSO technology.

Change the user's password to a default

Why it fails: Resetting a password to a default leaves the credential known and guessable, and the account still exists, so access is not revoked. It is tempting because administrators sometimes reuse accounts for reassignment, but offboarding requires disabling or deleting the account and terminating its sessions, entitlements and tokens instead.

Notify the user that their account will be removed

Why it fails: Notifying the departing user is courteous but not mandatory; offboarding must proceed on the organisation's schedule regardless of acknowledgement. It is tempting because communication is good practise during workforce changes, yet the mandatory steps are revoking access, disabling credentials and recovering assets, not informing the user.

Delete the account and all associated data

Why it fails: Deleting the account and all associated data conflicts with retention, legal-hold and audit obligations, and destroys evidence needed for investigations. It is tempting because deletion appears to guarantee no residual access, but offboarding requires disabling or removing access while preserving records according to the organisation's retention policy.

Kerberos ticket

Why it fails: Kerberos tickets are symmetric-key session credentials issued by a KDC with a fixed lifetime, not rotating TOTP values. Kerberos is tempting because it delivers single sign-on and mutual authentication, and would be correct for domain authentication within a realm, but it lacks the HMAC-based 30-second time-step algorithm TOTP requires.

Biometric fingerprint reader

Why it fails: A fingerprint reader verifies an inherent biometric trait through minutiae matching, producing no time-derived code. It is tempting as a possession-free authentication factor, and would be correct where non-repudiation or inherence-based identity verification is required, but TOTP specifically needs a shared secret seed and synchronised clock.

Smart card with PKI certificate

Why it fails: Smart cards with PKI certificates perform asymmetric cryptographic challenge-response authentication, not TOTP generation. They are tempting because they provide strong hardware-based possession-factor authentication, and would be correct where certificate-based mutual authentication or digital signing is required, but no shared time seed or HMAC counter produces a rotating code.

Users can share accounts to simplify management

Why it fails: Shared accounts remove individual accountability and make separation of duties unenforceable, since actions cannot be attributed to one person. Account sharing is chosen only where no audit trail or least-privilege requirement exists, such as a shared kiosk login.

It allows users to define their own permissions

Why it fails: RBAC assigns permissions to roles, not to users, so individuals cannot define their own access; that would defeat separation of duties. Self-defined permissions describe discretionary access control, which is appropriate where users own resources and set sharing themselves.

It uses system-wide labels to control access

Why it fails: System-wide labels describe mandatory access control, where the OS enforces sensitivity labels regardless of user identity; RBAC instead maps users to roles. MAC is the right choice in high-assurance environments requiring classification-based containment, such as multilevel secure systems.

Password vaulting with automatic rotation

Why it fails: Vaulting protects the password but doesn't prevent interactive logon if the account has that right.

Requiring multi-factor authentication for the service account

Why it fails: MFA is not typically feasible for automated service accounts.

Session recording and monitoring

Why it fails: Recording detects misuse but does not prevent it.

Discretionary Access Control (DAC)

Why it fails: DAC relies on owner discretion and lacks policy-driven attribute evaluation.

Non-Discretionary Access Control

Why it fails: This is a broad category; ABAC or MAC could be non-discretionary, but ABAC is the specific modern model.

Mandatory Access Control (MAC)

Why it fails: MAC uses fixed labels and does not support dynamic attributes like time or location.

Ticket Granting Service (TGS)

Why it fails: TGS issues service tickets, not TGTs.

Key Distribution Center (KDC)

Why it fails: KDC contains both AS and TGS; the AS specifically issues TGTs.

Domain Controller

Why it fails: Domain controller hosts KDC but AS is the specific component.

MAC

Why it fails: MAC uses labels, not roles.

ABAC

Why it fails: ABAC uses attributes; separation of duties is less direct.

DAC

Why it fails: DAC is owner-driven, not role-based.

Retina scan and iris scan

Why it fails: This uses two inherence factors (retina scan and iris scan), which are not from different categories, so it is incorrect.

Password and security question

Why it fails: This uses two knowledge factors (password and security question), which are not from different categories, so it is incorrect.

Identification

Why it fails: Identification is claiming identity; the issue is the account was not disabled.

Least privilege

Why it fails: Least privilege limits permissions, but the issue is account still active.

Separation of duties

Why it fails: Separation of duties prevents fraud by splitting tasks, not directly related.

To enforce separation of duties

Why it fails: Separation of duties is enforced through mutually exclusive roles, not hierarchy.

To allow users to have multiple roles

Why it fails: Users can have multiple roles without hierarchy.

To reduce the number of roles

Why it fails: Hierarchy doesn't necessarily reduce number of roles.

Security question

Why it fails: Security question is something you know.

Password

Why it fails: Password is something you know, but we need two factors; fingerprint and smart card provide two distinct factors.

IP address

Why it fails: IP address is not a standard authentication factor.

LDAP

Why it fails: LDAP is for directory services, not federation.

RADIUS

Why it fails: RADIUS is for AAA in network access, not federation.

Password hash history

Why it fails: Password hash history is not part of Kerberos logs; it's stored in the directory.

Ticket-Granting Ticket (TGT) expiration time

Why it fails: TGT expiration time doesn't indicate the source of compromise; it's just a validity period.

Service ticket session keys

Why it fails: Session keys are encrypted and not typically logged; they don't aid in source identification.

Kerberos

Why it fails: Kerberos is typically used within a single domain, not for federation across domains, unless extended by trust relationships.

Lightweight Directory Access Protocol (LDAP)

Why it fails: LDAP is a directory access protocol, not a federation technology.

Mandatory access control (MAC); the weakness is that labels are not enforced.

Why it fails: MAC enforces access based on security labels and clearances, and users cannot change permissions. If MAC were in use, a simple username and password would not grant access unless the user's clearance matched the file's label. The scenario indicates that role-based access is required, which is not a characteristic of MAC. Thus, MAC is not the model in use.

Discretionary access control (DAC); the weakness is that users can grant access to others.

Why it fails: DAC allows resource owners to set permissions, which means users have direct control over access. The scenario states that users should not have direct control, so DAC is not the intended model. While DAC could allow a user to access a file with just credentials if they are the owner, the policy requirement points away from DAC. The primary weakness described is not about delegation but about lack of role-based enforcement.

Attribute-based access control (ABAC); the weakness is that policies are too complex to evaluate correctly.

Why it fails: ABAC evaluates multiple attributes and can be fine-grained, but the scenario describes access based solely on username and password, which is more indicative of RBAC. ABAC would typically require additional attributes like department or time. The policy requires role-based access, not attribute-based. While ABAC policies can be complex, the primary issue here is not complexity but role misconfiguration.

Network topology attributes

Why it fails: Network topology attributes, such as the physical layout of routers and switches, are not a standard category in ABAC. While environmental attributes may include network location (e.g., IP subnet), the topology itself is not evaluated. ABAC focuses on subject, object, action, and environment attributes, not on network diagrams.

Environmental attributes

Why it fails: Environmental attributes, such as time of day, location, or threat level, are indeed evaluated in ABAC. However, the question asks for TWO categories, and the most fundamental categories are subject and object attributes. Environmental attributes are also valid, but since only two answers are allowed, subject and object are the primary categories. Selecting environmental would be incorrect in this context because the question expects the two core categories.

Action attributes

Why it fails: Action attributes describe the operation being performed (e.g., read, write, delete). While actions are part of an access request, they are not typically categorized as a separate attribute category in the same way as subject, object, and environment. The question asks for categories of attributes that ABAC evaluates; action is usually the requested operation, not an attribute of the request in the same sense.

The sticky bit

Why it fails: The sticky bit on a directory restricts deletion so that only the file's owner, the directory's owner, or root can remove or rename entries within it. It does not cause file access to inherit the directory's permissions. Setting the sticky bit here would address deletion control in shared directories but leave the stated goal of directory-governed file access unfulfilled.

The setuid bit

Why it fails: The setuid bit applies to executable files and causes them to run with the privileges of the file's owner instead of the invoking user. It has no defined role in governing directory-based access to files and is not applicable to this requirement. Applying setuid to a directory would not produce the intended permission behavior and could introduce security risk if misused on executables.

The setgid bit

Why it fails: The setgid bit on a directory causes new files and subdirectories created within it to inherit the directory's group ownership rather than the creator's primary group. That solves group consistency problems but does not make the directory's permission bits govern access to the files themselves. The scenario specifically asks for directory permissions to control file access, which setgid does not accomplish.

Implicit deny

Why it fails: Implicit deny states that anything not explicitly permitted is forbidden, which governs how rules are evaluated rather than how duties are divided among people. The finding here is that one individual can complete an entire sensitive transaction alone, not that an unlisted action was allowed. Implicit deny would not describe or correct the concentration of incompatible responsibilities.

Least privilege

Why it fails: Least privilege means granting only the minimum rights required for a job function, and it is certainly relevant, but the scenario specifically describes conflicting duties held by one person, not excessive breadth of rights. The payroll administrator may legitimately need both payroll and invoice menus; the finding is that those duties should not coexist in one identity, so least privilege alone does not capture the control failure described.

Mandatory access control

Why it fails: Mandatory access control enforces access decisions through system-wide labels and clearances rather than user discretion, typically in environments handling classified or compartmented data. This ERP scenario involves business process conflicts between payroll and accounts payable functions, not label-based enforcement of sensitivity levels, so mandatory access control is not the principle being violated and would not remediate the finding.