Cyber protection of web applications

Abstract

To provide a computer-implemented method for cyber protection of an application.SOLUTION: The method includes monitoring system calls made by a runtime process executing the application, providing the monitored system calls made by the runtime process to a supervising process executing outside of the runtime environment, the supervising process accessing a runtime context of the runtime process executing the application, the supervising process creating a context-aware baseline including the runtime context of the application partitioned into micro-components, and the supervising process preventing execution of system calls by the runtime environment executing the application that deviate from the context-aware baseline.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] Related Applications This application claims the benefit of priority to U.S. Patent Application No. 18 / 806,767, filed August 16, 2024, the contents of which are incorporated herein by reference in their entirety.

[0002] Technical Field The present invention, in some embodiments thereof, relates to cybersecurity and more particularly, but not exclusively, to cyber-protection of applications. [Background technology]

[0003] Application cyber protection involves implementing measures to protect applications from cyber threats such as data breaches, hacking, and malware. Summary of the Invention

[0004] According to a first aspect, a computer-implemented method for cyber-protection of an application includes monitoring system calls made by a runtime process executing the application, providing the monitored system calls made by the runtime process to a supervising process executing outside a runtime environment, the supervising process accessing a runtime context of the runtime process executing the application, the supervising process creating a context-aware baseline including the runtime context of the application divided into microcomponents, and the supervising process preventing the runtime environment executing the application from making system calls that deviate from the context-aware baseline.

[0005] According to a second aspect, a system for cyber-protection of an application includes at least one processor that executes code to monitor system calls made by a runtime process executing the application, provide the monitored system calls made by the runtime process to a supervising process executing outside a runtime environment, access by the supervising process a runtime context of the runtime process executing the application, create by the supervising process a context-aware baseline including the runtime context of the application divided into microcomponents, and prevent by the supervising process system calls made by the runtime environment executing the application that deviate from the context-aware baseline.

[0006] According to a third aspect, a non-transitory computer-readable storage medium storing program instructions for cyber-protection of an application, the program instructions, when executed by at least one processor, cause the at least one processor to monitor system calls made by a runtime process executing the application, provide the monitored system calls made by the runtime process to a supervising process executing outside a runtime environment, the supervising process accessing a runtime context of the runtime process executing the application, the supervising process creating a context-aware baseline including the runtime context of the application divided into microcomponents, and the supervising process preventing the runtime environment executing the application from making system calls that deviate from the context-aware baseline.

[0007] In a further implementation of the first, second, and third aspects, execution of the application by the runtime process is maintained while preventing execution of the system call.

[0008] In a further implementation of the first, second, and third aspects, the supervisor process resides within the runtime process and outside the runtime environment.

[0009] In further implementations of the first, second, and third aspects, during the learning phase, at least one of: each context-aware baseline is created by monitoring system call context and execution for each corresponding microcomponent of a plurality of microcomponents of the application; and a context-aware baseline is created by monitoring system call context and execution for a combination of two or more microcomponents of the application.

[0010] In further implementations of the first, second, and third aspects, at least one of the deviations in the execution of the system calls for each microcomponent are determined relative to the corresponding context-aware baseline defined for each microcomponent, the deviations in the execution of the system calls for a combination of two or more microcomponents are determined relative to the context-aware baseline defined for the combination of two or more microcomponents, and the deviations in the execution of the system calls are determined from a combination of two or more context-aware baselines defined for two or more microcomponents.

[0011] In further implementations of the first, second, and third aspects, the microcomponent includes a URL endpoint and / or a library.

[0012] In further implementations of the first, second, and third aspects, each runtime context may be accessed to reach each system call at the time the system call is made, and each system call is associated with a unique runtime context.

[0013] In a further implementation of the first, second, and third aspects, the application includes a web application that communicates with a remote client terminal over a network.

[0014] In a further implementation of the first, second, and third aspects, the features of the first, second, and third aspects are repeated in response to each triggering request message received from a client terminal to access the application, and the context-aware baseline of each repetition is specific to the context associated with the triggering request message.

[0015] In further implementations of the first, second, and third aspects, the current runtime context includes a runtime stack trace.

[0016] In a further implementation of the first, second, and third aspects, the current runtime context includes an HTTP request received from a client that triggered execution of the application.

[0017] In further implementations of the first, second, and third aspects, the current runtime context includes at least one of a library and a dependency.

[0018] In a further implementation of the first, second and third aspects, the system calls whose execution is prevented are selected to reduce the likelihood of exploitation of vulnerabilities in the application's code.

[0019] In a further implementation of the first, second, and third aspects, the monitoring of the system calls is triggered in response to a request message from the client over the network.

[0020] In a further implementation of the first, second, and third aspects, the request message is included in the context-aware baseline.

[0021] In further implementations of the first, second, and third aspects, the request message triggers loading of the web application into the runtime process and execution of the application by the runtime process, and the monitoring of the system calls is initiated in response to the loading and execution of the application.

[0022] In further implementations of the first, second, and third aspects, the runtime environment executes the microcomponent, the monitored system calls are made by the microcomponent, and the microcomponent is included in the runtime context.

[0023] In a further implementation of the first, second, and third aspects, the supervisory process is responsible for accessing the runtime context and creating the context-aware baseline for detection and / or profiling.

[0024] In a further implementation of the first, second, and third aspects, the application resides entirely within the runtime environment.

[0025] In further implementations of the first, second, and third aspects, the context-aware baseline includes arguments of the system calls for each microcomponent of the application.

[0026] In a further implementation of the first, second, and third aspects, the arguments to the system call include at least one of the process being run, the filename to write to, and the IP address to connect to.

[0027] In further implementations of the first, second, and third aspects, the supervision process further includes creating a filter, the filter created according to the context-aware baseline to prevent execution of the system calls outside the context-aware baseline and to allow execution of the system calls within the context-aware baseline.

[0028] In a further implementation of the first, second and third aspects, the filter is created using seccomp_unotify.

[0029] In further implementations of the first, second, and third aspects, monitoring the system call includes monitoring the input and / or output associated with the system call.

[0030] In a further implementation of the first, second, and third aspects, the application is implemented in a serverless computing environment.

[0031] In a further implementation of the first, second, and third aspects, the system calls are monitored from within the runtime process itself.

[0032] Unless otherwise defined, all technical and / or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although methods and materials similar or equivalent to those described herein can be used to practice or test embodiments of the present invention, exemplary methods and / or materials are described below. In case of conflict, the patent specification, including definitions, will control. Additionally, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting. [Brief explanation of the drawings]

[0033] Some embodiments of the present invention are herein described, by way of example only, with reference to the accompanying drawings. While specific reference will now be made in detail to the drawings, it is emphasized that the details shown are for the purpose of illustrating and discussing embodiments of the invention by way of example. In this regard, the description taken with the drawings will make apparent to those skilled in the art how embodiments of the invention may be practiced.

[0034] [Figure 1] FIG. 1 is a block diagram of components of a system for providing cyber protection for web applications based on a context-aware baseline, according to some embodiments of the present invention. [Figure 2] 1 is a schematic diagram illustrating the logical relationships between different executable code processes according to some embodiments of the present invention; [Figure 3] 1 is a flowchart of a method for providing cyber protection for web applications based on a context-aware baseline, according to some embodiments of the present invention. [Figure 4] 1 is a flowchart of another method for providing cyber protection for web applications based on a context-aware baseline, according to some embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0035] Web application cyber protection involves implementing measures to protect applications from cyber threats such as data breaches, hacking, and malware.

[0036] As used herein, the term application may refer to a web application.

[0037] As used herein, the terms syscall and syscalls may be used interchangeably. For example, monitoring and blocking a system call may refer to a single / individual system call and / or a set of system calls.

[0038] One aspect of some embodiments of the present invention relates to a system, method, computing device, and / or code instructions (e.g., stored in a data storage device and executable by one or more processors) for providing cyber protection for applications, optionally web applications. System calls made by a runtime process executing the application are monitored. The monitoring may be triggered, for example, in response to a request message, e.g., a Hypertext Transfer Protocol (HTTP) request, accessing the web application from a client terminal over a network. The system calls may be made by the runtime process executing one or more microcomponents of the application. The monitored system calls are provided to a supervising process executing outside the runtime environment. The supervising process executes within the runtime process. The supervising process has access to the runtime context of the runtime process executing the application. The runtime context may include the runtime stack trace and / or the triggering HTTP request. The supervising process creates a context-aware baseline including the context of the application divided into microcomponents. The context-aware baseline may be created for each microcomponent and / or for each combination of microcomponents. The context-aware baseline represents the "normal," i.e., non-malicious, activity of the system calls of the microcomponents within the context. A context-aware baseline may be created during the learning phase. Execution of system calls by the runtime environment within a context, optionally for each microcomponent and / or for each combination of microcomponents, is analyzed relative to the context-aware baseline to determine deviations, e.g., statistically significant deviations and / or deviations greater than a threshold. Deviations may indicate potential malicious activity, e.g., malware, hacking attempts, etc.In response to determining a deviation, a system call may be prevented from being executed by a runtime environment executing the application by a supervisory process.

[0039] Note that monitoring from the Operating System (OS) (kernel level) allows visibility into system calls. However, monitoring from the OS (kernel level) does not provide application context (e.g., runtime stack traces). At least some approaches described herein provide visibility into the entire flow, e.g., HTTP [request] → system call → stack trace (application code level), allowing for determining whether a system call deviates from a context-aware baseline indicating potential malicious activity and / or for blocking the system call from executing.

[0040] At least one embodiment described herein addresses the technical challenge of protecting applications from attacks, such as automated attacks (e.g., malware) and / or manual attacks (e.g., hacking). At least one embodiment described herein improves the technical field of cybersecurity by protecting applications from attacks. At least one embodiment described herein improves upon prior art approaches of protecting applications from attacks.

[0041] At least one embodiment described herein provides an Application Detection and Response (ADR) feature that operates in the runtime environment of web applications and provides in-context cyber protection and visibility. Application Detection and Response (ADR) is a set of cybersecurity strategies and techniques designed to detect and respond to threats and anomalies at the application layer. While traditional security measures often focus on network or endpoint security, ADR focuses specifically on applications, which are frequent vectors for cyber attacks due to their complexity and critical role in business operations.

[0042] At least one embodiment described herein provides cyber protection for web applications. A web application may refer to a software application that runs on a web server, on-premise, in the cloud, in a serverless environment, etc. A web application is accessed remotely by a client, for example, through a web browser over the internet or an intranet. Unlike traditional desktop applications that are installed on a local computer, web applications are hosted on a remote server and accessible from remote clients with a network connection. Due to their ability to be remotely accessible by different clients, protecting web applications presents a technical challenge. Web applications may be subject to attacks that exploit vulnerabilities in their code, such as: SQL Injection (SQLi): Attackers exploit vulnerabilities in web applications to execute malicious SQL queries. Cross-Site Scripting (XSS): An attacker injects malicious script into web pages viewed by other users. Cross-Site Request Forgery (CSRF): An attacker tricks a user into performing an action that the user did not intend.

[0043] At least one embodiment described herein detects cyber attacks against applications in a truly impact-driven manner, focusing on operational efficiency, seamless integration, and rapid threat mitigation.

[0044] At least one embodiment described herein addresses the above technical problem and / or improves upon the above technical field and / or improves upon the above existing approaches by monitoring and / or analyzing system calls made to an operating system by a runtime process executing code for a web application. The monitored system calls are provided to a supervising process executing outside the runtime environment and within the runtime process. The supervising process has access to the runtime context of the runtime environment executing the application, e.g., the runtime stack trace and / or the triggering HTTP request. The supervising process creates a context-aware baseline including the context of the application divided into microcomponents. The context-aware baseline may be created for each microcomponent and / or for each combination of microcomponents. The execution of system calls by the runtime environment within the context, optionally for each microcomponent and / or for each combination of microcomponents, is analyzed against the context-aware baseline to determine deviations, e.g., statistically significant deviations and / or deviations greater than a threshold. Deviations may indicate potential malicious activity, e.g., malware, hacking attempts, etc. In response to determining a deviation, the supervising process may prevent the execution of system calls by the runtime environment executing the application.

[0045] The runtime process may continue to execute the application while preventing system calls (that deviate from the context-aware baseline). A single request may be blocked. This contrasts with some existing approaches that "kill" the application's process, which can introduce reliability issues and / or cause other failures resulting from the application's abrupt termination.

[0046] The runtime process is a process that executes the code of a web application. Detection and / or prevention of exploitation of vulnerabilities in the code of the web application itself may be based on monitoring and / or analyzing the system calls made by the runtime process. Furthermore, because the entire web application resides within the runtime process, simply observing the system calls made by the runtime process may not provide sufficiently accurate data for detecting malicious activity. Simply observing the system calls made by the runtime process may be inaccurate, for example, because there are numerous microcomponents (e.g., URL endpoints and / or libraries) that provide different functionality. For example, different URL endpoints may be restricted to specific roles or internal functions.

[0047] Additionally, in at least one embodiment, runtime context (e.g., runtime stack traces and / or request messages, such as HTTP requests, that triggered the execution of a web application) is used to provide accurate detection and / or prevention of malicious activity.

[0048] Additionally, in at least one embodiment, system calls are monitored from within the runtime itself, allowing for monitoring of the runtime's system calls while having access to the runtime context.

[0049] Additionally, in at least one embodiment, considering system call arguments as part of the context-aware baseline improves the accuracy of preventing malicious activity. Indiscriminately preventing or allowing system calls without considering arguments may block the normal behavior of the application and may not provide a sufficiently accurate solution for web application security.

[0050] At least one embodiment described herein addresses the above technical challenges and / or improves upon the above technical field and / or improves upon the above existing approaches by generating a baseline for one or more microcomponents of a web application and monitoring deviations from the baseline to detect potential malicious activity, thereby protecting the application layer. A baseline may be generated for each microcomponent and / or for a combination of multiple microcomponents. Deviations may be for each baseline and / or for a combination of multiple baselines. The generation of baselines and their use to detect potential malicious activity used for application layer protection differs from, for example, endpoint detection and response (EDR) approaches for protecting personal computers and / or cloud detection and response (CDR) approaches for protecting cloud infrastructures. The activity of applications running in cloud environments is not visible at the microcomponent level to CDR approaches. In contrast, at least one embodiment described herein can monitor applications running in cloud environments and take action accordingly.

[0051] At least one embodiment described herein addresses the above technical challenges and / or improves upon the above technical fields and / or improves upon the above existing approaches by considering a runtime context for each event, e.g., considering a runtime stack trace and / or a triggering HTTP request. Considering a runtime context is an ADR approach that is distinct from other approaches.

[0052] At least one embodiment described herein addresses the above technical challenges and / or improves upon the above technical field and / or improves upon the above existing approaches with an architecture in which a supervising process exists within a runtime process but outside of a runtime environment. The runtime environment executes web applications. Having a supervising process that exists within the runtime process and outside of the runtime environment allows for normal execution of the runtime environment with and / or without altering code flow within the runtime environment. Additionally, monitoring within the runtime process by the supervising process allows for access to runtime context, which can be used to detect potential malicious activity, as described herein. This architecture differs from other approaches that monitor the runtime environment from within the runtime environment, which requires altering code flow, and / or monitoring from entirely outside the runtime process.

[0053] At least one embodiment described herein addresses the technical challenges of deploying cybersecurity processes in a serverless environment. Agents for detecting malicious activity based on standard approaches cannot be deployed in a serverless environment. Solutions that attempt to perform detection and provide response using standard approaches are often very limited in their capabilities and do not support serverless environments. At least one embodiment described herein addresses the above technical challenges and / or improves upon the above technical field and / or improves upon the above existing approaches with an architecture based on a supervising process equipped with monitored system calls, where the supervising process is located outside of the runtime environment and within the runtime process, and has access to the runtime context of the runtime environment to generate a context-aware baseline. Such an architecture can be deployed in a serverless environment.

[0054] Before describing at least one embodiment of the present invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and arrangement of components and / or methods set forth in the following description and / or illustrated in the drawings and / or examples. The invention is capable of other embodiments or of being practiced or carried out in various ways.

[0055] The present invention may be a system, a method, and / or a computer program product, which may include a computer-readable storage medium (or multiple computer-readable storage media) having computer-readable program instructions for causing a processor to implement aspects of the present invention.

[0056] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, and any suitable combination thereof. As used herein, computer-readable storage medium should not be construed as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses through a fiber optic cable) or electrical signals transmitted over wires.

[0057] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device, e.g., via the Internet, a local area network, a wide area network, and / or a wireless network. The network may comprise copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in each computing / processing device.

[0058] The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0059] Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0060] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium capable of directing a computer, programmable data processing apparatus, and / or other device to function in a particular way, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in the flowcharts and / or block diagrams.

[0061] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device, causing the computer, other programmable data processing apparatus, or other device to perform a series of operational steps to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable data processing apparatus, or other device, implement the functions / acts specified in the flowcharts and / or block diagrams.

[0062] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order depicted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a specific hardware-based system that performs the specified functions or operations or that implements a combination of specific hardware and computer instructions.

[0063] Reference is now made to FIG. 1, which is a block diagram of components of a system 100 for providing cyber-protection for web applications 122A based on a context-aware baseline, in accordance with some embodiments of the present invention. Reference is also made to FIG. 2, which is a schematic diagram 200 illustrating logical relationships between different executing code processes, in accordance with some embodiments of the present invention. Reference is also made to FIG. 3, which is a flowchart of a method for providing cyber-protection for web applications based on a context-aware baseline, in accordance with some embodiments of the present invention. Reference is also made to FIG. 4, which is a flowchart of another method for providing cyber-protection for web applications based on a context-aware baseline, in accordance with some embodiments of the present invention.

[0064] The system 100 may implement the operations of the methods described with reference to Figures 3 and 4 by a processor 102 of a computing environment 104 executing code instructions stored in a memory 106 (also called a program store).

[0065] The computing environment 104 may be implemented as, for example, one or more and / or combinations of a group of connected devices, a client terminal, a server, a virtual server, a computing cloud, a virtual machine, a desktop computer, a thin client, a network node, and / or a mobile device (e.g., a smartphone, a tablet computer, a laptop computer, a wearable computer, a glasses computer, and a watch computer).

[0066] Computing environment 104 may represent one or more of the following environments for running web application 122A, for example, on-premise, in a computing cloud, and in a serverless environment.

[0067] The computing environment 104 executing the stored code instructions 106A may be implemented to host the web application 122A for access and / or to provide services (e.g., one or more of the operations described with reference to FIG. 3 and / or FIG. 4) to the client terminals 108, for example, on-premise, in a computing cloud, and in a serverless environment. As described herein, the web application 122A is protected using a supervisory process 122C that analyzes system calls made by the web application 122A executed by the runtime environment 122B to detect suspicious activity (e.g., indicative of an attack by malware and / or hacking) in order to prevent certain system calls for protection of the code of the web application 122A.

[0068] Multiple architectures of the system 100 based on the computing environment 104 may be implemented. In one example, the supervising process 122C and the web application 122A may be executed by the same computing environment 104, e.g., the same processor 102, the same underlying hardware, etc. Note that the supervising process 122C may be virtually isolated from the web application 122A to provide a virtual barrier to protect the supervising process 122C. In another example, web application 122A and runtime environment 122B may be executed by one or more other servers 118 that provide access and / or services to client terminals 108. Computing environment 104 provides security for web application 122A executing on server 118, for example, by receiving system calls sent from server 118 and / or by accessing the runtime context.

[0069] The processor 102 of the computing environment 104 may be a hardware processor and may be implemented, for example, as central processing unit(s) (CPU), graphics processing unit(s) (GPU), field programmable gate array(s) (FPGA), digital signal processor(s) (DSP), and application specific integrated circuit(s) (ASIC). The processor 102 may include a single processor or multiple processors (homogeneous or heterogeneous) arranged for parallel processing as a cluster and / or as one or more multi-core processing devices.

[0070] Memory 106 stores code instructions executable by hardware processor 102, e.g., random access memory (RAM), read-only memory (ROM), and / or storage devices, such as non-volatile memory, magnetic media, semiconductor memory devices, hard drives, removable storage, and optical media (e.g., DVD, CD-ROM). Memory 106 stores code 106A that, when executed by hardware processor 102, implements one or more features and / or operations of the methods described with reference to Figures 3 and / or 4.

[0071] The computing environment 104 may include a data storage device 122 for storing data, such as one or more of a web application 122A that can be accessed by a client terminal 108, a runtime environment 122B that executes the web application 122A, a supervisory process 122C, a runtime context repository 122D configured to store data used to determine a runtime context and / or create a context-aware baseline, a context-aware baseline repository 122E configured to store context-aware baselines created for different cases, and a runtime process 122F that embeds the runtime environment. The data storage device 122 may be implemented, for example, as memory, a local hard drive, virtual storage, a removable storage unit, an optical disk, a storage device, and / or a remote server and / or computing cloud (e.g., accessed using a network connection).

[0072] The network 110 may be implemented as, for example, the Internet, a local area network, a virtual network, a wireless network, a cellular network, a local bus, a point-to-point link (e.g., wired), and / or combinations thereof.

[0073] The computing environment 104 may include a network interface 124 for connecting to the network 110, such as one or more of a network interface card, a wireless interface for connecting to a wireless network, a physical interface for connecting to a cable for network connectivity, a virtual interface implemented in software, network communications software providing an upper layer of network connectivity, and / or other implementations.

[0074] The computing environment 104 may communicate with one or more user interfaces 126 designed for inputting and / or presenting data. Exemplary user interfaces 126 include, for example, one or more of a touch panel, a display, a gesture-activated device, a keyboard, a mouse, and voice-activated software using a speaker and microphone.

[0075] Referring again to FIG. 2, a schematic diagram 200 in FIG. 2 illustrates the logical relationships between different executable code processes. Runtime process 122F embeds runtime environment 122B (not to be confused with an OS environment). Runtime environment 122B executes application 122A, optionally a web application. Application 122A may reside entirely within runtime environment 122B. Supervisor process 122C resides within runtime process 122F but external to runtime environment 122B. The architecture illustrated in FIG. 2 allows for normal execution of runtime environment 122B without altering and / or modifying the code flow within runtime environment 122B. Additionally, monitoring within runtime process 122F by supervisor process 122C provides access to runtime context that can be used to detect potential malicious activity, as described herein. The architecture illustrated in FIG. 2 differs from other approaches that require modifying code flow by monitoring the runtime environment from within the runtime environment and / or monitoring entirely external to the runtime process.

[0076] Referring again to Figure 3, a process for providing cybersecurity to an application may be installed at 302. The process for providing cybersecurity may implement one or more of the features 304-316 of Figure 3.

[0077] The application may be implemented as a web application that communicates with one or more remote client terminals over a network.

[0078] An application (e.g., a web application) may be implemented within a serverless computing environment, and a process for providing cybersecurity for the application may be implemented within the serverless computing environment. For example, as described herein, the design of the process for providing cybersecurity may allow for deployment within a serverless computing environment, as opposed to standard cybersecurity approaches that are not suitable for deployment within a serverless computing environment.

[0079] Applications may also be deployed in other architectures, for example, on-premise, in the cloud, in a server, etc.

[0080] The application may be deployed, for example, as described with reference to FIG. 1 and / or FIG.

[0081] At 304, system calls (system calls) made by the runtime process executing the application are monitored.

[0082] System calls may be monitored by a supervisory process, which may exist within the runtime process and external to the runtime environment, as described herein.

[0083] System calls may be monitored from within the runtime process itself.

[0084] The runtime process containing the application may have multiple URL endpoints that may serve as entry points for the code flow that defines the web application itself.

[0085] A runtime process executes the operating system's sub-mechanisms, i.e., the application's code, which may invoke system calls to handle processes, interact with the file system, open network connections, etc.

[0086] Monitoring system calls may be triggered in response to a request message, e.g., an HTTP request, from a client over a network to access an application. The request message may trigger loading of the application into a runtime process and execution of the application by the runtime process. Monitoring system calls may be initiated in response to loading of the application and execution of the application.

[0087] A system call (syscall or system call) is a mechanism by which a process requests services from the operating system kernel. These services may include, for example, hardware-related tasks such as reading and writing files, managing memory, and creating and terminating processes. System calls may provide a controlled interface for processes to interact with the operating system and may help ensure that these interactions are performed safely and efficiently. When a process needs to perform an operation that requires kernel-level resources, the process issues a system call, which the kernel then handles and executes. System calls may be initiated using a software interrupt or a specific instruction to switch the processor into kernel mode, thereby allowing the operating system to perform the requested task on behalf of the application.

[0088] Examples of common system calls include: * File management: open, read, write, close * Process management: fork, exec, wait, exit * Memory management: mmap, munmap, brk * Network management: socket, bind, connect, send, recv

[0089] Monitoring a system call may include monitoring inputs and / or outputs associated with the system call. Inputs may be arguments passed to a function called as part of the system call. Outputs may be data produced by processing the system call and / or output generated by the system call.

[0090] At 306, the monitored system calls made by the runtime process are provided to a supervisor process.

[0091] The supervising process may execute outside of the runtime environment and / or reside within the runtime process. The location of the supervising process may allow normal execution of the runtime environment and its code flow without modification and / or alteration and / or obtain the runtime context. This is in contrast to other approaches that require modifying and / or altering the code flow of the runtime environment and / or do not provide access to the runtime context.

[0092] At 308, the supervisor process accesses the runtime context of the runtime process executing the application.

[0093] The runtime context may include the state and / or environment in which an application executes. The runtime context may include the data and / or resources that the application uses to execute, such as memory allocations, variable values, execution stacks, CPU registers, and the state of the operating system. The runtime context may be established when an application launches and may be dynamically updated as the application executes.

[0094] Within the runtime context, one or more of the following data elements may be accessed and included: Runtime stack trace The hypertext transfer protocol (HTTP) request received from the client that triggered the execution of the application. Library Dependencies System call arguments, optionally for each microcomponent of the application. The system call arguments may include one or more of the process being run, the filename to write to, and the IP address to connect to. Microcomponents, such as URL endpoints and / or libraries. The microcomponents may be executed by a runtime environment. The monitored system calls may be made by the microcomponents. In embodiments where monitoring system calls is triggered in response to a request message from a client over a network, the request message may be included as part of the runtime context.

[0095] Optionally, each runtime context may be accessed to reach each system call at the time that it is made. Each system call may be associated with a unique runtime context at each time that it is invoked.

[0096] At 310, one or more context-aware baselines are created. The context-aware baselines may be created by an oversight process. The context-aware baselines may be used for detectable and / or profileable security threats, as described herein.

[0097] A context-aware baseline includes one or more data elements accessed from the runtime context of an application. The data elements of the runtime context may be divided into micro-components for inclusion in one or more context-aware baselines.

[0098] Optionally, each context-aware baseline is created for a corresponding microcomponent, for example, for each URL endpoint and / or for each library. Alternatively or additionally, multiple context-aware baselines may be created, one for each microcomponent. For example, multiple context-aware baseline combinations may be defined that represent combinations of microcomponents. Alternatively or additionally, a particular context-aware baseline may be created from a combination of two or more microcomponents.

[0099] The context-aware baseline may include a set of system calls and system call arguments made by each microcomponent. The context-aware baseline may be partitioned independently among microcomponents.

[0100] Each microcomponent may be associated with a unique set of distinctive data elements associated with a runtime context that, for example, indicates a particular set of behaviors. Context-aware baselines corresponding to individual microcomponents and / or combinations of microcomponents allow each microcomponent and / or combination of microcomponents to be profiled independently.

[0101] At 312, one or more of the features 304-310 may be repeated over time, for example, in response to different system calls.

[0102] Optionally, the iterations may be repeated during a learning phase to create a context-aware baseline. The learning phase may be repeated during "normal" operation of the application.

[0103] During the learning phase, context-aware baselines may be dynamically created and / or updated. Each context-aware baseline may be created and / or updated for each microcomponent of the application by monitoring the system call context and / or execution for each corresponding microcomponent of the application. Alternatively or additionally, a context-aware baseline may be created and / or updated by monitoring the system call context and execution for a combination of two or more microcomponents of the application. Each context-aware baseline may mirror the behavior of the corresponding microcomponent of the application during the learning phase.

[0104] A context-aware baseline may be defined over time, e.g., as a sequence that indicates "normal," non-malicious behavior over time. Alternatively or additionally, a context-aware baseline may be created on an iteration basis, e.g., as a snapshot in time.

[0105] The iterations may be in response to receipt of each triggering request message received from a client terminal to access the application, and the context-aware baseline for each iteration may be specific to a runtime context associated with the triggering request message.

[0106] At 314, a deviation in the execution of one or more of the monitored system calls of one or more micro components from a corresponding context-aware baseline may be detected.

[0107] Deviant system calls may refer to system calls that are outside the context-aware baseline. Non-deviant system calls may refer to system calls that are within the context-aware baseline.

[0108] A deviation may indicate anomalous behavior, which may indicate malicious activity. The absence of a deviation may indicate normal behavior. The amount of deviation from the context-aware baseline may be correlated with the probability of malicious activity. Optionally, any deviation from the context-aware baseline may be automatically designated as anomalous. If the deviation occurs by a certain amount, for example, above a system call threshold (e.g., 10%, 20%, or other value), the deviation may be designated as new legitimate application behavior, and the context-aware baseline is dynamically adapted to include the new legitimate application behavior. With regard to actual behavior, the type of deviation is not particularly important because security-sensitive operations are being monitored, all of which are treated as suspicious. Alternatively, the amount of deviation does not correlate with the probability of malicious activity. For example, the outcome of a deviation determination may be a binary between a deviation indicating possible malicious activity and a non-deviation indicating normal behavior.

[0109] Deviations in system call execution for each microcomponent are determined relative to a corresponding context-aware baseline defined for each microcomponent. Deviations in system call execution may be for a combination of two or more microcomponents relative to a context-aware baseline defined for a combination of two or more microcomponents and / or relative to a combination of two or more context-aware baselines defined for two or more microcomponents.

[0110] Different context-aware baselines for different microcomponents can help identify cases where malicious attacks against many applications are not specific to the runtime process as a whole, but instead perform behavior that is distinct from the baseline of one of the application's microcomponents (mostly a URL endpoint). For example, one of the administrator-only URL endpoints allows uploading a file to the server hosting the web application. This feature is allowed because only trusted administrators have access to this URL endpoint. For example, if another URL endpoint has a vulnerability that, when successfully exploited, allows the same feature to upload a file to the server (a very common scenario), then nothing suspicious is at work at the macro level of the web application (since uploading a file is already a feature). However, at the micro level, deviations from the context-aware baseline of this URL endpoint can allow detection of malicious activity.

[0111] In response to detecting the deviation, the system call may be prevented from executing at 316. For example, the system call may be prevented from executing by blocking further implementations of the system call and / or by issuing an error for an attempted implementation of the system call. The prevention of the system call from executing may be performed by a supervisor.

[0112] The runtime process may maintain execution of the application while preventing system calls (that deviate from the context-aware baseline). A single request may be blocked while the application may continue to run.

[0113] System calls that deviate from the context-aware baseline may be prevented from executing. Other system calls, such as system calls that are expected to be related to the deviating system call (e.g., in an expected sequence of system calls), may also be prevented from executing. Preventing other system calls from executing helps prevent damage from and / or contain malicious activity.

[0114] Deviations may be analyzed to determine whether malicious activity is occurring. For example, a combination of deviations from multiple context-aware baselines and / or a combination of multiple context-aware baselines and / or deviations from different context-aware baselines (for different microcomponents) may be analyzed. Such deviations may be referred to as macro-level deviations. For example, if a certain percentage of HTTP requests trigger a new feature (e.g., a new behavior), these HTTP requests are typically very low volume requests and therefore unlikely to be an attack.

[0115] A filter may be created, optionally created by an oversight process. The filter may be created according to the context-aware baseline to prevent execution of system calls that deviate from the context-aware baseline. The filter may be created to allow execution of system calls that do not deviate from the context-aware baseline (e.g., are within the context-aware baseline).

[0116] The filter may be a dedicated Berkeley Packet Filter (BPF) filter.

[0117] A filter may be created using seccomp, which may integrate with a "user_notify" system such as seccomp_unotify. Creating a filter using seccomp_unotify allows an external observer to know the system calls made by the runtime process. Creating a filter using seccomp_unotify may further allow an observer to identify the runtime context of an application to create a context-aware baseline. Creating a filter using seccomp_unotify may further allow an observer to prevent the execution of system calls that deviate from the context-aware baseline. Another potential benefit of using a filter created using seccomp_unotify (e.g., the seccomp BPD filter "user_notify") is the ability to consider system call arguments when building and applying a context-aware baseline. This may provide more precise prevention by considering the arguments as part of the context-aware baseline. On the other hand, indiscriminately preventing or allowing system calls without considering the arguments (e.g., the process being run, the filename to which it is written, or the IP address to which it is connected) may block the normal behavior of the application and may not provide a sufficient solution for application security.

[0118] The system calls that are prevented from execution may be selected to reduce the likelihood of exploitation of vulnerabilities in the application's code.

[0119] Optionally, one or more other actions may be implemented automatically, for example: Present an alert on the operator's computer display indicating that malicious activity was detected and / or which system calls were prevented from executing. Triggering an automated process to isolate the micro-component that made the system call that was prevented from executing. Disconnecting and / or blocking network connections with client terminals that lead to system calls whose execution has been prevented, for example to prevent hackers from gaining access to the server.

[0120] Referring again to FIG. 4, at 402, the client sends an HTTP request to the web application.

[0121] At 404, the HTTP request is received by the runtime process.

[0122] At 406, the received HTTP request triggers the loading of the web application into the runtime process and the execution of the web application by the runtime process.

[0123] At 408, a microcomponent of the web application makes a system call. For example, a URL endpoint code flow makes a system call.

[0124] At 410, a system call is provided to a supervisor process (i.e., a solution supervisor), which resides outside the runtime environment and within the runtime process as described herein. The supervisor process creates a context-aware baseline that includes the runtime context of the application broken down into microcomponents.

[0125] Alternatively or additionally to 410, a system call is executed at 412.

[0126] At 414, information about the executing system calls is provided to a supervisory process.

[0127] At 416, the supervisory process evaluates whether the information about the executing system calls deviates from the context-aware baseline.

[0128] At 418, if no deviation from the context-aware baseline is detected, the system call and / or arguments to the system call are determined to be part of the normal behavior of the microcomponent, for example, a normal URL endpoint code flow.

[0129] Alternatively, at 420, if a deviation from the context-aware baseline is detected, the system call and / or arguments of the system call are determined to be invalid, possibly associated with malicious activity, and execution of the system call may be blocked to block the malicious activity.

[0130] The description of various embodiments of the present invention has been presented for illustrative purposes, but is not intended to be exhaustive or to limit the description of various embodiments of the present invention to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications, or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0131] It is anticipated that many related runtime contexts will be developed during the life of the patent resulting from this application, and the scope of the term runtime context is intended to include, a priori, all such new technologies.

[0132] As used herein, the term "about" refers to ±10%.

[0133] The terms "comprises," "comprising," "includes," "including," "having," and their cognates mean "including but not limited to." This term encompasses the terms "consisting of" and "consisting essentially of."

[0134] The phrase "consisting essentially of" means that the composition or method may include additional ingredients and / or steps, but only if the additional ingredients and / or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

[0135] As used herein, the singular forms "a," "an," and "the" include plural referents unless the context clearly indicates otherwise. For example, the terms "a compound" or "at least one compound" may include multiple compounds, including mixtures thereof.

[0136] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment described as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments and / or to exclude the incorporation of features from other embodiments.

[0137] The term "optionally" is used herein to mean "is provided in some embodiments and not provided in other embodiments." Any particular embodiment of the present invention may include multiple "optional" features, provided that these features do not contradict one another.

[0138] Throughout this application, various embodiments of the present invention may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the present invention. Accordingly, the description of a range should be considered to have specifically disclosed all possible subranges and individual numerical values ​​within that range. For example, the description of a range such as 1 to 6 should be considered to have specifically disclosed subranges such as 1 to 3, 1 to 4, 1 to 5, 2 to 4, 2 to 6, 3 to 6, etc., as well as individual numerical values ​​within that range, such as 1, 2, 3, 4, 5, and 6. This is true regardless of the width of the range.

[0139] When a range of values ​​is given herein, it is meant to include any recited number (fractional or integer) within the range given. As used herein, the phrase "ranging / ranges between" a first recited number and a second recited number and the phrase "ranges from" a first recited number and a second recited number are used interchangeably and are meant to include the first recited number, the second recited number, and all fractional and integer numbers therebetween.

[0140] It is understood that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination, or as appropriate, in any other described embodiment of the invention. Particular features described in the context of various embodiments should not be considered essential features of those embodiments, except to the extent that the embodiment cannot function without those elements.

[0141] While the present invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications, and variations that fall within the spirit and broad scope of the appended claims.

[0142] It is the intention of the applicant(s) that all publications, patents, and patent applications mentioned herein be incorporated by reference in their entirety, as if each individual publication, patent, and patent application was specifically and individually indicated to be incorporated by reference herein. In addition, citation or identification of any reference in this application should not be construed as an admission that such reference is available as prior art to the present invention. Section headings, if used, should not be construed as necessarily limiting. In addition, any priority document(s) of this application are incorporated by reference herein in their entirety.

Claims

1. a runtime process that embeds a runtime environment that executes one or more microcomponents of an application, executing a supervising process outside of said runtime environment; monitoring by said runtime process of system calls made by said runtime process; the runtime process providing the monitored system calls to the supervisor process; accessing the runtime context of the runtime process by the supervisor process; the supervisory process creating a context-aware baseline that includes the runtime context broken down into microcomponents of the application; and the oversight process preventing the runtime environment from executing system calls that deviate from the context-aware baseline; A computer-implemented method for cyber-protection of an application, comprising:

2. Execution of the application by the runtime process is maintained while preventing execution of the system call. The computer-implemented method of claim 1 .

3. the supervisory process exists within the runtime process and outside the runtime environment; The computer-implemented method of claim 1 .

4. During the learning phase, Each context-aware baseline is created by monitoring system call context and execution for each corresponding microcomponent of the plurality of microcomponents of the application; and creating a context-aware baseline by monitoring the system call context and execution of a combination of two or more microcomponents of the application; At least one of the following is performed: The computer-implemented method of claim 1 .

5. the deviations in the execution of the system calls of each microcomponent are determined relative to the corresponding context-aware baseline defined for each microcomponent; The deviation of the execution of the system call for a combination of two or more microcomponents is determined relative to the context-aware baseline defined for the combination of two or more microcomponents; and the deviation of the system call execution is from a combination of two or more context-aware baselines defined for two or more microcomponents; At least one of the following is performed: The computer-implemented method of claim 1 .

6. The microcomponents include URL endpoints and / or libraries. The computer-implemented method of claim 1 .

7. Each runtime context may be accessed to reach each system call at the time the system call is made, and each system call is associated with a unique runtime context. The computer-implemented method of claim 1 .

8. The application includes a web application that communicates with a remote client terminal over a network. The computer-implemented method of claim 1 .

9. the monitoring, providing, accessing, creating, and preventing are repeated in response to each trigger request message received from a client terminal for accessing the application, and the context-aware baseline for each iteration is specific to the context associated with the trigger request message. The computer-implemented method of claim 1 .

10. The runtime context includes a runtime stack trace. The computer-implemented method of claim 1 .

11. the runtime context includes an HTTP request received from a client that triggered execution of the application; The computer-implemented method of claim 1 .

12. the runtime context includes at least one of a library and a dependency; The computer-implemented method of claim 1 .

13. the system calls whose execution is prevented are selected to reduce the likelihood of exploitation of vulnerabilities in the application's code; The computer-implemented method of claim 1 .

14. said monitoring said system calls being triggered in response to a request message from said client via said network; The computer-implemented method of claim 1 .

15. the request message is included in the context-aware baseline; 15. The computer-implemented method of claim 14.

16. the request message triggers loading of the web application into the runtime process and execution of the application by the runtime process, and the monitoring of the system calls is initiated in response to the loading and execution of the application.

15. The computer-implemented method of claim 14.

17. the runtime environment executes the microcomponent, the monitored system call is made by the microcomponent, and the microcomponent is included in the runtime context; The computer-implemented method of claim 1 .

18. the supervisory process accessing the runtime context and creating the context-aware baseline for detection and / or profiling; The computer-implemented method of claim 1 .

19. The application resides entirely within the runtime environment. The computer-implemented method of claim 1 .

20. the context-aware baseline includes arguments of the system calls for each microcomponent of the application; The computer-implemented method of claim 1 .

21. The arguments of the system call include one or more of the process being executed, the file name to write to, and the IP address to connect to.

21. The computer-implemented method of claim 20.

22. the supervision process further includes creating a filter, the filter being created according to the context-aware baseline to prevent execution of the system call outside the context-aware baseline and to allow execution of the system call within the context-aware baseline; The computer-implemented method of claim 1 .

23. The filter is created using seccomp_unnotify, 23. The computer-implemented method of claim 22.

24. monitoring the system call includes monitoring the input and / or output associated with the system call; The computer-implemented method of claim 1 .

25. The application is implemented in a serverless computing environment. The computer-implemented method of claim 1 .

26. The system calls are monitored from within the runtime process itself. The computer-implemented method of claim 1 .

27. a runtime process that embeds a runtime environment that executes one or more microcomponents of an application, executing a supervising process outside of said runtime environment; monitoring by said runtime process of system calls made by said runtime process; the runtime process providing the monitored system calls to the supervisor process; accessing the runtime context of the runtime process by the supervisor process; the supervisory process creating a context-aware baseline that includes the runtime context broken down into microcomponents of the application; and the oversight process preventing the runtime environment from executing the system call that deviates from the context-aware baseline; at least one processor executing code for performing A system for cyber protection of applications.

28. 1. A non-transitory computer-readable storage medium storing program instructions for cyber protection of an application, the program instructions, when executed by at least one processor, causing the at least one processor to: a runtime process that embeds a runtime environment that executes one or more microcomponents of an application, executing a supervising process outside of said runtime environment; monitoring by said runtime process of system calls made by said runtime process; the runtime process providing the monitored system calls to the supervisor process; accessing the runtime context of the runtime process by the supervisor process; the supervisory process creating a context-aware baseline that includes the runtime context broken down into microcomponents of the application; and the oversight process preventing the runtime environment from executing system calls that deviate from the context-aware baseline; A non-transitory computer-readable storage medium storing program instructions for cyber protection of an application, the program instructions causing the computer to execute the above steps.

Images