RU108896U1 - SYSTEM TO ENSURE GENERAL SAFETY OF MOBILE DEVICES - Google Patents

Abstract

 1. The security system of mobile devices, which includes:! the security module associated with the configuration module, while the security module is designed to perform security tasks on a mobile device and transfer information related to security tasks to other mobile devices; ! said configuration module is intended to configure a security module depending on data received from the risk calculation module and the computing resource calculation module associated with the configuration module; ! said risk calculation module is intended to determine risks associated with the security of a mobile device; ! said computing resource calculation module is for determining the used hardware resources of a mobile device. ! 2. The system according to claim 1, in which the security objectives are:! a) preventing unwanted information from reaching the mobile device; ! b) the detection and removal of unwanted information on a mobile device; ! c) prevention of threats. ! 3. The system according to claim 1, in which the security module includes:! a) firewall; ! b) message filter; ! c) antivirus; ! d) recovery module; ! e) intrusion prevention module. ! 4. The system according to claim 1, in which the security module includes:! a) a module for connecting to a security server, designed to transfer data to perform security tasks on a remote computer; ! b) a group security module designed to determine the level of security in a group; ! c) a module for coordinating group tasks, designed to select and define

Description

Technical field

The utility model relates to systems for ensuring the overall security of mobile devices through the dynamic configuration of security modules.

State of the art

Currently, more and more mobile devices are used in the world, and the latest technologies allow integrating into them an increasing number of functions that were previously available only to desktop users. The proliferation of devices such as smartphones, handhelds or personal digital assistants (PDAs), ultra-mobile personal computers (UMPCs), and mobile Internet devices (MIDs) has become truly massive. Such devices use energy-efficient processors such as Intel Atom or based on the ARM architecture, the latest generation operating systems Android, Symbian OS, Windows Mobile, as well as connecting to networks such as 3G or WiMax or to IEEE 801 networks.

As the number of devices, as well as networks and their latency, grows, which approaches the speed of several megabytes per second at present, there is a serious risk of transmitting malicious and other unwanted programs. Previously, malware was the real scourge of only popular desktop platforms, such as Windows, which was caused by a large number of vulnerabilities, huge popularity among users and network connectivity, but nowadays, in the field of mobile technologies, prerequisites for a similar increase in malware and threats have appeared. At the moment, hackers and spammers are also beginning to widely use mobile technologies and networks to transfer data for phishing attacks, spamming, password theft and other unwanted activity.

Well-known technologies such as firewalls, antivirus software, or anti-spam solutions have worked well for desktop computers and large servers, but security solutions for mobile devices are a different case. Firstly, mobile devices should provide access to information almost anywhere in the world where there is access to use the capabilities of mobile networks. Secondly, mobile devices have a limited capacity of the used battery, which entails a limitation on the use of hardware resources in order to save. Thirdly, performance (as well as battery capacity) cannot be increased indefinitely, as mobile devices have very limited sizes. All these difficulties pose a truly non-trivial task to ensure the security of mobile devices.

It is also worth noting that many anti-virus companies have a number of security solutions for mobile devices, for example, such as Dr.Web Anti-Virus for Symbian OS, Trend Micro Mobile Security, McAfee Mobile Security. Such solutions implement the classic antivirus scan based on signatures, a number of other important security functions (for example, antispam) and rely on timely updating of antivirus databases. However, such solutions do not use technologies for exchanging data between devices or with antivirus companies that have similar protection systems, which makes them very vulnerable, given the growing number of threats, including for mobile devices. Also, such solutions do not solve the problems associated with the consumption of resources on a mobile device, which are very limited (first of all, this concerns the battery charge, since the capacity of the latter cannot be increased at the same rate as the processor performance). All this requires the creation of approaches that will allow you to flexibly assess the level of risk for a mobile device, taking into account a number of factors related to security, as well as the capabilities of a mobile device.

One of the possibilities, which is due to the large number of mobile devices, can be concluded in the use of so-called "cloud" technologies (hereinafter we will use this term without quotes). Cloud technologies usually mean data processing technologies in which computer resources are provided in the form of some distributed service (service). Applications and patents such as US 20080134316, US 20080091763, EP 1912 413. describe the use of cloud services for various tasks. Another use of cloud technology is to combine the computing resources of several devices to solve common problems, which is reflected in such applications and patents as US 7389358, US 20090228950, US 20090178131, WO 2008077150.

Currently, the practice of using the general risk assessment for all network nodes is reflected in patents US 7257630 and US 7543056. Thanks to the use of this technology, it is possible to assess the possible risk for the entire network (including wireless) from the point of view of various vulnerabilities in found programs and data transfer protocols. A further development of this idea is the construction of an internal secure network (common perimeter), which is described in such applications as US 20090178132, US 20090178131, US 20060248205, with the subsequent blocking of vulnerabilities (application US 20090178132).

Various companies involved in creating security systems also did not stand aside from the development of cloud technologies and offer services like Kaspersky Security Network or Panda Cloud Antivirus. However, such services are not able to work with various mobile devices, for which it is necessary to constantly evaluate the security of the network used and the changing composition of its devices to dynamically change the security level of both an individual device and all devices as a whole.

An analysis of the prior art and the possibilities that arise when combining them in one system, allows you to get a new result, namely a system to ensure the overall security of mobile devices. The result of this system is achieved through the dynamic configuration of security modules on mobile devices.

Utility Model Essence

The technical result of this utility model is to ensure the overall security of mobile devices by dynamically configuring security modules on each of the mobile devices.

Within one implementation option, a technical result can be achieved through the use of a system that consists of: a security module associated with a configuration module, while the security module is designed to perform security tasks on a mobile device and transfer information related to security tasks to other mobile devices; said configuration module, which is intended to configure the security module depending on the data received from the risk calculation module and the computing resource calculation module associated with the configuration module; said risk calculation module, which is intended to determine the risks associated with the security of a mobile device; said computing resource calculation module, which is intended to determine the used hardware resources of the mobile device.

In one of the private implementation options, the security objectives are: to prevent unwanted information from reaching the mobile device; detection and removal of unwanted information on mobile devices; threat prevention.

In one of the private embodiments, the security module includes: a firewall; message filter; antivirus; recovery module; intrusion prevention module.

In one of the private options for implementation, the security module includes: a connection module to the security server, designed to transfer data to perform security tasks. on a remote computer; group security module designed to determine the level of security in a group; group tasks coordination module designed to select and define security tasks to be performed on mobile devices.

In one of the private options for implementation, a group is a set of mobile devices integrated into a mixed network and having the ability to transfer data safely among themselves.

In one of the private embodiments, the risk calculation module comprises: a user behavior tracking module designed to determine whether user behavior matches risks associated with the security of the mobile device; Security event tracking module for recording all events related to mobile device security; an application analysis module for analyzing applications installed on a mobile device; location module, designed to determine the location of a mobile device; location database designed to determine the level of security of a particular geographic location

In one of the private embodiments, the computing resources calculation module uses the following data on the hardware resources of the mobile device: data on the battery charge of the mobile device; data on the frequency of use of the processor of the mobile device; data about the type of mobile device; data on the free memory of the mobile device; Data on network connections of a mobile device.

Brief Description of the Drawings

Additional objectives, features and advantages of the present utility model will be apparent from reading the following description of the implementation of the utility model with reference to the accompanying drawings, in which:

On figa shows a mobile device on which can be installed a system that implements the present utility model.

On figb depicts the architecture of the system, which is designed to ensure the security of mobile devices.

On figv shows a diagram of a mobile device in the case when the mobile device is outside the secure network.

On fig.1G depicts options for using a mobile device in various networks.

On figa shows a diagram reflecting the basic functions of the security module.

On figb shows a diagram of the security module at various levels of the network model, depending on what applications are installed on the mobile device.

Figv and 2G show two possible configurations of information security systems for mobile devices.

On fig.2D shows a diagram of the thin client on a mobile device using a separate encrypted connection to communicate with the security server.

3A illustrates a security system for a mobile device in accordance with one embodiment of the present utility model.

On figb shows a diagram of the database locations.

Figure 4 shows the security system of a mobile device.

5A shows a risk calculation module.

On figb the algorithm for determining the model of user behavior.

Figure 6 shows an example implementation of a module for computing resources.

7A shows an update algorithm for a threat description depending on the performance of a mobile device.

On figb shows a circuit off various components of this module depending on the battery charge.

On figa shows a diagram of a group of mobile devices.

On figb shows a database of devices that contains a mobile device.

Fig. 8B illustrates various groups of mobile devices in various locations.

Fig. 8G shows a diagram of adding a new device to a group.

Fig. 8D shows an algorithm for selecting security tasks by one of the group devices.

9A illustrates an example task database.

Fig. 9B shows a consideration of the criteria for selecting a task by a group device.

Fig. 9B describes an algorithm for verifying confidence criteria.

On figa shows the database update component of the security module.

Figb shows a variant of the group when a new threat is detected.

Fig. 10B illustrates checking the executable file before running it on one of the devices in the group.

10G illustrates a case associated with the discovery of a new data store by one of the devices of the group.

Fig. 10D shows the change in the level of the power of attorney of the device in the event that a new vulnerability has been discovered related to the applications, operating system or hardware of one of the devices.

Description of Embodiments of a Utility Model

The objects and features of the present utility model, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present utility model is not limited to the exemplary embodiments disclosed below, it can be embodied in various forms. The essence described in the description is nothing more than the specific details provided to assist the specialist in the field of technology in a comprehensive understanding of the utility model, and the present utility model is determined only in the scope of the attached formula.

On figa shows a mobile device on which can be installed a system that implements the present utility model. The mobile device 100 may be a smartphone, PDA or PDA, an ultramobile personal computer (UMPC), a mobile Internet device (MID), or another device of a similar class. Currently, such devices, as a rule, combine compact dimensions and a wide touch screen for the convenience of input / output of information. The mobile device has its own processor 110 and memory 120, which are used for various computing tasks. Both the processor 110 and the memory 120 consume the resources of the battery (accumulator) 150, which is also used during operation of the location module 130 and the communication device 140. The location module 130 may be represented by a GPS receiver in one embodiment, while the device Communications 140 may use one or more types of communications, including mobile communications standards (GSM, CDMA, Indium, and others) and other wireless communications standards such as Wi-Fi or Bluetooth. When operating in various networks, the mobile device 100 can transmit data to other similar devices, thus forming a kind of mixed network. In such a network, some devices can be interconnected using one communication standard (for example, Bluetooth), while some of them can be connected to other devices via a Wi-Fi standard network.

FIG. 1B depicts a system architecture that is designed to provide security for mobile devices 100. Security server 170 monitors and verifies traffic between internal network 165 and external network 185 (typically, external network means the Internet). Traffic is generated by users through the use of their mobile devices, such as mobile device 100, on which various applications 160 can be installed - for example, an Internet pager or an email client. Server applications 180 can also be installed on the server, which ensure the correct operation of providing data for applications on a mobile device. An example of such an application can be called, for example, a dedicated web server for processing http-requests from users. In addition to applications that provide data transfer and processing, other server applications 180 can be installed on the server, which are designed to provide security - for example, a firewall. To manage a large number of applications, the server has a management console 175 (usually using a graphical interface) that can be used to configure server applications 180. As a rule, administrators use this console 175, but some settings can be set automatically when certain factors are triggered, such as the appearance of vulnerabilities in installed applications 160 or with the threat of virus infection. The system shown in FIG. 1B is generally accepted and well suited for local and fairly small networks, but only if the mobile device 100 is within the scope of such a secure network.

Figure 1B shows a diagram of the operation of a mobile device 100 when it is outside the secure network shown in Figure 1B and there is a need to use its own security module 190, which can be configured using the control console 195. Such an option is often They call it a “thick” client, which can contain the basic functions of ensuring computer security, such as a firewall, message filter, file and web antivirus. However, this embodiment has several drawbacks associated primarily with the cumbersomeness of such a solution, since it is an active consumer of system resources and, accordingly, battery power, and a complicated set of functions, which makes it difficult to manage the security module 190 in case of lack of skills.

In some cases, it is not always obvious which protection option from those proposed in FIGS. 1B and 1C is preferable. On fig.1G depicts the options for using the mobile device 100 in various networks. For example, when using the mobile device 100 at home or at work, the user can work under the protection of the security server 170, but when in a public place (for example, an airport or a cafe), the user can only rely on their own strength in the form of installed security applications, since it can be subjected to attack by hackers, as well as other types of threats, such as malware entering mobile device 100 through vulnerabilities in applications 160. To protect against these threats, the one already mentioned can serve a security module 190, which may be introduced. applications (or perform their functions) such as a firewall, spam filter, file and web antivirus. Let us consider in more detail the possible types of threats and countermeasures.

FIG. 2A is a diagram illustrating the main functions of the security module 190, which is the most widespread circuit at present for modern mobile devices. A module can mean a specialized integrated circuit (ASIC), a matrix of logic elements with operational programming (FPGA), or any other combination of software and hardware parts (firmware). The main functions of the security module 190 can be implemented as separate independent components, but can also be implemented using common hardware.

Security module 190 may perform functions related to the prevention of unwanted information 202, the detection / removal of unwanted information 204, and the prevention of threats 206. The prevention of unwanted information 202 means the blocking of threats such as various malicious programs (viruses, worms, trojans), spyware programs, free programs with advertising and banners (spyware, bannerware), as well as the prevention of possible hacker attacks and hacking attempts, receiving an unwanted schedule and other similar threats. Detection / removal of unwanted information 204 means the search for those unwanted programs and threats that are already on the mobile device 100. This can happen when, for example, a new virus was not yet known to antivirus companies and they did not add its description to their databases or in the case where other parts of the security module 190, such as, for example, a firewall, have not worked. Threat Prevention 206 refers to the detection of already running malicious programs (usually this means that a process was launched from the executable file of the malicious program in the operating system), their subsequent blocking and stopping, as well as system recovery by eliminating the consequences of the operation of such malicious programs.

To implement the above functions, the security module 190 may contain such components as a firewall 212, a message filter 214, an antivirus 216, a recovery module 218, an intrusion prevention module 220 (as a rule, such a module implements HIPS policies). It should be noted that the proposed list is approximate and may be supplemented by other means that implement the above functions. All of these components can be configured, including automatically, to provide various levels of protection for mobile device 100. It should be noted that in FIG. 2A, databases for various components, such as antivirus 216, which need constant updates, were omitted. therefore, it should be understood that the effectiveness of the security module 190 is directly dependent on the frequency and timeliness of updates.

FIG. 2B shows a diagram of the operation of the security module 190 at various levels of the OSI network model, depending on which applications are installed on the mobile device 100. Various applications 160 are installed on the device itself, which use different information exchange methods at the data presentation level 222. How as a rule, this level corresponds to the high levels of the OSI model (i.e., it covers the application and representative levels), while the direct data transfer occurs at the transport level (for example, the protocol s UDP and TCP), which is shown in FIG. 2B as a data transmission layer 230. Direct transmission of information in the form of bits or signals occurs already at the lowest level at which the network adapter 224 operates, which can be fully or partially presented in the form communication devices 140.

Security module 190 may use an application layer filter 226 and a firewall 212 at various levels of the OSI model. - The application layer filter 226 allows you to intercept information between the data presentation layer 222 and the data transfer layer 230, while the firewall 212 intercepts data at a lower level between the data transmission layer 230 and the network adapter 224. The application layer filter 226 allows you to track which application (for example, it can be a mail agent like MS Outlook Mobile or Opera Mini web browser) uses a specific port and with what protocols it transmits data. Thus, in the future, it is possible to reduce resource consumption by monitoring only those applications that exhibit network activity and whose vulnerabilities can be used by a certain type of threat. Firewall 212 captures only a small part of the entire schedule, since at this level it is possible to parse, for example, the ICMP protocol commands, while modern threats and malware operate at a higher level. However, such information can also be important, since many threats and attacks have their own signature, i.e. some template in the form of certain commands that can be disassembled and detected using the firewall 212.

As already mentioned, the application level filter 226 and the firewall 212 provide information about the status of applications 228 and the status of connections 232. Such information may include information about which port is used by a particular application installed on mobile device 100. In turn, this information is used by the processor 234 (it is also called the "engine"), which compares information about the state of applications 228 and the state of connections 232 with information stored in the database with a description of threats 236. In the event that The description or signature of the threat in the database matches the information received, and the corresponding threat is detected. The threat description may include information about the malware, vulnerabilities used in known applications (indicating their version), the number of the port used, registry branches, and other similar information. Thus, such a description is actually a rule for detecting certain types of attacks (or malware using such attacks) with an additional indication of those applications that have vulnerabilities (if any). As a result, a specific user does not need to download the entire database with a description of threats 236, but only his current part 238, which is suitable for the current operating system and installed applications 160 on mobile device 100. Due to the constant growth of threats and the number of malicious programs, this dividing the database saves the schedule.

Figv and 2G show two possible configurations of information security systems for mobile devices. It can be seen that in the embodiment shown in FIG. 2B, the mobile device can be completely exempted from the checks performed by the protection system installed on the server (the so-called “thin” client). Another option, on fig.2G, provides for the installation of a security system (in this case, it can be a security module 190) on a mobile device, which creates additional load and, as a result, reduces battery life. It is worth noting that the use of many resource-intensive technologies working together (the example is the use of flash animation in a browser) reduces the battery life of many modern mobile devices from hours to tens of minutes. These figures clearly show the need for a more flexible approach to the problem of using limited resources of mobile devices. The solution to this problem can be the use of security module 190 in the form of several components, some of which are active at certain settings. For example, when using an external server to filter data, you can turn off the firewall on your mobile device, relying entirely on the network. screen installed on an external server.

FIG. 2D shows a diagram of the operation of a thin client (or other similar configuration) on a mobile device 100 (an example of which is shown in FIG. 2B) using a separate encrypted connection to communicate with a security server 170 (as a rule, this is a server of a company providing services for computer security). Such a scheme is well suited in cases where the user using the thin client scheme does not want to put himself at risk in an unknown and possibly unsafe place from the point of view of computer threats. For this purpose, an encrypted channel 245 is used (in one embodiment, it may be a VPN connection), which is additionally encrypted 240, which ensures reliable data transfer between the mobile device 100 and the security server 170. Additional encryption 240 can be based on both hardware parameters parts of the mobile device 100, and depending on the user's personal settings, as well as depending on the environment variables (for example, connection establishment time). Thus, using the security server 170, the user can confidently access the desired resources using the outgoing connection 255.

Considering the above options for implementing a security system for mobile devices, we can conclude that it is necessary to provide a flexible approach to solving security problems on a mobile device. In order to apply various settings for security module 190, it will be necessary to use various system information (list of installed applications, type of mobile device, its characteristics), information about the current state of mobile device 100 (battery charge, amount of free memory, availability of active or used applications, location, type of network connection used), recent event logs - (standard logs provided by the operating system, and specific data regarding the dependence of the parameters of the mobile device 100 on various factors, such as the last prevented threats, undefined connections), the status of the current information security situation as in the whole world (for example, it can be data on specific types of attacks, for which no universal solutions have yet been found), and in various regions, user settings related to security and performance.

A possible solution to the security problem on the mobile device is to transfer the above information or at least part of it to the security server 170, which analyzes the received data and transfers the settings for the security module 190.

3A illustrates a security system for a mobile device in accordance with one embodiment of the present utility model. Security module 190 includes two main parts in the form of thin 308 and thick 310 clients. Thick client 310 is an analog of the security module shown in FIG. 2A and contains the same modules, each of which is configured separately. Thin client 308 transfers security-related information, primarily for scheduling and completing security tasks on other devices.

Thin client 308 includes a security server connection module 302, group security module 304, group task coordination module 306. As mentioned at the very beginning, mobile devices can form mixed networks. However, not all mobile devices may have security modules 190 installed, and therefore be considered reliable. Thus, devices in a mixed network that have security module 190 installed, at least in the form of a thin client, can be grouped. A group, within the framework of this utility model, is considered to be a set of mobile devices integrated into a mixed network and having the ability to transfer data safely among themselves. One of the options for data transfer involves the joint implementation of security tasks, which will be described below. The security server connection module 302 is responsible for exchanging data with one or more security servers 170. The module 302 itself contains a constantly updated list of such servers to select the closest or most accessible one. Group security module 304 is responsible for using a mobile device within a common group that is able to solve the tasks of individual group members using the common resources of the entire group. To solve such problems, their coordination and the choice of optimal solutions are required, which depends on the configurations of the mobile devices included in the group. To coordinate such tasks on each mobile device installed module 306 coordination of group tasks. Within one embodiment, group security module 304 and group task coordination module 306 can be used to create a special network that will include devices having similar modules 304 and 306, thus forming a group.

The operation algorithms of these modules will be discussed in more detail below.

The mobile device 100 includes a configuration module 314, which sets the settings for all components included in the security module 190. To make decisions on making certain settings as input, the configuration module 314 uses a set of criteria 316. For this purpose, a location module 130 can be used that allows you to determine the location of the mobile device 100. In one embodiment, the location module 130 may use a GPS receiver to determining the exact location of the mobile device 100 in space. Another implementation option involves the use of topology analysis. network in use (e.g. cellular). It should be noted that other known methods for determining the position in space can be used to determine the location.

In addition to the above modules, the mobile device 100 has a location database 312 that describes the security level of a particular geographic location. On figb shows an exemplary diagram of such a database. As an example, some places can be specified as safe globally - this means that these locations are within the network coverage provided by security servers 170. A similar list can be constantly updated by the antivirus company that supports such servers. Other secure locations may be specific to each mobile device (and, accordingly, its user). In addition to safe locations, potentially unsafe and insecure locations in terms of information security can also be identified. Such a determination can be made based on the settings used to connect to the real network, authentication capabilities, and geographic location (for example, using the latest data from anti-virus companies regarding the number of threats to different regions). The descriptions of location types used in this example and methods for determining the level of security may be different for each specific implementation.

Figure 4 shows the security system of a mobile device for one embodiment. As part of this system, a security module 190 is used, which has been presented in detail in FIG. 3A. Also in the system are a module 402 for calculating risks, a module 404 for calculating computing resources, and a module 406 for using user settings. The configuration module 314 uses all of the above modules to obtain a set of criteria 316, which in turn will be used to set the settings for various components of the security module 190. To determine the settings, you can use a large number of input parameters, but within the framework of the present description it’s worthwhile to dwell on the key ones.

To determine the protection level of the mobile device 100, two interrelated parameters are used: performance and protection level (security). In order for the user to always have the opportunity to choose a priority between these two concepts, the mobile device 100 uses the module 406 for using user settings, which in one embodiment can be presented in the form of a simple scale, which makes it possible to determine the user's preference for productivity or security.

The security level is organized as a hierarchy of functionality of the security module 190. The risk calculation module 402 interacts directly with the configuration module 314, providing the necessary data to form a set of criteria 316. Thus, a simple rule is applied, which directly determines the number of used components of the security module 190 and their settings from the protection level, which is generated using the module 402 counting risks. However, mobile devices are very limited in the resources they use - in the first place, computing power and battery power. To compensate for the increased consumption of the listed resources by the security module 190, an additional computational resource calculation module 404 is used, which weakens the set of criteria 316 by dynamically monitoring the resource consumption of the mobile device 100. The last module that affects the criteria set 316 is the above-mentioned user settings utilization module 406, which makes the latest changes to the set of criteria 316. In the future, the module 402 calculation of risks and module 404 calculation of computing resources will be p ssmotreny more.

We give an example of the system. When starting a new executable file on the mobile device 100, the risk counting module 402 sets the criteria 316 in such a way that the configuration module 314 will have to activate the intrusion prevention module 220. But due to its high resource consumption and small battery charge, the computational resource calculation module 404 will weaken the set of criteria 316 by excluding the activation of the intrusion prevention module 220, instead turning on the change log of the recovery module 218 in case you have to restore the system after launching an unknown executable file. Lastly, the configuration module 314 will refer to the user settings module 406, which may recommend the use of the security module 190 with a focus on security, which will strengthen the set of criteria 316 to such a level that the intrusion prevention module 220 will still be used to analyze the unknown executable file. In that case, if the emphasis was placed on performance, the set of criteria 316 can be weakened to the point that the unknown file can only be checked by standard methods of antivirus 216 - for example, using signature verification.

On figa shows a module for calculating risks in one embodiment. Within the risk calculation module 402, there are location database 312, location module 130, security server connection module 302 (which is also part of the thin client 308), application analysis module 502, security event monitoring module 504, and user behavior monitoring module 506. As already mentioned, the location database 312 is used by the location module 130 to assess the risks associated with using those networks that are within the geographic location of the device. The operation of the security server connection module 302 is described in detail in FIG. Let us consider in more detail the remaining three modules.

The application analysis module 502 is designed to analyze applications installed on the mobile device 100. One of its options is to analyze the system registry for entries that are specific to certain applications. Based on certain data, a list of installed applications is generated, for which known vulnerabilities will be identified in the future. The application analysis module 502 is capable of analyzing both the first time the risk calculation module 402 is turned on and periodically, as well as after the installation of each new application.

The security event tracking module 504 provides a log of all events related to the security of the mobile device 100. Such events include increased network activity, use of certain resources atypical for most applications, records about the use of system files or encrypted directories, etc.

User behavior tracking module 506 is for recording and analyzing user actions. Of course, not every user action will be recorded, but the most important will be reflected, such as: opening a new site in a browser, the frequency of use of the mail client, downloading files from the network, launching a new application.

Most users exhibit a behavior model that is similar to the behavior of other users. For example, you can select a group of users who often exchange messages using an Internet pager, listen to music and visit certain sites on the Internet (for example, entertainment topics, which increases the risk of malicious programs or links to them on such sites). On figb the algorithm for determining the model of user behavior. At step 510, the user’s behavior and actions associated with using the capabilities of the mobile device 100 are recorded. As the data accumulates at step 520, the user’s behavior is compared with known patterns. For example, a template may indicate a group as described above. Therefore, at block 530, user behavior is compared with known patterns. In the event that the behavior fits into a known template with a high degree of probability, then at step 540, the security policy for the corresponding template is applied. For example, for the group already mentioned above, this can mean careful control of applications such as a web browser and Internet pager, since their active use can lead to the penetration of various threats and malicious programs. In the event that the user’s behavior does not fit into the existing templates, a further recording of his actions occurs at step 550. Then, at step 560, a new template is sent to the security server 170 or other mobile devices in the group. At step 570, the resulting template is analyzed to develop a new security policy that would satisfy the needs of users with a similar template. As a rule, the development of a new template is required when using new types of applications.

The table below shows examples of patterns and corresponding user actions. Each template has its own unique identifier and description of the main risk characteristic, as well as related user actions. As you can see, all actions can be described for clarity in the form of simple production rules, which will be understandable, including by non-specialists.

Table 1. Template ID Key risk profile User Actions / Logic Trigger criteria 10041 Transfer of personal / important information to third parties Connecting to an external network / saiga AND The external network / site contains {the site in the list of banking / financial sites} OR {The page contains a form requesting personal data} True Any from the list Any similar entity 10042 User downloads malware Frequent file downloads > 3 file downloads in the last 10 minutes 10043 Spam / phishing User selects links in email messages > 2 selected links in the last 10 min 10044 Hacker attack / information theft User connects to an unknown network truth

Consider a template with identifier 10042. In this case, the risk may be related to the fact that the user often downloads programs and, as a result, may also download malware. The triggering criterion is to upload more than 3 files in the last 10 minutes. It is also worth paying attention to the fact that these rules can be edited by users themselves if they want to get the most appropriate ratio of protection level and performance. Some templates also contain rules that are checked at regular intervals. This may be due to the battery charge, which should be checked every 5-10 minutes, noting also the battery charge rate of 150. Next, forecasts on the use of the battery charge are made, and a set of criteria 316 is reassessed. Thus, dynamic control over the use of resources and security level.

Figure 6 shows an example implementation of a module for computing resources. The computing resource calculation module comprises a device type indicator 602 with a characteristic data base 604. devices, as well as a processor monitor 606, a battery capacity monitor 608, a memory monitor 610, a network connection monitor and graphics 612.

A device type indicator 602 is associated with a device characteristics database 604 that contains data on the basic characteristics of the currently created mobile devices. Due to the fact that it is rather difficult to upgrade mobile devices (that is, change components to more powerful ones), such a database is compact enough and can be stored on security server 170 and on mobile device 100. Device type indicator 602 receives data about the type mobile device 100 and requests its characteristics in the database 604 of the characteristics of the devices. The found characteristics are then transmitted to the device type indicator 602 for use by the computing resource calculation module 404 and the configuration module 314 to form a set of criteria 316. Table 2 below is a description of possible options for presenting data in the device characteristics data base 604. This includes information about the size of the monitor (as a result, you can also immediately make an assessment of the level of its energy consumption in order to further build a forecast of the battery charge during user work), processor power, disk space and memory, battery capacity and network capabilities. It should be understood that the capabilities of the database 604 of the characteristics of the devices are not limited to the scope of the above example and may include other data.

Table 2. Title Monitor CPU Disk Battery Communication ASUS ITS GS 900 8.9 " 900MHz Celeron 8 Gb SSD 4400-5200mAh, up to 3 hours 30 minutes Ethernet, 802.11b / a Msi wind 10" 1.6 GHz Atom 80-160Gb SATA 2200-5200mAh, 2.5-5.5 h Ethernet, 802. 11b / a HP 2133 Mini-Note PC 8.9 " VIAC7 1.0-1.6 GHz SSD, SATA 4400-5200mAh, 2.5-4 h Ethernet, 802. Ha / b / g Dell Inspiron Mini 9 8.9 " 1.6 GHz Atom 4-16Gb SSD 2200-3600mAh, up to 5 hours Ethernet, 802.11b / a Nanobook 7 " VIAC7 1.2 GHz 30 Gb HDD up to 4.5 hours Ethemet.802.11 b / a Sony Vaio UX Micro PC 4.5 " Intel Core Solo 1.06-1.33 GHz SSD, HDD 1.5-7 h 802.11 b / a Samsung SCH-J730 2.8 " Intel PXA 520 MHz SD standby time milking 180-280 h 802.11 b

The processor monitor 606 constantly monitors the load of the processor 110 of the mobile device 100. It is worth noting that the processor monitor is also able to detect the use of energy-saving technologies such as Speedstep® feature from Intel Corporation and Cool P Quiet ™ feature from AMD Inc. Both the battery capacity monitor 608 and the memory monitor 610 work similarly. Monitor 612 network connections and graphics works directly with communication device 140, which allows you to monitor all types of connections, helping to identify cases when malicious programs download other malicious code from the network or are engaged in spamming. Such data can primarily be used by a firewall 212. A network connection and graphics monitor 612 monitors access to various networks, which is used by the location module 130 to further generate a set of criteria 316 by the configuration module 314.

Thus, the computing resource calculation module 404 has data on the most important characteristics of the device: its functionality and available resources, remaining battery power, and also about possible connections to available networks. Such hardware information is taken into account in the initial configuration of the security module 190. Table 3 shows the possible options for evaluating the performance of devices. A similar estimate, expressed as a single number, is based primarily on the power of the processor 110 and the memory capacity 120 and can be calculated for each of the devices from. a database of 604 device characteristics data.

Table 3. Device Conditional Performance Device 1 1000 Device 2 7000 Device 5 32000 Device 16 18000

With such estimates, it is possible to determine the type of initial configuration of the security module 190. A higher performance rating indicates a more powerful processor and capacious memory, which allows you to use more features of the module 190 security. Table 4 shows the installation options for the security module 190 on the mobile device 100 based on its assessment. Thus, operating with only one performance value, it is possible to select a set of components of the security module 190 that best suits the configuration of the mobile device 100.

Table 4.

Performance type of instalation <1000 Basic (Management Console, location database, encryption tool) 1000-10000 Improved (Advanced antivirus, firewall) > 10,000 Full (Optional recovery module, full databases)

Having examined the operation of the module 402 for calculating risks and the module 404 for calculating computing resources, we can formulate a list of those factors that influence the formation of a set of criteria 316. In order of decreasing significance, we can cite the following set:

battery charge;

user preferences (defined through module 406 using user settings);

location (location);

installed applications;

possible connections and traffic;

general level of threats.

It is worth noting that the set of installed applications is closely related to the performance of the device in terms of updating the database components of the module 190 security. FIG. 7A shows an algorithm for updating threat definitions depending on the performance of mobile device 100. At step 702, installed applications are detected (for example, after installing security module 190 on mobile device 100), after which, at step 703, the type of threat definitions download is selected. At low performance, option 706 will be selected when descriptions are downloaded only for installed applications. In the case of a more powerful device, option 708 may be selected when threat descriptions for all applications of this type are downloaded. For example, if the user has Opera and Internet Explorer web browsers installed, additional descriptions of those threats that work with other web browsers will be downloaded. This allows you to improve security in the event that new types of threats that previously worked only with a certain type of web browser get the opportunity to use other types. In the case of a powerful device, option 710 will be selected to fully load the databases for all known applications, which will ensure that when installing a new application, threat descriptions will already be downloaded and no new analysis will be required. A similar scheme, depicted in figa, is especially relevant at the present time, when the volume of database updates can be tens of megabytes per week, and lead to the use of a significant amount of memory and transmitted schedule.

As mentioned earlier, the battery charge is the most significant factor in the formation of a set of criteria 316, which in turn directly affects the components of the security module 190. On figb. The circuit diagram for disabling various components of this module depending on the battery charge is shown. Typically, such a circuit starts to work when the battery charge drops to low levels, from about 30% or lower. When the battery is gradually discharged, at step 712, the ability to use the user settings module 406 is disabled first. In one embodiment, this means unloading the graphical user interface from the memory 120. This is done in order to reduce the load that the configuration module 314 creates, and user actions through the module for using user settings 406 immediately lead to a reassessment of the set of criteria 316 and the subsequent change in the operating mode of the module 190 security and e th component.

The next step is to check the active connection with the security server 170 at step 714. In the event that there is no active connection, then at step 716 the ability to create such connections is disabled. If there is an active connection to the security server 170, then this means that the user is interested in using the capabilities of this server to improve their own level of security and such a connection cannot be disconnected. Thus, at step 718, the operation of the location function is checked, and if the location module 130 is inactive, the location database 312 is disabled at step 720. If the user is actively moving and the communication device 140 detects the appearance of new networks, then the database 312 is disabled. locations do not occur, but the capabilities of the firewall 212 and antivirus 216 are minimized at step 722. When the battery is completely discharged, the ability to create secure connections is disabled (and the current connection is terminated with the security server 170) and the database of locations 312 is disabled at step 724. Such a reduction in the scope of functionality, on the one hand, increases the level of risk, but on the other hand, it saves battery power to a sufficient extent. Depending on the type of user behavior and its settings specified through the module 406 for using user settings, the boundaries for disabling functionality may be shifted and, in the worst case, no functionality will be disabled until the battery 150 is completely depleted.

Until that moment, it was about using a separate mobile device 100 and solving all security problems using its limited resources. Of course, if it is possible to use the security server 170, it is possible to use only the thin client 308 and the connection module 302 to the security server, but often there are situations when the security server 170 is unavailable or poor connection quality does not allow to establish a connection. In such cases, it makes sense to use the capabilities of a group of mobile devices that are within reach and that use similar security modules 190. On figa shows a diagram of the group of mobile devices. Mobile devices can use both broadcast protocols and peer-to-peer connections to organize work, which can be implemented using group security module 304 and group task coordination module 306, which will be discussed in more detail below. As mentioned earlier, 802-810 mobile devices (similar to mobile device 100) can form a mixed network. In such a network, some devices can be interconnected using one communication standard (for example, Bluetooth), while some of them can be connected to other devices via a Wi-Fi standard network. Hereinafter, a device will be understood to mean any mobile device similar to the mobile device 100.

On figb shows the database 812 of these devices, which contains the mobile device 100. Before connecting to other devices in a common network, you should consider the level of trust in these devices. In the example shown in FIG. 8B, my wife’s laptop, my smartphone and home server are considered trusted devices. A similar level of trust could be affixed if these devices contain some kind of security system similar to security module 190 and the system itself is up to date (for example, for an antivirus application this means that the latest version of updates has been downloaded and necessary checks have been performed). Most likely, trusted devices, such as Nikolai’s smartphone or Philippe’s Internet device, can have security module 190, but only as a thin client 308 or an incomplete part of thick client 310. Risky or unsafe devices can have no module 190 at all security and they can contain a variety of malicious programs, which is a threat to other devices. The formation of such a database can occur both automatically and in manual mode. Table 5 contains examples of entries in the device database 812, which contains a unique identifier for the device, its associated risk profile, its computing performance (power) and level of confidence.

Table 5. Device id Current risk profile Current computing performance Trust level S / NABCD AF6G44h $ ssd 25,000 Entrusted S / N BCDE DL # h6h33j4 15,000 Probably Trusted

The identifier is set for each new device for the first time when trying to connect with the mobile device 100. The risk level may change over time, as this may be related to updating the databases of the security module 190 and the type of installation (thin. 308 client or thick client 310). Current computing power can be obtained from the device type indicator 602, and the level of confidence is directly related to the current risk profile.

Figv illustrates various groups of mobile devices in different locations (locations), which are conventionally shown as "home", "public place", "work" (in the future we will use without quotes). During the day, a user with a mobile device 100 can visit, for example, three such places. At home or at work, security server 170 can be used to solve security problems without using the resources of other computing devices. However, in places where access to the security server 170 is difficult, the use of resources of other devices can be very useful. An example is the case when the user has a sufficiently powerful laptop that is used as a proxy server to access the Internet from his other device - a smartphone. To perform such tasks, three conditions must be met: (a) the presence of at least one device that is capable of performing security tasks; (b) sufficient performance of such a device to perform the necessary tasks; (c) the lack of ability or resources to perform such tasks on the mobile device 100.

Before proceeding to consider the scheme of performing security tasks on other devices, first, a diagram of adding a new device to the group in FIG. At block 820, a new device or network is detected. As a next step, at 822, the group is isolated from the new device or network before being verified at 824. As a simplest check, a query about the device type and version of the security module 190 used (if any) can be used. After that, at step 826, a determination is made whether the new device or network is secure. If the answer is yes, the new device or network will be added to the group as trusted at step 828. Otherwise, at step 830, the level of protection of the group will increase and the new device or network will be further turned on as unsafe at step 832.

After the devices in the group have been identified, an algorithm for selecting security tasks by one of the devices in the group occurs, as shown in Fig. 8E. At step 840, it is determined whether the device has enough resources to complete the task and, if the answer is yes, the mobile device performs the task on its own at step 842. If there are not enough resources, at step 844, the active devices in the group are searched. If no devices are found, then the user will be notified about this at step 846. If there are active devices at step 848, the task will be placed in the task database, which is described in detail in FIG. 9A. The task database contains all the tasks that devices in the group need to perform. For example, if there are three devices in a group and for the first and third devices you need to perform one and two tasks, respectively, then there will be three tasks in the task database. At block 850, the task database is updated on the group devices. Such synchronization is required so that each device in the group has an up-to-date list of tasks. The database update occurs when a new task appears, when a task is completed, or when other changes to the task database occur. At step 852, a task is selected by one of the group devices. A more detailed consideration of the criteria for the possibility of such a selection will be given in figv. If one of the devices selected a task from the task database, then at step 854 it is checked whether the device has started its execution. Accordingly, at step 856, the algorithm ends when the device completes the task. In the event that none of the devices has selected a task for execution, then at step 858, the wait limit for the task is checked. A similar step is needed so that low-priority, but at the same time resource-intensive tasks do not end up in. ultimately unfulfilled. If the waiting limit is exceeded, at step 860 the priority of the task is increased and the algorithm returns to step 852.

9A illustrates an example implementation of a task database 902. A similar task database is installed on each mobile device in the group that has security module 190. All tasks have a different priority level, which determines the sequence of their implementation. Each task also has its own timer, which determines how much this task is in the database. When describing the algorithm in FIG. 8D, it was shown that when the waiting limit is exceeded, the task has priority. For example, when a new device appears and determines the security level when exchanging data with this device, the priority task (and, accordingly, with the highest priority) will be the task of checking this device. The task of checking files can be classified as low priority, as it is not urgent and can be performed later. In addition, each device has its own performance and availability level. Device performance can be estimated using its own device type indicator 602. The availability level shows how available the device’s resources are. The availability level itself can be expressed as a percentage, which is the average value of the device’s free resources, data about which can be obtained from the processor monitor 606 (the processor is the most important resource), battery capacity monitor 608, memory monitor 610, and network connection and graph monitor 612. Then the actual performance of the device at the current time can be expressed through the formula:

[Real performance] = [Device performance] * [Availability level]

An example of correlation of the load to the required performance is shown in table 6.

Table 6. Load Required performance Availability Level (%) Low <5000 90 Average 5000-15000 70 High > 15000 fifty

The values of the required performance correspond to the performance values given in table 3. The level of availability of the device resources required to perform the task with the corresponding load is also given. This means that tasks with low load require not the most powerful devices, but do not perform unnecessary tasks.

Let us consider in more detail the process of selecting a task by a group device, which is illustrated in Fig. 9B. At step 910, it is checked whether the device is ready to perform group tasks. The algorithm ends at step 912 in the event that the device cannot perform such tasks. This may be due to a user’s refusal to use his device to solve group tasks or insufficient performance. If the device is ready to perform tasks, then at step 914 the selection of tasks from the task database 902 begins. At step 916, the selection starts with the tasks with the highest priority, then, at step 918, the required load of the selected task is checked and if at step 920 there is enough device performance for its implementation, the task is deleted from the task database at step 922 (the task database is also updated on all other devices) and its execution begins at step 924. If the device performance is not enough for this task, then at step 926, it is checked whether there are still tasks with a lower priority and the selection process returns to step 916. If there are no more tasks left, the device goes into standby mode for updating the task database at step 928.

It is worth noting that not all devices in the group can perform security tasks, which is primarily associated with the database of devices 812 and the level of trust for each device. As an example for FIG. 8B, it can be said that the task of checking personal folders on the mobile device 100 can only be entrusted to trusted devices, i.e. the wife’s laptop, the smartphone of the owner of the mobile device 100 and the home server. Fig. 9B describes an algorithm for verifying confidence criteria. At block 930, a confidence level for each task is set. This happens automatically depending on the type of task being performed: if the task includes filtering the schedule or checking data on another device, then such a task will require a high level of trust (i.e. the device will have to be trusted), while the task of checking the new device in a group can be executed by a device and not included in the list of trusted ones. At step 932, the task is placed in the task database 902, which is then updated on all devices in the group at step 934. Then, a task is selected by one of the devices in the group at step 936 and if the device meets the trust criteria (such a check is provided at step 938) , then the fact of the beginning of the task at step 940 is checked, which leads to the end of the algorithm at step 942, which ends when the task is completed. In other cases, the device may not meet the confidence criterion and then the task will not be executed on this device or it will have exceeded the expectation limit at step 944, which will increase its priority at step 946. The operation of such an algorithm can be described using - using a simple an example. If the user needs to carry out a number of important operations on the Internet (for example, go to the bank’s website), then he will wait for the moment when the schedule can be filtered by a trusted device that is free from other tasks.

Next, on figa-10D will be examples of the use of the group to solve various security problems. For example, using the group, you can more flexibly configure the database update of the components of the security module 190, as shown in figa. At step 1002, the availability of the update server is checked. It often happens that new malicious programs for effective operation block the ability to download database updates of components of security module 190, which leads to obsolescence of its databases and a decrease in protection efficiency. Another option for the unavailability of the update server may be a DoS attack. Thus, if the update server availability check at step 1004 is successful, then the updates are downloaded normally at step 1006. If the update server is unavailable, then at step 1008, the availability of the latest update versions on the group devices is checked. In the event that it was discovered that they have later versions of the databases, then at step 1010, the available updates will be downloaded. Subsequently, at step 1012, the time of the last database update is checked, which may lead to an increase in the level of proactive protection, i.e. an increase in the level of operation of such modules as intrusion prevention module 220, antivirus 216, or firewall 212.

figb shows a variant of the group when a new threat is detected. If one of the mobile devices detected a new threat at step 1020, then at step 1022 it generates a description (the possible address of the link where this threat is located, the hash of the malware file, etc.) and sends it to the other devices of the group at step 1024. Thus If one of the users got to the phishing site and the saiga address was blocked, then the link to this saiga will be automatically transferred to other devices, which avoids data loss even to devices with a thin client.

10B illustrates checking an executable file before running it on one of the devices of the group. At 1030, a start of the process from an unknown file is determined, and at 1032 a check is made on the adequacy of resources to verify the unknown process. If the device’s resources are sufficient, then at 1034, the device is isolated until the verification is complete. If there are not enough resources, then the check will pass at step 1036 on another device with a sufficient level of performance. An example is the following scenario:

the user downloaded an unknown file, and the signature check did not give results, after which, if there are not enough resources, the task of checking this file will be placed in the task database 902.

10G illustrates a similar case associated with the discovery of a new data store by one of the devices of the group. The simplest example is the use of a new memory card on a mobile device. At 1042, a sufficiency check is performed to verify the data store. If there are enough resources, the device will be isolated from the group until the verification is completed at step 1044. Otherwise, at step 1046, the verification will be performed by another device, for example, using the verification of all files in the signature data storage.

Fig. 10D shows a change in the power of attorney of the device in the event that a new vulnerability has been discovered related to the applications, operating system or hardware of one of the devices. At 1050, a new vulnerability is detected on one of the devices in the group, after which at 1052 this device will be designated as a higher-risk device (for example, from trusted ones it will be transferred to those associated with risk). On other devices, the security level will also be increased at block 1054. After the update is downloaded to close the vulnerability at block 1056, the security level will be at. devices will be lowered at 1058 and the device will be assigned to a lower risk device at 1060 (for example, will again be trusted).

In conclusion, it should be noted that the information given in the description are only examples that do not limit the scope of this utility model defined by the formula. The person skilled in the art will understand that there may be other options for implementing this utility model, consistent with the nature and scope of this utility model.

Claims (7)

1. The security system of mobile devices, which includes: the security module associated with the configuration module, while the security module is designed to perform security tasks on a mobile device and transfer information related to security tasks to other mobile devices; said configuration module is intended to configure a security module depending on data received from the risk calculation module and the computing resource calculation module associated with the configuration module; said risk calculation module is intended to determine risks associated with the security of a mobile device; said computing resource calculation module is for determining the used hardware resources of a mobile device. 2. The system according to claim 1, in which the security objectives are: a) preventing unwanted information from reaching the mobile device; b) the detection and removal of unwanted information on a mobile device; c) prevention of threats. 3. The system according to claim 1, in which the security module includes: a) firewall; b) message filter; c) antivirus; d) recovery module; e) intrusion prevention module. 4. The system according to claim 1, in which the security module includes: a) a module for connecting to a security server, designed to transfer data to perform security tasks on a remote computer; b) a group security module designed to determine the level of security in a group; c) a module for coordinating group tasks, designed to select and define security tasks to be performed on mobile devices. 5. The system according to claim 3, in which the group is a set of mobile devices connected in a mixed network and having the ability to transfer data safely among themselves. 6. The system of claim 1, wherein the risk calculation module comprises: a) a module for tracking user behavior, designed to determine whether user behavior matches the risks associated with the security of the mobile device; b) a security event tracking module designed to record all events related to the security of a mobile device; c) an application analysis module for analyzing applications installed on a mobile device; d) a location module designed to determine the location of a mobile device; e) a database of locations designed to determine whether a security level matches a specific geographic location. 7. The system according to claim 1, in which the computing resources calculation module uses the following data about the hardware resources of the mobile device: a) data on the battery charge of the mobile device; b) data on the frequency of use of the processor of the mobile device; c) data on the type of mobile device; d) data on the free memory of the mobile device; e) data on network connections of the mobile device.