Endpoint Security Using Behavioral Prediction Models

Abstract

A set of endpoint security events that reflect known security issues is defined and collected. A corresponding set of endpoint security actions to protect the endpoint is defined and executed. Machine learning is used to build a data model that reflects the relationship between endpoint security events and endpoint security actions. The data model can predict security actions directly from security events without the intermediate step of determining a threat level. Endpoint applications are developed to directly use the data model and apply security actions whenever a security event occurs.

Description

[Technical Field]

[0001] The present disclosure relates to protecting electronic devices, and more particularly to real-time endpoint security protection using data models that predict security actions in response to security events. [Background technology]

[0002] Today, there are many endpoint security issues, including viruses, ransomware, phishing ware, identity theft, device theft, etc. Protecting sensitive information stored on and transmitted from endpoints such as smartphones, tablets, laptops, and other mobile devices is both important and challenging.

[0003] There are many endpoint security providers on the market, and most of them offer similar solutions to solve security problems. One of them is Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP)®. The main strategy of this solution is the implementation of knowledge-based rules. A typical workflow of rule-based implementation is as follows: When information about a security problem is collected from the endpoint, the security provider analyzes the information and determines a solution. Then, an application is deployed to the endpoint to solve the security problem. In this sense, the solution is a rule-based application.

[0004] The rule-based strategy has several drawbacks. The solution to resolving a security problem offered by a particular provider is not necessarily standard, nor is it necessarily the best or most trusted, since it depends on the ability of this particular provider to analyze the problem and build corresponding remediation rules. Furthermore, this method requires many manual steps. Furthermore, there may be some delay in resolving newly emerging security problems, since the provider needs to collect information and analyze the problem before the solution can be applied to the endpoint.

[0005] Other solutions use artificial intelligence (AI) to identify threats by classifying detected events as either threatening or non-threatening. The output of the AI ​​model can be a risk score or whether a pattern of events is anomalous. However, once a threat or anomaly is confirmed, other techniques, such as rule-based techniques, are used to determine what response should be taken. Remedial actions are based on the risk score, the prediction of a threat, or the confirmation of an anomaly. Remedial actions can be automated or left to the administrator. The administrator can verify whether the AI ​​model's predictions are correct and provide feedback to the model.

[0006] U.S. Patent Publication No. 2019 / 0068627 to Thampy analyzes the risk of user behavior when using cloud services. U.S. Patent No. 9,609,011 to Muddu et al. discloses anomaly detection in networks using machine learning. U.S. Patent Publication No. 2019 / 0260804 to Beck et al. uses machine learning to detect threats in network entities. Threats are assigned a score, and automated responses based on the score can be implemented. U.S. Patent No. 10,200,389 to Rostamabadi et al. discloses identifying malware by viewing log files. U.S. Patent Publication No. 2019 / 0230100 to Dwyer et al. is a rule-based solution for analyzing events at endpoints. Remedial actions can be determined at the endpoint or at the connected server. Summary of the Invention

[0007] The AI ​​data model directly predicts the remedial actions to be taken in response to a detected security event, bypassing the intermediate steps that determine the event's risk or threat level. The data model is trained with security events and their corresponding security actions. The data model is trained using data from multiple user actions, so that the actions it predicts may be considered best practice.

[0008] Once the data model is mature, i.e., after machine learning techniques have been used with enough data to train the data model, the data model has the ability to predict what to do if a similar security event pattern occurs on the endpoint in the future. The result of the prediction is one or more security actions that should be applied to the endpoint. When the data model resides on the endpoint, the endpoint can be protected in real time.

[0009] It also allows the endpoint to be protected when an entirely new security problem emerges: if a new security problem causes (trigger) a set of security events that are known to the data model or close to those in the data model, the data model has the ability to predict the appropriate security action or actions, even if that particular security problem is not yet known at this point.

[0010] The particular AI model disclosed is a multi-label classification that directly classifies a sequence of events into a sequence of actions, bypassing the step of determining the threat level, thereby achieving greater efficiency.

[0011] Disclosed below is a method for securing an electronic device, the method comprising: generating a multi-label classification data model including groups of security events labeled with security actions; detecting one or more security events; predicting one or more security actions based on the detected one or more security events using the multi-label classification data model; and performing the predicted one or more security actions on the electronic device.

[0012] Also disclosed below is a system for protecting an electronic device, the system comprising: a processor; and a computer-readable storage medium storing computer-readable instructions that, when executed by the processor, cause the processor to: generate a multi-label classification data model including groups of security events labeled with security actions; receive one or more detected security events associated with the electronic device; use the multi-label classification data model to predict one or more security actions based on the detected one or more security events; and instruct the electronic device to perform the predicted one or more security actions. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a schematic diagram illustrating how user input is used by machine learning to create a data model, according to one embodiment of the present invention. [Figure 2] FIG. 2 is a schematic diagram of a use case illustrating the steps and features involved in the solution according to one embodiment of the present invention. [Figure 3] FIG. 3 is a block diagram of system components according to one embodiment of the present invention. [Figure 4] FIG. 4 is a flowchart of a security action prediction process according to an embodiment of the present invention. [Figure 5] FIG. 5 is a schematic diagram of a data model according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0014] A. Glossary Data model, AI model, AI data model, or machine learning model: An algorithm that takes complex inputs, either previously seen or unseen, and predicts the output that best corresponds to the input. The prediction is based on a data set of inputs and outputs used to train the data model, which identifies outputs as correct or incorrect for specific inputs.

[0015] Endpoint, or Device: This is any electronic or computing device that is to be protected. Non-limiting examples of devices include laptops, mobile phones, personal digital assistants, smartphones, memory sticks, personal digital assistants, gaming consoles, personal computers, tablet computers, e-books, cameras with network interfaces, and netbooks. While most devices protected by the present invention are mobile devices, static devices such as desktop computers, projectors, televisions, copiers, and consumer electronics can also be protected. This may include many other types of electronic devices, such as hi-fi equipment, cameras, bicycles, cars, barbecues, toys, and the like, as long as they have memory and a processor. The device is configured to communicate with a remote server, and communication can be initiated by the device and / or by the server. Communication may occur, for example, via Wi-Fi, SMS, cellular data, or satellite, or may use other communication protocols. While the present invention is often described in the context of a laptop computer, it should be understood that the present invention applies equally to other electronic and computing devices.

[0016] Security Event: A security event is a change or unusual behavior on an endpoint that is of security concern, such as a software change, hardware change, configuration change, unusual web / network usage, unusual software usage, unusual hardware usage, unusual device usage, or unusual data file usage. Security events can be specific or general and may include multiple constituent security events. A security event made up of two constituent events in one order may be different from a security event made up of the same two constituent events in a different order. Security events may depend on the state of the endpoint (such as whether a user is logged in, connected to the network, or its location).

[0017] Security Issue: This is a high-level description of an issue related to an endpoint, e.g., virus, ransomware, phishing ware, identity theft, device theft, etc. A security issue can result in one or more security events.

[0018] Security Action: A measure applied to an endpoint to protect it from a security issue or one or more security events. For example, a security action can stop an application, stop a service, display a warning message, log out the user, lock the screen, uninstall an application, wipe data, wipe the operating system (OS), or freeze the endpoint. One or more security actions can be implemented (executed) in response to a security event or issue.

[0019] System: Unless otherwise specified, this refers to the subject matter of the invention. Refers to a combination of one or more physical devices, including hardware, firmware, and software, configured to protect one or more endpoints. The system uses a multi-label classification data model to predict one or more security actions based on one or more detected security events and implements the predicted actions on the endpoints.

[0020] B. Working Example The embodiments described below enable the use of AI data models to predict security actions directly from detected security events.

[0021] A security issue may be the result of insufficient measures applied to an endpoint and may trigger a series of security events on the endpoint. For example, ransomware affecting an endpoint may result in one or more of the following security events: a malicious application being downloaded to the endpoint; a malicious application running in the background; a malicious application running at irregular times compared to normal endpoint uptime; a malicious application using a lot of processor, memory, or input / output resources; or a malicious application accessing sensitive data files.

[0022] The methods used in the disclosed solutions are fact-based. If a particular security problem leads to a common or nearly common set of security events, and if a majority of administrative users apply the same specific security response when the specific security events occur, then this specific security response is considered the best practice for resolving this particular security problem. The specific security response involves applying one or more security actions to the endpoint.

[0023] Examples of security events are shown in the second column of Table 1. Each specific security event is shown as belonging to a specific type of security event, which can be called a general security event. However, generalization is not necessary to build a data model. Analyzing specific events rather than types of events or general events can make the data model clearer and more precise.

[0024] [Table 1]

[0025] Security actions can have different levels of impact on an endpoint, and generally, security actions with greater impact are responses required for correspondingly greater threats. Some example security actions, along with their impact levels, are shown in Table 2. However, it is not necessary to determine the level of threat, nor the level of action required to respond to the threat. This is because security events are directly labeled with actions in the data model, and security actions can be predicted directly from security events.

[0026] [Table 2]

[0027] Whether something represents anomalous behavior is based on a comparison of the endpoint's current behavior to its normal behavior. Normal behavior is defined based on normal use of the device over time, or on use over a period of time when the device is known to be secure, or on use of similar devices by similar users. Anomalous behavior is determined by analyzing current behavior using normal behavior as a baseline.

[0028] Machine learning is the technology chosen to build a data model that establishes relationships between security events and security actions. Specifically, the method described in this solution can be treated as a multi-label classification case. The input to the data model is security events that occur on the endpoint. The output of the data model is security actions, not the determination (identification) of a security issue. Therefore, the response to a threat on the endpoint can be determined in fewer steps than if the security issue were first determined and then assessed by the threat's risk level.

[0029] 1 is an overview of the interactions between various entities that enable predicting security actions directly from detected security events. The disclosed solution takes input from or occurring on an endpoint 10, such as a security event. The solution also receives input from a user 12, such as an administrative user or computer security officer, who makes a decision about what security action to apply to the endpoint in response to a detected security event occurring on the endpoint.

[0030] Security events occurring at endpoints 10 and security actions applied to the endpoints by users 12 are fed to a machine learning (ML) application 14 on a server, for example a server on the cloud, to build an action prediction model 16. Action prediction model 16 is a data model that predicts security actions in response to security events.

[0031] The use case diagram in Figure 2 illustrates the steps and features that need to be developed to apply the solution. First, in step 20, data representing security events is collected from multiple endpoints. Next, in step 22, an administrative user responsible for the endpoints analyzes the security events. In step 24, the administrative user applies security actions to the endpoints as a result of the analysis and in response to the security events. In step 25, the security actions are collected and associated with the corresponding security events. Then, in step 26, machine learning is used to build an action prediction model using the collected security events and security actions. The action prediction model can be created and trained, for example, under the guidance of a data scientist. After the action prediction model is trained, it can be applied to protect endpoints in step 28.

[0032] The action prediction model 16, which is a multi-label classification data model, can use, for example, the security event definitions listed in Table 3. An event scenario can include one or more security events detected within a given time period and can be described by their attributes. The attributes and their IDs can be used both in the machine learning process and during operation of the action prediction model 16 after it has been trained. The examples of attributes given are non-limiting, and other attributes may be included in the list. The listed attributes may also be modified. For example, the time period may be set to less than one day or more than one day, depending on the particular implementation. Different attributes may have different time periods. Some attributes may be combined into a single attribute, for example, using an OR logical conjunction. Other attributes may be split into multiple individual attributes, such as for anomalous resource usage.

[0033] [Table 3]

[0034] Examples of labels that a machine learning application can use to label a security event scenario or set of security events include those defined in Table 4. These labels represent the security action that would be taken if predicted by the action prediction model. Again, these are non-limiting examples, and more can be added. These labels are also used in the action prediction model when it is used to protect the endpoint. The labels associated with a common subset of security events may differ depending on other security events or attributes. For example, an event detected while a user is not logged on is considered more serious than the same security event if it occurs while a user is logged on.

[0035] [Table 4]

[0036] Sample data used by the machine learning application to train the data model is shown in Table 5. Each row represents the detection of one or more security events. Therefore, each row can be said to represent a security event scenario. Each scenario can represent a specific time period during which one or more security events are detected. Some rows show that an individual security event, or attribute, was detected 0, 1, or 3 times.

[0037] [Table 5]

[0038] In a fully developed case, it is necessary to ensure that an appropriate set of security events is captured and used to train the action prediction model for every security issue or type of security issue, but this is not necessarily required. One option, if the action prediction model is not sufficiently mature, is to initially not utilize the action prediction model 16 on endpoints to predict security actions. Instead, security events can be collected from the endpoints and sent to the server side for analysis and selection of the optimal security action or actions. After the action prediction model 16 is trained, it can be deployed on the endpoints and used to predict security actions. However, in this initial mode, rather than automatically applying security actions to the endpoints, the action prediction model can suggest to an administrative user which security actions should be applied to the endpoint. This is a semi-automatic solution, requiring administrative verification of the predicted actions before implementation.

[0039] 3 is an example of system components including an endpoint 30 and a server 50. The action prediction model 16 resides in the server 50, and optionally, a copy or another version 16A of the action prediction model may reside in the endpoint 30.

[0040] Endpoint 30 has an endpoint-side application 36 that monitors and collects security events and reports the events to a server 50 on the server side of the system. Endpoint 30 also has a set of one or more endpoint-side applications 38 for applying security actions determined by action prediction model 16 or 16A when a security event occurs.

[0041] The endpoint 30 and other similar endpoints 40, 42 are connected to a server 50 via a network 44, such as the Internet. The server 50 has a set of server-side applications 56 for receiving and processing events from the endpoints 30, 40, 42. The server 50 also hosts a machine learning application 14 that processes security event data and security action data, analyzes security events and corresponding security actions taken both autonomously by the endpoints and by an administrator, and uses machine learning to build an action prediction model 16.

[0042] Also present is an administrator's computer 60 connected to the endpoints 30, 40, 42 via the network 44. The administrator's computer 60 has a set of applications that display security events and security actions and enable the administrator to analyze security events and select security actions that are or should be applied to the endpoints 30, 40, 42. For example, a display screen 66 of the administrator's computer 60 may display a user interface with a list of event scenarios (or incidents) 70, where each scenario may result from a different security issue, or the same security issue may cause multiple similar or dissimilar scenarios. The user interface also displays a set of one or more security events 72 that make up each scenario, a set of one or more predicted security actions 74 for each scenario, and a list of other optional security actions 76 that may help resolve the security issues. The predicted security actions 74 and other security actions 76 may be individually deleted by the administrator, or additional security actions may be added to the list of other security actions. When the administrator is ready to implement security actions 74, 76 for a given security event scenario, they can check the selection box 80 in the selection column 78 and click the "Implement" button 82. As expected, there are many other different forms the user interface can take to allow the administrator to view predicted actions, execute predicted actions, and modify the list of security actions that will be applied to the endpoint.

[0043] 4 is a flowchart of an exemplary process of the system in use. Initially, security events are detected in step 86 and corresponding security actions are applied in step 88, for example, by administrative user 90. These are then analyzed in step 92 by another administrative user 91 (or the same administrative user 90). In step 94, the results of analysis 92 are used to build an action prediction model in step 94. The results of analysis 92 may include, for example, detected events 86 and applied actions 88 in action prediction model 94. These initial steps are repeated multiple times to train data model 94.

[0044] Once data model 94 is trained, security events detected in step 86 are passed directly to data model 94, bypassing analysis step 92. Data model 94 then predicts what security actions to take in step 96. The security actions may be applied directly under the control of data model 94 in step 88, or may first be verified by administrative user 91 in step 98 before being applied.

[0045] Predicted actions performed continuously by running applications on individual endpoints can be used to continuously learn, evolve, and enhance the action prediction model. Similarly, actions performed by administrators can be used to continuously learn, evolve, and enhance the action prediction model. For example, whenever a new security issue arises, an administrator may be given the opportunity to either approve the security actions predicted by the action prediction model or to suggest a more appropriate set of security actions.

[0046] When a new security issue arises that causes a previously unseen security event pattern or scenario, the predicted actions created by the action prediction model and applied in real time are expected to be near-optimal, though possibly suboptimal. If the automated security actions taken in response to one or more sets of new security events are suboptimal, an administrator likely analyzes the issue and selects an appropriate action via a validation step 98 before a centralized security provider determines the most appropriate action. This is because multiple different administrators around the world may be faced with the same entirely new problem, while existing security providers may have limited staff, time, and workloads and may not be able to address new issues quickly. If a predicted action is reinforced by multiple administrators or modified and then invoked by multiple administrators, it may effectively become the optimal action.

[0047] If the predicted security action is optimal in step 96, it is likely to be verified by one of the administrators in step 98 before being taken by the centralized security provider, for the same reasons as above. One reason for using a machine learning data model rather than a rules engine is that the predicted response is likely to be closer to a human response than a response determined by a rules engine. The model evolves periodically as new security issues arise, so that over time it gains the ability to provide an optimal response for each new security issue.

[0048] Referring to Figure 5, an exemplary action prediction model is shown. The data model includes groups of security events 100, 102, 104, each labeled with one or more security action labels 110, 112, 114, and 116. The groups of security events can be thought of as security event scenarios. For example, Event Group 1 (100) is labeled with security actions 1 and 2 (110, 112). Event Group 2 (102) is labeled with security actions 1, 2, and M (110, 112, 116). Event Group N (104) is labeled with security action 3 (114).

[0049] Event groups 120 and 122 similar to event group 1 (100) are also labeled with the same action as event group 1. Event groups 100, 120, and 122 can be said to belong to security event pattern 1 (124). Event groups 130 and 132 similar to event group 2 (102) are labeled with the same action as event group 2. Event groups 102, 130, and 132 can be said to belong to security event pattern 2 (134). Event groups 140 and 142 similar to event group N (104) are labeled with the same action as event group N. Event groups 104, 140, and 142 can be said to belong to security event pattern N (144). Depending on the data model, the differences between event groups within the same pattern may be wider, narrower, or even nonexistent than those within other patterns. It is noteworthy that the action prediction model does not explicitly output a risk level or identify specific security issues. Instead, it jumps directly to predicting the necessary security actions.

[0050] As a result of the above, a new set of events that is not identical to any previous group of events will be deemed by the model to fall within a known pattern and will therefore be labeled with the action corresponding to the pattern. Alternatively, the new set of events may be determined to be closer to one pattern than any other and will therefore be labeled with the action corresponding to that closest pattern.

[0051] C. Variations By generalizing security events as in Table 1, the data model becomes simpler because it eliminates the need to identify each specific security event that is similar to each other.

[0052] Other labels can be applied to events beyond those listed above. For example, labels may include tracking the device, taking a photo, recording a video, capturing keystrokes, quarantining a file, etc. These labels correspond to security actions taken by an endpoint to protect and recover data when a security event indicates that data has been stolen.

[0053] Other labels may also include quantities in their definitions, for example, abnormal internet usage may be defined as exceeding a threshold number of gigabytes.

[0054] The sequence in which two or more security events occur can be defined as separate security events to which attributes can be attributed. The time period over which security events are captured can be changed in other embodiments and can be variable. The time interval between two security events can itself be a security event to which attributes can be attributed.

[0055] Each set of detected security events may have a confidence level attached to it, which indicates how certain the data model is that the set of detected security events is within a known pattern of events. If the confidence level is high, it can be assumed that the set of detected events matches a known pattern of events with well-defined labels (i.e., security actions) and has stood the test of time. If the confidence level is high, the set of actions can be implemented automatically, without necessarily alerting an administrator.

[0056] However, if the confidence level is low, the data model is uncertain as to which of at least two patterns the detected set of security actions belongs to. In this case, an administrator may be alerted and asked to make a decision. In another embodiment, the data model can default to selecting and applying the most secure set of security actions. Alternatively, the data model can automatically invoke all predicted actions if the set of security events could fall within two or more known patterns. This means that the data model is operating on the more cautious side. If the administrator is asked to respond but does not respond within a set time, the data model can automatically invoke all predicted actions.

[0057] An administrator can set rules that instruct the data model on how to behave if the confidence level falls below a threshold. An administrator can set the threshold level. For example, the threshold can be set relatively high during the initial deployment of the data model, and then set to a relatively lower level after the data model is mature and the administrator has gained confidence in it. An administrator can alternatively set a percentage that defines the number of predicted security actions for which they will receive notifications during a set period of time.

[0058] After a security event is processed, when a data model is used to generate a prediction for each action, a score is created for each action. The score represents the probability of each action's suitability, and its value can range, for example, from 0 to 1. A confidence level can be defined from this score. When multiple actions are predicted, each action has its own score, and the overall confidence level for the set of actions can be the average of the individual scores. A threshold can then be based on the overall confidence level.

[0059] If the pattern of a detected security event differs significantly from any known pattern, the data model may default to shutting down the endpoint and notifying an administrator.

[0060] Other administrators may be notified of predicted and performed security actions depending on which administrator is on duty.

[0061] The data model can be trained or enriched using simulated events, replicas of past events, as well as actual, current, or real-time events.

[0062] The system can automatically correlate patterns of similar security events detected across multiple endpoints and alert administrators that multiple endpoints are being affected in a similar way.

[0063] Applications can include, for example, bots (automated applications) for communicating with administrators, learning which security actions the administrator applies, and learning how the administrator verifies a predicted set of security actions.

[0064] Some embodiments may include assigning a score to one or more predicted actions in response to the set of detected events. The score may be related to how often an administrator uses the action. Some embodiments may incorporate a rules engine that determines what to do based on the score.

[0065] Events may be processed differently, ie some may be processed in real time and some may not.

[0066] Where a processor is described, the processor may include two or more component processors. The computer-readable memory may be divided into multiple component memories of the same or different types. Steps in the flowcharts and other figures may be performed in a different order, steps may be omitted, or additional steps may be included, without departing from the invention.

[0067] This description is made for the purpose of illustrating the general principles of the subject matter and is not to be construed in a limiting sense, as the subject matter may find utility in a variety of implementations without departing from the scope of the disclosure made, as will be apparent to those skilled in the art from an understanding of the principles underlying the subject matter.

Claims

1. 1. A method for protecting an electronic device, comprising: generating a multi-label classification data model including a plurality of security event groups labeled with security actions, each group including a security event and representing a security event scenario; detecting one or more security events indicative of a security event scenario; using the multi-label classification data model to predict one or more security actions based on the one or more security events; performing, at the electronic device, the predicted one or more security actions; assigning a confidence level to the detected security event; automatically proceeding to said executing step if said confidence level is above a threshold; If the trust level is below the threshold, notifying an administrator and proceeding with the performing step as directed by the administrator.

2. 10. The method of claim 1, wherein the performing step is performed in real time.

3. 10. The method of claim 1, wherein the one or more security events occur within a fixed time period.

4. The method of claim 1 , wherein at least one of the security events includes a plurality of configuration security events.

5. The method of claim 1 , comprising training the multi-label classification data model using security events and security actions from a plurality of electronic devices.

6. The method of claim 1 , comprising enhancing the multi-label classification data model with security events and security actions from multiple electronic devices.

7. A processor; a computer-readable memory storing a plurality of computer-readable instructions which, when executed by said processor, cause said processor to perform the steps of the method defined in any one of claims 1 to 6; A system comprising:

Images