Breaking Ambient Trust: In-Network Per-Process Access Control Against Lateral Movement

Breaking Ambient Trust: In-Network Per-Process Access Control Against Lateral Movement Osama Bajaber

Bo Ji

Peng Gao

King Abdulaziz University Jeddah, Saudi Arabia obajaber@kau.edu.sa

Virginia Tech Blacksburg, VA, USA boji@vt.edu

Virginia Tech Blacksburg, VA, USA penggao@vt.edu

arXiv:2608.29979v1 [cs.CR] 30 Aug 2026

Abstract Enterprise networks remain vulnerable to Advanced Persistent Threats (APTs), where adversaries gain an initial foothold and move laterally across the network, accumulating access permissions hop by hop to reach critical targets. Existing network defenses cannot track user movement at the process level across the network; instead, they grant ambient trust to all processes within a host. As a result, once a host is compromised, malicious processes inherit the victim’s permissions, thereby expanding the attacker’s access scope and enabling further lateral movement. To address this gap, we present NetZone, an in-network access control that confines each user process to a fixed access scope that persists as the user moves across the network. NetZone introduces a new abstraction, called AccessScope, which represents a lightweight access capability bound to the user’s processes. Each AccessScope encodes the set of hosts a user identity is authorized to access and is embedded in the process’s outgoing network traffic for validation before reaching its destination. As users pivot across hosts, AccessScope propagates with their traffic, rebinds to the receiving process, and persists across hosts. This ensures that regardless of network location, the user’s processes are consistently governed by their bound AccessScope and their access permissions remain unchanged. To handle the high volume of network traffic generated by processes, we develop a data-plane co-design that integrates programmable switches with eBPF. NetZone employs a set of in-network optimizations and lightweight AccessScope persistence techniques to inspect the embedded AccessScope on the fly, enabling line-rate processing of high traffic volumes with negligible latency overhead. Our extensive evaluations show that NetZone can effectively defend against various sophisticated attack scenarios without introducing noticeable overhead.

CCS Concepts • Security and privacy → Network security.

Keywords Network Security, Programmable Switch, eBPF

1

and widespread service disruptions [79]. Despite decades of investments in network access control [51], attackers still succeed as existing network defenses rely on coarse-grained, network-level information (i.e., IP addresses and port numbers) and lack visibility to track user process movement across hosts. As a result, they cannot enforce consistent permissions as users move. Consider a representative scenario in Fig. 1a with two hosts (Alice and Bob) and a sensitive server. A firewall permits only Alice (an administrator) to access the server. Although Alice and Bob can communicate with each other, Bob cannot directly reach the server. However, Bob turns malicious and uses Alice as a stepping stone to reach the server by sending a spear-phishing email that installs a backdoor on her machine. Leveraging this backdoor, Bob establishes a remote session using process P1 and spawns a new process P2 on Alice’s host. Since the firewall enforces only coarse IP- and port-based rules, it cannot distinguish between traffic from Bob’s malicious process P2 and Alice’s process P3, allowing Bob to inherit Alice’s permissions and pivot toward the server. Similar attacks arise through various other techniques (e.g., access token theft [56], session hijacking [58], or exploitation of shared services [57]), emphasizing a broader and pervasive security challenge. This exposes two fundamental weaknesses in current network defenses: (1) the ambient trust implicitly granted to all processes within a host, and (2) the inability to track user identity at the process-level as users move across the network. Defenses like distributed firewalls enforce coarse, IP- and port-based rules rather than the identity of the process initiating the connection. As a result, when an attacker pivots onto a compromised host, all outgoing connections appear to originate from the legitimate user, and malicious processes inherit the same access permissions. Even recent identity-aware solutions [12, 17] that incorporate user roles ultimately translate high-level policies into coarse-grained IP-based rules for enforcement, thereby trusting all processes on a host and failing to track user movement at the process level across hosts. This limitation is critical in data centers and cloud environments, where thousands of processes interact through shared infrastructure, enabling attackers to expand permissions and pivot deeper into the network [44, 52, 70].

Introduction

Modern enterprise networks remain vulnerable to Advanced Persistent Threats (APTs) [36]. These attacks share a common structure: an adversary gains an initial foothold and then moves laterally across hosts, progressively accumulating access permissions beyond their entry point (e.g., a compromised host becomes a stepping stone to internal and privileged systems). It is through this incremental accumulation of permissions that APTs achieve their goals, leading to major data breaches [70], significant financial losses [66],

Goal & challenges. What is needed is a fundamentally different model where access permissions are tied to the user’s identity rather than the host’s network location, and follow the user as they move across the network. Our key insight is twofold: (1) each process should carry distinct access permissions based on the user’s identity; (2) these permissions should persist and propagate with the user as they move across hosts, ensuring that a user maintains consistent access permissions regardless of network location.

Osama Bajaber, Bo Ji, and Peng Gao

To realize this insight, our idea is to bind a lightweight credential object to each user’s processes. This credential specifies which hosts a process is authorized to access and is attached to outgoing network packets for verification at every access attempt. This credential also propagates as the user pivots across hosts and spawns new processes. Through this mechanism, regardless of where the user lands, access decisions are governed by the credential object, strictly limiting the user’s access scope to authorized destinations. As illustrated in Fig. 1b, credential objects encode administratordefined policies that specify each user’s authorized access. Even if Bob successfully compromises Alice’s system, his malicious process P2 carries a restricted credential object that does not permit access to the server. In contrast, Alice’s legitimate process P3 holds a different credential object that authorizes the connection. However, realizing this vision introduces three key challenges. (1) Compact policy representation. Designing a credential object that encodes a user’s permissions across all hosts is non-trivial. The object must remain compact to propagate efficiently while still expressing permissions for potentially thousands of hosts. (2) Cross-host persistent. Permissions must remain bound to each process and propagate as users move across hosts, bridging intra-host activities (i.e., spawning new processes and threads) with inter-host communications (i.e., network connections), ensuring credentials propagate both within and between hosts. (3) Line-rate enforcement at scale. Validating credentials on every access attempt in a high-volume enterprise network must operate in real time without introducing noticeable overhead or degrading benign traffic. Contributions. We introduce NetZone, an in-network access control system that enforces per-user, per-process access scopes across the enterprise network. NetZone builds on capability-based access control [85] and brings this notion of fine-grained, decentralized access control to enterprise networks. Unlike existing capability-based systems [41, 78] that are restricted to a single host, NetZone extends capability enforcement across the network to regulate process access to remote hosts. At the core of NetZone is a new abstraction called the AccessScope object. This object encodes the set of hosts a user identity is authorized to access and is bound to the process identifier (PID). A process must be presented whenever the process attempts to access a remote host. As users spawn new processes or pivot across hosts, their associated AccessScope propagates with them, preserving a consistent access scope throughout the network. This is achieved by embedding the AccessScope associated with the sending process’s PID into outgoing packets, and propagating the corresponding capability to the recipient process. The key advantage of this design is that binding the AccessScope to individual processes eliminates the ambient trust granted to all connections from the same host. Instead, NetZone preserves each user’s access scope as they move across the network, enforcing consistent access permissions regardless of network location. Even if a host is compromised, malicious processes cannot inherit access permissions of legitimate ones and pivot. This decentralized, process-level design confines each user to a specific set of authorized hosts, effectively mitigating stepping-stone attacks. To efficiently enforce AccessScopes carried on network packets and propagate them across hosts, NetZone employs a novel data

plane co-design of programmable switches and eBPF. Programmable switches (e.g., Tofino) offer data plane programmability and guarantee customized Tbps line-rate packet processing. This enables NetZone to create custom packet headers that carry AccessScope objects and inspect them directly in the data plane at line rate. We further developed optimization techniques that enable efficient AccessScope generation, distribution, validation, and enforcement across the network. To bind AccessScopes to processes and propagate them within and between hosts, we developed lightweight kernel programs using eBPF technology. eBPF enables the operating system (OS) kernel to be extended through sandboxed custom programs, without modifying kernel source code or user-level applications. Our lightweight eBPF components efficiently trace process activity, bind processes to their corresponding AccessScopes within hosts, and attach or extract AccessScopes from network packets to ensure seamless propagation. Evaluations. We extensively evaluated NetZone on both a physical testbed with a Tofino programmable switch and on realistic large-scale topologies using packet-level simulations, incorporating both synthetic and real-world workloads. Our results show that: (1) NetZone can prevent a wide range of advanced attacks that evade existing network defenses [7, 12, 17], while adding only a negligible 140 ns latency to enforce AccessScope on the fly. (2) NetZone scales to real-world traces, including DARPA OpTC [76], Yatesbury [32], and LANL Unified Host and Network [74] datasets, achieving 99.9 Gbps throughput on a 100 Gbps (per-port) programmable switch with minimal impact on legitimate traffic. (3) The eBPF programs add only 3-9 𝜇𝑠 to the total time of the monitored kernel events with a small 130 MB memory footprint, imposing negligible performance impact on hosts. (4) To further demonstrate the benefits of our data-plane design, we compare NetZone with centralized identity-based network access control solutions [12, 17]. NetZone enforces policies 27-60x faster while remaining resilient against saturation attacks.

2

Background

Network-access control. Existing network access control solutions can be broadly grouped by the granularity of identity they enforce. However, each group leaves critical gaps that enable attackers to gain additional permissions. Traditional firewalls [7] are widely deployed and offer fast prevention with low compute overhead. However, they enforce lowlevel IP- and port-based rules, with no visibility into the identity of the process behind a connection. Access scopes are therefore tied to network location: any process running on a permitted host implicitly inherits that host’s access permissions. An attacker who lands on a permitted host can freely abuse those inherited permissions to move laterally without triggering a firewall rule. Signature-based firewalls [33, 73, 88] attempt to enrich rules with deep packet inspection (DPI). Yet, much of today’s applicationlayer traffic is encrypted (e.g., HTTPS, TLS), limiting their ability to extract meaningful user identity content. More fundamentally, DPI still treats each host as a single trust unit, leaving ambient trust unaddressed. DPI is also computationally expensive, often requiring dedicated CPU [73, 88] or GPU [33] resources, imposing significant performance overhead on the network.

Breaking Ambient Trust: In-Network Per-Process Access Control Against Lateral Movement

Bob P1

P1

Server

Alice P2 P3

Allow

Bob

Deny

Bob:

= Alice Svr

Alice:

= Bob

Svr

NetZone APIs: 1.allow(uid=Bob, dst=Alice) 2.allow(uid=Alice, dst=Bob) 3.allow(uid=Alice, dst=Svr) # deny all

Server

Alice

Firewall

P4

P2

P5

P3

NetZone Legend: : AccessScope Object

(a) Stepping-stone attacks leverage intermediate hosts to hide the attacker’s origin and reach a final target.

P4

(b) NetZone enforces user-specific access scopes via processlevel AccessScope objects.

Fig. 1: An enterprise network where a firewall blocks Bob from reaching the Server but allows Alice (an administrator) to access it. In (a), Bob cannot directly connect to the Server (dashed gray arrow) but exploits a vulnerability on Alice’s system to spawn a malicious process P2, using it as a stepping stone to bypass the firewall. In (b), NetZone encodes each user’s permissions in AccessScope objects (yellow boxes) that are bound to processes and persist across hosts. NetZone parses AccessScopes within programmable switches and enforces permissions at line rate, regardless of the connection’s origin or the user’s location. A more recent line of work [12, 17, 29] extends software-defined network (SDN) architectures with role- and attribute-based access control. These systems use high-level policies to determine network reachability based on the user’s identity behind each host. While this brings identity into the policy definition, enforcement still ultimately reduces to IP-based rules installed in the data plane. As a result, trust is granted to the host rather than to individual processes, and permissions are enforced at the host level rather than re-evaluated for each process initiating a connection. This means that once a host is compromised, the attacker’s processes appear indistinguishable from the legitimate user’s. Furthermore, these systems mediate every connection through a centralized controller, introducing significant per-connection latency and a single point of failure vulnerable to saturation attacks. To date, no solution fundamentally eliminates ambient trust by enforcing per-user, per-process access scopes that persist as users move laterally across the network. Capability-based systems. Capabilities [85] provide an efficient and secure mechanism for fine-grained resource management and protection. They enable decentralized access control by granting entities a token that defines a set of access permissions. A process can access a resource only by presenting the corresponding capability. This security model limits the resources permitted to each holder and enforces the principle of least privilege [68], ensuring that the holder can access only the resources explicitly authorized. Many recent works have introduced capability-based operating systems [41, 78], which regulate what resources a process can access. However, these systems operate strictly within OS boundaries. Their design focuses primarily on regulating access to local resources (e.g., files, memory locations, and I/O devices) rather than extending protection to accessing network hosts. They also require extensive kernel modifications to implement capability-based access control, which significantly limits their adoption. In contrast, NetZone extends the capability-based model beyond OS boundaries to regulate process-level access to remote hosts, protecting against stepping-stone attacks. Moreover, NetZone does not require any modifications to the OS kernel or running applications

to enforce capabilities. This allows seamless deployment and broad applicability of our defense system. Capabilities have been used for many security purposes, such as in programming languages [18, 54] and providing access confinement in capability-based operating systems [41, 78]. However, these solutions are restricted to a single host. Other efforts have integrated capabilities to regulate access to distributed resources (e.g., IoT [25, 26], and cloud computing [14, 45]). Unlike NetZone, these systems operate at a coarse granularity and assume ambient trust for all processes on the same host. Programmable data planes. Programmable switches have emerged as high-performance, Tbps-rate dataplane targets enabled by languages like P4 [15]. A P4 program defines the packet headers and protocols to be supported, along with a programmable parser that extracts these headers from incoming packets. The extracted headers are represented as a packet header vector (PHV) and processed through a pipeline of hardware stages, each performing match/action operations. Within each stage, match/action tables use keys (e.g., header fields) to look up entries and execute corresponding actions such as arithmetic, bitwise, or metadata updates. Arithmetic Logic Units (ALUs) in these stages perform simple computations, while the programmable deparser later reconstructs the packet before forwarding it to the next hop. However, these memory resources are limited, typically on the order of O(100)MB for SRAM and O(10)MB for TCAM. These constraints fundamentally restrict what can be processed at line rate, posing a significant challenge in designing efficient and scalable data-plane solutions.

3

System Overview

One key challenge is keeping AccessScopes lightweight to be efficiently carried with user traffic and processed within programmable switches. A naive approach would be to generate a single AccessScope per user. However, a single AccessScope may need to encode permissions for thousands of hosts, making it too large. Instead, NetZone partitions AccessScope into smaller, per-subnet AccessScopes, with each representing the user’s permissions within

Osama Bajaber, Bo Ji, and Peng Gao

B Distribute AccessScope

A High-Level Policies

Packets

Generate

Control Plane D AccessScope Persistent

.. .

.. .

C

Tagging Switch

In-Flight AccessScope Storage

Enforcement Switch

F AccessScope

P1

Enforcement

Bob

Private Subnet

P2 Alice

E P3

Public Subnet

On-the-Fly AccessScope Replacement

P4

Fig. 2: NetZone system workflow.

a specific network subnet. This design aligns naturally with enterprise network structure, where subnets (e.g., VLANs and ToR domains) partition large networks into smaller domains for easier management [53]. A user carries only the AccessScope corresponding to their current subnet. When the user moves to a new subnet, NetZone automatically replaces the current AccessScope with the corresponding one for the destination subnet. Even with compact AccessScopes, efficient in-network enforcement remains challenging. Programmable switches, while capable of line-rate packet processing, have limited on-chip resources (i.e., SRAM, TCAM, and processing capacity). Maintaining per-user AccessScopes and enforcing per-packet access decisions are both resource-intensive operations that together cannot fit within a single switch. This necessitates a division of labor, which NetZone adopts by separating these functions into two switch roles. Tagging switches are gateway switches positioned at the boundary of each subnet. These switches attach the appropriate per-subnet AccessScopes to each user’s connection before the traffic enters the subnet. Enforcement switches run within subnets, focusing solely on validating AccessScopes and enforcing security actions at line rate. Fig. 2 provides an overview of NetZone. We now briefly describe the high-level workflow of the defense. Initialization: This phase outlines how administrators define high-level policies and how the control plane generates and distributes the corresponding AccessScopes to tagging switches when a user logs in. (Step 1) NetZone provides a set of APIs (see Section 6) that allows administrators to define high-level, identity-centric policies through the control plane A . As shown in Fig. 1a, these policies specify which hosts a particular user is allowed to access. (Step 2) When a user logs in, our eBPF programs on the user’s system retrieve the UID from the running OS. It then sends the UID to the NetZone control plane to trigger the generation of the user’s AccessScope.

(Step 3) The control plane uses the received UID to retrieve the user’s high-level policies and encodes them into a persubnet AccessScope that defines the user’s access permissions (more details at Section 4.2.2). (Step 4) The control plane then distributes the generated AccessScopes using the lightweight AccessScope protocol (see Section 4.2.3) to store them in the tagging switches B . NetZone also sends the user’s current subnet AccessScope to their host system to bind existing processes with the received AccessScope. (Step 5) Each tagging switch stores the AccessScopes that define access permissions for hosts in its local subnets (see Section 4.3) C . Propagating AccessScopes: This phase describes how NetZone persists AccessScopes across hosts. (Step 6) When a process initiates a connection to another host, the eBPF program D on the sender constructs a custom AccessScope packet header (see Fig. 3b) that carries the user’s UID and access permissions. The eBPF program then attaches the process’s AccessScope to the outgoing traffic. (Step 7) Upon receiving the packet, the eBPF program on the receiving host extracts the appended AccessScope and binds it to the receiving process. (Step 8) The eBPF programs within the destination host maintain the received AccessScope by binding it to any new processes and threads spawned by the user, preserving the same access permissions. (Step 9) If the user initiates a connection to a different subnet, the tagging switch at the boundary intercepts the connection E . The tagging switch extracts the appended UID in the connection, looks up the corresponding destinationsubnet AccessScope from its local AccessScope store, and replaces the user’s current AccessScope with the destination-subnet AccessScope before forwarding the connection into the target subnet. Enforcing AccessScope: This phase describes how NetZone enforces AccessScopes entirely within the switch data plane. (Step 10) Before a connection reaches its destination within a subnet, the enforcement switch intercepts the packet carrying the AccessScope. (Step 11) The switch inspects the AccessScope F to verify whether it authorizes access to the destination host and then forwards or drops the packet accordingly. In Section 6, we further describe how NetZone reactively updates AccessScopes when policies change, handles packet loss, and recovers from switch failures. NetZone in action. Fig. 2 illustrates how NetZone prevents the attacker in our motivating example. Network administrators define high-level policies via NetZone APIs to restrict access to the private subnet to administrators (i.e., Alice), while regular users (i.e., Bob) are confined to the public subnet. Both Alice’s and Bob’s processes are initialized with their respective AccessScopes. When Bob’s malicious process P1 compromises Alice’s system and spawns a new malicious process P2, Bob’s AccessScope propagates along

Breaking Ambient Trust: In-Network Per-Process Access Control Against Lateral Movement

this connection to P2. Later, when both the malicious process P2 and the benign process P3 attempt to connect to the server, the tagging switch replaces their public-subnet AccessScopes with new ones specifying each user’s permissions in the private subnet. The enforcement switch then inspects the AccessScope for each flow: it blocks P2, which carries Bob’s restricted AccessScope, and allows P3, which carries an authorized AccessScope. Threat model. We consider attackers who gain an initial foothold into the network either externally from the public Internet or as insiders within the network. After compromising a host, the attacker can spawn processes or threads, initiate and receive connections, and laterally move across hosts by exploiting legitimate network paths. We consider that the programmable switches and control plane are secure as they are under the control of the network administrators. Also, we assume that our eBPF programs cannot be tampered with, which can be further secured by recent tamper-proof and tamper-evident auditing techniques [65]. Adversaries with kernel-level access could disable our eBPF programs and any other running security mechanisms, which is beyond the scope of this work and falls under kernel security rather than network security. We assume network administrators define appropriate high-level policies to regulate per-user access permission. We focus on enforcing these policies consistently as users move across hosts, rather than correcting the policies themselves. Our threat model aligns with established previous works on network security [12, 17] and defenses leveraging programmable switches [13, 35, 49, 81, 87, 89]. In Section 6, we further demonstrate how NetZone is resilient against adaptive adversaries attempting to compromise the system itself.

4

AccessScope Abstraction

AccessScope is an object that encodes a user’s permitted access in a network subnet. A naive design would define a single AccessScope for each user to encode their entire set of permissions across the network. However, such monolithic objects are not scalable: they can grow excessively large and become impractical for network switches with limited resources to process them. Instead, we generate a distinct AccessScope for each network subnet. Each AccessScope is uniquely defined by the tuple: 𝐴𝑐𝑐𝑒𝑠𝑠𝑆𝑐𝑜𝑝𝑒 = (𝑈 𝐼𝐷, 𝑆𝑢𝑏𝑛𝑒𝑡_𝐼𝐷, 𝑃𝑒𝑟𝑚𝑖𝑠𝑠𝑖𝑜𝑛𝑠)

• Permissions: Encodes which hosts within a Subnet_ID the user may access. NetZone dynamically updates and revokes Subnet_IDs and permissions as hosts migrate or reconfigure, ensuring that AccessScope objects remain consistent with the current network state (more details in Section 6). The user’s complete policy across the network is the union of all their AccessScope objects:

𝑁𝑢 = {(𝑆𝑢𝑏𝑛𝑒𝑡_𝐼𝐷𝑖 , 𝑃𝑒𝑟𝑚𝑖𝑠𝑠𝑖𝑜𝑛𝑠𝑖 ) | 𝑈 𝐼𝐷 = 𝑢}

(1)

• UID: This represents the user identity as defined in the identity and access management (IAM) system managed by network administrators (e.g., Active Directory). Each UID is unique within its IAM domain and remains consistent for a user across all hosts managed under that domain. In multi-domain environments (e.g., multi-forest Active Directory or federated IAM setups), NetZone adds the IAM domain identifier to the UID to guarantee global uniqueness across domains. • Subnet_ID: To uniquely identify network subnets, NetZone derives Subnet_IDs from existing network isolation mechanisms,

(2)

The set 𝑁𝑢 constitutes the user’s permissions across all subnets. When a user’s connection is about to enter subnet 𝑖, NetZone tags the user’s connection with AccessScope that matches its UID and the Subnet_ID the
user is entering as AccessScope 𝑈 𝐼𝐷, 𝑆𝑢𝑏𝑛𝑒𝑡_𝐼𝐷𝑖 , 𝑃𝑒𝑟𝑚𝑖𝑠𝑠𝑖𝑜𝑛𝑠𝑖 . Within the subnet, if the destination host is not present in 𝑃𝑒𝑟𝑚𝑖𝑠𝑠𝑖𝑜𝑛𝑠𝑖 , the connection is blocked.

4.2

Decentralized AccessScope Architecture

In this section, we detail the AccessScope abstraction, the tagging switch primitive, and the techniques we develop to replace AccessScope across network subnets in real time.

4.1

such as VLANs and subnets in traditional environments, and Virtual Private Clouds (VPC) in cloud environments. Specifically, NetZone’s control plane retrieves the VLAN and routing information from network switches, extracts the defined network subnets, and assigns a unique Subnet_ID for each subnet in the network. Each Subnet_ID defines the subnet where a given AccessScope specifies the user’s allowed access scope. The control plane maintains a canonical mapping of network subnet IP-toSubnet_ID, ensuring each IP address is consistently associated with the correct subnet.

AccessScope Distribution

NetZone leverages programmable switches to enforce user-specific access scopes via AccessScopes. Suppose we make the user carry their union set of AccessScopes (representing all resources in the network). This incurs high transmission overhead and forces the user to carry many permissions irrelevant to the user’s current network subnet. Alternatively, preloading all switches with every user’s AccessScopes is infeasible due to limited on-chip memory, especially in large enterprise networks with thousands of users. To address this, NetZone adopts an in-network division of labor. Gateway switches at the boundary of each network subnet act as tagging switches, while switches inside the subnet act as enforcement switches. When a user gets authenticated, the control plane generates the user’s AccessScope objects for all network subnets. The control plane then distributes them via our lightweight protocol (details in Section 4.2.3) in the form of packets. Each tagging switch stores only the AccessScopes that are relevant to resources in its directly connected subnet. As the user laterally moves from one network subnet to another, the tagging switch at the destination subnet replaces the source-subnet AccessScope with the destination-subnet AccessScope. Inside each subnet, enforcement switches (detailed in Section 5) inspect the attached AccessScope and mediate access to local resources. Next, we present the design of our custom AccessScope packet header, explain how NetZone generates user-specific AccessScopes from high-level policies, and describe how the AccessScope distribution protocol delivers AccessScopes to tagging switches.

L2

L3

L4

UID 32-bit

Subnet_ID 16-bit

Permissions 128-byte

Type 2-bit Osama Bajaber, Bo Ji, and Peng Gao

AccessScope packet header Allow UID

Deny

Subnet_ID

… Permissions

(a) AccessScope structure L2

L3

L4

UID 32-bit

Subnet_ID 16-bit

Permissions 128-byte

Type 2-bit

AccessScope packet header

(b) AccessScope packet header Allow Deny … Fig.UID 3: AnSubnet_ID illustration showing AccessScope structure and our custom packet header Permissions

4.2.1 AccessScope Custom Packet Header. Fig. 3a illustrates AccessScope structure. The UID and Subnet_ID specify the sender’s identity and the subnet where the AccessScope applies. The permission field is a bit string, where each bit represents access to a host in the subnet. If the bit is set to one, the user is allowed to access the corresponding host; otherwise, the user is blocked. The permission field size depends on the subnet size. In large-scale clusters such as Google’s [11], a single ToR switch typically serves hosts within a /22-/24 IP subnet (corresponding to 254-1022 hosts), making a 128B (1024-bit) permission field sufficient to represent all hosts in a network subnet. We detail how NetZone maps each bit position to its corresponding host in Section 4.2.2. To carry AccessScope in the network, NetZone employs a custom packet header (see Fig. 3b). We set the reserved bit in the IP fragmentation field [8] to mark packets carrying our AccessScope packet header. Our custom packet header can appear in two forms: (1) Standalone AccessScope control packet: Generated by the control plane (not part of the user’s data traffic) to carry AccessScopes across the network and store them in tagging switches. (2) Embedded AccessScope packet headers: Added to user data packets to carry the user’s AccessScope to be inspected by enforcement switches. The Type field is used to distinguish these roles: • (Type=0): Newly generated standalone AccessScope control packets by the control plane for distributing and storing. • (Type=1): Standalone AccessScope control packets stored in the tagging switch and ready to be assigned as the user enters a new network subnet. • (Type=2): User data packets carrying an embedded AccessScope packet header, which are validated by enforcement switches. A naive way of carrying embedded AccessScope packet headers is to attach them to every user data packet. This unnecessarily increases packet size, since the same security decision applies to all packets within a user’s connection. Instead, NetZone attaches the AccessScope header only to the initial packets of a connection. This is sufficient for enforcement switches (see Section 5.1) to inspect the AccessScope packet header once and apply the same decision to all subsequent packets (which do not carry a AccessScope

packet header) in the connection. Also, NetZone incorporates robust mechanisms to handle missing AccessScope packets through ACK packets and restores state after switch failures (see Section 6). 4.2.2 Generating AccessScopes from High-Level Policies. NetZone control plane translates high-level policies (defined via our APIs in Section 6) into AccessScopes. When a user logs in, our eBPF program on the host sends a packet containing the user’s UID to trigger the control plane to generate the corresponding AccessScopes. The control plane then fetches the high-level policies for the received UID and extracts the permitted host IPs. To generate AccessScopes, the control plane takes the user’s UID, permitted hosts, and the IP-to-Subnet_ID mapping (see Section 4.1). For each Subnet_ID, it encodes permitted hosts as a bit in the permission bit string. The result is a set of per-subnet AccessScopes, each containing the UID, Subnet_ID, and its permission bit string (as shown in Fig. 3a). Furthermore, the control plane creates a dictionary for each Subnet_ID that maps permission bit positions to host IPs. These dictionaries are loaded into the enforcement switches’ match/action tables to interpret permission bits for destination IPs. When a user’s policy is updated, NetZone automatically updates affected AccessScopes (details in Section 6). 4.2.3 AccessScope Distribution Protocol. After generating AccessScopes, the control plane distributes them to tagging switches so they are available when the user enters a subnet. For each AccessScope, NetZone creates a standalone control packet (Type=0) that carries the header to a specific Subnet_ID. To distribute these packets efficiently, NetZone employs the spanning tree protocol among tagging switches. The protocol builds a loop-free topology across switches, preventing AccessScope control packets from circulating indefinitely. The control plane elects a root switch, and each switch configures its forwarding ports to forward AccessScope packets along the tree. When a tagging switch receives a AccessScope control packet, it checks whether the carried Subnet_ID matches a locally connected network subnet. If so, the switch marks the packet as (Type=1) and stores it. Otherwise, the packet is forwarded to downstream switches in the tree. This approach ensures that all AccessScope control packets reach their corresponding tagging switch without flooding the network.

4.3

In-Flight AccessScope Storage

As users enter network subnets, the tagging switch fetches the user’s AccessScope and attaches it to their connection, ensuring it is enforced within the destination subnet (see Section 5). A key challenge, however, is that tagging switches must keep AccessScopes readily available to tag incoming user traffic. In large-scale environments such as Google clusters [50, 75], this can involve up to 10K active users. Storing AccessScopes for this many users in switch memory is infeasible due to two main constraints: (1) Limited on-chip memory (hundreds of MBs of SRAM and tens of TCAM). (2) Fixed-width entries (up to 64 bits [6]), which cannot accommodate entire AccessScopes (up to 128 bytes) or their variablelength permission fields. A recent line of work on in-network caching [40] introduced a caching architecture that overcomes the limitations of constrained

Breaking Ambient Trust: In-Network Per-Process Access Control Against Lateral Movement Request Register Request

State

UID(123) 1 (Completed) Subnet_ID (222) UID(456) Subnet_ID (222)

0 (Waiting)

...

...

Data Subnet_ID User A Packet 111

Response Registers Request State Request State Key Value UID(123) UID(123) Zone ID (777) H(Flow UID, Permissions Zone ID, ID (777) UID(456) Subnet_ID) (010110) UID(456) Zone ID (999) Zone...ID (999) ... ... ... ... ... ... ...

Data Subnet_ID User A Packet 222

AccessScope Header

Public Subnet Subnet_ID 111

User A

Subnet_ID 111

User A

Subnet_ID 222

Private Subnet Subnet_ID 222

On-the-Fly AccessScope Replacement

Fig. 4: Replacing AccessScope as the user moves to a new network subnet

switch memory in traditional in-network key-value stores [34, 71]. This architecture supports storing variable-length cache items by keeping them as in-flight packets within the data plane. This design leverages the built-in feature of programmable switches that allows packets to re-enter the recirculation pipeline through an internal loopback port (separate from other data packet ports). This design has proven effective in expanding switch storage capacity and handling variable-length cache items for load-balancing applications without increasing the switch’s memory footprint. Building on this idea, NetZone adopts a similar architecture to keep AccessScopes in-flight within the switch data plane. When a standalone AccessScope control packet (Type=0) arrives at a tagging switch that must store it, the switch modifies its type field to indicate stored state (Type=1) and sends the packet to the internal loopback port. The switch then matches incoming user connections (Type=2) against these in-flight AccessScopes, selecting the correct one based on the user’s UID as they enter the subnet. NetZone employs failure-handling mechanisms that coordinate with the control plane if an AccessScope is missing or a switch fails (see Section 6).

4.4

On-the-Fly AccessScope Replacement

When a user’s connection enters a new network subnet, the tagging switch needs to retrieve the user’s AccessScope. However, since AccessScopes are stored in-flight as packets (Type=1), programmable switches cannot directly copy an AccessScope header from the stored in-flight packet and attach it to the user’s connection. To resolve this, NetZone implements a lightweight request-response coordination mechanism within the data plane using two stateful registers: requestReg and responseReg, as illustrated in Fig. 4. Request register. When an initial user packet carrying an AccessScope header (Type=2) reaches a new subnet, the switch determines the destination Subnet_ID from the packet’s destination IP. Consequently, the switch adds an entry in requestReg, keyed by (UID, Subnet_ID). This records that there is a request to get the AccessScope for the user’s UID for Subnet_ID. The user’s data packet is recirculated until the request is resolved. Meanwhile, inflight AccessScope control packets (Type=1) check requestReg for matching entries. If a match is found, the switch responds to the request and writes the matched stored AccessScope values to responseReg, indexed by the connection’s 5-tuple (IPsrc , Portsrc , IPdst , Portdst , Protocol), UID, and the destination-Subnet_ID.

Response registers. A challenge in storing AccessScope permissions in responseReg is their variable sizes. Each AccessScope encodes a bitmap that can grow up to 1024 bits, while switch registers store only fixed-width words (32-64 bits). To address this, NetZone splits each permission field into fixed-size chunks and stores them sequentially across multiple responseReg registers, indexed by the flow’s 5-tuple, UID, and Subnet_ID. The waiting user’s data packet then replaces its existing AccessScope header with a new one for the destination subnet, reconstructing the complete AccessScope by sequentially reading and combining the matching entries from these registers. In practice, since the AccessScope is attached only to the initial packets of a connection, this process adds less than 100𝜇s of delay to a single waiting packet, which is negligible given that the RTT in typical enterprise networks spans several milliseconds. Subsequent packets are forwarded without modification with a negligible ∼130ns delay (see Section 7.3).

5

Enforcing and Persisting AccessScopes

Once the user’s AccessScope packet header enters a network subnet, NetZone enforces the encoded access scope at line rate and persists this scope as the user moves within the subnet.

5.1

In-Network AccessScope Enforcement

Enforcement switches mediate all connections within a subnet. NetZone leverages the embedded AccessScope packet header (Type=2) in the user’s initial packet to restrict access to authorized hosts. Each bit in the permission field represents access to a specific host. To interpret these bits efficiently, NetZone employs bitwise operations in the data plane. The switch maintains a match/action table (see Section 4.2) that maps each host IP address to a bitmask, where the bit representing the destination host is set to 1 and all others to 0. When a user’s process initiates a connection to a host, the switch retrieves the destination bitmask and performs a bitwise AND with the AccessScope permission field. A nonzero result indicates the process is authorized; otherwise, the connection is dropped. Cache security decision. Since the AccessScope is carried only in the initial packet of a connection, NetZone enforces the same security decision to subsequent packets in the connection that do not carry the header. After NetZone inspects the packet carrying the AccessScope (Type=2), the decision is stored in DecisionTable, indexed by the connection 5-tuple key and the decision value (0 to block, 1 to allow). Subsequent packets match against this table and are processed accordingly. To support various protocols, NetZone adopts the following strategies: the AccessScope header is attached to the SYN packet in TCP handshakes, to the first few packets in new UDP flows until an AccessScope ACK is received, and to both request and reply packets in ICMP exchanges.

5.2

Cross-Host AccessScope Persistence

Within a subnet, a user may move across hosts and perform various operations such as spawning new processes and threads. Enforcing least privilege requires tracking intra-host activity at the process level rather than treating each host as a single trust boundary. This requires a lightweight mechanism to track and propagate identity context as processes and threads are created, without intrusive kernel changes or application-level modifications.

Osama Bajaber, Bo Ji, and Peng Gao

NetZone achieves this using eBPF programs that propagate AccessScopes within hosts and across the network. eBPF [3] is a widely adopted kernel technology [2] that provides a secure sandbox for running user-defined programs inside the operating system kernel. These programs attach to kernel hooks (e.g., system calls or network events), enabling custom functionality without changing the kernel source or loading new modules. (1) Extracting AccessScope from incoming packets: Once a user reaches a host over the network, we design an eBPF program that extracts the AccessScope packet header from incoming packets. For high-performance processing, this program runs at the XDP (eXpress Data Path) hook [31], enabling execution directly in the network interface card driver. Packets marked with the reserved IP fragment bit are parsed to extract and remove the AccessScope header before the packet is passed to the kernel stack. The program then stores the extracted AccessScope and the destination port in a BPF map called incomingObject (dport->AccessScope). To bind the incoming AccessScope to the receiving process or thread, we attach a eBPF program to trace system calls used to accept the connection (i.e., accept() and accept4() for TCP, and recvfrom() and recvmsg() for UDP). Once such a system call is detected, our eBPF program looks up the destination port in incomingObject and, if matched, retrieves the process or thread identifier using bpf_get_current_pid_tgid(). This helper returns a 64-bit value that combines the process ID (upper 32 bits) and thread group ID (lower 32 bits), enabling fine-grained tracking even when threads spawn new processes. The extracted AccessScope is then stored in a BPF map objectMap (pid_tgid->AccessScope). (2) In-kernel AccessScope propagation: To track how a user’s identity propagates within a system, we attach multiple eBPF programs to system calls that create new execution contexts. Specifically, when a process spawns a child via fork(), clone(), or execve(), the eBPF program captures the parent’s pid_tgid. The parent’s pid_tgid is then used as a lookup key in objectMap to retrieve its associated AccessScope. Consequently, the eBPF program creates an entry in objectMap, indexed by the child’s pid_tgid, ensuring that the child inherits the correct AccessScope. (3) Propagate AccessScope back to the network: When a user initiates a connection to another host in the network, our eBPF program intercepts the corresponding system calls (i.e., connect() for TCP and sendto() for UDP). The program extracts the caller’s pid_tgid and records the mapping in a BPF map outgoingObject (sport->AccessScope). To attach AccessScope packet header to outgoing packets, we attach an egress eBPF program at the Traffic Control (TC) hook. It checks whether the outgoing packet’s source port is in outgoingObject. If found, the eBPF program constructs an AccessScope packet header and inserts it into the matched outgoing packet.

6

Handling Practical Requirements

Adaptive adversaries. NetZone is resilient to adaptive adversaries targeting our system itself. An attacker on the victim’s host may attempt PID spoofing to gain another process’s AccessScope. However, this attack fails since the OS enforces unique PIDs for all active processes. A more advanced man-in-the-middle attacker may try to capture AccessScopes in transit and manipulate their

permissions to gain unauthorized access. To prevent this, NetZone uses in-network keyed hashing [19] and integrates a lightweight message authentication code (MAC) scheme. Specifically, our eBPF programs compute a keyed hash over each AccessScope packet header and append it to the outgoing packet, while the switches verify the MAC inline before processing. Packets with invalid MACs are dropped, preventing forgery or tampering. An attacker may attempt to saturate the switches by flooding the network with a large number of connections. However, since NetZone processes all packets entirely within the data plane, it remains resilient to such denial-of-service (DoS) attacks (as evaluated in Section 7.4). Also, an attacker may try to exhaust switch registers by initiating many legitimate connections. To mitigate this, NetZone employs a rate-limiting mechanism that limits the number of connections from each UID within a defined time window. This allows NetZone to restrict malicious processes without disrupting benign processes on the same host. Also, NetZone periodically evicts inactive entries to free up switch memory. Failure handling. NetZone employs robust mechanisms to handle packet loss and switch failures. For packet loss, NetZone uses ACKs between tagging switches and the control plane to ensure reliable delivery of AccessScope packets (Type=0). When a switch stores an AccessScope, it clones the packet and sends it as an ACK to the control plane. If the control plane does not receive an ACK, the AccessScope is retransmitted until confirmed. If a tagging switch fails, all in-flight AccessScopes stored on it are lost. To ensure uninterrupted operations, NetZone automatically repopulates stored AccessScopes as follows. During normal operation, the control plane records which AccessScopes are stored on each tagging switch when ACKs are received. When a failed switch recovers, the control plane re-sends the corresponding AccessScopes to restore the switch’s storage. This adds negligible storage overhead to the control plane. In a typical data center cluster with about 10K concurrent active users and 13K hosts [50, 75], the control plane needs only ∼10 MB of memory to store AccessScopes, which is negligible in modern servers. Defining high-level policies. NetZone provides a set of APIs for administrators to define user-based policies, which are then encoded into AccessScopes. These APIs enable easy specification of per-user permissions without requiring low-level data-plane programmability. An administrator can define a new policy using AddAllowPolicy(UID, dst_ip), granting the specified user access to a destination host. Similarly, a policy can be removed with RemoveAllowPolicy(UID, dst_ip). By default, any host not explicitly allowed for a user is denied. Updating AccessScope. In dynamic networks with frequent policy changes, NetZone supports real-time updates to AccessScope permissions across switches and hosts. When a policy changes, the control plane generates an updated standalone AccessScope packet (Type=0) and injects it into the network. The distribution protocol delivers the updated AccessScope to relevant tagging switches while the control plane removes outdated versions. To synchronize hosts, the control plane sends the same update packets to systems within the updated network subnet, where eBPF programs extract the new AccessScope and overwrite old entries in objectMap.

Breaking Ambient Trust: In-Network Per-Process Access Control Against Lateral Movement

Logic

Frontend

This ensures consistent policy enforcement, with updates typically propagating network-wide within 2-10 ms.

Storage

Follow user

Blocked Users

Read Post

Recommender

Memcached MongoDB

7

Unique ID

Evaluation

We answer research questions on NetZone ’s effectiveness, scalability, overhead, and switch resource utilization through extensive evaluations on our physical testbed and using real-world workload datasets and network topologies. (RQ1) How effective is NetZone’s per-user network scope in mitigating various attacks? (RQ2) How efficiently does NetZone process traffic with realworld workloads and network topologies? (RQ3) What impact does NetZone have on the network and the host performance? (RQ4) How does NetZone ’s in-network implementation compare with an alternative server-based implementation? (RQ5) What is NetZone ’s resource utilization on programmable switches? Implementation and experimental setup. We implement NetZone using ∼1300 lines of code, including the tagging and enforcement switch primitives, eBPF programs, and switch control plane functions. For our main experiments, we deployed NetZone on a physical Tofino 32x100 Gbps port. Our setup mirrors existing network security and P4 works [49, 80, 83, 84, 87]. The switch is configured as a Top-of-Rack (ToR) switch, which is connected to three Dell R420 servers, each equipped with an Intel Xeon E5-2430 CPU running at 2.20 GHz, 64 GB RAM, and Ubuntu 22.04. We evaluate NetZone using three real-world datasets: (1) DARPA OpTC [76], (2) Yatesbury [32], and (3) LANL Unified Host and Network [74] datasets. In addition, we deploy NetZone in three representative topologies (illustrated in Figs. 5 to 7) to test against realistic attack scenarios: (1) a web-based social media network [23], (2) a media streaming service [23], and (3) Stanford University’s backbone network [38]. The social media network and media streaming services are deployed on a 4-VM scale set across our physical servers, connected through the Tofino switch. The Stanford backbone network is emulated in Mininet using software P4 switches (bmv2 [1]) to replicate the behavior of physical hardware. Next, we present three realistic attack scenarios that we conduct on the three topologies. In each scenario, the attacker employs realistic techniques, such as network scanning, zero-day exploitation, privilege escalation, and lateral movement. Use case 1: Social media network. The architecture (shown in Fig. 5) consists of frontend servers, ad engines, user recommendations, post composition, and metadata storage, with MongoDB and Memcached powering the backend. We embed a Log4Shell vulnerability [62] in the frontend web server. An attacker compromises the entry point by crafting an HTTP packet header that carries a malicious JNDI lookup string. This triggers remote code execution, granting the attacker an interactive shell on the compromised frontend. The attacker then leverages post-compromise tools (e.g., netcat, curl) to pivot laterally toward sensitive backend databases. Use case 2: Media streaming service. Its architecture (shown in Fig. 6) includes NGINX frontend servers, a payment authentication module, a streaming service (nginx-hls), and backend databases

Client

Load Balancer

Web Server

URL Shorten

Process Manager

Memcached

Read Timeline

Ads

MongoDB

User Info

Video Login

Posts Storage Write Timeline

Image Compose Post

Text

Index0 Index1

Search

Indexn

MongoDB Memcached

Write Graph

User Tag Favorite

Memcached

MongoDB Memcached MongoDB

Fig. 5: Social media network

Logic

Frontend

Storage

Video Streaming

Rent Movie

NFS User Info

Unique ID

Login

Text/Rating

Compose Review

Movie ID

Ads

User Review Client

Load Balancer

Process Manager

ngix

Search

MongoDB Memcached

Movie Review

MongoDB

Review Storage

Recommender

Memcached MongoDB

Reviews

Compose Page

Rating Plot Cast

Index0 Index1

Thumbnail

Indexn

Videos

Memcached

Memcached MongoDB MySQL

Photos

Fig. 6: Media streaming service

Backbone 1

S1

OZ 1a

OZ 1b

S2

OZ 2a

S3

OZ 2b

Backbone 2

S4

OZ 3a

S5

OZ 3b

S6

OZ 4b

S7

OZ 5a

S8

OZ 5b

S9

OZ 6a

S10

OZ 6b

OZ 7a

OZ 7b

Fig. 7: Stanford backbone network

(MySQL, MongoDB, Memcached). An attacker targets the movie review field of the web frontend page by exploiting an injection vulnerability [64]. Because the service fails to sanitize user input correctly, the attacker can inject malicious arbitrary code, acquiring an interactive shell. This enables the attacker to pivot across services, ultimately reaching the backend DB. Use case 3: Stanford backbone network. In Fig. 7, Stanford University’s backbone network [38] supports 15K students and 2K faculty across 14 operational zones (OZs), interconnected through edge switches and two central backbone switches. We deployed Infection Monkey malware [5] that initially infects a compromised host. Then, the malware attempts to propagate laterally across the university’s operational zones by scanning for vulnerable services and exploiting misconfigured or permissive inter-zone connectivity.

7KURXJKSXW0%VHF

Osama Bajaber, Bo Ji, and Peng Gao

     

)RUZDUGLQJEDVHOLQHEHQLJQWUDIILF 1HW=RQHEHQLJQWUDIILF $WWDFNWUDIILFDWWDFNFDVHV





7LPHVHF





Fig. 8: NetZone blocks all attack traffic while imposing minimal overhead on benign traffic

7.1

RQ1: Defense Effectiveness

We validate the effectiveness of NetZone in enforcing per-user access scopes to mitigate realistic attacks. We deploy our motivating example shown in Fig. 1 in our testbed, implemented on a 3-VM scale to represent each of the running hosts. We configure a traditional firewall (iptables [7]) that mediates access across two subnets: a Public subnet (hosting Alice and Bob) and a Private subnet (hosting the server). Firewall rules permit intra-subnet traffic and allow Alice to reach the server. Direct connections from Bob to the Private Subnet are blocked. Using the malicious Bob user, we attempt to reach the server by pivoting through Alice as an intermediate host. We conduct seven attacks, including exploiting a zero-day vulnerability [60] using Metasploit [67], deploying Infection Monkey malware [5], and exfiltrating sensitive data using the Data Exfiltration Toolkit (DET) [9] over multiple channels (e.g., TCP, UDP, DNS, HTTP, and Gmail). Each attack is tested with and without NetZone, and we measure the attacker’s throughput during the experiments using iperf3. Fig. 8 summarizes the results. Without NetZone, the attacker successfully reaches the server and sustains stable throughput for all seven attack variants, enabling data exfiltration despite firewall isolation. With NetZone enabled, we configure high-level policies in the control plane to allow only the user Alice to access the server, while Bob is restricted from accessing the Public Subnet. The control plane generates per-user AccessScopes accordingly, which are attached to traffic in the network. In every tested attack, NetZone confines the attacker to their permitted access scope and prevents lateral movement. Consequently, attacker throughput falls to zero for all seven attacks. Takeaways: NetZone effectively blocks all 7 attacks across 5 communication channels, reducing attacker throughput to 0 MB/sec while maintaining 99.9% of benign traffic throughput.

7.2

RQ2: Defense Scalability

Real-world workload traces. We evaluate NetZone using three datasets. In DARPA OpTC, an attacker pivoted across 14 hosts beyond its initial compromise. Yatesbury benchmark consists of 13 attack scenarios in an e-commerce web-based application. The LANL dataset collects benign activities from a real-world network of 17K hosts. As LANL lacks malicious traces, we simulate realistic attacks (similar to Section 7.1) for a comprehensive evaluation.

We use Distributed Internet Traffic Generator (D-ITG) [16] to generate the three workloads from our servers through the physical switch. We evaluate three switch programs: 1) a forwarding-only baseline (no defense), 2) a tagging switch program that updates the user’s AccessScope, and 3) an enforcement switch program that enforces security decisions based on the AccessScope. We measure NetZone’s impact on benign traffic by comparing the flow completion time (FCT) under each of the three scenarios. Fig. 9 shows the cumulative distribution function (CDF) of FCT for benign traffic. We observe negligible differences between the baseline and NetZone, because tagging and enforcement switches operate entirely in the data plane without involving the control plane. Also, NetZone inspects only the initial packet of each connection, forwarding subsequent packets without modification. These findings confirm that NetZone enforces per-user access scopes without impacting the performance of realistic workloads. Large-scale network topology. To evaluate NetZone in complex and realistic topologies, we deploy three topologies: the social media network Fig. 5, the media streaming service Fig. 6, and the Stanford backbone network Fig. 7. For each topology, we repeat the attack scenarios (described in Section 7) under two configurations: with distributed firewalls (iptables) and with NetZone. In every configuration, we pick a compromised host where the attacker begins and a target host that the attacker tries to reach. The firewall baseline restricts access to the target to a subset of hosts, while in the NetZone setup, policies explicitly limit the target to admin users, denying access from all others. We run an attacker script that carries out the exploits and then probes all possible routes to the target, recording every successful route leading to the target. With distributed firewalls, only direct connections from the attacker are blocked, covering just 3-5% of all possible routes. The attacker can still compromise intermediate hosts and bypass defenses to reach the target. In another run, we deploy NetZone in the topologies. In contrast, when NetZone is deployed, the attacker’s AccessScopes are tracked across hosts, confining them to their authorized access scope. As a result, the attacker cannot reach the target regardless of the pivoting route, increasing the percentage of blocked routes from 3-5% to 100%. Takeaways: NetZone scales to real-world workloads, imposing negligible latency on 3 tested datasets, and effectively increases the attack coverage by 33.3x across 3 real-world topologies compared to distributed firewalls.

7.3

RQ3: NetZone Overhead Impact

In-flight AccessScope overhead. We evaluate NetZone ’s performance when handling multiple in-flight AccessScopes by installing our tagging switch program on a physical Tofino switch. We gradually inject AccessScopes while initiating new connections that require them, continuing until the switch’s parser queue becomes saturated and packet drops occur. To increase our in-flight storage, we apply port shaping to reduce the processing bitrate of AccessScopes, allowing more AccessScope packets to remain in the switch pipeline before re-entering the parser.











1RGHIHQVHEDVHOLQH (QIRUFHPHQWVZLWFK 7DJJLQJVZLWFK

 



 )&7VHF





1RGHIHQVHEDVHOLQH (QIRUFHPHQWVZLWFK 7DJJLQJVZLWFK

 

(a) DARPA OpTC FCT

 )&7VHF

&')

 &')

&')

Breaking Ambient Trust: In-Network Per-Process Access Control Against Lateral Movement



1RGHIHQVHEDVHOLQH (QIRUFHPHQWVZLWFK 7DJJLQJVZLWFK

 



(b) LANL FCT



  )&7VHF





(c) Yatesbury FCT







 /DWHQF\ 

5HFLUFXODWLRQ%LWUDWH







 















Kernel Function execve clone exit TC egress XDP ingress

Time (𝜇s)

NetZone Δ (𝜇s)

432 261 11 51 32

5.1 6.3 0.7 0.9 0.3

Table I: Original average time taken for kernel functions with their respective overhead introduced by our eBPF programs





Fig. 10: In-flight storage can support a sufficient number of AccessScopes while incurring negligible latency.

Fig. 10 shows the relationship between the number of stored AccessScopes and the pipeline processing bitrate. The bitrate declines gradually as more AccessScopes are stored, dropping by ∼15% when storing AccessScopes for 16K users. At this bitrate, tagging an incoming packet with its AccessScope adds less than 110𝜇𝑠 of latency, which is negligible considering that the RTT in typical enterprise networks spans several milliseconds. This only occurs for the first packet of a new connection, as subsequent packets are forwarded without modifications. Number of supported AccessScopes. Large-scale enterprise environments typically require support for up to 10K active users concurrently in a single cluster. For instance, a single Google cluster [50, 75] may include 1K-13K machines but usually serves 10K concurrent users. As shown in Fig. 10, NetZone efficiently stores up to 16K concurrent AccessScopes, well above this requirement. Thus, NetZone provides sufficient capacity for large-scale deployments while accommodating future growth in the number of active users. Number of supported active connections. We leverage the feature of the P4 compiler to measure the capacity of NetZone in handling active connections. We keep increasing the maximum number of active connections until the P4 compiler rejects our program and record the largest number supported. We find that up to 200K concurrent connections can be supported at the same time. This is more than the number of active connections found in Facebook frontend clusters, which range between 10K and 100K [55].

7KURXJKSXW*ESV

Number of Stored AccessScope Objects (log scale)



 /DWHQF\QV



5HFLUFXODWLRQ%LWUDWH0ESV

/DWHQF\PLFURVHFRQGV

Fig. 9: NetZone imposes minimal overhead on real-world workloads



  %DVHOLQH)ZG

7DJJLQJ 33URJUDP

7KURXJKSXW  /DWHQF\ (QIRUFHPHQW 

Fig. 11: NetZone tagging and enforcement primitives network performance compared to the forwarding baseline

Throughput and latency. We evaluate NetZone ’s impact on network performance by comparing it against a P4 program that performs simple packet forwarding. We run the switch once with the tagging program and once with the enforcement program. The comparison results are shown in Fig. 11. After successful compilation, the pipelined nature of the switch hardware ensures that the NetZone ’s P4 program operates at a rate of 99.9 Gbps per port, matching the forwarding baseline. Also, NetZone adds 110-160 ns of latency, which is negligible considering that the RTT in typical enterprise networks spans several milliseconds. eBPF programs overhead. We evaluate the impact of our eBPF programs on a Linux server (kernel 5.15.0) by measuring both latency and memory overhead. To quantify the runtime cost of propagating AccessScope across system entities, we connected to a server using netcat, invoked 10K child processes, and measured the additional delay introduced by the eBPF programs. To measure the cost of our TC and XDP programs, we generated 10K flows carrying AccessScope and recorded the program’s execution time. Our results show that the programs add only 2-7𝜇𝑠 of latency per system call. This overhead is negligible compared to the baseline runtime of execve() and clone() system calls, which we measured at 432𝜇𝑠

6XFFHVVIXOFRQQ

Osama Bajaber, Bo Ji, and Peng Gao

     

Table II: Hardware resource utilization

1HW=RQH 6'1EDVHG LPSOHPHQWDWLRQV . . . . . . $WWDFNVWUHQJWKQHZFRQQHFWLRQV

Fig. 12: NetZone in-network approach is resilient to saturation attacks compared to centralized systems

Program

SRAM

TCAM

VLIW

Hash Units

NetZone Enforcement NetZone Tagging

17.3% 21.1%

0.1% 0.1%

2.1% 2.9%

6% 2.9%

tna_simple_switch.p4 + NetZone Tagging + NetZone Enforcement

6.3% 27.4% 23.6%

9% 9.1% 9.1%

9.6% 12.5% 11.7%

0% 2.9% 6%

switch.p4 + NetZone Tagging + NetZone Enforcement

33.6% 54.7% 50.9%

31.6% 31.7% 31.7%

13.5% 16.4% 15.6%

19.4% 22.3% 25.4%

and 261𝜇𝑠, respectively. We also analyze the memory requirements of storing AccessScope in BPF maps. With our 64 GB RAM system, Linux caps our system to about 1M processes and threads that can be concurrently created [47]. With an AccessScope with a 1028-bit width permission field, our BPF maps consume roughly 130MB of memory, which is insignificant given modern server resources.

of setup requests and install rules. This not only increases perconnection latency but also overwhelms the controller’s processing capacity, leading to delayed or dropped legitimate connections. As shown in Fig. 12, SDN-based solutions are completely saturated beyond 100K packet/s. In contrast, NetZone enforces AccessScopes entirely within the data plane, sustaining line-rate performance and remaining inherently robust against such saturation attacks.

Takeaways: NetZone supports up to 16K users and 200K concurrent connections while maintaining line-rate performance and adding only 110-160 ns of latency. Its eBPF programs incur a negligible 2-7 𝜇𝑠 per system call.

Takeaways: NetZone eliminates controller dependency, achieving a 27-68× speedup over centrlized systems such as Ethane [17] and NetView [12], while being resilient against control-plane saturation attacks.

7.4

7.5

RQ4: Comparison with Centralized User-Based Access Control Solutions

Recent SDN-based efforts [12, 17, 29] have introduced role- and attribute-based policy definitions. Each new connection pauses until the controller verifies both endpoints and installs the required forwarding rules. In our testbed, we set up an ONOS SDN controller, and we deploy both NetView [12] and Ethane [17]. Since Ethane’s code is not publicly available, we implement it as an SDN program. Installing defense rules. We evaluate how quickly the NetZone switch-based design enforces access decisions for new connections. In Ethane and NetViews, every new connection requires controller involvement. The controller must process policy rules, verify the source and destination, and then install forwarding entries in the switches. This controller-mediated process takes 10 ms-5 s, dominated by policy engine execution and delays in installing switch rules. Such overhead is far too high for enterprise networks, where connection setup is expected to complete within milliseconds. In contrast, NetZone processes AccessScope entirely within the data plane, eliminating controller processing and round-trip overhead. Our tagging switches incur less than 110 𝜇𝑠 of delay on the first packet, while subsequent packets incur only 130 ns of latency. For enforcement, NetZone can effectively enforce AccessScopes within 140 ns. This represents a 27-68x improvement over SDN-based approaches, suitable for high-throughput, lowlatency enterprise requirements. Saturating the control plane. A centralized control plane quickly becomes a bottleneck under high connection rates. An attacker can launch a saturation attack by initiating a large number of shortlived connections, forcing the controller to process a large number

RQ5: Switch Resources and Utilization

Table II shows the switch resource utilization of both NetZone tagging and enforcement programs as reported via the Intel P4 Insight tool. Both NetZone’s programs consume a small footprint on shared resources (SRAM 17.3%, TCAM 0.1%). As the tagging switch maintains AccessScopes in-flight, it can store up to 16K AccessScopes without incurring a footprint on the scarce switch memory. Also, both programs make minimal use of VLIW units (for header modifications) and hash units (for in-network hash computations), leaving sufficient resources for additional P4 programs to run alongside NetZone on the same switch. In fact, we deployed NetZone programs alongside two complex P4 programs: tna_simple_switch.p4 and switch.p4. Table II demonstrates each of the P4 program and the total resources used after adding NetZone. These results show that NetZone can be deployed alongside feature-rich programs on the same hardware switch while efficiently handling AccessScopes away from scarce resources. Takeaways: NetZone uses only 17-21% SRAM and 0.1% TCAM, maintains minimal VLIW and hash unit utilization, and retains enough resources to coexist with other complex P4 programs on the same switch.

8

Discussion

eBPF security. While eBPF provides a secure sandbox environment for running user-defined programs in the kernel, there are still some potential vulnerabilities with the current technology. Recent zeroday vulnerabilities [61, 63] enable attackers to execute arbitrary

Breaking Ambient Trust: In-Network Per-Process Access Control Against Lateral Movement

memory reads and writes, potentially compromising the integrity of our BPF maps. Existing works have been proposed to enhance the safety verification of eBPF programs [24, 59], significantly reducing the eBPF vulnerabilities that may be used to exploit the kernel. Such efforts further bolster the security of our eBPF programs. Stolen user credentials. NetZone is not designed to detect attackers who steal user credentials (e.g., username and password) and authenticate to the IAM system to gain the victim’s access scope. NetZone can benefit from recent works [30, 48] that analyze login activities across the network to identify and flag suspicious authentication attempts.

9

Related Work

In-network programmability. Programmable switches are widely used in enterprise networks to offload various networking tasks [20, 37, 39, 72]. A parallel line of work has explored in-network defenses against different attack types, such as covert channels [82], distributed denial-of-service [49, 84, 87], data leakage [13], link flooding [83, 89], privacy threats [77], and RDMA vulnerabilities [80]. However, none of the existing in-network defenses enforce per-user, process-level access scopes at line rate. Network isolation. A large body of work focuses on isolating network traffic to contain breaches and limit lateral movement. Traditional network virtualization techniques such as VLANs [10] and network slices [4] provide coarse-grained separation at the subnet level. More recent efforts [27, 42, 43, 86] aim to simplify virtualization definitions in large-scale environments. Leveraging SDN, these systems introduce policy abstractions that allow administrators to specify VLAN requirements. Another line of work [12, 17, 29] maps high-level role- and attribute-based policies into IP-based rules that mediate traffic. While these mechanisms restrict communication between isolated networks, they still lack process-level visibility and cannot track users’ movement, enabling attackers to find permitted paths among network subnets to laterally move. eBPF for cybersecurity. Existing efforts have leveraged eBPF to develop offensive tools and eBPF-based malware [21, 22]. Other works have explored new attacks that leverage the nature of eBPF programs to target cloud containers [28]. On the defensive side, several works [46, 69] have utilized eBPF to enhance OS logging. NetZone leverages eBPF to realize process-level capabilities that mediate access to remote resources without modifying the OS or the underlying kernel.

10

Conclusion

We presented NetZone, an in-network, fine-grained defense that enforces per-user, access scopes to secure network access against lateral movement in enterprise networks. NetZone introduces AccessScope, a lightweight, process-bound credential that encodes user permissions, propagates across hosts, and is enforced at line rate using programmable data planes. Our design eliminates ambient host-level trust by binding permissions to individual processes and persisting them as users move across the network.

References [1] Behavioral model (bmv2). https://github.com/p4lang/behavioral-model. [2] ebpf case studies. https://ebpf.io/case-studies/.

[3] ebpf official website. https://ebpf.io/". [4] A framework for network slices in networks built from ietf technologies. https: //datatracker.ietf.org/doc/rfc9543/. [5] Infection monkey. https://www.akamai.com/infectionmonkey". [6] Intel® tofino™ programmable ethernet switch asic. https://www.intel.com/cont ent/www/us/en/products/network-io/programmable-ethernet-switch/tofinoseries.html. [7] The netfilter.org "iptables" project. https://www.netfilter.org/projects/iptables/ index.html. [8] The security flag in the ipv4 header ietf rfc3514. https://www.ietf.org/rfc/rfc35 14.txt. [9] Det (extensible) data exfiltration toolkit. https://github.com/PaulSec/DET, 2019. [10] Ieee standard for local and metropolitan area networks–bridges and bridged networks. IEEE Std 802.1Q-2022, pages 1–2163, 2022. [11] Mohammad Al-Fares, Alexander Loukissas, and Amin Vahdat. A scalable, commodity data center network architecture. In ACM SIGCOMM, page 63–74, 2008. [12] Iffat Anjum, Daniel Kostecki, Ethan Leba, Jessica Sokal, Rajit Bharambe, William Enck, Cristina Nita-Rotaru, and Bradley Reaves. Removing the reliance on perimeters for security using network views. In ACM SACMAT, page 151–162, 2022. [13] O. Bajaber, B. Ji, and P. Gao. P4control: Line-rate cross-host attack prevention via in-network information flow control enabled by programmable switches and ebpf. In IEEE S&P, pages 146–146, 2024. [14] Arnar Birgisson, Joe Gibbs Politz, Ulfar Erlingsson, Ankur Taly, Michael Vrable, and Mark Lentczner. Macaroons: Cookies with contextual caveats for decentralized authorization in the cloud. 2014. [15] Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick McKeown, Jennifer Rexford, Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, and David Walker. P4: Programming protocol-independent packet processors. page 87–95. SIGCOMM CCR, 2014. [16] Alessio Botta, Alberto Dainotti, and Antonio Pescapè. A tool for the generation of realistic network workload for emerging networking scenarios. Comput. Netw., pages 3531–3547, 2012. [17] Martin Casado, Michael J. Freedman, Justin Pettit, Jianying Luo, Nick McKeown, and Scott Shenker. Ethane: taking control of the enterprise. In SIGCOMM, page 1–12, 2007. [18] Sylvan Clebsch, Sophia Drossopoulou, Sebastian Blessing, and Andy McNeil. Deny capabilities for safe, fast actors. AGERE! 2015, page 1–12, 2015. [19] Trisha Datta, Nick Feamster, Jennifer Rexford, and Liang Wang. SPINE: Surveillance protection in the network elements. In FOCI, 2019. [20] Arjun Devraj, Liang Wang, and Jennifer Rexford. Redact: Refraction networking from the data center. SIGCOMM Comput. Commun. Rev., page 15–22, 2021. [21] Jeff Dileo. Evil ebpf: Practical abuses of an in-kernel bytecode runtime, 2019. [22] Guillaume Fournier, Sylvain Baubeau, and Sylvain Baubeau. ebpf, i thought we were friends, 2021. [23] Yu Gan, Yanqi Zhang, Dailun Cheng, Ankitha Shetty, Priyal Rathi, Nayan Katarki, Ariana Bruno, Justin Hu, Brian Ritchken, Brendon Jackson, Kelvin Hu, Meghna Pancholi, Yuan He, Brett Clancy, Chris Colen, Fukang Wen, Catherine Leung, Siyuan Wang, Leon Zaruvinsky, Mateo Espinosa, Rick Lin, Zhongling Liu, Jake Padilla, and Christina Delimitrou. An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems. In ASPLOS, page 3–18, 2019. [24] Elazar Gershuni, Nadav Amit, Arie Gurfinkel, Nina Narodytska, Jorge A. Navas, Noam Rinetzky, Leonid Ryzhyk, and Mooly Sagiv. Simple and precise static analysis of untrusted linux kernel extensions. In Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation, page 1069–1084, 2019. [25] S. Gusmeroli, S. Piccione, and D. Rotondi. Iot access control issues: A capability based approach. In 2012 Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing, pages 787–792, 2012. [26] Sergio Gusmeroli, Salvatore Piccione, and Domenico Rotondi. A capabilitybased security approach to manage access control in the internet of things. Mathematical and Computer Modelling, pages 1189–1205, 2013. [27] Stephen Gutz, Alec Story, Cole Schlesinger, and Nate Foster. Splendid isolation: A slice abstraction for software-defined networks. In ACM HotSDN, pages 79–84, 2012. [28] Yi He, Roland Guo, Yunlong Xing, Xijia Che, Kun Sun, Zhuotao Liu, Ke Xu, and Qi Li. Cross container attacks: The bewildered ebpf on clouds. In USENIX Security 23, pages 5971–5988, 2023. [29] Timothy L Hinrichs, Natasha S Gude, Martin Casado, John C Mitchell, and Scott Shenker. Practical declarative network management. In ACM WREN, pages 1–10, 2009. [30] Grant Ho, Mayank Dhiman, Devdatta Akhawe, Vern Paxson, Stefan Savage, Geoffrey M Voelker, and David Wagner. Hopper: Modeling and detecting lateral movement. In USENIX Security, pages 3093–3110, 2021. [31] Toke Høiland-Jørgensen, Jesper Dangaard Brouer, Daniel Borkmann, John Fastabend, Tom Herbert, David Ahern, and David Miller. The express data

Osama Bajaber, Bo Ji, and Peng Gao

path: Fast programmable packet processing in the operating system kernel. In CoNEXT, page 54–66, 2018. [32] Kevin Hsieh, Mike Wong, Santiago Segarra, Sathiya Kumaran Mani, Trevor Eberl, Anatoliy Panasyuk, Ravi Netravali, Ranveer Chandra, and Srikanth Kandula. Netvigil: Robust and low-cost anomaly detection for east-west data center security. In USENIX NSDI, pages 1771–1789, 2024. [33] Muhammad Asim Jamshed, Jihyung Lee, Sangwoo Moon, Insu Yun, Deokjin Kim, Sungryoul Lee, Yung Yi, and KyoungSoo Park. Kargus: a highly-scalable software-based intrusion detection system. In ACM CCS, pages 317–328, 2012. [34] Xin Jin, Xiaozhou Li, Haoyu Zhang, Robert Soulé, Jeongkeun Lee, Nate Foster, Changhoon Kim, and Ion Stoica. Netcache: Balancing key-value stores with fast in-network caching. In SOSP, pages 121–136, 2017. [35] Qiao Kang, Lei Xue, Adam Morrison, Yuxin Tang, Ang Chen, and Xiapu Luo. Programmable In-Network security for context-aware BYOD policies. In USENIX Security, pages 595–612, 2020. [36] Matt Kapko. Amazon pins cisco, citrix zero-day attacks to apt group. https: //cyberscoop.com/amazon-threat-intel-apt-group-cisco-citrix-zero-days/, 2025. [37] Naga Katta, Mukesh Hira, Changhoon Kim, Anirudh Sivaraman, and Jennifer Rexford. Hula: Scalable load balancing using programmable data planes. In ACM SOSR, 2016. [38] Peyman Kazemian, George Varghese, and Nick McKeown. Header space analysis: Static checking for networks. In USENIX NSDI, pages 113–126, 2012. [39] Daehyeok Kim, Jacob Nelson, Dan R. K. Ports, Vyas Sekar, and Srinivasan Seshan. Redplane: enabling fault-tolerant stateful in-switch applications. In ACM SIGCOMM, page 223–244, 2021. [40] Gyuyeong Kim. Pushing the limits of { In-Network } caching for { Key-Value } stores. In USENIX NSDI, pages 1155–1168, 2025. [41] Gerwin Klein, Kevin Elphinstone, Gernot Heiser, June Andronick, David Cock, Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt, Rafal Kolanski, Michael Norrish, et al. sel4: Formal verification of an os kernel. In ACM SOSP, pages 207–220, 2009. [42] Jonghoon Kwon, Claude Hähni, Patrick Bamert, and Adrian Perrig. Mondrian: Comprehensive inter-domain network zoning architecture. In NDSS, 2021. [43] Jonghoon Kwon, Taeho Lee, Claude Hähni, and Adrian Perrig. Svlan: Secure & scalable network virtualization. In NDSS, pages 498–512, 2020. [44] Ravie Lakshmanan. Microsoft confirms server misconfiguration led to 65,000+ companies’ data leak, 2022. [45] Adrian Shuai Li, Reihaneh Safavi-Naini, and Philip WL Fong. A capability-based distributed authorization system to enforce context-aware permission sequences. In ACM SACMAT, pages 195–206, 2022. [46] Soo Yee Lim, Bogdan Stelea, Xueyuan Han, and Thomas Pasquier. Secure namespaced kernel audit for containers. In ACM SoCC, page 518–532, 2021. [47] Red Hat Enterprise Linux. Capacity tuning. https://docs.redhat.com/en/doc umentation/red_hat_enterprise_linux/6/html/performance_tuning_guide/smemory-captun. [48] Fucheng Liu, Yu Wen, Dongxue Zhang, Xihe Jiang, Xinyu Xing, and Dan Meng. Log2vec: A heterogeneous graph embedding based approach for detecting cyber threats within enterprise. In ACM CCS, pages 1777–1794, 2019. [49] Zaoxing Liu, Hun Namkung, Georgios Nikolaidis, Jeongkeun Lee, Changhoon Kim, Xin Jin, Vladimir Braverman, Minlan Yu, and Vyas Sekar. Jaqen: A HighPerformance Switch-Native approach for detecting and mitigating volumetric DDoS attacks with programmable switches. In USENIX Security, pages 3829–3846, 2021. [50] Zitao Liu and Sangyeun Cho. Characterizing machines and workloads on a google cluster. In IEEE ICPP, pages 397–403, 2012. [51] Allied Analytics LLP. Network access control market report 2032: Trends, size and opportunities. https://www.openpr.com/news/4468021/network-accesscontrol-market-report-2032-trends-size, 2026. [52] Mandiant. Unc5537 targets snowflake customer instances for data theft and extortion. https://cloud.google.com/blog/topics/threat-intelligence/unc5537snowflake-data-theft-extortion, 2024. [53] Sarah McClure, Zeke Medley, Deepak Bansal, Karthick Jayaraman, Ashok Narayanan, Jitendra Padhye, Sylvia Ratnasamy, Anees Shaikh, and Rishabh Tewari. Invisinets: Removing networking from cloud networks. In USENIX NSDI, pages 479–496, 2023. [54] Adrian Matthew Mettler, David A. Wagner, and Tyler Close. Joe-e: A securityoriented subset of java. In NDSS, 2010. [55] Rui Miao, Hongyi Zeng, Changhoon Kim, Jeongkeun Lee, and Minlan Yu. Silkroad: Making stateful layer-4 load balancing fast and cheap using switching asics. In SIGCOMM, page 15–28, 2017. [56] MITRE. Access token manipulation: Token impersonation/theft. https://attack .mitre.org/techniques/T1134/001/, 2025. [57] MITRE. Exploitation of remote services. https://attack.mitre.org/techniques/T1 210/, 2025. [58] MITRE. Remote service session hijacking. https://attack.mitre.org/techniques/ T1563/, 2025. [59] Luke Nelson, Jacob Van Geffen, Emina Torlak, and Xi Wang. Specification and verification in the field: Applying formal methods to BPF just-in-time compilers

in the linux kernel. In OSDI, pages 41–61, 2020. [60] NIST. Cve-2004-2687 detail. https://nvd.nist.gov/vuln/detail/CVE-2004-2687, 2008. [61] NIST. Cve-2020-8835 detail. https://nvd.nist.gov/vuln/detail/CVE-2020-8835, 2020. [62] NIST. Cve-2021-44228 detail. https://nvd.nist.gov/vuln/detail/cve-2021-44228, 2021. [63] NIST. Cve-2023-39191 detail. https://nvd.nist.gov/vuln/detail/CVE-2023-39191, 2023. [64] NIST. Cve-2025-1974 detail. https://nvd.nist.gov/vuln/detail/CVE-2025-1974, 2025. [65] Riccardo Paccagnella, Pubali Datta, Wajih Ul Hassan, Adam Bates, Christopher Fletcher, Andrew Miller, and Dave Tian. Custos: Practical tamper-evident auditing of operating systems using trusted execution. In NDSS, 2020. [66] Sofia Ramirez. Cyber threat statistics 2025: Costs, targets, and best practices, 2025. [67] Rapid7. Metasploit framework. https://docs.rapid7.com/metasploit/msf overview/, 2008. [68] Jerome H Saltzer and Michael D Schroeder. The protection of information in computer systems. Proc. IEEE, pages 1278–1308, 1975. [69] R Sekar, Hanke Kimm, and Rohit Aich. eaudit: A fast, scalable and deployable audit data collection system. In IEEE S&P, pages 87–87, 2024. [70] Ax Sharma. Doordash hit by new data breach in october exposing user information. https://www.bleepingcomputer.com/news/security/doordash-hit-by-newdata-breach-in-october-exposing-user-information/, 2025. [71] Siyuan Sheng, Huancheng Puyang, Qun Huang, Lu Tang, and Patrick PC Lee. { Farreach } : Write-back caching in programmable switches. In USENIX ATC, pages 571–584, 2023. [72] John Sonchack, Oliver Michel, Adam J. Aviv, Eric Keller, and Jonathan M. Smith. Scaling hardware accelerated network monitoring to concurrent and dynamic queries with *Flow. In USENIX ATC, pages 823–835, 2018. [73] Haoyu Song, Todd Sproull, Michael Attig, and John Lockwood. Snort offloader: A reconfigurable hardware nids filter. In IEEE FML, pages 493–498, 2005. [74] Melissa J. M. Turcotte, Alexander D. Kent, and Curtis Hash. Unified Host and Network Data Set, pages 1–22. World Scientific, 2018. [75] Abhishek Verma, Luis Pedrosa, Madhukar Korupolu, David Oppenheimer, Eric Tune, and John Wilkes. Large-scale cluster management at google with borg. In EuroSys, pages 1–17, 2015. [76] Arbaugh W. and Opstal M. Operationally transparent cyber datase, 2020. [77] Liang Wang, Hyojoon Kim, Prateek Mittal, and Jennifer Rexford. Raven: Stateless rapid ip address variation for enterprise networks. In PETS, 2023. [78] Robert NM Watson, Jonathan Woodruff, Peter G Neumann, Simon W Moore, Jonathan Anderson, David Chisnall, Nirav Dave, Brooks Davis, Khilan Gudka, Ben Laurie, et al. Cheri: A hybrid capability-system architecture for scalable software compartmentalization. In IEEE S&P, pages 20–37, 2015. [79] Kitty Wheeler. Top 10: Biggest cyber threats, 2025. [80] Jiarong Xing, Kuo-Feng Hsu, Yiming Qiu, Ziyang Yang, Hongyi Liu, and Ang Chen. Bedrock: Programmable network support for secure RDMA systems. In USENIX Security, pages 2585–2600, 2022. [81] Jiarong Xing, Qiao Kang, and Ang Chen. NetWarden: Mitigating network covert channels while preserving performance. In USENIX Security, pages 2039–2056, 2020. [82] Jiarong Xing, Qiao Kang, and Ang Chen. { NetWarden } : Mitigating network covert channels while preserving performance. In USENIX Security, pages 2039– 2056, 2020. [83] Jiarong Xing, Wenqing Wu, and Ang Chen. Ripple: A programmable, decentralized Link-Flooding defense against adaptive adversaries. In USENIX Security, pages 3865–3881, 2021. [84] Sophia Yoo, Xiaoqi Chen, and Jennifer Rexford. Smartcookie: Blocking largescale syn floods with a split-proxy defense on programmable data planes. In USENIX Security, 2024. [85] Jason Zhijingcheng Yu, Conrad Watt, Aditya Badole, Trevor E Carlson, and Prateek Saxena. Capstone: A capability-based foundation for trustless secure memory access. In USENIX Security, pages 787–804, 2023. [86] Tianlong Yu, Seyed Kaveh Fayaz, Michael P Collins, Vyas Sekar, and Srinivasan Seshan. Psi: Precise security instrumentation for enterprise networks. In NDSS, 2017. [87] Menghao Zhang, G. Li, Shicheng Wang, Chang Liu, Ang Chen, Hongxin Hu, Guofei Gu, Qi Li, Mingwei Xu, and Jianping Wu. Poseidon: Mitigating volumetric ddos attacks with programmable switches. In NDSS, 2020. [88] Zhipeng Zhao, Hugo Sadok, Nirav Atre, James C Hoe, Vyas Sekar, and Justine Sherry. Achieving 100gbps intrusion prevention on a single server. In USENIX OSDI, pages 1083–1100, 2020. [89] Huancheng Zhou, Sungmin Hong, Yangyang Liu, Xiapu Luo, Weichao Li, and Guofei Gu. Mew: Enabling large-scale and dynamic link-flooding defenses on programmable switches. In IEEE S&P, pages 3178–3192, 2023.

Related documents

• Breaking Ambient Trust: In-Network Per-Process Access Control Against Lateral Movement#799226
• Breaking Ambient Trust: In-Network Per-Process Access Control Against Lateral Movement#797803
• Okay, Google, Can I Trust You? An Anti-trust Argument for Antitrust#86047
• Pirateship: Append-Only Ledgers for (Mostly) Trusted Execution Environments#1084127
• When Derived Measurements Mislead: Quantifying and Mitigating LLM Over-Trust with Privileged-Modality Reliability Evidence#414151