Stacked malware detector for mobile platforms
By adopting multi-level feature processor stacking and data replacement module methods on mobile computing platforms, feature selection and availability issues in malware detection are solved, and fast and effective malware detection is achieved, improving the accuracy and efficiency of detection.
Patent Information
- Application Number
- CN202380071429.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-10-26
- Filing Date
- 2023-10-24
- Publication Date
- 2025-05-13
AI Technical Summary
The prior art faces feature selection and availability issues when detecting malware on mobile computing platforms, making it difficult to find reliable malware indicator features, and some features may be unavailable or have high computational costs, affecting the user experience.
Multiple feature processors are employed to ensure robustness and scalability of malware detection by configuration to determine the derived feature values based on the main feature values of the software entity and to fill in the missing feature values with a data replacement module in the feature processor cascade.
Through the combination of multi-level feature processor stacking and data replacement modules, the ability to quickly and efficiently detect malware on mobile computing platforms is achieved, reducing dependence on feature availability, and improving detection accuracy and efficiency.
Smart Images

Figure CN119998804A_ABST
Abstract
Description
Background Art
[0001] The present invention relates to computer security and, in particular, to protecting users and devices from malicious software.
[0002] Malicious software, also known as malware, affects a large number of computer systems around the world. Malware, in its many forms such as computer viruses, spyware, and ransomware, poses a serious risk to millions of computer users, making them vulnerable to fraud, loss of data and sensitive information, identity theft, and loss of productivity, among others. The explosive growth of mobile computing has only exacerbated computer security risks, with millions of devices such as smartphones and tablets always connected to the Internet and serving as potential targets for malware. Specifically, on mobile platforms, malware may masquerade as genuine applications, including games, news, and messaging platforms, thereby tricking unsuspecting users into installing them. In some cases, users may be completely unaware of any malicious activity occurring beneath the surface of a seemingly legitimate and fun interface.
[0003] Conventional methods of protecting against malware include executing security software on the corresponding device. Detection methods typically include static analysis, in which the target software is compared to a library of malware-indicating 'code signatures', and behavioral analysis, in which the security software monitors the target software for indications of malicious behavior. In response to detecting a malicious agent, the security software may isolate or prevent its further execution. Due to recent developments in artificial intelligence (AI) and machine learning (ML), some modern malware detectors currently rely on various types 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 characterizes a target software entity and outputs a label indicating whether the corresponding target software is malicious.
[0004] However, such AI methods face huge technical challenges. One example is the selection of input features. Typically, there are no obvious or universal criteria for selecting which features of target software are more likely to reveal maliciousness and / or distinguish malicious from benign behavior. Mobile computing platforms (smartphones, wearable devices, etc.) and Internet of Things (IoT) devices show significantly more variability in hardware and software than personal computers. Therefore, it may be difficult to find malware indicator features that work reliably across such a heterogeneous set of devices. In addition, some features may not be reliable indicators of maliciousness because the same software application may behave differently on different devices, depending on the local operating system settings and the permissions granted on each device.
[0005] Other reasons why software applications exhibit device-specific behavior are deliberate attempts by sophisticated malware to evade countermeasures. For example, some malware avoids malware-indicative behavior for long periods of time, tricking security software into classifying it as benign. Some malware may tailor its behavior based on the type of device (e.g., smartphone vs. tablet, one manufacturer or model vs. another), the type of operating system, the current geographic location of the respective device, etc. Some malware further selects its victims by searching the respective device for indicators of the user's value to the attacker. For example, malware may determine what other software is currently installed on the respective device and search for specific applications (e.g., banking, social media, etc.). Other malware may monitor the user's patterns of accessing various applications, online resources, etc. Such malware may then only launch attacks on carefully selected devices and / or carefully selected users when the respective attack is deemed more likely to pay off.
[0006] Another challenge faced by AI-implemented anti-malware solutions is the availability of input features. In other words, even when the relevant feature set is known, some of the corresponding features may not always be available and / or available on all client devices. This is particularly true for mobile computing platforms such as smartphones and wearable devices, where extracting or evaluating certain features may require specific permission from the user. In addition, extracting or evaluating some features may be relatively expensive in terms of computation, which may unacceptably change the user experience, especially on mobile platforms, which typically have far fewer computing resources than personal computers and servers.
[0007] To address the feature selection and availability issues, some conventional approaches increase the feature count, and thus the size of the AI model, in an attempt to improve its performance. However, large neural networks are computationally expensive to implement and train, and typically require large training corpora that are difficult to acquire, annotate, and maintain.
[0008] For all of the reasons outlined above, there is a great deal of ongoing effort and interest in developing robust and scalable computer security systems and methods that can quickly and effectively respond to emerging threats to mobile computing platforms. Summary of the invention
[0009] According to one aspect, a malware detection method includes employing at least one hardware processor of a computer system to execute a plurality of feature processors configured to determine a plurality of derived feature values based on a plurality of primary feature values characterizing a software entity executing on the computer system, wherein a selected feature processor is configured to determine a selected derived feature value based on a selected subset of the plurality of primary feature values. The method further includes determining, in response to executing the plurality of feature processors, whether the selected derived feature value is missing, and if so, supplying a replacement value to replace the missing selected derived feature value. The method further includes employing at least one hardware processor of the computer system to determine whether the software entity is malicious based on the derived feature values determined by the plurality of feature processors and further based on the replacement feature value.
[0010] According to another aspect, a computer system includes at least one hardware processor configured to execute 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 based on a plurality of primary feature values characterizing a software entity executing on the computer system, wherein a selected feature processor is configured to determine a selected derived feature value based on a selected subset of the plurality of primary feature values. The data replacement module is configured to determine whether the selected derived feature value is missing, and if so, to supply a replacement value to replace the missing selected derived feature value. The synthesizer module is configured to determine whether the software entity is malicious based on the derived feature values determined by the plurality of feature processors and further based on the replacement feature value.
[0011] According to another aspect, a non-transitory computer-readable medium stores instructions that, when executed by at least one hardware processor of a 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 based on a plurality of primary feature values characterizing a software entity executing on the computer system, wherein a selected feature processor is configured to determine a selected derived feature value based on a selected subset of the plurality of primary feature values. The data replacement module is configured to determine whether the selected derived feature value is missing, and if so, to supply a replacement value to replace the missing selected derived feature value. The synthesizer module is configured to determine whether the software entity is malicious based on the derived feature values determined by the plurality of feature processors and further based on the replacement feature value. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The foregoing aspects and advantages of the present invention will become better understood upon reading the following detailed description and referring to the accompanying drawings, in which:
[0013] Figure 1 Exemplary software executing on a client device according to some embodiments of the invention is shown, including a security application that protects the client device from malware.
[0014] Figure 2 An exemplary structure and operation of a malware detector according to some embodiments of the present invention are described.
[0015] Figure 3 An exemplary sequence of steps performed by a malware detector according to some embodiments of the invention is presented.
[0016] Figure 4 A plurality of client devices are shown being protected from malware by a security server according to some embodiments of the invention.
[0017] Figure 5 An exemplary data exchange between a selected client device and a secure server according to some embodiments of the present invention is shown.
[0018] Figure 6 Another exemplary data exchange between a client device and a secure server according to some embodiments of the present invention is shown.
[0019] Figure 7 A number of means are shown for providing data to a substitute generator according to some embodiments of the invention.
[0020] Figure 8 A general multi-level stacked malware detector according to some embodiments of the present invention is presented.
[0021] Fig. 9 An exemplary hardware configuration is shown for a computer system programmed to perform some of the methods described herein. DETAILED DESCRIPTION
[0022] In the following description, it should be understood that all the cited connections between structures can be direct operational connections or indirect operational connections through intermediate structures. A set of elements includes one or more elements. Any reference to an element should be understood to refer to at least one element. A plurality of elements includes at least two elements. Unless otherwise required, any described method steps do not necessarily need to be performed in a specific described order. A first element (e.g., data) derived from a second element includes a first element that is identical to a second element, and a first element generated by processing a second element and optionally other data. Making a determination or decision based on a parameter includes making a determination or decision based on a parameter and optionally based on other data. Unless otherwise specified, an indicator of a certain quantity / data may be the quantity / data itself, or an indicator different from the quantity / data itself. A computer program is a sequence of processor instructions that implements a task. The computer program described in some embodiments of the present invention may be an independent software entity or a sub-entity (e.g., a subroutine, a library) of another computer program. The term 'database' is used herein to represent any organized data collection. A hash is a numerical result of applying a hash function to a token (e.g., a string, a code snippet, etc.). A hash function maps data of arbitrary size to a fixed-size value. Exemplary hash functions / processes include, among others, cyclic redundancy checks (CRCs), checksums, message digest functions (e.g., MD5), and secure hash algorithms (SHA). Computer-readable media encompass non-transitory media such as magnetic, optical, and semiconductor storage media (e.g., hard drives, optical disks, flash memory, DRAM), and communication links (e.g., conductive cables and fiber optic links). According to some embodiments, the present invention provides, among others, 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 to perform the methods described herein.
[0023] The following description illustrates embodiments of the invention by way of example and not necessarily by way of limitation.
[0024] Figure 1 An exemplary client device 12 is shown that is protected from 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 the respective device to communicate with other devices / computer systems. Exemplary client devices 12 include personal computers, mobile computing platforms (e.g., laptops, tablet computers, mobile phones, and wearable devices such as smart watches and fitness bands, etc.), entertainment devices (e.g., TVs, game consoles), and home appliances (e.g., refrigerators, washing machines), etc.
[0025] In some embodiments, client device 12 executes a plurality of computer programs, such as an operating system (OS) 22, which provides an interface between the hardware of client device 12 and other computer programs, such as a set of target applications 24 executing on the respective client device. Exemplary operating systems include and wait.
[0026] The target application 24 generally represents any software, such as word processing, image processing, spreadsheet, calendar, game, social media, web browser, and electronic communication applications. The term 'application' herein refers to independently executable software that is distinct from an operating system and can be called by a user independently of other applications (e.g., as opposed to a software library or a subroutine that forms part of another computer program). Exemplary applications 24 include software downloaded from a store (e.g., Inc.'s App Store or ) or other third-party applications installed by the user (e.g., an APK file downloaded directly from the Internet by the user and installed on the client device 12). The modifier 'target' is included only for the sake of clarity to indicate that the application 24 forms the subject of the security analysis (malware detection) as described herein. For example, a malware detector as described herein may be configured to determine whether the target application 24 includes malware.
[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 malware. For clarity, the following description will focus on an embodiment in which the security application 30 comprises software executed on at least one hardware processor of the client system 12. However, those skilled in the art will appreciate that in alternative embodiments, the described functionality may be implemented in hardware (e.g., an application specific 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 may provide various security services, such as traffic filters, virtual private networks (VPNs), anti-spam, parental controls, etc.
[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) executing on respective client devices by evaluating a set of features / attributes of such software. The features evaluated by the extractor 32 are considered 'primary' herein simply because they are used as input to the first stage of a stacked malware detector as described below. The modifier 'primary' is not meant to indicate the relative importance or relevance of some features relative to other features.
[0029] Key features herein refer broadly to any property known in the art of computer security that can be used to determine whether a client device 12 includes malware. Some such features may not be indicative of malware by themselves, but may indicate malicious intent when occurring in conjunction with other features. Exemplary key features include so-called 'static' features, such as the current contents of a segment of memory, the contents of a file or folder (e.g., The main features include the following: a) a list of static features, b) a list of static features, c) a list of static features, e ...
[0030] The operation of feature extractor 32 may include any method and algorithm known in the art of computer security. Evaluating static features may include signature matching by hashing or other methods, accessing OS-specific data structures (e.g., Registry) to read the current values of various settings, etc. Evaluating dynamic features may include detecting the occurrence of hardware or software events, such as application installation, uninstallation and update, process / application startup and termination, subprocess derivation (e.g., forking), dynamic loading / unloading of libraries, execution of specific processor instructions (e.g., system calls), file events (e.g., file creation, writing, deletion, etc.), and setting various OS parameters (e.g., Registry events, permission / privilege changes), etc. Other exemplary detected events include requests to access peripheral devices (e.g., hard disk, SD card, network adapter, microphone, camera), requests to access remote resources (e.g., Hypertext Transfer Protocol-HTTP requests to access specific URLs, attempts to access document repositories through a local network), requests formulated with 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.), etc. Still other exemplary events include moving the user interface / window of the target application 24 into and / or out of focus / foreground.
[0031] Some embodiments may further detect various timing-related events, such as inactivity periods, i.e., time gaps between events and / or time intervals when the corresponding client device is idle, registering no user activity, or performing only internal system tasks. Such inactivity periods may be further distinguished into short time gaps (e.g., on the order of seconds) and long time gaps (e.g., on the order of minutes to hours). Other timing-related events may include, for example, sequences of events occurring in rapid succession / bursts of activity.
[0032] Other exemplary detected events may include receiving and / or displaying a particular type of content, such as an SMS containing a hyperlink, an HTML document containing a login form, a payment interface, an advertisement, etc.
[0033] Exemplary events specific to mobile devices or particularly relevant to the security of mobile devices include screen switching (on / off), changes in the label / name / icon of an application, and screen captures. Other examples include requests to grant specific types of permissions (e.g., administrator, accessibility), dynamically requested permissions (i.e., during various stages of execution, rather than at installation time), and granting persistence (e.g., foreground services dynamically started by the corresponding application). Still other examples include attempts to prevent uninstallation of the corresponding application and displaying overlays on top of the OS settings interface (such overlays may trick an unsuspecting user into granting the corresponding application undesired permissions).
[0034] Event detection may be device type specific. In one example where the client device 12 is a personal computer or laptop, upon detecting the launch of the target application 24, the feature extractor 32 sends a message to the event log service of the OS 22 (e.g., Event Tracing - ETW, The extractor 32 may register the corresponding application and / or its associated process with the Syslog in the corresponding process. In response, the extractor 32 may receive notifications of various events that occur during the execution of the corresponding process in real time or in the form of a log. The event log tool typically generates a list of event descriptors, including a timestamp for each event, a numerical code identifying the type of event, an indicator of the type of process or application that generated the corresponding event, and other event parameters. In such embodiments, the extractor 32 may detect the occurrence of a target event by parsing the corresponding event log.
[0035] In another example of event detection, feature extractor 32 may modify a set of native functions of OS 22 by inserting redirection instructions (also referred to as hooks or patches). In this way, when a process executing on client device 12 calls a corresponding OS function, execution is redirected to a callback routine, notifying extractor 32 of an attempt to execute the corresponding OS function. When the hook function plays an important role in the monitored event (e.g., file creation, process startup, etc.), the attempt to call the corresponding function can be used as an indicator of the occurrence of the corresponding event.
[0036] In yet another example of event detection, electronic communications sent by a respective client device may be detected by installing a proxy module configured to intercept Domain Name Service (DNS) queries and / or HTTP requests transmitted by the respective client device.
[0037] Some operating systems (such as those executed on smartphones, wearable devices, etc.) may not allow such manipulation. However, other tools can be used to detect the occurrence of various events. For example, some OS open application programming interfaces (APIs) that enable registering callbacks for different notifications, checking network services, SMS / MMS manipulation, detecting access to storage devices (e.g., SD cards), etc. Some embodiments of the feature extractor 32 use the functionality of the accessibility API to access content on the screen and detect user interactions with the corresponding device and / or application. Some embodiments may further use artificial intelligence (e.g., natural language processing, computer vision, etc.) or other ways of analyzing content displayed on the screen.
[0038] In some embodiments, feature extractor 32 generates a plurality of primary feature values 40, i.e., current values of a plurality of features / attributes that characterize the software (e.g., target application 24) executing on client device 12. Such values may be numeric, string, Boolean, etc., depending on the type of the corresponding feature. In typical embodiments, the count of primary features is relatively large, e.g., hundreds or thousands, but the present description generally applies to any number of primary features.
[0039] In some embodiments, the security application 30 further includes a malware detector 34 that receives the primary feature value 40 as input and determines a security ruling 26 based on the feature value 40, the ruling 26 indicating whether the client device 12 includes malware. An exemplary ruling 26 includes a Boolean label (e.g., yes / no) and a likelihood that the corresponding client is infected. The ruling 26 may further include an identifier of a software entity (e.g., a target application 24) that is considered malicious, an identifier of the type of malicious agent or malware, and a set of instructions for mitigating the effects of the corresponding infection.
[0040] Figure 2 An exemplary structure and operation of a malware detector 34 according to some embodiments of the present invention is described. The detector 34 has a stacked or cascaded architecture in which a plurality of feature processors (FPs) 36a to d receive primary feature values 40 determined by a feature extractor 32 and output a plurality of derived feature values 44 determined from the primary feature values 40. The derived feature values are then used as input to a second-level synthesizer module 38, which in turn determines a security ruling 26 based on the derived feature values 44. When some derived feature values 44 are missing (cannot be determined for any reason), a data replacement module 37 fills in the missing values with substitute data 42, as described in detail below. Although Figure 2 Only two stages of feature processing are shown, but those skilled in the art will recognize that the present description applies generally to malware detectors comprising a stack of feature processor stages, where each stage receives the output of the previous stage and feeds its own output to the next stage of feature processors. For a description of such a multi-stage architecture, see Figure 8 Related below.
[0041] In some embodiments, each primary feature processor 36a-d inputs a specific subset of feature values 40, i.e., the values of a specific subset of features. In other words, each FP 36a-d analyzes the software executed on the client device 12 through the perspective of the selected subset of features. Figure 2 In the example illustrated in FIG. 3 , FP 36a considers only main features F1 to F6, while FP 36b processes only main features F4, F6, F7 to F9, F 11 and F 12 However, this aspect is not meant to be limiting, for example, some FPs may input the entire feature range. The feature subsets analyzed by each FP 36a to d may overlap, such as Figure 2 In the exemplary embodiment illustrated in , both FPs 36a and 36b use features F4 and F6.
[0042] Each feature processor 36a-d computes a particular set of derived feature values 44 based on its respective input. Figure 2In the example of , FP 36a determines derived feature D1 based on the current values of primary features F1-F6. Derived features 44 may include any features that characterize the software (e.g., target application 24) executing on client device 12. In one exemplary embodiment, each FP 36a-d outputs a derived feature value that indicates the probability that client device 12 includes malware. In such an example, even if all feature processors 36a-d output the same kind of information (i.e., partial security rulings), each such partial ruling may still be determined based on a different subset of the primary features.
[0043] In some embodiments, each FP 36a to d embodies a different malware detection algorithm, process, etc. Exemplary FPs 36a to d may implement various malware detection heuristics, such as signature matching and decision trees, etc. Other exemplary FPs 36a to d may implement automatic classifiers based on clustering algorithms (e.g., k-means, k-nearest neighbors, etc.), statistical techniques (e.g., Bayesian methods, etc.), support vector machines (SVMs), and / or Markov models. Some categories / clusters may be associated with benign behavior, while other categories / clusters may be associated with malware. In embodiments using artificial intelligence (AI) techniques, some FPs 36a to d may include artificial neural networks (NNs) that are pre-trained to determine whether a client device includes malware based on 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, malware that is packed / encrypted, etc.).
[0044] Several NN architectures are known in the art, as are strategies for training NNs as malware detectors. A simple FP example includes a feed-forward network that is trained to determine malware-indicative labels from a subset of the primary eigenvalues. Another exemplary class of FPs, known as autoencoders, may be trained to perform lossy compression and subsequent recovery of a subset of the primary eigenvalues. Some embodiments may train an autoencoder on data obtained during execution of benign software, and use a mismatch between the input and output of the autoencoder as an indicator of anomalous, and therefore potentially malicious, application behavior. Some FPs 36a-d may employ neural networks specialized for text and natural language processing to analyze data from The features extracted from the manifest file and / or user interface. Such FPs may implement a recurrent neural network (RNN), a long short-term memory (LSTM) architecture, etc. Other exemplary FPs 36a to d may employ a NN specifically for image processing (e.g., a convolutional neural network, etc.) to analyze the screenshots and / or image files received or sent by the corresponding client device. The specific architecture and functional details of such NN-based feature processors are beyond the scope of this description.
[0045] In yet another exemplary embodiment, some FPs 36a-d may compute a projection of a subset of the main features into an abstract vector space, which is often referred to as an embedding. Figure 2 Taking the illustrative example of as an example, the derived feature values D2, D3 and D4 can be the coordinates of points in the abstract three-dimensional embedding space, and the corresponding coordinates are based on the main features F4, F6, F7, F8, F9, F 11 and F 12 The current value of is determined by a specific mathematical transformation. The corresponding embedding space can be constructed via a machine learning process, where the parameters of the corresponding feature processor / neural network are tuned to meet a predetermined goal, such as minimizing a cost function determined based on the input and output of the corresponding FP. An exemplary embedding space can be a space in which all examples of malware are clustered together.
[0046] In some embodiments, the synthesizer module 38 is configured to receive an input array 46 of derived feature values calculated by the feature processors 36a to d, and determine a security ruling 26 based on the corresponding derived feature values. The module 38 may implement any malware detection or decision-making method known in the art. In a simple example where each derived feature value 44 indicates a partial ruling / likelihood of maliciousness, the module 38 may determine a merged security ruling as a weighted sum of the individual derived feature values 44. Each weight may reflect a particular degree of relevance or confidence for each respective partial ruling. Another instance of the synthesizer module 38 implements a decision tree in which each node tests a condition based on a subset of the 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 a malware-indicative label or a number indicating the likelihood that the device 12 includes malware. The architecture of such an AI module may depend on the type of input, i.e., on the feature D evaluated by the upstream feature processor. i Type.
[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, which may not currently be activated on the corresponding 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 a working Internet connection, which may not currently be available. Evaluating some key features may require additional software that may not be installed on the corresponding device. Some key feature evaluations may be particularly expensive, and thus some embodiments may defer evaluation of such features during periods of relatively low user activity, at predetermined time intervals, etc. In Figure 2In FIG. 4 , available primary eigenvalues 40 are represented as solid circles, while currently unavailable eigenvalues are represented as hollow circles. For example, the current values of features F1 and F9 are available, while the current values of features F7 and F8 are available. 11 cannot be evaluated and therefore the corresponding eigenvalue is missing.
[0048] In some embodiments, a feature processor with incomplete or unavailable input does not execute or produce valid output. Figure 2 In the exemplary embodiment of FIG. 1 , the values of the derived features D2, D3, and D4 are not available because the primary features F7, F8, and F9 cannot be evaluated. 11 . Similarly, the value of derived feature D7 is missing because one of the primary feature values entering feature processor 36d is currently unavailable. Some FPs may fail to execute for other reasons, such as due to 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 suspended or postponed so as not to affect the user experience. Missing / unavailable feature values may be programmatically represented as, for example, NULL, N / A, NaN, a specific error code, etc., using any method known in the art.
[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 substitute values 42 within the array 46. Thus, filling in the missing inputs ensures that the synthesizer module 38 can execute and generate the ruling 26 even when some individual feature processors are not functional. In this case, the synthesizer module 38 determines the safe ruling 26 based on the available derived feature values 44 and further based on the substitute feature values 42 supplied by the module 37.
[0050] Substitute value 42 in Figure 2 The term 'substitution' in this context indicates that the corresponding value is not determined by the local instance of the corresponding feature processor based on the locally calculated primary feature value, but is instead supplied from an alternative source. In some embodiments, the data substitution module 37 selectively selects from the following: Figure 1 4. The replacement value 42 is retrieved from a repository illustrated as a secure database 20 in FIG. The database 20 may reside on a computer-readable medium forming part of or communicatively coupled to the client device 12. Alternatively, some embodiments may retrieve the replacement value from a remote secure server, as described in further detail below.
[0051] In some embodiments, the substitute value 42 is intentionally selected to represent the current situation and / or state of the client device 12. Therefore, some embodiments of the database 20 may store multiple reference values for each derived feature, each reference value is associated with an identifier of the corresponding derived feature, and is further associated with a state indicator indicating the state of the device that generated the corresponding reference value. Exemplary state indicators may include, among other things, an indicator of the device type (e.g., a smartphone of a specific brand and model), an indicator of the type and version of the operating system, a timestamp indicating the moment when the corresponding value was calculated, a location indicator (e.g., a geographic location, a network address, etc.), and a set of identifiers (e.g., an integrity hash) of software applications installed and / or executed when the corresponding feature value was calculated. Other exemplary state indicators may include a primary feature value used to determine the corresponding substitute value. In one exemplary embodiment, the database 20 stores a set of records, each record including a reference value and a set of metadata indicating the state of the device. The database 20 and individual records may use any format and data structure known in the art, which enables selective retrieval of substitute values 42 based on the device state. A detailed description of calculating and / or harvesting substitute feature values is given below.
[0052] Figure 3 An exemplary sequence of steps performed by malware detector 34 according to some embodiments of the present invention is shown. In some embodiments, feature extractor 32 may evaluate primary features continuously. Alternatively, operation of extractor 32 may be initiated by a predetermined triggering event, such as the launch of target application 24, suspicious or malware-indicative activity, or upon detection of a period of user inactivity. In still other embodiments, feature extractor 32 may attempt to evaluate various primary features at predetermined times, such as according to a schedule or periodically. In any such case, malware detector 34 may receive a set of primary feature values 40 from feature extractor 32 (step 302).
[0053] In response, the detector 34 may attempt to execute the feature processors 36a to d to calculate the corresponding derived feature values. In the sequence of steps 304 to 306 to 308, all feature processors are selected and executed. When the detector 34 includes multiple layers of feature processors (see, e.g. Figure 8 , and the associated description below), all stages may be executed step by step, with each feature processor receiving input from other feature processors upstream. In some embodiments, each feature processor may execute independently and asynchronously, such as in a parallel computing configuration. For example, client device 12 may maintain a pool of processor threads reserved for feature processing; in such embodiments, malware detector 34 may wait until a thread becomes available and assign the corresponding thread to an unfinished feature processor, which in turn will release the corresponding thread when it completes its work.
[0054] Step 310 may check whether the calculation of the derived feature value 44 is successful, or in other words, whether the output of the corresponding FP is available. The corresponding FP may fail to produce output, for example because at least one of the primary feature values required as input to the corresponding feature processor is currently unavailable, or because the corresponding FP has crashed. In response to failure to calculate at least one derived feature value, in step 312, the data replacement module 37 may supply a replacement value to replace the corresponding missing derived feature value. In various embodiments as described below, supplying a replacement value may include locally generating, looking up, and / or requesting the corresponding value from a remote service.
[0055] In some embodiments, module 37 may be configured to generate alternative feature values based on prior knowledge about the corresponding derived features. In one such instance using a variant of Gaussian data regression, data previously harvested from the client and / or test device is used to calculate various statistics, such as typical limits, means, and standard deviations for each derived feature. The corresponding statistics may then be transmitted to each client device or instance of malware detector 34, which may then generate alternative values with the desired statistics. Gaussian distribution is given herein as an example and is not meant to be limiting. Some embodiments may fit the harvested data to other distributions (e.g., Student's distribution, multimodal distribution, etc.). Other embodiments may use a clustering algorithm (e.g., k-means) to distribute the data harvested from the client and / or test device into a set of clusters, each of which may be defined by a set of characteristic parameters (e.g., centroid and radius). Such cluster parameters may be transmitted to each client device or instance of malware detector 34, which may then determine alternative data based on the corresponding cluster parameters. In one such example, module 37 may generate a random replacement value based on whether the corresponding value is closer to the centroid of the cluster than the radius of the corresponding cluster. In another example, module 37 may select the centroid coordinates of the cluster as the replacement value.
[0056] In some embodiments, step 312 may include formulating a query to the database 20 and / or a remote secure server and receiving a substitute feature value in response. The corresponding substitute value may be pre-calculated based on previous observations and / or data harvested from other client devices and / or test devices, as further described below.
[0057] In some embodiments, the data replacement module 37 may look up / request replacement values based on the current state of the client device 12. The device state may include, among other things, an indicator of the device type, brand and model, an indicator of the type and version of the OS 22, identifiers of various software currently installed and / or executing on the device 12 (e.g., identifiers of the target application 24), etc. Other query criteria may include the current location of the client device 12 (e.g., geographic location, network domain). Alternatively or in addition, in step 312, the module 37 may formulate a query / request based on a subset of the primary features, e.g., the current values of at least some of the primary features used to calculate the corresponding missing derived feature values. In using Figure 2 In one such example described in the description of FIG, a request for an alternative value for derived feature D2 may explicitly include or otherwise be based on primary features F4, F6, F9, and F 12 The current value of is set.
[0058] In some embodiments as described above, database 20 stores multiple records indexed according to device state and / or other criteria, which enables selective retrieval of relevant alternative feature values. Sometimes, a query may return multiple matching values for a feature of a corresponding type. For example, there may be multiple database records that partially match the device state parameters of the corresponding query. When multiple alternative values are available for the selected derived feature, in step 312, module 37 may select one according to predetermined criteria. For example, some embodiments may calculate the average or median of the available alternative values, or may select the maximum or minimum value among the available alternative values.
[0059] In step 314 ( Figure 3 ), the detector 34 may assemble the input of the synthesizer module 38, for example Figure 2 The input array 46 described in , wherein the array 46 consists of derived feature values 44 arranged in a predetermined order and supplemented with substitute data whenever the corresponding derived feature value is missing / cannot be calculated. Figure 2 In the example in, substitute feature value 42 fills in the missing values of derived features D2, D3 and D4. In some embodiments, array 46 may further include other malware indication data, such as main feature values, quantities calculated based on derived feature values, and possible other data.
[0060] Another step 316 may execute the synthesizer module 38 to determine a security verdict 26 based on the input array 46. When the verdict 26 does not indicate the presence of malware, some embodiments of the detector 34 return to step 302, for example, to perform another cycle of malware detection calculations. Otherwise, in step 320, some embodiments may perform some malware mitigation process, such as notifying a user or administrator of the respective device, suspending execution of the suspected malicious software (e.g., the target application 24), etc. An exemplary warning displayed to the user may include a hyperlink to an online description of the respective malware agent and instructions for recovering from its effects (e.g., instructions for removing the respective malicious application, changing various operating system settings, etc.).
[0061] Some embodiments may further transmit reports to a remote security server, including, for example, an indicator of the current device state of client device 12 and / or a set of primary and / or derived feature values used in calculating decision 26. Such reports may be analyzed and used to keep pace with evolving threats and develop new anti-malware tools and strategies.
[0062] The embodiments described above primarily include a 'self-sufficient' client device that executes its own local instance of the detector 34 and stores an instance of the secure database 20 on a local computer-readable medium. However, those skilled in the art will appreciate that such a configuration is merely exemplary and is not meant to be limiting. In alternative embodiments, the detector 34 may be executed on a remote server and may communicate with the client device 12 via messages compatible with the client-server protocol. Figure 4 In one such example illustrated in FIG. 1 , a plurality of client devices 12 a to d are connected to a communication network 15, which may include a local area network (e.g., a home network, a corporate network, etc.), a wide area network, and / or the Internet. The network 15 generally represents a set of hardware (physical layer) and software interfaces that enable data transfer between the devices 12 a to d and other entities connected to the network 15.
[0063] Figure 4 Further shown is a secure server 14 connected to a communication network 15. Server 14 generally represents a group of communicatively coupled computer systems that may or may not be physically proximate to each other. Figure 5 In some embodiments further described in , server 14 protects all client devices 12a-d from malware by receiving primary feature values 40 from each client, executing malware detector 34 to compute a corresponding security ruling, and returning the ruling 26 to the corresponding client.
[0064] exist Figure 6In yet another alternative embodiment illustrated in , rather than locally hosting a repository of substitute feature values, the client device 12 may request substitute values from the secure server 14. The server 14 may then execute a substitute generator 50 configured to maintain a centralized version of the secure database 20, including substitute feature values indexed according to device state or other criteria as described above. Figure 6 The configuration described in may be preferred to Figure 1 , because it avoids transmitting the contents of database 20 to each protected client, and because centralized systems generally respond to emerging threats more quickly. However, the client-server communications required to operate in such a configuration may significantly slow down the operation of client-side malware detector 34.
[0065] Figure 6 Further illustrating an exemplary exchange in which the client 12 transmits a data request 48 to the server 14 and receives in response the substitute values 42. The data request 48 may be formulated to enable selective retrieval of substitute values, for example, based on the feature type of the respective feature, based on the device type and / or current device state of the respective client, and / or based on other criteria, such as the current location (geographic location, network domain, etc.) of the respective client. In some such embodiments, the data request 48 may include the device state data of the client 12 and / or a set of primary feature values 40.
[0066] In some embodiments, the data request 48 may include a client identifier, enabling the server 14 to associate the client 12 with a client-specific account or service agreement, which may indicate various client-specific security settings, such as an acceptable false positive rate. The respective client identifier may be further associated with device type data characterizing the respective client device 12, such as the device type, brand and model, the type and version of the OS 22, a list of applications currently installed on the device 12, etc. Some embodiments of the server 14 may then use such information to customize the retrieval of alternative data for the respective client device.
[0067] Figure 7 An exemplary process for generating substitute feature values according to some embodiments of the present invention is described. In one exemplary strategy, the security server 14 may harvest the derived feature values 44 remotely calculated by the protected client devices 12a to e and then use them as substitute values to deliver to the requesting client. To further enable the association between the feature values 44 and the device state, in some embodiments, the client further pairs a set of values 44 with a device state indicator 54 indicating the device state of the calculated value 44. For example, the state indicator 54 may include a set of primary feature values 40 used to calculate the derived feature value 44. In the example of Figure 6In one exemplary embodiment illustrated in FIG. 5 , the status indicator 54 and the feature value 44 are bundled together in an activity report 52 a that can be generated by the client device 12 according to a schedule or in response to the above description of the activity report 52 a. Figure 3 The malware detection process described is transmitted.
[0068] The server 14 may further receive a device profile 28 from each client, including a client identifier and a set of data characterizing the hardware and / or software configuration of the respective client (e.g., device type, brand, model, OS version, various current settings, etc.). The server 14 may then use such information in associating the harvested feature values 44 with a particular device type and / or configuration.
[0069] Alternatively or in addition, some embodiments employ 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, with the device 18 acting as a stand-in for a protected client. One instance of the test device 18 consists of a physical device, such as a specific brand and model of mobile phone having a specific hardware and / or software configuration and communicatively coupled to the secure server 14. Another instance of the test device 18 comprises an emulation of a physical device, i.e., a set of software modules that reproduce the behavior of a real physical device (e.g., a smartphone). In one such instance, various software components of the test device 18 are executed in a sandbox (isolated container). In other exemplary embodiments, the test device 18 may include a virtual machine or an abstraction / virtualization of a corresponding client device, the virtual machine being capable of executing an operating system, a set of target applications, and a security application, as described above with respect to Figure 1 Some test devices 18 may operate as a web service, for example, as part of a device farm. Several such services are commercially available.
[0070] In some such embodiments, the server 14 may remotely configure a test device 18 with specific hardware and software characteristics, and may remotely trigger the execution of a malware detector on the respective device. Some such tests may explore the behavior of the test device 18 when executing various target applications, some benign and some known to be malicious. As a result of the respective executions, the server 14 may harvest a set of derived feature values calculated by the test device 18, for example in the form of an activity report 52b, which further includes associated device status and / or other data. Some embodiments may then index, annotate, and store the collected derived feature data in the secure database 20 for further transmission to the requesting client as a replacement value 42.
[0071] The database 20 may be formatted and stored according to any standard known in the art. Exemplary database formats include relational databases, extensible markup language (XML) documents, spreadsheets, key-value stores, etc. The server 14 and / or client devices may be configured to selectively retrieve and / or insert data into the database 20, such as using structured queries.
[0072] By collecting a large amount of data from the protected clients and / or test devices, the server 14 can further determine each derived feature D i The server 14 may fit various types of statistical distributions (e.g., Gaussian regression) to the collected data and thereby determine other statistical properties, such as means, standard deviations, expected values, etc. Such data may then be used by some embodiments of the malware detector 34 to generate replacement values 42 with similar properties as needed.
[0073] Figure 2 The exemplary malware detector 34 illustrated in FIG. 1 includes only two layers, with a first layer of feature processors 36a-d feeding into a second layer consisting of a synthesizer module 38. However, one skilled in the art will appreciate that the systems and methods described above may be adapted for stacked malware detectors having more than two layers. Figure 8 An exemplary malware detector 134 is shown according to some embodiments of the present invention, the detector 134 consisting of a stack / cascade of N layers, each layer i including a set of feature processors 36 that take inputs from an upstream layer i-1 and compute a set of derived feature values 44 based on the respective inputs. The respective derived feature values are then passed as inputs to the next layer (i+1) of feature processors 36. As illustrated, the type and count of feature processors 36 may vary among the layers. In an exemplary embodiment, each feature processor 36 comprises a separate pre-trained artificial neural network. The feature processors in layer 1 take as input the primary feature values 40. At the other end of the cascade, the output of layer N-1 is fed as input to a synthesizer module 38, which in turn outputs a security ruling 26.
[0074] When some of the primary eigenvalues 40 are missing, some of the feature processors 36 that depend on the corresponding input cannot be executed, and therefore, some of the derived eigenvalues 44 may also be missing. In this case, the data replacement module 37 fills in the missing derived eigenvalues with substitute values 42 to produce a complete input array 46 for the synthesis module 38. Such supplementation with substitute values can be performed at any stage of the cascade from 1 to N-1. However, if Figure 8 The preferred embodiment described in only supplies substitute values 42 to the output of layer N-1.
[0075] The above description shows various methods and algorithms, which can be embodied as computer programs executed by a general-purpose hardware processor, but those skilled in the art will understand that the corresponding functions 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. Fig. 9 An exemplary hardware configuration of a computer system 80 that can be programmed to implement some of the methods and algorithms described herein is illustrated. The illustrated configuration is generic and may represent any of the client devices 12a-d and / or the secure server 14. A skilled person will appreciate that the hardware configuration of some types of devices (e.g., mobile phones, smart watches, servers, routers) may differ slightly from the hardware configuration of the client devices 12a-d and / or the secure server 14. Fig. 9 The hardware configuration described in .
[0076] The illustrated computer system includes a set of physical devices, including a hardware processor 82 and a memory unit 84. The processor 82 includes a physical device (e.g., a microprocessor, a multi-core integrated circuit formed on a semiconductor substrate, etc.) configured to perform computational and / or logical operations with 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) encoding an algorithm for implementing some of the methods described herein. The memory unit 84 may include a volatile computer-readable medium (e.g., DRAM, SRAM) that stores instructions and / or data accessed or generated by the processor 82.
[0077] Input devices 86 may include a computer keyboard, mouse, and microphone, etc., including corresponding hardware interfaces and / or adapters that allow a user to introduce data and / or instructions into the corresponding computer system. Output devices 88 may include display devices (such as monitors and speakers, etc.) and hardware interfaces / adapters (such as graphics cards) that allow the illustrated computing device to communicate data to the user. In some embodiments, input devices 86 and output devices 88 share common hardware, such as in the case of a touch screen device. Storage device 92 includes computer-readable media that implements non-volatile storage, reading, and writing of software instructions and / or data. Exemplary storage devices 92 include magnetic and optical disks and flash memory devices, as well as removable media (such as CD and / or DVD disks and drives). A set of network adapters 94 together with associated communication interfaces enable the illustrated computer system to connect to a communication network 15 ( Figure 4) and / or other devices / computer systems. Controller hub 90 generally represents multiple system, peripheral and / or chipset buses, and / or all other circuit systems that enable communication between processor 82 and devices 84, 86, 88, 92, and 94. For example, controller hub 90 may include a memory controller, an input / output (I / O) controller, and an interrupt controller, etc. In another example, controller hub 90 may include a north bridge that connects processor 82 to memory 84, and / or a south bridge that connects processor 82 to devices 86, 88, 92, and 94.
[0078] The exemplary systems and methods described above enable protection of electronic devices and their users from malware. Some of the described methods and systems are particularly applicable to mobile computing devices, such as smartphones, tablet computers, and wearable computers. Such mobile devices typically have significantly less computing power, memory, and storage than other computer systems (such as personal computers and servers), and therefore may present particular challenges to conventional computer security paradigms.
[0079] Some conventional anti-malware software analyzes the code of the program (e.g., memory images) looking for patterns or fragments known to be malicious. Other conventional anti-malware methods include monitoring the behavior of the software by detecting the occurrence of selected events, and applying a set of rules and / or calculations to the detected events to determine whether the corresponding device is infected. Recent developments in machine learning have enabled the use of artificial neural networks to efficiently analyze data. In a typical example of such technology, a set of neural networks is configured to analyze an array of features that characterize the target software and determine whether the corresponding software is malicious. The neural network is pre-trained on a corpus containing known malicious and benign samples. In some cases, the number of input features may be very large (hundreds to thousands of different features, including static and behavioral features as described above).
[0080] However, evaluating such features may not be technically simple, especially on mobile computing devices (such as smartphones and other wearable computing devices). The computations required to both inspect memory and observe the behavior of applications may consume a lot of resources and thus negatively affect the user experience. Some event detection methods (such as hooking various OS functions) may not be available on all operating systems and device types. In addition, evaluating some features may require specific OS settings, such as specific permissions that may not be granted on all devices. Some features may not be available at all times or in all locations. Therefore, it may not be practical to apply some of the conventional anti-malware methods described above on mobile computing platforms.
[0081] Some embodiments of the present invention explicitly address such shortcomings, thereby enhancing the security of mobile computing devices. In some embodiments, a feature extractor attempts to evaluate multiple features that characterize the hardware and software of a client device. A set of resulting primary feature values is then fed to multiple feature processors arranged in a multi-stage cascade, where each stage receives input from the next stage upstream and in turn provides input to the next stage downstream (see Figure 2 and 8 At the last level of the stack of feature processors, the synthesizer module outputs a security ruling indicating whether the corresponding client device includes malware.
[0082] In some embodiments, each feature processor includes a set of pre-trained neural networks configured to input a subset of derived feature values available at a corresponding stage of the cascade. Figure 2 In a simple example constructed as described in , each feature processor may include a neural network configured to determine whether the corresponding client includes malware based on a different subset of the primary feature values. In other words, each feature processor may evaluate the target software from a different 'viewpoint', i.e., according to different criteria, and produce a different verdict. To use an analogy from image processing, each feature processor may analyze different aspects of an image (i.e., a set of primary feature values) to determine whether the corresponding image shows a particular object (e.g., a bicycle): one feature processor may consider edge information, while another may consider image segmentation data. The independent evaluations may then be brought together by the synthesizer module, thus producing a unified evaluation of the primary feature data.
[0083] Some conventional malware detectors feed the entire set of primary feature values to a single neural network. In contrast, some embodiments of the present invention partition the input among multiple smaller feature processors / neural networks as described above. The advantages of such partitioning are at least twofold. First, the computational cost of training and running a neural network is generally proportional to the square of the size of the input, and thus smaller networks may be significantly cheaper to train and use than large networks. This may be particularly true for anti-malware activities, where successful detection may require analysis of hundreds or thousands of different input parameters.
[0084] Second, some primary feature values may not always be available, for any of the reasons outlined above. Thus, architectures that rely on a single neural network configured to consider all features of the input data may fail when at least one required feature is missing. In contrast, as described herein, partitioning the input data among multiple smaller feature processors / networks allows execution of at least those feature processors whose inputs are available.
[0085] Some embodiments of the present invention further supply substitute data to fill in missing eigenvalues. However, in some embodiments, the substitute data is used to replace derived eigenvalues that cannot be calculated due to missing primary eigenvalues, rather than replacing any missing primary eigenvalues. In other words, in some embodiments of the present invention, supplementation with substitute values is performed at an intermediate stage of the feature processor cascade. In a preferred embodiment, the substitute eigenvalues are provided as input to the synthesizer module (see, e.g. Figure 1 and 8 ) to ensure that the corresponding module can always be executed.
[0086] This choice is deliberate and has significant advantages over other strategies for mitigating missing inputs. Some embodiments rely on the observation that feature processors (e.g., neural networks) provide significant dimensionality reduction. In other words, the size of the output of a typical feature processor may be several orders of magnitude smaller than the size of its input. Figure 2 In the exemplary embodiment illustrated in FIG. 1 , the feature processor 36 a inputs six primary eigenvalues and outputs only one derived eigenvalue D1. This means that the count of derived eigenvalues 44 is generally expected to decrease down the cascade of stacked feature processors, such as Figure 8 A typical input to the synthesizer module 38 may be 20 to 30 elements long, while the size of the main feature vector 40 may be hundreds or thousands.
[0087] Thus, solving the missing input problem according to some embodiments of the present invention may require only supplying an appropriate number of substitute 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 substitute values at an intermediate or final stage (rather than at the primary stage) of a feature processor stack / cascade removes the computational burden of actually performing the feature processors that would normally calculate the feature values that are now supplied as substitute values.
[0088] Some embodiments further rely on the observation that derived eigenvalues 44 (i.e., eigenvalues determined at intermediate levels of the FP stack / cascade) typically have significantly less variability than primary eigenvalues 40. This results from the general tendency of neural networks to infer and generalize. In one exemplary embodiment, a feature processor 36 may be trained to analyze a web page currently displayed on the screen of a client device 12 to determine whether the corresponding web page is an electronic banking interface. Because the appearance and functionality of such interfaces vary significantly between banking institutions, there is significantly greater variability in the inputs to the corresponding FPs than in the outputs. Providing alternative inputs at the primary feature level would require generating alternative web pages / HTML documents, which is significantly more computationally expensive than providing alternative outputs (i.e., bank or non-bank).
[0089] Some embodiments use reference values for each derived feature as surrogate values, the reference values being determined by other protected client devices and / or by test devices having hardware and / or software configurations similar to the client executing the corresponding instance of the malware detector. Such reference values may be centrally harvested by a secure server computer system and provided to requesting clients as needed. Other embodiments use such data harvested from clients and / or test devices to determine various statistics (mean, standard deviation, etc.) for each derived feature, and then generate random surrogate data based on the determined statistics.
[0090] 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 present invention. Therefore, the scope of the present invention should be determined by the following claims and their legal equivalents.
Claims
1. A malware detection method comprising: using at least one hardware processor of a computer system to: executing a plurality of feature processors configured to determine a plurality of derived feature values based on a plurality of primary feature values characterizing software entities executing on the computer system, wherein the selected feature processor is configured to determine a selected derived feature value based on a selected subset of the plurality of primary feature values; In response, determining whether the selected derived feature value is missing; If so, supplying a replacement value to replace the missing selected derived feature value; and A determination is made as to whether the software entity is malicious based on the derived feature values determined by the plurality of feature processors and further based on the substitute feature values.
2. The method of claim 1, wherein the selected derived feature value quantifies the likelihood that the software entity is malicious.
3. The method of claim 1, wherein supplying the substitute value comprises employing the at least one hardware processor to calculate the substitute value based on a reference value determined by another instance of the selected feature processor.
4. The method of claim 3, wherein supplying the substitute value comprises calculating the substitute value based on statistics of a plurality of reference values determined by other instances of the selected feature processor.
5. The method of claim 1, wherein supplying the substitute value comprises selectively retrieving the substitute value from a database storing a plurality of reference values determined by other instances of the selected feature processor.
6. The method of claim 5, comprising selecting the substitute value from the plurality of reference values according to a current state of the computer system.
7. The method of claim 5, comprising selecting the substitute value from the plurality of reference values according to a device type of the computer system.
8. The method of claim 1 , wherein supplying the substitute value comprises: employing at least one hardware processor of a computer system to transmit a data request to a remote secure server, the data request being formulated based on an indicator of a current state of the computer system; and In response, the replacement value is received from the remote secure server.
9. The method of claim 8, wherein the data request comprises at least one value of the plurality of primary characteristic values.
10. The method of claim 1, wherein each of the plurality of feature processors comprises a neural network trained to determine a likelihood that the software entity is malicious based on a corresponding subset of the plurality of primary feature values.
11. A computer system having at least one hardware processor configured to perform: a plurality of feature processors configured to determine a plurality of derived feature values based on a plurality of primary feature values characterizing software entities executing on the computer system, wherein the selected feature processor is configured to determine the selected derived feature values based on a selected subset of the plurality of primary feature values; a data replacement module connected to the plurality of feature processors and configured to: determining whether the selected derived feature value is missing, and in response, if yes, supplying a replacement value to replace the missing selected derived feature value; and A synthesizer module is configured to determine whether the software entity is malicious based on the derived feature values determined by the plurality of feature processors and further based on the substitute feature values.
12. The computer system of claim 11, wherein the selected derived feature value quantifies the likelihood that the software entity is malicious.
13. The computer system of claim 11, wherein supplying the substitute value comprises employing the at least one hardware processor to calculate the substitute value based on a reference value determined by another instance of the selected feature processor.
14. The computer system of claim 13, wherein supplying the substitute value comprises calculating the substitute value based on statistics of a plurality of reference values determined by other instances of the selected feature processor.
15. The computer system of claim 11, wherein supplying the substitute value comprises selectively retrieving the substitute value from a database storing a plurality of reference values determined by other instances of the selected feature processor.
16. The computer system of claim 15, wherein the data replacement module is configured to select the substitute value from the plurality of reference values according to a current state of the computer system.
17. The computer system of claim 15, wherein the data replacement module is configured to select the substitute value from the plurality of reference values according to a device type of the computer system.
18. The computer system of claim 11, wherein supplying the substitute value comprises: transmitting a data request to a remote secure server, the data request formulated based on an indicator of a current state of the computer system; and In response, the replacement value is received from the remote secure server.
19. The computer system of claim 18, wherein the data request includes at least one value of the plurality of primary characteristic values.
20. The computer system of claim 11, wherein each of the plurality of feature processors comprises a neural network trained to determine a likelihood that the software entity is malicious based on a corresponding subset of the plurality of primary feature values.
21. 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: a plurality of feature processors configured to determine a plurality of derived feature values based on a plurality of primary feature values characterizing software entities executing on the computer system, wherein the selected feature processor is configured to determine the selected derived feature values based on a selected subset of the plurality of primary feature values; a data replacement module connected to the plurality of feature processors and configured to: determining whether the selected derived feature value is missing, and in response, if yes, supplying a replacement value to replace the missing selected derived feature value; and A synthesizer module is configured to determine whether the software entity is malicious based on the derived feature values determined by the plurality of feature processors and further based on the substitute feature values.