Patent Application
20240146694
The present disclosure relates to computing device security, and more particularly, to techniques for securing control systems for critical infrastructure.
Many advancements have been made in recent years in the field of data communications and network security. However, in certain situations, legacy devices that are incapable of adopting these advancements are still in use for a variety of reasons. For example, most circuit breakers in use today do not support message or transport-level security. As a result, these circuit breakers rely on legacy unsecured communication protocols. While replacing these circuit breakers is the best option from a security perspective, many installations make this impractical due to downtime, cost, etc. And more generally, there are industries where unsecured protocols (e.g., clear-text data communications and other unsecured communication protocols) are still in-use and may even be required in order to ensure compatibility and transparency with monitoring and intrusion detection systems.
A more detailed description of the disclosure, briefly summarized above, may be had by reference to various embodiments, some of which are illustrated in the appended drawings. While the appended drawings illustrate select embodiments of this disclosure, these drawings are not to be considered limiting of its scope, for the disclosure may admit to other equally effective embodiments.
Identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. However, elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation.
Embodiments described herein provide techniques for securing communications in legacy systems. Power systems in critical infrastructure are designed with a solid and secure foundation. This includes implementing a full defense-in-depth strategy with layers of firewalls, intrusion detection systems as well as elements of physical security. One challenge of a securing an implementation is that many devices for power, building management, automation and industrial process require unprotected protocols (such a Modbus or IEC61850) and will not support message-based encryption. While a single vendor can instrument a secure process for their products (such as requiring secure Modbus), there will remain situations where legacy communications must take place with third-party hardware. Embodiments described herein provide a solution to raise the bar on security while allowing the continued use of these legacy protocols.
More particularly, embodiments described herein relate to power monitoring systems and/or Supervisory Control and Data Acquisition (SCADA) system and the ability of these systems to dynamically configure downstream network devices (firewalls, intrusion detection/prevention or SIEM systems) when events or actions occur. Generally, systems exist that communicate with downstream networking devices to configure settings dynamically. However, that these existing systems rely on configured events, statuses or conditions that occur on the network infrastructure. Embodiments described herein not only focus on the network infrastructure, but to also focus on the electrical network infrastructure for events that are happening or are about to happen.
Generally, power systems and/or SCADA systems contain critical information that is not captured and analyzed by these network-based systems today. For instance, a SCADA system may be aware that a load-shedding event is going to take place (e.g., at a specific time or in response to specific user input). Based on this information, the SCADA system could reconfigure, using a secure channel, the security devices on an Industrial Control System (ICS) network to allow specific control messages (resulting in electrical relay or circuit breaker operations). That is, while the legacy devices in these networks may not be able to implement appropriate security protocols, modern security devices (e.g., routing devices) may be configured to implement modern security measures. Accordingly, embodiments can transmit configuration instructions to the security devices using a secure channel (e.g., encrypting the configuration instructions using a public key previously provided by the security device, whereby the security device could use a private key to decrypt the received configuration instructions). Once the operation is complete, the network could then be re-configured to a more secure state. Advantageously, embodiments described herein provide the programmatic creation of signatures for packet data to instruct the firewall on when to permit or block the passage of data, thereby improving the security of the system.
One part of the defense-in-depth strategy to securing a network involves placing firewalls at various levels of the network hierarchy. This includes edge firewalls (at the edge, or “entrance” to the network) as well as lower level sub-networks (e.g., within a single switch board or panel board). Conventionally, power systems may only include an edge firewall and the remainder of the ICS network (or power network) is considered “secure,” but this misconception leads to a false sense of security. Further, even for systems with multiple firewalls on varying layers, these systems are generally setup in an IT-centric fashion, where security is concentrated on TCP ports and IP addresses, and not the actual protocol data that they permit to pass.
Recent firewalls have the ability to pass traffic based on the application, or protocol. Some firewalls have the ability to inspect ICS-specific protocols such as Modbus or IEC61850. In these cases, the firewall can condition the traffic to only allow control writes to, e.g., a specific Modbus register. Unfortunately, most conventional ICS firewalls have shortcomings that make it impossible to use for the intended purpose. For instance, many Modbus devices have custom functions (or vendor functions) that the ICS firewall does not understand. As a result, most conventional ICS firewalls are configured in a way that they are essentially TCP-port filtering (e.g., for Modbus, they are open on port 502 for all traffic).
Embodiments described herein provide a firewall configured to understand ICS protocols and to include a time-based element and a trigger that is defined in the SCADA or software system. ICS Firewalls typically have a secured API interface that could allow communication directly from a SCADA, and ICS-capable firewalls generally have the ability to customize a signature for traffic that they are instructed to permit or block. For instance, if given an example TCP packet of desired data (e.g., from Wireshark or some other packet capturing software), one can configure the firewall with portions of the packet data, in conjunction with regular expression and basic conditional operators, to permit or block similar packets in the future. Embodiments described herein take advantage of this by programmatically orchestrating signatures in real time and applying them at precise times.
Generally, a SCADA system has a system-level context, meaning that the SCADA system is aware of all of the devices on the network, all of the device capabilities (e.g., including register maps/lists) and all of the other computers and network-capable devices on the ICS network. The SCADA typically contains this context as it is the responsibility of the SCADA to communicate with the human users (through a Human Machine Interface (HMI) or other means such as notification). In addition to the static context, the SCADA system may also be aware of upcoming events and actions that may take place.
Using a scheduler, the SCADA system may start a sequence of control operations at a specific time. For example, the SCADA system may have an event-triggered script that executes control commands when a specific event is triggered. Using this additional context, the SCADA system can “wrap” control signals with firewall updates.
The SCADA system can also send updates to the firewall when the state of the system changes. For instance, if a device is added to the SCADA system, then the SCADA system can send the necessary configuration updates to the firewalls to allow data to travel from this new device. As the SCADA system already has the information about the device (IP address, Modbus register map, etc.), the SCADA system can develop signatures to be used for configuration (in XML or similar format).
According to one embodiment described herein, a SCADA system can manage the addition and/or removal of a device from a power network. For example, a power metering device could be installed in a panel that requires communication with the SCADA system. In the present example, the device has an IP address configured locally, and an application engineer adds the device by providing the IP address to the SCADA system using the SCADA development environment.
Based on the IP address provided, the SCADA system could identify that a firewall is installed in the panel. The SCADA system could recognize that this is a new device and, in response, generate signatures for the device to allow communication. The SCADA system could then securely configure the firewall (using a previously configured Firewall connection with certificates exchanged) and attempt to communicate with the new power device. In one embodiment, the SCADA system is configured to not attempt communication with the power device until the firewall is successfully configured (as it realizes that communication is not possible).
According to one embodiment described herein, the SCADA system can provide security for a circuit breaker(s) that use legacy communication protocols. Generally, most circuit breakers in use today do not support message or transport-level security. As a result, these circuit breakers rely on legacy unsecured communication protocols. While replacing these circuit breakers is the best option from a security perspective, many installations make this impractical due to downtime, cost, etc. Embodiments described herein can secure control operations in these legacy systems using strategic signatures on the firewalls and enabling rules at critical times.
In one example, a circuit breaker is installed in a panel that includes an ICS firewall. The circuit breaker communicates via Modbus and may be configured to support critical commands, namely open, close and reset. The commands can be triggered by the SCADA system. In the present example, the device could be installed using the same mechanism as in the previous use case (so the SCADA can generate signatures for this circuit breaker, including open, close and reset). These signatures can be configured as rules on the firewall and could initially be set to deny (meaning that the traffic is not allowed).
The SCADA system could issue a command to open the circuit breaker. For example, the SCADA system could receive a request from a user (e.g., via a Human Machine Interface (HMI)) or a process to open a circuit breaker. The SCADA system could recognize that the circuit breaker is behind the firewall, and in response could first send a firewall configuration message through a secure communications channel to tell the firewall to allow the rule for “open”. In one embodiment, the SCADA system could further specify a number of other attributes for the rule, e.g., the open command is allowed if it comes from a specific IP address, a specific port, a specific Modbus station identifier, and/or if the open command is directed to a specific IP address, a specific destination port and/or a specific destination Modified station identifier. Of course, such an example is provided for illustrative purposes only, and more generally the security techniques described herein are applicable to and can be applied to other protocols, consistent with the functionality described herein.
The SCADA system could then send the open command, which successfully traverses the firewall and is executed on the breaker. The SCADA system could then send a firewall configuration message to deny the rule for “open”, effectively locking the circuit breaker back down. In a particular embodiment, the SCADA system could include a “count” value when providing the original rule that the firewall device is configured to decrement each time the rule is satisfied and the corresponding operation executed. Moreover, the firewall device could be configured to only consider rules having a count value above 0, and may delete (e.g., in real-time, as a periodic batch operation, etc.) rules having a count value of 0. As an example, the SCADA system could specify a count of “1” for the original rule, thereby avoiding a need to transmit a subsequent configuration message to deny the rule for “open”, as the rule can only be executed a single time due to the specified count value.
In one embodiment, the “open” rule is intentionally different from the “close” rule. This is because if the rule were “operate”, then an attacker could flood the network with “close” commands when we are attempting to send an “open” command. In the scenario presented, only the command issued by the SCADA would be passed (even if a malicious flood were occurring).
Most of the time in security-sensitive environments a fail-secure methodology is required. In the case of a circuit breaker, such devices are generally required to fail-safe, meaning that the firewall should be configured to allow “open” in the event of communication loss, etc. For this reason, the SCADA system could poll the firewall to ensure that it is in operation and alert users if failures are detected. In one embodiment, a “rule” as referred to herein may contain not only the signature data discussed, but it also includes the traditional firewall rule data (e.g., IP address of sender and recipient, TCP/UDP port addresses, etc.).
As such, according to one embodiment described herein, the SCADA/HMI system 105 can add, through a secure communications channel, an entry to a firewall structure maintained on a firewall device 115. For example, the SCADA/HMI system 105 can transmit the entry to the firewall management component 125 on the firewall device 115 over a secure communications channel (e.g., by encrypting the message in such a way that the firewall management component 125 can, upon receiving the encrypted message, can decrypt it to access the message's contents). The entry can specify (i) a register operation for an endpoint device, (ii) a value for the register operation, and (iii) a count of times that the register operation can be performed. In the depicted example, the firewall device 115 in the system 130 is configured with a rule stating that source device A (the SCADA/HMI system 105) is allowed to perform write operations to register 1101 of endpoint device D (endpoint device 120(N)), and more specifically the source device A is only permitted to write the value 0x01 to the register a single time (as indicated by the count value of 1).
The SCADA/HMI system 105 can then transmit the register operation to the firewall device over an unsecured communications channel and in an unencrypted format to be forwarded to the endpoint device. The firewall management component 125 can be configured to forward the register operation to the endpoint device only if the count specified in the firewall structure would not be exceeded, and to decrement the count and/or remove the configuration table entry upon successfully forwarding the register operation to the endpoint device. As such, embodiments may securely send the register operation to the appropriate endpoint device using unsecured communications, and yet the system 130 is protected against attack from the attacker system 110. That is, even if the attacker system 110 were to successfully spoof the identity of the SCADA/HMI system 105, the attacker system 110 would only be able to submit the desired register operation having a value of 0x01 to the desired register 1101 a single time. In other words, the only “attack” that would be permitted in the depicted system 130 would be the desired result, i.e., the completion of the requested operation a single time.
The firewall management component 125 receives, over a secure communications channel, an entry to the firewall data structure, the entry specifying (i) a register operation for an endpoint device, (ii) a value for the register operation, and (iii) a count of times that the register operation can be performed (block 315). For example, the firewall management component 125 can be preconfigured with a private key and the entry could be encrypted by system transmitting the entry (e.g., a SCADA/HMI system) using a corresponding public key. The firewall management component 125 could then decrypt the received entry using the private key in order to access the entry's contents.
The firewall management component 125 updates the firewall data structure to add the received entry to the firewall data structure (block 320). The firewall management component 125 subsequently receives a first register operation for the endpoint device over an unsecured communications channel (block 325). The firewall management component 125 determines that the added entry within the firewall data structure corresponds to the received first register operation (block 330). For example, the firewall management component 125 could query the firewall data structure to determine if the firewall data structure contains an entry corresponding to a particular register operation having a particular value and for a particular endpoint device.
In one embodiment, if the firewall management component 125 determines that the firewall data structure does not contain an entry corresponding to the first register operation (e.g., based on the endpoint device identifier, register operation and value specified in the first register operation), the firewall management component 125 could discard the first register operation without forwarding the first register operation to the endpoint device. Similarly, if the firewall management component 125 accesses the firewall data structure and determines that the entry corresponding to the first register operation has a count less than or equal to 0, the firewall management component 125 could discard the first register operation without forwarding the first register operation to the endpoint device. Doing so enables the firewall device to ensure that register operations are only transmitted a specified number of times to preconfigured endpoint devices and with preconfigured values, thereby preventing flooding and other forms of attack against the endpoint devices.
In the depicted embodiment, the firewall management component 125 decrements the count of times that the register operation can be performed within the firewall data structure (block 335) and forwards the received first register operation to the endpoint device for execution (block 340), and the method 300 ends.
The firewall management system 105 includes one or more computer processors 532, a non-transitory computer-readable memory 535, and a network interface controller 549. The memory 535 contains a firewall management component 125 and an operating system 548. Generally, the firewall management component 125 represents software logic that can generate and manage a firewall data structure for use in managing register operations that can be transmitted to the endpoint device 120. As described herein, a software module refers to any software component, including (without limitation) device firmware, a software application, a module for a software application, a suite of software applications, and so on. Generally, the operating system 548 represents any suitable operating system for a computing device.
The endpoint device 120 includes one or more computer processors 592, a non-transitory computer-readable memory 593, and a network interface controller 597. The memory 593 contains a software module 594. Generally, the software module 594 contains device-specific control logic for managing the operation of the endpoint device 120. For example, in an embodiment where the endpoint device 120 represents a circuit breaker, the software module 594 could be configured to process register operations for opening and closing the circuit breaker, retrieving status information corresponding to the circuit breaker and/or one or more sensors connected to the circuit breaker, etc. As described herein, a software module refers to any software component, including (without limitation) device firmware, a software application, a module for a software application, a suite of software applications, and so on.
Many products today in critical infrastructure do not support secure protocols and yet for reasons discussed above, these products will continue to operate for years to come. Embodiments described herein present a solution to securely integrating with these products and provide an effective layered firewall approach.
In the preceding, reference is made to various embodiments. However, the scope of the present disclosure is not limited to the specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, although embodiments may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the preceding aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s).
A more detailed description of the disclosure may be had by reference to various embodiments, some of which are illustrated in the appended drawings. While the appended drawings illustrate select embodiments of this disclosure, these drawings are not to be considered limiting of its scope, for the disclosure may admit to other equally effective embodiments.
Identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. However, elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation.
The various embodiments disclosed herein may be implemented as a system, method or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied thereon.
Any combination of one or more computer-readable medium(s) may be utilized. The computer-readable medium may be a non-transitory computer-readable medium. A non-transitory computer-readable medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the non-transitory computer-readable medium can include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. Program code embodied on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages. Moreover, such computer program code can execute using a single computer system or by multiple computer systems communicating with one another (e.g., using a local area network (LAN), wide area network (WAN), the Internet, etc.). While various features in the preceding are described with reference to flowchart illustrations and/or block diagrams, a person of ordinary skill in the art will understand that each block of the flowchart illustrations and/or block diagrams, as well as combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer logic (e.g., computer program instructions, hardware logic, a combination of the two, etc.). Generally, computer program instructions may be provided to a processor(s) of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus. Moreover, the execution of such computer program instructions using the processor(s) produces a machine that can carry out a function(s) or act(s) specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality and/or operation of possible implementations of various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other implementation examples are apparent upon reading and understanding the above description. Although the disclosure describes specific examples, it is recognized that the systems and methods of the disclosure are not limited to the examples described herein but may be practiced with modifications within the scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense. The scope of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled
This application claims priority to and the benefit of U.S. Provisional Application No. 63/157,304, filed Mar. 5, 2021, the entire contents of which are herein incorporated by reference in their entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2022/018843 | 3/4/2022 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63157304 | Mar 2021 | US |
