Infrastructure and Network Architecture
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
In physical architecture, the transition from heavy load-bearing stone walls to steel frames fundamentally changed how we construct skyscrapers. In digital architecture, the shift from monolithic bare-metal servers and rigid network perimeters to abstracted workloads and dynamic routing represents an equally profound revolution. For a Security Operations Center (SOC) analyst, this evolution alters the very physics of incident response. You are no longer defending a static castle wall; you are policing a decentralized, highly ephemeral metropolis. Understanding the precise distinction between virtual machines, containers, and serverless architectures—and navigating modern networks defined by Zero Trust, Secure Access Service Edge (SASE), and Software-Defined Networking (SDN)—is the difference between rapidly containing a threat and watching helplessly as an alert fires for an IP address that no longer exists.
To understand how to investigate a workload compromise, you must first understand how modern workloads are packaged, isolated, and executed. The progression from physical hardware to serverless functions is fundamentally an exercise in stripping away layers of administrative overhead, which inversely changes the nature of telemetry available to security teams.
Virtualization: The Foundational Abstraction
Virtualization abstracts physical hardware resources to allow multiple operating systems to run concurrently on a single physical host machine. By inserting a layer between the hardware and the operating system, a single robust physical server is carved into multiple distinct Virtual Machines (VMs), each running its own complete guest operating system.
The engine powering this abstraction is the hypervisor.
- A Type 1 hypervisor runs directly on the bare-metal hardware of a host machine to manage guest operating systems. Think of solutions like VMware ESXi or Microsoft Hyper-V. Because there is no intermediary operating system, Type 1 hypervisors are highly performant and secure.
- A Type 2 hypervisor runs as an application within a conventional host operating system (like Oracle VirtualBox running on your Windows laptop). It is convenient for local development but rarely used for enterprise production workloads.
The Analyst's Reality: While VMs provide strong isolation, they are not impenetrable. The nightmare scenario for an incident responder is a virtual machine escape—an exploit where an attacker runs code on a virtual machine that interacts directly with the underlying hypervisor. If a threat actor achieves hypervisor-level access, they effectively own every other VM on that physical host, bypassing all internal network controls.
Containerization: Shared Kernels and Ephemeral Threats
Virtual machines are resource-heavy because each requires a full OS boot sequence. Containerization solves this by packaging an application and its dependencies together to share the underlying host operating system kernel. If a VM is a standalone house with its own foundation and plumbing, a container is an apartment in a high-rise; residents have their own private living space, but they all share the building's central foundation and utilities.
How does the Linux kernel keep these "apartments" separate?
- Containers use Linux namespaces to isolate processes from other processes running on the same host system. Namespaces ensure that Container A cannot see the process trees, network interfaces, or mount points of Container B.
- Containers use control groups (cgroups) to limit the resource usage of an individual process or set of processes. This prevents a compromised container from initiating a denial-of-service attack by consuming all the host's CPU or RAM.
For an attacker, the goal is often a container breakout, which occurs when a process escapes the container runtime environment to access the host operating system. Because the kernel is shared, a kernel vulnerability is highly prized by attackers looking to pivot from a single compromised web container to the underlying host.
At scale, managing thousands of ephemeral containers requires an automated traffic cop. Container orchestration platforms automate the deployment, scaling, and management of containerized applications across clusters of hosts. The undisputed industry standard is Kubernetes, an open-source container orchestration system originally designed by Google. When you hunt for threats in modern cloud environments, you are fundamentally querying the Kubernetes API to understand which pods were active at a specific timestamp.
Serverless Computing: The Disappearing Host
If virtualization removes hardware management, and containers remove OS configuration, serverless computing allows developers to build and run applications without managing or provisioning the underlying servers at all.
The most common execution of this is Function as a Service (FaaS), a serverless model where applications are broken down into individual functions that execute in response to specific triggers or events (such as a file being uploaded to a storage bucket or an HTTP request).
The shared responsibility model shifts dramatically here. In a serverless architecture, the cloud service provider assumes complete responsibility for operating system patching and server maintenance.
The Analyst's Reality: This shift radically alters security operations. You cannot deploy an Endpoint Detection and Response (EDR) agent on a serverless function, nor can you SSH into a server to run forensics. Therefore, security monitoring for serverless applications relies heavily on analyzing application execution logs and API gateway metrics rather than traditional host-based agent logs. Your threat hunting shifts from identifying malformed processes on a host to identifying anomalous execution durations, unusual API calls, and logic abuse in CloudWatch or CloudTrail.
Comparing Infrastructure Architectures
| Characteristic | Virtual Machines | Containers | Serverless (FaaS) |
|---|---|---|---|
| Isolation Mechanism | Hypervisor (Hardware-level abstraction) | Namespaces & Cgroups (OS-level abstraction) | Cloud Provider Multi-tenancy |
| OS Management | You manage Guest OS patching | You manage Container Image vulnerabilities | Provider manages OS patching |
| Execution Time | Persistent (Months/Years) | Ephemeral (Minutes/Days) | Triggered (Milliseconds/Seconds) |
| Primary SOC Concern | VM Escape, Lateral Movement | Container Breakout, Malicious Images | Logic Flaws, Identity/Role Abuse, API Abuse |
For decades, network security relied on a simple premise: a hard outer perimeter and a soft, trusted interior. If you were plugged into the office wall or connected to the corporate VPN, you were trusted. In a world of remote work, BYOD, and distributed cloud workloads, the perimeter has dissolved. The network architecture must evolve accordingly.
Zero Trust Architecture
The core principle of Zero Trust architecture is precisely what it sounds like: "never trust, always verify". It entirely abandons the concept of implicit trust based on network location. Instead, a Zero Trust architecture assumes that threat actors are already present within the enterprise network perimeter.
Because you cannot trust the network, a Zero Trust architecture requires continuous authentication and authorization for every user and device access request, regardless of where the request originates.
This continuous verification is orchestrated through two critical components:
- The Policy Decision Point (PDP): The "brain" of the operation. It evaluates access requests against organizational security policies and context (e.g., user identity, device health, time of day, geolocation).
- The Policy Enforcement Point (PEP): The "brawn." It actively grants or denies access based on instructions from the Policy Decision Point. This might be an identity-aware proxy or a next-generation firewall.
To help organizations operationalize this philosophy, the Cybersecurity and Infrastructure Security Agency (CISA) publishes the Zero Trust Maturity Model to guide organizations in implementing zero trust architectures. To ensure a holistic approach, the CISA Zero Trust Maturity Model defines five foundational pillars: Identity, Devices, Networks, Applications and Workloads, and Data.
At the network layer, Zero Trust relies heavily on micro-segmentation, a strategy that divides a network into highly granular security zones to restrict lateral movement by an attacker. Instead of a flat network where an infected workstation can freely scan a database server, micro-segmentation uses software-based firewalls to isolate workloads down to the individual VM or container level.
Secure Access Service Edge (SASE)
If Zero Trust is the philosophy of modern security, SASE is how we physically route remote users through it. Secure Access Service Edge (SASE) combines software-defined wide area networking (SD-WAN) capabilities with cloud-native security functions.
Instead of backhauling remote worker traffic through a centralized corporate data center to inspect it (which causes immense latency), SASE architectures deliver security controls directly to the user or device edge regardless of physical location. The enforcement nodes are distributed globally in the cloud.
When analyzing SASE deployments, integrations typically include Zero Trust Network Access (ZTNA), Cloud Access Security Brokers (CASB), and Firewall as a Service (FWaaS).
The Analyst's Reality: Historically, tracking a compromised employee who was moving between a home network, a coffee shop, and a corporate office meant piecing together fragmented logs from local firewalls, VPN concentrators, and cloud proxies. Secure Access Service Edge platforms provide unified logging for remote workers to assist incident responders in tracking distributed threats. A single dashboard reveals every web request, cloud application login, and file download the user initiated, regardless of where they were physically sitting.
Beneath these evolving security frameworks, the fundamental way network switches move packets has also been re-engineered.
Historically, a physical network router was a monolithic box. It maintained its own routing tables (deciding where traffic should go) and its own switching fabric (physically pushing the data). Software-Defined Networking (SDN) shatters this monolith. SDN separates the network control plane from the network data plane.
- The control plane in a Software-Defined Network makes logical routing decisions and manages overall network policies. It is the centralized "brain."
- The data plane in a Software-Defined Network physically forwards network traffic based on rules defined by the control plane. It is the "muscle."
Because the brain is decoupled from the muscle, network engineers use a Software-Defined Networking controller, which provides a centralized administrative view of the entire network architecture.
The Nervous System: APIs
To function, the SDN controller must communicate upward to administrators and downward to the network hardware. It does this via Application Programming Interfaces:
- Northbound APIs in Software-Defined Networking facilitate communication between the centralized controller and higher-level network applications (such as a load balancer, a firewall manager, or an automated orchestration script).
- Southbound APIs in Software-Defined Networking allow the centralized controller to communicate with and configure physical or virtual network switches. OpenFlow is a classic example of a southbound protocol.
The Analyst's Reality: SDN is not just a tool for network engineers optimizing bandwidth; it is a profound weapon for the SOC. In a legacy network, quarantining a host meant manually logging into a specific switch port and shutting it down, or writing an ACL on a firewall and waiting for replication. Today, incident responders can use Software-Defined Networking controllers to dynamically quarantine infected hosts by pushing new isolation flow rules to network switches at machine speed. If your EDR detects ransomware, a playbook can automatically call the SDN controller's Northbound API, instructing it to push new rules down the Southbound APIs to the Data Plane, instantaneously dropping all packets from the infected machine before the ransomware can encrypt network shares.