Modbus is an application layer messaging protocol, meaning that it operates at layer 7 of the OSI model. It allows for efficient communications between interconnected assets based on a request/reply methodology. It can be used by extremely simple devices such as sensors or motors to communicate with a more complex computer, which can read measurements and perform analysis and control. To support a communications protocol on a simple device requires that the message generation, transmission, and receipt all require very little processing overhead. This same quality also makes Modbus suitable for use by PLCs and RTUs to communicate supervisory data to a SCADA system.

Because Modbus is a layer 7 protocol, it can operate independently of underlying network protocols, and it has allowed Modbus to be easily adapted to both serial and routable network architectures.

Modbus is a request/response protocol using only three distinct Protocol Data Units (PDUs): Modbus Request, Modbus Response, and Modbus Exception Response, as illustrated in Figure 4.1. ¹

Each device communicating via Modbus must be assigned a unique address. A command is addressed to a specific Modbus address, and while other devices may receive the message, only the addressed device will respond.

A session begins with the transmission of an initial Function Code and a Data Request within a Request PDU. The receiving device responds in one of two ways. If there are no errors, it will respond with a Function Code and Data Response within a Response PDU. If there are errors, the device will respond with an Exception Function Code and Exception Code within a Modbus Exception Response.

Function Codes and Data Requests can be used to perform a wide range of commands. Some examples of Modbus commands include the following:

The popularity of Modbus has led to the development of several variations to suit particular needs. These include Modbus RTU and Modbus ASCII, which support binary and ASCII transmissions over serial buses, respectively. Modbus TCP is a variant of Modbus developed to operate on modern networks using the IP. Modbus Plus is a variant designed to extend the reach of Modbus via interconnected busses. ²

Modbus is typically deployed between PLCs and HMIs, or between a Master PLC and slave devices such as PLCs, HMIs, Drivers, Sensors, I/O devices, etc., as shown in Figure 4.5. Typically up to 247 devices are supported in a single, non-bridged bus.

A common deployment uses Modbus on TCP/IP within a SCADA DMZ or Supervisory LAN, where master HMIs provide a central management capability to a number of Master PLCs, each of which may connect serially over a bus topology to a number of PLCs and/or HMIs, responsible for a distinct control loop.

Modbus represents several security concerns:

Modbus, like many industrial control protocols, should only be used to communicate between sets of known devices, using expected function codes, and as such it is easily monitored by establishing clear enclaves and by baselining acceptable behavior. For more information about creating whitelists, this topic is discussed in detail in Chapter 8, “Exception, Anomaly, and Threat Detection.”

Some specific examples of Modbus messages that should be of concern include the following:

A SCADA Intrusion Detection System (SCADA-IDS) or SCADA Intrusion Prevention System (SCADA-IPS) can be easily configured to monitor for these activities using Modbus signatures such as those developed and distributed by Digital Bond. In more critical areas, an application-aware firewall, industrial protocol filter, or Application Data Monitor may be required to validate Modbus sessions and ensure that Modbus has not been “hijacked” and used for covert communication, command, and control (i.e., the underlying TCP/IP session on port 502 has not been altered to hide additional communications channels within otherwise normal-looking Modbus traffic). This is discussed in detail in Chapter 7, “Establishing Secure Enclaves.”

ICCP is used to perform a number of communication functions between control centers, including the following:

The ICCP protocol defines communication between two control centers using a client/server model. One control center (the server) contains application data and defined functions. Another control center (the client) issues requests to read from the server, and the server responds. Communications over ICCP occur using a common format in order to ensure interoperability.

ICCP support is typically either integrated directly into a control system, provided via a gateway product, or provided as software running on Windows or Unix that can then be installed to perform gateway functions.

Although ICCP is primarily a unidirectional client/server protocol, most modern implementations support both functions, allowing a single ICCP device to function as both a client and a server, and thus supporting bidirectional communication (of a sort) over a single connection.

Although ICCP can operate over essentially any network protocol, including TCP/IP, it is commonly implemented using ISO transport on top of TCP port 102, as defined in RFC 1006. ICCP is effectively a point-to-point protocol due to the use of a “bilateral table” that explicitly defines an agreement between two control centers connected with an ICCP link, as shown in Figure 4.6. The bilateral table is essentially an access control list that identifies which data elements a client can access. The permissions defined within the bilateral tables in the server and the client are the authoritative control over what is accessible to each control center. In addition, the entries in the bilateral tables must match on both the client and the server, ensuring that the permissions are agreed upon by both centers (remembering that ICCP is used to interconnect to other organizations in addition to internal WAN links to substations). ⁴

ICCP is widely used between control system enclaves and between distinct control centers, as shown in Figure 4.7, for example, between two electric utilities, between two control systems within a single electric utility, between a main control center and a number of substations, etc.

Like Modbus, ICCP represents several security concerns. ICCP is susceptible to spoofing, session hijacking, and any number of attacks made possible because of:

The limited security mechanisms within ICCP are configured on the ICCP Master station, meaning that the successful breach of the Master through a Man-in-the-Middle (MITM) or other attack opens the entire communication session up to manipulation.

ICCP offers several improvements over more basic fieldbus protocols such as Modbus, including the following:

Secure ICCP variants should be used wherever possible. There are several known vulnerabilities with ICCP that are reported by ICS-CERT. Because there are known exploits in the wild and ICCP is a WAN protocol, proper penetration testing and patching of ICCP servers and clients is recommended.

Extreme care should be taken in the definition of the bilateral table. The bilateral table is the primary enforcement of policy and permissions between control centers and malicious commands issued via ICCP could directly alter or otherwise impact control center operations.

In addition, ICCP clients and servers should be isolated into a unique enclave consisting only of authorized client/server pairs (multiple enclaves can be defined for devices communicating to multiple clients), and the enclave(s) should be thoroughly secured using standard defense-in-depth practices, including a firewall and/or IDS system that enforces strict control over the type, source, and destination of traffic over the ICCP link.

Many malicious behaviors can be detected through monitoring the ICCP link, including the following:

Monitoring of ICCP protocol functions can also detect suspicious or malicious behavior, such as

A SCADA-IDS or SCADA-IPS can be easily configured to monitor for these activities. Digital Bond, a security research team funded by the Department of Energy, has Snort compatible IDS signatures and preprocessors to detect a variety of ICCP-related security events. Again, in more critical areas, an application-aware firewall, industrial protocol filter, or Application Data Monitor may be required to validate ICCP sessions and ensure that ICCP or the underlying RFC-1006 connection have not been “hijacked” and that messages have not been manipulated or falsified.

Like the other ICS protocols that have been discussed, DNP3 is primarily used to send and receive messages between control system devices—only in the case of DNP3, it also does it with a high degree of reliability. Assuming that the various CRCs are all valid, the data payload is then processed. Again, the payload is very flexible and can be used to simply transfer informational readings, or it can be used to send control functions, or even direct binary or analog data for direct interaction with devices such as Remote Terminal Units (RTUs), as well as other analog devices such as IEDs.

As mentioned previously, both the link-layer frame (or LPDU) header and the data payload contain CRCs, and the data payload actually contains a pair of CRC octets for every 16 data octets. This provides an exceptional degree of assurance that any communication errors will be detected. If any errors are detected, DNP3 will retransmit the errored frames. In addition to frame integrity, there are also physical layer integrity issues, and it remains possible that a correctly formed and transmitted frame will not arrive at its destination. To overcome this risk, DNP3 uses an additional link layer confirmation. When link layer confirmation is enabled, the DNP3 transmitter (source) of the frame requests that the receiver (destination) confirms the successful receipt of the frame. If a requested confirmation is not received, the link layer will retransmit the frame. This confirmation is optional because although it increases reliability, it adds overhead that directly impacts the efficiency of the protocol. In real-time environments, this added overhead may not be appropriate. ⁵

Once a successful and (if requested) confirmed frame arrives, the frame is processed. Each frame consists of a multipart header and a data payload. The header is significant as it contains a well-defined function code, which can tell the recipient whether it should confirm, read, write, select a specific point, operate a point (initiate a change to a point), directly operate a point (both selecting and changing a point in one command), or directly operate a point without acknowledgment. ⁶

These functions are especially powerful when considering that the data payload of the DNP3 frame supports analog data, binary data, files, counters, and other types of data objects. At a high level, DNP3 supports two kinds of data, referred to as class 0 or static data (data that represents a static value or point reading) and event data (data that represents a change, some sort of activity, or an alarm condition). Event data is rated by priority from class 1 (highest) to class 3 (lowest). The differentiation of static and event data, as well as the classification of event data allows DNP3 to operate more efficiently by allowing higher-priority information to be polled more frequently, for example, or to enable or disable unsolicited responses by data type. The data itself can be binary, analog input or output, or a specific control output. ⁷

DNP3 provides a method to identify the remote device’s parameters and then use message buffers corresponding to event data classes 1 through 3 in order to identify incoming messages and compare them to known point data. In this way, the master device is only required to retrieve new information resulting from a point change or change event.

Initial communications are typically a class 0 request from the Master to an Outstation, used to read all point values into the Master database. Subsequent communications will typically either be direct poll requests for a specific data class from the Master; unsolicited responses for a specific data class from an outstation; control or configuration requests from the Master to an RTU, and subsequent periodic class 0 polls. When a change occurs on an outstation, a flag is set to the appropriate data class. The Master station is then able to poll only those outstations where there is new information to be reported.

This is a huge departure from constant data polling that can result in improved responsiveness and much more efficient data exchange. The departure from a real-time polling mechanism does require time synchronization, however, because the time between a change event and a successful poll/request sequence is variable. Therefore, all responses are time-stamped, so that the events between polls can be reconstructed in the correct order.

Communication is initiated by the Master to the Slave, or in the case of unsolicited responses (alarms) from the slave to the master, as shown in Figure 4.8. Because DNP3 operates bidirectionally and supports unsolicited responses, as shown in Figure 4.9, each frame requires both a source address and a destination address so that the recipient device knows which messages to process, and so that it knows which device to return responses to. Although the addition of a source address (remember that in the other purely Master/Slave protocols, there is no need for a source address as the originating device is always the master) does add some overhead, it does so for the sake of dramatically increased scalability and functionality; as many as 65,520 individual addresses are available within DNP3, and any one of them can initiate communications. An address equals one device (every DNP3 device requires a unique address), although there are reserved DNP3 addresses, including one for broadcast messages (which will be received and processed by all connected DNP3 devices). ⁸

Secure DNP3 is a DNP3 variant that adds authentication to the response/request process, as shown in Figure 4.10. Authentication is issued as a challenge by the receiving device. A challenge condition occurs upon session initiation (when a master station initiates a DNP3 session with an outstation), after a preset period of time (the default is 20 minutes), or upon a critical request (it is possible to know which requests are critical because the data types and functions of DNP3 are well defined) such as writes, selects, operates, direct operates, starts, stops and restarts, etc. ⁹

Authentication occurs using a unique session key, which is hashed together with message data from the sender and from the challenger. The result is an authentication method that at once verifies authority (checksum against the secret key), integrity (checksum against the sending payload), and pairing (checksum against the challenge message). In this way, it is very difficult to perform data manipulation or code injection, or to spoof or otherwise hijack the protocol. ¹⁰

The DNP3 layer 2 frame provides the source, destination, control, and payload, and can operate over a variety of application layers including TCP/IP (typically using TCP port 20000 or UDP port 20000). The function codes are resident within the CNTRL bytes in the DNP3 frame header, as shown in Figure 4.11.

As shown in Figure 4.12, DNP3 is primarily used between a master control station and an RTU in a remote station, over almost any medium including wireless, radio, and dial-up. However, DNP3 is also widely used between RTUs and IEDs. As such it competes directly with the Modbus protocols within several areas of the control system.

Unlike Modbus, however, DNP3 is well suited for hierarchical and aggregated point-to-multipoint topologies in addition to the linear point-to-point and serial point-to-multipoint topologies that are supported by Modbus. ¹¹

While much attention is given to the integrity of the data frame, there is no authentication or encryption inherent within DNP3 (although there is within Secure DNP3). Because of the well-defined nature of DNP3 function codes and data types, it then becomes relatively easy to manipulate a DNP3 session.

Also, while DNP3 does include security measures, the added complexity of the protocol increases the chances of vulnerability. As of this writing, there are several known vulnerabilities with DNP3 that are reported by ICS-CERT. Because there are known exploits in the wild and DNP3 is a heavily deployed protocol, proper penetration testing and patching of DNP3 interconnections is recommended.

Some examples of realistic hacks against DNP3 include the use of MITM attacks to capture addresses, which can then be used to manipulate the system. Examples include the following:

Because a secure implementation of DNP3 exists, the primary recommendation is to implement only Secure DNP3. However, it may not always be possible due to varying vendor support and other factors. In these cases, secure use of the transport layer protocol is advised, such as the use of Transport Layer Security (TLS). In other words, treat your encapsulated DNP3 traffic as highly sensitive information and use every TCP/IP security best practice to protect it.

As always, DNP3 masters and outstations should be isolated into a unique enclave consisting only of authorized devices (multiple enclaves can be defined for devices communicating to multiple clients, or for hierarchical Master/Slave pairs), and the enclave(s) should be thoroughly secured using standard defense-in-depth practices, including a firewall and/or IDS system that enforces strict control over the type, source, and destination of traffic over the DNP3 link.

Many threats can be detected through monitoring the DNP3 session, and looking for specific function codes and behaviors, including the following:

As with other industrial protocols, SCADA-IDS or SCADA-IPS can be easily configured to monitor for these activities, while an application-aware firewall or Application Data Monitor may be required to validate DNP3 sessions.

OPC differs from the other fieldbus protocols discussed in this chapter in that its primary function is to interconnect other distributed control systems with Windows hosts, typically connected via an Ethernet TCP/IP network. OPC is an implementation of OLE for Process Control Systems. Originally OPC was Distributed Component Object Model (DCOM) based, and many OPC systems in use today use DCOM, although OPC has more recently been updated to use an object-oriented protocol called OPC-Unified Architecture (OPC-UA). ¹³

OPC provides a common communications interface between diverse industrial control systems and products by leveraging Microsoft’s DCOM communications API, reducing the need for device-specific drivers. In place of specific communications drivers for each device, simple device drivers could be written to interface with OPC. The use of OPC therefore minimized driver development and allowed for better optimization of core OPC interfaces. ¹⁴

OPC’s strengths and weaknesses come from its foundation, which is based upon Microsoft’s OLE protocol. OLE is used extensively in Office document generation and is used to embed a common data set in both a Word file and an Excel spreadsheet, for example. This not only allows OPC-connected devices to communicate and interact with minimal operator feedback (as in the case of the Office documents) but also presents significant security challenges. ¹⁵

OPC works in a client/server manner, where a client application calls a local process, but instead of executing the process using local code, the process is executed on a remote server. The remote process is linked to the client application and is responsible for providing the necessary parameters and functions to the server, over an RPC.

In other words, the stub process is linked to the client, but when a function is performed, the process is performed remotely, on the server. The server RPC functions then transmit the requested data back to the client computer. Finally, the client process receives the data over the network, provides it to the requesting application, and closes the session, as shown in Figure 4.13.

In Windows systems, the requesting application typically loads RPC libraries at run-time, using a Windows dynamic link library (DLL). ¹⁶

OPC is more complex than previous client/server industrial network protocols because of this interaction with the calling application and the underlying DCOM architecture. It interacts with various aspects of the host operating system, tying it closely to other host processes and exposing the protocol to a very broad attack surface. OPC also inherently supports remote operations (ROPs) that allow OPC to perform common control system functions. ¹⁷

The OPC-UA and the OPC Express Interface (XI) are newer variations of OPC that break away from OPC Classic’s dependence upon OLE. OPC-UA and OPC-XI preserve the functionality of earlier OPC implementations, while introducing new capabilities including stronger authentication services, encryption, and new transport mechanisms, including SOAP over HTTPS, and binary encoding to improve performance over XML, which has relatively high overhead. ¹⁸

OPC-UA and OPC-XI represent strong improvements over legacy OPC implementations in terms of security. However, legacy OPC systems remain heavily deployed.

OPC is primarily a SCADA protocol, and it is used within many areas of industrial networks, including data transfer to data historians, data collection within HMIs, and other supervisory controls, as shown in Figure 4.14. OPC is a Windows interconnection, and so all communications occur either between Windows-based devices, or via OPC gateways that translate the RPC to the native fieldbus format. Unfortunately, OPC is also widely used within an industrial system’s business network, including connections to corporate intranets, and even the Internet. ¹⁹ Because of the common use of OLE, RPC, and DCOM protocols within OPC, this opens the SCADA environment to a very broad attack surface.

Typically, OPC will be used “upstream” of fieldbus protocols, acting as a gateway between these protocols and Windows-based computing networks.

OPC’s use of DCOM and RPC makes it highly vulnerable to attack, as it is subject to the same vulnerabilities as the more ubiquitously used OLE. In addition, OPC is rooted in the Windows operating system (OS) and is therefore susceptible to attack through exploitation of any vulnerability inherent to the OS. ²⁰

OPC and related control system vulnerabilities are available only to authorized members of ICS-CERT; however, many OLE and RPC vulnerabilities exist and are well known. Because of the difficulties involved in patching production systems within an industrial network (see Chapter 6, “Vulnerability and Risk Assessment”), many of these vulnerabilities are still in place, even if there is an available patch from Microsoft.

Also, because OPC is supported on Windows, many basic host security concerns apply. Many OPC hosts utilize weak authentication, and passwords are often weak when authentication is enforced. Many systems support additional Windows services that are irrelevant to SCADA systems, resulting in unnecessary processes, which often correspond to open ports. These issues open the OPC system up to a broader attack surface. Inadequate or nonexistent logging exacerbates this by providing insufficient forensic detail should a breach occur, as Windows 2000/XP auditing settings do not record DCOM connection requests by default. ²¹

In other words, unlike the simple and single-purpose protocols discussed until now, OPC must be treated as a larger system, according to modern OS and network security practices. Given OPC’s reliance on Microsoft authentication mechanisms, weak passwords are among the most critical vulnerabilities that can undermine the security of an OPC server. Inadequate logging is also a primary concern, as by default, Windows 2000/XP auditing settings do not record DCOM connection requests, SMB log-ins, or attempts to access system objects. ²²

Other security concerns of OPC include the following:

OPC-UA or OPC-XI should be used where possible.

Regardless of the OPC variation used (Classic, UA, or XI), all unnecessary ports and services should be removed or disabled from the OPC server. This includes any and all irrelevant applications, and all unused network protocols. All unused services may introduce vulnerabilities to the system that could result in a compromise of the Windows host, and therefore the OPC network. ²⁷

OPC servers should be isolated into a unique enclave consisting only of authorized devices, and the enclave(s) should be thoroughly secured using standard defense-in-depth practices, including a firewall and/or IDS/IPS system that enforces strict control over the type, source, and destination of traffic to and from the OPC enclave.

Because OPC is primarily used in a supervisory capacity, IPS can be considered in place of IDS, understanding that an IPS may block SCADA traffic and result in a lack of visibility into control system operations. If information loss will be damaging to the control process or detrimental to business operations, use only IDS.

Many threats can be detected through monitoring OPC networks and/or OPC servers (server activity can be monitored through the collection and analysis of Windows logs), and looking for specific behaviors, including the following:

Most commercially available IDS and IPS devices support a wide range of detection signatures for OLE and RPC and therefore can also detect many of the underlying vulnerabilities of OPC. Similarly, most open-source and commercial log analysis and threat detection tools are capable of collecting and assessing Windows logs.

Ethernet/IP uses standard Ethernet frames (ethertype 0x80E1) in conjunction with the Common Industrial Protocol (CIP) suite to communicate with nodes. Communication is typically client/server, although an “implicit” mode is supported to handle real-time requirements. Implicit mode uses connectionless transport—specifically the User Datagram Protocol (UDP) and multicast transmissions—to minimize latency and jitter.

The CIP uses object models to define the various qualities of a device. There are three types of objects: Required Objects, which define attributes such as device identifiers, routing identifiers, and other attributes of a device such as the manufacturer, serial number, date of manufacture, etc.; Application Objects, which define input and output profiles for devices; and Vendor-specific Objects, which enable vendors to add proprietary objects to a device. Objects (other than vendor-specific objects) are standardized by device type and function, to facilitate interoperability: if one brand of pump is exchanged for another brand, for example, the application objects will remain compatible, eliminating the need to build custom drivers. The wide adoption and standardization of CIP has resulted in an extensive library of device models, which can facilitate interoperability but can also aid in control network scanning and enumeration (see Chapter 6, “Vulnerability and Risk Assessment”).

While the Required Objects provide a common and complete set of identifying values, the Application Objects contain a common and complete suite of services for control, configuration, and data collection that includes both implicit (control) and explicit (information) messaging. ²⁸

Profibus (Process fieldbus) is a fieldbus protocol that was originally developed in the late 1980s in Germany by the Central Association for the Electrical Industry. Several specialized variants of Profibus exist, including Profibus-DP (Decentralized Periphery) and Profibus-PA (Process Automation). The standardized variant is Profibus-DP, which itself has three common variants: Profibus DP-V0, DP-V1, and DP-V2, each of which represents a minor evolution of capabilities within the protocol. There are also three profiles for Profibus communication: asynchronous, synchronous, and via Ethernet using ethertype 0x8892. Profibus over Ethernet is also called Profinet. ²⁹

Profibus is a Master/Slave protocol that supports multiple master nodes through the use of token sharing: when a master has control of the token, it can communicate with its slaves (each slave is configured to respond to a single master). In Profibus DP-V2, slaves can initiate communications to the master or to other slaves under certain conditions. Typically, a master Profibus node is a PLC or RTU, and a slave is sensor, motor, or some other control system device.

EtherCAT is another real-time Ethernet fieldbus protocol, which uses a defined Ethernet ethertype (0x88A4) to transport control systems communications over standard Ethernet networks. To maximize the efficiency of distributed process data communications (which requires only a few bytes per cycle) over Ethernet frames (which vary in size from 46 to 1500 bytes of payload), EtherCAT communicates large amounts of distributed process data with just one Ethernet frame, so that typically only one or two Ethernet frames are required for a complete cycle. Slaves pass the frame(s) to other slaves in sequence, appending its appropriate response, until the last slave returns the completed response frame back. ³⁰

Ethernet Powerlink uses Fast Ethernet as the basis for real-time transmission of industrial control messages. A master node is used to initiate and synchronize cyclic polling of slave devices, by transmitting a master “Start of Cycle” frame that provides a basis for the network synchronization. The master then polls each station; slaves can only respond if they receive a poll request frame, ensuring that all Master/Slave communications occur in sequence. Slave responses are broadcast, eliminating source address resolution. Because collisions are avoided solely via the carefully controlled request/response cycles, Ethernet Powerlink is best used homogeneously: the introduction of other Ethernet-based systems could disrupt synchronization and cause a failure. ³¹

Ethernet Powerlink is often used in conjunction with CANopen, an application layer protocol based on CAN (Controller Area Network). CANopen enables the communication between devices of different manufacturers, and the protocol stacks are widely available including open-source distribution for both Windows and Linux platforms. The open nature of CANopen makes Ethernet Powerlink/CANopen a desirable combination for industrial networks requiring inexpensive solutions in Linux environments. ³²

SERCOS (Serial Real-time Communications System) is a fieldbus specialized for digital motion control. SERCOS III is a real-time Ethernet communication protocol specifically designed for serial communications between PLCs and IEDs, operating at high speeds within closed loops. ³³

SERCOS III is a Master/Slave protocol that operates cyclically, using a mechanism in which a single Master Synchronization Telegram is used to communicate to slaves, and the slave nodes are given a predetermined time (again synchronized by the master node) during which they can place their data on the bus. All messages for all nodes are packaged into a Master Data Telegram, and each node knows which portion of the MDT it should read based upon a predetermined byte allocation. ³⁴

An interesting addition to SERCOS III is that, although SERCOS dedicates the use of the bus for synchronized real-time traffic during normal cycles, it allows unallocated time within a cycle to be freed up for other network protocols such as IP. This “IP Channel” allows the use of broader network applications from the same device—for example, a web-based management interface that would be accessible to business networks. ³⁵

The security concerns of smart grid are numerous. AMI represents an extremely large network that touches many private networks and is designed for command and control in order to support remote disconnect, demand/response billing, and other features. ³⁸ Combined with a lack of industry-accepted security standards, the smart grid represents significant risk to connected systems that are not adequately isolated. Specific security concerns include the following:

The best recommendation for smart grid security at this point is for electric utilities to carefully assess smart grid deployments and to perform risk and threat analysis early in the planning stages, and for the end users who are connected to the smart grid to perform a similar assessment of the system as a potential threat vector into the business (or home) network.

Again, clear delineation, separation of services, and the establishment of strong defense in depth at the perimeters will help to minimize any threat associated with the smart grid. For the smart grid operators, this could represent a challenge (especially in terms of security monitoring) due to the broad scale of smart grid deployments, which could contain hundreds of thousands or even millions of intelligent nodes. Therefore, it may be necessary to carve smart grid deployments into multiple, smaller and more manageable security enclaves.