# Dynamic transmission scheduling method for high-concurrent zero trust access control

Taisho Sasada, Christophe Kiennert, Gregory Blanc, Yuzo Taenaka, Youki Kadobayashi

► To cite this version:

Taisho Sasada, Christophe Kiennert, Gregory Blanc, Yuzo Taenaka, Youki Kadobayashi. Dynamic transmission scheduling method for high-concurrent zero trust access control. 20th International Conference on Availability, Reliability and Security (ARES), Aug 2025, Ghent, Belgium. pp.324-341, 10.1007/978-3-032-00633-2_19. hal-05446750

HAL Id: hal-05446750

https://hal.science/hal-05446750v1

Submitted on 7 Jan 2026

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_1.png" /></figure>
Dynamic Transmission Scheduling Method for
High-Concurrent Zero Trust Access Control

Taisho Sasada¹, Christophe Kiennert², Gregory Blanc², Yuzo Taenaka¹, and
Youki Kadobayashi¹

¹ Graduate School of Science and Technology, Nara Institute of Science and Technology, Japan

² SAMOVAR, Télécom SudParis, Institut Polytechnique de Paris, France
 taisho.sasada@naist.ac.jp,
 {christophe.kiennert, gregory.blanc}@telecom-sudparis.eu,
 {yuzo,youki-k}@is.naist.jp

**Abstract.** In remote work environments, once account authentication is completed, users can continue accessing confidential data without their authenticity verification (proof of being the legitimate user with proper access rights). This poses a risk when the device or authentication credentials are hijacked by attackers after authentication, the authenticity becomes compromised. To address this, Zero Trust Access Control (ZTAC) monitors and utilizes behavior information unique to each user without trusting any access requests, enabling access control while continuously ensuring user authenticity after authentication. However, collecting behavioral information necessary for user authenticity verification creates a critical trade-off: more detailed monitoring increases traffic load, necessitating longer intervals between behavior information updates. These extended intervals create security vulnerabilities, as modern ransomware can complete lateral movement within minutes, potentially exploiting these update gaps when the system cannot respond quickly enough. In this paper, we propose a highly concurrent ZTAC architecture to address this challenge. Our system dynamically schedules monitoring intervals based on real-time network status and concurrent connection load, shortening transmission intervals when suspicious behavior is detected to intensify behavioral monitoring. However, this approach can lead to false positives, thus our verification process introduces temporary blocking as an intermediate state between permission and denial. By allowing access after a short waiting period, we minimize false detections while effectively delaying lateral movement by adversaries. Through implementation and evaluation experiments, we demonstrated that our proposed system reduced processing time in high-concurrency environments with over 10,000 concurrent connections and effectively detected and prevented unauthorized access attempts while maintaining operational efficiency.

**Keywords:** Zero Trust · Access Control · Transmission Scheduling · Single Packet Authorization
# 1 Introduction

In recent years, malware attacks targeting data, such as OrBit, WannaCry and NotPetya, have become serious threats. Data-driven services and applications continue to increase daily, making it essential to secure proper security for safe data management [1, 2]. Traditionally, security measures focused on perimeter defense using firewalls and Intrusion Detection Systems to block unauthorized access by separating internal and external networks [3]. However, with the widespread adoption of cloud services and remote work becoming commonplace, the boundary between internal and external networks has become increasingly blurred. In such ambiguous network situations, it has become difficult to completely prevent attacker's penetration, leading to a growing need to control access by not trusting data access from either internal or external networks.

As a result, organizations are transitioning from perimeter defense to Zero Trust Access Control (ZTAC) [3–10]. In ZTAC, all access requests, whether internal or external, are not trusted, and authentication and authorization are performed dynamically based on monitored behavioral information for each access attempt. Specifically, ZTAC uses verification algorithms to determine allow/-deny decisions based on information such as IP address, access location, time, device ID, OS and browser versions, security patch status, antivirus software status, and security alerts, enabling dynamic access control. This enables security to be maintained without unconditionally trusting even internal networks. However, monitoring this information alone cannot guarantee user authenticity (whether the user operating an account is the legitimate account holder). Therefore, additional monitoring of user-specific behavioral information (such as keyboard typing and mouse movement patterns) [5, 9, 10] and device-specific information (such as device fingerprints and hardware configurations) [4, 6, 7] is used for access control.

Attempting to constantly monitor and collect more information to guarantee user authenticity increases the traffic load per access, resulting in the constraint of having to lengthen the monitoring information update interval (MIUI) [11]. While longer MIUIs enable more accurate collection of user behavioral data (e.g. keystroke patterns, mouse hovering behavior) leading to more appropriate access control decisions in ZTAC, they also create vulnerabilities. If anomaly conditions arise due to malware or attacker intrusion into endpoints during MIUI, access control cannot respond to and track these changes in situation. Some malware, such as OrBit, WannaCry and NotPetya, completes lateral movement in about 10 minutes of infection [12], spreading horizontally across the same network to expand its compromise to other endpoints. Therefore, existing technologies that require a certain amount of time to update monitoring information are clearly insufficient to respond in time. On the other hand, reducing the collected behavioral information leads to decreased accuracy in continuous authentication/authorization, which is a core function of ZTAC. Resolving this trade-off is a crucial challenge in implementing ZTAC.

To ensure authenticity and appropriate access control in multi-user access scenarios, this paper proposes a ZTAC architecture that can adaptively schedule
each user's MIUI according to concurrent connection conditions and network load. We use Single Packet Authorization (SPA), which enables authentication prior to establishing communication and efficiently transmits authentication/authorization information in a single packet, to include device and user behavior information in one packet. When blocking access through packet verification, our system chooses between complete blocking or pending depending on the situation, allowing communication to resume after a certain period if it is not an attack. However, when the system detects abnormal behavior, it shortens the MIUI, and subsequently gradually adjusts the interval in accordance with increasing network load. This achieves a high-concurrent ZTAC that appropriately controls access based on behavioral information while minimizing traffic load for authentication and authorization for each user.

**Outline.** In Section 2, we review related work on ZTAC. Section 3 presents the threat model in this study. In Section 4, we describe the proposed system architecture. In Section 5, we detail the implementation and experimental evaluation. Finally, we conclude the paper with future work in Section 6.

## 2 Related Work

Security architecture in information systems has evolved from perimeter-based defense to Zero Trust Architecture (ZTA), which implements more granular control. Perimeter-based defense is a security model that prevents unauthorized access from external sources by placing firewalls and Intrusion Detection Systems at the boundary between an organization's internal and external networks. In perimeter-based defense, the internal network is treated as a trusted zone, meaning that once inside, resources can be accessed relatively freely. However, with the sophistication of targeted attacks and malware, it has become increasingly difficult to completely prevent intrusion into internal networks, and unconditionally trusting the internal network puts resources at risk.

In contrast, ZTA as defined by NIST SP800-207 [13], maintains security by following the principle of “never trust, always verify” and requires authentication and authorization based on various monitoring behaviors without placing implicit trust in access requests. Figure 1 shows the configuration of ZTA. The main components are Subject, Resource, Policy Enforcement Point (PEP), and Policy Decision Point (PDP). In this paper, Subject refers to users and endpoints. Resource is the target that Subjects access, including various network services and databases. PDP is the function that determines whether to allow or deny Subject access to Resources. PEP is installed on the communication path between Subject and Resource and allows or blocks communication according to PDP decisions.

Many ZTAC systems based on ZTA have been proposed and summarized by Azad et al. [14]. Simply collecting IP addresses and timestamps is insufficient for the PDP to verify authenticity (whether the user is the legitimate device owner or account holder) and for the PEP to implement appropriate access control. Consequently, ZTAC systems that utilize user-specific behaviors and device-specific
<figure><img src="image_2.png" /><figcaption>Fig. 1. Zero Trust Architecture</figcaption></figure>

information for verification have been proposed. In research utilizing device-
specific information, Huang et al. [7] added monitoring items such as network
connection patterns and resource usage statistics including CPU/memory uti-
lization. To block access from devices with high security risks, García-Teodoro
et al. [6] monitored device patch status, security configuration values, running
process lists, and installed software information. To deny access from unautho-
rized or tampered devices, Yao et al. [4] added monitoring items such as device
hardware characteristics and firmware versions. In research utilizing user-specific
behaviors, Lei et al. [15] enhanced verification capabilities by adding user location
information as a monitoring item and verifying its consistency with IP addresses
and timestamps. Sasada et al. [5, 10] added browser input operations such as
clicks, keystrokes, and page transition speeds as monitoring items to accurately
capture user behavior and cognition. However, increasing monitoring items for
PDP verification results in massive data volume per packet, causing verification
overload on the PDP in ZTAC systems that perform access control for each re-
quest. Additionally, since it takes time for monitoring items to be fully updated,
if access occurs before changes in monitoring items are properly reflected, se-
quential control becomes insufficient, preventing proper access authorization or
denial.

We use SPA to solve these problem, but despite having different motivations
from this research, several other studies have adopted SPA in ZTA. Kataoka
et al.'s NI-SPA [16] positions network devices as information providers during
SPA packet forwarding, leveraging behavioral information from within the net-
work that would be difficult for individual clients to collect. While this approach
successfully achieves spatial expansion of information sources, it maintains fixed
patterns for temporal control of information transmission, without implement-
ing dynamic transmission interval adjustments based on network load or threat
levels. Xu et al. [17] propose a method to address the vulnerability of the entire
system when a single policy engine comes under attack by deploying multi-
ple authentication engines in parallel, each configured with different software compositions. After each engine independently processes SPA authentication, a final decision is made through majority voting. This structural redundancy improves resistance against coordinated attacks exploiting the same vulnerability, but insufficient consideration has been given to processing time variations among multiple engines and dynamic load balancing control in response to increasing concurrent connections.

## 3 Threat Model

This section defines the system settings and threat model assumed in this research. As a system prerequisite, we assume deployment within an enterprise network environment similar to other works [18–20] related to this research. Specifically, the system requires a common communication path through which all TCP/UDP packets from any Subject to any Resource must pass, and where a PEP can be installed. This requirement is essential to ensure authorization decisions can be made reliably for all communications. Additionally, we assume a network environment where communication delay variations between Subjects and confidential data destinations are less than 100 milliseconds, with minimal fluctuations. This condition is necessary to properly control the timing of authorization request packets and TCP SYN packets, enabling efficient communication establishment. Particularly in countermeasures against malware, stable communication conditions are crucial as authorization processing delays directly impact defense effectiveness. These conditions are typically met in standard LANs and corporate networks.

Regarding threats, this research primarily assumes two types of adversaries: (1) Malware operators, (2) Insider threats. (1) represents operators of malware, who aim to propagate infection throughout organizational networks using malware such as OrBit, WannaCry and NotPetya. These types of malware initiate infection activities targeting other endpoints, causing damage to expand and completing infection across the entire target network in approximately 10 minutes [12]. (2) represents insider threats who obtain legitimate users' authentication credentials (IDs, passwords, etc.) through unauthorized means, aiming to exfiltrate organizational confidential information and intellectual property. Unlike the first type, these adversaries, being familiar with the system environment, avoid unnecessary lateral movement and attempt to access confidential resources through the shortest path. Such efficient unauthorized access cannot be prevented by standard authentication methods. Even in ZTAC, distinguishing these actors from legitimate account holders becomes difficult when relying solely on information like access time and IP addresses, necessitating access control based on access patterns and behavior.

From an attack perspective, this research excludes physical attacks, power interruptions, DDoS attacks, and direct attacks against the system's constituent software. These attacks fall outside our scope because their defense mechanisms belong to domains different than access control, which is the primary focus of this
research. These threats should be addressed through existing physical security measures and availability assurance mechanisms. The User-Agent, which monitors user behavior, is assumed to have sufficient security measures in place and is not included as an attack target. The execution privileges of the User-Agent processes are constrained to the minimum necessary level, and it is designed not to collect user behavior information beyond its intended scope.

# 4 Proposed System

In conventional ZTAC, there exists a trade-off in continuous behavior monitoring after user authentication: attempting to collect more behavioral information increases communication overhead, forcing longer MIUI. The proposed method addresses this challenge by combining three key technologies. First, it extends SPA to design an architecture that authenticates and authorizes both endpoint and user behavioral information in a single packet. Second, it designs a multi-stage trust algorithm that selects between complete blocking or pending based on verification, depending on the circumstances. Finally, it adaptively schedules the transmission timing of authorization request packets and communication initiation packets to prevent timing attacks and control errors in MIUI.

## 4.1 System Design

**Architecture.** We show the architecture of the proposed method in Figure 2. Similar to SPA, the proposed method consists of Subject, Resource, PDP, and PEP. The Subject incorporates a User-Agent that makes access authorization requests to the PEP based on device and user behaviors. The User-Agent is responsible for monitoring behavior, compressing information, sending authorization requests, and storing behavioral information. The PDP not only manages relatively static information such as access policies and job positions but also evaluates access requests and makes authorization decisions based on these policies. The PEP enforces these decisions by querying the PDP and acting on its responses. For information that changes infrequently and has low real-time requirements (access policy scripts, resource confidentiality levels, user positions, etc.), authorization decisions queried from PDP to PEP are cached for a certain period to reduce PDP-PEP communication volume. The PEP is located either on the same computer as the Resource or on the communication path connecting the Subject and Resource, and intercepts access request packets directed from Subject to Resource. The PEP is responsible for managing and applying access policies, validating authorization request packets, expanding compressed information, making access authorization decisions, and controlling access requests. By combining policies and static information obtained from the PDP with dynamic behavioral information sent from the Subject, it achieves fine-grained access control.
<figure><img src="image_3.png" /><figcaption>Fig. 2. Sequence Diagram of the Proposed System</figcaption></figure>

**Authorization Flow.** The detailed flow of access requests from Subject to Resource is explained in three phases: Request Phase, Authorization Phase, and Access Control Phase. At the start of the communication, the Subject generates a TCP SYN packet as a connection request to the Resource. This packet contains essential information needed for communication, including the source IP address, destination IP address, and destination port number (Process ① in Figure 2). Next, the User-Agent, which runs continuously on the Subject, intercepts the TCP SYN packet at the network stack. The intercepted packet is not immediately transmitted but is temporarily buffered and remains in a pending state until the authorization request packet is completely sent. The User-Agent generates an SPA packet (authorization request packet) containing information necessary for authorization decisions. First, it collects behavioral information such as process lists, service status, and communication history (Process ②). Next, it applies irreversible compression to list-type information, reducing it to a size that can fit into a single UDP packet (Process ③). Then, it encrypts the entire packet with an AES key and adds an HMAC for tampering detection. Finally, it generates a digital signature using the User-Agent's private key and appends it to the packet (Process ④). The User-Agent sends the generated SPA packet to the PEP using UDP protocol (Process ⑤). After transmission, it waits for an interval time dynamically determined based on past transmission history and processing status, then sends the buffered TCP SYN packet. The PEP forwards the received SPA packet to the PDP, which performs multi-stage verification using trust algorithms (Process ⑥). First, it verifies the digital signature to confirm the packet's authenticity, then decrypts the AES-encrypted content. Afterwards, it expands the compressed information while matching it against keywords specified in the access policy. The PDP returns verification
results to the PEP (Process ⑦). The PEP performs authorization decisions by matching the expanded behavioral information against access policy scripts. It verifies Subject/Resource attributes and evaluates whether the collected behavioral information meets the specified conditions. When multiple policies exist, evaluation is conducted according to their respective priorities. Based on the policy evaluation results, the PEP implements access control. If authorized, TCP communication is allowed for the $τ_{allow}$ period (default 3 seconds). In case of authorization failure, access is blocked for the $τ_{deny}$ period, while for pending, communication is allowed for the $τ_{allow}$ period after the $τ_{deny}$ period expires. When authorized, the Subject's TCP SYN packet reaches the Resource, and communication is established through normal TCP 3-way handshake.

## 4.2 Trust Algorithm

Traditional access control with simple binary decisions (permit or deny) can lead to significant problems when misclassifications occur. Especially when classified as “deny”, legitimate users are completely prevented from accessing services, severely compromising availability. On the other hand, relaxing the “permit” criteria increases the risk of data leakage through malware or insider threats. Our trust algorithm addresses this issue by introducing a multi-stage authorization with “pending”. In “pending”, after a denial period of $τ_{deny}$, access from the same device to the Resource is unconditionally permitted for a period of $τ_{allow}$. This provides a recovery mechanism for devices incorrectly identified as high-risk, even if they are not actually associated with insider threats or malware, by allowing a period for communication to resume later. By implementing pending rather than complete blocking, we can delay the lateral movement of malware. Simultaneously, legitimate users who were misclassified can access services after a short waiting period, thus minimizing the impact of misclassifications.

The main loop process in Algorithm 1 controls the continuous operation of the entire system, implementing the flow from packet reception to execution in an infinite loop, representing the basic operation of a continuously running system. Within this loop, verification and authorization processes are executed sequentially. The algorithm begins with packet reception function $\mathcal{R}: \emptyset \to \mathcal{P}$, where $\mathcal{P}$ denotes the packet space, followed by policy matching function $\mathcal{M}: \mathcal{P} \to \Pi$ that maps each packet $p$ to an appropriate policy $\pi$ from the policy space $\Pi$. The core verification and authorization is performed by function $\mathcal{V}: \mathcal{P} \times \Pi \to \mathcal{D}$, which returns a decision $r$ from the decision space $\mathcal{D} = \{allow, deny, pending, false, null\}$. Based on the verification result $r$, the system executes appropriate actions through function $\mathcal{A}: \text{ActionType} \to \text{Effect}$. For denial cases, the system employs a pending check function $\mathcal{I}: \emptyset \to \{0, 1\}$ to determine whether to apply complete blocking or pending. When pending is selected, the scheduling function $\mathcal{S}: \text{IP} \times \mathbb{R}_{>0} \to \text{Schedule}$ manages the timing for access resumption. The cache update function $\mathcal{U}: \emptyset \to \text{CacheState}$ maintains system state consistency.

The packet verification process in Algorithm 2 performs authenticity verification and content analysis of authorization request packets. It implements
<table><caption>**Algorithm 1** Multi-Stage Trust Algorithm</caption><tr><td>1:</td><td>loop</td><td></td></tr><tr><td>2:</td><td>p &larr; 𝒜()</td><td>&Delta; 𝒜: ∅ &rarr; 𝒫 (packet reception)</td></tr><tr><td>3:</td><td>&pi; &larr; 𝒜(p)</td><td>&Delta; 𝒜: 𝒫 &rarr; Π (policy matching)</td></tr><tr><td>4:</td><td>r &larr; 𝒩(p, &pi;)</td><td>&Delta; 𝒩: 𝒫 &times; Π &rarr; 𝒫 (verification)</td></tr><tr><td>5:</td><td>if r &isin; {false, null} then</td><td></td></tr><tr><td>6:</td><td> A("drop")</td><td>&Delta; A: ActionType &rarr; Effect</td></tr><tr><td>7:</td><td> else if r = "allow" then</td><td></td></tr><tr><td>8:</td><td> A("accept")</td><td></td></tr><tr><td>9:</td><td> else</td><td></td></tr><tr><td>10:</td><td> if 𝒫() = true then</td><td>&Delta; 𝒫: ∅ &rarr; {0, 1} (pending check)</td></tr><tr><td>11:</td><td> S(p.source, &tau;<sub>deny</sub>)</td><td>&Delta; S: IP &times; ℝ<sub>&gt;0</sub> &rarr; Schedule</td></tr><tr><td>12:</td><td> A("pending")</td><td></td></tr><tr><td>13:</td><td> else</td><td></td></tr><tr><td>14:</td><td> A("deny")</td><td></td></tr><tr><td>15:</td><td> end if</td><td></td></tr><tr><td>16:</td><td> end if</td><td></td></tr><tr><td>17:</td><td> U()</td><td>&Delta; U: ∅ &rarr; CacheState (cache update)</td></tr><tr><td>18:</td><td> end loop</td><td></td></tr></table>

digital signature verification function $V_{\sigma}: \mathcal{P} \to \{0, 1\}$ and decryption using AES keys managed by cache function $C: S \to K$, where $S$ represents the signature space and $K$ the key space. When a signature is confirmed, the AES key is cached to improve processing efficiency by omitting public key cryptography operations in subsequent packet verifications through the AES key decryption function $D_{\text{AES}}: \mathcal{P} \to K$. The system converts behavior information bit arrays compressed within the packet back to original keywords using the bitmap conversion function $B: \{0, 1\}^m \to 2^{\text{Keywords}}$, and matches the information obtained from the packet with access policies. It evaluates three conditions: Subject attributes, Resource attributes, and Context conditions based on behavior information through evaluation functions $\phi_s, \phi_r, \phi_c$: Request $\times$ Policy $\to \{0, 1\}$. When all conditions are met, it returns an allow or deny decision according to the policy's effect. In this case, for allow decisions, a permission period of $\tau_{\text{allow}}$ is set, while for deny decisions, a blocking period of $\tau_{\text{deny}}$ is established. Conversely, when a deny decision is made, the system implements either complete blocking or pending according to system settings. In the case of pending, the system includes a mechanism to resume communication after $\tau_{\text{deny}}$ has elapsed, mitigating the impact of false detections. If packet verification fails or no appropriate policy is found, the packet is discarded according to the default-deny principle.

## 4.3 Dynamic Transmission Scheduling

We show the detail of dynamic transmission scheduling in Algorithm 3 and Algorithm 4. The authorization request packet scheduling algorithm proposed
<caption>**Algorithm 2 Verification and Authorization Process**</caption>

1: **function** $V(p, \pi)$ ▷ $V: \mathcal{P} \times \Pi \to \mathcal{D}$
2:   **if** $p.\sigma \notin C$ **then** ▷ $C: S \to K$ (AES key cache)
3:   $k \leftarrow D_{AES}(p)$ ▷ $D_{AES}: \mathcal{P} \to K$ (key decryption)
4:   **if** $V_\sigma(p) = \text{true}$ **then** ▷ $V_\sigma: \mathcal{P} \to \{0, 1\}$ (signature verification)
5:   $C[p.\sigma] \leftarrow k$
6:   **else**
7:   **return** false
8:   **end if**
9:   **end if**
10:  $d \leftarrow D_{AES}(p.\text{data}, C[p.\sigma])$ ▷ $D_{AES}: \{0, 1\}^* \times K \to \mathcal{B}$
11:  $\text{req} \leftarrow \{\text{data}: d, \text{behavior}: \mathcal{B}(p.\text{ bitmap})\}$ ▷ $\mathcal{B}: \{0, 1\}^m \to 2^{\text{Keywords}}$
12:  **if** $\phi_s(\text{req}, \pi.\text{subject}) \land \phi_r(\text{req}, \pi.\text{resource}) \land \phi_c(\text{req}, \pi.\text{context})$ **then** ▷
13:   $\phi_s, \phi_r, \phi_c$: Request $\times$ Policy $\to \{0, 1\}$
14:  **return** $\pi$.effect
15:  **end if**
16:  **return** null
17: **end function**

in this research implements a dynamic control mechanism composed of a primary control function $P_{req}: \emptyset \to \perp$ and an auxiliary function $I: \mathbb{R}_{\ge 0} \times \mathbb{R}_{> 0} \times \mathbb{R}_{> 0} \to \mathbb{R}_{> 0}$ to optimize both monitoring information volume and network load. The main processing function $P_{req()}$ runs continuously in an infinite loop, enabling dynamic transmission scheduling based on system state.

During normal operation, the system conducts periodic monitoring based on a standard interval $\tau_0$. In this process, the packet capture function $C_{pkt}: \emptyset \to \mathcal{P}$ first captures access request packets, and the PEP address resolution function $G_{PEP}: \mathcal{IP} \to \text{PEPAddr}$ identifies the corresponding PEP address. Then, the transmission counting function $\mathcal{N}: \text{PEPAddr} \times \mathcal{P} \times \mathbb{R}_{> 0} \to \mathbb{N}$ calculates the number of authorization request packet transmissions $n$ to the PEP within the recent $\tau_{req}$ time period. The authorization packet transmission function $\mathcal{T}_{auth}: \text{PEPAddr} \to \text{Effect}$ executes the transmission of authorization request packets when either the transmission count $n$ is 0 or when a random number generated by $\mathcal{R}: \emptyset \to [0, 1]$ falls below the packet loss probability $\epsilon_{loss}(n)$.

If the PDP detects abnormal behavior patterns, it shifts from fixed intervals to dynamic transmission scheduling. Specifically, when events such as suspicious process execution, abnormal access patterns, or matches with known attack signatures are observed, the interval calculation function $\mathcal{I}: \mathbb{R}_{\ge 0} \times \mathbb{R}_{> 0} \times \mathbb{R}_{> 0} \to \mathbb{R}_{> 0}$ implements dynamic scheduling of transmission intervals. This function calculates the elapsed time $\tau_{diff}$ from the difference between the last transmission time $\tau_{last}$ (obtained via the last transmission time function $\mathcal{L}: \text{PEPAddr} \times \mathcal{P} \to \mathbb{R}_{\ge 0}$) and the current time provided by $\mathcal{T}_{curr}: \emptyset \to \mathbb{R}_{\ge 0}$. When $\tau_{diff}$ is less than $\tau_{req}$, it applies exponential decay to significantly reduce the transmission interval. Conversely, the system autonomously reschedules transmission intervals in
<table><caption>**Algorithm 3 Authorization Request Packet Transmission Control**</caption><tr><td>1:</td><td>function $\mathcal{P}_{\text{REQ}}$</td><td>$\triangleright \mathcal{P}_{\text{req}} : \emptyset \to \perp$ (main control loop)</td></tr><tr><td>2:</td><td>while true do</td><td></td></tr><tr><td>3:</td><td>p &larr; $C_{\text{pkt}}$</td><td>$\triangleright C_{\text{pkt}} : \emptyset \to \mathcal{P}$ (packet capture)</td></tr><tr><td>4:</td><td>a &larr; $\mathcal{G}_{\text{PEP}}(p.dst)$</td><td>$\triangleright \mathcal{G}_{\text{PEP}} : \text{IP} \to \text{PEPAddr}$ (PEP address resolution)</td></tr><tr><td>5:</td><td>n &larr; $\mathcal{N}(a, p, \tau_{\text{req}})$</td><td>$\triangleright \mathcal{N} : \text{PEPAddr} \times \mathcal{P} \times \mathbb{R}_{>0} \to \mathbb{N}$ (count function)</td></tr><tr><td>6:</td><td>if $n = 0 \lor \mathcal{R}() < \epsilon_{\text{loss}}(n)$ then</td><td>$\triangleright \mathcal{R} : \emptyset \to [0, 1]$ (random generator)</td></tr><tr><td>7:</td><td>$\mathcal{T}_{\text{auth}}(a)$</td><td>$\triangleright \mathcal{T}_{\text{auth}} : \text{PEPAddr} \to \text{Effect}$ (auth packet send)</td></tr><tr><td>8:</td><td>end if</td><td></td></tr><tr><td>9:</td><td>$\tau_l \leftarrow \mathcal{L}(a, p)$</td><td>$\triangleright \mathcal{L} : \text{PEPAddr} \times \mathcal{P} \to \mathbb{R}_{\ge 0}$ (last transmission time)</td></tr><tr><td>10:</td><td>$\delta \leftarrow \mathcal{I}(\tau_l, \tau_{\text{req}}, \tau_0)$</td><td>$\triangleright \mathcal{I} : \mathbb{R}_{\ge 0} \times \mathbb{R}_{>0} \times \mathbb{R}_{>0} \to \mathbb{R}_{>0}$ (interval calc)</td></tr><tr><td>11:</td><td>$\mathcal{W}(\delta)$</td><td>$\triangleright \mathcal{W} : \mathbb{R}_{>0} \to \text{Effect}$ (wait/sleep)</td></tr><tr><td>12:</td><td>$\mathcal{T}_{\text{access}}(p)$</td><td>$\triangleright \mathcal{T}_{\text{access}} : \mathcal{P} \to \text{Effect}$ (access packet send)</td></tr><tr><td>13:</td><td>end while</td><td></td></tr><tr><td>14:</td><td>end function</td><td></td></tr></table>

<table><caption>**Algorithm 4 Auxiliary Function to Calculate Transmission Interval**</caption><tr><td>1:</td><td>function $\mathcal{I}(\tau_l, \tau_r, \tau_0)$</td><td>$\triangleright \mathcal{I} : \mathbb{R}_{\ge 0} \times \mathbb{R}_{> 0} \times \mathbb{R}_{> 0} \to \mathbb{R}_{> 0}$</td></tr><tr><td>2:</td><td>$\tau_d \leftarrow \mathcal{T}_{\text{curr}}() - \tau_l$</td><td>$\triangleright \mathcal{T}_{\text{curr}} : \emptyset \to \mathbb{R}_{\ge 0}$ (current time)</td></tr><tr><td>3:</td><td>if $\tau_r \le \tau_d$ then</td><td></td></tr><tr><td>4:</td><td>return $\tau_0$</td><td></td></tr><tr><td>5:</td><td>else</td><td></td></tr><tr><td>6:</td><td>return $\exp(\ln(\tau_0) - \frac{\tau_d}{\tau_0})$</td><td></td></tr><tr><td>7:</td><td>end if</td><td></td></tr><tr><td>8:</td><td>end function</td><td></td></tr></table>

response to increased network load. This scheduling is executed based on recent packet transmission status and network performance metrics. Specifically, when $\tau_{\text{diff}}$ is greater than or equal to $\tau_{\text{req}}$, it maintains standard transmission intervals based on $\tau_0$ while dispersing transmission timing according to network load.

The proposed algorithm executes packet transmission through the access packet transmission function $\mathcal{T}_{\text{access}} : \mathcal{P} \to \text{Effect}$ after waiting via the sleep function $\mathcal{W} : \mathbb{R}_{> 0} \to \text{Effect}$, following transmission intervals calculated by comprehensively evaluating these elements. This dynamic transmission scheduling simultaneously satisfies the conflicting requirements of efficient monitoring during normal operations, responsiveness during anomaly detection, and adaptation to network load.

# 5 Evaluation

## 5.1 Implementation

We implemented our system by using Go v1.16. The experiments were conducted on a Supermicro SYS-620U-TNR server equipped with dual Intel Xeon Silver
<table><caption>**Table 1.** List of Major Packages Used in Implementation</caption><thead><tr><td>Category</td><td>Go Package Name</td><td>Main Purpose</td></tr></thead><tbody><tr><td>Serialized/Deserialization</td><td>binary</td><td>Network byte order conversion</td></tr><tr><td>Buffer Processing</td><td>bytes</td><td>Variable-length data handling</td></tr><tr><td>Network</td><td>net</td><td>UDP communication</td></tr><tr><td>Synchronization</td><td>sync</td><td>Concurrency/pool management</td></tr><tr><td>Encryption</td><td>crypto</td><td>Hash generation</td></tr><tr><td>Error Handling</td><td>fmt</td><td>Error message handling</td></tr><tr><td>Logging</td><td>log</td><td>Application logging</td></tr><tr><td>Time Processing</td><td>time</td><td>Timestamp handling</td></tr><tr><td>Configuration Management</td><td>flag</td><td>Command-line parsing</td></tr><tr><td>Performance Measurement</td><td>runtime</td><td>Profiling implementation</td></tr></tbody></table>

4316 processors (20 cores each, 2.30 GHz) and 1TB RAM, running Red Hat Enterprise Linux 8.7. The core PDP in ZTAC consolidates access control policy evaluation logic in a structure called PolicyEngine, while the PEP handles packet reception and verification through a UDPReceiver structure, and applies policy decisions received from the PDP. The communication between PDP-PEP was implemented as in-process communication using Go's goroutines and channels. The Go packages used in the implementation and their purposes are shown in Table 1.

## 5.2 Performance

**Response Time.** To evaluate the impact of concurrent connections and access requests on authorization processing time, we conducted measurements at the PEP by varying the number of Subject concurrent connections [1, 10, 100, 1000, 10000] and access requests [1, 10, 100, 1000, 10000]. In this experiment, to evaluate the impact of scheduling methods on authorization processing, we conducted a performance comparison between static scheduling (transmission at fixed-length intervals) and our proposed dynamic scheduling method. Figure 3 shows the findings from the experimental results in: Under low load conditions (1-10 requests), both methods showed relatively similar performance, with processing times ranging from 0.1 to 0.5 milliseconds. However, when the number of requests exceeded 100, the static scheduling method began to show a linear increase in processing time relative to the number of concurrent connections. Particularly under conditions with 1000 requests, the static method's processing time increased up to approximately 350 milliseconds depending on the number of concurrent connections, while the dynamic method maintained processing times around 260 milliseconds. Under high load conditions with 10000 requests, the static method's processing time increased to a maximum of approximately 2700 milliseconds as concurrent connections increased, while the dynamic method maintained processing times around 2300 milliseconds. However, the difference between both decreases as the number of concurrent users increases Due to
<figure><img src="image_4.png" /><figcaption>Fig. 3. Execution Time</figcaption></figure>

the nature of dynamic scheduling interval control in the proposed method, it exhibited larger standard deviations proportional to the number of concurrent connections compared to the static method. This characteristic inevitably arises from the dynamic adjustment of transmission intervals.

**Data/Packet Size.** Some of the behavioral information monitored by the User-Agent can become relatively large in data size, making it difficult to store in a single packet in its original form. Therefore, the information compression module compresses the behavioral information to reduce data size. Traditional reversible compression methods like ZIP are highly ineffective for compressing list-type hash values with high randomness. As a solution, we compressed data via Probabilistic Data Structure (PDS). When storing data in PDS packets, hash functions are applied to each element, setting corresponding bit positions to 1. During verification, high-speed compression is achieved as it only requires checking the relevant bits using the same hash functions. The total packet size remains within OpenSPA's recommended value of 1,232 bytes [21]. We conducted experiments to evaluate the compression efficiency of authorization request packets using xxHash (Bloom Filters), one of PDS. As shown in Table 2, the most notable compression effect was observed in process hash information. We achieved approximately 83% compression, reducing the size from 2,400 bytes to 412 bytes. Similarly, substantial compression was achieved for both the list of applications and patch hash information, reducing from 1,488 bytes to 284 bytes and from 1,036 bytes to 244 bytes, respectively. On the other hand, numerical data such as suspicious access, keystroke/mouse input, traffic volume, address/port scans, generated file counts, executable file counts, and idle process counts showed no change in size between pre- and post-compression. This indicates that these items are already expressed using the minimum number of bytes, leaving limited room for optimization through additional compression. When totaling all monitoring items, the pre-compression size of 5,190 bytes significantly exceeds Ethernet's maximum frame size of 1,500 bytes. However, after compression, we achieved a reduction of approximately 77% to 1,206 bytes. This result satisfies the 1,232-bytes limit recommended by OpenSPA [21], allowing for transmission within a single Ethernet packet. However, there is a constraint where the PDS's bit array length increases proportionally with the number of elements to be registered. This is particularly relevant for process hash value lists, as environments
<table><caption>**Table 2.** The Average of Data Size in Monitored Items</caption><thead><tr><th>Item Name</th><th>Description</th><th>Original<br>(Bytes)</th><th>Compressed<br>(Bytes)</th></tr></thead><tbody><tr><td>Process Hash</td><td>List of hash values for running process</td><td>2,400</td><td>412</td></tr><tr><td>Application</td><td>List of hash values for applications</td><td>1,488</td><td>284</td></tr><tr><td>Patch Hash</td><td>List of hash values for software patch</td><td>1,036</td><td>244</td></tr><tr><td>Suspicious Access</td><td>List of hash values for destination hosts connected without access history</td><td>128</td><td>128</td></tr><tr><td>Keystroke/Mouse</td><td>Time since last user's input (seconds)</td><td>84</td><td>84</td></tr><tr><td>Header Fields</td><td>Version, ID, timestamps, etc.</td><td>32</td><td>32</td></tr><tr><td>Traffic Volume</td><td>Maximum outbound traffic volume</td><td>8</td><td>8</td></tr><tr><td>Address/Port Scan</td><td># of suspicious IP addresses connected</td><td>4</td><td>4</td></tr><tr><td>Generated File</td><td># of specific file types generated</td><td>4</td><td>4</td></tr><tr><td>Executable File</td><td># of executable files generated internally</td><td>4</td><td>4</td></tr><tr><td>Idle Process</td><td># of processes without execution history</td><td>2</td><td>2</td></tr><tr><td>Total</td><td></td><td>5,190</td><td>1,206</td></tr></tbody></table>

running numerous applications require registration of more elements, leading to increased bit array lengths.

**PDP Verification.** In verification using PDS in the PDP, false positive assessment is crucial for determining control reliability. Due to the inherent characteristics of PDS, there can be false positives where malicious processes that are not actually running on the terminal are incorrectly identified as running. Such misidentifications can potentially cause legitimate users to be unnecessarily blocked from access. We thus evaluated verification speed, False Positive Rate (FPR), and hash collision rate using three configurations: Config A (1KB/3 hash functions), Config B (2KB/5 hash functions), and Config C (4KB/7 hash functions). The results in Figure 4 show that verification times remained similar across configurations for fewer than 100 keywords, but Config C's processing time increased by approximately 25% at 1000 keywords due to additional hash function computation. Contrary to the original analysis, Figure 4 demonstrates that Config C consistently delivered the lowest FPR across all keyword volumes, with Config B showing moderate values and Config A exhibiting the highest FPR. This pattern occurs because the larger bit array sizes in Config B and C (2KB and 4KB respectively) provide sufficient space to distribute bits despite using more hash functions, thereby reducing collision probability. For hash collision rates, all configurations showed increases as keywords increased, with Config C reaching approximately 0.8 at 1000 keywords while Config A remained around 0.4. This inverse relationship between FPR and collision rate highlights the inherent trade-offs. In practical implementation, Config B offers a balanced approach between verification time, memory usage, and acceptable FPR, while Config C would be preferred for systems where minimizing false positives is paramount.
<figure><img src="image_5.png" /><figcaption>Fig. 4. PDP Verification Performance</figcaption></figure>

## 5.3 Security Analysis

The detection performance depends on specific monitoring items. As shown in Table 2, comprehensive monitoring items such as process hash lists, running processes, HotFix lists, and suspicious access lists contribute to malware detection. Additionally, monitoring items such as the number of idle processes, creation of executable files, and PowerShell script execution are effective in detecting malware activities that exhibit unusual behavior. For internal threats, monitoring items such as keystroke/mouse hover time effectively. These serve as indicators to identify differences in behavioral patterns between legitimate users and internal threat actors (who use authentication credentials without permission). The performance of access blocking using these monitoring items directly depends on the system's response time. Experimental results in Figure 3 show that the proposed method completes processing within approximately 300 milliseconds even under 1000 simultaneous connections and 1000 requests, and keeps processing time to about 2200 milliseconds with 10000 requests. This demonstrates the ability to respond before propagation is complete against malware, which complete lateral movement within 10 minutes. Furthermore, even if the number of keywords in the xxHash is increased, the PDP verification results in Figure 4 show that verification using these monitoring items as keywords completes in about 0.5 seconds even with 1000 keywords. Combined with the processing time in Figure 4, the system can make access control decisions within 3 seconds. This is fast enough to detect and block the activities of malware or internal threat actors that spread within 10 minutes, before substantial damage occurs.

In addition to addressing the threat model of this paper, this proposed architecture brought about several unexpected benefits. First, we initially use xxHash intended primarily for data size reduction, but ultimately proved valuable from a privacy protection perspective as well. The irreversible compression of user behavior information makes it difficult to reconstruct the original detailed behavioral data in the event of packet interception, reducing the risk of information leakage. Additionally, the proposed dynamic transmission scheduling, designed to dynamically adjust according to network load, has also contributed to improved resistance against DDoS attacks. The function that detects high-load
conditions and automatically adjusts transmission intervals has inadvertently taken on the aspect of a mitigation measure against DDoS attacks.

Lastly, we describe limitations of proposed architecture. Temporary blocking through a multi-stage trust algorithm mitigates immediate business interruptions due to false detections, but we should consider that this mechanism itself may pose security risks. Advanced targeted attacks could potentially develop methods to exploit the timing of these blocking releases. The system proposed in the paper includes a mechanism where an allowance period $\tau_{allow}$ is automatically set after a denial period ($\tau_{deny}$). This provides a potentially exploitable time window for attackers. Attackers can initially exhibit intentionally abnormal behavior to trigger temporary blocking and observe the system's response patterns. Once they understand this blocking/unblocking cycle, they can devise a strategy to launch concentrated attacks immediately after the $\tau_{deny}$ period ends. For example, malware lateral movement could be executed immediately following the blocking release to conduct reconnaissance activities or prepare payloads before the next blocking is activated, executing instantly at the moment of unblocking to maximize attack effectiveness. To address such vulnerabilities, countermeasures could include introducing randomness to the length of $\tau_{deny}$ and $\tau_{allow}$, extending $\tau_{deny}$ incrementally according to patterns of abnormal behavior, or transitioning from temporary blocking to complete blocking for repeatedly detected anomalies.

# 6 Conclusion

In this research, we proposed a new architecture for ZTAC that combines dynamic transmission interval scheduling with a multi-stage trust algorithm capable of allow/deny/temporary deny decisions to address the balancing continuous authenticity verification with network efficiency. Through implementation and evaluation experiments, we confirmed that the proposed method reduced processing time in environments with over 1,000 simultaneous connections and achieved detection and blocking of unauthorized accesses (including malware). Additionally, the introduction of temporary blocking functionality minimized the impact of false positives. As a future work, we have to consider two additional experiments: measuring detection time of infection activities and lateral movement tolerance using actual malware samples, as well as comparatively evaluating of PDP load reduction effects between the proposed method and reverse proxy-based ZTAC.

# ACKNOWLEDGEMENTS

This research has been supported by the Kayamori Foundation of Informational Science Advancement.
References

1. Fares Alharbi and Gautam Siddharth Kashyap. Empowering Network Security through Advanced Analysis of Malware Samples: Leveraging System Metrics and Network Log Data for Informed Decision-Making. *International Journal of Networked and Distributed Computing*, pages 1–15, 2024.

2. Craig Beaman, Ashley Barkworth, Toluwalope David Akande, Saqib Hakak, and Muhammad Khurram Khan. Ransomware: Recent Advances, Analysis, Challenges and Future Research Directions. *Computers & security*, 111:102490, 2021.

3. Songpon Teerakanok, Tetsutaro Uehara, and Atsuo Inomata. Migrating to Zero Trust Architecture: Reviews and Challenges. *Security and Communication Networks*, 2021(1):9947347, 2021.

4. Qigui Yao, Qi Wang, Xiaojian Zhang, and Jiaxuan Fei. Dynamic Access Control and Authorization System Based on Zero-Trust Architecture. In *Proceedings of the 2020 1st international conference on control, robotics and intelligent system*, pages 123–127, 2020.

5. Taisho Sasada, Yuto Masuda, Yuzo Taenaka, Youki Kadobayashi, and Doudou Fall. Zero-Trust Access Control Focusing on Imbalanced Distribution in Browser Click-streams. In *2021 Eighth International Conference on Software Defined Systems*, pages 1–8. IEEE, 2021.

6. Pedro García-Teodoro, José Camacho, Gabriel Maciá-Fernández, José Antonio Gómez-Hernández, and Victor José López-Marín. A novel Zero-Trust Network Access Control Scheme Based on the Security Profile of Devices and Users. *Computer Networks*, 212:109068, 2022.

7. Wenhua Huang, Xuemin Xie, Ziying Wang, JingYu Feng, Gang Han, and Wenbo Zhang. ZT-Access: A combining Zero Trust Access Control with Attribute-Based Encryption Scheme against Compromised Devices in Power IoT Environments. *Ad hoc networks*, 145:103161, 2023.

8. Taisho Sasada, Masataka Kawai, Yuto Masuda, Yuzo Taenaka, and Youki Kadobayashi. Factor Analysis of Learning Motivation Difference on Cybersecurity Training with Zero Trust Architecture. *IEEE Access*, 11:141358–141374, 2023.

9. Iurii Matiushin and Vladimir Korkhov. Continuous Authentication Methods for Zero-Trust Cybersecurity Architecture. In *International Conference on Computational Science and Its Applications*, pages 334–351. Springer, 2023.

10. Taisho Sasada, Yuzo Taenaka, Youki Kadobayashi, and Doudou Fall. Web-Biometrics for User Authenticity Verification in Zero Trust Access Control. *IEEE Access*, pages 129611–129622, 2024.

11. Yuanhang He, Daochao Huang, Lei Chen, Yi Ni, and Xiangjie Ma. A Survey on Zero Trust Architecture: Challenges and Future Trends. *Wireless Communications and Mobile Computing*, 2022(1):6476274, 2022.

12. Michael Akibis, Joaquin Pereira, David Clark, Victoria Mitchell, and Hugo Alvarez. Measuring Ransomware Propagation Patterns via Network Traffic Analysis: An Automated Approach. 2024.

13. Rose Scott, Borchert Oliver, Mitchell Stu, and Connelly Sean. NIST SP800-207: Zero Trust Architecture. Technical report, National Institute of Standards and Technology, 2020. Accessed: 2025-02-26.

14. Muhammad Ajmal Azad, Sidrah Abdullah, Junaid Arshad, Harjinder Lallie, and Yussuf Hassan Ahmed. Verify and Trust: A Multidimensional Survey of Zero-Trust Security in the Age of IoT. *Internet of Things*, 27:101227, 2024.
15. Lei Meng, Daochao Huang, Jiahang An, Xianwei Zhou, and Fuhong Lin. A Continuous Authentication Protocol without Trust Authority for Zero Trust Architecture. *China Communications*, 19(8):198-213, 2022.

16. Shinnosuke Kataoka, Daisuke Kotani, and Yasuo Okabe. NI-SPA: SPA-Based Dynamic Access Control Utilizing In-Network Behavior. In *Proceedings of the SIGCOMM Workshop on Zero Trust Architecture for Next Generation Communications*, pages 19–24, 2024.

17. Mingyang Xu, Junli Guo, Haoyu Yuan, and Xinyu Yang. Zero-Trust Security Authentication Based on SPA and Endogenous Security Architecture. *Electronics*, 12(4):782, 2023.

18. Tahir Bashir. Zero Trust Architecture: Enhancing cybersecurity in enterprise networks. *Journal of Computer Science and Technology Studies*, 6(4):54-59, 2024.

19. Matthew Bush and Atefeh Mashatan. From Zero to One Hundred: Demystifying Zero Trust and Its Implications on Enterprise People, Process, and Technology. *Queue*, 20(4):80-106, 2022.

20. Yunfei Ge and Quanyan Zhu. Trust Threshold Policy for Explainable and Adaptive Zero-trust Defense in Enterprise Networks. In *2022 IEEE conference on communications and network security (CNS)*, pages 359-364. IEEE, 2022.

21. Gregor R Krmelj, Matjaž Pančur, Miha Grohar, and Mojca Ciglarič. OpenSPA - An Open and Extensible Protocol for Single Packet Authorization. In *Proceedings of the Central European Cybersecurity Conference 2018*, pages 1-6, 2018.