Security Principles practice questions

Possession-based

Why it fails: Possession-based would be only the OTP.

Biometric

Why it fails: Biometric is a single factor (inherence).

Single-factor

Why it fails: Single-factor uses only one type.

PIN

Why it fails: A PIN is knowledge — something you know — so it is a Type 1 factor, not Type 2. It is tempting because PINs are often paired with a possession factor in two-factor setups, but the PIN itself supplies no physical token. Type 2 requires something you have, such as a smart card or hardware OTP device.

Password

Why it fails: A password is memorised knowledge, placing it firmly in Type 1, so it cannot satisfy a Type 2 requirement. It is tempting because passwords are the most familiar authentication method, but familiarity does not change the factor category. Type 2 demands something you have, like a token or certificate.

Fingerprint

Why it fails: A fingerprint is inherence — something you are — making it a Type 3 biometric factor, not Type 2. It is tempting because biometrics feel like a possession you carry, but the factor taxonomy classifies them separately. Type 2 requires a physical object you have, such as a smart card.

A fingerprint

Why it fails: A fingerprint is something you are, a Type 3 biometric factor, not Type 2 something you have. It is tempting because fingerprints are widely deployed for authentication, and biometrics would be the correct choice when the question asks for inherence-based factors.

A password

Why it fails: A password is something you know, a Type 1 factor; Type 2 demands something you have, like a hardware token or smart card. It is tempting because passwords are the most familiar authentication method, and they would be correct when the question asks for knowledge-based factors.

A PIN

Why it fails: A PIN is something you know, which is a Type 1 factor; Type 2 requires something you have, such as a token or smart card. It is tempting because PINs are frequently paired with hardware tokens, but the PIN itself remains knowledge-based.

PIN

Why it fails: A PIN is knowledge (Type 1, something you know), not possession; it is memorised rather than carried. It is tempting because PINs often accompany a token, and would be the correct choice when the question asks for a knowledge-based authentication example.

Password

Why it fails: A password is knowledge (Type 1, something you know), not possession; it is recalled rather than held. It is tempting because passwords are the most familiar authentication factor, and would be the correct choice when the question asks for a knowledge-based authentication example.

Fingerprint scan

Why it fails: A fingerprint scan is a biometric (Type 3, inherence) factor, verifying a physical characteristic rather than something possessed. It is tempting because fingerprints are commonly used in MFA, and would be the correct choice when the question asks for an inherence-based authentication example.

Email address

Why it fails: Email is regular PII.

Date of birth

Why it fails: Date of birth is regular PII.

Phone number

Why it fails: Phone number is regular PII.

Critical

Why it fails: Critical is a risk or impact rating, not a classification label; schemes typically use Public, Internal, Confidential and Restricted. It tempts because severity tiers in incident response do include Critical, so it fits that context rather than a data classification policy.

Sensitive

Why it fails: Sensitive describes a quality of data rather than a defined handling tier; standard schemes use labels such as Public, Internal, Confidential and Restricted. It tempts because sensitivity intuitively maps to protection level, but classification requires discrete, enforceable categories with assigned controls.

Biometric authentication

Why it fails: Biometric is Type 3; neither factor here is biometric.

Multi-layer authentication

Why it fails: Multi-layer is not a standard term; the correct term is multi-factor.

Single-factor authentication

Why it fails: Two different factors are used, so it is not single-factor.

Advance and protect the profession

Why it fails: The Code of Ethics orders canons with protect society and infrastructure first, then earn and maintain public trust, then provide diligent service, and advancing the profession last. This option sits at the bottom of that hierarchy. It is tempting because professional advocacy matters, but it never outranks public safety.

Provide diligent and competent service to principals

Why it fails: Providing diligent and competent service to principals is the third canon, ranked below protecting society and infrastructure and below earning and maintaining public trust. It is tempting because client service is central to the CISSP role, but the Code subordinates it to public safety and trust.

Act honorably, honestly, justly, responsibly, and legally

Why it fails: Acting honourably, honestly, justly, responsibly and legally forms the second canon, subordinate to protecting society, the common good, necessary public trust and confidence, and the infrastructure. It is tempting because ethical conduct feels foundational, yet the Code explicitly places public safety above it.

A potential cause of an unwanted incident

Why it fails: A vulnerability is a weakness that a threat can exploit, not the cause of an incident; a potential cause of an unwanted incident defines a threat. It is tempting because threats and vulnerabilities interact in risk, and threat would be correct when describing an actor or event that could trigger harm.

The likelihood of a threat exploiting a weakness

Why it fails: Likelihood of exploitation is the risk or probability component, not the weakness itself. A vulnerability is the flaw an attacker could exploit, such as an unpatched service. This option is tempting because likelihood and vulnerability both feed risk calculations, but quantifying probability is risk assessment, not identifying the weakness.

A measure that reduces risk

Why it fails: A risk-reducing measure is a control or mitigation, not the weakness itself. A vulnerability is the flaw a threat could exploit, such as an unpatched service. This option is tempting because controls and vulnerabilities both appear in risk registers, but controls are the response to risk, not the exposure being assessed.

Ensure confidentiality

Why it fails: Confidentiality is provided by encryption, which hides plaintext from eavesdroppers. A digital signature instead proves origin and detects tampering, so it would be chosen when the requirement is verifying the sender's identity and message integrity, not secrecy.

Authenticate users via password

Why it fails: Password authentication verifies a user at login but produces no cryptographic binding to a message. A digital signature uses a private key to prove the signer's identity and detect alteration, which password entry cannot achieve for transmitted data.

Encrypt the data

Why it fails: Encryption conceals content, which a digital signature does not do; signed data remains readable. Signing is chosen when the goal is proving authenticity and integrity, while encryption is chosen when data must be unreadable to unauthorised parties.

Fingerprint scan

Why it fails: Fingerprint is Type 3 (inherence).

Password

Why it fails: Password is Type 1 (knowledge).

PIN

Why it fails: PIN is Type 1 (knowledge).

Phone number

Why it fails: Phone number is general PII.

Name and email address

Why it fails: This is general PII.

Employee ID number

Why it fails: An internal employee ID number may not be PII if it cannot be used to identify a specific person outside the organization; usually it is not considered PII.

Job title

Why it fails: Job title alone is not PII as it does not identify a specific individual.

Department name

Why it fails: Department name does not identify a specific person, so it is not PII.

Internal

Why it fails: Internal data is for internal use but not as sensitive as confidential or restricted.

Public

Why it fails: Public data is intended for unrestricted access, not for sensitive financial or medical information.

Physical control

Why it fails: Physical controls are tangible measures like locks, fences, or guards that protect physical assets. Locking a computer screen is a logical control, not a physical one, because it operates within the operating system and does not involve a physical barrier. Physical controls would include locking the door to the office, not the computer itself.

Compensating control

Why it fails: Compensating controls are alternative measures used when primary controls cannot be implemented. Locking a computer is a primary control, not a compensating one. There is no indication that another control is missing and being compensated for. Therefore, this is not the correct classification.

Administrative control

Why it fails: Administrative controls are policies, procedures, and guidelines that govern behavior. While the policy itself is administrative, the act of locking the computer is a technical control. The question asks about the control type of the action, not the policy. Locking a computer is a logical/technical measure, not purely administrative.

Rule-Based Access Control (RuBAC)

Why it fails: RuBAC uses a set of rules, often based on attributes like time of day or location, to grant or deny access. While it can enforce dynamic conditions, it is not primarily designed to manage access based on job roles and treatment relationships. In this scenario, RuBAC would require complex rule sets for each clinical role, increasing administrative overhead rather than reducing it.

Mandatory Access Control (MAC)

Why it fails: MAC relies on security labels and clearances assigned by a central authority, which is typically used in military or highly classified environments. In a hospital, implementing MAC would require labeling every record and assigning clearances to every clinician, creating excessive administrative overhead and inflexibility for dynamic treatment relationships. It does not align with the requirement to minimize administrative effort.

Discretionary Access Control (DAC)

Why it fails: DAC allows data owners to set permissions at their discretion, which can lead to inconsistent access and privilege creep. In a hospital, physicians might grant broad access to colleagues, violating least privilege and increasing the risk of unauthorized access to patient records. DAC lacks the centralized control needed to enforce consistent, role-based restrictions across the organization.

Security cameras recording the server room

Why it fails: Security cameras are a detective physical control. They record activity for later review but do not actively prevent an incident from occurring. While their presence may deter some attackers, their primary function is to detect and provide evidence after an event. They do not physically stop someone from entering a restricted area, so they are not preventive.

Biometric locks on the data center door

Why it fails: Biometric locks are a preventive physical control, but they are also technical in nature. The question asks for a preventive physical control, and biometric locks combine physical hardware with technology. However, security guards are purely physical and preventive. In the context of defense in depth, both are valid, but the question likely expects the most straightforward physical control, which is guards.

Fire suppression system in the data center

Why it fails: A fire suppression system is a physical control designed to mitigate damage from a fire, but it is not preventive in the sense of stopping an intrusion. It reacts to a fire event, making it a corrective or compensating control. It does not prevent unauthorized access or a security breach; it addresses a different threat (fire) and activates after detection.

A web application firewall filtering portal traffic

Why it fails: A web application firewall inspects HTTP requests and blocks malicious payloads, which makes it a technical or logical control. It operates in software on network traffic rather than through policies, training, or procedures. Although administrators configure it according to policy, the control mechanism itself is technological, so it does not belong in the administrative category the officer is compiling.

Biometric readers controlling the data centre door

Why it fails: A biometric reader is a physical control because it restricts who can physically enter a facility. It combines a physical barrier with a technical authentication mechanism, but its purpose is to control movement through space. The scenario asks specifically for administrative controls, which govern behaviour through rules and education, not through physical access hardware.

Mandatory vacation policy for privileged administrators

Why it fails: Mandatory vacation is frequently classified as an administrative control because it is a management policy, yet in this item the requested pair is the acceptable use policy and awareness training, both unambiguously administrative. The vacation policy is a personnel-related directive, but selecting it would leave only one clearly administrative option alongside it, and the item requires exactly two. The distinction matters because exam items often mix personnel policies with broader administrative directives.

Risk

Why it fails: Risk is the potential for loss or damage when a threat exploits a vulnerability. While the scenario describes a risk situation, the question asks for the combination of the software flaw and the threat actor's potential to exploit it, which is more precisely the vulnerability itself. Risk encompasses likelihood and impact, but the combination described is the vulnerability.

Threat

Why it fails: A threat is any circumstance or event with the potential to cause harm to an asset. The threat actor is the entity that could exploit the flaw, but the combination of the flaw and the actor's potential is not the threat alone. The threat is the actor, while the flaw is the vulnerability. The question asks for the combination, which points to vulnerability.

Exploit

Why it fails: An exploit is a specific technique or code that takes advantage of a vulnerability. The scenario describes the potential for exploitation, not the actual exploit. The combination of the software flaw and the threat actor's potential is not an exploit; it is the vulnerability that could be exploited. An exploit would be the method used, such as a crafted packet or script.

Confidentiality

Why it fails: Confidentiality ensures information is not disclosed to unauthorized individuals. While phishing can lead to confidentiality breaches, the scenario is about recognizing a social engineering attempt, which relates more to user awareness and verification. Confidentiality is a goal, but the principle of skepticism and verification is the immediate concern.

Integrity

Why it fails: Integrity ensures data is not altered improperly. Phishing could lead to integrity issues if credentials are stolen and used to modify data, but the scenario focuses on the employee's suspicion of a fraudulent email. The relevant principle is about not trusting unsolicited requests, which is more aligned with security awareness than data integrity.

Availability

Why it fails: Availability ensures systems and data are accessible when needed. Phishing attacks rarely target availability directly; they aim to steal credentials or install malware. The employee's suspicion is about the legitimacy of the request, not about system uptime. Thus, availability is not the most relevant principle here.