One or more aspects of embodiments according to the present disclosure relate to internet-connected devices, and more particularly to a system and method for providing security to internet-connected devices.
Internet-connected devices are commonly used in various applications including home automation and industrial telemetry and control. Such devices may have relatively constrained needs for the various types of communications that are possible within a local network and with other devices on a wide-area network, such as the internet, but the networks to which they are connected may nonetheless grant such devices unrestricted access. This may result in vulnerabilities that may be exploited by a malicious actor.
It is with respect to this general technical environment that aspects of the present disclosure are related.
A system and method for providing security to network-connected devices is provided. In an aspect, a method includes receiving, by a security device for a first network segment, a request from a device to be configured to receive or transmit data on the first network segment, and determining, based on the request to be configured, a first profile for the device. The method may further include receiving, by the security device, a data packet, the data packet being a data packet from the device, or a data packet addressed to the device; determining, by the security device, based on the first profile, that forwarding of the data packet is not authorized, and not forwarding, by the security device, the data packet.
These and other features and advantages of the present disclosure will be appreciated and understood with reference to the specification, claims, and appended drawings wherein:
The detailed description set forth below in connection with the appended drawings is intended as a description of exemplary embodiments of a system and method for providing security to network-connected devices provided in accordance with the present disclosure and is not intended to represent the only forms in which the present disclosure may be constructed or utilized. The description sets forth the features of the present disclosure in connection with the illustrated embodiments. It is to be understood, however, that the same or equivalent functions and structures may be accomplished by different embodiments that are also intended to be encompassed within the scope of the disclosure. As denoted elsewhere herein, like element numbers are intended to indicate like elements or features.
Internet of Things (IoT) devices may comprise common user devices, such as an internet-connect refrigerator, an internet-connected thermostat, or an internet-connected home automation controller, etc. Industrial Internet of Things (IIoT) devices may be user devices used in industry, such as internet-connected process sensors providing telemetry for industrial processes, or internet-connected Computer Numerically Controlled (CNC) machines. Such a device, or a set of such devices, may be connected to the internet through a security device, such as a router (or such as a gateway or firewall). IoT devices, IIoT devices, and user computing devices (e.g., desktop, laptop, or tablet computers) are collectively referred to herein simply as “devices.”
As such, in some embodiments, a router 105 may distinguish, in determining whether to forward data packets (e.g., Transmission Control Protocol/Internet Protocol (TCP/IP) packets) that it receives from, or that are addressed to, a device 110 connected to it, based on the characteristics of the device 110. Each device 110 may be associated with one or more profiles, each of which may correspond to a service that the device 110 is expected to provide, or that the device 110 is expected to consume. As used herein, a “profile” may comprise a data structure containing one or more parameters characterizing a service that the device 110 is expected to provide, or that the device 110 is expected to consume. Based on the profiles of a device 110, the security device 105 may decide, for any packet from, or addressed to, the device 110, whether to forward the packet. The parameters may be used by the security device 105, e.g., in a set of rules, to determine whether the forwarding of a given packet is authorized under the profiles associated with the device 110, and the security device 105 may forward the packet (to the address specified by the device 110, or to the device 110) only if such forwarding is authorized. The security device 105 may make the determination based only on the contents of the packet header, or it may also employ deep packet inspection to determine characteristics of the payload. If the forwarding of the packet is not authorized under any of the profiles associated with a device 110, the security device 105 may simply drop the packet, or drop the packet and (i) update statistics it may maintain related to dropped packets, or (ii) save the packet in a log of unauthorized packets, for future inspection by a user managing the local network (e.g., via user computing device 112).
Each profile may have a name, which may be useful if the user (e.g., an administrator of the first network segment 115) is to participate in the setting up of the security device 105 with a device 110. Parameters that may be defined in a profile may include ports at which the device 110 may receive packets, ports to which the device 110 may send packets, whether the device 110 is permitted to perform peer-to-peer access (e.g., to access other devices 110 connected (or directly connected) to the same security device 105), times (e.g., times of day) during which access is permitted, Internet Protocol (IP) addresses to which the device 110 is permitted to send packets, average data rates at which the device 110 is permitted to send or receive data, and protocols the device 110 is permitted to employ (e.g., File Transfer Protocol (FTP), Server Message Block (SMB), or Secure Shell (SSH)). The profile may also include, for example, parameters specifying whether the device 110 is permitted to perform peer-to-peer access (e.g., access to other devices 110 directly connected to the same security device 105), whether the device 110 is permitted to accept pushed updates, or whether the device 110 is permitted to send a Domain Name System (DNS) query to a resolver other than the resolver of the security device 105. The security device 105 may detect attempts to push an update to the device 110 based on port numbers, or, if the security device 105 has enough processing power and visibility (e.g., if the packets are unencrypted), it may prevent certain POSTs or URLs from being processed. In some embodiments, the security device may perform (or require) proxy functions for certain protocols in order to gain additional visibility. Peer-to-peer restrictions may prevent an infected device from infecting peers while allowing, e.g., a laptop to access a video camera that is its peer.
Other profile parameters may specify whether certain other behaviors (e.g., scanning behaviors), that for example in an IoT device 110 may be an indication that the device 110 has been infected, are permitted, or whether a device 110 may receive packets having characteristics indicating known attack vectors. For example, the security device 105 may block a packet sent by a device 110 to a particular IP address if the device 110 has recently sent packets to multiple (e.g., 10 or more) different ports at the same IP address, and the security device 105 may block a packet addressed to a device 110 if the device 110 has received packets (e.g., from the same source IP address), at multiple (e.g., 10 or more) different ports. In some embodiments, device “signatures” may be stored by the security device 105, which may include the expected behavior of the device. For example, the device signature of a device 110 may indicate that port 80 may be used to select a stream, followed by connection to port 88 for Real Time Streaming Protocol (RTSP). This may form additional security if another device attempts to access a profiled device 110, or the profiled device 110 attempts to access other devices.
The security device 105 may store and recognize a set of standardized profiles (including, e.g., one or more device signature), each with default parameter values (which may or may not be capable of being overridden upon request by a device 110 or user computing device 112). The security device 105 may be capable (e.g., via firmware update) of updating the standardized profiles or of adding new standardized profiles, if the standard defining them is updated. The behavior of the security device 105 may change as a result of such updates; for example, after an update the security device 105 may decline to forward certain packets that, prior to the update, it would have forwarded. The security device 105 may also be capable of receiving, from a device 110, a request to be associated with a non-standard profile, a definition of which is supplied by the device 110, and then associating (or declining to associate) the device 110 with the profile. In examples, the user computing device 112 may be used to control what profile is associated with a device 110 when registering with the security device 105. For example, a user of user computing device 112 may be requested to approve assigning a “security camera” profile when a new camera device 110 is configured for use on first network segment 115 (e.g., when the new camera device 110 engages the security device 105 in the DHCP process of obtaining an internet protocol (IP) address).
The data structure of
The “Provide” portion of the profile may be for inbound connections, and the “Consume” portion of the profile may be for outbound connections. In some embodiments (e.g., to handle a situation in which a device is trying to establish a “callback” on a provided service (e.g., FTP “active” mode transfers)), other conventions may be employed; for example, parameters such as “Listen-Ports” and “Outbound-Ports” may be defined (for inbound and outbound connections, respectively) and included in a profile instead of, or in addition to, the “Ports” parameter. The “PortFwd” parameter may allow the device 110 to request port-forwarding from the security device 105. For example, the security device 105 may provide a network address translation (NAT) service, whereby internet protocol (IP) addresses on the inside of the first data segment 115 (e.g., a Local Area Network (LAN)) are unreachable from the outside (e.g., the second network segment 120, which may comprise a Wide Area Network (WAN)). Port forwarding may create a listening port on the WAN side of the security device 105 for each of one or more ports that are forwarded to the ports “provided” by the inside device 110. This parameter may assume (authorized) automatic port-forwarding (e.g., Universal Plug and Play (UPnP) port forwarding). The “Hints” parameter may be a string that may be easier to understand by the end user. It may also be standardized and formalized, and it may be used to inform the security device 105 which protocols are expected to run over the ports. In the latter case, the parameter may be named “Protocols,” for example.
In the example of
The “FW-Update” profile may be used by the device 110 when it is checking for firmware updates. For example, the “Endpoints” parameter may include a list of Uniform Resource Locators (URLs) or IP addresses from which the device 110 is authorized to fetch firmware updates, and the “Schedule” parameter may specify a limited time window, so that attempts to fetch an update at an unauthorized time may be detected, by the security device 105, and used to detect and foil an attempt by a malicious actor to perform an illegitimate firmware update. The detection of such an attempt may cause the security device 105 to disable the “FW-Update” profile of the device 110 (e.g., cause all attempted updates to be failed) until re-enabled by an administrator (e.g., through user computing device 112). If a device 110 is configured to receive pushed updates, then such updates may be similarly constrained (e.g., permitted only within one or more limited time windows or from particular URLs or IP addresses).
Other profiles may be defined in an analogous manner for services such as audio streaming, file storage, HTTP (used by a device 110 implementing the server side of the HTTP protocol (e.g., Apache, NGINX, etc.)), remote telemetry, home automation events, domain name resolution, email messaging, printer, scanner, and software defined radio. User computing devices (such as user computing device 112) may use an entirely (or largely) unrestricted profile, which may be named “All” (or “All Access” or “Any”).
In some embodiments, the association of profiles with a device 110 may occur when the device 110 is first connected to the security device 105, or when the device 110 is powered up. The device 110 may then negotiate its profiles with the security device 105; for example, the device 110 may request to be associated with certain profiles (e.g., by sending, to the security device 105, a name (and, optionally, a set of parameter values to be used to override standard parameter values) for each requested profile) and the security device 105 may, in response, associate, or decline to associate, the device 110 with one more or the requested profiles. In some embodiments, the Dynamic Host Configuration Protocol (DHCP) may be adapted to support the negotiation between the device 110 and the security device 105.
The decision regarding whether or not to grant the requested association of a device 110 to a profile may be based on one or more of several factors. For example, if after a firmware update, the device 110 requests additional profiles, the security device 105 may decline the request, especially if the newly requested profiles would give the device 110 significant additional freedom to communicate, such as a profile that permits peer-to-peer access, when peer-to-peer access was not authorized for any of the profiles previously associated with the device 110.
In some embodiments the security device 105 may operate autonomously (without user participation) in associating profiles with devices 110; in other embodiments a user may participate (using a suitable interface to the security device 105, as discussed in further detail below) in the association of profiles with a device 110. For example, the security device 105 may be configured (e.g., hard coded, or configured by its firmware, or configured by a user-settable parameter) not to associate a profile with a device 110 without the concurrence of an authorized user, e.g., via user computing device 112. Such a process may have the advantage that the user may have independent information about the nature of the device 110, which may allow the user to determine more reliably than the security device 105 whether a certain profile is appropriate for the device 110. For example, if a thermometer, after installing an update, requests to be associated with the profile “All,” the user, aware that the device 110 is a thermostat, may instruct the security device 105 not to grant the association request. In such a circumstance the security device 105 may also automatically take other actions (such as disconnecting the thermostat from the first network segment) until explicitly re-added by an authorized user.
In some embodiments, as mentioned above, the security device 105 may provide a user interface that the user may use for management and reporting functions. For example, the security device 105 user interface may be a web site associated with the security device 105, which the user may access by navigating to it, using a browser running on a user computing device 112. In other examples, the user interface is operating on a user computing device 112 that is directly connected to the security device 105 within the first network segment. Such an interface may allow the user to participate, e.g., as described above, in the determination of whether a device's profile requests are granted. It may also allow the user to view data related to the security device's security operations, such as statistics on the number of packets, from a particular device 110, during a recent time interval (e.g., during the past day or during the past week) that the security device 105 declined to forward. Such statistics may allow the user to determine that a device 110 has been infected.
Operating environment 400 typically includes at least some form of computer readable media. Computer readable media can be any available media that can be accessed by processing circuit 402 or other devices comprising the operating environment. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium which can be used to store the desired information. Computer storage media is non-transitory and does not include communication media.
Communication media embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, microwave, and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
As used herein, when a device is “directly connected” to a security device, it means that the device is connected to the security device without intervening switching or routing elements (e.g., hubs, switches, or other security devices) being present. As used herein, the word “or” is inclusive, so that, for example, “A or B” means any one of (i) A, (ii) B, and (iii) A and B. As used herein, when a method or a first quantity (e.g., a first variable) is referred to as being “based on” a second quantity (e.g., a second variable) it means that the second quantity is an input to the method or influences the first quantity, e.g., the second quantity may be an input (e.g., the only input, or one of several inputs) to a function that calculates the first quantity, or the first quantity may be equal to the second quantity, or the first quantity may be the same as (e.g., stored at the same location or locations in memory as) the second quantity. The term “processing circuit” is used herein to mean any combination of hardware, firmware, and software, employed to process data or digital signals. Processing circuit hardware may include, for example, application specific integrated circuits (ASICs), general purpose or special purpose central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), and programmable logic devices such as field programmable gate arrays (FPGAs). In a processing circuit, as used herein, each function is performed either by hardware configured, i.e., hard-wired, to perform that function, or by more general-purpose hardware, such as a CPU, configured to execute instructions stored in a non-transitory storage medium. A processing circuit may be fabricated on a single printed circuit board (PCB) or distributed over several interconnected PCBs. A processing circuit may contain other processing circuits; for example, a processing circuit may include two processing circuits, an FPGA and a CPU, interconnected on a PCB.
Although exemplary embodiments of a system and method for providing security to network-connected devices have been specifically described and illustrated herein, many modifications and variations will be apparent to those skilled in the art. Accordingly, it is to be understood that a system and method for providing security to network-connected devices constructed according to principles of this disclosure may be embodied other than as specifically described herein. The invention is also defined in the following claims, and equivalents thereof.
This application claims the benefit of U.S. Provisional Application No. 63/269,354 filed on Mar. 15, 2022, entitled “System and Method for Network-Connected Device Security,” which is incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
63269354 | Mar 2022 | US |