Establishing and maintaining secure device communication

Abstract

Techniques for dynamically generating a trust level for IoT devices are described. A plurality of characteristics of a first device of a first device type are analyzed against a set of expected characteristics for the first device type. Embodiments monitor runtime behavior of the first device for a time window to collect runtime behavior data and analyze the runtime behavior data of the first device to determine whether the device is operating in a manner consistent with the first device type. Upon determining that the analyzed plurality of characteristics are consistent with the set of expected characteristics and that the first device is operating in a manner consistent with the first device type, embodiments generate a security profile for the first device that designates the first device as a trusted device.

Description

Technical Field

[0001] This disclosure relates to secure data processing, and more specifically, to techniques for establishing and maintaining secure communications for Internet of Things (IoT) devices. Background Technology

[0002] The Internet of Things (IoT) promises to connect components on a massive scale. Depending on the application context and environment, this convergence allows these components to interact and collaborate to accomplish one or more specific tasks. For example, tasks can range from sensing and monitoring environmental characteristics (such as temperature or humidity in a single room) to controlling and optimizing entire buildings to achieve larger goals (such as energy management strategies). Protecting the data processed by these IoT devices is highly beneficial in a variety of environments, especially in environments where the devices are initially deployed with little or no cloud-based network connectivity.

[0003] IoT devices, or more generally, devices used to capture data from the environment, have existed for several years, and various methods exist to secure the communication data associated with these deployed devices. Many previously deployed devices were designed to operate in isolated network environments, storing the collected data locally for analysis by local computer systems. However, with the advent of cloud-based connectivity, traditional techniques for securely connecting devices in isolated network environments are insufficient for securely connecting devices in cloud computing environments. Furthermore, many of these legacy devices lack the computing resources (e.g., processing resources, storage resources, etc.) to run modern device firmware that enables secure communication. Therefore, there are technical challenges in retrofitting these legacy devices to operate securely in modern environments. Attached Figure Description

[0004] A more detailed description of the present disclosure, which has been briefly summarized above, can be obtained by referring to various embodiments, some of which are illustrated in the accompanying drawings. While the drawings illustrate selected embodiments of the present disclosure, they should not be considered as limiting its scope, as the present disclosure may allow for other equally effective embodiments.

[0005] Figure 1 Aspects of a system for establishing and maintaining communication between security devices, according to an embodiment described herein, are shown.

[0006] Figure 2 Different types of devices are shown connected to a system for establishing and maintaining secure device communications, according to one embodiment described herein.

[0007] Figure 3 The deployment of connection elements of a system for establishing and maintaining communication between security devices, according to an embodiment described herein, is shown.

[0008] Figure 4 This is a block diagram illustrating a system for establishing and maintaining communication between security devices according to an embodiment described herein.

[0009] Figure 5 An incremental trust element and a decrementing trust element for establishing and maintaining secure device communication are illustrated according to one embodiment described herein.

[0010] Figure 6A A state diagram of trust state evolution elements for establishing and maintaining secure device communication is shown according to an embodiment described herein.

[0011] Figure 6B A flowchart is shown illustrating a trust state evolution process for establishing and maintaining secure device communication according to an embodiment described herein.

[0012] Figure 6C A sequence diagram of provisioning devices in a system for establishing and maintaining secure device communications is shown according to one embodiment described herein.

[0013] Figure 7 A functional block diagram of a general-purpose computer system according to an embodiment described herein is shown.

[0014] Figure 8 A functional block diagram of a general-purpose storage system for use with a general-purpose computer system according to one embodiment described herein is shown.

[0015] Figure 9 This is a flowchart illustrating a method for generating a security profile for a device according to an embodiment described herein.

[0016] Figure 10 This is a flowchart illustrating a method for calculating a trust metric and associating the trust metric with a device according to an embodiment described herein.

[0017] Figure 11 This is a flowchart illustrating a method for generating a trust level metric and associating the trust level metric with a device, according to an embodiment described herein.

[0018] Where possible, the same reference numerals are used to denote common elements in the figures. However, elements disclosed in one embodiment may be advantageously used in other embodiments without specific description. Detailed Implementation

[0019] In the emerging world of the Internet of Things (IoT), or more generally, Cyber-Physical Systems (CPS), the convergence of multiple technologies is underway to allow sensing, actuation, data capture, storage, and / or processing of data from a large number of connected components, including physical components, virtual components, and / or combinations of both. These components can be remotely accessed using existing network infrastructure to enable efficient machine-to-machine (M2M) and human-to-machine (H2M) communication. As the network of connected components changes and grows over time, an ever-increasing volume of data will be generated from these connected component elements. Protecting the data associated with these dynamically connected devices and sets of components presents a significant technical challenge.

[0020] Complicating this challenge are devices deployed several generations ago that may not be prepared for robust, secure communication between the devices themselves and large data networks, such as cloud-based environments. Furthermore, some of these devices may be "untrusted" to the networks they currently belong to. A challenge with legacy devices is that the ownership chain from the factory to the current owner is often unknown, creating the possibility of "untrusted" devices present in the field. These devices may have been compromised by malicious actors or used for malicious device emulation, which may be indistinguishable from the real device from the perspective of a remote system. Ideally, any devices previously present in the environment (i.e., brownzone devices) and newly deployed devices (i.e., greenzone devices) can coexist and operate in combination, as this avoids the cost of replacing brownzone devices with greenzone devices. However, this presents significant challenges because many brownzone devices are not configured to operate in modern environments (e.g., modern environments where one or more components reside in cloud computing environments), and in many cases, these brownzone devices may lack the computing resources (e.g., processing and storage capacity) to execute firmware updates that would add those capabilities.

[0021] As these IoT computing devices rapidly become more available and accessible, improperly secured IoT devices become highly attractive targets for compromising valuable data and associated infrastructure. Data theft, botnet creation, the theft of valuable information, and the performance of attacks on infrastructure via connected IoT devices are examples of potential problems that IoT systems may face. Such attacks can typically target IoT devices that directly use or provide data services, including (but not limited to) data-generating IoT devices, IoT gateways, and edge devices.

[0022] Security challenges exist for IoT devices that are not typically suited to traditional computing devices and systems. This challenge includes securely deploying devices regardless of their creation within the environment. An example of system vulnerabilities, including those involving brownzone devices, is a denial-of-service (DoS) attack exploiting unauthenticated brownzone devices. In such attacks, malicious users may impose additional loads on the platform or inject fake data. For example, a malicious user might create one or more login requests and / or multiple fake accounts on the platform. With a sufficient number of such accounts, a malicious user can register a large number of malicious devices that can be used to launch a DoS attack against the system, such as a data storage system or another part of the IoT platform.

[0023] As another example, a DoS attack can be launched against the registration process by "overwhelming" it with requests to register devices. A malicious user can create multiple authorization requests for the device as a DoS attack against the registration process itself. As yet another example, a malicious user can create spoofed devices that can prevent legitimate devices from connecting to the platform and / or load invalid data into the platform, thereby compromising analytics. For instance, a malicious user can create a malicious device that sends corrupted or excessively large amounts of data to the platform, exceeding its processing capacity and thus denying legitimate devices access. Large amounts of data can be maliciously sent to the platform to increase its operating costs without causing platform failure.

[0024] System administrators of IoT systems can use mitigation strategies to mitigate the impact of such attacks. This can include restricting access from invalid users to parts or the entire system, thereby helping to prevent malicious users from creating additional load on the platform. Furthermore, the registration process can be limited to a set number of requests for registration of devices. Additionally, registration can be restricted by requiring the process to be performed by an authenticated IDMS user. As another example, the system can restrict IDMS from requiring one or more of the following to create an account: multi-factor authentication, CAPTCHA portal, email verification for account creation, unique IDMS login authentication for each device, and rate limits for adding devices.

[0025] However, as mentioned above, many brownzone devices may lack the configured programming logic to integrate with modern IoT systems running in cloud environments. While some devices can be "upgraded" by installing updated software that adds cloud connectivity, in many cases, these brownzone devices may lack the computing resources (e.g., processing power, storage capacity, etc.) to execute such updated software logic. Furthermore, even with updated software, these brownzone devices may lack the necessary data and configuration to fully integrate into modern IoT environments. For example, manufacturers assign a unique identifier to many modern devices, stored in the device's memory. This unique identifier is known and can be verified through cloud applications that communicate with the device. While many brownzone devices are configured with this unique identifier at manufacturing, they may not be able to be authenticated by cloud applications. In other words, if a device is not configured with a unique identifier in a verifiable manner during manufacturing (e.g., secret information such as a pre-shared key is pre-configured on the device during the manufacturing process and this information is known to the cloud server, a public-private key infrastructure with certificates is used, or a private key is pre-configured at manufacturing and securely stored on the device, etc.), the cloud system may only be able to verify that the device's unique identifier is a valid unique identifier, but may not be able to verify the device's identity. Therefore, traditional solutions do not provide sufficient methods to determine when it is acceptable to completely trust brownzone devices.

[0026] To address this security challenge, this disclosure provides a system that considers trust elements of a particular device and uses these trust elements to generate a trust metric for that device. Typically, such trust elements may include trust atoms and non-trust atoms. These trust elements can then be processed at each device level to create a trust metric for each device. Once the trust metric is created, the embodiments described herein can compare the trust metric to a device-level trust threshold. Based on this processing, the security management device can take further action. For example, when a particular device is determined to be sufficiently trustworthy (e.g., when the trust metric exceeds the device-level trust threshold), the embodiments can begin to utilize data collected by the particular device during system monitoring activities, such as when system-level events and alarms are generated.

[0027] Figure 1 A system for establishing and maintaining secure device communications according to one embodiment of the present disclosure is illustrated. As shown, system 125 includes one or more general-purpose computers 110, one or more data storage arrays 130, a cloud computing environment 120, a building or other structure 140 containing one or more connecting elements (not shown), and a network connection 150 that allows data exchange between these parts of the system.

[0028] like Figure 1As shown, building 140 includes one or more connectivity elements, components, devices, and / or actuation components, which may be physical, virtual, or a combination of both, and perform sensing, actuation, data capture, storage, or processing to monitor or control or manage building 140. Any type of connectivity element can be used to capture, store, or process data, or to actuate associated devices via network connection 150, to cloud computing environment 120, or to other parts of the system. For example, these connectivity elements can detect temperature, humidity, ambient light, sound, smoke, carbon monoxide, carbon dioxide, motion, non-conductive fluids, conductive fluids, vibration, energy, power, voltage, current, or any other desired characteristic and combinations thereof. Connectivity elements can also operate or engage elements, components, and / or other systems, such as turning on lights, opening doors or windows, moving curtains, or triggering door locks. Connectivity elements can also process data structures from other connectivity elements or propagate data structures from one or more connectivity elements to one or more other connectivity elements. Any number of connectivity elements can be deployed in any combination to monitor or manage a physical space. Examples of such spaces can include closets, rooms, buildings, campuses, offices, corridors, or any other desired location.

[0029] As shown in the figure, one or more buildings 140, including connecting elements, are connected to a cloud computing environment 120 via a network connection 150. This connection allows access to the cloud computing environment 120 by various devices capable of connecting to it via wired or wireless connections. Figure 1 In the depicted example, such a device includes one or more general-purpose computers 110 capable of receiving input from a user or providing autonomous operation. One or more data storage arrays 130 may be used to provide additional data storage capacity. It should be understood that while the cloud computing environment 120 provides additional communication paths to additional components or systems, it is not required as part of the semantic search method. Some other embodiments contemplate self-contained systems or stand-alone systems.

[0030] Network connection 150 can be a wired or wireless connection. This connection can include, but is not limited to, any physical cabling method, such as Category 5 cable, coaxial cable, fiber optic cable, copper cable, twisted pair cable, or any other physical medium for transmitting electrical signals. Wireless connections can include, but are not limited to, Personal Area Networks (PANs), Local Area Networks (LANs), Wi-Fi, Bluetooth, LPWAN (Low Power WAN) cellular, global, or space-based communication networks. In other embodiments, access between cloud environment 120 and any other cloud environment configured to connect to devices similar to, for example, the existing cloud environment 120. It should be understood that... Figure 1The computing devices shown are illustrative only, and computing nodes and cloud computing environments can communicate with any type of computerized device through any type of network with addressable or direct connectivity.

[0031] The principles of this disclosure include a system 125 for establishing and maintaining communication between security devices, which may include... Figure 1 The details of the components may include more or fewer of these components, or they may be located in building 140 or a series of buildings. The security device communication system 125 may be physical, virtual, or a combination of both. There are no limitations on the configuration, location, or organization of the security device communication system 125.

[0032] Figure 2 Various embodiments of a system for establishing and maintaining secure device communications, according to various embodiments of this disclosure, are shown, enabling different types of devices to connect to each other. Figure 2 In one embodiment, building 140 includes one or more types of connection elements 210, 220, 230, 240 for monitoring or managing the structure. These connection elements 210, 220, 230, 240 communicate via a wired network 250 or a wireless network 260, and make data structures from each connection element available via network connection 150 to security device communication system 125 and / or cloud environment 120.

[0033] Any type of connectivity element can be used to perform sensing, actuation, data capture, storage, or processing on the security device communication system 125, cloud computing environment 120, or other parts of the system via network connection 150. For example, a connectivity element could be a carbon dioxide measuring sensor 210 used to monitor the air quality of building 140 and communicating via wired network connection 250. A connectivity element could be both a connectivity sensor detecting ambient light and an actuator 220 changing the state of occupants' lighting fixtures, communicating via wired network connection 250. A connectivity element could be a connectivity sensor 230 used for temperature and humidity monitoring of the environment of building 140 and communicating via wireless network connection 260. Finally, connectivity element 240 acts as a connectivity gateway to communicate with the associated connectivity elements 210, 220, 230 via their respective network connections 250, 260, process the data structure of each connectivity element, and send it to network connection 150 for transmission to the cloud environment 120. It should be understood that while the cloud computing environment 120 provides additional communication paths to additional devices or systems, this is for illustrative purposes only and not for limitation. Other embodiments are considered as self-contained systems or standalone systems.

[0034] These connectivity elements do not need to be geographically localized or logically grouped in any way to utilize embodiments of this disclosure. Geographically or logically grouping connectivity elements allows for more economical use. Geographic grouping can be accomplished, for example, in apartments, homes, or office buildings, as well as logically positioning connectivity elements by function. One example of many logical grouping examples could be positioning connectivity endpoints designed for temperature sensing near a residential location to detect changes in the environment. It should be understood that grouping of connectivity endpoints can also be over a very large geographical area, even globally. Such global operation can be monitored through a network located in any number of facilities worldwide.

[0035] Figure 3 The deployment of various connecting elements for establishing and maintaining communication of security devices according to one embodiment described herein is shown. A “North” building 310 and a “West” building 320 are shown. Each building has (3) floors associated with it. North floors (1) 312, (2) 314, and (3) 316 are contained within North building 310. West floors (1) 322, (2) 324, and (3) 326 are contained within West building 320. Each floor has (3) connecting elements of different types. For example, the connecting elements could be connecting sensors 330, 332, 334, 360, 362, and 364 for measuring carbon dioxide, used to monitor the air quality of buildings 310 and 320 respectively and communicate via a wired network connection. The connecting elements could be both connecting sensors for detecting ambient light and actuators 340, 342, 344, 370, 372, and 374 for changing the state of occupants' lighting fixtures, and communicate via a wired network connection. The connecting elements can be temperature and humidity sensors 350, 352, 354, 380, 382, ​​and 384, which monitor the environment of buildings 310 and 320 respectively and communicate via a wireless network connection. As shown, a security device communication system 125 is connected to the system to establish and provide the ability to register known or unknown trusted devices into the system.

[0036] Figure 4 Example block diagrams of a system 250 for establishing and maintaining secure device communications according to various embodiments of the present disclosure are shown. Various embodiments of the present disclosure may include a user initiating a device provisioning process, requesting provisioned devices through a middleware portal capable of verifying one or more device characteristics, requesting user identification and / or characteristics, communicating with an IDMS or a similarly functional identity provider to further verify the user's identity using the middleware portal, provisioning devices, and communicating with the devices to perform ongoing characterization and monitoring.

[0037] As shown in the figure Figure 4The system includes an Integrated Database Management System (IDMS) 402 that manages a user identity database 403. IDMS 402 is connected to a middleware portal 400. Middleware portal 400 includes a device registry 404, a cloud processing component 406, and a trust measurement component 408. In the depicted example, a user can interact with user terminal 110 to initiate a device provisioning process for a new brownzone IoT device 210. Typically, cloud processing component 406 provides a message bus and computing logic. IoT device 210 can send a message to cloud processing component 406 via the Internet 125, requesting provisioning and specifying its device ID. Cloud processing component 406 can then forward the provisioning request to device registry 404, which in turn sends a request to user terminal 110 for the user identity associated with the device registration. The user enters login credentials into user terminal 110, and this information is sent to IDMS 402, which manages the user identity database 403, and verifies the login credentials. After successfully authenticating the user, IDMS 402 sends an indication to the device registry 404, indicating that the user is a valid user.

[0038] Typically, cloud processing component 406 can collect event data related to the behavior of IoT device 210 during routine operation. For example, this event data may describe the amount of network traffic generated by IoT device 210, the content of the network traffic generated by IoT device 210, the timing of actions performed by IoT device 210, the processing resource usage of IoT device 210, the storage resource usage of IoT device 210, etc. Cloud processing component 406 can typically compare observed behavioral patterns for IoT device 210 with expected behavioral patterns for IoT devices at the same time. For example, this expected behavioral pattern can be generated based on historical data collected from other IoT devices of the same type in the control environment (e.g., using devices that the manufacturer knows are genuine and functioning correctly). Cloud processing component 406 can generate trust atoms (or, alternatively, generate untrust atoms) based on the results of these comparisons. For example, if cloud processing component 406 observes that IoT device 210 is generating network traffic that is substantially the same in content and quantity as historical devices of the same device type, cloud processing component 406 can generate trust atoms for IoT device 210, indicating that IoT device 210 is determined to be more trustworthy.

[0039] As another example, a manufacturer can implement a process of assigning serial numbers to devices, and the cloud processing component 406 can be configured with logic for determining the relationship between the assigned serial number and the device's MAC address. For example, the cloud processing component 406 can access the serial number and MAC address of IoT device 210 and can use information and logic associated with the serial number to verify the device's serial number. For instance, the cloud processing component 406 can determine the device's manufacturing time by performing a lookup operation in a data store using the device's MAC address, and the cloud processing component 406 can further access that data store (or a different data store) to determine the range of serial numbers assigned during a time window (e.g., one week), including manufacturing data. The cloud processing component 406 can then determine whether the serial number assigned to the device is within the determined range, and if so, the device can be successfully verified. After verifying the serial number of device 210, the cloud processing component 406 can generate the corresponding trust atom.

[0040] The cloud processing component 406 can generate multiple trust (or untrusted) atoms for various attributes of the IoT device 210, and the trust measurement component 408 can compile these atoms and calculate an aggregate trust metric for the IoT device 210. The trust measurement component 408 can send the calculated trust metric to the IoT cloud platform 410, which can store the trust metric associated with the IoT device 210. If the aggregate trust metric of the IoT device 210 indicates that the IoT device 210 is sufficiently trustworthy, the IoT cloud platform 410 can incorporate the IoT device 210 into its IoT platform. For example, the IoT cloud platform 410 can begin using data collected by the IoT device 210 to generate visualizations, events / alerts, etc. The trust measurement component 408 can continue to monitor the trust and untrusted atoms generated by the cloud processing component 406, and if the IoT device 210 begins to behave abnormally and does not behave in a manner consistent with other devices of the same device type, the trust measurement component 408 can revoke the trust level granted to the IoT device 210. Therefore, while brownzone IoT devices may never be given the same level of trust as greenzone IoT devices, implementations can provide brownzone devices with a certain level of trust by monitoring their attributes and behavior, and this trust level can be continuously updated in real time, thereby allowing some brownzone devices to operate in a cloud environment.

[0041] Figure 5An embodiment of incremental and decremental trust elements for establishing and maintaining secure device communication is illustrated. Trust atoms and untrust atoms are used to determine the level of trust on a device-by-device basis. These trust elements are processed at the device level to create a trust metric. Once created, the trust metric is compared to a device-level trust threshold. Based on this processing, the security management device can take further action.

[0042] Devices supplied using embodiments of the present invention can be tagged in their metadata in a device database using the methods used to supply them. These methods can be brown zone, green zone, or any other method defined by the agency responsible for supplying the devices. This data can be immutable and can be used to enhance any filtering of devices, such as removing or identifying devices supplied through brown zone processes. This aspect may be helpful in determining whether one or a series of devices should be placed in a particular category of devices (e.g., unauthorized devices).

[0043] When a device is first supplied to the system via a brownzone process, it can be assumed that the device has no trust level (0 trust weight). It should be understood that this weight is highly variable and configurable. A great deal of flexibility exists to allow for broad application and preserve the benefits of innovation. As an example, identity provider service (IDMS in this example) authentication can have a trust weight greater than 0. Required authentication before registration ensures that the supplied device will start with a specific initial trust weight equal to the authentication trust weight (e.g., greater than 0).

[0044] Devices that do not meet the trust level required for system use, such as brown zone devices after initial provisioning, can be assigned a probationary status to determine if they have sufficient trust. This probationary status can be used to further isolate suspicious devices from the platform's authorized and trusted devices. Once a device's trust threshold is met, it can be moved to full operational status and removed from the probationary status. During the probationary period, data collection may be disabled or subject to other restrictions to prevent harm to other devices or the network and / or to prevent the need to move data at the end of the probationary period.

[0045] As devices are deployed, various trust atoms accumulate. If sufficient trust weights are accumulated, the device will pass a trust threshold and be considered a trusted device in the system. Alternatively, if a device fails to pass the trust threshold or other criteria determined by the security system administrator during the trial period, the device will be considered untrusted and deprovisioned or subjected to other actions. For legitimate users using real devices, reaching the trust threshold within a specified time period may not be a problem, as normal operation should verify trust. However, this serves as a deterrent to attackers, as they must maintain an active attack during the trial period to gain full access to the system.

[0046] Typically, a Trust Atom has several associated properties. It should be understood that these are not exhaustive, as other properties exist. Furthermore, these properties can be combined to produce unique properties. For example, a Trust Atom (AoT) may have different weights, including negative values ​​in the case of an Untrusted Atom (AoD). As another example, a Trust Atom can be represented by an integer Boolean or other data value type. In one embodiment, the sSize of each element can be defined by the weight of the AoT. In a particular embodiment, a brownzone device may not receive a single AoT to gain a trusted state, but rather requires multiple AoTs before it can obtain a trusted state. This can reduce the likelihood of gaining access in a single attack. It should be understood that devices manufactured using a verifiable manufacturing process (e.g., serial number) have high trust weights and can be marked in their metadata with a flag indicating that they were manufactured with a verifiable identity.

[0047] In one embodiment, the system can be configured such that a single AoD can override all accumulated AoTs, including already trusted devices. Large, untrusted atoms can be reserved for devices exhibiting untrusted behavior (e.g., sending data too frequently over an extended period). In this embodiment, a device can potentially transition to a blacklisted state based on a single AoD (e.g., from an untrusted state, a trial trusted state, or a trusted state).

[0048] Furthermore, time can be a component of cumulative AoT. For example, trust atoms can accumulate weights during the trial period, and if a trust threshold is reached during the trial period, the system can have some confidence that the device can be trusted. However, if the device does not reach the trust threshold during the trial period, it may be removed from the system, requiring the user to re-register the device. Failed provisioning attempts can be logged and counted, and if the count of provisioning attempts exceeds a certain threshold, the device can be blacklisted.

[0049] According to one embodiment, the system is configured to stop monitoring and evaluating the trust status of a device once it is classified as blacklisted, because once a device is blacklisted, the system will not remove the blacklisted status regardless of the expected amount of behavior of the blacklisted device. In one embodiment, the system is configured to completely stop communication with the blacklisted device and ignore any network messages sent from the blacklisted device. As another example, the system may be configured to clear all data previously received from or otherwise collected for the blacklisted device. In one embodiment, the system is configured to implement a process through which a device can be removed from the blacklisted status. For example, such a process may involve calling customer support to verify the authenticity of the device, having a technician visit a customer site to verify the authenticity of the device, etc.

[0050] One reason for removing devices that fail to reach the trust threshold during the trial period is that legitimate users will connect the device to the system, and legitimate users should accumulate sufficient trust during the trial period. One explanation for failing to achieve this trust is that the device was not connected during that interval or it is a malicious device. For a malicious user to meet this threshold and time requirement, they would need to invest significant resources over a period of time (e.g., attempting to create multiple invalid device identities using an emulator), thus increasing the cost of an attack. This resource cost is not a problem for legitimate users because they possess valid physical devices capable of sending appropriate data during the trial period.

[0051] Atom weights can be scored in several ways. One example could be that the smallest and easiest-to-implement atom has a weight of 1. All other atoms are scored relative to this smallest atom. This disclosure considers several factors related to atom scoring that can be used to further weight atoms. These include, but are not limited to, atoms that are difficult to discover, such as serial numbers; atoms that are difficult to automate, such as those requiring human interaction in a loop; and atoms that are difficult to forge, such as any atom that is very difficult to replicate, such as a "salt" code.

[0052] When creating Trust Atoms and their corresponding weights, an important consideration is the relative cost and difficulty of generating AoTs. For example, an AoT that relies on a device performing its normal operation is not expensive for the device to execute, but expensive for an attacker to generate, and may therefore be a valuable AoT. An AoT that requires platform computing power for verification as well as the attacker's computing power can have a moderate value. An AoT that requires more computing power for verification than generation may have a lower value.

[0053] Below are examples of various AoTs. Determining the weights of atoms is a highly flexible process that depends on the application. Each atom can have two values: a positive value for possessing the atom and a negative value for if the atom is known not to be real. Atoms can initially be assigned values ​​determined by the system.

[0054] An atom with a very high distrust score can render any trusted item untrusted, causing it to be blacklisted from future communications. A very high trust score can indicate a reliable and robust process, suggesting that no further trust is needed.

[0055] Trust atoms can have binary weights (e.g., whether they possess a trust element or not) or integer weights reflecting the amount that trust atom has accumulated. Some trust atoms can have pass / fail weights, indicating a positive trust weight if they pass the test, and an associated negative weight if they fail. Generally, failing a test is more negative than passing it, because a malicious user is attempting to pass the test.

[0056] IDMS verification can have low atomic weights and can be based on the following characteristics. Like any AoT, it may require provisioning to devices based on system-defined requirements. IDMS has a CAPTCHA portal to prevent brute-force attacks, and IDMS requires email verification and / or multi-factor authentication (MFA) before account activation. These characteristics can include further qualifiers, such as CAPTCHA requiring manual account creation, a unique email address, and / or MFA requiring a second source of human verification.

[0057] MAC / serial number combination verification for network interfaces can have both low AoT (Aspect-Oriented Time) and very high AoD (Aspect-Oriented Demand). Users can use a web application to photograph a barcode on a device, which will then read the MAC address, serial number, and SKU number. This information can be compared to manufacturing records. Verification can be performed to prevent duplicate MAC / serial number combinations. If a duplicate MAC address or serial number is detected, an atomic method for identifying duplicate identifiers is provided. Furthermore, attackers can infer the correct relationship between the MAC address and serial number from product labels, enabling them to guess MAC / serial number combinations that have not been seen before.

[0058] The host system's serial number / SKU number can have low AoT and very high AoD. Users will use a web application to photograph the barcode of the device installed on it. This information is sent to the cloud and can be verified against user input. Data in the message packet can only be retrieved by a valid device. If a duplicate MAC address or serial number is detected, an atomic method for identifying duplicate identifiers is provided here.

[0059] When using a UPS, verification against other data items shows that UPS data can have low AoT (Average Time Tolerance) and very high AoD (Average Time Demand). In some manufacturing processes, there is a mathematical correlation between the serial number and the manufacturing date. If the manufacturing date does not match within tolerance, the calculated AoD is high. There are known relationships to constrain the manufacturing date of the UPS. The UPS serial number can be used to determine the SKU number via retrieval and comparison with a Manufacturing Execution System (MES) database based on values ​​reported by the equipment. Verification exists to prevent duplicate UPS serial numbers from being registered by identifying units with multiple registrations.

[0060] When using a UPS, users who need to perform self-tests from the unit's front panel can have low AoT and very high AoD. The user will be instructed to perform actions on the UPS and will be required to perform these actions within a specific requested time period. The user will use the UPS's local interface to have the UPS check the battery health. The response to this action will be a set of characteristic messages with specific values ​​at different locations.

[0061] Communication pattern verification can have low AoT and low AoD. Monitoring incoming messages and tracking arrival rates (e.g., messages received over a period of time) and comparing them to expected traffic rates can improve the trust level. The AoT can have multiple values ​​that increase over time, not necessarily linearly. The distrust level may increase when communication rate limits are exceeded. This distrust atom may accumulate during the trial period and could become a large distrust item if it exceeds a specified threshold.

[0062] As an example, all telemetry data from the device is sent to the event center, and a stream analytics job measures the time between messages. For instance, if the time between messages is 5 minutes + / - 20 seconds, an AoT (Average Time Tolerance) might be achieved. If it's outside this range, 1 is subtracted. In this case, if 85% of the messages pass the time between message tests, the device is trusted. If the threshold is not met during the trial period, the device is untrusted. The threshold could be assumed to be one week of device operation, or any other appropriate time metric, so failing to meet it for more than 25 intervals means the device lacks sustained connectivity.

[0063] The message content unit that verifies the sequence number and statistical timer in the data increments as expected can have low AoT and high AoD. For example, all telemetry data needs to be protocol-converted and key-value pairs are queried using a stream analysis process. For example, the stream analysis process can verify the data based on knowledge that the sequence number should increment, and process counters and timers should be changed appropriately (e.g., shifted up, shifted down, or left unchanged based on the measured attribute).

[0064] Statistical verification of physical telemetry units can have low AoT and high AoD. For example, vehicle battery voltage or other measurements have a specific statistical distribution that varies over time. For example, a given metric on a device can be expected to change over time. Therefore, if the system determines that devices report the same value for a given metric over a period of time, the system can determine that this indicates a device that is not worthy of trust (e.g., a counterfeit or malicious device), and can generate an untrusted atom accordingly. More generally, embodiments may take into account known limitations of devices of a given device type in determining whether individual devices behave in the expected manner.

[0065] Duplicate identifiers, such as serial numbers or MAC addresses, can have low AoD (Average Distrust) values. Duplicate MAC addresses or serial numbers may exist due to manufacturing defects or malicious actors “faking” MAC addresses or serial numbers for DoS attacks. Since the actual (i.e., non-spoofed) device cannot be identified, all devices with copies may accumulate untrust atoms. If one of the copies is already trusted, it does not need to accumulate untrust atoms because it is assumed to have performed correctly over a long period, ensuring it is a genuine device. In this case, newly attempted devices may be untrusted and have a high untrust weight. As another possible variation, a single user with multiple duplicate MAC addresses is likely a malicious actor, and all devices associated with that user may be disabled.

[0066] Message content inspection can have a high AoD (Aspect of Dependency). This characteristic requires each message to contain a predetermined number of data items, as determined by the system. If a message is not sufficiently "different" from previous messages, untrusted atoms may accumulate.

[0067] In one embodiment, the system can perform a stimulus-response test on the device to generate a trust atom or a non-trust atom. For example, the system can generate the occurrence of a stimulus event for the device and monitor the device's behavior to determine how the device responds to the stimulus event. If the device responds in the expected manner and within the expected amount of time, the system can generate a trust atom for the device; similarly, if the device responds unexpectedly and / or does not respond for a time period consistent with the device type (e.g., within a time period determined by analyzing historical performance data collected from other devices of the same device type in the control environment), the system generates a trust atom. Examples of stimulus events include, but are not limited to, network messages sent to the first device, predefined sensor data sent to the first device, and physical events that manually cause a first physical event type to occur (e.g., manually turning on a physical light switch or pressing a physical button), wherein the first device is configured to monitor the occurrence of events of the first physical event type.

[0068] Figure 6A , Figure 6B and Figure 6C Examples of state diagrams, flowcharts, and sequence diagrams illustrating the trust state evolution for establishing and maintaining secure device communication are shown. The process of establishing or maintaining a secure device connection begins with the device or receiving a registration request message. When a device is provided with brown zone provisioning services, it can start with a trust weight of zero. Each acquired AoT adds a trust weight through the weight of the AoT. Some AoTs are binary (present or absent), while others have integer values ​​whose weights change over time. There may be a trial period; if a device does not reach the trust threshold from provisioning to the end of the trial, it is assumed to be untrusted and removed from the system (de-provisioning and de-registration). If a device is removed from the system, the entire registration and trial process can be repeated; however, the number of allowed repetitions can be limited (e.g., 3 attempts before the device is permanently blacklisted). The need for devices that do not achieve trust within a specified time makes creating a slowly accumulating army of "potential" devices more challenging. A user with a device removed from the trust pool will receive an untrusted atom, as it may be a malicious user; users with a high level of untrust will not be allowed to register devices. If a device “gets” a high distrust score, it will be blacklisted. If the device is a brown zone device, other devices owned by the user will also be blacklisted.

[0069] Any general-purpose computer system used in the various embodiments of this disclosure may be, for example, a general-purpose computer, such as a general-purpose computer based on an Intel Pentium processor, Motorola PowerPC, Sun UltraSPARC, HP PA-RISC processor, or any other type of processor.

[0070] For example, various embodiments of this disclosure can be implemented in, for example... Figure 7 Specialized software executing in the general-purpose computer system 700 shown. The computer system 700 may include a processor 720 connected to one or more memory devices 730 (e.g., disk drives, memory, or other devices for storing data). The memory 730 is typically used to store programs and data during operation of the computer system 700. The computer system 700 may also include a storage system 750 providing additional storage capacity. Components of the computer system 700 may be coupled via an interconnect mechanism 740, which may include one or more buses (e.g., between components integrated within the same machine) and / or networks (e.g., between components residing on separate, discrete machines). The interconnect mechanism 740 enables the exchange of communication (e.g., data, instructions) between system components of the system 700.

[0071] The computer system 700 also includes one or more input devices 710 (e.g., keyboard, mouse, trackball, microphone, touchscreen) and one or more output devices 760 (e.g., printer, display screen, speaker). Furthermore, the computer system 700 may include one or more interfaces (not shown) for connecting the computer system 700 to a communication network (as a supplement or alternative to the interconnect mechanism 740).

[0072] exist Figure 8 The storage system 750, shown in more detail below, typically includes a computer-readable and writable non-volatile recording medium 810, in which signals defining a program executed by a processor or information stored on or in the medium 810, are stored. This information is processed by the program to perform one or more functions associated with the embodiments described herein. The medium may be, for example, a magnetic disk or flash memory. Typically, in operation, the processor causes data to be read from the non-volatile recording medium 810 into another memory 820, which allows the processor to access information faster than the medium 810. The memory 820 is typically a volatile random access memory, such as dynamic random access memory (DRAM) or static random access memory (SRAM). As shown, it may be located in storage system 800 or in memory system 730. The processor 720 typically controls data within integrated circuit memories 730, 820 and then copies the data to the medium 810 after processing. Various mechanisms are known for managing data movement between the medium 810 and integrated circuit memory elements 730, 820, and this disclosure is not limited thereto. This disclosure is not limited to the specific memory system 730 or storage system 750.

[0073] Computer systems may include specially programmed special-purpose hardware, such as application-specific integrated circuits (ASICs). Aspects of this disclosure may be implemented using software, hardware, or firmware, or any combination thereof. Furthermore, methods, actions, systems, and their system elements and components may be implemented as part of or as independent components of the aforementioned computer system.

[0074] Although computer system 700 is shown as an example of a type of computer system on which various aspects of this disclosure can be practiced, it should be understood that aspects of this disclosure are not limited to such... Figure 8 This disclosure can be implemented on the computer system shown. Various aspects of this disclosure can be implemented on systems with... Figure 8 The different architectures or components shown are practiced on one or more computers. Furthermore, where the functions or processes of embodiments of this disclosure are described herein (or in the claims) as being executed on a processor or controller, such description is intended to include systems that use more than one processor or controller to perform the functions.

[0075] Computer system 700 can be a general-purpose computer system that can be programmed using high-level computer programming languages. Computer system 700 can also be implemented using specialized hardware that is specifically programmed. In computer system 700, processor 720 is typically a commercially available processor, such as the well-known Pentium-class processor available from Intel Corporation. Many other processors are also available. The operating system typically running on this processor can be, for example, Windows 95, Windows 98, Windows NT, Windows 2000, Windows ME, Windows XP, Vista, Windows 7, Windows 10, or a derivative operating system available from Microsoft Corporation; MAC OS X or a derivative operating system available from Apple Computer; Solaris operating system available from Sun Microsystems; UNIX; Linux (any distribution); or a derivative operating system available from various sources. Many other operating systems can be used.

[0076] The processor and operating system together define a computer platform, for which applications are written in high-level programming languages. It should be understood that embodiments of this disclosure are not limited to a specific computer system platform, processor, operating system, or network. Furthermore, it will be apparent to those skilled in the art that this disclosure is not limited to a specific programming language or computer system. Moreover, it should be understood that other suitable programming languages ​​and other suitable computer systems may also be used.

[0077] One or more parts of a computer system may be distributed across one or more computer systems coupled to a communication network. For example, as described above, the computer system determining available power capacity may be located remotely from the system manager. These computer systems may also be general-purpose computer systems. For example, various aspects of this disclosure may be distributed across one or more computer systems configured to provide services (e.g., servers) to one or more client computers, or to perform overall tasks as part of a distributed system. For example, various aspects of this disclosure may be implemented on a client-server or multi-tiered system that includes components distributed across one or more server systems performing various functions according to various embodiments of this disclosure. These components may be executable code, intermediate code (e.g., IL), or interpreted code (e.g., Java) that communicates over a communication network (e.g., the Internet) using a communication protocol (e.g., TCP / IP). For example, one or more database servers may be used to store device data, such as expected power consumption, for designing layouts associated with embodiments of this disclosure.

[0078] It should be understood that this disclosure is not limited to execution on any particular system or group of systems. Furthermore, it should be understood that this disclosure is not limited to any particular distributed architecture, network, or communication protocol.

[0079] Figure 9 This is a flowchart illustrating a method for generating a security profile for a device according to one embodiment described herein. As shown, method 900 begins at block 910, where middleware portal 400 determines multiple characteristics of a first device of a first device type. Middleware portal 400 analyzes these multiple characteristics against an expected set of characteristics for the first device type (block 915). Additionally, middleware portal 400 monitors the runtime behavior of the first device within a time window to collect runtime behavior data of the first device (block 920). Middleware portal 400 analyzes the runtime behavior data of the first device to determine whether the device is operating in a manner consistent with the first device type (block 925). Upon determining that the analyzed multiple characteristics are consistent with the expected set of characteristics and that the first device is operating in a manner consistent with the first device type, middleware portal 400 generates a security profile for the first device designating it as a trusted device (block 930), and method 900 ends.

[0080] Figure 10This is a flowchart illustrating a method for calculating a trust metric and associating the trust metric with a device according to an embodiment described herein. As shown, method 1000 begins at box 1010, where a user initiates a device provisioning process via a user terminal. The device requests provisioning from a middleware portal (box 1015). The middleware portal requests user identity information from the user (box 1020), and the user logs in to the IDMS using login credentials (box 1025). The IDMS verifies the user's identity and sends an instruction to the middleware portal confirming the validity of the user's identity (box 1030). The middleware portal determines the device's trust atoms and untrust atoms and calculates the device's aggregate trust metric (box 1035). The IoT cloud platform stores the device's trust metric (box 1040). As shown, boxes 1035 and 1040 may be repeated as the middleware portal continues to monitor the device's real-time behavior and attributes and continues to update the device's atomic and aggregate trust metrics. At box 1045, the IoT cloud platform associates the device data collected by the device with the trust metric and processes the device data accordingly. For example, if the aggregate trust metric indicates that a device is determined to be trustworthy, the IoT cloud platform can process the data collected by the IoT device in essentially the same way as data collected by certified green zone devices. As another example, if the aggregate trust metric indicates that a device is behaving anomalously or is otherwise determined to be untrustworthy, the IoT cloud platform can mark the data collected by the device as untrustworthy and exclude that data from visualizations, events, alerts, etc., generated by the IoT cloud platform. Of course, such examples are provided merely for illustrative purposes, and more generally, any appropriate actions considered in relation to trustworthy or untrustworthy devices within an IoT system can be performed by an IoT cloud platform consistent with the functionality described herein.

[0081] Figure 11 This is a flowchart illustrating a method for generating a trust level metric and associating the trust level metric with a device according to an embodiment described herein. As shown, method 1100 begins at box 1110, where a middleware portal monitors the behavior of the device within a time window to determine multiple runtime behavioral characteristics of the device. The middleware portal determines multiple device characteristics of the device, including at least the device's MAC address and serial number (box 1115). The middleware portal further determines multiple user characteristics of the user requesting to register the device with the IoT system (box 1120).

[0082] The middleware portal generates trust levels for devices based at least in part on multiple runtime behavior characteristics, multiple device characteristics, and multiple user characteristics (box 1125). The middleware portal stores the trust levels associated with the devices (box 1130) and associates the trust levels with one or more data values ​​subsequently received from the devices (box 1135).

[0083] Various embodiments of this disclosure can be programmed using object-oriented programming languages ​​such as Smalltalk, Java, C++, Ada, or C# (C-Sharp). Other object-oriented programming languages ​​may also be used. Alternatively, functional, scripting, and / or logic programming languages ​​such as BASIC, ForTran, COBoL, TCL, or Lua may be used. Various aspects of this disclosure can be implemented in a non-programming environment (e.g., documents created in HTML, XML, or other formats that, when viewed in a browser program window, present aspects of a graphical user interface (GUI) or perform other functions). Various aspects of this disclosure can be implemented as programmable or non-programmable elements, or any combination thereof.

[0084] The embodiments of the systems and methods described above are typically described for relatively large data centers with a large number of equipment racks; however, embodiments of this disclosure can also be used for smaller data centers and facilities outside of data centers. Some embodiments may also involve a very small number of geographically distributed computers, rather than a specific architecture.

[0085] In the embodiments of this disclosure discussed above, the analysis results are described as being provided in real time. As those skilled in the art will understand, the use of the term "real time" does not imply that the results are immediately available, but rather that they are rapidly available, enabling designers to try out multiple different designs within a short period of time (e.g., a few minutes).

[0086] Various embodiments have been referenced in the foregoing. However, the scope of this disclosure is not limited to the specifically described embodiments. Rather, any combination of the described features and elements, whether or not associated with different embodiments, is contemplated for implementation and practice of the contemplated embodiments. Furthermore, while embodiments may achieve advantages over other possible solutions or prior art, whether a particular advantage is achieved by a given embodiment does not limit the scope of this disclosure. Therefore, the foregoing aspects, features, embodiments, and advantages are merely illustrative and should not be considered as elements or limitations of the appended claims unless expressly stated in the claims.

[0087] The various embodiments disclosed herein can be implemented as systems, methods, or computer program products. Therefore, aspects can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, which are collectively referred to herein as “circuit,” “module,” or “system.” Furthermore, aspects can take the form of computer program products embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0088] Any combination of one or more computer-readable media may be used. The computer-readable medium may be a non-transitory computer-readable medium. For example, a non-transitory computer-readable medium may be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. More specific examples (not an exhaustive list) of non-transitory computer-readable media may include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF (radio frequency), etc., or any suitable combination thereof.

[0089] Computer program code used to perform the operations of various aspects of this disclosure can be written in any combination of one or more programming languages. Furthermore, such computer program code can be executed using a single computer system or multiple computer systems communicating with each other (e.g., using a local area network (LAN), wide area network (WAN), the Internet, etc.). While the various features described above are illustrated with reference to flowchart illustrations and / or block diagrams, those skilled in the art will understand that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer logic (e.g., computer program instructions, hardware logic, combinations of both, etc.). Typically, computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus. Furthermore, using a processor to execute such computer program instructions produces a machine capable of performing the functions or actions specified in the blocks of the flowchart illustrations and / or block diagrams.

[0090] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and / or operation of various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, code segment, or code portion, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative embodiments, the functions marked in the blocks may occur in a non-linear order. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or sometimes the blocks may be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system or a combination of dedicated hardware and computer instructions that performs the specified function or action.

[0091] It should be understood that the above description is intended to be illustrative and not limiting. Many other examples of implementation will become apparent upon reading and understanding the above description. Although specific examples have been described in this disclosure, it should be recognized that the systems and methods of this disclosure are not limited to the examples described herein, but can be practiced with modifications within the scope of the appended claims. Therefore, the specification and drawings are to be considered illustrative and not limiting. Consequently, the scope of this disclosure should be determined by reference to the appended claims and the full scope of their equivalents.

Claims

1. A method for establishing and maintaining communication between security devices, comprising: Determine multiple characteristics of the first device of the first device type; The multiple characteristics are analyzed in accordance with the expected characteristic set of the first device type; Monitor the runtime behavior of the first device within a time window to collect runtime behavior data; Analyze the runtime behavior data of the first device to determine whether the first device is operating in a manner consistent with the first device type; as well as Once it is determined that the analyzed features are consistent with the expected feature set and the first device is running in a manner consistent with the first device type, a security profile is generated for the first device designating the first device as a trusted device. The characteristics of the first device that determine the first device type include: Obtaining manufacturing data related to a first characteristic among the plurality of characteristics of the first device, wherein analyzing the plurality of characteristics against an expected characteristic set for the first device type further includes: The second characteristic is verified using the acquired manufacturing data and predefined logic that correlates the manufacturing data with a second characteristic among the plurality of characteristics. Obtaining manufacturing data related to a first characteristic among the plurality of characteristics of the first device further includes: Determine the Media Access Control (MAC) address of the first device; By querying data storage using at least the MAC address of the first device, a time window for manufacturing the first device during that period is determined; and Determine the range of serial numbers assigned to the device during the time window, and Verifying the second characteristic among the plurality of characteristics further includes: The serial number is verified by determining whether the serial number assigned to the first device is within the range of serial numbers assigned to the device during the time window.

2. The method of claim 1, wherein monitoring the runtime behavior of the first device within a time window to collect runtime behavior data further comprises: Monitor the network traffic generated by the first device on the data communication network. The analysis of the runtime behavior data of the first device further includes determining whether the network traffic generated by the first device is consistent with the type of the first device in terms of quantity and composition.

3. The method of claim 1, wherein monitoring the runtime behavior of the first device within a time window to collect runtime behavior data further comprises: Monitor computing resources used on the first device during the time window, wherein the computing resources include at least one of processor resources and memory resources. The analysis of the runtime behavior data of the first device further includes determining whether the computing resources used by the first device are consistent with the historical computing resource usage of devices of the first device type, and Once the first device has reached a trial trusted state or a fully trusted state, the process of monitoring the runtime behavior of the first device within a time window to collect runtime behavior data is executed.

4. The method of claim 1, wherein generating the security profile designating the first device as a trusted device for the first device further comprises: The first trust level of the first device is transitioned to a second trust level using predefined state transition logic, wherein the first trust level and the second trust level are selected from a plurality of predefined trust levels.

5. The method of claim 4, further comprising: When the first device is assigned the second trust level, it receives one or more data records collected by the first device through a data communication network; Associate the assigned second trust level indication with the one or more data records; as well as The one or more data records are processed at least in part based on the associated indication of the assigned second trust level.

6. The method of claim 5, wherein processing the one or more data records further comprises at least one of the following: Store the one or more data records together with the associated indication of the assigned second trust level; and A predefined action is taken based on one or more data values ​​in the one or more data records and the associated indication of the assigned second trust level.

7. The method of claim 6, wherein taking the predefined action comprises at least one of the following: (i) generating an automatic alarm based on the one or more data values ​​satisfying one or more predefined conditions, and (ii) merging the one or more data values ​​into a data model based on the corresponding assigned trust level exceeding a predefined minimum trust threshold.

8. The method of claim 4, wherein the predefined plurality of trust levels includes at least an untrusted level, a trusted level, a trial trusted level, and a blacklist level.

9. The method of claim 8, further comprising: Determine a second plurality of characteristics of the first device of the first device type; The second plurality of characteristics are analyzed in accordance with the expected characteristic set of the first device type; Monitor the subsequent runtime behavior of the first device within the second time window to collect second runtime behavior data; Analyze the second runtime behavior data of the first device to determine whether the first device is operating in a manner consistent with the first device type; as well as If it is determined that at least (i) one or more of the analyzed characteristics are inconsistent with the expected characteristic set, and (ii) the first device is operating in a manner inconsistent with the first device type: Generate a second security configuration file for the first device, designating the first device as a blacklisted device.

10. The method of claim 1, wherein monitoring the runtime behavior of the first device within a time window to collect runtime behavior data further comprises: Generate a stimulus event for the first device; as well as The behavior is monitored periodically in response to the stimulus event and the behavior of the first device. Analyzing the runtime behavior data of the first device to determine whether the first device is operating in a manner consistent with the first device type further includes: Determine whether the behavior of the first device and the timing of the behavior are consistent with the type of the first device.

11. The method of claim 10, wherein generating the occurrence of the stimulus event further comprises at least one of: (i) sending a network message to the first device, (ii) sending predefined sensor data to the first device, and (iii) manually causing a physical event of a first physical event type to occur, wherein the first device is configured to monitor the occurrence of an event of the first physical event type.

12. The method of claim 11, wherein determining whether the behavior of the first device and the timing of the behavior are consistent with the first device type further comprises: Based on the expected behavior patterns of devices of the first device type, determine one or more expected responses of the first device; Based on the expected behavior pattern, determine the timing of the one or more expected responses; as well as Based on the monitored behavior of the first device, determine whether the one or more expected responses are executed according to the time schedule.

13. A system for establishing and maintaining communication between security devices, comprising: One or more computer processors; as well as A non-transitory computer-readable storage medium containing computer program code, wherein when the computer program code is executed by operations of the one or more computer processors, the computer program code performs operations, including: Determine multiple characteristics of the first device of the first device type; The multiple characteristics are analyzed in accordance with the expected characteristic set of the first device type; Monitor the runtime behavior of the first device within a time window to collect runtime behavior data; Analyze the runtime behavior data of the first device to determine whether the first device is operating in a manner consistent with the first device type; and Once it is determined that the analyzed features are consistent with the expected feature set and the first device is running in a manner consistent with the first device type, a security profile is generated for the first device designating the first device as a trusted device. The characteristics of the first device that determine the first device type further include: Determine the Media Access Control (MAC) address of the first device; By querying data storage using at least the MAC address of the first device, a time window for manufacturing the first device during that period is determined; and Determine the range of serial numbers assigned to the device during the time window. The analysis of the multiple characteristics in comparison with the expected characteristic set of the first device type further includes: The serial number is verified by determining whether the serial number assigned to the first device is within the range of serial numbers assigned to the device during the time window.

14. The system of claim 13, wherein monitoring the runtime behavior of the first device within a time window to collect runtime behavior data further comprises: Monitor the network traffic generated by the first device on the data communication network. The analysis of the runtime behavior data of the first device further includes determining whether the network traffic generated by the first device is consistent with the type of the first device in terms of quantity and composition.

15. The system of claim 13, wherein generating a security profile for the first device designating the first device as a trusted device further comprises: The first device transitions from a first trust level to a second trust level using predefined state transition logic. The first and second trust levels are selected from a plurality of predefined trust levels, which include at least an untrusted level, a trusted level, a trial trusted level, and a blacklist level. The operation further includes: When the first device is assigned the second trust level, it receives one or more data records collected by the first device through a data communication network; Associate the assigned second trust level indication with the one or more data records; and Processing the one or more data records, at least in part, based on the associated indication of the assigned second trust level, includes: Store the one or more data records together with the associated indication of the assigned second trust level; and Based on one or more data values ​​within the one or more data records and the associated indication of the assigned second trust level, a predefined action is taken, wherein taking the predefined action includes at least one of the following: (i) generating an automatic alert based on the one or more data values ​​satisfying one or more predefined conditions, and (ii) merging the one or more data values ​​into the data model based on the corresponding assigned trust level exceeding a predefined minimum trust threshold.

16. The system of claim 15, further comprising: Determine a second plurality of characteristics of the first device of the first device type; The second plurality of characteristics are analyzed in accordance with the expected characteristic set of the first device type; Monitor the subsequent runtime behavior of the first device within the second time window to collect second runtime behavior data; Analyze the second runtime behavior data of the first device to determine whether the first device is operating in a manner consistent with the first device type; as well as If it is determined that at least (i) one or more of the analyzed characteristics are inconsistent with the expected characteristic set, and (ii) the first device is operating in a manner inconsistent with the first device type: Generate a second security configuration file for the first device, designating the first device as a blacklisted device.

17. A non-transitory computer-readable medium comprising computer program code, wherein when executed by operations of one or more computer processors, the computer program code performs operations, including: Determine multiple characteristics of the first device of the first device type; The multiple characteristics are analyzed in accordance with the expected characteristic set of the first device type; Monitor the runtime behavior of the first device within a time window to collect runtime behavior data; Analyze the runtime behavior data of the first device to determine whether the first device is operating in a manner consistent with the first device type; as well as Once it is determined that the analyzed features are consistent with the expected feature set and the first device is running in a manner consistent with the first device type, a security profile is generated for the first device designating the first device as a trusted device. The characteristics of the first device that determine the first device type further include: Obtaining manufacturing data related to a first characteristic among the plurality of characteristics of the first device, wherein analyzing the plurality of characteristics against an expected characteristic set for the first device type further includes: The second characteristic is verified using the acquired manufacturing data and predefined logic that correlates the manufacturing data with a second characteristic among the plurality of characteristics. Obtaining manufacturing data related to a first characteristic among the plurality of characteristics of the first device further includes: Determine the Media Access Control (MAC) address of the first device; By querying data storage using at least the MAC address of the first device, a time window for manufacturing the first device during that period is determined; and Determine the range of serial numbers assigned to the device during the time window, and Verifying the second characteristic among the plurality of characteristics further includes: The serial number is verified by determining whether the serial number assigned to the first device is within the range of serial numbers assigned to the device during the time window.

Images