Field of the Invention

[0001] This disclosure relates generally to mobile device security, more specifically for identifying a risk of system access operations on a mobile device.

Background of the Invention

[0002] Mobile devices (e.g. running Android (RTM) or iOS (RTM) mobile operating systems) are exploitable, enabling persistent footholds onto these devices for malicious actors via the installation of apps. These apps (often referred to generally as "malware") can use the mobile device functions for the benefit of malicious actors. This has been achieved in the past by some or all of: listening in to conversations via the microphone, recording the camera and blackmailing the user, recording the screen to steal passwords and other personal information from the device, recording calls to listen in on conversations and using location information to track a user's whereabouts. [0003] Apps that exhibit malicious or otherwise considerably unwanted behaviour can come from anywhere, even trusted software marketplaces. As a direct result of recent advancements and increase in quantity of mobile malware, businesses and consumers alike are facing financial implications following these security breaches. The shift towards an increasing amount of corporate data residing on organisations' mobile devices has resulted in 67 % of organisations having suffered a data breach due to their mobile devices. This problem is only predicted to worsen with 1/3 of all malware expected to be mobile in 2019.

[0004] There is therefore an ever-increasing need to protect against mobile malware and mobile app permission abuse.

Statements of the Invention

[0005] In one aspect of the invention, there is provided a computerised method for calculating a risk rating of system access operation events by means of real-time system access operation monitoring and contextual system state analysis on a mobile device. The method includes calculating a system access operation event risk rating based upon a computational model e.g. a classification model to deduce the context of a system access operation. Responsive actions may be enabled on the basis of the risk rating.

[0006] The context may be based on contextual system state information comprising one or more of: time of system access operation, system access operation type, lock state of the device, interactivity state of the device (for example one or more of: whether the user is interacting with the device, the power state of the device (e.g. device idle, device charging, device dreaming, CPU idle, screen is on/off)), relevant foreground Information on apps that are running or have been running in the foreground, any apps associated with the system access operation and their relevant information, a list of all active network connections, the associated app to the process ID that holds the handle to each respective TCP Socket and its relevant information. The relevant information may include permissions, app name, version, developer, signing certificate information, app category and/or file hash and/or associative file hash, the files themselves and/or file system access operations (e.g. the APK installer or the constituent files themselves). The contextual state information may also include information on any other apps running on the mobile device, for example if it is not possible to identify or deduce the associated apps based on foreground or network activity.

[0007] The contextual system state information is provided to a risk rating calculation thread or method which may be spawned from or run within a system listener service that captures the contextual system state information in real time when a system access operation occurs. The system listener service may comprise one or more system access operation type listeners, the operations including for example camera, microphone, location, display state, phone state (e.g. calls) and/or app install events.

[0008] One or more apps responsible for and/or associated with the system access operation may be deduced based upon the contextual system state information passed from the system listener service. A risk rating of a deduced perpetrator app and/or accessory app associated with a system access operation event may be calculated based upon relevant information as defined above, relevant foreground information, network information (e.g. IP Address, Port, domain name etc.) and/or an average of calculated risk ratings spanning all system access operation events with which the perpetrator app and/or accessory app is associated.

[0009] The relevant foreground information obtained may include one or more of: the first, total and last time spent in the foreground, the total and last time the app was visible in the Ul, the total and last time the app's foreground service was used and/or visible, additional usage statistics events and additional relevant information, such as permissions, app name, version, developer, signing certificate information, app category, file hash and/or associative file hashes and/or the files themselves, and/or file system access operations. The relevant foreground information may also be obtained for apps with network connections and/or any other apps installed on the system.

[0010] A device risk rating may be calculated based upon one or more factors including: OS type, OS version and consideration of other system-wide activity including frequency and risk rating of previous system access operation events, and app risk ratings for apps installed on the device.

[0011] The risk rating(s) may be normalized into a scale (e.g. %) to prioritize and act as a reference point for events.

[0012] The system access operation event context and associated application(s) from the computational classification model may have an associated certainty score based upon supervised and/or unsupervised data classification, analysis and correlation.

[0013] The supervised data classification may be achieved by prompting users or administrators to provide feedback on suspected uncertain deductions and their correct assumptions. For example, if the user or administrator suspects the deduced associated apps to be incorrect, they can modify this e.g. by identifying another associated app. In another example, the user or administrator may reclassify a risk rating for a system operation event and/or an app. In either example, or other examples, a manual override corresponding to the modification or reclassification is added into the associated system access operation event entry in the local database and/or a remote database.

[0014] The user may be alerted visually via a notification when a system access operation is active (e.g. if the microphone, camera, call recording or screen recording is active). In response to an alert of the risk rating, the local user may perform one or more responsive interactions (e.g. uninstall an app, revoke permissions or kill background processes) to system access operation type listeners locally on the device, or a remote administrator may perform responsive interactions and/or manage the configuration of the system via a remote, web- based console or via an MDM (mobile device management) API (application programming interface).

[0015] A combination of data from the risk ratings of the system access operation events, the deduced apps associated with the system access operation events, the system access operation events themselves and/or contextual system state analysis may be used to identify correlations in behaviour of applications that are behaving in an unauthorized manner (e.g. malicious or suspicious intent).

[0016] A plurality of concurrently active system access operation type listener triggers can be combined to identify additional system access operation types (e.g. Phone State (Call) + Microphone = Call recording).

[0017] The risk ratings and associated information may be stored in a local database on the device and a background data transfer service running locally on the computerised mobile device may authenticate with a remote API gateway and periodically synchronize the data across a network via an encrypted session into a centralised database/indexing engine for correlation. The information transferred from the device may be anonymized before transfer by the background data transfer service.

[0018] Other aspects of the invention include a (non-transient) computer program product arranged to perform the method of the invention when installed on a mobile device.

Brief Description of the Drawings

[0019] Specific embodiments of the present invention will now be described with reference to the accompanying drawings, in which:

Figure 1 is a schematic showing the system and interaction between subsystems on a mobile device in an embodiment of the invention;

Figure 2 is an exemplary flow diagram illustrating the steps of a computational classification model for initial risk rating based on display state system access operation event in the embodiment;

Figure 3 is an exemplary flow diagram illustrating the steps of the computational classification model for initial risk rating based on location system access operation event;

Figure 4 is an exemplary flow diagram illustrating the steps of the computational classification model for initial risk rating based on camera system access operation event;

Figure 5 is an exemplary flow diagram illustrating the steps of the computational classification model for initial risk rating based on microphone system access operation event; Figure 6 is an exemplary flow diagram illustrating the steps of the computational classification model for initial risk rating based on app install system access operation event;

Figure 7 is an exemplary flow diagram illustrating the steps of the computational classification model for initial risk rating based on call recording system access operation event;

Figure 8 is an exemplary flow diagram illustrating the steps of the computational classification model for initial risk rating based on phone state change (call) system access operation event; Figure 9 is a diagram of the background data transfer service architecture in the embodiment; Figures 10-12 are examples of screenshots from an app on the mobile device in an embodiment of the invention, showing respectively:

Figure 10: app analysis Figure 11: app install detection analysis; and

Figure 12: camera use detection analysis;

Figure 13 is an example of a screenshot from a web-based EDR platform in an embodiment of the invention.

Figures 14-17 are examples of screenshots from an app on the mobile device in another embodiment of the invention, showing respectively:

Figure 14: dashboard

Figure 15: timeline analysis

Figure 16: camera use detection analysis; and Figure 17: microphone access detection analysis.

Figures 18 and 19 are examples of screenshots from a web-based EDR platform in another embodiment of the invention, showing respectively a dashboard display and an event display.

Description of Specific Embodiments

System Overview

[0020] Figure 1 is a schematic diagram showing the system and interaction between subsystems on a mobile device to achieve the computer-implemented method of an embodiment of the invention.

[0021] The mobile device itself may be of a conventional type, comprising for example a processor, memory, a display, an input device e.g. a keyboard or touchscreen, a camera, microphone, navigation signal (e.g. GPS) receiver and/or one or more wireless interfaces (e.g. 3G/4G/5G mobile, Bluetooth (RTM) NFC and/or WiFi (RTM)). The mobile device may be a portable computing device such as a smartphone, personal digital assistant, wearable device (e.g. smart watch), tablet or single board computer device such as an loT (Internet of Things) device. The mobile device may run a mobile OS, such as iOS (RTM), Android (RTM) or an embedded OS such as Android Things. One or more mobile application programs or 'apps' may be installed, typically from a digital distribution platform such as the App Store for iOS (RTM) or Play Store for Android (RTM) and run on the mobile device, within the mobile OS. On or more services may also be run within the mobile OS.

[0022] The subsystems in this embodiment comprise system access operation event listener service 101, risk calculation thread 102 and a local database 103. The system access operation event listener service 101 is a background service that comprises a plurality of system access operation listeners to trigger an event in real-time when a system access operation occurs; for example, by using native library calls such as: broadcast receivers, callbacks and listeners. [0023] The plurality of system access operation listeners may comprise at least some of the following system access operation event types 112:

• camera system access operation listener 104

• microphone system access operation listener 105

• phone state system access operation listener 106

• display state system access operation listener 107

• location system access operation listener 108

• install event system access operation listener 109

[0024] Once any of the said system access operation listeners are triggered, the listener service obtains a snapshot of the contextual system state information 110 at the time of the triggered event. The contextual system state information 110 may comprise one or more of:

• Time of System access operation Event 111 • System access operation Event Type 112

• Device Locked State 113

• Device Interactivity State 114, for example one or more of: whether the user is interacting with the device, the power state of the device (e.g. device idle, device charging, device dreaming, CPU idle, screen is on/off)

• Relevant foreground Information on apps that are running or have been running in the foreground 115

• Any apps associated with the system access operation and their relevant information

116 · A list of all active network connections, the associated app to the process ID that holds the handle to each respective TCP Socket and its relevant information 117 [0025] For each of the events triggered by one of the system access operation listeners, the contextual system state information 110 is obtained and a risk calculation thread 102 is spawned. The risk calculation thread 102 is passed all of the contextual system state information 110 obtained for the respective system access operation events. The risk calculation thread 102 then accesses a computational classification model to deduce the context, associated apps and calculate an initial risk rating 118 to the system access operation event. Exemplary flow diagrams illustrating the steps of an embodiment of the computational classification model for initial risk rating 118 based on system access operation event type are represented in Figures 2-8.

[0026] Once the initial risk rating 118 is calculated, a risk rating of apps associated with the system access operation event 119 and a device risk rating 120 are then considered, to calculate a final risk rating 121. The risk rating of apps associated with system access operation event 119 is calculated/re-calculated in the risk calculation thread 102 and may be based on a plurality of variables including: an average of all system access operation event initial risk ratings to which each app is associated, their permissions, app name, version, developer, signing certificate information, app category and file hash (and/or associative file hash(es) and/or the files themselves and/or file system access operations). Once the risk rating of deduced apps associated with system access operation event 119 is calculated/recalculated, it is inserted/updated into the local database 103.

[0027] The device risk rating 120 is calculated in the risk calculation thread 102 and may be based on one or more variables including: OS, OS version and/or other system-wide activity including frequency and risk rating of previous system access operation events and app risk ratings for apps installed on the device. Once the device risk rating 120 is calculated/recalculated, it is inserted/updated into the local database 103 [0028] Finally, once the final risk rating 121 for a specific system access operation event is calculated, it is inserted into the local database 103 along with the contextual system state information 110, and the respective risk calculation thread 102 is killed.

[0029] In an alternative embodiment, the risk calculation method may be performed in the same thread or process as the system listener.

Computational Classification Model Examples

[0030] In the examples shown in Figures 2-8, the term "perpetrator app" refers to the app deduced, determined or predicted to be responsible for the system access operation that triggered the system access operation event listener. This determination or deduction may be based upon the apps' relevant information e.g. permissions, foreground information, network connection information, SFIA 256, app category, name, signing cert, version etc.

[0031] The term "accessory app" refers to any additional apps determined relevant to the system access operation event.

[0032] Where it is not possible to identify the perpetrator app and/or accessory apps by the above techniques (e.g. PA=Unknown or AA=Unknown in Figures 2-8), the method may include checking the UID, package name, version or file hash and/or associative file hash(es) and/or the files themselves and/or file system access operations of all apps installed or running system-wide to confirm if they are running in the background and if so, deducing the perpetrator app and/or accessory app(s) based upon the running apps' relevant information (e.g. permissions, SFIA 256, app category, name, signing cert, version etc.).

[0033] The exemplary computational classification model in one embodiment is a decision tree in which a system access operation event of a specific type is triggered. The computational classification model uses a series of nested logic operators to predict the context of a display attachment and assign an appropriate initial risk rating 118. Dependent upon the path through the decision tree, an appropriate result code and risk rating is assigned to each system access operation event, using for example the result code lookup table of Figure 10.

[0034] Figure 2 is an exemplary flow diagram illustrating the steps of an embodiment of the computational classification model for initial risk rating based on a display state system access operation event. In this context the system access operation may be recording the screen. The accessory app refers to any additional relevant apps to the system access operation event e.g. the app that was in the foreground when screen recording occurred.

[0035] The result of logic operator 202 is dependent upon the foreground apps, their last time in the foreground as passed by the system listener service 101.

[0036] Figure 3 is an exemplary flow diagram illustrating the steps of an embodiment of the computational classification model for initial risk rating based on a location system access operation event. In this context the system access operation event may be access to location information.

[0037] The result of logic operator 302 is dependent upon the device interactivity state determined by a user's interactivity with the device as passed by the system listener service 101.

[0038] The result of logic operator 303 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation.

[0039] The result of logic operator 305 is dependent upon whether the other most recent apps to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0040] The result of logic operator 306 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0041] The result of logic operator 310 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation.

[0042] The result of logic operator 312 is dependent upon whether the other most recent apps to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0043] The result of logic operator 314 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0044] Figure 4 is an exemplary flow diagram illustrating the steps of an embodiment of the computational classification model for initial risk rating based on a camera system access operation event. In this context the system access operation may be access to the camera. [0045] The result of logic operator 409 is dependent upon the device locked state as passed by the system listener service 101 for the respective system access operation event.

[0046] The result of logic operator 402 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation.

[0047] The result of logic operator 403 is dependent upon whether the other most recent apps to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0048] The result of logic operator 404 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0049] The result of logic operator 410 is dependent upon the device interactivity state e.g. is the screen on as passed by the system listener service 101 for the respective system access operation event.

[0050] The result of logic operator 411 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation.

[0051] The result of logic operator 413 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0052] The result of logic operator 416 is dependent upon whether the most recent app to be in the foreground is the default camera app for the operating system, as passed by the system listener service 101 for the respective system access operation event, and is deduced to be responsible for this operation.

[0053] The result of logic operator 417 is dependent upon whether the system access operation is deduced to have been triggered by the "face unlock" feature on the device. The deduction is based upon the contextual system state information 110 e.g. is the device locked and interactive and have there been other recent state changes?

[0054] The result of logic operator 420 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation. [0055] The result of logic operator 422 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0056] Figure 5 is an exemplary flow diagram illustrating the steps of an embodiment of the computational classification model for initial risk rating based on a microphone system access operation event. In this context the system access operation may be access to the microphone. [0057] The result of logic operator 509 is dependent upon the device locked state as passed by the system listener service 101 for the respective system access operation event.

[0058] The result of logic operator 502 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation.

[0059] The result of logic operator 503 is dependent upon whether the other most recent apps to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0060] The result of logic operator 505 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0061] The result of logic operator 510 is dependent upon the device interactivity state determined by a user's interactivity with the device as passed by the system listener service 101.

[0062] The result of logic operator 511 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation.

[0063] The result of logic operator 513 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0064] The result of logic operator 516 is dependent upon whether the most recent app to be in the foreground is the default camera app for the OS, as passed by the system listener service 101 for the respective system access operation event, and is deduced to be responsible for this operation.

[0065] The result of logic operator 517 is dependent upon whether the most recent app to be in the foreground is the voice assist app for the OS, as passed by the system listener service 101 for the respective system access operation event, and is deduced to be responsible for this operation. The deduction is based upon the system's voice assist settings relevant information e.g. is the voice assistant enabled?

[0066] The result of logic operator 520 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation.

[0067] The result of logic operator 522 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0068] Figure 6 is an exemplary flow diagram illustrating the steps of an embodiment of the computational classification model for initial risk rating based on app install system access operation event. In this context the perpetrator app may be the app that installed another app. The accessory app refers to any additional relevant apps to the system access operation event e.g. the app that was installed by the perpetrator app.

[0069] The result of logic operator 602 is variant based upon the app's relevant information e.g. file hash (and/or associative file hash(es) and/or the files themselves and/or file system access operations), app name, app category, signing cert, version etc. as passed by the listener service 101.

[0070] The result of logic operator 603 is a variant based upon whether the marketplace app, as passed by the system listener service 101 for the respective app install event, is one which is deemed to be trusted e.g. Google play store/Apple app store.

[0071] The result of logic operator 604 is a variant based upon whether the marketplace app, as passed by the system listener service 101 for the respective app install event, is unknown. [0072] The result of logic operator 608 is a variant based upon whether the installed app, as passed by the system listener service 101 for the respective app install event, is one which information is already known in the local database 103.

[0073] The result of logic operator 609 is dependent upon whether one of the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0074] Figure 7 is an exemplary flow diagram illustrating the steps of an embodiment of the computational classification model for initial risk rating based on call recording system access operation event. In this context the perpetrator app may be the app that is suspected of recording a phone call. The accessory app refers to any additional relevant apps to the system access operation event e.g. the app that made a phone call which was suspected to have been recorded.

[0075] The result of logic operator 702 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0076] The result of logic operator 703 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation.

[0077] The result of logic operator 706 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation.

[0078] Figure 8 is an exemplary flow diagram illustrating the steps of an embodiment of the computational classification model for initial risk rating based on a phone state change call system access operation event. In this context the perpetrator app may be the app deduced or suspected to have made a phone call.

[0079] The result of logic operator 802 is dependent upon the device locked state as passed by the system listener service 101 for the respective system access operation event.

[0080] The result of logic operator 803 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation.

[0081] The result of logic operator 805 is dependent upon whether the other most recent apps to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0082] The result of logic operator 806 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0083] The result of logic operator 813 is dependent upon the device interactivity state determined by a user's interactivity with the device as passed by the system listener service 101.

[0084] The result of logic operator 812 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation. [0085] The result of logic operator 811 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0086] The result of logic operator 817 is dependent upon whether the most recent app to be in the foreground is the default phone app for the OS, as passed by the system listener service 101 for the respective system access operation event, and is deduced to be responsible for this operation.

[0087] The result of logic operator 816 is dependent upon whether the most recent app to be in the foreground, as passed by the system listener service 101 for the respective system access operation event, is deduced to be responsible for this operation.

[0088] The result of logic operator 822 is dependent upon whether any of the apps with active network connections, as passed by the system listener service 101 for the respective system access operation event, are deduced to be responsible for this operation.

[0089] In the above embodiments, the computational model is a decision tree. Alternative models may be used, such as a machine learning model e.g. a deep learning neural network.

Background Data Transfer

[0090] Figure 9 is a diagram of the background data transfer service architecture in an embodiment of the invention, wherein data from local database 908 is periodically synchronized across a network by a background data transfer service 907 running locally on the mobile device (904). The background data transfer service 907 running locally on the mobile device 904 will initially authenticate across a network with an API gateway 901 (e.g. via OAuth 2, JWT or API Key). Upon successful authentication, the background data transfer service 907 running locally on the computerised mobile device 904 will then transfer the data across a network (e.g. in JSON over HTTPS) via an encrypted session (e.g. TLS) into a centralised database/indexing engine for correlation. The information transferred from the device may also be anonymized before transfer by the background data transfer service 907. [0091] The web front end 905 (e.g. Apache) is organically developed using HTML, CSS & JS and the back-end uses PHP (and possibly Node.js) to communicate with Elasticsearch 903 PHP API via Authentication through OpenDistro 901. The combination of OpenDistro 901, Elasticsearch 903 and web front end 905 comprise an EDR Platform, as shown for example in Figure 13 or Figures 18 and 19, that can be deployed commercially. Instance of these components may be used in order to collate and further analyse anonymized data, which may be anonymised or not, from end users of the technology. User Interface

[0092] A user interface (Ul) for accessing the system of the embodiment may be provided via a Ul app. System access operation events are accessible and may be represented graphically via the Ul app, in a graphical user interface (GUI). The highest risk events and/or apps (for example events with a risk rating equal to a threshold, such as 3 or 5) may be prioritised and brought to the user's attention via the GUI. These higher risk events may for example be brought to the user's attention via either or both of two methods: first, a notification pops up on the occurrence of a particularly high-risk event or high-risk app. By clicking into this notification, the user is brought to the detection analysis view for an event and an app analysis view for an app where they can respond to this high-risk activity. Secondly, the highest risk events and apps may be displayed upon opening the Ul app, for example in a dashboard display as shown in Figure 10 or Figure 14, allowing the user to drill down further into either an analysis of the app or information on the system access operation event in the detection analysis view. [0093] When a user chooses to drill down into an event by going onto the detection analysis view, they are presented with information about the event, as shown for example in Figure 11 for an app install event and in Figures 12 or 16 for a camera use event, and Figure 17 for a microphone access event. The identification of any apps suspected or deduced to be directly associated with the event is displayed, preferably along with a reason as to why this conclusion has been drawn. The user is presented with a risk rating and preferably the certainty of this deduction. If the user considers any of the deductions made in association to the respective system access operation event to be incorrect, they can reclassify the risk locally on the mobile device. If the user considers the app deduction wrong, they may look through a list of other potential apps and choose to manually override this deduction for improved accuracy. Flowever, if the user thinks that the information in the system access operation event is accurate, they may immediately take responsive action (e.g. revoke permissions or uninstall associated apps), for example as prompted in the mobile Ul under 'Suggested Actions'.

[0094] When the user goes into the app analysis view, as shown for example in Figure 10 or Figure 14, they may see the previous system access operation events to which the app was deduced to be associated, risk rating of the app, any app information accessible, and are given the ability to respond to the app by uninstalling or revoking permissions. [0095] The mobile Ul may include a timeline of risk events, as shown for example in Figure 15, in which each event in the timeline is categorised by risk level (e.g. low, med, high) and access type (e.g. microphone, camera, app install).

[0096] Via the GUI, the user can also directly share information on a system access operation event or on an app to social media (e.g. share directly to Linkedln (RTM), Twitter (RTM), Instagram (RTM), or Facebook (RTM), or generate a report). A user can also search for any app installed or previously installed on their device, which will take them directly to the app analysis view for the respective app.

[0097] Embodiments of the invention can be deployed in a commercial context (e.g. Enterprise Mode) whereby the app is enrolled to a single EDR Platform (901 + 903 +905) and uses OAuth2, JWT or API Tokens to authenticate. In this deployment mode, the app GUI will be changed accordingly (e.g. may not prompt the end user to check status) and may be used to display push notifications to the end user.

[0098] Alternatively or additionally to providing the above information on system access operation events to the user and awaiting a response from the user, a response may be generated automatically, based for example on one or more predefined policies; for example revoke permissions from or uninstall the perpetrator app for a system access operation event having a risk rating of 5.

Deployment Examples [0099] Embodiments of the invention may comprise a computer program, program code and/or a computer program product, which may for example be deployed in one or more of the following considered scenarios:

1. As a standalone Mobile Threat Defence/EDR Agent app for consumers which may be deployed via installation from a digital distribution platform such as the App Store for iOS (RTM) or Play Store for Android (RTM) and run on the mobile device.

2. As an enrolled and centrally managed Mobile Threat Defence/EDR Agent app for licensed commercial use which may be deployed via installation from a digital distribution platform such as the App Store for iOS (RTM) or Play Store for Android (RTM) or via a Mobile Device Management (MDM) platform to a digital distribution platform or as a standalone app installer (e.g. .APK or .ipa file) and run on the mobile device.

3. Integrated into a separate app (e.g. OEM to/from a third party) to coexist alongside other functionality. Risk Scoring Result Code Lookup Table

[00100]Table 1 below is an example of a risk scoring result code lookup table in an embodiment of the invention, for converting a result code as shown in Figures 2 to 8 into a risk rating.