RU2772072C1 - METHOD FOR USING A MODEL OF THE IoT APPARATUS TO DETECT ANOMALIES IN THE OPERATION OF THE APPARATUS - Google Patents

Abstract

FIELD: information security.

SUBSTANCE: described result is achieved by using a method for using a model of the IoT apparatus to detect anomalies in the operation of the apparatus, wherein a new apparatus is determined; the data on the apparatus is obtained to generate a profile; a convolution of the apparatus is created based on the profile; a convolution similar to the created convolution is selected from a convolution database; if a known model is available, then the already known model of behaviour of the apparatus, linked with the selected convolution, is used; otherwise, data is collected in the profile of the apparatus in order to create and train a model of the apparatus and subsequently use the trained model, wherein the use of the model involves detecting anomalies in the operation of the apparatus.

EFFECT: implemented possibility of detecting anomalies in the operation of the apparatus by using a model of the IoT apparatus (hereinafter the apparatus).

1 cl, 22 dwg, 12 tbl

Description

Technical field

The invention relates to technologies, and more specifically, to methods for ensuring information security for IoT devices.

State of the art

Nowadays, an increasing number of devices are connected to the Internet - from computers and smartphones of users to more mundane things such as TVs or refrigerators. In the case of connecting new types of devices to the Internet, they often “acquire” the “Smart” prefix (for example, Smart TV). When Smart devices are connected to the Internet, users get the ability to manage the operation of these devices, including updating the devices themselves, monitoring the status of the device (for example, a refrigerator) and integrating the device itself within the framework of the so-called “smart home” concept (English Smart house). Such a concept allows you to control such "smart" things (devices) from one point, checking the status of such things, adjusting them to your personal needs. The concept of "smart home" includes another concept called the Internet of Things (English Internet of Things, IoT), which implies the interaction of the above things without the direct participation of a person.

Currently, users are widely using routers that allow you to create wireless (smart devices also work over wired networks) networks, which in turn allow you to connect other smart things to the Internet. Currently, many routers support the ability to create so-called heterogeneous (heterogeneous) networks. An example is a network of devices (“smart” things), some of which are connected to the router via a wireless Wi-Fi network, and the other part via Bluetooth.

Not surprisingly, with the growth in the number of devices that have the ability to network, the number of attempts to maliciously use such devices began to grow. When you gain access with administrator rights to the router, it becomes possible to analyze the network traffic that goes through the router. When you gain access to devices such as smart watches, you can also check data on paired smartphones. All these actions can lead to data theft, spoofing or damage.

Malicious use of such IoT devices is carried out with the help of malware, the number of which is also growing. Due to the fact that such devices often do not have a high-performance computing platform (as a rule, these are small platforms based on the ARM architecture) and run a low-functional operating system (OS) that uses a small amount of resources, the use of any security policies or anti-virus applications is redundant. The problem is also exacerbated by the fact that the creators of malicious applications have only just begun to explore the possibilities of using such devices, which in turn leads to the fact that antivirus companies do not have time to respond to new threats.

Also, IoT devices can generate a large amount of traffic due to their quantity, which is used by the creators of botnets. An example is the Hide'n'Seek botnet, which uses a p2p infrastructure, making it even more difficult to detect.

It is worth noting that the widespread use of IoT devices can be accompanied by an invasion of people's privacy. On the one hand, a person can trust devices to manage data (including data collection and analysis), which can directly or indirectly be his personal information - heart rate, calorie consumption (“smart” fitness bracelet), call frequency (“smart” watch ), temperature and humidity in the house (“smart” devices such as a thermometer and a hygrometer with feedback), and others. Although the level and quality of service directly depends on the use of information from such devices, not all users agree to the transfer of information, especially since attackers can also receive such information.

One of the latest problems can also be called security issues related to the functioning of “smart” technology within the framework of a “smart” home. For example, it is unacceptable for the air temperature to rise above 23-25 degrees Celsius during the warm season, even if the settings allow you to raise the temperature higher. In addition, attackers can also take advantage of this by disabling a number of sensors and changing the settings.

Such problems can be catastrophic if vulnerabilities for the Industrial Internet of Things (IIoT) are exploited. This definition includes a multi-level system that includes sensors and controllers installed on the nodes and assemblies of an industrial facility, means of transmitting, visualizing and analyzing the collected data. If one of these nodes is compromised, then it is quite possible that not one device or set of devices in the house will be denied service, but even a change in the operation or failure of critical infrastructure within an entire city (for example, city traffic management systems or city cameras). An example of exploitation of such vulnerabilities is attacks such as Stuxnet and Duqu. ( ¹ https://www.kaspersky.ru/about/press-releases/2014_stuxnet-v-detaliakh, ² https://www.securitylab.ru/news/tags/Duqu/)

Patent publications are known that disclose possible solutions for ensuring information security associated with IoT devices. For example, US20180041546 discloses security design for IoT systems based on user desired characteristics. Publication US20180040172 discloses monitoring the interaction of a machine with an IoT device and analyzing possible information risks. However, these publications do not disclose an integrated approach to solving information security problems, coupled with ensuring the security and correct operation of IoT devices, as well as ensuring the necessary level of confidentiality.

An analysis of the prior art allows us to conclude that the previous technologies are ineffective and, in some cases, impossible to use, the disadvantages of which are solved by the present invention, namely, the method of using an IoT device model to determine anomalies in the operation of the device.

Disclosure of invention

The technical result of the present invention lies in the purpose of the invention.

According to one of the implementation options, the specified result is achieved using the method of using the IoT device model (hereinafter referred to as the device) to determine anomalies in the operation of the device, includes the following steps: determine a new device; receive data about the device for forming a profile; creating a device rollup based on the profile; choose from the database of convolutions a convolution similar to the created convolution; if there is a known model, then the already known device behavior model associated with the selected convolution is used, otherwise, data is collected in the device profile to create and train the device model and then use the trained model, while using the model involves identifying anomalies in the device operation.

Brief description of the drawings

Additional objects, features and advantages of the present invention will become apparent from reading the following description of an embodiment of the invention with reference to the accompanying drawings, in which:

On FIG. 1 shows a diagram of the IoT ecosystem (infrastructure).

Fig. 2 illustrates an IoT device that can be secured with a secure OS installed.

Fig. 3 shows an example diagram of an IoT ecosystem (infrastructure) to which elements have been added that provide the necessary level of security at different levels.

A description of the main functionality of the hub 310 is illustrated in FIG. 4.

Fig. 5 illustrates the partitioning into domains (by security).

Fig. 6 illustrates the division into domains (by functionality).

Fig. 7 shows the division into domains (hierarchically).

Fig. 8 shows the construction of a network map using a hub 310.

Fig. 9 illustrates how hub 310 operates when a new device is connected.

On FIG. 10 depicts how the hub 310 is used as part of an IoT device vulnerability study.

Fig. 11 illustrates the creation and use of rules for IoT devices.

Fig. 12 shows the scheme for encrypting and tokenizing user data transmitted from IoT devices.

Fig. 13 depicts a method for creating a device profile, training, and using the trained device model to predict device behavior.

Fig. 14a-c show the construction of a network profile of IoT devices using hub 310 over a period of time.

Fig. 15 reflects how the network profile is constructed.

Fig. 16 shows the setup of devices depending on the type of network.

Fig. 17 depicts the use of the model to estimate the degree of wear of devices.

On FIG. 18 shows an example of changing (shaping) traffic in order to smooth out peaks that may indicate certain user actions.

Fig. 19 displays the application of personal data processing policies.

Fig. 20 is an example of a general purpose computer system with which the present invention may be implemented.

Description of embodiments of the invention

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, but may be embodied in various forms. The gist of the description is nothing but the specific details necessary to assist a person skilled in the art in a thorough understanding of the invention, and the present invention is defined within the scope of the appended claims.

We introduce several definitions that will be used in the framework of this application for the invention.

“Smart” things (IoT devices, both terms will be used below) - everyday things such as watches, street lights and other sources of lighting, surveillance cameras, refrigerators, voice recorders, bracelets, heart rate monitors, thermostats and others that have Internet access (or local area network) through various types of wired and wireless connections such as Wi-Fi or Bluetooth. These devices create network connections, receive and process incoming traffic, have an interface for interaction (API, English Application Programmable Interface), which allows not only to monitor the parameters of a thing (device), but also to configure it. In addition, a number of network devices, such as signal amplifiers or media set-top boxes, can be attributed to IoT devices.

IoT devices find their application in various fields, such as: automotive (English automotive), consumer goods (for example, smart watches), infrastructure facilities (various sensors, for example, a humidity sensor or a temperature sensor), medicine (for example, a pacemaker with the ability to sending data about their work to a local server), smart home (English smart home / building) and others. Often, IoT devices are combined into an infrastructure that allows you to perform tasks at the level of not only an individual or household, but also at the level of cities or states.

Compromise / theft / damage to IoT devices can lead to various consequences for the entire infrastructure. The characteristics that are affected by IoT device damage are highlighted below.

Integrity - how much damage to one or more IoT devices affects the integrity of the entire infrastructure.

Availability - how much damage to one or more IoT devices affects the availability of both the device itself and several devices associated with it (infrastructure).

Confidentiality is the impact of compromise or theft of one or more IoT devices on access to personal information of the user(s).

Smart things can use different kinds of network protocols and standards such as wireless (e.g. 2G, 3G, LTE, WiFi, BlueTooth, ZigBee, LoRa) or wired (e.g. Ethernet) or other protocols such as BACnet, Modbus, SNMP, RS232, RS422, RS485.

Data exchange between the IoT devices themselves can be implemented using a wide range of data exchange protocols. Examples include HTTP, Web Sockets, MQTT (Message Queue Telemetry Transport), CoAP (Constrained Application Protocol), XMPP (Extensible Messaging and Presence Protocol), SNMP (Simple Network Management Protocol), AliJoyn and others. Support for these protocols, as a rule, is implemented within the development tools (SDK, Software Development Kit), which are used to create the software part of IoT devices.

One of the problems of IoT devices is the wide variety of devices themselves and their applications. People can use a personal pedometer (for example, as part of a “smart” watch, English smartwatch), a variety of sensors and units (English ECU, Electronic Control Unit) can be used in a car, sensors for temperature, pressure and other parameters can work in the house, video surveillance systems and smart locks are used (August Smart Lock, which allows you to unlock the lock using a smartphone, is an example), and in an industrial plant, a variety of sensors are used to control the entire production process.

The security issues already mentioned for IoT devices are related to the wide variety of devices, interfaces used, and the presence of zero-day vulnerabilities ³ . ( ³ https://www.anti-malware.ru/threats/zero-day)

The present invention proposes a solution to security problems for IoT devices at different levels:

• at the level of the device itself,

• at the network level,

• at the infrastructure level.

The IoT infrastructure, which has the implementation of the indicated solutions at each of the indicated levels, will have the highest level of security.

At the level of the device itself, there may also be several implementations of the information security solution, depending on the hardware and software capabilities. It can be a secure operating system, a lightweight client, or a full-fledged antivirus application.

In addition, within the infrastructure of IoT devices, the issue of building trust (English root of trust) is also considered. Since various elements (nodes) of the infrastructure can be both trusted and untrusted, the entire security system should be built on the basis of such knowledge, restricting access from untrusted elements.

Another important point is the fact that the entire IoT infrastructure is not static - new devices can be added to it, old ones can change, etc. Thus, the problem arises of predicting possible threats and identifying vulnerable devices.

By collecting data about a device, you can determine its type, and use the collected data to train and use machine learning models for this type of device to predict their use. An example is IP cameras that enter the market with several models a year, even from the same manufacturer, which requires a deep analysis in terms of information security, since new models can have both old and new vulnerabilities.

The same IoT devices can be used in different infrastructures, so different requirements may apply to the same devices. For example, temperature sensors for the home and for the industrial plant have different tolerances in relation to usage parameters.

Another problem is the use of different devices in different conditions - temperature, humidity, pressure, overload, etc. These conditions must be taken into account to predict failure or other problems (including those related to safety). For a number of applications that require real-time decision making, in particular for IIoT, the response time to an event / incident in such environments is measured in milliseconds and seconds, delays associated with sending data or due to wear of certain parts are unacceptable. For example, wear and tear may be associated with the hardware and software platform of an IoT device - cache overflow, load increase over time, incorrect operation of batteries. Thus, it is additionally required to predict the operation time of IoT devices in order to determine possible failures before they actually occur.

Another aspect (but by no means the least important) is privacy. Building a common privacy policy, which is used on all network elements to control the personal data of the user (or users), as well as critical (confidential) data of an enterprise, institution, infrastructure, has recently become increasingly important.

Description of the ecosystem of IoT devices (general)

On FIG. 1 shows a diagram of the IoT ecosystem (infrastructure). IoT devices 110 can be wearable devices for people (smartphone, smart watch, etc.), various household items with the ability to automate and connect to the Internet, sensors inside a car or home, and various sensors in an enterprise. Devices 110 receive, process, and transmit information (for example, temperature data) either to other similar devices 110 (for example, a smartwatch can be paired with a smartphone) or through a gateway 120. Gateway 120 can be a home router or other network device (hub, switch) designed to transmit data over the network to platform 130. Gateway 120 may support various data transfer protocols, for example, some devices 110 use the ZigBee protocol (for example, smart plugs), and an Ethernet connection is used to connect to platform 130 through an internet provider.

Platform 130 refers to one or more data processing servers, which are usually referred to as cloud services (English cloud service / infrastructure). Within the platform 130, applications 140 operate that allow the processing and interpretation of data from devices 110. Users can use individual devices 150 (this can be smartphones, personal computers, etc.) to control devices 110 either directly or through applications 140. Typically, one or more gateways 120 with connected devices 110 and 150 form a personal area network (PAN, Personal Area Network). In one implementation, platform 130 or a portion of it may be hosted within such a network.

An example is the smart home platform from Xiaomi ⁴ ( ⁴ https://xiaomi-mi.us/mi-smart-home/). Devices 110 can be Yeelight Smartbulb lights, Mi Smart Power Plug surge protector, Mi Smart Remote Center control tool. To process data from these devices, its own platform 130 Mi Eco Cloud is used, which allows you to use various 140 applications (including third-party ones) to process data and manage 110 devices.

Consider various aspects of security at different levels - from devices 110 to applications 140.

At the device level 110, it can be expensive (both in terms of resources and time) or even impossible to build authentication using PKI (Public Key Infrastructure), for example, due to the lack of hardware support (or poor software support performance) of the encryption functions of devices 110 .

It is important to note that, in addition to the data received from the devices 110, privacy should also be kept in mind when using and storing data. An example is a hospital where a doctor records the readings of medical devices about the condition of patients. Devices - they are also devices 110 - transmit personal data of users (patients) through network devices (gateways) 120 to platform 130. But such data as the location (geolocation) of a doctor who moved around the hospital, and the time he was in certain places, also are important information, as they may disclose some of the personal information of the users themselves, based on a number of assumptions about the health of patients. And the use of big data processing methods (English big data analysis) allows you to make more advanced assumptions based on the analysis of such metadata.

Shown in FIG. 1 infrastructure scheme can be dynamic. Part of the devices 110 may relate, for example, to sensors in a car or other vehicle. The sensors can be either various units (ECUs) or other devices, such as telematics, which transmit data on the movement of the car to the insurance company, which in turn uses its applications 140 to process the received data within the framework of the provided platform 130. Thus Thus, one cannot say that the infrastructure is something permanent and / or homogeneous structure, but can change over time or under the influence of external factors or events.

Let's highlight the key points of information security of IoT devices 110:

• Security of the device itself: determining the configuration of the device, ensuring data integrity, identifying vulnerabilities.

• Network Security: Prevent network attacks and manage network load.

• Platform security: ensuring the integrity and confidentiality of data, servicing IoT devices.

• Security of applications running within the platform: ensuring the integrity of user data and ensuring the correct operation of the applications themselves.

• Security of the work process and interaction of IoT devices with the platform.

To ensure security at different levels, the following is performed:

• analysis of existing threats and development of means and methods of counteraction,

• analysis of protected systems, identification of weaknesses and prediction (modeling) based on this possible threats and attack vectors.

An attack refers to exploiting a vulnerability or other weakness (e.g., a weak password) in the firmware of device 110, gateway 120, platform 130, or application 140 in order to gain unauthorized access to the functionality or data of said devices/applications.

Threats are considered:

• Data integrity violation. Integrity violation refers to the modification, deletion or substitution of data. For example, ransomware that encrypts user data (for example, electronic documents or images) for subsequent blackmail.

• Intrusion (English intrusion). An example is a network attack, the purpose of which is to gain access to one of the network devices.

• Privilege escalation, such as gaining root / administrator access. Such an attack is carried out by exploiting vulnerabilities, including the use of zero-day vulnerabilities (eng. 0-day or zero day).

• Data leakage. Related to this is the theft of user data that may be stored on devices 110, including personal data (for example, data on the movement of a person or his vital signs).

• Interruption of services. For example, stopping or malfunctioning applications 140. Such attacks can be carried out using denial of service attacks on the service 130.

• Use of computing resources. For example, turning the attacked system into a botnet element used, for example, to perform DDOS attacks, or performing calculations on the attacked system, such as calculating (mining) cryptocurrencies.

To protect against such threats, devices 110 need to support X.509 authentication and the ability to verify digital signatures. It also requires support for one or more encryption standards for data transmission and storage. In the ideal case, devices should support an intrusion detection system (IDS, intrusion detection system), as well as remote administration of security settings.

An example of a lightweight or embedded operating system on devices 110 would be Huawei LiteOS developed by Huawei.

Gateways 120 have the following options:

• filtering transmitted content and determining network protocols for communicating with devices 110;

• maintaining a blacklist for devices 110 to provide isolation of vulnerable or untrusted (unknown) devices;

• IDS support.

For platform 130, the following security features can be distinguished:

• support for firewalls such as Distributed Firewall (DFW), Web Application Firewall (WAF);

• isolation of data from different devices 110;

• privacy support;

• support for third-party APIs for additional information security.

After describing the necessary capabilities of the platform and gateways to inspect IoT device traffic, consider possible threats to such devices 110, as well as possible requirements for preventing such threats.

Threats (description)

Within the scope of the present examples, all given IoT devices for which examples of attacks are given are referred to devices 110 in FIG. one.

Example 1

August Smart Lock.

This IoT device represents a “smart” lock that is activated (i.e. changes the state “open / locked”) when there is a nearby trusted device via the Bluetooth protocol (more precisely, Bluetooth Low Energy, BLE). The trusted device uses a special application that sends commands to lock/unlock the lock. Additionally, the application communicates via the network with the August servers, through which they set access rights to the castle.

For communication, unique session keys and AES encryption are used. The lock itself can store up to 256 encryption keys, with the null key being the immutable key. These keys are used offline (when there is no connection to the August servers).

The Bluetooth protocol transmits information about phone authentication, access rights, who unlocked/locked the lock. Users are divided into two types - OWNERS (hosts) and GUESTS (guests), for which the connection setup procedure is different.

One of the known attacks occurs on the August server by changing variables on requests, such an attack allows you to change access rights or get GUESTS access rights for any locks.

Another type of attack is based on the operation of the lock in offline mode, when the lock has not received information about the revocation of access rights from the August servers. For “smart” locks, the following attack can be made: for a certain smartphone, access rights are revoked, but this smartphone switches to offline mode (i.e. there is no network connection), due to which the cloud service cannot confirm the revocation of access rights from this smartphone. A smartphone can still be used to access this lock, although the rights have been revoked. Such an attack is called a state consistency attack.

Another attack is fuzzing control commands, for example by adding a random sequence of bytes after the command opcode, which puts the smart lock in an error state and forces it to open.

If the owner's phone is stolen, access is possible when the auto-unlock option is enabled.

Another attack uses BLE traffic sniffing.

Thus, to protect against the above attacks, it is required to: control access to devices when they work in offline mode, check traffic between devices.

Example 2

A smart home that includes a Philips Hue smart bulb, a Belkin WeMo switch, and a Nest Protect smoke detector.

Nest Protect uses a secure authentication protocol (such as SSO, Single Sign On) with its servers, using an OAuth 2.0 token to exchange information that is then sent to the user's phone.

Attacks can include sniffing network packets, attacks on accounts (English credential attacks), and downloading malware onto the device itself (for example, Nest Protect). Since traffic sniffing by an attacker will not give results, since the connection is encrypted, and there are no rights to install software by default, so the attack on the account remains.

Another version of the attack on Nest Protect includes replay attacks, when the size of network packets is correlated with a change in the operation of the device itself. For example, researchers have found ⁵ ( ⁵ B. Copos, K. Levitt, M. Bishop, and J. Rowe, “Is Anybody Home? Inferring Activity From Smart Home Network Traffic,” 2016 IEEE Security and Privacy Workshops (SPW), 2016 ) that packets of sizes 1663, 1631, 1711, 1786 and 1819 changed the state of Nest Protect, which makes it possible to resend (or combine) such packets to change the state of the device (for example, shutdown).

To identify the Nest Protect sensor, read the QR code on it (usually using a smartphone). The user then needs to enter additional information (such as the WLAN password). Bluetooth is used for initial setup. Then communication with the sensor is already carried out via WLAN, several Nest Protect sensors can communicate with each other also via WLAN, but also via the 802.15.4 protocol (ZigBee, WirelessHART, MiWi and other protocols) if the WLAN fails.

For Philips Hue, primary authorization occurs using GET and PUT requests, in which information about the device itself (light bulb) is transmitted. It is impossible to connect directly to such a light bulb (more precisely, to the control chip) from a smartphone. For this, a special device (hub) is used, which sends commands to the bulbs themselves via the Zigbee protocol.

A replay attack can be made on Philips Hue, such as turning a light bulb on or off. Port 80 is used to listen for requests that are in JSON format. Also, the Philips Hue hub can broadcast requests to all Philips Hue bulbs, which is also a possible attack vector.

Belkin WeMo uses the SOAP protocol to communicate between the device and the switch. There is no authentication, as well as connection encryption.

The response from the device comes in the following form:

This allows attackers to eavesdrop and spoof data, send various commands if they know the device parameters.

WeMo uses OpenWrt, a Linux-based operating system.

The device is initially detected using the UDP protocol by enabling a hotspot on the device (SSDP / UDP multicast package), then the device is detected using the application on the smartphone. Through a series of HTTP requests, the MAC address, serial number, device name, and description of functionality are obtained. All this is stored in XML files on the device itself, which can also be accessed.

Next, the device receives a password from the WiFi network and is already connected to the application on the smartphone through the existing WiFi network. Commands are exchanged via the SOAP protocol. The commands are specified in the SOAPAction header.

In addition, WeMo smartphone applications (to control smart devices) have vulnerabilities. Another attack option is device emulation, when an application on a smartphone sees an emulated device.

With the help of an emulated device, you can steal the user password from the WeMo personal account. After obtaining the password to the WiFi network, various user data can be stolen.

To analyze the WeMo application, attackers can use a number of applications such as "apktool", "dex2jar" and "jd-gui".

To protect privacy, Nest Protect requires blocking/filtering data being sent to the logging server.

Thus, for the devices described above, strong protection already exists, for some it does not exist at all. It is required to allocate a pool of devices for which there are no measures for information protection, and their additional configuration or protection from the outside.

Other examples of threats include the LinkHub light control hub (in which the researchers noted the lack of encryption, data transmission in the clear), the Lifx Bulb smart light bulb (insufficient authorization level), the Muzo Cobblestone audio streaming device (lack of encryption) and other similar devices. Manufacturers of such devices constantly release firmware updates, but due to a number of reasons (lack of connection, unwillingness of users, software errors), some devices may have outdated software that contains vulnerabilities.

TP-Link Smart LED Light Bulbs are susceptible to replay attacks. Such attacks consist in the fact that a network packet with a command is intercepted, duplicated and sent again, so the device receives two commands at once. For example, for such a light bulb, turning on and off are carried out by the same command, and using such an attack will cause the light bulb, for example, to only blink, but not turn on. This annoys users, which affects QoS (English Quality of Service). One simple protection option is to use a counter when sending commands, which will not allow you to duplicate the same command twice. Also TP-Link Smart LED Light Bulb and Philips Hue are subject to MITM attacks (Man in the Middle).

For the Vine Wifi Thermostat, data is encrypted using TLS 1.2 only between the smartphone and the server, but in the WiFi network there is no encryption when transferring data to the thermostat itself, and you can, for example, change the schedule for using the thermostat, which looks like this (JSON format ):

Upgrading to version 1.3.1 and later resolves this issue. Thus, for a number of devices, a firmware update is a solution to problems.

You can give examples of data leakage from IoT devices. Traffic activity for the Sense Sleep Monitor device can track when the user is sleeping, which is an indirect leak of personal data. The Nest Cam Indoor camera actively sends traffic only when someone appears in the line of sight (i.e. motion is detected).

Another problem is building a hierarchy of IoT devices, which is that one or more IoT devices connect to another IoT device, which in turn connects to another IoT device. And only the last IoT device is connected directly to the gateway 120.

An example is a set of light bulbs (for example, Osram Lightify or GE Link), which are connected via the ZigBee protocol to a hub operating according to the Zigbee Light Link standard. The hub itself can be controlled through a separate device, which also combines other IoT devices, forming control elements. Thus, some IoT devices can be hidden when trying to inventory all devices within the network, because they cannot be managed directly. This also creates the problem that attackers can take control of one of the IoT devices.

The LightwaveRF hub is designed to control IoT devices, such as those related to lighting (smart bulbs). The vulnerability lies in the fact that every 15 minutes the device checks for new firmware on the server through an unencrypted channel using the Trivial File Transfer Protocol (TFTP). A MITM attack allows you to change the firmware, which will allow an attacker to gain control over the device. In addition, it will be possible to send commands to control lighting.

Also, in the future, the application will consider the issue of controlling physical access to smart things, since using engineering ports (for example, a USB port that is closed by default), an attacker can take control of the device.

Another option for attacking IoT devices is to intercept and spoof traffic between platform 130, where applications 140 are installed, with which data is exchanged from IoT devices. Such attacks can be done using ARP spoofing methods (ARP spoofing), as well as DNS spoofing, which allows you to redirect traffic to malicious devices or network nodes and emulate the response from applications 140 in the cloud service 130. In some cases, traffic it may not even be encrypted, and users may use weak passwords (such as 1234 or qwerty) to access their personal account within application 140, which allows attackers to brute-force passwords and gain access.

In addition to IoT devices that perform certain functions (such as a thermostat or lighting), there are also IoT devices that control other IoT devices - the so-called controllers. Their main functions:

• creating scenes for each room using a graphical interface;

• setting up timers and emergency notifications;

• control of home automation from a mobile phone or tablet via an external access point;

• many ready-made scenarios for safety, comfort, climate schedules and energy saving.

However, such controllers (for example, Mi Casa Verde Vera Lite) may have vulnerabilities. The mentioned controller connects to the MiCasaVerde servers via the SSH protocol. The controller itself can execute scripts written in Lua. The following vulnerabilities exist for the specified controller.

• Authentication disabled by default when accessing the controller's control panel.

• Adding a backdoor with the following command:

• Path traversal allows access to files such as the user file (/etc/lighttpd.users) and password hashes (/etc/passwd).

• Insufficient permission checks. For example, for users with Guest access rights, the interface has options to save settings that such users should not change.

• Lack of signature for firmware.

• Users with Guest privileges can create backup files that contain important information (such as a list of users and password hashes).

• Lack of Lua code execution checks (ie potentially malicious code can be executed).

• CSRF vulnerabilities.

• Some libraries have buffer overflow vulnerabilities.

There is also the issue of physical access. For example, an attacker can gain physical access to one of the IoT devices and can reset its settings (for example, for Nest Thermostat, it is enough to hold down the power button for 10 seconds, other devices can also be easily reset to factory settings), disable its functionality, change settings and even use the device to track the user. For example, one use case for smart cameras involves sending frames to one of the attacker's addresses. For smart locks that have been accessed by an attacker, one use case involves providing access to a house during certain hours when the owners themselves are not at home.

Thus, additional solutions are required to track possible hacking of IoT devices.

We list the main vulnerabilities mentioned above.

• No or weak authentication (use of short or weak passwords).

• Lack of encryption when transferring sensitive data (eg passwords).

• Weak protection of devices when working in offline mode.

• Poor implementation of IoT device management applications. For example, applications can store encryption keys in clear text.

• Insufficient verification of the legitimacy of commands sent to devices. Some devices can be reset to factory settings using just one command (eng. 'reset to factory default') without any verification.

• No checks on basic physical parameters such as signal strength. For example, even if the device is designed to transmit signals at 2-3 meters, the upper limit of this parameter can be ten times higher - up to 30 meters, which allows attackers to attack from the street or from another house.

• Ability to access application data on smartphones that control IoT devices. For example, you can extract the traffic encryption key between a smartphone and a smart lock. In addition to being able to gain control, personal data of users also fall under the attack.

• Lack of firmware checks for devices. If the IoT device does not support digital signature verification for the firmware file, then it is possible to change the legal firmware to the one with the backdoor.

• The presence of additional services / services that run on the IoT device and which do not carry a payload for the user, but can be used by attackers to gain access to the device. An example would be telemetry services that send data to the manufacturer's servers or other parties.

Using these vulnerabilities, an attacker can carry out both “classic attacks”, such as theft of encryption keys, DoS attacks, reboots and resets of equipment, and specific ones specifically for certain IoT devices - for example, so-called blink attacks can be carried out against smart light bulbs, when the bulbs themselves flash frequently and chaotically, which annoys others (which affects QoS).

Thus, the creation of the surrounding infrastructure is required, which will avoid their use by intruders.

Hub (general description)

On FIG. 3 shows an example of an IoT ecosystem (infrastructure) diagram, to which elements have been added that are designed to provide the required level of security at different levels. In addition to devices 110, there may also be secure devices 320 in the network, which differ from conventional devices in having a secure OS (to be discussed in the context of the description of FIG. 2). Such devices have a sufficient level of protection already by default and can additionally be flexibly configured in order to increase the level of information protection, ensure confidentiality and ensure the safety of using devices.

In addition, security hubs 310 are also present in the system, as well as a security application 330 running on the side of platform 130. Security hubs 310 are network devices and can operate as an analogue of gateways 120, and work with mirrored traffic from gateways 120. Such implementations allow the hub 310 to intercept traffic, analyze the traffic that passes through the hub (proxy mode), receive mirrored traffic from other network devices. Security application 330 may be an antivirus application that checks both data stored within infrastructure 130 and running applications 140. An example of such an application is McAfee VirusScan Enterprise or Security Solutions for Amazon Web Services (AWS).

Each of the elements is discussed below:

• secure device 320,

• security hub 310,

• security application 330.

Fig. 2 illustrates an IoT device that can be secured with a secure operating system (OS). An example of a protected operating system is Kaspersky OS ⁶ ( ⁶ https://os.kaspersky.com/). An example of a device is a router.

On FIG. 2 shows the main elements - applications 240, the kernel of the operating system 230, the decision block 220 and security settings 210 (security policies, eng. Security Policies). Security settings 210 may be pre-created and typically include a set of rules governing how applications interact with both device resources and other applications. These settings are then loaded into decision block 220, which is used by the OS kernel 230 to validate all requests from applications 240. Such decisions are described in US10361998 and US9774568.

Settings (they are also security policies) can be based both on the use of roles (English role-based), and on mandatory access control (English mandatory access control), temporary access logic (English temporal logic) and any other known from the level of technology. The more sophisticated the policy, the more application control can be provided through the OS kernel and decision block.

Another option involves installing a separate hypervisor (not shown in Fig. 2), which will ensure the security of one or more guest operating systems on the device. An example of such a hypervisor is the solutions described in US10162964.

Such protection using a secure OS also provides opportunities for secure device boot (eng. secure boot) and secure application updates (eng. secure update). For secure boot, through security policies, the digital signature verification of the OS itself and its key modules (for example, drivers) will be initiated even before they are actually loaded into memory, which will avoid possible data compromise and loading of malicious modules. For secure app updates, the updates themselves are first downloaded to temporary storage on the device, then they are verified (which may also include verification of the digital signature of the update), and only then the trusted update process will be launched, which will update the applications and their data. In addition, security policies allow you to audit running applications (through logging of performed operations) using any of the techniques known from the prior art. The settings themselves can be transferred to the device from the security hub 310.

In addition, a whitelist is used on the secure device 320, containing applications that can be installed and run on the device, as well as applications that are not on the device, but with which this device is allowed to interact remotely. A similar list is used when implementing the Default Deny policy, when only applications from the list of allowed applications are allowed to install and run. Otherwise, when it is allowed to launch applications not only from this list, the protected OS allows you to log calls to system functions to track possible malicious actions. Such functionality is known in computer security and is called Application Control. The list of allowed applications is updated via hub 310. Application interaction rules include system call control. System calls include at least one of: inter-process communication, access to hardware (drivers).

Additionally, the policy for using the computing resources of the device 320 is loaded from the hub 310. For example, the policy contains a list of I / O ports allowed for use, as well as the conditions for their use. This eliminates the situation when an attacker uses engineering ports (for example, a USB port) to gain access to the device - in such cases, the protected OS turns off the power of such ports.

Consider the case when an untrusted device is used on the network. There are a number of ways to ensure a sufficient level of security for the entire IoT infrastructure:

• A ban on the transmission of unencrypted data over the network;

• Ban on the use of IoT protocols that have known vulnerabilities or limit their use;

• Detection and counteraction to DDoS attacks;

• The use of security policies that use allowing (English whitelist) and prohibiting (English blacklist) lists of devices, as well as installed applications;

• Using methods to mitigate (reduce risks) vulnerabilities in the protocols used (in cases where it is impossible not to use this version of the protocol);

• Isolation of individual network segments;

• Search and detection of anomalies in traffic, use of firewalls;

• Use of strong passwords, implementation of a password manager to manage passwords. Replacing default passwords for IoT devices;

• Priority of using wired data transfer protocols over wireless ones;

• Checking IoT devices for the possibility of physical hacking and access to closed functions (for example, engineering ports);

• Disabling unsafe or unused features of IoT devices;

• Replacing insecure IoT devices with dumb devices. For example, smart bulbs can be replaced with regular ones if the former are susceptible to replay attacks;

• Event logging at different levels - both at the level of individual devices and at the network level.

Since IoT devices are used in various fields of activity (from personal use to use in various areas of industrial production), the requirements for the same device can vary dramatically depending on the field of application. For example, a temperature sensor used within a smart home may have an allowable error of 0.1°C and operate in a small temperature range (for example, from -10°C to +40°C), while a temperature sensor used in production , should have an error of 0.01°C and work over a wider temperature range. Moreover, industrial sensors are subject to more stringent requirements for the transmission of readings (for example, real-time operation), speed of operation, responsiveness to changes by users and other parameters.

The security hub 310 can be either a standalone device (which can be a personal computer, laptop, or phone) or network equipment (such as a router). The description of the main functionality is illustrated in Fig. 4. An example of a hub 310 is Kaspersky IoT Secure Gateway.

In another implementation, the hub 310 can be a computer that has an antivirus installed with the ability to manage security settings for IoT devices.

The main functions of the hub 310:

• inventory of all IoT devices 110,

• selection of secure IoT devices 320 from the list of devices 110,

• defining links between IoT devices 110,

• organization of secure interaction of IoT devices 110 with applications 140 on the platform 130,

• organization of secure interaction of IoT devices 110 with computers 150.

Computer 150 refers to any personal computer, tablet, mobile phone (smartphone), server, or other device that has applications for interacting with IoT devices 110 and/or applications installed on these devices. An example is a server for storing data from smart webcams and managing them. Another example is a smartphone (e.g. Android OS) with installed applications (e.g. Mi Home) to control a robot vacuum cleaner (e.g. Roborock Sweep One). Also, the smartphone 150 may have a direct connection with the IoT device 110, for example, using Bluetooth LE. Device 150 will be referred to throughout the application as any device such as smartphones, personal computers, or servers.

The preferred implementation of the hub 310 is a router or other network device due to the large number of connectivity options. To communicate with computers 150, a conventional Ethernet or WiFi connection is used. For communication with IoT devices 110, there is support for protocols such as BlueTooth, ZigBee, LoRa, BACnet, Modbus, SNMP, RS232, RS422, RS485, OPC UA and others.

To organize secure interaction between IoT devices, hub 310 has the following features:

• checking network traffic, using IDS for anomaly detection;

• identifying vulnerabilities in IoT devices (for example, those related to IoT device firmware);

• inventory of IoT devices in order to separate various IoT devices into separate sub-segments (clusters) for management;

• analysis of transmitted objects, such as files, using anti-virus scanning, including using a virtual machine (sandbox);

• use of cloud anti-virus technologies such as Kaspersky Security Network, Symantec SONAR and others;

• the ability to deliver and install updates for IoT devices.

Another important function of the hub 310 is the filtering of data that is transmitted to the side of the platform 130 applications 140, in order to ensure the required level of user data privacy. For example, to check the transmitted telemetry data, there must be support for protocols such as MQTT and MQTT over TLS. The privacy features will be discussed in more detail below.

Another important function of the hub 310 is the storage of encryption keys. IoT devices can support PKI or have their own mechanisms for encrypting transmitted data. In the second case, the hub 310 will store the encryption keys after establishing a connection with the IoT device itself. In one implementation, hub 310 acts as a proxy server where devices 110 connect securely to hub 310 first, after which hub 310 creates a separate connection to service (platform) 130. One implementation includes VPN support from hub 310 .

All of the above functions of the hub 310 work with a complete inventory of IoT devices, when the maximum possible amount of information is known about these devices so that the necessary information security functions can be effectively performed.

Inventory of IoT devices (for security)

One of the inventory options is the classification of devices according to the level of information security. To do this, it is necessary to take into account the parameters related to the ability to identify the device, check its safe boot, use secure connections and reliable ports, support for encryption for stored data, the ability to update in a timely manner, work with certificates, support for centralized security policies, and much more. Let us give examples of the classification of such devices.

All IoT devices can be classified into different classes according to compliance with such key parameters as integrity, availability and confidentiality. For example, the following table illustrates the different classes of IoT devices:

Table 1-7 ( ^{7 IoT Security Compliance Framework, © 2017 IoT Security Foundation} )

Security Level Class Integrity Availability Confidentiality Class 0 Base Base Base Class 1 Average Average Base Class 2 Average Tall Average Class 3 Tall Tall Tall Class 4 Very tall Tall Tall

Class 0 characterizes devices, the loss of control over which or their compromise will lead to a subtle damage to the information security of an individual or organization. An example is the temperature data leak inside a refrigerator. Higher classes describe devices whose corruption or failure can cause more significant damage to people and organizations, including class 4 suggests that loss of control over the device will lead to injury (or even death) or catastrophic consequences for infrastructure (for example, sensors in industrial plants or life support systems in hospitals).

Consider security levels for integrity, availability, and confidentiality. Information integrity is a term in computer science that means that data has not been changed during any operation performed on it, whether it be transmission, storage or display. In telecommunications, data integrity is often checked using the hash sum of the message computed by the MAC algorithm. Availability of information - the state of information in which subjects with access rights can exercise them freely. Access rights include: the right to read, change, store, copy, destroy information, as well as the right to change, use, destroy resources.

Basic - Device failure can result in minor integrity issues, reduced availability, and loss of personal data.

Medium - Device failure can result in a limited integrity threat, reduced availability, and loss of personal data.

High - Failure of devices can result in a severe threat to integrity, reduced availability, and loss of personal data.

As mentioned above, the same device can be assigned to different classes depending on where it will be used. For example, a WiFi extender for personal use might be class 0, but a hospital use would result in a class 3 device due to privacy and accessibility requirements.

Checking compliance with key parameters or compliance for the device.

Hardware

Immutable Secure Boot process, installed by default class 1 Debugging process (debugging) only after authentication class 1 Protection against breaking (tampering) class 1 Physical protection against tampering, adding tags that indicate tampering (English tamper evident measures) class 2 Protection against reverse engineering (reverse engineering) class 3 Extra access ports (USB, RS232, etc.) are not available class 1 Unavailability of test mode (test points) class 2 Impossibility of copying (downloading from the device) firmware class 1 Controller in the CPU (eng. CPU watchdog) to monitor unauthorized attempts to stop the CPU class 1 Random number generator (true random numbers) class 1 Random number generator as a separate device class 2

Software part

Ability to restrict the operation of unauthorized software on the platform class 1 The need to sign updates class 1 Software image encryption class 2 Software works only through allowed ports class 2 Software downgrade protection class 2 Availability of tamper-resistant memory to store the root of trust class 2 Software images do not contain information for debugging (English debug) class 2 Protecting software from side-channel attacks class 2 The source code has been checked by a static analyzer class 2 Development process audit class 2 Keys for signing software are stored in storage according to the FIPS-140 level 2 standard class 2 The software is checked by fuzzing on the input data class 2 Support for partial installation/download of patches class 1 If it is impossible to authenticate the update, such an update is possible if the user is physically present (when the user himself joined manually, and not over the network) class 1 Working with FIPS 140 keys class 1

OS

Updated OS upon delivery of devices class 2 File access control configured class 2 Only the most privileged account has access to password files class 2 All services and applications unnecessary for the correct functioning of the device have been removed. class 2 Applications have the lowest execution priority class 2 All information security features of this OS are included class 1 Firewall configured class 1 Unsecured communication protocols are not used (for example, HTTP) class 1 All unused ports are closed class 1 All passwords are reset by default (e.g. for Bluetooth PIN) class 1 WiFi does not use WPA and TKIP class 1 When using the MQTT protocol, TLS encryption is used class 1 When using the CoAP protocol, a DTLS connection is used class 1 Latest protocols used (Bluetooth 4.2, not 4.0) class 1

Authentication and Authorization

Device ID is unique and tamper resistant class 2 Secure NTP is used class 2 Empty password cannot be set class 1 NIST SP800-63b password guidelines class 1 Anonymous access is not possible class 1

Encryption

Uses a true random number generator (NIST SP 800-90A) class 2 Uses a separate process to generate, distribute, and store keys (per FIPS140-2) class 2 Unprotected functions (such as MD-5 or SHA-1) are not used class 1 Keys are stored in secure storage (tamper resistant) class 2 Asymmetric encryption uses unique keys for each device class 2

(Web) device interface

Access uses Strong Authentication class 2 Mandatory exit on timeout class 1 Do not store passwords in plain text class 1 Vulnerability analysis was carried out (according to the top 10 popular OWASP attacks) class 1 Data is validated when entering a login-password class 1 Decreasing session duration class 1 Fuzzy tests done class 1

Mobile app (if used to manage the device)

3GPP TS33.117 device password class 2 Interaction with the product server only through a secure connection class 1 Password storage according to the FIPS140-2 standard class 1 Validation of data entered into the application class 1

Confidentiality

Minimum storage of personal data of users class 1 Personal data is encrypted class 1 Only authorized users have access to personal data class 1 Anonymization of personal data class 1 The service provider implements a Data retention policy class 1 Informing users about what information is collected from users class 1 There is a verification of deletion of personal data class 1 The product complies with local laws on the protection of personal data (i.e. adapted to the region) class 1 The device manufacturer must provide the user with the ability to configure, store and delete personal data class 1 The manufacturer must also provide a notice of users' responsibility for the safety of their data. class 1

Cloud service (application 140 within platform 130)

All cloud services have up-to-date software class 2 Web Server Authentication Disabled class 1 HTTP trace disabled class 1 Valid TLS certificate class 1 Web services do not have publicly known vulnerabilities (CVE...) class 1 Disabled repeated negotiations of TLS connections class 1 Unused ports are disabled (closed) class 1 Support for valid client certificates only class 2 Blank or default passwords are not supported or reset class 1 The maximum number of failed login attempts is limited by 3GPP TS33.117 class 2 Access to privileged functions is limited class 1 Anonymous access is allowed only for the public part of the services class 1 Cloud security standards comply with Cloud Security Alliance [ref 18], NIST Cyber Security Framework [ref 21] or UK Government Cloud Security Principles [ref 24] class 2

The above classes reflect compliance with respect to one of such characteristics as integrity, availability and confidentiality. The overall device class can be calculated from various metrics - for example, based on the lowest class of one of the characteristics.

As already noted in the description of FIG. 4, the key function of the hub 310 is the inventory of all IoT devices 110 and the selection of certain groups - domains - from the list of these devices. Devices 110 are divided into domains based on a number of characteristics (discussed below) - primarily related to the information security requirement of the devices themselves.

In one embodiment, security is determined based on the device's compliance class information. If a device has a class 3, then it can be classified as a safe device, while a class 0 device should be considered unsafe.

In one implementation, the hub 310 collects class information about the IoT device 110 directly from the device itself. In yet another implementation, the class of the IoT device 110 can be determined based on the characteristics of the IoT device 110. The characteristics of the IoT device 110 can be obtained after communicating with the specified device over the network - for example, at the stage of connecting the IoT device 110 to the hub 310 .

For example, when connecting to Hue Light Bulb using HTTP requests such as GET and PUT, you can get the following response after authorization:

The data obtained allows you to determine the parameters of a particular model of this device. As a rule, IoT devices transmit the following data for identification: serial number and / or identifier, timestamp, device class, identifier of the factory key that was used to create the identifier, public key and other data.

Figure 5 shows a diagram of the partitioning of IoT devices into information security domains based on the data received from them. Hub 310 splits all IoT devices into at least three domains:

• Trusted devices 510. For example, these could be secure IoT devices 320. In yet another implementation, the trusted device domain 510 includes all devices with a compliance level of 2 or higher.

• Insecure IoT devices 520. Such devices include those that have known vulnerabilities, are sources of malicious activity (for example, they spread malware such as network worms). The vulnerability database can use information from CVE (Common Vulnerabilities and Exposures). In yet another implementation, insecure devices 510 include all compliance level 1 devices.

• Untrusted devices 530. These IoT devices may not have known vulnerabilities, but based on the compliance class (which is defined as class 0, for example), they cannot be classified as trusted devices 510 or even insecure 520.

Trusted devices 510 can be not only secure IoT devices 320, but also IoT devices whose specification allows them to be considered reliable in terms of information security. For example, if information was received from an IoT device that it contains firmware that meets the EAL4+ ⁸ specification ( ⁸ For example, OPTIGA™ TPM chips) according to the Common Criteria standard, has only one working communication interface with encryption support, and reliable authentication option, then this IoT device will also be classified as a trusted device 510.

Another example of trusted devices is IoT devices built using the Intel EPID platform, which allows for a stronger encryption key infrastructure ⁹ ( ⁹ http://www.intel.com/content/www/us/en/internet -of-things/iot-platform.html).

Another option for classifying an IoT device as trusted 510 is the ability to use a separate security application 330. The preferred implementation of such an application is an antivirus application (for example, Kaspersky Internet Security). The key functions of such an application are a file scanner, a firewall, a vulnerability scanner, and application control. In addition, the application 330 maintains a separate interface for communicating with the hub 310. The preferred implementation of the application on the hub 310 is to use Kaspersky Security Center.

One of the factors why most IoT devices are either insecure devices 520 or untrusted 530 is the inability to use the security application 330 due to a number of reasons - lack of support for the hardware platform, lack of computing resources, closed platform and other factors.

As noted earlier, some IoT devices can connect through other IoT devices, thus not having a direct connection to the 310 hub. air conditioning system. Such sensors may not be connected to the hub 310, but at the same time have a number of known vulnerabilities that can lead to incorrect operation of these (and other related) IoT devices. Incorrect readings of temperature sensors can change the operation of the air conditioner, due to which the temperature regime in the room may be disturbed. To combat replay attacks, you can use special counters on the IoT device 110 and hub 310, which synchronously increase their values during data transfer, and in case of discrepancy, you can determine the fact of this attack.

In addition, a number of IoT devices, such as motion sensors, are important from the point of view of computer security, since the operation of other IoT devices, such as smart locks, lighting and air conditioning systems, and others, depends on the correct operation of such sensors.

Also, the user's device (eg, smartphone) 150 may have a direct connection to the IoT device 110, for example, using Bluetooth LE. Thus, in such cases, the hub 310 is not used as an intermediary, and such connections can compromise the security of the entire system. In such cases, it is preferable to install an anti-virus application on the smartphone 150.

Consider other options for partitioning groups of IoT devices 110 into domains that are not related to information security.

Breakdown into functional domains

In addition to partitioning IoT devices into domains based on information security characteristics, hub 310 also partitions groups of IoT devices into domains based on their functionality. The functionality of the device determines the main purpose of the device.

For example, within a smart home, IoT devices can be broken down into the following domains (or classes):

• lighting (light sensors, smart lamps, automatic curtains);

• air filtration and purification (humidifiers, humidity sensors, heaters, odor absorbers, thermometers);

• sewerage (water leakage sensors, dispensers, reducers);

• cleaning (smart vacuum cleaners);

• security (smart locks, motion sensors, smoke sensors, smart sockets, video cameras and tracking systems, window and door opening sensors, gas leakage sensors);

• communications (smart speakers, routers, signal amplifiers and other communication equipment);

• wearable devices (transponder for an animal, bracelets for monitoring blood pressure, sleep and other physiological parameters).

Figure 6 shows an example of partitioning IoT devices into functionality domains. It can be seen that the domains of security (FIG. 5) and functionality (FIG. 6) can be different but also overlap. Such partitions allow building different topologies of IoT devices depending on the required tasks.

The main task in dividing IoT devices into functional domains is to ensure the correct operation of these devices, including taking into account information security (Fig. 5). For example, the domain of security-related functionality (such as smart locks and webcams) needs to work as securely as possible, which will require additional analysis of device data from an information security perspective. Thus, the compliance for a smart lock should be higher than for a smart light bulb.

Determination of the type of functionality of the IoT device can be performed when it is initially connected to the hub 310. The hub 310 has information about the type of device based on data about its serial number and/or identifier, device class, factory key identifier. In another implementation, the hub 310 makes a request to the side of the platform 130, where one of the applications 140 serves the requests of a particular IoT device. Based on the application type information 140 (for example, the application provides access to cleaning functions), it can be concluded that a particular IoT device belongs to the cleaning functionality domain. The application type information may be contained in the application data in an application store such as Google Play or the Apple Store. Thus, the definition of functionality is also performed dynamically, based on data that will be collected over time.

Partitioning devices into owner domains

Another option for dividing devices into domains using the hub 310 is to use labels by device owner and configure them by usage.

Examples are listed below.

• There is no owner (English no owner, unowned). The device has no owner and is not used for its intended purpose.

• Certain owner (English owned). The device is owned but not configured for use.

• Enabled. The device is ready to perform its functionality.

• Registered. The device is recognized and known to hub 310.

• Controlled (English controlled). The device is included using the hub 310 in one of the security domains.

• Configured. The owner has configured the device for use, the hub 310 has applied the necessary security policies within the security and functionality domains.

• Works (English operational). The device performs the inherent functionality within the user settings.

For example, when the device is turned on for the first time, it does not have an owner and transmits its connection identifier to the network, after which it will be recognized using hub 310 (it will receive the status of an enabled device and the device will be included in the security domain of untrusted devices), then the user will connect to the device either through hub 310 using your device, or through application 140, after which the device will acquire an owner and be registered and included in one of the security domains. Then the user sets up the device, and it begins to work within the imposed security policies.

Division into domains for the safety of human life.

Another option for splitting into domains involves taking into account the functionality of IoT devices in terms of security for human life. For example, a malfunctioning (damaged or hacked) smart light bulb can be turned off using a toggle switch and will not pose a noticeable threat to the safety of human life, while a broken thermostat can seriously change the temperature in the room, which will lead to inconvenience (change in QoS). The use of smart locks that have vulnerabilities that can be used by intruders in order to steal valuables indoors is another big problem and threat. Malicious use of various sensors used in industrial equipment or in critical infrastructure nodes (for example, nuclear power plants) can lead to serious accidents and casualties.

Thus, it is possible to make a gradation of devices according to the degree of their influence on the safety of human life. This table reflects an approximate division:

Security level Degree of influence 0 None or minimal. Example - light sensor one small
An example is a range of household appliances such as a smart vacuum cleaner, a rheostat and other smart home elements. 2 Important
Example - smart locks, central control units for smart things 3 critical
Management of critical infrastructure elements, elements of human life support (for example, a pacemaker)

Partitioning by device domains, its configuration

After the device is assigned to a specific domain (information security, functionality, safety of human life, owners), the hub 310 can apply security policies that define restrictions for IoT devices to the operation of a particular IoT device, depending on whether the device belongs to certain domains.

As noted above, hub 310 can impose the following restrictions on IoT devices:

• using a gateway to control traffic,

• disabling individual (insecure) IoT devices,

• firmware update for IoT devices,

• updating the software of IoT devices.

Restrictions can be imposed based on the reputation of a particular IoT device. Reputation is based both on static data about the device (for example, identifier, manufacturer data) and on its behavior, which is expressed in the form of network traffic associated with the operation of the IoT device. Thus reputation is a dynamic parameter. Even if the device can be trusted when connected (have no vulnerabilities, have the necessary compliance classes), anomalies can occur during the operation of the device itself, including the use of zero-day vulnerabilities.

In addition, the hub 310 may perform initial configuration of the IoT devices 110 when they are first turned on and/or connected to the hub 310.

Examples of initial setup.

Example 1

Smart light bulb.

The user added a new Hue Light Bulb, which, when turned on, tried to connect via ZigBee to a 310 hub that supports this type of protocol. After collecting the identification information, the hub 310 retrieves from the database information that this device belongs to an untrusted device class in terms of information security, belongs to the lighting domain (class) in terms of functionality, does not have an owner during initial configuration, and has a zero level of human life safety.

Based on certain parameters, the hub 310 will wait for the user to further configure the smart lamp and will not impose any traffic restrictions.

Example 2

Water leakage system. A set of sensors and controllers.

The device will be defined as belonging to an untrusted information security device class, belonging to the sewerage domain (class) in terms of functionality, having an owner (since it sends data about its work to a user device, such as a tablet) and having the first class of human life safety.

Hub 310 will then apply a set of rules to filter traffic that is directed to the controller, as well as periodically check the integrity of the firmware in case the controller firmware has been changed by other means (for example, through a different protocol bypassing the hub 310).

Example 3

Smart locks.

In this case, the trusted class of the device in terms of information security will be determined, the device belongs to the security domain (class) in terms of functionality, has an owner (since it sends data about its work to a user device, such as a tablet) and the second class of human life safety.

Since the device has a trusted class in terms of information security, it is assumed that at the moment, attackers do not have the ability to maliciously change functionality and additional configuration or traffic control is not required. At the same time, passive observation is necessary to check the performance, because this device has a significant impact on human life. One of the options for such control is to check the periodic sending of service traffic from the smart lock, which indicates its operability. If the traffic stops being sent, the hub 310 will send a notification to the owner or even block the locks if such settings are provided by the user.

Fig. 9 illustrates how hub 310 operates when a new device is connected.

In step 910, the hub 310 defines a new IoT device 110. This can be done by passively listening to traffic, through a direct connection to the hub 310 (the main functionality of the hub 310 is a router), user input.

At step 920, data about the device is collected using the hub 310. The data can be a device identifier and series, a device name, manufacturer information, a set of characteristics (for example, the parameters of the device itself), a MAC address, and other data.

At block 930, the information security domain of the device is determined. Specifically, domains include trusted, untrusted, and insecure devices.

At block 940, a device functionality domain is determined. Functionality domains are such domains as: lighting (light sensors, smart lamps, automatic curtains), air filtration and purification (humidifiers, humidity sensors, heaters, odor absorbers, thermometers), sewerage (water leakage sensors, dispensers, reducers), cleaning ( smart vacuum cleaners), security (smart locks, motion sensors, smoke sensors, smart sockets, video cameras, window and door opening sensors, gas leak sensors), communications (smart speakers, routers, signal amplifiers and other communication equipment), wearable devices. For a car, these can be other domains of functionality - control systems for individual units (engine, brakes, gearbox), airbags, adaptive assistance systems and emergency braking, anti-skid, multimedia, light, heating.

At step 950, a device domain for human safety is determined. In particular, in one of the implementation options, a partition is used at least into 4 domains with varying degrees of impact on the safety of human life. Steps 930-950 can be performed either sequentially or simultaneously as the necessary data is collected (or available).

At step 960, based on the determined domains at steps 930-950, the device is configured. Hub 310 can filter traffic both from the device itself and to it (firewall), disable the device itself (for example, insecure), update the device firmware or software on the device. In another implementation, the hub 310 can send a number of commands to configure the device if the protocol for working with this device is supported.

Device configuration 110 uses device configuration policies that depend on the domains defined in steps 930-950. The combination of domains of information security, functionality and safety of human life generates a three-dimensional matrix of intersections. To simplify, we present the intersection of information security and functionality domains in the form of a table below (example):

Lighting Filtration and purification of air Security Class 0 Policy 1 Policy 1 Policy 7 Class 1 Policy 1 Politics 2 Politics 9 Class 2 Politics 2 Policy 3 Politics 13 Class 3 Policy 3 Politics 10 Politics 14 Class 4 Politics 9 Politics 12 Politics 15

Depending on the information security class and functionality domain, different device configuration policies can be selected. The policy itself is presented as a set of rules that are executed either on the device 110 itself (configuring the device itself) or using the hub 310 (for example, downloading the latest firmware). Rules in the preferred implementation are specified as a condition and an action (Eng. If This Then That (IFTTT)).

In addition, each policy can be further refined (if possible) for a specific device model. Let's take an example.

For example, if an unknown IoT device was defined as a smart light bulb (i.e. belongs to the “Lighting” functionality domain) and has a class 0 for information security, then Policy 1 will be selected for this device for subsequent configuration, which includes traffic monitoring. In addition, the device identifier and series were determined, which made it possible to determine the light bulb from the Philips manufacturer, which implies an extended set of settings, such as controlling settings for a given device.

Another example would be to define another IoT device as a smart lock, it should be assigned to the Security functionality domain and depending on the information security class, for example, class 2 will be selected within home use, and class 4 within an industrial enterprise. Depending on these classes, different configuration policies for this IoT device will be selected (Policies 13 and 15, respectively).

In addition to the initial configuration, the hub 310 additionally monitors the activity of the IoT device 110 itself over time and changes its settings, as well as the imposed restrictions. For example, a thermostat should send data only to certain addresses (for example, manufacturer and statistics on google.com) and use only ports 9543, 11095, 80 and 443. Any changes are an anomaly, and such a rheostat should be transferred to another information security domain.

Hub 310 supports partitioning of IoT devices into domains according to other characteristics. One of them is the location of the device. The location can be determined:

• by the user manually, using the web interface when joining the hub 310;

• based on data on the strength of the wireless signal from the IoT device;

• based on belonging of IoT devices to one of the domains in the hierarchy (Fig. 7).

Using additional domain partitioning by other characteristics allows you to enter additional parameters in policies to configure devices. For example, location accounting allows you to understand which of the IoT devices are outside the home and, accordingly, may be subject to a possible attack from the outside, which requires higher information security requirements for these devices, as well as stricter configuration policies.

Another example of additional partitioning into domains is the partitioning of all IoT devices into two domains by the possibility of analyzing data transfer protocols from IoT devices. Separate policies for configuring IoT devices are imposed on the domain in which there are devices for which it is possible to analyze packets of transmitted data, and, accordingly, make changes and generally control traffic.

Using the hub to control (configure) the device

As part of the use of IoT device configuration policies, the hub 310 configures the IoT device 110.

On FIG. 10 shows how the hub 310 is used as part of an IoT device vulnerability investigation and subsequent configuration.

An IoT device 110 is connected to the hub 310 via one of the data transfer protocols. In addition, a device 150 (for example, a smartphone) is connected to the hub 310, on which an application 1020 is installed to configure the IoT device 110. An example of such an application is Mi Home to control smart things like a robot vacuum cleaner or a lighting system. The hub 310 also provides interaction with the platform (service) 130 and applications 140.

Of the elements that provide information security, in Fig. 10 shows a security application 330 (for example, Kaspersky Internet Security antivirus), a cloud-based security service 1010 (for example, Kaspersky Security Network), and a database 1040 that stores information about known vulnerabilities for applications 1020 as well as devices 110. In one embodiment, the database 1040 is included in the security application 330 and/or security service 1010. In addition, such a database 1040 contains rules for configuring applications 1020 and devices 110.

An insecure interaction that cannot be controlled by the hub 130 is the direct interaction of the application 1020 with the application(s) 140, such as over a mobile network. Also, the IoT device 110 can communicate with other IoT devices through other communication protocols without using the hub 310. An example of such a connection is a connection between devices via the Bluetooth LE protocol.

The beginning of the hub 310 interaction with the IoT device looks like this:

• IoT device 110 discovery and characterization. Additionally, the hub 310 receives information about the OS that is installed on the IoT device 110 and the applications (services) that are installed and running there.

• Identification of possible vulnerabilities and risks of the IoT device 110 in the database 1040. If there is no data, then a request is made to the security service 1010 and the database 1040 is updated.

• Determination of a possible device (in this case, a smartphone) 150 with which the IoT device 110 communicates. In one embodiment, this is done based on the communication between the IoT device 110 and the smartphone 150 on which the application 1020 is installed.

• Determination of possible vulnerabilities of the application 1020. In one implementation, this is done using the installed security application (antivirus) 330 and using the database 1040.

• Determining possible insecure interactions between application 1020 and application(s) 140, such as over a mobile network. Also, the IoT device 110 can communicate with other IoT devices through other communication protocols without using the hub 310.

• Based on the collected information, the hub 310 determines the rules for configuring the IoT device 110, application 1020, smartphone 150.

Example.

Once the robot cleaner is identified as the IoT device 110, an Android smartphone 150 is identified on which the legacy application 1020 for controlling the robot cleaner is installed. The fact of an outdated application can be obtained while this application is running (by transferring the application version) or using third-party applications installed on the smartphone 150. The smartphone 150 was initially connected to the hub 310, which provides router functions in this network.

The hub 310 retrieves from the database 1040 the rules for updating the application 1020 to the current version (for example, via Google Play), as well as downloading new firmware for the robot cleaner from the platform 130 and then installing it. The firmware itself must be verified before being installed on the device using the following checks:

• verification of the digital signature and certificate of the firmware file;

• checking the firmware file using a file scanner for malicious code;

• running the executable code (if present) in the virtual machine.

In the embodiment of FIG. 10, the application installed on hub 310 is Kaspersky Security Center.

One option for connecting the IoT device 110 requires a smartphone 150 to be in range of the Bluetooth connection to ensure that the authenticated user is trying to add a new IoT device.

The determination of the nearby mobile device 150 can be performed based on the received signal strength indicator ¹⁰ (https://en.wikipedia.org/wiki/Received_signal_strength_indication).

Hub 310 can detect not only IoT devices, but also routers (which can also be considered IoT devices) to which they are connected (if there is a network hierarchy), and at the same time reconfigure routers, if possible.

To correctly support the settings for managing IoT devices, the hub 310 uses the profile of each device separately (discussed below).

Device discovery

IoT device discovery can be implemented using several discovery methods.

The preferred implementation is to directly connect the IoT device 110 to the hub 310. For example, when connecting the Hue Light Bulb, the following request will be sent via the HTTP protocol for authorization:

Using information about known (present in the system) devices, you can use a signature detection method (for example, regular expressions to search for strings) that will allow you to determine which device is connecting to the hub 310 at the moment.

Additional information includes network information - for example, information about connection ports. As an example, the WeMo switch uses specific ports - 49154 and 49153.

The authorization request looks like this:

Signature overlay using hub 310 using network information will determine that a number of WeMo products are being used, and using data from device IDs, determine their type.

Another option for device discovery is to use the analysis of wireless signals using the hub 310. In stages, such an analysis includes:

• determination of the frequency domain of signals (eng. frequency domain samples);

• selection in the frequency domain of certain signal zones (eng. spectrum tiles);

• clustering of signals in the zone;

• selection of unique signals in clusters.

By using multiple antennas at the hub 310 (or by using multiple hubs 310), it becomes possible to discover the physical location of the discovered IoT device 110 based on signal strength relative to the antennas/hubs. Note that the present invention uses already known technologies for detecting unknown devices, such as those described in US10567948.

Once a device is discovered, specific identifiers can be used to identify and track it, such as the MAC address or factory ID (DeviceId).

Device Profile

After discovering an IoT device, the hub 310 builds its profile based on the data collected (and collected during device operation).

Determination of possible vulnerabilities and risks of an IoT device includes building a device profile, which includes the following parameters:

• device identifier;

• information about the manufacturer, series, firmware version;

• MAC address;

• data on OS and installed applications (for example, application identifiers, vendor names, file hash sums, etc.);

• use of protocols (data transfer security analysis), traffic characteristics, eg encrypted network traffic is considered secure;

• frequency of network activity;

• user access log (including anonymous ones, if allowed), while access can be analyzed based on data packets or based on user binding to certain mobile devices 150, and network packet analysis uses DPI (deep packet) technologies inspection);

• known vulnerabilities (stored in database 1040);

• RF analysis (US2016127392A1 discloses RF analysis to identify possible wireless attacks).

Based on the data from the profile, the risk level is calculated. It can be expressed on a scale from 0 to 100, where 0 is a guaranteed safe (trusted) device, 100 is a guaranteed untrusted device that has pronounced malicious functionality. Different parameters affect the level of risk in different ways. For example, information about the manufacturer may not affect the level of risk, while data on installed applications contribute up to 80% of the level of risk.

The profile can also be updated based on the following events.

• Events from sensors. Events at the physical layer (physical layer) of the OSI network model or at the data layer (data layer). For example, data transfer via virtual LAN.

• Session events. Data packets from the network (network layer) or transport layer (transport layer).

• Application layer events. Data packets at the session layer (session layer), presentation layer (presentation layer) or application layer (application layer). Such packets are generated when applications are running (sending and receiving traffic).

• Events at the level of user interaction with the device. Occurs when the user interacts with the device. For example, during the authentication process.

• Status related events. For example, periodically sending data about the status of the device (that it is working correctly).

• Information about the domain in which the device resides. Domains include functionality domains, information security domains, human life security domains.

Such events are continuously received on the side of the hub 310, they are grouped by device.

Grouping can be done using machine learning algorithms, namely: random forest, artificial neural network, support vector machine, as well as boosting algorithms for the composition of the mentioned algorithms.

Device profile templates can be stripped of personal data (such as geotags or specific device settings, such as a temperature range for a thermostat) and uploaded to the cloud so that the template can be used for other users' similar devices. In another implementation, the personal data is hashed without the possibility of reverse transformation.

The profile of an IoT device can be checked in two stages - first by traffic, then - if anomalies are detected - based on an analysis of the operation of the IoT device itself. The analysis can be performed both indirectly and directly - if the security application 330 is installed on the IoT device itself. Deviations from the profile also increase the level of risk, but for a short period of time to prevent false positives.

Fig. 13 depicts a method for creating a device profile, as well as training and using a trained device model to predict device behavior. At step 1310, a new IoT device is detected using the hub 310. Device discovery methods are described below (FIG. 8). At 1320, device data is collected to generate a device profile. The profile can be formed either immediately after the device is discovered, or after a period of time, as it is necessary to collect enough data for certain profile fields (for example, those related to network activity).

The device profile is converted into data that can be used to create a machine learning model.

и параметры

(от англ. parameter):For example, select the following commands that were sent to the device (captured packets) or from the device itself,

and parameters

(from English parameter):

,

,

,

,

,

,

,

,

,

,

.

.

Based on the selected commands and parameters, behavior templates are formed containing one command and one parameter each describing the said command:

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

.

,

.

Then, based on the generated templates, behavior templates are additionally formed containing one parameter each and all commands described by the mentioned parameter:

,

,

,

,

,

,

Then, based on the generated templates, behavior templates are additionally formed containing several parameters and all commands simultaneously described by the mentioned parameters:

.

.

In yet another implementation, the behavior profile parameters are converted as follows:

• in case the behavior profile parameter can be expressed as a number, - "numerical range"

команды connect, тип упомянутого параметра может быть «численное значение от 0x0000 до 0xFFFF»,for example, for a parameter that is

connect command, the type of the mentioned parameter can be "a numerical value from 0x0000 to 0xFFFF",

• if the behavior profile parameter can be expressed as a string, - "string"

for example, for a behavior profile parameter that is a connect command, the type of the referenced behavior template element could be "string less than 32 characters"

• if the behavior profile parameter can be expressed as data described by a predetermined data structure, the type of the mentioned behavior profile parameter can be "data structure"

In another embodiment, in addition to the behavior profile, as parameters, tokens are included that are generated based on the lexical analysis of the mentioned parameters using at least:

• predefined rules for the formation of lexemes,

• pre-trained recursive neural network (English recurrent neural network).

For example, using parameter lexical analysis

‘c:\windows\system32\data.pass’

based on the rules for the formation of lexemes:

• if the string contains a path to a file, determine the disk where the file is located;

• if the string contains a path to a file, determine the folders where the file is located;

• if the string contains a path to a file, determine the file extension;

where the tokens are:

• paths to files;

• folders where files are located;

• file names;

• file extensions;

tokens can be generated:

"file paths" →

'c:\',

"folders where the files are located" →

'windows',

'system32',

'windows\system32',

"file extensions" →

'.pass'.

In another example using parameter lexical analysis

‘181.39.82.8’, ‘181.39.72.38’, ‘181.39.14.213’

based on the lexeme formation rule:

для всех упомянутых IP);• if the parameters are IP addresses, define a bitmask (or its equivalent, expressed in terms of metacharacters) describing the mentioned IP addresses (i.e., such a bitmask M that satisfies the equality

for all mentioned IPs);

a token can be generated:

‘181.39.*.*’.

In another example, from all available parameters, which are numbers, tokens of numbers are formed in predefined ranges:

23, 16, 7224, 6125152186, 512, 2662162, 363627632, 737382, 52, 2625, 3732, 812, 3671, 80, 3200

sorted by ranges of numbers:

0 to 999

→ {16, 23, 52, 80, 512, 812},

from 1000 to 9999

→ {2625, 3200, 3671, 7224},

from 10000

→ {737382, 2662162, 363627632, 6125152186}

Next, at step 1325, the device profile rollup is created. A convolution is created in one of several ways:

hashing of each profile field;

hashing of all profile fields as a whole (by concatenation);

use of flexible or fuzzy convolutions (English fuzzy hash).

Rollup also ensures that personal data associated with a particular device cannot be reverse-transformed and, therefore, data cannot be recovered after rollup has been applied.

In one of the options for implementing the system, the convolution function is formed by the metric learning method, i.e. so that the distance between convolutions obtained using the mentioned convolution function for behavior patterns having a degree of similarity greater than a predetermined threshold value is less than a predetermined threshold value, and for behavior patterns having a degree of similarity less than a predetermined threshold value, it is greater than a predetermined threshold.

In another embodiment of the system, the formation of the convolution function from the indicative description of the behavior pattern is performed through an autoencoder, while the input data are the parameters of the indicative description of the behavior profile, and the output data is data having a coefficient of similarity with input data above a predetermined threshold.

Then, at step 1330, it is checked whether this device rollup is known either on the side of the hub 310 or on the side of the security service 1010 (eg, Kaspersky Security Network). The latter option is preferable, since it is cloud security services that have much greater computing power and have the most complete database of known objects (both legitimate and malicious).

Device convolution is associated with a device model in the form of a trained machine learning algorithm, for example, random forest, artificial neural network, support vector machine. The model describes the known behavior of the device based on the input parameters associated with the profile (for example, network activity). The model allows you to predict the behavior of the device in time, and when the event diverges, to determine anomalies. The model can also be selected based on various parameters such as speed and efficiency.

For example, when choosing a machine learning method, a decision is made whether to use an artificial neural network or random forests as a detection model, then, in the case of choosing a random forest, a separating criterion for nodes of the random forest is chosen, or in the case of choosing an artificial neural network, a method of numerical optimization of parameters is chosen artificial neural network. In this case, the decision to choose one or another machine learning method is made based on the effectiveness of the mentioned method in detecting malicious files (i.e., the number of errors of the first and second kind that occur when malicious files are detected) using input data (behavior patterns) of a predetermined type (i.e., data structure, number of behavior pattern elements, performance of the computing device on which malicious files are searched, available resources of the computing device, etc.).

In yet another example, a discovery model machine learning method is selected based on at least:

• cross-validation, cross-validation, cross-validation (English cross-validation, CV);

• mathematical substantiation of criteria AIC, BIC, etc.;

• A/B testing (English A/B testing, split testing);

• staking.

In another example, in the case of low performance of the computing device, random forests are chosen, otherwise, an artificial neural network is chosen.

In one implementation of the system, machine learning is performed on a pre-built untrained detection model (i.e., a detection model whose parameters of said model do not allow, based on the analysis of the input data, to obtain output data with an accuracy higher than a predetermined threshold value).

In another implementation of the system, at least the following acts as a machine learning method for the detection model:

• gradient boosting on decision trees (eng. decision-tree-based gradient boosting);

• decision trees;

• kNN nearest neighbor method (K-nearest neighbor method);

• support vector machine (SVM).

If the convolution is known, then at step 1340 a known model is loaded onto the hub 310, which will be used to check the device for anomalies. Models can be stored both in a database and as separate files that contain both a description of the model itself and a set of its parameters (for example, weights for a neural network).

Otherwise, at block 1350, data collection on the device continues (profile is completed), which will then be used at block 1360 to build a device behavior model. At step 1370, the resulting model, along with the model-identifying device rollup, is loaded into the security service 1010 and can be used further.

Consider an example. When new models of smart things appear (for example, a smart robot vacuum cleaner), the hub 310 will detect the device as new, create a bundle and send it to the side of the security service 1010, where there is no data on this device yet. Hub 310 will continue to collect data, create a device behavior model, which will include parameters such as:

• first 3 octets of IP addresses where traffic from the device is sent;

• average size of sent data packets;

• frequency of sending data;

• device series identifier;

• time and frequency of work (in this case, cleaning the premises);

• other data.

Using the received data, the hub 310 builds a model of the behavior of this device, which will then be uploaded to the side of the security service 1010.

As output parameters for the behavior model, the state of the vacuum cleaner is used - switched on and active (vacuums the rooms), standby mode (the vacuum cleaner is connected and waiting for a command or time to start cleaning), firmware update, offline (the vacuum cleaner is disconnected from the network), error codes.

Once the model has been trained, it can be used to detect anomalies in the operation of the robot cleaner. If, according to the model, the vacuum cleaner performs cleaning between 12 and 18 hours when there are no owners in the house, but at the same time it turns on at 11 am and sends data packets to a new IP address, then this may indicate that the robot vacuum cleaner was is hacked (for example, by exploiting a vulnerability), and running the trained model will signal that the vacuum cleaner's current behavior is different from the predicted behavior. An anomaly signal will be sent to both hub 310 and security service 1010.

The trained model can be used on similar devices in the future, i.e. can be used with other hubs 310 on other networks. To do this, the trained model must take into account a number of parameters that may depend on the location of both the IoT device and the hub. These options can be:

• IP addresses of services where network packets are sent from the IoT device. Regional servers can be used for different regions.

• Timestamps. IoT devices operate in different time zones, which must be taken into account when training the model. For example, local time on hub 310 may be used.

• Geotags.

Another option for training the model involves ignoring parameters that may depend on the regional location, but this is only possible if such parameters (for example, geotags) do not make a significant contribution (weight) to the training of the model.

If the model has already been created earlier, then at step 1340, a ready-made device behavior model is loaded. After that, at step 1345, an additional step is implemented in the form of monitoring the performance of the model, when feedback is collected (for example, from the user) about errors in the operation of the model. In the case of a robot cleaner, this could be model false positives when the device tries to download firmware updates from new regional servers, which will cause the model to report anomalous device behavior. The user can take note of this and either disable the use of this model via the hub 310 interface, or add the IP addresses of the regional servers to the exception.

Feedback can also be implemented automatically. For example, in the above case, the IP addresses of the new regional servers can be checked by the security service 1010 using well-known antivirus technologies (eg, checking the specified addresses against a database of IP addresses, digital signature verification, and other checks). If it turns out that the specified IP addresses are trusted, then the behavior model can be retrained taking into account the new parameters (this stage is not shown).

Restoring an IoT device from a backup

Hub 310 has the ability to restore a number of IoT devices. Such possibilities include:

• Resetting the IoT device settings to the default (factory) settings;

• restoring IoT device settings from a backup.

Restoring from a backup can be done through the application 140, which saved the profile of the IoT device 110, or by saving the settings in a file directly on the hub 310. For example, for Philips Hue, all settings are stored in a JSON file that can be imported to IoT device from hub 310.

In one embodiment, the hub 310 associates the backup copy of the IoT device 110 with its identifier. In yet another implementation, the hub 310 binds the backup to a device profile.

In one implementation, the hub 310 stores a backup of the IoT device 110 on the security service 1010 and uses it in the event of a restore.

In one implementation, the hub 310 stores a backup copy of the firmware of the IoT device. In this case, in case of recovery (for example, the device has switched to the emergency boot mode), the hub 310 also restores the device firmware, for example, using known commands specified in the device profile.

In one implementation, in the event that an IoT device fails (e.g., spontaneously reboots) more often than based on statistics or device profile, hub 310 forces a backup and sends a notification to the user, for example, through application 140. A reboot can be detected by the hub 310, for example, by querying the device to return the current uptime.

Similar Device Detection

The device profile is additionally used to detect similar (for example, similar in functionality, security/danger) devices using the hub 310. For example, when a new device model is released, many of its operation parameters remain similar (or completely identical) to the parameters of the old model. These options are:

• manufacturer identifier;

• device characteristics, for example, a new version of a smart light bulb will also have parameters identical to the old model (brightness, color temperature and other parameters);

• the communication protocol used between the device and the cloud service 130 and applications 140, the frequency of network activity, and many other parameters related to network traffic.

In one implementation, when determining an unknown device, the hub 310 reads the vendor ID and sends a request to the security service 1010 to look for similar device profiles from that vendor. Having received the necessary profiles, the hub 310 builds a profile of an unknown device and compares either the profile itself or the profile collapse with the downloaded data. In the event that the profile of an unknown device is determined to be similar to a profile of an already known one, the hub 310 considers the unknown device to be the same device whose profile was downloaded from the security service 1010. All device configuration policies can be applied to this device.

In one implementation, the hub 310 computes the fingerprint of the IoT device 110.

In general, the fingerprint contains information about the characteristics of the device 110. The characteristics of the device 110 are:

• device ID 110;

• identifier of the operating system running the device 110;

• location (geolocation or position within a network) of device 110;

• regional characteristics of the device firmware 110 (eg, continent/country/city);

• software authentication methods available on device 110 (eg, password, pin code, screen unlock pattern);

• the presence of available communication channels on the device 110 (does it have access via wireless data transfer interfaces, such as Wi-Fi, is data transfer enabled on the device via mobile networks and how many mobile networks, is data transfer enabled via wireless interfaces);

• others.

The data collected by the hub 310 about the device 110 is transmitted to the security service 1010.

In general, the security service 1010 calculates a vector of key features from the fingerprint of the device 110 based on the data received from the hub 310.

In general, the security service 1010 extracts key characteristics, where the key characteristics are characteristics that influence the identification of the device 110. In general, the key characteristics are extracted statistically during system operation. For example, the characteristic "manufacturer LG" may be a key characteristic, as it affects the identification of the device 110.

In one implementation, the security service 1010 creates clusters (performs clustering) of devices 110 based on at least one key characteristic of device 110 extracted from the fingerprint of device 110. Said clustering is generally system learning. In one embodiment, clustering is performed based on a few of the identified device key characteristics 110, which are in turn a vector of device key characteristics 110. Thus, the key characteristic vector contains at least a portion of the extracted device key characteristics. As a result, for each hub 310, the security service 1010 forms a set of clusters, which include previously known devices 110 of the hub 310.

Next, the security service 1010, using one or more of the vector distance functions known in the art, calculates the distance between the key feature vector of the device 110 and the key feature vector of at least one device known to the security service 1010 that is part of the aforementioned created clusters. . Device 110 is considered new (unknown to hub 310) if the calculated distance exceeds a threshold value. In general, basic security policies may apply for the new device 110.

Network profile

In addition to building profiles of IoT devices, hub 310 also builds a profile of the entire network.

One option for collecting data about IoT devices on the network is to passively listen for traffic. For example, for all wireless protocols, hub 310 can collect data packets and, based on the analysis, even identify IoT devices that are not directly connected to hub 310. As mentioned earlier, such devices can be various sensors (for example, light or temperature sensors) that are connected to another IoT device.

The collection of traffic using the hub 310 can be implemented as follows (Fig. 8). After enabling the hub 310 at step 810, it turns on all possible data transfer protocols and at step 820 determines all devices that operate nearby based on passive listening for traffic. Then, at step 830, all devices are turned off (this can be done automatically by sending appropriate commands if the hub 310 has information about the protocols of the real IoT devices), after which they start turning on in turn at step 840. This is done specifically to confirm authentication of all IoT devices. For example, for devices that support IEEE 802.1X, this is done via the EAPOL protocol. At block 850, a complete map is built from all identified IoT devices.

Based on the collected data, it is possible to build both a flat network model of all detected IoT devices and a hierarchical one (illustrated in Fig. 7). The latter is built on the basis of known data about the subordination (hierarchical connection) of some IoT devices to other IoT devices. For example, if a number of smart bulbs and light sensors are connected via a proprietary protocol (which is not supported by the hub 310) to a smart switch that is already connected to the hub 310 itself, then you can use a special rule that combines these devices into a separate domain, then referring this domain as a separate object to the functionality domain in the lighting class. In another implementation, the hub 310 combines several of these devices into one logical (virtual) device for ease of monitoring and verification.

Fig. 14a-c show the construction of a network profile of IoT devices using hub 310 over a period of time. On FIG. 14a shows the initial connection of the hub 310 to the network, during which it detects two IoT devices 110, for example, a robot vacuum cleaner and a rheostat. After some time (Fig. 14b), the user's mobile device 150 connects to the network, and an IoT device 110 is detected, which is an aggregator of other IoT devices 110. Such aggregators are devices such as HomeBridge or MajorDomo. The dotted arrow reflects the fact that the mobile device 150 both appears (connects) to the network and disappears, which is due to the fact that the user himself, along with the smartphone 150, can leave the house. Fig. 14c displays the state of the network after a certain period of time, when one of the devices was disconnected from the network. This may be due to a number of reasons - the device has exhausted its resource, was moved, it had a firmware update (due to which it can now be detected on the network as a new device).

The network profile includes at least:

• at least one device, its characteristics, device profile collapse;

• lifetime of the device in the network, the frequency of its appearance;

• communications of the device with other devices, whereby the relationship is determined based on the intercepted traffic between the devices (if applicable);

• time when the device appeared in the network;

• operating time of the device (time spent in the network).

Network profile information is stored in one of the data formats that allow you to describe objects, such as XML or JSON.

The format of the record about the object has an approximate form:

Fig. 15 reflects how the network profile is constructed. At step 1510, data is collected by the hub 310 about certain (discovered) devices. Then, at step 1520, the hub 310 creates a network profile from certain devices, after which, at step 1530, it continues to collect information about devices - about connecting new ones, disappearing old ones, updating the software part of known devices, etc. In step 1540, the network profile is updated after each collection of information in step 1530, i. e. steps 1530-1540 are repeated continuously after a predetermined amount of time has elapsed. In addition, at step 1530, information about devices can be updated not only periodically, but also based on events, for example, during an unscheduled update of the device itself (firmware).

The resulting network profile hub 310 uploads to the security service, if necessary, constantly sending updates for this profile. In one implementation, the profile itself is stored as an XML or JSON file, and all updates are stored separately as small files that describe all changes (English diff) for the next version of the file. In another implementation, the network profile is stored as a single file, and older versions are stored in backup storage.

Network profiles from various sources allow you to keep statistics on the prevalence of certain devices, do statistical research on the popularity of manufacturers, assess the security level of each network individually, and also in comparison with other networks of IoT devices.

One of the advantages of using such information is to predict the appearance of new devices on the network when new hubs are connected in the future.

For example, based on statistics for all available network profiles, it is known that 20% percent of all networks have at least one robot vacuum cleaner that was connected to the hub during the first week. In addition, with a probability of 40% within a month, an aggregator for smart light bulbs is connected to the hub. Using this information, it is possible to predict the emergence of new IoT devices in each network as it lives. This allows:

• preload device configuration policies that have not yet appeared, but are likely to appear in the near future;

• pre-load traffic analyzers for devices that have not yet appeared, but are likely to appear in the near future;

• additionally download new firmware for devices;

• offer the user to use those devices that have a higher class of information protection;

• offer the user those devices that satisfy the level of security specified by him.

Network profiles can be compared with each other - comparison can be made both by highlighting changes in files (eng. diff), and using comparisons of network profile convolutions, as well as using a comparison of the entropy of data describing profiles.

A network profile rollup is created in one of several ways:

• hashing of each profile field;

• hashing of all profile fields as a whole (by concatenation);

• use of flexible or fuzzy convolutions (English fuzzy hash).

Using clustering methods, one (or several - if more than one cluster centroids are allocated) is additionally constructed averaged network profile, which is the center of the cluster (centroid). The average network profile includes the most popular (frequently encountered) IoT devices. In yet another implementation, the average profile includes devices for which the maximum usage time multiplied by the number of devices. In this case, the profile includes devices that are not so common, but work longer.

Comparison of the network profile with the average profile additionally allows us to estimate what the network will become after a certain period of time (for example, after six months). For example, when hub 310 is turned on for the first time, it identified only one robot vacuum cleaner as an IoT device, but by downloading information about the average network profile from security service 1010 and comparing these two profiles, hub 310 loads device configuration policies that have not yet appeared, but are likely to appear in the near future (for example, these will be smart bulbs and a weather station, smart refrigerator, game console, TV and refrigerator), traffic analyzers for new devices (if necessary), firmware updates.

Configuring the machine according to the type of network

Building a network profile also allows you to determine which devices interact with the hub 310 and understand what type of network (devices) it is. Examples of network types are shown below.

• Home (home network). Devices that are designed for use in homes predominate, namely lighting, cleaning, air filtration, wearable devices.

• Public. The devices are used in public places such as parks, squares and other areas that are visited by a large number of people.

• Industrial. Various sensors and industrial controllers with high safety requirements prevail.

• Transport. Machine control units (eng. ECU) act as sensors.

• Medical. IoT devices are various life support sensors for patients, which also have very high security requirements.

The definition of the network type is implemented based on data about network devices. A network is a set of connected devices within the same network infrastructure that are controlled by one or more hubs 310. The network infrastructure includes one or more networks (including subnets).

For example, hub 310 has identified the following IoT devices:

• smart vacuum cleaner Xiaomi Roborock Vaccum Cleaner,

• a range of Philips Hue bulbs,

• LightwaveRF hub.

Then such a network is home (home type).

Hub 310 has defined the following IoT devices for the industrial network:

• Danfoss 060G1100 pressure transducers,

• thermostatic valves Danfoss AVTA 25 003N0032,

• temperature sensors MBT 400 084N1025.

Hub 310 has defined the following IoT devices for the medical network:

• temperature sensor MAX30205,

• oximeter MAX30101.

For each IoT device, an additional characteristic is used that determines what type of networks the IoT device data is used in. These characteristics can be downloaded from the security service 1010 when requested from the hub 310. In one implementation, the network usage characteristic is determined based on the popularity of using the IoT device on certain networks.

For example, if a particular sensor is known to be used 94% of the time on home networks, 5% of the time on public networks, and only 1% of the time on industrial networks, then that sensor would be identified as being used on home networks.

In yet another implementation, the network type is determined based on the security settings (policies) used. For example, a user who cares about information security can use industrial-type sensors and configure the network in such a way that such a network is no longer considered a home network, but an industrial one, and work with it is carried out on the basis of appropriate algorithms (for example, the requirements for cryptographic strength of algorithms are completely different ).

Most networks in practice are mixed networks - in the same network there are IoT devices that are found both in typical home networks and in industrial, medical or public networks. This is due to various aspects: the availability of devices on the market, their cost, functionality and other characteristics.

In one implementation, the user (administrator) sets the final network type through the web interface of the hub 310.

In another implementation, the network type is determined using rules. Examples of rules might be:

IF

(Number of IoT devices used in industrial networks) > 5

OR

(Percentage of IoT devices used in industrial networks) > 15%

THEN

Network - industrial

Depending on the type of network, hub 310 enforces different policies for IoT devices when they are configured and managed. For such types of networks as industrial or transport, more strict adherence to information security standards is required. For example, for a smart lock, which is usually installed on a network with a type of home, when installed on a network that has been defined as industrial, you will need:

• use an encryption key with a length of at least 512 bits;

• use a stronger encryption algorithm than AES;

• using hub 310 to block sending any traffic to all servers that are not on the whitelist.

For smart switches, in this case, it will also be necessary to carry out traffic control using the 310 hub when they are installed in an industrial network in order to avoid replay attacks. In addition, hub 310 maintains a list of allowed devices from which commands can be sent to smart switches.

In one embodiment, the hub 310 may set up a mixed network type. That is, apply the rules for two or more of the above types of networks. In case the rules override each other, the hub 310 selects the rule that is more secure.

Fig. 16 shows the setup of devices depending on the type of network. At 1610, device data is collected using the hub, with the devices connected to the hub. At step 1620, the type of network is determined using the security service, where information about certain devices is sent. In other implementations, the determination occurs at the side of the hub 310. At 1630, policies are determined to configure devices depending on the defined network. At 1640, policies are applied with the device control hub 310.

Changing network packets for device control

The hub 310 acts as a firewall to control network packets that are sent to the IoT device 110 to change its settings.

Analyzed parameters:

• protocol type (for example, SMB or HTTPS);

• network address or domain name;

• port number;

• IPv4/IPv6;

• identifier of the device from/to which the traffic is directed;

• an indication of the application that performs the network exchange.

Parameters can be overlaid with regular expressions to work with network address ranges and/or applications and devices.

Fig. 11 illustrates the creation and use of rules for IoT devices. At the first discovery and identification of the IoT device 110 at step 1110, the hub 310 makes a request for its metadata (for example, data about the manufacturer, identifier, serial number, etc.) to the side of the cloud security service 1010 (for example, Kaspersky Security Network), which contains information about the supported protocols, and which will be downloaded at step 1120 to the hub 310.

For example, for the Hue Light Bulb, it is known that the transfer and configuration of parameters is carried out using GET / PUT requests over the HTTP protocol. Thus, when such a device is detected, a module for analyzing the HTTP protocol will be loaded on the hub 310 at step 1130. The analysis of the upper layer protocols corresponds to the seventh level of the OSI model (English Application level). Then, for this module, rules will be loaded that determine the parsing of parameters specifically for a series of these devices.

After the parameter parsing rules are loaded, rules can be created to control the IoT device (its parameters) at step 1140. In one implementation, this is done by the user, who thus sets the required range of parameters of the IoT device. However, not all parameters can be supported in the current version of the protocol or device, some of the parameters cannot be changed for security reasons or within the framework of the device design itself. Thus, automatic parameter filtering is the preferred option.

In one implementation, all parameters of the IoT device 110 are divided into mutable and immutable, which allows you to either change or discard all network packets to change the immutable parameters.

Another implementation option describes the ranges within which the parameters of the IoT device can be changed.

For example, Hue Light Bulb will only allow the following options:

On-true/false

Sat - from 0 to 255

Bri - from 0 to 255

Hue - from 0 to 10000

A PUT request to change these parameters within the specified limits will be correctly passed to the Hue Light Bulb IoT device.

Threat Modeling

Having a built network profile and device profiles, as well as the ability to predict the appearance of new devices in the network, the hub 310 has the ability to simulate threats and exploit possible vulnerabilities in the future.

Each IoT device can be tested against known attacks, such as checking for default passwords (and weak passwords from tables), fuzzing, and other research options. Since it is usually impossible to examine such IoT devices from the users themselves, this should be done within the infrastructure of an information security service provider. For example, you can buy the most popular models of IoT devices (data about this can be obtained from the average network profile) and examine them for vulnerabilities or possible attacks.

For threat modeling, as well as modeling a possible network of IoT devices, you can use models such as STRIDE ¹¹ ( ¹¹ https://en.wikipedia.org/wiki/STRIDE_(security) or PASTA ¹² ( ¹² https://threatmodeler.com /threat-modeling-methodologies-overview-for-your-business/).

For STRIDE, the following analysis methods are used:

• spoofing - use of other authentication data;

• falsification (English Tampering) - falsification of data or commands;

• denial (eng. Repudiation) - the impossibility of verifying the integrity of the data or manufacturer's data;

• Information disclosure - disclosure of personal data;

• Denial of service - refusal to service equipment;

• Elevation of privilege - escalation of access rights.

Similar methods can be used in relation to various data associated with IoT devices, namely:

• firmware,

• application on a smartphone,

• application in the cloud service,

• certificates and encryption keys,

• magazines,

• authentication data,

• data loaded into memory,

• traffic.

For example, for smart locks, attack channels can be: traffic between a smartphone and a cloud service 130, traffic between a smartphone and the lock itself. An application on a smartphone may store users' personal information in an unencrypted form. Spoofing the cloud platform 130 may result in the user not being able to correctly use their smartphone app to set up the smart lock. Interception of data transmitted between a smartphone and a smart lock, as well as platform 130 with further spoofing, can lead to a denial of service. In addition, the application on a smartphone may have vulnerabilities and other critical errors that may lead to incorrect interaction with the smart lock, as well as the 130 platform.

An example of an attack on industrial controllers is a constant flood of commands containing falsified data, for example, in the MODBUS protocol format. Such attacks can occur when intruders penetrate the network and then send out the mentioned data by intruders, which often leads to equipment failure. When modeling threats, the hub 310 itself can send such packets and analyze the status of IoT devices.

In one implementation, the hub 310 also analyzes from which network segment data is coming to the IoT device. In yet another implementation, the hub 310 analyzes how long the device from which data is sent to the IoT device has been online. So, for example, data packets from devices that have been registered on the network for less than 10 minutes can be ignored. When modeling threats, the hub 310 can create models of device behavior and use them for further operation.

Wear assessment

One of the important factors in the operation of IoT devices for the safety of human life is the assessment of the wear of the devices themselves to determine the guaranteed service life of these devices, depending on environmental conditions and the characteristics of the devices themselves.

For each IoT device, the following data is additionally collected and used:

• Working hours, working schedule, parameters (including expected ones), error information.

• Available data on operating conditions. This includes information about the ambient temperature (for example, air, if the sensor works in air), pressure, chemical composition of the medium (for example, pH).

• Known ranges of environmental characteristics for the correct operation of devices.

• Guaranteed service life when operating within the specified ranges.

• Mean time to failure (greater than guaranteed service life).

• Data of the actual stay of the device functioning (time between failures).

• The coefficient of criticality of the device for human life.

For example, for the AVTA 25 003N0032 thermostatic valve, the operating temperature range is from -130 to +25 degrees Celsius for the external environment. Such information is provided by the provider itself or may be obtained through information gathering methods (such as web crawling).

An example of using the criticality factor of a device for human life can be a situation in which an industrial IoT device has a reduced device criticality factor for human life, and an IoT device in a smart home has an increased one.

Information about operating conditions can be collected both from sensors of IoT devices and from third-party sensors that are installed nearby. For example, a temperature sensor located next to a water valve will report the ambient temperature.

Another source of information on device wear assessment is information on how often the devices themselves are changed. This information can be tracked using the hub 310 at the moment when one of the IoT devices is replaced with a similar one in functionality - the hub 310 stores information about how long the last device was registered on the network. Such information can be passed to the side of the security service 1010, where the average uptime of a certain IoT device will be calculated. In addition, the provider (supplier) of the IoT devices themselves can provide such information.

Another option for obtaining information about the wear and tear of devices is to intercept traffic from the IoT device to the application 140 in the cloud service 130, where information about errors and malfunctions is sent. When analyzing the data transfer protocol, you can track the frequency of occurrence of errors in the operation of IoT devices to assess the degree of wear and tear of the device.

Another option for obtaining information about a failed device is the user himself, who marks the device through the web interface of the hub 310 as failed. The hub 310 takes this information into account to calculate the time the device has been online.

The obtained information is also used to estimate the degree of wear, which is a numerical value in a given range, where one end of the range corresponds to the fact that the device is guaranteed to remain operational for a given period of time, and the other to the fact that the device is guaranteed to fail during a given period of time. time interval.

All of the above information is used to build a device wear model. The wear model is implemented as a trained machine learning algorithm, such as a random forest, an artificial neural network, a support vector machine, a set of rules for determining the degree of wear. The trained model is then used to:

• recommendations for the replacement of specific IoT devices whose service life is coming to an end according to the model;

• changes in IoT device configuration policies based on the safety of human life;

• changes in IoT device configuration policies, based on the extension of the service life (operation).

The recommendations are a report that contains statistical data on changes in device operation parameters over time, device efficiency, energy consumption during device operation, and device performance.

For example, the hub 310 determines that one of the IoT devices - a leakage sensor - is close to its wear and tear, and the frequency of errors about the operation of the automatic tap changeover is constantly increasing (this indicates the need to clean the tap and / or replace the sensors). Hub 310 changes the control policy of this device:

• forced regular sending of messages to the user about the wear of the device,

• the settings of the device operation are changed in order to extend the functionality of its operation before replacement,

• replace the specified device with a similar device from the device pool, where the similar device is a device that has the functionality necessary to perform the tasks performed by the specified device (in case the device pool contains at least two devices similar to the specified device, the user is informed on the availability of similar devices in order to select a similar device to replace the specified device),

• a device preventive check mechanism can be triggered.

The wear model itself is preliminarily trained on data on the operation of devices similar to the specified one. If the device is out of order, the wear model is retrained in such a way that the degree of wear of the device, determined anew with the help of the specified model, most closely matches the real one.

Fig. 17 depicts the use of the model to estimate the degree of wear of devices. At step 1710, the hub 310 determines the IoT devices on the network using the discovery techniques previously described. At step 1720, data is collected on the operation of the device to assess its wear. The data is error messages, malfunctions in the operation of nodes, and other important messages that can serve as information about a possible device failure. In addition, the hub 310 counts the time the device has been operating on the network. Additional step 1730 allows you to collect information about the operation of similar devices. This helps to estimate the wear of new, just released models, for which not enough statistics have yet been collected - in this case, knowledge of the degree of wear of previous models can be used to estimate the wear of future ones. All data from the hub 310 can be aggregated in the security service 1010.

At steps 1720 and 1730, information about operating conditions is additionally collected both from the sensors of the IoT devices themselves and from third-party sensors that are installed nearby.

At step 1740, a device operation model is built taking into account the degree of its wear (the preferred option is on the side of the security service 1010). The model is represented as a trained machine learning algorithm, such as random forest, artificial neural network, support vector machine. The model describes the known behavior of the device based on the input parameters associated with the profile (for example, network activity). The output of the model uses data about errors and the time of their occurrence. Using such a model, it is possible to predict possible errors in the operation of devices and, based on these errors, predict the degree of wear. The degree of wear can be expressed as a bit flag (healthy/failed) or have a scale, for example from 0 to 100. At step 1750, the resulting model is used to estimate the degree of wear of the device. Also, depending on the degree of wear, further actions are determined - inform the user, turn off the device, reduce its operation time (changing configuration policies).

For example, during the month, a number of hubs 310 collected information about the operation of smart bulbs of a certain model, including data on errors when using them, as well as available information about their operating conditions. The collected data will be used on the side of the security service 1010 to build a model to assess the degree of wear of devices. The created model will be uploaded to all hubs 310 where similar (similar) devices are registered.

Additionally, the hub 310 changes the operation settings of the IoT devices 110 using commands with a known data transfer protocol.

Protecting the safety of human life

The hub 310 can impose restrictions on the parameters of the IoT devices 110, which can be changed using a number of commands, for example through the application 1020 or the application 140.

Parameter control requires knowledge of the protocols used to transfer parameters. Hue Light Bulb uses the HTTP protocol, where the parameters of the light bulb are changed via a PUT request, such as:

In the query above, the user has disabled the remote turning on of this light bulb or changing its brightness.

Thus, a rule will be created that will allow sending such PUT requests only from a specific MAC address of the user's device, or discard PUT requests that change the state parameters (state).

The user can set filtering rules on the hub 310 in a human-readable form, for example, in the form of the statement “for all thermostats, the temperature should be between 20 and 26 degrees”, which will allow converting this statement into a set of network rules that will apply to all devices of the functionality domain “Filtration and purification of air” and their parameters related to temperature.

In addition, the hub 310 may contain basic settings (parameters) that are optimal for human life. For example, if there is a light sensor, set the maximum and minimum illumination thresholds. If there is a temperature sensor, set the maximum and minimum temperature thresholds. In one implementation, the hub 310 prevents the lamps from turning on too brightly or too dimly, and also prevents, for example, the air conditioning system from going beyond thresholds. In another implementation, when the threshold values are exceeded, the hub 310 sends notifications to the user.

In one implementation, the hub 310 takes into account the time interval (season, month of the year) to manage settings (parameters). For example, in summer, one threshold value is used in the settings for temperature, in winter, another. In another implementation, the hub 310 considers the time of day to control settings. So, for example, in the daytime, one parameter is used for the light sensor (one interval of lighting brightness is available), at night, others. In yet another implementation, the hub 310 takes into account the environmental conditions in which the sensors are used. For example, if the light sensor is located on the terrace (outside the building), then some parameters are used, if inside the building, others. In one implementation, the hub 310 takes into account the conditions by whom the IoT device is used. For example, the hub 310 does not allow the water heater in the adult bathroom to heat water above 60 degrees Celsius, and in the children's bathroom - above 45 degrees Celsius.

privacy aspect

There are a number of IoT devices that can collect information about the user's sleep (Beddit Sleep Monitor), children's behavior (for example, a number of modern toys can record geotags, voice recordings and other information), exercise performance (sports trackers), medical information, and even information about sexual habits.

For example, by examining sleep monitor traffic, you can determine when a user is sleeping because the traffic patterns will be different from when the user is awake (and out of the room). You can also determine the user behavior pattern by smart locks that send service traffic when the user passes through the door.

An example can be given when data collected using modern toys equipped with call recording functionality was freely available, and the MongoDB database was discovered using the Shodan system ¹³ ( ¹³ https://www.vice.com/en_us/article/ pgwean/internet-of-things-teddy-bear-leaked-2-million-parent-and-kids-message-recordings).

The option of data leakage is through a fake (English rogue) device. The IoT device itself, which can be registered on the network through a separate web server, can be either real or virtual. Such a device can collect data both about the network it is connected to and about devices nearby when they send out broadcast requests. A more advanced version of listening involves a single device with many interfaces, the main purpose of which is to listen to traffic. However, most often, attackers use existing devices, using vulnerabilities to establish access, as well as adding backdoors (English backdoor) for further use of devices that have been accessed.

Another variant of the attack refers to the attack on the machine learning processes associated with IoT devices - this is the supply of incorrect data during training. For example, an attacker can deliberately add certain distortions to the data stream that will lead to incorrect training of the model.

To counter attacks on traffic, you can use the ILP shaping (independent link padding) method. Another protection option is to use a VPN. Changing traffic reduces its entropy and allows you to deal with attacks on personal data. On FIG. 18 shows an example of changing (shaping) traffic in order to smooth out peaks that may indicate certain user actions.

For example, Xiaomi ClearGrass Air Detector determines the air quality and additionally sends this data to one of the servers using the MQTT protocol. As one of the options, you can write a rule in iptables to redirect this traffic (for example, to the same localhost) or simply block this traffic through the firewall on hub 310.

The user can be offered the option of tracking the leakage of personal data, indicating the distribution of resources around the world (through server positioning), so that the user can determine where his data can be sent. For example, a user in Russia may decide not to send telemetry data to China or the US and prohibit sending data to servers from these regions. For users in the EU, you can use an automatic rule that will prevent any data from being sent outside of network resources located in the EU, which is consistent with GDPR regulations.

Another option is to upload a list of policies (rules) to the hub 310 to control leakage of personal information. The set of rules includes:

• list of allowed/denied IP-addresses or networks;

• data transfer protocols allowed for use for a given region and/or user;

• list of devices for which separate traffic processing is required;

• a list of data fields (attributes) that require separate processing (generalization, prohibition, tokenization, and other options).

Options for agreeing to send data can be implemented on the side of the hub 310, which will, through a separate interface, offer users options for ensuring Privacy through control of sent data. Options:

• Opt-in

• Opt Out

Data hiding options may include data generalization, when the data of one user is changed in such a way that it cannot be distinguished from a group of users (usually tied to a specific group, for example, age or place of residence). Another option includes a ban on the transfer of certain data (English suppression). Similar approaches are included in the framework of the k-anonymity method. An example implementation is the following approach:

• an age group is indicated instead of the exact age, for example, from 20 to 30 years;

• the name is deleted;

• geography of residence can be enlarged from a state/province to an entire state or entity (eg the EU).

I-diversity is an extension of k-anonymity to track data homogeneity. T-closeness is a further refinement of i-diversity considering the distribution of quantities.

Additionally, to maintain confidentiality, these methods can be applied not only to user data, but also to the IoT devices themselves. For example, for telemetry tools, you can transfer not the unique identifiers of the devices themselves, but some generated identifier.

Fig. 12 shows the scheme for encrypting and tokenizing user data transmitted from IoT devices. If the IoT device 110 supports one of the encryption protocols (for example, via HTTPS or DTLS), then the connection is established with the hub 310, which acts as a proxy server. The transmitted data is decrypted and tokenized if the protocol is supported by the hub 310. Tokenization is the process of replacing a confidential data element with a non-confidential equivalent, called a token, which has no independent meaning/meaning for external or internal use. All identifiers are subject to tokenization, for example, those that identify the user or his device (IoT device 110). In addition to tokenization, some of the data is subject to generalization, such as geotags.

The data is then transmitted over an encrypted channel to the cloud service 130 side of the security application 330, which can recover, through a reverse replacement process, some of the data that has been tokenized and is necessary for the application 140 to function correctly. In this way, the user will be able to use the application 140 in the same way as if its data were not tokenized, but the protection of confidentiality during data transfer is achieved.

For additional protection of the user's personal data, a scheme is provided for encrypting and tokenizing data that the IoT devices 110 transmit to the side of the platform 130 (applications 140).

Fig. 19 displays the application of personal data processing policies. At step 1910, the data transfer protocol between the IoT device 110 and the hub 310 is analyzed. At step 1920, fields are extracted that may contain personal data. Processing is based on the use of rules that can be implemented as regular expressions. Then, at step 1930, each field is analyzed in terms of the personal data processing settings (policies) that have been uploaded to a particular hub 310. For example, depending on the country, these will be different settings. After that, at step 1940, the specified field is processed on the side of the hub (prohibition of transmission, tokenization, generalization, and other methods).

Fig. 20 shows an example of a general purpose computer system, a personal computer or a server 20, comprising a central processing unit 21, a system memory 22, and a system bus 23 that contains various system components, including memory associated with the central processing unit 21. The system bus 23 is implemented as any bus structure known from the prior art, which in turn contains a bus memory or bus memory controller, a peripheral bus, and a local bus that is capable of interfacing with any other bus architecture. System memory contains a read only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26 contains the main procedures that provide information transfer between the elements of a personal computer 20, for example, at the time of loading the operating systems using ROM 24.

The personal computer 20, in turn, contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29 and an optical drive 30 for reading and writing to removable optical disks 31, such as CD-ROM, DVD -ROM and other optical storage media. The hard disk 27, the magnetic disk drive 28, the optical drive 30 are connected to the system bus 23 via the hard disk interface 32, the magnetic disk interface 33, and the optical drive interface 34, respectively. Drives and related computer storage media are non-volatile means of storing computer instructions, data structures, program modules, and other data of the personal computer 20.

The present description discloses an implementation of a system that uses a hard disk 27, a removable magnetic disk 29, and a removable optical disk 31, but it should be understood that other types of computer storage media 56 that are capable of storing data in a computer-readable form (solid-state drives, flash memory cards, digital disks, random access memory (RAM), etc.), which are connected to the system bus 23 through the controller 55.

The computer 20 has a file system 36 where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38 and program data 39. The user has the ability to enter commands and information into the personal computer 20 through input devices (keyboard 40, manipulator " mouse" 42). Other input devices (not shown) may be used: microphone, joystick, game console, scanner, etc. Such input devices are typically connected to computer system 20 via serial port 46, which in turn is connected to the system bus, but may be connected in other ways, such as through a parallel port, game port, or universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, the personal computer may be equipped with other peripheral output devices (not shown), such as speakers, a printer, etc. .

The personal computer 20 is capable of operating in a networked environment, using a network connection to another or more remote computers 49. The remote computer (or computers) 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description of the entity. personal computer 20 shown in FIG. 20. Other devices may also be present in the computer network, such as routers, network stations, peering devices, or other network nodes.

The network connections may form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the local area network 50 via a network adapter or network interface 51. When using networks, the personal computer 20 may use a modem 54 or other means to communicate with a wide area network such as the Internet. Modem 54, which is an internal or external device, is connected to system bus 23 via serial port 46. It should be clarified that network connections are only exemplary and are not required to represent the exact network configuration, i. in fact, there are other ways to establish a connection by technical means of communication from one computer to another.

In conclusion, it should be noted that the information given in the description are examples that do not limit the scope of the present invention defined by the formula.

Claims (6)

The method of using the IoT device model (hereinafter referred to as the device) to determine anomalies in the operation of the device includes the following steps: a. define a new device; b. receive data about the device for forming a profile; in. creating a device rollup based on the profile; d. choose from the database of convolutions a convolution similar to the created convolution; e. if there is a known model, then the already known device behavior model associated with the selected convolution is used, otherwise, data is collected in the device profile to create and train the device model and then use the trained model, while using the model involves identifying anomalies in the device operation .

Images