Security Concepts practice questions

NIST Cybersecurity Framework

Why it fails: It is a framework, not a compliance regulation.

ISO 27001

Why it fails: It is a standard, not a compliance framework per se.

Steganography

Why it fails: Steganography hides data, not for integrity or non-repudiation.

Symmetric encryption

Why it fails: Symmetric encryption provides confidentiality, not non-repudiation.

Non-repudiation

Why it fails: Non-repudiation is about preventing denial of actions, not directly related.

Risk

Why it fails: Risk is a broader measure; the specific event is more about threat and exploit.

Vulnerability

Why it fails: A vulnerability is a weakness; the scenario shows an attempt to exploit, not the weakness itself.

HIPAA

Why it fails: HIPAA applies to health information, not payment data.

ISO 27001

Why it fails: ISO 27001 is a general information security standard.

NIST Cybersecurity Framework

Why it fails: NIST CSF is a voluntary framework, not specific to payment data.

Reconnaissance

Why it fails: No evidence of initial reconnaissance in the scenario.

Weaponization

Why it fails: Weaponization involves creating the exploit; not described.

Availability

Why it fails: Availability ensures timely access to data, not its protection from alteration. It tempts because outages are highly visible and availability is a core CIA element, yet the stem concerns unauthorised modification, which integrity covers rather than uptime or accessibility.

Authentication

Why it fails: Authentication verifies identity before access; it is not a CIA triad element and does not itself prevent modification. It tempts because authentication is a common security control, but the stem asks which CIA element ensures data cannot be altered by unauthorised parties, which is integrity.

Confidentiality

Why it fails: Confidentiality prevents unauthorised disclosure, not modification; that is integrity's role. It tempts because confidentiality is the most familiar CIA element and breaches often involve data exposure, but the stem specifies alteration by unauthorised parties, which integrity directly addresses.

Spear phishing

Why it fails: Spear phishing targets a specific individual with personalized information, but the description lacks personalization.

Vishing

Why it fails: Vishing uses voice calls, not email.

Pretexting

Why it fails: Pretexting involves creating a fabricated scenario to obtain information, often through impersonation, not necessarily email.

Vishing

Why it fails: Vishing uses voice calls, not email.

Phishing

Why it fails: Phishing is a mass email, not personalized.

Pretexting

Why it fails: Pretexting involves fabricating a scenario, but not necessarily via email.

Asymmetric encryption

Why it fails: Asymmetric encryption provides confidentiality and authentication, but not integrity alone.

Digital signature

Why it fails: Digital signatures provide authentication and non-repudiation, but hashing is the integrity check.

Symmetric encryption

Why it fails: Encryption provides confidentiality, not integrity verification.

ARP spoofing

Why it fails: ARP spoofing targets MAC-IP mappings at Layer 2.

Man-in-the-Middle

Why it fails: MitM intercepts traffic, but DNS poisoning specifically corrupts DNS.

Pharming

Why it fails: Pharming often involves DNS poisoning, but DNS poisoning is the specific attack.

Non-repudiation

Why it fails: Non-repudiation proves that a party performed an action, typically via digital signatures, so it prevents later denial rather than preventing modification itself. The stem describes integrity, which detects and prevents unauthorised alteration. Non-repudiation would be correct if the requirement were proving who sent or signed data.

Confidentiality

Why it fails: Confidentiality restricts data disclosure to authorised parties through encryption and access controls, so it prevents unauthorised reading, not modification. The stem describes integrity, which detects and prevents unauthorised alteration. Confidentiality would be correct if the requirement were preventing disclosure of sensitive data rather than preventing tampering.

Availability

Why it fails: Availability keeps systems and data reachable to authorised users, so it addresses uptime and denial-of-service resilience, not modification. The stem describes integrity, which detects and prevents unauthorised alteration. Availability would be the answer if the requirement were guaranteed access or recovery from outages rather than preventing tampering.

Integrity

Why it fails: Integrity ensures data is not altered; the attacker did not modify data but stole it.

Non-repudiation

Why it fails: Non-repudiation is not part of the CIA triad; it is related to digital signatures.

Availability

Why it fails: Availability ensures systems are accessible; the attack does not directly prevent access.

Private key

Why it fails: Private keys are generated and kept by users, not part of the PKI infrastructure.

Certificate Revocation List (CRL)

Why it fails: CRL is a list of revoked certificates, but it is not a core component of PKI; it is a supporting mechanism.

Watering hole attack

Why it fails: A watering hole attack compromises a website frequented by a target group and infects visitors, but here the user was directed via an email link to a fake internal portal, not to a legitimate site that was previously compromised. The scenario lacks evidence of a compromised third-party site used to infect many visitors.

Typosquatting

Why it fails: Typosquatting relies on misspellings of a legitimate domain to trick users, but the scenario describes a domain that closely resembles the real one and redirects to a credential-harvesting page, which is characteristic of phishing via a look-alike domain rather than simple typo registration. Typosquatting alone does not explain the credential capture page.

DNS tunneling

Why it fails: DNS tunneling encodes data within DNS queries and responses to exfiltrate information or establish command-and-control channels, but the observed behavior is a user being redirected to a credential-harvesting page, not covert data transfer over DNS. The repeated resolution of a look-alike domain does not by itself indicate tunneling.

Vulnerability

Why it fails: A vulnerability is a weakness in a system, such as an unvalidated input field that permits SQL injection. While the crafted input field is indeed a vulnerability, the team is specifically trying to classify the potential damage to the database. Vulnerability describes the flaw itself, not the magnitude of loss that would result if the flaw were exploited, so it is not the best answer here.

Likelihood

Why it fails: Likelihood is the probability that a threat will exploit a vulnerability. The scenario focuses on the potential damage from reading the database, not on how probable that event is. Although likelihood is part of risk analysis, it does not describe the severity of the data exposure itself. The question asks what the team is classifying, which is the consequence, not the probability.

Threat

Why it fails: A threat is any potential cause of an unwanted incident, such as a malicious actor or a natural event. Here the team is not identifying the actor or source of harm; it is quantifying how harmful an exploited input field would be. Threat alone does not capture the potential loss to the database contents, so it is not the best classification for this risk assessment.

Exploitation

Why it fails: Exploitation is the phase where the attacker leverages a vulnerability to execute code on the target. In the scenario, exploitation already occurred to gain initial access to the web server. Lateral movement happens after exploitation, so this is not the correct phase.

Installation

Why it fails: Installation refers to installing malware or a backdoor on the compromised system to maintain persistence. While the attacker may install tools during lateral movement, the phase itself is not defined by installation. The scenario emphasizes moving to another system, not establishing persistence on the initial host.

Weaponization

Why it fails: Weaponization involves creating a deliverable payload, such as coupling an exploit with a backdoor. It occurs before delivery and does not involve lateral movement within the target network. The scenario describes post-exploitation activity, so this phase does not apply.

Packing

Why it fails: Packing compresses or encrypts the malware's code so that static signatures cannot match it. While packing can hide code, the scenario's evasion relies on using a benign file type with embedded scripting to execute a download, not on a packer obscuring the payload's structure.

Polymorphic code

Why it fails: Polymorphic malware changes its code on each infection to avoid signature detection. The scenario describes an unknown hash and embedded JavaScript, but it does not indicate that the code mutates between executions, so polymorphic behavior is not the primary evasion technique shown.

Rootkit

Why it fails: A rootkit hides the presence of malware by subverting the operating system, often at the kernel level. The scenario describes a PDF with embedded JavaScript that downloads a payload; there is no indication that the attacker is hiding processes or files at the OS level, so rootkit behavior is not demonstrated.

Maintain a policy that addresses information security for all personnel

Why it fails: While PCI DSS Requirement 12 requires maintaining an information security policy, it is not one of the core technical requirements often emphasized in the context of protecting cardholder data. The two most directly related to technical controls for cardholder data protection are firewall configuration and encryption of transmission. This option is valid but less specific to the scenario's focus on core requirements.

Implement mandatory annual penetration testing for all employees

Why it fails: PCI DSS does not require annual penetration testing for all employees. Penetration testing is required for external and internal networks and applications, but not for every employee. Employee training is required, but it is security awareness training, not penetration testing. This option misstates the requirement.

Use only open-source software for all payment processing systems

Why it fails: PCI DSS does not mandate the use of open-source software. It requires secure systems and applications, but does not specify the type of software license. Organizations can use proprietary or open-source software as long as it meets security requirements. This option is incorrect and not a PCI DSS requirement.

Non-repudiation

Why it fails: Non-repudiation ensures that a party cannot deny having performed an action, often achieved through digital signatures. This scenario involves an attacker hiding their traffic, not attempting to prove or deny an action. The self-signed certificate does not provide non-repudiation because it is not trusted. The core issue is the deceptive modification of traffic, which relates to integrity, not non-repudiation.

Availability

Why it fails: Availability ensures that systems and data are accessible when needed. This scenario does not describe a denial-of-service or any disruption of access. The attacker is maintaining stealthy communication, not causing an outage. While command-and-control could later lead to availability impacts, the immediate technique of mimicking HTTPS with a self-signed certificate primarily affects integrity, not availability.

Confidentiality

Why it fails: Confidentiality ensures that data is not disclosed to unauthorized parties. In this scenario, the attacker is hiding command-and-control traffic, not accessing or exposing sensitive data. While encryption is used, it is for evasion, not to protect the confidentiality of the victim's data. The primary impact is on the integrity of the network traffic and the trustworthiness of communications, not on data secrecy.

ARP spoofing

Why it fails: ARP spoofing sends forged ARP replies to associate an attacker's MAC address with a legitimate IP address, enabling man-in-the-middle or denial-of-service on a local network. It operates at Layer 2 and does not involve TCP SYN packets or half-open connections. The packet capture shows TCP SYN traffic to many ports, which is unrelated to ARP. Therefore, ARP spoofing is not consistent with the described behavior.

Port scan

Why it fails: A port scan also sends SYN packets to multiple ports, but its purpose is to discover which ports are open, and a scanner typically completes or resets connections after receiving responses. The scenario emphasizes that the handshake is never completed and that the host repeats this behavior, which points to resource exhaustion rather than enumeration. A port scan is reconnaissance, not a denial-of-service flood, so it does not fit the described pattern.

UDP flood

Why it fails: A UDP flood sends large volumes of UDP datagrams to random or targeted ports to consume bandwidth and processing resources. The scenario explicitly describes TCP SYN packets and the absence of a completed three-way handshake, which are TCP-specific behaviors. UDP has no handshake at all, so a UDP flood would not produce the observed SYN pattern. This option is incorrect because the protocol and mechanics do not match the evidence.