CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional Patent Application 62/435,866, filed December 19, 2016, which is incorporated herein by reference. FIELD OF THE INVENTION

The present invention relates generally to computer network communications, and particularly to methods and apparatus for protecting against malicious access to devices over a network.

BACKGROUND

The "Internet of Things" (IoT) is a term used to refer generally to physical devices that are controlled remotely through a communication network. Some IoT devices serve as sensors and transmit signals, in addition to or instead of performing local control functions. IoT devices are most commonly controlled via the Internet, but IoT may communicate over other networks, as well. IoT devices in common use at present include cameras, alarm systems, heating and cooling systems, lighting devices (lamps), entertainment systems, such as televisions and gaming consoles, kitchen equipment, and even door-locks, as well as gateways, which connect small, local networks (such as home networks) to the Internet. While the concept of IoT holds great promise, it also opens the door to new security vulnerabilities.

IoT devices are often low-cost products, offered by a wide range of vendors (not always trusted), with weak or even non-existent security mechanisms. For example, some IoT devices, such as many type of printers, are not protected at all, while other IoT devices are protected only by a weak password, which might even be hardcoded and cannot be changed easily. The firmware of many IoT devices cannot be easily updated, which often implies that it cannot be modified to withstand newly-discovered security threats.

A number of attempts to address the security vulnerabilities of IoT devices have been described in the patent literature. For example, U.S. Patent Application Publication 2016/0212099 describes management of IoT devices through a private cloud. When an IoT device makes a request to connect to the private cloud, an identification of the IoT device is determined. The IoT device is onboarded, using the identification, for management through the private cloud. A device profile of the IoT device is generated. The flow of data to and from the IoT device is regulated through application of IoT rules of an IoT firewall according to the device profile of the IoT device. As another example, U.S. Patent Application Publication 2016/0301707 describes IoT management based on packet analysis. Data packets transmitted to and from an IoT device are obtained and analyzed using deep packet inspection to identify transaction data. An event log is generated for the IoT device from the transaction data and is used to generate a historical record for the IoT device. The event log is updated in real-time to indicate current operation of the IoT device. Abnormal behavior of the IoT device is determined using the event log and the device profile.

SUMMARY

Embodiments of the present invention that are described hereinbelow provide methods and apparatus for controlling access to devices, such as IoT devices, over a network.

There is therefore provided, in accordance with an embodiment of the invention, a method for network protection, which includes monitoring data packets transmitted to and from an IoT device over a network. Based on the monitored data packets, a set of one or more endpoints that are authorized to communicate with the IoT device via the network is identified. Among the monitored data packets, an attempt to communicate with the IoT device by an endpoint that is not a member of the identified set is detected. Responsively to detecting the attempt, a protective action is performed at a certain location in the network, between the endpoint and the IoT device, so as to mitigate unauthorized communications with the IoT device.

In some embodiments, identifying the set of the one or more endpoints includes recognizing one or more user devices that are operated by an authorized user of the IoT device.

Additionally or alternatively, identifying the set of the one or more endpoints includes recognizing one or more servers that are authorized to communicate with the IoT device. In a disclosed embodiment, at least one of the one or more servers supports an IoT service, through which an authorized user of the IoT device passes commands to the IoT device. Additionally or alternatively, recognizing the one or more servers includes identifying a server that is authorized to send firmware updates to the IoT device.

In some embodiments, identifying the set of the one or more endpoints includes assembling a list of one or more domains. In one such embodiment, assembling the list includes extracting the one or more domains from DNS queries transmitted to the network by the IoT device. Additionally or alternatively, identifying the set of the one or more endpoints includes periodically submitting queries from the guard location to a DNS server in order to retrieve IP addresses of the one or more domains. Additionally or alternatively, identifying the set of the one or more endpoints includes assembling a list of one or more IP addresses of the one or more authorized endpoints, and detecting the attempt to communicate with the IoT device by an endpoint that is not a member of the identified set includes identifying a data packet transmitted from or to an IP address that is not on the list. In one embodiment, assembling the list of the one or more IP addresses includes recognizing a user device that is operated by an authorized user of the IoT device, and retrieving a current IP address of the recognized user device.

Further additionally or alternatively, monitoring the data packets includes identifying a type of the IoT device responsively to the monitored data packets. In some embodiments, the method includes associating a name with the identified type, wherein the name is indicative of a functionality of the IoT device, and displaying the name to a user of the network or system. In one such embodiment, associating the name includes extracting a string from one or more domain names that are associated with the one or more endpoints in the set, and assigning the name responsively to the extracted string.

In one embodiment, performing the protective action includes detecting and blocking a denial-of- service attack involving the IoT device.

Additionally or alternatively, monitoring the data packets includes detecting anomalous traffic between the IoT device and the network, wherein the method includes issuing a notification of the anomalous packet traffic to an authorized user of the network or blocking the outgoing attack at devices on the paths from the corresponding IoT devices to the Internet and to the destination of the attack. In one embodiment, notifications are issued for any traffic to or from the IoT device.

Further additionally or alternatively, monitoring the data packets includes setting and applying a quality of service policy to packet traffic between the IoT device and the one or more authorized endpoints.

There is also provided, in accordance with an embodiment of the invention, apparatus for network protection, including a communications interface, which is configured to transmit and receive data packets to and from a network, and a memory. A processor is configured to monitor, via the communications interface, the data packets transmitted to and from an IoT device over the network, and based on the monitored data packets, to store in the memory a profile identifying a set of one or more endpoints that are authorized to communicate with the IoT device via the network, and to detect, among the monitored data packets, an attempt to communicate with the IoT device by an endpoint that is not a member of the identified set, and responsively to detecting the attempt, to invoke a protective action at a guard location in the network, between the endpoint and the IoT device, so as to mitigate unauthorized communications with the IoT device.

In some embodiments, the processor is configured to detect, based on the monitored data packets, a denial of service attack, and the protective action includes blocking or limiting traffic associated with the denial of service attack. Additionally or alternatively, the processor may detect, based on the monitored data packets, a distributed denial of service attack originating from plurality of IoT devices in multiple customer premises, and the protective action includes blocking or limiting traffic associated with the distributed denial of service attack.

In some embodiments, the processor is configured to monitor the data packets transmitted to and from a plurality of IoT devices concurrently and to distinguish between data packets coming from different IoT devices and to store in the memory a respective profile, identifying the authorized endpoints, for each of the IoT devices, and to invoke the protective action, based on the respective profile, so as to mitigate the unauthorized communications with each of the IoT devices.

In some embodiments, the guard location is in an access network, operated by an Internet service provider, through which the IoT devices communicates with the endpoints. Typically, the processor is configured to intercept and monitor the data packets that are transmitted through the access network to multiple customer premises where the IoT devices are deployed. Additionally and alternatively, in order to distinguish between data packets coming from different IoT devices within the same customer premises, packets are marked at the gateway of the customer premise (and/or internal tables of the gateway in the customer premise are extracted). Such marking is configured through management protocols of the corresponding gateway.

In other embodiments, the guard location is in a customer premises in which the IoT devices are located. The processor may be deployed in a gateway that connects the customer premises to a public network or in a stand-alone device in the customer premises, which communicates with a gateway that connects the customer premises to a public network.

Alternatively, the guard location is on a public wide-area network, and the data packets transmitted to and from the IoT devices are routed through the guard location.

In a disclosed embodiment, when the guard location is on a public network, the processor can be configured to cause a gateway that connects a customer premises in which the IoT devices are located to the public network to mark the data packets transmitted from the IoT devices so as to enable the processor to identify the IoT devices from which the data packets respectively originate.

There is also provided, in accordance with an embodiment of the invention, a computer software product, including a non-transitory computer-readable medium in which program instructions are stored. The instructions, when read by a programmable processor, cause the processor to monitor data packets transmitted to and from an IoT device over a network, and based on the monitored data packets, to identify a set of one or more endpoints that are authorized to communicate with the IoT device via the network, and to detect, among the monitored data packets, an attempt to communicate with the IoT device by an endpoint that is not a member of the identified set, and responsively to the detected attempt, to perform a protective action at a certain location in the network, between the endpoint and the IoT device, so as to mitigate unauthorized communications with the IoT device.

The present invention will be more fully understood from the following detailed description of the embodiments thereof, taken together with the drawings in which: BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a schematic, pictorial illustration of a system for communication with IoT devices, in accordance with an embodiment of the invention;

Fig. 2 is a block diagram that schematically illustrates a guard device, in accordance with an embodiment of the invention;

Fig. 3 is a block diagram that schematically illustrates a residential communication gateway, in accordance with an embodiment of the invention;

Fig. 4 is a flow chart that schematically illustrates a method for acquiring and applying an IoT device profile, in accordance with an embodiment of the invention; and

Fig. 5 is a flow chart that schematically illustrates a method for filtering network traffic using an IoT device profile, in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

OVERVIEW

IoT devices are commonly deployed within a local network, such as a home, small business, or enterprise network. Alternatively, some IoT device are connected directly to public networks, such as a cellular network. IoT devices communicate with and are controlled by endpoints either on the same local network or on a wide-area network, such as the public Internet, to which the local network is connected. Embodiments of the present invention are based on the realization that in order to prevent malicious exploitation, each IoT device should be allowed to communicate only with a small, specific set of authorized endpoints. Depending on the IoT device, these authorized endpoints can be user devices, such as the cellular telephones of authorized users; or servers, such as a cloud server that hosts an IoT service and relays requests to the IoT device from its users; or servers that provide other specific services, such as the Domain Name System (DNS), time services, or digital media content. Therefore, it should be possible to protect against most attempts to gain unauthorized access to an IoT device by defining a device profile - containing a specific, limited "whitelist" of endpoints that are authorized to communicate with the IoT device - and blocking or alerting on traffic between the IoT device and all endpoints that deviate from the profile.

Based on this realization, embodiments of the present invention provide methods and apparatus for detecting and filtering unauthorized traffic to and from IoT devices. This approach does not require or rely upon any sort of security mechanism within protected IoT devices. Rather, the disclosed techniques complement and can be used in conjunction with existing security mechanisms, such as password authentication, as well as with other methods of cyber- attack detection that are known in the art, such as signature-based detection. Because the present approach is whitelist-based, rather than blacklist- or signature -based, it can also protect against zero-day attacks in ways that existing mechanisms cannot.

The present embodiments secure IoT devices not only against unauthorized attempts to control or collect information from the IoT device, but also against Distributed Denial-of-Service (DDoS) attacks, i.e., attempts to interfere with legitimate users by choking the available bandwidth to or from the IoT device. These embodiments are also effective in preventing and protecting against malicious traffic transmitted concurrently by IoT devices on multiple customer premises (such as in botnet attacks). Upon detecting global anomalies in traffic coming from multiple premises, which may originate from a DDoS attack, some embodiments of the present invention filter or otherwise limit all traffic that corresponds to the abnormal behavior and thus secure Internet service providers against this sort of excessive malicious traffic.

In the disclosed embodiments, protective apparatus, referred to herein as a guard device, monitors data packets transmitted to and from multiple IoT devices over a network. For each IoT device, based on the monitored data packets, the guard device identifies a set of one or more endpoints that are authorized to communicate with the IoT device via the network. Thereafter, when the guard device detects an attempt to communicate with the IoT device by an endpoint that is not a member of the identified set, it invokes a protective action at a certain location in the network, between the endpoint and the IoT device, and thus mitigates unauthorized communications with the IoT device. This location is referred to herein as a "guard location," which may or may not be collocated with the guard device. The protective action may be performed by the guard device itself or by a packet filter deployed by the guard device at another suitable location such as router or a firewall.

In some embodiments of the present invention, the set of authorized endpoints is identified by a profile, which the guard device automatically acquires and stores for each IoT device or device type. The profile is typically acquired by observing the traffic to and from the IoT device, meaning that profile acquisition does not require active involvement by the IoT manufacturer or the user (although such involvement is possible in some cases). Once the profile of a given device has been acquired in this fashion for a given type of IoT device, it can be reused in other locations where IoT devices of the same type are deployed. Thus, in many cases, when a new IoT device joins a network and its type was learned in the past, the guard device can identify the device type, for example based on the observed traffic, and then apply an existing profile to the IoT device, as opposed to developing a new profile autonomously.

The profile for each IoT device can specify the endpoints with which the IoT device may legitimately communicate in a variety of ways:

• By a set of domain names, such as domain names of servers and corresponding cloud services through which users communicate with their IoT devices. These domain names are periodically resolved to Internet Protocol (IP) addresses using queries to the Domain Name System (DNS).

• By identifiers of specific user devices. These identifiers can be resolved to IP addresses using proprietary message exchanges between an application installed on the user devices and the guard device.

• By explicit (hard-coded) IP addresses of the authorized endpoints.

In addition, for further enhancement of security of the IoT device, the profile may include a specification of legitimate traffic patterns, in terms of bandwidth, protocols, etc. The guard device can then take protective action not only against unauthorized access attempts, but also against deviant traffic patterns in general, for example by sending a notification to a user or system operator when a traffic anomaly (or, in some cases, any traffic) is detected. Such deviant traffic patterns can be indicative either of an attempted attack or of a failure in the local network or in the IoT device itself. Additionally or alternatively, the profile can specify a Quality of Service (QoS) policy, which can be applied by the guard device in order to ensure that each IoT device receives no more than its allocated share of network resources.

An added benefit of the profiling provided by embodiments of the present invention is that it enhances the visibility of IoT devices on a network, thus enabling users and system and network operators to more readily and precisely identify the IoT devices that have been deployed in customer premises. For this purpose, in some embodiments, the guard device assigns a descriptive name to each profile, automatically or with user assistance, which can then be displayed to and/or queried by authorized users and system operators. The name can be indicative of the functionality of the IoT device.

A challenge in protecting against unauthorized access to an IoT device on a local area network (LAN), when the guard device is deployed outside the local network, is that packet traffic to and from such devices can be difficult to distinguish, because the IP addresses of the packets are modified by network address translation (NAT) at a gateway or other router that connects the LAN to the Internet. The IP address of the IoT device can also change due to application of the Dynamic Host Configuration Protocol (DHCP) within the LAN. In response to this challenge, some embodiments of the present invention provide methods to identify, at an upstream network device, such as a router, packets transmitted on connections to and from specific IoT devices. This identification is made possible by marking packets originating from different IoT devices with different bit sequences in a field of the packet headers, for example, by setting different values in the Type of Service (ToS) field of the IP header for packets coming from different Medium Access Control (MAC) addresses. This sort of marking can be carried out by a network element that resides in the same LAN as the IoT device, such as by the gateway connecting the LAN to the Internet, typically under instructions from the guard device.

In most deployment scenarios, IoT devices are connected (by wireless or wired connection) to a LAN in a customer premises and access the Internet via a suitable gateway router. The embodiments shown in the figures and described in detail hereinbelow are therefore directed to this sort of deployment model. The principles of the present invention, however, are not limited to this sort of scenario, and can similarly be applied in protecting other sorts of deployments. For example, a guard device on the access network of an Internet service provider (ISP) can protect not only customer premises, but also IoT devices that connect directly to a wide-area network, such as street cameras, drones, and other devices that connect to the ISP directly through a cellular network. SYSTEM DESCRIPTION

Fig. 1 is a schematic, pictorial illustration of a system 20 for communication with IoT devices, in accordance with an embodiment of the invention. In the pictured example, the IoT devices are deployed in a customer premises 22, such as a residence, and include a video camera 24, a door lock 26, a cooking stove 28, and an air conditioner 30. These IoT devices are shown solely by way of example, however, and the techniques and apparatus that are described herein may equally be used in controlling substantially any types of IoT devices that are known in the art. Furthermore, although Fig. 1, for the sake of simplicity, shows only a single customer premises, in practice system 20 will typically comprise many customer premises, all protected concurrently by the present techniques and apparatus.

IoT devices 24, 26, 28, 30, connect over a LAN (which is shown as a wireless LAN in Fig. 1, but can include any other sort of LAN-based communication) to a communication gateway 32, which in turn connects to a public wide-area network 38, such as the Internet. Authorized users 34, 36 communicate with and access these IoT devices by transmitting and receiving data packets over network 38 or 46 from and to respective user devices 40 and 44. Additionally or alternatively, users within customer premises 22 can communicate with the IoT devices over the LAN. In Fig. 1, user devices 40 and 44 are shown as mobile telephones, but other sorts of mobile and fixed user devices may be applied in similar fashion.

Depending on the IoT device and its setup configuration, users may in some cases communicate directly with the IoT device, as illustrated by telephone 44. In this direct mode of communications, the IoT device general functions as a server, which receives and responds to requests from the user device.

In other cases, users communicate with IoT devices indirectly, via an intermediate server 42, such as a cloud IoT service, as exemplified by device 40. In this case, an application running on device 40 will typically authenticate the user and then submit requests to server 42, which relays the requests to the target IoT device. Response from the IoT device are similarly directed to server 42, which may then send updates to device 40. IoT devices 24, 26, 28, 30, ..., may also communicate with other servers on network 38, such as with a DNS server 58 and with servers operated by manufacturers of the devices for the purpose of checking for and receiving firmware updates (not shown in the figures).

In the pictured example, gateway 32 connects customer premises 22 to a router 48 in an access network 46, which is operated by an ISP. Router 48 is configured to send copies of or divert traffic to a guard device 54, for the purpose of detecting and mitigating attempts at unauthorized access to devices in customer premises 22. Guard device 54 can be used in this configuration in providing a value-added service from the ISP to customers, in order to protect IoT device in customer premises 22 from unauthorized access. Router 48 may divert all traffic (or copies of all traffic) to guard device 54, or only traffic meeting certain criteria, in terms of protocol type, for example. In an alternative embodiment, not shown in the figures, guard device 54 is deployed in line with router 48. In the present description and in the claims, guard device 54, as well as other guard devices described herein, is considered to "intercept" data packets in all such configurations, regardless of whether the guard device is deployed in line or whether the packets, or copies of the packets, are diverted to the guard device by a router or other switch, and regardless of whether the guard device receives all traffic of interest or only a sampling of the traffic.

Alternatively or additionally, some or all of the functions of guard device 54 may be implemented within customer premises 22 (as shown in Fig. 3, for example), or by a guard server 56 on public network 38, rather than within access network 46. In this latter sort of distributed deployment scenario, guard device 54 can communicate with guard server 56 and/or with customer premises equipment, such as gateway 32, in order to coordinate guard operations. These communications can use protocols that are known in the art, such as the TR-069 and TR- 098 protocols promulgated by the Broadband Forum, or the Simple Network Management Protocol (SNMP), or alternatively using a suitable proprietary protocol.

In another embodiment guard server 56 is implemented as a cloud-based service, and traffic is diverted or tunneled to guard server 56 from one of or more of the routers along the path to customer premises 22. In this case, router 48 or gateway 32 can be configured to discard all traffic directed to IoT devices 24, 26, 28, 30, unless it comes from the cloud-based service. The same cloud-based service can handle traffic of multiple subscribers and can simultaneously serve several branches of an enterprise.

The description that follows will focus on the operations carried out by guard device 54 in inhibiting unauthorized access to IoT devices 24, 26, 28, 30, .... Guard device 54 may be dedicated to this particular sort of functionality, or it may carry out additional functions, particularly protective functions. These latter functions, however, are beyond the scope of the present description. Guard device 54 may comprise a dedicated hardware unit, or it may alternative be implemented as a function of a general-purpose network appliance, for example in a network function virtualization (NFV) environment, as is known in the art. As explained earlier, guard device 54 acquires and maintains a respective profile for each IoT devices 24, 26, 28, 30, identifying the endpoints that are authorized to communicate with the IoT device, such as user device 44 and/or server 42. Gateway 32 itself may also be regarded as an IoT device and protected by guard device 54 in similar fashion. In general, the profile of each IoT device will identify a different set of endpoints, although there may be overlap among the sets. Some of the endpoints, such as server 42, are typically identified in the profile by a domain name. In order to recognize traffic originating from or going to server 42, guard device 54 periodically queries a DNS server, which returns the current IP address of the server, and guard device 54 adds this address to its current whitelist. (Although only the single DNS server 58 is shown in Fig. 1 for the sake of simplicity, in practice guard device 54 may communicate with a different, secure DNS server, as described further hereinbelow, which may be located on access network 46.) Additionally or alternatively, guard device 54 may extract current IP addresses from DNS requests and replies sent from and to the monitored IoT devices.

In the scenario that is shown in Fig. 1, an unauthorized user 50 attempts to access one of IoT devices 24, 26, 28, 30, in customer premises 22, by means of an unauthorized endpoint 52, such as a computer. In this case, guard device 54 will receive an incoming packet from endpoint 52 with a source IP address that is not on the current whitelist. Upon detecting such a packet, guard device 54 will invoke a protective action at a certain guard location, for example in router 48 or gateway 32, in order to mitigate unauthorized communications between endpoint 52 and IoT devices 24, 26, 28, 30, .... Typically, the protective action will involve blocking this unauthorized traffic and/or notifying an authorized user of the attempted communication. In this latter case, the authorized user may be prompted to approve the communication between endpoint 52 and a given IoT device, for example so that a new endpoint can be added, if desired, to the set of authorized endpoints of the IoT device.

Fig. 2 is a block diagram that schematically shows details of guard device 54, in accordance with an embodiment of the invention. Guard device 54 comprises a processor 60, which is connected to a network by a communications interface 62. In the pictured example, interface 62 connects the guard device to access network 46, but the guard device may alternatively be connected to a LAN or Internet cloud. Typically, communications interface comprises one or more network ports (not shown), comprising suitable physical-layer (PHY) and MAC interfaces, as are known in the art. Processor 60 typically comprises a software-driven, programmable processing device, such as a general-purpose central processing unit (CPU) or a multi-core, dedicated network processor, for example. Additionally, processor 60 may comprise one or more hardware accelerators to speed up the execution of specific processing operations. Processor 60 is coupled to a memory 64, which typically comprises both high-speed, volatile random-access memory (RAM) and non-volatile storage memory.

Processor 60 runs software 66, which causes guard device 54 to carry out the functions that are described herein. Software 66 may be downloaded to processor 60 in electronic form, for example over a network. Additionally or alternatively, software 66 may be provided and/or stored on a tangible, non-transitory computer-readable medium, such as optical, magnetic, or electronic memory media.

Software 66 comprises two major components: a control plane 68 and a data plane 70. In the pictured embodiment, both the control plane and the data plane run on the same guard device 54, but alternatively these components may run on different network elements or may be distributed among multiple network elements. Data plane 70 is responsible for detection and/or enforcement of authorized and unauthorized connections to IoT devices 24, 26, 28, 30, by monitoring the traffic to and from the IoT devices and/or filtering the traffic as necessary using a set of profile rules 72. Control plane 68 controls the data plane and configures it as necessary, including retrieving the IP addresses of the authorized endpoints and managing the data plane.

Data plane 70 monitors and detects unauthorized access attempts to IoT devices using profile rules 72 and initiates protective actions in response to detecting such attempts. Such protective actions can include, for example proactively applying appropriate filters to mitigate traffic when an unauthorized access attempt is detected. The profile rules contain the list of authorized endpoints per IoT device. Data packets received by communication interface 62 are matched with these profile rules, and any deviation from these rules triggers a protective action.

The monitoring, detection, and protective functions of data plane 70 can use a variety of technologies that are known in the art, depending on the architecture and network elements carrying out these functions. For example, in a software-defined network (SDN) architecture, protocols such OpenFlow can be used to capture packets of possible interest as the packets traverse an SDN-enabled switch, with or without port mirroring to the data plane of the guard device. If the protective action taken by data plane 70 is to block traffic, control plane 68 can use TR-069 or another suitable configuration protocol to block unauthorized accesses, for example at gateway 32. Alternatively or additionally, control plane 68 can configure an access control list (ACL) on router 48 and/or any of the other routers in system 20 in order to block the unauthorized accesses as needed. The above ACL and filtering functions can be configured for various actions, including not only dropping packets, but also controlling QoS (for example, in terms of allocated bandwidth) to different IoT devices.

As explained earlier, profile rules 72 for each IoT device 24, 26, 28, 30, typically detect any unauthorized attempts to access the IoT device, as well as invoking mitigation rules to block unauthorized access by applying appropriate filters, for example at gateway 32 and/or router 48. To properly configure these profile rules, control plane 68 builds and maintains a database 74 in memory 64, for example, containing a respective profile for each IoT device. Additionally or alternatively, database 74 can be distributed and shared among multiple guard devices at different locations within system 20. The profile identifies the endpoints that are on the "whitelist" for this IoT device. In some embodiments, control plane 68 assembles the profiles by monitoring DNS traffic to and from the IoT devices. These DNS monitoring techniques are described in greater detail hereinbelow.

As noted earlier, each profile in database 74 can contain some or all of the following data:

a) A list of domains of authorized servers with which the IoT device is authorized to communicate. From this list the corresponding specific, authorized IP addresses are retrieved (typically using DNS queries),

b) Identifiers of the authorized user devices that are authorized to communicate directly with the IoT device.

c) A list of hard-coded IP addresses of authorized endpoints.

d) The domain or IP address from which the IoT device may carry out firmware updates.

e) Statistics of traffic to and from the IoT device for purposes of identifying abnormal behavior. f) The name of the IoT device type.

In addition to the packet filtering functions described above, gateway 32 can also mark IoT packets, if needed, in order to assist parts of the data plane that are implemented outside customer premises 22 in recognizing these packets. For example, control plane 68 can configure a component of data plane 70 running on a device (such as gateway 32) inside customer premises 22 to mark packets originating from IoT devices 24, 26, 28, 30, such that packets from different devices receive different markings. These markings enable other components of data plane 70, running on guard device 54 or server 56, to identify the origin IoT device of each of the packets, notwithstanding changes in the source IP address of these packets due to NAT. For this purpose, control plane 68 can configure gateway 32 to set specified ToS bits in the header of each such packet according to the source MAC address of the device in customer premises 22, and can inform the elements of data plane 70 that are outside the customer premises of the settings. Alternatively, gateway 32 can be instructed to map different MAC addresses to different IP port numbers. These configuration instructions can be conveyed to gateway 32, for example, using TR-069 and/or TR-098, as mentioned above, or using SNMP or other control protocols that are known in the art.

As an alternative to packet marking, control plane 68 may periodically retrieve the NAT table from gateway 32 and pass the relevant IP addresses and port numbers (for example, TCP and UDP port numbers) of IoT devices 24, 26, 28, 30, to components of data plane 70 running outside customer premises 22, such as guard device 54 and server 56. The NAT table may be retrieved either by installing suitable software on gateway 32, which causes the gateway to periodically transmit its NAT table to guard device 54, for example, or by querying an application programming interface (API) of the gateway, if available.

Components of data plane 70 outside customer premises 22 use the NAT table or packet markings (such as ToS values) in identifying and filtering traffic from and to IoT devices 24, 26, 28, 30, ..., while distinguishing this traffic from other traffic on the network. When a "protected network" contains only a single IoT device (for example, an IoT device with a cellular interface that connects directly to a cellular network), packet marking is greatly simplified.

Fig. 3 is a block diagram that schematically illustrates a residential communication gateway 32, in accordance with another embodiment of the invention. Fig. 3 specifically illustrates components of gateway 32 that can be used, either in conjunction with guard device 54 and/or server 56, or independently, in protecting IoT devices 24, 26, 28, 30, against unauthorized access.

Gateway 32 typically comprises a broadband modem 82, such as a digital subscriber line (DSL) or cable modem, which communicates with access network 46. Alternatively, modem 82 comprises a mobile broadband modem, which connects to a wireless ISP via a cellular network. A router 84 directs incoming and outgoing packet traffic to and from both IoT devices and other customer equipment, such as a computer 80, for example via a wireless access point 86. Gateway 32 also performs other routing related functions, such as a DHCP function 88 and a NAT function 90, as are known in the art.

In the embodiment shown in Fig. 3, gateway 32 comprises a processor 92, such as a

CPU, which is programmed to carry out functions of a guard device in protecting IoT devices 24, 26, 28, 30, ..., in customer premises 22. Processor 92 (which may be a virtual component within gateway 32) may also perform other functions of the gateway, such as DHCP and/or NAT, or it may be dedicated to the IoT guard functionality. A memory 94 of gateway 32 can be used to store elements of data plane 70, such as profile rules 72, as described above and shown in Fig. 2, which processor 92 applies in filtering traffic to and from the IoT devices in customer premises 22.

Processor 92 can also implement control plane 68, or it can receive control instructions from guard device 54 or server 56. In this latter case, the guard device or server may, for example, assemble profiles for IoT devices of certain types and then distribute the profiles to gateway 32 in customer premises 22 and similarly to other customer premises. To conserve memory 94, it is desirable that gateway 32 receive and store profile information only with respect to the particular types of IoT devices that are actually deployed in the corresponding customer premises.

Additionally or alternatively, parts of control plane 68 and/or data plane 70 can be implemented on a dedicated, stand-alone IoT guard device 96 within customer premises 22.

This solution is useful particularly in cases in which an existing gateway does not have the necessary resources or programmability to carry out the required functions. IoT guard device 96 can be useful in monitoring the traffic within customer premises 22, as well, so that protective action can be taken, if necessary, against communications between IoT devices 24, 26, 28, 30, and unauthorized endpoints within the customer premises. IoT guard device 96 is connected to gateway 32 by a wired or wireless link and comprises a suitable processor and memory, with software for offloading some or all of the guard functions described above. Router 84 can be configured in this case to divert either IoT traffic or all traffic, or a copy of such traffic, to IoT guard device 96 for handling.

CREATING THE DATABASE OF IOT PROFILES

Fig. 4 is a flow chart that schematically illustrates a method for acquiring and applying an IoT device profile, in accordance with an embodiment of the invention. For the sake of convenience and clarity, the method is described hereinbelow with reference to the elements of system 20, and assuming that guard device 54 in ISP access network 46, (as illustrated in Figs. 1 and 2) carries out most of the steps of the method. Alternatively, however, the principles of this method may be applied, mutatis mutandis, in other guard configurations, such as by a guard device in customer premises 22 (as shown in Fig. 3) or by guard server 56, or by distribution of guard functionality among such devices and servers.

The method of Fig. 4 is initiated when guard device 54 detects that a new IoT device has been installed in customer premises 22, at a new device detection step 100. Guard device is able to distinguish between an IoT device and other computing devices (such as mobile phones, tablets, and desktop computers) by extracting information from the packet traffic. Such information includes, for example, device identification information, such as MAC address and/or host identification, and traffic patterns, such as numbers of DNS queries and the number of different domains to which the queries are directed, or the number of different IP addresses with which the device is communicating. (Most IoT devices will generally issue only a small number of DNS queries to a limited set of domains.)

Whenever guard device 54 detects a new IoT device, it checks whether the profile for this device is already known, at a profile checking step 101. In many cases, guard device 54 will be able to identify the IoT device as being of a certain, known type, for which a profile already exists in memory 64. For example, the device type can be identified on the basis of its MAC address, along with the DNS queries that the IoT device issues initially, as well as on the basis of explicit user input. Upon ascertaining that the new IoT device belongs to an existing type, guard device 54 can acquire the necessary profile simply by reading and applying the preexisting profile.

Otherwise, guard device 54 acquires a new profile at step 102. The implementation of step 102 that is described below assumes that guard device 54 is able to identify traffic to and from the IoT device in question, for example based on marking of the packets by gateway 32, as described above. Alternatively or additionally, profile acquisition can be performed under controlled conditions, in which traffic to and from the IoT device in question is isolated from other traffic, and/or using information provided by the device manufacturer. In any case, it is assumed that during the step 102, the IoT device is not compromised, meaning that the domains and addresses with which the IoT device communicates belong to authorized endpoints. When one or a small number of IoT devices of a given type exhibit deviant behavior at this stage, in terms of communicating with endpoints with which other IoT devices of the same type do not communicate, guard device 54 may identify the deviant devices and exclude their endpoints from the profile.

After an existing IoT device has performed a firmware update from the known, authorized firmware update address for this device, the IoT device is also treated as new, implying that a new IoT profile should be also obtained in this case and used to update the existing profile. (A firmware update from any other address will generally be treated as suspicious until proven otherwise.) The mode of profile acquisition at step 102 depends upon whether the IoT device in question is accessed by users directly (as in the case of user device 44 in Fig. 1) or via a cloud IoT service (such as server 42). In some cases, the IoT device may enable both types of user access methods, and the profile will then include both types of access methods. The description that follows will first cover the mode of profile acquisition in the case of IoT access via servers on network 38, and then the mode of acquisition for direct user device control.

Profile acquisition for cloud services

The profile acquired at step 102 for IoT devices controlled by a cloud service will typically include the corresponding domains of the services on servers 42. In addition, the profile can include domains of other services that the IoT device accesses, such as a network time protocol (NTP) server, as well as of the server that is designated by the IoT device manufacturer for use in firmware updates. These domains are maintained in the IoT device profile, rather than just listing the IP addresses of the corresponding endpoints, because the IP addresses are more likely to change over time, and the same domain may be associated with different IP addresses in different geographical areas. In some cases, however, IP addresses may be hard-coded in the IoT device and will be stored as such in the device profile. For some types of IoT devices, the domains and/or hard-coded IP addresses for a given type of IoT device will also vary geographically, in which case a separate profile is acquired for each geographical territory.

In order to acquire a profile of a new IoT device at step 102, guard device 54 intercepts and analyzes DNS queries issued by the IoT device to DNS server 58. In many cases, however, the DNS queries from the IoT device are issued to a DNS resolver in gateway 32 or other customer premises equipment. The gateway then issues a new query (in which the gateway is the source) to the DNS server. This DNS configuration makes it difficult for guard device 54 outside customer premises to associate the DNS query with the IoT device issuing the query. In order to resolve this problem, the DNS resolver can be configured during step 102 to be a DNS server outside customer premises 22, for example using DHCP to change the DNS server configuration. When DHCP function 88 is implemented by gateway 32, as shown in Fig. 3, the DHCP server within gateway 32 can be configured with the desired DNS server using the TR- 069 protocol or other router management protocol.

Profile acquisition step 102 begins monitoring the traffic from a new IoT device only after the device is detected at step 100. When such detection is carried out automatically by guard device 54, step 102 may begin only after the IoT device has been active for some time. Therefore, guard device 54 is likely to have missed some initial DNS queries and responses and might obtain only a partial list of domain names. As a result, the guard device may record certain IP addresses with which the IoT device communicates as hard-coded addresses in the IoT device profile, even though they were actually obtained through a DNS response. This problem can be exacerbated by the fact that some IoT devices perform their DNS queries sporadically and may use an IP address obtained from a DNS response for days, without performing another DNS query.

Embodiments of the present invention provide two possible solutions to handle this problem: One solution operates in a passive mode, in which guard device 54 monitors the IoT traffic in a systematic manner designed to discover all relevant domains without interfering with normal operation of gateway 32 and IoT devices that are in operation. Alternatively, in an active mode, guard device triggers DNS queries from IoT devices, for example by invoking a reboot of gateway 32 or blocking certain connections between gateway 32 and network 38.

Passive mode

The passive mode works in two successive epochs: During the first epoch, guard device

54 listens to traffic routed from and to the IoT device in question within customer premises 22 and records all DNS requests and DNS responses without performing any action. The length of this first epoch is fixed by the system operator by setting a system parameter L _s tart. In the second epoch, whose length is at least Lmonitor (also configured by the system operator), guard device 54 continues to keep track of DNS requests and DNS responses, and, in addition, it checks the IP address of each endpoint that communicates with the IoT device against the recorded DNS responses. The guard device adds an IP address to the IoT device profile, as a hard-coded address, only if the address has not appeared in any DNS response obtained in either the first or the second epoch. The second epoch continues until the profile has stabilized, meaning that there has been no change in the lists of both the domains and the IP addresses in the profile for at least a time L _sta bie, wherein L _sta bie is again a parameter set by the system operator. The three parameters of the passive acquisition algorithm (Lstart, Lmonitor and L _sta bie) are typically set to values of one to several days. The acquired IP addresses and domains can undergo verification tests to ensure that they are not bogus or malicious destination (for example by finding abnormal geolocation of IP addresses or domains).

Table I below shows the passive profile acquisition mode in detail: TABLE I - PASSIVE PROFILE ACQUISITION

Initially:

start_time = gettimeofday(), stable_time=gettimeofday()

D(X) = [ ] // set of domain names for device X

ID(X) = [ ] // set of the IP addresses received in DNS responses for domains in D(X) I(X) = [ ] // set of hard-coded IP addresses for device X

epoch = 1

Upon receiving packet p from/to device X:

// can be determined by ToS bits or other methods of packet marking If epoch == 1 and gettimeofday()-start_time > L _st art:

epoch = 2

stable_time = gettimeofday()

If p.src_port == 53 or p.dst_port == 53: // DNS packet

if p.dns.OPCODE == QUERY: // DNS query

if p.dns.QNAME not in D(X):

D(X).append(p.dns.QNAME)

if epoch == 2:

stable_time = gettimeofday()

else: // DNS response

for each ip in p.dns.RDATA:

ID(X).append(ip)

if ip in l(X):

I(X).remove(ip) else: // regular IP packet

if p.src_address == ip(X): // ip(X) is the ip address of device X

address = p.dst_address

else:

address = p.src_address

if address not in I(X) and address not in ID(X) and epoch==2: I(X).append(address)

stable_time=gettimeodfay() if gettimeofday()-start_time>L _s tart+Lmonitor and gettimeofday()-stable_time>L _s tabie:

return (D(X),I(X))

// D(X) is the list of profile's domains and I(X) is the list of the profile's

hard-coded IPs.

Active mode

The active mode works similarly to the passive mode, albeit without its first epoch, thus potentially reducing the time until the profile is acquired by L _s tart. The active mode is initiated by triggering the IoT device to issue all of its DNS queries from scratch, for example by rebooting gateway 32 or otherwise disconnecting the IoT device from network 38 for a short time. Alternatively (and less disruptively), guard device 54 may briefly block all outgoing connections of the IoT device whose profile is to be acquired, so that the IoT device will assume its endpoints have failed and will issue DNS queries to recover them.

In addition to the user control domain (or domains), the IoT device profile acquired at step 102 typically includes a firmware domain, from which the IoT device receives firmware updates. Accurate acquisition of the firmware domain is important in ensuring that firmware updates are download only from authorized domains, as well as in detecting firmware update events, which may change other records in the IoT device profile. Guard device 54 can identify firmware updates, for example, by observing characteristic traffic behavior, such as consumption of high bandwidth on the downlink to IoT devices from addresses that are not part of the user control profile. Additionally or alternatively, firmware updates can sometimes be identified on the basis of their domain names, which often include certain characteristic strings, such as "update" or "static."

Although the description above assumed that the same IoT profile could be used for many IoT devices of the same type, in various different customer premises, some IoT devices allow individual users to add services (and thus endpoints), for example to connect smart audio speakers to different streaming services. In such cases, step 102 will result in acquisition of different profiles for the same IoT device in different customer premises, although some endpoints will be common to all instances of the IoT device. To address these cases, guard device 54 may acquire an IoT profile that includes all legitimate services that the IoT device can access, for example by applying the techniques described above to a group of user premises or by offline learning in a testing laboratory. Users may be prompted to select the actual services that their IoT device is permitted to access. This model may be extended to IoT devices, such as smart televisions, that are capable of running different applications, in which case a specific profile can be acquired for each application.

Profile acquisition for directly-connected user devices

For direct connections between user devices, such as device 44 (Fig. 1), and an IoT device, guard device 54 identifies authorized endpoints on the basis of a user identification component installed on the user device, such as the telephone number of a mobile phone. The IoT device profile will then include this identification components as a sort of private "domain" for the user, from which the current IP address of the authorized endpoint can be retrieved. These private "domains," however, cannot generally be resolved using DNS queries. Therefore, in some embodiments, software is installed on device 44 and periodically communicates with guard device 54 in order to inform the guard device of the current IP address of device 44 (for example, every few minutes or upon a change in the IP address of the device). This functionality is useful in handling the frequent changes in the IP addresses of mobile devices that occur as users move from one network or access point to another. Details of this process are described hereinbelow.

In the present embodiments, in order to enable secure direct access to IoT devices, user 36 installs IoT device control application software on device 44. The primary object of this application is to enable guard device 54 to securely resolve the IP address of device 44. For this purpose, the application provides an identification mechanism to verify that the user is authorized to access the IoT device, and thus ensure that the current IP address of the user device is legitimate. Authentication mechanisms that are known in the art, such as digital signatures, can be used for this latter purpose. The digital signature itself can be of any suitable form, such as a cryptographic signature computed over packet data, a cookie in headers of packets transmitted by the user device, data and/or metadata in the packets that verifies the user with high probability, or any other method that cannot be forged by a malicious user. To ensure that only authorized user devices can be associated with a given IoT device, the software may allow installation on the user device to be completed only upon verifying that the user device is actually connected to the customer premises network, or using a password obtained from the ISP, or using multifactor authentication (MFA) mechanisms, or combinations of such methods. Alternatively or additionally, other techniques for user authentication can be used, even when identification software is not installed on user device 44. For example, upon detecting an attempt to access a given IoT device, guard device 54 can send a notification to the authorized user (in the form of a text message to the user's mobile phone, for instance) that a connection to the IoT device has been attempted. The user may then approve or disapprove the connection attempt (for instance by sending an appropriate text message in reply).

Naming IoT profiles

Upon acquiring a new IoT profile at step 102, guard device 54 can automatically associate a name with the profile, at an IoT device naming step 104. The name is typically indicative of the functionality of the IoT device and/or is based on names that are commonly used in the industry. The device name can be displayed subsequently to users and ISPs in order to enable them to see easily which IoT devices are installed and/or operating in a given customer premises 22. This approach is in contrast to IoT devices that are known in the art, in which identifiers are not generally representative of the functionality of the device.

Upon identifying a new IoT device, guard device 54 can automatically derive a representative name for the device at step 104, typically combining information from several sources in deriving the name. One source is information that can be extracted from the local network in customer premises 22, such as the MAC address of the IoT device and local configuration protocols. Additionally or alternatively, users can be prompted to name their IoT devices, and the characteristic traffic pattern of an IoT device can be used to assign it to a certain class, such as cameras, sensors, or switches.

Further additionally or alternatively, guard device 54 can use one or more strings extracted from domain names in the IoT device profile in deriving the profile name. For this purpose, guard device 54 first filters from the IoT profile the domain names of generic services that are common to many or most of the IoTs (and thus appear in many different device profiles), such as NTP servers. Guard device 54 checks the remaining, device-specific domain names for a recurrent substring and matches this substring against known IoT device names (for example, using a search engine or by scanning sites that sell IoT devices). Additionally or alternatively, the guard device can extract substrings from the firmware-update domain or from payload traffic. The process of name assignment can be performed automatically or with human help.

Retrieving IP addresses using the profile

Once the IoT profile has been acquired at step 102 (and possibly named at step 104), guard device 54 adds the profile to database 74, at a profile installation step 106. Known profiles found at step 101 are likewise installed at step 106. The profiles can then be used in monitoring traffic to and from the IoT device in question. For this purpose, guard device 54 periodically looks up the IP addresses corresponding to the domains in the profile, at an IP lookup step 108. In addition, when user devices are allowed to connect directly to an IoT device, guard device 54 periodically checks and updates the IP addresses of authorized user devices based on the device identifiers. These periodic updates are needed, except in the case of hard-coded IP addresses, because IP addresses of both user devices (such as device 44) and cloud services (such as server 42) may change over time.

To check the IP addresses corresponding to domains in the IoT device profile, guard device 54 obtains and reads DNS responses (from server 58, for example) to DNS queries made with respect to these domains. One way for the guard device to obtain the DNS responses is to passively intercept DNS queries from the IoT device, verify that the queries related to domains in the profile, and then intercept and retrieve the IP addresses from the DNS responses. Alternatively or additionally, guard device 54 itself may actively issue its own DNS queries for the domains in the profile, typically at short intervals, for example every few minutes, in order to keep up with changes of IP addresses. Furthermore, upon intercepting a packet transmitted from an IoT device to an unidentified endpoint, guard device 54 may immediately trigger DNS queries of all domains in the profile. The guard device is thus able to verify that the IP addresses have not changed since the last active DNS query and to eliminate false positive alerts that might otherwise result.

In order to avoid learning malicious IP addresses due to DNS poisoning, guard device 54 may also store a common, permitted address space in the profile (for each geographical region) or perform its DNS queries to a secure DNS server (such as an OpenDNS or Quad9 server) that is immune to such attacks, as noted earlier.

For directly-connected user devices, guard device 54 can use the identification software that has been installed on these devices, as described above, in checking and updating the respective IP addresses. This software periodically sends information to guard device 54 that includes the signature used to verify the user device identity and the current IP address of the user device. Guard device 54 saves these addresses in the IoT device profile for the corresponding customer premises 22.

The information collected by guard device 54 with respect to domains and user devices in the profile of an IoT device can optionally also include other information for storage in the profile. For example, the guard device may store information about usage patterns, such as the times at which a user has run the application that controls the IoT device in question. Guard device 54 can use this information in verifying traffic patterns, for example, in correlating between the peak of traffic from a camera and opening of the application on the user device. This sort of information, together with the current endpoint IP, can be sent either periodically, or every time the user device changes its IP address, or only before initiating a request to the IoT device.

USING PROFILES TO GUARD IOT DEVICES

Fig. 5 is a flow chart that schematically illustrates a method for filtering network traffic using an IoT device profile, in accordance with an embodiment of the invention. After acquiring current IP addresses of authorized endpoints, at step 108, control plane 68 of guard device 54 installs profile rules 72 in data plane 70 (Fig. 2), in order to detect attempts at communication between unauthorized endpoints and IoT devices 24, 26, 28, 30, at a rule installation step 110.

When a deviation from profile-rules 72 is detected, filters, which either block, limit or alert upon unauthorized traffic, can be installed at any suitable location in system 20, such as on router 48, gateway 32, guard server 56, or on guard device 54 itself. Data plane 70 detects and tracks connections made to each protected IoT device, at a connection tracking step 112.

Using profile rules 72, data plane 70 identifies traffic between unauthorized endpoints, such as endpoint 52, and protected IoT devices, at a traffic identification step 114. When unauthorized traffic is not detected at this stage, the guard device may log the traffic in order to assemble a statistical profile of normal traffic patterns, at a traffic logging step 115. This statistical profile may later be applied in detecting anomalous traffic patterns.

When unauthorized traffic is detected at step 114, data plane 70 may be configured to take various sorts of protective action. For example, when the threat level of malicious activity is believed to be low, profile rules 72 can be set simply to log and distribute information with regard to detected attempts at unauthorized access, at a logging step 116. Guard device 54 may send this log information to an authorized user of this customer premises 22 and/or to the ISP.

The user or the ISP can then decide on further actions, which can include switching to mitigation mode, at a mitigation step 118.

Additionally or alternatively, guard device 54 may autonomously invoke mitigation and move on to step 118, for example upon detecting a potentially severe, anomalous access pattern.

For instance, if a certain IoT device type causes alerts in several customer premises at the same time, or if the same unauthorized endpoint attempts to communicate with many IoT devices type at the same time, guard device 54 may conclude that an attack, such as a botnet attack, is in progress. In such cases, guard device 54 may also inform the IoT manufacturer of a possible security breach in its products. Control plane 68 of guard device 54 may provide a trusted cloud interface through which vendors can receive and respond to reports of such breaches and verify the profiles of their products.

When mitigation is invoked at step 118, control plane 68 can decide to set one or more filters to mitigate the unauthorized traffic. For IoT devices that allow direct connections from user devices, the default filter rule can be that no traffic to the IoT device is permitted; and the rule can be updated to permit an authorized endpoint to send traffic to the IoT device only when the authorized user indicates that she is ready to activate the IoT device. The user can indicate her intentions either explicitly, for example using the software installed in her pre- authorized user device or sending a text message, or implicitly, by accessing the IoT device through its own application or Web site. Guard apparatus 54 then checks the identity of the endpoint and changes the filter rule to permit access only when the endpoint has been authenticated.

Additional filtering may be required at step 118 in order to mitigate widespread attacks, such as distributed denial-of-service (DDoS) attacks on IoT devices. Upon detecting such an attack, control plane 68 sets profile rules 72 as filters to permit outgoing connections initiated from within customer premises 22, as well as direct connections between authorized endpoints and IoT devices within the customer premises. All other traffic is either blocked or rate-limited by router 48. This is an example of the use of guard device 54 in controlling quality of service and ensures that all IoT devices (both directly-connected and cloud-controlled) continue their normal operations, while malicious traffic to IoT devices is blocked.

It will be appreciated that the embodiments described above are cited by way of example, and that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and subcombinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art.