Whitelisting for HART communications in process control systems

Abstract

A cybersecurity system for use in a process plant provides a whitelist of device-specific and general HART read commands in a process controller and a safety controller to perform highly secure communications in a process plant that still enable advanced functionality provided in HART devices. A whitelist implementation application applies one or more whitelists in a secure gateway device to determine whether messages such as HART messages should be allowed or processed. A whitelist learning application automatically creates and configures whitelists by using a lock / learning mode, while a whitelist configuration application discovers device-specific and general HART commands by issuing a device description request to a specific device, parsing the response, and transmitting whitelist configuration information with the parsed command type to the relevant process controller and safety controller for use in the whitelist. A user interface enables a user to interact with and guide the configuration process to provide a highly secure system that still enables diagnostics and other advanced functionality for field devices in a process plant.

Description

[0001] Related Applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 904,229, filed on September 23, 2019, entitled “Whitelisting for HART Communications in a Process Control System,” the entire contents of which are expressly incorporated herein by reference. Technical Field

[0003] The present invention relates generally to process control systems and safety systems used in process plants, and more particularly to implementing cyber security in a combined process control and safety system. Background Art

[0004] Process control systems, such as those used in chemical, petroleum or other processes, typically include one or more process controllers that are communicatively coupled to at least one host or operator workstation and one or more field devices via an analog, digital or combined analog / digital bus. Field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within a process plant, such as opening or closing valves and measuring process parameters. The process controller receives signals indicative of process measurements obtained by the field devices and / or other information related to the field devices, uses the information to implement a control routine, and then generates control signals that are sent to the field devices via the bus to control the operation of the process. Information from the field devices and controllers is typically available to one or more applications executed by the operator workstation to enable the operator to perform any desired functions related to the process, such as configuring the process, viewing the current state of the process, modifying the operation of the process, and so on.

[0005] In some process systems, a separate safety system may be provided to detect major safety-related problems within the process plant and automatically close valves, remove power from equipment, switch flows within the plant, etc. when problems occur, which may cause or lead to serious hazards in the plant, such as spills of toxic chemicals, explosions, etc. These safety systems typically include one or more separate input / output (I / O) devices that have controllers other than process controllers, which are connected to safety field devices via separate buses or communication lines set within the process plant. The safety controller uses the safety field devices to detect process conditions associated with major events (such as the position of certain safety switches or shutoff valves, overflow or underflow in the process, operation of important power generation or control equipment, operation of fault detection equipment, etc.), thereby detecting "events" within the process plant. When an event is detected, the safety controller will take some action to limit the harmful effects of the event, such as closing valves, shutting down equipment, removing power from part of the plant, etc.

[0006] In the past, attempts have been made to integrate data from process control and safety systems in the same plant on the same user interface, thereby providing viewing and manipulation of this disparate data in the same location through an integrated control and safety system (ICSS). One of the most common methods of acquiring information from field devices in an ICSS is the Highway Addressable Remote Transmitter (HART). One of the most common methods of delivering information to field devices via the ICSS is through pass-through communication using HART commands.

[0007] HART communication protocol commands are classified into specific groups. Specifically, the HART communication protocol defines universal commands (which must be recognized and supported by all devices using the protocol), conventional commands (which are recognized and supported by some but not all HART communication devices), and device-specific commands (which represent functions unique to each field device). The vast majority of HART commands can be further divided into read or write commands. Typically, read commands read information from field devices, while write commands change the internal settings or physical state of field devices. Device-specific commands are defined by and become useful through a formal description of the operating process of a device called a device description. Device descriptions are typically created and provided by device manufacturers and can be used to discover conventional commands and device-specific commands specific to any field device.

[0008] Device descriptions are typically collected or acquired by an asset management system (ASM) or configuration system of a process plant during installation of field devices. The system may issue a "command zero" to obtain the device description from a database or other device description repository. In addition, the device description (which may be stored in an unchanged format in a configuration database) may be parsed and then stored. For example, the device description may be parsed for device variables, device commands, and device menus, and each parsed segment may be stored separately. The device description and its subfields are typically readable by other devices in the process plant.

[0009] Sometimes, a higher level of security is needed in an ICSS that implements the HART communication protocol. To this end, safety logic solvers and controllers typically have some type of hardware key to prevent or achieve a higher level of security, and in some cases, this higher level of security has been used to block certain HART commands instead of forwarding these commands to devices connected to the safety logic solvers and controllers. Some methods of high ICSS security include blocking all commands (such as HART commands) to safety system field devices. However, this method is not flexible, so commands that do not have dangerous properties are not allowed to be forwarded. Other methods of high ICSS security include allowing all read general commands. Unlike blocking all commands, this method does allow certain non-dangerous messages (especially, read general commands) to be forwarded. Generally, read commands are considered safe because they do not essentially change the state of the equipment in the process plant. Instead, these read commands only request the current value of the data field. In contrast, write commands can be used maliciously, thereby putting process plants and individuals in the plant at risk. The current method of providing safety within a safety system by blocking all HART commands except read-only general commands utilizes the safety properties of the read-only general commands of the HART protocol to provide a coarse-grained blocking of potentially dangerous messages while allowing read general commands. However, this method blocks and / or discards all safety read commands outside a limited set of general commands. In other words, all conventional read commands and all device type read commands that are generally considered safe will still be blocked by this method. As a result, control and safety systems that use high-level safety (such as any of the above-mentioned blocking methods) make it difficult (if not impossible) to use the numerous diagnostic functions and other auxiliary functions of the HART devices used in the safety system by not realizing the data provided by the device functions defined by the general commands of the HART protocol, thereby greatly reducing the efficiency of these methods in the process. Therefore, the existing methods lack fine-grained features to meet the needs of providing a large amount of advanced diagnostic and device information while transmitting the appropriate level of safety. Summary of the invention

[0010] The process plant includes a whitelist configuration application that enables a user to securely configure a safety logic solver or process controller to transmit an appropriate security level while also meeting the need to send a large amount of information between the safety system device and one or more supervisory or support applications (e.g., configuration, asset management, etc.). In one embodiment, when the safety logic solver is set to a certain security level (e.g., the hardware key is set in a prohibited position, resulting in a higher or highest security level), the communication interface of the safety logic solver can respond to receiving a message by executing a whitelist execution application configured on the device. The whitelist execution application can access one of a plurality of whitelists stored in a memory based in part on the current security level and configuration information. The whitelist execution application can then compare the command type of the message with the command type in the selected whitelist. If there is no match, the application can block the message, which can include not forwarding the message to the safety system field device in a direct communication mode, such as a direct communication mode, and can include notifying the process plant operator or other user. If there is a match in the whitelist, the application can perform a standard operation, which can include accessing and executing one or more logic modules, and can include forwarding the message to the desired device.

[0011] In addition, a whitelist learning application can provide systems and methods for performing automatic whitelist configuration for both process control systems and safety systems. Specifically, the whitelist learning application can enable a user to build one or more whitelist configurations for one or more safety logic solvers (also referred to as safety controllers) and / or process controllers by placing one or more controllers in a learning mode, wherein the learning mode extracts the command type of the incoming command and builds a whitelist based on the security level of the controller (and optionally based on the destination of the command). When the controller is switched back to the locked mode, the whitelist learning application stores the whitelist it has built in the whitelist execution application for future command processing.

[0012] In addition, the whitelist configuration application provides another system and method for performing automatic whitelist configuration using an interface. In particular, the whitelist configuration application can enable a user to build a whitelist configuration for a safety logic solver or process controller, and the whitelist configuration can be stored in a desired gateway device with different degrees of automation. In one embodiment, the whitelist configuration application coordinates with the configuration database to read and parse the device description of the installed field device to determine the device-specific (Device Specific) and common (Common Practice) read commands for the field device. The whitelist configuration application then generates and configures one or more whitelists that consist of some or all of the device-specific and common practice read messages, and configures the appropriate process controller or safety logic solver to process incoming messages using one or more of the created whitelists. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a block diagram of an exemplary process plant having a safety system integrated with a process control system and including one or more interface, whitelist configuration, and whitelist execution applications that provide integrated security, configuration, and diagnostic activities with respect to the process control system and the safety system.

[0014] Figure 2 is an exemplary screen display illustrating Figure 1 A configuration view of a process plant showing both process control system equipment and safety system equipment.

[0015] Figure 3A is Figure 1 A block diagram of an exemplary safety logic solver is schematically illustrated in FIG.

[0016] Figure 3B is Figure 3A A block diagram of an example whitelist execution application operating within an example safety logic solver is schematically illustrated in FIG.

[0017] Figure 4 A block diagram illustrating the operation of a whitelist execution application.

[0018] Figure 5A is a block diagram of an exemplary whitelist learning application.

[0019] Figure 5B A block diagram illustrating the operational flow of a whitelist learning application.

[0020] Figure 6 is a block diagram of an exemplary whitelist configuration application system having a configuration for managing, creating, and editing whitelist configurations. Figure 1The whitelist configuration is applied to one or more workstations in the .

[0021] Figure 7 A block diagram illustrating the operational flow of a whitelist configuration application.

[0022] Figure 8 A block diagram illustrating the operational flow of a routine that discovers device-specific and general command types from a device description.

[0023] Fig. 9A Is Figure 6 An exemplary screen display generated by the whitelist configuration application in Figure 7 Authentication steps in .

[0024] Fig. 9B Is Figure 6 An exemplary screen display generated by the whitelist configuration application in Figure 7 The configuration steps in . DETAILED DESCRIPTION

[0025] Figure 1 A process plant 10 is generally illustrated that implements a combined process control and safety system and is configured to include a set of whitelist components or applications that provide a high level of network security in the plant 10 while still enabling the use of higher level functionality of various field devices (particularly HART field devices) within the plant 10. Typically, the whitelist components or applications include one or more whitelist execution applications that operate to securely process messages (e.g., HART messages) or commands when received by a secure gateway device (e.g., a logic solver and a process controller) by performing analysis on the incoming signal in the form of comparing the command type of the message to one or more stored whitelists to determine whether the message can pass through the subsystem device. The whitelist components also include one or more whitelist configuration applications that enable a user to securely set up, create, edit, download, and configure the whitelist execution application and the whitelists used thereby for any of a plurality of secure gateway devices.

[0026] generally, Figure 1The exemplary process plant 10 includes a process control system 12 integrated with a safety system 14 (represented by a dashed line), which safety system 14 typically operates as a safety instrumented system (SIS) to monitor and override the control provided by the process control system 12 to maximize the safest possible operation of the process plant 10. The process plant 10 also includes one or more host workstations, computers or user interfaces 16 (which can be any type of personal computer, workstation, etc.) accessible by plant personnel (e.g., process control operators, maintenance personnel, configuration engineers, etc.). These workstations host and execute a whitelist configuration application 80. In Figure 1 In the illustrated example of FIG. 1 , three user interfaces 16 are shown connected to two separate process control / safety control nodes 18 and 20 and a configuration database 21 via a common communication line or bus 22. The communication network 22 may be implemented using any desired bus-based or non-bus-based hardware, using any desired hardwired or wireless communication structure, and using any desired or suitable communication protocol (e.g., Ethernet protocol).

[0027] It will be appreciated that each of the nodes 18 and 20 of the process plant 10 includes process control system devices and safety system devices connected together via a bus structure, which may be provided on a backplane to which the various devices are attached. Figure 1 2 is illustrated as including a process controller 24 (which may be a pair of redundant controllers) and one or more process control system input / output (I / O) devices 28, 30, and 32, while the node 20 is illustrated as including a process controller 26 (which may be a pair of redundant controllers) and one or more process control system I / O devices 34 and 36. Each of the process control system I / O devices 28, 30, 32, 34, and 36 is communicatively connected to a group of process control related field devices. Figure 1 The process controllers 24 and 26, the I / O devices 28-36, and the process control field devices 40 and 42 generally constitute Figure 1 of the process control system 12. In addition, as discussed in more detail below, the process controllers 24 and 26 may store and execute one or more whitelist execution applications 202 and / or whitelist learning applications 204 in the memory 75 to securely process messages sent to the field devices 40 and 42.

[0028] Likewise, node 18 includes one or more safety system logic solvers 50 and 52, while node 20 includes safety system logic solvers 54 and 56. Each of the logic solvers 50-56 is an I / O device (also variously referred to as a safety controller) having a processing unit 57 that can execute a safety logic module and a whitelist execution application 202 stored in a memory 58, and these devices are communicatively connected to provide control signals to and / or receive signals from safety system field devices 60 and 62. In addition, each of nodes 18 and 20 may include at least one message propagation device (MPD) 70 or 72, which are connected via a ring bus connection 74 (in Figure 1 Safety system logic solvers 50-56, safety system field devices 60 and 62, MPDs 70 and 72, and bus 74 generally constitute Figure 1 As will be appreciated, the safety system logic solvers 50 - 56 may store the aforementioned whitelist execution application 202 and / or whitelist learning application 204 in the memory 58 to securely process messages sent to the safety system field devices 60 and 62 .

[0029] Process controllers 24 and 26 (by way of example only, they may be DeltaV Series controllers sold by Emerson Process Management) TM Controller 24 or any other desired type of process controller) is programmed to use I / O devices 28, 30 and 32 (for controller 24), I / O devices 34 and 36 (for controller 26), and field devices 40 and 42 to provide process control functions (using components generally referred to as control modules). Specifically, each of the controllers 24 and 26 implements or supervises one or more process control routines (also referred to as control modules) stored in memory 75 or otherwise associated therewith, and communicates with the field devices 40 and 42 and the workstation 14 in any desired manner to control the process 10 or a portion of the process 10. The process controllers 24 and 26 may also store and execute a whitelist execution application 202 and / or a whitelist learning application 204 to perform security checks on messages being sent to the process control or safety system before or during execution of one or more process control routines stored in memory 75. Field devices 40 and 42 may be any desired type of field device, such as sensors, valves, transmitters, positioners, etc., and may conform to any desired open, proprietary, or other communication or programming protocol, including, for example, HART or 4-20ma protocols (as illustrated for field device 40), any fieldbus protocol (e.g., Fieldbus protocol (as illustrated for field device 42) or CAN, Profibus or AS-Interface protocols, to name a few. Similarly, I / O devices 28-36 may be any known type of process control I / O devices using any suitable communication protocol or protocols.

[0030] Figure 1 The safety logic solver 50-56 in (which may be any desired type of safety system control device) includes a processor 57 and a memory 58 that stores a safety logic module to provide control functions associated with the safety system 14 using safety field devices 60 and 62. The memory 58 of the safety logic solver 50-56 may store a whitelist execution application 202 and / or a whitelist learning application 204 suitable for execution on the processor 57 before or during execution of the safety logic module. Of course, the safety field devices 60 and 62 may be any desired type of field devices that conform to or use any known or desired communication protocol, such as those described above. In particular, the field devices 60 and 62 may be safety-related field devices of the type that are traditionally controlled by a separate, dedicated safety-related control system. In Figure 1 In the illustrated process plant 10, the safety field device 60 is depicted as using a dedicated or point-to-point communication protocol, such as HART or 4-20ma protocol, while the safety field device 62 is illustrated as using a bus communication protocol such as a Fieldbus protocol. Typically, the safety devices including the safety system logic solvers (controllers) 50-56 and the safety system field devices 60 and 62 used as part of the safety system 14 will be rated as safety devices, which generally means that these devices must undergo an evaluation process by an appropriate agency to be rated as safety devices.

[0031] A common backplane 76 (represented by dashed lines through the controllers 24, 26, I / O devices 28-36, safety logic solvers 50-56, and MPDs 70 and 72) is used in each of the nodes 18 and 20 to connect the controllers 24 and 26 to the process control I / O cards 28, 30 and 32 or 34 and 36, and to the safety logic solvers 52 and 54 or 56 and 58 and the MPDs 70 or 72. The controllers 24 and 26 are also communicatively coupled to the bus 22 and act as a bus arbitrator for the bus 22 to enable each of the I / O devices 28-36, logic solvers 52-56, and MPDs 70 and 72 to communicate with any workstation 16 via the bus 22.

[0032] As will be understood, Figure 1The processor 57 and memory 58 of the safety logic solver 50-56 and the processor and memory 75 of the process controller 24 or 26 enable the use and configuration of a whitelist execution application 202 and a whitelist learning application 204 (if necessary) that stores, for example, a whitelist of HART commands.

[0033] Reference again Figure 1 , the process plant 10 is configured to provide a user with the ability to configure a whitelist execution application 202 for the safety controllers 50-56 and the process controllers 24 and 26. Specifically, one or more of the workstations 16 include a processor 77 and a memory 78 that can store any number of user interfaces, configuration, whitelist, diagnostic and / or viewing applications suitable for execution on the processor 77. The whitelist configuration application 80 and the process plant configuration application 82 are configured to be executed by the user. Figure 1 16, and the user interface or display application 85 is illustrated as being stored in a second workstation in the workstation 16. However, if desired, these applications may be stored and executed in different workstations in the workstations 16 or other computers associated with the process plant 10. In general, the whitelist configuration application 80 provides whitelist configuration information to a configuration engineer to configure some or all elements of the whitelist functionality included in the process plant 10. As part of the configuration activities performed by the whitelist configuration application 80, the configuration engineer can create new whitelists, can edit and remove existing whitelists, and can download these different whitelist configurations to the appropriate whitelist execution applications 202 of the process controllers 24 and 26 and the safety logic solvers 50-56 via the bus 22 and the controllers 24 and 26.

[0034] In general, the process plant configuration application 82 provides process plant configuration information to a configuration engineer to configure some or all elements of the process plant 10, some of which may involve whitelist execution, and store the configuration in the configuration database 21. As part of the configuration activities performed by the configuration application 82, the configuration engineer may create control routines or control modules for the process controllers 24 and 26, may create a safety logic module 58 for any or all of the safety logic solvers 50-56, and may download these various process control modules and safety modules to the process controllers 24 and 26 and the appropriate one of the safety logic solvers 50-56 via the bus 22 and the controllers 24 and 26 to control the behavior of the safety logic solvers 50-56 and the process controllers 24 and 26 during processing commands outside of or in addition to whitelist execution.

[0035] Figure 2An exemplary display screen 83 is shown that demonstrates the hierarchy and relationships between devices and modules within a process plant 10 that can utilize a whitelist execution application 202 to ensure secure transmission of messages between devices in the plant 10. The display screen 83 can be, for example, Figure 1 82, or generated by an operator interface application that illustrates the plant configuration. As illustrated in display screen 83, process plant 10 includes a physical network portion 84 that displays the physical interconnections of devices within process plant 10 and a safety network portion 85 that displays safety system devices. Physical network portion 84 includes a control network 86 that includes a group of controllers, including controller 87 (named CTLR1) and controller 101 (named CTLR2). It can be Figure 1 The controller 87 of one of the controllers 24, 26 in the embodiment includes a set of allocated modules 88, which are control modules stored in the controller 87 and executed for communication purposes by an I / O device portion 89 connected to the controller 87. The I / O device portion 89 is expanded to illustrate the Figure 1 One of the backplanes 76 of the controller 87 (CTLR1) is connected to all I / O cards 90 of the controller 87 (CTLR1). In this example, the I / O device portion 89 includes process control input / output cards C01-C09, C11, C14 and C15 (collectively referred to by the number 90). Each of these cards can be expanded to instantiate different field devices connected to each of these cards (they are Figure 1 The controller 87 (CTLR1) may, for example, implement a whitelist execution application to ensure protection of its associated field devices.

[0036] The safety system 14 is illustrated in the safety network portion 85 as including three safety logic solvers 91-93 named BLR1BMS, BLR2BM and LS1. The safety logic solver 91 is expanded to illustrate that it includes an assigned safety module, one or more channels (which are connected to safety field devices, such as Figure 1 The safety logic solver 91 (and / or solvers 92 and 93) may, for example, similarly implement a whitelist execution application to ensure protection of its associated safety field devices. In these cases, one or more whitelists 95 may be illustrated in the configuration display 83 as being associated with (stored in and used by) the safety logic solvers 91, 92, 93.

[0037] Figure 2The configuration display screen 83 illustrates the manner in which the configuration application 82 has configured the software (and hardware) associated with the different devices within the process plant 10, and can be used by a configuration engineer to create or change the current configuration of the process plant 10 by downloading new configuration software to devices within the process plant 10 (including process control system devices and safety system devices). It can also display how the configuration information is stored in Figure 1 The configuration database 21. As will be appreciated, the whitelist configuration application 82 utilizes this information to configure the whitelist execution application 202 and the whitelist used thereby.

[0038] Figure 3A A block diagram of a device 300 is shown, which may be Figure 1 Safety Logic Solver 50-56 or Figure 1 One of the process controllers 24 and 26 of the present invention implements, among other functions, a whitelist execution application 320 and a whitelist learning application 330. The device 300 is illustrated as including one or more processors or CPUs 301, random access memory (RAM) 302, a hardware key 303 for setting a security level, a communication interface 304 for sending and receiving data via a local area network, a wide area network, or any other suitable network, a manual configuration portal 305, and a memory 310 for storing various executable modules or data used by the device 300. In general, the device 300 can be configured in a manner similar to that of FIG. Figure 1 The processor 301 may communicate with field devices, I / O devices, user workstations, and / or any other suitable computing devices during operation of the process plant 10. The processor 301 may, among other functions, execute logic in the memory 310, wherein the executable logic relates to commands received by the processing device 300 via a communication network coupled to the communication interface 304. Some of the executable logic may depend on the state of the hardware key 303, indicating a security level.

[0039] Importantly, Figure 3A The memory 310 of the device 300 is illustrated as including an operating system 311 and a set of logic modules 312 that are executed on the processing unit 301 to perform process control activities (such as safety system control and shutdown actions) and process messages that have been received by the device 300 via the communication interface 304. The logic module 312 can communicate with the configuration engineer through Figure 1 The logic module 312 can control how the device 300 responds to a request that has been received from another controller or user interface device (such as Figure 1 ) and data or messages from a safety system or process control field device connected to device 300 via interface 304. Figure 3AAs shown, the memory 310 stores a whitelist enforcement application 320 and / or a whitelist learning application 330. Although the whitelist learning application 330 and the whitelist enforcement application 320 are illustrated as separate applications, their functions may be combined into a single application.

[0040] Generally speaking, the whitelist execution application 320 (which can be Figure 1 2) is executed on the processing unit 301 to act as a network security gateway for sending messages such as HART messages to one or more field devices or other devices in a subnet connected to the device 300. More specifically, the whitelist execution application 320 decodes and analyzes incoming messages received via the communication interface 304 and intended for or addressed to devices (e.g., field devices) in the subnet (e.g., safety system field devices) to determine whether the message can be sent to the intended device, or conversely, whether the message should be blocked. The whitelist execution application 320 can, for example, decode the incoming message and determine the command type (e.g., HART command type) associated with the message. The whitelist execution application 320 can then compare the command type with a list of command types that are allowed to be sent to devices in the subnet as defined in one or more whitelists stored in the device 300. For example, if the command type is stored in the appropriate whitelist, the application 320 can allow the message to be forwarded to a device (e.g., field device) in the subnet via the interface 304. However, if the command type is not stored in the appropriate whitelist, the application 320 will prevent the message from being sent to the device in the subnet via the interface 304, and may instead send a message to the sending device (i.e., the device sending the message) indicating that the message has been blocked because it is not allowed. Further, the whitelist execution application 320 can determine the appropriate whitelist for the function based on the setting of the hardware key 303, or based on other configuration data provided to the device 300 during its configuration, which defines the level and type of security to be provided based on various other factors, including setting the security level by, for example, the hardware key 303 (or software key), one or more specific devices to which the message is sent, the operating state of the device 300, or the process plant in which the device 300 is used.

[0041] In addition, as will be described in more detail below, a whitelist learning application 330 can be executed on the processing unit 301 to accept messages, learn the messages, and in particular, the command types present in the messages, and then based on this learning, generate one or more whitelists to be used by the whitelist execution application 320. In particular, the whitelist learning application 330 can operate in a safe mode (i.e., when it is known that the plant or process control network is operating in a safe mode or environment) to learn commands or command types (e.g., HART commands) that are typically seen in messages sent to the security gateway device, and can create one or more whitelists containing these commands or command types. Thereafter, when the plant or security gateway device is set to a locked mode, the security gateway device can operate using the learned whitelists to determine which messages are allowed to be processed in the gateway device or devices in the subnet of the gateway device.

[0042] Figure 3B More detailed examples Figure 3A At least a portion of a device 300 includes an expanded view of a whitelist execution application 320 running on a processor 301 of the device 300. The expanded view of the whitelist execution application 320 includes a whitelist execution logic module 326, a decryption module 325, whitelist configuration information 324 and a set of one or more whitelists 321, a secure write client 322, and a security level setting 323. The secure write client 322 can implement authentication of users who intend to add content to, delete content from, and generally edit the whitelist configuration information 324 and whitelists 321 of the whitelist execution application 320. Some of the information in the whitelist configuration information 324 can be sent to the whitelist execution application 320 in an encrypted form. The encrypted whitelist configuration information can be decrypted by the decryption module 325. In addition, the whitelist execution logic module 326 includes logic or programming that is executed in Figure 3A When executed on the processor 301, it receives a message or command from the communication interface 304 (sent by a process controller, a user interface, or any other device and intended for the device 300 or a device in a subnet connected to the device 300), and coordinates with other components of the whitelist execution application 300 to determine whether the message command is allowed to be further processed by the device 300 (for example, in the logic module 312) or sent to one or more devices in the subnet connected to the device 300 (for example, the field device 22).

[0043] Whitelist enforcement logic module 326 will determine whether a message received via communication interface 304 is allowed (e.g., processed by device 300 or sent to a device in a subnet for which device 300 acts as a gateway) based in part on whitelist configuration information 324, whitelist 321, and security level 323. Security level 323 stores the security level of whitelist implementation device 300 at a certain moment. Security level 323 can be used Figure 3A The hardware key 303 can be set or the security level 323 can be set via Figure 1 The whitelist 321 may be set by an appropriate user of one or more of the user workstations 16, or via any other desired method. The whitelist 321 constitutes a list of whitelists. Each whitelist is a unique set of permissible command types. As will be appreciated, at least one of the multiple whitelists 321 may contain device-specific commands and / or regular commands, particularly device-specific and / or regular read commands. The whitelist configuration information 324 contains data for determining which whitelist 321 may be used for a given incoming command or processing state, or other information that may affect which whitelist 321 is to be used. Specifically, the whitelist configuration information 324 may constitute a mapping, such as a hash map, which defines which whitelist(s) will be used when the illustrated device is set to a particular security level. The whitelist 321 and the whitelist configuration information 324 may be stored in a list, a mapping, a hash map, a hash set, a linked list, a queue, a stack and / or any other applicable data structure. The manner in which the whitelist 321 is selected and whether the incoming message is allowed is determined by the operation of the whitelist execution logic module 326, such as by Figure 4 This is illustrated in more detail by flowchart 400 in FIG.

[0044] Specifically, Figure 4 As shown, in step 401, Figure 3BThe whitelist execution logic module 326 of the device 300 receives a command or message (e.g., a HART message) from the communication interface 304. Then, in step 402, the application 320 identifies the command type by extracting the command type field from the message. In step 403, the application 320 obtains one or more whitelists 321 based on the current security level 323 and the whitelist configuration information 324, as described in detail below. In step 404, if the command type of the received message exists in the (multiple) whitelists 321, the application 320 enables the message to be processed as an allowed message. In step 406, the application 320 can enable the communication interface 304 to forward the message to the desired field device through the communication interface 304, or to be processed by one or more of the logic modules 312 within the device 300, as described in more detail below. In step 404, if the message type is not included in the whitelist 321, the application 320 can mark the message so that it will not be processed because it is an unallowed message. In step 405, the disallowed message may be discarded (e.g., it may not be returned to the communication interface for forwarding), or the disallowed message may be discarded in any other manner. Step 405 may further or alternatively include notifying plant personnel (e.g., process control operators, maintenance personnel, configuration engineers, etc.) via the communication interface 304 that the message has been discarded so that these personnel or the initiating device can take appropriate action.

[0045] Thus, when an incoming message (e.g., a HART message) is received by the communication interface 304, it is first passed to the whitelist execution application 320. The whitelist execution logic module 326 of the whitelist execution application 320 includes communication logic that extracts the command type from the message and uses the whitelist configuration information 324 and the security level 323 to find the whitelist 321. The whitelist execution logic module 326 can then search the extracted command type in the selected whitelist to determine whether the message should be allowed or denied. For example, if the hardware key 303 on the device 300 hosting the whitelist execution application 320 is set to a position indicating a high security level, the whitelist configuration information 324 can specify that incoming commands through the communication interface 304 can be checked against a first whitelist. However, when the whitelist implementation device 300 is set to a medium security level, the whitelist configuration information 324 can specify that incoming commands can be checked against a second whitelist. The second whitelist may be longer (i.e., less strict). Alternatively or additionally, the whitelist configuration information 324 may specify that at (multiple) lower security levels, the whitelist execution application 320 may use a total whitelist (i.e., including every command type). Alternatively or additionally, the whitelist configuration information 324 may specify that at higher security levels, the whitelist execution application 320 may use an empty whitelist (i.e., a full blacklist). Of course, each whitelist may contain any number or type of command types that are allowed, and in many cases, these types may be distinct, rather than overlapping, groups.

[0046] Of course, if the message is allowed, the message may be returned to the communication interface 304 for standard operation at step 406. The standard operation may include the execution of one or more logic modules 312. The standard operation may further and / or alternatively include forwarding the message or processing the message based on a standard protocol (e.g., using a MAC address or IP address destination field of the message, alternatively or additionally using pass-through HART communication).

[0047] In another embodiment or the same embodiment, the whitelist configuration information 324 can define which whitelists will be used when the whitelist implementation device 300 is set to a specific security level and the incoming command destination is a specific field device connected to the whitelist implementation device 300. In this way, step 402 can extract both the command type and the destination from the signal to determine which whitelist to use and whether the message is allowed based on the whitelist. For example, if the hardware key 303 on the whitelist implementation device 300 is set to a position indicating a high security level, the whitelist configuration information 324 can specify that the incoming command going to the first valve through the communication interface 304 will be checked against the first whitelist. However, when the incoming command is going to the second valve at the same security level, the whitelist configuration information 324 can specify that the incoming command is checked against the second whitelist. Of course, this is only an example, and many other combinations of configurations, process states, or other data can be used to determine which whitelist is used to process any particular message at any particular time.

[0048] Figure 5A More detailed examples Figure 3A At least a portion of a device 300 includes an expanded view of a whitelist learning application 330 running on a processor 301 of the device 300. The expanded view of the whitelist learning application 330 includes a lock / learning mode setting or data 333, a set (multiple) of whitelist builder logic data 332, and a whitelist learning logic module 331. The whitelist learning logic module 331 may contain machine executable code that, when executed, performs the logic of the whitelist learning application 330. The lock / learning mode 333 may indicate or store data indicating that the device 300 is in a "locked" state or that the device 300 is in a "learning" state. The device 300 may be configured by an appropriate user (such as a configuration engineer, a plant operator, a maintenance person, etc.) based on a hardware element (e.g., a key) on the device, or based on a lock / learning mode configured by a user (e.g., a configuration engineer, a plant operator, a maintenance person, etc.). Figure 1 The actions taken by the whitelist learning logic module 331 may depend on these states. As will be appreciated, when the device 300 is in the learning state, (multiple) whitelist builder logic or data 332 is used to build a whitelist configuration. Similar to Figure 3B The whitelist configuration information 324, (multiple) whitelist builder logic or data 332 can constitute a map, such as a hash map. In general, the whitelist learning application 330 can receive commands from the communication interface 304, and the application 330 can forward these commands to the whitelist execution application 320, and / or return messages to the communication interface 304 based on the settings and operations of the logic module 331 to be forwarded to the desired destination field device.

[0049] Figure 5BAn example of a flow chart 500 of the whitelist learning logic module 331 is illustrated in more detail. When the whitelist learning application 330 receives a message from the communication interface 304 (at step 501), the logic module 331 may first check to determine whether the device 300 is in a "learning" state, or conversely, whether the device 300 is in a "locked" state, as defined by data 333 (at step 502). If the device 300 is in the locked state, the application 330 may simply send the message to the whitelist execution application 320 for processing as described above (at step 503). However, if the device 300 is in the learning state, the logic module 331 may treat the incoming message as being of a secure nature and will use the (multiple) whitelist builder logic 332 to appropriately "learn" information about the message, such as the HART command type of the message, the devices in the subnet receiving the message, etc. After the logic 332 "learns" this information, the whitelist learning logic module 331 passes the command back to the communication interface 304 to perform standard operations, such as, for example, executing the logic module 312 and forwarding the command to its desired destination. Therefore, as illustrated in step 504, when in learning mode, the whitelist learning logic module 331 can extract the command type of the incoming message (as well as the security level and any other desired information). Then, in step 505, the logic module 331 can use (multiple) whitelist builders 332 to build whitelists and whitelist mappings, as will be understood, to store command types. For example, in one embodiment, in step 504, the whitelist learning logic module 331 can check the security level 323 of the device 300, and can further look up the security level in the (multiple) whitelist builders to check whether there is an existing whitelist for that security level. In the event that there is an existing whitelist, the logic module 331 can append the command type to the whitelist in the whitelist builder logic or data 332 in step 505. In the absence of an existing whitelist, the logic module 331 can store a new whitelist corresponding to the security level, wherein the whitelist contains the command type of the incoming message. In another embodiment, the whitelist builder 332 can further store a mapping from a combination of (multiple) security levels and (multiple) command destinations (and / or other information) to (multiple) whitelists. For example, in one embodiment, the whitelist learning logic module 332 can check the security level 323 of the security gateway device 300 and the device destination (e.g., device address) of the incoming message. The logic module 331 can then look up the value corresponding to the security level and the device destination in the whitelist builder data 332 to see if there is a whitelist for the combination. If a whitelist exists, the logic module 331 can append the command type to the whitelist, and if a whitelist does not exist, the logic module 331 can create a new whitelist containing the command type for the destination device.The whitelist learning application 330 may communicate with the whitelist execution application 320 at various points during execution of the learning application 330. Specifically, the learning application 320 may directly edit when new commands are received, instead of or in addition to using the whitelist builder logic or data 332. Figure 3B Of course, when building a whitelist during the learning mode, as illustrated in step 506, the logic module 311 can return a message or command to the communication interface when normal operation is allowed.

[0050] Finally, when the whitelist learning application 330 recognizes that the device has switched from the learning state to the locked state or is switching from the learning state to the locked state, the application 330 (or its logic module 331) can appropriately update the whitelist enforcement application 320, including updating one or more whitelists used by the application 320. If the application 330 has stored its learned information in the whitelist builder(s) 332, the application 320 can then clear the whitelist builder(s) 332. Before being cleared, it can also configure the whitelist enforcement application 320 based on the updated whitelist reflecting the information contained in the whitelist builder(s) 332. For example, when the device 300 switches from the learning state to the locked state, the application 323 can append all commands from the whitelists it has built (as reflected in the builder logic or data 332) to the appropriate whitelists in the whitelist configuration information 324 of the whitelist enforcement application 330. Alternatively, during the learning mode, the application 330 may replace the whitelist stored in and used by the whitelist execution application 320 with a whitelist created in or by the builder logic or data 332. It will be appreciated that the whitelist learning application 330 enables automatic learning or building of a whitelist for use by the whitelist execution application 320 based on known normal operation of the process control and safety system.

[0051] Will refer to Figure 6 -9 Describe in more detail Figure 1 The whitelist configuration application 80 operates. Specifically, Figure 6 Shows the settings Figure 1 A security whitelist configuration application 80 in one of the workstations 16 of the process plant, wherein the whitelist configuration application 80 can be executed to perform whitelist configuration actions, such as creating and establishing one or more whitelists for use in one or more of the security gateway devices in the process plant (e.g., Figure 1The whitelist configuration application 80 is configured to execute a whitelist configuration logic module on a processing unit 601 and is communicatively coupled to a configuration memory 610 including configuration information, a communication layer 630 for communicating with other devices in the process plant 10, and a user display interface 620 for interacting with a user interface to provide information to and obtain information from one or more users.

[0052] More specifically, the security whitelist configuration application 80 interacts with communication software such as a communication layer or stack 630 that communicates with the process controllers 24 and 26 via the Ethernet connection 22 to send signals to and receive signals from the controllers 24 and 26, the safety logic modules 50-56, the I / O devices 28-36, the field devices 40, 42, 60 and 62, and / or other workstations 16. The communication layer 630 also appropriately formats messages (e.g., alarm confirmation signals) to be sent to the controllers, I / O devices, field devices, safety logic solvers, and other workstations. The communication software 630 can be any known or desired communication software currently used, for example, with Ethernet communications. Of course, the communication stack 630 can be coupled to other software running within the workstation 16 that performs other functions, such as configuration applications, diagnostic or other process applications, database management applications, etc.

[0053] The configuration memory 610 may store or provide configuration information representing the physical and electrical configurations, connections, and links within the process plant 10 , and may define communication capabilities between devices within the process plant 10 . Figure 6 The configuration information can be Figure 1 The configuration information database 21 of the process control system 12 and the safety system 14 may be stored locally, or the configuration information may be obtained from another location. The user display interface 620 within the workstation 16 enables the whitelist configuration application 80 to read user input to provide information to the user, or perform any other user interface activities. Generally, the processing unit 601 can operate in conjunction with the user display interface 620 to detect requests to read from or write to elements within the process control system 12 and the safety system 14. Collectively, the configuration information storage 610, the user display 620, and the communication layer 630 operate to implement the functionality of the whitelist configuration application 80.

[0054] Generally speaking, the whitelist configuration application 80 is executed on the processing unit 601 to perform a secure whitelist configuration process with respect to any desired whitelist configuration to the process controller(s) 24 and / or 26 of the process control system 12, or the safety logic solver(s) 50-56 of the safety system 14, or any other secure gateway device within the plant 10. The whitelist configuration application 80 is configured to authenticate a user, create one or more whitelists, receive instructions from the user to edit a whitelist or change the configuration of the whitelist execution application 320 through read and write functions, and configure the desired secure gateway devices and their corresponding whitelist execution applications 320. Figure 6 As shown, the whitelist configuration application 80 includes a device-specific command discovery module 602, a whitelist configuration logic module 603, a set of stored access permissions 604, a configuration information module 605, a set of encryption rules 606, a whitelist configuration information module 607, and a secure write server 608. Although the secure whitelist configuration application 80 is illustrated as a stand-alone application, it will be understood that the application can be incorporated into Figure 1 in any other application used in an operator workstation 16 (or any other computer) to ensure that reading from and writing to the safety system 14 (and, if desired, the process control system 12) can proceed according to the security whitelist configuration application 80.

[0055] Typically, the whitelist configuration logic module 603 is executed on the processing unit 601 to execute logic associated with the application 80, and more specifically, operates to perform configuration of the whitelist execution application 320 and the whitelist learning application 330 using other modules (which may be subroutines) or information components 602 and 604-608 in conjunction with the communication layer 630, the configuration information 610, and the user display interface 620. These configuration activities may include creating and setting (downloading) one or more whitelist execution applications 320 and / or whitelist learning applications 330 in one or more security gateway devices in the factory 10, thereby implementing or changing the configuration settings of one or more whitelist execution applications 320 and / or whitelist learning applications 330 in the factory 10, and creating or modifying one or more whitelists used by one or more whitelist execution applications in the factory 10.

[0056] In general, the logic module 603 performs user authentication using a secure write server 608 and a set of stored access permissions 604 that define which authenticated user accounts can configure a whitelist execution application for a particular logic solver, process controller, or other secure gateway device. Further, the logic module 603 can call a device-specific command discovery module 602 to discover one or more commands that are placed in one or more whitelists to be used in one or more of the whitelist execution applications 320. Similarly, the logic module 603 can use a configuration information module 605 to store or obtain general configuration information about the plant 10 and the devices within the plant to create one or more whitelists, and can use a whitelist configuration information module 607 to store or obtain configuration information related to one or more whitelists that have been created for use in the plant 10. Similarly, the logic module 603 can use encryption rules 606 to encrypt information that will be sent to and received from devices within the plant 10.

[0057] During operation, the application 80 may receive information related to the requested whitelist configuration read or write activity from the user display interface 620. In response, the logic module 603 (executed on the processing unit 601) determines whether the requested whitelist configuration read or write belongs to a process controller or a secure logic solver (or other secure gateway device) to which the authenticated user has appropriate access rights 604 (i.e., the user can issue configuration reads and / or writes). As part of this process, the whitelist configuration logic module 603 may receive data from the user display interface 620 and authenticate the user via the secure write server 608. In some cases, the logic module 603 may already know the identity of the user and indicate the user's write / read capabilities in advance by graying out the portion of the user interface display screen of the device that the user cannot read and / or write to it. In other cases, the logic module 603 may alternatively or additionally request the user to provide a password and user identification, and the logic module 603 may check the password and user identification against the stored user access rights 604 to obtain appropriate permissions before performing the requested read and / or write.

[0058] After receiving commands from an authenticated user from the user display interface 620 to configure a particular security gateway device within the plant 10 (e.g., download a whitelist execution application, change settings of a whitelist execution application or learning application, such as placing the device in a learning or lock mode, adding, changing, or deleting a whitelist, etc.), the whitelist configuration logic module 603 uses the whitelist configuration information module 607, the configuration information module 605, and the device-specific command discovery module 602 to prepare configuration commands and send these commands to the appropriate process controllers and / or safety logic solvers to configure one or more whitelist execution applications 320 or whitelists within these devices. These outgoing commands can download or can update the whitelist execution application 320 and whitelist learning application 330 on the process controller and / or safety logic solver, to change settings of these applications, to download or install these applications, to change the whitelists used by these applications, and so on. Thus, the logic module 603 can use the whitelist configuration information module 607 to provide information to the user about the existing whitelist configuration in the process plant 10. The whitelist configuration information module 607 can, for example, store a representation of the whitelist configuration locally in a Figure 6 16, or module 607 may use communication layer 630 to obtain whitelist configuration information, such as from a safety logic device 50-56 and / or process controller 24 or 26 or a configuration database (such as Figure 1 In addition, the configuration information module 605 can obtain the information provided by the configuration application 80 (partially in the configuration application 80) via the network 22 when the logic module 603 needs the information. Figure 2 ) is implemented and stored in Figure 1 Other configuration information in the configuration database 21.

[0059] In one embodiment, the whitelist configuration application 80 configures the whitelist on the logic solver 50-56 or process controller 24 or 26 by enabling the user to issue specific instructions to add or remove specific command types to new or existing whitelists. The configuration application 80 also enables the user to edit the existing whitelist in the same manner. The editing function can be provided by obtaining information from the whitelist configuration information module 607 and providing the information to the user via the user interface, and then enabling the user to specify changes to the whitelist. For example, the whitelist configuration application 80 can receive instructions from the user to configure (multiple) specific devices with certain whitelist configurations. Depending on the access rights 604, the devices that can be changed can be limited to devices of a certain subgroup within the plant 10. As will be understood, the whitelist configuration application 80 can also obtain configuration information from the user specifying which (which) whitelists correspond to (or will be used for) which (multiple) security levels of the specific device. The application 80 then configures the indicated device(s) 300 according to the new whitelist configuration information by sending packets to the devices where the whitelist resides or is used according to a communication protocol such as HART or any other communication method known to those skilled in the art.

[0060] In another embodiment, the whitelist configuration application 80 receives an indication of a safety logic solver 50-56, a process controller 24, 26, and / or a field device and utilizes a device-specific command discovery module 602 to obtain relevant device-specific and general command types for one or more field devices as suggestions for a user to use in a whitelist for the device. The device-specific HART commands discovered by the device-specific command discovery module 602 can be presented to a user of the whitelist configuration application 80 via a user interface 620 as suggested options for building a new whitelist or for editing an existing whitelist. The suggested options can correspond to a field device selected by the user and can additionally or alternatively correspond to a field device connected to the user-selected safety logic solver(s) 50-56 or process controller(s) 24 or 26.

[0061] In another embodiment, the process plant personnel can use the whitelist configuration application 80 to automatically perform any number of the aforementioned steps. The operator or configuration engineer of the process plant can configure the whitelist configuration application 80 to automatically perform the above-mentioned discovery process. The whitelist configuration application 80 can also use the discovery module 602 to automatically build the above-mentioned whitelist of device-specific commands. The whitelist configuration application 80 can additionally or alternatively only use the read command described in detail above to build the above-mentioned whitelist. In addition, the whitelist configuration application 80 can automatically configure the whitelist execution application of a specific safety logic solver 50-56 or process controller 24 or 26 to achieve an automatically generated whitelist. These automated steps can be part of the above-mentioned manual process, or can be automated to any degree desired by those skilled in the art. Each automated step can be executed in response to a command from a user, or it can be executed in response to a change in the process plant. For example, whitelist generation can be automatically performed after field devices 40, 42, 60 or 62 are installed in the process plant, or it can be directly found by the user The recently installed field device 40, 42, 60 or 62. In another example, a user may select a specific device 50 - 56 , 24 , 26 40 , 42 , 60 , or 62 in a process plant and then begin the automatic whitelist generation and configuration process.

[0062] In all of the foregoing embodiments, the configuration information sent across the communication layer 630 to configure the whitelist implementing device 300 may be encrypted using the encryption rules 606 based on information from the user display interface 620 .

[0063] In a preferred embodiment, the whitelist is generally composed of read commands, thereby excluding write commands with more potentially dangerous properties. In addition, in one embodiment, instead of constructing a whitelist consisting of only HART universal type read commands, the whitelist also includes HART device specific type or HART conventional type read commands.

[0064] Figure 7 Shows Figure 6 Flowchart 700 of an example of the logic of the whitelist configuration logic module 603 of the whitelist configuration application 80. In step 701, the logic 603 authenticates the user via a login process. Then, the logic 603 authenticates the user via a login process. Figure 6 The user interface 602 of one of the workstations 16 is presented to the user. In step 702, the logic 603 enables the user to identify the whitelist implementing device 300 to be configured. In one embodiment, if the received information specifies a particular field device and / or field device type(s) 40, 42, 60, and / or 62, then determining the whitelist implementing device 300 selected by the user may require additional steps. The additional steps may be configured using Figure 6The configuration information module 605 is used to obtain the identity of the safety logic solver 50-56 and / or the process controller 24 or 26 (or other safety gateway device), which is coupled to the specified field device and / or field device type or acts as a gateway for the specified field device and / or field device type. Next, in step 703, the whitelist configuration logic module 603 executes the device-specific command discovery module 602, as described in more detail below, to determine or discover a set of device commands that can be used in a whitelist for a specified device. Step 703 can also include building one or more whitelists for the device based on the discovered command information of the device, and the logic module 603 can build these whitelists automatically or based on user input. However, typically, the logic module 603 can provide a set of suggested commands to the user to be placed in one or more whitelists for the device, and enable the user to modify or confirm those suggestions. In steps 704 and 705, the whitelist configuration logic module 603 then constructs a configuration message (e.g., a message including a whitelist to be used or changes to settings of the whitelist execution application 320 and the whitelist learning application 330) and sends the configuration information to one or more whitelist implementation devices 300 (e.g., a security logic solver 50-56 and / or a process controller 24 or 26) to affect the configuration of one or more whitelist execution applications 320 or learning applications 330. Optionally, the whitelist configuration application 80 may perform the authentication step 701 only after the user attempts to send the whitelist configuration information. Alternatively or additionally, the whitelist configuration application 80 may prompt the user to authenticate themselves only after checking to see if the access permission 604 allows general read / write access to avoid unnecessary authentication. Alternatively or additionally, the whitelist configuration logic module 603 may use before the outgoing message is sent Figure 6 The encryption rule 606 is used to encrypt outgoing messages.

[0065] Figure 8 800 is shown, which depicts an example of the operation of the aforementioned device-specific command discovery module 602, which device-specific command discovery module 602 (e.g., in Figure 7 703) is used to collect or discover device-specific and / or general command types that will be used for one or more whitelisted specific field devices. In step 801, module 602 obtains, for example, Figure 6The processing unit 601 receives the target device. Then, in step 802, the module 602 queries the configuration database 21 or the configuration information 610, or otherwise uses the configuration information module 605 to obtain the device-specific command types and / or general command types associated with the selected field device 40, 42, 60 and / or 62. In step 802, the module 602 may optionally only issue a query for device-specific and / or general read command types that will be received from the user or a configuration database that may store these command types. In step 803, the module 602 sends the command type to the processing unit to be used in the manner described above and below. In an alternative embodiment, in step 802, the module 602 issues a read message to the target device or configuration database, for example via Figure 6 602 parses the device description to access or identify the device-specific command types and / or general command types implemented by the device as defined in the device description. In addition, module 602 may determine whether each device command type is a read or write command. In another embodiment, at step 803, device-specific command discovery module 602 then returns the command types to the processing unit, where they are used to Figure 7 The device-specific command discovery module 602 may also optionally return only the read command types it discovers.

[0066] As a more detailed example, in step 802, the device-specific command discovery module 602 sends Figure 1 The configuration database 21 of the device sends a request for the relevant device-specific command type for the relevant device. In this embodiment, the device-specific command type has been parsed from the device description and stored in the configuration database. If desired, the device-specific command discovery module 602 can optionally request only the device-specific read command, which is also parsed and stored in the configuration database 21. In another embodiment, the device-specific command discovery module 602 can request a device description for the relevant device (for example, from the configuration database or from the field device itself), and can process this information directly. For example, the device-specific command discovery module 602 can request a device description from the configuration database, and then parse the device description and extract all device-supported commands, including universal, conventional and device-specific types of HART commands. In this embodiment, the device-specific command discovery module 602 can also further parse the command to discover which device commands (of any type) are read-only commands.

[0067] Determining the complete set of device commands (including common, general, and device-specific commands) to be requested based on the target device can be accomplished by using the configuration information module 605, which can obtain configuration information implemented by the configuration application 82, which is partially in Figure 2 and stored via network 22 Figure 1 Alternatively or additionally, the configuration information may be stored locally on the device 16 hosting the configuration information module 605. For example, a user of the whitelist configuration application 80 may be inclined to build a new whitelist for a process controller. The system may enable a user to Figure 2 CTLR1 is selected as an option in the user display interface 620. The device-specific command discovery module 602 can then determine based on the configuration information module 605 that CTLR1 controls, for example, C01-C04, C06-C09. In one embodiment, the configuration information module 605 can then send Figure 1 The configuration database 21 of the device 80 issues the above request to obtain the device-specific command type of each field device connected to these cards and presents them to the processing unit. In another embodiment, the device-specific command discovery module 602 can issue a read command to read the device description of the field device directly connected to the I / O cards C01-C04 and C06-C09. The module 602 can then parse these device descriptions and compile a list of command types supported by these devices, including various general, conventional and device-specific command types for each of these field devices, and present these command types to the processing unit. The application 80 can then suggest these command types to the user as a suggested whitelist addition. The application 80 can alternatively only present the read commands supported by the device or create or add to one or more whitelists. Determining that the command type is a read command type can be performed during the configuration of the field device. In this way, the read command can be obtained by querying the configuration database 21 only for the device read command. (It should be noted that in this specification, the phrases device command and device command type are used interchangeably.) In another embodiment, the application 80 can parse the complete list of device commands to determine which commands are read commands. For example, this can be done by checking whether the "OPERATION" tag of the command is "READ". The device-specific command discovery module 602 can additionally or alternatively use any caching method known to those skilled in the art to locally store portions of the configuration database information. The device-specific command discovery module 602 can operate in conjunction with, in collaboration with, or with the device installation entity.

[0068] Fig. 9A A simple display screen 900 is illustrated which shows a method for enabling a user to perform Figure 6 and Figure 780. In this embodiment, the system requires the user to enter a username 901 and a user password 902. These credentials may be drawn from other authenticated systems in the process plant 10 or may be specific to the whitelist configuration application 80. The credentials may also be determined by a system administrator, operator, or expert, or by individual users through another application as needed.

[0069] Fig. 9B Another display screen 905 is shown, which shows an exemplary user interface that can be used to enable a user to build, edit and configure a whitelist execution application 320 for a safety logic solver 50-56 and / or a process controller 24 or 26 in a process plant 10. In particular, the left hand side of the display screen 920 is associated with and can be used to perform editing of an existing whitelist or creation and configuration of a new whitelist, while the right hand side of the display screen 910 is associated with displaying existing whitelist configurations 911 and 912. For example, field or portion 911 illustrates the current configuration of the security gateway device SLS1 as including a whitelist A used with a high security level of the device SLS1 and a whitelist C used with a medium security setting of the device SLS1. In addition, whitelist A includes four enabled or allowed read commands or command types and specifies encryption, while whitelist C includes five enabled or allowed read commands or command types and also specifies encryption. Further, field or portion 912 illustrates whitelists that have been configured for all process control devices (e.g., process controllers) at high and low security settings.

[0070] In general, the first group of fields 921 on the left hand side of the screen 920 represent or list whitelist implementation devices 927, which can be configured to include one or more whitelists or whitelist execution applications 80. These devices 927 can include any of the following: a security logic solver 50-56 and / or a process controller 24 or 26 or any other security gateway device or node in the factory. A user can select one of the devices 927 to perform configuration on that device or create one or more whitelists for that device. The authentication process that has been described may cause some users to see certain grayed-out whitelist implementation devices 927, indicating that the user does not have access rights to read and / or write whitelist configurations for these whitelist implementation devices 927.

[0071] A second set of fields 922 indicates the security level of the selected device 927. The user may select one of a variety of different security levels in field 922 to configure or create different whitelists for each security setting of a particular selected device 927. The user may use a set of commands or inputs in field 923 to build one or more whitelists for the selected device at the selected security level. Field 923 may allow the user to specify an existing whitelist to be used or an existing device command to be used at input 926 to build a new whitelist for the device. Additionally or alternatively, field 928 may display a set of discovered device command types (e.g., more generally, including general device command types 928a and device-specific command types 928b), which are identified by, for example, Figure 6 The operation of the discovery module 602 is identified. In this case, the user may also or additionally select individual ones of the discovered command types to be included in the whitelist by selecting the checkboxes next to the command types.

[0072] Thus, as described above, when the system confirms that the user has selected a specific gateway device 927 (which is connected to or communicates with the various specific field devices using those commands), the configuration application 80 can use Figure 3B The whitelist configuration information module 607 reads values ​​from the existing whitelist configuration and presents the information to the user. When the user selects one or more of the process controller(s) or safety logic solver(s) from the left side of the display 920, the configured security levels and corresponding whitelists are available for the user to edit. In one embodiment, the whitelist is displayed as a list of command types with check boxes next to them (i.e., they are pre-selected), and the system enables the user to add new command types to the existing whitelist by selecting or entering the new command type. The system also enables the user to remove command types from the whitelist by deselecting the pre-selected command types on the left side of the display. In another embodiment, the existing whitelist configuration on the right panel 910 may provide an edit button to allow editing using a pop-up display.

[0073] In a similar manner, application 80 can enable the user to use the left side of display screen 920 to write values ​​into a new or existing whitelist configuration. In particular, the system can enable the user to select the desired (multiple) whitelist implementation device 927. These values ​​can specify a process controller or a safety logic solver or other safety gateway device. Application 80 can then enable the user to select a security level 922. The security level can, for example, have a low, medium and high format, or be specified in any other way. The security level can also be in a binary format, such as safe, unsafe, or they can have any other desired format. Then, the user will use field 923 to determine the whitelist that will be assigned to the (multiple) selected device at the (multiple) given security level. Depending on the embodiment, a list 928 of the relevant device-specific and / or conventional command types that will be selected from can be presented to the user, or application 80 can enable the user to enter the command type without presenting the command type suggestion found. Application 80 can also enable the user to select encrypted configuration information via field 924 to make it reach the intended destination safely. Once the device to be configured (field 921), the security level of the device to be configured (field 922), the whitelist details for the device being configured (field 923), and the encryption status of the whitelist (field 926) are specified, the user can select the Submit button 925 to cause the application 80 to generate the whitelist being created and download the whitelist to the intended security gateway device 927 to be used to perform advanced security operations within the process plant 10 using the whitelist and whitelist application described herein.

[0074] Of course, while the screen display 905 enables a user to configure a single security gateway device at a time, the user interface associated with the application 80 may enable selection of individual field devices 40, 42, 60, and / or 62, alternatively or in addition to whitelist-implementing devices. Alternatively or in addition to individual field devices and / or whitelist-implementing devices, the user interface of the application 80 may also enable selection of field device types, and may enable configuration of a group of security gateway devices (such as all process controllers, all safety systems in a particular area of ​​a plant, etc.) to be configured with the same configuration information or whitelist.

[0075] It is emphasized that the above described systems and methods can be applicable to situations where the process includes a variety of field devices. Using the described methods and systems, coarse-grained blocking of all non-generic non-read commands is not necessary and can be used in conjunction with blocking general non-read commands and / or device-specific non-read commands to produce a more granular blocking approach that allows critical information to pass while also providing an appropriate level of network security between workstations, process controllers, safety logic solvers, I / O devices, and their associated field devices.

[0076] In general, any use of the term "safety logic solver" herein may be used interchangeably with a process controller, vice versa, or with any other desired process plant device. Additionally, any use of the term "read command" or "read message" herein may be used interchangeably with "write command" or "write message" or any other suitable HART command classification, and vice versa. Still further, any use of the term device-specific HART command may be used interchangeably with a conventional HART command, and vice versa. Finally, any reference to the HART communication protocol herein may be used interchangeably with another desired communication protocol.

[0077] In addition, the term "field device" is used broadly herein to include multiple devices or combinations of devices (i.e., devices that provide multiple functions, such as a transmitter / actuator hybrid) and any other device(s) that perform a function in a control system. In any case, field devices may include, for example, input devices (e.g., devices such as sensors and instruments that provide status, measurement results, or other signals indicative of process control parameters (e.g., temperature, pressure, flow rate, etc.), and control operators or actuators that perform actions in response to commands received from controllers and / or other field devices.

[0078] When implemented, any software described herein may be stored in any computer-readable memory, such as on a magnetic disk, laser disk or other storage medium, in the RAM or ROM of a computer or processor, etc. Likewise, the software may be transmitted to a user, process plant or operator workstation using any known or desired transmission method, including, for example, on a computer-readable disk or other transmittable computer storage mechanism, or through a communication channel (e.g., telephone line, Internet, World Wide Web, any other local area network or wide area network, etc. (transmission is considered to be the same or interchangeable with providing such software via a transmittable storage medium). In addition, the software may be provided directly without modulation or encryption, or may be modulated and / or encrypted using any appropriate modulation carrier wave and / or encryption technique before being sent over a communication channel.

[0079] Although the present invention has been described with reference to specific examples, these specific examples are merely illustrative and not limiting of the present invention, and it is obvious to those skilled in the art that changes, additions or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the present invention.

Claims

1. A computer-implemented method of providing security in a process plant, the method being performed by one or more processors contained in a device associated with the process plant and programmed to perform the method, the method comprising: storing a whitelist of command types for a process control communication protocol, the whitelist of command types being stored based on an identification of one or more of device-specific read commands and regular read commands supported by the device such that the whitelist of command types includes one or more of the device-specific read commands and the regular read commands; receiving a message at the device via a communication interface, wherein the message complies with the process control communication protocol; extracting a command type from the message; checking the extracted command type against a stored white list of command types for the process control communication protocol; and The message is allowed when the extracted command type is included in the whitelist of command types for the process control communication protocol, and the message is not allowed when the extracted command type is not included in the whitelist of command types for the process control communication protocol.

2. The method according to claim 1, wherein: Receiving the message includes receiving the message at a process controller associated with a process control system within the process plant, wherein the process controller is communicatively coupled to one or more process control field devices and performs control functions with respect to the process plant.

3. The method according to claim 2, wherein: Allowing the message includes enabling the process controller to forward the message to one or more of the process control field devices via a communication link.

4. The method according to claim 2, wherein: Allowing the message includes enabling one or more logic modules within the process controller to process the message.

5. The method according to claim 1, wherein: Receiving the message includes receiving the message at a safety logic solver associated with a process control system in the process plant, wherein the safety logic solver is communicatively coupled to one or more safety field devices and performs safety control functions with respect to the process plant.

6. The method according to claim 5, wherein: Allowing the message includes enabling the safety logic solver to forward the message to one or more of the safety field devices over a communication link.

7. The method according to claim 5, wherein: Allowing the message includes enabling one or more logic modules within the safety logic solver to process the message.

8. The method according to claim 1, wherein: Not allowing the message includes not forwarding the message over the communication network to another device to which the message is addressed.

9. The method according to claim 1, wherein: Not allowing the message includes sending a notification through the communication network that the message is not allowed.

10. The method according to claim 9, wherein: Sending the notification includes notifying one or more of a plant operator, a maintenance person, and a configuration engineer that the message is not allowed.

11. The method according to claim 1, wherein: The process control communication protocol is a highway addressable remote transmitter (HART) communication protocol, wherein receiving the message at the device via the communication interface includes: receiving a HART protocol message at the communication interface, wherein storing a whitelist of command types includes: storing a whitelist of command types associated with the HART communication protocol, and wherein checking the extracted command type against the whitelist of command types includes: checking the extracted command type against the whitelist of HART communication protocol command types.

12. The method according to claim 1, further comprising: Multiple whitelists of command types for the process control communication protocol are stored, and wherein checking the extracted command type against the whitelist of command types for the process control communication protocol includes: selecting one of the stored whitelists of command types for the process control communication protocol as the whitelist of command types for comparing the extracted command type.

13. The method according to claim 12, wherein: Selecting one of the stored whitelists includes selecting one of the stored whitelists based on a security level associated with the device associated with the process plant.

14. The method according to claim 13, further comprising: The security level associated with the device associated with the process plant is determined by determining a hardware security setting of the device associated with the process plant.

15. The method according to claim 13, further comprising: The security level associated with the device associated with the process plant is determined by determining a security setting stored with software of the device of the process plant.

16. The method according to claim 1, wherein: Receiving the message includes: receiving the message at a gateway device associated with a process control system; storing the whitelist of command types for the process control communication protocol includes: storing the whitelist of command types for the process control communication protocol in the gateway device; and wherein, allowing the message when the extracted command type is included in the whitelist of command types for the process control communication protocol includes: allowing the gateway device to process the message and take action on the message, and wherein, not allowing the message when the extracted command type is not included in the whitelist of command types for the process control communication protocol includes: not allowing the gateway device to process the message and take action on the message.

17. The method according to claim 1, wherein: Receiving the message includes: receiving the message at an input / output device coupled between a process controller device and one or more field devices associated with a process control system within the process plant, wherein storing the whitelist of command types for a process control communication protocol includes: storing the whitelist of command types for the process control communication protocol in the input / output device, and wherein, allowing the message when the extracted command type is included in the whitelist of command types for the process control communication protocol includes: forwarding the message to another device addressed by the message, and wherein, not allowing the message when the extracted command type is not included in the whitelist of command types for the process control communication protocol includes: not forwarding the message to another device addressed by the message.

18. A process control device comprising: Memory; a whitelist of command types for a process control communication protocol stored in the memory, the whitelist of command types stored based on an identification of one or more of device-specific read commands and regular read commands supported by the process control device such that the whitelist of command types includes one or more of the device-specific read commands and the regular read commands; a communication interface adapted to be coupled to an external communication network; a processor coupled to the communication interface; as well as a whitelist routine stored in the memory and adapted to be executed on the processor to: extracting a command type from a message received at the communication interface from the external communication network in a specific process control communication protocol, checking the extracted command type against the white list of command types for the process control communication protocol, and The message is allowed when the extracted command type is included in the white list of command types for the process control communication protocol, and the message is not allowed when the extracted command type is not included in the white list of command types for the process control communication protocol.

19. The process control device of claim 18, wherein: The process control device is a process controller that is communicatively coupled to one or more process control field devices and performs control functions with respect to a process plant.

20. The process control device of claim 18, wherein: The process control device is a safety logic solver that is communicatively coupled to one or more safety-related process control field devices and performs safety-related control functions with respect to the process plant.

21. The process control device of claim 18, wherein: The process control device is an input / output device that is communicatively coupled between a process controller and field devices within a process plant.

22. The process control device of claim 18, wherein: The process control device is a gateway device coupled between two process control communication networks in a process plant.

23. The process control device of claim 18, wherein: The whitelist routine allows the message by forwarding the message to one or more other devices addressed by the message via a communication network, and does not allow the message by not forwarding the message to one or more other devices addressed by the message via any communication network.

24. The process control device of claim 18, further comprising one or more logic modules stored in the memory, and wherein: The whitelist routine allows the message by enabling the one or more logic modules to execute on the processor to process the message, and disallows the message by not allowing the one or more logic modules to execute on the processor to process the message.

25. The process control device of claim 18, wherein: When the message is not allowed, the whitelist routine sends a notification that the message is not allowed through the external communication network.

26. The process control device of claim 25, wherein: The whitelist routine sends the notification that the message is not allowed to one or more of a plant operator, maintenance personnel, and a configuration engineer.

27. The process control device of claim 18, wherein: The process control communication protocol is a Highway Addressable Remote Transmitter (HART) communication protocol.

28. The process control device of claim 18, further comprising a plurality of different whitelists of command types for the process control communication protocol stored in the memory, and wherein: The whitelist routine also selects one of the stored whitelists of command types for the process control communication protocol as the whitelist for checking the extracted command type.

29. The process control device of claim 28, wherein: The whitelist routine selects the one of the stored whitelists as the whitelist to be used based on a security level associated with the process control device.

30. A computer-implemented method of performing security in a process plant communication network, the method being performed by one or more processors contained in a device having a communication interface coupled to the communication network and programmed to perform the method, the method comprising: At a first time, the device is placed in a learning state, wherein when the device is in the learning state, the method includes identifying a command type of a device-specific command or a general command supported by each of one or more process control field devices in the process plant communication network by: receiving one or more messages at the communication interface via the communication network, each of the one or more messages conforming to a specific process control communication protocol, extracting a command type associated with the particular process control communication protocol from each of the one or more messages, the command type comprising a device-specific command or a general command supported by the device, storing the extracted one or more command types in one or more whitelists such that the whitelists include one or more of device-specific commands or general commands supported by the device, and storing the one or more whitelists in the device; and At a second time, the device is placed in a locked state, wherein when the device is in the locked state, the method comprises: receiving one or more messages at the communication interface via the communication network, each of the one or more messages conforming to the particular process control communication protocol, and A whitelist application operation is performed on each of the one or more messages received at the communication interface via the communication network using one of the one or more stored whitelists.

31. The method according to claim 30, wherein: Storing the extracted one or more command types in the one or more whitelists includes storing the extracted one or more command types in a specific one of the one or more whitelists based on a security setting of the device.

32. The method according to claim 31, wherein: The security setting is a hardware-based security setting.

33. The method of claim 30, wherein: When the device is in a locked state, performing a whitelist application operation on each of the one or more messages received at the communication interface via the communication network includes: extracting a command type from each of the one or more messages, checking the extracted command type against one of one or more stored whitelists of command types for the process control communication protocol, and The message is allowed when the extracted command type is included in one of the one or more whitelists of command types for the process control communication protocol, and the message is not allowed when the extracted command type is not included in one of the one or more whitelists of command types for the process control communication protocol.

34. The method of claim 33, wherein: Allowing the message includes forwarding the message to another process control device to which the message is addressed via an external communication link.

35. The method of claim 33, wherein: Allowing the message includes enabling one or more logic modules within the device to process the message.

36. The method of claim 33, wherein: Not allowing the message includes not forwarding the message to another device addressed by the message over an external communication link.

37. The method of claim 33, wherein: Not allowing the message further comprises: sending a notification through the communication network that the message is not allowed.

38. The method of claim 30, wherein: The particular process control communication protocol is the Highway Addressable Remote Transmitter (HART) protocol.

39. The method of claim 30, further comprising: During the first time that the device is in the learning state, receiving a message instructing the device to exit the learning state, and in response to receiving the message instructing the device to exit the learning state, storing the one or more whitelists in the device used in the locked state.

40. A process control device comprising: computer readable memory; a communication interface adapted to be coupled to an external communication network; a processor coupled to the communication interface; as well as a whitelist routine stored in the computer readable memory and adapted to be executed on the processor to operate in one of a learning state or a locked state, wherein when the whitelist routine operates in the learning state, the whitelist routine identifies a command type of a device-specific command or a general command respectively supported by each of the one or more process control field devices by the following operations; receiving one or more messages from the external communication network via the communication interface, each of the one or more messages conforming to a specific process control communication protocol, extracting a command type associated with the particular process control communication protocol from each of the one or more messages, the command type comprising a device-specific command or a general command supported by at least one of the one or more process control field devices, and storing the extracted one or more command types in at least one whitelist in a set of whitelists such that the at least one whitelist in the set of whitelists includes one or more of device-specific commands or general commands supported by the one or more process control field devices; and When the whitelist routine operates in the locked state, the whitelist routine performs the following operations: receiving one or more messages from the external communication network via the communication interface, each of the one or more messages conforming to the specific process control communication protocol, and A whitelist application operation is performed using a whitelist from the set of whitelists on a message received at the communication interface via the communication network.

41. The process control device of claim 40, further comprising: When the whitelist routine is in the learning state, the extracted one or more command types are stored in a specific one of the set of whitelists based on the security settings of the device.

42. The process control device of claim 41, further comprising a hardware configurable security setting indicating a level of security to be applied to communications.

43. The process control device of claim 41, further comprising a software configurable security setting indicating a level of security to be applied to communications.

44. The process control device of claim 40, further comprising: Upon receiving a command for exiting the learning state via the external communication network, the set of whitelists is stored in the memory for use in the learning state.

45. The process control device of claim 40, wherein: The whitelist routine performs a whitelist application operation on each of the one or more messages received at the communication interface via the external communication network in the locked state by: extracting a command type from each of the one or more messages, checking the extracted command type against a whitelist in the set of whitelists, and The message is allowed when the extracted command type is contained in the one of the set of whitelists, and the message is not allowed when the extracted command type is not contained in the one of the set of whitelists.

46. ​​The process control device of claim 45, wherein: The whitelist routine allows the message by forwarding the message via a communication link to another process control device to which the message is addressed.

47. The process control device of claim 45, further comprising one or more logic modules stored in the computer memory and executable on the processor to perform functions, wherein: The whitelist routine allows the message by enabling the one or more logic modules within the process control device to process the message and perform a function based on the message.

48. The process control device of claim 45, wherein: The whitelist routine disallows the message by not forwarding the message to another device addressed by the message via a communications link.

49. The process control device of claim 45, further comprising one or more logic modules stored in the computer readable memory and executable on the processor to perform functions, wherein: The whitelist routine disallows the message by preventing the one or more logic modules within the process control device from processing the message and performing functions based on the message.

50. The process control device of claim 40, wherein: The particular process control communication protocol is the Highway Addressable Remote Transmitter (HART) protocol.

51. A configuration system for configuring communications in a process control system associated with a process plant having one or more field devices communicatively coupled to one or more control devices, the configuration system comprising: a first routine stored in a computer readable memory and adapted for execution on a processor to obtain configuration information related to configuration of the one or more field devices in the process plant, the configuration information being related at least in part to a command type of a particular process control communication protocol, the command type indicating one or more of a device-specific read command and a general read command supported by a corresponding field device of the one or more field devices; a second routine stored in the computer readable memory and adapted to be executed on the processor to present said configuration information to a user via a user interface; a third routine, stored in the computer-readable memory and adapted for execution on the processor, to enable a user to specify contents of at least one whitelist, said at least one whitelist comprising a list of command types for said particular process control communication protocol, said list of command types comprising device-specific commands or general commands supported by said one or more field devices in said process plant; as well as A fourth routine, stored in the computer readable memory and adapted to be executed on the processor, sends the at least one whitelist to a control device to configure the control device to implement whitelisting for communications using the particular process control communications protocol received at the control device.

52. The configuration system of claim 51, wherein: The first routine acquires configuration information including information related to a communication connection of the one or more field devices to the control device.

53. The configuration system of claim 51, wherein: The first routine obtains configuration information including one or more command types of the particular process control communication protocol supported by each of the one or more field devices.

54. The configuration system of claim 51, wherein: The first routine obtains configuration information specifying one or more read command types of the particular process control communication protocol supported by each of the one or more field devices.

55. The configuration system of claim 51, wherein: The first routine includes a discovery routine that parses a device description for at least one of the one or more field devices to determine one or more command types of the particular process control communication protocol supported by the at least one of the one or more field devices.

56. The configuration system of claim 51, wherein: The first routine obtains the configuration information from a user via a user input device.

57. The configuration system of claim 51, wherein: The first routine obtains the configuration information from a configuration database.

58. The configuration system of claim 51, wherein: The first routine obtains the configuration information from a field device of the one or more field devices in the process control system.

59. The configuration system of claim 51, wherein: The third routine enables the user to specify the security level for which the whitelist is to be applied.

60. The configuration system of claim 51, wherein: The third routine enables a user to add and remove command types from the at least one whitelist.

61. The configuration system of claim 51, wherein: The third routine enables a user to create a plurality of different whitelists for the controlling device, each of the plurality of different whitelists being associated with a different security setting for the controlling device.

62. The configuration system of claim 51, wherein: The fourth routine downloads a whitelist implementation routine to the control device, the whitelist implementation routine being configured to allow or deny messages at the control device using a whitelist provided to the control device.

63. The configuration system of claim 51, wherein: The control device is a process controller that performs process control functions using the one or more field devices.

64. The configuration system of claim 51, wherein: The control device is a safety controller that performs a safety control function using the one or more field devices.

65. The configuration system of claim 51, wherein: The control device is a gateway or input / output device coupled between two different communication networks in the process control system.

66. The configuration system of claim 51, wherein: The third routine enables a user to select one of a plurality of control devices for which a whitelist is to be created.

67. The configuration system of claim 66, wherein: The first routine acquires configuration information indicating the field devices connected to the selected control device.

68. The configuration system of claim 51, wherein: The third routine enables a user to view and change one or more whitelists stored in the control device.

69. The configuration system of claim 51, wherein: The third routine enables a user to apply the same whitelist to multiple different control devices.

70. A process control system for controlling the operation of a process in a process plant, comprising: a plurality of field devices that perform physical functions within the process in the process plant; one or more control devices coupled to the plurality of field devices via one or more communication networks, wherein at least one of the control devices includes a processor and a communication application executing on the processor to implement a whitelist filtering operation on messages received at the control device; and a configuration system communicatively coupled to the one or more control devices, the configuration system comprising a processor and a computer readable memory, and a configuration application stored in the computer readable memory and adapted to be executed on the processor to perform the following operations: obtaining configuration information related to configuration of one or more of the field devices in the process plant, the configuration information related to a command type of a specific process control communication protocol, the command type indicating one or more of a device-specific read command and a general read command supported by a corresponding field device of the plurality of field devices; presenting the configuration information to a user via a user interface; enabling the user to specify contents of at least one whitelist, the at least one whitelist comprising a list of command types for the particular process control communication protocol, the list of command types comprising device-specific commands or general commands supported by the one or more of the field devices in the process plant; and The at least one whitelist is sent to one of the one or more control devices to configure a communication application of the one of the one or more control devices, thereby using the at least one whitelist to implement the whitelist filtering operation on messages at the control device.

71. The process control system of claim 70, wherein: The configuration application acquires configuration information including information related to a communication connection of the one or more field devices to the control device.

72. The process control system of claim 70, wherein: The configuration application obtains configuration information including one or more command types of the particular process control communication protocol supported by one or more of the field devices.

73. The process control system of claim 70, wherein: The configuration application includes a discovery routine that parses a device description for at least one of the one or more field devices to determine one or more command types of the particular process control communication protocol supported by the at least one of the one or more field devices.

74. The process control system of claim 70, wherein: The configuration application obtains the configuration information from a user via a user input device.

75. The process control system of claim 70, wherein: The configuration application obtains the configuration information from a configuration database.

76. The process control system of claim 70, wherein: The configuration application obtains the configuration information from a field device of the one or more field devices in the process control system.

77. The process control system of claim 70, wherein: The configuration application enables a user to specify a security level of the control device for which the whitelist is to be applied.

78. The process control system of claim 70, wherein: The configuration application enables the user to add and remove command types from the whitelist.

79. The process control system of claim 70, wherein: The configuration application enables a user to create a plurality of different whitelists for the controlling device, each of the plurality of different whitelists being associated with a different security setting for the controlling device.

80. The process control system of claim 70, wherein: The configuration application additionally downloads the communication application implementing the whitelist filtering operation to the control device.

81. The process control system of claim 70, wherein: The control device is one of: a process controller that uses one or more of the field devices to perform process control functions, a safety controller that uses one or more of the field devices to perform safety control functions, and a gateway or input / output device coupled between two different communication networks in the process control system.

82. The process control system of claim 70, wherein: The configuration application enables a user to view and change one or more whitelists stored in the control device.

83. The process control system of claim 70, wherein: The communication application implements the whitelist filtering operation; extracting a command type from each of the one or more messages arriving at the control device, checking the extracted command type against a stored white list of command types for the process control communication protocol, and The message is allowed when the extracted command type is contained in a stored whitelist of command types for the process control communication protocol, and the message is not allowed when the extracted command type is not contained in the stored whitelist of command types for the process control communication protocol.

Images