EPRI SECURITY ARCHITECTURE FOR THE DISTRIBUTED ENERGY RESOURCES INTEGRATION NETWORK
RISK-BASED APPROACH FOR NETWORK DESIGN
EXECUTIVE SUMMARY
As distributed energy resources (DERs) expand rapidly as a major source of electricity generation and interconnect with the grid,
Copyright By PowCoder代写 加微信 powcoder
the ability to securely monitor and control the operations of the resources in a large geographical area becomes increasingly important to maintain safety, reliability, and resiliency of the nation’s grid. Remote monitoring and control of distributed generation require local devices and sensors to communicate operational status and receive commands from the remote systems, via public or private communication networks. In the meantime, the cyber-threats
against the nation’s grid is increasing as more and more devices become intelligent and connected. Without adequate cybersecurity protection, energy generation and interconnected systems are innately exposed to cyber threats.
This paper provides a practical set of cybersecurity requirements pertaining to the network components supporting distributed energy resources (DER) communications. The requirements specified herein aim to reduce the cybersecurity risk to the distribution grid to which various DER are connected. The requirements discussed herein do not make any assumption to the communication protocols, particular functional standards, or certain ownership/business models in terms of their effectiveness in cybersecurity. Rather, it aims to provide a holistic view of the interconnected systems, including DER, and it suggests how they can be protected from cyberattacks.
The scope of this report is limited to network security concerns. The goal is to provide guidelines for designing and implementing network infrastructure in a way that will minimize the likelihood, duration, or impact of a successful cyberattack.
It is important to note that network security architecture addresses only a portion of the cybersecurity risks associated with DER integration. To protect DER and the connected grid adequately, a more comprehensive cybersecurity standard must be developed and implemented.
The standard must consider various facets of cyber security including: • Communications and protocol security
• Cryptographic key management
• End-point security for DER devices
• Personnel, physical, and environmental security
• Ongoing security operations—vulnerability and patch
management, security monitoring, and incident response
TERMINOLOGY
In this report, DER, distributed energy resource, and resource are used interchangeably. The following terms that appear in the report might be used to convey slightly different meanings from their general usage:
• DER supporting system, supporting system, or system. A system, application, or device used to support the operation of DER or grid services in relation to DER.
• DER managing system or managing system. A supporting system specifically used to manage DER. The essential functions of a DER managing system include data acquisition and control.
• External network. A telecommunication network that extends external to the local area network (LAN)— that is, a wide area network (WAN), Internet area network (IAN or cloud), or the Internet.
• Security zone. One or more subnets or broadcast domains where a device in a zone can communicate with other devices within the zone freely, but access to and from devices outside the zone is controlled.
NETWORK SECURITY REQUIREMENTS
The general network security requirements described in this section are drawn from various cybersecurity standards available to the industry [1–6].
R1. Resource Criticality Levels
R-1.1 Each distributed energy resource or supporting system participating in DER communications must be categorized into one of three distinct criticality levels—high impact, medium impact, or low impact.
R-1.2 The criticality level of a resource must be determined
based on the impact of any misuse of that resource to grid reliability, public safety, finances, and privacy. The high- impact criticality level should be assigned to a resource determined to have high impact; medium-impact to a resource with medium impact; and low-impact to a resource with low impact.
R-1.3 If a group of resources can be operated simultaneously through the same managing system, each resource in the group must be assigned the criticality level corresponding to the aggregate risk posed by the simultaneous (mis)operation of all resources in the group.
R-1.4 A managing system that can issue a write/control command to one or more resources must be assigned the criticality level that corresponds to the aggregate risk of simultaneous (mis)operation of all resources that can be controlled by the managing system.
R-1.5 If a resource can be categorized into two or more different criticality levels, it must be categorized into the highest possible level.
R2. Network Segmentation
R-2.1 Resources with different criticality levels must be located in different security zones. A security zone with high-impact resources is a high-impact zone. A security zone with medium-impact resources is a medium-impact zone, and
a security zone with low-impact resources is a low-impact zone.
R-2.2 Each security zone must have one or more security gateways (see the glossary) with access controls.
R-2.3 Communications between two different security zones must be routed through the security gateways with access controls.
R-2.4 Communications between systems or resources in the high- impact zone and a system/resource in the low-impact zone must be routed through a demilitarized zone (DMZ; see the glossary).
R-2.5 Communications to and from an external network must be routed through a DMZ.
R3. Boundary Protection
R-3.1 Access controls in security gateways should be configured to deny a connection request from a lower security zone to a higher security zone by default.
R-3.2 Security gateways at the boundary of high-impact zones must be monitored on a 24/7 basis in order to detect security events that can negatively impact the operation of systems or resources in the security zone.
R-3.3 Security gateways interfacing with external networks must be monitored on a 24/7 basis in order to detect security events that can negatively impact the operation of resources located in the internal network.
R4. Communication Partitioning
R-4.1 DER communications to and from high-impact resources must be physically or logically partitioned from other types of communications.
R-4.2 Communications required for the administration of network infrastructure must be physically or logically partitioned from other types of communications.
R5. Network Service Protection
R-5.1 Network access control: network infrastructure supporting DER communications must allow only authorized resources or systems to join the network.
R-5.2 Administrative access control: an application, device, or tool used for the administration of network infrastructure must have one or more strong access control mechanisms in place to prevent unauthorized physical or logical access.
R-5.3 Secure name/address resolution service: systems providing name/address resolution to high-impact-level resources must have a technical mechanism to prevent forging or manipulating of DNS data.
R-5.4 Denial-of-service protection: high-impact resources must
be protected from a denial-of-service attack or distributed denial-of-service attack through both technical controls and an emergency response service agreement.
R6. Communication Integrity
R-6.1 All DER communications must be protected with a mechanism to verify the authenticity of each resource or system participating in the communication.
R-6.2 All DER communications must be protected with a mechanism to verify the integrity of messages between the resources or systems participating in the communication.
R-6.3 DER communications to and from a high-impact resource must be protected with a mechanism to detect illegitimate alteration of messages between resources connected to the network.
R-6.4 Network infrastructure supporting DER communications must support the communications integrity requirements specified in R6.1–R6.3.
R7. Communication Confidentiality
R-7.1 End-to-end protection of confidentiality means that the data payload is encrypted using a cryptographic mechanism with sufficient security strength at the data source and is not decrypted until it reaches its final destination.
R-7.2 DER communications to and from high-impact resources must be protected end-to-end using a unique cryptographic key for each end-point.
R-7.3 DER communication traversing an external network must be protected end-to-end using a unique cryptographic key for each end-point.
R-7.4 DER communication between two systems or resources with different owners must be protected end-to-end using a unique cryptographic key for each end-point.
R-7.5 Network infrastructure supporting DER communications must support the communication confidentiality requirements specified in R7.1–R7.4.
IMPLEMENTATION GUIDE
This section elaborates on the requirements in the previous section by demonstrating their use in a reference architecture that represents a DER aggregation network implementation.
Note: To focus the discussion on the security architecture and related requirements, this report uses a simplified criticality categorization based purely on the nameplate real-power rating of the DER, where less than
10 kW is considered low impact, 10 kW or more but less than 100 kW is considered medium impact, and more than 100 kW is considered high impact (see Table 1). In real-life applications, the criticality rating must be assessed based on a thorough impact analysis of the resources with multiple evaluation criteria.
Table 1 – Example criticality rating criteria (Must be developed by DER managing entity.)
RISK-BASED NETWORK DESIGN (R1–R4)
A basic DER aggregation network, illustrated in Figure 1, consists of multiple independent DERs, each with its own nameplate rating and local control system, monitored and controlled by a centralized control system. Independently, each DER might have a different criticality; however, when they can all be controlled simultaneously by the same managing system (or headend), criticality must be evaluated at the aggregate group level (R1.3), and the same criticality is then assigned to each component in the group.
Figure 1 – Nonsegmented central management
In this architecture, some DERs on their own might be low-impact (that is, 2 kW or 2.5 kW), some might be medium-impact (10 kW or 30 kW), and some might be high-impact (200 kW and 1250 kW). However, their aggregate is 1496.5 kW, and they can all be controlled by the same managing system, which places the entire network and each of its component resources squarely in the high-impact criticality categorization. By changing the network topology, the design can be adjusted to reduce the risk posed by various elements and allow the use of appropriate security controls for elements with different risk profiles, as shown in Figure 2.
Figure 2 – Segmented central management
R1. Resource Criticality Level
The first step in implementing the proposed architecture in accordance with the preceding requirements is to divide the components into zones based on risk. Resources are grouped such that all the resources in the group share the same criticality classification and the aggregate criticality of each group is the same as the criticality of the resources in it.
A level of indirection needs to be introduced into the control path in order to truly separate the groups of resources and avoid assigning the same criticality to all of them. This can be accomplished by using a separate headend for each group, as shown in Figure 2. Each headend then has the aggregate criticality of the group it controls. All headends typically connect to a centralized control system, which is assigned the criticality of the aggregate of all groups it can control. In the sample architecture shown in Figure 2, the managing system controls three groups of DERs—low-impact, medium-impact, and high-impact.
There can be instances where a distributed energy resource can be included in multiple groups if it can be controlled by different headends. In that case, the distributed energy resource should be assigned the criticality of the highest rated group in which it is included. Note that this will raise the criticality of any other group in which the resource is included, so this situation should be avoided if possible.
Criticality Rating
Real-Power Nameplate Rating
Low-impact
Medium-impact
High-impact
R2. Network Segmentation
R-2.1 Resources with different criticality levels must be located in different security zones. A security zone with high-impact resources is called a high-impact zone. A security zone with medium-impact resources is a medium-impact zone, and a zone with low-impact resources is a low-impact zone.
Once resources have been divided into groups of various criticality levels, they need to be located in separate security zones so that each zone contains only systems of the same criticality. This allows the same security controls to be applied uniformly to all systems in the zone and creates logical interfaces between zones where network traffic can be inspected and controlled.
A zone is typically defined as one or more subnets or broadcast domains where a device in the zone can communicate with other devices
within the zone freely, but access to/from devices outside the zone is controlled. When defining a zone, it is necessary to identify each device that should be part of the zone (that is, each device that is part of the same criticality group), identify each communications network to which it is connected, and then identify all other devices on that same network—for example, all devices connected to the same subnet or virtual local area network (VLAN) on an Ethernet switch or all devices connected to the same service set identifier (SSID) or wireless local access network (WLAN) on an 802.11 wireless access point.
Note that in some cases, a particular subnet, VLAN, or so on might
be connected to other networks without any type of access control between them. For example, a layer 3 switch may freely route traffic between different VLANs/subnets defined on it if it has an Internet protocol (IP) addresses on each defined VLAN/subnet. In some cases, this might be allowed if all the VLANs/subnets are supposed to be within that zone. In some cases, some of the VLANs/subnets belong
to a different zone, and access control will need to be imposed in some manner. Note that in the latter example, the underlying network device (such as a switch or wireless access point) could contain multiple zones of different criticality and must be assigned the criticality of the most critical zone on the device; this has implications for the location of the management interface, as covered in the following.
There are typically multiple options for how the segmentation is done— through separate hardware, VLANs, virtual routing and forwarding (VRF), virtual switches in a hypervisor, and so on. The tradeoff is typically between cost, flexibility, and probability of compromise—that is, a virtual switch in a hypervisor provides a low-cost, flexible solution, arguably with a higher probability of compromise due to the complexity and larger attack surface of the hypervisor; separate physical switches are a relatively expensive, inflexible solution (each new zone requires
a new switch), but with a minimal probability of compromise due to the physical separation. There is no right or wrong approach, but the implementer must weigh the pros and cons of each solution for their particular design and risk level.
As shown in the architecture illustrated in Figure 3, the central management systems will typically consist of multiple zones containing headends of various criticality levels and a zone containing the core managing system, which will have the highest criticality of all the zones. Field device networks might be simple and contain only a single zone (such as a 1-kW residential solar installation with a single smart inverter), or they might be a replica of the central managing system with multiple zones of different criticalities, as shown in Figure 4. An example is a university campus with a variety of DER, battery storage, demand response capability, and a campuswide control network.
R-2.6 Each security zone must have one or more security gateways with access controls.
R-2.7 Communications between two different security zones must be routed through the security gateways with access controls.
New systems should be designed with this type of zoning built in— that is, each zone should contain only devices with the same level
of criticality. Existing systems might require some redesign—some devices might need to be moved to different zones. Note that systems or devices that are not part of the DER control ecosystem but that may communicate with the managing system for the purposes of supplying it with data or collecting data from the managing system should be located in separate zones (that is, not in the distributed energy resource management [DERMS] zone) because they also have a different level of criticality.
In practice, this means that each device in the zone can be connected only to the network(s) in the zone. A device cannot be multihomed such that one connection on the device is inside one zone and another is in another zone, unless that device is acting as a security gateway— that is, unless it has some mechanism for controlling what traffic is allowed to move between zones.
When a zone is mapped or designed (all the networks and devices in the zone are identified), all connections to other zones must also be identified, and an appropriate security gateway must be installed at each such connection point. In some cases, some connection points might be eliminated or consolidated to reduce the number of gateways that need to be installed. The gateway(s) should then be sized to handle the expected amount of traffic without creating a large delay or congestion.
A security gateway is typically implemented as a firewall; however, it could also take the form of a router, layer 3 switch, cellular modem, radio, and so on—essentially, any device with the ability to control incoming and outgoing traffic based on some predefined ruleset.
In some cases, this could also be a virtual firewall integrated into a virtualized environment.
In the reference architecture depicted in Figure 4, firewall 1 controls access between the managing system in the high-impact zone and headend in the medium-impact zone and another high- impact zone. Firewall 2 controls access between the DMZs and the communications network to the DERs. Note that the actual
Figure 3 – R2, Network Segmentation
implementation of the two firewalls could vary significantly (such as two physical firewalls, a single firewall with multiple connections, virtual firewalls inside a physical firewall, or virtual firewalls inside a virtualization cluster) without impacting the end result—that
all traffic between zones must go through a security gateway that determines whether the traffic is allowed based on some predefined ruleset.
R-2.8 Communications between a system/resource in the high-impact zone and a system/resources in the low-impact zone must be routed through a DMZ.
R-2.9 Communications to/from an external network must be routed through a DMZ.
Where devices with a high-impact rating need to communicate with devices with a low-impact rating (for example, the managing system
in Figure 3 communicating with low-impact residential DER) or communications need to traverse an external communications network (for example, the Internet in Figure 3), a level of indirection and additional filtering needs to b
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com