Hard Difficulty Questions

Implement a privileged identity management (PIM) solution to manage access to the financial applications.

Why it fails: Implementing PIM manages privileged access but does not address the frequency of MFA prompts for regular users.

Review the Conditional Access policy for the financial applications to ensure that the 'Session' controls are configured to 'Use app enforced restrictions' and adjust MFA trust settings.

Why it fails: Incorrect. 'Use app enforced restrictions' does not control how often MFA is prompted; it delegates session control to the application, which does not solve the issue.

Disable Seamless SSO and require users to enter passwords each time to ensure token freshness.

Why it fails: Disabling Seamless SSO would force password entry each time, increasing friction and not resolving excessive MFA prompts.

Pass-the-ticket attack

Why it fails: Pass-the-ticket reuses a legitimately issued, still-valid TGT or service ticket captured from memory; it does not fabricate one. Forging a TGT with the KRBTGT hash is a Golden Ticket attack. Pass-the-ticket fits scenarios where an attacker steals existing tickets via credential dumping.

Silver ticket attack

Why it fails: A silver ticket forges a service ticket using a service account hash, granting access to one service, not domain-wide rights. It is tempting because both abuse Kerberos tickets, and would be correct if the attacker had compromised a specific service account rather than KRBTGT.

Kerberos brute force attack

Why it fails: Brute force guesses credentials repeatedly; it cannot forge a TGT, which requires possession of the KRBTGT hash to encrypt a valid ticket. The forged-TGT technique is Golden Ticket. Brute forcing is tempting where weak or guessable passwords protect Kerberos pre-authentication, and lockout policies are absent.

Integration with all third-party applications

Why it fails: Integrating Data Loss Prevention (DLP) solutions with all third-party applications is generally impractical and often unnecessary. DLP operates effectively at various layers, such as network egress points, endpoint agents, or storage repositories, to monitor and control data flow without requiring deep, custom integration with every single application. Attempting universal integration would introduce significant complexity, cost, and potential compatibility issues, hindering deployment and maintenance rather than enhancing security.

Blocking all data transfers to external devices

Why it fails: Indiscriminately blocking all data transfers to external devices, such as USB drives, cloud storage, or personal email, is an overly restrictive and impractical approach for Data Loss Prevention (DLP). While it might prevent some data leakage, it severely impedes legitimate business operations, collaboration, and productivity, leading to significant user frustration and potential workarounds. Effective DLP aims for selective enforcement based on data classification and policy, allowing authorized transfers while preventing unauthorized ones, balancing security with operational necessity.

SSH access is limited to the 10.0.0.0/8 subnet.

Why it fails: This statement may seem true based on the visible rule, but it is not guaranteed. The exhibit only shows one ACL's inbound rules; other ACLs or outbound rules could permit SSH from different subnets, so 'limited to' is too absolute.

The rule order is irrelevant.

Why it fails: ACL rule order is critical; the first matching rule is applied. Thus, statement C is false.

All inbound HTTP traffic is denied.

Why it fails: If the exhibit includes a rule permitting HTTP (e.g., permit tcp any any eq 80), then HTTP is not denied. The exhibit likely shows such a rule, making D false.

Eliminate all risks

Why it fails: Eliminating all risks is neither possible nor desirable; risk management aims to balance risk and reward.

Ensure compliance

Why it fails: Compliance satisfies external obligations but is a by-product, not a primary objective; a programme can be fully compliant yet carry unmanaged risk. Compliance suits regulated reporting contexts, whereas risk management's objectives centre on identifying, assessing and treating risk to agreed tolerance.

The DPO should not hold any other role within the organization

Why it fails: GDPR Article 38(6) states that a Data Protection Officer (DPO) may fulfill other tasks and duties, provided these do not result in a conflict of interest. This means the DPO can hold dual roles, as long as their additional responsibilities do not involve determining the purposes and means of processing personal data, which would compromise their ability to independently advise and monitor compliance. The key is avoiding situations where the DPO would be auditing their own decisions.

The DPO must be a lawyer certified in data protection

Why it fails: GDPR Article 37(5) requires the DPO to possess 'expert knowledge of data protection law and practices,' but it does not mandate a specific professional certification or a legal background. While legal expertise is valuable, the role also demands understanding of information technology, security, and organizational processes. Therefore, a DPO does not strictly need to be a certified lawyer, as long as they demonstrate the requisite knowledge and experience for the role.

The DPO must be located in the EU

Why it fails: GDPR does not explicitly require the Data Protection Officer to be physically located within the European Union. Article 37(6) allows the DPO to be an employee of the controller or processor, or to fulfill the tasks on the basis of a service contract, without specifying a geographical residency. The crucial requirement is that the DPO must be 'easily accessible' from within the EU by data subjects and supervisory authorities, which can be achieved remotely.

Verifying software license compliance

Why it fails: While essential for legal and contractual adherence, verifying software license compliance primarily addresses intellectual property rights and contractual obligations rather than the inherent security of the software itself. This activity ensures the acquiring organization adheres to the terms of use, preventing legal repercussions or financial penalties. However, it does not directly assess or improve the security posture, vulnerability profile, or operational resilience of the acquired software product, making it distinct from direct security assessment activities.

Ensuring code signing is used in the vendor's development process

Why it fails: Ensuring code signing is used in the vendor's development process is a specific technical control for maintaining software integrity, but it is not a primary initial acquisition assessment activity. Code signing cryptographically verifies the authenticity and integrity of software, confirming it has not been tampered with since its release by the developer. While crucial for deployment and runtime security, this is a post-development control that verifies the software's state at release, rather than assessing the inherent vulnerabilities within the code or the vendor's broader security practices during the initial acquisition phase.

Protect society, the common good, necessary public trust and confidence, and the infrastructure

Why it fails: Sharing confidential data directly undermines the public's trust and confidence in organizations and the security professionals safeguarding their information, which is a core tenet of Canon 1. This action erodes the common good by potentially exposing individuals to harm, compromising organizational integrity, and destabilizing the critical infrastructure that relies on secure data handling. Canon 1 mandates that protecting society and maintaining this essential trust is the paramount ethical responsibility for all CISSP professionals, making this the most direct and severe ethical breach.

Advance and protect the profession

Why it fails: Although sharing confidential data can indirectly tarnish the reputation of the cybersecurity profession, this canon is not the *primary* ethical breach in this scenario. Advancing and protecting the profession primarily involves upholding professional standards, sharing knowledge responsibly, and fostering a positive image for security practitioners through exemplary conduct. The direct harm from a data breach is inflicted upon the individuals whose data is exposed and the public's confidence, rather than the abstract concept of the profession itself.

Act honorably, honestly, justly, responsibly, and legally

Why it fails: While sharing confidential information is undoubtedly a dishonorable, dishonest, irresponsible, and illegal act, this canon describes the *manner* in which a professional should conduct themselves, rather than the specific *object* of protection in a data breach scenario. Canon 2 serves as a broad behavioral guideline, emphasizing personal integrity and adherence to legal standards. However, Canon 1 specifically addresses the direct harm to society, public trust, and critical infrastructure caused by such a breach, making it the more precise and primary ethical canon violated.

Role-Based Access Control (RBAC)

Why it fails: RBAC assigns permissions to roles rather than letting the resource owner decide, so authority rests with role administrators, not owners. RBAC is correct where job functions map cleanly to fixed permission sets, such as large enterprises with stable, well-defined organisational roles.

Mandatory Access Control (MAC)

Why it fails: MAC enforces access through system-assigned labels and clearances, removing owner discretion entirely, so it cannot satisfy owner-determined permissions. MAC is the right model for high-assurance environments, such as military or government systems, where central policy must override individual owners.

Attribute-Based Access Control (ABAC)

Why it fails: ABAC grants access from policies evaluating attributes of subject, resource and environment, not from the resource owner's discretion, so ownership does not drive permissions. ABAC is correct for fine-grained, context-aware policy at scale, such as dynamic least-privilege across many resources.

Implement network segmentation with VLANs and IPsec encryption between VMs.

Why it fails: Network segmentation with VLANs and IPsec encryption protects data in transit between VMs over the virtual network. However, a compromised hypervisor operates at a lower privilege level than the VMs, granting it direct access to the physical memory allocated to each VM. This allows the hypervisor to bypass all network-level controls and directly read or modify the VM's unencrypted memory contents, rendering these protections ineffective against such a privileged attack.

Deploy a data loss prevention (DLP) system to monitor data transfers between VMs.

Why it fails: A Data Loss Prevention (DLP) system monitors and prevents unauthorized data exfiltration or transfer based on predefined policies, typically operating at the network or application layer. While DLP can detect suspicious data movement, it is a reactive control and cannot prevent a compromised hypervisor from directly accessing and reading a VM's memory. Direct memory access by the hypervisor is not a 'data transfer' event that DLP is designed to intercept or prevent.

Use a public key infrastructure (PKI) to issue certificates for each VM and enforce mutual TLS for all inter-VM communication.

Why it fails: Using PKI to issue certificates and enforce mutual TLS secures communication between VMs, ensuring data confidentiality and integrity in transit. However, TLS encryption occurs at the network layer and decrypts data once it reaches the VM's operating system for processing. This means that data residing in the VM's active memory or stored on its virtual disk remains unencrypted and fully accessible to a compromised hypervisor, which can directly read these memory regions.

The outbound rules allow all traffic

Why it fails: While allowing all outbound traffic is not a security best practice, as it could facilitate data exfiltration or command-and-control communication from compromised systems, it typically presents a lower immediate risk compared to overly permissive inbound rules. Many organizations prioritize restricting inbound access to critical services, assuming internal systems are generally more trusted or protected by other controls. Therefore, in a comparative analysis of immediate vulnerabilities, this configuration is less critical than broad inbound administrative access.

RDP (port 3389) is allowed from a trusted internal subnet

Why it fails: Allowing RDP (port 3389) exclusively from a specific internal subnet (e.g., 192.168.1.0/24) is generally considered a secure and appropriate configuration for internal administrative access. This adheres to the principle of least privilege by limiting access to a defined, presumably trusted management segment, rather than exposing it to the entire network or the internet. Such a restriction significantly reduces the attack surface for RDP-related vulnerabilities or brute-force attempts.

The VPC ID is exposed

Why it fails: The exposure of a Virtual Private Cloud (VPC) ID does not constitute a security vulnerability. A VPC ID is a unique identifier for a cloud network environment, similar to a network name, and is not considered sensitive information. It is often publicly visible in various cloud resource configurations, logs, or policy outputs and cannot be used on its own to gain unauthorized access or compromise the network's security posture.

Principle of least privilege

Why it fails: The Principle of Least Privilege dictates that users, programs, or processes should be granted only the minimum necessary permissions to perform their legitimate functions. While crucial for overall security by limiting the impact of a compromised account, it primarily governs access control to data and system functions, not the network-level isolation between distinct server workloads or hypervisors to prevent lateral movement within a network segment.

Defense in depth

Why it fails: Defense in depth is a security strategy that employs multiple layers of security controls to protect assets. While essential for a robust security posture, providing redundancy and varied protection mechanisms, it is an overarching architectural philosophy rather than a specific technical solution or mechanism designed to actively segment network traffic between individual servers or virtual machines to prevent lateral movement once an initial breach occurs within a network zone.

Single point of failure elimination

Why it fails: Single point of failure elimination focuses on designing systems with redundancy and fault tolerance to ensure high availability and business continuity. Its primary objective is to prevent service disruption due to the failure of a single component, not to logically segment network traffic between individual servers or virtual machines to contain a security breach and prevent an attacker from moving laterally across the network.

Hashing of DNS responses without keys

Why it fails: Hashing alone provides integrity checking, ensuring data has not been tampered with in transit. However, without a cryptographic key or digital signature, hashing does not verify the *origin* of the DNS response. DNSSEC's core function is to authenticate that the DNS data originated from the authoritative source, which simple unkeyed hashing cannot achieve, leaving responses vulnerable to spoofing.

Transport Layer Security for DNS

Why it fails: Transport Layer Security (TLS), often used in DNS over TLS (DoT), secures the communication channel between a DNS client and a recursive resolver. While TLS encrypts and authenticates the *connection*, it does not provide end-to-end data origin authentication for the DNS records themselves, which is DNSSEC's specific role. DNSSEC operates at the DNS data layer, verifying the authenticity of the records within the zone, independent of the transport layer security.

Symmetric encryption of DNS queries

Why it fails: DNSSEC's primary objective is to authenticate the origin and ensure the integrity of DNS data, not to provide confidentiality for DNS queries. Symmetric encryption would encrypt the content of DNS queries, hiding them from eavesdroppers, but this is outside the scope of DNSSEC's design. DNSSEC uses asymmetric cryptography for digital signatures to validate data, rather than symmetric encryption to obscure query traffic, which is a function typically addressed by protocols like DNS over TLS.

BGP MD5 authentication

Why it fails: BGP MD5 authentication secures the BGP session itself by cryptographically validating the identity of the BGP peer sending updates, preventing unauthorized routers from establishing sessions or tampering with BGP messages in transit. However, it does not verify the legitimacy of the IP prefix being advertised or whether the originating Autonomous System (AS) is authorized to announce that prefix. Therefore, it cannot prevent a legitimate but compromised peer from advertising hijacked routes.

BGP community values

Why it fails: BGP community values are optional, transitive attributes used to tag routes for applying specific routing policies or for informational purposes within and between Autonomous Systems. While they can influence routing decisions, such as local preference or export policies, they are purely informational and lack any cryptographic mechanism to validate the authoritative ownership or origin of an IP prefix. Consequently, community values offer no defense against route hijacking, as they do not verify the legitimacy of the advertised prefix's origin.

AS-path filtering

Why it fails: AS-path filtering involves configuring routers to accept or reject BGP routes based on the sequence of Autonomous Systems listed in the AS_PATH attribute. This technique is primarily used to prevent routing loops, enforce peering policies, or filter out clearly invalid or undesirable paths based on the path's length or specific ASes present. However, AS-path filtering relies on the accuracy of the advertised AS path and does not cryptographically verify the *origin* of the prefix or whether the originating AS is the legitimate owner, thus failing to prevent a malicious AS from announcing a prefix it doesn't own.

WPA3 replaces PSK with SAE and uses GCMP-256 encryption.

Why it fails: WPA3 significantly enhances wireless security by replacing the vulnerable Pre-Shared Key (PSK) authentication with Simultaneous Authentication of Equals (SAE) for personal mode. SAE provides robust protection against offline dictionary attacks and ensures forward secrecy through its Dragonfly Key Exchange, meaning compromise of a long-term key does not compromise past session keys. Furthermore, WPA3 mandates the use of GCMP-256, a stronger encryption algorithm, to protect wireless traffic, moving beyond the limitations of WPA2's AES-CCMP.

WPA3 uses TKIP for backward compatibility.

Why it fails: This statement is incorrect because WPA3 explicitly deprecates and removes support for TKIP (Temporal Key Integrity Protocol). TKIP, introduced with WPA and carried over for backward compatibility in WPA2, is known to have significant cryptographic vulnerabilities that make it unsuitable for modern secure networks. WPA3's design prioritizes strong security, requiring only robust AES-based encryption methods like GCMP-256 or AES-CCMP in transition modes, thereby eliminating any reliance on the outdated TKIP.

WPA3 uses AES-CCMP as the mandatory encryption method.

Why it fails: While AES-CCMP (Advanced Encryption Standard in Counter Mode with CBC-MAC Protocol) is the mandatory encryption method for WPA2, it is not the mandatory standard for WPA3. WPA3 elevates the baseline security by mandating GCMP-256 (Galois/Counter Mode Protocol with 256-bit keys) for its most secure operations, particularly in WPA3-Personal. Although AES-CCMP can still be supported in WPA3 transition modes for backward compatibility with WPA2 devices, it is not the primary or mandatory encryption for new WPA3 connections.

WPA3 eliminates the need for 802.1X authentication.

Why it fails: This statement is false; WPA3 does not eliminate the need for 802.1X authentication; rather, it continues to fully support and enhance it for enterprise environments. While WPA3-Personal utilizes SAE for stronger password-based authentication, WPA3-Enterprise relies on 802.1X with EAP (Extensible Authentication Protocol) to provide robust, centralized user and device authentication, often integrating with RADIUS servers. This distinction ensures that large organizations can still leverage their existing identity management infrastructure while benefiting from WPA3's cryptographic improvements.

IPsec with IKEv2

Why it fails: IPsec with IKEv2 (Internet Key Exchange version 2) is a robust and widely adopted VPN solution designed for strong security. IKEv2 establishes secure Security Associations (SAs) and performs mutual authentication using strong methods such as X.509 certificates, pre-shared keys, or Extensible Authentication Protocol (EAP) which can encapsulate various methods, but not primarily MS-CHAPv2. This modern protocol provides strong encryption, integrity, and replay protection, making it highly resistant to the vulnerabilities associated with older protocols.

SSL/TLS VPN

Why it fails: SSL/TLS VPNs leverage the Transport Layer Security (TLS) protocol to create secure tunnels, offering strong encryption and authentication for remote access. Authentication in TLS VPNs typically involves server-side X.509 certificates to verify the VPN gateway's identity and often client certificates, username/password combinations, or multi-factor authentication for users. Unlike PPTP, TLS does not utilize MS-CHAPv2 as its core authentication mechanism, instead relying on more secure cryptographic primitives and established certificate-based trust models.

L2TP/IPsec

Why it fails: L2TP/IPsec combines the Layer 2 Tunneling Protocol (L2TP) for creating the tunnel with the robust security features of IPsec. IPsec provides confidentiality, integrity, and authentication for the L2TP traffic through its Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols. Key exchange and secure association establishment are handled by IKE, which supports strong authentication methods like X.509 certificates or pre-shared keys, thereby avoiding the use and inherent weaknesses of MS-CHAPv2.

Relying on network segmentation and IP allowlisting

Why it fails: Relying solely on network segmentation and IP allowlisting provides an insufficient security posture for microservices, as it primarily focuses on perimeter defense rather than granular service-level identity. While segmentation can reduce the attack surface, IP allowlisting is vulnerable to IP spoofing and does not authenticate the identity of the calling service, only its network origin. A compromised host within an allowed segment could freely interact with other services, bypassing this weak control and violating the principle of least privilege.

Using JSON Web Tokens (JWT) in the HTTP header

Why it fails: Using JSON Web Tokens (JWT) in the HTTP header primarily serves to convey authenticated user identity and authorization claims from an identity provider to a service, or between services for authorization purposes. However, JWTs themselves do not provide encryption for the transport layer or mutual authentication between the communicating services. While a JWT can assert who is authorized to perform an action, it does not cryptographically verify the identity of the service making the request or secure the communication channel against eavesdropping or man-in-the-middle attacks.

Using pre-shared API keys for each service pair

Why it fails: Pre-shared API keys offer a basic form of authentication, typically unidirectional, where a client service presents a secret key to identify itself to a server service. This method lacks mutual authentication, meaning the client does not verify the server's identity, making it susceptible to impersonation. Moreover, managing and securely distributing a large number of unique API keys for every service pair in a dynamic microservices environment becomes operationally complex and increases the risk of key compromise, especially if not protected by an underlying secure transport like TLS.

Cross-site scripting (XSS)

Why it fails: Cross-site scripting (XSS) is a client-side code injection attack where malicious scripts are injected into legitimate websites, typically targeting end-users' browsers. This attack exploits vulnerabilities in web applications that fail to properly sanitize user-supplied input before rendering it in a web page. It is fundamentally different from a policy-based authorization issue like scope confusion, as XSS does not directly manipulate or exploit OAuth authorization scopes or server-side access policies.

Cross-site request forgery (CSRF)

Why it fails: Cross-site request forgery (CSRF) is an attack that tricks an authenticated user into submitting an unintended request to a web application where they are currently logged in. The attacker crafts a malicious web page or email containing a hidden request that, when loaded by the victim's browser, executes an action on the target site using the victim's authenticated session. This attack primarily targets state-changing requests and does not involve the misinterpretation or misuse of OAuth authorization scopes or the underlying access control policies.

SQL injection

Why it fails: SQL injection is a code injection technique used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution, often to dump database content or bypass authentication. This type of attack specifically targets vulnerabilities in an application's interaction with its backend database. It has no direct relevance to OAuth authorization policies, the definition of access scopes, or the proper configuration of an authorization server's permission grants, which are policy-level concerns.

Deauthentication attack

Why it fails: A deauthentication attack involves an attacker sending specially crafted deauthentication frames to one or more clients, or to the access point (AP) itself, impersonating either the client or the AP. This forces legitimate clients to disconnect from the wireless network, often to capture a WPA/WPA2 handshake during re-association. However, this attack focuses on disrupting existing connections rather than establishing a rogue access point to impersonate a legitimate one.

ARP spoofing

Why it fails: ARP spoofing, also known as ARP poisoning, is a Layer 2 attack that involves an attacker sending forged Address Resolution Protocol (ARP) messages onto a local area network. This causes the attacker's MAC address to be associated with the IP address of another host, such as the default gateway, on the victim's ARP cache. While it can be performed on a wired or wireless network, it manipulates network traffic flow within an existing network and does not involve establishing a rogue access point to mimic a legitimate one.

Karma attack

Why it fails: A Karma attack is a specific type of rogue AP attack where the attacker's access point passively listens for probe requests from clients that are searching for previously connected, preferred networks. The rogue AP then responds to *any* such probe request, regardless of the requested SSID, by advertising itself as that preferred network. This technique exploits client behavior to trick devices into automatically connecting to the attacker's AP, but it's distinct from an evil twin which actively broadcasts a specific, known SSID.

Block all access to public cloud storage services from corporate devices.

Why it fails: Blocking all access to public cloud storage services from corporate devices is an overly restrictive measure that severely impedes legitimate business operations and employee productivity. Many organizations rely on public cloud services for collaboration, data sharing with external partners, and remote work, making a complete block impractical and potentially driving users to unmonitored shadow IT solutions. This approach lacks the necessary granularity to differentiate between legitimate and unauthorized data transfers, creating significant operational friction.

Implement mandatory security awareness training focusing on data handling procedures.

Why it fails: Implementing mandatory security awareness training is a crucial foundational control for educating employees on data handling policies and the risks associated with sensitive information. However, training alone is insufficient to prevent all accidental data breaches, as human error remains an inevitable factor, even among well-trained individuals. It lacks the automated, real-time enforcement capabilities required to consistently monitor and block unauthorized or accidental sharing of sensitive data, making it a valuable but not a primary preventative technical solution for this specific problem.

Encrypt all sensitive data at rest and in transit to render shared data useless.

Why it fails: Encrypting all sensitive data at rest and in transit is a critical security measure for protecting data confidentiality, rendering it unreadable to unauthorized parties. However, encryption does not inherently prevent an authorized user from *sharing* the encrypted data, which is the core issue of an employee inadvertently sharing information. If an employee with legitimate access shares an encrypted file, and the recipient also gains access to the decryption key or the means to decrypt it, the data is still compromised through sharing, even if it was encrypted.