WO2018116123A1 - Protection contre un accès non autorisé à des dispositifs de l'internet des objets (iot) - Google Patents

Protection contre un accès non autorisé à des dispositifs de l'internet des objets (iot) Download PDF

Info

Publication number
WO2018116123A1
WO2018116123A1 PCT/IB2017/058054 IB2017058054W WO2018116123A1 WO 2018116123 A1 WO2018116123 A1 WO 2018116123A1 IB 2017058054 W IB2017058054 W IB 2017058054W WO 2018116123 A1 WO2018116123 A1 WO 2018116123A1
Authority
WO
WIPO (PCT)
Prior art keywords
iot device
iot
network
data packets
endpoints
Prior art date
Application number
PCT/IB2017/058054
Other languages
English (en)
Inventor
Anat Bremler-Barr
Original Assignee
Bremler Barr Anat
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bremler Barr Anat filed Critical Bremler Barr Anat
Publication of WO2018116123A1 publication Critical patent/WO2018116123A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]

Definitions

  • 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.
  • IoT Internet of Things
  • IoT devices are 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.
  • U.S. Patent Application Publication 2016/0212099 describes management of IoT devices through a 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • identifying the set of the one or more endpoints includes recognizing one or more servers that are authorized to communicate with the IoT device.
  • 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.
  • recognizing the one or more servers includes identifying a server that is authorized to send firmware updates to the IoT device.
  • identifying the set of the one or more endpoints includes assembling a list of one or more domains.
  • 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.
  • 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.
  • 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.
  • monitoring the data packets includes identifying a type of the IoT device responsively to the monitored data packets.
  • 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.
  • 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.
  • performing the protective action includes detecting and blocking a denial-of- service attack involving the IoT device.
  • 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.
  • notifications are issued for any traffic to or from the IoT device.
  • 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.
  • 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.
  • 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.
  • 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.
  • the guard location is in an access network, operated by an Internet service provider, through which the IoT devices communicates with the endpoints.
  • 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.
  • 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.
  • 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.
  • the processor when the guard location is on a public network, 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • DNS Domain Name System
  • 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.
  • DDoS Distributed Denial-of-Service
  • 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).
  • 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.
  • protective apparatus 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.
  • 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).
  • 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:
  • domain names such as domain names of servers and corresponding cloud services through which users communicate with their IoT devices.
  • IP Internet Protocol
  • DNS Domain Name System
  • 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.
  • 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.
  • 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.
  • QoS Quality of Service
  • 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.
  • the IP address of the IoT device can also change due to application of the Dynamic Host Configuration Protocol (DHCP) within the LAN.
  • DHCP Dynamic Host Configuration Protocol
  • 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.
  • 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 are not limited to this sort of scenario, and can similarly be applied in protecting other sorts of deployments.
  • a guard device on the access network of an Internet service provider 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.
  • ISP Internet service provider
  • Fig. 1 is a schematic, pictorial illustration of a system 20 for communication with IoT devices, in accordance with an embodiment of the invention.
  • 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.
  • a video camera 24 a door lock 26, a cooking stove 28, and an air conditioner 30.
  • a door lock 26 a door lock 26, a cooking stove 28, and an air conditioner 30.
  • air conditioner 30 air conditioner
  • 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.
  • 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.
  • the IoT device 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.
  • IoT devices 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.
  • 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).
  • 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.
  • guard device 54 is deployed in line with router 48.
  • guard device 54 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • NFV network function virtualization
  • 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.
  • 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.
  • guard device 54 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.
  • 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.
  • 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.
  • guard device 54 will receive an incoming packet from endpoint 52 with a source IP address that is not on the current whitelist.
  • guard device 54 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, ....
  • the protective action will involve blocking this unauthorized traffic and/or notifying an authorized user of the attempted communication.
  • 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.
  • interface 62 connects the guard device to access network 46, but the guard device may alternatively be connected to a LAN or Internet cloud.
  • communications interface comprises one or more network ports (not shown), comprising suitable physical-layer (PHY) and MAC interfaces, as are known in the art.
  • PHY physical-layer
  • 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.
  • RAM volatile random-access 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.
  • 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.
  • SDN software-defined network
  • 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.
  • control plane 68 can use TR-069 or another suitable configuration protocol to block unauthorized accesses, for example at gateway 32.
  • 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.
  • ACL access control list
  • 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.
  • 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.
  • 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.
  • 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.
  • each profile in database 74 can contain some or all of the following data:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • API application programming interface
  • 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.
  • packet markings such as ToS values
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • control plane 68 and/or data plane 70 can be implemented on a dedicated, stand-alone IoT guard device 96 within customer premises 22.
  • 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.
  • 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.
  • 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.
  • guard device 54 in ISP access network 46 (as illustrated in Figs. 1 and 2) carries out most of the steps of the method.
  • 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.
  • 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.)
  • guard device 54 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.
  • 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.
  • 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.
  • guard device 54 may identify the deviant devices and exclude their endpoints from the profile.
  • 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.
  • 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.
  • 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.
  • NTP network time protocol
  • 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.
  • IP addresses may be hard-coded in the IoT device and will be stored as such in the device profile.
  • 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.
  • guard device 54 intercepts and analyzes DNS queries issued by the IoT device to DNS server 58.
  • the DNS queries from the IoT device are issued to a DNS resolver in gateway 32 or other customer premises equipment.
  • the gateway 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the passive mode works in two successive epochs: During the first epoch, guard device
  • 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.
  • 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.
  • 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 shows the passive profile acquisition mode in detail: TABLE I - PASSIVE PROFILE ACQUISITION
  • start_time gettimeofday()
  • stable_time gettimeofday()
  • 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.
  • 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.
  • 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.”
  • 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.
  • guard device 54 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.
  • 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.
  • 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.
  • 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.
  • MFA multifactor authentication
  • other techniques for user authentication can be used, even when identification software is not installed on user device 44.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • guard device 54 periodically looks up the IP addresses corresponding to the domains in the profile, at an IP lookup step 108.
  • 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.
  • guard device 54 obtains and reads DNS responses (from server 58, for example) to DNS queries made with respect to these domains.
  • DNS responses from server 58, for example
  • 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.
  • 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.
  • 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.
  • 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.
  • a secure DNS server such as an OpenDNS or Quad9 server
  • 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.
  • 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.
  • 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.
  • control plane 68 of guard device 54 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.
  • 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.
  • data plane 70 identifies traffic between unauthorized endpoints, such as endpoint 52, and protected IoT devices, at a traffic identification step 114.
  • 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.
  • 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.
  • guard device 54 may autonomously invoke mitigation and move on to step 118, for example upon detecting a potentially severe, anomalous access pattern.
  • 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.
  • control plane 68 can decide to set one or more filters to mitigate the unauthorized traffic.
  • 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.
  • 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.
  • DDoS distributed denial-of-service

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de protection de réseau qui consiste à surveiller des paquets de données transmis à un dispositif de l'Internet des objets (IDO) (24, 26, 28, 30), et à partir de ce dernier, sur un réseau (38, 46). Sur la base des paquets de données surveillés, un ensemble d'un ou de plusieurs points d'extrémité (42, 44), qui sont autorisés à communiquer avec le dispositif IDO par le biais du réseau, est identifié. Parmi les paquets de données surveillés, une tentative de communication avec le dispositif IDO au moyen d'un point d'extrémité (52) qui n'est pas un membre de l'ensemble identifié, est détectée. En réponse à la détection de la tentative, une action de protection est exécutée au niveau d'un emplacement de garde dans le réseau, entre le point d'extrémité et le dispositif IDO de sorte à atténuer des communications non autorisées avec le dispositif IDO.
PCT/IB2017/058054 2016-12-19 2017-12-18 Protection contre un accès non autorisé à des dispositifs de l'internet des objets (iot) WO2018116123A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662435866P 2016-12-19 2016-12-19
US62/435,866 2016-12-19

Publications (1)

Publication Number Publication Date
WO2018116123A1 true WO2018116123A1 (fr) 2018-06-28

Family

ID=62626273

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2017/058054 WO2018116123A1 (fr) 2016-12-19 2017-12-18 Protection contre un accès non autorisé à des dispositifs de l'internet des objets (iot)

Country Status (1)

Country Link
WO (1) WO2018116123A1 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2581990A (en) * 2019-03-06 2020-09-09 British Telecomm Network protection
CN111970309A (zh) * 2020-10-20 2020-11-20 南京理工大学 基于Spark车联网组合深度学习入侵检测方法及系统
US10893090B2 (en) 2019-02-14 2021-01-12 International Business Machines Corporation Monitoring a process on an IoT device
WO2021180439A1 (fr) * 2020-03-10 2021-09-16 BSH Hausgeräte GmbH Dispositif et procédé pour la commande de l'accès à un dispositif électrique
WO2021194362A1 (fr) * 2020-03-27 2021-09-30 Motorola Solutions, Inc Procédé et appareil pour empêcher l'accès à un dispositif iot
US11405357B2 (en) 2018-04-27 2022-08-02 Cloudflare, Inc. Protecting internet of things (IoT) devices at the network level
US11683246B2 (en) 2021-03-09 2023-06-20 Ayla Networks, Inc. Edge-based intelligence for anomaly detection
WO2023242821A1 (fr) * 2022-06-16 2023-12-21 Sternum, Ltd. Systèmes et procédés pour l'instrumentation, la détection de compromis en temps réel et la gestion de dispositifs connectés à l'internet

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160219065A1 (en) * 2015-01-23 2016-07-28 Cisco Technology, Inc. Packet capture for anomalous traffic flows

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160219065A1 (en) * 2015-01-23 2016-07-28 Cisco Technology, Inc. Packet capture for anomalous traffic flows

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KEUNTAE LEE: "Secure DNS Name Autoconfiguration for IPv6 Internet-of-Things Devices", INTERNATIONAL CONFERENCE ON INFORMATION AND COMMUNICATION TECHNOLOGY CONVERGENCE (ICTC, 19 October 2016 (2016-10-19), pages 564 - 569, XP033039477 *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11405357B2 (en) 2018-04-27 2022-08-02 Cloudflare, Inc. Protecting internet of things (IoT) devices at the network level
US11979373B2 (en) 2018-04-27 2024-05-07 Cloudflare, Inc. Protecting internet of things (IoT) devices at the network level
US10893090B2 (en) 2019-02-14 2021-01-12 International Business Machines Corporation Monitoring a process on an IoT device
GB2581990A (en) * 2019-03-06 2020-09-09 British Telecomm Network protection
GB2581990B (en) * 2019-03-06 2021-10-20 British Telecomm Network protection
WO2021180439A1 (fr) * 2020-03-10 2021-09-16 BSH Hausgeräte GmbH Dispositif et procédé pour la commande de l'accès à un dispositif électrique
CN115280818A (zh) * 2020-03-10 2022-11-01 Bsh家用电器有限公司 用于控制对电设备的访问的装置和方法
WO2021194362A1 (fr) * 2020-03-27 2021-09-30 Motorola Solutions, Inc Procédé et appareil pour empêcher l'accès à un dispositif iot
CN111970309A (zh) * 2020-10-20 2020-11-20 南京理工大学 基于Spark车联网组合深度学习入侵检测方法及系统
US11683246B2 (en) 2021-03-09 2023-06-20 Ayla Networks, Inc. Edge-based intelligence for anomaly detection
WO2023242821A1 (fr) * 2022-06-16 2023-12-21 Sternum, Ltd. Systèmes et procédés pour l'instrumentation, la détection de compromis en temps réel et la gestion de dispositifs connectés à l'internet

Similar Documents

Publication Publication Date Title
EP3725054B1 (fr) Surveillance des risques basée sur un contexte
WO2018116123A1 (fr) Protection contre un accès non autorisé à des dispositifs de l'internet des objets (iot)
US20220255960A1 (en) Rogue device detection including mac address spoofing detection
US10257186B2 (en) Method and network element for improved access to communication networks
US7124197B2 (en) Security apparatus and method for local area networks
US10542020B2 (en) Home network intrusion detection and prevention system and method
US7448076B2 (en) Peer connected device for protecting access to local area networks
US20220103592A1 (en) Enhanced risk assessment
US20040255167A1 (en) Method and system for remote network security management
US20060095961A1 (en) Auto-triage of potentially vulnerable network machines
EP1956463A2 (fr) Procédé et appareil pour sécurité de réseau basée sur un état de sécurité de dispositif
US20210099473A1 (en) Anomaly detection including property changes
US20030004688A1 (en) Virtual intrusion detection system and method of using same
Dietz et al. IoT-botnet detection and isolation by access routers
Cox et al. Leveraging SDN for ARP security
US10505967B1 (en) Sensor-based wireless network vulnerability detection
US10498758B1 (en) Network sensor and method thereof for wireless network vulnerability detection
Mandal et al. A survey on network security tools for open source
Agrawal et al. The performance analysis of honeypot based intrusion detection system for wireless network
Ye et al. Retrofitting security and privacy measures to smart home devices
Khurana A security approach to prevent ARP poisoning and defensive tools
KR101186873B1 (ko) 시그니쳐 기반 무선 침입차단시스템
Jadhav et al. Detection and mitigation of ARP spoofing attack
Nenova et al. Intrusion detection system model implementation against ddos attacks
Kamal et al. Analysis of network communication attacks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17883720

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17883720

Country of ref document: EP

Kind code of ref document: A1