## 6 Implement and Evaluation
### LiSEA's Protective Efficacy against the OWASP API Security Top 10
#### 6.2.2 Latency Impact on the Original Business System  
When interfacing with LiSEA, business systems possess the flexibility to opt for the inclusion of protection policies solely at the pre-intervention point, exclusively at the post-intervention point, or at both the pre- and post-intervention points. To holistically gauge the quantitative impact of LiSEA on the latency dynamics inherent within the original business system, a series of three comprehensive experiments were meticulously orchestrated. In these experiments, the testbed encapsulating the business system and LiSEA is meticulously instantiated across distinct CentOS virtual machines. Each virtual machine is configured with a 4-core CPU, 8 GB of RAM, and a capacious 200 GB disk allocation. The test business system, engineered within the Java programming paradigm, deliberately incorporates vulnerabilities culled from the OWASP API Security Top 10. The experimentation framework simulates user interactions with the system, thereby emulating thread counts ranging from 100 to 600, with a discrete step increment of 100. The orchestrated orchestration further dictates a ramp-up period of 1 s and a comprehensive iteration cycle \begin{table}
\begin{tabular}{p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline
**API Security Top 10 2019** & **Prevent by LiSEA** & **How** \\ \hline API1:2019 Broken Object & TRUE & Introducing a post-intervention point for verifying the relationship alignment between the access subject and the designated object. \\ \hline API2:2019 Broken User Authentication & TRUE & Implementing a pre-intervention point validation mechanism for corroborating attributes such as login device and network environment. \\ \hline API3:2019 Excessive Data Exposure & TRUE & Instituting attribute scrutiny for returned resources via the post-intervention point. \\ \hline API4:2019 Lack of Resources and Rate Limiting & TRUE & Establishing pre-intervention point limitations on access frequency and resource solicitation. \\ \hline API5:2019 Broken Function & TRUE & Conducing a pre-intervention point scrutiny of the interplay between the access subject and the corresponding API function. \\ \hline API6:2019 Mass Assignment & TRUE & Effecting a pre-intervention point validation of attributes affiliated with client-submitted objects. \\ \hline API7:2019 Security Misconfiguration & FALSE & \\ \hline API8:2019 Injection & TRUE & Introducing an injected feature evaluation at the pre-intervention juncture, coupled with subsequent relationship assessment between the access subject and object at the post-intervention point. \\ \hline API9:2019 Improper Assets Management & FALSE & \\ \hline API10:2019 Insufficient Logging and Monitoring & TRUE & Enabling comprehensive monitoring through the systematic logging of each business process and API invocation within LiSEA’s framework, thus fortifying the surveillance and oversight apparatus. \\ \hline \end{tabular}
\end{table} 
Table 2: Coverage for the OWASP API Security Top 10.  
amounting to 1000 iterations. For the benchmark, we chose the average time of round trip time for obtaining a token based on the getToken API in [27], where a microservice security agent with the API gateway technology for presenting a secure authentication mechanism was used. In light of the insights gleaned from Figure 7a-c, it emerges unequivocally that the escalation in thread count begets a marginal increase in access latency to LiSEA. Remarkably, this augmented latency remains confined within the realm of a mere few tens of microseconds, or even diminishing to a few microseconds, when juxtaposed against the backdrop of the original business system. Importantly, the discernible trajectory of latency overhead incurred by LiSEA exhibits a consonance with that of the original business system. Crucially, this augmentation in latency fails to ascend to a threshold that could potentially jeopardize the user experience.