HK40049002B - Systems and methods for behavioral threat detection - Google Patents

Description

Systems and methods for behavioral threat detection

Background Technology

This invention relates to computer security systems and methods, and more particularly, to systems and methods for detecting malware and/or intrusions into computer systems and/or communication networks.

In recent years, computer and cybersecurity have become increasingly important for both individuals and companies. The rapid development of electronic communication technologies, the increasing reliance on software in daily activities, and the emergence of the Internet of Things have made companies and individuals vulnerable to privacy breaches and data theft.

Skilled attackers can use various techniques (such as installing backdoors on company computers with malware) to infiltrate a company network. They can then obtain, modify, or destroy sensitive information. Other exemplary attacks include disabling or otherwise incapacitating physical security systems (such as burglar alarms), installing spyware, and interfering with automated systems that control the manufacture or distribution of goods and services (such as power grids).

Software running on a computer system can be used to automatically detect and/or prevent unauthorized intrusions and other malicious activities. This software, often called an Intrusion Detection System (IDS), monitors for anomalous events or policy violations in network and/or computer activity. A typical IDS logs information related to observed events, notifies users or network administrators, and generates reports. Some IDS can further prevent intruders from carrying out malicious activities, for example, by changing security settings in response to an intrusion detection (e.g., reconfiguring the firewall).

However, with the increasing delocalization of software services and the growing volume of data flowing across information networks, it has become increasingly impractical for security software to sift through this vast amount of information to find indicators of malicious activity. Therefore, the development of more robust and scalable intrusion detection systems and methods has generated considerable interest.

Summary of the Invention

According to one aspect, a computer system includes at least one hardware processor configured to: in response to receiving a cluster membership indicator indicating a group of multiple client systems into multiple client clusters, select a client cluster from the multiple client clusters, the selected client cluster comprising the multiple client systems. The at least one hardware processor is further configured to: in response to selecting the client cluster, select a training corpus of events from an event set based on whether the selected event has occurred on a member of the selected client cluster. The at least one hardware processor is further configured to: in response to selecting the training corpus of events, train a behavioral model based on the training corpus of events to encode collective behavior of the members of the selected client cluster, the behavioral model having a set of adjustable parameters. The at least one hardware processor is further configured to: in response to training the behavioral model, emit a set of values of the adjustable parameters to an anomaly detector configured to determine whether a target event occurring on a target client system indicates a computer security threat. The behavioral model is configured to input the selected events of an event sequence and, in response, determine a prediction indicator indicating the probability that another event in the event sequence has the selected event type. The event sequence includes multiple events from the training corpus, which are ordered according to the occurrence time of each event. Training the behavior model includes adjusting the set of configurable parameters based on the prediction indicator.

According to another aspect, a computer implementation method includes: employing at least one hardware processor of a computer system, in response to receiving a cluster membership indicator indicating a grouping of multiple client systems into multiple client clusters, selecting a client cluster from the multiple client clusters, the selected client cluster comprising multiple client systems. The method further includes: in response to selecting the client cluster, employing at least one hardware processor of the computer system to select a training corpus of events from an event set based on whether a selected event has occurred on a member of the selected client cluster. The method further includes: in response to selecting the training corpus of events, employing at least one hardware processor of the computer system to train a behavioral model based on the training corpus of events to encode collective behavior of members of the selected client cluster, the behavioral model having a set of adjustable parameters. The method further includes: in response to training the behavioral model, employing at least one hardware processor of the computer system to emit a set of values of the adjustable parameters to an anomaly detector, the anomaly detector being configured to determine whether a target event occurring on a target client system indicates a computer security threat. The behavioral model is configured to input the selected events of an event sequence and, in response, determine a predictive indicator indicating the probability that another event in the event sequence has the selected event type. The event sequence includes multiple events from the training corpus, which are ordered according to the occurrence time of each event. Training the behavior model includes adjusting the set of configurable parameters based on the prediction indicator.

According to another aspect, a non-transitory computer-readable medium storing instructions, which, when executed by at least one hardware processor of a computer system, cause the computer system to: in response to receiving a cluster membership indicator indicating a grouping of multiple client systems into multiple client clusters, select a client cluster from the multiple client clusters, the selected client cluster comprising multiple client systems. The instructions further cause the computer system, in response to selecting the client cluster, to select a training corpus of events from an event set based on whether an event has occurred on a member of the selected client cluster. The instructions further cause the computer system, in response to selecting the training corpus of events, to train a behavioral model based on the training corpus of events to encode the collective behavior of the members of the selected client cluster, the behavioral model having a set of adjustable parameters. The instructions further cause the computer system, in response to training the behavioral model, to emit a set of values of the adjustable parameters to an anomaly detector configured to determine whether a target event occurring on a target client system indicates a computer security threat. The behavioral model is configured to take the selected events of an event sequence as input and, in response, determine a prediction indicator indicating the probability that another event in the event sequence has the selected event type. The event sequence includes multiple events from the training corpus, which are ordered according to the occurrence time of each event. Training the behavior model includes adjusting the set of configurable parameters based on the prediction indicator.

Attached Figure Description

The foregoing aspects and advantages of the invention will be better understood after reading the following detailed description and referring to the drawings, wherein:

Figure 1 illustrates several exemplary interconnected client systems according to some embodiments of the present invention, wherein a security server acts as an intrusion detection system.

Figure 2 illustrates an exemplary data exchange implemented according to some embodiments of the present invention to protect a client system.

Figure 3-A illustrates an exemplary hardware configuration of a client system according to some embodiments of the present invention.

Figure 3-B illustrates an exemplary hardware configuration of a security server according to some embodiments of the present invention.

Figure 4 illustrates exemplary software components executed on a protected client system according to some embodiments of the present invention.

Figure 5 illustrates an exemplary software architecture of a security server according to some embodiments of the present invention.

Figure 6 illustrates exemplary operation of the analysis engine according to some embodiments of the present invention.

Figure 7 illustrates an exemplary sequence of steps implemented by an analysis engine according to some embodiments of the present invention.

Figure 8-A illustrates exemplary training of an event encoder according to some embodiments of the present invention.

Figure 8-B illustrates alternative exemplary training of an event encoder according to some embodiments of the present invention.

Figure 9 shows an exemplary sequence of steps performed to train the event decoder configured as shown in Figure 8-A.

Figure 10 illustrates an exemplary event embedding space and a set of exemplary event clusters according to some embodiments of the present invention.

Figure 11 illustrates an exemplary client configuration file space and a group of clients according to some embodiments of the present invention.

Figure 12 shows an exemplary event configuration file of a client system according to some embodiments of the present invention.

Figure 13 illustrates exemplary components and operation of an anomaly detector according to some embodiments of the present invention.

Figure 14 illustrates an exemplary sequence of steps performed by an anomaly detector during training, according to some embodiments of the present invention.

Figure 15 illustrates exemplary components of a behavioral model for forming an anomaly detector according to some embodiments of the present invention.

Figure 16 illustrates an exemplary sequence of steps performed by a trained anomaly detector according to some embodiments of the present invention.

Figure 17-A shows the results of experiments that included detecting real-world computer security threats using some embodiments of the present invention.

Figure 17-B shows other experimental results of detecting real-world computer security threats using some of the embodiments.

Detailed Implementation

In the following description, it should be understood that all referenced connections between structures may be direct or indirect connections via intermediate structures. A group of elements comprises one or more elements. It should be understood that any reference to an element refers to at least one element. Multiple elements comprise at least two elements. Unless otherwise specified, any use of "or" means non-exclusive or. Unless otherwise required, any method steps described need not necessarily be performed in the specific order stated. A first element derived from a second element (e.g., data) encompasses the first element equal to the second element, and also encompasses the first element generated by processing the second element and optional other data. Making a determination or decision based on parameters encompasses making a determination or decision based on parameters and optionally other data. Unless otherwise specified, some quantity/data indicators may be the quantity/data itself, or indicators different from the quantity/data itself. A computer program is a sequence of processor instructions that performs a task. The computer program described in some embodiments of the invention may be a separate software entity or sub-entity (e.g., subroutine, library) of other computer programs. Unless otherwise specified, computer security encompasses protecting devices and data from unauthorized access, modification, and/or destruction. Computer-readable media encompasses non-transitory media (e.g., magnetic, optical, and semiconductor storage media (e.g., hard disk drives, optical discs, flash memory, DRAM)) and communication links (e.g., conductive cables and fiber optic links). According to some embodiments, the present invention particularly provides a computer system comprising hardware (e.g., one or more processors) programmed to perform the methods described herein, and computer-readable media encoded with instructions for performing the methods described herein.

The following description illustrates embodiments of the invention by way of example and not necessarily by way of limitation.

Figure 1 illustrates a set of exemplary client systems 10a to h protected from computer security threats according to some embodiments of the present invention. Client systems 10a to h generally represent any electronic device having a processor, memory, and a communication interface. Exemplary client systems 10a to h include personal computers, laptop computers, tablet computers, mobile telecommunications devices (e.g., smartphones), media players, TVs, game consoles, home appliances (e.g., refrigerators, smart heating and/or lighting systems), and wearable devices (e.g., smartwatches, fitness equipment), etc. Client systems 10a to h can execute various software, such as document processing, games, electronic messaging, and social media applications. Some clients can exchange information with a remote content server 17, such as for internet browsing.

The client systems described are connected via local networks 12a to 12b and further connected to an extended network 14, such as a wide area network (WAN) or the Internet. In one example, client systems 10a to 10d represent home electronic devices interconnected via home network 12a. Meanwhile, client systems 10e to 10g may identify personal computers and/or enterprise mainframes within an office building. Next, local networks 12a to 12b may represent segments of an enterprise network (e.g., a local area network - LAN).

The router includes electronic devices that enable communication between multiple client systems and/or access to the extended network 14 for each client. In the example of Figure 1, routers 15a to 15b interconnect clients on local networks 12a to 12b and/or enable clients 10a to 10g to access the Internet. Routers 15a to 15b may act as gateways between local networks 12a to 12b and the extended network 14, and may further provide a set of network services to client systems 10a to 10g. Such services include, for example, assigning network configuration parameters to client systems 10a to 10g (e.g., assigning network addresses via Dynamic Host Configuration Protocol - DHCP) and routing communication through a series of network nodes. Some client systems (e.g., exemplary client system 10h) may be directly connected to the extended network 14, for example, via a telecommunications repeater.

Figure 1 further illustrates a security server 16 connected to the extended network 14. Server 16 generally represents a group of communicationally coupled computer systems that may or may not be physically close to each other. Server 16 protects client systems 10a to h from computer security threats, such as malware and intrusions. In some embodiments, this protection includes the security server 16 detecting suspicious activity occurring at the client systems, such as actions by an attacker controlling the respective client systems.

An exemplary data exchange between the security server 16 and the client system 10 is illustrated in Figure 2. The client system 10 may represent any of the clients 10a to h in Figure 1. In some embodiments, the server 16 is configured to receive an event indicator 20a from the client system 10, which indicates that a specific type of event occurred during the execution of software on the client 10. Instances of such events include process/thread initiation (e.g., user-initiated application, parent process creating child process, etc.), attempts to access the input device of the corresponding client system (e.g., camera, microphone), attempts to access local or remote network resources (e.g., Hypertext Transfer Protocol (HTTP) requests to access a specific URL, attempts to access a document repository via a local network), requests specified using a particular Uniform Resource Identifier (URI) scheme (e.g., mailto: or ftp: requests), execution of specific processor instructions (e.g., system calls), attempts to load libraries (e.g., dynamic link libraries - DLLs), attempts to create new disk files, attempts to read from or write to a specific location on the disk (e.g., attempts to overwrite existing files, attempts to open a specific folder or document), and attempts to send electronic messages (e.g., email, short message service - SMS, etc.). In some embodiments, inactive periods, i.e., time intervals between events and/or time intervals when the corresponding client system is idle, not registering user activity, or only performing internal system tasks, are also considered events and can be reported to the security server via event indicators. Such inactivity periods can be further differentiated into short intervals (e.g., approximately a few seconds) and long intervals (e.g., approximately a few minutes to several hours). Detected events may or may not indicate malicious intent; some events may be considered malicious when they occur alongside other events and/or when they occur in a specific sequence. Other events may be considered malicious when they occur at a specific time of day or at an unusual frequency, such as continuously reading a specific disk folder 1000 times within a few-second interval.

Each event indicator 20a may include, in particular, an indicator of the type of the corresponding event and a timestamp indicating when the corresponding event occurred. The event indicator 20a may further include an identifier of the corresponding client system (client ID) and/or an indicator of the user operating the corresponding client system (user ID). For example, when the event being communicated includes process creation, the user indicator may indicate the owner of the parent process. The event indicator 20a may encode other parameters such as the process name, file system location/path to the initiating process, network address (e.g., Internet Protocol-IP address), Uniform Resource Locator (URL) of the HTTP request, etc.

In some embodiments, server 16 may also collect information from routers 15a to 15b, as illustrated by event indicator 20b in FIG2. Such event indicators may include, for example, indicators of network events, such as network access requests issued by client systems connected to the respective routers/gateways. For example, event indicator 20b may include originating IP address, destination IP address, timestamp, and payload size. In some embodiments, event indicator 20b includes client event data (e.g., network traffic, network logs, etc.) aggregated by the respective router according to various data processing protocols.

Security server 16 maintains a set of user behavior models representing the baseline, normal, and/or legal modes of operation of subsets of client systems 10a to h. Such behavior models are referred to herein as client profiles. The parameters of such behavior models are generally represented as the profile database 19 in Figure 1 and may include the output of event and/or client clustering algorithms, as shown in detail below. In an exemplary embodiment where the profile is represented by a cluster of clients or events, the parameters of the respective profile may include the coordinates of the cluster centroid and a set of numbers indicating the range of the respective cluster along each axis. Other profile parameters may include, in particular, a measure of the eccentricity of the respective cluster, the average distance between cluster members and the cluster centroid, etc. Client profiles can be automatically generated using supervised or unsupervised learning methods and algorithms, as shown below.

Client profiles can capture the behavior of a single user or collectively capture the behavior of multiple users. To illustrate, a smartphone is primarily used by a single user, so a client profile attached to that smartphone essentially captures the baseline behavior of its primary user. In contrast, computers belonging to a university computer lab can be used by many different students; a client profile attached to one of these machines collectively represents the baseline behavior of all the respective students. A client profile can be attached to a single client system/physical machine (e.g., a smartphone, a laptop computer). In some embodiments, a client profile can collectively represent multiple physical machines. In one such example, client systems 10a to d in Figure 1 can be collectively represented by a single client profile capturing the normal or baseline behavior of members of a particular family. In another example, one client profile represents all the computers in an enterprise's accounting department, while another client profile represents all the computers used by the corresponding enterprise's research and development team. In a cloud computing environment, such as a Virtual Desktop Infrastructure (VDI) environment where physical machines can run multiple virtual machines for various distributed users, a client profile can be attached to multiple virtual machines running on the respective physical machines.

In some embodiments, a single user may be represented by multiple distinct client profiles. For example, the same person may have one client profile/baseline behavior at work and distinct client profiles/baseline behaviors at home. Other instances of client profiles may be associated with users of a specific age group (e.g., teenagers), specific personal interests (e.g., gaming), specific professions (e.g., engineers, artists, educators), etc. In yet another exemplary embodiment, distinct client profiles may correspond to distinct computer activities, such as using different computer programs: browsing the Internet, using social media, performing office work, etc. Other exemplary client profiles may be attached to distinct device types (e.g., smartphones versus PCs). Common profiles may be envisioned based on more complex criteria, such as a client profile instructing an engineer on typical/baseline ways of browsing the Internet from company X. Yet another exemplary profile may instruct a young person on typical ways of using a tablet computer.

A subset of event indicators 20a to 20b can be collected to form an event corpus for further deriving client profiles, as shown in detail below. Another subset of event indicators can be used to detect security threats. For example, in response to receiving event indicators 20a to 20b, security server 16 can determine whether the event conveyed by the corresponding event indicator is consistent with the client profile selected according to the corresponding client indicator. In other words, security server 16 can determine whether the corresponding event matches a pattern of normal/baseline behavior encoded in the corresponding client profile. When there is a mismatch, the corresponding event can indicate suspicious activity, in which case some embodiments may take protective actions, such as sending security warnings 22a to 22b to the corresponding client system and/or the administrator of the corresponding client system. In another instance of protective action, some embodiments instruct routers belonging to the same local network as the suspicious client system to block communication to and/or from the corresponding suspicious client system. The processing of client profiles and event indicators by security server 16 is further described below.

Figure 3-A illustrates an exemplary hardware configuration of a client system according to some embodiments of the present invention. Client system 10 may represent any of the client systems 10a to h in Figure 1. For clarity, the illustrated client system is a computer system. Other client systems (e.g., mobile phones, tablet computers, and wearable devices) may have slightly different configurations. Processor 32 includes physical means (e.g., a microprocessor, a multi-core integrated circuit formed on a semiconductor substrate) configured to perform computational and/or logical operations using a set of signals and/or data. Such signals or data may be encoded in the form of processor instructions (e.g., machine code) and delivered to processor 32. Memory unit 34 may include volatile computer-readable media (e.g., dynamic random access memory - DRAM) that stores data/signals accessed or generated by processor 32 during the implementation of operations.

Input device 36 may include a computer keyboard, mouse, and microphone, and a corresponding hardware interface and/or adapter that allows the user to input data and/or instructions into client system 10. Output device 38 may include a display device, such as a monitor and speakers, and a hardware interface/adapter, such as a graphics card, that enables the corresponding client system to transmit data to the user. In some embodiments, input and output devices 36 to 38 share common hardware components (e.g., a touchscreen). Storage device 42 includes a computer-readable medium that implements non-volatile storage, retrieval, and writing of software instructions and/or data. Exemplary storage devices include disk and optical disk and flash memory devices, and also include removable media, such as CDs and/or DVDs and drives. Network adapter 44 enables client system 10 to connect to electronic communication networks (e.g., networks 12 and 14 in FIG. 1) and/or other devices/computer systems.

Controller hub 40 generally represents multiple systems, peripherals, and/or chipset buses, and/or all other circuitry enabling communication between processor 32 and the remaining hardware components of client system 10. For example, controller hub 40 may include memory controllers, input/output (I/O) controllers, and interrupt controllers. Depending on the hardware manufacturer, some of these controllers may be incorporated into a single integrated circuit and/or integrated with the processor. In another example, controller hub 40 may include a northbridge connecting processor 32 to memory 34 and/or a southbridge connecting processor 32 to devices 36, 38, 42, and 44.

Figure 3-B illustrates an exemplary hardware configuration of a security server 16 according to some embodiments of the present invention. The server 16 includes at least one hardware processor 132 (e.g., a microprocessor, a multi-core integrated circuit), physical memory 134 (e.g., DRAM), server storage device 142, and a set of server network adapters 144. The server processor 132 may include a central processing unit (CPU) and/or a graphics processing unit (GPU) array. The adapters 144 may include a network card and other communication interfaces enabling the security server 16 to connect to a communication network 14. The server storage device 142 may store data, such as event indicators and/or client configuration file parameters. In some embodiments, the server 16 further includes input and output devices, whose functions may be similar to the input/output devices 36 and 38 of the client system 10, respectively.

Figure 4 illustrates exemplary software components executed on a client system 10 according to some embodiments of the present invention. This software may include an operating system (OS) 46 that provides an interface between the hardware of the client system 10 and other computer programs (e.g., user applications 48 executed on the respective client system). The exemplary operating system particularly includes, and the user application 48 generally represents any application, such as word processing, image processing, spreadsheets, calendars, online games, social media, web browsers, and electronic communication applications. In some embodiments, a security application 50 is configured to protect the client system 10 from computer security threats, such as malware and intrusions. Among other functions, the security application 50 is particularly configured to send event indicators to a security server 16 and/or receive security alerts. In some embodiments, the application 50 further includes an event collector 52 and a network filter 53. Some functionality of the network filter 53 may be implemented directly in the hardware. When the client system 10 operates the hardware virtualization platform, where the OS 46 and application 48 are executed within a virtual machine (e.g., in a cloud computing environment), the event collector 52 and/or network filter 53 can operate outside the respective virtual machine, for example at the level of the hypervisor exposing the respective virtual machine, using a technique known in the field as introspection.

Event collector 52 is configured to detect various events occurring during software execution by client system 10. Some embodiments may timestamp each detected event to record the time of its occurrence. Detected events may be machine- and/or operating system-specific. Exemplary events include, in particular, process initiation, process termination, child process creation, access requests to peripheral devices (e.g., hard drives, network adapters), and commands typed by the user into a command-line interface. Such hardware and/or software events can be detected using any method known in the field of computer security, such as intercepting specific operating system functions, detecting system calls, employing file system microfilters, or altering memory access permissions to detect intent to execute code from a specific memory address.

Some embodiments use system logging tools built into OS 46 (such as Syslog) to monitor hardware and/or software events. Such tools generate a list of event descriptors containing a timestamp for each event, a numeric code identifying the event type, an indicator of the type of process or application that generated the event, and other event parameters. Security application 50 can extract this information from the relevant system log to formulate event indicators.

The following is a sample syslog entry:

<30>Feb 8 21:36:51 dtm charon: 12[IKE]establishing CHILD_SA dtmhq5{5}

<30>Feb 8 21:36:51 dtm charon: 12[IKE]establishing CHILD_SA dtmhq5{5}

<187>Feb B 21:37:56 example.domain.biz dhcpd:DHCPDISCOVER from Oc:14:7b:11:14:64 via ethl:network ethl:no free leases

Network filter 53 detects a set of network events occurring during electronic communications between client system 10 and other parties via networks 12 to 14. Exemplary events detected by network filter 53 include events that form part of establishing a connection between client system 10 and another network entity (e.g., requesting a network address, transmitting a network address, handshake events, etc.), events that configure encrypted connections (Secure Sockets Layer - SSL, Virtual Private Network - VPN), transmitting data, and receiving data. In some embodiments, network filter 53 collects metadata from intercepted network traffic. Such metadata may include, for example, the originating network address (e.g., Internet Protocol - IP address), the destination address, the timestamp of the data packet, an indicator of the communication protocol type, and the size of the data packet. Other exemplary metadata may include the type of Hypertext Transfer Protocol (HTTP) user agent transmitting the corresponding communication/data packet. Some embodiments organize the communication metadata into a specialized data structure, referred to in the art as network traffic (e.g., from Cisco Systems, Inc.). Table 1 shows examples of communication metadata represented as traffic according to some embodiments of the present invention.

Table 1

In some embodiments, the security application 50 generates event indicators based on hardware, software, and/or network events detected by the collector 52 and the network filter 53. The application 50 may further manage communication with the security server 16 to transmit event indicators and/or receive security notifications, etc.

In alternative embodiments, instead of processing network communications at the client end as shown above, network filter 53 and/or router 15 may be configured to reroute at least a portion of incoming and/or outgoing electronic communications from client system 10 to security server 16. For example, network configuration parameters of client system 10 may be set to designate server 16 as the default network gateway. Subsequently, some embodiments employ security server 16 to extract event indicators from the corresponding rerouted traffic.

Figure 5 illustrates exemplary software running on a security server 16 according to some embodiments of the present invention. The illustrated software includes an analysis engine 60 and an anomaly detector 62 further connected to an alert manager 64. Those skilled in the art will appreciate that not all illustrated components need to run on the same machine/processor; for example, the analysis engine 60 may run on a dedicated processor cluster, while the example of the anomaly detector 62 may run on other machines/processors.

In some embodiments, the analysis engine 60 is configured to analyze events occurring on a set of client systems (e.g., a subset of clients 10a to h in Figure 1) and construct multiple client profiles representing baseline, normal, and/or legitimate modes of operation for the respective client systems. A subset of event indicators 20a to b received from the clients can be used to assemble a training event corpus, labeled as corpus 18 in Figures 1, 5, and 6. Profiles are then determined based on the event corpus 18. Determining client profiles may involve, in particular, representing events in an abstract multidimensional event space and implementing data clustering processes, as shown in more detail below. The constructed profiles can then be stored as entries in a profile database 19. Exemplary profile database entries include a set of profile parameters, such as a set of coordinates of the cluster centroid, a measure of the cluster diameter and/or eccentricity, etc.

Figure 6 illustrates exemplary components and operation of the analysis engine 60. In some embodiments, engine 60 includes an event encoder 70, an event clustering engine 72, and a client clustering engine 74 connected to the event encoder 70 and the event clustering engine 72. An exemplary sequence of steps performed by the analysis engine is illustrated in Figure 7.

In the sequence of steps 202 to 204 to 206, the analysis engine 60 may assemble a training event corpus 18 based on event indicators received from selected client systems and/or routers. In some embodiments, event indicators are accumulated until certain accumulation conditions are met. Accumulation conditions may be determined based on the count of events (collecting a corpus of 1 million events), based on time conditions (e.g., recording all events received within a 1-hour interval), based on the identity of the client system and/or user (e.g., recording all events received from enterprise X, IP range Y, subscription account Z, etc.), or based on any other method known in the field. Individual events may be tagged according to their origin and may include a timestamp indicating the moment the corresponding event has occurred, been detected, or been received at the security server 16. In some embodiments, the event corpus 18 is periodically and/or refreshed on demand by incorporating the most recently received event indicators.

In some embodiments, the event encoder 70 (FIG. 6) is configured to take on an event record 26 including data characterizing events that have occurred on the client system (e.g., initiating a process on the client machine), and in response, output an event vector 28a including representations of the corresponding events as a vector in an abstract multidimensional space, typically considered in the field as an embedding space. An exemplary embedding space is expanded by a set of axes, each representing a distinct event feature. In the case of network events, exemplary features may include source IP address, source port, destination IP address, destination port, and indicators of transport protocols, etc. In another instance, each axis of the embedding space corresponds to a linear combination of event features (e.g., in a principal component/singular value decomposition embodiment). In a preferred embodiment, events are analyzed within the context of other events preceding and/or following the corresponding event. In such cases, the encoder 70 is configured to represent events as vectors in the embedding space of a context, where two events primarily occurring in similar contexts are relatively closely positioned together. Some embodiments select the dimension of the embedding space based on the size of the event vocabulary N (i.e., the count of dissimilar event types being monitored by the corresponding security system) (see below for more information on the event vocabulary). For example, the dimension of the event space may be approximately the square root of N, or approximately the logarithm of N. Typical embodiments of the invention use an embedding context space with hundreds to thousands of dimensions.

The event encoder 70 can be constructed using any method known in the field of automated data processing. In a preferred embodiment, the encoder 70 includes an artificial intelligence system, such as a multilayer artificial neural network (e.g., a recursive and/or feedforward neural network). To achieve the desired representation of the event vectors, the parameters of the encoder 70 can be tuned until certain performance conditions are met. This tuning is referred to herein as training and is represented by step 208 in FIG. 7. In a neural network embodiment, exemplary tunable parameters of the event encoder 70 include a set of synaptic weights, etc. In some embodiments, training the encoder 70 is equivalent to constructing the embedding space itself. In other words, the embedding space is not predetermined but depends on the composition of the event corpus 18 and the selected training process.

The exemplary training process is illustrated in Figures 8-A to 8-B and includes versions of the word2vec algorithm, such as the Continuous Skip Metagram and the Continuous Bag-of-Words algorithm. In such embodiments, events are not analyzed in isolation, but rather as components of an event sequence 25 consisting of multiple events ordered according to their occurrence or detection time. In some embodiments, all events in the corresponding sequence are selected such that they occur on the same client system. The event sequence 25 includes a central event E _₀ and an event context consisting of a subset of events E _{_-k}…E _{_-1} (k≥0) preceding the central event and/or a subset of events E₁…E_{_p} (p≥0) following the central event. A typical embodiment uses a symmetric event context (p = k), where p is in the range of 2 to 5. Each individual event E _{_i} (-k≤i≤p) can be represented as an N-by- ₁ numeric vector, where each row represents a distinct event type (e.g., opening a browser, initiating a file download, writing data to disk, etc.), N represents the size of the "vocabulary" of the event type, and non-zero elements indicate that the corresponding event has the corresponding event type. This representation is commonly referred to in the field as one-hot encoding. The exemplary size N of the event vocabulary ranges from hundreds to thousands of dissimilar event types, but can increase to millions for a specific application. Those skilled in the art will understand that one-hot encoding is used herein only as an example and is in no way intended to limit the scope of the invention.

In the exemplary training process, the event encoder and event decoder are paired and trained together, both of which may include portions of a feedforward and/or recurrent neural network. Generally, the encoder-decoder is configured to "predict" a first subset of the training sequence (e.g., the central event E _₀ ) and output a second subset of the corresponding sequence (e.g., a context event E _{_i}, i≠0). In the examples of Figures 8-A to B, the predictions are illustrated as one-hot vectors; alternative embodiments may use different representations. For example, the predictions may be represented as N-dimensional numeric vectors, each numeric indicating the probability that the corresponding event type exists in the second subset.

In the continuous skip metagram training process illustrated in Figure 8-A, the encoder-decoder pair is trained to generate the correct event context given a central event E _₀. For each event sequence obtained from the event corpus 18, encoder 70a is configured to take the one-hot encoding of the central event E _₀ as input and generate an event vector 28c that includes a representation of the central event E _₀ in the embedded context space. Decoder 76a is then configured to take the event vector 28c as input and output multiple guess vectors, each representing the “predicted” context event E _{_i} (i≠0) for the corresponding event sequence. The encoder-decoder pair can then be trained by adjusting the parameters of encoder 70a and/or decoder 76a to reduce prediction error, i.e., to correct the mismatch between the “predicted” context and the actual context of the corresponding training sequence.

The alternative training process uses a continuous bag-of-words training algorithm and aims to generate the correct center event _E0 of the training sequence given the corresponding event context. In one example illustrated in Figure 8-B, the event encoder 70b is configured to take as input a set of one-hot vectors representing the context events _Ei (i≠0) of sequence 25, and output embedded event vectors 28d to f determined for each corresponding context event. In contrast to the continuous skip metagrammation embodiment illustrated in Figure 8-A, the encoder 70b is now paired with an event decoder 76b configured to take as input multiple event vectors 28d to f and generate a prediction or “guess” of the center event _E0 of sequence 25. The encoder-decoder pair can then be trained by adjusting the parameters of encoder 70b and/or decoder 76b to reduce prediction error, i.e., the mismatch between the “predicted” center event and the actual center event of the corresponding training sequence.

An exemplary sequence of steps for training the event encoder is illustrated in Figure 9. Step 222 retrieves a set of event records from the event corpus 18 and identifies the event sequence 25 based on the event timestamps and the source of the corresponding event (i.e., the client system where the corresponding event has occurred). In a continuous jump metagrammation embodiment, step 224 then executes the event encoder 70a to produce an embedding space representation of event _E0 (event vector 28c in Figure 8-A). In step 226, the analysis engine 60 executes the event decoder 76a to produce a set of predictions or "guesses" for events preceding and/or following the central event _E0 within sequence 25. Step 228 compares each predicted context event of sequence 25 with the corresponding actual context event _Ei (i≠0) to determine the numerical prediction error. The prediction error, which can be interpreted as a cost function or objective function, can be calculated according to any method known in the field of artificial intelligence. Such calculations may include determining the distance between the predicted and actual events, such as edit distance, Euclidean distance, or cosine distance. Some embodiments determine the objective function based on a cross-entropy metric. In step 230, the analysis engine adjusts the parameters of encoder 70a in the direction that minimizes the calculated prediction error. Some exemplary algorithms used for training include backpropagation using gradient descent, simulated annealing, and genetic algorithms. Then, in some embodiments, steps 222 to 230 are repeated until a termination condition is met, for example, until the average prediction error of the event corpus 18 drops below a predetermined threshold. In another embodiment, training is performed for a predetermined amount of time or a predetermined number of iterations. Those skilled in the art will understand that the sequence of steps illustrated in Figure 9 is also applicable to the bag-of-words embodiment (Figure 8-B) with slight modifications.

In response to training the event encoder as shown above, some embodiments further transform the generated embedding space to reduce its dimensionality. This operation can include any data dimensionality reduction algorithm, such as principal component analysis (PCA) or singular value decomposition (SVD).

After training and optional dimensionality reduction (step 208 in Figure 7), the event encoder 70 is able to represent each event as a vector in a multidimensional embedding space of the event context, where two events that frequently occur within the same event context occupy similar positions. In other words, two such events are separated in the embedding space by a distance smaller than the distance between two events that primarily occur in different contexts.

Returning to the components of the analysis engine 60 (Figure 6), the event clustering engine 74 is configured to organize event vectors generated by the trained event encoder 70 and representing members of the training corpus 18 into clusters based on the position of each event vector within the embedding space (see also step 207 in Figure 7). In some embodiments, a cluster includes multiple events that are relatively close together in the embedding space, or in other words, multiple events characterized by relatively small inter-event distances in the embedding space. In alternative embodiments, a cluster consists of events occupying cluster-specific regions of the embedding space. Such regions may be mutually exclusive or partially overlapping. Figure 10 illustrates an exemplary embedding space and a set of event clusters 80a to b according to some embodiments of the invention. The illustrated axes may include, for example, the first and second principal components of the illustrated event vectors (vectors 28g to h to k). In embodiments using an embedding space with event contexts, clusters may selectively contain events that primarily occur within similar event contexts. Furthermore, the same cluster may contain events occurring on various client systems and/or representing the activities of various users.

To construct event clusters, the analysis engine 60 can employ any data clustering algorithm known in the field, such as a variant of the k-means algorithm. Another exemplary embodiment can train a set of perceptrons to divide the embedding space into dissimilar regions and assign event vectors located within each region to dissimilar event clusters. The number of clusters and/or regions can be predetermined (e.g., based on a count of protected client systems and/or monitored event types) or can be dynamically determined by the clustering algorithm itself. The result of event clustering includes a set of event cluster parameters 54 (Figure 6), which may include the coordinates of the cluster's centroid and measures of the cluster's extent, such as diameter and/or eccentricity, for each cluster. Other exemplary cluster parameters 54 may include, in particular, a list of members for the corresponding cluster, with selected members of the corresponding cluster considered as representatives/prototypes of the corresponding cluster. The cluster parameters can be passed to the client clustering engine 74.

Client clustering engine 74 (Figure 6) is configured to determine a set of client profiles based on event clusters computed by event clustering engine 72. Such client profiles are illustrated in Figure 11. In some embodiments, each client profile includes a selected subset (cluster) of protected client systems 10a to h. Some client profiles may contain multiple client clusters. In some embodiments, client profiles may include profile prototypes, which may be actual members of the corresponding client clusters or fictitious client systems characterized by specific locations in the profile space. For example, a profile prototype may include the centroids of client clusters determined by client clustering engine 74.

To compare client profiles, some embodiments of the client clustering engine 74 assign client systems 10a to h to clusters based on event profiles indicating a typical distribution of events occurring on the respective client systems. In one exemplary embodiment, the event profiles of the client systems include numeric vectors, each determined based on the event counts occurring on the respective client system and belonging to dissimilar event clusters previously determined by the event clustering engine 72. In the example illustrated in FIG12, each component of the event profile is determined based on a cluster loyalty metric indicating the proportion of events belonging to the respective event cluster _Ci , which is determined as a fraction of the total event counts available from the respective client system. For example, when the event clustering engine 72 has identified three event clusters _C1 , _C2 , and _C3 , the event profile vector [0.1, 0.75, 0.15] could represent a client system where 10% of the events occurring on the respective client system belong to event cluster _C1 , 75% belong to event cluster _C2 , and 15% belong to event cluster _C3 .

In the exemplary embodiment illustrated in Figure 11, each client system is represented in a multidimensional profile space according to a corresponding event profile. In other words, each coordinate of a client system represents a component of the corresponding client's event profile. Figure 11 shows three exemplary client clusters/profiles 82a to c. Those skilled in the art can construct such profiles using any methods known in the fields of machine learning or data mining; exemplary methods include k-means clustering algorithms and variations of neural networks, etc. Alternative embodiments may use other criteria for assigning client systems to clusters, or use this criterion in addition to the corresponding client's event profile. Exemplary additional client clustering criteria include, in particular, the owner and/or user of the corresponding client system, the network address of the corresponding client system, the device type of the corresponding client system, etc. For example, clients belonging to the same household, the same business, or the same network domain may be grouped together in the same cluster.

After client-side clustering, the analysis engine 60 can save cluster parameters to the configuration file database 19, such as the list of client systems assigned to each cluster/configuration file, the coordinates of the cluster prototype (e.g., centroid), the cluster diameter, etc.

Figure 13 illustrates exemplary components and operation of an anomaly detector 62 according to some embodiments of the present invention (see also Figure 5). The anomaly detector 62 is configured to receive an event stream 24 including event indicators indicating events occurring on various client systems and a security flag 88 as a response output indicating whether the corresponding event indicates a security threat (e.g., intrusion or execution of malware). In some embodiments, the anomaly detector 62 includes a profile manager 84 configured to select a client profile based on the corresponding event in response to receiving an event notification indicating an event occurring on a protected client system. The profile manager 84 is further connected to a behavior model 86 configured to determine whether the corresponding event fits a pattern of normal/baseline behavior represented by the corresponding profile. When it does not fit, the corresponding event may be considered an anomaly, thereby indicating a possible attack on the corresponding client system.

In preparing to perform anomaly detection as shown below, some embodiments of the anomaly detector 62 are first trained on an event corpus using the output of the analytics engine 60. One purpose of training the anomaly detector 62 is to determine normal/baseline user behavior for each client profile identified by the analytics engine 60. Training involves adjusting a set of parameters of the behavior model 86 until a termination criterion is met. The event corpus used to train the anomaly detector 62 may differ from the training corpus 18 used to train the components of the analytics engine 60.

Figure 14 illustrates an exemplary sequence of steps performed by the anomaly detector 62 during the training process according to some embodiments of the present invention. In response to the anomaly engine 60 constructing a set of client profiles, step 242 selects one such client profile from the profile database 19. In some embodiments, each such client profile includes a set of client clusters, such as cluster 82a in Figure 11. Each client cluster further includes a selected subset of protected client systems. Step 244 may select a set of training events registered as occurring on any client system associated with the corresponding profile/cluster. In some embodiments, step 244 may include selecting a set of training events from a training corpus 18 already used to construct client profiles as shown above. Another step 246 may use the corresponding event training set as a training corpus to train the behavior model 86.

In some embodiments, behavioral model 86 includes components that are structurally and functionally similar to some components of analytics engine 60. For example, some embodiments of model 86 include an encoder-decoder pair as illustrated in FIG. 15, which can be constructed using neural network techniques and trained according to members of the word2vec family of algorithms (see the description above regarding FIG. 8-A to B). Training behavioral model 86 can then be equivalent to adjusting the parameters (e.g., a set of synaptic weights) of encoder 70c and/or decoder 76c to represent each event from the respective client cluster/profile as a vector in the event embedding space. In a preferred embodiment, encoder 70c analyzes each event in the context of the event sequence and generates an embedding space where events occurring primarily in similar contexts are separated by smaller distances than events occurring in other contexts. However, the event embedding space generated by training encoder 70c (i.e., the meaning of axes, the magnitude of distances between events, etc.) can be significantly different from the event embedding space generated by training event encoder 70, because the training corpora used for the two encoders are different.

In a preferred embodiment, step 246 includes training the encoder-decoder pair using a version of the bag-of-words algorithm (see Figure 8-B). In one such example, the encoder-decoder pair (Figure 15) is configured to receive multiple events E _{_-k}…E _{_-1} , E_₁…E_{_p} representing the event context of the currently analyzed event sequence, and generating an N-dimensional prediction score vector 90, where each element is associated with a dissimilar event type, and each element represents the probability that the central event of the corresponding event sequence has the corresponding event type. For example, a higher score value may indicate that the corresponding event type is more likely to occur as the central event of the corresponding event sequence than an event type with a lower score. In such embodiments, exemplary training of model 86 may include selecting an event sequence from a subset of the events identified in step 244 (Figure 14), inputting the event context of the corresponding sequence into encoder 70c, executing decoder 76c to generate a prediction of the central event E _₀ of the corresponding event sequence, and penalizing incorrect predictions by backpropagating prediction errors through the neural network forming encoder 70c and/or decoder 76c. In response to successful training, step 248 may save the parameter values of the trained behavioral model. The training process can be repeated for each client profile identified by the analytics engine 60.

Figure 16 illustrates an exemplary sequence of steps performed by an anomaly detector 62 according to some embodiments of the present invention to protect a target client system (e.g., clients 10a to h in Figure 1) from computer security threats. The target client system may or may not be a member of a subset of clients that provide a training corpus of events that generate behavioral models and/or client profiles as shown above. To protect the target client system, events may be detected at the target client system and/or other devices (e.g., routers 15a to b (see Figure 1)) and may be communicated to the security server 16 in the form of event indicators. These event indicators may then be preprocessed according to their source, event type, timing, service account settings, etc., and organized into an event stream 24. Events may be processed individually or in batches. In response to receiving an event indicator from the target client system, in step 254, the anomaly detector 62 may assemble an event sequence for analysis based on the corresponding event indicator. Step 254 may include identifying the event source (i.e., the client system where the corresponding event has occurred) and selecting multiple other events from the event stream 24 to form an event sequence. In some embodiments, the members of the sequence are selected such that they all originate from the same target client system. In another instance, all members of the sequence must occur on a predetermined subset of client systems, such as (for example) a network subdomain or a common IP address. The selected events may also be ordered according to their occurrence and/or detection time, for example, using a timestamp provided along with the incoming event indicator. The event sequence may be further divided into several parts, for example, to identify the central event and the event context (see, for example, Figure 8-A).

In step 256, the profile manager 84 may select a client profile based on a corresponding event indicator, such as the identity of the target client system where the corresponding event has occurred. When the corresponding target client system has provided training events for developing client profiles and/or for training behavioral models, step 256 may include selecting a client profile/cluster with the corresponding target client system as a member. Other profile selection criteria may also be used. For example, step 256 may include selecting a client profile based on the location of the target client system within the client profile space (see Figure 11), such as by comparing the location of the target client system with a set of cluster prototypes or centroids and selecting the cluster/profile whose centroid is closest to the target client system. In one example, the client profile may be selected based on an event profile determined for the target client system (e.g., based on the count of events received from the target client system that fit into a specific event category/cluster). Other client profile selection criteria may include selecting a client profile based on the network address of the target client system (e.g., selecting a client profile containing clients with the same IP address as the target client system), selecting a client profile based on the owner/user of the target client system (e.g., selecting a profile containing members of the same household as the target client system), etc.

In another step 258, the anomaly detector may instantiate behavior model 86 using parameter values specific to the corresponding selected client profile. In some embodiments, after profile-specific instantiation, executing model 86 (step 260) includes projecting events of the corresponding event sequence into the event embedding space associated with the corresponding client profile.

Step 262 can now determine whether the events in the corresponding event sequence represent normal/baseline user behavior associated with the corresponding client profile. In one embodiment, step 260 includes feeding the event context (E _{_i}, i≠0) of the corresponding sequence to the behavior model 86 and calculating a predicted score vector 90 for the corresponding sequence. Step 262 then includes identifying elements of the vector 90 that identify the event type corresponding to the actual central event E _₀ of the sequence, and comparing the corresponding score to a predetermined threshold (e.g., 0.95). In some embodiments, a score below the threshold indicates that the corresponding event E _₀ is substantially unlikely to occur in the corresponding event context, and therefore indicates an anomaly consistent with a potential computer security threat. In some embodiments, the user or administrator of the security server 16 can tune the sensitivity of the method by adjusting the value of the threshold. In one example, different thresholds are associated with different groups of client systems.

In an alternative embodiment, step 260 may include using model 86 to determine the representation of the event E_{_i} of the sequence in an event embedding space specific to the corresponding client profile. Next, step 262 may include determining whether the event E_{_i} fits a pattern of normal behavior of the corresponding client profile based on the location of the corresponding event within the embedding space. For example, an event may be considered normal when it is located within a cluster of training events (e.g., closer to the cluster centroid than a predetermined threshold). In another instance, an event may be considered normal/benign when located in a specific region of the embedding space, and abnormal when located in other regions.

When a sequence of events (e.g., _E0 ) is considered anomalous, or in other words, does not fit the normal pattern established through training on the corresponding client profile, step 264 may flag the event for further analysis. In some embodiments, the anomaly may trigger a security warning issued by the warning manager 64 of the security server 16 (see Figure 5). The security warning may be sent to the client system where the anomalous event occurred and/or to the administrator of the corresponding client system. The occurrence of the anomalous event may also be collected and reported to a computer security laboratory for further analysis.

The exemplary systems and methods described above allow for the efficient detection of computer security threats, such as malware and intrusions. The disclosed systems and methods implement behavioral approaches for computer security, wherein normal/baseline user behavior is automatically inferred by the system from a training corpus of events, and violations of baseline behavioral patterns can indicate threats.

Some embodiments detect various events occurring on multiple client systems (e.g., computers, mobile phones, network devices, and virtual machines). Exemplary events include specific process initiation, attempts to access specific files or network locations, and network traffic events such as access to specific ports and addresses. Those skilled in the art will understand that the systems and methods described herein can be adapted to other types of events, such as those related to a user's activity on social media, a user's browsing history, and a user's gaming activity. Event notifications are aggregated at a security server. This collection of events can be used as a training corpus for constructing a set of client profiles, where each client profile may represent a single user, a single machine, or multiple users/machines. In some embodiments, each client profile includes a subset of client systems and/or a subset of events that have occurred on a corresponding subset of client systems. Each client profile may represent a normal and/or benign usage pattern of the corresponding client system. Such client profiles can then be used to detect incidents of anomalous behavior, which may indicate computer security threats.

Some conventional computer security systems operate based on a set of rules that quantify malicious behavior. Because developers are typically interested in providing such solutions to a wide variety of clients, these behavioral rules are often generic rather than user-specific. However, in reality, users are highly diverse. Even within the same company or family, each member can use a computer in vastly different ways. What might be considered normal for a software developer or engineer could be highly unusual when detected on a computer in an accounting department. Furthermore, the same user may exhibit significantly different behaviors at work compared to at home. Therefore, generic behavioral rules may fail to capture the diversity and specificity of real users. In contrast to such conventional systems, in some embodiments of the present invention, events occurring on the respective client systems are selectively examined and analyzed against models that capture the normal/baseline behavior of each client system itself and/or similar clients. In other words, the boundaries of behavioral "normality" can be defined using substantial specificity: a specific client machine, a specific user group (e.g., a specific department within a company, family members, a specific age group), etc.

Due to the surge in software and internet usage, attempts to develop highly specific behavioral profiles (e.g., profiles attached to each individual user) could require unrealistic computational resources and are therefore impractical. Furthermore, collecting events from individual users/machines may not provide sufficient data to develop statistically robust behavioral models. In contrast, some embodiments of the present invention group multiple users and/or machines into a single client profile, thereby ensuring a useful trade-off between specificity, robustness, and computational cost. Moreover, the manner in which users and machines are grouped into profiles is itself based on behavioral criteria to ensure that such grouping retains specificity. In some embodiments, each client profile group groups users/machines with substantially similar event profiles together. In other words, all members of the client profiles exhibit similar baseline behavior in terms of the statistics of events occurring on member machines.

Some conventional computer security systems and methods primarily analyze individual events. Many events that occur during the operation of a computer system (e.g., opening a file, accessing a webpage) may not indicate malicious intent when performed in isolation. However, when they occur in the context of other events (e.g., as a specific sequence of actions), they may be malicious. In contrast to more conventional solutions, some embodiments of the present invention explicitly analyze events in context and are therefore more suitable for such event-related situations. Preferred embodiments represent individual events as vectors in a multidimensional embedding space, which have unique properties such that a pair of events occurring with a relatively high frequency in the same event context is less separated than another pair of events occurring with a lower frequency in the same event context.

Successful behavioral modeling may require detecting a large number (e.g., hundreds or thousands) of dissimilar event types, but not all event types are equally important in behavioral modeling. Collecting and analyzing statistics on such numerous event types received from a large number of sources can be impractical. To address this issue, some embodiments group events into event categories or clusters based on their similarity, thereby creating more robust and/or relevant statistics. This meaningful dimensionality reduction can significantly facilitate the construction of client profiles. Event similarity can be determined according to several criteria, such as the distance that separates two events in the event embedding space. In a preferred embodiment, two events are considered similar if they primarily occur in the same context (e.g., events A and B are considered similar when both frequently follow event X and/or precede event Y, i.e., events A and B are considered similar, as in the exemplary sequences XAY and XBY).

Figures 17-A through 17-B illustrate an experiment applying some of the systems and methods described above to the detection of computer security threats. An event corpus collected from multiple monitored clients is used to train components of the analysis engine as shown above, resulting in the monitored clients being divided into 11 client clusters/profiles. Events are categorized into several event classes based on their representation in a 15-dimensional embedding space. Profile-specific behavioral models are developed for each corresponding client cluster. Then, specific types of attacks are launched on a test machine. Event sequences collected from the test machine are fed into an anomaly detector, which is instantiated using parameters specific to each of the behavioral models. Some of these event sequences are detected as anomalies.

Figure 17-A illustrates cluster-specific anomaly scores, expressed as levels, where a score of 1 indicates 100% certainty of the anomaly (e.g., at least one event in the sequence of events received from the test machine has not been seen during training). The graph represents the average score across the sequence of anomalous events and the associated standard deviation. The figure illustrates that the same sequence can be considered anomaly with a cluster-specific level of certainty. In other words, the same sequence of events is considered "less anomalous" on some clients compared to others. For example, the behavioral models associated with clusters 1, 2, and 7 not only detect attacks more efficiently than other models, but all event sequences associated with the attacks are considered "equally anomalous." In contrast, the models associated with clusters 0 and 9 indicate that some event sequences of the same attack are "less anomalous" than others.

Figure 17-B illustrates profile-specific average detection rates achieved against three distinct attack types. Event sequences collected from the test machine during each attack type were analyzed using each of 11 profile-specific trained behavioral models. The detection rates differed between models and attack types, further confirming the specificity of some of the systems and methods described in this paper.

Such experimental results indicate another potential application of some embodiments of the invention. Centralized computer security solutions can selectively develop protection strategies for each group of clients identified by client profiles and/or other clients that are similar to the prototype of each client cluster. Some embodiments can identify client clusters for which the methods described herein provide a satisfactory level of security, as well as other client clusters that require additional security measures. Customizing protection for each client cluster can improve the user experience and reduce unnecessary computational costs.

It will be apparent to those skilled in the art that the above embodiments can be modified in many ways without departing from the scope of the invention. Therefore, the scope of the invention should be determined by the appended claims and their legal equivalents.

Claims (15)

1. A computer system including at least one hardware processor, said at least one hardware processor being configured to: In response to receiving a cluster membership indicator that directs multiple client systems to multiple client clusters, a client cluster is selected from the multiple client clusters. The grouping is determined by analyzing a set of events that have occurred on members of the multiple client systems to identify client systems with similar behaviors; In response to selecting the client cluster, a behavioral model is trained to encode baseline behaviors that collectively represent the members of the selected client cluster, wherein: The behavioral model includes an event encoder configured to determine the embedding vector of the selected event in the event sequence based on the position of the selected event within the event sequence and further based on at least one other event in the event sequence. The event sequence consists only of events that have occurred on members of the selected client cluster and is ordered according to the occurrence time of each event. Training the behavior model includes predicting another event in the event sequence based on the embedding vector and adjusting the parameters of the event encoder based on the prediction; and In response to training the behavioral model, adjusted values of the parameters are emitted to an anomaly detector configured to use the trained behavioral model to determine whether a target event occurring on a target client system indicates a computer security threat. 2. The computer system according to claim 1, wherein: The event sequence includes a central event and an event context, wherein the event context includes a first subset of the events that occurred before the central event and a second subset of the events that occurred after the central event; The selected event is the central event; and The other event is a member of the event context. 3. The computer system according to claim 1, wherein: The event sequence includes a central event and an event context, wherein the event context includes a first subset of the events that occurred before the central event and a second subset of the events that occurred after the central event; The selected event is a member of the event context; and The other event is the central event. 4. The computer system according to claim 1, wherein: The event set is divided into multiple event categories based on the event context of each event in the event set; and Grouping the multiple client systems into a cluster includes determining whether a selected client system belongs to the selected client cluster based on the event count of events that have occurred on the selected client system and belong to the selected category of the multiple event categories. 5. The computer system of claim 4, wherein grouping the plurality of client systems into a cluster includes further determining whether the selected client system belongs to the selected client cluster based on a count of another event that has occurred on the selected client system and belongs to another category of the plurality of event categories. 6. The computer system of claim 1, wherein the selected event includes the initiation of the selected process on a client system among the plurality of client systems. 7. The computer system of claim 1, wherein predicting the other event includes determining a prediction indicator indicating the likelihood that the other event belongs to the event sequence. 8. A computer-implemented method, comprising: Employing at least one hardware processor of a computer system, in response to receiving a cluster membership indicator indicating packets from multiple client systems to multiple client clusters, a client cluster is selected from the multiple client clusters. The grouping is determined by analyzing a set of events that have occurred on members of the multiple client systems to identify client systems with similar behaviors; In response to selecting the client cluster, at least one hardware processor of the computer system is used to train a behavioral model to encode baseline behavior that collectively represents the members of the selected client cluster, wherein: The behavioral model includes an event encoder configured to determine the embedding vector of the selected event in the event sequence based on the position of the selected event within the event sequence and further based on at least one other event in the event sequence. The event sequence consists only of events that have occurred on members of the selected client cluster and is ordered according to the time of occurrence of each event. Training the behavior model includes predicting another event in the event sequence based on the embedding vector and adjusting the parameters of the event encoder based on the prediction; In response to training the behavioral model, at least one hardware processor of the computer system transmits adjusted values of the parameters to an anomaly detector configured to use the trained behavioral model to determine whether a target event occurring on the target client system indicates a computer security threat. 9. The method according to claim 8, wherein: The event sequence includes a central event and an event context, wherein the event context includes a first subset of the events that occurred before the central event and a second subset of the events that occurred after the central event; The selected event is the central event; and The other event is a member of the event context. 10. The method according to claim 8, wherein: The event sequence includes a central event and an event context, wherein the event context includes a first subset of the events that occurred before the central event and a second subset of the events that occurred after the central event; The selected event is a member of the event context; and The other event is the central event. 11. The method according to claim 8, wherein: The event set is divided into multiple event categories based on the event context of each event in the event set; and Grouping the multiple client systems into a cluster includes determining whether a selected client system belongs to the selected client cluster based on the event count of events that have occurred on the selected client system and belong to the selected category of the multiple event categories. 12. The method of claim 11, wherein grouping the plurality of client systems into a cluster includes further determining whether the selected client system belongs to the selected client cluster based on a count of another event that has occurred on the selected client system and belongs to another category of the plurality of event categories. 13. The method of claim 8, wherein the selected event includes the initiation of the selected process on a client system among the plurality of client systems. 14. The method of claim 8, wherein predicting the other event includes determining a prediction indicator indicating the likelihood that the other event belongs to the event sequence. 15. A non-transitory computer-readable medium storing instructions that, when executed by at least one hardware processor of a computer system, cause the computer system to perform the following operations: In response to receiving a cluster membership indicator that directs multiple client systems to multiple client clusters, a client cluster is selected from the multiple client clusters. The grouping is determined by analyzing a set of events that have occurred on members of the multiple client systems to identify client systems with similar behaviors; In response to selecting the client cluster, a behavioral model is trained to encode baseline behaviors that collectively represent the members of the selected client cluster, wherein: The behavioral model includes an event encoder configured to determine the embedding vector of the selected event in the event sequence based on the position of the selected event within the event sequence and further based on at least one other event in the event sequence. The event sequence consists only of events that have occurred on members of the selected client cluster and is ordered according to the time of occurrence of each event. Training the behavior model includes predicting another event in the event sequence based on the embedding vector and adjusting the parameters of the event encoder based on the prediction; and In response to training the behavioral model, adjusted values of the parameters are emitted to an anomaly detector configured to use the trained behavioral model to determine whether a target event occurring on a target client system indicates a computer security threat.