Methods and devices for controlling endpoint communication in an industrial enterprise system based on integrity

Abstract

Device comprising: an integrity measurement comparator for comparing an integrity measurement with a reference value, wherein the integrity measurement is generated by a first endpoint in a first network of an industrial enterprise system based on a status of the first endpoint, wherein the reference value corresponds to a trusted status of the endpoint, wherein the status of the endpoint corresponds to at least one of software or firmware loaded on the endpoint, configuration data assigned to the endpoint, or hardware or peripherals coupled to the endpoint, and wherein the first endpoint corresponds to a group of second endpoints in a subnetwork of the first network, wherein the integrity measurement corresponds to a combination of different integrity measurements corresponding to the group of second endpoints in the subnetwork; and an authorization control device for enabling communication access for the endpoint to the network based on the comparison of the integrity measurement with the reference value.

Description

AREA OF REVELATION

[0001] This disclosure relates generally to industrial control, and more particularly to methods and apparatus for controlling the communication of endpoints in an industrial enterprise system based on integrity. BACKGROUND

[0002] Process control systems, such as those used in chemical, oil, or other industrial plants, typically include one or more process control devices communicatively connected to one or more field devices via analog, digital, or combined analog / digital buses. The field devices, which may include valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, and flow rate sensors), perform process control functions within the process, such as opening or closing valves and measuring process control parameters.The process control devices receive signals relevant to process measurements made by the field devices and then process this information and / or communicate the information to other control devices, workstations, or other components within the control system. Furthermore, multiple control systems may be subsystems of a higher-level enterprise system, where information from the separate subsystems is communicated among themselves and / or monitored by a supervisory system.

[0003] Relevant prior art is represented by the publications US 2012 / 0151206 A1 and DE 698 32 096 T2, each of which deals with checking the integrity of a network node. US 2012 / 0151206 A1 provides, in particular, guidance on performing a target-actual comparison of the status of an endpoint or node and on enabling communication based on this comparison. DE 698 32 096 T2 provides guidance on downgrading a node as a result of detecting that an error in the node exceeds a threshold. SUMMARY

[0004] Methods and apparatus for controlling communication of endpoints in an integrity-based industrial enterprise system are disclosed. An example apparatus includes an integrity measurement comparator for comparing an integrity measurement with a reference value. The integrity measurement is generated by an endpoint in a network of an industrial enterprise system based on a status of the endpoint. The reference value corresponds to a trusted status of the endpoint. The example apparatus also includes an authorization controller for enabling communication access for the endpoint to the network based on the comparison of the integrity measurement with the reference value.

[0005] An example method includes receiving a health measurement from an endpoint in a network of an industrial enterprise system. The health measurement is generated by the endpoint based on a status of the endpoint. The example method further includes comparing the health measurement to a reference value corresponding to a trusted status of the endpoint. The example method also includes enabling communication access to the network for the endpoint based on the comparison.

[0006] An example article of manufacture includes instructions that, when executed, cause a machine to receive at least one health measurement from an endpoint in a network of an industrial enterprise system. The health measurement is generated by the endpoint based on a status of the endpoint. The instructions further cause the machine to compare the health measurement to a reference value corresponding to a trusted status of the endpoint. The instructions also cause the machine to enable communication access for the endpoint to the network based on the comparison. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram of an exemplary hierarchy of components in an industrial enterprise system. Fig. 2 is a block diagram of an exemplary control system corresponding to the control system level of the exemplary hierarchy of Fig. 1. Fig. 3 is a block diagram of an exemplary supervisory system corresponding to the supervisory system level of the exemplary hierarchy of Fig. 1. Fig. 4 shows an exemplary implementation of the exemplary configuration module Fig. 2. Fig. 5 shows an exemplary implementation of the exemplary integrity measurement modules Fig. 2 and / or 3. Fig. 6 shows an exemplary implementation of the exemplary system integrity monitoring modules Fig. 2 and / or 3. Fig. 7 is a flowchart illustrating an exemplary method used to implement the exemplary configuration module of Fig. 2 and / or 4 can be performed. Fig. 8-10 are flowcharts illustrating exemplary methods used to implement the exemplary integrity measurement modules of Fig. 2, Fig. 3 and / or 5 can be carried out. Fig. 11-16 are flowcharts illustrating example methods used to implement the example system integrity monitoring modules of Fig. 2, Fig. 3 and / or 6 can be carried out. Fig. 17 is a schematic representation of an exemplary processor platform that may be used and / or programmed to implement the exemplary method of Fig. 7, and / or, more generally, to execute the exemplary configuration module from Fig. 2 and / or 4 to be implemented. Fig. 18 is a schematic representation of an example processor platform that may be used and / or programmed to perform the example methods of Fig. 8-10, and / or, more generally, to implement the exemplary integrity measurement modules from Fig. 2, Fig. 3 and / or 5 to be implemented. Fig. 19 is a schematic representation of an example processor platform that may be used and / or programmed to implement the example methods of Fig. 11-16, and / or, more generally, to execute the exemplary system integrity monitoring modules from Fig. 2, Fig. 3 and / or 6 to be implemented. DETAILED DESCRIPTION

[0007] When we refer to an industrial enterprise system here, we mean the raw materials and associated physical processes, the field equipment that interacts with such processes, the corresponding control systems that govern such processes, and the higher-level administrative systems of an industrial enterprise. Thus, an industrial enterprise system is a system of hierarchically related systems (e.g., there are multiple levels) that are usually connected via corresponding networks. When we refer to an industrial system computer endpoint (or endpoint) here, we mean any computer component that serves as a node in a network (at any level) within an industrial enterprise system to communicate with other such components. Thus, an endpoint here includes individual computer equipment (e.g.,Field devices, control devices, I / O devices, self-contained plug-in cards for control devices and / or I / O devices, workstations, servers, etc.), as well as systems or groups of such devices operating as an integrated whole subordinate system of a higher-level system (e.g., a modular control system within a larger control system, a control system within a supervisory system, etc.). Typically, the endpoints in an industrial enterprise system establish communication with each other based either on their configuration information (for more powerful endpoints) or on their physical connectivity (for less powerful endpoints).In the context of computer and data security, the establishment of communication between such endpoints is based on a form of implicit trust, because no endpoint truly knows whether the communication from other endpoints is secure and reliable or has been compromised by some kind of security breach or flaw. Specifically, the establishment of communication between endpoints for operating an industrial operation depends on each endpoint trusting that the other endpoint is (a) legitimate (i.e., that the other endpoint is truly what it claims to be) and (b) operating with full integrity (i.e., that the other endpoint is functioning properly and that the communication sent, as well as the data generated for that communication, has not been compromised).

[0008] For some well-known industrial system endpoints, trust in the security and / or reliability of communication is based on identifying information (e.g., serial numbers, hardware addresses, or IP addresses) associated with each endpoint and on knowledge of the communication protocol used for communication. While this serves to confirm the legitimacy of a specific endpoint (e.g., whether an endpoint is truly what it claims to be), such approaches are insufficient to provide reliable information about the integrity of each endpoint (e.g., whether an endpoint is functioning as expected or whether it has been compromised, thereby calling into question the reliability of its operation). Historically, integrity-based trust has largely been assumed based on assurances of product quality by the manufacturers of the computer endpoints involved in the communication.That is, manufacturers typically follow standards (e.g., International Organization for Standardization (ISO) 9000) that define quality assurance processes for the development and testing of software, firmware, and / or hardware. As a result, there is a certain level of confidence that the devices (e.g., endpoints) produced by such manufacturers will function according to their design specifications (i.e., with trusted integrity).

[0009] While manufacturers' quality assurances provide a certain level of confidence in the integrity of the computer equipment they produce, these assurances diminish over time due to the possibility of a security breach or other causes of failure after the equipment has left the manufacturer's control. For example, there is a possibility that a computer equipment may be tampered with between the time it is shipped by a manufacturer and delivered to an end user. Furthermore, even after an end user has received a computer equipment, there is a possibility that the equipment may be hacked and modified with malicious code.Although security measures are typically implemented to mitigate and / or detect such attacks, if a specific attack goes undetected, the malicious software may compromise the operation of the computing device. Consequently, confidence in the integrity of such a device and / or the communications sent from that device may be misplaced. Accordingly, there is a need to verify the integrity of endpoints when they are newly acquired, configured, and put into operation, as well as to monitor the integrity of endpoints in an industrial enterprise system over time to detect any potential threats to or defects in the integrity of such endpoints and to implement appropriate response measures based on any corresponding changes in the level of trust placed in communications from such endpoints.

[0010] The examples disclosed herein overcome the problems identified above by requiring endpoints in a network to provide computed or measured values ​​that are meaningful about certain aspects of their current state for comparison with known good values ​​corresponding to the endpoints' status in a trusted state (i.e., a state of integrity) before allowing the endpoints to communicate in the corresponding network. The measurements produced by an endpoint regarding its own state are referred to herein as integrity measurements. The integrity measurements are, in some examples, generated by computing one or more checksums about different aspects of the endpoint that may be meaningful about the operation, security, and / or reliability of the endpoint.Thus, in some examples, the integrity measurements are described herein as computed. That is, data associated with various aspects of the endpoint is passed through a cryptographic checksum algorithm to produce a value that can be used as an integrity measurement or to create an integrity measurement (along with checksums computed for other aspects of the endpoint). In some examples, the generation of the integrity measurements is based on the endpoint's software stack. In some examples, the generation of the integrity measurements is based on the endpoint's configuration within a control system. In some examples, the generation of the integrity measurements is based on the peripherals associated with the endpoint.In some examples, the generation of the integrity measurements is performed by a standalone security chip associated with the endpoint. Furthermore, in some examples, the generation of the integrity measurements occurs during boot time of the endpoint. In other examples, the generation of the integrity measurements occurs during runtime of the endpoint. In some examples, where the endpoint corresponds to a subsystem of multiple computing devices (e.g., endpoints), the integrity measurements are combinations of multiple lower-level integrity measurements associated with each individual device within the subsystem.

[0011] Each health measurement generated by an endpoint can be compared to corresponding baseline values ​​known to correspond to a trusted state of the endpoint. In some examples, the baseline values ​​are based on health measurements generated when an endpoint was first acquired, installed, and / or configured. In some examples, the baseline values ​​are defined based on values ​​provided by the endpoint manufacturer. If a comparison of the health measurements to the baseline values ​​indicates a match, the downstream endpoint is confirmed to be in a trusted state. This means that the software / firmware, hardware / peripherals, configuration, and / or other measured aspects of the endpoint are as expected, so communications from the endpoint are trusted and / or reliable.In such situations, the endpoint may be granted full communication access on an appropriate network based on its verified integrity. However, if the integrity measurements do not match the appropriate baseline values, the endpoint's integrity becomes suspect, and an appropriate response action can be implemented. In some of these examples, the type and / or level of communication access provided to the endpoint may be restricted and defined as something less than full communication access. In some examples, the level or type of communication access provided to an endpoint is determined based on authorization information provided by the upstream endpoint, which is used to generate or define secret and / or public values ​​or keys used to complete communication between endpoints.Such an integrity-based verification process can be implemented for new endpoints added to a network (to ensure that the endpoint is legitimate and functions as expected before it is registered and / or configured on the network) and / or can be applied to endpoints that are already in operation (to verify whether a previously configured endpoint has been compromised in a way that calls its integrity into question).

[0012] Fig. 1 is a block diagram of an exemplary hierarchy 100 of levels 102, 104, 106, 108, 110, 112 of a typical industrial enterprise system. The exemplary hierarchy of Fig. 1 follows the Purdue Reference Model outlined in ISA 95 (International Society of Automation 95). At the lowest level, the hierarchy 100 begins with the physical processes 102 of a manufacturing / processing enterprise. For example, in an industrial enterprise system, the physical processes 102 correspond to the processed materials and / or products, as well as the piping, tanks, heaters, conveyors, and / or other equipment assets that directly interact with the processed materials and / or products. The next higher level in the hierarchy is the facilities level 104. The facilities level 104 corresponds to intelligent and non-intelligent field devices that measure, monitor, and / or influence the physical process. For example, the facilities level 104 includes valves, actuators, temperature sensors, pressure sensors, and so on.

[0013] Furthermore, the equipment level 104 may include control devices and / or I / O devices that interact with and / or control the field devices. Such control devices and I / O devices serve as an interface between the equipment level 104 and the control system level 106, the next higher level in the hierarchy 100. The task of the control system level 106 is to directly supervise and control the field devices and thus control the physical processes. A control system at the control system level 106 may be a distributed control system (DCS), a supervisory and data acquisition system (SCADA), and / or another process control system.Typically, the control system level 106 includes one or more controllers and I / O devices directly connected to field devices associated with the device level 104. Furthermore, the control system level 106 typically includes one or more servers and / or one or more workstations providing a human-machine interface (HMI) that allows operators to configure, monitor, and / or adjust the control of the physical processes. Each of the controllers, I / O devices, workstations, and / or servers in a particular control system may be connected via a control system network, referred to herein as the control system's control network.

[0014] The supervisory system level 108 is the next higher level in the hierarchy 100 and represents the operations that serve to oversee the manufacturing / processing of the enterprise. Thus, the supervisory system level 108 typically includes a system of subsystems (e.g., corresponding to one or more control systems associated with the control system level 106) and one or more workstations and / or one or more servers for interacting with the subsystems. Such a system is referred to herein as a supervisory system. In some examples, a supervisory system may oversee the manufacturing / processing operations of a particular facility within an enterprise. Each of the workstations, servers, and other subsystems (e.g.,other control systems associated with the control system level 106) may be connected to the supervisory system via a network, referred to herein as a plant network or supervisory network of the supervisory system.

[0015] Above the supervisory system level 108 is the business system level 110, which corresponds to the business-related activities and decisions that govern and monitor all aspects of the enterprise. The highest level in the hierarchy 100 of the illustrated example corresponds to the Internet 112. Although technically the Internet is not a level within a specific enterprise, enterprise implementations often rely on communications accomplished over the Internet. As such, the Internet 112 is represented for explanatory purposes in a discussion of computer security and integrity because it relates to industrial enterprise systems.

[0016] About the length of the exemplary hierarchy 100 from Fig. 1 extends an integrity scale 114, representing the importance of the integrity or trustworthiness of computer endpoints at each level in the hierarchy 100 to achieving the intended business purpose. As shown in the example presented, higher levels of integrity are required at the hierarchical levels closer to the physical process, while integrity becomes less critical the farther away from the physical process a computer facility is implemented. For example, if the lowest-level operations in an enterprise (corresponding to the physical processes 102) cannot be trusted to perform as expected, there can be no trust in the resulting products being processed and / or manufactured, which is the primary purpose of the enterprise facility in the first place.However, the physical equipment assets and materials processed within the physical processes 102 typically correspond to piping, tanks, hoppers, and the like, as well as the associated raw materials. Thus, although the correct operation of the physical processes 102 is critical to an industrial enterprise system, from a computer and data integrity perspective, the facility level 104 is the most important level. The facility level 104 is the most important (i.e., the integrity of the corresponding facilities (e.g., field facilities, control facilities, I / O facilities, etc.) is most important) because it corresponds to the computer facilities or endpoints closest to and directly interacting with the physical processes 102.

[0017] The next most critical level in the hierarchy 100 from an integrity perspective is the control system level 106, because a control system defines the configuration and implementation of the control devices, I / O devices, and field devices at the device level 104. Decisions made at the supervisory system level 108 typically do not directly impact the physical processes, so this level is less critical in terms of integrity. The degree of integrity required at each subsequent level decreases progressively as one moves away from the physical processes 102 until the Internet is reached, where integrity is not important, or at least cannot be expected, because the Internet 112 is an open network to which virtually anyone can connect and communicate.To ensure and maintain the integrity of endpoints implemented at lower levels in the hierarchy 100, while still allowing communication between the levels, restrictions are imposed on communication between endpoints at lower levels of the hierarchy 100 and endpoints at higher levels. In particular, the nature or type of communication access, as well as the extent of communication (e.g., the number and types of other endpoints with which a first endpoint communicates), can be strictly controlled to reduce the likelihood that a particular endpoint will be corrupted (e.g., lose integrity due to a security breach). At the same time, communication is restricted and specially controlled to reduce the possibility that a potentially corrupted endpoint in a system will affect other endpoints.

[0018] In addition to controlling communication between endpoints to protect endpoints and reduce the likelihood of endpoints becoming corrupted, as described more fully below, in some examples, the integrity or trustworthiness of endpoints is tested at various points in time, specifically to identify any endpoints that may have been compromised, in order to proactively respond by restricting and / or completely denying communication from such endpoints. Briefly, in some examples, endpoints within a given level in the example hierarchy 100 request registration with and / or admission to a network one level higher in the hierarchy 100.To obtain approval to enable and / or permit full communication access, in some examples, a measurement provided by each endpoint that is meaningful regarding its current state must match a reference value that corresponds to the endpoint when it is in a trusted state (e.g., a state of integrity). If the measurements do not match the corresponding reference value, admission to communication may be denied entirely, or the endpoint may be placed in a remediation mode in which the nature and / or scope of communication is significantly restricted (e.g., limited to software / firmware updates). In some examples disclosed herein, integrity-based measurements are implemented before authorization for communication between endpoints at different levels in the hierarchy 100.In particular, the endpoints at lower hierarchical levels are tested for their integrity before enabling communication with higher hierarchical levels. For example, as indicated by arrow 116 in . Fig. 1, a field device or a corresponding control device and / or I / O device at the device level 104 may provide an integrity message about its current status that matches a corresponding reference value before the field device or the corresponding control device and / or I / O device can communicate on a control network of a control system at the control system level 106. Similarly, as indicated by the arrow 118 in Fig. 1, a control system at the control system level 106 may provide an integrity message about its current status that matches a corresponding reference value before the control system can communicate on a supervisory network of a supervisory system at the supervisory system level 108. This verification process of a lower-level endpoint (where integrity is critical) by a higher-level component (where integrity is less important) serves to ensure that the endpoints closest to the physical processes 102 are functioning as expected (i.e., with integrity).

[0019] Fig. 2 is a schematic representation of an exemplary control system 200 corresponding to the control system level 106 in the exemplary hierarchy 100 of Fig. 1. The exemplary control system 200 from Fig. 2 comprises one or more process control devices 202 and one or more I / O devices 204 which serve as an interface to the field devices 206, 208, 210, 212, 214 corresponding to the device level 104 of the hierarchy 100 from Fig. 1. In addition, the exemplary control system 200 comprises Fig. 2, one or more servers 216, and one or more operator stations, application stations, and / or workstations (collectively referred to herein as workstations). In the illustrated example, one workstation is designated within the control system 200 or serves as a configuration workstation 218, while another workstation serves as a primary workstation 220 (other workstations are represented by reference numeral 222). In the illustrated example, the example controller devices 202, the example I / O devices 204, the example servers 216, and the example workstations 218, 220, 222 are communicatively coupled via a communication bus and / or a local area network 224, generally referred to herein as a control network of the control system 200.

[0020] The exemplary configuration workstation 218 includes a configuration module (CM) 226 for generating a configuration file based on configuration data provided by an engineer, operator, and / or other personnel that defines all parameters and logic desired for implementing the devices (e.g., endpoints) within the control system 200. Once the configuration file is generated, the configuration workstation 218 transmits the configuration file to each of the endpoints of the control network 224 in the control system 200, thereby enabling each endpoint to be configured.

[0021] The exemplary primary workstation 220 includes a System Integrity Monitor (SIM) 228 for monitoring, authorizing, and / or controlling communication access from any endpoint in the control network 224 of the control system 200. That is, as described more fully below, the SIM 228 of the exemplary primary workstation 220 is comprised of Fig. 2 confirms and / or verifies the integrity of the other endpoints within the control system 200 to either permit or restrict communication access. In particular, in some examples, the SIM 228 receives from each endpoint one or more integrity measurements generated by an integrity measurement module (IMM) 230 associated with each endpoint. Once the integrity measurements are received by the SIM 228, the SIM 228 compares the integrity measurements to a database of reference values. If the measurements match the reference values, the corresponding endpoint is permitted full communication with other endpoints via the control network 224. Conversely, if the integrity measurements do not match the reference values, the SIM 228 may implement mitigation measures to restrict or deny access to the control network 224 for communication.In some examples, the SIM 228 of the primary workstation 220 monitors the health of the other endpoints of the control network 224 to detect any changes and respond accordingly. Although the primary workstation 220 and the configuration workstation 218 are depicted as separate workstations, in some examples, a single workstation may serve both functions (e.g., implement both the CM 226 and the SIM 228).

[0022] The exemplary control network 224 from Fig. 2 may be implemented using any desired communication medium or protocol. For example, the exemplary control network 224 may be based on a wired and / or wireless Ethernet communication scheme. However, any other suitable communication media and / or protocols may be used.

[0023] The exemplary I / O devices 204 from Fig. 2 are coupled to a plurality of intelligent field devices 210, 212, 214 via a digital data bus 232. The intelligent field devices 210, 212, 214 may be Fieldbus-compatible valves, actuators, sensors, etc., in which case the intelligent field devices 210, 212, 214 communicate over the digital data bus 232 using the well-known Foundation Fieldbus protocol. Of course, other types of intelligent field devices and communication protocols could also be used. For example, the intelligent field devices 210, 212, 214 could instead be Profibus and / or HART-compatible devices that communicate over the data bus 232 using the well-known Profibus and HART communication protocols.In addition to the exemplary intelligent field devices 210, 212, 214, one or more non-intelligent field devices 206, 208 may be communicatively coupled to the exemplary control device 201. The non-intelligent field devices 206, 208 of FIG. Fig. 2, for example, may be conventional 4-20 milliampere (mA) or 0-10 volt direct current (VDC) devices that communicate with the control device 202 via respective wired connections. Typically, the field devices 206, 208, 210, 212, 214 are designed with relatively limited processing power specified to implement their assigned functions. Accordingly, a field device may not implement an IMM 230 that generates an integrity measurement meaningful regarding a current status of the field device. However, in some examples, one or more of the field devices 206, 208, 210, 212, 214 may implement an IMM 230 in the same manner as the other devices mentioned above.In some such examples, the respective controller 202 or I / O device 2024 may implement a separate SIM that governs communication between the field devices 206, 208, 210, 212, 214 and the respective controller 202 or I / O device 204. In other such examples, the SIM 228 implemented by the primary workstation 220 may control communication access of such field devices.

[0024] While Fig. 2 illustrates an exemplary control system 200 in which the methods and apparatus for controlling communication admissions based on the integrity measurements described in detail below may be advantageously employed, one of ordinary skill in the art will readily appreciate that the advantageous use of the teachings disclosed herein may, if desired, also be employed in other control devices of greater or lesser complexity (e.g., with more than one control device, across more than one geographical location, etc.) than the illustrated example of Fig. 2 is possible.

[0025] Fig. 3 is a schematic representation of an exemplary supervisory system 300 corresponding to the supervisory system level 108 in the hierarchy 100 of Fig. 1. The exemplary supervision system 300 from Fig. 3, the control system 200 comprises Fig. 2 and a further control system 302 corresponding to the control system level 106 of the hierarchy 100 from Fig. 1. In addition, the exemplary supervisory system comprises 300 Fig. 3 one or more servers 304 and one or more workstations 306, 308. In the illustrated example, the control system 200, the servers 304 and the workstations 306, 308 are communicatively coupled via a communications bus and / or a local area network 310, which is generally referred to herein as a supervisory network for the supervisory system 300.

[0026] In the illustrated example, one of the workstations 306 operates as a primary workstation for monitoring and / or controlling the communication access of the other endpoints (e.g., the individual servers 304 and workstations 308 or the control systems 200, 302 as subsystems of the supervisory system 300) that operate in the same or similar manner as the primary workstation 220 in the control system 200. Fig. 2 are connected to the supervisory network 310. That is, in the illustrated example, the primary workstation 306 has a SIM 228 for receiving health measurements that are meaningful regarding the current status of the other endpoints and for comparing the measurements to reference values. In the illustrated example, the health measurements associated with the servers 304 and / or the workstations 308 are generated via corresponding IMMs in each of the servers 304 and / or the workstations 308. Although each control system 200, 302 can be treated as an endpoint (from the perspective of the supervisory system 300), the fact that the control systems 200, 302 represent a subsystem of multiple devices means that no single IMM can generate the health measurements to be analyzed by the SIM 228 of the primary workstation 306.Accordingly, in some examples, the SIM 228 of the primary workstation 306 within each control system (e.g., the primary workstation 220 of the control system 200 of FIG. Fig. 2) one or more health measurements that are meaningful regarding a status of the entire subsystem and provided to the SIM 228 of the primary workstation 306 of the supervisory system 300. In some examples, the health measurements for an entire control system (as an endpoint in a supervisory network) are based on a combination of the health measurements obtained from each of the IMMs 230 implemented at each endpoint of the control system's control network.

[0027] While Fig. 3 illustrates an exemplary supervisory system 300 in which the teachings disclosed herein may be advantageously employed, one of ordinary skill in the art will readily appreciate that the advantageous use of the teachings disclosed herein may, if desired, also be applied in other systems of greater or lesser complexity (e.g., having more control systems, across more than one geographical location, etc.) than the illustrated example of Fig. 3 is possible.

[0028] Fig. 4 illustrates an exemplary implementation of the exemplary configuration module (CM) 226 Fig. 2. In the illustrated example, the CM 226 includes an example user interface 402, an example configuration file generator 404, an example reference value generator 406, an example configuration database 408, and an example communication interface 410.

[0029] The exemplary CM 226 from Fig. 4 includes the example user interface 402 to enable interactions between the CM 226 and a configuration engineer and / or other user. In particular, a systems engineer can use the user interface 402 to assign parameters, define control logic, specify IP addresses, assign names for physical cards, and / or provide any other relevant configuration data required to configure each endpoint within the control system. The example configuration file generator 404 of the illustrated example takes the input configuration data and generates a configuration file for the project or control system to which the configuration data is to be applied. In some examples, the configuration data and the resulting configuration file are stored in the example configuration database 408.

[0030] In the example shown from Fig. 4, the CM 226 has the exemplary reference value generator 406 for calculating configuration reference values ​​for each endpoint in the control system 200 that is to be monitored for integrity based on the configuration file (e.g., an integrity measurement module (IMM)). That is, based on the illustrated example from Fig. 2, the exemplary configuration reference value generator 406 of the CM 266 generates reference values ​​for each of the controllers 202, the I / O devices 204, the servers 216, and the workstations 218, 220, 222. In some examples, the generation or calculation of the reference values ​​is performed as a cryptographic checksum of the configuration data associated with the specific endpoint of interest. In such examples, the calculated checksum values ​​correspond to the proper configuration of each endpoint because the checksum calculation is based on the original configuration file (developed by a systems engineer). Thus, these checksum values ​​(integrity measurements) can be used as a starting point or reference for comparing the actual configuration of the endpoint at a later time.Thus, when a particular endpoint later generates integrity measurements of its own configuration (calculates checksums), the generated integrity measurements should match the reference values. If the later generated integrity measurements do not match the corresponding reference values, there is a possibility that something has happened to the endpoint that has compromised its integrity because its configuration status is not as expected or originally defined. Additionally or alternatively, the reference value generator 406 can generate reference rules based on the configuration data according to the status of the hardware (peripherals) associated with each endpoint.

[0031] In the example shown from Fig. 4, the CM 226 includes the exemplary communications interface 402 for enabling communication between the CM 226 and the other endpoints in the control system 200. In some examples, once the configuration file is generated, it is transmitted to each endpoint via the communications interface 410 to enable configuration of each device according to the system engineer's design specifications. Furthermore, in some examples, the communications interface 410 is used to provide the generated reference values ​​to the System Integrity Monitor (SIM) module 228 of the primary workstation 220 for comparison with endpoint integrity measurements obtained at a later time.

[0032] While in Fig. 4 an exemplary implementation of the CM 226 from Fig. 2, one or more of the Fig. 4. Processes and / or devices may be combined, divided, rearranged, omitted, eliminated, and / or implemented in any other manner. Furthermore, the implementation of the exemplary user interface 402, the exemplary configuration file generator 404, the exemplary reference value generator 406, the exemplary configuration database 408, the exemplary communication interface 410, and / or, more generally, the exemplary CM 226 of Fig. 4 may be implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. Thus, for example, the implementation of each of the example user interface 402, the example configuration file generator 404, the example reference value generator 406, the example configuration database 408, the example communications interface 410, and / or, more generally, the example CM 226 could be implemented by one or more analog or digital circuits, logic circuits, programmable processors, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and / or field-programmable logic devices (FLDs).If any of the device or system claims of the present patent read as if they cover a purely software and / or firmware implementation, then at least one of the example user interface 402, the example configuration file generator 404, the example reference value generator 406, the example configuration database 408, and / or the example communications interface 410 is expressly defined to include a tangible computer-readable storage device or disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. for storing the software and / or firmware. In an even broader sense, the example CM 226 of FIG. Fig. 2 one or more elements, processes and / or facilities in addition to or instead of those in Fig. 4 and / or may contain more than one of all of the elements, processes and facilities shown.

[0033] Fig. 5 illustrates an exemplary implementation of an exemplary integrity measurement module (IMM) 230 Fig. 2 and / or 3. In the illustrated example, the IMM 230 includes an example integrity measurement generator 502, an example integrity measurement self-test device 504, an example integrity measurement controller 506, an example communication authenticator 508, an example communication interface 510, an example software measurement register 512, an example configuration measurement register 514, an example hardware measurement register 516, an example authorization information database 518, and an example configuration database 520.

[0034] In the example shown from Fig. 5, the IMM 230 is equipped with the example integrity measurement generator 502 to calculate or generate integrity measurements associated with the particular endpoint implementing the IMM 230. In some examples, the integrity measurements correspond to the software and / or firmware of the endpoint implementing the IMM 230 and are referred to herein as software integrity measurements. In some examples, generation of the software integrity measurements occurs during boot time when the software stack of the respective endpoint is loaded. In some such examples, as each piece of software is loaded, the integrity measurement generator 502 calculates a cryptographic checksum for the software and adds it to the example software measurement register 512 (e.g., appended to previously calculated checksum values).In some examples, once all software has been loaded (or before all software has been loaded), the resulting string of computed checksums may be passed through a hashing algorithm to facilitate management of the software integrity measurement (e.g., using less memory). In some examples, the IMM 230 is implemented as a hardware device (e.g., as a Trusted Platform Module) to be independent of the rest of the software implemented by the endpoint. Alternatively, in some examples where no separate security devices are available (e.g., in a pre-existing device), the IMM 230 may be implemented as software that is loaded onto the corresponding endpoint.

[0035] In some examples, the integrity measurements may alternatively or additionally correspond to the configuration of the endpoint implementing the IMM 230 and are referred to herein as configuration integrity measurements. As described above, a systems engineer or other personnel at the configuration workstation 218 may create a configuration file, which is then deployed to each endpoint in the control system 200. In some examples, the section of the system configuration file relevant to each specific endpoint is used to configure that endpoint. In some examples, once the endpoint has been configured, the parameters, logic, and / or other configuration data used to configure the endpoint are stored in the example configuration database 520 of the IMM 230.Thus, in some examples, a configuration integrity measure is generated by calculating a cryptographic checksum of each piece of configuration data in the configuration database 520 assigned to the corresponding endpoint. After the checksum for each piece of configuration data is calculated by the integrity measure generator 502, the checksum is appended to the previously calculated checksums in the corresponding configuration measure register 514. In some examples, a single checksum is calculated for the entire configuration file assigned to the endpoint. In other examples, multiple checksums are calculated for different sections of the configuration data and then combined (e.g., concatenated in a string). In some examples, separate configuration files may apply to separate layers in the software stack, and / or the endpoint may otherwise store multiple configuration files (e.g.,different versions). In some examples, a separate checksum is calculated for the configuration data associated with each configuration file, and then the resulting values ​​are concatenated. In some examples, once a checksum has been calculated for all configuration data (or before all configuration data has been analyzed), the resulting string of calculated checksums can be passed through a hashing algorithm to facilitate configuration integrity measurement management.

[0036] In some examples, the integrity measurements may alternatively or additionally correspond to the hardware associated with the endpoint implementing the IMM 230 and are referred to herein as hardware integrity measurements. In some examples, the hardware associated with an endpoint corresponds to the peripherals plugged into or otherwise coupled to the endpoint (e.g., I / O cards plugged into a controller). In some examples, a hardware integrity measurement is generated by calculating a cryptographic checksum for each peripheral associated with the endpoint. In some examples, the peripherals for which measurements (e.g., checksums) are to be generated are identified based on the configuration data stored in the configuration database 520.In some examples, the generation of the integrity measurements is based on the configuration file associated with the peripheral device. In other examples, in response to a request from the endpoint, the peripheral device provides a checksum value that is representative of its status. After the checksum for each peripheral device is calculated by the integrity measurement generator 502, each checksum is appended to the previously calculated checksums in the corresponding hardware measurement register 516. In some examples, once the checksums have been calculated for all (or part of) the hardware associated with an endpoint, the resulting string of calculated checksums can be passed through a hashing algorithm to facilitate hardware integrity measurement management.

[0037] In the example shown from Fig. 5, the IMM 230 is equipped with the exemplary integrity measurement self-test facility 504 to perform pre-tests of the functions used to generate the integrity measurements. That is, in some examples, the integrity measurement self-test facility 504 performs an internal test of the ability of the integrity measurement generator 502 to properly calculate the values ​​corresponding to the integrity measurements. For example, the integrity measurement self-test facility 504 may verify that the hash algorithms and checksum algorithms implemented by the integrity measurement generator 502 produce the expected outputs based on known inputs.

[0038] In the example shown from Fig. 5, the IMM 230 is equipped with the exemplary integrity measurement controller 506 to control various operations of the IMM 230. In some examples, the integrity measurement controller 506 communicates instructions or commands to other portions of the exemplary IMM 230 to control the operations of those portions. For example, the integrity measurement controller 506 instructs when to generate integrity measurements by the integrity measurement generator 502 and add the values ​​to the respective registers 512, 514, 516; when to report the integrity measurements via the communication interface 510; when to delete the stored integrity measurements from the registers 512, 514, 516, and so on.

[0039] In the example shown from Fig. 5, the IMM 230 is equipped with the exemplary communication authenticator 508 to authenticate and / or verify communication with other endpoints after obtaining full communication access to the corresponding control network. In some examples, full communication access is enabled by the SIM 228, which provides authorization information used by the endpoint to generate secret and / or public values ​​for digital signatures, encryption / decryption, authentication, and so forth.

[0040] In some examples, the authorization information used by the communication authenticator 508 is provided to the IMM 230 to enable full communication access after the endpoint's integrity has been confirmed or verified. For example, part of the initial configuration and commissioning of an endpoint includes rebooting the endpoint upon receiving a new configuration file. During the reboot, in some examples, the integrity measurement generator 502 generates software integrity measurements as described above. In some examples, configuration and / or hardware integrity measurements may also be generated. These integrity measurements are meaningful regarding the current state of the endpoint (i.e., at the time of the reboot).Once configured according to the configuration file, the newly deployed endpoint can request registration with and admission to the control system. Before admission to communicate over the control network is granted, the health measurements are compared with reference values. If the health measurements match the reference values, the endpoint is granted full communication access by providing it with the authorization information from which the secret and / or associated public values ​​are generated. In some examples, the authorization information is provided to other endpoints on the corresponding network, allowing all endpoints to communicate with the newly admitted endpoint (as well as with each other).

[0041] There is a possibility that a particular endpoint may become compromised in some way after initial configuration and after receiving authorization information granting the endpoint full communication access. Accordingly, in some examples, the integrity of the endpoints is monitored over time or verified at various points in time to detect any changes in the endpoint's state that are indicative of a loss of integrity (e.g., that it is no longer in a trusted state). In some examples, once a compromised endpoint is detected, new authorization information is distributed to all other endpoints to be used for future configuration.In this way, the compromised endpoint is denied full communication access in the future because the previously received authorization credentials are no longer valid. Furthermore, in some such examples, unique authorization credentials are provided to the compromised endpoint to place the endpoint into remediation mode and / or to enable limited communication access.

[0042] In some examples, the problem of an endpoint with suspect integrity using previously provided authorization information is resolved by the communication authenticator 508 encrypting the authorization information upon initial receipt in such a way that it can subsequently be decrypted and used only if the endpoint is in the same state as when the authorization information was initially received. Thus, if an endpoint is compromised in any way that affects its current state (indicated by a change in integrity measurements), the endpoint is no longer able to access (decrypt) the authorization information required to communicate with other endpoints.As a result, in some examples, communication from a compromised endpoint can be prevented without the SIM 228 having to detect the endpoint's loss of integrity.

[0043] Some messages sent by an endpoint contain reports of the health measurements for the endpoint. One challenge in network security is the problem of the lying endpoint. For example, in the case where the health of an endpoint is verified by comparing the health measurements to reference values ​​corresponding to a known trusted state, there is a possibility that an infected endpoint will simply repeat previously obtained health measurements that match the reference values, rather than providing health measurements generated from the actual and / or current state of the endpoint (which could indicate that the endpoint is infected). To address this problem, in some examples, a nonce (a unique, one-time use value) is provided to the IMM 230 with each request for health measurements.In some of these examples, the communication authenticator 508 combines the nonce with the integrity measurement when responding to the request, so that an endpoint can be detected that only reports pre-existing values ​​for the integrity measurement (without the nonce).

[0044] While in Fig. 5 an exemplary implementation of the IMM 230 from Fig. 2 and / or 3, one or more of the Fig. 5. Processes and / or devices may be combined, divided, rearranged, omitted, eliminated, and / or implemented in any other manner. Furthermore, the implementation of the exemplary integrity measurement generator 502, the exemplary integrity measurement self-test device 504, the exemplary integrity measurement controller 506, the exemplary communication authenticator 508, the exemplary communication interface 510, the exemplary software measurement register 512, the exemplary configuration measurement register 514, the exemplary hardware measurement register 516, the exemplary authorization information database 518, the exemplary configuration database 520, and / or, more generally, the exemplary IMM 230 may be Fig. 5 by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. Thus, for example, the implementation of each of the example integrity measurement generator 502, the example integrity measurement self-test device 504, the example integrity measurement controller 506, the example communication authenticator 508, the example communication interface 510, the example software measurement register 512, the example configuration measurement register 514, the example hardware measurement register 516, the example authorization information database 518, the example configuration database 520, and / or, more generally, the example IMM 230 could be implemented by one or more analog or digital circuits, logic circuits, programmable processors, application-specific integrated circuits (ASICs),programmable logic devices (PLDs) and / or field programmable logic devices (FLDs). If any of the device or system claims of the present patent read as if they cover a purely software and / or firmware implementation, at least one of the exemplary integrity measurement generator 502, the exemplary integrity measurement self-test device 504, the exemplary integrity measurement controller 506, the exemplary communication authenticator 508, the exemplary communication interface 510, the exemplary software measurement register 512, the exemplary configuration measurement register 514, the exemplary hardware measurement register 516, the exemplary authorization information database 518, and / or the exemplary configuration database 520 is hereby expressly defined asthat a tangible computer-readable storage device or disk such as a memory, a Digital Versatile Disk (DVD), a Compact Disk (CD), a Blu-ray Disk, etc., is included for storing the software and / or firmware. In an even broader sense, the exemplary IMM 230 of , Fig. 2 and / or 3 one or more elements, processes and / or facilities in addition to or instead of those in Fig. 5 and / or may contain more than one of all of the elements, processes and facilities shown.

[0045] Fig. 6 illustrates an exemplary implementation of the exemplary System Integrity Monitor (SIM) 228 modules. Fig. 2 and / or 3. In the illustrated example, the SIM 228 includes an example communication interface 602, an example integrity measurement comparator 604, an example authorization controller 606, an example integrity measurement generator 608, an example integrity measurement self-tester 610, an example integrity monitoring module controller 612, an example user interface 614, an example reference value database 616, an example integrity measurement database 618, an example authorization information database 620, an example software measurement register 622, an example hardware measurement register 624, and an example configuration measurement register 626.

[0046] In the example shown from Fig. 6, the SIM 228 includes the example communication interface 602 for enabling communication with other endpoints in the corresponding network. For example, the communication interface 602 of the SIM 228 sends requests for health measurements from other endpoints. Similarly, the example communication interface 602 receives reports of health measurements from the IMMs 230 of the other endpoints and / or from the SIM 228 of a primary workstation of a subsystem (e.g., of the control system 200 as an endpoint in the supervisory system 300). Thus, in some examples, the SIM 228 of a primary workstation of a control system may communicate the health measurements to a SIM 228 of a primary workstation of a supervisory system.

[0047] The exemplary SIM 228 from Fig. 6 includes the example integrity measurement comparator 604 for comparing the integrity measurements with reference values ​​stored in the example reference value database 616. In some examples, the reference values ​​are received and / or generated based on the configuration file created with the configuration module 226 of the configuration workstation 218. In some examples, the reference values ​​are received from a user manually entering the values ​​via the example user interface 614 based on values ​​provided by an original equipment manufacturer of the corresponding endpoint (e.g., included in the documentation shipped with the device and / or provided online). In this way, the values ​​are trusted at the time of manufacture, so any tampering with the devices during shipping can be detected.Additionally or alternatively, in some examples, some or all of the reference values ​​are based on health measurements generated by the IMMs 230 of the respective endpoints when the endpoints were initially configured, commissioned, and / or added to the respective network. In some such examples, an engineer and / or other user confirms the use of such health measurements as reference values. In this way, the engineer has a way to verify that each specific endpoint is correctly configured and functioning as expected if these values, at later times, correspond to what was used in testing the endpoint's health.

[0048] In the example shown from Fig. 6, the SIM 228 is equipped with the example authorization controller 606 to determine the appropriate communication authorization or access for each endpoint based on the results of comparing the reported integrity measurements with the stored reference values. In some examples, if the integrity measurements match the reference values, the authorization controller 606 provides authorization information to the endpoint and all other endpoints to enable communication between them. In some examples, the authorization information distributed to the other endpoints is also stored in the example authorization information database 620 for subsequent reference.

[0049] In some examples, if the integrity measurements do not match the corresponding reference values, the authorization controller 606 takes remedial action. In some examples, the remedial action includes denying communication access for the endpoint (e.g., by providing new authorization information to the other endpoints). In other examples, communication access for the endpoint is not completely denied but is restricted in some way. For example, the endpoint may be provided with unique authorization information that restricts the endpoint to communication access for firmware updates (e.g., the only communication that can be performed is related to updating the endpoint's firmware).In some examples, the endpoint may be provided with unique authorization information that restricts the endpoint to communication access for configuration (e.g., the only communication that can be performed is related to updating the endpoint's configuration). In some examples, communication from the endpoint may be permitted, but that communication is flagged. In some examples, the authorization controller 606 triggers an alarm and / or warning to notify a user of a potential loss of integrity. In some examples, in addition to preventing communication from a compromised endpoint, the authorization controller 606 provides authorization information to a redundant or failover endpoint that is to assume the role of the compromised endpoint.In some examples, the authorization controller 606 may implement any combination of the above-mentioned mitigations.

[0050] Additionally, in some examples, the authorization controller 606 generates nonce values ​​to be provided along with the requests for integrity measurements to be used by the corresponding IMM 230 in responding so that the responses from the endpoints can be verified as legitimate.

[0051] In the example shown from Fig. 6, the SIM 228 is equipped with the exemplary integrity measurement generator 608 to generate meaningful integrity measurements regarding the status of the integrity of the entire system of endpoints monitored by the SIM 228. In some examples, the generation of such system-wide integrity measurements is accomplished by combining the integrity measurements collected from each endpoint in the associated network monitored by the SIM 228. This combined integrity measurement may be reported to another SIM 228 on a workstation assigned to a higher level in the hierarchy 100. Fig. 1. In some examples, the integrity measurement generator 608 generates the combined integrity measurements by appending each integrity measurement reported by each endpoint in the network into the corresponding software, hardware, and configuration registers 622, 624, 626 and then calculating a checksum for the resulting string of values. In some examples, the SIM 228 requests the integrity measurements from each endpoint before generating the combined integrity measurements. Additionally or alternatively, the combined integrity measurements may be generated based on previously reported integrity measurements stored in the integrity measurement database 618.

[0052] In the example shown from Fig. 6, the SIM 228 is equipped with the exemplary integrity measurement self-test facility 610 to perform pre-tests of the functions used to generate the integrity measurements. That is, in some examples, the integrity measurement self-test facility 610 performs an internal test of the ability of the integrity measurement generator 608 to properly calculate the values ​​(e.g., checksums) corresponding to the integrity measurements. For example, the integrity measurement self-test facility 610 may verify that the hash algorithms and checksum algorithms implemented by the integrity measurement generator 608 produce the expected outputs based on known inputs.

[0053] In the example shown from Fig. 6, the SIM 228 is equipped with the example integrity monitoring module controller 612 to control various operations of the SIM 228. In some examples, the integrity monitoring module controller 612 communicates instructions or commands to other portions of the example SIM 228 to control the operations of those portions. For example, the integrity monitoring module controller 612 may maintain a schedule of when to request integrity measurements from the IMMs 230 from other endpoints. In some examples, the integrity monitoring module controller 612 controls and / or defines the order in which the various integrity measurements from the various endpoints are combined to generate the combined integrity measurements, because the order influences the resulting checksum value of the entire string.

[0054] While in Fig. 6 an exemplary implementation of the SIM 228 from Fig. 2 and / or 3, one or more of the Fig. 6, processes and / or devices may be combined, divided, rearranged, omitted, eliminated, and / or implemented in any other manner. Furthermore, the implementation of the exemplary communication interface 602, the exemplary integrity measurement comparator 604, the exemplary authorization controller 606, the exemplary integrity measurement generator 608, the exemplary integrity measurement self-test device 610, the exemplary integrity monitoring module controller 612, the exemplary user interface 614, the exemplary reference value database 616, the exemplary integrity measurement database 618, the exemplary authorization information database 620, the exemplary software measurement register 622, the exemplary hardware measurement register 624, the exemplary configuration measurement register 626, and / or, more generally, the exemplary SIM 228 may be Fig. 6 by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. Thus, for example, the implementation of each of the exemplary communication interface 602, the exemplary integrity measurement comparator 604, the exemplary authorization controller 606, the exemplary integrity measurement generator 608, the exemplary integrity measurement self-test device 610, the exemplary integrity monitoring module controller 612, the exemplary user interface 614, the exemplary reference value database 616, the exemplary integrity measurement database 618, the exemplary authorization information database 620, the exemplary software measurement register 622, the exemplary hardware measurement register 624, the exemplary configuration measurement register 626, and / or, more generally,of the exemplary SIM 228 by one or more analog or digital circuits, logic circuits, programmable processors, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and / or field-programmable logic devices (FLDs). If any of the device or system claims of the present patent read as if they cover a purely software and / or firmware implementation, then at least one of the exemplary communication interface 602, the exemplary integrity measurement comparator 604, the exemplary authorization controller 606, the exemplary integrity measurement generator 608, the exemplary integrity measurement self-test device 610, the exemplary integrity monitoring module controller 612,the example user interface 614, the example reference value database 616, the example integrity measurement database 618, the example authorization information database 620, the example software measurement register 622, the example hardware measurement register 624, and / or the example configuration measurement register 626 may be explicitly defined to include a tangible computer-readable storage device or disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc., for storing the software and / or firmware. In an even broader sense, the example SIM 228 of FIG. Fig. 2 and / or 3 one or more elements, processes and / or facilities in addition to or instead of those in Fig. 6 and / or may contain more than one of all of the elements, processes and facilities shown.

[0055] A flowchart illustrating an exemplary method for implementing the exemplary CM 226 of Fig. 2 is in Fig. 7. Flowcharts illustrating exemplary methods for implementing the exemplary IMM 230 of Fig. 2 and / or 3 are in Fig. 8-10. Flowcharts illustrating exemplary methods for implementing the exemplary SIM 228 of Fig. 2 and / or 3 are in Fig. 11-16. The methods may be implemented using machine-readable instructions that form programs for execution by a processor, such as processors 1712, 1812, 1910, illustrated in example processor platforms 1700, 1800, 1900, described below in connection with Fig. 17-19. The programs may be embodied in software stored on a tangible computer-readable storage medium such as a CD-ROM, a floppy disk, a hard disk, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, or memory associated with the processors 1712, 1812, 1910, but all and / or portions of the programs could alternatively be executed by a device other than the processors 1712, 1812, 1910 and / or be embodied in firmware or dedicated hardware. Furthermore, although the example programs may be described with reference to the Fig. 7-16, alternatively, many other methods may be used to implement the exemplary CM 226, the exemplary IMM 230, and the exemplary SIM 228. For example, the order of execution of the blocks may be changed, and / or some of the described blocks may be changed, eliminated, or combined.

[0056] As mentioned above, the exemplary methods can be Fig. 7-16 be implemented using coded instructions (e.g., computer- and / or machine-readable instructions) stored on a tangible computer-readable storage medium such as a hard disk, flash memory, read-only memory (ROM), compact disk (CD), digital versatile disk (DVD), cache, random-access memory (RAM), and / or any other storage device or storage medium on which information is stored for any length of time (e.g., for extended periods of time, permanently, for brief moments, for temporary buffering and / or caching of the information).When reference is made herein to a tangible computer-readable storage medium, this definition expressly includes any type of computer-readable storage device and / or computer-readable storage medium and excludes propagation of signals and excludes transmission media. As used herein, the terms "tangible computer-readable storage medium" and "tangible machine-readable storage medium" are used interchangeably. Additionally or alternatively, the example methods of . Fig. 7-16 be implemented by means of encoded instructions (e.g., computer- and / or machine-readable instructions) stored on a non-transitory computer- and / or machine-readable medium such as a hard disk, flash memory, read-only memory, compact disk, digital versatile disk, cache, random access memory, and / or any other storage device or storage medium on which information is stored for any length of time (e.g., for extended periods of time, permanently, for brief moments, for temporary buffering and / or caching of the information). When reference is made here to a non-transitory computer-readable medium, then by definition that expressly includes any type of computer-readable storage device and / or computer-readable storage medium and excludes the propagation of signals and excludes transmission media.If the term “at least” is used here as a transitional term in a generic term of a claim, then this is considered to be open in the same way as the term “comprehensive” is considered to be open.

[0057] Now referring in detail to the figures, Fig. 7 is a flowchart illustrating an exemplary method for implementing the exemplary configuration module (CM) 226 of Fig. 2 and / or 4. The example method begins in block 700, where the example user interface displays configuration data for a control system (e.g., the control system 200 of Fig. 2). In some examples, the configuration data corresponds to the totality of configuration parameters, logic, and inputs provided by an engineer to configure a control system. In block 702, the example user interface receives software and / or hardware reference values ​​for endpoints in the control system. In some examples, the software reference values ​​and the hardware reference values ​​correspond to values ​​entered by the engineer based on values ​​specified by the manufacturer(s) of the endpoint devices. In some examples, the software and / or hardware values ​​are collected at the same time as the configuration data. In other examples, the software and / or hardware data is collected separately from the configuration data. In some examples, no software and / or hardware reference values ​​are collected.In some examples, the software and / or hardware reference values ​​may be collected and / or generated at a later time, as described below.

[0058] In block 704, the example configuration file generator 404 generates a configuration file based on the configuration data. In block 706, the example reference value generator 406 generates reference values ​​for an endpoint in the control system based on the configuration file. In some examples, the reference values ​​are generated by calculating one or more checksums for the configuration file and / or portions thereof associated with the endpoint. In some examples, where software and hardware reference values ​​were received in block 702, the generated reference corresponds to the configuration reference values ​​for the corresponding endpoint. In some examples, the generated reference values ​​include hardware reference values ​​(e.g., where such values ​​are not defined by the user in block 702). In block 708, the configuration reference value generator 406 determines whether there is another endpoint with corresponding configuration data.If so, control returns to block 706 to calculate the appropriate configuration reference values ​​for the endpoint. Otherwise, control continues to block 710, where the example communication interface 410 transmits the configuration file to the endpoints of the control system. Based on this transmission, each endpoint may receive and / or download and instantiate the configuration file (or relevant portions thereof) and then reboot to complete the configuration process, as described in detail below. In block 712, the example communication interface 410 transmits the reference values ​​(e.g., the configuration reference values, software reference values, and / or hardware reference values) to a system integrity monitor (SIM) module (e.g., the SIM 228 of FIG. Fig. 2). The exemplary procedure ends Fig. 7.

[0059] Fig. 8 is a flowchart illustrating an example method for implementing the example integrity measurement module (IMM) 230 of Fig. 2, Fig. 3 and / or 5 to generate integrity measurements for an endpoint during boot time. The example method from Fig. 8 is executed when an endpoint implementing the IMM 230 is started (booted), for example, after receiving the configuration file, as described above in connection with block 10 of Fig. 7. In other examples, the endpoint restart may be based on a request provided by the SIM 228. In other examples, the endpoint restart may be performed manually. In block 802, the example integrity measurement self-test device 504 tests the integrity measurement functions of the IMM 230. For example, the integrity measurement self-test device 504 tests the checksum algorithm, hash algorithm, etc., to be used to generate integrity measurements based on known inputs and known outputs. In block 804, the example integrity measurement controller 506 determines whether the integrity measurement functions are functioning properly (e.g., whether the outputs are as expected). If not, the example method exits. Fig. 8. In some examples, the integrity measurement controller 506 generates an error message indicating that the test failed before the method ends. If the example integrity measurement controller 506 determines that the integrity measurement functions are functioning properly (block 804), control continues with block 806.

[0060] In block 806, the exemplary integrity measurement controller 506 clears all of the integrity measurement registers 512, 514, 516. In block 808, the exemplary integrity measurement generator 502 generates an integrity measurement for a software component (and / or firmware component) loaded onto the endpoint. For example, the integrity measurement generator 502 calculates a cryptographic checksum for the software component. In block 810, the exemplary integrity measurement controller 506 adds the integrity measurement to the exemplary software measurement register 512. In block 812, the exemplary integrity measurement controller determines whether there is another software component that needs to be loaded during the boot process. If so, control returns to block 808 where an integrity measurement for that software component is generated and then added to the software measurement register 512 (block 810).In some examples, the integrity measurements associated with subsequent software components are appended to the integrity measurements associated with previously generated integrity measurements for other software components at a lower position in the software stack (e.g., preloaded during boot time). In some examples, if the appended string of values ​​becomes too long for the software measurement register 512, the example integrity measurement generator 502 may perform a hashing algorithm on the combined values ​​to reduce them to a more manageable set. If the example integrity measurement controller determines that there is no more software to be loaded during the boot process (block 812), control continues with block 814. The combined integrity measurements for all software components (e.g.,after hashing) correspond to the final software integrity measurement for the endpoint, which can then be sent to the SIM 228 upon request.

[0061] At block 814, the example integrity measurement generator 502 generates an integrity measurement for configuration data assigned to the endpoint. For example, the integrity measurement generator 502 calculates a cryptographic checksum for the configuration file stored in the endpoint, or a portion thereof. At block 816, the example integrity measurement controller 506 adds the integrity measurement to the example configuration measurement register 514. At block 818, the integrity measurement controller determines whether there is additional configuration data. If so, control returns to block 814, where an integrity measurement is generated for that configuration data and then added to the configuration measurement register 514 (block 816).In some examples, the integrity measurements associated with subsequently analyzed configuration data are added to register 514 by appending them to the integrity measurements associated with previously generated integrity measurements for other configuration data. In some examples, if the appended string of values ​​becomes too long for configuration measurement register 514, example integrity measurement generator 502 may perform a hashing algorithm on the combined values ​​to reduce them to a more manageable set. If the example integrity measurement controller determines that there is no further configuration (block 818), control continues with block 820. The combined integrity measurements for all configuration data (e.g.,after hashing) correspond to the final configuration integrity measurement for the endpoint, which can then be sent to the SIM 228 upon request.

[0062] At block 820, the example integrity measurement generator 502 generates an integrity measurement for a peripheral of the endpoint. For example, the integrity measurement generator 502 calculates a cryptographic checksum for a peripheral identified in the corresponding configuration file for the endpoint. At block 822, the example integrity measurement controller 506 adds the integrity measurement to the example hardware measurement register 516. At block 824, the example integrity measurement controller determines whether there is another peripheral. If so, control returns to block 820, where an integrity measurement is generated for that peripheral and then added to the hardware measurement register 516 (block 816).In some examples, the health measurements associated with subsequent peripherals are added to register 516 by appending them to the health measurements associated with previously generated health measurements for other peripherals. In some examples, if the appended string of values ​​becomes too long for hardware measurement register 516, example health measurement generator 502 may perform a hashing algorithm on the combined values ​​to reduce them to a more manageable set (e.g., into a shorter string using less memory). The combined health measurements for all peripherals (e.g., after hashing) correspond to the final hardware health measurement for the endpoint, which may then be sent to SIM 228 upon request.If the example integrity measurement controller determines that there are no more peripheral devices (block 824), the example method of FIG. 12 ends. Fig. 8.

[0063] Fig. 9 is a flowchart illustrating an example method for implementing the example integrity measurement module (IMM) 230 of Fig. 2, Fig. 3 and / or 5 to generate integrity measurements for an endpoint during runtime. That is, the exemplary method from Fig. 9 occurs after an endpoint has been configured and approved for a network and is in operation. The example procedure from Fig. 9 begins in block 902, where the exemplary communication interface 510 receives a request from a system integrity monitoring module (e.g., the SIM 228 of Fig. 2, Fig. 3 and / or 6). In some examples, the request includes a nonce value to be used in generating the response. Further details regarding the SIM 228 and scenarios when such a request may be received are described below in connection with Fig. 11-13. In block 904, the exemplary integrity measurement self-test device 504 tests the integrity measurement functions of the IMM 230. In block 906, the exemplary integrity measurement controller 506 determines whether the integrity measurement functions are functioning properly (e.g., whether the outputs are as expected). If not, the exemplary method exits. Fig. 9. In some examples, the integrity measurement controller 506 generates an error message indicating that the test failed before the method ends. If the example integrity measurement controller 506 determines that the integrity measurement functions are functioning properly (block 906), control continues with block 908.

[0064] In block 908, the example integrity measurement controller 506 clears the configuration and hardware integrity measurement registers 514, 516. In some examples, the software measurement register 512 is used in conjunction with a runtime integrity measurement, as described in the example method of Fig. 9 is implemented, because software integrity measurements are generated when the endpoint loads software during boot time. In this way, previously collected software integrity measurements stored in software measurement register 512, which were generated during the last boot of the endpoint, may still be available for reporting purposes.

[0065] At block 910, the example integrity measurement generator 502 generates an integrity measurement for configuration data assigned to the endpoint. In some examples, the configuration data assigned to the endpoint is based on the configuration profile and / or portions thereof stored on the endpoint. At block 912, the example integrity measurement controller 506 adds the integrity measurement to the example configuration measurement register 514. At block 914, the integrity measurement controller determines whether there is additional configuration data. If so, control returns to block 910, where an integrity measurement is generated for this configuration data and then added to the configuration measurement register 514 (block 912).In some examples, the integrity measurements associated with subsequently analyzed configuration data are added to register 514 by appending them to the integrity measurements associated with previously generated integrity measurements for other configuration data. In some examples, if the appended values ​​become too long for configuration measurement register 514, example integrity measurement generator 502 may perform a hashing algorithm on the combined values ​​to reduce them to a more manageable set. If the example integrity measurement controller determines that there is no more configuration data (block 914), control continues with block 916. The combined integrity measurements for all configuration data assigned to the endpoint (e.g., after hashing) correspond to the final configuration integrity measurement for the endpoint.

[0066] At block 916, the example integrity measurement generator 502 generates an integrity measurement for a peripheral of the endpoint. At block 918, the example integrity measurement controller 506 adds the integrity measurement to the example hardware measurement register 516. At block 920, the integrity measurement controller determines whether there is another peripheral. If so, control returns to block 916, where an integrity measurement is generated for that peripheral and then added to the hardware measurement register 516 (block 918). In some examples, the integrity measurements associated with subsequent peripherals are added to the hardware measurement register 516 by appending them to the integrity measurements associated with previously generated integrity measurements for other peripherals.In some examples, if the appended values ​​become too long for the hardware measurement register 516, the example integrity measurement generator 502 may perform a hashing algorithm on the combined values ​​to reduce them to a more manageable set. The combined integrity measurements for all peripheral devices (e.g., after hashing) correspond to the final configuration integrity measurement for the endpoint.

[0067] If the example integrity measurement controller determines that there are no more peripherals (block 920), control continues to block 922, where the example communication interface 510 sends a report of the integrity measurements. In some examples, the reported integrity measurements include the software integrity measurements stored in the software measurement register 512 (previously generated during the last endpoint boot), the configuration integrity measurements stored in the configuration measurement register 514 (generated in block 912), and the hardware integrity measurements stored in the hardware measurement register 516 (generated in block 918). In some examples, the report of the integrity measurements is provided along with the nonce value provided with the request for the measurements. After reporting the integrity measurements, the example method ends. Fig. 9.

[0068] Fig. 10 is a flowchart illustrating an example method for implementing the example integrity measurement modules (IMM) 230 of Fig. 2, Fig. 3 and / or 5, to restrict the use of authorization information provided to an endpoint to circumstances when the endpoint is in a trusted state. As described above, communication is enabled via authorization information provided to an endpoint, from which the endpoint generates secret and / or public values ​​or keys. In some examples, the endpoint stores the authorization information in an encrypted form that can only be accessed (decrypted) when the endpoint is in the same state as when the authorization information was encrypted. In some examples, the authorization information is provided to the endpoint after the integrity of the endpoint has been verified, such that when the authorization information is encrypted, the endpoint is in a trusted state.Thus, in some examples, if an endpoint is compromised and therefore no longer in a trusted state (e.g., integrity measurements no longer match reference values), the endpoint is unable to use the authorization information because the endpoint cannot decrypt the authorization information. This allows communication from a potentially compromised endpoint to be prevented without requiring the endpoint to be specifically tested by a SIM 228, as described in more detail below.

[0069] The exemplary procedure from Fig. 10 begins when an endpoint implementing the IMM 230 is started (booted). In the illustrated example, this is a boot process after the IMM 230 has already been configured and has received authorization information stored in an encrypted form in the authorization information database 518. The exemplary method from Fig. 10 begins with block 1002, where the example integrity measurement generator 502 acquires boot-time integrity measurements (e.g., by implementing the example method of Fig. 8). In block 1004, the example communication authenticator 508 retrieves encrypted authorization information from the authorization information database 518. In block 1006, the example communication authenticator 508 attempts to decrypt the authorization information based on the boot-time integrity measurements. That is, in some examples, the communication authenticator 508 uses the status of the endpoint indicated by the integrity measurements to decrypt the encrypted authorization information.

[0070] In block 1008, the example communication authenticator 508 determines whether the authorization information was successfully decrypted. If so, this indicates that the endpoint's status corresponds to the expected integrity status (e.g., a trusted status), and the endpoint can access and use the authorization information to communicate. Accordingly, in block 1010, the example communication interface 510 uses the decrypted authorization information for communication within the control system. Thereafter, the example method ends. Fig. 10.

[0071] If the example communication authenticator 508 determines that the authorization information was not successfully deciphered (block 1008), control continues with block 1012. An unsuccessful attempt to decipher the encrypted authorization information indicates that something about the endpoint's status (as indicated by the health measurements) differs from the desired status (e.g., integrity) of the endpoint. In block 1012, the example health measurement controller 506 determines whether the configuration file is available. If so, control continues with block 1014, where the example communication interface 510 sends a request for admission to the control network. In some examples, this request may include the example method described below. Fig. 12. After that, the exemplary procedure ends Fig. 10. If, however, again in block 1012, the exemplary integrity measurement controller 506 determines that the configuration file is not available, control continues with block 1016 before the exemplary method of Fig. 10 ends. In block 1016, the example communication interface 510 sends a request to register with the control network. In some examples, this request corresponds to the beginning of the example method described below. Fig. 11.

[0072] Fig. 11 is a flowchart illustrating an example method for implementing the example system integrity monitoring module 228 of Fig. 2, Fig. 3 and / or 6 to verify the integrity of an endpoint that is registering for the first time in an associated control network. The example method begins in block 1102, where the example communication interface 602 receives a registration request from an endpoint. Registration of the endpoint refers to connecting and identifying the endpoint as a node or endpoint in the control network corresponding to the control system in which the endpoint is to be implemented, which has not been previously connected or does not have valid configuration data (e.g., the request in block 1016 of Fig. 10). In block 1104, the example communication interface 602 sends a nonce (e.g., generated by the example authorization controller 606) to the endpoint along with a request for software integrity measurements for the endpoint. In some examples, the nonce is used to detect a "lying endpoint" (e.g., an endpoint that simply repeats previously determined values). In the illustrated example, the endpoint is assumed to be a newly implemented device that has not yet been configured (or a device that no longer has valid configuration data), such that the corresponding configuration and / or hardware integrity measurements would not produce valid results that match the corresponding reference values. Thus, in the illustrated example, software integrity measurements are requested, while other types of integrity measurements (e.g.,Hardware and / or configuration integrity measurements) may not be requested. However, in some examples, the hardware and / or configuration integrity measurements may still be requested along with the software integrity measurements in block 1104.

[0073] In block 1106, the example communication interface 602 receives a report of the software integrity measurements. In some examples, the reported software integrity measurements correspond to any values ​​stored in the software measurement register 512 that were previously generated when the endpoint was first started, as described above in connection with Fig. 8. In block 1108, the example integrity measurement database 618 stores the reported software integrity measurements. In some examples, the integrity measurements are used for subsequent comparison to reference values ​​and / or for integrity verification of the entire control system (as an integrated whole) against a supervisory system, such as that described below in connection with Fig. 16 is described in more detail.

[0074] In block 1110, the example integrity measurement comparator 604 compares the software integrity measurements to software reference values. In some examples, the software reference values ​​were previously entered by a user via the user interface 614 based on data provided by the manufacturer of the endpoint device. In this way, the reference values ​​can be set independently of direct feedback from the endpoint, eliminating the possibility that the endpoint device has been tampered with after it leaves the manufacturer's possession and before the endpoint is connected to the network (e.g., during shipping). In some examples, the hardware and / or software configuration reference values ​​can also be entered by an engineer or other employee.In other examples, the software reference values ​​are obtained based on the initial software integrity measurements received in block 1106, as described in more detail below. Similarly, in some examples, the initial data for establishing the hardware and / or software configuration reference values ​​may be obtained from an initial calculation of the corresponding integrity measurements.

[0075] In block 1112, the example integrity measurement comparator 604 determines whether the reported integrity measurements match the reference values. If the reference values ​​were previously manually entered by a user and the endpoint has not been modified since leaving the manufacturer, the software integrity measurements should match the reference values. If so, control continues to block 1114, where the example authorization controller 606 authorizes the endpoint for communication access to the configuration. In some examples, communication access to the configuration enables the endpoint to receive configuration data to be used to configure the endpoint (e.g., based on the Fig. 7 configuration file described above).

[0076] If the integrity measurements do not match the reference values ​​(block 1112), control proceeds to block 1116, where the example integrity monitoring module controller 612 prompts an administrator to override the discrepancy. In some examples, the integrity measurements may not match the reference values ​​when an endpoint is first deployed (e.g., a newly acquired and / or installed device) and the reference values ​​were not previously manually entered via the user interface 614. Accordingly, a prompt provided in block 1116 allows an administrator to accept the initially reported integrity measurements as the new reference values ​​if they match the desired values. Thus, in block 1118, the example integrity monitoring module controller 612 determines whether the override is confirmed.If so, control continues with block 1120, where the example health monitoring module controller 612 assigns the reported health measurements as the new reference values. In this way, the software reference values ​​can be initially set based on the endpoint's health measurements without requiring manual entry of the values ​​as described above. Because the reported health measurements are assigned as the reference values ​​in block 1120, in such examples, the health measurements necessarily match the reference values, so control continues with block 1114 to authorize the endpoint for communication access to the configuration.

[0077] Once the endpoint has been authorized for communication access to the configuration (block 1114), the configuration file may be sent from the configuration module 226 to the endpoint as described above in connection with Fig. 7. A reboot of the endpoint may then be performed to complete the configuration process. This allows the endpoint to acquire valid configuration data so that the software, hardware, and configuration integrity measurements each reflect the proper status of the endpoint to verify the integrity of the endpoint. In block 1122, the example communication interface 602 receives a request for admission from the endpoint following a configuration reboot. Admitting the endpoint refers to allowing the endpoint to communicate (e.g., enabling communication) with other endpoints in this control network associated with the control system in which the endpoint is to be implemented and in which the endpoint is already registered (e.g., in block 1114 in response to the request for registration in block 1102).In block 1124, the example integrity monitoring module controller 612 verifies the integrity of the fully configured endpoint. An example method for verifying the integrity of the fully configured endpoint is described below in . Fig. 12. In block 1126, the example integrity monitoring module controller 612 determines whether there is another endpoint to be admitted to the control system's control network. If so, control returns to block 1102. Otherwise, the example method of FIG. Fig. 11.

[0078] Again, if at block 1118 the example integrity monitoring module controller 612 determines that the override is not confirmed (e.g., if the administrator does not want to use the software integrity measurement reported by the endpoint as the new baseline), control continues to block 1128, where the example authorization controller 606 restricts the endpoint to communication access for firmware updates. In some examples, communication access for firmware updates restricts the endpoint to receiving firmware updates but does not allow any other communication with the endpoint. After restricting communication access for the endpoint (block 1128), control continues to block 1126, where the example integrity monitoring module controller determines whether to terminate the example method or repeat it for another endpoint.

[0079] Fig. 12 is a flowchart illustrating an example method for implementing the example system integrity monitoring module 228 of Fig. 2, Fig. 3 and / or 6 to verify the integrity of an endpoint attempting to gain communication access in a control network of a control system. In particular, the exemplary method of Fig. 12 from block 1124 Fig. 11. The exemplary procedure from Fig. 12 begins in block 1202, where the example communication interface 602 sends a nonce (e.g., generated by the example authorization controller 606) to the endpoint along with a request for integrity measurements for the endpoint. In contrast to block 1104 of Fig. 11, where only software integrity measurements were requested, the exemplary communication interface 602 may request values ​​for the software, hardware, and configuration integrity measurements, respectively, because the endpoint is fully configured at this point and the reference value database 616 has all relevant reference values ​​for comparison with such integrity measurements. In some examples, the verification of the software ( Fig. 11) to ensure that the endpoint functions as expected when deployed by the manufacturer, before verifying that the endpoint has been properly configured for the specific application for which the endpoint is used ( Fig. 12). In some examples, the exemplary methods of Fig. 11 and Fig. 12 so that the software, hardware and configuration integrity of the endpoint are verified simultaneously.

[0080] In block 1204, the example communication interface 602 receives a report of the integrity measurements. In some examples, the integrity measurements are based on calculations performed during runtime. In some such examples, the reported software integrity measurements correspond to values ​​previously stored in the software measurement register 512 because no restart of the endpoint was performed to obtain new measurements. That is, the software integrity measurements may correspond to the values ​​previously generated when the endpoint was last restarted (e.g., immediately before block 1122 in Fig. 11). In contrast, in some examples, the hardware and configuration integrity measurements are regenerated during runtime. In block 1206, the example integrity measurement database 618 stores the reported integrity measurements.

[0081] In block 1208, the example integrity measurement comparator 604 compares the reported integrity measurements to reference values. In some examples, the reference values ​​correspond to the values ​​received in block 1102 and / or in block 1120 from Fig. 11. In block 1210, the example integrity measurement comparator 604 determines whether the reported integrity measurements match the reference values. If not, control continues to block 1212, where the example integrity monitor module controller 612 requests an administrator to override the discrepancy. In some examples, the request enables an administrator to accept the reported integrity measurements as the new reference values. In block 1214, the example integrity monitor module controller 612 determines whether the override is confirmed. If so, control continues to block 1216, where the example integrity monitor module controller 612 assigns the reported integrity measurements as the new reference values, after which control continues to block 1218.

[0082] In block 1218, the example authorization controller 606 authorizes the endpoint for full communication access by providing authorization information to the endpoint. In some examples, full communication access enables the endpoint to fully communicate with other endpoints within the control network in which the endpoint is implemented. In some examples, full communication access is enabled by providing the endpoint with authorization information that is used by the endpoint to generate secret and / or public values. Again, in block 1210, if the example integrity measurement comparator 604 determines that the reported integrity measurements do not match the reference values, control proceeds directly to block 1218.Once the endpoint has been authorized for full communication access (block 1218), the example method of FIG. 12 ends. Fig. 12 and returns to complete the exemplary procedure Fig. 11 back.

[0083] Again, if at block 1214 the example integrity monitoring module controller 612 determines that the overwrite is not confirmed (e.g., if the administrator does not want to use the reported integrity measurement as the new reference value), control continues to block 1220, where the example integrity measurement comparator 604 determines whether the reported software integrity measurements match the software reference values. If they do not, the software on the endpoint is suspect. Accordingly, control continues to block 1222, where the example authorization controller 606 restricts the endpoint to communication access for firmware updates. After restricting communication access for the endpoint (block 1222), the example method of Fig. 12 and returns to complete the exemplary procedure Fig. 11. Again, if in block 1220 the exemplary integrity measurement comparator 604 determines that the reported software integrity measurements do not match the software reference values, control continues with block 1224. In block 1224, the exemplary authorization controller 606 restricts the endpoint to communication access for configuration. Thereafter, the exemplary method of Fig. 12 and returns to complete the exemplary procedure Fig. 11 back.

[0084] Fig. 13 is a flowchart illustrating an example method for implementing the example system integrity monitoring module 228 of Fig. 2, Fig. 3 and / or 6, to verify the integrity of an endpoint in a control network of a control system during runtime. That is, during Fig. 11 and Fig. 12 represents an exemplary method for verifying the integrity of an endpoint that is initially set up and configured in a control network. Fig. 13 Verifying the integrity of the endpoint at a later time, while the endpoint is in operation and / or in service. This allows for the detection and appropriate response to potential security breaches that occur after the endpoint has been acquired, installed, and configured for use.

[0085] The exemplary procedure from Fig. Figure 13 begins at block 1302, where the example integrity monitoring module controller 612 determines whether it is time to verify the runtime integrity of an endpoint. Many computing devices (endpoints) in a control system may remain in operation for extended periods of time (e.g., months or years) without being powered down or rebooted. Thus, while the integrity of an endpoint during boot time is useful for confirming the state of the software stack (loaded at boot time), such tests are often not performed regularly enough to detect potential changes to the endpoint. Accordingly, in some examples, the user may define runtime integrity on a periodic or aperiodic schedule that is more regular and / or frequent. In some examples, runtime integrity measurements are performed once daily for each endpoint in a network.However, the runtime integrity tests can be implemented on any suitable schedule. Furthermore, in some examples, certain endpoints may be tested more frequently than others, depending, for example, on how critical the endpoint is to the control system in which it operates (e.g., hourly for critical endpoints). Additionally or alternatively, in some examples, only certain types of integrity measurements (software, hardware, or configuration) are requested at a given time. In some examples, a separate schedule may be applied for monitoring each of the software, hardware, and configuration integrity measurements.If the example integrity monitoring module controller 612 determines that it is not time to verify the runtime integrity of an endpoint (block 1302), the example integrity monitoring module controller 612 waits until it is time.

[0086] Once it is time to verify the runtime integrity of the endpoint, control proceeds to block 1304, where the example communication interface 602 sends a nonce (e.g., generated by the example authorization controller 606) to the endpoint along with a request for integrity measurements for the endpoint. In block 1306, the example communication interface 602 receives a report of the integrity measurements. In some examples, the integrity measurements are based on calculations performed during runtime. However, in some examples, the software integrity measurements are based on integrity measurements generated when the endpoint last rebooted, so no new software integrity measurements are created during runtime.Rather, in such examples, the software integrity measurements correspond to the values ​​previously generated when the endpoint was last restarted. In contrast, in some examples, the hardware and configuration integrity measurements are regenerated during runtime. At block 1308, the example integrity measurement database 618 stores the reported integrity measurements.

[0087] In block 1310, the example integrity measurement comparator 604 compares the reported integrity measurements with reference values. In block 1312, the example integrity measurement comparator 604 determines whether the reported integrity measurements match the reference values. If not, control continues to block 1314, where the example integrity monitoring module controller 612 implements a response based on the failed integrity measurements. In some examples, the specific response depends on which type of integrity measurements (e.g., software, hardware, and / or configuration) do not match the reference values. In some examples, the manner of the response depends on the nature of the endpoint and / or its configuration and relationship to other endpoints in the respective network.In some examples, the response includes generating an alert (block 1316), marking future data from the endpoint as suspect (block 1318), restricting the endpoint to communication access for firmware updates and / or communication access for configuration (block 1320), and / or switching to a redundant endpoint (block 1322). In some examples, the response includes a combination of more than one of blocks 1316, 1318, 1320, and 1322. In some examples, the implemented response is defined by a user when configuring the endpoint. After the appropriate response is implemented (block 1314), control continues with block 1324. Again, at block 1312, if the example integrity measurement comparator 604 determines that the integrity measurements match the reference values, the integrity of the endpoint is verified, and no further action is required.In such examples, control continues directly with block 1324.

[0088] In block 1324, the example integrity monitoring module controller 612 determines whether there is another endpoint that needs to be verified. If so, control returns to block 1302. Otherwise, control continues with block 1326, where the example integrity monitoring module controller 612 determines whether control should continue. If so, control returns to block 1302. Otherwise, the example method ends. Fig. 13.

[0089] The above-described Fig. 11-13 correspond to the implementation of the SIM 228 within a primary workstation of a control system (e.g., the control system 200 of Fig. 2), which in the control system level 106 of the hierarchy 100 consists of Fig. 1. This refers to Fig. 11-13 refer to the configuration- and integrity-based authorization of communication access for process control devices (e.g., control devices, I / O devices, field devices, etc.) at device level 104 of hierarchy 100 in a control network belonging to control system level 106 of hierarchy 100. Additionally or alternatively, Fig. 11-13 to the configuration and integrity-based authorization of communication between various endpoints (e.g., workstations, servers, etc.) at the control system level 106 over a control network belonging to the control system level 106. This, in some examples, Fig. 11-13 connected SIM 228 is implemented in a primary workstation designated for the control network for which communication is authorized (e.g., the primary workstation 220 from Fig. 2). Furthermore, in such examples, the IMM 230 is implemented in endpoints corresponding to specific devices communicatively coupled to the control network.

[0090] In contrast, the following Fig. 14-15 of the implementation of the SIM 228 within a primary workstation of a supervisory system (e.g., the supervisory system 300 of Fig. 3), which in the supervisory system level 108 of the hierarchy 100 consists of Fig. 1. This refers to Fig. 14-15 to the integrity-based authorization of communication access for endpoints in a supervisory system (e.g., the supervisory system 300 of Fig. 3), which belongs to the supervisory system level 108 of the hierarchy 100 Fig. 1, and / or between a subordinate system (e.g. the control systems 200, 302 from Fig. 3) at the control system level 106 and other endpoints at the supervisory system level 108. This, in some examples, in conjunction with Fig. 14-15 referenced SIM 228 is implemented in a primary workstation designated for the supervisory network for which communication is authorized (e.g., the primary workstation 306 of Fig. 3). Furthermore, in such examples, the endpoints to be admitted to the supervisory network 310 correspond to individual computing devices (e.g., workstations 308, servers 304, etc.) implementing an IMM 230. Additionally or alternatively, in some examples, the endpoints to be admitted to the supervisory network 310 correspond to a subordinate system for the supervisory system at the control system level 106 (e.g., the control system 200). In some such examples, the SIM 228 implemented in the primary workstation associated with the subordinate system (e.g., the primary workstation 220 of the control system 200) provides health measurements requested by the SIM 228 implemented in the workstation of the supervisory system, as described below in connection with Fig. 16 is described.

[0091] Fig. 14 is a flowchart illustrating an example method for implementing the example system integrity monitoring module 228 of Fig. 2, Fig. 3 and / or 6 to verify the integrity of an endpoint attempting to be admitted to a supervisory system. In the illustrated example, the SIM 228 corresponds to a SIM implemented in a primary workstation of the supervisory system (e.g., the primary workstation 306 of the supervisory system 300). The exemplary method of Fig. 14 begins at block 1400, where the example communications interface 602 receives a request to connect from an endpoint in the supervisory system. In some examples, the request comes from a particular endpoint (e.g., a workstation 308, a server 304, etc.) communicatively coupled to the supervisory system's supervisory network. In some examples, the request comes from a primary workstation of a subordinate system (e.g., primary workstation 220 of control system 200). At block 1402, the example communications interface 602 sends a nonce (e.g., generated by the example authorization controller 606) to the endpoint along with a request for integrity measurements for the endpoint.

[0092] At block 1404, the example communication interface 602 receives a report of the integrity measurements. In some examples, the integrity measurements for an endpoint at the supervisory system level 108 are generated by the IMM implemented by the endpoint in the same or similar manner as described above for an IMM implemented by an endpoint at the control system level 106. However, a supervisory system typically does not have a specifically designated configuration as does a control system. Accordingly, in some examples, the reported integrity measurements do not include configuration integrity measurements.On the other hand, in some examples where the endpoint corresponds to a control system, the integrity measurements may comprise a value corresponding to the combination of configuration integrity measurements from all endpoints within the control system, as described below in connection with . Fig. 16. In block 1406, the example integrity measurement database 618 stores the reported integrity measurements.

[0093] In block 1408, the example integrity measurement comparator 604 compares the reported integrity measurements to reference values. In block 1410, the example integrity measurement comparator 604 determines whether the reported integrity measurements match the reference values. If not, control continues to block 1412, where the example integrity monitoring module controller 612 requests an administrator to override the discrepancy. In block 1414, the example integrity monitoring module controller 612 determines whether the override is confirmed. If so, control continues to block 1416, where the example integrity monitoring module controller 612 assigns the reported integrity measurements as the new reference values.In block 1418, the example authorization controller 606 authorizes the endpoint for full communication access by providing authorization information to the endpoint. Again, in block 1410, if the example integrity measurement comparator 604 determines that the reported integrity measurements match the reference values, control proceeds directly to block 1418. In block 1420, the example integrity monitoring module controller 612 determines whether there is another endpoint. If so, control returns to block 1400. Otherwise, the example method of FIG. 14 ends. Fig. 14.

[0094] Again, if at block 1414 the example integrity monitoring module controller 612 determines that the override is not confirmed (e.g., if the administrator does not want to use the reported integrity measurement as the new reference value), control continues with block 1422. At block 1422, the example authorization controller 606 restricts the endpoint's communication access. In some examples, communication access is denied (i.e., no communication access is granted). In some examples, the endpoint is restricted to communication access for firmware updates. In other examples, communication may be allowed, but the data from the specific node is flagged or marked as suspect.In some examples, communication access may be granted to certain endpoints in the supervisory system while preventing communication to other endpoints. After restricting communication access for the endpoint (block 1422), control proceeds to block 1420, where the example health monitoring module controller determines whether there is another endpoint as described above.

[0095] Fig. 15 is a flowchart illustrating an example method for implementing the example system integrity monitoring module 228 of Fig. 2, Fig. 3 and / or 6, to verify the integrity of an endpoint in a supervision network of a supervision system during runtime. That is, during Fig. 14 represents an exemplary method for verifying the integrity of an endpoint that is initially admitted to the supervision system, Fig. 15 Verifying the integrity of the endpoint at a later time, while the endpoint is in operation and / or in service. This allows for the detection of potential security breaches that occur after the endpoint has been acquired, installed, and configured for use, and for appropriate action to be taken. As described above, the Fig. 15 illustrates an example of the SIM 228 of a SIM implemented in a primary workstation of a supervisory system (e.g., the primary workstation 306 of the supervisory system 300).

[0096] The exemplary procedure from Fig. 15 begins at block 1502, where the example integrity monitoring module controller 612 determines whether it is time to verify the runtime integrity of an endpoint. In some examples, the runtime integrity measurements are performed on a suitable periodic or aperiodic schedule. For example, the runtime integrity measurements may be requested once daily for each endpoint in a network. Furthermore, in some examples, certain endpoints may be tested more frequently than others, depending, for example, on how critical the endpoint is to the supervisory system in which the endpoint operates. If the example integrity monitoring module controller 612 determines that it is not time to verify the runtime integrity of an endpoint (block 1502), the example integrity monitoring module controller 612 waits until it is time.

[0097] Once it is time to verify the runtime integrity of the endpoint, control proceeds to block 1504, where the example communication interface 602 sends a nonce (e.g., generated by the example authorization controller 606) to the endpoint along with a request for integrity measurements for the endpoint. At block 1506, the example communication interface 602 receives a report of the integrity measurements. In some examples, the integrity measurements for an endpoint are generated at the supervisory system level 108 by the IMM implemented by the endpoint in the same or similar manner as described above for an IMM implemented by an endpoint at the control system level 106.However, in some examples, the health measurements do not include a configuration health measurement because supervisory systems typically do not have configuration files that define how the system should be configured. On the other hand, in some examples where the endpoint corresponds to a control system, the health measurements may include values ​​corresponding to the combination of configuration health measurements from all endpoints within the control system, as described below in connection with . Fig. 16. In block 1508, the example integrity measurement database 618 stores the reported integrity measurements.

[0098] In block 1510, the example integrity measurement comparator 604 compares the reported integrity measurements to reference values. In block 1512, the example integrity measurement comparator 604 determines whether the reported integrity measurements match the reference values. If not, control continues to block 1514, where the example integrity monitoring module controller 612 implements a response based on the failed integrity measurements. In some examples, the specific response depends on which type of integrity measurements (e.g., software, hardware, and / or configuration) do not match the reference values. In some examples, the manner of the response depends on the nature of the endpoint and / or its relationship to other endpoints in the corresponding network.In some examples, the response includes generating an alert (block 1516), marking future data from the endpoint as suspicious (block 1518), and / or restricting communication access for the endpoint (block 1520). In some examples, communication access is denied (i.e., no communication access is granted). In some examples, the endpoint is restricted to communication access for firmware updates. In other examples, communication may be allowed, but data from the specific node is marked or flagged as suspicious. In some examples, communication access may be allowed to certain endpoints in the supervisory system while communication to other endpoints is prevented. In some examples, the response includes a combination of more than one of blocks 156, 158, 1520, and 1522.In some examples, the implemented response is defined by a user when configuring the endpoint.

[0099] After the appropriate response has been implemented (block 1514), control continues with block 1522. Again, if in block 1512 the example integrity measurement comparator 604 determines that the integrity measurements match the reference values, the integrity of the endpoint is verified, and no further action is required. In such examples, control continues directly with block 1522. In block 1522, the example integrity monitoring module controller 612 determines whether there is another endpoint that needs to be verified. If so, control returns to block 1502. Otherwise, control continues with block 1526, where the example integrity monitoring module controller 612 determines whether control should continue. If so, control returns to block 1502. Otherwise, the example method ends. Fig. 15.

[0100] Fig. 16 is a flowchart illustrating an example method for implementing the example System Integrity Monitor (SIM) 228 of Fig. 2, Fig. 3 and / or 6 for generating combined integrity measurements for an endpoint belonging to a system of lower-level endpoints (e.g., the control system 200 as an endpoint in the supervisory system 300 of Fig. 3). That is, in the example shown from Fig. 16, the SIM 228 corresponds to a SIM that is implemented in a primary workstation of a control system (e.g., the primary workstation 220 of the control system 200) and that communicates with a primary workstation of a supervisory network (e.g., with the primary workstation 306 of the supervisory system 300). In other words, from the perspective of the primary workstation 306 of the supervisory system 300, the Fig. 6, SIM 228 implemented the task of reporting health measurements in the same or similar manner as the IMMs 230 described above. However, as described in more detail below, to generate such health measurements, SIM 228 must first receive or collect health measurements from the IMMs 230 implemented in lower-level endpoints monitored by SIM 228.

[0101] The exemplary procedure from Fig. 16 begins at block 1602, where the example communications interface 602 receives a nonce with a request from a system health monitoring module of a supervisory system for health measurements for an endpoint corresponding to a subordinate system (e.g., a control system within the supervisory system). In some examples, although the endpoint refers to an entire subsystem, the endpoint is effectively represented by a primary workstation in the subsystem implementing the SIM 228 that receives the request. In some examples, the nonce value provided along with the request is to be used in generating the response. At block 1604, the example health measurement self-tester 504 tests the health measurement capabilities of the SIM.In block 1606, the example integrity monitoring module controller 612 determines whether the integrity measurement functions are functioning properly (e.g., whether the outputs are as expected). If not, the example method of FIG. 12 ends. Fig. 16. In some examples, the integrity monitoring module controller 612 generates an error message indicating that the test failed before the method ends. If the example integrity monitoring module controller 612 determines that the integrity measurement functions are functioning properly (block 1606), control continues with block 1608.

[0102] In block 1608, the example integrity monitoring module controller 612 clears all of the integrity measurement registers 622, 624, 626. In block 1610, the example integrity monitoring module controller 612 adds the software integrity measurement from an endpoint in the subordinate system to the example software measurement register 622. In some examples, the software integrity measurement is obtained from the integrity measurement database 618, which previously received a request from the SIM 228 monitoring the corresponding endpoint. In other examples, the SIM 228 requests the software integrity measurement in response to the request received in block 1602. In block 1612, the example integrity monitoring module controller 612 adds the hardware integrity measurement from the endpoint in the subordinate system to the example hardware measurement register 624.In some examples, the hardware integrity measurement is obtained from the integrity measurement database 618, which previously received a request from the SIM 228 monitoring the corresponding endpoint. In other examples, the SIM 228 requests the hardware integrity measurement in response to the request received in block 1602. In block 1614, the example integrity monitor module controller 612 adds the configuration integrity measurement from the endpoint in the subordinate system to the example configuration measurement register 626. In some examples, the configuration integrity measurement is obtained from the integrity measurement database 618, which previously received a request from the SIM 228 monitoring the corresponding endpoint. In other examples, the SIM 228 requests the configuration integrity measurement in response to the request received in block 1602.

[0103] At block 1616, the example integrity monitoring module controller 612 determines whether there is another endpoint in the subordinate system. If so, control returns to blocks 1610, 1612, and 1614 to add the corresponding integrity measurements from the endpoint to the corresponding registers 622, 624, 626. In some examples, the integrity measurements are added to the respective registers by appending them to previously added integrity measurements. If the example integrity monitoring module controller 612 determines that there are no more endpoints in the subordinate system (block 1616), control continues to block 1618, where the example integrity measurement generator 608 generates combined integrity measurements for the subordinate system.In some examples, the combined integrity measurements are generated by calculating a checksum of the string of values ​​in each of the software, hardware, and configuration registers 622, 624, 626. In block 1620, the example communication interface 602 sends a report of the combined integrity measurements to the supervisory system SIM, whereupon the example method of FIG. Fig. 16 ends.

[0104] Fig. 17 is a block diagram of an example processor platform 1700 that may be used and / or programmed to implement the example method of Fig. 7 for implementing the exemplary configuration module 226 from Fig. 2 and / or 4. The processor platform 1700 may be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smartphone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet device, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a game console, a personal video recorder, a set-top box, or any other type of computing device.

[0105] The processor platform 1700 of the illustrated example includes a processor 1712. The processor 1712 of the illustrated example is hardware. For example, the processor 1712 may be implemented by one or more integrated circuits, logic circuits, microprocessors, or controllers from any desired family and from any manufacturer.

[0106] The processor 1712 of the illustrated example includes a local memory 1713 (e.g., a cache). In the illustrated example, the processor 1712 implements the example configuration file generator 404 and / or the example reference value generator 406. The processor 1712 of the illustrated example communicates via a bus 1718 with a main memory, which includes a volatile memory 1714 and a non-volatile memory 1716. The implementation of the volatile memory 1714 may be synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), and / or any other type of random access memory device.The non-volatile memory 1716 can be implemented using flash memory and / or any other type of memory device. Access to the main memory 1714, 1716 is controlled by a memory controller.

[0107] The processor platform 1700 of the illustrated example also includes an interface circuit 1720. The implementation of the interface circuit 1720 may be through any type of interface standard, such as an Ethernet interface, a Universal Serial Bus (USB), and / or a PCI Express interface.

[0108] In the illustrated example, one or more input devices 1722 are connected to the interface circuit 1720. The input devices 1722 enable a user to input data and commands into the processor 1712. The input devices can be implemented, for example, by an audio sensor, a microphone, a camera (still image or video), a keyboard, a button, a mouse, a touchscreen, a trackpad, a trackball, Isopoint, and / or a speech recognition system.

[0109] Additionally, one or more output devices 1724 are connected to the interface circuit 1720 of the illustrated example. The output devices 1724 can be implemented, for example, by display devices (e.g., a light-emitting diode (LED), an organic light-emitting diode (OLED), a liquid crystal display, a cathode ray tube (CRT) display, a touchscreen, a tactile output device, a light-emitting diode (LED), a printer, and / or a speaker). The interface circuit 1720 of the illustrated example thus typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.

[0110] The interface circuit 1720 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, and / or a network interface card to enable the exchange of data with external machines (e.g., computing devices of any kind) over a network 1726 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, a coaxial cable, a cellular phone system, etc.).

[0111] The processor platform 1700 of the illustrated example also includes one or more mass storage devices 1728 for storing software and / or data. For example, the mass storage device 1728 may contain the example configuration database 408 of Fig. 4. Examples of such mass storage devices 1728 are floppy disk drives, hard disks, compact disk drives, Blu-ray disk drives, RAID systems, and DVD (Digital Versatile Disk) drives.

[0112] Coded instructions 1732 for implementing the method from Fig. 7 may be stored in the mass storage device 1728, in the volatile memory 1714, in the non-volatile memory 1716, and / or on a removable tangible computer-readable storage medium such as a CD or DVD.

[0113] Fig. 18 is a block diagram of an example processor platform 1800 that may be used and / or programmed to implement the example methods of Fig. 8-10 for implementing the exemplary integrity measurement module 230 from Fig. 2, Fig. 3 and / or 5. The processor platform 1800 may be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smartphone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet device, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a game console, a personal video recorder, a set-top box, or any other type of computing device.

[0114] The processor platform 1800 of the illustrated example includes a processor 1812. The processor 1812 of the illustrated example is hardware. For example, the processor 1812 may be implemented by one or more integrated circuits, logic circuits, microprocessors, or controllers from any desired family and from any manufacturer.

[0115] The processor 1812 of the illustrated example includes a local memory 1813 (e.g., a cache). In the illustrated example, the processor 1812 implements the exemplary integrity measurement generator 502, the exemplary integrity measurement self-test device 504, the exemplary integrity measurement controller 506, and / or the exemplary communication authenticator 508. The processor 1812 of the illustrated example communicates via a bus 1818 with a main memory, which includes a volatile memory 1814 and a non-volatile memory 1816.The volatile memory 1814 may be implemented by synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), and / or any other type of random access memory device. The non-volatile memory 1816 may be implemented by flash memory and / or any other type of memory device. Access to the main memory 1814, 1816 is controlled by a memory controller.

[0116] The processor platform 1800 of the illustrated example also includes an interface circuit 1820. The implementation of the interface circuit 1820 may be through any type of interface standard, such as an Ethernet interface, a Universal Serial Bus (USB), and / or a PCI Express interface.

[0117] In the illustrated example, one or more input devices 1822 are connected to the interface circuit 1820. The input devices 1822 enable a user to input data and commands into the processor 1812. The input devices can be implemented, for example, by an audio sensor, a microphone, a camera (still image or video), a keyboard, a button, a mouse, a touchscreen, a trackpad, a trackball, Isopoint, and / or a speech recognition system.

[0118] In addition, one or more output devices 1824 are connected to the interface circuit 1820 of the illustrated example. The output devices 1824 can be implemented, for example, by display devices (e.g., a light-emitting diode (LED), an organic light-emitting diode (OLED), a liquid crystal display, a cathode ray tube (CRT) display, a touchscreen, a tactile output device, a light-emitting diode (LED), a printer, and / or a speaker). The interface circuit 1820 of the illustrated example thus typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.

[0119] The interface circuit 1820 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, and / or a network interface card to enable the exchange of data with external machines (e.g., computing devices of any kind) over a network 1826 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, a coaxial cable, a cellular phone system, etc.).

[0120] The processor platform 1800 of the illustrated example also includes one or more mass storage devices 1828 for storing software and / or data. For example, the mass storage device 1828 may include the example software measurement register 512, the example configuration measurement register 514, the example hardware measurement register 516, the example authorization information database 518, and / or the example configuration database 520. Examples of such mass storage devices 1828 include floppy disk drives, hard disk drives, compact disk drives, Blu-ray disk drives, RAID systems, and DVD (Digital Versatile Disk) drives.

[0121] Coded instructions 1832 for implementing the procedure from Fig. 8-10 may be stored in the mass storage device 1828, in the volatile memory 1814, in the non-volatile memory 1816, and / or on a removable tangible computer-readable storage medium such as a CD or DVD.

[0122] Fig. 19 is a block diagram of an example processor platform 1900 that may be used and / or programmed to implement the example methods of Fig. 11-16 for implementing the exemplary system integrity monitoring module 228 from Fig. 2, Fig. 3 and / or 6. The processor platform 1900 may be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smartphone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet device, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a game console, a personal video recorder, a set-top box, or any other type of computing device.

[0123] The processor platform 1900 of the illustrated example includes a processor 1912. The processor 1912 of the illustrated example is hardware. For example, the processor 1912 may be implemented by one or more integrated circuits, logic circuits, microprocessors, or controllers from any desired family and from any manufacturer.

[0124] The processor 1912 of the illustrated example includes a local memory 1913 (e.g., a cache). In the illustrated example, the processor 1912 implements the exemplary integrity measurement comparator 604, the exemplary authorization controller 606, the exemplary integrity measurement generator 608, the exemplary integrity measurement self-tester 610, and / or the exemplary integrity monitoring module controller 612. The processor 1912 of the illustrated example communicates via a bus 1918 with a main memory, which includes a volatile memory 1914 and a non-volatile memory 1916.The volatile memory 1914 may be implemented by synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), and / or any other type of random access memory device. The non-volatile memory 1916 may be implemented by flash memory and / or any other type of memory device. Access to the main memory 1914, 1916 is controlled by a memory controller.

[0125] The processor platform 1900 of the illustrated example also includes an interface circuit 1920. The implementation of the interface circuit 1920 may be through any type of interface standard, such as an Ethernet interface, a Universal Serial Bus (USB), and / or a PCI Express interface.

[0126] In the illustrated example, one or more input devices 1922 are connected to the interface circuit 1920. The input devices 1922 enable a user to input data and commands into the processor 1912. The input devices may be implemented, for example, by an audio sensor, a microphone, a camera (still image or video), a keyboard, a button, a mouse, a touchscreen, a trackpad, a trackball, Isopoint, and / or a speech recognition system.

[0127] Additionally, one or more output devices 1924 are connected to the interface circuit 1920 of the illustrated example. The output devices 1924 can be implemented, for example, by display devices (e.g., a light-emitting diode (LED), an organic light-emitting diode (OLED), a liquid crystal display, a cathode ray tube (CRT) display, a touchscreen, a tactile output device, a light-emitting diode (LED), a printer, and / or a speaker). The interface circuit 1920 of the illustrated example thus typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.

[0128] The interface circuit 1920 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, and / or a network interface card to enable the exchange of data with external machines (e.g., computing devices of any kind) over a network 1926 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, a coaxial cable, a cellular phone system, etc.).

[0129] The processor platform 1900 of the illustrated example also includes one or more mass storage devices 1928 for storing software and / or data. For example, the mass storage device 1928 may include the example reference value database 616, the example integrity measurement database 618, the example authorization information database 620, the example software measurement register 622, the example hardware measurement register 624, and / or the example configuration measurement register 626. Fig. 6. Examples of such mass storage devices include floppy disk drives, hard disks, compact disk drives, Blu-ray disk drives, RAID systems, and DVD (Digital Versatile Disk) drives.

[0130] Coded instructions 1932 for implementing the procedure from Fig.11-16 may be stored in the mass storage device 1928, in the volatile memory 1914, in the non-volatile memory 1916, and / or on a removable tangible computer-readable storage medium such as a CD or DVD.

[0131] From the foregoing, it is readily apparent that the methods, apparatus, and articles of manufacture disclosed above improve the security and reliability of components in an industrial enterprise system. Unlike previous approaches that assume integrity in network communication devices (endpoints) based on quality assurances from original equipment manufacturers, the examples disclosed herein can verify the integrity of such endpoints. Furthermore, such verification can be performed when an endpoint is initially registered and / or admitted to a particular network and / or during runtime while the endpoint is in operation.In this way, potential security breaches and / or other errors that compromise the integrity of endpoints can be detected regardless of their occurrence, ensuring that communications from such endpoints do not impact other endpoints, and enabling remedial action to be taken with respect to the compromised endpoint. Furthermore, the teachings disclosed herein enable the rollup and / or combination of integrity measurements for lower-level endpoints to verify a corresponding system subordinate to a higher-level oversight system.

[0132] Although certain exemplary methods, apparatus, and articles of manufacture have been disclosed herein, the scope of the present patent is not limited thereto. Rather, the present patent covers all methods, apparatus, and articles of manufacture reasonably included within the scope of the claims of the present patent.

Claims

[1] Device comprising: an integrity measurement comparator for comparing an integrity measurement with a reference value, wherein the integrity measurement is generated by a first endpoint in a first network of an industrial enterprise system based on a status of the first endpoint, wherein the reference value corresponds to a trusted status of the endpoint, wherein the status of the endpoint corresponds to at least one of software or firmware loaded on the endpoint, configuration data assigned to the endpoint, or hardware or peripherals coupled to the endpoint, and wherein the first endpoint corresponds to a group of second endpoints in a subnetwork of the first network, wherein the integrity measurement corresponds to a combination of different integrity measurements corresponding to the group of second endpoints in the subnetwork; and an authorization control device for enabling communication access for the endpoint to the network based on the comparison of the integrity measurement with the reference value. [2] The apparatus of claim 1, further comprising an integrity measurement controller for updating the reference value to match the integrity measurement based on a confirmed override of a discrepancy between the integrity measurement and the reference value; and / or wherein the communication access for the first endpoint corresponds to full communication access when the integrity measurement matches the reference value, wherein the authorization controller provides authorization information to the first endpoint to enable full communication access. [3] Device according to one of the preceding claims, in particular according to claim 2, wherein the integrity measurement is generated by calculating a checksum of the software loaded on the first endpoint. [4] Device according to one of the preceding claims, in particular according to claim 3, wherein the communication access corresponds to the communication access for firmware updates if the checksum does not match the reference value. [5] Device according to one of the preceding claims, in particular according to claim 2, wherein the integrity measurement is generated by calculating a checksum of the configuration data stored on the first endpoint. [6] Device according to one of the preceding claims, in particular according to claim 5, wherein the communication access corresponds to the communication access for configuration if the checksum does not match the reference value. [7] Device according to one of the preceding claims, in particular according to claim 5, wherein the reference value is generated based on a configuration file generated for the first network. [8] Device according to one of the preceding claims, in particular according to claim 2, wherein the integrity measurement is generated by calculating a checksum for the peripheral device of the first endpoint. [9] Apparatus according to one of the preceding claims, in particular according to claim 1, wherein the integrity measurement is generated by the first endpoint during the boot time of the first endpoint; and / or wherein the integrity measurement is generated by the first endpoint during the runtime of the first endpoint. [10] Device according to one of the preceding claims, in particular according to claim 1, wherein the authorization control device performs at least one of the following: (1) Generating an alarm if the integrity measurement does not match the reference value, the alarm being meaningful with respect to a suspicious identity of the first endpoint, or (2) flagging the data provided by the first endpoint if the integrity measurement does not match the reference value, wherein the flagged data is meaningful with respect to a suspicious identity of the first endpoint; and / or wherein the authorization control device prevents communication access for the endpoint to the network and allows communication access for a redundant endpoint if the integrity measurement does not match the reference value. [11] Apparatus according to any one of the preceding claims, in particular according to claim 1, wherein the first network corresponds to a control network of a control system within the industrial enterprise system, wherein the first endpoint corresponds to one of the following: a workstation, a server, a control device, an input / output device or a field device coupled to the control network; and / or wherein the first network corresponds to a supervisory network of a supervisory system within the industrial enterprise system, wherein the first endpoint corresponds to a control system subordinate to the supervisory system. [12] Method comprising: Receiving an integrity measurement from a first endpoint in a first network of an industrial enterprise system, wherein the integrity measurement is generated by the first endpoint based on a status of the first endpoint; Comparing the integrity measurement with a reference value corresponding to a trusted status of the endpoint, wherein the status of the endpoint corresponds to at least one piece of software or firmware loaded on the endpoint, configuration data assigned to the endpoint, or hardware or peripheral coupled to the endpoint, and wherein the first endpoint corresponds to a group of second endpoints in a subnetwork of the first network, wherein the integrity measurement corresponds to a combination of different integrity measurements corresponding to the group of second endpoints in the subnetwork; and Allowing the first endpoint to communicate with the first network based on the comparison. [13] The method of claim 12, further comprising: Receiving an authorization to overwrite a discrepancy between the integrity measurement and the reference value; and Updating the reference value to comply with the integrity measurement based on the approval; and / or further comprising enabling full communication access for the first endpoint if the integrity measurement matches the reference value by providing authorization information to the first endpoint. [14] Method according to claim 12 or 13, in particular according to claim 16, wherein the integrity measurement is generated by calculating a checksum of the software loaded on the first endpoint. [15] Method according to one of claims 12-14, in particular according to claim 17, further comprising enabling communication access for firmware updates if the checksum does not match the reference value. [16] Method according to one of claims 12-15, in particular according to claim 16, wherein the integrity measurement is generated by the first endpoint calculating a checksum of the configuration data stored on the first endpoint. [17] The method of any of claims 12-16, in particular according to claim 19, further comprising enabling communication access to the configuration if the checksum does not match the reference value; and / or wherein the reference value is generated based on a configuration file generated for the first network. [18] Method according to one of claims 12-17, in particular according to claim 16, wherein the integrity measurement is generated by the first endpoint by calculating a checksum for the peripheral device of the first endpoint. [19] Method according to one of claims 12-18, in particular according to claim 14, wherein the integrity measurement is generated by the first endpoint during the boot time of the first endpoint; and / or wherein the integrity measurement is generated by the first endpoint during the runtime of the first endpoint; and / or further comprising at least one of the following: Generate an alarm if the integrity measurement does not match the reference value; or Flagging the data provided by the first endpoint if the integrity measurement does not match the reference value, whereby both the alarm and the flagged data are meaningful with respect to a suspicious identity of the first endpoint. [20] Method according to any one of claims 12-19, in particular according to claim 12, further comprising: Preventing communication access for the first endpoint to the first network if the integrity measurement does not match the reference value; and Enabling communication access for a redundant endpoint; and / or wherein the first network corresponds to a control network of a control system within the industrial enterprise system, wherein the first endpoint corresponds to one of the following: a workstation, a server, a control device, an input / output device, or a field device coupled to the control network. [21] Method according to one of claims 12-20, in particular according to claim 12, wherein the first network corresponds to a supervisory network of a supervisory system within the industrial enterprise system, wherein the first endpoint corresponds to a control system subordinate to the supervisory system. [22] A computer-readable storage medium storing instructions which, when executed by at least one processor, cause a machine to implement one of the methods of any one of claims 12-21.

Images