Cloud-Native and Software-Defined Network Security

Introduction and Context

Cloud computing and software-defined infrastructure have changed network security from a primarily perimeter-based discipline into a distributed control problem. In a traditional enterprise, security boundaries were commonly represented by a corporate data centre, a firewall, and a relatively stable set of internal networks. In cloud-native environments, applications are decomposed into services, workloads are created and destroyed automatically, traffic may remain inside a cloud provider’s virtual network, and users, devices, APIs, workloads, and automated pipelines all become security-relevant identities.

This transformation creates substantial benefits: elastic capacity, rapid deployment, programmable infrastructure, global reach, and efficient use of resources. It also changes the location of risk. Misconfigured identity policies, exposed storage, insecure container images, vulnerable dependencies, weak Kubernetes controls, unprotected east-west traffic, and excessive trust between services can be more consequential than a single perimeter firewall rule.

Cloud-native security therefore requires coordinated controls across governance, identity, infrastructure, applications, workloads, networks, data, observability, and incident response. The central principle is that security must be continuous, policy-driven, and integrated with the software delivery lifecycle.

Learning Objectives

After completing this chapter, a student should be able to:

1. Explain shared responsibility in public, private, and hybrid cloud environments.

2. Analyse security risks in virtual networks, containers, Kubernetes, SDN, NFV, and service meshes.

3. Design controls using zero-trust, defence-in-depth, microsegmentation, and policy-as-code principles.

4. Evaluate DevSecOps, SASE, and secure access service architectures.

5. Analyse a cloud-native security incident and recommend technically and organisationally appropriate controls.

6. Critically assess governance, privacy, regulatory, operational, and ethical implications.

1. The Cloud-Native Security Model

Cloud-native systems generally use elastic infrastructure, declarative configuration, APIs, containers, orchestration, microservices, managed services, and automated deployment pipelines. Their security model has five important characteristics.

Identity-centric control. Access decisions increasingly depend on authenticated identities and attributes rather than network location. Relevant identities include human users, service accounts, workloads, devices, CI/CD pipelines, and cloud roles.

Distributed enforcement. Security controls may be implemented at an API gateway, identity provider, cloud network, host, container runtime, service mesh proxy, application, and database. No single device provides complete protection.

Ephemeral assets. A workload may exist for minutes or hours. Security must therefore attach to machine-readable attributes, images, identities, and policies rather than manually maintained IP address lists.

Automation. Infrastructure is commonly created through infrastructure-as-code. The same automation that rapidly creates secure environments can also reproduce a dangerous configuration at scale.

Observable behaviour. Security teams must correlate identity, network flow, API, workload, and application events. Static configuration review alone is insufficient.

A useful analytical distinction is between the control plane and the data plane. The control plane makes decisions about configuration, identity, routing, policy, and orchestration. The data plane forwards packets, executes workloads, or enforces decisions on live traffic. Compromise of the control plane can have an extensive blast radius because an attacker may alter many data-plane components at once.

2. Shared Responsibility and Cloud Deployment Models

2.1 Shared responsibility

Shared responsibility does not mean that provider and customer responsibilities are always equal. The provider is generally responsible for security of the cloud: physical facilities, foundational hardware, and core managed services. The customer is responsible for security in the cloud: identities, data, configurations, applications, and often operating systems and network controls.

Responsibility varies by service model:

• In infrastructure as a service (IaaS), the customer commonly manages guest operating systems, applications, virtual networks, identities, and data.
• In platform as a service (PaaS), the provider manages more of the operating environment, while the customer remains responsible for application code, data, identities, and configuration.
• In software as a service (SaaS), the provider manages the application platform, but the customer remains responsible for accounts, authorisation, data governance, configuration, and appropriate use.

The exact boundary must be verified in provider documentation and contracts. A provider may secure a managed database engine while the customer can still expose the database publicly, permit excessive access, or store unencrypted sensitive information.

2.2 Public, private, and hybrid cloud

A public cloud provides shared physical infrastructure through logically isolated tenants. Its advantages include elasticity and managed security capabilities. Risks include misconfiguration, insecure credentials, provider dependency, multi-tenant concerns, and loss of visibility into underlying infrastructure.

A private cloud is dedicated to one organisation, whether operated internally or by a service provider. It may provide greater control and customisation, but it does not automatically provide better security. The organisation must usually operate more of the infrastructure, including patching, monitoring, availability, and hardware or virtualisation security.

A hybrid cloud connects private and public environments. It can support regulatory separation, gradual migration, and burst capacity. However, identity federation, routing, DNS, cryptographic key management, logging, and incident response become cross-environment dependencies. A weak connection or inconsistent policy can undermine both environments.

2.3 Responsibility allocation

A practical responsibility matrix should assign each control to an accountable party, identify evidence, and specify a verification frequency. Typical domains include:

• physical and environmental security;
• hypervisor and host security;
• virtual network configuration;
• identity lifecycle and privileged access;
• operating-system and image patching;
• application security;
• data classification, encryption, retention, and deletion;
• logging, detection, and incident response;
• resilience, backup, and disaster recovery.

Responsibility must be accompanied by capability. If a business unit is accountable for cloud logging but has no access to logs or no budget for analysis, the allocation is not operationally meaningful.

3. Virtual Networks and Cloud Network Security

Cloud virtual networks provide logical isolation over shared infrastructure. Common components include virtual networks or virtual private clouds, subnets, route tables, security groups, network access control lists, gateways, load balancers, private endpoints, DNS services, and network inspection appliances.

3.1 Security groups and network policies

Stateful security groups generally control traffic associated with virtual interfaces or instances, while stateless access control lists may filter traffic at subnet boundaries. Rules should be based on explicit business flows, use least privilege, and avoid broad sources such as the entire internet or an unrestricted internal network.

Network segmentation should reflect trust and function rather than merely organisational charts. For example, an internet-facing load balancer, application services, administrative systems, and data stores should not share unrestricted connectivity. Segmentation reduces lateral movement and limits the effect of a compromised workload.

3.2 East-west traffic

North-south traffic crosses the boundary between an environment and external networks. East-west traffic flows between internal workloads. Microservices generate substantial east-west traffic, often using APIs that may contain sensitive data. A perimeter firewall cannot adequately protect such flows if internal services are mutually trusted.

Controls include workload identity, service-to-service authorisation, network policies, mutual TLS, application-layer validation, runtime detection, and explicit egress controls. Egress filtering is particularly important because it can restrict command-and-control communication and unauthorised data transfer.

3.3 DNS and metadata services

Cloud DNS is part of the security boundary. Compromise or manipulation of DNS can redirect traffic, defeat service discovery, or enable credential theft. Workloads may also access instance metadata services that expose temporary credentials or configuration. Metadata access should be restricted, hardened according to provider guidance, and monitored.

3.4 Encryption and key management

Encryption in transit protects communication from interception, but it does not establish authorisation by itself. Encryption at rest protects stored data, but access control and key governance remain necessary. Key management should address separation of duties, rotation, backup, revocation, access logging, geographic requirements, and recovery from key loss.

4. Containers and Kubernetes Security

A container packages an application and its dependencies while sharing the host operating system kernel. Containers are not equivalent to virtual machines: isolation depends on kernel mechanisms, runtime configuration, namespaces, capabilities, file-system controls, and orchestration policy.

4.1 Container image security

Image risks include vulnerable packages, malicious or untrusted base images, embedded secrets, excessive privileges, and unverified provenance. Secure image management includes:

1. selecting trusted minimal base images;

2. pinning versions and recording software bills of materials;

3. scanning operating-system packages and application dependencies;

4. signing images and verifying signatures at deployment;

5. removing build tools, shells, and unnecessary files;

6. rebuilding images when vulnerabilities or base-image changes require it.

Scanning is not a complete security decision. A scanner may report vulnerabilities that are not reachable or may miss configuration, business-logic, and runtime risks. Risk-based triage should consider exploitability, exposure, privilege, compensating controls, and data sensitivity.

4.2 Kubernetes architecture and threats

Kubernetes includes an API server, control-plane components, scheduler, controllers, worker nodes, container runtimes, and an etcd data store. The API server is a high-value control-plane interface. Threats include stolen service-account tokens, excessive role-based access control, exposed dashboards, insecure admission policies, compromised images, vulnerable nodes, malicious workloads, and unauthorised access to secrets.

Important controls include:

• strong authentication and role-based access control;
• separate administrative and workload identities;
• least-privilege service accounts;
• encryption and access control for etcd;
• network policies that deny unnecessary traffic by default;
• admission controls for image provenance, privileges, namespaces, and resource limits;
• restricted host networking, host PID, host file-system mounts, and Linux capabilities;
• node hardening, rapid patching, and workload isolation;
• audit logging and centralised monitoring;
• resource quotas and limits to reduce denial-of-service risk.

Kubernetes Secrets are intended for sensitive configuration but should not be assumed to be safe merely because they are called secrets. Their protection depends on encryption, access control, API exposure, backup handling, and whether applications print them into logs.

5. Software-Defined Networking and Network Functions Virtualisation

Software-defined networking (SDN) separates or logically distinguishes network control from packet forwarding. A controller uses programmable interfaces to install forwarding or security policy in switches, virtual switches, or other enforcement points. SDN improves automation and visibility, but the controller and its interfaces become high-value assets.

SDN threats include controller compromise, unauthorised API access, malicious or incorrect policy updates, denial of service against control channels, insecure switch-controller communication, and inconsistent policy propagation. Controls include mutual authentication, authorisation, signed or validated policy changes, controller redundancy, segmentation of management networks, secure APIs, change approval for high-risk actions, and independent verification of effective forwarding state.

Network functions virtualisation (NFV) implements functions such as firewalls, routers, and intrusion prevention systems as software on virtualised infrastructure. NFV can reduce hardware dependency and support rapid scaling, but it introduces risks involving hypervisors, virtual network functions, orchestration systems, images, interfaces, and service chaining. Security must cover the management and orchestration layer as well as the virtual network functions themselves.

A key limitation of programmable networking is policy complexity. A rule may be syntactically valid but semantically unsafe because of ordering, shadowing, overlapping address groups, or interaction between multiple controllers. Policy analysis and automated testing are therefore essential.

6. Service Meshes and Workload Identity

A service mesh provides a dedicated communication layer for service-to-service traffic, commonly using sidecar or node-level proxies. It may provide mutual TLS, service discovery, traffic routing, retries, telemetry, and authorisation policies.

Mutual TLS authenticates communicating workloads and encrypts traffic. However, it does not automatically authorise every action. A service may be authenticated correctly and still be permitted to invoke an inappropriate endpoint. Effective policy should consider workload identity, namespace, service, operation, data classification, and environmental context.

Service meshes introduce operational complexity. Certificate issuance and rotation, proxy upgrades, policy propagation, failure behaviour, and performance overhead must be managed. A mesh can also create a false sense of security if applications accept unauthenticated traffic locally, expose debugging interfaces, or fail to validate input.

7. Zero Trust, DevSecOps, and Policy-as-Code

Zero trust is a security approach in which no user, device, workload, or network location is inherently trusted. Access is continuously evaluated using identity, device posture, workload attributes, resource sensitivity, requested action, and contextual risk. Zero trust is not identical to removing a perimeter, nor does it require that every packet be individually inspected. It requires explicit, least-privilege, evidence-based decisions.

DevSecOps integrates security into planning, coding, building, testing, deployment, and operations. Typical practices include threat modelling, secure coding, dependency analysis, secrets detection, static and dynamic application testing, infrastructure-as-code scanning, image verification, deployment policy checks, runtime monitoring, and incident feedback into development.

Security automation must be designed carefully. A pipeline with permission to alter production infrastructure represents a privileged identity. Controls should include short-lived credentials, protected branches, signed commits or builds where appropriate, separation of duties, approval for sensitive changes, isolated build environments, and detailed audit logs.

Policy-as-code expresses controls in machine-readable form so they can be tested and enforced consistently. Examples include prohibiting public storage, requiring encryption, restricting privileged containers, requiring approved regions, and denying overly broad network rules. Policy-as-code improves repeatability but may encode incorrect assumptions. Policies require ownership, testing, exception management, version control, and periodic review.

8. SASE and Secure Access Service Architectures

Secure Access Service Edge (SASE) is an architectural approach that converges networking and security capabilities, commonly including software-defined wide-area networking, secure web gateways, cloud access security brokers, zero-trust network access, firewall-as-a-service, and central policy management. The goal is to provide secure access based on identity and context near users and resources rather than forcing all traffic through a central enterprise location.

SASE can improve support for remote work, distributed applications, and internet-based access. It may reduce appliance dependency and provide consistent policy across locations. Its risks include provider concentration, outages, policy misconfiguration, inspection of sensitive traffic, data residency concerns, complex licensing, and dependence on identity and endpoint signals.

A secure access service architecture should define:

• which users, devices, workloads, and applications are covered;
• how identity is federated and revoked;
• what traffic is inspected and under which legal basis;
• how exceptions and offline operation are handled;
• where logs and decrypted content are stored;
• how provider failure, lock-in, and migration are addressed.

SASE is not a product category that removes the need for secure applications, endpoint protection, data governance, or incident response.

9. Governance, Privacy, and Regulatory Considerations

Cloud-native security involves governance decisions as well as technical controls. Organisations should classify information, define retention periods, document processing purposes, control cross-border transfers, and establish responsibilities for data subjects’ rights where applicable. Regulations may require breach notification, resilience, access logging, segregation, or protection of critical services.

Privacy and security can conflict if extensive telemetry collects more personal information than necessary. Security monitoring should follow purpose limitation, access restriction, retention control, and proportionality. De-identification or pseudonymisation may reduce exposure, but these techniques do not eliminate all re-identification risks.

Ethical questions arise when organisations use automated risk scoring, behavioural analytics, or AI-based detection. Models may produce false positives, discriminate against groups, or make decisions that cannot be explained to affected users. Human review, documented model limitations, protected data handling, testing for bias, and appeal processes are appropriate safeguards.

Third-party risk management should examine provider architecture, subcontractors, software supply chains, breach notification, audit evidence, resilience, exit provisions, and the customer’s ability to retrieve data and logs. Compliance certification is useful evidence but is not a substitute for understanding the actual control environment.

10. Measuring Cloud-Native Security

Security measurement should combine preventive, detective, responsive, and business-oriented indicators. Examples include the proportion of privileged identities using phishing-resistant authentication, percentage of production images with verified provenance, time to remediate exploitable vulnerabilities, coverage of effective network policies, mean time to detect and contain incidents, and percentage of critical assets with tested recovery procedures.

Metrics require definitions and denominators. For example, “90% of workloads monitored” is ambiguous unless the organisation defines workload population, monitoring meaning, and measurement date. Metrics should not reward superficial compliance. A high patching percentage is weak evidence if critical internet-facing systems are excluded.

Useful assurance activities include configuration assessment, threat modelling, penetration testing within authorised scope, attack-path analysis, tabletop exercises, disaster recovery tests, policy simulation, and independent review of provider evidence. Testing should examine failure modes, such as loss of an identity provider, compromise of a CI/CD account, accidental public exposure, or control-plane unavailability.

11. Illustrative Case: Hybrid Retail Platform

Background

A fictional retailer operates customer-facing web services in a public cloud and keeps selected payment and analytics systems in a private cloud. Kubernetes hosts the online platform. A service mesh provides mutual TLS, and a SASE service connects remote employees. Infrastructure is deployed through a central CI/CD pipeline.

Problem

An attacker obtains a developer token through a phishing attack. The token has excessive permission to modify a deployment repository and read a cloud secret store. The attacker deploys a modified image, establishes outbound communication from a container, and attempts to reach an analytics database through east-west traffic.

Analysis

The incident is not solely a container vulnerability. It involves identity governance, CI/CD privilege, image provenance, secret access, network segmentation, egress control, and monitoring. Mutual TLS does not prevent the attack because the malicious workload receives a valid service identity. The service mesh authenticates the workload but an overly broad authorisation policy permits access to the analytics service.

Approach and solution

The retailer takes the following actions:

1. Revokes the compromised token and rotates affected credentials.

2. Suspends the deployment pipeline and preserves logs, image layers, and audit records.

3. Uses image signatures and admission controls to prevent unsigned images.

4. Reduces the pipeline role to narrowly defined deployment actions.

5. Separates build, staging, and production identities.

6. Applies deny-by-default network policies and restricts egress to approved destinations.

7. Revises service-mesh authorisation to permit only specific operations between named services.

8. Protects secrets with stronger access controls and removes secrets from build logs.

9. Conducts a compromise assessment of nodes, repositories, service accounts, and databases.

10. Performs a tabletop exercise and updates recovery procedures.

Outcome

The retailer cannot assume that no data was accessed merely because database authentication failed. It must establish evidence from API logs, network flows, database audit records, workload telemetry, and endpoint or node investigation. The long-term outcome is a layered architecture in which a stolen developer credential does not directly permit arbitrary production deployment or broad east-west access.

Learning points

The case demonstrates that cloud-native security is an interdependent system. Identity, software supply chain, network policy, workload protection, and observability must reinforce one another. A control can be technically present yet ineffective if its policy is overly broad or its evidence is not monitored.

12. Best Practices and Limitations

A mature programme should begin with asset and data discovery, a documented responsibility matrix, strong identity governance, and secure defaults. It should then implement segmentation, hardened images, controlled orchestration, protected pipelines, centralised logging, tested recovery, and continuous validation.

Organisations should avoid several common errors: assuming the provider secures customer configuration; treating compliance as complete security; deploying a service mesh without policy ownership; relying on vulnerability counts without exploitability analysis; granting permanent administrative access; and assuming encryption solves authorisation problems.

Cloud-native controls have limitations. Automation can propagate mistakes quickly. Microsegmentation can become unmanageable without service ownership and dependency mapping. Security inspection can affect latency and privacy. Centralised cloud security services may create concentration risk. Detection systems produce false positives and require skilled analysis. Finally, technical controls cannot compensate for unclear accountability, insufficient investment, or poor incident decision-making.

Contemporary Developments

Current practice increasingly includes confidential computing, software bills of materials, signed build provenance, identity-aware proxying, eBPF-based observability, workload attestation, automated attack-path analysis, and AI-assisted security operations. These technologies are promising but should be assessed through evidence rather than marketing claims.

AI can assist with alert triage, policy explanation, anomaly detection, code review, and incident summarisation. It can also generate insecure code, expose confidential prompts or logs, amplify false positives, and be manipulated by adversarial input. Human accountability, secure data handling, model evaluation, and approval gates remain necessary.

Chapter Summary

Cloud-native and software-defined environments distribute security across identities, APIs, virtual networks, hosts, workloads, orchestration platforms, applications, and data. Shared responsibility requires explicit allocation of controls and verification of provider and customer obligations. Public, private, and hybrid clouds each present different control and dependency patterns.

Virtual network security requires segmentation, least-privilege rules, east-west protection, egress control, secure DNS, and careful key management. Container and Kubernetes security depends on trusted images, provenance, admission control, RBAC, node hardening, network policies, secret protection, and auditability. SDN and NFV improve programmability but make controllers, orchestration systems, and policy interfaces high-value targets. Service meshes provide encrypted, identity-aware communication but do not replace application authorisation.

Zero trust, DevSecOps, and policy-as-code integrate security into identity and delivery processes. SASE supports distributed access but introduces provider, privacy, availability, and governance concerns. Effective programmes combine preventive controls with detection, response, recovery, measurement, and ethical oversight. The central professional lesson is that security must be designed as a continuously verified system rather than added as a perimeter device or isolated tool.

Key Terms

Shared responsibility: Allocation of cloud security duties between provider and customer.

IaaS: Cloud service model in which customers manage substantial virtual infrastructure and operating-system responsibilities.

PaaS: Cloud service model in which the provider manages more of the platform runtime.

SaaS: Provider-managed application service accessed by customers.

Virtual network: Logically isolated network implemented over shared infrastructure.

Microsegmentation: Fine-grained separation of workloads or services using identity, policy, or network attributes.

East-west traffic: Communication between internal workloads or services.

Control plane: Components that make configuration, routing, identity, or policy decisions.

Data plane: Components that forward traffic or execute workload operations.

Container: Isolated application process sharing an operating-system kernel.

Kubernetes: Platform for orchestrating containerised workloads.

Admission control: Policy enforcement applied before a workload or configuration is accepted.

Software-defined networking: Programmable networking that separates or logically distinguishes control and forwarding functions.

Network functions virtualisation: Implementation of network functions as software on virtualised infrastructure.

Service mesh: Infrastructure layer that manages service-to-service communication.

Mutual TLS: Protocol arrangement in which both communicating parties authenticate using certificates.

Zero trust: Security approach based on explicit, continuously evaluated, least-privilege access.

DevSecOps: Integration of security practices throughout software development and operations.

SASE: Architecture combining network connectivity and cloud-delivered security services.

Policy-as-code: Machine-readable policy that can be versioned, tested, and automatically enforced.

Review Questions

Short Answer Questions

1. What is meant by shared responsibility in cloud security?

2. Distinguish north-south from east-west traffic.

3. Why is a container not equivalent to a virtual machine?

4. What security function does mutual TLS provide in a service mesh?

5. Define policy-as-code.

Long Answer Questions

1. Compare the security responsibilities and risks of IaaS, PaaS, and SaaS.

2. Explain a comprehensive Kubernetes security architecture.

3. Analyse the security advantages and limitations of SDN and NFV.

4. Discuss how DevSecOps and zero trust reinforce one another.

5. Evaluate SASE as an architecture for a globally distributed organisation.

Analytical / Application Questions

1. A cloud application has strong perimeter controls but unrestricted communication among internal services. Analyse the likely attack paths and propose a microsegmentation design.

2. A CI/CD pipeline can deploy any image to production using a permanent administrative credential. Design a safer identity, provenance, approval, and monitoring model.

3. A hybrid-cloud organisation must process regulated data while supporting remote employees. Recommend a secure access architecture and identify its principal governance and privacy risks.

Multiple Choice Questions with Answers

Question 1

Which statement best describes cloud shared responsibility?

A. The provider is always responsible for all customer data and configurations.

B. The customer is always responsible for physical data-centre security.

C. Responsibilities vary by service model, with customers retaining important duties such as identity and configuration management.

D. Shared responsibility means provider and customer must perform identical security tasks.

Correct Answer: C. Responsibilities vary by service model, with customers retaining important duties such as identity and configuration management.

Question 2

Which control most directly reduces unnecessary east-west movement between microservices?

A. A larger internet-facing firewall

B. Default-deny workload network policies

C. Longer password-expiration intervals

D. Public DNS registration

Correct Answer: B. Default-deny workload network policies

Question 3

Why does a service mesh’s mutual TLS capability not by itself provide complete authorisation?

A. It cannot encrypt traffic.

B. It authenticates communicating parties but does not necessarily restrict permitted operations.

C. It works only for north-south traffic.

D. It disables workload identities.

Correct Answer: B. It authenticates communicating parties but does not necessarily restrict permitted operations.

Question 4

Which Kubernetes control helps prevent deployment of unsigned or privileged workloads?

A. Admission control

B. Public DNS

C. A subnet route table alone

D. A data-retention schedule

Correct Answer: A. Admission control

Question 5

Which asset is especially high impact if compromised in an SDN architecture?

A. A user’s screen brightness setting

B. The central controller and its policy APIs

C. An archived paper document

D. A disconnected printer

Correct Answer: B. The central controller and its policy APIs

Question 6

What is a principal purpose of image signing and verification?

A. To guarantee that application code has no vulnerabilities

B. To establish provenance and prevent deployment of unauthorised images

C. To replace runtime monitoring

D. To eliminate the need for access control

Correct Answer: B. To establish provenance and prevent deployment of unauthorised images

Question 7

Which statement best characterises zero trust?

A. All internal network traffic is trusted after login.

B. Access is explicitly and continually evaluated using identity and context.

C. Only physical network segmentation is required.

D. Users do not need authentication if devices are corporate-owned.

Correct Answer: B. Access is explicitly and continually evaluated using identity and context.

Question 8

Which practice is most consistent with secure CI/CD design?

A. Permanent production administrator credentials in source code

B. Shared accounts without audit logs

C. Short-lived, narrowly scoped deployment identities

D. Unreviewed deployment of every developer build

Correct Answer: C. Short-lived, narrowly scoped deployment identities

Question 9

Which is a significant governance concern for SASE?

A. It makes provider outages impossible.

B. It removes all privacy considerations from traffic inspection.

C. It may create provider concentration, data-residency, and logging dependencies.

D. It requires every application to run on a single physical server.

Correct Answer: C. It may create provider concentration, data-residency, and logging dependencies.

Question 10

Why should vulnerability counts not be used as the sole basis for cloud risk decisions?

A. All vulnerabilities have exactly the same impact.

B. Scanners never identify vulnerabilities.

C. Risk also depends on exploitability, exposure, privilege, reachability, and compensating controls.

D. Vulnerabilities matter only in private clouds.

Correct Answer: C. Risk also depends on exploitability, exposure, privilege, reachability, and compensating controls.