Security policy for software call stack

Abstract

The present disclosure provides systems, methods, and computer readable media for implementing security policies at the level of a software call stack. In one example, a method includes generating a call stack classification scheme; detecting a call stack during deployment of an application; classifying, using the call stack classification scheme, the detected call stack as one of an authorized call stack or an unauthorized call stack during a runtime of the application to produce a classification; and applying a security policy based on the classification.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit and priority of U.S. nonprovisional patent application No. 17 / 023,035, filed on September 16, 2020, the entire disclosure of which is expressly incorporated herein by reference in its entirety. Technical Field

[0003] The subject matter of this disclosure generally relates to the field of application security, and more specifically, to applying security measures to the internal software call stack of an application during its runtime to enhance its security. Background Technology

[0004] Zero-trust security policies for applications require strict authentication of individuals and devices attempting to access the application. Currently, zero-trust security policies for applications apply the concept of whitelisting at the application level. This type of zero-trust security policy protects the application by allowing access to pre-defined network paths included in the whitelist. Zero-trust policies can significantly reduce the number of potential attack sources or security threats by preventing potentially malicious sources from accessing the application. Attached Figure Description

[0005] In order to describe how the above and other advantages and features of this disclosure can be obtained, a more specific description of the principles briefly described above will be presented by reference to specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only embodiments of this disclosure and are therefore not to be considered as limiting its scope. The principles herein are described and explained more specifically and in detail using the accompanying drawings, in which:

[0006] Figures 1A to 1B An aspect of the network environment according to one aspect of this disclosure is shown;

[0007] Figure 2 An example of a software call stack security system according to one aspect of this disclosure is shown;

[0008] Figure 3 An example method for applying a zero-trust security policy at the software call stack level is shown according to one aspect of this disclosure;

[0009] Figure 4 An example neural architecture according to one aspect of this disclosure is shown;

[0010] Figures 5A to 5C An example diagram of a software call stack according to one aspect of this disclosure is shown; and

[0011] Figures 6A to 6B An example of a system according to one aspect of this disclosure is shown. Detailed Implementation

[0012] Various embodiments of this disclosure are discussed in detail below. Although specific implementations are discussed, it should be understood that this is done for illustrative purposes only. Those skilled in the art will recognize that other components and configurations can be used without departing from the spirit and scope of this disclosure. Therefore, the following description and drawings are illustrative and should not be construed as limiting. Numerous specific details have been described to provide a thorough understanding of this disclosure. However, in some cases, well-known or conventional details have not been described to avoid obscuring the description. References to one embodiment or an embodiment in this disclosure may refer to the same embodiment or any of the embodiments; and such references refer to at least one embodiment.

[0013] The reference to "an embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of this disclosure. The phrase "in one embodiment" appearing throughout the specification does not necessarily refer to the same embodiment, and individual or alternative embodiments are not mutually exclusive with other embodiments. Furthermore, the various features described may be exhibited by some embodiments but not by others.

[0014] The terms used in this specification generally have their ordinary meaning in the art, in the context of this disclosure, and in the specific context in which each term is used. Alternative languages ​​and synonyms may be used for any one or more terms discussed herein and should not be given special meaning regardless of whether the terms are elaborated or discussed herein. In some cases, synonyms for certain terms are provided. The description of one or more synonyms does not preclude the use of other synonyms. The use of examples anywhere in this specification, including examples of any terms discussed herein, is illustrative only and is not intended to further limit the scope and meaning of this disclosure or any of the example terms. Likewise, this disclosure is not limited to the various embodiments given in this specification.

[0015] Without intending to limit the scope of this disclosure, examples of means, apparatus, methods, and related results according to embodiments of this disclosure are given below. Note that headings or subheadings may be used in the examples for the reader's convenience, but this should in no way limit the scope of this disclosure. Unless otherwise defined, the technical and scientific terms used herein have the meanings commonly understood by one of ordinary skill in the art to which this disclosure pertains. In the event of any conflict, this document (including the definitions) shall prevail.

[0016] Additional features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description, or may be learned by practicing the principles disclosed herein. The features and advantages of this disclosure may be realized and obtained by the means and combinations particularly pointed out in the appended claims. These and other features of this disclosure will become more apparent from the following description and the appended claims, or may be learned by practicing the principles set forth herein.

[0017] Overview

[0018] The invention is set forth in the independent claims, and preferred features are set forth in the dependent claims. A feature of one aspect may be applied to each aspect alone or in combination with other aspects.

[0019] This subject matter relates to applying security policies at the software call stack level, based on software call stack classification, within applications. Manual and / or automated processes (e.g., using machine learning (ML) techniques) are used to determine an authorized list of call stacks associated with the application. These lists are used at various stages of application deployment to determine whether the call stack can be accessed by the application.

[0020] In one aspect, one approach includes: generating a call stack classification scheme for an application; detecting call stacks during application deployment; using the call stack classification scheme during application runtime to classify the detected call stacks as either authorized or unauthorized call stacks to generate a classification; and applying a security policy based on the classification.

[0021] On the other hand, call stack classification schemes include: a whitelist of authorized call stacks that can be accessed by the application.

[0022] On the other hand, call stack classification schemes include: a classifier trained using machine learning techniques to identify detected call stacks as either authorized or unauthorized call stacks.

[0023] On the other hand, training the classifier includes training the classifier using a previously known list of authorized call stacks and a previously known list of unauthorized call stacks.

[0024] On the other hand, the classifier is trained to output scores for detected call stacks during the application's runtime.

[0025] On the other hand, classifying the detected call stacks also includes: comparing a score to a threshold; and if the score is greater than the threshold, classifying the call stack as an authorized call stack.

[0026] On the other hand, the classifier is trained to classify the call stack detected during runtime as either an authorized call stack or an unauthorized call stack.

[0027] In one aspect, a system includes: one or more memories having computer-readable instructions stored therein; and one or more processors configured to execute the computer-readable instructions to perform the following operations: generating a call stack classification scheme; detecting a call stack during application deployment; using the call stack classification scheme during application runtime to classify the detected call stack as either an authorized call stack or an unauthorized call stack to generate a classification; and applying a security policy based on the classification.

[0028] In one aspect, one or more non-transitory computer-readable storage media include computer-readable instructions that, when executed by one or more processors of a security system, cause the security system to perform the following operations: generate a call stack classification scheme; detect call stacks during application deployment; use the call stack classification scheme during application runtime to classify the detected call stacks as either authorized or unauthorized call stacks to generate a classification; and apply a security policy based on the classification.

[0029] describe

[0030] Various embodiments of this disclosure are discussed in detail below. Although specific implementations are discussed, it should be understood that this is done for exemplary purposes only. Those skilled in the art will recognize that other components and configurations can be used without departing from the spirit and scope of this disclosure.

[0031] As mentioned above, current zero-trust application security strategies can be implemented at the application level based on the concept of whitelisting. Such strategies can reduce the number of potential attack sources or security threats by preventing attempts by potentially malicious sources to access the application. Furthermore, such applications can include many (e.g., hundreds, thousands, etc.) software call stacks that can access the application during runtime at various stages of testing, pre-production, and production. These software call stacks are exploited in the operation of any application. For example, the software call stack can store information about the application's active subroutines and track the point at which each active subroutine returns control upon completion of its execution. Therefore, the call stack introduces another possibility of unauthorized access to the application, compromising the security of the entire application. Currently, there is a lack of zero-trust security strategy schemes implemented at the software call stack level.

[0032] The techniques disclosed herein improve application security at the software call stack level. The improvements provided herein are examples of implementing security policies at the software call stack level by identifying a list (whitelist) of authorized call stacks. Implementing security policies based on whitelists at a single software call stack can significantly reduce the number of potential attack sources or security threats to applications (e.g., enterprise applications) at the software call stack level, thereby improving overall network security.

[0033] An application's software call stack whitelist can be determined manually and / or using a machine learning model. As described below, in one example, machine learning techniques can be used to train a call stack classification service to implement a scoring system that determines whether software call stacks detected during application execution / deployment should be classified as authorized call stacks for use in application security policies. Feedback can be provided to the classifier during training to improve the classification process. For example, the list of boundary software call stacks can be manually reviewed and marked as authorized or unauthorized to further train the machine learning model. The process of training and utilizing the classifier to implement security policies at the software call stack level will be described more fully below.

[0034] This disclosure begins with a description of example systems in which this disclosure can be deployed in relation to zero-trust application security at the software call stack level.

[0035] Figure 1A A diagram illustrating an example network environment 100 according to one aspect of this disclosure is shown. Network environment 100 (system 100) may include network 106, which may represent any type of communication, data, control, or transport network. For example, network 106 may include wireless, over-the-air networks (e.g., the Internet), local area networks (LANs), wide area networks (WANs), software-defined WANs (SDWANs), data center networks, physical layers, overlay layers, or any other combination thereof. Network 106 can be used to connect various network elements, such as routers, switches, infrastructure nodes, edge devices, aggregation switches, gateways, ingress and / or egress switches, provider edge devices and / or any other type of routing or switching equipment, computing devices, or computing resources (e.g., servers, firewalls, processors, databases, virtual machines, etc.).

[0036] Computing resources 108a and 108b represent examples of network devices that can be connected to network 106 for communication with each other and / or with other devices. For example, computing resources 108a and 108b may include various host devices, servers, processors, virtual machines, or other devices capable of hosting applications, executing processes, performing network management functions, etc. In some examples, applications 110a and 110b may execute on computing resource 108a, while applications 110c and 110d may execute on computing resource 108b. Application 110a may include any type of software application, process, or workflow defined using instructions or code.

[0037] Data ingestion block 102 representatively illustrates a mechanism for providing input data to any one or more of applications 110a, 110b, 110c, and 110d. Network 106 can be used to direct input data to the corresponding applications 110a, 110b, 110c, and 110d for execution. One or more applications 110a, 110b, 110c, and 110d can (e.g., during their execution) generate and interpret program statements obtained from data ingestion block 102. Instrumentation, such as vulnerability detection, can be provided by vulnerability detection engine 104 for evaluating these applications during execution. During runtime, as part of their regular workflow, the installed applications receive input and create output. Each input reaching the installed input (source) point is examined by one or more vulnerability sensors that check the syntax of the input for characteristics of attack patterns such as SQL injection, cross-site scripting (XSS), file path manipulation, and / or JavaScript object declaration (JSON) injection. For example, Runtime Application Self-Protection (RASP) agents 112a and 112d can be provided in the respective applications 110a and 110d to evaluate the application's execution during runtime. As will be described below, such agents can also be used to provide call stack-level vulnerability / security issues for the application during runtime. For example, RASP agents 112a and / or 112b can examine call stacks that may be invoked during application runtime to determine whether these call stacks are authorized (permitted) to be invoked by the application.

[0038] RASP agents 112a, 112b, 112c, and 112d can perform any type of security assessment on the application at runtime. In some examples, such as the reference... Figure 1BAs shown, applications 130a and 130b can be stored on codebase 120 or other memory storage, rather than being actively executed on computing resources. Similar agents (e.g., RASP agents) can perform analysis of the applications (e.g., static analysis). For example, code scanner agent 122 can be used to analyze the code in applications 130a and 130b. RASP agents 112a, 112b, 112c, 112d and / or code scanner agent 122 or other such embedded solutions can be used to analyze the health and status of the applications at various stages (e.g., during runtime or under static conditions in memory).

[0039] In some examples, sensors can be used to monitor and collect dynamic information related to applications running on various servers or virtual machines, and report this information to a collector for analysis. This information can be used (e.g., to a RASP agent) to provide application security. RASP techniques can be used, for example, to protect software applications from security vulnerabilities by adding protective features to the application. In typical RASP implementations, these protective features are installed into the application runtime environment, for example, by making appropriate changes and additions to the application code and / or operating platform. This approach is designed to detect suspicious behavior during application execution and initiate protective actions when such behavior is detected.

[0040] For example, during the runtime of an application on a virtual machine or server in network environment 100, sensors provided for monitoring the installed application can receive inputs and create outputs as part of the application's regular workflow. In some examples, inputs arriving at the installed input (source) point of the sensor can be examined for one or more vulnerabilities. For instance, the sensor can collect application-related information to provide to one or more collectors, where an analytics engine can be used to analyze whether vulnerabilities may exist in the application.

[0041] Vulnerabilities can include weaknesses, flaws, errors, loopholes, etc., in software applications. These vulnerabilities can be exploited by malicious actors to gain access to any part or the entirety of the network environment 100, cause disruption, conduct unauthorized transactions, or lead to other harmful activities. For example, vulnerabilities in software or applications running on network environment 100 can lead to cyberattacks against the computer systems of various enterprises and organizations by compromising security systems (e.g., using computer viruses, worms, Trojans, ransomware, spyware, adware, scareware, and other malware). Most enterprises or organizations recognize the need to continuously monitor their computer systems to identify risky software not only from known software vulnerabilities but also from newly reported vulnerabilities (e.g., due to new computer viruses or malware). Identifying vulnerable software allows for protective measures such as deploying specific antivirus software, restricting the operation of vulnerable software to limit damage, and preventing access to suspicious / unauthorized call stacks.

[0042] Figure 2 An example of a software call stack security system according to one aspect of this disclosure is shown. The software call stack security system 200 may include a call stack tracing service 202, a call stack classification service 210, and a call stack security service 220. Various functional blocks are shown in the call stack security system 200, and the functions of these functional blocks will be explained below; however, it should be noted that these functional blocks can be implemented by a suitable combination of computing devices, network systems, and storage mechanisms (e.g., provided in network environment 100). For example, the function of the call stack tracing service 202 can be described by referring to the above... Figure 1A and Figure 1B The described RASP agents 112a, 112b, 112c, 112d and / or code scanner agent 122 are implemented. Furthermore, the functionality of call stack classification service 210 and call stack security service 220 can be implemented by vulnerability detection engine 104. In another example, all the functionality of call stack tracing service 202, call stack classification service 210, and call stack security service 220 can be implemented by vulnerability detection engine 104.

[0043] Call stack tracing service 202 can be used to perform call stack tracing and enumeration for one or more applications. Different phases include integration testing, pre-production, and past production phases. In one example, call stack tracing service 202 can periodically generate runtime call stack lists (e.g., every millisecond, every second, every minute, every hour, etc.). Each runtime call stack list includes all runtime call stacks of the application at a given point in time. Runtime call stacks include all possible call stacks accessed (or accessible by the application) and occupying memory capacity when the list is generated. Based on runtime call stack lists from a first set of execution environments, such as a test environment, call stack tracing service 202 can generate a trace list of all encountered software call stacks.

[0044] In another example, call stack tracing service 202 can track runtime software call stacks encountered in a second set of execution environments that may introduce potential security threats to the application. For example, such a second set of execution environments for the application could include environments where penetration testing of the application is performed. These software call stacks could also be stored in a tracing list. However, because these software call stacks may be associated with potential security threats to the application, they can be stored as a separate authorized / insecure list (blacklist), rather than a list of runtime call stacks from the first set of execution environments.

[0045] In yet another example, this trace list could include a combination of all periodic lists of the runtime call stack, as well as the execution order in which the software call stacks are executed. This execution order can be stored for the runtime call stacks of both the first and second execution environments. (See reference...) Figure 5A , 5B Examples of this execution order are described in more detail in 5C.

[0046] The call stack tracing service 202 can transmit / provide such a tracing list to the call stack classification service 210 for further processing. As described below, the call stack classification service 210 can use the tracing list created by the call stack tracing service 202 to determine whitelists and blacklists.

[0047] A whitelist can include a subset or all of the software call stacks included in a trace list. In some examples, the call stack classification service 210 can generate a whitelist based on manual feedback. During any execution environment, call stacks can be manually identified (e.g., by a network operator) as secure / authorized call stacks. An authorized call stack list can be created. Such a list can include call stacks for several applications and is not necessarily limited to one application. In another example, such a list can include multiple entries that associate each call stack with one or more applications and indicate whether a given call stack is authorized for each application. The call stack classification service 110 can use such a list to generate a whitelist from received trace lists for specific applications. In one example, this manually created authorized call stack list can be updated periodically (e.g., hourly, daily, weekly, monthly, etc.).

[0048] The blacklist may include a subset or all of the software call stacks encountered in a second set of execution environments (e.g., a test environment) of the application in the tracking list, and / or unauthorized call stacks identified during previous runs of the application. In some examples, the call stack classification service 210 may generate the blacklist based on manual feedback and in a manner similar to the manual process described above for creating a whitelist.

[0049] As described above regarding the call stack tracing service 202, the whitelist and blacklist also include the execution order of each software call stack. Each execution order of each specific software call stack can be marked as authorized or unauthorized and stored in the whitelist or blacklist along with the corresponding software call stack.

[0050] Software call stacks can be determined as secure and whitelisted or insecure and blacklisted based on various criteria. For example, some call stacks may be considered insecure under certain settings or conditions in which the application is deployed / executed, while the same call stacks may be considered secure under other settings in which the application is deployed. For example, connection type can be a setting / condition affecting whether a given call stack is whitelisted. In one case, application A may have a corresponding call stack X that will be invoked when application A is deployed. If the terminal is using a public Wi-Fi connection to access application A, call stack X can be considered insecure / unauthorized for application A, while if the terminal is using a secure private network connection to access application A, call stack X can be considered authorized / secure. Therefore, manually created links can also include entries indicating the settings (or conditions) under which the call stack will be whitelisted. Another example of a setting or condition is the version of the application. For example, call stack X may be authorized for a first version of application A, but unauthorized for a second version of application A. Even after the application is in production and / or deployed, the call stack classification service 210 can periodically update the whitelist and blacklist.

[0051] Those skilled in the art will understand that the call stack tracing service 202 can use techniques specific to application code types to trace and enumerate the software call stack. In an example of a Java-based application, the executing thread "public static Map"...<thread,StackTraceElement[]> The `getAllStackTraces()` function can be used to return a stack trace graph of all live threads, including all runtime stacks corresponding to the threads of a Java-based application. In the example of a Python-based application, the "Trace" module and its related functions can be used to extract, format, and print all stack traces for a Python-based application.

[0052] The call stack classification service 210 can use a classifier trained with a machine learning model to classify software call stacks as authorized or unauthorized. This machine learning model can be trained using positive and negative example call stacks (authorized and unauthorized example call stacks) as well as manual feedback to provide a system that automatically scores any detected call stack and uses that score and a corresponding threshold to determine whether the detected call stack should be whitelisted or blacklisted. (See below for reference.) Figure 4 This process will be described further.

[0053] The execution order of the software call stack can also be used as additional training data for training machine learning models. This will be described further below.

[0054] As described below, the call stack classification service 210 can transmit / provide the software call stack classification results and the score to the call stack security service 220 for further processing and implementation of appropriate security policies.

[0055] Call stack security service 220 can control the execution of each software call stack during application deployment. In one example, call stack security service 220 can apply a security policy to each software call stack based on classification results from call stack classification service 110. One example security policy may include allowing execution of a software call stack classified as authorized by call stack classification service 210. Another example security policy may include blocking execution of a software call stack classified as unauthorized by call stack classification service 210. Yet another example security policy may include marking or warning for encountered software call stacks classified as unauthorized by call stack classification service 210.

[0056] In some examples, when the call stack classification service 210 is a machine learning-trained classifier, the call stack security service 220 can apply a security policy to each software call stack based on the scoring results from the call stack classification service 210. This classifier can assign a score to any call stack encountered during application runtime. One example security policy may include allowing execution of software call stacks with scores above a predetermined threshold, but blocking or flagging software call stacks with scores below the predetermined threshold. Another example security policy may include setting authorized score ranges, unauthorized score ranges, and undetermined score ranges. This security policy includes allowing execution of software call stacks with scores within the authorized score range, blocking or flagging software call stacks with scores within the unauthorized score range, and submitting software call stacks with scores within the undetermined score range for manual review (e.g., within the threshold score range as described above).

[0057] Although Figure 2 It shows the application to Figure 1A and Figure 1BThe example configuration of various components of the software call stack security system 100 is provided below; however, those skilled in the art will understand that the components of the software call stack security system 200 or any system described herein can be configured in a variety of different ways and can include any other type and number of components. For example, the functionality of call stack tracing service 202, call stack classification service 210, and / or call stack security service 220 can be implemented using a single component or a set of instructions executed by a processor. In another example, part or all of the machine learning model and its associated scoring system in call stack classification service 210 can be included in call stack tracing service 202 or call stack security service 220. Services can also be combined into fewer components and / or further divided into more components.

[0058] Based on the above reference Figure 2 The example of the described software call stack security system now turns to an example method for applying a zero-trust security policy at the software call stack level. Security systems such as call stack security system 200 can apply a zero-trust security policy by utilizing the classification and scoring results of each software call stack (e.g., classification and scoring results from call stack classification service 210). As mentioned above, the functionality of call stack security system 200 can be implemented by vulnerability engine 104 or other components of system 100.

[0059] Figure 3 An example method for applying a zero-trust security policy at the software call stack level, according to one aspect of this disclosure, is illustrated. The components of system 100 in Figure 1, Figure 2 Describing from the perspective of any appropriate combination of call stack tracing service 202, call stack classification service 210, and call stack security service 220 Figure 3 The process. However, it should be understood that each of the call stack tracing service 202, call stack classification service 210, and call stack security service 220 may have one or more processors that execute computer-readable instructions stored in associated memory to implement Figure 3 The process is 300.

[0060] At S302, vulnerability engine 104 (by implementing the functionality of call stack classification service 210) can generate a call stack classification scheme. In one example, generating such a call stack classification scheme may include determining a whitelist and / or blacklist of software call stacks for the application. In one example, the above reference can be used... Figure 2 The described manual process determines this whitelist and / or blacklist. S302 can be determined before the application runs or before application deployment, or alternatively, it can be determined when the application is detected to be being deployed. If determined in advance, S302 itself can be a separate process, and not necessarily... Figure 3 It is part of the entire process and function.

[0061] In another example, generating such a call stack classification scheme could include using machine learning techniques to train a classifier, as will be referenced below. Figure 4 As described. Such a classifier can be trained to provide a score for any given / encountered call stack during application runtime (which can then be compared to a threshold to determine whether the call stack is authorized), or alternatively, it can be trained to classify encountered call stacks as authorized or unauthorized.

[0062] At S304, during application deployment, vulnerability engine 104 (by implementing the functionality of call stack classification service 210) can detect the call stack during application deployment. In one example, vulnerability engine 104 can log information about... Figure 2 The described runtime call stack information may include the execution order of the runtime call stack.

[0063] At S306, vulnerability engine 104 (by implementing the functionality of call stack classification service 210) can use the call stack classification scheme determined at S302 to classify the call stack detected at S304. In one example, a neural network (classifier) ​​can be used to classify the call stack as described above, which will be referenced below. Figure 4 The generation of this classifier is described in detail. This classifier can be trained to provide a score for any given / encountered call stack during application runtime (which can then be compared to a threshold to determine whether the call stack is authorized), or alternatively, it can be trained to classify encountered call stacks as authorized or unauthorized.

[0064] In one example, when utilizing a trained classifier, vulnerability engine 104 can receive the encountered call stack (and / or associated execution order) as input and provide a score for the encountered call stack as output. Vulnerability engine 104 can then compare this score to a threshold or range threshold as described above to determine whether the encountered call stack is an authorized call stack. In another example, a trained classifier can be used to receive the encountered call stack as input and provide a classification of the encountered call stack (as authorized or unauthorized) as output.

[0065] In another example, the call stack classification scheme can be a manually created call stack classification scheme (such as a whitelist and / or blacklist as described above). In the case of a manually created whitelist, the vulnerability engine 104 can receive the encountered call stack (and / or associated execution order) as input and compare the encountered call stack with the whitelist. If the whitelist indicates that the encountered call stack is an authorized call stack, the vulnerability engine 104 classifies the encountered call stack as an authorized call stack. Otherwise, the vulnerability engine 104 classifies the encountered call stack as an unauthorized call stack. Therefore, at S306, the vulnerability engine 104 provides a classification result for each encountered call stack.

[0066] At S308, vulnerability engine 104 (by implementing the functionality of call stack security service 220) can apply a security policy to each software call stack based on the classification results. In one example, the security policy could indicate that only authorized software call stacks included in the whitelist are allowed access to the application, and access to the application is denied to call stacks classified as unauthorized.

[0067] Figure 4 The example process enables any application to apply a zero-trust security policy at the endpoints of an enterprise network at the software call stack level, thereby improving application and network security within such an enterprise network.

[0068] As referenced above Figure 3 As described, vulnerability engine 104 can utilize a trained classifier to classify encountered call stacks as authorized or unauthorized. This disclosure now turns to example methods for training a classifier (neural network) to classify software call stacks.

[0069] Figure 4 An example neural architecture according to one aspect of this disclosure is shown.

[0070] Figure 4 An example neural architecture 400 of a neural network 410 (which may be referred to as classifier 410) as defined by an example neural network description 402 in a neural controller 401 is shown. The neural network description 402 may include a full specification of the neural network 410, which includes the neural architecture 400. For example, the neural network description 402 may include: a description or specification of the architecture of the neural network 410 (e.g., layers, layer interconnections, number of nodes in each layer, etc.); input and output descriptions (which indicate how the inputs and outputs are formed or processed); descriptions of activation functions, operations, or filtering in the neural network; neural network parameters (e.g., weights, biases, etc.); etc.

[0071] Neural network 410 may reflect the neural architecture 400 defined in neural network description 402. In this non-limiting example, neural network 410 includes an input layer 403 that includes input data, which can be any type of data, such as media content (images, videos, etc.), numbers, text, etc. In an illustrative example, input layer 403 may include data representing a software call stack. In the example context related to call stack security system 200, data representing a software call stack may include, for example, data about... Figure 2 The described trace list is generated by the call stack tracing service 202. In another example, data representing the software call stack may include information about the software call stack detected by the call stack tracing service 202 during application deployment.

[0072] The neural network 410 may include hidden layers 404A to 404N (collectively referred to as "404"). Hidden layers 404 may include n hidden layers, where n is an integer greater than or equal to 1. The number of hidden layers may include the number of layers required for the desired processing outcome and / or rendering intent. In an illustrative example, any layer in hidden layers 404 may include data representing software call stacks that have been categorized in a whitelist or blacklist. This data may include data for each software call stack included in the whitelist or blacklist, such as information about... Figure 2 As described. This data may also include which whitelist or blacklist each software call stack is included in.

[0073] The neural network 410 also includes an output layer 406 that provides the output of the processing performed by the hidden layer 404. In one illustrative example, the output layer 406 may provide output data based on the input data. In an example context related to the call stack security system 200, the output data may include classifying the input software call stack as authorized or unauthorized. In another example, the output data may include a score of the input software call stack, which can then be compared to an example threshold or an example threshold range to classify the corresponding software call stack as authorized or unauthorized.

[0074] In this example, neural network 410 is a multi-layered neural network composed of interconnected nodes. Each node can represent a piece of information. The information associated with a node is shared between different layers, and each layer retains the information as it is processed. In some cases, neural network 410 may include a feedforward neural network, in which case there are no feedback connections, and the output of the neural network is fed back to itself. In other cases, neural network 410 may include a recurrent neural network, which may have loops that allow information to be read at input and to be transferred across nodes.

[0075] Information can be exchanged between nodes through node-to-node interconnections between layers. Nodes in input layer 403 can activate a set of nodes in the first hidden layer 404A. For example, as shown, each input node in input layer 403 is connected to each node in the first hidden layer 404A. Nodes in hidden layer 404A can transform the information of each input node by applying activation functions to the information. The information derived from the transformation can then be passed to nodes in the next hidden layer (e.g., 404B) and these nodes can be activated, allowing them to perform their own specified functions. Example functions include convolution, upsampling, data transformation, pooling, and / or any other suitable function. The output of the hidden layer (e.g., 404B) can then activate nodes in the next hidden layer (e.g., 404N), and so on. The output of the last hidden layer can activate one or more nodes in output layer 406, at which point the output is provided. In some cases, although nodes in neural network 410 (e.g., nodes 408A, 408B, 408C) are shown as having multiple output lines, the nodes have a single output, and all lines shown as outputs from the node represent the same output value.

[0076] In some cases, each node or the interconnection between nodes can have weights, which are a set of parameters derived from training the neural network 410. For example, an interconnection between nodes can represent a piece of known information about the interconnected nodes. This interconnection can have numerical weights that can be adjusted (e.g., based on the training dataset), which allows the neural network 410 to adapt to the input and learn as more data is processed.

[0077] The neural network 410 can be pre-trained to process features from the data in the input layer 403 using different hidden layers 404, in order to provide an output through the output layer 406. In an example where the neural network 410 is used to classify a software call stack, training data can be used to train the neural network 410, which includes exemplary classified software call stacks. For example, the trained software call stack can be input into the neural network 410, processed by the neural network 410 to generate an output, and can be used to adjust one or more aspects of the neural network 410, such as weights, biases, etc.

[0078] In some cases, neural networks 410 can use a training process called backpropagation to adjust the weights of nodes. Backpropagation includes forward pass, loss function, backward pass, and weight update. Forward pass, loss function, backward pass, and parameter update can be performed in a single training iteration. For each set of training media data, this process can be repeated a certain number of iterations until the layer weights are accurately adjusted.

[0079] In an example of classifying or scoring the software call stack, a classifier based on a trained neural network 410 can be included in the call stack classification service 210.

[0080] In the example of classifying the software call stack, forward propagation may include passing software call stack data through a neural network 410. The weights may initially be randomized before the neural network 410 is trained. The software call stack data may include, for example, an array of numbers and / or letters representing the functionality of the software call stack, past code of the software call stack, stack frames associated with the software call stack, and the values ​​of frame pointers, etc.

[0081] Neural network 410 can include any suitable neural or deep learning network. One example includes a convolutional neural network (CNN), which consists of an input layer and an output layer, with multiple hidden layers between them. The hidden layers of a CNN include a series of convolutional layers, non-linear layers, pooling layers (for downsampling), and fully connected layers. In other examples, neural network 410 can represent any other neural or deep learning network, such as an autoencoder, a deep belief network (DBN), a recurrent neural network (RNN), etc.

[0082] NAS involves a process in which a neural controller 401 searches various types of neural networks (e.g., CNNs, DBNs, RNNs, etc.) to determine which type of neural network, given the input / output description of neural network description 402, can, once trained, perform a near-desired output. Because each type of available neural network is treated as a "black box," this search process is currently cumbersome and resource-intensive. In other words, a neural controller such as neural controller 401 selects an available neural network (black box), trains it, validates it, and selects or does not select it based on the validation results. However, each example or type of available neural network is a collection of nodes. As described below, this disclosure allows for in-depth analysis of the performance of each individual node to evaluate its performance, and then allows the system to select a hybrid structure of nodes that may be the same as or different from the specific structure of currently available neural networks. In other words, this disclosure enables AutoML systems to pick nodes from different available neural networks and create new structures that perform best for a given application.

[0083] The classifier based on neural network 410 can also be trained to score software call stacks encountered during the production phase of application deployment. To train neural network 410 to score software call stacks, training scores can be assigned to each software call stack included in hidden layer 404 before training. Each node of output layer 406 can represent each of a finite number of scores, and output layer 406 can output the score of the software call stack.

[0084] In one example, the score for each software call stack represents the likelihood of the software call stack being secure and authorized. For example, the score for each software call stack can be a number on a scale (e.g., in the range of 0 to 10, 0 to 20, 0 to 100, etc.), a percentage, and / or any other type of indicator. A threshold score may exist, against which scores can be compared to determine whether a software call stack is authorized or unauthorized. For example, a score above the threshold score may indicate that the call stack is authorized, while a score below the threshold score may indicate that the call stack is unauthorized. In another example, scores within a given range of the threshold score (e.g., within 1 point or 1% of the threshold score) can be included in a graylist. In one example, call stacks in the graylist can be submitted for manual analysis / inspection to determine whether they should be included in a whitelist or blacklist. The threshold score can be determined based on any known or developing methods and / or empirical research. For example, the score for each software call stack could be a percentage. Return to Reference Figure 2 The call stack classification service 210 can classify software call stacks based on threshold scores and scores of software call stacks generated by a classifier.

[0085] Scores are determined based on different factors. When determining the final score, the same or different weights can be assigned to the individual scores based on different factors.

[0086] In one example, scores can be determined based on the frequency with which a software call stack is encountered during different stages of application execution. A whitelist can include software call stacks and the corresponding number of times each particular call stack is encountered. Therefore, a trained classifier can assign higher scores to software call stacks that are encountered more frequently during different stages of application execution.

[0087] In another example, the score is determined based on whether the execution order of the encountered software call stack is marked as authorized in a whitelist or unauthorized in a blacklist. For example, a whitelist (which includes a specific software call stack in a secure execution environment) includes all execution orders of the software call stack. If a new execution order involving the software call stack is encountered, and that new order is not included in the whitelist, the machine learning model can assign a lower score to that software call stack, indicating a lower likelihood that the software call stack should be authorized. In another example, a blacklist (which includes a specific software call stack and is considered insecure and unauthorized) includes all execution orders of the software call stack. If a new execution order involving the software call stack is encountered, and that new order is included in the blacklist, the machine learning model can assign a lower score to that software call stack, indicating a lower likelihood that the software call stack should be authorized.

[0088] After generating scores for the software call stack, the classifier can transfer the scores to the call stack classification service 210. The call stack classification service 210 can be based on... Figure 3 The scores described in S306 are used to classify the software call stack.

[0089] Although Figure 4 The examples in Figures 1 and 2 are shown from the perspective of the various components within the system; however, those skilled in the art will understand that the components of the neural architecture 400 or neural network 410 or any system described herein can be configured in a variety of different ways and can include any other type and number of components.

[0090] Referring to Figure 1 to Figure 4 Following the examples of software call stack security systems, methods for applying zero-trust security policies at the software call stack level, and examples of neural architectures for classifying and scoring software call stacks, this disclosure now turns to... Figure 5A , Figure 5B and Figure 5CAn example diagram illustrating the software call stack is provided to further illustrate the operation of the aforementioned software call stack security system 200 and / or other components of the system.

[0091] Figures 5A to 5C An example diagram of a software call stack according to one aspect of this disclosure is shown. The description will be based on the functionality of the vulnerability engine 104 as described above, which implements the call stack tracing service 202, the call stack classification service 210, and the call stack security service 220. Figure 5A , Figure 5B and Figure 5C Example diagram. However, those skilled in the art will readily understand that other system configurations and components capable of supporting functions for implementing zero-trust security at the software call stack level are also within the scope of this disclosure.

[0092] Figure 5A Example diagram 500 illustrates a software call stack encountered during past execution phases of an application. Boxes 502, 504, 506, 508, 510, and 512 each represent a software call stack encountered during past execution phases of the application and form an example whitelist. For example, box 502 represents a software call stack titled "main". The percentages in the boxes represent enumerations based on tracking past phases of the software call stack. For example, 0.04% in software call stack 506 represents the percentage of times software call stack "main" was called (e.g., 0.04% of all calls in the application). Each arrow connecting the boxes (e.g., arrow 520) indicates the execution order of the software call stack. For example, arrow 520 indicates that software call stack 504 was called before software call stack 506. The number to the right of each arrow (e.g., number 522) indicates the number of times a particular call order was used. For example, the call order from software call stack 504 to software call stack 506 occurred once in a past phase. In some examples, the call stack classification service 210 may include the above information (e.g., the percentage of times the software call stack main is called, the execution order, the number of times a specific call order is used in a whitelist), as a condition for classifying any future detected call stack as an authorized call stack.

[0093] Figure 5B Example diagram 530 shows a software call stack encountered during application deployment. The software call stack 514, titled "pointed," and the execution order 524 are not included. Figure 5AThe example whitelist. Therefore, the call stack classification service 210 can classify the software call stack 514 as unauthorized, and the call stack security service 220 can prevent the software call stack 514 from accessing the corresponding application during runtime. In an example using a classifier, the call stack classification service 210 can determine a score for the software call stack 514 when it encounters it, which can be compared to a threshold to identify the software call stack 514 as unauthorized. Alternatively, the classifier can provide a classification of the software call stack 514 (classified as unauthorized) as output. In another example, a trained classifier can determine the score of the software stack 514 within an undetermined range, such as regarding Figure 2 and Figure 4 Detailed description. In this case, the call stack classification service 210 can submit the software call stack 514 and execution order 524 for manual review before classifying the software call stack 514 as unauthorized.

[0094] Figure 5C Example diagram 540 shows the software call stack encountered during application deployment. Execution order 542 is not included. Figure 5A The example whitelist is not included. Therefore, even if software call stacks 508 and 512 are included in the whitelist, call stack classification service 210 can still classify software call stack 512 as unauthorized because of execution order 542. As mentioned above, this classification can be based on a manually created whitelist, or alternatively, using the trained classifier described above. In an example using a classifier, when call stack 508 is encountered in this execution order, call stack classification service 210 can determine a score for software call stack 508, which can be compared with a threshold to identify software call stack 508 as unauthorized. Alternatively, the classifier can provide a classification of software call stack 508 as output, since execution order 542 is not included in the example whitelist, so software call stack 508 is classified as unauthorized. Therefore, call stack security service 220 can prevent call stack 508 from accessing the runtime application.

[0095] Having provided the example of a zero-trust security scheme at the software call stack level described above with reference to Figures 1-5, this disclosure now turns to... Figure 6A and 6B , Figure 6A and 6B This is an example system architecture used to describe the implementation of the software call stack security system 200 and / or other components of the aforementioned system.

[0096] Figures 6A-6BAn example of a system according to one aspect of this disclosure is shown. More suitable systems will be apparent to those skilled in the art when practicing various embodiments. Those skilled in the art will also readily recognize that other systems are possible.

[0097] Figure 6A An example architecture of a bus computing system 600 is shown, in which the components of the system communicate electrically with each other using a bus 605. The computing system 600 may include a processing unit (CPU or processor) 610 and a system bus 605, which may couple various system components, including system memory 615 (e.g., read-only memory (ROM) and random access memory (RAM) 675 in storage device 670), to the processor 610. The computing system 600 may include a cache 612 of high-speed memory that is directly connected to, near, or integrated as part of the processor 610. The computing system 600 may copy data from memory 615 and / or storage device 630 to the cache 612 for fast access by the processor 610. In this way, the cache 612 can provide performance improvements by avoiding latency for the processor while waiting for data. These and other services may be controlled or configured to control the processor 610 to perform various actions. Other system memories 615 may also be available. Memory 615 may include various different types of memory with different performance characteristics. Processor 610 may include any general-purpose processor, hardware module, or software service (e.g., services 1 632, 2 634, and 3 636 stored in storage device 630), which is configured to control processor 610 and dedicated processors, wherein software instructions are incorporated into the actual processor design. Processor 610 may essentially be a fully self-contained computing system containing multiple cores or processors, buses, memory controllers, caches, etc. Multi-core processors may be symmetric or asymmetric.

[0098] To enable users to interact with the computing system 600, input device 645 can represent any number of input mechanisms, such as a microphone for speaking, a touchscreen for gesture or graphical input, a keyboard, a mouse, motion input, voice, etc. Output device 635 can also be one or more of many output mechanisms known to those skilled in the art. In some cases, a multimodal system allows users to provide multiple types of input to communicate with the computing system 600. Communication interface 640 can control and manage user input and system output. It is not limited to any particular hardware arrangement, and therefore, as improved hardware or firmware arrangements are developed, these basic features can be easily replaced.

[0099] Storage device 630 may be a non-volatile memory and may be a hard disk or other type of computer-readable medium that can store data accessible by a computer, such as magnetic tape, flash memory card, solid-state storage device, digital multifunction disk, cassette tape, random access memory (RAM) 625, read-only memory (ROM) 620 and combinations thereof.

[0100] Storage device 630 may include software services 632, 634, and 636 for controlling processor 610. Other hardware modules or software services are also considered. Storage device 630 may be connected to system bus 605. In one aspect, a hardware module performing a specific function may include software components stored in a computer-readable medium that are connected to necessary hardware components (e.g., processor 610, bus 605, output device 635, etc.) to perform that function.

[0101] Figure 6B An example architecture of a chipset computing system 650, which may be used according to an embodiment, is shown. The computing system 650 may include a processor 655, which represents any number of physically and / or logically distinct resources capable of executing software, firmware, and hardware configured to perform specific computations. The processor 655 may communicate with a chipset 660, which may control inputs to and outputs from the processor 655. In this example, the chipset 660 outputs information to an output device 665 such as a display and may read and write information to a storage device 670, which may include, for example, magnetic media and solid-state media. The chipset 660 may also read data from and write data to RAM 675. A bridge 680 may be provided for interfacing with various user interface components 685, such as a keyboard, microphone, touch detection and processing circuitry, directional devices such as a mouse, etc. The input to the computing system 650 can come from any of a variety of sources, which are machine-generated and / or artificially generated.

[0102] Chipset 660 can also interface with one or more communication interfaces 690, which may have different physical interfaces. Communication interfaces 690 may include interfaces for wired and wireless LANs, broadband wireless networks, and personal area networks. Some applications of the methods disclosed herein for generating, displaying, and using a GUI may include receiving an ordered dataset via a physical interface, or generating it by the machine itself through processor 655 analyzing data stored in storage device 670 or RAM 675. Furthermore, computing system 600 may receive input from a user via user interface component 685 and perform appropriate functions, such as browsing functions, by interpreting this input using processor 655.

[0103] It should be understood that computing systems 600 and 650 may each have more than one processor 610 and 655, or computing systems 600 and 650 may be part of a group or cluster of computing devices networked together to provide greater processing power.

[0104] In summary, this disclosure provides systems, methods, and computer-readable media for implementing security policies at the software call stack level. In one example, a method includes: generating a call stack classification scheme for an application; detecting the call stack during application deployment; using the call stack classification scheme during application runtime to classify the detected call stack as either an authorized call stack or an unauthorized call stack to generate a classification; and applying a security policy based on the classification.

[0105] For clarity, in some cases, various embodiments may be represented as including various functional blocks, including functional blocks that include: devices, device components, steps or routines of methods embodied in software (or a combination of hardware and software).

[0106] In some examples, computer-readable storage devices, media, and memories may include cables or wireless signals containing bit streams, etc. However, when referred to, non-transitory computer-readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and the signals themselves.

[0107] The methods according to the embodiments described above can be implemented using computer-executable instructions that are stored or otherwise obtained from a computer-readable medium. Such instructions may include, for example, instructions and data that cause or otherwise configure a general-purpose computer, special-purpose computer, or special-purpose processing device to perform a function or group of functions. A portion of the computer resources used may be accessible via a network. The computer-executable instructions may be, for example, binary files, intermediate format instructions (e.g., assembly language, firmware, or source code). Examples of computer-readable media that can be used to store instructions, information, and / or information created during the methods according to the embodiments include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and the like.

[0108] Devices implementing the methods disclosed herein may include hardware, firmware, and / or software, and may take any of a variety of form factors. Typical examples of such form factors include laptops, smartphones, small form factor personal computers, personal digital assistants, rack-mount devices, standalone devices, etc. The functionality described herein may also be embodied in peripheral devices or add-in cards. As a further example, such functionality may also be implemented on different chips on a circuit board or in different processes executing within a single device.

[0109] Instructions, a medium for conveying such instructions, computing resources for executing such instructions, and other structures for supporting such computing resources are devices for providing the functions described in these disclosures.

[0110] While various examples and other information have been used to interpret aspects within the scope of the appended claims, no limitation on the claims should be implied based on specific features or arrangements in such examples, as those skilled in the art will be able to use these examples to obtain a wide variety of implementations. Furthermore, while some subjects may have been described in language specific to structural features and / or method steps, it should be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or actions. For example, such functionality may be distributed differently in or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.

Claims

1. A method comprising: Generate a call stack classification scheme; Detect the call stack during application deployment; During the runtime of the application, the call stack classification scheme is used to classify detected call stacks as either authorized call stacks or unauthorized call stacks to generate a classification. as well as Security policies are applied based on the aforementioned classification.

2. The method according to claim 1, wherein, The call stack classification scheme includes: A whitelist of authorized call stacks that can be accessed by the application.

3. The method according to claim 1 or 2, wherein, The call stack classification scheme includes: A classifier trained using machine learning techniques is used to identify detected call stacks as either authorized or unauthorized call stacks.

4. The method according to claim 3, wherein, Training the classifier includes: The classifier is trained using a previously known list of authorized call stacks and a previously known list of unauthorized call stacks.

5. The method according to claim 3 or 4, wherein, The classifier is trained to output a score for the detected call stack during the runtime of the application.

6. The method according to claim 5, wherein, The classification of the detected call stacks also includes: Compare the score with a threshold; and If the score is greater than the threshold, the call stack is classified as the authorized call stack.

7. The method according to any one of claims 3 to 6, wherein, The classifier is trained to output the classification of the call stack detected during the runtime as either an authorized call stack or an unauthorized call stack.

8. A system comprising: One or more memories having computer-readable instructions stored therein; as well as One or more processors are configured to execute the computer-readable instructions to perform the following operations: Generate a call stack classification scheme; Detect the call stack during application deployment; During the runtime of the application, the call stack classification scheme is used to classify detected call stacks as either authorized call stacks or unauthorized call stacks to generate a classification. as well as Security policies are applied based on the aforementioned classification.

9. The system according to claim 8, wherein, The call stack classification scheme includes: A whitelist of authorized call stacks that can be accessed by the application.

10. The system according to claim 8 or 9, wherein, The call stack classification scheme includes: A classifier trained using machine learning techniques is used to identify detected call stacks as either authorized or unauthorized call stacks.

11. The system according to claim 10, wherein, The one or more processors are configured to execute the computer-readable instructions to train the classifier using a previously known list of authorized call stacks and a previously known list of unauthorized call stacks.

12. The system according to claim 10 or 11, wherein, The classifier is trained to output a score for the detected call stack during the runtime of the application.

13. The system according to claim 12, wherein, The one or more processors are configured to execute the computer-readable instructions to perform the following operations: Compare the score with a threshold; and If the score is greater than the threshold, the call stack is classified as the authorized call stack.

14. The system according to any one of claims 10 to 13, wherein, The classifier is trained to output the classification of the call stack detected during the runtime as either an authorized call stack or an unauthorized call stack.

15. One or more non-transitory computer-readable storage media, comprising computer-readable instructions that, when executed by one or more processors of a security system, cause the security system to perform the following operations: Generate a call stack classification scheme; Detect the call stack during application deployment; During the runtime of the application, the call stack classification scheme is used to classify detected call stacks as either authorized or unauthorized call stacks to generate a classification; and Security policies are applied based on the aforementioned classification.

16. One or more non-transitory computer-readable storage media according to claim 15, wherein, The call stack classification scheme includes: A whitelist of authorized call stacks that can be accessed by the application.

17. One or more non-transitory computer-readable storage media according to claim 15 or 16, wherein, The call stack classification scheme includes: A classifier trained using machine learning techniques is used to identify detected call stacks as either authorized or unauthorized call stacks.

18. One or more non-transitory computer-readable storage media according to claim 17, wherein, Executing the computer-readable instructions by the one or more processors also causes the security system to train the classifier using a previously known list of authorized call stacks and a previously known list of unauthorized call stacks.

19. One or more non-transitory computer-readable storage media according to claim 17 or 18, wherein, The classifier is trained to output a score for the detected call stack during the runtime of the application.

20. One or more non-transitory computer-readable storage media according to claim 19, wherein, Executing the computer-readable instructions by the one or more processors also causes the security system to perform the following operations: Compare the score with a threshold; and If the score is greater than the threshold, the call stack is classified as the authorized call stack.

21. An apparatus comprising: Generate a call stack classification scheme; Detect the call stack during application deployment; During the runtime of the application, the call stack classification scheme is used to classify detected call stacks as either authorized call stacks or unauthorized call stacks to generate a classification. as well as Security policies are applied based on the aforementioned classification.

22. The apparatus of claim 21, further comprising a module for implementing the method of any one of claims 2 to 7.

23. A computer program, computer program product, or computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 7.

Images