Leaving the Business Security Burden to LiSEA: A Low-Intervention Security Embedding Architecture for Business APIs

Abstract

In the evolving landscape of complex business ecosystems and their digital platforms, an increasing number of business Application Programming Interfaces (APIs) are encountering challenges in ensuring optimal authorization control. This challenge arises due to factors such as programming errors, improper configurations, and sub-optimal business processes. While security departments have exhibited proficiency in identifying vulnerabilities and mitigating certain viral or adversarial incursions, the safeguarding of comprehensive business processes remains an intricate task. This paper introduces a novel paradigm, denoted as the Low-Intervention Security Embedding Architecture (LiSEA), which empowers business applications to enhance the security of their processes through judicious intervention within business APIs. By strategically incorporating pre- and post-intervention checkpoints, we devise a finely grained access control model that meticulously assesses both the intent of incoming business requests and the outcomes of corresponding responses. Importantly, these advancements are seamlessly integrated into the existing business codebase. Our implementation demonstrates the effectiveness of LiSEA, as it adeptly addresses eight out of the ten critical vulnerabilities enumerated in the OWASP API Security Top 10. Notably, when the number of threads is less than 200, LiSEA brings less than 20 msec of latency to the business process, which is significantly less than the microservice security agent based on the API gateway.

1. Introduction

In recent years, the business landscape has witnessed a conspicuous escalation in the magnitude of financial losses attributed to Application Programming Interface (API) security breaches. Prominent corporations, including but not limited to Facebook, LinkedIn, Shopify, and Amazon, have suffered extensive instances of user and merchant data compromise, stemming from vulnerabilities within their respective APIs [1,2]. Evidently, the proliferation of business content and the ascendancy of microservice architectures have ushered in an inexorable progression. This trajectory is characterized by the escalating complexity of business applications and software platforms, accompanied by a concomitant surge in the quantity of APIs [3]. This development trend increases the attack surface, and application security becomes harder due to the fact that security is a global property, not the sum of local security defenses. In quantifiable terms, statistical analysis reveals a discernible disparity in vulnerability density. For every 100 KLOC (Kilo Lines of Code), a monolithic application, compared to its microservice counterpart, exhibits a substantially lower average of 39 vulnerabilities. In contrast, the average number of vulnerabilities surges to 180 for a microservice-based application [4].

In contrast to conventional network security paradigms, contemporary business security challenges may not solely stem from overt and malicious attacks, but can also manifest due to inadequate oversight over the service APIs intrinsic to the business ecosystem [5,6]. This assertion finds resonance in the OWASP Security API Top 10 [7], wherein deficiencies in user authentication, object authorization, and functional access control mechanisms can potentially facilitate unauthorized user encroachments into business data, devoid of explicit attack vectors or payloads [8]. Furthermore, instances of immoderate data exposure or erroneous security configurations possess the capacity to engender inadvertent leakage of sensitive information [9]. Security departments today face a multifaceted responsibility that transcends the conventional realm of safeguarding against external network-borne viruses and external attacks. A paramount challenge in this domain resides in the imperative to meticulously oversee and substantiate the congruence of business operations with meticulously crafted architectural frameworks across an extensive spectrum of intricate scenarios. This challenge is notably pronounced in contexts featuring users endowed with legitimate authority.

LiSEA represents an innovative architectural paradigm underpinned by the ZERO TRUST framework [9], aimed at securing business processes. LiSEA provides a client Software Development Kit (SDK) tailored for integration within the business system. This SDK seamlessly incorporates the business APIs and LiSEA, thereby imbuing them with inherent security considerations. Consequently, the architecture empowers precise scrutiny and adjudication of requests and responses emanating from these business APIs. The underpinning tenet of LiSEA resides in the contextual richness of security assessments, derived from the meticulous collection and transmission of intricate business contexts via the client SDK. Importantly, this security enhancement operates harmoniously alongside the underlying business system, exerting minimal disruption.

In tandem with the architectural innovation, LiSEA introduces a bespoke business security operational framework. This framework is orchestrated through a fusion of risk modeling, business modeling, and Access Control Lists (ACLs) [10,11]. This orchestrated synergy engenders an ecosystem capable of perpetuating continuous security operations, effectively combating both known and unknown business security problems. The cohesive orchestration of LiSEA’s components presents a promising trajectory for elevating the resilience and robustness of business process security.

Compared to existing business security solutions such as static analysis and unit testing [12,13,14], automatic detection tools [15,16,17], authorization and authentication [4,18,19,20,21,22], etc., LiSEA engenders a more encompassing suite of capabilities. By holistically embracing business semantics and ensuring seamless integration within the operational landscape, LiSEA distinctively addresses the multifaceted imperatives of contemporary business security.

We have realized the implementation of LiSEA within a representative business scenario, coupled with a thoroughgoing performance assessment. The outcomes of this evaluation robustly demonstrate the efficacy of LiSEA’s instantiation. Specifically, the deployment of business systems fortified by LiSEA manifests the capability to pre-emptively mitigate the eight security vulnerabilities as articulated in the OWASP API Security Top 10. Moreover, the LiSEA augmentation effectively thwarts the occurrence of erroneous requests and responses. Impressively, this heightened security paradigm is achieved with a mere marginal increase in processing overhead, introducing a minuscule latency measured in microseconds to the intricate fabric of the business process. These empirical findings substantiate the palpable advantages inherent in the deployment of LiSEA as a potent and practical mechanism for bolstering cybersecurity within the contours of diverse business landscapes.

This paper contributes significantly to the realm of business security through the following key facets:

• Conceptual Clarification and Architectural Innovation: The exposition within this paper comprehensively elucidates the foundational tenets of business security that underlie our investigation. We introduce LiSEA, an innovative architectural paradigm within the domain of business security. This framework stands as a bulwark, ensuring the accurate operation of business processes, aligned meticulously with their intended design.
• Introduction of Business Security Operational Mechanism: We delve into the intricacies of the business security operational mechanism inherent to LiSEA. This mechanism emerges as a dynamic framework capable of facilitating seamless and continuous business security operations, ensuring the ongoing fortification of organizational resilience against threats related to programming errors, improper configurations, and sub-optimal business workflows.
• Empirical Implementation and Validation: Our study extends beyond theoretical constructs to concretely manifest within an implementation of LiSEA. The subsequent empirical evaluation attests to the capability of LiSEA in effectively mitigating eight distinct categories of security vulnerabilities, as classified under the OWASP API Security Top 10.

These contributions collectively attest to the substantive advancement of the field, presenting LiSEA as a potent and viable approach to elevate the security architecture of business operations.

2. Related Work

In the pursuit of comprehending the originality and substantive contributions of our endeavor, this section undertakes an exploration of established methodologies and techniques within the realm of classical business security. The distinctiveness and efficacy of our proposed work are subsequently illuminated through a comparative analysis against these extant paradigms.

The application of static analysis and unit testing represents a partial mitigation strategy against security vulnerabilities that may manifest during the runtime of a business system. Mirabella et al. [12] and Martin et al. [13] proposed automated black-box testing and deep learning-based testing to solve security issues. However, the effective and concise testing is the main challenge for this solution. The lack of a test oracle, the time taken, the level of code coverage, the lack of source code and other factors severely limit the effectiveness of testing [14].

Rahaman et al. [17], Singleton et al. [16] and Philippe et al. [15] created tools to detect programming errors. These tools match programs against known error patterns, and the quality of the error database affects the effectiveness of them. Developers will not readily accept tool reports due to their concerns on the tools’ capabilities, the correctness of the suggested fixes, and the exploitability of the reported issues [23].

Authorization and authentication are the most mentioned security mechanisms [4]. Following the conceptual models of applications and applying the principle of least privilege, authorization and authentication mechanisms such as OAuth 2.0 [22], OpenID Connect [21], firewalls [20], and JWT [19] are designed to specify valid accesses. This increases the complexity of implementing security in each microservice, generating a complexity both in the development and in the increase in the attack surface, since individual attention must be given to each microservice [18]. It is crucial to underscore that these mechanisms, notwithstanding their sophistication, exhibit limitations in their capacity to utilize business semantic rules during the execution of business processes.

Business application systems are characterized by the existence of sensitive information whose violation of security leads to endangering business interests. To approach the security of electronic business in a systematic way, Segura et al. [24] and Vuli et al. [25] developed a methodology for implementing security in a distributed business environment. The authors aimed to propose a methodology to be used by persons who are not from information and communication technology backgrounds. Their concern was the security development of distributed business systems and the identification of security requirements, but they failed to propose a practical business security framework.

In order to solve issues of data leakage and unauthorized data manipulation, Hai et al. [26] designed a secure cryptography-based mechanism to protect against malicious attacks. Xu et al. [27] proffered an innovative solution in the form of a microservice security agent. By integrating this agent with API gateway technology, a secure authentication mechanism was proffered. However, it cannot use business semantics as controls and has low extensibility. Nguyen et al. [28], in an analogous vein, leveraged the Spring Security Framework and OAuth2 to fortify microservice APIs underpinned by the Spring framework. However, its protective ambit predominantly addressed CSRF, XSS, and Brute Force attacks, only underscoring a partial coverage.

A number of emerging technologies are also increasingly being applied to business security. Blockchain is primarily used as a tamper-proof, secure, and permanent record of the business [29]. Demirkan et al. [30] proposed blockchain-based technology to prevent business data tampering. Yarygina et al. [31] indicated a hardware security module, with fewer privileges, no shared memory access, secure languages, and SGX technology with enclaves to prevent data leakage. Machine learning and big data have become an imperative innovation for cybersecurity [32,33]. With its capacity to figure out a huge number of records and distinguish conceivably risky ones, machine learning and big data are progressively being utilized to reveal dangers and naturally squash them before they can unleash ruin. Nevertheless, the disadvantages of these emerging technologies are high cost and immature use.

Table 1. Summary of different business security solutions and their issues.

Busienss Security Solutions	Reference	Issues
Static Analysis and Unit Testing	[12,13,14]	Limited effectiveness and conciseness.
Automatic Detection Tools	[15,16,17]	The correctness and exploitability of reports are not trusted.
Authorization and Authentication	[4,18,19,20,21,22]	No business semantic control capability.
Business Security Methodology	[24,25]	Low practicability.
Data leakage and tampering prevention	[26,27,28]	High complexity and overhead.
Emerging Technologies	[29,30,31,32,33]	High cost and immature application.

summarizes the business security solutions discussed above. The main issues connected with existing business security solutions is that they are basic and generic and cannot be tailored to specific business scenarios. In juxtaposition to these discernible advancements, the LiSEA framework, as propounded in this paper, engenders a more encompassing suite of capabilities. By holistically embracing business semantics and ensuring seamless integration within the operational landscape, LiSEA distinctively addresses the multifaceted imperatives of contemporary business security.

3. Business Security

Business security transcends the scope of mere defense against network viruses or external attacks. Instead, it pertains to the intricate realm of security challenges that might remain concealed during the stages of design and development but subsequently surface during the active business operations. This encompasses a broad spectrum of vulnerabilities, encompassing technical-level susceptibilities such as programmatic bugs, as well as managerial-level vulnerabilities stemming from misconfigurations and misauthorizations. These vulnerabilities have the potential to precipitate adverse consequences, ranging from inadvertent information leakage to financial setbacks and other unfavorable outcomes. It is imperative to recognize that the domain of business security is intricately intertwined with the very fabric of the business it safeguards, thereby exuding a pronounced resonance with specific contextual scenarios. As such, it transcends the confines of mere technicality, establishing itself as a multidimensional concern that necessitates holistic consideration [34].

3.1. Typical Business Security Scenarios

Business security challenges typically come to light within distinct contextual scenarios, often materializing as situations where authorized users adhere to appropriate operational protocols yet yield undesired outcomes [35]. The ensuing discourse outlines a selection of illustrative instances exemplifying prevalent business security scenarios.

3.1.1. Programming Errors

The realm of security risks in business settings is predominantly characterized by programming errors, which can be categorized into systemic bugs and business-related bugs. Systemic bugs typically precipitate either unavailability or conspicuous operational aberrations within the application system. In contrast, business-related bugs primarily give rise to erroneous business outcomes, without necessarily impinging upon or jeopardizing the integrity of the application system itself. Consequently, the domain of business security is primarily preoccupied with addressing and mitigating business-related bugs.

To illustrate this, consider a scenario where a business identifier comprises a 32-character hexadecimal string. Should an individual, say Alice, make a request involving a business identifier entirely composed of numerical values (e.g., 9527…1234), the program may not interpret it as a string but rather process it as scientific notation ($9.527\dots 1234\times {10}^{31}$ ), then save it as ‘9’ in a database. This computational misinterpretation culminates in the system, erroneously yielding all business identifiers commencing with ‘9’ to Alice.

3.1.2. Improper Configurations

The intricacy of business structures often correlates with an augmented intertwining of user privilege configurations, potentially engendering challenges in effectively curating subject–object binding relationships. This intricacy can precipitate dual outcomes as follows: the exploitation of user privileges for business expediency, and an inadvertent overexposure of business data to extraneous users.

To illustrate the former, consider a scenario where Bob operates as Alice’s subordinate. In an endeavor to facilitate interim project processing, Bob is endowed with analogous role permissions as Alice. This renders Bob with unmitigated access to the entirety of business data associated with Alice.

Similarly, an alternative case involves distinct department managers, Alice and Cindy. To effectuate the transfer of a specific business file to Alice, the supervisor opts to directly configure the dissemination to all department managers. The eventual consequence of this approach is that both Alice and Cindy receive the transmitted data.

These illustrative instances underscore the complex terrain of user privilege management within intricate business contexts, necessitating strategic mechanisms to circumvent potential instances of abuse or unintended exposure of sensitive business data.

3.1.3. Sub-Optimal Business Processes

Business operations are intricately intertwined with processes, forming an essential foundation for its functioning [36]. These processes can be likened to interlinked trees or rings, wherein each user and data component is inherently confined within specific boundaries. Deviations from this established order can lead to disarray within the business ecosystem, potentially culminating in severe consequences, including catastrophic data leaks.

For instance, consider a scenario where Alice intends to disseminate a confidential document to all members of Bob’s department. Preceding the distribution process, Bob is mandated to conduct a requisite review and approval. However, if a download hot-link is generated at the onset, Bob’s approval process becomes rendered ineffectual, jeopardizing the control over this confidential document. This has the potential to culminate in a loss of control over sensitive data. In instances where the process pertains to public access, the repercussions can escalate to the point of inevitable and significant data leakage. The intricacies of process management within a business context thus assume paramount significance, underlining the criticality of meticulous control mechanisms to circumvent potential disruptions or inadvertent breaches.

3.2. Challenges

Significant interdependencies exist between business security concerns and the orchestration of business activities, underscoring the imperative for a comprehensive understanding of these activities themselves. Business processes, serving as the conduits through which organizations generate value, constitute an amalgamation of discrete business activities. These activities are indivisible atomic entities, shaped by user behaviors and data flow dynamics, with their interplay facilitated through business APIs. In this intricate landscape, the focal point of business security inquiry resides in the elemental realm of business activities, with business APIs constituting the nexus of concerted endeavor [37].

The aforementioned contextual scenarios underscore a fundamental tenet as follows: business security attainment hinges upon the precise and accurate execution of pertinent business actions. This necessitates a stringent adherence to business requirements and established design principles, not only during the invocation and fulfillment of business API calls, but also across the entire spectrum of user interactions. This intricate interplay bestows a set of challenges unto business security, precipitating a cascade of pivotal research questions that this paper endeavors to address.

• RQ.1: How can security capabilities be accessed without imparting disruptions to the native business functioning?
• RQ.2: What methodologies can be employed to guarantee minimal authorization and curtailment of data exposure?
• RQ.3: How can the consistent and comprehensive integration of security capabilities be ensured across all facets of business APIs access?

3.3. Solutions

The aforementioned business security scenarios are emblematic, and their origins can be attributed to inadequacies in both the design and implementation phases of business processes. To mitigate these issues, various solutions have been devised and are currently accessible.

Web Application Firewall (WAF) stands as a prevalent network security apparatus, primarily utilized to mitigate web-based attacks [38]. Its utility has expanded to encompass business API security through feature matching, policy rules, parameter validation, and compliance assessments [39]. However, it is essential to recognize that WAF fundamentally functions as a traffic and content inspector, primarily focusing on input requests and employing rudimentary pattern matching to detect potentially malicious activities [40]. Regrettably, its protective efficacy often experiences limitations in terms of precision and fails to fully address the intricate business security scenarios elucidated above.

API Gateway, characterized as a tool aimed at orchestrating API behavior [41], has historically found application within enterprises as a foundational element of public infrastructure. However, its compatibility with contemporary lightweight, swiftly responsive architectural paradigms, such as microservices, poses challenges. Within this context, the perceived unwieldiness of API Gateway can arise. Notably, discerning the totality of APIs within an enterprise presents a challenge, compounded by complexities in seamlessly integrating the API Gateway into the developmental workflow. For Data-in APIs and Data-out APIs, which are used to handle user operations and business resources, respectively, in Figure 1, API Gateway’s capabilities cannot differentiate between them, while LiSEA can set different control rules for Data-in APIs and Data-out APIs. In practical implementations, the API Gateway frequently assumes the role of a centralized intake point, potentially isolating users from the core fabric of business operations [42].

DevSecOps, a movement that seeks to integrate contemporary security practices congruent with the DevOps methodology, underscores a paradigm shift towards proactive security implementation [7]. While the potential benefits are substantial, the practical implementation often necessitates the incorporation of developer-centric application security testing tools that seamlessly align with the accelerated practices of DevSecOps. Striking an optimal equilibrium between expeditious software delivery and robust security remains a pivotal challenge in the DevSecOps framework [43]. The pursuit of this equilibrium stands as a pivotal concern for practitioners operating within the DevSecOps realm.

4. Overview of LiSEA

LiSEA, conceived as a safeguarding framework for business processes grounded in the zero-trust paradigm, is structured upon two principal constituents—the embedding client and the operating center—as illustrated in Figure 1.

To ensure the preservation of the underlying business while demarcating business security concerns from broader application considerations, the embedding client is meticulously structured along the principles of aspect-oriented programming [44]. This design ethos enables the encapsulation of security functionalities within a coherent and cohesive package. Within the dynamics of the business process, the transmission of data between Process A and Process B transpires via API invocations. The embedding client assumes the pivotal role of infusing aspect joints into the business APIs, realizing this integration in a minimally intrusive manner. The aspect joints are dichotomized into pre- and post-intervention points, thereby harmonizing contextual insights and operational interventions during API execution. The pre-intervention point serves to validate the legitimacy of the request intention, while the post-intervention point ascertains the alignment between the response outcome and the identity of the requester.

The operating center, an indispensable facet of LiSEA, accumulates the corpus of business contextual data collated by the embedding client. This repository is judiciously harnessed to facilitate business security analysis, all of which is choreographed in consonance with configurations delineated by the security department. In essence, the operating center assumes the mantle of processing verification solicitations originating from the embedding client. Subsequent to rigorous analysis and calculated scrutiny of diverse business security scenarios, the operating center dispenses verification responses. Notably, the resultant verification records are perpetually preserved, not only serving as fodder for comprehensive business analysis and modeling but also potentially augmenting the repository of application logs.

The operational agility of the operating center is augmented through the assimilation of third-party security platform capabilities and data, including entities like security operation centers (SOC) [45] and risk control centers. By tapping into the insights of these platforms, the operating center gains a panoramic view of the security landscape, facilitating timely configuration adjustments. Additionally, it operates as an information source and a mechanism for repelling attacks discovered by these third-party security platforms.

In a holistic context, LiSEA adeptly addresses RQ.1 by ingeniously inculcating access security capabilities via the embedding client without engendering perturbations to the native business processes. This is particularly evident when the embedding client is systematically integrated with each API during the application development phase, thereby rendering all APIs discernible and amenable to operational center management. Consequently, LiSEA effectively surmounts RQ.3, ensuring comprehensive and seamless access of business APIs to security capabilities.

5. Business Security Operation Mechanism with LiSEA

In the trajectory of materializing a business architecture grounded in microservices, the business API emerges as the elemental building block of business realization. This pivotal construct is characterized as the smallest operational unit within the overarching business framework. The realm of business realization, contingent upon diverse business scales, is discernibly stratified along three distinct dimensions.

In the context of small-scale businesses, the adept orchestration of business applications driven by business APIs is deemed proficient and fitting. For medium-scale businesses, a requisite transition transpires, necessitating the creation of an encompassing business platform marked by an assemblage of distinct yet synergistic business applications. This platform serves as the linchpin for facilitating multifunctional operations. In stark contrast, large-scale enterprises assume a considerably intricate architecture, wherein the realization of a specific business domain demands concerted efforts across multiple business platforms. These platforms collectively harmonize their services to undergird the comprehensive fulfillment of the designated business sphere. This tripartite categorization delineates the strategic contours that govern the execution of business realization across various scales.

Within the context of LiSEA, the architecture’s access control model is concretely instantiated through the strategic deployment of security interventions grounded in the realm of aspect-oriented programming. Depending on the requisite scope of control, distinct agents within the security joint point framework are meticulously devised, culminating in the realization of a finely calibrated and granular control mechanism, as visually elucidated in Figure 2.

Intrinsically, LiSEA recognizes that contemporary online business processes subsist within a perpetual state of vulnerability, susceptible to an array of both known and hitherto unidentified risks. To comprehensively fortify against these multifarious threats, LiSEA ingeniously amalgamates three distinct operational management mechanisms in a parallel fashion, collectively fortifying the business landscape. Risk modeling is a flexible framework with big modern data analyses based on deep learning, machine learning, and artificial intelligence to detect new, unknown risks [46]. This flexible framework leverages the prowess of modern data analysis to promptly discern novel and enigmatic risks. The proven utility of risk models, notably prevalent within diverse sectors encompassing finance, internet technologies, and power grids, underscores the ubiquity and efficacy of this approach [47]. Within LiSEA, the focus of the risk model is primarily centered on the dynamic evaluation and nuanced risk assessment of diverse business scenarios.

Business processes, serving as pivotal instruments in the value generation endeavors of organizations, are subjected to a plethora of internal and external norms and constraints [48]. The delineation of relationships and delineation of boundaries amid key business constituents such as business activities, business events, business collaborators, business resources, and data is aptly realized through meticulous business modeling. Leveraging business models, LiSEA efficaciously transmutes both the model and the stipulated security prerequisites into rigorous formal specifications, thus engendering inputs conducive for business verification.

ACLs [10,11] provide security for a private network by controlling the flow of incoming and outgoing packets. In LiSEA, the formulation of business ACLs manifest through the crafting of a sequential assemblage of rules, assiduously devised to sieve through and prohibit unauthorized access. These rules can emanate from diverse sources, ranging from threat intelligence to third-party security products, and even administrative stipulations.

LiSEA orchestrates a strategic amalgamation of three synergistic mechanisms as follows: the risk model, the business model, and ACLs. This strategic fusion acts as a robust bulwark against both familiar and novel risks, serving as a cogent response to Research Question 2 (RQ.2). In addressing unknown risks, LiSEA’s API intervention points discern pertinent business contexts, subsequently underpinning a dynamic evaluation of risk by interfacing with the risk model. This process is further expedited through the constitution of a repository housing a spectrum of well-defined business scenes. This repository augments the evaluation speed of the risk assessment model. Conversely, for known risks, the efficacy of API calls is positively affirmed in congruence with the tenets stipulated within the business model. Complementing this, ACL proves instrumental in delineating forbidden API calls in line with stipulated security policies. This multidimensional assessment, premised upon risk evaluation, business validation, and rule analysis, culminates in a determination of whether an API call merits blocking, as visually explicated in Figure 3.

Specifically, for a particular business process P, the unknown risk value $V_R\left(P\right)$ is measured by the risk model $F_R\left(P\right)$

$$V_R\left(P\right)=F_R\left(P\right)$$

(1)

For unknown risk warning values $W_R\left(P\right)$, calculated by setting a suitable threshold value T, the following applies:

$$W_R\left(P\right)=\left\{\begin{array}{cc}1,\hfill & V_R\left(P\right)\ge T\hfill \\ 0,\hfill & V_R\left(P\right)<T\hfill \end{array}\right.$$

(2)

For known risks, the business model positive determination is similar to a whitelist mechanism, and for the business policy $P_B$, the alert value $W_B\left(P\right)$ is calculated as follows:

$$W_B\left(P\right)=\left\{\begin{array}{cc}0,\hfill & P\in P_B\hfill \\ 1,\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(3)

For the ACL policy $P_A$, the alert value $W_A\left(P\right)$ is calculated as follows:

$$W_A\left(P\right)=\left\{\begin{array}{cc}1,\hfill & P\in P_A\hfill \\ 0,\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(4)

Finally, for business process P, the final security analysis result $W\left(P\right)$ was obtained by considering $W_R\left(P\right)$, $W_B\left(P\right)$, and $W_A\left(P\right)$ together.

$$W\left(P\right)=W_R\left(P\right)\bigcup W_B\left(P\right)\bigcup W_A\left(P\right)$$

(5)

If $W\left(P\right)=1$, business process P is blocked. Otherwise, the execution of P is permitted.

6. Implement and Evaluation

6.1. Scene of LiSEA

LiSEA’s utility manifests across three pivotal business scenarios as follows: security operations, emergency response, and business modification. Each scenario capitalizes on LiSEA’s robust capabilities, engendering tangible benefits that reverberate throughout diverse operational dimensions.

6.1.1. Security Operations

In the realm of business security operations, elucidated in Figure 4, developers employ the embedding client as a conduit to establish a seamless connection between business applications and the LiSEA operating center. Leveraging the operational center’s capabilities, business security experts judiciously configure protection policies congruent with prevailing security requisites, all in real-time. This adaptive configuration augments the organization’s agility in safeguarding its business landscape. Simultaneously, managerial stakeholders gain real-time insights into the extent of coverage engendered by the business security fortifications. The operational center further emerges as an instrumental conduit for channeling monitoring data to third-party security platforms. This symbiotic interaction bolsters network security experts’ capacity to meticulously analyze security events while also bolstering the real-time incident response capabilities of third-party security platforms.

6.1.2. Emergency Response

In the context of emergency response, as illustrated in Figure 5, LiSEA assumes a vanguard role in furnishing targeted security controls over discrete components, users, and data. Consider, for instance, a scenario involving a hiccup in a specific component denoted as “a” within a business application. In contrast to conventional approaches entailing the outright offline suspension of the entire application, LiSEA facilitates the configuration of rules within the operating center. These rules are adeptly designed to selectively block APIs associated with module “a”, thereby circumventing any deleterious impact on the operational integrity of other application components. The versatility of LiSEA’s response extends to encompass problematic individuals or data, which can be adeptly addressed through the establishment of targeted rules, obviating the need for the broad-based suspension of accounts or data deletion.

6.1.3. Business Modification

LiSEA effectively streamlines the process of business modifications. It expedites rule-based configuration via its dynamic operating center, obviating the exigency to await the cumbersome cycle of application redevelopment to facilitate live implementation. Illustrated in Figure 6, this expedient maneuver ensures that business modifications are promptly actualized without undue latency. To illustrate, envision a scenario where Cindy, entrusted with the oversight of process C, is temporarily absent on business engagements. In response, a judiciously crafted rule can be seamlessly enacted within LiSEA’s operating center, effectively forestalling the assignment of process C to Cindy during her absence.

6.2. LiSEA’s Protective Efficacy against the OWASP API Security Top 10

6.2.1. Coverage

The OWASP API Security Top 10 2019 list of the ten most critical API security risk methodologies was used to investigate the potential threats and risks. By instituting a set of rules at both pre- and post-intervention points, LiSEA demonstrates a robust capability in mitigating eight out of the top ten risks, as delineated in

Table 2. Coverage for the OWASP API Security Top 10.

API Security Top 10 2019	Prevent by LiSEA	How
API1:2019 Broken Object Level Authorization	TRUE	Introducing a post-intervention point for verifying the relationship alignment between the access subject and the designated object.
API2:2019 Broken User Authentication	TRUE	Implementing a pre-intervention point validation mechanism for corroborating attributes such as login device and network environment.
API3:2019 Excessive Data Exposure	TRUE	Instituting attribute scrutiny for returned resources via the post-intervention point.
API4:2019 Lack of Resources and Rate Limiting	TRUE	Establishing pre-intervention point limitations on access frequency and resource solicitation.
API5:2019 Broken Function Level Authorization	TRUE	Conducing a pre-intervention point scrutiny of the interplay between the access subject and the corresponding API function.
API6:2019 Mass Assignment	TRUE	Effecting a pre-intervention point validation of attributes affiliated with client-submitted objects.
API7:2019 Security Misconfiguration	FALSE
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.
API9:2019 Improper Assets Management	FALSE
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.

.

There are business security risks with API 7 and API 9 that cannot be covered by LiSEA. For API 7, security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad hoc configurations, etc. These misconfigurations may exist in the API, transport protocol, or application infrastructure. LiSEA can only control APIs and therefore cannot cover API 7. For API 9, improper Asset Management is often caused by issues such as deprecated API versions and exposed debug endpoints. These endpoints are usually overlooked by developers and obtain access to LiSEA, and thus API 9 is not covered.

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 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. Moreover, from the observations illustrated in Figure 7d, it becomes apparent that the latency attributed to exclusive access of either the pre-intervention control point or the post-intervention point demonstrates a remarkable similarity. However, a notable surge in latency emerges when both pre- and post-intervention points are simultaneously accessed. This discernible latency increase underscores the significant contribution of network transmission within the overall latency framework. This finding further underscores the potential for latency reduction through the strategic co-deployment of LiSEA alongside the business system.

In light of benchmark comparison, a salient pattern emerges. Specifically, with a thread count of 200, the latency attributed to simultaneous access of both pre- and post-intervention points approximates the latency benchmark. It is pertinent to note that the benchmark performance is derived from a singular thread count of 1. This juxtaposition underscores the remarkable superiority of our proposed LiSEA framework in contrast to the performance exhibited by authentication mechanisms rooted in the API gateway paradigm.

7. Analysis

In the realm of business security enhancement, the LiSEA framework, as articulated within this paper, encapsulates a spectrum of notable attributes as follows:

• Inherently Geared Towards Business-Centric Security: LiSEA is intrinsically tailored to the exigencies of business scenarios, engendering a more congruent alignment with the semantic intricacies inherent to business operations. This focus safeguards against undue semantic distortion, fostering a harmonious fusion of security and business imperatives.
• Precision-Driven Intervention Points via APIs: The architectural underpinning of LiSEA enables the establishment of discerningly positioned intervention points through APIs, thereby furnishing an elevated degree of control granularity. This fine-tuned control mechanism augments the efficacy of security measures, ensuring a judicious allocation of security resources.
• Multifaceted SDK for Development Streamlining: LiSEA capitalizes on a multifaceted Software Development Kit (SDK), which effectively mitigates the developmental overhead. This adaptive SDK harmoniously bridges the divide between business demands and security considerations, thereby obviating undue developmental burdens.
• Real-Time Conduit for Proactive Illicit Access Interception: An inherent attribute of LiSEA is the real-time interception of illicit access attempts. This proactive mechanism acts as a sentinel, promptly detecting and curtailing unauthorized access endeavors, thereby precluding their escalation into potential breaches.

It is, however, imperative to underscore certain limitations inherent to this architectural paradigm. A symbiotic collaboration between application developers and security stakeholders is requisite, necessitating a cohesive alliance to optimize the synergy between LiSEA’s capabilities and the broader operational landscape. Moreover, the comprehensive integration of all business interfaces with LiSEA poses a noteworthy challenge, requiring meticulous orchestration and coordination.

When harnessing the LiSEA framework to extend security capabilities, an array of strategic modalities emerges. Business models and ACLs are instrumental in affording precise control over well-acknowledged risks. Concurrently, the realm of uncharted risks is effectively addressed through dynamic risk models, which proactively evaluate and judge emerging security threats, thereby fortifying the resilience of business operations.

8. Conclusions

This paper introduces a novel paradigm termed LiSEA, which empowers applications to fortify business processes through the strategic intervention of business APIs. By strategically embedding pre- and post-intervention points, we established a granular and discriminating access control model, thereby facilitating scrutiny of both the intent of incoming requests and the outcomes of subsequent responses, all the while minimizing disruption to the existing business codebase. Our practical implementation substantiates the efficacy of LiSEA by effectively addressing eight out of the top ten OWASP-API vulnerabilities. Notably, the incremental processing latency introduced by LiSEA into the business process remains confined to the realm of microseconds, thereby further affirming its efficacy. However, LiSEA may have incompatibility problems with different development frameworks, and APIs’ access to LiSEA requires the cooperation of developers. In order to overcome the above limitations, non-intervention business security frameworks will be researched in future work.