Defense in Depth practice questions

Deploying a third perimeter firewall to add redundancy to the external gateway boundary

Why it fails: Adding another perimeter firewall simply duplicates the existing ingress and egress inspection logic without addressing visibility into outbound cloud traffic protocols. Redundancy improves availability but fails to solve blind spots in egress data monitoring.

Implementing strict egress filtering and content inspection for all outbound TLS traffic

Why it fails: Strict egress filtering involves blocking unauthorized ports, but since HTTPS operates over port 443 which is typically required for business operations, simple port blocking is insufficient without deep packet inspection and cloud application visibility.

Upgrading host-based intrusion detection agents to isolate the compromised workstation automatically

Why it fails: Host isolation mitigates lateral movement and host compromise after an incident starts, but it does not address the fundamental architectural failure of failing to monitor and inspect outbound data channels leaving the internal enterprise boundary.

Least Privilege

Why it fails: Least privilege mandates that users and processes are granted only the minimum access rights necessary to perform their required tasks. While important for security, it focuses on limiting the scope of potential damage from a compromised identity rather than the layered control strategy defined by defense in depth.

Security through Obscurity

Why it fails: Security through obscurity relies on hiding information or system details to prevent attacks. This is generally considered a weak practice because attackers can discover hidden details through reconnaissance. It does not involve the structural layering of redundant controls that define the defense in depth architecture paradigm.

Fail-Safe Defaults

Why it fails: Fail-safe defaults imply that in the event of a system failure, the security mechanism defaults to the most restrictive state, such as denying all access. This is an important security design principle, but it describes how a single control behaves rather than the layered defense architecture.

To eliminate the need for regular security patching.

Why it fails: Defense in depth does not negate the necessity of vulnerability management or patching. Patching is a critical layer of defense that addresses the root cause of exploits. Relying on other layers to compensate for unpatched software is a flawed strategy that leaves the organization unnecessarily vulnerable to attacks.

To replace the requirement for user security awareness training.

Why it fails: Human users are often the weakest link in the security chain. No amount of technical layering can fully protect against social engineering if users are not trained. Defense in depth is intended to complement, not replace, the human element of an organization's overall cybersecurity and risk posture.

To centralize all logs into a single storage location.

Why it fails: While centralized logging is a best practice for visibility, it is a management and monitoring capability, not a primary objective of defense in depth. Defense in depth focuses on the layered application of security controls to stop attackers, whereas logging is primarily a detective and forensic capability.

Installing a web application firewall at the network edge.

Why it fails: A WAF deployed at the network edge is a perimeter-level control designed to inspect traffic before it reaches the internal network. While effective for filtering web traffic, it does not provide protection directly on the host itself, which is the defining requirement for a host-level defense control.

Implementing multi-factor authentication for corporate VPN access.

Why it fails: MFA for VPN access is a strong identity and access management control, but it is applied at the network perimeter or the identity provider layer. It helps secure entry into the network, but it does not represent a control applied locally to an endpoint to provide host-level defense.

Deploying a network intrusion detection system (NIDS) in promiscuous mode.

Why it fails: A NIDS is a network-level security control that monitors traffic traversing the network segments. It is not an endpoint or host-based security control. While it is part of an overall defense in depth architecture, it does not satisfy the requirement for security controls deployed specifically on the host.

To reduce the overall cost of software licensing and maintenance.

Why it fails: Using diverse technologies and vendors typically increases administrative complexity and costs due to the need for broader skill sets and integrated management tools. While cost is a factor in business, it is not the security-related reason for favoring heterogeneity in a defense in depth strategy.

To simplify the process of configuring and managing security logs.

Why it fails: Heterogeneous environments actually make log management and correlation more difficult because different vendors use different formats, syslog structures, and APIs. While this makes the environment harder to manage, the security benefit of diversity outweighs the operational complexity of aggregating logs into a centralized security information system.

To minimize the need for external security audits and compliance checks.

Why it fails: The use of heterogeneous controls does not exempt an organization from audits. Auditors require evidence of compliance regardless of the diversity of the security stack. In many cases, a complex, heterogeneous environment may require more rigorous documentation to demonstrate that all controls are functioning as expected.

It eliminates the need for host-based firewalls on individual servers.

Why it fails: Segmentation is a network-level control and does not remove the need for host-based protection. Defense in depth requires layers at both the network and host levels. Relying solely on network-level segmentation ignores the possibility of threats originating from within the network or bypassing the perimeter firewall.

It automatically encrypts all data in transit between segments.

Why it fails: Network segmentation controls traffic flow and access; it does not provide encryption for data in transit. Encryption requires the implementation of protocols like IPsec, TLS, or SSH. Segmentation and encryption are distinct layers of defense that must be implemented separately to provide true defense in depth.

Zero Trust Architecture

Why it fails: While Zero Trust shares the goal of protecting data, it is a specific framework centered on the principle of 'never trust, always verify' identity and access. Defense in depth is a broader architectural strategy that can incorporate Zero Trust principles but is not synonymous with the entire concept.

Security Information and Event Management (SIEM)

Why it fails: A SIEM is a tool used for logging and monitoring, not an architectural strategy for layering defenses. While a SIEM is a critical component of security operations, it functions as a detective control that aggregates data from other layers rather than being the overarching strategy itself.

Privileged Access Management (PAM)

Why it fails: PAM is a specific security discipline focused on controlling and monitoring administrative access to critical systems. It is an important layer in a defense in depth strategy, but it is too narrow in scope to describe the full spectrum of layered security covering perimeter to data.

They automatically block all malicious traffic before it reaches the network.

Why it fails: Detective controls are designed to alert and provide visibility, not to block traffic. Preventive controls are the ones responsible for blocking malicious activity. Misunderstanding the function of detective controls can lead to a false sense of security regarding the organization's ability to stop active threats in real time.

They remove the need for regular vulnerability assessments.

Why it fails: Detective controls do not address the root causes of vulnerabilities. Regular vulnerability assessments are essential to identify and remediate weaknesses in the environment. Relying on detection to manage vulnerabilities is an inefficient and high-risk strategy that fails to address the underlying security issues present in the network.

They ensure that all user actions are strictly restricted by policy.

Why it fails: Detective controls monitor actions but do not restrict them based on policy; that is the role of access control and preventive policy enforcement. Confusing detection with enforcement is a common mistake that undermines the effectiveness of an organization's security posture by failing to implement necessary preventive measures.

Deploy an intrusion prevention system (IPS) on the internal network to block SMB exploits.

Why it fails: An IPS is a detective and preventive control that inspects traffic for known malicious patterns, but it does not restrict which hosts can initiate connections to the payroll server. The contractor's laptop could still establish a legitimate SMB session and, if the IPS signature set does not flag the specific activity, the access would proceed. Least privilege requires limiting reachability, not just filtering for malicious content.

Enable port security on the access switch to limit the number of MAC addresses per port.

Why it fails: Port security controls which devices can connect to a switch port based on MAC address, which helps against rogue devices but does not restrict what an already-authorized device can reach. The contractor's laptop is a legitimate endpoint on the network, so port security would not block its SMB connection to the payroll server. It operates at Layer 2 and does not enforce Layer 3 or application-level least privilege.

Configure the perimeter firewall to block all inbound SMB traffic from the internet.

Why it fails: Blocking inbound SMB at the perimeter prevents external attackers from reaching internal SMB services, but the contractor's laptop is already inside the network. The traffic from the laptop to the payroll server never crosses the perimeter firewall, so this rule has no effect on the internal lateral movement path. The control is necessary but insufficient for the scenario's requirement.

Heterogeneous controls reduce licensing costs because multiple vendors compete for the same functionality.

Why it fails: While competition can influence pricing, the primary security rationale for heterogeneity is not cost reduction. In fact, managing multiple vendors often increases operational overhead and training requirements. The scenario asks for the best justification of the architect's security design choice, and cost savings do not address the resilience benefit that heterogeneous controls provide against a single point of failure or a common vulnerability.

Different vendors provide more comprehensive log formats that are easier to correlate in the SIEM.

Why it fails: Vendor diversity usually complicates log normalization and correlation because each product uses its own schema and semantics. A SIEM must parse and map fields from multiple sources, which can increase tuning effort. The architect's recommendation is not about improving log correlation; it is about avoiding a common-mode failure. Standardizing on one vendor often yields more consistent logs, not less.

Heterogeneous controls are required by HIPAA for any system that stores electronic protected health information.

Why it fails: HIPAA does not mandate the use of multiple vendors or heterogeneous controls. The Security Rule requires appropriate administrative, physical, and technical safeguards, but it is technology-neutral and does not prescribe specific vendor diversity. While defense in depth is a sound practice for protecting ePHI, the legal requirement is risk-based and does not include this specific architectural constraint.

Implementing full-disk encryption on the EHR database servers

Why it fails: Full-disk encryption protects data at rest if the physical disk is stolen, but it does not detect unauthorized modification of records while the system is running and unlocked. It is a preventive confidentiality control, not a detective integrity control. It would not alert the security team to tampering with EHR records.

Configuring syslog forwarding from the EHR servers to a central SIEM

Why it fails: Syslog forwarding collects and centralizes log events, which is useful, but it does not by itself detect unauthorized modification of database records unless the application generates specific integrity events. It is a transport mechanism, not a data-integrity detective control. The scenario calls for detection of record tampering, which syslog alone does not provide.

Deploying an additional host-based firewall on the EHR application servers

Why it fails: A host-based firewall controls network traffic to and from the server but does not inspect or detect changes to database records. It would duplicate the existing preventive network controls rather than add a detective capability at the data layer. The scenario already has network and endpoint controls, so this does not fill the stated gap.

Configure Windows Audit Policy to log all file access events to the Security event log.

Why it fails: Windows auditing can record access attempts, but an attacker with administrative rights can clear or tamper with the event log. Auditing also generates enormous volume on a busy billing server, and it does not provide a cryptographic baseline to prove whether file contents changed. It is weaker than hash-based integrity monitoring for this purpose.

Enable Windows BitLocker full-disk encryption on the billing server's data volume.

Why it fails: BitLocker protects data confidentiality when the disk is offline or the host is powered down, but once the operating system is running and unlocked, files are transparently decrypted. An attacker with administrative access can modify claim files freely, and BitLocker provides no mechanism to detect those changes. It is a confidentiality control, not an integrity-detection control.

Deploy a host-based intrusion prevention system (HIPS) that blocks suspicious process execution on the billing server.

Why it fails: A HIPS monitors and blocks suspicious process behavior on the host, but it does not create a verifiable record of file contents. An attacker with administrative access could disable the agent or alter files without the HIPS producing cryptographic evidence of tampering. It addresses prevention and some detection, not integrity verification of stored claim data.

Implementing 802.1X port-based network access control on all switch ports

Why it fails: 802.1X controls which devices can connect to the network, but once admitted, a compromised workstation can still reach other hosts on the same flat network. It does not limit lateral movement or reduce the blast radius after compromise. The goal is to contain an already-compromised endpoint, so port-based authentication alone is insufficient.

Deploying a web application firewall (WAF) in front of the firm's public website

Why it fails: A WAF protects web applications from external attacks by filtering HTTP traffic, but it does not address internal lateral movement from a compromised workstation. The scenario is about limiting the impact of an internal compromise, not defending a public web service. A WAF operates at the application layer for external-facing services and does not segment internal networks.

Enforcing strong password policies and multi-factor authentication for all users

Why it fails: Strong authentication reduces the likelihood of credential compromise, but it does not contain an attacker who already has a foothold on a workstation. Once compromised, the attacker can move laterally regardless of password policies. The scenario asks for limiting blast radius after compromise, which requires network segmentation, not authentication hardening.

Configure private VLANs to prevent hosts within the cardholder data environment from communicating with each other.

Why it fails: Private VLANs restrict east-west traffic inside a single VLAN, adding a preventive segmentation layer. They do not observe or alert on malicious traffic that traverses the boundary between the cardholder and corporate segments. The architect specifically asked for detection of successful cross-segment attacks, and private VLANs provide isolation rather than visibility.

Deploy a web application firewall (WAF) in front of the cardholder data environment.

Why it fails: A WAF inspects HTTP and HTTPS application traffic for web-specific attacks such as SQL injection, but it does not monitor general network traffic between VLANs. Malicious traffic using non-web protocols, lateral movement, or command-and-control channels would pass unnoticed. The scenario calls for detecting cross-segment malicious traffic, which is broader than web application protection.

Enable 802.1X port-based network access control on all switch ports in both VLANs.

Why it fails: 802.1X authenticates devices before granting switch port access, which is a preventive access control. It does not inspect traffic after authentication or detect malicious activity crossing between VLANs. An authenticated but compromised host could still send malicious traffic that 802.1X would never flag, so it does not satisfy the detective requirement.

Enforcing a password complexity policy for all database accounts

Why it fails: Password complexity reduces the risk of brute-force or guessing attacks, but the breach involved stolen credentials, so complexity would not have prevented it. It is a preventive control that does not address detection of future similar attacks. The scenario specifically calls for improving detection, not prevention.

Implementing full-disk encryption on the database server

Why it fails: Full-disk encryption protects data at rest if the disk is physically stolen, but it does not detect an attacker using valid credentials to access the database over the network. It is a preventive confidentiality control, not a detective one. The breach involved remote access, so encryption would not have helped detect or prevent it.

Configuring a next-generation firewall to block outbound traffic from the database server

Why it fails: Blocking outbound traffic can limit data exfiltration, but it does not provide detection of credential misuse or database activity. It is a preventive network control that may be useful but does not fill the stated logging and monitoring gaps. The investigation showed no host-based logging and no database monitoring, so detection controls are needed.

Grant the build service account passwordless sudo access to all commands to simplify automation.

Why it fails: Passwordless sudo to all commands means a compromise of the build service account yields full root control immediately. This removes privilege boundaries and maximizes the impact of an intrusion instead of containing it. It is the opposite of least privilege and undermines the defense in depth strategy the team is pursuing.

Disable SELinux on the build server to avoid build failures caused by mandatory access control denials.

Why it fails: Disabling SELinux removes a mandatory access control layer that confines processes to defined domains. Doing so makes a compromised build process more powerful, not less, because it can access files and sockets outside its intended role. This directly weakens defense in depth and contradicts the goal of reducing the impact of compromise.

Enforcing application whitelisting on all endpoints

Why it fails: Application whitelisting prevents unauthorized executables from running on endpoints, which can hinder some attacker tools, but it does not provide visibility into network-based lateral movement or exploitation of internal servers. It is a host-level preventive control that may not detect an attacker using legitimate tools or exploiting server misconfigurations. The scenario specifically calls for detecting lateral movement, which requires network monitoring.

Increasing the perimeter firewall rule set to block more inbound ports

Why it fails: The attackers already gained initial access via phishing and moved laterally internally, so tightening inbound perimeter rules would not detect or stop internal lateral movement. It addresses the initial entry vector rather than the post-compromise behavior. The scenario asks for detecting lateral movement, which requires internal visibility.

Implementing stricter email filtering to prevent phishing emails

Why it fails: Email filtering can reduce the likelihood of initial compromise, but it does not help detect or respond to lateral movement once an attacker is inside. The red team already succeeded in gaining access, so the agency needs internal detection capabilities. This control is preventive and external-facing, not detective for internal traffic.

Block all inbound traffic from countries where the company has no customers.

Why it fails: Geo-blocking reduces some attack surface but is easily bypassed with proxies and VPNs, and it does not address credential stuffing from residential IPs in allowed regions. It also risks blocking legitimate customers who travel or use corporate VPNs. The control is too coarse and does not specifically target automated login abuse.

Enforce a strict account lockout after three failed login attempts for all users.

Why it fails: A strict lockout policy stops automated guessing but also lets attackers lock out legitimate customers by deliberately failing logins on their accounts. This creates a denial-of-service condition and increases help desk load. It does not distinguish between a real user and an attacker, so it harms the customer experience the team wants to protect.

Require all customers to use a hardware security key for authentication.

Why it fails: Hardware security keys provide strong phishing-resistant authentication, but requiring them for all retail customers is impractical and would drive away business. The scenario asks for a control that preserves a smooth experience, and mandating hardware tokens does the opposite. It is disproportionate to the threat of credential stuffing on a public e-commerce site.

Deploying a bastion host that developers must use to reach repositories

Why it fails: A bastion host centralizes and controls access to internal systems, but it does not inherently require two distinct authentication factors. It can be combined with MFA, but by itself it only provides a single authentication step. The scenario specifically requires two distinct factors, so a bastion host alone is insufficient.

Enforcing role-based access control (RBAC) on repositories

Why it fails: RBAC limits what authenticated users can do based on their roles, but it does not add a second authentication factor. It is an authorization control, not an authentication control. The requirement is to require two distinct factors before access, which RBAC does not provide.

Configuring IP allowlisting for repository access

Why it fails: IP allowlisting restricts access to specific network addresses, which can prevent external access, but it does not require two distinct authentication factors. An attacker on an allowed IP could still access repositories with a single stolen credential. The scenario demands multi-factor authentication regardless of network location.

Require the courier to sign a non-disclosure agreement and provide chain-of-custody documentation.

Why it fails: An NDA and chain-of-custody records create legal and procedural accountability, but they do not prevent data exposure if a tape is physically lost or stolen. Anyone who recovers the tape could still read its contents. This is an administrative control that supports investigation but does not protect the data itself.

Install GPS trackers on the transport vehicle and monitor the route in real time.

Why it fails: GPS tracking helps locate a vehicle after a theft and may deter some incidents, but it does not protect the data on the tapes. If a tape is removed and copied, tracking the vehicle provides no confidentiality. This is a physical security measure that supports recovery, not data protection.

Reduce the backup retention period from one year to thirty days to limit exposure.

Why it fails: Shortening retention reduces the window in which a lost tape could be exploited, but it does not prevent exposure if a tape is lost during the shortened period. It also conflicts with business and regulatory retention requirements. The control changes policy but leaves the underlying data unprotected on the media.