System and Method for Zero Trust Application Programming Interface Security

Abstract

A system and method for providing application programming interface (API) security may include receiving API documentation data elements that describe one or more types of API requests, parsing the API documentation data elements to create one or more first schemas, each having one or more definitions for use of the corresponding API request type, receiving an API request for accessing a computing device on a protected computer network, associating a schema of the one or more first schemas with the received API request based on the type of the received API request, and filtering the received API request based on the associated first schema.

Description

Technical Field

[0001] This application was filed on May 26, 2022, and claims the benefit of priority under 35 U.S.C. § 119(e) of U.S. Provisional Patent Application No. 63 / 346,097, entitled "Systems and Methods for Zero Trust Application Programming Interface Security." The entire content of the above application is incorporated herein by reference in its entirety as if fully set forth herein.

[0002] The present invention generally relates to systems and methods for cybersecurity. Specifically, the present invention relates to systems and methods for providing zero trust application programming interface (API) security.

Background Art

[0003] Recent research has shown that API cyberattacks have become the most frequent vector or form of cyberattacks leading to data breaches in enterprise web applications. API attacks are increasing at an alarming rate, and many well-known API security vulnerabilities have already affected a wide range of organizations. As a result, API security products have become one of the fastest-growing segments in the cybersecurity industry.

[0004] Current solutions available for API security use signatures, anomaly detection algorithms, supervised and unsupervised machine learning (ML) algorithms to ensure the legitimacy of data manipulation, authentication of entities (such as users) and authorization, and to protect computing systems and the data stored therein.

[0005] All of these approaches rely on trust-based mechanisms adapted to gain knowledge of attack vectors and / or detect anomalies in data access in order to avoid exploitation of vulnerabilities and reduce attack risks. Therefore, protected organizations need to rely on these mechanisms to maintain cyber security. However, it can be understood that trust-based tools can lead to cyber security failures.

[0006] Also, currently available API security solutions are typically developed as gateways within protected computer networks and are configured to determine whether to permit or block API requests based on existing trust-based security information. Such security mechanisms are generally general-purpose and not designed or configured for a specific API (e.g., an API of a specific organizational website). Therefore, such security mechanisms require a learning curve or rule-based system to adapt to constantly changing customer traffic. This learning curve period generally depends on the specific characteristics of the organizational website and the level of sophistication of the algorithms. It can be understood that as the learning curve period lengthens, protected computer networks (e.g., organizational websites) can be exposed to a wide range of cyber threats.

[0007] A neural network (NN) or artificial neural network (ANN), such as a neural network implementing machine learning (ML) or artificial intelligence (AI) functions, refers to an information processing paradigm that may include nodes called neurons organized in layers, with links between the neurons. The links transmit signals between neurons and may be associated with weights. An NN can be configured or trained for a specific task, such as pattern recognition or classification. Training an NN for a specific task may involve adjusting these weights based on examples. Each neuron in an intermediate or final layer may receive a weighted sum of input signals, such as output signals from other neurons, and process the input signals using a linear or non-linear function (such as an activation function). The results of the input and intermediate layers are transferred to other neurons, and the results of the output layer may be provided as the output of the NN. Typically, the neurons and links within an NN are represented by mathematical structures such as activation functions, matrices of data elements, and weights. A processor, such as a CPU or graphics processing unit (GPU), or a dedicated hardware device may perform the associated calculations.

[0008] As referred to herein, the term "web page" may typically refer to a document whose source code is written in plain text incorporating hypertext markup language (HTML, XHTML) and optionally formatting instructions of a cascading style sheet (CSS), and a web page may include such text, images, videos, audio, hyperlinks, and the like.

[0009] As referred to herein, the term "website" may refer to a set of related web pages. A website is hosted on at least one web server and is accessible via an Internet address known as a Uniform Resource Locator (URL) through a network such as the Internet or a private local area network. The web pages of a website are typically requested and provided from the web server using an API such as, for example, the Hypertext Transfer Protocol (HTTP) API.

[0010] As referred to herein, the term "web browser" may refer to a software application for retrieving, interpreting, rendering, and presenting information resources from the World Wide Web or a local server. A web browser enables a user to access and view documents and other resources on the Internet. Some of the current major web browsers are Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, Opera, and Apple Safari.

SUMMARY OF THE INVENTION

[0011] Embodiments of the present invention may implement a novel zero-trust approach to cybersecurity that can limit the vulnerability of an organizational computer network to API attack vectors.

[0012] Embodiments of the present invention may receive an API schema or API documentation, such as OpenAPI documentation (a de facto industry standard regarding API documentation). The API documentation may represent one or more public API services defined, implemented, and tested by developers who need to minimize the cyber attack surface of these API services at present. The API schema or documentation may include descriptions or definitions of API performance, the structure of API fields, acceptable value types, and acceptable values of the public API services.

[0013] As detailed herein, embodiments of the present invention may be configured to enforce these restrictions by allowing only legitimate traffic that complies with the restrictions defined by the API documentation.

[0014] In other words, embodiments of the present invention may be configured to define a standard for data actions based on an API schema or document, and block any form of data communication or action that deviates from this standard.

[0015] Additionally or alternatively, embodiments of the present invention may utilize unsupervised learning algorithms to automatically learn or determine one or more API structures or patterns based on API traffic. Embodiments of the present invention may then enforce restrictions on API actions and communications according to the determined API structure.

[0016] Embodiments of the present invention may include a method of providing API security by at least one processor. Method embodiments may include receiving API documentation data elements that describe one or more types of API requests, and parsing the API documentation data elements to create one or more first schemas, where at least one of the first schemas (e.g., each) may include one or more definitions for the use of a corresponding API request type. Method embodiments may further include receiving an API request to access a computing device on a protected computer network, associating a schema of one or more first schemas with the received API request based on the type of the received API request, and filtering the received API request based on the associated first schema.

[0017] According to some embodiments, the definition for the use of API requests may include the definition of one or more fields of the API request type and one or more applicable values for these fields.

[0018] Method embodiments may further include attributing one or more filtering actions to at least one API request type. Filtering a received API request may include applying one or more filtering actions to the received API request based on the relevant scheme.

[0019] For example, the filtering actions may include transferring the API request to a computing device of a protected computer network, blocking the received API request, securing the received API request, reconstructing the received API request, transferring the response of the computing device of the protected computer network to the received API request, blocking the response of the computing device of the protected computer network to the received API request, securing the response of the computing device of the protected computer network to the received API request, reconstructing the response of the computing device of the protected computer network to the received API request, generating an alert (e.g., in relation to blocked API requests and / or API responses), and the like.

[0020] Method embodiments may further include applying a machine learning (ML)-based model to the received API request to obtain at least one second usage scheme that may include one or more definitions for the use of the fields of the received API request. The embodiment may then filter the received API request according to the second usage scheme.

[0021] Method embodiments may receive, during a training phase, a plurality of API requests corresponding to respective pluralities of API request types. For at least one API request type, method embodiments may train an ML model to cluster the corresponding plurality of API requests into one or more clusters based on the content of the fields of the API requests. For at least one cluster, method embodiments may associate a second usage scheme including one or more definitions for the usage of the fields of the corresponding API requests.

[0022] According to some embodiments, filtering API requests received according to a second usage scheme may include associating one or more filtering actions with at least one cluster, identifying that the received API requests do not conform to the second usage scheme of at least one cluster, and applying one or more filtering actions to the received API requests based on this identification.

[0023] Embodiments of the present invention may include a method of providing API security by at least one processor. Method embodiments may include receiving an API request, applying an ML-based model to the API request to obtain a usage scheme including one or more definitions regarding the content of the fields of the received API request, and filtering the received API request according to the usage scheme.

[0024] During a training phase, method embodiments may receive a plurality of API requests corresponding to respective pluralities of API request types. For at least one API request type, embodiments of the present invention may train an ML model to cluster the corresponding plurality of API requests into one or more clusters based on the content of the fields of the API requests. For at least one cluster, embodiments of the present invention may associate a usage scheme including one or more definitions for the usage of the fields of the corresponding API requests.

[0025] According to some embodiments, filtering an API request received according to a usage scheme may include associating one or more filtering actions with at least one cluster, identifying a state in which the received API request does not comply with the usage scheme of at least one cluster, and applying one or more filtering actions to the received API request based on the identification.

[0026] Embodiments of the present invention may include a system for providing zero-trust API security, the system may include a non-transitory memory device storing modules of instruction code, and a processor associated with the memory device and configured to execute the modules of instruction code. When executing the modules of instruction code, the processor receives API documentation data elements describing one or more types of API requests, analyzes the API documentation data elements to create one or more first schemes, each of which may include one or more definitions for the use of the corresponding API request type, receives an API request for accessing a computing device on a protected computer network, associates a scheme of one or more first schemes with the received API request based on the type of the received API request, and may be configured to filter the received API request based on the associated first scheme.

[0027] The subject matter regarded as the invention is particularly pointed out and distinctly claimed at the end of this specification. However, the invention, together with its objects, features, and advantages, may be best understood by reference to the following detailed description when read in conjunction with the accompanying drawings, both as to organization and method of operation.

Brief Description of the Drawings

[0028]

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4

Figure 5

Figure 6

[0029] For the sake of brevity and clarity of illustration, it is understood that the elements shown in the figures are not necessarily drawn to scale. For example, some dimensions of the elements may be enlarged relative to other elements for clarity. Further, where appropriate, reference numerals may be repeated between figures to indicate corresponding or similar elements.

[0030] Those skilled in the art will understand that the present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. Therefore, the above embodiments are to be considered illustrative rather than restrictive of the invention described herein in every respect. Thus, the present invention is indicated by the appended claims rather than the foregoing description, and all changes that come within the meaning and range of equivalency of the claims are intended to be embraced therein.

[0031] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention. Some features or elements described with respect to one embodiment may be combined with features or elements described with respect to other embodiments. For the sake of clarity, descriptions of the same or similar features or elements may not be repeated.

[0032] Embodiments of the present invention are not limited in this regard, but for example, descriptions using terms such as "processing", "calculating", "computing", "determining", "establishing", "analyzing", "checking", etc. may refer to operations and / or processes of a computer, computing platform, computing system, or other electronic computing device that manipulate and / or transform data represented as physical (e.g., electronic) quantities in a computer's registers and / or memory into other data represented as physical quantities in the computer's registers and / or memory, or in other non-transitory storage media capable of storing instructions for performing the operations and / or processes.

[0033] Embodiments of the present invention are not limited in this regard, but the terms "plurality" and "a plurality of" as used herein may include, for example, "a number" or "two or more". The terms "plurality" and "a plurality of" may be used throughout this specification to describe two or more components, devices, elements, units, parameters, etc. The term "set" as used herein may include one or more items.

[0034] Unless otherwise specified, the method embodiments described herein are not limited to a particular order or sequence. Also, some of the described method embodiments or elements thereof may occur, or be performed, simultaneously, at the same time, or in parallel.

[0035] Reference is now made to FIG. 1, which is a block diagram depicting a computing device that may be included in an embodiment of a system for providing zero-trust API security, according to some embodiments of the present invention.

[0036] The computing device 1 may include, for example, a central processing unit (CPU) processor, a chip, or a controller 2 that may be any suitable computing or computational device, an operating system 3, a memory 4, executable code 5, a storage system 6, an input device 7, and an output device 8. The processor 2 (or, in some cases, one or more controllers or processors across multiple units or devices) may be configured to execute the methods described herein and / or to execute, or perform the functions of, various modules, units. A plurality of computing devices 1 may be included in a system according to embodiments of the present invention, and one or more computing devices 1 may function as components of a system according to embodiments of the present invention.

[0037] The operating system 3 may be any code segment (such as the executable code 5 described herein) that is designed and / or configured to perform tasks involving the coordination, scheduling, arbitration, supervision, control, or other management operations of the computing device 1, such as scheduling the execution of software programs or tasks, or enabling the communication of software programs or other modules or units. The operating system 3 may be a commercially available operating system. The operating system 3 may be an optional component. Note that, for example, in some embodiments, the system may include a computing device that does not require or include the operating system 3.

[0038] The memory 4 may be, for example, a random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous DRAM (SD-RAM), double data rate (DDR) memory chips, flash memory, volatile memory, non-volatile memory, cache memory, buffer, short-term memory unit, long-term memory unit, or other suitable memory unit or storage unit, or may include them. The memory 4 may optionally be a plurality of different memory units, or may include them. The memory 4 may be a computer or processor non-transitory readable medium, or a computer non-transitory storage medium, such as RAM. In one embodiment, a non-transitory storage medium, such as the memory 4, a hard disk drive, or another storage device, may store instructions or code that, when executed by the processor, may cause the processor to perform the methods described herein.

[0039] The executable code 5 may be any executable code, such as an application, program, process task, or script. The executable code 5 may, in some cases, be executed by a processor or controller 2 under the control of the operating system 3. For example, the executable code 5 may be an application that provides zero-trust API security, as described in more detail herein. For clarity, a single executable code 5 is shown in FIG. 1, but the systems according to some embodiments of the present invention may include a plurality of executable code segments similar to the executable code 5 that may be loaded into the memory 4 and cause the processor 2 to execute the methods described herein.

[0040] The storage system 6 may be, for example, a flash memory known in the art, a memory built into or embedded in a microcontroller or chip known in the art, a hard disk drive, a CD recordable (CD-R) drive, a Blu-ray disk (BD), a universal serial bus (USB) device, or other suitable removable and / or fixed storage unit, or may include them. Data regarding zero-trust API security may be stored in the storage system 6, loaded from the storage system 6 into the memory 4, and processed there by the processor or controller 2. In some embodiments, some of the components shown in FIG. 1 may be omitted. For example, the memory 4 may be a non-volatile memory having the storage capacity of the storage system 6. Thus, although shown as a separate component, the storage system 6 may be embedded in or included in the memory 4.

[0041] Input device 7 may be, or may include, any suitable input device, component, or system, such as a detachable keyboard or keypad, a mouse, etc. Output device 8 may include one or more (optionally detachable) displays or monitors, speakers, and / or any other suitable output device. As indicated by blocks 7 and 8, any applicable input / output (I / O) device may be connected to computing device 1. For example, a wired or wireless network interface card (NIC), a Universal Serial Bus (USB) device, or an external hard drive may be included in input device 7 and output device 8. It is understood that any suitable number of input devices 7 and output devices 8 may be operably connected to computing device 1 as indicated by blocks 7 and 8.

[0042] Systems according to some embodiments of the present invention may include components such as, but not limited to, multiple central processing units (CPUs) or any other suitable other-purpose or specific processors or controllers (such as element 2), multiple input units, multiple output units, multiple memory units, and multiple storage units.

[0043] Reference is now made to FIG. 2A, which is a block diagram depicting an application of system 100 for providing zero-trust API security according to some embodiments of the present invention. According to some embodiments of the present invention, system 100 may be implemented as a software module, a hardware module, or any combination thereof. For example, system 100 may be, or may include, a computing device such as an element of FIG. 1, and may be adapted to execute one or more modules of executable code (such as element 5 of FIG. 1) to provide zero-trust API security, as described in more detail herein.

[0044] In some embodiments, system 100 may be or include a server computing device or a proxy server computing device adapted to provide API security for an on-premises or virtual private network, also referred to herein as "protected network 50". System 100 may be implemented on an on-premises computing device (e.g., local to protected network 50), on a distributed computing device (e.g., cloud-based), or on any other processing device.

[0045] Additionally or alternatively, system 100 may be installed, integrated, or associated with one or more computer network components or modules 12, such as a gateway module, router module, switch module, load balancer module, firewall module, etc.

[0046] According to some embodiments, system 100 may receive an API documentation data element 60 (or simply API document 60) that defines or describes one or more types 20AT of API requests 20A (e.g., may include a description 20ADES), as detailed herein. For example, system 100 may include an API security management user interface (UI), such as input element 7 of FIG. 1, and may receive API document 60 via UI 7.

[0047] Additionally or alternatively, system 100 may receive a link to such an API documentation data element 60 that may be stored within protected network 50 (e.g., in storage device 6 of FIG. 1), shown as element 60A, or outside of protected network 50, shown as element 60B.

[0048] It can be understood that API requirement 20A can be configured to generate a corresponding API response 20B. In this context, API document 60 may also include a definition or description 20BDES of one or more types 20BT of API response 20B, as detailed herein.

[0049] It can be understood that embodiments of the present invention are not limited to any particular type or standard of API documentation. System 100 can be configured or adapted to analyze API document 60 according to any particular API documentation standard to create one or more schema data elements 70 (or simply "schema"). One or more (e.g., each) schema data elements 70 may include at least one definition or description 20ADES for using a corresponding API requirement 20A type 20AT and / or a corresponding API response 20B type 20BT.

[0050] For example, the definition 20ADES for use of API requirement 20A type 20AT may include a definition and / or limitation of one or more fields of API requirement 20A type 20AT. In another example, the definition for use of API requirement type 20AT may include a definition and / or limitation of one or more applicable or allowable values of the fields of API requirement type 20AT.

[0051] Additionally or alternatively, system 100 may receive or extract one or more schema data elements 70 directly from storage device 6 and / or UI 7 of FIG. 1.

[0052] Reference is made to FIG. 2B, which is a schematic diagram depicting the visualization of the content of the API documentation data element 60, which is known in the art. As shown in the example of FIG. 2B, the API document 60 may include descriptions 20ADES of a plurality of API request 20A types 20AT. In this example, the API request 20A types 20AT include a first type ("POST / pet") for adding a new pet to a pet store, a second type ("PUT / pet") for updating an existing pet, and a third type ("GET / pet / findByStatus") for finding a pet according to a status.

[0053] Also, as is known in the art, the API documentation data element 60 may include several overloaded API requests 20A. As used herein, the term "type" may refer to a single implementation of an overloaded API request 20A in some cases. In this example, the API request 20A ("PUT / pet") may be overloaded in the sense that it may include two API request types 20AT, a global API request type 20AT ("PUT / pet") for adding a pet to the store and a specific API request type 20AT ("PUT / pet / {pet_id}") for adding a pet with a specific ID to the store.

[0054] The API documentation data element 60 may conform to, or comply with, any particular standard or syntax, such as the syntax of a scripting language and / or a standard of a data structure, in order to convey or include information as depicted in the example visualization of FIG. 2B. The system 100 may be adapted to analyze the API document 60 according to a relevant standard (such as the syntax of a scripting language and / or a standard of a data structure) to create one or more schema data elements 70.

[0055] The schema data element 70 may include one or more data structures (e.g., tables), each including a field defining one or more corresponding API request 20A types 20AT and a definition 20ADES of the field value. In this example, the first schema data element 70 may define the "POST / pet" API request 20A type, and thus may include a definition 20ADES of the method (POST) of the API request 20A and a required field (e.g., a string) regarding the name of the pet. The second schema data element 70 may define the "GET / pet / findByStatus" API request 20A type, and thus may include a definition 20ADES of the method (GET) of the API request 20A type, a required field (e.g., an integer value) representing the status of the pet, and an expected return value (e.g., a string representing the name of the pet) in a subsequent API response 20B.

[0056] As detailed herein, the system 100 may convert or associate one or more (e.g., each) API schemas 70 with a set of rules and / or restrictions based on field types and / or allowed values. These rules may associate a particular API request with a corresponding action (e.g., a filtering action) to enforce a predefined policy. Thus, in this context, the terms "rule" and "policy" may be used interchangeably herein.

[0057] Regarding the example of "GET / pet / findByStatus", the system 100 may generate (a) a first rule or policy that restricts the input type (e.g., an integer value corresponding to the "status" field) of this method in the API request 20A, (b) a second rule or policy that restricts the input value (e.g., an integer value in the range [1~100] without letters or special characters) of this method in the API request 20A, (c) a third rule or policy that restricts the type of the expected return value in a subsequent API response 20B (e.g., a string representing the name of the pet), and (d) a fourth rule or policy that restricts the return value in the API response 20B (e.g., restricts the field to 10 characters and does not allow numbers and special characters).

[0058] According to some embodiments, the system 100 may receive an API request 20A for accessing a computing device on a protected computer network from one or more computing devices, shown herein as client device 20, that may be included in (e.g., in the same network domain as) the protected network 50 or outside the protected network 50 (as shown in FIG. 2A). For example, the API request 20A may include a request for accessing (e.g., read access, write access, deletion, etc.) one or more application backend servers 14 such as, for example, storage server(s) and / or compute server(s) included in the protected network 50.

[0059] The system 100 may associate the received API request 20A with a corresponding scheme 70 of one or more first schemes based on the type of the received API request. With respect to the example depicted in FIG. 2B, the system 100 may receive a "PUT / pet" API request 20A and associate an instance of the received API request 20A with a scheme 70 corresponding to the particular type of this overloaded API request 20A (e.g., "PUT / pet / " or "PUT / pet / {pet_id}").

[0060] As detailed herein, the system 100 may then filter the received API request 20A based on the associated scheme. In other words, the system 100 may apply one or more restrictions to the received API request 20A according to rules associated with the scheme of the received API request 20A.

[0061] Additionally or alternatively, system 100 may filter the received API request 20A by attributing one or more filtering actions 114B to at least one API request 20A or API request type and applying the one or more filtering actions 114B to the received API request 20A based on the relevant schema 70.

[0062] For example, system 100 may inspect an instance of the received API request 20A from the perspective of one or more corresponding rules. System 100 may then (a) apply a first filtering action (e.g., transfer the received API request 20A to the backend server 14) if the API request 20A complies with the relevant rules, or (b) apply a second filtering action (e.g., block the received API request 20A) if the API request 20A does not comply with the relevant rules.

[0063] It can be understood that system 100 may cooperate with additional (e.g., trust-based) methods and logic to enhance cybersecurity on the protected network 50. For example, system 100 may complement the functionality of a machine learning (ML)-based solution aimed at learning the structure or pattern of legitimate or illegitimate API requests 20A and responses 20B.

[0064] For example, system 100 may be configured to calculate metrics representing the characteristics of the monitored API requests 20A and responses 20B. System 100 may utilize these metrics as a stand-alone computing device to enhance the learning of the structure or pattern of legitimate or illegitimate API requests 20A and responses 20B. Additionally or alternatively, system 100 may be configured to send the calculated metrics as enhanced data to another computing device, such as a data lake server or an artificial intelligence (AI) engine server, to learn the structure or pattern of legitimate or illegitimate API requests 20A and responses 20B.

[0065] In another example, the system 100 may provide an immediate and stringent security layer by implementing a zero-trust cybersecurity methodology to complement an ML-based system that may provide an effective cybersecurity layer only after the completion of a learning curve.

[0066] Reference is now made to FIG. 3, which is a block diagram depicting a system 100 for providing zero-trust API security according to some embodiments of the present invention. The system 100 of FIG. 3 may be the same as the system 100 of FIG. 2.

[0067] As shown in FIG. 3, the arrows may represent one or more data flows between and / or among the modules or elements of the system 100. Some of the arrows are omitted in FIG. 3 for clarity.

[0068] As shown in FIG. 3, the system 100 may include an API request module 110. As detailed herein, the API request module 110 receives an instance of an API request 20A, analyzes the received API request 20A in view of API documentation 60 (e.g., in view of a schema 70), optionally filters the received API request 20A based on the analysis, and optionally is adapted to transfer a filtered version 20A' of the received API request 20A to the backend server 14.

[0069] Next, the backend server 14 may be configured to process an API request 20A (e.g., received from the client 20) or a filtered version 20A' (e.g., from the API request module 110) and generate an API response 20B', as known in the art.

[0070] Additionally or alternatively, system 100 may include an API response module 120. As detailed herein, the API response module 120 may receive an API response 20B’ (e.g., from back-end server 14), analyze the received API response 20B’ in view of the API document 60 (e.g., in view of the schema 70), optionally filter the received API response 20B’ based on the analysis, and optionally be adapted to transfer the filtered version 20B of the API response 20B’ to the relevant client 20.

[0071] Reference is now made to FIG. 4, which is a block diagram depicting an example of aspects of a system 100 for providing zero-trust API security, according to some embodiments of the present invention. The system 100 of FIG. 4 may be the same as the system 100 of FIGS. 2 and / or 3. It can be understood that the example depicted in FIG. 4 may focus on the functionality of the API request module 110. Some elements of the system 100 are omitted from FIG. 4 for clarity.

[0072] As detailed herein (e.g., in relation to FIGS. 2A and / or 3), the API request module 110 may receive an API request 20A for accessing a computing device on a protected computer network from at least one client 20 (e.g., via network communication components such as routers, switches, load balancers, firewall security modules, etc.).

[0073] As shown in FIG. 4, the API request module 110 may include an API analysis module 112 adapted to generate or obtain at least one schema data element 70 and analyze the API request 20A according to the at least one schema data element 70.

[0074] According to some embodiments, API analysis module 112 may include a supervised analysis module 112A configured to generate or obtain schema data elements 70 from API document 60 as detailed herein (e.g., in connection with FIG. 2B). In other words, supervised analysis module 112A may receive API documentation data elements 60 that describe one or more types 20AT of API requests 20A (e.g., including description 20ADES), and may be configured to parse the API documentation data elements 60 to create one or more schemas 70 each including one or more definitions 20ADES for use of the corresponding API request 20A type 20AT. The term "supervised" may be used in this context to indicate that the creation of schema 70 can be performed according to supervised data (in this example, documentation data element 60).

[0075] Additionally or alternatively, API analysis module 112 may include an unsupervised analysis module 112B configured to generate or obtain one or more schema data elements 70 in an unsupervised manner. The term "unsupervised" may be used in this context to indicate that the creation of schema 70 can be performed in a way that does not include labeled or annotated supervised data.

[0076] According to some embodiments, unsupervised analysis module 112B may be or include a machine learning (ML)-based model 112B', such as a clustering model.

[0077] As detailed herein, the unsupervised analysis module 112B may apply the ML model 112B' to at least one instance of the API request 20A to obtain a usage scheme 70B that may include one or more definitions 20ADES regarding the content of the fields of the received API request. The unsupervised analysis module 112B may associate the instance of the API request 20A with the usage scheme 70B and then filter (e.g., apply a filtering action) the received API request 20A according to the usage scheme 70B.

[0078] During the training phase, the system 100 may apply the ML model 112B' to a plurality of received API requests 20A to learn at least one usage scheme or pattern 70 (e.g., 70B) of the plurality of received API requests. The usage scheme or pattern 70B may include one or more definitions 20ADES / 20BDES for the usage of the fields of the received API request 20A, as detailed herein.

[0079] In other words, during the training phase, the system 100 may receive a plurality of API requests 20A corresponding to each of the plurality of API request types 20AT. For at least one (e.g., each) API request type 20AT, the system 100 may train the ML model 112B' to cluster the corresponding plurality of API requests 20A into one or more clusters based on the type and / or content of the fields of the API request 20A. Regarding the example of FIG. 2B, each of such clusters may represent or include API requests 20A of a specific API request type 20AT (e.g., "POST / pet", "PUT / pet", "GET / pet / findByStatus", etc.).

[0080] Additionally or alternatively, for at least one (e.g., each) cluster, the unsupervised analysis module 112B may associate or attribute a particular usage scheme 70 (e.g., 70B). The usage scheme 70B may include or represent one or more definitions 20ADES for the use of fields of the corresponding API request 20A. In other words, each scheme 70B may include definitions 20ADES regarding fields of the API request 20A of the API request type 20AT corresponding to the associated cluster.

[0081] Additionally or alternatively, the API analysis module 112 may analyze the received API request 20A in terms of a usage scheme 70 (e.g., 70A, 70B). For example, the API analysis module 112 may parse the received API request 20A and associate the received API request 20A with a particular scheme 70A, as detailed herein (e.g., in relation to FIG. 2B). In another example, the API analysis module 112 may parse the received API request 20A to identify the API request type 20AT of the received API request 20A, and then associate the received API request 20A with a particular cluster (and corresponding scheme 70) representing the identified API request type 20AT.

[0082] As shown in FIG. 4, the API request module 110 may include a policy module 114 configured to filter the received API request 20A based on the associated scheme. In other words, the policy module 114 may apply at least one rule 114A to the received API request 20A according to a usage scheme 70 (e.g., 70A and / or 70B) to apply a filtering action 114B to the associated API request 20A.

[0083] For example, the supervised analysis module 112A may associate one or more filtering actions 114B with at least one scheme 70A (which may represent one or more specific API request types 20AT). The analysis module 112A may then identify that the received API request 20A does not comply with the usage scheme 70A. Such non - compliance may include, for example, having API fields and / or field values that exceed or deviate from the fields and / or field values defined by the definition 20ADES / 20BDES of the usage scheme 70 (e.g., 70A). The supervised analysis module 112A may then cooperate with the policy module 114 to apply one or more associated filtering actions 114B to the received API request 20A based on the identification of non - compliance.

[0084] In another example, the unsupervised analysis module 112B may associate one or more filtering actions 114B with at least one cluster of a clustering model 112B’ (which may represent a scheme 70B of one or more specific API request types 20AT). The analysis module 112B may, as described above, identify that the received API request 20A does not comply with the usage scheme 70B of the associated cluster. The unsupervised analysis module 112B may then cooperate with the policy module 114 to apply one or more associated filtering actions 114B to the received API request 20A based on the identification of non - compliance.

[0085] As described herein, the schemes 70 (e.g., 70A, 70B) may be obtained by a zero - trust methodology. Embodiments of the rules of the present invention may provide rules 114A and / or filtering actions 114B for implementing an API security policy based on the obtained zero - trust scheme 70. Thus, those skilled in the art can understand that the rules 114A and / or filtering actions 114B can bring improvements to currently available API security systems and methods that are not based on the zero - trust methodology.

[0086] As detailed herein, Rule 114A may be, or may include, a data structure (e.g., a table) that can associate at least one scheme 70 with one or more respective filtering actions 114B applicable to the associated API request 20A.

[0087] For example, Rule 114A may instruct that the policy module 114 apply a filtering action 114B such as transferring the received API request 20A to a computing device of a protected computer network, such as the application backend server 14 of FIG. 3.

[0088] In another example, Rule 114A may instruct that the policy module 114 apply a filtering action 114B such as transferring the received API request 20A to a subsequent security module of the system 100, such as the API detection module 115, as detailed herein.

[0089] In another example, Rule 114A may instruct that the policy module 114 apply a filtering action 114B such as blocking the received API request 20A so that the API request 20A is not permitted to reach a computing device of a protected computer network (e.g., the computing device 14 of FIG. 3). In such an embodiment, the blocking module 118 may issue a blocking response 118A and notify the associated client 20 of the blocking action.

[0090] In another example, the policy module 114 may instruct that the polysimodule 114 may apply a filtering action 114B, such as securing a received API request 20A. In such an embodiment, the policy module 114 may send or transfer the API request 20A to a securing module 116A adapted to further analyze the API request 20A to identify or detect malicious, unexpected, or unauthorized content in the API request 20A. The term "securing" may be used in this context to indicate the detection of harmful, malicious, or unauthorized fields, field contents, or field values (e.g., outlier values or unpermitted values) in the API request 20A.

[0091] In another example, the policy module 114 may apply a filtering action 114B, such as reconstructing a received API request 20A. The term "reconstructing" may be used in this context to indicate a modification or editing of the API request 20A to generate a legitimate version 20A' of the API request 20A. Such modifications may include, for example, modifying the value of a field in the API request 20A, deleting the content (e.g., a string) or a part of a field (e.g., a part of a string) in the API request 20A, omitting a field in the API request 20A, and the like.

[0092] In such an embodiment, the polysimo module 114 may send or transfer the API request 20A to the reconstruction module 116B. According to some embodiments, the reconstruction module 116B may cooperate with the securitization module 116A to reconstruct the API request 20A and generate a legitimate version 20A'. For example, the securitization module 116A may identify or detect malicious content within the API request 20A, as detailed herein, and the reconstruction module 116B may modify or omit the malicious content to generate a legitimate version 20A' of the API request 20A that does not contain malicious content. The reconstruction module 116B may then transfer the legitimate version 20A' of the received API request 20A to a computing device (e.g., the application backend server 14 of FIG. 3) of the protected computer network 50.

[0093] According to some embodiments, different entities and / or modules of the system 100 may be included in or implemented by the same computing platform, enabling the various functions described herein to be performed by a single computing device (e.g., the computing device 1 of FIG. 1). For example, a single computing device 1 may facilitate the functions of the API analysis module 112 and the securitization module 116A and / or the reconstruction module 116B. Additionally or alternatively, the entities and / or modules of the system 100 may be distributed among or implemented by different, communicatively connected computing devices 1.

[0094] As shown in FIG. 4, the API request module 110 may include an API verification module 117 adapted to ensure that the legitimate version 20A' of the API request 20A complies with the API definition 20ADES included in the schema 70.

[0095] For example, as detailed herein, the reconstruction module 116B may modify the API request 20A (e.g., omit or delete API field content) to generate a legitimate version 20A'. At this point, if the legitimate version 20A' does not conform to the definition 20ADES of the API request 20A, such as 20ADES defined by the scheme 70 (e.g., a field in the API is missing after reconstruction of the API request 20A), the API verification module 117 may block the API request version 20A' or may not permit the transmission of the API request version 20A' to the application backend server 14. In a complementary manner, if the legitimate version 20A' conforms to the definition 20ADES of the API request 20A, such as 20ADES defined by the scheme 70 (API request 20A), the API verification module 117 may enable or permit the transmission of the API request version 20A' to the application backend server 14.

[0096] As shown in FIG. 4, the API request module 110 may include, or be associated with, one or more API detection modules 115 (e.g., 115A, 115B, 115C, 115D) configured to provide additional aspects of cyber security in relation to the received API request 20A.

[0097] For example, the API detection module 115 may include a signature module 115A adapted to verify a signature included in or associated with the API request 20A sent by a particular client 20, as is known in the art.

[0098] In another example, the API detection module 115 may include an anomaly detection module 115B adapted to identify any type of anomaly associated with the API request 20A.

[0099] For example, the anomaly detection module 115B may be or include an ML-based model adapted to learn and / or identify anomalies in API requests 20A based on the activity of a single user or multiple users. Such anomalies may be learned based on univariate or multivariate data features derived from a single API request 20A event or API request 20A field. Additionally or alternatively, anomalies may be learned based on univariate or multivariate data features derived from multiple API request 20A events or API request 20A fields. For example, the anomaly detection module 115B may trigger an anomaly based on an abnormal API request 20A usage frequency or abnormal API request 20A content.

[0100] The anomaly detection module 115B may report any detected anomalies as events based on their severity. Additionally or alternatively, the anomaly detection module 115B may aggregate multiple anomalies to increase the confidence of the reported alerts.

[0101] In another example, the API detection module 115 may include a classification module 115C that may be or include a supervised or semi-supervised ML-based classification model. The classification module 115C may be trained to classify a single event and / or multiple events based on the data labeling of known events. Such classification may be performed on different types of information domains such as, for example, API request content, the past behavior of one or more users, etc.

[0102] According to some embodiments, the ML-based model of the classification module 115C may be applied to tabular (e.g., feature-based) information. Additionally or alternatively, the ML-based model of the classification module 115C may be applied to text information. In such embodiments, the classification module 115C may apply an information vector embedding (e.g., word or character-based embedding) to the API request 20A to process the text and classify the API request 20A (e.g., using a deep learning methodology).

[0103] In yet another example, the API detection module 115 may include a similarity module 115D adapted to establish a similarity between information regarding the received API request and information on well-known API attacks.

[0104] For example, the similarity module 115D may compare one or more fields of the API request 20A with patterns of known attacks based on string comparison (distance-based) or string vector embedding similarity metrics. The similarity module 115D may then identify at least one API request as being related to a known API attack. Thus, the similarity module 115D may detect evasive API attacks based on known vulnerabilities or past API attacks.

[0105] Reference is now made to FIG. 5, which is a block diagram depicting an example of aspects of a system 100 for providing zero-trust API security according to some embodiments of the present invention. The system 100 of FIG. 5 may be the same as the system 100 of FIGS. 2, 3, and / or 4. It can be understood that the example depicted in FIG. 5 may focus on the functionality of the API response module 120. Some elements of the system 100 are omitted from FIG. 5 for clarity.

[0106] As detailed above (e.g., in relation to FIGS. 3 and 4), the system 100 may include an API request module 110 adapted to apply API security to an API request received from a client 20, for example, en route to an application backend server 14. It can be understood that the API response module 120 may include similar sub-modules and functionality that can apply API security to an API response 20B' received from the backend server 14, for example, en route to the associated client 20.

[0107] In other words, the API response module 120 may include sub-modules such as, for example, elements 122, 124, 125, 126, 127, and 128 that may be applied to the API response 20B' to provide the required API security. The elements 122, 124, 125, 126, 127, and 128 of the API response module 120 may be functionally similar to the sub-modules 112, 114, 115, 116, 117, and 118 of the API request module 110, respectively. Therefore, the descriptions of the sub-modules 122, 124, 125, 126, 127, and 128 are not repeated in detail here for the sake of brevity.

[0108] As shown in FIG. 5, the API response module 120 may include an API analysis module 122. The API analysis module 122 may apply functions similar to those of the API analysis module 112 applied to the API request 20A to the API response 20B'. Therefore, the description of the sub-module 122 is not repeated in detail here for the sake of brevity.

[0109] According to some embodiments, the API analysis module 122 may be adapted to generate or obtain at least one schema data element 70 (e.g., 70A, 70B). The API analysis module 122 may generate or obtain the schema data element 70 in relation to the API response 20B' in a manner similar to the API analysis module 112 (related to the API request 20A) as detailed herein (e.g., in relation to FIG. 4).

[0110] The API analysis module 122 may then analyze the API response 20B' according to at least one schema data element 70 in a manner similar to the API analysis module 112 (related to the API request 20A) as detailed herein (e.g., in relation to FIG. 4).

[0111] According to some embodiments, the API analysis module 122 may include a supervised analysis module 122A that may be similar to the supervised analysis module 112A of FIG. 4. The supervised analysis module 122A may be configured to generate or obtain the schema data elements 70 from the API document 60 as detailed herein in relation to the API analysis module 112. For example, the supervised analysis module 122A may receive an API documentation data element 60 that describes one or more types 20BT of the API response 20B' (e.g., including the description or definition of 20BDES), and may be configured to parse the API documentation data element 60 to create one or more schemas 70. Each schema 70 may include one or more definitions 20BDES for the use of the corresponding API response 20B type 20BT.

[0112] Additionally or alternatively, the API analysis module 122 may include an unsupervised analysis module 122B that may be similar to the unsupervised analysis module 112B of FIG. 4. The unsupervised analysis module 122B may be configured to generate or obtain one or more schema data elements 70 in an unsupervised manner as detailed herein in relation to the unsupervised analysis module 112B.

[0113] According to some embodiments, the unsupervised analysis module 122B may include an ML model 122B' that may be similar to the ML model 112B' of FIG. 4. The unsupervised analysis module 122B may apply the ML model 122B' to at least one instance of the API response 20B' as detailed herein. Accordingly, the unsupervised analysis module 122B may obtain a usage schema 70B that may include one or more definitions 20BDES regarding the content of the fields of the received API response 20B'. The unsupervised analysis module 122B may associate an instance of the API response 20B' with the usage schema 70B, and then filter (e.g., apply a filtering action) the received API response 20B' according to the usage schema 70B.

[0114] As shown in FIG. 5, the API response module 120 may include a policy module 124 that may be similar to the policy module 114 of FIG. 4. According to some embodiments, the policy module 124 may be configured to filter the received API response 20B' based on the relevant scheme. In other words, the policy module 124 may apply at least one rule 124A to the received API response 20B' according to the usage scheme 70 (e.g., 70A and / or 70B), and apply a filtering action 124B to the relevant API response 20B.

[0115] For example, the supervised analysis module 112A may associate one or more filtering actions 124B with at least one scheme 70A (which may represent one or more specific API response types 20BT). The analysis module 122A may then identify that the received API response 20B' does not comply with the usage scheme 70A. Such non-compliance with the rule 124A may include, for example, having API fields and / or field values that exceed or deviate from the fields and / or field values (20ADES / 20BDES) defined by the usage scheme 70 (e.g., 70A). In another example, non-compliance with the rule 124A may include the presence of personal data or confidential data in the response 20B. In another example, non-compliance with the rule 124A may include a state where the API request 20A does not match the structure, content, or data volume of the subsequent corresponding response 20B'.

[0116] According to some embodiments, the supervised analysis module 122A may then cooperate with the policy module 124 to apply one or more relevant filtering actions 124B to the received API response 20B based on the identification of non-compliance.

[0117] For example, in response to identifying a non-compliance with Rule 124A, the policy module 124 may apply one or more filtering actions 124B. The filtering actions 124B may include, for example, transferring the response 20B’ of the computing device 14 of the protected computer network 50 to the received API request 20A, blocking the response 20B’ of the computing device 14 of the network 50 to the received API request 20A, securing the response 20B’ of the computing device 14 of the network 50 to the received API request 20A, reconstructing the response 20B’ of the computing device 14 of the protected computer network 50 to the received API request 20A, and generating and / or presenting an alert regarding the non-compliance with Rule 124A to one or more computing devices (such as the client 20).

[0118] As detailed herein, the API response module 120 may include an API delivery module 126 that may be similar to the API delivery module 116 of FIG. 4. As detailed herein, Rule 124A may instruct that the policy module 124 may apply filtering actions 124B such as securing the received API response 20B’. In such an embodiment, the policy module 124 may send or transfer the API response 20B’ to a securing module 126A adapted to further analyze the API response 20B’ to identify or detect malicious, unexpected, or unauthorized content in the API response 20B’. The term “securing” may be used in this context to indicate the detection of harmful, malicious, or unauthorized fields, field contents, or field values (such as abnormal values or unpermitted values) in the API response 20B’.

[0119] Additionally or alternatively, the policy module 124 may apply filtering actions 124B, such as, for example, the reconstruction of the received API response 20B’. The term “reconstruction” may be used in this context to denote the modification or editing of the API response 20B’ to generate a legitimate version 20B of the API response 20B’. Such modifications may include, for example, modifying the values of fields within the API response 20B’, deleting the contents (e.g., a string) or a part of the contents (e.g., a part of a string) of a field within the API response 20B’, omitting a field within the API response 20B’, and the like.

[0120] In such embodiments, the policy module 124 may send or transfer the API response 20B’ to a reconstruction module 126B. According to some embodiments, the reconstruction module 126B may cooperate with the securitization module 126A to reconstruct the API response 20B’ and generate a legitimate version 20B. For example, the securitization module 126A may identify or detect malicious content within the API response 20B’ as detailed herein, and the reconstruction module 126B may modify or omit the malicious content to generate a legitimate version 20B of the API response 20B’ that does not include the malicious content. The reconstruction module 126B may then transfer the legitimate version 20B of the received API response 20B’ to a computing device (e.g., the client 20).

[0121] As shown in FIG. 5, the API response module 120 may include an API verification module 127 that may be similar to the API verification module 117 of FIG. 4. According to some embodiments, the API verification module 127 may be adapted to ensure that the legitimate version 20B of the API response 20B’ complies with the API definition 20BDES included in the scheme 70.

[0122] For example, as detailed herein, the reconstruction module 126B may modify the API response 20B' (e.g., omit or delete API field content) to generate a valid version 20B. If the valid version 20B does not conform to the definition 20BDES of the API response 20B' as defined by the scheme 70 at this point (e.g., a field in the API is missing after the reconstruction of the API request 20A), the API verification module 127 may block the API response version 20B, or may not permit the transmission of the API response version 20B to the client. In a complementary manner, if the valid version 20B conforms to the definition 20BDES of the API response 20B' as defined by the scheme 70, the API verification module 127 may enable or permit the transmission of the API response version 20B to the client 20.

[0123] As shown in FIG. 5, the API response module 120 may include a block module 128 that may be similar to the block module 118 of FIG. 4. According to some embodiments, the rule 124A may instruct that the policy module 124 may apply a filtering action 124B such as blocking the received API response 20B' so that the API response 20B' is not permitted to reach a computing device (e.g., the client 20). In such an embodiment, the blocking module 128 may issue a blocking response 118A (e.g., not permit the transfer of the API response 20B' to the client 20) and notify the associated computing device (e.g., the client 20) of the blocking action.

[0124] As shown in FIG. 5, the API response module 120 may include or be associated with one or more API prevention modules 125 (e.g., 125A, 125B, 125C) configured to provide additional aspects of cyber security in relation to the received API response 20B'.

[0125] For example, the API prevention module 125 may include a personally identifiable information (PII) module 125A adapted to identify any type of data included in an API response 20B' that may identify a particular individual. For example, the PII module 125A may identify a username, address, email account, phone number, date of birth, passport number, fingerprint, driver's license number, credit card number, social security number, or any other confidential information that may be used for improper conduct. The PII information in the response 20B' may be legitimate, but it can be understood that it may also be included in the response 20B' as part of a suspicious act indicating, for example, an API attack. The PII module 125A is configured to identify the types of PII that may be included in the response 20B' and quantify a risk score representing the probability that the identified type of PII is actually abnormal or malicious in the current response 20B' or in the context of each type 20BT.

[0126] In another example, the API detection module 125 may include an anomaly detection module 125B adapted to identify any type of anomaly associated with the API response 20B'.

[0127] For example, the anomaly detection module 125B may be, or include, an ML-based model adapted to learn and / or identify anomalies in the API response 20B' based on the activity of a single user or multiple users. Such anomalies can be learned based on univariate or multivariate data features that can be derived from a single API response 20B' event or an API response 20B' field.

[0128] Additionally or alternatively, the anomaly detection module 125B may learn anomalies based on univariate or multivariate data features that can be derived from multiple API response 20B' events and / or API request 20A fields. For example, the anomaly detection module 125B may trigger an anomaly based on an abnormal API response 20B' usage frequency or abnormal API response 20B' content.

[0129] Additionally or alternatively, the anomaly detection module 125B may report any detected anomaly as an event based on its severity. The anomaly detection module 125B may aggregate multiple anomalies to increase the confidence of the reported alerts.

[0130] In another example, the API detection module 125 may include a user and entity behavior analytics (UEBA) module 125C. As is known in the art, the term UEBA (also known as user behavior analytics (UBA)) may refer to the process of collecting insights into the network events that users generate on a daily basis. According to some embodiments, the UEBA module 125C may detect and alert against threats originating from external sources, rather than being limited to detecting threats originating from individual users. Such external sources may include, but are not limited to, bots, routers, servers, applications, and other network devices that can be utilized by an attacker to breach or attack the APIs of the application server 14 in a distributed manner. The UEBA module 125C may be configured to detect abnormal activities derived from the perspective of multi-users who may consume the same API or API group using AI and ML. The UEBA module 125C may then perform mitigation measures such as, for example, generating notifications, alerting against suspicious UEBA events, and / or blocking detected suspicious or abnormal entity behaviors.

[0131] Reference is made to FIG. 6, which is a flow diagram depicting a method of providing zero-trust API security by at least one processor (e.g., processor 2 of FIG. 1) according to some embodiments of the present invention.

[0132] As shown in step S1005, at least one processor 2 may receive an API documentation data element (e.g., API documentation 60 of FIGS. 3, 4, and / or 5) that describes one or more types 20AT of API requests 20A and / or one or more types 20BT of API responses 20B (e.g., including description 20ADES).

[0133] As shown in step S1010, at least one processor 2 may analyze the API documentation data element 60 to create one or more schemas 70 (e.g., 70A, 70B). Each schema may include one or more definitions 20ADES / 20BDES for the use of the corresponding API request type 20AT and / or API response type 20BT.

[0134] As shown in step S1015, at least one processor 2 may receive an API request 20A (from a computing device such as client 20 in FIG. 2A) for accessing a computing device (such as application server 14 in FIG. 2A) on a protected computer network (such as network 50 in FIG. 2A).

[0135] As shown in steps S1020 and S1025, at least one processor 2 may associate one or more schemas 70 of the schemas with the received API request 20A based on the type 20AT of the received API request 20A, and then filter the received API request 20A and / or the response 20B' to the API request 20A based on the associated schema, as detailed herein.

[0136] As detailed herein, embodiments of the present invention may provide practical applications by improving the functionality or security of a computer network.

[0137] For example, embodiments of the present invention may implement a novel zero-trust approach to cybersecurity that can limit the vulnerability of an organizational computer network to API attack vectors. As described herein, schemes 70 (e.g., 70A, 70B) may be obtained by a zero-trust methodology, and embodiments of the present invention enable the provision of rules 114A and / or filtering actions 114B for implementing an API security policy based on the obtained zero-trust scheme 70. Thus, one of ordinary skill in the art can understand that rules 114A and / or filtering actions 114B may provide improvements over currently available API security systems and methods that are not based on a zero-trust methodology.

[0138] Unless otherwise specified, method embodiments described herein are not limited to a particular order or sequence. Further, all formulas described herein are intended as merely examples, and other formulas or different formulas may be used. Also, some of the method embodiments or elements thereof described may occur or be performed at the same time point.

[0139] While certain features of the present invention have been illustrated and described herein, many modifications, alternatives, variations, and equivalents will occur to those of ordinary skill in the art. Accordingly, it is to be understood that the appended claims are intended to cover all such modifications and changes that fall within the true spirit of the present invention.

[0140] Various embodiments have been presented. Each of these embodiments may, of course, include features of the other embodiments presented, and embodiments not specifically described may include various features described herein.

Claims

**Claim 1** A method for providing application programming interface (API) security by at least one processor, the method comprising: Receiving an API documentation data element that describes one or more types of API requests; Analyzing the API documentation data element to create one or more first schemas, each having one or more definitions for use of a corresponding API request type; Receiving an API request for accessing a computing device on a protected computer network; Associating a schema of the one or more first schemas with the received API request based on the type of the received API request; Filtering the received API request based on the associated first schema; A method comprising the above steps. **Claim 2** The method according to claim 1, wherein the definition for use of the API request comprises a definition of one or more fields of the API request type and one or more applicable values for these fields. **Claim 3** The method according to any one of claims 1 to 2, further comprising attributing one or more filtering actions to at least one API request type, and filtering the received API request comprises applying the one or more filtering actions to the received API request based on the associated schema. **Claim 4** The filtering action is selected from the list consisting of transferring the API request to a computing device of the protected computer network, blocking the received API request, securing the received API request, reconstructing the received API request, transferring a response of the computing device of the protected computer network to the received API request, blocking a response of the computing device of the protected computer network to the received API request, securing a response of the computing device of the protected computer network to the received API request, and reconstructing a response of the computing device of the protected computer network to the received API request, the method according to claim 3.

5. Applying a machine learning (ML)-based model to the received API request to obtain at least one second usage scheme comprising one or more definitions for the usage of fields of the received API request; Filtering the received API request according to the second usage scheme The method according to any one of claims 1 to 4, further comprising.

6. In the training stage, Receiving a plurality of API requests corresponding to each of a plurality of API request types; Training the ML model to cluster the plurality of corresponding API requests into one or more clusters based on the content of the fields of the API requests for at least one API request type; Associating a second usage scheme comprising one or more definitions for the usage of fields of the corresponding API requests with at least one cluster The method according to claim 5, further comprising.

7. Filtering the received API request according to the second usage scheme comprises Associating one or more filtering actions with at least one cluster; Identifying a state in which the received API request does not conform to the second usage scheme of the at least one cluster; Applying the one or more filtering actions to the received API request based on the identification The method according to claim 6, comprising:

8. A method for providing application programming interface (API) security by at least one processor, the method comprising: Receiving an API request; Applying a machine learning (ML)-based model to the API request to obtain a usage scheme comprising one or more definitions regarding the content of the fields of the received API request; Filtering the received API request according to the usage scheme; A method comprising:

9. In a training phase, Receiving a plurality of API requests corresponding to each of a plurality of API request types; Training the ML model to cluster the plurality of corresponding API requests into one or more clusters based on the content of the fields of the API requests for at least one API request type; Associating a usage scheme comprising one or more definitions for the use of the fields of the corresponding API requests with the at least one cluster The method according to claim 8, further comprising:

10. Filtering the received API request according to the usage scheme comprises: Associating one or more filtering actions with at least one cluster; Identifying a state in which the received API request does not conform to the usage scheme of the at least one cluster; Applying the one or more filtering actions to the received API request based on the identification The method according to any one of claims 8 and 9, further comprising:

11. A system for providing zero-trust API security, the system comprising a non-transitory memory device storing a module of instruction code, and a processor associated with the memory device and configured to execute the module of instruction code, wherein, when executing the module of instruction code, the processor Receives an API documentation data element describing one or more types of API requests Analyze the API documentation data elements to create one or more first schemas, each having one or more definitions for the use of corresponding API request types. Receive an API request to access a computing device on a protected computer network. Based on the type of the received API request, associate the schema of the one or more first schemas with the received API request. Filter the received API request based on the associated first schema. A system configured as described above.

12. The system according to claim 11, wherein the definition for the use of the API request comprises definitions of one or more fields of the API request type and one or more applicable values for these fields.

13. The at least one processor is further configured to Attribute one or more filtering actions to at least one API request type, Filter the received API request by applying the one or more filtering actions to the received API request based on the associated schema. The system according to any one of claims 11 to 12.

14. The filtering actions include transferring the API request to a computing device on the protected computer network, blocking the received API request, securing the received API request, reconstructing the received API request, transferring a response from the computing device on the protected computer network to the received API request, blocking a response from the computing device on the protected computer network to the received API request, securing a response from the computing device on the protected computer network to the received API request, and reconstructing a response from the computing device on the protected computer network to the received API request. The system according to claim 13, selected from the list consisting of:

15. The at least one processor is further configured to Apply a machine learning (ML)-based model to the received API request to obtain at least one second usage scheme with one or more definitions for the use of the fields of the received API request. The system according to any one of claims 11 to 14, configured to filter the received API request according to the second usage scheme. **Claim 16** The at least one processor is further in a training phase Receive a plurality of API requests corresponding to each of the plurality of API request types For at least one API request type, train the ML model to cluster the corresponding plurality of API requests into one or more clusters based on the content of the fields of the API request Associate a second usage scheme with one or more definitions for the use of the fields of the corresponding API requests for at least one cluster The system according to claim 15, configured as such. **Claim 17** The at least one processor is further Associate one or more filtering actions with at least one cluster Identify a state in which the received API request does not conform to the second usage scheme of the at least one cluster Based on the identification, apply the one or more filtering actions to the received API request The system according to claim 16, configured to filter the received API request according to the second usage scheme by the above. **Claim 18** A system for providing application programming interface (API) security, the system comprising a non-transitory memory device storing a module of instruction code, and a processor associated with the memory device and configured to execute the module of instruction code. When the module of instruction code is executed, the processor Receives an API request Apply a machine learning (ML)-based model to the API request to obtain a usage scheme with one or more definitions regarding the content of the fields of the received API request Filter the received API request according to the usage scheme A system configured as such.

Images