SunSpec Best Practice Guide - Security Recommendations...

Security Recommendations Best Practice Guide 1 www.sunspec.org

Document #: A42025-1.1 Status: Approved Version 1.1 Approval date: 06-19-2013

Security Recommendations SunSpec Alliance Best Practice Guide Contributors: John Blair, John Nunneley, Ralf Kaisler, Bob Fox, Ferdy Nagy, Bill Randle, Lynn Linse, Tom Tansy

Abstract This document examines issues related to cyber-physical security of PV systems in residential, commercial, and utility scale applications. Recommendations are made for developers of SunSpec standard solutions.


Copyright © SunSpec Alliance 2009-2014. All Rights Reserved. All other copyrights and trademarks are the property of their respective owners.

License Agreement and Copyright Notice This document and the information contained herein is provided on an "AS IS" basis and the SunSpec Alliance DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This document may be used, copied, and furnished to others, without restrictions of any kind, provided that this document itself may not be modified in anyway, except as needed by the SunSpec Technical Committee and as governed by the SunSpec IPR Policy. The complete policy of the SunSpec Alliance can be found at www.sunspec.org.

Prepared by the SunSpec Alliance

4030 Moorpark Avenue, Suite 109

San Jose, CA 95117

Website: www.sunspec.org

Email: [email protected]


Revision History Revision Date Reason

1.0 06-19-2013

Added secure read operation Added secure write operation Updates per group feedback Incorporate Tansy editorial, Ralf Kaisler feedback on secure response

1.1 09-22-2014 Change to new SunSpec document format


About the SunSpec Alliance The SunSpec Alliance is a trade alliance of developers, manufacturers, operators and service providers, together pursuing open information standards for the distributed energy industry. SunSpec standards address most operational aspects of PV, storage and other distributed energy power plants on the smart grid—including residential, commercial, and utility-scale systems—thus reducing cost, promoting innovation, and accelerating industry growth.

Over 70 organizations are members of the SunSpec Alliance, including global leaders from Asia, Europe, and North America. Membership is open to corporations, non-profits, and individuals. For more information about the SunSpec Alliance, or to download SunSpec specifications at no charge, please visit www.sunspec.org.

About the SunSpec Specification Process SunSpec Alliance specifications are initiated by SunSpec members desiring to establish an industry standard for mutual benefit. Any SunSpec member can propose a technical work item. Given sufficient interest and time to participate, and barring any significant objections, a workgroup is formed and its charter is approved by the board of directors. The workgroup meets regularly to advance the agenda of the team. The output of the workgroup is generally in the form of an Interoperability Specification. These documents are considered to be normative, meaning that there is a matter of conformance required to support interoperability. The revision and associated process of managing these documents is tightly controlled. Other documents are informative, or make some recommendation with regard to best practices, but are not a matter of conformance. Informative documents can be revised more freely and frequently to improve the quality and quantity of information provided.

SunSpec Interoperability Specifications follow this lifecycle pattern of DRAFT, TEST, APPROVED and SUPERSEDED.

For more information or to download a SunSpec Alliance specification, go to http://www.sunspec.org/specifications.


Table of Contents Table of Figures .............................................................................................................. 6 Nomenclature ................................................................................................................. 7 1. INTRODUCTION ....................................................................................................... 8 2. SECURITY REQUIREMENTS ................................................................................... 9

2.1 Availability & Safety .................................................................................................... 10 2.2 Confidentiality .............................................................................................................. 10 2.3 Data Integrity & Reasonableness ............................................................................... 10 2.4 Non-Repudiation/Accountability ................................................................................ 10

3. SUNSPEC REFERENCE ARCHITECTURE ........................................................... 11 3.1 Transport Security ....................................................................................................... 12 3.2 SunSpec Field Bus Transport .................................................................................... 12

RS-485 / Modbus RTU ........................................................................................................ 12 Ethernet (IEEE 802.3) / Modbus TCP ................................................................................. 13 Wireless (Zigbee, WIFI) ...................................................................................................... 13

3.3 Internet Transport ........................................................................................................ 14 3.4 Cloud Transport ........................................................................................................... 14 3.5 End-to-End Security .................................................................................................... 14

SunSpec Secure Meter Model ............................................................................................ 14 SunSpec Secure Dataset Read Request and Response Models ....................................... 15

3.6 Control Operations ...................................................................................................... 18 Role-Based Access Control (RBAC) ................................................................................... 18 Autonomous Operations ..................................................................................................... 19 Local Control Operations .................................................................................................... 19 Remote Control Operations ................................................................................................ 20 Secure Write Request and Response Models .................................................................... 21

3.7 Security Operations ..................................................................................................... 24 Device Key Management .................................................................................................... 24 Operator Key Management ................................................................................................. 25 Certificate Authority Key Management ............................................................................... 26

4. SUPPLY CHAIN RISKS .......................................................................................... 26 Appendix A – Digital Signature Implementation Notes ............................................ 27 Appendix B – Open Issues .......................................................................................... 27 References .................................................................................................................... 28


Table of Figures Figure 1: Hierarchy of DER Management ........................................................................ 9 Figure 2: SunSpec Reference Architecture .................................................................... 11 Figure 3: Potential Man-in-Middle Attack on Modbus RTU Daisy Chain ........................ 12 Figure 4: Secure Meter Read Model .............................................................................. 15 Figure 5: Inclusion of the Secure Dataset Read Models in a device .............................. 16 Figure 6: Secure Dataset Read Request Model ............................................................ 17 Figure 7: Secure Dataset Read Response Model .......................................................... 18 Figure 8: Local Operator ................................................................................................ 20 Figure 9: Remote operator via Trusted Gateway ........................................................... 21 Figure 10: Inclusion of the Secure Write Models in a device ......................................... 21 Figure 11: Secure Write Request Model ........................................................................ 22 Figure 12: Secure Write Sequential Request Model ...................................................... 23 Figure 13: Secure Write Response Model ..................................................................... 23 Figure 14: Get Device X.509 Security Certificate ........................................................... 24 Figure 15: Set Operator Certificate Model ..................................................................... 25


Nomenclature Abbreviation Meaning CA Certificate Authority

DER Distributed Energy Resources

EPRI Electric Power Research Institute

FIPS US Federal Information Procurement Standard

HMI Human Machine Interface

HTTP Hypertext Transfer Protocol

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol

ISO Independent System Operator

NIST National Institute of Standards and Technology

PCC Point of Common Coupling

PEM Privacy-Enhanced Mail

PKI Public Key Infrastructure

RBAC Role-Based Access Control

RTO Regional Transmission Organization

RTU Remote Terminal Unit

SCADA Supervisory Control and Data Acquisition

SSL Secure Sockets Layer

SW SunSpec Alliance Security Workgroup

TCP Transmission Control Protocol

TLS Transport Layer Security


1. INTRODUCTION For the solar industry to continue to grow and achieve high levels of penetration, the security of PV systems must be understood and improved to ensure adequate levels of protection from inadvertent or malicious behavior. The advent of advanced inverter controls, and new rules permitting Distributed Energy Resources (DER) to offer grid support services means the need to secure these systems has become urgent. In this document, the SunSpec Alliance Security Workgroup (SW) examines issues related to the cyber-physical security of PV systems in residential, commercial, and utility scale applications. The analysis focuses on the monitoring and control aspects of PV plant operations and identifies security threats as well as mitigation strategies. New information models are introduced to “wrap” the standard device models and address key security requirements. Increased reliance on remote monitoring and control communications to manage PV systems creates more security vulnerabilities. Furthermore, since PV systems are typically located at diverse customer locations, uniform security policies cannot be put into place or enforced. With increasing numbers of PV systems being installed throughout the electric distribution system, direct control by utilities becomes less feasible and practical. Rather, aggregation of these systems by retail energy service providers into larger virtual power plants introduces a hierarchical model of control to help manage this complexity. At the plant premise level, the operator manages generation based on the owner’s preferences. When these plants are participating in grid support operations, they must be coordinated with other resources within the distribution system, and ultimately with regional transmission and market operations. This hierarchy of management systems is depicted in the following figure.


Figure 1: Hierarchy of DER Management (courtesy of Frances Cleveland, Xanthus Consulting)

2. SECURITY REQUIREMENTS PV systems are termed cyber-physical systems because they combine operational power equipment with cyber control to provide the generation function they were designed for. In addition to attacks on the information, they also need to protect from deliberate cyber attacks, inadvertent errors, and equipment failures that have a direct physical impact.

There are many facets to security, all of which have varying importance depending upon the risk of an attack, the consequences should one occur, and the value of the target relative to the cost of protecting it. The National Institute of Standards and Technology (“NIST” see References) has identified 17 families of requirements with each family containing many detailed technical requirements. This paper will not attempt to cover all of these but will instead focus on a few key requirements related to PV plant operations. In particular, Modbus communication, common to most equipment, is often cited as a “weak link” in the security chain because of its lack of security. This paper will describe various mitigations and some improvements that address these concerns.


It is important to note that not all PV plants need to meet all requirements for security protections. A variety of factors including the ownership, size, location, and type of grid support provided, are all involved in determining what security measures should be put into place.

2.1 Availability & Safety PV Plants are built to safely provide clean, quality power to the energy off-takers. In this context, availability refers both to keeping the power on while the sun is shining and to keeping the communication channel open for important control signals and reliable telemetry. Safety requirements of the plant override this priority and dictate how the plant should behave under adverse grid conditions as well as potential cyber attacks. PV plant downtime or loss of supervisory control can result in lost revenue and potential for equipment damage.

2.2 Confidentiality Consumer and supplier identities can easily be exposed by the monitoring systems of operational PV plants and must be protected to ensure compliance with consumer protection laws as well as the potential loss of reputation by suppliers.

Plant operational data shall only be provided to authorized personnel and applications that have been adequately authenticated. While many owners proudly display their PV generation data in their public lobby, others regard this information as proprietary, of which unauthorized disclosure could cause financial harm or loss of reputation. Access to PV control systems should be minimally protected with passwords and physical controls such as locked doors. Stronger authentication and access control methods are introduced and proposed. Data encryption should be used for sensitive information being transmitted over public networks such as the Internet.

2.3 Data Integrity & Reasonableness Special care must be taken to ensure the data has not been tampered with. False readings from a PV plant may cause an operator to initiate shutdown or issue other controls that limit the availability or create a potential safety hazard. Off takers may not be getting what they are paying for without assurance of data integrity. Modification of control parameters by an attacker could also cause the plant to mis-operate or create unsafe conditions with potential for equipment damage.

Systems should be constructed so that unreasonable data will be ignored and trigger a security alarm. For example, a command to operate outside of accepted limits or telemetry that deviates significantly from normal/established patterns would be considered unreasonable. Such unreasonable data could be the result of faulty equipment, inadvertent operation, or a deliberate attack.

2.4 Non-Repudiation/Accountability Non-repudiation refers to the inability to deny that an action took place or to claim the source of some data was from some other than originally found. Non-repudiation is often required in the financial sector for high valued transactions where long-lived accountability is necessary. Non-repudiation is closely tied to message authentication and data integrity. For PV plants with revenue grade meters, it is important to guarantee that the readings are from the actual meter, that


they have not been tampered with when received, and that they cannot be changed or disputed later on.

Non-repudiation is also required for high impact grid control signals. Control operations need the ability to be audited and traced back to the issuer with confidence.

3. SUNSPEC REFERENCE ARCHITECTURE The SunSpec Reference Architecture (see Figure 2 below) describes the scope of the communication and information standards recommended by the SunSpec Alliance. On the left hand side of the figure, logical information models as defined by SunSpec represent the physical plant devices. These devices communicate using Modbus as the transport protocol over some transmission media (e.g. TCP/IP, RS-485(serial), Ethernet, wireless, or power-line).

The SunSpec Gateway functions as the Modbus Master, collecting data and passing controls to and from local and/or remote operators. The SunSpec Data Store accepts the SunSpec device data from the Gateway and is responsible for archiving and redistributing the data to SunSpec Applications. SunSpec Applications include Bulk Data Transfer (Operational Continuity), Periodic Reporting (Financial Oversight), Operational Status (Grid Integration), and other custom needs.

Security requirements are met through a combination of transport level security mechanisms, end-to-end security mechanisms, and security policies. Transport level security is required to provide protection of the data while it is in transit. End-to-end security provides protection of the data both in transit and while the data is at rest.

Beyond good locks, fences, and other standard surveillance techniques to prevent and detect physical attacks on the plant, the SunSpec Security Model discussed later in this paper can be included in the devices to meet requirements for end-to-end data integrity and non-repudiation.

Figure 2: SunSpec Reference Architecture


3.1 Transport Security Transport security provides protection while the data is in transit between two points in the network. There are typically three hops in the reference architecture:

1. Device < SunSpec Field Bus > Gateway

2. Gateway < Internet > Data Store 3. Data Store < Cloud > Application

3.2 SunSpec Field Bus Transport The SunSpec Field Bus transports Modbus data over a variety of communications interfaces such as TCP/IP, RS-485(serial), Ethernet, Wireless, or Power-Line. Each of these is examined in turn.

Modbus itself provides no security features. There are no encryption methods to protect data from prying eyes or modification. A simple (trusted) Master / Slave relationship exists between the communicating parties. Therefore, security measures must be employed elsewhere to meet requirements. This specification proposes information models that support the secure exchange of information and controls for SunSpec compliant devices.

RS-485 / Modbus RTU RS-485 is a long proven and well-established method of communication between devices. It remains the dominant field bus in PV applications because of its very low cost, simple wiring, support for long wiring runs, and reliability in often electrically noisy environments. Modbus RTU uses a “daisy-chain” method for connecting up to 254 individual devices per run. The data passes through each device in the chain and is relayed to each in turn to complete the transmission. RS-485 does not provide any security features itself, therefore physical security is required to prevent unauthorized modification of the daisy-chain. With physical access, it is possible to introduce a “man-in-the-middle” attacker using special purpose hardware and software that effectively splits the chain in two and mimics subverted devices to the real master. Because physical security may be inadequate or readily subverted by “insiders”, this is an area of concern for some applications. Because there are no encryption methods provided over RS-485, data confidentiality requirements are not met. Generally this is not viewed as a concern and is more effectively mitigated through the physical security measures. Applications that require confidentiality on the field bus should use a field bus that supports data encryption.

Figure 3: Potential Man-in-Middle Attack on Modbus RTU Daisy Chain

Meter Inverter Weather Man-in-

the-Middle Attacker

SunSpec Gateway

Slave Slave Slave Rogue|Mimic Master

Modbus RTU Daisy Chain


Ethernet (IEEE 802.3) / Modbus TCP Ethernet is a long proven and well-established method of communication between devices that has evolved over time under the authority of the IEEE. IEEE 802 networks are capable of running full TCP/IP stacks, and it is quite common for devices to support encapsulation of Modbus over TCP/IP. Modbus over TCP/IP provides much higher bandwidth, lower latency, and permits for multiple Modbus Masters to be present on the network. This introduces the potential for a rogue Master to be added to the network either by connecting to a local port or by subverting the Plant firewall in a remote attack. With physical access to the plant, an attacker could plug standard hardware and software into an available port to mimic the real Master to the devices, or with the proper knowledge, to subvert the firewall from the inside to enable a remote attack. A remote attacker would first require specialized software tools or knowledge to subvert the firewall, but would then be able to use standard software to mimic the real Master (note that this is not a classical “man-in-the-middle” attack because the real Master is still able to communicate with the real devices). A man-in-the-middle attack is possible if, depending on the network topology, an intermediate switch or router is infected. This attack may be mitigated by the use of Transport Layer Security (TLS) with mutual authentication to establish an encrypted tunnel between the device and the logger that cannot be modified. Modbus TCP implementations do not typically support Transport Layer Security (TLS) at this time. Vendors cite the additional cost because this is generally not viewed as a concern or more effectively mitigated through physical security measures. Over time, cost will become less and less of an issue, and we can expect more implementations to provide TLS support. Applications that require confidentiality on the field bus should require the use of TLS.

Wireless (Zigbee, WIFI) Wireless forms of communication are popular for many applications because of easier installation, particularly in retrofit situations such as Residential applications where it may be impractical to run wiring.

Common wireless networks in use are WiFi (IEEE 802.11) and Zigbee (IEEE 802.15.4). Both have evolved over time and matured under the authority of the IEEE. These networks can be operated in both secure and insecure modes. When operating insecurely, attacks as described in the Ethernet section are possible but without the need for physical access; only wireless proximity is required, to carry out an attack. When operating in secure mode, it is not theoretically possible to gain access to the network without being duly authorized. Secure modes of operation also provide data encryption that meets the confidentiality requirement for the field bus. The strength of the security modes for these networks is evolving. WIFI, because of its ubiquity, is constantly under attack and has undergone numerous security revisions. Zigbee security strength is often cited as an advantage over WIFI but comes with more complex setup, whereas WIFI is simpler and much more broadly deployed.


3.3 Internet Transport Once the Modbus data has been collected by the SunSpec Gateway over the SunSpec Field Bus, it is ready to be transported over the Internet to the SunSpec Data Store. The raw Modbus data is encoded into XML according to the SunSpec Upload Specification and transported using HTTP POST over a TCP/IP connection. Typically the Gateway is configured, at the factory or during installation, to report the data to one or more well-known Data Stores. All connections are outbound from the Plant to the Data Store and should use HTTPS, which is typically permitted by standard firewall configurations. Requirements for data integrity and confidentiality are met by using TLS to protect the data while in transit over the open Internet. Requirements for data integrity and non-repudiation are met by attaching a digital signature to the XML payload in the form of an HTTP header. The digital signature may be verified and stored by the Data Store, and made available to applications.

3.4 Cloud Transport Once the Modbus records have been safely accepted by a SunSpec Data Store, they are made available to applications. Applications typically will query the Data Store for some set of SunSpec data records. SunSpec data records that have been digitally signed can be further verified by the application. In particular, an audit application may process signed records to validate them and correlate the information with standardized reports generated by other applications.

3.5 End-to-End Security End-to-end data integrity and non-repudiation is achieved in the SunSpec architecture through the application of digital signatures at the source of the data generation and carried all the way through to the end consuming application. The SunSpec security models accommodate a variable length digital signature and algorithm for flexibility. The signature must be a minimum of 4 registers (64 bits) and shall be an integral of 16 bit registers. See Appendix A for details on the digital signature implementation.

SunSpec Secure Meter Model The AC meter has been singled out as a device that requires a high degree of data integrity and support for non-repudiation. This requirement comes from the financial community need to provide oversight and substantiate payments. With the introduction of Plant control, this same requirement is needed to provide status to the operators. Incorrect reporting of status could cause operators to take actions leading to grid instability. Therefore, a purpose built security model for the meter is defined. This model provides selected meter readings and appends a digital signature from the meter covering this data.


Figure 4: Secure Meter Read Model

SunSpec Secure Dataset Read Request and Response Models A general purpose secure dataset read request/reponse model is defined. Secure SunSpec devices should include the SunSpec Secure Dataset Read models to allow a digital signature to be requested over a selected set of registers. The model definition follows the standard SunSpec format and is included in the device map along with the device and vendor models.


In the following example (Figure 5), a SunSpec compliant device includes the Secure Dataset Read models to provide access to digitally signed meter measurements by financial and other applications.

Figure 5: Inclusion of the Secure Dataset Read Models in a device

In the Secure Read Request Model, the Master specifies a dataset of up to 100 register values that are to be securely read. A write to the “Sgn” register, causes the dataset values to be updated, time stamped down to the millisecond, and digitally signed by the device. An optional digital signature may be used to authenticate and control access to secured registers. The Secure Read Response Model provides the requested register set and includes a digital signature as proof the dataset was originated by the device and provides for data integrity and non-repudiation. A generic security Alarm “Alm” is included to raise a security exception, which indicates device tampering or other security related conditions. NOTE: Secure devices should support Modbus Function code 23 (0x17) Read/Write Multiple registers. This function code allows for the secure request and secure response to be performed within the context of a single Modbus transaction, thereby reducing complications related to multiple masters.


Figure 6: Secure Dataset Read Request Model


Figure 7: Secure Dataset Read Response Model

3.6 Control Operations High penetration of solar PV plants within the electric distribution system is driving the need to rewrite the interconnection rules in order to allow these systems to provide grid support functions. Details of these functions can be found in the SunSpec Inverter Control specification which is based on related EPRI and IEC 61850 work. The security requirements for control operations are driven primarily by the needs to maintain a stable and available grid. PV plants under the control of a rogue operator can cause disruptions in service and power quality.

Most PV power plants, such as a residential roof top installation, are too small to be of much concern individually. However, the ability to aggregate these resources into a “virtual” power plant raises the specter of a coordinated “class break ” style of attack that could destabilize the grid.

Large “utility” scale PV plants are typically afforded physical security protections but are still vulnerable to cyber attacks that could disrupt operations if not adequately protected.

Role-Based Access Control (RBAC) SunSpec recommends the implementation of role-based access control (RBAC) mechanisms to protect critical control operations from being invoked by unauthorized attackers. An RBAC


system implements multiple levels of access to control operations in order to limit the operations that may be performed by a given operator.

SunSpec has identified 5 levels of access control. Operators identify themselves to the system via an identifier+password combination that slots them into a specific “role” that determines what operations are allowed. Each level may have a discreet set of permissions that make up the role.

1. User Level. Access to this level permits basic user preferences to be accessed. For example, shutting down or disconnecting the plant to perform maintenance.

2. Operator Level. Access to this level permits the invoking of certain modes or functions. For example, enabling volt-var support or switching from schedule A to schedule B.

3. Supervisor Level. Access to this level permits the programming of settings that affect how the various modes actually function. For example, setting the curves to be used for volt-var support or the setting of a new schedule.

4. Manufacturer Level. Access to this level permits the changing of settings that are typically set once at the factory. For example, changing operating limits and internal settings that should not need to be changed to support normal operations.

5. Security Level. Special access is required for setting up and maintaining the RBAC system and the keystore. This includes updating keys as necessary and the ability to add/remove/modify users of the system along with their corresponding access rights.

RBAC systems are supported by strong authentication of the operator requesting access to the controls and strong integrity of the control messages. It should not be possible for an attacker to masquerade as a valid user, nor should it be possible for a man-in-the-middle attacker to modify the control messages or the responses. Once again, digital signatures provide the foundation for authentication, message integrity, and non-repudiation requirements.

Autonomous Operations Because of the large number of small, “unmanned” PV systems being deployed, it is becoming increasingly impractical to control these systems directly. Instead, PV systems can be pre-programmed to affect the desired responses according to given operating conditions as sensed on the grid. For example, volt-var curves can be enabled according to time-of-day or temperature based schedules. These settings can be provisioned in the factory, in the field at installation time, or during maintenance by trained technicians. Still, methods are needed for operators to override these settings under changing operational or emergency conditions.

Local Control Operations Operations may be performed under the authority of a local operator. Entering of a valid login identifier and authentication method permits access to the level of control for that operator. A secure write operation which contains the appropriate digital signature is defined such that a device can duly authorize the operation.


Figure 8: Local Operator

Remote Control Operations Operations may also be performed under the control of a remote operator via a trusted gateway of some form. Two types of trusted gateways are identified:

1. A standard gateway provides a secured “virtual private network” where the remote operator appears on the network just as a local operator would.

2. A Trusted Gateway is a special purpose proxy that implements the role-based access control system. The gateway securely polls a well-known host for digitally signed control messages. Authorization is performed at the gateway and the control is forwarded on to the inverter using a secure write operation that includes the digital signature of the gateway. The inverter is configured to trust and only accept commands from the gateway.


Figure 9: Remote operator via Trusted Gateway

Secure Write Request and Response Models Secure write models are proposed to provide strong authentication and message integrity. These models are included with the device and vendor models to authenticate and control access to the device settings. The request model includes a block of register values that include both the register offsets and register values for the target registers to be written, and includes a digital signature over the secure register block. This allows up to 50 non-contiguous target registers to be written in a single write operation, and supports “select before write” semantics.

Figure 10: Inclusion of the Secure Write Models in a device

Two forms of the secure write request are provided. The first allows for up to 40 arbitrary registers to be written two as defined by the <offset, value> pairs. The second form allows for up to 80 registers to be written sequentially from a starting offset point. The control operation may fail for a variety of reasons including: digital signature incorrect, access control, invalid offset, or invalid value. It is recommended that a Secure Write Response Model be used in conjunction with the request model to securely communicate the success or failure of the operation.


NOTE: Secure devices should support Modbus Function code 23 (0x17) Read/Write Multiple registers. This function code allows for the secure request and secure response to be performed within the context of a single Modbus transaction, thereby reducing complications related to multiple masters and improving performance.

Figure 11: Secure Write Request Model


Figure 12: Secure Write Sequential Request Model

Figure 13: Secure Write Response Model


3.7 Security Operations Operations that update the security of the system require separate methods and level of access control to perform. A certificate authority (CA) issues keys to devices and operators so that they may authenticate each other. Mutually authenticating parties require access to the other party’s public certificate to perform the authentication. In addition, the CA makes public its signing certificate so that the certificates themselves may be authenticated. Certificates may expire or become otherwise comprised, and require updating. ToDo: This entire section needs more work ….

Device Key Management Secure operations and policies are required to maintain the integrity of the security system. This includes manufacturer processes to install device keys (outside of the scope of this specification) as delivered from the factory, and the management of operator keys used to access the device controls. PKI depends on a CA to vouchsafe device identity along with the ability to update and revoke keys, should that be necessary. Common practice allows for a relatively long (years), but automatic, expiration period that necessitates key updates. Furthermore, the root CA key will need to be updated from time to time and accounted for with extra care.

Device Public Key READ A model is defined to read the device public key certificate. This certificate is installed at the factory, and may be encoded in DER or PEM format. Because the certificates are relatively large, it may take multiple Modbus read operations to read the entire certificate, which verifies its authenticity by virtue of the CA signature attached to it. The reader of this certificate must have the CA public key to verify the device’s certificate signature.

Figure 14: Get Device X.509 Security Certificate

Device PKI UPDATE


ToDo. Update the device key-pair. The device key-pair has expired or become otherwise compromised. May be manufacturer-specific.

ToDo: How long should the default expiration period be? This is our policy to be specified with some technical constraint on risk.

Operator Key Management A Role-Based Access Control mechanism allows for multiple levels of operator control to be set as a policy. In particular, it is recommended that requests to perform security key updates should be done with a different key than normal operator requests. A method for an operator certificate to be installed on the device is required for the device to be able to authenticate requests made by the operator.

ToDo: Determine and document level of control required for writeable registers.

Set Operator Certificate A model is defined to set the certificate for an operator. An operator is referenced by their user_id and associated role. In the simplest case, a single operator could be associated with all roles. However, it is recommended that each role have a separate certificate to control access to the various levels of roles defined. This is especially important for the security role.

ToDo: Explain the setting of the security role certificate

Figure 15: Set Operator Certificate Model


Certificate Authority Key Management All participants in the security chain need access to the Certificate Authority (CA) root certificate in order to authenticate the other participant’s certificate. The CA certificate will typically be installed at the factory but may need updating from time to time depending on the policy of the CA. ToDo: Determine the CA policy for the expiration period for the CA root certificate. Get this from the selected CA.

ADD CA Root Certificate ToDo: Define model or method. Accommodate multiple CAs.

4. SUPPLY CHAIN RISKS Increased risk and incidences of embedded malware and industrial espionage have increased scrutiny around best practices in supply chain management relative to the cyber security of these systems. As noted, infected networking gear can introduce man-in-the-middle scenarios that open up a number of attack vectors at running plants. Viruses specific to industrial control systems have been created by accessing insider information such as software codes and design specifications, and spread through IT networks.

While these types of attacks may strike directly at our economic competiveness and national security, it is incorrect to think of this as an “import” problem. The supply chain is global, and nothing is going to change that. Since attacks may be originated from both home and abroad, supply chain security measures need to be broadly applied. As there has been much discussion and writing on this topic lately, this paper will not delve into this any further other than to identify a few key considerations:

• Use of standard IT defenses plus supply chain security to prevent insertion of counterfeit or compromised devices.

• Build on business supply chain management best practices • End-of-life disposal to prevent counterfeiting • Secure chain-of-custody / contractual requirements • QA programs that include audit. • Tamper detection - Secure boot loaders that will only load authenticated modules • Secure software source code and product design documentation repositories that support

document secrecy and access control policies. This helps prevent attackers from stealing intellectual property and security secrets, and from intentional modifications that enable an internal threat.


Appendix A – Digital Signature Implementation Notes A digital signature allows an entity to authenticate the integrity of the message data and the identity of the signatory. The digital signature algorithm used shall be the United States Federal Information Procurement (FIPS) standard, as specified in FIPS 186-3 and published by the NIST. Signature generation uses asymmetric (public/private) key technology. The signer uses their private key to compute the digital signature, and anyone can verify the signature using the signer’s public key. The signature includes enough data such that it is not feasible to alter the document in order to produce the same signature. To Be Specified: Key Size DS Size Key Management

Appendix B – Open Issues • How to administer the access control writes

o Tagging of registers to roles o Assignment of credentials to roles

• How to expose the device public key • PKI management

o Vendor evaluation (Green Hills, other? o Certificate format o Getting keys onto the devices o Updating keys

• Symmetric key management o Exchange of shared secret keys

• Crypto o Algorithms o Key sizes o Hash sizes


References R1: IEC/TS 62351: Power systems management and associated information exchange – Data and communications security. R2: Guidelines for SmartGrid Cyber Security. NIST Interagency Report 7628. National Institute of Standards and Technology: Gaithersburg, MD, August 2010. http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7628 R3: NESCOR DER Cybersecurity Reports https://community.energysec.org/confluence/category/sub-dashboard.action?categoryKey=nescor R4: US Resilience Project: Supply Chain Solutions for Smart Grid Security. US Resilience Project. 2012. http://www.us-nesco.org/files/2013/01/SupplyChain-Solutions-for-Smart-Grid-Security.pdf

R5: Frances Cleveland, et.al. SGIP DRGS DEWG: DER Cyber Security Recommendations. R6: Wikipedia Links

http://en.wikipedia.org/wiki/Digital_Signature_Algorithm http://en.wikipedia.org/wiki/Customs_Trade_Partnership_against_Terrorism http://en.wikipedia.org/wiki/Supply_chain_security R7: FIPS 186-3 Digital Signature Standard - http://csrc.nist.gov/publications/drafts/fips186-3/fips_186-3.pdf FIPS 180-4 Secure Hash Standard

SunSpec Best Practice Guide - Security Recommendations...

Documents

Transcript of SunSpec Best Practice Guide - Security Recommendations...