Security Models, Principles and Architecture

Introduction and Context

Enterprise networks are no longer bounded, static environments. Employees work from multiple locations, applications are delivered through cloud platforms, operational technology is connected to corporate systems, and users, devices, services, and data may be distributed across many administrative domains. In this environment, network security cannot depend on a single firewall or a trusted internal perimeter. It must be designed as a system of mutually reinforcing controls.

This chapter examines the principles and architectural models used to construct such systems. It focuses on defense in depth, least privilege, separation of duties, secure-by-design, fail-safe defaults, resilience, threat modeling, security reference architectures, and Zero Trust. These ideas are related but not interchangeable. Defense in depth concerns layers of protection; least privilege limits authority; separation of duties reduces the risk of unilateral misuse; secure-by-design places security in the development and architecture process; fail-safe defaults determines how systems behave when decisions or components fail; resilience addresses continued operation and recovery; threat modeling provides a method for identifying and prioritizing risks; and Zero Trust supplies an identity- and policy-centered approach to access decisions.

A postgraduate security professional must be able not only to define these concepts, but also to resolve conflicts between them, select controls appropriate to risk, justify architectural decisions, and evaluate whether an implementation provides meaningful protection rather than merely appearing sophisticated.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain major security principles and distinguish their purposes.

2. Apply defense in depth and least privilege to enterprise network design.

3. Analyze the relationship between security, availability, resilience, and usability.

4. Conduct a structured threat-modeling exercise.

5. Design a security reference architecture using segmentation, identity, policy enforcement, monitoring, and recovery controls.

6. Explain Zero Trust principles and compare them with perimeter-based security.

7. Evaluate architectural trade-offs, governance obligations, and implementation limitations.

1. Security as a System of Constraints and Assumptions

A security architecture is a set of structures, rules, processes, and technologies that protect assets against unacceptable risk. It is not simply a collection of security products. Architecture expresses assumptions about users, devices, networks, applications, attackers, trust relationships, and failure conditions.

Security objectives are commonly expressed through the confidentiality, integrity, and availability (CIA) triad:

• Confidentiality prevents unauthorized disclosure.
• Integrity protects information and systems from unauthorized or improper alteration.
• Availability ensures that authorized users can obtain required services when needed.

Modern architectures often extend the triad with authenticity, accountability, privacy, safety, and resilience. For example, a hospital network must protect patient confidentiality, preserve the integrity of clinical records, maintain availability of life-supporting systems, authenticate clinicians, provide auditability, and respect privacy obligations.

A control should therefore be evaluated against a defined risk, not praised merely because it is technically advanced. Encryption may protect confidentiality, but it does not by itself prevent an authorized administrator from deleting data. Network segmentation may limit lateral movement, but poorly managed identities can still allow an attacker to enter multiple segments. Security architecture is consequently an exercise in combining controls so that the failure or bypass of one control does not automatically produce unacceptable harm.

2. Foundational Security Principles

2.1 Defense in Depth

Defense in depth uses multiple, partially independent layers of protection. Typical layers include governance and policy, physical security, identity security, endpoint protection, network segmentation, application security, data protection, monitoring, and recovery.

The principle is not simply “add more controls.” Effective layers should differ in mechanism and failure mode. A password and a second password provide less diversity than a password combined with a phishing-resistant hardware authenticator. A firewall and a second firewall configured with the same rule error may provide less protection than a firewall, application authorization, and database access monitoring.

A layered design commonly contains:

1. Preventive controls, such as secure configuration, access control, and segmentation.

2. Detective controls, such as logging, intrusion detection, and anomaly analysis.

3. Corrective controls, such as account isolation, patching, and malware removal.

4. Recovery controls, such as tested backups, alternate processing, and disaster recovery.

Defense in depth has costs. Each layer creates administrative complexity, possible latency, and opportunities for inconsistent policy. Layers should therefore be selected through risk analysis and reviewed for independence, coverage, and operational feasibility.

2.2 Least Privilege

Least privilege requires each subject—human, process, service, device, or application—to receive only the authority necessary for an authorized task, for only the required period. The principle has at least four dimensions:

• Scope: which resources may be accessed.
• Operation: what actions may be performed.
• Context: under what conditions access is permitted.
• Duration: how long authority remains valid.

A database service may need to read selected tables but not alter schemas. A network administrator may need to change firewall rules but not retrieve customer content. Temporary privilege elevation may be appropriate for emergency maintenance, provided that approval, time limits, and recording are enforced.

Least privilege is difficult in practice because organizations often lack accurate inventories, application dependencies, and role definitions. Excessive privilege also accumulates through role changes, inherited group membership, service accounts, and emergency exceptions. Periodic entitlement review, just-in-time access, separation of administrative accounts, and automated revocation are therefore important.

Least privilege is not identical to “deny everything.” Access must be sufficient for legitimate work, and overly restrictive permissions can encourage unsafe workarounds. The design objective is necessary and proportionate authority, supported by evidence of business need.

2.3 Separation of Duties

Separation of duties divides a sensitive process among multiple people, roles, or technical components so that no single actor can complete an abuse-prone operation alone. For example, one employee may request a payment, another may approve it, and a system may execute it. In network security, a person who develops firewall rules may be prohibited from unilaterally approving and deploying them to production.

Separation can be preventive or detective. Preventive separation blocks a single actor from completing the full operation. Detective separation permits the operation but requires independent review. Strong separation reduces fraud and insider risk, but it can increase operational delay and become impractical in small teams. Compensating controls—such as immutable logs, dual approval, automated testing, and independent review—may be necessary.

2.4 Secure-by-Design and Secure Defaults

Secure-by-design treats security requirements as architectural requirements from the beginning of a system’s lifecycle. It includes threat modeling during design, secure interfaces, strong identity assumptions, protected secrets, safe update mechanisms, and failure analysis before deployment.

Secure defaults ensure that an unconfigured or newly deployed system begins in a defensible state. Examples include disabled unused services, non-public administrative interfaces, encryption enabled by default, unique initial credentials, restrictive network exposure, and logging of security-relevant events.

Secure-by-design differs from post-deployment hardening. Retrofitting controls may be more expensive and may leave architectural weaknesses that cannot be repaired without redesign. Nevertheless, secure-by-design does not eliminate the need for operational security: vulnerabilities, misconfigurations, and changing threats remain.

2.5 Fail-Safe Defaults and Failure Modes

Fail-safe defaults deny access or limit functionality when a decision cannot be safely made. A failed authorization service should not automatically grant administrative access. A firewall rule that cannot be evaluated should normally fail closed for sensitive traffic.

Fail-safe behavior must be distinguished from availability requirements. If denying all access during an identity-provider outage would interrupt emergency medical care, the system may need a carefully controlled break-glass mechanism. Such a mechanism should use narrowly defined emergency accounts, strong authentication, time limits, logging, and retrospective review.

Designers should explicitly analyze:

• What happens if an authentication service is unavailable?
• What happens if logs cannot be delivered?
• What happens if a certificate expires?
• What happens if a segmentation device fails open or fails closed?
• Can an attacker intentionally trigger the failure mode?

A failure mode is secure only when its consequences, operational alternatives, and recovery procedures are understood.

2.6 Resilience and Recoverability

Resilience is the ability of an organization or system to continue delivering important functions under stress and to recover within an acceptable period. Security resilience includes resistance to attack, detection, containment, continuity, restoration, and learning.

Resilience should not be confused with redundancy alone. Two identical systems with the same vulnerability may fail together. Resilience requires diversity where useful, tested recovery procedures, independent backups, dependency mapping, alternate communications, and practiced decision-making.

Two common recovery objectives are:

• Recovery Time Objective (RTO): the maximum acceptable time to restore a service after disruption.
• Recovery Point Objective (RPO): the maximum acceptable age of data after recovery, expressed as a time interval.

For example, an RTO of four hours means the service should be restored within four hours; an RPO of fifteen minutes means the organization may lose no more than approximately fifteen minutes of recent data under the stated recovery design. These are business requirements, not guarantees produced automatically by a technology.

3. Threat Modeling as an Architectural Method

Threat modeling is a structured process for identifying what must be protected, how it may be attacked, and which controls reduce risk. It should be performed early and revisited when architecture, dependencies, or threats change.

A practical process contains the following stages:

3.1 Establish Scope and Security Objectives

Define the system boundary, business purpose, data flows, users, trust relationships, and assumptions. Identify assets such as credentials, personal data, intellectual property, operational processes, and safety-critical functions. State security objectives in concrete terms, such as “only approved clinicians may view a patient record” or “a compromised workstation must not directly administer production servers.”

3.2 Model Components and Trust Boundaries

Use data-flow diagrams to show processes, data stores, external entities, and communication paths. Mark trust boundaries wherever control, ownership, privilege, or security assumptions change. Examples include the boundary between a user device and a cloud service, between a corporate network and a supplier, and between an application tier and a database tier.

Trust boundaries are analytical boundaries, not necessarily physical network boundaries. A single cloud network may contain several logical trust zones, while a single office network may contain users with very different privileges.

3.3 Identify Threats

Threat categories can be derived using structured approaches such as spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Other methods emphasize adversary tactics, attack paths, misuse cases, or abuse of business processes.

Threat identification should include:

• credential theft and impersonation;
• malicious or compromised insiders;
• vulnerable exposed services;
• supply-chain compromise;
• insecure interfaces and excessive permissions;
• data leakage and privacy violations;
• destructive attacks and extortion;
• failures of critical dependencies.

3.4 Analyze Risk and Select Treatments

Risk analysis considers likelihood, impact, existing controls, and uncertainty. A qualitative matrix may classify risks as low, medium, high, or critical. Quantitative estimates are possible when credible data exist, but false precision should be avoided.

A useful conceptual relationship is:

Residual risk = inherent risk − risk reduction from implemented controls

This is not a universal numerical equation; it is a reasoning model. “Inherent risk” means risk before the proposed controls, and “risk reduction” must account for control effectiveness, coverage, dependencies, and bypass opportunities. Residual risk is rarely zero and must be accepted, transferred, avoided, or further reduced by an accountable authority.

3.5 Validate and Maintain the Model

Threat models should produce testable requirements. If the threat is lateral movement from a workstation, the design requirement might include administrative segmentation, restricted management protocols, and detection of unusual east-west traffic. Validation may use architecture review, configuration assessment, penetration testing, adversary emulation, and recovery exercises.

4. Security Reference Architecture for Enterprise Networks

A reference architecture is a reusable conceptual pattern, not a product-specific design. A contemporary enterprise reference architecture can be organized into the following planes and zones.

4.1 Identity and Policy Plane

Identity services establish who or what is requesting access. They include identity providers, multifactor authentication, device identity, privileged access management, policy engines, and authorization data. Access decisions should consider identity, device posture, resource sensitivity, requested action, location or network context, time, and current risk.

Authentication proves or evaluates identity; authorization determines what an authenticated entity may do. Confusing these functions is a common architectural error.

4.2 User and Endpoint Zone

Endpoints should be inventoried, securely configured, patched, monitored, and evaluated before accessing sensitive resources. Endpoint controls may include host firewalls, application control, disk encryption, endpoint detection and response, secure boot, and device-health attestation.

A network location such as an office subnet should not be treated as sufficient evidence of trust. A managed laptop and an unmanaged personal device on the same wireless network require different treatment.

4.3 Access and Enforcement Zone

Policy enforcement points mediate access between subjects and resources. Examples include secure access gateways, network access control, software-defined perimeter components, API gateways, reverse proxies, service-mesh authorization, and database access controls.

Enforcement should occur close to the protected resource where practical. A single perimeter gateway is inadequate when workloads communicate directly across cloud networks or when users access services over the public Internet.

4.4 Segmentation and Protected Zones

Segmentation separates systems according to sensitivity, function, administrative responsibility, or threat exposure. Common zones include public services, user systems, application services, databases, management systems, development environments, backups, and operational technology.

Segmentation can be physical, virtual, logical, identity-based, or application-aware. Its value depends on enforcement quality. A VLAN without access-control policy is not meaningful isolation. Rules should be explicit, minimal, documented, monitored, and regularly reviewed.

Microsegmentation applies policy at a finer granularity, often between workloads or services. It can reduce lateral movement but may be difficult to operate because application dependencies are dynamic and poorly documented.

4.5 Data and Management Planes

Data protection includes classification, minimization, encryption in transit and at rest, tokenization where appropriate, rights management, retention controls, and secure deletion. Encryption keys require separate lifecycle management; encrypting data while allowing broad access to keys does not provide strong protection.

The management plane should be isolated from ordinary user traffic. Administrative interfaces require strong authentication, privileged access workflows, restricted source locations, session recording where appropriate, and independent monitoring. Compromise of the management plane can defeat otherwise strong segmentation.

4.6 Telemetry, Detection, and Response

Logs should support detection, investigation, accountability, and compliance. Important events include authentication, privilege changes, policy decisions, administrative actions, configuration changes, data access, and security alerts. Logs should be time-synchronized, protected against alteration, retained according to risk and legal requirements, and accessible to authorized investigators.

Security information and event management systems, network detection, endpoint telemetry, and cloud audit services can support correlation. Automation should be carefully governed: an automated block may reduce attack impact but may also disrupt critical operations if its confidence is poor.

5. Zero Trust Architecture

Zero Trust is an architectural approach in which no user, device, network, or workload receives implicit trust solely because of its location or prior access. Access is continuously evaluated against policy, and authorization is limited to a specific resource, action, and context.

Its central ideas include:

• verify explicitly using available identity and context signals;
• apply least-privilege access;
• assume breach and limit blast radius;
• monitor continuously and use telemetry to update decisions;
• protect resources rather than relying primarily on network perimeters.

A Zero Trust architecture typically includes a policy decision function, policy administration mechanisms, and policy enforcement points. The exact implementation varies. Zero Trust is not a single product, a requirement to eliminate all networks, or a guarantee that compromise is impossible.

Zero Trust complements defense in depth. Identity-based policy may prevent unauthorized access, segmentation may restrict movement, endpoint detection may reveal compromise, and recovery controls may restore services. Zero Trust also introduces operational challenges: identity sprawl, device-attestation limitations, legacy protocols, policy complexity, privacy concerns, and dependence on centralized services.

Continuous verification must be proportionate. Requiring disruptive reauthentication for every low-risk action may damage usability and encourage unsafe behavior. Risk-adaptive access can use session age, device posture, resource sensitivity, anomalous behavior, and transaction value, but automated decisions require transparency, testing, and appeal or override mechanisms.

6. Worked Application: Illustrative University Research Network

Background

A fictional university operates a research network containing student laptops, administrative systems, laboratory instruments, research databases, and a public collaboration portal. Researchers need external collaboration, while some projects contain confidential industry data. The network historically relied on a campus firewall and broad internal access.

Problem

A stolen researcher password was used to access a workstation. The attacker discovered shared credentials, moved to a laboratory server, copied research data, and attempted to encrypt shared storage. Logs were incomplete, and the backup system was reachable using the same administrative credentials.

Analysis

Threat modeling identified several weaknesses:

1. Internal network location was treated as trust.

2. Research services had excessive east-west connectivity.

3. Privileged and ordinary accounts were not separated.

4. Backup administration was not isolated.

5. Multifactor authentication was absent for remote access.

6. Recovery procedures had not been tested.

The highest-impact attack path was stolen identity to workstation compromise, lateral movement, privileged access, and backup destruction.

Approach

The university adopted a staged architecture:

• phishing-resistant multifactor authentication for administrators and remote access;
• separate administrative identities and just-in-time privilege elevation;
• segmentation of student, administrative, laboratory, research, and backup zones;
• application-level access rules for research databases;
• isolated backup administration with immutable or offline copies;
• endpoint monitoring and centralized, protected logging;
• restricted management access through a hardened administrative pathway;
• threat-model reviews for new research services;
• tested recovery objectives agreed with research owners.

The university also introduced separation of duties: laboratory system owners could request changes, but an independent security or operations role approved production firewall changes. Emergency access was retained through monitored break-glass accounts.

Outcome

The redesigned environment did not eliminate compromise risk. It did, however, reduce the probability that one stolen credential would provide broad access, improve detection of unusual movement, and increase the probability of recovery without paying an attacker. The main implementation difficulty was dependency discovery: several laboratory systems used undocumented legacy protocols and could not immediately support modern identity controls.

Learning Points

The case demonstrates that Zero Trust is most effective when combined with segmentation, least privilege, resilient backups, and operational governance. It also shows that architecture must accommodate safety, research continuity, legacy constraints, and human behavior rather than assuming ideal technology.

7. Governance, Ethics, and Regulatory Considerations

Security architecture determines who may observe, deny, or investigate activity. Excessive monitoring can affect privacy, academic freedom, employee dignity, and due process. Organizations should define legitimate purposes, minimize collected data, restrict access to telemetry, establish retention periods, and communicate monitoring practices transparently.

Regulatory obligations vary by sector and jurisdiction. Requirements may address personal-data protection, breach notification, financial controls, healthcare confidentiality, critical infrastructure, records retention, and evidence handling. Compliance is not equivalent to security: a compliant control may be ineffective against a current threat, while a useful security control may require additional legal assessment.

Governance should assign accountability for risk acceptance, architecture approval, access review, incident response, and recovery testing. Suppliers and cloud providers require contractual, technical, and assurance controls. Shared-responsibility models must be documented; outsourcing infrastructure does not outsource the organization’s responsibility for appropriate data governance.

8. Challenges and Contemporary Developments

Important challenges include:

• Legacy systems: old protocols may lack authentication, encryption, or granular authorization.
• Cloud and multicloud complexity: control responsibilities and telemetry differ across providers.
• Identity concentration: compromise of a central identity provider can have systemic impact.
• Policy drift: infrastructure changes faster than documentation and review cycles.
• Alert overload: excessive low-quality detections reduce human effectiveness.
• Availability trade-offs: strict fail-closed controls can disrupt essential services.
• Supply-chain dependency: software, hardware, managed services, and updates introduce external risk.

Artificial intelligence can assist with anomaly detection, code analysis, attack-path discovery, and security operations. However, AI systems can generate false positives, conceal reasoning, expose sensitive data, or be manipulated by adversarial inputs. AI should support—not replace—clear accountability, human review for high-impact actions, secure model and data governance, and testing against realistic failure cases.

Contemporary practice increasingly emphasizes software supply-chain security, identity threat detection, confidential computing, passwordless authentication, continuous control validation, attack-surface management, and cyber recovery. These developments are valuable when they address a defined architectural gap; adopting them as isolated technologies does not create a coherent security model.

9. Best-Practice Design Method

A practical design sequence is:

1. Identify business services, assets, dependencies, and unacceptable outcomes.

2. Define security objectives and regulatory constraints.

3. Draw data flows and mark trust boundaries.

4. Model threats and likely attack paths.

5. Establish identity, authorization, and least-privilege requirements.

6. Select diverse preventive, detective, corrective, and recovery controls.

7. Define segmentation and enforcement points close to resources.

8. Specify secure defaults, fail-safe behavior, and emergency procedures.

9. Establish logging, monitoring, incident response, and recovery objectives.

10. Test the architecture through review, technical validation, exercises, and adversary simulation.

11. Measure control effectiveness and revise the model as systems change.

A mature architecture is therefore a continuing governance process. Its quality is shown not by the number of tools deployed, but by whether important risks are reduced, failures are contained, decisions are auditable, and critical services can recover.

Chapter Summary

Enterprise network security requires an architectural system rather than a single defensive product. Defense in depth combines diverse preventive, detective, corrective, and recovery controls. Least privilege limits the scope, action, context, and duration of authority, while separation of duties prevents one actor from controlling sensitive processes alone. Secure-by-design and secure defaults embed protection early; fail-safe defaults define safe behavior during uncertainty or failure; and resilience ensures continuity and recoverability under attack.

Threat modeling connects assets, trust boundaries, threats, controls, and residual risk. A security reference architecture typically integrates identity, endpoint security, enforcement points, segmentation, protected data and management planes, telemetry, response, and recovery. Zero Trust rejects implicit trust based on network location and applies explicit, least-privilege, resource-focused decisions supported by continuous monitoring. Effective implementation must address legacy systems, availability, privacy, governance, supply-chain risk, and operational complexity.

Key Terms

Defense in depth: Use of multiple, diverse security layers to reduce the effect of control failure.

Least privilege: Granting only the authority necessary for an authorized task and period.

Separation of duties: Dividing sensitive responsibilities so one actor cannot complete an abuse-prone process alone.

Secure-by-design: Integrating security requirements into architecture and development from the beginning.

Secure default: A system’s initial configuration that provides a defensible security posture.

Fail-safe default: Behavior that denies or restricts access when a safe decision cannot be made.

Resilience: The ability to withstand disruption, continue important functions, and recover.

RTO: Maximum acceptable time for restoring a service after disruption.

RPO: Maximum acceptable age of data after recovery.

Threat modeling: Structured identification and analysis of assets, threats, attack paths, and controls.

Trust boundary: A point where assumptions about control, ownership, privilege, or security change.

Risk treatment: The decision to avoid, reduce, transfer, or accept risk.

Segmentation: Dividing systems or traffic into controlled security zones.

Microsegmentation: Fine-grained segmentation, often between workloads or services.

Policy enforcement point: A component that permits, denies, or controls access according to policy.

Authentication: Establishing or evaluating the identity of a subject.

Authorization: Determining which actions an authenticated subject may perform.

Zero Trust: An architecture that grants no implicit trust and verifies access explicitly.

Residual risk: Risk remaining after controls are applied.

Break-glass access: Exceptional emergency access governed by strict limits, logging, and review.

Review Questions

Short Answer Questions

1. What is the purpose of defense in depth, and why should its layers have different failure modes?

2. Distinguish authentication from authorization.

3. Define RTO and RPO.

4. What is a trust boundary in threat modeling?

5. Why is network location insufficient as the sole basis for trust?

Long Answer Questions

1. Explain how least privilege, separation of duties, and fail-safe defaults can be combined in an administrative network design.

2. Describe the stages of a threat-modeling process and explain how its outputs influence architecture.

3. Compare perimeter-based security with Zero Trust architecture.

4. Discuss the benefits and limitations of segmentation and microsegmentation.

5. Explain how governance, privacy, and regulatory requirements affect security architecture.

Analytical / Application Questions

1. Design a layered security architecture for a cloud-hosted application containing public, internal, and confidential functions. Justify the identity, segmentation, monitoring, and recovery controls selected.

2. A hospital cannot tolerate complete loss of access when its identity provider fails. Analyze how fail-safe principles, break-glass access, availability, and auditability should be balanced.

3. Using the university research-network case, identify the most important attack path and propose metrics that would demonstrate whether the redesigned architecture is effective.

Multiple Choice Questions with Answers

Question 1

Which principle limits a subject to only the authority required for a specific task?

A. Least privilege

B. Defense in depth

C. Separation of duties

D. Fail-safe default

Correct Answer: A. Least privilege

Question 2

What is the primary purpose of separation of duties?

A. To increase network bandwidth

B. To prevent one actor from controlling a sensitive process alone

C. To encrypt all stored data

D. To eliminate the need for monitoring

Correct Answer: B. To prevent one actor from controlling a sensitive process alone

Question 3

An RPO of 15 minutes primarily specifies:

A. The maximum time to restore service

B. The maximum acceptable age of recovered data

C. The maximum number of administrators

D. The maximum time for authentication

Correct Answer: B. The maximum acceptable age of recovered data

Question 4

Which activity is most directly associated with identifying trust boundaries?

A. Drawing data-flow diagrams

B. Increasing password length only

C. Purchasing additional storage

D. Removing audit logs

Correct Answer: A. Drawing data-flow diagrams

Question 5

Which statement best describes Zero Trust?

A. All internal users are trusted automatically

B. Trust is granted permanently after first authentication

C. Access is explicitly evaluated using identity, context, and resource policy

D. Network firewalls are unnecessary in every implementation

Correct Answer: C. Access is explicitly evaluated using identity, context, and resource policy

Question 6

Which is an example of a detective control?

A. Multifactor authentication

B. Network segmentation

C. Centralized analysis of security logs

D. Secure configuration baseline

Correct Answer: C. Centralized analysis of security logs

Question 7

Why should backup administration be isolated from ordinary production administration?

A. To increase the number of shared credentials

B. To reduce the chance that a production compromise can destroy recovery resources

C. To make backups accessible to every user

D. To eliminate recovery testing

Correct Answer: B. To reduce the chance that a production compromise can destroy recovery resources

Question 8

A system that denies access when its authorization service is unavailable is applying which principle?

A. Fail-safe default

B. Open design

C. Least functionality only

D. Separation of duties

Correct Answer: A. Fail-safe default

Question 9

Which statement about residual risk is most accurate?

A. It is always zero after controls are implemented

B. It is the risk remaining after controls and their limitations are considered

C. It is identical to the purchase price of controls

D. It applies only to physical security

Correct Answer: B. It is the risk remaining after controls and their limitations are considered

Question 10

Which control most directly limits lateral movement between application and database tiers?

A. Publicly exposing the database

B. Broad internal routing

C. Explicit segmentation and application-level authorization

D. Removing database audit logs

Correct Answer: C. Explicit segmentation and application-level authorization