Stacked malware detector for mobile platforms

Abstract

The systems and methods described protect electronic devices, such as smartphones and IoT devices, from malicious software. In some embodiments, the malware detector comprises a stack / cascade of feature processors configured to determine a set of derived feature values ​​according to key features that characterize the software running on each device, and further comprises a synthesizer module configured to determine whether a client device is malware according to the derived feature values. When a derived feature value is currently unavailable or cannot be computed, in some embodiments, a surrogate value is supplied to replace the missing derived feature value, thereby ensuring that the malware detector can always generate a determination.

Description

[Technical Field]

[0001]

[0001] The present invention relates to computer security, and more particularly to protecting users and devices from malicious software. [Background technology]

[0002]

[0002] Malicious software, also known as malware, affects a large number of computer systems worldwide. In many forms, such as computer viruses, spyware, and ransomware, malware poses a significant risk to millions of computer users, making them vulnerable to, among other things, fraud, loss of data and confidential information, theft of identity, and loss of productivity. The explosive growth of mobile computing is exacerbating computer security risks, with millions of devices, such as smartphones and tablet computers, constantly connected to the internet and acting as potential targets for malware. Particularly on mobile platforms, malware can disguise itself as legitimate applications, including games, news, and messaging platforms, thereby deceiving unsuspecting users into installing them. In some cases, users may be completely unaware of any malicious activity hidden behind a seemingly legitimate and entertaining interface.

[0003]

[0003] Conventional methods of protecting against malware include running security software on each device. Detection methods typically include static analysis, which is compared against a library of “code signatures” that indicate that the target software is malware, and behavioral analysis, in which the security software monitors the target software for signs of malicious behavior. In response to the detection of a malicious agent, the security software may quarantine or prevent its further execution. With recent advances in artificial intelligence (AI) and machine learning (ML), some modern malware detectors now rely on various features of artificial neural networks, pre-trained on a corpus of known malicious and clean samples. In a typical example, the neural network receives a vector of feature values ​​that characterize the target software entities and outputs a label indicating whether each target software is malicious.

[0004]

[0004] However, such AI methods face considerable technical challenges. One example is the selection of input features. There are usually no clear or universal criteria for choosing which features of target software are likely to expose malice and / or differentiate malicious behavior from harmless behavior. Mobile computing platforms (smartphones, wearables, etc.) and Internet of Things (IoT) devices exhibit considerable diversity in terms of hardware and software compared to personal computers. Thus, it can be difficult to find features that reliably work and indicate malware across such a heterogeneous collection of devices. Furthermore, some features cannot be reliable indicators of malice because the same software application may behave differently on different devices depending on local operating system settings and the permissions granted to each device.

[0005]

[0005] Another reason why software applications exhibit device-specific behavior is a deliberate attempt by sophisticated malware to evade countermeasures. For example, some malware refrains from exhibiting behavior that indicates it is long-standing malware, deceiving security software into classifying it as harmless. Some malware can adapt its behavior according to the type of device (e.g., a tablet versus a smartphone, one manufacturer or model versus another), the type of operating system, the current geographical location of each device, etc. Some malware further selects its victims by exploring each device against an indicator of the user's value to the attacker. For example, malware can determine what other software is currently installed on each device and may explore specific applications such as banking, social media, etc. Other malware can monitor user patterns of accessing various applications, online resources, etc. Such malware may then launch attacks only on carefully selected devices and / or against carefully selected users when each attack is deemed to have a higher probability of being effective.

[0006]

[0006] Another challenge faced by AI-driven anti-malware is the availability of input features. In other words, even when a set of relevant features is known, some of each feature may not be available at all times and / or on all client devices. This is especially true for mobile computing platforms, such as smartphones and wearables, where extracting or evaluating some features may require specific permission from the user. Furthermore, extracting and evaluating some features can be relatively costly from a computational standpoint, which can unacceptably alter the user experience, particularly on mobile platforms, which typically have far fewer computing resources compared to personal computers and servers.

[0007]

[0007] To address the feature selection and usability problem, some conventional methods increase the number of features and, consequently, the size of the AI ​​model in an attempt to improve their performance. However, large neural networks are known to be computationally expensive to implement and train, and typically require large training corpora that are difficult to obtain, annotate, and maintain.

[0008]

[0008] For all the reasons outlined above, there is considerable ongoing effort and sustained interest in developing robust and scalable computer security systems and methods that are capable of responding quickly and efficiently to emerging threats to mobile computing platforms. [Overview of the Initiative]

[0009]

[0009] According to one embodiment, a malware detection method includes the step of executing a plurality of feature processors configured to determine a plurality of derived feature values ​​according to a plurality of primary feature values ​​that characterize a software entity running on the computer system, using at least one hardware processor of the computer system, wherein a selected feature processor is configured to determine a selected derived feature value according to a selected subset of the plurality of primary feature values. The method further includes the step of determining whether a selected derived feature value is missing in response to executing the plurality of feature processors, and if so, supplying a surrogate value to replace the missing selected derived feature value. The method further includes the step of determining whether a software entity is malicious, using at least one hardware processor of the computer system, according to the derived feature values ​​determined by the plurality of feature processors and further according to the surrogate feature values.

[0010]

[0010] In another embodiment, the computer system comprises at least one hardware processor configured to run a plurality of feature processors, a data replacement module, and a synthesizer module. The plurality of feature processors are configured to determine a plurality of derived feature values ​​according to a plurality of primary feature values ​​that characterize a software entity running on the computer system, wherein a selected feature processor is configured to determine a selected derived feature value according to a selected subset of the plurality of primary feature values. The data replacement module is configured to determine whether a selected derived feature value is missing, and if so, to replace the missing selected derived feature value by supplying a surrogate value. The synthesizer module is configured to determine whether a software entity is malicious according to the derived feature values ​​determined by the plurality of feature processors, and further according to the surrogate feature values.

[0011]

[0011] In another embodiment, a non-temporary computer-readable medium stores instructions that, when executed by at least one hardware processor of the computer system, cause the computer system to form a plurality of feature processors, a data replacement module, and a synthesizer module. The plurality of feature processors are configured to determine a plurality of derived feature values ​​according to a plurality of primary feature values ​​that characterize a software entity running on the computer system, and a selected feature processor is configured to determine a selected derived feature value according to a selected subset of the plurality of primary feature values. The data replacement module is configured to determine whether a selected derived feature value is missing, and if so, to replace the missing selected derived feature value by supplying a surrogate value. The synthesizer module is configured to determine whether a software entity is malicious according to the derived feature values ​​determined by the plurality of feature processors, and further according to the surrogate feature values.

[0012]

[0012] The above aspects and advantages of the present invention will be better understood by reading the following detailed description and by referring to the drawings. [Brief explanation of the drawing]

[0013] [Figure 1]

[0013] This figure shows exemplary software that runs on a client device, including a security application that protects the client device against malware, according to some embodiments of the present invention. [Figure 2]

[0014] This figure shows the exemplary structure and operation of a malware detector according to several embodiments of the present invention. [Figure 3]

[0015] This figure shows an illustrative sequence of steps performed by a malware detector according to some embodiments of the present invention. [Figure 4]

[0016] This figure shows multiple client devices protected from malware by a security server, according to some embodiments of the present invention. [Figure 5]

[0017] This figure shows an example of data exchange between a selected client device and a security server according to several embodiments of the present invention. [Figure 6]

[0018] This figure shows another exemplary data exchange between a client device and a security server according to some embodiments of the present invention. [Figure 7]

[0019] This figure shows multiple devices that provide data to a surrogate generator according to some embodiments of the present invention. [Figure 8]

[0020] This figure shows a typical multi-level stacked malware detector according to several embodiments of the present invention. [Figure 9]

[0021] This figure shows an exemplary hardware configuration of a computer system programmed to perform some of the methods described herein. [Modes for carrying out the invention]

[0014]

[0022] In the following description, all described connections between structures can be directly operable connections or indirectly operable connections through intermediate structures. A set of elements contains one or more elements. Any description of an element is understood to refer to at least one element. Multiple elements contain at least two elements. Unless otherwise required, any described method steps do not necessarily have to be performed in a specific shown order. A first element derived from a second element (e.g., data) includes a first element equal to the second element, as well as a first element resulting from processing the second element and, optionally, other data. Making a decision or judgment according to a parameter includes making a decision or judgment according to the parameter and, optionally, other data. Unless otherwise specified, indicators of some quantity / data may be the quantity / data itself or indicators different from the quantity / data itself. A computer program is a sequence of processor instructions that perform a task. Computer programs described in some embodiments of the present invention may be standalone software entities or subentities (e.g., subroutines, libraries) of other computer programs. The term “database” is used herein to describe an organized collection of any data. A hash is a numerical result obtained by applying a hash function to a token (e.g., a string, a code snippet, etc.). A hash function maps data of any size to a fixed-size value. Examples of hashing functions / procedures include, among others, cyclic redundancy checks (CRC), checksums, message digest functions (e.g., MD5), and secure hash algorithms (SHA). Computer-readable media include magnetic, optical, and semiconductor storage media (e.g., hard drives, optical discs, flash memory, DRAM), as well as non-transient media such as communication links, including conductive cables and fiber optic links.According to some embodiments, the present invention provides, among other things, a computer system comprising hardware (e.g., one or more processors) programmed to perform the methods described herein, and a computer-readable medium encoding instructions for performing the methods described herein.

[0015]

[0023] The following description shows embodiments of the present invention for illustrative purposes and is not necessarily for the purpose of limitation.

[0024] FIG. 1 shows an exemplary client device 12 protected against malware, according to some embodiments of the present invention. The client device 12 generally represents any electronic device having a processor, a memory, and a communication interface that enables each device to communicate with other devices / computer systems. Exemplary client devices 12 include, among other things, personal computers, mobile computing platforms (e.g., among other things, laptop computers, tablets, mobile phones, and wearable devices such as smart watches and fitness bands), entertainment devices (e.g., TVs, game consoles), and household appliances (e.g., refrigerators, washing machines).

[0016]

[0025] In some embodiments, the client device 12 runs multiple computer programs, such as an operating system (OS) 22 that provides an interface between the hardware of the client device 12 and other computer programs, such as a set 24 of target applications running on each client device. Exemplary operating systems include, among other things, Windows®, MacOS®, iOS®, and Android®.

[0017]

[0026] The target application 24 generally represents any software, including, but not limited to, word processing, image processing, spreadsheets, calendars, gaming, social media, web browsers, and electronic communication applications. In this specification, the term “application” refers to a standalone, executable part of software separate from the operating system, which can be launched by a user independently of other applications (as opposed to, for example, a software library or subroutine that forms part of another computer program). The exemplary application 24 includes smartphone apps downloaded from stores such as Apple® Inc.’s App Store or Google® Play®, or other third-party applications installed by the user (for example, an APK file downloaded directly from the internet by the user and installed on client device 12). The modifier “target” is included simply for clarity to indicate that application 24 is subject to security analysis (malware detection) as described herein. For example, a malware detector as described herein may be configured to determine whether target application 24 contains malware.

[0018]

[0027] In some embodiments, the security application 30 is configured to protect the client device 12 and its users from computer security threats, such as malicious software. For clarity, the following description focuses on embodiments in which the security application 30 comprises software running on at least one hardware processor of the client system 12. However, those skilled in the art will understand that in alternative embodiments, the functions described may be implemented in hardware (e.g., a dedicated integrated circuit forming part of the device 12) or in a combination of hardware and software. The security application 30 may form part of a larger software suite that can provide a variety of security services, such as traffic filtering, virtual private networks (VPNs), anti-spam, parental controls, and others.

[0019]

[0028] In some embodiments, the security application 30 further includes a feature extractor 32 and a malware detector 34 communicatively coupled to the feature extractor 32. The feature extractor module 32 is configured to characterize various software entities (e.g., target applications 24) running on each client device by evaluating sets of such software features / attributes. Hereinafter, features evaluated by the extractor 32 are considered “primary” because they serve only as input to the first stage of a stacked malware detector, as described below. The modifier “primary” does not imply any relative importance or relevance of some features to others.

[0020]

[0029] In this specification, "key features" broadly refers to any attribute known in the art of computer security that may be used to determine whether a client device 12 is equipped with malicious software. Some such features may not indicate malware on their own, but may indicate malice when occurring in conjunction with other features. Illustrative key features include so-called "static" features such as the current contents of a section of memory, the contents of a file or folder (e.g., an Android® manifest file), current OS settings, the contents of the OS registry, text displayed to the user, various features of images displayed on the screen of the client device 12, and others. Other static features include indicators of whether the memory of the client system 12 currently stores a particular portion of instruction code / sequence, commonly known in the art as a malware signature. Other examples of key features include behavioral or so-called "dynamic" features that indicate whether a particular software entity has performed a particular action, such as opening a file, changing permissions, starting a child process, injecting code into another software entity, sending electronic communications (e.g., an HTTP request to a remote resource), and others.

[0021]

[0030] The operation of the feature extractor 32 may include any methods and algorithms known in the technical field of computer security. Evaluating static features may include signature matching by hashing or other means, by accessing OS-specific data structures such as the Windows® registry to read various settings and other current values. Evaluating dynamic features may include, among other things, detecting the occurrence of hardware or software events such as application installation, uninstallation, and updates; process / application startup and termination; child process creation (e.g., forking); dynamic loading / unloading of libraries; execution of specific processor instructions (e.g., system calls); file events such as file creation, writing, deletion, etc.; and setting of various OS parameters (e.g., Windows® registry events, permission / privilege changes). Other exemplary events to be detected include, among others, requests to access peripheral devices (e.g., hard disks, SD cards, network adapters, microphones, cameras), requests to access remote resources (e.g., hypertext transfer protocol - HTTP requests to access a specific URL, attempts to access a document repository through a local network), requests formulated in a specific uniform resource identifier scheme (e.g., mailto: or ftp: requests), and attempts to send electronic messages (e.g., email, short message service - SMS, etc.). Further exemplary events include moving the user interface / window of the target application 24 into and out of focus / foreground.

[0022]

[0031] Some embodiments may further detect various timing-related events, such as time gaps and / or intervals between events, i.e., periods of inactivity, i.e., when each client device is idle, has no user activity registered, or is performing only internal system tasks. Such periods of inactivity may be further differentiated into short gaps (e.g., of a few seconds) and long gaps (e.g., of a few minutes to a few hours). Other timing-related events may include, for example, sequences of events occurring in rapid successions / bursts of activity.

[0023]

[0032] Other examples of events that may be detected may include receiving and / or viewing certain types of content, such as SMS messages containing hyperlinks, login forms, payment interfaces, HTML documents containing advertisements, and so on.

[0024]

[0033] Exemplary events specific to or particularly relevant to mobile device security include screen toggling (on / off), changes to application labels / names / icons, and screen captures. Other examples include requests to grant specific types of permissions (e.g., management, accessibility), dynamically requested permissions (i.e., during various stages of execution, as opposed to installation), and granting persistence (e.g., foreground services dynamically started by each application). Still other examples include attempts to prevent the uninstallation of each application and displaying overlays on the OS settings interface (such overlays could deceive an unsuspecting user into granting unwanted permissions to each application).

[0025]

[0034] Event detection can be device type specific. In one example, where the client device 12 is a personal or laptop computer, as soon as the launch of the target application 24 is detected, the feature extractor 32 registers each application and / or its associated processes with the OS 22's event logging service (e.g., Event Tracking - ETW for Windows®, Syslog for UNIX®). In response, the extractor 32 may receive notifications of various events occurring during the execution of each process, either in real time or in log form. The event logging tool typically generates a list of event descriptors, including a timestamp for each event, a numeric code identifying the event type, an indicator of the type of process or application that generated each event, and other event parameters. In such embodiments, the extractor 32 may detect the occurrence of the target event by parsing each event log.

[0026]

[0035] In another example of event detection, the feature extractor 32 may modify a set of native OS22 functions by inserting redirection instructions (also known as hooks or patches). In this way, when a process running on the client device 12 calls each OS function, the execution is redirected to a callback routine that notifies the extractor 32 of the attempt to execute each OS function. When the hooked function becomes a means in the monitored event (e.g., file creation, process start, etc.), the attempt to call each function can act as an indicator of the occurrence of each event.

[0027]

[0036] In yet another example of event detection, electronic communications sent by each client device can be detected by installing a proxy module configured to intercept Domain Name Service (DNS) queries and / or HTTP requests sent by each client device.

[0028]

[0037] Some operating systems, such as those running on smartphones, wearables, and other devices, may not enable such operations. However, other tools may be available to detect the occurrence of various events. For example, some operating systems expose application programming interfaces (APIs) that enable things like registered callbacks for various notifications, inspecting network traffic, SMS / MMS operations, and detecting access to storage devices (e.g., SD cards). Some embodiments of the feature extractor 32 use the functionality of accessibility APIs to access on-screen content and detect user interactions with the respective devices and / or applications. Some embodiments may further employ artificial intelligence (e.g., natural language processing, computer vision, etc.) or other means of analyzing the content displayed on the screen.

[0029]

[0038] In some embodiments, the feature extractor 32 generates multiple key feature values ​​40, i.e., current values ​​of multiple features / attributes that characterize the software running on the client device 12 (e.g., the target application 24). Such values ​​can be numerical, string, Boolean, etc., depending on the type of feature. In typical embodiments, the number of key features is relatively large, for example, several hundred or several thousand, but this description generally applies to any number of key features.

[0030]

[0039] In some embodiments, the security application 30 further includes a malware detector 34 that receives key feature values ​​40 as input and determines a security decision 26 according to the feature values ​​40, the decision 26 indicating whether the client device 12 is equipped with malicious software. An exemplary decision 26 includes a Boolean label (e.g., yes / no) and the likelihood that each client is infected. The decision 26 may further include an identifier of the software entity deemed malicious (e.g., target application 24), an identifier of the type of malicious agent or malware, and a set of instructions to mitigate the effects of each infection.

[0031]

[0040] Figure 2 illustrates the structure and operation of an exemplary malware detector 34 according to several embodiments of the present invention. The detector 34 has a stacked or cascaded architecture in which multiple feature processors (FPs) 36a-d receive primary feature values ​​40 determined by a feature extractor 32 and output multiple derived feature values ​​44 determined according to the primary feature values ​​40. The derived feature values ​​then act as input to a second-level synthesizer module 38, which in turn determines a security decision 26 according to the derived feature values ​​44. When some derived feature values ​​44 are missing (cannot be determined for some reason), a data replacement module 37 fills in the missing values ​​with surrogate data 42, as detailed below. Although Figure 2 shows only two levels of feature processing, those skilled in the art will understand that this description generally applies to malware detectors with stacked feature processor levels, where each level receives the output of the previous level and feeds its own output to the next level of feature processors. For a description of such a multi-level architecture, see below in relation to Figure 8.

[0032]

[0041] In some embodiments, each major feature processor 36a-d is input a specific subset of feature values ​​40, i.e., a specific subset of features. In other words, each FP36a-d analyzes the software running on the client device 12 from the perspective of a selected subset of features. In the example shown in Figure 2, FP36a considers only major features F1-F6, while FP36b considers major features F4, F6, F7-F9, F 11 , and F 12 It processes only those features. However, this aspect is not intended to be limiting, and for example, some FPs may take the entire range of features as input. The subsets of features analyzed by each FP36a~d may overlap, as in the exemplary embodiment shown in Figure 2, where both FP36a and 36b use features F4 and F6.

[0033]

[0042] Each feature processor 36a-d calculates a specific set of derived feature values ​​44 according to its respective input. In the example in Figure 2, FP36a determines derived feature D1 according to the current values ​​of the primary features F1-F6. The derived feature 44 may include any features that characterize the software running on the client device 12 (e.g., target application 24). In one exemplary embodiment, each FP36a-d outputs a derived feature value indicating the probability that the client device 12 contains malware. In such an example, even though all feature processors 36a-d output the same kind of information, namely partial security decisions, each such partial decision may be determined according to a distinct subset of the primary features.

[0034]

[0043] In some embodiments, each FP36a-d embodies a separate malware detection algorithm, procedure, etc. Exemplary FP36a-d may implement various malware detection heuristics, including signature matching and decision trees. Other exemplary FP36a-d may implement automated classifiers based on clustering algorithms (e.g., K-means, K-nearest neighbors), statistical techniques (e.g., Bayesian methods), support vector machines (SVMs), and / or Markov algorithms. Some classes / clusters may be associated with harmless behavior, while others may be associated with malware. In embodiments using artificial intelligence (AI) techniques, some FP36a-d may include an artificial neural network (NN) pre-trained to determine whether a client device contains malware according to a specific subset of features. Some such NNs may be trained to detect specific malware types (e.g., ransomware, malware that steals bank or credit card details, compressed / encrypted malware, etc.).

[0035]

[0044] Several NN architectures and strategies for training NNs as malware detectors are known in the art. A simple example of a FP involves a feedforward network trained to determine a label indicating malware according to a subset of key feature values. Another class of FP examples, known as autoencoders, can be trained to perform lossy compression and subsequent recovery of a subset of key feature values. Some embodiments can train an autoencoder on data acquired during the execution of harmless software, and can also use discrepancies between the autoencoder's inputs and outputs as indicators of anomalous, and therefore potentially malicious, application behavior. Some FP36a-d may use neural networks specialized for text and natural language processing to analyze features extracted from Android® manifest files and / or user interfaces. Such FPs may implement recurrent neural networks (RNNs), long short-term memory (LSTM) architectures, etc. Other example FP36a-d may use NNs specialized for image processing (among others, convolutional neural networks) to analyze screen snapshots and / or image files received or sent by each client device. The specific architecture and functional details of such NN-based feature processors are beyond the scope of this description.

[0036]

[0045] In yet another exemplary embodiment, several FP36a~d can compute projections of a subset of the principal features onto an abstract vector space, the projections are generally known as embeddings. Taking the exemplary example in Figure 2, the derived feature values ​​D2, D3, and D4 can be the coordinates of points in the abstract 3D embedding space, and each coordinate can be the principal features F4, F6, F7, F8, F9, F 11 , and F 12It is determined according to the current value. Each embedding space can be constructed through machine learning procedures, and the parameters of each feature processor / neural network are tuned to satisfy a given goal, such as minimizing a cost function determined according to the inputs and outputs of each FP. An example embedding space can be one in which all instances of malware are clustered together.

[0037]

[0046] In some embodiments, the synthesizer module 38 is configured to receive an input array 46 of derived feature values ​​computed by feature processors 36a-d, and to determine a security decision 26 according to each derived feature value. Module 38 can implement any malware detection or determination method known in the art. In a simple example where each derived feature value 44 indicates a partial determination / possibility of being malicious, module 38 may determine the enhanced security decision as a weighted sum of the individual derived feature values ​​44. Each weight may reflect a certain degree of relevance or reliability for each respective partial determination. Another example of the synthesizer module 38 implements a decision tree, where each node tests a condition according to a subset of derived feature values ​​44. In a more complex example, the synthesizer module 38 may include a set of pre-trained neural networks configured to map the input array 46 to labels indicating that something is malware, or to numbers indicating the likelihood that device 12 is malware-bearing. The architecture of such an AI module is configured to map the input type to features D evaluated by the upstream feature processors. i It may depend on the type.

[0038]

[0047] For various reasons, not all key feature values ​​40 may be available. For example, evaluating some key features may require specific OS settings or permissions that are not currently activated on each client device. Some key feature values ​​may not be computable at all times, in all geographic locations, on all carrier networks, etc. Evaluating some features may require an internet connection that is actually available and may not be currently available. Evaluating some key features may require additional software that is not installed on each device. Some key features may be particularly costly to evaluate, and therefore some embodiments may postpone the evaluation of such features to a predetermined time interval, etc., during periods of relatively low user activity. In Figure 2, available key feature values ​​40 are represented as black circles, and currently unavailable feature values ​​are represented as white circles. For example, the current values ​​for features F1 and F9 are available, and features F7 and F 11 Some features may not be able to be evaluated, and therefore each feature value will be missing.

[0039]

[0048] In some embodiments, a feature processor whose input is incomplete or unavailable will not execute or produce a valid output. In the exemplary embodiment of Figure 2, the values ​​of derived features D2, D3, and D4 are the same as the primary features F7, F8, and F 11 Since it could not be evaluated, it is unavailable. Similarly, the value of derived feature D7 is missing because one of the primary feature values ​​that goes into feature processor 36d is currently unavailable. Some FPs may fail to execute for other reasons, such as occasional errors, exceptions, or crashes. In another example, the execution of some FPs (e.g., FPs that are particularly demanding on computing resources) may be interrupted or postponed so as not to affect the user experience. Missing / unavailable feature values ​​may be represented programmatically using any method known in the art, such as NULL, N / A, NaN, or a specific error code.

[0040]

[0049] In some embodiments, when some of the inputs to the synthesizer module 38 are unavailable, the data replacement module 37 replaces the missing derived feature values ​​with surrogate values ​​42 in the array 46. Filling in the missing inputs thus ensures that the synthesizer module 38 can execute and generate a decision 26 even when some individual feature processors are unavailable. In such situations, the synthesizer module 38 determines the security decision 26 according to the available derived feature values ​​44 and further according to the surrogate feature values ​​42 supplied by module 37.

[0041]

[0050] The surrogate value 42 is represented as a hatched circle in Figure 2. The term “surrogate” as used herein indicates that each value is not determined by a local instance of the respective feature processor according to locally calculated primary feature values, but is instead supplied from an alternative source. In some embodiments, the data replacement module 37 selectively retrieves the surrogate value 42 from a repository shown as the security database 20 in Figure 1. The database 20 may reside on a computer-readable medium that forms part of the client device 12 or is communicably coupled to it. Alternatively, in some embodiments, the surrogate value may be retrieved from a remote security server, as further detailed below.

[0042]

[0051] In some embodiments, the surrogate value 42 is deliberately chosen to represent the current status and / or state of the client device 12. Thus, some embodiments of the database 20 may store a number of reference values ​​for each derived feature, each reference value associated with an identifier for the respective derived feature and further associated with a state indicator indicating the state of the device that generated the respective reference value. Exemplary state indicators may include, among others, an indicator of the device type (e.g., a specific manufacturer and model of smartphone), an indicator of the operating system type and version, a timestamp indicating the point in time when each value was calculated, a location indicator (e.g., geographic location, network address, etc.), and a set of identifiers for software applications installed and / or running when each feature value was calculated (e.g., a consistency hash). Other exemplary state indicators may include the primary feature value used in determining each surrogate value. In one exemplary embodiment, the database 20 stores a collection of records, each record comprising a reference value and a set of metadata indicating the device state. The database 20 and individual records may use any format and data structure known in the art that allows for the selective retrieval of the surrogate value 42 according to the device state. Further details regarding the calculation and / or acquisition of surrogate features are provided below.

[0043]

[0052] Figure 3 shows an illustrative sequence of steps performed by the malware detector 34 according to several embodiments of the present invention. In some embodiments, the feature extractor 32 may evaluate key features sequentially. Alternatively, the operation of the extractor 32 may be initiated by a predetermined launch event, such as the launch of a target application 24 or the launch of an activity that indicates it is suspicious or malware, or as soon as a period of user inactivity is detected. In yet another embodiment, the feature extractor 32 may attempt to evaluate various key features at predetermined points in time, for example, according to a schedule or periodicity. In any such case, the malware detector 34 may receive a set of key feature values ​​40 from the feature extractor 32 (step 302).

[0044]

[0053] In response, the detector 34 may attempt to execute feature processors 36a-d to compute their respective derived feature values. In the sequence of steps 304-306-308, all feature processors are selected and executed. When the detector 34 has multiple layers of feature processors (see, for example, Figure 8 and the related description below), all levels can be executed incrementally, with each feature processor receiving input from other feature processors upstream. In some embodiments, each feature processor may run independently and asynchronously, for example, in a parallel computing configuration. For example, the client device 12 may maintain a pool of processor threads reserved for feature processing, in which case the malware detector 34 may wait until a thread becomes available and assign each thread to an unprocessed feature processor, thereby releasing each thread as soon as it completes its job.

[0045]

[0054] Step 310 may check whether the calculation of the derived feature values ​​44 was successful, or in other words, whether the output of each FP is available. Each FP may fail to produce an output, for example, because at least one of the primary feature values ​​required as input to each feature processor is not currently available, or because each FP has crashed. In response to the failure of the calculation of at least one derived feature value, in step 312, the data replacement module 37 may supply surrogate values ​​to replace the respective missing derived feature values. In various embodiments as described below, supplying surrogate values ​​may involve locally occurring, retrieving, and / or requesting the respective values ​​from remote services.

[0046]

[0055] In some embodiments, module 37 may be configured to generate surrogate feature values ​​according to prior knowledge of each derived feature. In one such example using a variation of Gaussian data regression, previously collected data from the client and / or test device is used to calculate various statistics for each derived feature, such as the typical range, mean, and standard deviation. Each statistic can then be sent to each client device or instance of the malware detector 34, which can then generate surrogate values ​​having the desired statistics. The Gaussian distribution is shown herein as an example and is not limiting. In some embodiments, the collected data may be fitted to other distributions (e.g., Student's distribution, multimodal distribution, etc.). In other embodiments, a clustering algorithm such as K-means can be used to distribute the data collected from the client and / or test device into a set of clusters, each cluster may be defined by a feature set of parameters such as center and radius. Such cluster parameters can then be sent to each client device or instance of the malware detector 34, which can then determine the surrogate data according to their respective cluster parameters. In one such example, module 37 may generate random surrogate values ​​depending on whether each value is closer to the cluster center than the radius of the respective cluster. In another example, module 37 may select the cluster center coordinates as the surrogate value.

[0047]

[0056] In some embodiments, step 312 may include formulating a query to the database 20 and / or to a remote security server, and receiving surrogate feature values ​​in response. Each surrogate value may be pre-calculated based on previous observations and / or data taken from other client devices and / or test devices, as further described below.

[0048]

[0057] In some embodiments, the data replacement module 37 may look up / request surrogate values ​​according to the current state of the client device 12. The device state may include, among other things, indicators of the device type, manufacturer, and model, indicators of the OS 22 type and version, identifiers of various software currently installed and / or running on the device 12 (e.g., identifier of the target application 24), and others. Other query criteria may include the current location of the client device 12 (e.g., geographic location, network domain). Alternatively or additionally, in step 312, the module 37 may formulate the query / request according to the current values ​​of a subset of the main features, e.g., at least some of the main features used in the calculation of the respective missing derived feature values. In one such example using the representation in Figure 2, the request for a surrogate value for derived feature D2 may explicitly include, or otherwise, main features F4, F6, F9, and F 12 It can be formulated according to the current value of .

[0049]

[0058] In some embodiments as described above, the database 20 stores multiple records indexed according to device state and / or other criteria, which allows for the selective retrieval of relevant surrogate feature values. Sometimes, a query may return multiple matching values ​​for each type of feature. For example, there may be multiple database records that partially match the device state parameter of each query. When multiple surrogate values ​​are available for a selected derived feature, in step 312, module 37 may select one according to a predetermined criterion. For example, in some embodiments, the mean or median of the available surrogate values ​​can be calculated, or the maximum or minimum of the available surrogates can be selected.

[0050]

[0059] In step 314 (Figure 3), the detector 34 can assemble an input for the synthesizer module 38, for example, an input array 46 as shown in Figure 2, the array 46 consisting of derived feature values ​​44 arranged in a predetermined order, where any derived feature values ​​that are missing or could not be computed are always filled in with surrogate data. In the example in Figure 2, the surrogate feature values ​​42 substitute for the missing values ​​of derived features D2, D3, and D4. In some embodiments, the array 46 may further include data indicating other malware, such as amounts computed according to primary feature values, derived feature values, and possibly other data.

[0051]

[0060] A further step 316 may involve executing the synthesizer module 38 to determine a security decision 26 according to the input array 46. If the decision 26 does not indicate the presence of malware, some embodiments of the detector 34 may return to step 302 to perform another cycle of malware detection calculations, for example. Otherwise, in step 320, some embodiments may perform several malware mitigation steps, such as notifying the user or administrator of the respective device, interrupting the execution of the suspected malicious software (e.g., target application 24), and so on. The exemplary warning displayed to the user may include a hyperlink to the online description of each malware agent and instructions to recover from its effects (e.g., instructions to remove the respective malicious application, change various operating system settings, etc.).

[0052]

[0061] Some embodiments may further send a report to a remote security server, for example, an indicator of the current device state of the client device 12, and / or a set of primary and / or derived feature values ​​used in the calculation of determination 26. Such reports may be analyzed and used to keep pace with evolving threats and to develop new anti-malware tools and strategies.

[0053]

[0062] The embodiments described above largely involve “standalone” client devices that run local instances of their own detectors 34 and store instances of the security database 20 in a locally computer-readable medium. However, those skilled in the art will understand that such configurations are illustrative and not limiting. In alternative embodiments, the detectors 34 may run on a remote server and communicate with client devices 12 through messages compliant with the Client-Server Protocol. In one such example shown in Figure 4, a group of client devices 12a-d are connected to a communication network 15, which may include a local area network (e.g., a home network, a corporate network), a wide area network, and / or the Internet. The network 15 generally represents a set of hardware (physical layer) and software interfaces that enable the transfer of data between devices 12a-d and other entities connected to the network 15.

[0054]

[0063] Figure 4 further illustrates a security server 14 connected to a communication network 15. The server 14 generally represents a set of communicateable computer systems that may or may not be physically close to each other. As further shown in Figure 5, in some embodiments, the server 14 protects all client devices 12a-d from malware by receiving key feature values ​​40 from each client, running a malware detector 34 to calculate a security determination for each, and returning a determination 26 to each client.

[0055]

[0064] In yet another alternative embodiment shown in Figure 6, instead of locally hosting a repository of surrogate feature values, the client device 12 may request surrogates from the security server 14. This, in turn, may enable the server 14 to run a surrogate generator 50 configured to maintain a centralized version of the security database 20 containing surrogate feature values ​​indexed according to the device states or other criteria described above. Configurations such as those shown in Figure 6 may be preferable to those shown in Figure 1 because they avoid transferring the contents of the database 20 to each protected client, and the centralized system typically responds more quickly to emerging threats. However, the client-server communication required for operation in such configurations may substantially slow down the operation of the client-side malware detector 34.

[0056]

[0065] Figure 6 further illustrates an exemplary exchange in which client 12 sends a data request 48 to server 14 and receives a surrogate value 42 in response. The data request 48 may be formulated to allow selective retrieval of surrogates, for example, according to the feature type of each feature, according to the device type and / or the current device state of each client, and / or according to other criteria such as the current location of each client (geographic location, network domain, etc.). In some such embodiments, the data request 48 may include device state data and / or a set of key feature values ​​40 of client 12.

[0057]

[0066] In some embodiments, the data request 48 may include a client identifier that enables the server 14 to associate the client 12 with a client-specific account or service consent agreement, which may represent various client-specific security settings, such as the false-positive tolerance rate. Each client identifier may be further associated with device type data that characterizes each client device 12, such as the device type, manufacturer, and model, the type and version of the OS 22, a list of applications currently installed on the device 12, and so on. Some embodiments of the server 14 may then use such information to customize the retrieval of surrogate data for each client device.

[0058]

[0067] Figure 7 illustrates an exemplary process for generating surrogate feature values ​​according to several embodiments of the present invention. In one exemplary policy, a security server 14 may collect derived feature values ​​44 remotely calculated by protected client devices 12a-e and then use them as surrogate values ​​for provision to requesting clients. To further enable association between feature values ​​44 and device states, in some embodiments, the client further pairs a set of values ​​44 with a device state indicator 54 that indicates the device state when the value 44 was calculated. For example, the state indicator 54 may include a set of primary feature values ​​40 used to calculate the derived feature value 44. In one exemplary embodiment, as shown in Figure 6, the state indicator 54 and the feature value 44 are bundled together in an activity report 52a, which may be sent by the client device 12 according to a schedule or in response to the malware detection procedure described above in relation to Figure 3.

[0059]

[0068] Server 14 may further receive a device profile 28 from each client, which includes a client identifier and a set of data characterizing the hardware and / or software configuration of each client (e.g., device type, manufacturer, model, OS version, various current settings, etc.). Server 14 may then use this information to associate the collected feature values ​​44 with a specific device type and / or configuration.

[0060]

[0069] As an alternative or addition, some embodiments use a set of test devices 18 to compute derived feature values ​​44 in various hardware and software configurations. In some embodiments, the test device 18 comprises an instance of a mobile computing device, such as a smartphone or tablet computer, and the device 18 acts as a substitute for a protected client. One example of the test device 18 consists of a physical device, e.g., a mobile phone of a specific make and model, having a specific hardware and / or software configuration and communicatively coupled to the security server 14. Another example of the test device 18 comprises an emulation of a physical device, i.e., a set of software modules that replicate the behavior of a real, physical device, such as a smartphone. In one such example, the various software components of the test device 18 run within a sandbox (isolated container). In other exemplary embodiments, the test device 18 may include a virtual machine, or comprise an abstraction / virtualization of each client device, and the virtual machine has the ability to run an operating system and the set of target and security applications described above in relation to Figure 1. Some test devices 18 may operate as a web service, for example, as part of a device farm. Some such services are commercially available.

[0061]

[0070] In some such embodiments, server 14 can remotely configure test device 18 with specific hardware and software characteristics and can remotely initiate execution of malware detectors on each device. Some such tests can investigate the behavior of test device 18 when running various target applications, some of which are known to be harmless and some of which are known to be malicious. As a result of each execution, server 14 can collect a set of derived feature values computed by test device 18 in the form of activity report 52b, which can further include, for example, relevant device states and / or other data. Some embodiments can then index, annotate, and store the collected derived feature data in security database 20 for further transmission to the requesting client as surrogate value 42.

[0062]

[0071] Database 20 can be formatted and stored according to any standard known in the art. Exemplary database formats include, among others, relational databases, extensible markup language (XML) documents, spreadsheets, and key-value stores. Server 14 and / or client devices can be configured to selectively retrieve and / or insert data into database 20, for example, using structured queries.

[0063]

[0072] By collecting large amounts of data from protected clients and / or test devices, server 14 can further determine reliable statistics for each derived feature D i , such as typical values and / or typical ranges for each feature. Server 14 can fit various types of statistical distributions (e.g., Gaussian regression) to the collected data, thereby determining other statistical characteristics such as mean values, standard deviations, expected values, and the like. Such data can then be used on demand by some embodiments of malware detector 34 to generate surrogate value 42 using similar characteristics.

[0064]

[0073] The exemplary malware detector 34 shown in Figure 2 has only two layers, with the first layer of feature processors 36a-d feeding into the second layer consisting of a synthesizer module 38. However, those skilled in the art will understand that the systems and methods described above can be adapted to stacked malware detectors having more than two layers. Figure 8 shows an exemplary malware detector 134 according to several embodiments of the present invention, the detector 134 consisting of a stack / cascade of N layers, each layer i comprising a set of feature processors 36 that receive input from the upstream layer i-1 and compute a set of derived feature values ​​44 according to each input. Each derived feature value is then passed as input to the next layer (i+1) of the feature processor 36. The type and number of feature processors 36 can vary between layers as shown. In one exemplary embodiment, each feature processor 36 comprises a separate pre-trained artificial neural network. The feature processor in layer 1 takes primary feature values ​​40 as input. At the other end of the cascade, the output of layer N-1 is sent as input to the synthesizer module 38, which in turn outputs the security determination 26.

[0065]

[0074] When some of the primary feature values ​​40 are missing, some feature processors 36 that depend on their respective inputs cannot be executed, and therefore some derived feature values ​​44 may also be missing. In such cases, the data replacement module 37 fills in the missing derived feature values ​​with surrogate values ​​42 so that a complete input array 46 is generated for the synthesizer module 38. Such surrogate supplementation can be performed at any level from cascade 1 to N-1. However, the preferred embodiment shown in Figure 8 supplies the surrogate values ​​42 only to the output of the N-1 layer.

[0066]

[0075] The above description illustrates various methods and algorithms that can be embodied as computer programs executed by general-purpose hardware processors. However, those skilled in the art will understand that each function can also be implemented using dedicated hardware components such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs), or using a combination of hardware and software. Figure 9 shows an exemplary hardware configuration of a computer system 80 programmable to perform some of the methods and algorithms described herein. The configuration shown is general and could represent any of the client devices 12a-d and / or the security server 14. Those skilled in the art will understand that some types of hardware configurations of devices (e.g., mobile phones, smartwatches, servers, routers) may differ somewhat from those shown in Figure 9.

[0067]

[0076] The computer system described comprises a set of physical devices, including a hardware processor 82 and a memory unit 84. The processor 82 comprises a physical device (e.g., a microprocessor, a multicore integrated circuit formed on a semiconductor substrate, etc.) configured to perform computations and / or logical operations using a set of signals and / or data. In some embodiments, such operations are specified to the processor 82 in the form of a sequence of processor instructions (e.g., machine code) that encodes an algorithm for performing some of the methods described herein. The memory unit 84 may comprise a volatile computer-readable medium (e.g., DRAM, SRAM) for storing instructions and / or data accessed or generated by the processor 82.

[0068]

[0077] The input devices 86 may include, among other things, a computer keyboard, mouse, and microphone, including their respective hardware interfaces and / or adapters that enable the user to input data and / or instructions into the computer system. The output devices 88 may include, among other things, display devices such as monitors and speakers, as well as hardware interfaces / adapters such as graphics cards that enable the indicated computing equipment to communicate data to the user. In some embodiments, the input devices 86 and output devices 88 share common hardware parts, as in the case of a touchscreen device. The storage devices 92 include computer-readable media that enable non-volatile storage, reading, and writing of software instructions and / or data. Exemplary storage devices 92 include magnetic and optical disks, flash memory devices, as well as removable media such as CDs and / or DVD disks and drives. A set of network adapters 94, along with associated communication interfaces, enables the indicated computer system to connect to a communication network 15 (Figure 4) and / or other devices / computer systems. The controller hub 90 collectively represents all other circuits that enable communication between multiple systems, peripherals, and / or chipset buses, and / or between processor 82 and devices 84, 86, 88, 92, and 94. For example, the controller hub 90 may include, among other things, a memory controller, an input / output (I / O) controller, and an interrupt controller. In another example, the controller hub 90 may include a northbridge connecting processor 82 to memory 84, and / or a southbridge connecting processor 82 to devices 86, 88, 92, and 94.

[0069]

[0078] The exemplary systems and methods described above enable the protection of electronic devices and their users against malicious software. Some of the methods and systems described are particularly suitable for mobile computing devices, such as smartphones, tablet computers, and wearable computers. Such mobile devices typically have substantially less computing power, memory, and storage than other computer systems such as personal computers and servers, and therefore may present certain challenges to conventional computer security paradigms.

[0070]

[0079] Some traditional anti-malware software analyzes program code (e.g., memory images) to look for patterns or snippets known to be malicious. Other traditional anti-malware methods involve monitoring software behavior by detecting the occurrence of selected events and applying a set of rules and / or calculations to the detected events to determine whether each device is infected. Recent advances in machine learning enable the effective analysis of data using artificial neural networks. In a typical example of such a technique, a set of neural networks is configured to analyze an array of features that characterize target software and determine whether each piece of software is malicious. The neural networks are pre-trained on a corpus containing known malicious and harmless samples. In some cases, the number of input features can be very large (hundreds to thousands of distinct features, including static and behavioral features, as mentioned above).

[0071]

[0080] However, evaluating such features may not be technically straightforward, especially for mobile computing devices such as smartphones and other wearable computing devices. The computations required for both memory inspection and observing application behavior can consume considerable resources and thus negatively impact the user experience. Some event detection methods, such as hooking various OS functions, may not be usable for all operating systems and device types. Furthermore, evaluating some features may require specific OS settings, such as certain permissions that cannot be granted to all devices. Some features may not be available at all times or in all places. Therefore, applying some of the conventional anti-malware methods described above to mobile computing platforms may be impractical.

[0072]

[0081] Some embodiments of the present invention explicitly address these drawbacks and thereby enhance the security of mobile computing devices. In some embodiments, a feature extractor attempts to evaluate several features that characterize the hardware and software of a client device. The resulting set of key feature values ​​is then fed into several feature processors, arranged in a multi-level cascade, where each level receives input from the next upstream level, which in turn supplies input to the next downstream level (see the illustrative architectures in Figures 2 and 8). At the final level of the feature processor stack, a synthesizer module outputs a security determination indicating whether each client device has malicious software.

[0073]

[0082] In some embodiments, each feature processor comprises a set of pre-trained neural networks configured to receive a subset of derived feature values ​​available at each level of the cascade. In a simple example constructed as shown in Figure 2, each feature processor may comprise a neural network configured to determine whether each client possesses malware according to a distinct subset of primary feature values. In other words, each feature processor can assess target software and generate distinct decisions from a distinct "perspective," i.e., according to distinct criteria. To employ an analogy from image processing, each feature processor could analyze distinct aspects of an image (i.e., a set of primary feature values) to determine whether each image represents a particular object (e.g., a bicycle), with one feature processor considering edge information and another considering image segmentation data. Independent assessments can then be combined by a synthesizer module to generate an integrated assessment of the primary feature data.

[0074]

[0083] Some conventional malware detectors feed the entire set of key feature values ​​into a single neural network. In contrast, some embodiments of the present invention, as described above, split the input among multiple, smaller feature processors / neural networks. Such splitting has at least two advantages. Firstly, the computational cost of training and running neural networks typically scales with the square of the input size, and therefore smaller networks can be substantially cheaper to train and use than larger ones. This is particularly true for anti-malware activities, where successful detection may require analyzing hundreds or thousands of distinct input parameters.

[0075]

[0084] Secondly, some key feature values ​​may not always be available for any of the reasons outlined above. An architecture that relies on a single neural network configured to consider all features of the input data can therefore always fail when at least one of the required features is missing. In contrast, as described herein, dividing the input data between multiple, smaller feature processors / networks makes it possible to run at least one feature processor whose input is available.

[0076]

[0085] In some embodiments of the present invention, surrogate data is supplied to substitute for missing feature values. However, instead of replacing any missing primary feature values, in some embodiments, surrogate data is used to replace derived feature values ​​that cannot be computed due to missing primary feature values. In other words, in some embodiments of the present invention, surrogate supplementation is performed at an intermediate level of the feature processor cascade. In preferred embodiments, surrogate feature values ​​are supplied as input to the synthesizer module to ensure that each module can always run (see, for example, Figures 1 and 8).

[0077]

[0086] This choice is intentional and offers significant advantages over other measures to mitigate missing inputs. Some embodiments rely on the observation that feature processors, such as neural networks, result in a significant reduction in dimensionality. In other words, the output size of a typical feature processor can be orders of magnitude smaller than the size of its inputs. In the exemplary embodiment shown in Figure 2, feature processor 36a takes six primary feature values ​​as input and outputs only one derived feature value D1. This means that the number of derived feature values ​​44 is generally expected to decrease down the cascade of stacked feature processors, as shown in Figure 8. A typical input to the synthesizer module 38 can be 20-30 elements long, and the size of the primary feature vector 40 can be hundreds or thousands.

[0078]

[0087] Therefore, solving the problem of missing inputs according to some embodiments of the present invention may require supplying only a relatively small number of surrogate feature values ​​42. In contrast, solving the problem at the primary feature level may require supplying a much larger number of missing values, some of which may be difficult or impractical to determine. Furthermore, supplying surrogates at an intermediate or final level (rather than the primary level) of the feature processor stack / cascade removes the computational burden that would normally be used to compute the feature values ​​currently supplied as surrogates, which would actually run the feature processor.

[0079]

[0088] Some embodiments further rely on the observation that derived feature values ​​44 (i.e., feature values ​​determined at intermediate levels of FP stacking / cascading) typically have substantially lower diversity compared to primary feature values ​​40. This is derived from the general tendency of neural networks to infer and generalize. In one exemplary embodiment, a feature processor 36 may be trained to analyze the web pages currently displayed on the screen of a client device 12 in order to determine whether each web page is an electronic banking interface. Since the appearance and functionality of such interfaces differ substantially between one financial institution and another, there is substantially greater diversity in the inputs than in the respective FP outputs. At the primary feature level, supplying surrogate inputs requires generating surrogate web pages / HTML documents, which is substantially more computationally expensive than supplying surrogate outputs (i.e., banking or non-banking).

[0080]

[0089] In some embodiments, a surrogate threshold is used for each derived feature, which is determined by other protected client devices and / or by test devices with similar hardware and / or software configurations as the client runs each instance of the malware detector. Such thresholds may be centrally collected by a security server computer system and supplied on demand to requesting clients. In other embodiments, such data collected from clients and / or test devices is used to determine various statistics (mean, standard deviation, etc.) for each derived feature, and then random surrogate data is generated according to the determined statistics.

[0081]

[0090] Those skilled in the art will see that the above embodiments can be modified in many ways without departing from the scope of the invention. Accordingly, the scope of the invention should be determined by the following claims and their legal equivalents.

Claims

1. Using at least one hardware processor of a computer system, A step of executing a plurality of feature processors configured to determine a plurality of derived feature values ​​according to a plurality of primary feature values ​​that characterize a software entity running on the computer system, wherein a selected feature processor is configured to determine a selected derived feature value according to a selected subset of the plurality of primary feature values. In response, the steps include determining whether the selected derived feature value is missing, If affirmative, the steps include supplying a surrogate value to replace the missing selected derived feature value, A step of determining whether the software entity is malicious, according to derived feature values ​​determined by the plurality of feature processors, and further according to the surrogate feature values. Malware detection methods, including those mentioned.

2. A method according to claim 1, wherein the selected derived feature value quantifies the likelihood that the software entity is malicious.

3. A method according to claim 1, wherein the step of supplying the surrogate value includes the step of calculating the surrogate value using the at least one hardware processor according to a reference value determined by another instance of the selected feature processor.

4. A method according to claim 3, wherein the step of supplying the surrogate value includes the step of calculating the surrogate value according to a statistic of a plurality of reference values, the plurality of reference values ​​being determined by other instances of the selected feature processor.

5. A method according to claim 1, wherein the step of supplying the surrogate value includes the step of selectively retrieving the surrogate value from a database storing a plurality of reference values ​​determined by other instances of the selected feature processor.

6. A method according to claim 5, comprising the step of selecting the surrogate value from a plurality of reference values ​​according to the current state of the computer system.

7. A method according to claim 5, comprising the step of selecting the surrogate value from a plurality of reference values ​​according to the device type of the computer system.

8. The method according to claim 1, wherein the step of supplying the surrogate value is: A step of sending a data request to a remote security server using at least one hardware processor of a computer system, wherein the data request is formulated according to an indicator of the current state of the computer system; In response, the steps include receiving the surrogate value from the remote security server and Methods that include...

9. A method according to claim 8, wherein the data request includes at least one value of the plurality of principal feature values.

10. A method according to claim 1, wherein each of the plurality of feature processors includes a neural network trained to determine the maliciousness of the software entity according to each subset of the plurality of primary feature values.

11. A computer system having at least one hardware processor, wherein the at least one hardware processor is A plurality of feature processors configured to determine a plurality of derived feature values ​​according to a plurality of primary feature values ​​that characterize a software entity running on the computer system, wherein a selected feature processor is configured to determine a selected derived feature value according to a selected subset of the plurality of primary feature values, A data replacement module connected to the plurality of feature processors, To determine whether the selected derived feature value is missing, In response, if affirmative, a surrogate value is supplied to replace the missing selected derived feature value. A data replacement module configured to perform the following: A synthesizer module configured to determine whether the software entity is malicious according to derived feature values ​​determined by the plurality of feature processors, and further according to the surrogate feature values, A computer system configured to run.

12. A computer system according to claim 11, wherein the selected derived feature value quantifies the likelihood that the software entity is malicious.

13. A computer system according to claim 11, wherein supplying the surrogate value includes using the at least one hardware processor to calculate the surrogate value according to a reference value determined by another instance of the selected feature processor.

14. A computer system according to claim 13, wherein supplying the surrogate value comprises calculating the surrogate value according to a statistic of a plurality of reference values, the plurality of reference values ​​being determined by other instances of the selected feature processor.

15. A computer system according to claim 11, wherein supplying the surrogate value includes selectively retrieving the surrogate value from a database storing a plurality of reference values ​​determined by other instances of the selected feature processor.

16. A computer system according to claim 15, wherein the data replacement module is configured to select the surrogate value from the plurality of reference values ​​according to the current state of the computer system.

17. A computer system according to claim 15, wherein the data replacement module is configured to select the surrogate value from the plurality of reference values ​​according to the device type of the computer system.

18. The computer system according to claim 11, wherein the supply of the surrogate value is Sending a data request to a remote security server, wherein the data request is formulated according to an indicator of the current state of the computer system, and sending In response, the system receives the surrogate value from the remote security server. A computer system, including a computer system.

19. A computer system according to claim 18, wherein the data request includes at least one value of the plurality of principal feature values.

20. A computer system according to claim 11, wherein each of the plurality of feature processors includes a neural network trained to determine the maliciousness of the software entity according to each subset of the plurality of primary feature values.

21. A non-temporary computer-readable medium storing instructions, wherein when an instruction is executed by at least one hardware processor of a computer system, the computer system... A plurality of feature processors configured to determine a plurality of derived feature values ​​according to a plurality of primary feature values ​​that characterize a software entity running on the computer system, wherein a selected feature processor is configured to determine a selected derived feature value according to a selected subset of the plurality of primary feature values, A data replacement module connected to the plurality of feature processors, To determine whether the selected derived feature value is missing, In response, if affirmative, a surrogate value is supplied to replace the missing selected derived feature value. A data replacement module configured to perform the following: A synthesizer module configured to determine whether the software entity is malicious according to derived feature values ​​determined by the plurality of feature processors, and further according to the surrogate feature values, A non-temporary computer-readable medium that forms a [unclear].

Images