System and method for establishing secure communication via application programming interface (API)

Abstract

The present invention relates generally to the technological field of cybersecurity. More specifically, the present invention relates to preventing malicious data distribution via application programming interface (API). The claimed invention represents a system and method for establishing secure communication via API which provide an improvement of the technological field of cybersecurity by reducing network communication latency caused by performing threat detection and threat prevention actions, as well as reducing computational loads required to achieve and maintain a desired cyber protection level. This is achieved by performing a validation, comprising determining that a specific data structure pattern is valid and performing a comparison of a calculated hash value with one or more preset hash values of a respective at least one structure-defined portion of a valid content of an API.

Description

SYSTEM AND METHOD FOR ESTABLISHING SECURE COMMUNICATION VIA APPLICATION PROGRAMMING INTERFACE (API)CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of priority of U.S. Provisional Patent Application No. 63 / 540,679, filed September 27, 2023, the contents of which are all incorporated herein by reference in their entirety.FIELD OF THE INVENTION

[0002] The present invention relates generally to the technological field of cybersecurity. More specifically, the present invention relates to preventing malicious data distribution via application programming interface (API).BACKGROUND OF THE INVENTION

[0003] As known, information technology security or cybersecurity has become an imperative aspect of contemporary computer systems and networks, as they remain vulnerable to cyberattacks.

[0004] A cyberattack is a deliberate attempt to access data, functions, or other restricted areas of the system without authorization, potentially with malicious intent. Cyberattacks may be aimed at stealing, altering, or destroying target information by hacking into susceptible systems. As a result of cyberattacks, confidentiality, integrity or availability of target resources may be compromised. Moreover, the damage may extend to resources in addition to the ones initially identified as vulnerable, including, e.g., further resources of the organization that owns the initial resource, and the resources of other involved parties (customers, suppliers). Eventually, cyberattacks have become increasingly sophisticated and dangerous.

[0005] Even though many approaches and techniques of cyberattack prevention are known from the prior art nowadays, the technological field of information security remains constantly evolving, struggling to challenge with both rapidly developing cyber threats and new ways of hiding and distributing them.

[0006] Malicious data distribution is mostly conducted via the internet communication protocols, in particular, by embedding malicious data into Application Programming Interface (API) messages (API requests and responses), which account for a significant portion of internet traffic nowadays. Currently, a great variety of traffic analysis and threatdetection tools and techniques are known in the art, including network firewalls, web API security tools, Web Application Firewall (WAF), content signatures, Artificial Intelligence (Al)-based threat detection and traffic classification tools etc. Those tools and techniques may provide for reliable threat detection in most cases, however, using any of them may affect traffic latency significantly, since performing complex threat detection solutions is a computationally expensive task.

[0007] Presently, threat detection tools struggle to handle enormous number of API requests and responses in the information communication environment where processing time and data transferring latency are factors of critical importance. A continuously developing information communication practice dictates respectively increasing requirements to bandwidth and data-transfer rate of computing networks, thereby dramatically increasing computational loads threat detection tools are subject to and impeding maintenance of the desired cybersecurity level.SUMMARY OF THE INVENTION

[0008] Accordingly, there is a need for a system and method for establishing secure communication via API which would provide an improvement of the technological field of cybersecurity by reducing network communication latency caused by performing threat detection and threat prevention actions, as well as reducing computational loads required to achieve and maintain a desired cyber protection level.

[0009] In the general aspect, the invention may be directed to a method of establishing secure communication via application programming interface (API) by at least one processor. The method may include the following steps: receiving an incoming API message having a content organized according to a specific data structure pattern; applying a multi- step validation procedure on the incoming API message, wherein a first-step validation comprises determining that the specific data structure pattern is valid; and a second-step validation comprises, when it is determined that the specific data structure pattern is valid, parsing the incoming API message to determine at least one structure-defined portion of the content; calculating a hash value of the at least one structure-defined portion of the content; performing a comparison of the calculated hash value with one or more preset hash values of the respective at least one structure-defined portion of a valid content; and validating the incoming API message, based on the comparison of the calculated hash value.

[0010] In another general aspect, the invention may be directed to a system for establishing secure communication via application programming interface (API). The system may include: a non-transitory memory device, wherein modules of instruction code are stored, and at least one processor associated with the memory device, and configured to execute the modules of instruction code, whereupon execution of said modules of instruction code, the at least one processor may be configured to: receive an incoming API message having a content organized according to a specific data structure pattern; apply a multi-step validation procedure on the incoming API message, wherein a first-step validation may include determining that the specific data structure pattern is valid; and a second-step validation may include, when it is determined that the specific data structure pattern is valid, parsing the incoming API message to determine at least one structure-defined portion of the content; calculating a hash value of the at least one structure-defined portion of the content; performing a comparison of the calculated hash value with one or more preset hash values of the respective at least one structure-defined portion of a valid content; and validating the incoming API message, based on the comparison of the calculated hash value.

[0011] In some embodiments, the incoming API message may be an API request or API response.

[0012] In some embodiments, determining that the specific data structure pattern is valid may include the following steps: inferring a machine-learning (ML)-based validation model on the incoming API message, wherein the ML-based validation model is respectively pretrained to detect a presence of anomalies in the specific data structure pattern of the incoming API message; and determining that the specific data structure pattern is valid when the presence of anomalies is not detected.

[0013] In some embodiments, the method may further include: determining that the specific data structure pattern is invalid when the presence of anomalies is detected; when it is determined that the specific data structure pattern is invalid, applying a threat detection algorithm on the incoming API message, to detect malicious data in the incoming API message; and determining that the incoming API message is valid when the malicious data is not detected.

[0014] In some embodiments, determining that the specific data structure pattern is valid may include applying a rule-based validation model on the incoming API message, wherein the rule-based validation model may be configured (i) to perform a comparison of thespecific data structure pattern with one or more preset data structure patterns; and (ii) to determine that the specific data structure pattern is valid when, based on the comparison of the specific data structure pattern, it is determined that the specific data structure pattern is similar to the one or more preset data structure patterns.

[0015] In some embodiments, the method may further include: determining that the specific data structure pattern is invalid when, based on the comparison of the specific data structure pattern, it is determined that the specific data structure pattern is not similar to any of the one or more preset data structure patterns; and when it is determined that the specific data structure pattern is invalid, applying a threat detection algorithm on the incoming API message, to detect malicious data in the incoming API message; and determining that the incoming API message is valid when the malicious data is not detected.

[0016] In some embodiments, validating the incoming API message, based on the comparison of the calculated hash value, may include determining that the incoming API message is valid when, based on the comparison of the calculated hash value, it is determined that the calculated hash value matches the one or more preset hash values of the respective at least one structure-defined portion of the valid content.

[0017] In some embodiments, validating the incoming API message, based on the comparison of the calculated hash value, may further include: when, based on the comparison of the calculated hash value, it is determined that the calculated hash value does not match any of the one or more preset hash values of the respective at least one structure- defined portion of the valid content, applying a threat detection algorithm on the incoming API message, to detect malicious data in the incoming API message; and determining that the incoming API message is valid when the malicious data is not detected.

[0018] In some embodiments, the one or more preset hash values may be selected from a set of the preset hash values of the respective at least one structure-defined portion of the valid content; wherein the method may further include, when the malicious data is not detected, supplementing the set of the preset hash values with the calculated hash value.BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of operation, together with objects, features, and advantagesthereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which:

[0020] Fig. 1 is a block diagram, depicting a computing device which may be included in a system for establishing secure communication via API, according to some embodiments;

[0021] Fig. 2A is a block diagram, depicting, in general, a system for establishing secure communication via API, according to some embodiments;

[0022] Fig. 2B is a block diagram, depicting, in detail, aspects of a first- step validation module of the system for establishing secure communication via API, according to some embodiments;

[0023] Fig. 2C is a block diagram, depicting, in detail, aspects of a second-step validation module of the system for establishing secure communication via API, according to some embodiments;

[0024] Fig. 3 is a flow diagram, depicting a method of establishing secure communication via API, according to some embodiments;

[0025] Fig. 4 depicts an example of a Hypertext Transfer Protocol (HTTP) API request;

[0026] Fig. 5 is a table depicting an example of a conversion scheme, facilitating conversion of an API message to an abstracted version, according to some embodiments of the invention.

[0027] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.DETAILED DESCRIPTION OF THE PRESENT INVENTION

[0028] One skilled in the art will realize the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The foregoing embodiments are therefore to be considered in all respects illustrative rather than limiting of the invention described herein. Scope of the invention is thus indicated by the appended claims, rather than by the foregoing description, and all changes that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

[0029] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the 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, discussion of same or similar features or elements may not be repeated.

[0030] Although embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, “processing,” “computing,” “calculating,” “determining,” “establishing”, “analyzing”, “checking”, “choosing”, “selecting”, “omitting”, “training” or the like, may refer to operation(s) and / or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulates and / or transforms data represented as physical (e.g., electronic) quantities within the computer’s registers and / or memories into other data similarly represented as physical quantities within the computer’s registers and / or memories or other information non-transitory storage medium that may store instructions to perform operations and / or processes.

[0031] Although embodiments of the invention are not limited in this regard, the terms “plurality” and “a plurality” as used herein may include, for example, “multiple” or “two or more”. The terms “plurality” or “a plurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. The term “set” when used herein may include one or more items.

[0032] Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, concurrently, or iteratively and repeatedly.

[0033] In embodiments of the present invention, some steps of the claimed method may be performed using machine-learning (ML)-based models or may include actions performed on ML-based models. ML-based models may be configured or “trained” for a specific task, e.g., classification or regression.

[0034] In some embodiments, ML-based models may be artificial neural networks (ANN).

[0035] A neural network (NN) or an artificial neural network (ANN), e.g., a neural network implementing a machine learning (ML) or artificial intelligence (Al) function, may refer to an information processing paradigm that may include nodes, referred to as neurons, organized into layers, with links between the neurons. The links may transfer signals between neurons and may be associated with weights. A NN may be configured or trained for a specific task, e.g., detecting presence of anomalies in a specific data structure pattern of an incoming API message. Training a NN for the specific task may involve adjusting these weights based on examples. Each neuron of an intermediate or last layer may receive an input signal, e.g., a weighted sum of output signals from other neurons, and may process the input signal using a linear or nonlinear function (e.g., an activation function). The results of the input and intermediate layers may be 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 a NN are represented by mathematical constructs, such as activation functions and matrices of data elements and weights. A processor, e.g., CPUs or graphics processing units (GPUs), or a dedicated hardware device may perform the relevant calculations.

[0036] It should be obvious for the one ordinarily skilled in the art that various ML-based models can be implemented without departing from the essence of the present invention. It should also be understood, that in some embodiments ML-based model may be a single ML- based model or a set (ensemble) of ML-based models realizing as a whole the same function as a single one. Hence, in view of the scope of the present invention, the abovementioned variants should be considered equivalent.

[0037] In order to mitigate the abovementioned problems of the prior art, the following concept is provided.

[0038] When analyzing internet traffic, and, in particular, communication via API, it turns out that the absolute majority of the traffic is known, e.g., has already been analyzed and validated. Accordingly, when applying threat detection tools, for example, to the entire API traffic (e.g., to each API message), computational loads on these tools are extremely high, while most of the loads account for redundant threat detection operations, applied to the same or similar messages (or to specific portions of message content) repeatedly.

[0039] Therefore, it is suggested herein to apply an API-specific smart whitelisting and filtering mechanism, in order to filter out “known” (previously validated) messages (or “known” (previously validated) portions of content thereof), and forward, to threat detectiontools, only those messages that are determined as “unknown”. Thereby, heavy computational operations aimed at threat detection are substituted by computationally light search operations.

[0040] Furthermore, after applying threat detection tools to “unknown” API messages and determining that those messages are safe, they may be marked as “known”, i.e., whitelisted, in order to avoid redundant analysis in future.

[0041] The suggested process of filtering out API messages includes multiple steps. As suggested, the first- step validation is directed to determining whether the data structure pattern of the API message is known as valid, since malicious data embedding often causes an alteration in a data structure pattern. If the data structure pattern is determined to have no anomalies and is thereby valid, the filtering mechanism may turn to the second-step validation. At the second-step validation, the message is parsed in order to determine structure-defined portions of its content, and then, each (or, depending on an embodiment, at least one) structure-defined portion is compared with respective preset structure-defined portions of the content that is known to be safe (e.g., that has been checked and validated previously).

[0042] To further speed up the entire process, it is suggested herein to perform said comparison based on the hashed content of API messages. In particular, it is suggested to store preset structure-defined portions of the known content in the hashed form, and to calculate hash values of the structure-defined portions of the incoming API message content. Accordingly, it is further suggested to perform a comparison of the calculated hash values with preset hash values of the respective structure-defined portions of the valid content, and to determine that the incoming API message is valid when, based on the comparison, it is determined that the calculated hash value matches the one or more preset hash values of the respective at least one structure-defined portion of the valid content.

[0043] Thereby, the claimed invention provides for reducing the network communication latency caused by performing threat detection and threat prevention actions, as well as for reducing computational loads required to ensure desired cyber protection level.

[0044] In the context of the present invention, the term “threat” is used as a generic term for different types of data that may cause a potential negative action or event facilitated by a vulnerability that results in an unwanted impact to a computer system or application. For example, said “threat” may represent or include malware or malware-based threats, fraud-based threats, specific known attackers (e.g., may be identified by known signatures of their usage), or bots employing malicious communication, or any other malicious activity, e.g., an attempt to obtain access to restricted resources with malicious or potentially malicious intent (e.g., SQL injections, Log4J vulnerability etc.). It could also involve unknown zero- day vulnerabilities targeting the organization's API that may be detected, e.g., using ML- based techniques (for example, by performing ML-based anomaly detection in API data structure pattern). Accordingly, it shall be understood that the present invention is not limited in respect of detection and prevention of any specific type of cyber threats.

[0045] In the context of the present invention, the term “malicious data” is accordingly used as a generic term for the data (e.g., specific portions of code) that represents a respective cyber threat. Accordingly, “malicious data” may be or may include, e.g.: (a) a malware communication; (b) a request itself, that, at first glance, may be considered legitimate, but, in fact, may request to perform malicious / restricted / unauthorized action, e.g., aimed to get access to restricted data or source; (c) a malicious request (e.g., armed with an exploit); (d) signatures of specific known attackers' activity; and (e) bots employing malicious communication. This list is provided only as an example and shall not be considered exclusive.

[0046] Reference is now made to Fig. 1, which is a block diagram depicting a computing device, which may be included within an embodiment of the system for establishing secure communication via API, according to some embodiments.

[0047] Computing device 1 may include a processor or controller 2 that may be, for example, a central processing unit (CPU) processor, a chip or any suitable computing or computational device, an operating system 3, a memory device 4, instruction code 5, a storage system 6, input devices 7 and output devices 8. Processor 2 (or one or more controllers or processors, possibly across multiple units or devices) may be configured to carry out methods described herein, and / or to execute or act as the various modules, units, etc. More than one computing device 1 may be included in, and one or more computing devices 1 may act as the components of, a system according to embodiments of the invention.

[0048] Operating system 3 may be or may include any code segment (e.g., one similar to instruction code 5 described herein) designed and / or configured to perform tasks involving coordination, scheduling, arbitration, supervising, controlling or otherwise managingoperation of computing device 1, for example, scheduling execution of software programs or tasks or enabling software programs or other modules or units to communicate. Operating system 3 may be a commercial operating system. It will be noted that an operating system 3 may be an optional component, e.g., in some embodiments, a system may include a computing device that does not require or include an operating system 3.

[0049] Memory device 4 may be or may include, for example, a Random- Access Memory (RAM), a read only memory (ROM), a Dynamic RAM (DRAM), a Synchronous DRAM (SD-RAM), a double data rate (DDR) memory chip, a Flash memory, a volatile memory, a non-volatile memory, a cache memory, a buffer, a short-term memory unit, a long-term memory unit, or other suitable memory units or storage units. Memory device 4 may be or may include a plurality of possibly different memory units. Memory device 4 may be a computer or processor non-transitory readable medium, or a computer non-transitory storage medium, e.g., a RAM. In one embodiment, a non-transitory storage medium such as memory device 4, a hard disk drive, another storage device, etc. may store instructions or code which when executed by a processor may cause the processor to carry out methods as described herein.

[0050] Instruction code 5 may be any executable code, e.g., an application, a program, a process, task, or script. Instruction code 5 may be executed by processor or controller 2 possibly under control of operating system 3. For example, instruction code 5 may be a standalone application or an API module that may be configured to receive an incoming API message and to apply the abovementioned multi-step validation procedure on the incoming API message, as further described herein. Although, for the sake of clarity, a single item of instruction code 5 is shown in Fig. 1, a system according to some embodiments of the invention may include a plurality of executable code segments or modules similar to instruction code 5 that may be loaded into memory device 4 and cause processor 2 to carry out methods described herein.

[0051] Storage system 6 may be or may include, for example, a flash memory as known in the art, a memory that is internal to, or embedded in, a micro controller or chip as 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. Various types of input and output data may be stored in storage system 6 and may be loaded from storage system 6 into memory device 4 where it may be processed by processor or controller 2. Insome embodiments, some of the components shown in Fig. 1 may be omitted. For example, memory device 4 may be a non-volatile memory having the storage capacity of storage system 6. Accordingly, although shown as a separate component, storage system 6 may be embedded or included in memory device 4.

[0052] Input devices 7 may be or may include any suitable input devices, components, or systems, e.g., a detachable keyboard or keypad, a mouse and the like. Output devices 8 may include one or more (possibly detachable) displays or monitors, speakers and / or any other suitable output devices. Any applicable input / output (I / O) devices may be connected to Computing device 1 as shown by blocks 7 and 8. For example, a wired or wireless network interface card (NIC), a universal serial bus (USB) device or external hard drive may be included in input devices 7 and / or output devices 8. It will be recognized that any suitable number of input devices 7 and output device 8 may be operatively connected to Computing device 1 as shown by blocks 7 and 8.

[0053] A system according to some embodiments of the invention may include components such as, but not limited to, a plurality of central processing units (CPU) or any other suitable multi-purpose or specific processors or controllers (e.g., similar to element 2), a plurality of input units, a plurality of output units, a plurality of memory units, and a plurality of storage units.

[0054] Reference is now made to Figs. 2A-2C complementary depicting various aspects of system 100 for establishing secure communication via API, according to some embodiments.

[0055] According to some embodiments of the 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 computing devices such as element 1 of Fig. 1. Furthermore, system 100 may be adapted to execute one or more modules of instruction code (e.g., element 5 of Fig. 1) to request, receive, analyze, calculate and produce various data.

[0056] As further described in detail herein, system 100 may be adapted to execute one or more modules of instruction code (e.g., element 5 of Fig. 1) in order to perform steps of the claimed method.

[0057] As shown in Figs. 2A-2C, arrows may represent flow of one or more data elements to and from system 100 and / or among modules or elements of system 100. Some arrows have been omitted in Figs. 2A-2C for the purpose of clarity.

[0058] In some embodiments, system 100 may include API communication module 10. API communication module 10 may be configured to receive incoming API message 10A. Depending on embodiments, incoming API message 10A may be an API request or API response. Incoming API message 10A may have content organized according to specific data structure pattern 10A’.

[0059] Reference is also made to Fig. 4, which depicts an example of an API request (e.g., HTTP API request).

[0060] It may be appreciated that the term “API” may relate to any type of applicationspecific traffic that may be conveyed via a network, including, for example, REST API requests and responses, HTTP requests and responses, Operating System (OS) APIs, Hardware APIs, Database (DB) APIs, and the like.

[0061] For example, as depicted in the HTTP API request example of Fig. 4, API request (e.g., API message 10A shown in Figs. 2A-2C) may be divided into a header portion and a body portion, where each may include fields of various data types and formats (e.g., textual, symbolic and / or numerical formats).

[0062] As known in the art, API request headers typically provide information about the API request’s context, supply authentication credentials, and provide information about the client (e.g., a person, a computing device and / or a browser application) that had initiated the API request.

[0063] For example, API request headers may include user-agent strings that contains information about the type, version and / or identification of operating systems and / or browsers that are being used by a client.

[0064] Pertaining to the example of Fig. 4, fields of a User-Agent string may include: “Mozilla / 5.0”, “(Macintosh; Intel Mac OS X 10.6; rv:25.0)”, “Gecko / 20100101”, and “Firefox / 25.0”.

[0065] In another example, API request headers may include set-cookie strings, which are responsible for sending cookies between respective network nodes.

[0066] Set cookie strings may include one or more attributes and corresponding value formats, such as Expires=<date>, Max-Age=<number>, Domain=<domain-value>, Path=<path-value>, Secure, HttpOnly, SameSite=Strict, SameSite=Eax, SameSite=None, and Secure. Pertaining to the example of Fig. 4, fields of the set cookie string include, for example: ck= “c-v SzHCN8nE4JOP7t2TeOOwa...”, UU“PXyF8ixMSPAYjDxju9_OK2tC. . .”, Session = “85c301e5-d3ad-483e-0. . etc., alongside corresponding domain and expiration fields.

[0067] In another example, API request headers may include host strings, which specify host or Internet Protocol (IP) addresses and / or port numbers of a network node to which the API request is being sent. Valid IPV4 syntax of host strings (Host: <host>:<port>) should be in the format of: {0 <= Num < 256} . {0 <= Num < 256} . {0 <= Num < 256} . {0 <= Num < 256} : { 1 <= Num <= 65535}. Pertaining to the example of Fig. 4, the fields of the Host string are: “127.0.0.1:5000”.

[0068] In some embodiments, system 100 may include validation procedure management module 20, first-step validation module 30 and second-step validation module 40. In some embodiments, validation procedure management module 20 may be configured to apply and to manage the conduction of a multi-step validation procedure on incoming API message 10A.

[0069] In some embodiments, first-step validation module 30 may be configured to perform first-step validation procedure as further described in detail with reference to Fig. 2B.

[0070] In some embodiments, second- step validation module 40 may be configured to perform second-step validation procedure as further described in detail with reference to Fig. 2C.

[0071] In some embodiments, system 100 may further include threat detection module 50. In some embodiments, validation procedure management module 20 may be further configured to transfer incoming API message 10A to threat detection module 50, when message 10A fail to pass said first- and / or second-step validation procedure, as described with reference to Figs. 2B and 2C further below. Threat detection module 50 may be configured to apply the respective threat detection algorithm to incoming API message 10A (or to specific portions thereof) to determine presence of malicious data therein.

[0072] As indicated above, the present invention suggests API-specific smart whitelisting and filtering mechanism, in order to filter out “known” (previously validated) messages (or “known” (previously validated) portions of content thereof), and forward, to threat detection tools (e.g., to threat detection module 50), only those messages that are determined as “unknown”. Accordingly, it shall be understood that the present invention is not limited with respect to the threat detection algorithm applied. Hence, the threat detection algorithm, as referred herein, may include various threat detection algorithms known in the art. E.g., thethreat detection algorithm may be or may include Cherrybomb API security tool. Spectral OWASP API Security tool, may be based on so-called detection rules such as Yara, Sigma, Suricata, Snort etc.

[0073] In some embodiments, validation procedure management module 20 may be configured to output API message validation result 20A, indicating whether, in result of multi-step validation procedure, it is determined that API message 10A is valid or not. In case API message 10A is determined valid, it may be further transferred to the designated node (not shown in figures), thereby API communication may proceed as expected. Otherwise, in case API message 10A is determined invalid, it may be further transferred, e.g., to content disarm and reconstruction (CDR) tools (not shown in figures), to disarm and / or reconstruct the detected malicious data.

[0074] Referring now to Fig. 2B, aspects of first-step validation module 30 of system 100 for establishing secure communication via API are described, according to some embodiments.

[0075] In some embodiments, first-step validation module 30 may be configured to determine whether the specific data structure pattern is valid.

[0076] E.g., in some embodiments, first-step validation module 30 may be configured to convert received API message 10A (such as API request shown in Fig. 4), to produce an abstracted version of API message 10A.

[0077] Reference is also made to Fig. 5, which is a table depicting an example of a conversion scheme, facilitating conversion of API message 10A (such as API request shown in Fig. 4) to an abstracted version of API message 10A.

[0078] The term “abstracted” may be used herein to indicate that abstracted API message versions may represent an abstraction (e.g., a lossy abstraction) of original API messages (e.g. API message 10A). For example, as shown by pairs of columns in the example of Fig. 5, first-step validation module 30 may convert each string in API message 10A to the string “str”, which is a representative, abstract version of the original string in API message 10A.

[0079] Additionally, or alternatively, abstracted version of API message 10A may be, or may include fully textual representation of API message 10A and may thereby also be referred to as “fully textual” version thereof.

[0080] For example, as shown by pairs of columns in the example of Fig. 5, first-step validation module 30 may convert each non-textual symbol in API message 10A to one ormore predefined textual symbols or strings, to form abstracted version of API message 10A as fully textual vector. For example, numerical values in API message 10A may be converted to the string “numeric” in the abstracted version thereof. In another example, colonsymbols in API message 10A may be converted to the string “colon” in the abstracted version thereof, etc. Other such textual representations of symbols in API message 10A may also be possible.

[0081] Pertaining to the example of Fig. 4, first-step validation module 30 may convert an HTTP API request string such as “ / orders / get / id / 9013 gzip, deflate, br de-CH none web socket ?1 document” in the API request shown in Fig. 4 to produce abstracted version of the API request as the following, fully textual representation: [slash str slash str slash str slash numeric str cmma str cmma str minus str str stun numeric str].

[0082] Additionally, or alternatively, first-step validation module 30 may be configured to identify specific fields of API message 10A, and maintain (e.g., refrain from abstracting) the values of these fields. For example, a Uniform Resource Locator (URL) of an HTTP API request (such as shown in Fig. 4) may include one or more combinations of key + value entries. First-step validation module 30 may be configured to maintain the key in its original form, and only abstract the value entry. In this example, first-step validation module 30 may convert a key + value entry such as “Name= Abraham” to the following, partially abstracted, fully textual entries [name = str] or [name equal str], and include these entries in the abstracted version of the API request.

[0083] As can be appreciated, abstracting the specific value entries (specific field values) of API message 10A (as described above) renders the content negligible. However, by maintaining field names and the division into a header and body portion, the information about data structure pattern 10 A’ remains informative. Consequently, the abstracted version can be considered representative of data structure pattern 10A’.

[0084] According to some embodiments, API messages (such as API message 10A) may include, or may be associated with an endpoint information. The term “endpoint information” may refer herein to any type of data or metadata that may represent a type, an origin or identification of a respective API message (e.g., API message 10A).

[0085] For example, the endpoint information may include: (a) a method of the API message 10A, (b) a hostname associated with, or accommodating API message 10A, and (c) a path included in API message 10A.

[0086] Pertaining to the example of Fig. 4, the endpoint information may include or may be defined by (a) the method or type of API request shown in Fig. 4 (e.g., “GET”), (b) the hostname of the API request (e.g., “http: / / 127.0.0.1:5000”), and (c) the path of the API request (e.g., “ / orders / get / id / 9013”).

[0087] Additionally, or alternatively, the endpoint information may be configured to include any additional information which may uniquely identify a type of API message 10A.

[0088] As elaborated herein, endpoint information may represent a unique type of an API message 10A in a sense that first-step validation module 30 may evaluate anomaly of data structure pattern 10A’ in relation to specific types, as manifested by unique combinations of the endpoint information values (values of respective fields).

[0089] E.g., some aspects of certain data structure pattern (e.g., data structure pattern 10A’) may be considered normal (valid) for one type of API messages (e.g., API message 10A), as defined by the respective endpoint information, but be abnormal for another type of API messages. Accordingly, in some embodiments, first-step validation module 30 may include means (e.g., ML-based structure validation model 31 and rule-based structure validation model 32, described further below) configured (e.g., trained) for determining data structure anomalies for each type of API messages specifically. Furthermore, in some embodiments, first-step validation module 30 may be further configured to pre-categorize API messages, based on their endpoint information, before proceeding with data structure validation.

[0090] In some embodiments, first-step validation module 30 may further include machinelearning (ML)-based structure validation model 31. ML-based structure validation model 31 may be respectively pretrained to detect a presence of anomalies in the specific data structure pattern (e.g., data structure pattern 10A’) of the incoming API message (e.g., API message 10A).

[0091] E.g., in some embodiments, ML-based structure validation model 31 may be trained to produce an embedding (representation) of textual data (e.g., textual data of the abstracted version of API messages) in a textual embedding space.

[0092] According to some embodiments, during a training stage, first-step validation module 30 may receive a training dataset, that may include a plurality of verified, legitimate (e.g., devoid of anomalous) API messages that may form a baseline for anomaly detection. In some embodiments, each such baseline API message may be associated with a corresponding endpoint information (e.g., specific type of API messages). First-stepvalidation module 30 may produce, for one or more (e.g., each) baseline API messages of the training dataset, a respective abstracted version (e.g., according to the method described above).

[0093] First-step validation module 30 may further apply an unsupervised training algorithm, to train ML-based structure validation model 31, to produce baseline API vectors based on the abstracted versions of the baseline API messages, and, optionally, based on the endpoint information thereof, said baseline API vectors representing respective abstracted version of API messages in a textual embedding space.

[0094] In some embodiments, during training, ML-based structure validation model 31 may produce the textual embedding space so as to represent a reduced dimensionality of text in relation to the abstracted version of baseline API messages.

[0095] According to some embodiments, during an inference stage, ML-based structure validation model 31 may receive an abstracted version of API message 10A (e.g., in a fully textual format, obtained as described above). First-step validation module 30 may further infer model 31 on API message 10A (e.g., on the abstracted version thereof), to generate a vector representation of the abstracted version of API message 10A that represents an embedding of the text thereof in the textual embedding space.

[0096] According to some embodiments, each entry of the calculated vector representation of API message 10A may correspond to a specific textual feature, represented as a specific dimension in the textual embedding space.

[0097] ML-based structure validation model 31 may include or may be implemented by any type of ML-based model architecture that may enable or facilitate extraction of numerical features from text, as known in the art of Natural Language Processing (NLP). For example, model 31 may include an instantiation of the currently available Bidirectional Encoder Representations from Transformers (BERT) model, FastText model, Word2Vec model, and / or any other appropriate ML-based model for language embedding. As known in the art, such model architectures (e.g., BERT, FastText, Word2Vec, and the like) may facilitate efficient learning of representations of words and sentences as numerical vectors (or, as also referred herein, vector representations) via unsupervised training.

[0098] Additionally, or alternatively, model 31 may include a tokenization module, and a corresponding token-based language model. For example, model 31 may include an instantiation of the currently available RoBERTa model. As known in the art, the RoBERTamodel may facilitate efficient learning of representations of sub-word portions of text, denoted herein as ‘tokens’ (e.g., letters and syllables, etc.) as numerical vector representations via unsupervised training.

[0099] Such vector representations may therefore be viewed as an embedding layer, which manifests patterns in textual representation of incoming API messages (such as API message 10A), in particular, in their data structure patterns (such as data structure pattern 10A’). First- step validation module 30 may subsequently analyze such vector representations to determine or identify anomalies data structure patterns of incoming API messages (e.g., in pattern 10 A’ of API message 10 A).

[0100] In some embodiments, ML-based structure validation model 31 may further include a nearest neighbor, or Approximate Nearest Neighbor (ANN) model. As known in the art, an ANN model may include a plurality of points in a multidimensional feature space, each defined by features’ values of a respective data example, corresponding to the dimensions of the multidimensional space. An ANN model may be utilized to facilitate a proximity search, such as a Nearest Neighbor Search (NNS), as commonly referred to in the art. During a proximity search, points in the ANN model that are closest to a given target, or query point of interest may be identified.

[0101] Closeness among points in the ANN model may represent similarity among features of the underlying data examples. This closeness may be expressed by a distance function value, which may represent similarity / dis similarity among the features of respective data examples. Therefore, model 31 may be configured to utilize a proximity search to identify one or more baseline data examples (the ones obtained during the training stage, a described above), that are characterized by features values represented in the multidimensional space, that are most similar to those of a queried data sample (e.g., of the vector representation of API message 10A), meaning that these identified baseline data examples are located closer, in the multidimensional space, to the queried data sample (e.g., the vector representation of API message 10A), than other baseline data examples.

[0102] It should be understood, that during the training stage, first-step validation module 30 may obtain, e.g., using above-described textual embedding, a plurality of baseline API vectors, based on abstracted versions of respective baseline API messages. One or more (e.g., each) baseline API vectors may be, or may represent an embedding of text of an abstracted version of respective baseline API message in the textual embedding space. Forexample, each entry of baseline API vectors may correspond to a specific textual feature, represented as a specific dimension in the textual embedding space.

[0103] Thereby, first-step validation module 30 may obtain, or calculate ANN model based on these baseline API vectors of the textual embedding space.

[0104] Accordingly, in some embodiments, said multidimensional space of the ANN model may be the same or correspond to the textual embedding space, hence, these terms may be used herein interchangeably. Accordingly, dimensions of the ANN model may correspond to the dimensions of the textual embedding space. In other words, each API vector may be represented as a point in the multidimensional space of ANN model.

[0105] ML-based structure validation model 31 may therefore support a proximity search (e.g., nearest neighbor search) among a plurality of baseline API vectors, to identify baseline API message that are most similar to API message 10A, based on the calculated distance metric value.

[0106] Additionally, or alternatively, ML-based structure validation model 31 may include a separate representation for each endpoint. For example, for each combination of endpoint information, model 31 may have a specific, unique labelling. In such embodiments, model 31 may confine the nearest neighbor search to baseline API vectors that pertain to the same endpoint (e.g., have the same combination of endpoint information as API message 10A).

[0107] According to some embodiments, first- step validation module 30 may be further configured to select one or more baseline API vectors based on the calculated distance metric value (e.g., the ones having vector representations located close, in the multidimensional feature space, to the vector representation of the API message 10A). First-step validation module 30 may further calculate a similarity metric value, representing similarity of the vector representation of API message 10A to the one or more selected baseline API vectors. In some embodiments, similarity metric value may represent cosine similarity. For example, similarity metric value may be a function (e.g., a maximum value, an average value, a weighted sum value, etc.) of the distance metric values of the selected one or more baseline API vectors.

[0108] In some embodiments, first-step validation module 30 may be further configured to compare the calculated similarity metric value with a predefined threshold value, and, if the similarity metric value is lower than a predefined threshold value, may output structurevalidation result 31 A, indicating that data structure pattern 10A’ is anomalous. Accordingly, if the similarity metric value is higher than the threshold value, first-step validation module 30 may output structure validation result 31 A, indicating that data structure pattern 10A’ is normal and proceed to second- step validation, as described further below.

[0109] In some additional or alternative embodiments, ML-based structure validation model 31 may be or may include a structure of an autoencoder, that may be pretrained to reliably reconstruct API messages of a normal (e.g., standard, not having anomalies) data structure pattern (e.g., abstracted versions of baseline API messages, or vector representations thereof, as described above). While being pretrained on “normal” API messages only, such an autoencoder may thereby fail to reconstruct API message of an anomalous data structure, thereby indicating presence of anomaly therein.

[0110] It shall be further understood that ML-based structure validation model 31 may include a plurality of ML-based models 31, each pretrained for specific types of data structure patterns.

[0111] It shall also be understood that the abovementioned configurations of ML-based model 31 are provided only as an example and other configurations may fall under the scope of the present invention.

[0112] In some embodiments, validation procedure management module 20 may be further configured to infer ML-based structure validation model 31 on the incoming API message (e.g., API message 10A). ML-based structure validation model 31 may be further configured to output normal / anomalous structure classification result 31 A, indicating whether the presence of anomalies in the specific data structure pattern (e.g., data structure pattern 10A’) of the incoming API message (e.g., API message 10A) has been detected. In some embodiments, said classification result 31A may be appended by confidence metric value 31 A’, representing confidence (e.g., probability) of providing a respective prediction (e.g., presence / absence of anomaly) by ML-based structure validation model 31. In case model 31 has an autoencoder-based structure, confidence metric value 31 A’ may be formed based on reconstruction error value, indicating the extent of the difference between original API message 10A and the respective reconstructed one. In case model 31 has the abovedescribed ANN structure, confidence metric value 31 A’ may be formed based on, or be represented by, the calculated similarity metric value.

[0113] In some embodiments, first-step validation module 30 may include rule-based structure validation model 32. In some embodiments, rule-based structure validation model 32 may be configured (i) to perform a comparison of the specific data structure pattern (e.g., data structure pattern 10A) with one or more preset data structure patterns (e.g., data structure patterns 32A” taken from data structure pattern database 32A’); and (ii) to determine that the specific data structure pattern (e.g., data structure pattern 10A) is valid when, based on the comparison of the specific data structure pattern, it is determined that the specific data structure pattern (e.g., data structure pattern 10A) is similar to the one or more preset data structure patterns (e.g., data structure patterns 32A” taken from data structure patterns database 32A’). In some embodiments, said database 32A’ may be formed in advance, e.g., manually.

[0114] It shall be understood that rule-based structure validation model 32 may be formed based on predefined set of rules, e.g., checking whether the specific data structure pattern (e.g., data structure pattern 10A) includes specific structure-defined portion A and structure-defined portion B, checking whether structure-defined portion A comes before structure-defined portion B, whether structure-defined portion A has size of a predefined range, same as specific preset data structure pattern (e.g., data structure pattern 32A” taken from database 32A’) etc.

[0115] E.g., API request header fields are typically derived from a limited set of options. Accordingly, rule-based structure validation model 32 may use a predefined set of rules to verify API request headers’ content (e.g., by comparing the abstracted version of API message 10A with abstracted versions of the baseline API messages). Additionally, such a content verification may be performed further considering the abovementioned endpoint information, as set of rules may vary depending thereon.

[0116] In this example, rules may include definition of legitimate, or illegitimate header field such as set-cookie strings fields, host fields, Internet Protocol (IP) addresses, port numbers, and the like. It shall be understood that, for the matter of structure pattern validation, the rules may be limited to the presence / absence of specific fields, not to their values.

[0117] It shall be understood that the present invention is not limited to any specific configuration of rule-based structure validation model 32, as well as ML-based structure validation model 31. By providing embodiment of Figs. 2A-2C, it is among other thingsintended to show that first-step validation module 30 may perform API message structure validation using either or both rule-based and ML-based techniques.

[0118] In some embodiments, validation procedure management module 20 may be further configured to apply rule-based structure validation model 32 on the incoming API message (e.g., API message 10A, or the abstracted version thereof, as explained above). Rule-based structure validation model 32 may be further configured to output structure comparison result 32A, indicating whether it has been determined that the specific data structure pattern (e.g., data structure pattern 10A) is similar to the one or more preset data structure patterns (e.g., data structure patterns 32A” taken from data structure pattern database 32A’, e.g., data structure patterns of abovementioned baseline API messages) or not, and / or whether the specific data structure pattern complies with the predefined set of rules.

[0119] In some embodiments, first-step validation module 30 may further include resulting structure validation module 33. Resulting structure validation module 33 may be configured to receive normal / anomalous structure classification result 31 A, confidence metric value 31 A’, and structure comparison result 32A. In some embodiments, resulting structure validation module 33 may be further configured to form structure validation result 33 A, based on classification result 31 A, confidence metric value 31 A’ and comparison result 32A.

[0120] E.g., in some embodiments, resulting structure validation module 33 may be configured to determine that the specific data structure pattern (e.g., pattern 10A’) is invalid when, based on the comparison of the specific data structure pattern (e.g., pattern 10A’), it is determined, by model 32, that the specific data structure pattern (e.g., pattern 10A’) is not similar to any of the one or more preset data structure patterns (e.g., patterns 32A”); and to determine that data structure pattern 10 A’ is valid when it is determined, by model 32, that the specific data structure pattern (e.g., pattern 10A’) is similar to at least one of the one or more present data structure patterns (e.g., patterns 32A”). Accordingly, in some embodiments, resulting structure validation module 33 may be further configured to determine that the specific data structure pattern (e.g., pattern 10A’) is valid when the presence of anomalies is not detected by model 31; and to determine that the specific data structure pattern (e.g., pattern 10A’) is invalid when the presence of anomalies is detectedby model 31. Resulting structure validation module 33 may be further configured to output respective structure validation result 33A.

[0121] It shall be understood that, within the scope of the present invention, various logic may be applied to form structure validation result 33A and the present invention is not limited in this regard. E.g., resulting structure validation module 33 may be configured to give priority to structure comparison result 32A in case it is “positive” (e.g., if one or more preset data structure patterns 32 A” similar to data structure pattern 10A’ have been found) and to neglect structure classification result 31 A, thereby outputting structure validation result 33A indicating that data structure pattern 10A’ of API message 10A is valid. In case structure comparison result 32A is “negative” (e.g., if no preset data structure patterns 32A’ ’ similar to data structure pattern 10 A’ have been found), resulting structure validation module 33 may be further configured to prioritize structure classification result 31A and, e.g., (a) if confidence metric value 31 A’ is above a predefined threshold value, indicating the presence of anomaly in data structure pattern 10A’ - to output structure validation result 33A indicating that data structure pattern 10 A’ of API message 10A is invalid; and (b) if confidence metric value 31 A’ is below the predefined threshold value, indicating the absence of anomaly in data structure pattern 10A’ - to output structure validation result 33 A indicating that data structure pattern 10A’ of API message 10A is valid.

[0122] It shall be understood that abovementioned algorithm of using ML-based structure validation model 31 and rule-based structure validation model 32 in combination is provided only as an example clarifying the concept of the invention, and other, even completely different algorithms may be applied herein. Furthermore, in some alternative embodiments, only one of ML-based structure validation model 31 and rule-based structure validation model 32 may be included and applied, or, alternatively, validation procedure management module 20 may select which of models 31 and 32 to apply depending on specific data structure pattern type (e.g., pattern 10A’) of incoming API message (e.g., API message 10A).

[0123] System 100 may be further configured to transfer structure validation result 33A to validation procedure management module 20. Validation procedure management module 20 may be further configured to transfer, in case structure validation result 33A indicates that structure 10A’ is invalid, API message 10A to threat detection module 50.

[0124] Threat detection module 50 may be configured to apply a threat detection algorithm to the incoming API message (e.g., API message 10A), to detect malicious data in the incoming API message (e.g., API message 10A). Threat detection module 50 may be further configured to transfer threat detection result (not shown), indicating whether there was malicious data detected, to validation procedure management module 20. Accordingly, validation procedure management module 20 may be further configured to determine that incoming API message 10A is valid when the malicious data is not detected, and that message 10A is invalid when the malicious data is detected, and to output the respective API message validation result 20A (as shown in Fig. 2A).

[0125] In some embodiments, validation procedure management module 20 may be further configured to supplement preset data structure patterns 32A” of database 32A’ with data structure pattern 10A”, in case there is no malicious data detected in API message 10A by threat detection module 50.

[0126] Validation procedure management module 20 may be further configured to proceed to second-step validation (as further described with reference to Fig. 2C), when it is determined that data structure pattern 10A’ is valid (which is indicated in structure validation result 33A).

[0127] Referring now to Fig. 2C, aspects of second-step validation module 40 of system 100 for establishing secure communication via API are described, according to some embodiments.

[0128] In some embodiments, second-step validation module 40 may be configured to determine whether the content of the incoming API message (e.g., message 10A) is valid.

[0129] In some embodiments, second-step validation module 40 may include parsing module 41. Parsing module 41 may be configured to parse the incoming API message (e.g., API message 10A) to determine structure-defined portions 41A of the content of the API message.

[0130] In the context of the present invention, by “structure-defined portions”, the separate or stand-alone portions of the API message (e.g., API message 10A) content, as they defined by the message data structure pattern (e.g., pattern 10A’), should be understood.

[0131] In some embodiments, second-step validation module 40 may further include hashing module 42. Hashing module 42 may be configured to receive structure-defined portions 41 A of the content. Hashing module 42 may be further configured to calculate hashvalues 42A of each of structure-defined portions 41A, e.g., using any of known hashing algorithms (e.g., strong hashing algorithm SHA-256).

[0132] In some embodiments, second-step validation module 40 may further include hash comparison module 43. Hash comparison module 43 may be configured to perform a comparison of calculated hash values 42A with preset hash values 43 A” (e.g., taken from preset hash value database 43 A’) of respective structure-defined portions (same types of portions as portions 41 A) of a valid content. Hash comparison module 43 may be further configured to output hash comparison result 43A, indicating, for each of calculated hash values 42A, whether the respective calculated hash value (e.g., hash value 42A) matches at least one of respective preset hash values of respective structure-defined portions of the valid content (e.g., preset hash values 43 A” taken from database 43 A’).

[0133] E.g., structure-defined portion may represent specific string-type field or variable represented herein as X, which has certain value (content) represented as z. After parsing, it may be determined that incoming API message 10A includes respective structure-defined portion 41 A - X, wherein X has value io. Hashing module 42 may calculate hash value 42 A of io which equals io ’. There may be a known variety of values of X commonly used in API messages of this specific data structure pattern 10A’. E.g., X may be expected to have one of 20 known (preset) values represented herein as a set {ii, i , z’20} - Accordingly, database 43 A’ may store hash values 43 A” represented herein as a set {O ’, O ’, ..., z'20 ’} of abovementioned preset values {ii, iz, z'20}, respectively. Hence, hash comparison module 43 may compare calculated hash value io ’ with each of preset hash values {O ’, 0 ’, ..., Z20’}, thereby determining whether X = io is known as “valid”. Accordingly, if hash comparison module 43 has found, within preset hash values {0 ’, 0 ’, ..., Z20 ’}, a hash value that matches io ’, hash comparison module 43 may output hash comparison result 43 A, indicating that io ’ matches one of preset hash values 43 A”. If hash comparison module 43 has not found, within preset hash values {O ’, 0 ’, ..., Z20 ’}, a hash value that matches io ’, hash comparison module 43 may output hash comparison result 43 A, indicating that io ’ does not match any of preset hash values 43 A’ ’ .

[0134] In some embodiments, system 100 may be further configured to transfer hash comparison result 43 A to validation procedure management module 20. Validation procedure management module 20 may be further configured to determine that the incoming API message (e.g., API message 10A) is valid when, based on the comparison of thecalculated hash values (e.g., hash values 42A), it is determined, in hash comparison result 43A, that the calculated hash values match (or, in certain embodiments, may be similar to) the one or more preset hash values (e.g., hash values 43 A”) of the respective structure- defined portions (e.g., same as portions 41 A) of the valid content.

[0135] In some embodiments, validation procedure management module 20 may be further configured to transfer API message to threat detection module 50, when, based on the comparison of the calculated hash values (e.g., hash values 42A), it is determined, in hash comparison result 43 A, that at least one of the calculated hash values does not match (or, in certain embodiments, is not similar to) any of the one or more preset hash values (e.g., hash values 43 A”) of the respective structure-defined portions (e.g., same as portions 41 A) of the valid content. Threat detection module 50 may be further configured to apply the threat detection algorithm on incoming API message 10A, to detect malicious data therein. Threat detection module 50 may be further configured to transfer threat detection result (not shown), indicating whether there is malicious data detected, to validation procedure management module 20. Accordingly, validation procedure management module 20 may be further configured to determine that incoming API message 10A is valid when the malicious data is not detected, and that message 10A is invalid when the malicious data is detected, and to output the respective API message validation result 20A (as shown in Fig. 2A).

[0136] In some particular embodiments, validation procedure management module 20 may be configured to transfer to threat detection module 50 not the entire API message 10A, but only those structure-defined portions thereof (e.g., potions 41A) with respect to which there is no matching hash values 43 A’ found by hash comparison module 43. Threat detection module 50 may be further configured to apply the threat detection algorithm on respective structure-defined portions 41 A of incoming API message 10A, to detect malicious data in respective portions 41 A. It shall also be understood that, in practice, it may not be reasonable to apply the abovementioned hashing-based comparison technique to every obtained structure-defined portion 41A of API message 10A. Some structure-defined portions 41A (e.g., certain fields and parameters) may have an innumerable number of values, e.g., such fields as “login” and “password”. Hence, in some embodiments, parsing module 41 may be further configured to identify such fields and to forward their content to the threat detection procedure (e.g., to threat detection module 50) right after parsing API message 10A (therefore skipping hash calculation and hash comparison procedures).

[0137] In such embodiments, the present invention provides additional improvement of technological field of cybersecurity by further reducing computational loads on threat detection tools, and thereby decreasing network communication latency, since less data is provided to threat detection tools for analysis (not necessarily the entire API message 10A, but only certain structure-defined portions 41 A thereof).

[0138] It shall be understood that, in some embodiments , threat detection module 50 may include a plurality of threat detection modules 50, each specifically configured for threat detection in specific types of structure-defined portions. Thereby, being more specifically configured, threat detection modules 50 may provide more reliable threat detection and detection results, further improving the technological field of cybersecurity.

[0139] In some embodiments, validation procedure management module 20 may be further configured to supplement the set of the preset hash values (e.g., set of preset hash values 43 A”) with respective calculated hash value (e.g., hash value 42A), when the malicious data is not detected in API message 10A (or in respective structure defined portion 41A of API message 10A, if only said portion is subject to the analysis) after applying the threat detection algorithm by threat detection module 50. Thereby, when the following API messages having the same data structure pattern and same respective structure defined portions will be analyzed, hash comparison module 43 may compare respective hash values 42A of these new API messages with the supplemented list of preset hash values 43 A”, including hash values (e.g., hash values 42A) of API messages that were previously analyzed and determined as not containing malicious data.

[0140] Thereby, the described concept provides constantly improving system 100 for secure communication via API, which is configured to adapt to new incoming API traffic, thus progressively reducing loads on threat detection tools and decreasing network communication latency.

[0141] As indicated above, in case API message 10A has been determined as invalid, it can be further transferred to malware detection tools and / or CDR tools.

[0142] As for CDR tools, in some embodiments, a CDR tool may be configured to create a disarm rule based on the data structure pattern 10’ (e.g., using the abstracted version of API message 10A) and the cyber vulnerability of data structure pattern 10’. E.g., the disarm rule may include an association between (a) instantiation of said cyber vulnerability of data structure pattern 10’ and (b) at least one omission action, required for omitting at least oneportion of the data structure (defined by data structure pattern 10A’), said portion comprising that cyber vulnerability. In the context of the present invention, the cyber vulnerability may refer to weaknesses or flaws of the original API message (e.g., API message 10A) that were exploited by the attacker to embed a malicious data thereinto. E.g., such a cyber vulnerability may be associated with a section (e.g., header block, specific field, etc.) of data structure pattern 10 A’ that is determined, by first-step validation module 30, as containing anomaly, or with a specific field having with respect to which it was determined, by second-step validation module 40, that the respective hash value does not match any of the one or more preset hash values (e.g., hash values 43 A”) of the respective structure-defined portions (e.g., same as portions 41 A) of the valid content. In some embodiments, such a cyber vulnerability may be further associated with the specific malicious content detected in an invalid portion of API message 10A (e.g., which may be indicated in API message validation result 20A), by the threat detection module 50, as described above.

[0143] For example, the omission action may include omission of a specific keyword located in a specific section of the data structure of data structure pattern 10A’. In another example, the omission action may include a definition for omission of one or more sections of data structure.

[0144] The CDR tool may be further configured to apply the omission action of the created disarm rule on API message 10A that includes the respective known cyber vulnerability. CDR tool may be further configured to output a disarmed version of API message 10A. In some embodiments, if the omission action results in deleting content from API message 10A that does not affect its main purpose, the disarmed version may be further transferred to the initially designated recipient.

[0145] Additionally or alternatively, the CDR tool may be further configured to create a reconstruction rule, based on data structure pattern 10’ (e.g., using the abstracted version of API message 10A) and the known cyber vulnerability of data structure pattern 10’. The reconstruction rule may include an association between (a) location of instantiation of the cyber vulnerability in a data structure (e.g., defined by data structure pattern 10A’), and (b) at least one reconstruction action, required for maintaining a predefined functionality of the data structure following the omission of the cyber vulnerability from the data structure.

[0146] For example, data structure pattern 10 A’ of API message 10 A may include a body section and a header section, wherein header section includes a cyber vulnerability, e.g., afield that after the malware analysis was determined as having potentially malicious value (e.g., a link to a malicious content). For such cases, reconstruction action may include replacing the existing header section (or a value of the respective field thereof) with a template header section (or with a template field value, respectively).

[0147] In some embodiments, the CDR tool may be further configured to create the reconstruction rule further based on the endpoint information of API message 10A. E.g., system 100 may have a legitimate API message stored (e.g., as a baseline API message, described above) having the same endpoint information (e.g., type, IP address, etc.) as the API message 10A that is considered malicious. Accordingly, in such cases, the reconstruction action may include, e.g., replacing the existing header section (or a value of the respective field) of API message 10A with a header section (or with a template field value) of said legitimate API message.

[0148] Accordingly, in some embodiments, the CDR tool may be further configured to apply the respective reconstruction action of the created reconstruction rule on API message 10A (or, e.g., on the disarmed version thereof), thereby reconstructing the respective section (or a value of the respective field) of API message 10A and outputting a reconstructed version of API message 10A. The reconstructed version of API message may be further transferred to the designated recipient.

[0149] Referring now to Fig. 3, a flow diagram is presented, depicting a method of establishing secure communication via API, by at least one processor (e.g., processor 2 of Fig. 1), according to some embodiments.

[0150] As shown in step S1005, the at least one processor (e.g., such as processor 2 of Fig. 1) may receive an incoming API message (e.g., API message 10A, as shown in Figs. 2A-2C) having a content organized according to a specific data structure pattern (e.g., data structure pattern 10A’, as shown in Figs. 2A-2C). Step S1005 may be carried out by API communication module 10 (as described with reference to Fig. 2A).

[0151] As shown in step S1010, the at least one processor (e.g., such as processor 2 of Fig. 1) may apply, on the incoming API message (e.g., API message 10A, as shown in Figs. 2A-2C), a first-step validation procedure, comprising determining whether the specific data structure pattern (e.g., data structure pattern 10A’, as shown in Figs. 2A-2C) is valid. Step S1010 may be carried out by first-step validation module 30 (as described with reference to Fig. 2B).

[0152] As shown in step S1015, the at least one processor (e.g., such as processor 2 of Fig. 1), when it is determined that the specific data structure pattern (e.g., data structure pattern 10A’, as shown in Figs. 2A-2C) is valid, may parse the incoming API message (e.g., API message 10A, as shown in Figs. 2A-2C) to determine at least one structure-defined portion of the content (e.g., structure-defined portion 41 A, as shown in Fig. 2C). Step S 1015 may be carried out by parsing module 41 (as described with reference to Fig. 2C).

[0153] As shown in step S1020, the at least one processor (e.g., such as processor 2 of Fig. 1), may calculate a hash value (e.g., hash value 42A, as shown in Fig. 2C) of the at least one structure-defined portion of the content (e.g., structure-defined portion 41A, as shown in Fig. 2C). Step S1020 may be carried out by hashing module 42 (as described with reference to Fig. 2C).

[0154] As shown in steps S1025 and S1030, the at least one processor (e.g., such as processor 2 of Fig. 1), may perform a comparison of the calculated hash value (e.g., hash value 42 A, as shown in Fig. 2C) with one or more preset hash values of the respective at least one structure-defined portion of a valid content (e.g., preset hash values 43 A”, as shown in Fig. 2C). Steps S 1025 and S 1030 may be carried out by hash comparison module 43 (as described with reference to Fig. 2C).

[0155] As shown in step S1035, the at least one processor (e.g., such as processor 2 of Fig. 1), may determine that the incoming API message (e.g., API message 10A, as shown in Figs. 2A-2C) is valid when, based on the comparison of the calculated hash value (e.g., hash value 42A, as shown in Fig. 2C), it is determined that the calculated hash value (e.g., hash value 42A, as shown in Fig. 2C) matches the one or more preset hash values of the respective at least one structure-defined portion of the valid content (e.g., preset hash values 43 A”, as shown in Fig. 2C). Step S1035 may be carried out by validation procedure management module 20 (as described with reference to Fig. 2C).

[0156] As shown in step S1040, the at least one processor (e.g., such as processor 2 of Fig. 1), when, (a) it is determined that the specific data structure pattern (e.g., data structure pattern 10A’, as shown in Figs. 2A-2C) is invalid; and / or (b) based on the comparison of the calculated hash value (e.g., hash value 42A, as shown in Fig. 2C), it is determined that the calculated hash value (e.g., hash value 42A, as shown in Fig. 2C) does not match any of the one or more preset hash values of the respective at least one structure-defined portion of the valid content (e.g., preset hash values 43 A”, as shown in Fig. 2C), applying a threatdetection algorithm on the incoming API message (e.g., API message 10A, as shown in Figs. 2A-2C), to detect malicious data in the incoming API message (e.g., API message 10A, as shown in Figs. 2A-2C). Step S1040 may be carried out by validation procedure management module 20 and threat detection module 50 (as described with reference to Fig. 2C).

[0157] As can be seen from the provided description, the claimed invention represents a system and method for establishing secure communication via API which provide an improvement of the technological field of cybersecurity by reducing network communication latency caused by performing threat detection and threat prevention actions, as well as reducing computational loads required to achieve and maintain a desired cyber protection level.

[0158] Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Furthermore, all formulas described herein are intended as examples only and other or different formulas may be used. Additionally, some of the described method embodiments or elements thereof may occur or be performed at the same point in time.

[0159] While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents may occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the invention.

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

Claims

CLAIMS1. A method of establishing secure communication via application programming interface (API) by at least one processor, the method comprising: receiving an incoming API message having a content organized according to a specific data structure pattern; applying a multi-step validation procedure on the incoming API message, wherein a first- step validation comprises determining that the specific data structure pattern is valid; and a second-step validation comprises, when it is determined that the specific data structure pattern is valid, parsing the incoming API message to determine at least one structure -defined portion of the content; calculating a hash value of the at least one structure-defined portion of the content; performing a comparison of the calculated hash value with one or more preset hash values of the respective at least one structure-defined portion of a valid content; and validating the incoming API message, based on the comparison of the calculated hash value.

2. The method of claim 1, wherein the incoming API message is an API request or API response.

3. The method according to any one of claims 1 and 2, wherein determining that the specific data structure pattern is valid comprises: inferring a machine-learning (ML)-based validation model on the incoming API message, wherein the ML-based validation model is respectively pretrained to detect a presence of anomalies in the specific data structure pattern of the incoming API message; and determining that the specific data structure pattern is valid when the presence of anomalies is not detected.

4. The method of claim 3, wherein the method further comprises: determining that the specific data structure pattern is invalid when the presence of anomalies is detected;when it is determined that the specific data structure pattern is invalid, applying a threat detection algorithm on the incoming API message, to detect malicious data in the incoming API message; and determining that the incoming API message is valid when the malicious data is not detected.

5. The method according to any one of claims 1-4, wherein determining that the specific data structure pattern is valid comprises applying a rule -based validation model on the incoming API message, wherein the rule -based validation model is configured (i) to perform a comparison of the specific data structure pattern with one or more preset data structure patterns; and (ii) to determine that the specific data structure pattern is valid when, based on the comparison of the specific data structure pattern, it is determined that the specific data structure pattern is similar to the one or more preset data structure patterns.

6. The method of claim 5, wherein the method further comprises: determining that the specific data structure pattern is invalid when, based on the comparison of the specific data structure pattern, it is determined that the specific data structure pattern is not similar to any of the one or more preset data structure patterns; when it is determined that the specific data structure pattern is invalid, applying a threat detection algorithm on the incoming API message, to detect malicious data in the incoming API message; and determining that the incoming API message is valid when the malicious data is not detected.

7. The method according to any one of claims 1-6, wherein validating the incoming API message, based on the comparison of the calculated hash value, comprises determining that the incoming API message is valid when, based on the comparison of the calculated hash value, it is determined that the calculated hash value matches the one or more preset hash values of the respective at least one structure-defined portion of the valid content.

8. The method of claim 7, wherein validating the incoming API message, based on the comparison of the calculated hash value, further comprises,when, based on the comparison of the calculated hash value, it is determined that the calculated hash value does not match any of the one or more preset hash values of the respective at least one structure-defined portion of the valid content, applying a threat detection algorithm on the incoming API message, to detect malicious data in the incoming API message; and determining that the incoming API message is valid when the malicious data is not detected.

9. The method according to any one of claims 7 and 8, wherein the one or more preset hash values are selected from a set of the preset hash values of the respective at least one structure-defined portion of the valid content; and the method further comprises, when the malicious data is not detected, supplementing the set of the preset hash values with the calculated hash value.

10. A system for establishing secure communication via application programming interface (API), the system comprising: a non-transitory memory device, wherein modules of instruction code are stored, and at least one processor associated with the memory device, and configured to execute the modules of instruction code, whereupon execution of said modules of instruction code, the at least one processor is configured to: receive an incoming API message having a content organized according to a specific data structure pattern; apply a multi-step validation procedure on the incoming API message, wherein a first- step validation comprises determining that the specific data structure pattern is valid; and a second-step validation comprises, when it is determined that the specific data structure pattern is valid, parsing the incoming API message to determine at least one structure -defined portion of the content; calculating a hash value of the at least one structure-defined portion of the content; performing a comparison of the calculated hash value with one or more preset hash values of the respective at least one structure-defined portion of a valid content; and validating the incoming API message, based on the comparison of the calculated hash value.

11. The system of claim 10, wherein the incoming API message is an API request or API response.

12. The system according to any one of claims 10 and 11, wherein the at least one processor is further configured to determine that the specific data structure pattern is valid by: inferring a machine-learning (ML)-based validation model on the incoming API message, wherein the ML-based validation model is respectively pretrained to detect a presence of anomalies in the specific data structure pattern of the incoming API message; and determining that the specific data structure pattern is valid when the presence of anomalies is not detected.

13. The system of claim 12, wherein the at least one processor is further configured to: determine that the specific data structure pattern is invalid when the presence of anomalies is detected; when it is determined that the specific data structure pattern is invalid, apply a threat detection algorithm on the incoming API message, to detect malicious data in the incoming API message; and determine that the incoming API message is valid when the malicious data is not detected.

14. The system according to any one of claims 10-13, wherein the at least one processor is further configured to determine that the specific data structure pattern is valid by applying a rule-based validation model on the incoming API message, wherein the rule-based validation model is configured (i) to perform a comparison of the specific data structure pattern with one or more preset data structure patterns; and (ii) to determine that the specific data structure pattern is valid when, based on the comparison of the specific data structure pattern, it is determined that the specific data structure pattern is similar to the one or more preset data structure patterns.

15. The system of claim 14, wherein the at least one processor is further configured to:determine that the specific data structure pattern is invalid when, based on the comparison of the specific data structure pattern, it is determined that the specific data structure pattern is not similar to any of the one or more preset data structure patterns; when it is determined that the specific data structure pattern is invalid, apply a threat detection algorithm on the incoming API message, to detect malicious data in the incoming API message; and determine that the incoming API message is valid when the malicious data is not detected.

16. The system according to any one of claims 10-15, wherein the at least one processor is further configured to validate the incoming API message by determining that the incoming API message is valid when, based on the comparison of the calculated hash value, it is determined that the calculated hash value matches the one or more preset hash values of the respective at least one structure-defined portion of the valid content.

17. The system according to any one of claims 10-16, wherein the at least one processor is further configured to: validate the incoming API message further by applying a threat detection algorithm on the incoming API message, to detect malicious data in the incoming API message, when, based on the comparison of the calculated hash value, it is determined that the calculated hash value does not match any of the one or more preset hash values of the respective at least one structure-defined portion of the valid content; and determine that the incoming API message is valid when the malicious data is not detected.

18. The system according to any one of claims 10-17, wherein the at least one processor is further configured to: select the one or more preset hash values from a set of the preset hash values of the respective at least one structure-defined portion of the valid content; and supplement the set of the preset hash values with the calculated hash value, when the malicious data is not detected.

Images