WO2023236125A1

WO2023236125A1 - Application live-patch control for consumer device malware detection

Info

Publication number: WO2023236125A1
Application number: PCT/CN2022/097752
Authority: WO
Inventors: Qiming Li; Gang LIAN; Tailiang Hong; Yucheng DAI
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2022-06-09
Filing date: 2022-06-09
Publication date: 2023-12-14

Abstract

Disclosed is a method (1) for control of live-patching of an application on an electronic device (3). The method (1) comprises collecting (11) application-specific live-patch statistics related to the application; obtaining (12), from an analyzer engine (4) disposed remotely from the electronic device (3), a device-specific security policy for the electronic device (3) in accordance with the application-specific live-patch statistics; and applying (13) the device-specific security policy on the electronic device (3). This enables detection and selective prevention of high-risk live-patch operations performed by applications, in a way that is more transparent and friendly to developers and end-users.

Description

APPLICATION LIVE-PATCH CONTROL FOR CONSUMER DEVICE MALWARE DETECTION

Technical Field

The present disclosure relates generally to the field of malware detection on consumer devices, and more particularly to a method for control of live-patching of an application on an electronic device, to the corresponding electronic device, to a method for control of live-patching of an application on a plurality of electronic devices, and to a corresponding analyzer engine.

Background Art

Application live-patch refers to methods that allow applications to update their code and content after they are installed, without end-user explicitly installing updates or patches. Typically, an application performing live-patch would download new executable code and/or content during their runtime and dynamically loads to downloaded code or content so that part of their original code or content is replaced. The downloaded executable code may be in the form of executable programs, but it is more common to be in the form of dynamically loadable shared libraries, compiled bytecode, or even source code.

Such methods are commonly observed in many applications for consumer devices such as mobile phones, where an application developer embeds a live-patch framework or library into the application to be published. Once the application is distributed by an application distributor and installed on a device, the live-patch framework or library would check from a 3 ^rd party live-patch server from time to time to see if there is any update. When the application developer decides to publish an update in the form of a live-patch, the developer would update the patch to the live-patch server, so that the installed applications would download the patches via the live-patch framework or library and loads them during runtime.

Compared with normal application patches or updates, using live-patch methods allows application developers to distribute new content and bug fixes much faster by avoiding the delay that may be introduced by the application distributor, and to achieve much wider coverage by silently installing the updates without user interaction.

However, the silent installation nature of application live-patch would also mean that such live-patch would be installed without user consent, and without any automated or manual checks done by the application distributor. This is often abused by malware developers and distributors to by-pass malware detections and counter measures that are typically performed by the application distributor during the normal application distribution process.

Even for benign applications, they could be tricked to load malicious code when the developers used malicious live-patch frameworks or libraries that would download malware code from 3 ^rd party servers that is unintended by the application developers. It is also possible that the live-patch frameworks or libraries are not well-designed and easily attacked, so that they would load malicious code injected by attackers.

Exemplary methods to detect and/or mitigate the risks of malware introduced by application live-patch essentially employ a detect-and-block strategy, wherein malware code is first detected (either before or after distribution) , and then the associated application is prevented from launching (by way of blacklisting, quarantining, etc. ) or is uninstalled. Such a strategy is unsatisfactory in a number of ways.

First, there is no attempt to control the live-patch operations performed by applications (i.e., dynamically downloading patch code and loading it) . It may be possible that an initially benign application becomes malicious after a live-patch operation is performed, and the resulting application may be detected as malware and blocked. However, there is a lack of mechanisms that would prevent benign applications from becoming malicious by live-patching themselves.

Secondly, a distinction between a benign and a malicious application is sometimes vague. An application that requests permissions excessively may provide a useful service to some users and be seen as malicious by other users. However, end users do not have a choice whether to allow certain applications to perform live-patch based on their actual needs, even when the live-patch may contain code that could be seen as malicious to other users.

Thirdly, applications depending on live-patch frameworks or libraries may be blocked before actual malicious code is found, and/or not be blocked accurately, since developers may avoid detection by using a less popular framework or library, developing their own application specific live-patch frameworks or libraries, or using ad-hoc methods such as directly downloading from some known web locations using standard networking libraries.

Summary

It is an object to overcome these and other drawbacks by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description, and the figures.

According to a first aspect, a method is provided for control of live-patching of an application on an electronic device. The method comprises collecting application-specific live-patch statistics related to the application; obtaining, from an analyzer engine disposed remotely from the electronic device, a device-specific security policy for the electronic device in accordance with the application-specific live-patch statistics; and applying the device-specific security policy on the electronic device.

This may selectively prevent high-risk application live-patch operations on a consumer device, by reported and intercepting live-patch operations in accordance with a security policy formed by a cloud-generated policy taking into account the live-patch statistics of a plurality of electronic devices, and a user-defined policy relating to the particular electronic device at hand.

Thereby, high-risk live-patch operations performed by applications may be detected, and be prevented selectively, in a way that is more transparent and friendly to developers and end-users.

In a possible implementation form, the method may further comprise modifying the device-specific security policy on the electronic device in accordance with user feedback.

Thereby, users being aware of the risks and current status may be allowed to change the cloud-generated policy depending on their specific needs.

In a possible implementation form, the collecting may comprise monitoring, by an application manager of the electronic device, whether a file manipulated by the application is being executed; determining, by the application manager, the application-specific live-patch statistics related to the application and the file executed by the application; and submitting, by the application manager to a live-patch manager of the electronic device, the application-specific live-patch statistics. The application-specific live-patch statistics may comprise at least one of: an identifier of the application, a path name of the file executed by the application, and a hash value of a content of the file.

Thereby, a plurality of applications may be monitored device-internally with respect to live-patching, without breaching a user privacy by unnecessary network communications.

In a possible implementation form, the application manager may comprise an application management system service of the electronic device.

An application manager as used herein may refer to a software entity hosted on the electronic device which is responsible for monitoring file accesses made by applications, including writing and loading files that contain executable code or bytecode.

A live-patch manager as used herein may refer to a software entity hosted on the electronic device which is responsible for an information exchange as regards application live-patching.

Thereby, an integration with a system service infrastructure of the electronic device may be improved.

In a possible implementation form, the collecting may further comprise retrieving, by the live-patch manager, the application-specific live-patch statistics; aggregating, by the live-patch manager, the application-specific live-patch statistics over a period of time; and anonymizing, by the live-patch manager, the application-specific live-patch statistics. The anonymized live-patch statistics may comprise at least one of: a hash value of the identifier of the application, a hash value of the path name of the file executed by the application, and a hash value of the content of the file.

The anonymization allows a detection of malware, assessing a risk involved, and generating a security policy accordingly, without revealing information that is not necessary for malware detection, such as application or file characteristics, names or identifiers of applications etc. Thereby, a user privacy is improved.

In a possible implementation form, the live-patch manager may comprise a live-patch management system service of the electronic device.

In a possible implementation form, the analyzer engine may comprise an analyzer cloud service.

Thereby, the analyzer functionality required for a plurality of electronic devices is advantageously centralized.

In a possible implementation form, the obtaining of the device-specific security policy may comprise submitting, by the live-patch manager to the analyzer engine, the application-specific live-patch statistics; retrieving, by the live-patch manager, the device-specific security policy; and de-anonymizing, by the live-patch manager, the device-specific security policy. The de-anonymized device-specific security policy may comprise at least one of: the identifier of the application, the path name of the file executed by the application, and the action relating to the application and/or the file.

The device-specific security policy and its associated action may prevent specified live-patch operations of applications. Thereby, a more fine-grained response to malware detection is facilitated.

In a possible implementation form, the applying of the device-specific security policy may comprise causing, by the live-patch manager, a security policy engine of the electronic device to enforce the device-specific security policy; and retrieving, by the live-patch manager, policy enforcement statistics related to the application.

A security policy engine as used herein may refer to a system service hosted on the electronic device, which is responsible for enforcing security policies by utilizing capabilities provided by an operating system of the electronic device, and for reporting enforcement statistics.

In a possible implementation form, the modifying of the device-specific security policy may comprise displaying, by the live-patch manager, the device-specific security policy and/or the policy enforcement statistics related to the same on a user interface; receiving, by the live-patch manager, a modification of the device-specific security policy via the user interface; and causing, by the live-patch manager, the security policy engine of the electronic device to enforce the modified device-specific security policy.

According to a second aspect, a method is provided for control of live-patching of an application on a plurality of electronic devices. The method comprises providing, by an analyzer engine disposed remotely from the plurality of electronic devices, a device-specific security policy for the electronic device in accordance with application-specific live-patch statistics related to the application on the plurality of electronic devices.

Thereby, high-risk live-patch operations performed by applications on a plurality of electronic devices may be detected, and yet be prevented in a device-specific manner.

In a possible implementation form, the providing of the device-specific security policy may comprise retrieving the application-specific live-patch statistics relating to each of the plurality of electronic devices; acquiring, from a malware detection engine, an application-specific security policy in accordance with the application-specific live-patch statistics relating to the plurality of electronic devices, the application-specific security policy defining if the file executed by the application is potentially malicious; generating the device-specific security policy in accordance with the application-specific security policy, the device-specific security policy defining an action relating to the application and/or the file executed by the application; and submitting the device-specific security policy to the electronic device.

Thereby, the device-specific security policy may automatically be generated taking into account the live-patch statistics of a plurality of electronic devices.

In a possible implementation form, the providing of the device-specific security policy may further comprise aggregating the application-specific live-patch statistics over a period of time.

Thereby, a quantity of the plurality of electronic devices being taken into account may be controllable.

In a possible implementation form, the providing of the device-specific security policy may further comprise filtering the application-specific live-patch statistics.

Thereby, especially irregularities of the live-patch statistics of the plurality of electronic devices may be taken into account.

In a possible implementation form, the providing of the device-specific security policy may further comprise digitally signing the device-specific security policy.

Thereby, the generated security policy is safe from the risk of being tampered.

In a possible implementation form, the malware detection engine may comprise a malware detection cloud service.

Thereby, a malware detection cloud service for anti-virus purposes may be reused.

According to a third aspect, an electronic device is provided, comprising a processor being configured to perform the method of the first aspect or any of its implementations.

According to a fourth aspect, an analyzer engine is provided, comprising a processor being configured to perform the method of the second aspect or any of its implementations.

According to a fifth aspect, a computer program is provided, comprising executable instructions which, when executed by a processor, cause the processor to perform the method of the first aspect or any of its implementations or the method of the second aspect or any of its implementations.

The technical effects and advantages described above in relation with the methods of the first and second aspects apply to the devices of the third and fourth aspects and to the computer program of the fifth aspect as well.

Brief Description of Drawings

The above-described aspects and implementations will now be explained with reference to the accompanying drawings, in which the same or similar reference numerals designate the same or similar elements.

The drawings are to be regarded as being schematic representations, and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose become apparent to those skilled in the art.

FIG. 1 illustrates a method for control of live-patching of an application on an electronic device in accordance with the present disclosure;

FIG. 2 illustrates a method for control of live-patching of an application on a plurality of electronic devices in accordance with the present disclosure; and

FIG. 3 illustrates a message flow in accordance with the present disclosure.

Detailed Descriptions of Drawings

In the following description, reference is made to the accompanying drawings, which form part of the disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and comprise structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

For instance, it is understood that a disclosure in connection with a described method may also hold true for a corresponding apparatus or system configured to perform the method and vice versa. For example, if one or a plurality of specific method steps are described, a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps) , even if such one or more units are not explicitly described or illustrated in the figures. On the other hand, for example, if a specific apparatus is described based on one or a plurality of units, e.g. functional units, a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units) , even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary embodiments and/or aspects described herein may be combined with each other, unless specifically noted otherwise.

FIG. 1 illustrates a method 1 for control of live-patching of an application on an electronic device 3 in accordance with the present disclosure.

An electronic device 3 comprising a processor 31 is provided. The processor 31 may be configured to perform said method 1.

The method 1 comprises collecting 11 application-specific live-patch statistics related to the application.

The collecting 11 may comprise monitoring 111, by an application manager 311 of the electronic device 3, whether a file manipulated by the application is being executed.

In particular, the application manager 311 may comprise an application management system service of the electronic device 3.

The collecting 11 may further comprise determining 112, by the application manager 311, the application-specific live-patch statistics related to the application and the file executed by the application. The application-specific live-patch statistics may comprise at least one of: an identifier of the application, a path name of the file executed by the application, and a hash value of a content of the file.

The collecting 11 may further comprise submitting 113, by the application manager 311 to a live-patch manager 312 of the electronic device 3, the application-specific live-patch statistics.

In particular, the live-patch manager 312 may comprise a live-patch management system service of the electronic device 3.

The collecting 11 may further comprise retrieving 114, by the live-patch manager 312, the application-specific live-patch statistics.

The collecting 11 may further comprise aggregating 115, by the live-patch manager 312, the application-specific live-patch statistics over a period of time.

The collecting 11 may further comprise anonymizing 116, by the live-patch manager 312, the application-specific live-patch statistics. The anonymized live-patch statistics may comprise at least one of: a hash value of the identifier of the application, a hash value of the path name of the file executed by the application, and a hash value of the content of the file.

The method 1 further comprises obtaining 12, from an analyzer engine 4 disposed remotely from the electronic device 3, a device-specific security policy for the electronic device 3 in accordance with the application-specific live-patch statistics.

In particular, the analyzer engine 4 may comprise an analyzer cloud service.

The obtaining 12 of the device-specific security policy may comprise submitting 121, by the live-patch manager 312 to the analyzer engine 4, the application-specific live-patch statistics.

The obtaining 12 of the device-specific security policy may further comprise retrieving 122, by the live-patch manager 312, the device-specific security policy.

The obtaining 12 of the device-specific security policy may further comprise de-anonymizing 123, by the live-patch manager 312, the device-specific security policy. The de-anonymized device-specific security policy may comprise at least one of: the identifier of the application, the path name of the file executed by the application, and the action relating to the application and/or the file.

The method 1 further comprises applying 13 the device-specific security policy on the electronic device 3.

The applying 13 of the device-specific security policy may comprise causing 131, by the live-patch manager 312, a policy engine 313 of the electronic device 3 to enforce the device-specific security policy.

The applying 13 of the device-specific security policy may further comprise retrieving 132, by the live-patch manager 312, policy enforcement statistics related to the application.

The method 1 may further comprise modifying 14 the device-specific security policy on the electronic device 3 in accordance with user feedback.

The modifying 14 of the device-specific security policy may comprise displaying 141, by the live-patch manager 312, the device-specific security policy and/or the policy enforcement statistics related to the same on a user interface.

The modifying 14 of the device-specific security policy may further comprise receiving 142, by the live-patch manager 312, a modification of the device-specific security policy via the user interface.

The modifying 14 of the device-specific security policy may further comprise causing 143, by the live-patch manager 312, the policy engine 313 of the electronic device 3 to enforce the modified device-specific security policy.

With particular reference to the anonymizing 116 step, it is noted that it is possible to anonymize the application statistics collected by the live-patch manager 312 in such a way that the analyzer engine 4 only receives enough information to perform its analysis.

For example, malware detection systems would typically maintain a database of the characteristics of known malicious files. To determine if a file contains malicious code, the characteristics of the file in question need to be compared with the records in the database. If a match is found, the file contains malicious code with high probability. In the simplest cases, the characteristics contains only a hash value of the file.

The statistics collected by the live-patch manager 312 may contain information such as the name and identifiers of the applications, the paths of files written and loaded by these applications, hash values of these files, the time at which the files are accessed, and so on. In the simplest cases, only the hash values of the files are sent to the analyzer engine 4, which are then used to compare with the malware database. However, for the analyzer engine 4 to generate security policy correctly, it is desirable to know the hash values of all the files downloaded by the same application.

In this case, the live-patch manager 312 may generate a temporary application identifier at random for each application in the collected statistics, and associate the temporary identifier to the hash values instead of the real application name or identifier. In this way, the analyzer engine 4 would still have sufficient data to perform the analysis but the identity of the applications are hidden from the analyzer engine 4. In any case, the analyzer engine 4 knows only if malicious code with specific hash values exists on a device but learns nothing else. After the signed security policy is received from the analyzer engine 4 and its signature validated, the live-patch manager 312 may de-anonymize the policy by replacing the temporary application identifiers to the real identifiers or names.

Instead of using a temporary random identifier, other anonymization techniques may be used. For example, an encryption function may be applied on the data that needs to be anonymized. The corresponding decryption function can then be applied to de-anonymize the data. In another example, a keyed hash function may be applied to anonymize the data. In this case, the de-anonymization is similar to temporary random identifiers, where the original data needs to be recorded and associated with the hash value so that de-anonymization can be done via a table lookup.

With particular reference to the causing 131 step, the policies generated by analyzer engine 4 should include enough information for the policy enforcement by the policy engine 313. Naturally, the exact form of the security policy depends on the way applications are installed and identified on the electronic device 3, and the way in which live-patch code is downloaded and loaded by the applications.

In the following, an example policy definition is provided that would make sense in many electronic (e.g., mobile or tablet) devices 3, where each installed application is identified by an integer that is unique among all applications on the same device 3, and each application is allowed to write to an application specific data directory by default without requesting for extra permissions from the end user. The live-patch operations of the applications involves downloading and writing code to a specific file under the application data directory and later loading the code from the file. In this setup, a security policy may contain rules, where each rule may look like below.

In this security policy rule, the application identified by the integer value “5000” cannot write a file at the path “/data/app/5000/plugin/libxyz. so” if it does not exist, and cannot open it for reading if it already exists. Furthermore the policy engine 313 would report to the live-patch manager 312 when the application tries to write to the file.

Such security rules assume that the application “5000” always tries to write live-patch code to specific locations in the file system, which is typically the case with many known live-patch frameworks or libraries. If an application developer or live-patch framework/library developer attempts to circumvent such straight-forward security policy rules, more complex rules and enforcement mechanisms may be required. In other words, the security policy definition and enforcement should not be seen as a static process but rather an evolving one.

FIG. 2 illustrates a method 2 for control of live-patching of an application on a plurality of electronic devices 3 in accordance with the present disclosure.

An analyzer engine 4 comprising a processor 41 is provided. The processor 41 may be configured to perform said method 2.

The method 2 comprises providing 21, by an analyzer engine 4 disposed remotely from the plurality of electronic devices 3, a device-specific security policy for the electronic device 3 in accordance with application-specific live-patch statistics related to the application on the plurality of electronic devices 3.

In particular, the analyzer engine 4 may comprise an analyzer cloud service.

The providing 21 of the device-specific security policy may comprise retrieving 211 the application-specific live-patch statistics relating to each of the plurality of electronic devices 3.

The providing 21 of the device-specific security policy may further comprise aggregating 212 the application-specific live-patch statistics over a period of time.

The providing 21 of the device-specific security policy may further comprise filtering 213 the application-specific live-patch statistics.

The providing 21 of the device-specific security policy may further comprise acquiring 214, from a malware detection engine 5, an application-specific security policy in accordance with the application-specific live-patch statistics relating to the plurality of electronic devices 3. The application-specific security policy may define if the file executed by the application is potentially malicious.

In particular, the malware detection engine 5 may comprise a malware detection cloud service.

The malware detection cloud service may be configured to determine if any of the files involved in application live-patching are potentially malicious. In practice, the malware detection cloud service may be an on-line service provided by an anti-virus or anti-malware company.

The providing 21 of the device-specific security policy may further comprise generating 215 the device-specific security policy in accordance with the application-specific security policy. The device-specific security policy may define an action relating to the application and/or the file executed by the application.

The providing 21 of the device-specific security policy may further comprise digitally signing 216 the device-specific security policy, and may further comprise submitting 217 the device-specific security policy to the electronic device 3.

FIG. 3 illustrates a message flow in accordance with the present disclosure.

The message flow involves an electronic device 3 (i.e., a consumer device) , an analyzer engine 4 disposed remotely from the electronic device 3, and a malware detection engine 5 disposed remotely from the electronic device 3 and the analyzer engine 4.

The electronic device 3 comprises a processor 31 being configured to perform the method 1 for control of live-patching of an application on an electronic device 3. The electronic device 3 further comprises executable code relating to an application manager 311, a live-patch manager 312, and a policy engine 313, respectively.

The analyzer engine 4 comprises a processor 41 being configured to perform the method 2 for control of live-patching of an application on a plurality of electronic devices 3.

On the right of the analyzer engine 4 a malware detection engine 5 is provided.

A number of applications may be installed on the electronic device 3, either from an official application distributor, a 3 ^rd party application distributor, or by an end user.

During run-time, these applications may write executable code or bytecode as files into specific locations of the file systems provided by the operating system of the electronic device 3, and may load and execute such code or bytecode at a later time. Such application behaviors may be monitored and recorded by the application manager 311.

The application manager 311 may use the recorded data to determine which operations are live-patch operations of the applications. For example, the application manager 311 may monitor all file accesses from a specific application, and check if files created by the application contains executable code or bytecode, and if such code is later executed. Similarly, the application manager 311 may also monitor modifications to existing files that contain executable code or bytecode, and see if the modified file is later loaded and executed by the application. If a file containing such live-patch code or bytecode is executed, the characteristics of the application and the file, such as the application identifier, the file name/path and the hash value if the file content, is collected and sent to the live-patch manager 312 on the electronic device 3.

The live-patch manager 312 may be operable to aggregate the statistics reported by the application manager 311over a period of time, anonymize the statistics data, and report the anonymized data to the analyzer engine 4, in accordance with the method steps 111-113 mentioned previously.

This initial phase of the method 1 may be referred to as statistics collection phase “A” indicated on the right of FIG. 3.

The statistics collection phase may allow the analyzer engine 4 to collect a potentially large amount of information to facilitate malware detection, where the statistics data may be further aggregated, analyzed, and/or filtered, in accordance with the method steps 211-213 mentioned previously.

The characteristics of the files (mainly the hash values in practical systems) may then be sent to the malware detection engine 5 to determine if any of the files involved in application live-patch are potentially malicious, in accordance with the method step 214 mentioned previously.

Upon receipt of the malware detection results, the analyzer engine 4 may be able to identify precisely which live-patch file downloaded, written and loaded by which application is potentially malicious. In this way, for each electronic device 3 the analyzer engine 4 may be able to generate a device-specific security policy comprising entries that regulate which files or directories for which applications should be prevented from accessing. Such a security policy may signed by the analyzer engine 4 and distributed to the live-patch manager 312 on the electronic device 3, in accordance with the method steps 215-217 mentioned previously.

The received security policy may then be received, validated and de-anonymized by the live-patch manager 312, in accordance with the method steps 122-123 mentioned previously.

This second phase of the methods 1, 2 may be referred to as policy distribution phase “B” indicated on the right of FIG. 3.

With the policy received from the analyzer engine 4, the live-patch manager 312 may be operable to configure the policy engine 313, so that the security policy can be enforced. The policy engine 313 may use other system services and invoke an Application Programming Interface (API) provided by the operating system of the electronic device 3 for policy enforcement, in accordance with the method step 131 mentioned previously.

For example, if an application tries to access a file at a location specified by the security policy where the file access should not be permitted, the underlying operation system should reject the access request from the application. The file access may be one of the common file system operations, such as file creation, opening, reading, writing or deletion. The actual mechanisms on top of which such enforcement can be implemented depend on the capabilities provided by the operating system and other system services hosted on the electronic device 3.

This third phase of the method 1 may be referred to as policy enforcement phase “C” indicated on the right of FIG. 3.

Similar to the application statistic collection, the statistics of the policy enforcement may also be collected, such as which file accesses are rejected or allowed, whether any errors or unexpected events occurred, and the like, in accordance with the method step 132 mentioned previously.

This allows the live-patch manager 312 to report to the end-user about the security policy and the status of the enforcement.

This fourth phase of the method 1 may be referred to as enforcement statistics phase “D” indicated on the right of FIG. 3.

Subsequently, an interaction with the end user may take place.

After the live-patch manager 312 receives a policy from the analyzer engine 4 and the policy is enforced by the policy engine 313, the status and the statistics of the enforcement being collected by the live-patch manager 312 may be presented to the end-user via a settings user interface (UI) , in accordance with the method step 141 mentioned previously. A setting UI may refer to a software component hosted on the electronic device 3 being configured to present a policy enforcement status and corresponding statistics to the end user and allow the end user to make custom choices.

The status and the statistics may include information such as a list of applications that have attempted live-patch operations, a list of applications whose live-patch operations are controlled by the current security policy, a list of operations that are rejected according to the policy, a list of operations that are allowed, the last time a cloud policy was received, the status of the security policy engine, and so on.

The end-user may then be presented with options to adjust the security policy. For example, if the end-user believes that the live-patch control that is currently applied to a specific application has affected the functionality of the application and made an important service provided by the application unavailable to the end user, the end user may choose to lift the restrictions currently applied on the application and allow it to live-patch. In another example, the end-user may choose to disallow live-patch of an application, which is allowed by the security policy, in accordance with the method step 142 mentioned previously.

Such decisions may then be translated to a local security policy by the live-patch manager 312, which is then combined with the cloud policy to form a final aggregated (i.e., modified) security policy, and the policy engine 313may be reconfigured with the aggregated security policy to take it into effect, in accordance with the method step 143 mentioned previously.

This final phase of the method 1 may be referred to as policy customization phase “E” indicated on the right of FIG. 3.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed matter, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

A method (1) for control of live-patching of an application on an electronic device (3) , the method (1) comprising

- collecting (11) application-specific live-patch statistics related to the application;

- obtaining (12) , from an analyzer engine (4) disposed remotely from the electronic device (3), a device-specific security policy for the electronic device (3) in accordance with the application-specific live-patch statistics; and

- applying (13) the device-specific security policy on the electronic device (3) .
The method (1) of claim 1, further comprising

- modifying (14) the device-specific security policy on the electronic device (3) in accordance with user feedback.
The method (1) of any one of the claims 1 to 2,

the collecting (11) comprising

- monitoring (111) , by an application manager (311) of the electronic device (3) , whether a file manipulated by the application is being executed;

- determining (112) , by the application manager (311) , the application-specific live-patch statistics related to the application and the file executed by the application; and

- submitting (113) , by the application manager (311) to a live-patch manager (312) of the electronic device (3) , the application-specific live-patch statistics;

the application-specific live-patch statistics comprising at least one of:

- an identifier of the application,

- a path name of the file executed by the application, and

- a hash value of a content of the file.
The method (1) of claim 3,

the application manager (311) comprising an application management system service of the electronic device (3) .
The method (1) of any one of the claims 1 to 6,

the collecting (11) further comprising

- retrieving (114) , by the live-patch manager (312) , the application-specific live-patch statistics;

- aggregating (115) , by the live-patch manager (312) , the application-specific live-patch statistics over a period of time; and

- anonymizing (116) , by the live-patch manager (312) , the application-specific live-patch statistics;

the anonymized live-patch statistics comprising at least one of:

- a hash value of the identifier of the application,

- a hash value of the path name of the file executed by the application, and

- a hash value of the content of the file.
The method (1) of any one of the claims 1 to 5,

the live-patch manager (312) comprising a live-patch management system service of the electronic device (3) .
The method (1) of any one of the claims 1 to 6,

the analyzer engine (4) comprising an analyzer cloud service.
The method (1) of any one of the claims 1 to 7,

the obtaining (12) of the device-specific security policy comprising

- submitting (121) , by the live-patch manager (312) to the analyzer engine (4) , the application-specific live-patch statistics;

- retrieving (122) , by the live-patch manager (312) , the device-specific security policy; and

- de-anonymizing (123) , by the live-patch manager (312) , the device-specific security policy;

the de-anonymized device-specific security policy comprising at least one of:

- the identifier of the application,

- the path name of the file executed by the application, and

- the action relating to the application and/or the file.
The method (1) of any one of the claims 1 to 8,

the applying (13) of the device-specific security policy comprising

- causing (131) , by the live-patch manager (312) , a policy engine (313) of the electronic device (3) to enforce the device-specific security policy; and

- retrieving (132) , by the live-patch manager (312) , policy enforcement statistics related to the device-specific security policy.
The method (1) of any one of the claims 2 to 9,

the modifying (14) of the device-specific security policy comprising

- displaying (141) , by the live-patch manager (312) , the device-specific security policy and/or the policy enforcement statistics related to the same on a user interface;

- receiving (142) , by the live-patch manager (312) , a modification of the device-specific security policy via the user interface; and

- causing (143) , by the live-patch manager (312) , the policy engine (313) of the electronic device (3) to enforce the modified device-specific security policy.
A method (2) for control of live-patching of an application on a plurality of electronic devices (3) , the method (2) comprising

- providing (21) , by an analyzer engine (4) disposed remotely from the plurality of electronic devices (3) , a device-specific security policy for the electronic device (3) in accordance with application-specific live-patch statistics related to the application on the plurality of electronic devices (3) .
The method (2) of claim 11,

the analyzer engine (4) comprising an analyzer cloud service.
The method (2) of any one of the claims 11 to 12,

the providing (21) of the device-specific security policy comprising

- retrieving (211) the application-specific live-patch statistics relating to each of the plurality of electronic devices (3) ;

- acquiring (214) , from a malware detection engine (5) , an application-specific security policy in accordance with the application-specific live-patch statistics relating to the plurality of electronic devices (3) , the application-specific security policy defining if the file executed by the application is potentially malicious;

- generating (215) the device-specific security policy in accordance with the application-specific security policy, the device-specific security policy defining an action relating to the application and/or the file executed by the application; and

- submitting (217) the device-specific security policy to the electronic device (3) .
The method (2) of any one of the claims 11 to 13,

the providing (21) of the device-specific security policy further comprising

- aggregating (212) the application-specific live-patch statistics over a period of time.
The method (2) of any one of the claims 11 to 14,

the providing (21) of the device-specific security policy further comprising

- filtering (213) the application-specific live-patch statistics.
The method (2) of any one of the claims 11 to 15,

the providing (21) of the device-specific security policy further comprising

- digitally signing (216) the device-specific security policy.
The method (2) of any one of the claims 11 to 16,

the malware detection engine (5) comprising a malware detection cloud service.
An electronic device (3) , comprising

a processor (31) , being configured to perform the method (1) of any one of the claims 1 to 10.
An analyzer engine (4) , comprising

a processor (41) , being configured to perform the method (2) of any one of the claims 11 to 17.
A computer program, comprising executable instructions which, when executed by a processor (31; 41) , cause the processor (31; 41) to perform the method (1) of any one of the claims 1 to 10 or the method (2) of any one of the claims 11 to 17.