Prevention of false positive detection of malware

A system manages the rate of false positive detections of malware by controlling release of malware definition updates. The system determines a cohort of target devices for distributing an initial release of an update of malware definitions and sends the update exclusively to the target devices. The system then obtains telemetry data which include information associated with usage of the target devices following the update. The system analyzes the telemetry data for instances of false positive detections of malware arising from the update to the malware definitions. Based on the analysis of the telemetry data, the system determines whether to further distribute the update outside of the cohort of target client devices or to roll back the update provided to the cohort. The system executes the decision to further distribute the update or to roll back the update.

FIELD OF ART

The present disclosure generally relates to computer security and more specifically to prevention of false positive detection of malware.

BACKGROUND

A malware definition is a set of data that specifies characteristics or behaviors of malware. Because malware is constantly evolving, anti-malware applications receive frequent updates to malware definitions. If malware definitions are written too broadly, newly released malware definitions may erroneously classify trusted applications as malware. These false positive detections may result in trusted programs or files being quarantined or removed.

SUMMARY

A false positive analysis system prevents false positive detection of malware due to an update in malware definition by releasing the update in a controlled fashion. The false positive analysis system determines a cohort of target devices for distributing an initial release of an update of malware definitions and sends the update exclusively to the target devices. The false positive analysis system then obtains, from the target devices, telemetry data which include information associated with usage of the target devices following the update. The false positive analysis system analyzes the telemetry data for instances of false positive detections of malware arising from the update to the malware definitions. Based on the analysis of the telemetry data, the false positive analysis system determines whether to further distribute the update outside of the cohort of target client devices or to roll back the update provided to the cohort. The false positive analysis system executes the decision to further distribute the update or to roll back the update.

In another embodiment, a non-transitory computer-readable storage medium stores instructions that when executed by a processor causes the processor to execute the above-described method.

In yet another embodiment, a computer system includes a processor and a non-transitory computer-readable storage medium that stores instructions for executing the above-described method.

DETAILED DESCRIPTION

FIG. 1is a system diagram illustrating an example embodiment of a system environment100comprising a server105, a network110, and clients120A,120B and120C, which are collectively referenced herein as clients120. For simplicity and clarity, only one server105and a limited number of clients120are shown. However, other embodiments may include different numbers of servers105and clients120. The system environment100may also include different or additional entities.

The network110represents the communication pathways between the server105and clients120. In one embodiment, the network110is the Internet. The network110may also utilize dedicated or private communications links that are not necessarily part of the Internet such as local area networks (LAN). In one embodiment, the network110uses standard communications technologies and/or protocols.

Each client120comprises one or more computing devices capable of processing data as well as transmitting and receiving data via the network110. For example, a client device120may be a desktop computer, a laptop computer, a smart phone, a tablet computing device, an Internet of Things (IoT) device, or any other device having computing and data communication capabilities. Each client120includes a processor125for manipulating and processing data, and a storage medium130for storing data and program instructions associated with various applications. The storage medium130may include both volatile memory (e.g., random access memory) and non-volatile storage memory such as hard disks, flash memory, flash drives, external memory storage devices, USB drives, and the like. In addition to storing program instructions, the storage medium130stores various data associated with operation of the client device120.

In one embodiment, the storage medium130comprises a non-transitory computer-readable storage medium that stores a file directory140and various executable programs including an operating system134, anti-malware application136, user applications132, and a data collection module138that are each embodied as computer-executable instructions stored to the non-transitory computer-readable storage medium. The instructions, when executed by the processor125, cause the clients120to perform the functions attributed to the programs described herein.

The operating system134is a specialized program that manages computer hardware resources of the clients120and provides common services to the user applications132. For example, a computer's operating system134may manage the processor125, storage medium130, or other components not illustrated such as a graphics adapter, an audio adapter, network connections, disc drives, and USB slots. A cell phone's operating system134may manage the processor125, storage medium130, display screen, keypad, dialer, wireless network connections and the like. Because many programs and executing processes compete for the limited resources provided by the processor125, the operating system134may manage the processor bandwidth and timing to each requesting process. Examples of operating systems134include WINDOWS, MAC OS, IOS, LINUX, UBUNTU, UNIX, and ANDROID.

The user applications132may include applications for performing a particular set of functions, tasks, or activities for the benefit of the user. Examples of user applications132may include a word processor, a spreadsheet application, and a web browser. In some cases, a user application132may be a source of malware that is unknowingly hidden in the user application132. The malware may infect the client120when the user application132is installed or executed.

The file directory140stores files. Files may include system files associated with operation of the operating system134, the user applications132, or the anti-malware application136. The files may further include user files that may be created or modified by users. Examples of user files may include image files, video files, word processor documents, spreadsheet documents, and drawing files.

An anti-malware application136detects, stops, and removes malware. The anti-malware application136may prevent new malware from being installed on a client120or remove or disable existing malware that is already present on the client120. The anti-malware application136may determine if a process is malware based on behaviors indicative of malware, based on static analysis of a file, based on emulation of a program using a sandbox, based on blacklist or whitelists, or based on a combination of factors. In one embodiment, the anti-malware application136may store and/or download from the network110, malware definitions that specify characteristics or behaviors of malware that the anti-malware application136seeks to detect. For example, the malware definition may specific a particular snippet of code, header information, a file hash, a behavior heuristic, or combination thereof that is indicative of a specific known malware of class of malware. The anti-malware application136may furthermore maintain a whitelist of trusted files, which may similarly be identified based on various characteristics (e.g., a goodware definition), and which will not be identified as malware by the anti-malware application. Malware definition updates may be sent to different clients120at different times. For example, as described in further detail below, a subset of clients120may be selected to test new malware definitions prior to other clients120receiving the updates.

The anti-malware application136may perform scans on a directory of files at scheduled intervals or may operate to scan files just before they are accessed. In response to detecting malware, the anti-malware application136may temporarily block the malware from executing and may generate a notification in a user interface of the client120to alert the user that the identified file may be malware. The anti-malware application136may recommend quarantining the identified file but may also give the user the option to decline the quarantine. For example, users with specialized knowledge, such as IT professionals, may be able to identify that the file can in fact be trusted and that the detection was a false positive. In either case, the anti-malware application136may store data recording the file that was detected as malware, the malware definition that invoked the detection, and the user's selection of whether or not to quarantine the file in response to the detection. The data may also be sent to the server105for further analysis, as will be described in further detail below.

A data collection module138collects general data relating to the client120, such as configuration and behavior data associated with client120relevant to selecting clients120for testing an update to the malware definitions applied by the anti-malware application136. For example, the data collection module138may collect information such as the hardware configuration, operating system, software configuration, software versions (including a version of the anti-malware application136), and geographical locations of the client device120. The data collection module138may also collect data associated with downloads of malware definition updates and general usage of user applications132. For example, the data collection module138may collect data such as if and when a client120downloads an update after a user notification is provided indicating that the update is available for download.

The data collection module138may also collect usage information associated with how a user interacts with a client120. Information such as which hours in the day and which days a user most actively uses a client device may be collected.

In an embodiment, the data collection module138provides a user of the client120with an option to opt into or opt out of the data collection associated with testing of updates. In the user opts out, then the client and user-specific data not necessary for operation of the anti-malware application136is not collected or sent to the server105. If the user opts in, the collected data may be used to enable possible participation in receiving and testing of new updates. For example, a user may indicate that s/he is willing to test new updates and consents to the data collection module138collecting relevant information and sending it back to the server105to benefit the testing process.

The server105is a computer system configured to store, receive, and transmit data to client devices120via the network110. The server105may include a singular computing system, such as a single computer, or a network of computing systems, such as a data center or a distributed computing system. In one embodiment, the server105includes a processor115for manipulating and processing data, and a storage medium108for storing data and program instructions associated with various applications. The storage medium108may include both volatile memory (e.g., random access memory) and non-volatile storage memory such as hard disks, flash memory, flash drives, external memory storage devices, USB drives, and the like. The server105may receive data from the clients120and may also send data to the clients.

The storage medium108includes an update distribution module107. The update distribution module107releases updates for malware definitions to client devices120in a controlled fashion by first providing an update of malware definition to a cohort of target devices for testing the update, where the cohort of target devices are selected based on telemetry data collected by the data collection module138. Based on the test results, the update distribution module107makes a decision whether to distribute the update outside of the cohort of target client devices or to roll back the update provided to the cohort. The update distribution module107is discussed in further detail inFIG. 2below.

FIG. 2illustrates an example embodiment of update distribution module107of the server105. The update distribution module107includes a user and device cohorting module202, a distribution and targeting module204, a telemetry and usage collection module206, a false positive detection module208, a central controller210, a whitelist generation module212, and a notification module214. Alternative embodiments may include different or additional modules or omit one or more of the illustrated modules.

The user and device cohorting module202identifies and selects a list of target devices (i.e., a cohort)120to receive and test an initial release of an update in malware definitions. The target devices are selected based on a set of parameters relating to devices, users, or both collected from the data collection module138. The user and device cohorting module202may furthermore derive additional metrics from the received parameters that may be used for cohort selection. For example, the user and device cohorting module202may predict a likelihood of the user downloading the update and predict an activity level of the client device120in a stipulated time slot. Here, a prediction of the user's activity level may be based on the local time in the location of the client120when the update is scheduled for publication and historical activity levels during different time periods. For example, if a new update is published at 9 AM, Pacific Time, the user and device cohorting module202may predict higher activity level in the U.S. and western Europe than in parts of Asia. As another example, user and device cohorting module202may predict activity level based on user-specific data (e.g., by observing that a particular user spends little time on a client device during weekdays).

The user and device cohorting module202may further identify the list of target devices based on configuration information (e.g. hardware configuration, operating system, software configuration, software versions, etc.) associated with client devices120. Depending on different updates in malware definitions, the user and device cohorting module202may select clients120that span a range of different configurations to achieve diversity between the clients120and increase the likelihood of detecting various false positives that may be specific to one configuration. In some embodiments, if the updates are specific to certain configurations (e.g. Windows vs. MacOS, a specific version of a software or OS, etc.), the user and device cohorting module202may instead select target devices limited to certain specific configurations.

The distribution and targeting module204receives the list of target devices120in the selected cohort and distributes the updates to the selected cohort of clients120. In one embodiment, the distribution and targeting module204initiates the updates by sending push messages to the selected target devices. The push messages notify users that a new update in malware definitions is available for download, and enables the user to initiate the update. In other embodiments, the distribution and targeting module204causes the target clients120to automatically download and install the update without necessarily requiring user input.

The telemetry and usage collection module206obtains and aggregates real-time download, usage and behavior data from the clients120in the cohort. The data may include information such as if and when a target client device downloads and installs the update and detection results relating to malware definitions in the update useful for identifying false positives. For example, if an updated malware definition triggers a detection, the telemetry and usage collection module206may obtain a report indicating the specific malware definition that triggered the update, the file or set of files that matched the definition, and a user's decision of whether or not to quarantine the identified files.

The false positive detection module208identify patterns of false positive detection based on data received from the telemetry and usage collection module206. The false positive detection module208may detect a potential false positive in response to a pattern of detections (e.g., over a threshold number) associated with a particular malware definition in which the user declined to quarantine the identified file and indicated that the file is trusted. Alternatively, the false positive detection module208may identify a potential false positive in response to an abnormally large number of detection (e.g., over a threshold) regardless of the user response to the quarantine decision. In further embodiments, potential false positive detections may be identified based on a combination of factors. In an embodiment, potential false positives may be sent to either an automated analysis system or manual analysis system (e.g., a human researcher) to confirm whether the malware definition was triggering false positives.

The central controller210monitors the use and device cohorting module202, the distribution and targeting module204, the telemetry and usage collection module206, and the false positive detection module208, and makes decisions relating to distribution of updated malware definitions.

The central controller210monitors download and usage goals associated with the update to determine whether the initial cohort is of sufficient size to achieve a statistically meaningful level of data for the central controller210to reach a conclusion about whether or not the updated malware is triggering false positives. For example, based on the data collected by the telemetry and usage collections module206, the central controller210may determine that the number of downloads, uses, or responses from users does not reach a threshold number, and therefore expanding the cohort may be desirable. In this case, the central controller210may notify the use and device cohorting module202to identify additional target devices to add to the cohort.

Once enough data is obtained, the central controller210determines whether to roll back an update or to distribute the update more widely to devices outside the cohort of target devices. If the false positive detection module208identified that the update to a malware definition triggered false positives at above a threshold rate, the central controller210may send instructions to the target devices that roll back the updated malware definition. Here, the malware definition may then be refined to avoid triggering the false positive and re-tested. On the other hand, if the false positive detection module208indicates a sufficiently low rate of false positives associated with the update, the central controller210may make a decision to distribute the update more widely to devices outside the cohort of target devices. The central controller210may send instructions for mass distribution of the update to the notification module214as described below.

The whitelist generation module212generates a whitelist containing a list of trusted files. The whitelist generation module212may obtain information from the central controller210associated with false positives, and in some instances, may add a file determined to be trusted to the whitelist. The whitelist generation module212sends the whitelist to the notification module214for distribution to clients120.

The notification module214manages sending of notifications to clients120. For example, the notification module214facilitates sending of malware definition updates (or rollbacks), whitelist updates, or other information to the clients120.

FIG. 3is a flowchart illustrating an embodiment of a process for determining whether an update in malware definition triggers false positive detections. The user and device cohorting module202determines302a cohort of target devices for an initial release of an update in malware definitions based on a set of parameters relating to both devices and users. The identified target devices are selected based on their likelihood of generating sufficient usage data relevant to detecting false positives within a predetermined time frame. The distribution and targeting module204distributes304the new update to the target devices. The telemetry and usage collection module206obtains306telemetry data including usage data associated with the update indicative of detections and user actions in response to the detections. The false positive detection module208analyzes308the telemetry data for instances of false positive detections of malware arising from the update. Based on the analysis, the central controller210determines310whether to further distribute the update outside of the cohort or to roll back the update provided to the cohort of target devices. The update distribution module107executes312the decision to further distribute or roll back the update.

Additional Considerations