10.1.1 Technical Requirements

The smart grid communication infrastructure represents a technical challenge that is far beyond the simple addition of an information technology infrastructure on top of an electrical network. The number of widely distributed nodes that are tightly coupled and operating in the electrical network has grown over many years. It is very challenging to figure out where intelligence needs to be added. Another challenge comes from the continuous operation of the current power grid. The smart grid implementation will be a continuous evolution of successive projects over many years. Incorporating a huge number of legacy systems will pose a constant challenge to the evolution of the smart grid. Besides, different stakeholders are responsible for different parts of the system. Independently, each may make different choices about the evolution and use of the grid.

The functional requirements of major applications in the smart grid are listed in Table 10.1. It is clear that the requirements vary from one application to another. There is no single solution to all the challenges in smart grid applications. For example, the AMI and the monitoring infrastructure have completely different requirements, from security to backup power. The diversity of requirements further increases the complexity of the technical challenges in the smart grid.

10.1.2 Information Security Domains

Security in smart grid communications infrastructure can be divided into different information domains as follows.

• Public supplier and maintainer domain
• Power plant domain
• Substation domain
• Telecommunication domain
• Real‐time operation domain
• Corporate IT domain

Interdependencies among different information security domains present challenges when evaluating the impacts of a cybersecurity incident.

10.1.3 Standards and Interoperability

Utility providers are different even within the same country. The major challenge is to integrate interchangeable parts and technologies from a variety of providers worldwide. There is a need for interoperability standards to address this issue. Standards are also required to test the relatively new technologies that are applied to the smart grid communications infrastructure. One major challenge is the continuous operation of the power grid. The upgrading process to the smart grid will need to occur without interrupting critical grid operations.

10.2.1 Key Concepts and Assumptions

The logical security architecture specifies the following key concepts and assumptions:

• Defense‐in‐depth strategy. Smart grid cybersecurity should be applied in layers, with one or more security measures implemented at each layer. The objective is to mitigate the risk of one component of the defense being compromised or circumvented.
• Defense‐in‐breath strategy. Security activities are planned across the system, network, or subcomponent life cycle: product design and development, manufacturing, packaging, assembly, system integration, distribution, operations, maintenance, and retirement. The goal is to identify, manage, and reduce the risks of exploitable vulnerabilities across all parts of the life cycle.
• Power system availability. The primary focus of power systems engineering and operations is supporting the safe and reliable delivery of electricity. Existing power system designs and capabilities have been successful in providing this availability by protecting against inadvertent actions and natural disasters. These existing power system capabilities may be used to address the cybersecurity requirements.
• Microgrids. An implied hierarchy in availability and resilience eliminates potential peer‐to‐peer negotiations between microgrids. Microgrid models suggest that availability starts in a local microgrid and that resilience is gained by aggregating and interconnecting those microgrids. These interactions are not just theoretical. Microgrids are intended to operate either as islands or interconnected entities; islands are key where critical operations need to be maintained.
• Wide‐area situation awareness (WASA). WASA is often shared between business entities; such information should be specified and secured in accordance with the principles of service‐oriented architecture (SOA) security. Examples of such interactions might include the exchange of WASA between a provider and aftermarket consumers (co‐op or aggregator), between a utility and emergency management, or between adjacent bulk providers.

A logical security architecture needs to provide protection for data at all interfaces within and among all smart grid domains. The logical security architecture baseline assumptions are as follows:

• A logical security architecture promotes an iterative process for revising the architecture to address new threats, vulnerabilities, and technologies.
• All smart grid systems will be targets.
• There is a need to balance the impact of a security breach and the resources required to implement mitigating security measures. (Note: The assessment of the cost of implementing security is outside the scope of this chapter. However, this is a critical task for organizations as they develop their cybersecurity strategy, perform a risk assessment, select security requirements, and assess the effectiveness of those security requirements.)
• The logical security architecture should be viewed as a business enabler for the smart grid to achieve its operational mission (e.g. avoid rendering mission‐purposed feature sets inoperative).
• The logical security architecture is not a one‐size‐fits‐all prescription, but rather a framework of functionality that offers multiple implementation choices for diverse application security requirements within all electric sector organizations.
• As is common practice, the existing legacy systems will need to be considered as the new architecture is designed. Security implications will need to be reviewed and updated, both to consider the legacy security mechanisms and the current state of security practice.

10.2.2 Logical Interface Categories

A total of 22 logical interface categories are listed in the NIST guidelines for developing a cybersecurity strategy and implementing a risk assessment to select security requirements. This information may also be used by vendors and integrators as they design, develop, implement, and maintain security requirements. The logical interface categories are as follows:

1. Interface between control systems and equipment with high availability, and with compute and/or bandwidth constraints.
2. Interface between control systems and equipment without high availability, but with compute and/or bandwidth constraints.
3. Interface between control systems and equipment with high availability, without compute or bandwidth constraints.
4. Interface between control systems and equipment without high availability and without compute or bandwidth constraints.
5. Interface between control systems within the same organization.
6. Interface between control systems in different organizations.
7. Interface between back‐office systems under common management authority.
8. Interface between back‐office systems not under common management authority.
9. Interface with B2B connections between systems usually involving financial or market transactions.
10. Interface between control systems and noncontrol/corporate systems.
11. Interface between sensors and sensor networks for measuring environmental parameters, usually simple sensor devices. possibly with analog measurements.
12. Interface between sensor networks and control systems.
13. Interface between systems that use the AMI network.
14. Interface between systems that use the AMI network with high availability.
15. Interface between systems that use customer (residential, commercial, and industrial) site networks.
16. Interface between external systems and the customer site.
17. Interface between systems and mobile field crew laptops/equipment.
18. Interface between metering equipment.
19. Interface between operations decision support systems.
20. Interface between engineering/maintenance systems and control equipment.
21. Interface between control systems and their vendors for standard maintenance and service.
22. Interface between security/network/system management consoles and all networks and systems.

10.3.1 Utility‐Owned Private Networks

Data in smart grid communications is generated by many different intelligent devices together with direct input from human administrators for different purposes. The data transmitted over private networks can be categorized into four types, namely, metering data, monitoring data, control messages, and pricing/tariff information. Strictly speaking, metering data is a kind of monitoring data, and pricing/tariff is part of control messages. However, metering data and pricing/tariff mostly contribute to demand response, while other monitoring data and control messages are mostly applied to other grid operations. The security requirements of those four types of data in private networks are summarized in Table 10.2.

	Confidentiality	Integrity	Non‐repudiation
Metering data
Pricing/tariff information
Monitoring data
Control message

Metering data is gathered from customers, in particular the power consumption of each household. Metering data contains much private information. For example, from the pattern of energy consumption, it is possible to sketch the lifestyle of a customer. Therefore, it is vital to provide confidentiality to metering data. In addition, integrity is also important to metering data. Manipulation of energy consumption (e.g. energy theft) may cause loss to the service provider. More importantly, manipulation of energy consumption data may cause the service provider to deviate from optimal control of the power grid, which in turn will lead to unnecessary fuel waste and pollution. However, non‐repudiation may not be as critical as the other two security requirements for two reasons. 1) Providing non‐repudiation, which usually is achieved by digital signature, may compromise the identity of the customer and thus jeopardize privacy. 2) Data in the uplink is frequently transmitted by simple devices such as smart meters or DAPs. They have limited computational capability, so applying public key cryptography frequently is not practical.

Pricing/tariff information is generated and transmitted from the service provider to customers in several ways. The most efficient way is through the private networks in AMI so that smart meters can receive real‐time updates and adjust the power consumption of each smart appliance accordingly. For such transmissions, confidentiality can be dropped since pricing/tariff information is meant for all (or the majority) of the customers. Nonetheless, integrity and non‐repudiation are critical requirements. Pricing/tariff information must remain fresh and correct all the time so that demand response can be applied accordingly. Customers (i.e. smart meters in this case) must be able to verify the legitimate sender (i.e. the service provider) so that forgery of such information can be detected, reported, and discarded. Besides, the availability of metering data is important but not critical, since alternative means for retrieving metering data can still be used. The types of security that could be applied are limited to the computational capabilities of a smart meter. Moreover, key management of millions of meters will pose significant challenges. Standard development is required to test the capabilities of new technologies used with smart meters.

The monitoring data of power grid status is gathered by low‐profile sensors (e.g. PMUs). Obviously, data integrity needs to be provided so that the service provider can monitor the grid correctly. However, such sensors have limited computational power and power supplies. Moreover, monitoring data has strict latency requirements (e.g. about 10 ms for PMU data in WAMS). Therefore, it is not necessary to provide confidentiality and non‐repudiation to monitoring data. However, integrity of monitoring data must be guaranteed for precise grid monitoring and optimal grid operations. Certain control messages to intelligent components (e.g. in response to hazardous situations) also require integrity. Due to low latency and limited computational power at the receiver side, confidentiality and non‐repudiation may not be provided. Nonetheless, logs and files containing forensic evidence following events should probably remain confidential for both critical infrastructure and organizational reasons.

10.3.2 Public Networks in the Smart Grid

Different types of information are constantly transmitted over the public network in smart grid communications. General security requirements are listed in Table 10.3 for each type of information.

	Confidentiality	Data Integrity	Non‐repudiation
Pricing forecast
Raw energy forecast
Preprocessed data
External information

The security‐related issues for the interface between external systems and the customer site (for example, between a third party and the HAN gateway) include confidentiality and integrity. Not all security services are required for this interface. Obviously, the pricing forecast does not need to remain confidential; nonetheless its integrity and non‐repudiation must be guaranteed. Preprocessed data is transmitted from local control centers to the cloud computing service. Big data analytics can be applied to such data to extract energy forecasts, and thus it is not meant for the public. Therefore, confidentiality, integrity, and non‐repudiation are all required for preprocessed data. The raw energy forecast is made from big data analytics by the cloud computing service. Again, it is not meant for the public and thus confidentiality is required. Integrity and non‐repudiation are also important for the raw energy forecast. External information is usually open to the public, so confidentiality is not required. Neither is non‐repudiation, since the external sources may not even cooperate on this term. However, integrity should be provided. Availability and bandwidth are not generally critical between external parities and the customer site, since most interactions are not related to power system operations in real time.

10.4.1 Component‐Based Attacks

Stuxnet was specifically programmed to attack SCADA in 2010 [173]. This malicious computer worm could reprogram programmable logic controllers, which allow the automation of electromechanical processes such as those used to control process plants and nuclear plants. The design and architecture of Stuxnet are not domain specific, and it could be tailored to become a platform for attacking modern SCADA systems of the power grid.

The PMU could suffer from three types of attacks [174]. A reconnaissance attack is defined as an attack that reconnoiters and identifies the system before an attack by a cyber‐attacker. A packet injection attack is defined as sensor measurement injection and command injection. The third type of attack is denial of service. Since the PMU is required to have precise synchronization, another attack against the PMU is a time synchronization attack [175]. An example is the TSA‐GPS spoofing attack, which is achieved by inserting a delay on satellite signals and not modifying them in the encoding process. The goal is to maximize alternations among the receiver's clock offset with and without the attack. The main functions of the PMU affected by TSA are fault detection in the transmission line and inaccurate event location.

The SCADA may suffer from internal and external attacks. Internal attacks against the SCADA may be launched by employees or contractors who have access to the system. External attacks are nonspecific malware and hackers. For example, Stuxnet could be launched as either an internal or external attack. Attacks launched by a former insider may target special knowledge of the SCADA system. Attacks launched by external hackers or terrorists may not target special knowledge. Natural or even man‐made disasters should be considered attacks on the system.

Other cyberattacks can be launched against a specific component in the smart grid. For instance, regular cyberattacks against an SCADA system may include web server or SQL attacks, email attacks, zombie recruitment, DDoS attacks, etc. Some of the vulnerability points in the smart grid system could be unused telephone lines, use of removable media, infected Bluetooth‐enabled devices, Wi‐Fi‐enabled devices that have an Ethernet connection to a SCADA system, insufficiently secure Wi‐Fi, corporate web servers, email services, Internet gateways, etc.

10.4.2 Protocol‐Based Attacks

All protocols run on top of the IP protocol, and the IP protocol has its own set of weakness. For example, DNP3 (distributed network protocol) implements TLS (transport layer security) and SSL (security sockets layer) encryption, which is weak. The protocol is vulnerable to out‐of‐order, unexpected, or incorrectly formatted packets. Besides the IP protocol, vulnerabilities may exist in smart grid relevant protocols. For example, a significant weakness for IEC 61850 (standard for design of substation automation) is that it maps to manufacturing message specification as the communications platform, which itself has a wide range of potential vulnerabilities. Protocol based attacks must be addressed according to a specific protocol. As mentioned earlier, standards and regulations are required to test any protocols that are proposed to secure smart grid communications infrastructure.

10.6.1 Commissions and Considerations

The Energy Independence and Security Act (EISA) of 2007 is a public law to move the United States toward greater energy independence and security; to increase the production of clean renewable fuels; to protect consumers; to increase the efficiency of products, buildings, and vehicles; to promote research on and deployment of greenhouse gas capture and storage options; and to improve the energy performance of the Federal Government, as well as other purposes.

In particular, EISA 2007 directs the NIST to coordinate the development of model standards for interoperability of smart grid devices and systems by 1) creating flexible, uniform, and technology neutral standards and 2) enabling traditional resources, distributed resources, renewables, storage, efficiency, and demand response to contribute to an efficient, reliable grid. Moreover, EISA 2007 directs the Federal Energy Regulatory Commission (FERC), when sufficient consensus exists, to adopt standards necessary to insure smart‐grid functionality and interoperability in the interstate transmission of electric power and regional and wholesale electricity markets. However, EISA 2007 did not expand the FERC's Federal Power Act authority to enforce standards.

Regulation may adopt standards separately or in parallel with FERC. State commission may also consider standards when approving utility investments. When adopting standards, regulators need to ensure interoperability and security, without impeding innovation. Regulators also need to consider that consistent action will influence the vendor community. Some vendors often will follow standards that are not legally mandated.

10.6.2 Selected Standards

Table 10.4 lists a few selected standards proposed for the traditional power grid and the smart grid. IEEE Stardard P2030, “Guide for Smart Grid Interoperability of Energy Technology and Information Technology Operation with the Electric Power System (EPS), and End‐Use Applications and Loads” provides a knowledge base addressing terminology, characteristics, functional performance and evaluation criteria, and the application of engineering principles to smart grid interoperability of the electric power system with end‐use applications and loads [186].

The International Electrotechnical Commission (IEC) has published over 100 standards that are relevant to the smart grid. In particular, IEC 62351, “Power systems management and associated information exchange—Data and communications security” is relevant to EMS, DMS, DA, SA, DER, AMI, DR, smart home, storage, and EVs in the smart grid. IEC 62351 has seven categories, where each one defines specifications for a certain area.

• IEC/TS 62351‐1: Communication network and system security ‐ Introduction to security issues.
• IEC/TS 62351‐2: Glossary of terms.
• IEC/TS 62351‐3: Profiles including TCP/IP.
• IEC/TS 62351‐4: Profiles including MMS.
• IEC/TS 62351‐5: Security for IEC 60870‐5 and derivatives.
• IEC/TS 62351‐6: Security for IEC 61850.
• IEC/TS 62351‐7: Network and system management (NSM) data object models.
• IEC/TS 62351‐8: Role‐based access control.

Other security standards and regulations have been developed for the current power grid and/or the smart grid communications infrastructure in the past. Some examples are:

• DISA Security Technical Implementation Guides (STIGs).
• FIPS 201 (Federal Information Processing Standard Publication 201): a U.S. federal government standard that specifies Personal Identity Verification (PIV) requirements for federal employees and contractors.
• North American Electrical Reliability Corporation‐Critical Infrastructure Protection (NERC CIP).
• National Infrastructure Protection Plan (NIPP).
• IEEE 1402: IEEE guide for electric power substation physical and electronic security.
• International Society of Automation(ISA).
• ISO/IEC 17799: Information technology, security techniques, code of practice for information security management.
• Domain Expert Working Groups (DEWGs): Consists of NIST and GridWise Architecture Council (GWAC) to explore smart grid interoperability issues, including:
  • Home‐to‐Grid;
  • Building‐to‐Grid;
  • Industrial‐to‐Grid;
  • Transmission and Distribution;
  • Business and Policy.

Given the continuous evolution of the smart grid and the massive scale as well as complexity of the cyber‐physical system, even more standards and regulations are required by the smart grid communications infrastructure, especially for security.