Certification Procedures for Data and Communication...

NREL is a national laboratory of the U.S. Department of Energy Office of Energy Efficiency & Renewable Energy Operated by the Alliance for Sustainable Energy, LLC This report is available at no cost from the National Renewable Energy Laboratory (NREL) at www.nrel.gov/publications.

ThisdraftisNRELpropertyanditisforworkinggroupuseonly.Pleasedonotcite,quote,ordistribute.

Contract No. DE-AC36-08GO28308

Certification Procedures for Data and Communication Security of Distributed Energy Resources Danish Saleem, Andrew Michalski National Renewable Energy Laboratory

Technical Report NREL/TP-xxxx-xxxxx March 2018

This is a Draft for working group use only. Do not cite, quote, or distribute. Send comments and feedback to [email protected]


NOTICE

This report was prepared as an account of work sponsored by an agency of the United States government. Neither the United States government nor any agency thereof, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States government or any agency thereof. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States government or any agency thereof.

This report is available at no cost from the National Renewable Energy Laboratory (NREL) at www.nrel.gov/publications.

Available electronically at SciTech Connect http:/www.osti.gov/scitech

Available for a processing fee to U.S. Department of Energy and its contractors, in paper, from:

U.S. Department of Energy Office of Scientific and Technical Information P.O. Box 62 Oak Ridge, TN 37831-0062 OSTI http://www.osti.gov Phone: 865.576.8401 Fax: 865.576.5728 Email: [email protected]

Available for sale to the public, in paper, from:

U.S. Department of Commerce National Technical Information Service 5301 Shawnee Road Alexandria, VA 22312 NTIS http://www.ntis.gov Phone: 800.553.6847 or 703.605.6000 Fax: 703.605.6900 Email: [email protected]

Cover Photos by Dennis Schroeder: (left to right) NREL 26173, NREL 18302, NREL 19758, NREL 29642, NREL 19795.

NREL prints on paper that contains recycled content.


January,2018

Certification Procedures for Data and Communication Security of Distributed Energy

Resources Danish Saleem, Andrew Michalski

National Renewable Energy Laboratory


Abstract As global electric power infrastructures evolve, the power industry is relying more on the information that is needed to operate the power systems. The reliability of power systems is becoming more vulnerable due to the problems caused by poor infrastructure of information systems. The security and management of information systems infrastructure has now become equally important as a power systems infrastructure. But unfortunately, there is significant gap and lack of consistency in the adoption of basic and stringent cyber security controls for the information infrastructure of distributed energy resources (DERs) by the vendors on their technology and how those controls interoperate with the data and communications security controls that utilities are implementing at the interface to the DERs. This certification procedure document is intended to provide minimum security requirements for the DER that can be used by vendors, utilities, certification labs and government organizations.


Acknowledgements This work is funded by the National Electric Manufacturers Association (NEMA). The author will add all the members that had and will provide comments and feedback to this project.


Table ofContents

Executive Summary ....................................................................................................... 81 Introduction ............................................................................................................... 92 Security Vulnerabilities Addressed ....................................................................... 11

2.1 Man in the Middle Attacks (MITM) ...............................................................................112.2 Replay ..............................................................................................................................112.3 Eavesdropping .................................................................................................................112.4 Spoofing through Security Certificates ...........................................................................11

3 Test Cases ............................................................................................................... 113.1 Two-Party Application Association ................................................................................13 3.2 Initiates TCP on port 19998 ............................................................................................14 3.3 Client/Server matching object model namespace ............................................................14 3.4 Transport-Level Security activated for Client/Server .....................................................15 3.5 Session Resumption/Renegotiation .................................................................................15 3.6 Master Secret Key Update ...............................................................................................16 3.7 Message Authentication Code .........................................................................................17 3.8 Multiple Certification Authorities ...................................................................................18 3.9 Certification Revocation List ..........................................................................................18 3.10 Expired Certificate ...........................................................................................................19 3.11 Client interacts with server ..............................................................................................19 3.12 Client reads data attributes ..............................................................................................20 3.13 Client reads complete data objects ..................................................................................20 3.14 Client sets data attribute ..................................................................................................21 3.15 Client receives data objects .............................................................................................21 3.16 Client receives data objects .............................................................................................22 3.17 Client receives data objects .............................................................................................23 3.18 Data transfer with activated cyber security .....................................................................23 3.19 Data transfer with activated cybersecurity ......................................................................24 3.20 Read individual data attributes with cybersecurity .........................................................25 3.21 Client reads complete data objects with cybersecurity ....................................................25 3.22 Client sets individual data attribute with cybersecurity ..................................................26 3.23 Client receives the data objects with cybersecurity .........................................................26 3.24 Client issues control commands with cybersecurity .......................................................27

4 Next Steps & Milestones ........................................................................................ 28


Acronyms

NREL National Renewable Energy Laboratory CPSS&R Cyber Physical Systems Security & Resiliency NEMA National Electric Manufacturers Association IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers DER Distributed Energy Resource IT Information Technology OT Operational Technology MGMT Management VLAN Virtual Local Area Network TLS Transport Layer Security RTU Remote Terminal Unit SCADA Supervisory Control and Data Acquisition ICCP Inter-Control Center Communications Protocol TCP/IP Transmission Control Protocol/Internet Protocol DNP Distributed Network Protocol SCD Substation Configuration Description SCL Substation Configuration Language PKI Public Key Infrastructure TPAA Two Party Application Association TCP Transmission Control Protocol CA Certification Authority OCSP Online Certificate Status Protocol MITM Man in The Middle DoS Denial of Service SDN Software Defined Networking NCAT Network Comparison and Analysis Tool NMAP Network Messaging Application Protocol ACL Access Control List IP Internet Protocol HTTP Hyper Text Transfer Protocol WebUI Web User Interface IDS Intrusion Detection System PIXIT Protocol Implementation eXtra Information for Testing CRL Certificate Revocation List NIC Network Interface Controller


Executive Summary

The National Electric Manufacturers Association (NEMA) asked National Renewable Energy Laboratories to create a test plan that can satisfy minimum security requirements for DERs and can help vendors to improve the overall cyber security posture of their products (DERs). This certification procedure document is intended to provide minimum security requirements for the DER and it can be used by any vendors, utilities, certification labs government organizations and industry partners.

The scope of this project includes developing a detailed consensus based test plan to validate the DER security standards specifications. In this report we have taken high level business use cases of DER security, compared them with the specifications mentioned in the International Electrotechnical Commission (IEC) 62351-3 and -4 standards, and converted them into 24 test cases. The team then distilled out a detailed test plan for each of the 24 test cases with action and review items so they will be easy to test and validate on DERs in the lab environment. Once done with testing and validating the DER test cases, the plan will serve as a certification procedure for the vendors and certification labs. These test cases are adhere to part three and four of IEC 62351, which is communications & network security over TCP/IP and might serve (in the future) as a certification procedure for data and communication security of DER.

The 24 test cases, which are detailed in section 4 of this report, protect against vulnerabilities like eavesdropping and replay (through TLS encryption), man-in-the-middle security risk and spoofing through security certificates (node authentication). These test cases cover the four major communication standards that are used for power systems management and associated information exchange. These communication standards are: IEC 60870-5, which is widely used in Europe and other non-U.S. countries for supervisory control and data acquisition (SCADA) systems to remote terminal unit (RTU) communications; Institute of Electrical and Electronics Engineers (IEEE) standard for Electric Power Systems Communications-Distributed Network Protocol (DNP3), also known as IEEE 1815 and widely used in North America and many other countries for SCADA system to RTU communications; IEC 60870-6, also known as Inter-Control Center Communications Protocol (ICCP) and used internationally for communications between control centers and also for communications between SCADA systems and other control systems, and IEC 61850,used for interaction with field equipment.

The following test cases also cover profiles used previously by: § IEC 60870-5 (part 104) § IEC 60870-6 (ICCP) § IEEE 2030.5 (SEP2) § IEEE 1815 (DNP3) over TCP/IP § IEC 61850 over Transmission Control Protocol (TCP)/Internet Protocol (IP)


1 Introduction 1.1 Background

Security by obscurity is no longer a valid concept. The rising potential of cybersecurity threats has become particularly evident in recent events, such as the wannacry ransomware attack and Equifax cyberattack. Despite the sensitivity of communications infrastructure, the incorporation of stringent security controls and preventive measures, that can stand the cyberattacks, is below par. Therefore, to create an efficient and effective way of making DERs secure, there should be compliance documentation that takes into account all the necessary basic and stringent security controls along with the specifications mentioned in the IEC 62351-3 & 4 standards for securing the data and communication structure of DERs.

There were 3,007,682,404 data records lost or stolen since 2013 till March 2015. The WannaCry ransomware attack, that happened in May 2017, effected 200,000 people and 300,000 computers from 150 countries. Recent data breach of Equifax cost almost 120 million customers lose their Personal Identifiable Information (PII). eBay data breach cost 145 million customers lose their PII. The Home Depot data breach cost 56 million customers lose their Debit and credit card numbers

The reason for showing all these stats is very simple. Good judgement comes from experience and experience comes from bad judgement and we already had enough bad judgements. Its high time that we make a Certification Procedure document which is authorized and validated by


SunSpec alliance DER security group, SGCC committee, IEEE standards committee and IEC TC 57 WG15 and other standards committee as well.

All test cases will involve a client and a server connected to one another with an ethernet cable, configured with a reachable IP address. Static addresses will be configured. 192.168.1.1/30 will be used by the server and 192.168.1.2/30 will be used by the client. Prior to all tests, connectivity between the client and server will be tested and pingability will be confirmed. The server will host its own Online Certificate Status Protocol (OCSP) responder on its loopback interface and will capture loopback traffic to observe requests sent to the OCSP. Between each test a reboot on both the client and the server will occur to ensure there are no active connections.

1.2 Goals and Objectives

1. To accelerate the adoption of stringent security controls for DERs. These days we have very granular data and on top of that the ability to access that data increase the vulnerabilities of cyber-attack. Therefore, there is s need to Accelerate the adoption of stringent security controls for the protection of the data and communication security for DERs.

2. To standardize certification procedures for DER security. For a multi-vendor environment utility, there should not be a lot of variations in security and interoperability controls of DERs just because those DER are coming from different vendors. Therefore, standardizing the certification procedure will help utilities, aggregators and all the end users to have a peace of mind while purchasing DER

3. To address the potential DER cybersecurity issues by establishing partnership with

multiple vendors.


2 Security Vulnerabilities Addressed TCP/IP and the security specifications in this part of IEC 62351 cover only the communication transport layers (OSI layers 4 and lower). This part of IEC 62351 does not cover security for the communication application layers (OSI layers 5 and above) or application-to-application security.

2.1 Man in the Middle Attacks (MITM) A man-in-the-middle attack occurs when a third party secretly replays and possibly alters the communication between two parties who believe they are directly communicating with each other. This attack can drop, modify, or add data transmissions while in transit to a destination. This threat is countered through the use of message authentication code specified in the document.

2.2 Replay Packet replay (also known as playback attack) is an attack where a third party maliciously captures and repeats, or delays, valid data transmissions. This threat is countered through the use of specialized processing state machines specified by the normative references of this document.

2.3 Eavesdropping This attack is an attempt from a third party to view valid data transmissions from an unauthorized source for reconnaissance. This threat is countered through the use of encryption. NOTE: The actual performance characteristics of an implementation claiming conformance to this standard are out-of-scope of this standard.

2.4 Spoofing through Security Certificates Security certificates are used to authenticate the client and the server. A CRL (Certificate Revocation List) can be issued in the event of a compromised certificate to ensure connections only occur between an authenticated client and server.

3 Basic and Stringent Security Controls

3.1 Basic security controls • Strictly enforce role-based access controls in firewall. • Network segmentation with different VLANs to create air gap between OT, IT and

Management networks • Locking down each DER in 30-bit mask so that no other parties can talk to them • Periodically updating of software security patches and firmware. • Encrypt selectively to minimize processing overhead and application latency


• Systemically secure the network by implementing context based, and signature based intrusion detection systems and in-line blocking tools

• Disabling all unused ports to eliminate unauthorized access

3.2 Stringent security controls • Transport layer security (TLS) should be activated in the DERs like inverters, microgrid

controllers etc • Session resumption should happen if the session is severed for the time less than TLS

session resumption time using the secret session key. • Session negotiation should happen if the session is severed for the time greater than the

TLS session renegotiation time. • Use of Message Authentication Code (MAC) • Support for multiple Certification Authorities (CA) • Capability of terminating the session if a revoked certificate is used to establish the

connection. This is done by using Certification Revocation list (CRL) • Capability of identifying and terminating the session if an expired certificate is used to

establish the connection.

4 Test Cases All test cases will involve a client and a server connected to a single switch with an Ethernet cable, configured with a reachable IP address. The switch will have a mirror port that a laptop will be plugged into for capturing traffic between the client and server. Prior to all tests,


connectivity between the client and server will be tested and pingability will be confirmed. The server will host its own OCSP) responder on its loopback interface and will capture loopback traffic to observe requests sent to the OCSP. Between each test, a reboot on both the client and the server will occur to ensure there are no active connections.

4.1 Two-Party Application Association The client configures the network addressing information that is necessary for it to enable communications with the selected server. It then establishes a two-party application association (TPAA) using TCP/IP. The client closes the association with the server and verifies that no interactions can take place. No. Action

1 Connection of the client and server with Ethernet cable

2Lock them down by assigning IP address in 30 bit mask so that no other parties can talk to them

3 A packet capture is started on the client

4 Then check that are they pingable or not

5 The client will initiate TPAA using TCP/IP

6 The session is kept active for 10 minutes

7 The session is closed by the client and the time is documented


8 The session is left closed for at least 10 minutes before stopping the packet capture

9 Packet capture will be reviewed to verify success

No. Review

1The Controlling Station initiates the TCP/IP connection using remote station TCP/IP port 19998.

2 The Controlled Station accepts the TCP/IP connection on TCP/IP port 19998

3Verify that no communication took place after the session was closed between the client and server

4.2 Initiates TCP on port 19998 The client configures itself with the server object model namespace by extracting the Logical Node and corresponding data template information from the appropriate SCD file. No. Action

1 A client/server is configured the same way as Test Case #1

2 Client will establish a connection to the server

3 The data template will be collected from the server and the client to inspect the Substation Configuration Description (SCD ) file

No. Review

1 Review the server object model namespace

2 Compare the data template on the client side with the server.

4.3 Client/Server matching object model namespace The client verifies that its configuration actually matches the server’s object model namespace by performing GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDirectory, GetDataDirectory, GetDataDefinition, and GetDataSetDirectory services. Reporting of a pre-defined dataset is started.


No. Action

1 Theclientestablishesaconnectiontotheserver

2 Theslientperformsthefollowingcommandstotheserver:GetServerDirectory,GetLogicalDeviceDirectory,GetLogicalNodeDirectory,GetDataDirectory,GetDataDefinition,GetDataSetDirectory

No. Review

1 Reviewtheserver'sobjectmodelnamespace

2 Reviewtheclient'sconfigurationandensureitmatcheswiththeServer

4.4 Transport-Level Security activated for Client/Server Transport level cybersecurity (TLS) for the network (TLS as per IEC 62351-3 and the Transport Profile from IEC 62351-4) is activated at both the client and the server, using the mandatory T-profile cipher suite. The public key infrastructure (PKI) technology is used to establish secret keys and initiate the creation and use of session keys. The client then establishes a TPAA with the server. No. Action

1 The client establishes a connection to the server

2 A packet capture is started on the server and the client

3 The client connects with PKI and TPAA activated.

No. Review

1 Both packet captures are reviewed to see if PKI and TPAA exchange occurred

4.5 Session Resumption/Renegotiation The connection between the client and server is severed for less time than the TLS session resumption time and/or bytes exchanged as specified in the PIXIT. The client resumes the secure connection by renewing the secret session key. The connection between the client and server is severed for a longer time than the TLS session resumption time. The client renegotiates the secure connection.


No. Action


2 Certificates will be created on the client and server (less than 8192 octets)


4 The client connects to the server

5 A consistent data flow exchange is started from the client to the server

6After 15 or more minutes of successful data exchange, the client Network Interface Controller (NIC) is disabled and the time is recorded

7The client NIC is enabled before the session expires and the session should resume. The time is recorded to note when session resumption occurred

8 The client maintains an active session for 15 or more minutes

9 After 15 or more minutes, the client NIC is disabled

10 After a duration longer than the session resumption time, re-enable the client NIC

11 Record the time to note when session renegotiation occurred

No. Review

1 Review the packet capture that the client/server successfully exchanged data

2Review the packet capture that communication stopped after the client's NIC was disabled

3Verify in the packet capture that session resumption occurred when the NIC was disabled for a shorter time than the session resumption time

3Verify in the packet capture that a session was renegotiated when the NIC was disabled longer than the session resumption time

4.6 Master Secret Key Update After the connection has been active for more than the master secret key update time, the master secret keys are updated, initiated by the “called” entity.


No. Action






6 Ensure the data exchange occurs for longer than the master secret key update time

No. Review

1 Review packet capture and identify when the master secret keys updated

4.7 Message Authentication Code It is verified that the message authentication code is used.

No. Action






6 Ensure the data exchange occurs for longer than the master secret key update time

No. Review

1 Review packet capture and verify the message authentication code is used


4.8 Multiple Certification Authorities Support for multiple certification authorities(CAs) is verified, including with secret keys and public keys. Error conditions are handled correctly and cause notifications. If any error occurs, the connection is terminated.

No. Action


2 Multiple CAs (4 or more) are created and exchanged between the client and server



5 A single CA is tampered with on the CA to provoke an error

No. Review

1 Review packet capture for error conditions and notifications generated

4.9 Certification Revocation List A CRL is used to identify the server as having a revoked certificate. The client takes appropriate action and terminates the session based on that certificate. Once all certificates are revoked, the connection is terminated and a notification is issued.

No. Action


2 Multiple CAs (4 or more) are created and exchanged between the client and server


4 The server starts a packet capture between itself and the OCSP responder

5 The client sends a steady flow of communication to the server for a period of time

6 A single CA is revoked and will send a CRL

No. Review

1 Review packet capture for notifications and verify the connection is terminated


4.10 Expired Certificate The client tries to establish an association using an expired certificate. The association is not established and a notification is issued. No. Action


2 A CA is created and exchanged between the client and server with an expiration date that has already expired


4 The client attempts to establish a connection to the server

No. Review

1 The packet capture will show that the session was attempted but did not complete

4.11 Client interacts with server With cyber security disabled, the client verifies that it can interact with the server by performing GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDirectory, GetDataDirectory, GetDataDefinition, and GetDataSetDirectory services. The data is validated. No. Action

1 Cyber security controls in the protocol will be disabled

2 A client and server are connected by Ethernet cables and configured with IP addresses that can communicate

3 The client sends the following requests to the server: GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDirectory, GetDataDirectory, GetDataDefinition, and GetDataSetDirectory

4 The session is closed from the Client side

5 Keep the packet capture running for 15 minutes to verify no further communication takes place


No. Review

1 The data returned is checked for accuracy.

4.12 Client reads data attributes The client reads individual data attributes from data objects in the server. The values are validated by viewing the client results against what is in the server. No. Action

1 A tool will need to be configured to inspect the attributes of the data objects on the server as they exist in memory.


3 The client will request each data attribute from the server one at a time as possible. The values on the client will be inspected from the packet capture.

4 The data object values will be dumped off the server using the tool mentioned above

5 The values from the packet capture being received from the client will be compared against the data object values on the server dumped from memory.

No. Review


4.13 Client reads complete data objects The client reads complete data objects in the server. The values are validated by viewing the client results against what is in the server. No. Action


2 A packet capture is started on the client.

3 The client will request all data attributes from the server. The values on the client will be inspected from the packet capture.



5 The values from the packet capture being received from the client will be compared against the data object values on the server dumped from memory. The values should match.

No. Review


4.14 Client sets data attribute The client sets an individual data attribute in the server. The values are validated by viewing the client results against what is in the server. No. Action



3 The client will send a request to set an individual data attribute on the server one at a time for all applicable data attributes.

No. Review

1 The values dumped from memory on the server will be inspected to ensure it is what the client set the data attribute to be.

4.15 Client receives data objects The client receives the data objects in a dataset. The values are validated by viewing the client results against what is in the server. No. Action



3 The client will request all data attributes from the server. The values on the client will be


inspected from the packet capture.

No. Review



4.16 Client receives data objects Application level cybersecurity is activated for an OSI environment, with or without TLS. The client (the requestor) establishes an association with the server (the acceptor) as defined in IEC 62351-4 for end-to-end application profiles. In particular, all association actions are tested, including association request, association accept, association reject, association abort, and data transfer abort. No. Action


2 A local proxy server will be setup on the client to tamper outgoing client requests.

3 The client sends an association request. The server should reply with an association accept.

4 The client will send an association request. This time the request will be edited via the proxy to intentionally make the request invalid. The server should send an association reject.

5 The client will send an association request again. The server should reply with an association accept. After the connection is associated the client will resend an association request that will be tampered via a proxy the server should send associations reject to the request, and send associations abort to the accepted association.

6 The client will send an association request again. The server should reply with an association accept. The client will send test data to the server. Part way through the transfer the packets will be tampered via a proxy to modify the session information. The server should recognize it and respond with a data transfer abort.

No. Review

1 The packet capture is reviewed to inspect the association request


4.17 Client receives data objects Handshake handling with activated cyber security: The handshake process during association is validated including appropriate actions and notifications. Error handling includes handshake rejection, MMS (Multimedia Messaging Message) rejection, association abort, and other causes. The various cryptographic components (ClearToken1 parameters, signature algorithms, handshake problem, and data transfer problem) are validated. The response of the acceptor to errors is validated. No. Action

1 Cybersecurity controls are enabled for the protocol

2 A client and server are connected by Ethernet cables and configured with IP addresses that can communicate.


No. Review


4.18 Data transfer with activated cyber security The format of the data power distribution units (PDUs) is validated for both unencrypted and encrypted data, per the A+ and AE+ profiles. Error handling includes validation of unencrypted data transfers and encrypted data transfers. The various cryptographic components (syntax of messages, ClearToken2 parameters, and authenticator) are validated. The response of the acceptor to errors is validated. No. Action

1 Cyber security controls are enabled for the protocol.


3 Encryption will be turned off.

4 Unique test data will be constructed on the client. Different test data will be constructed on the server.

5 Theclientwilltransferitsdatatotheserver.

6 Theserverwilltransferitsdatatotheclient.


7 Theclientsystemwillbeinspectedandwillconfirmithasreceivedtheuniquetestdatafromtheserver.

8 Theserversystemwillbeinspectedtoconfirmithasreceivedtheuniquetestdatafromtheclient.

9 Encryption is turned on.

10 Unique test data will be newly constructed on the client. Different test data will be constructed on the server.

11 The client will transfer its data to the server.

12 The server will transfer its data to the client.

13 The client system will be inspected and will confirm it has received the unique test data from the server.

14 The server system will be inspected to confirm it has received the unique test data from the client.

No. Review

1 The client system will be inspected and will confirm it has received the unique test data from the server.

2 The server system will be inspected to confirm it has received the unique test data from the client.

4.19 Data transfer with activated cybersecurity With cybersecurity activated, the client verifies that it can interact with the server by performing GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDirectory, GetDataDirectory, GetDataDefinition, and GetDataSetDirectory services. The data is validated. No. Action

1 Cybersecurity controls in the protocol will be disabled


3 The client sends the following requests to the server: GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDirectory, GetDataDirectory, GetDataDefinition, and GetDataSetDirectory


No. Review


4.20 Read individual data attributes with cybersecurity With cybersecurity activated, the client reads individual data attributes from data objects in the server. The values are validated by viewing the client results against what is in the server. No. Action

1 Cybersecurity controls in the protocol are enabled. (Otherwise it is same as test case #2)



4 The client will request each data attribute from the server one at a time as possible. The values on the client will be inspected from the packet capture.

5 The data object values will be dumped off the server using the tool mentioned above.

No. Review

1 The values from the packet capture being received from the client will be compared against the data object values on the server dumped from memory.

4.21 Client reads complete data objects with cybersecurity With cybersecurity activated, the client reads complete data objects in the server. The values are validated by viewing the client results against what is in the server. No. Action

1 Cyber security controls in the protocol are enabled. (Otherwise it is the same as test case #3)






No. Review


4.22 Client sets individual data attribute with cybersecurity With cybersecurity activated, the client sets an individual data attribute in the server. The values are validated by viewing the client results against what is in the server. No. Action



3 The client will send a request to set an individual data attribute on the server one at a time for all applicable data attributes.


No. Review


4.23 Client receives the data objects with cybersecurity With cybersecurity activated, the client receives the data objects in a dataset. The values are validated by viewing the client results against what is in the server.


No. Action





No. Review


4.24 Client issues control commands with cybersecurity With cybersecurity activated, the client issues control commands. The values are validated by viewing the server results against what was requested by the client. Control command handling, including cancelling a command, is validated. The response of the acceptor to errors is validated. No. Action

1 Cyber security controls in the protocol are enabled.

2 A reference list on client control commands will need to be attained for the protocol.



5 The client will send each known control command to the server one at a time.

No. Review

1 The response via the packet capture will be compared against the value in the memory dump of the data objects on the server and ensure they relate as according to the reference list of client control commands.


5 Next Steps, Phases and Milestones

1. Extend the scope of NEMA funded DER security standards and certification development project by working in collaboration with government and industry partners including: SunSpec Alliance DER security working group, IEEE 1547 standards group, P2030 standards group, IEC TC57 WG15, SEPA SGCC and NIST smart grid program.

2. To gather the consensus of the industry and to work with UL, IEC and other Standard Development organizations (SDOs) to convert this certification procedure document into their template which certification labs can easily use

3. The security controls mentioned in this certification procedure document, doesn’t adhere to Modbus protocol. They are adhered to DNP3, ICCP and 61850. Therefore, we will continue working on these security controls to extend them to Modbus as well because lot of DERs still use Modbus for communication.

4. To work towards making communication protocols and cybersecurity controls, that are used for data and communication information exchanges in DER, an international standard.

5. To ensure that DER have minimum cybersecurity policies, controls and procedure that ensure authentication, authorization, accountability and integrity of the data and communication information exchange

NREL will continue moving forward on this work in Fiscal Year (FY) 2018-2021, provided there is enough research and development funding for the research. The NREL team is planning to collaborate with Sandia National Lab (SNL) and few vendors to accomplish the milestones outlined below. We are hoping that at the end of FY 2021, we will be able to deliver cybersecurity standards specifications for DERs that can be incorporated in any DER device. These standards specifications will be based on the detail and vigorous testing of DER that we will be doing in the Year 2, with the help of SNL. It will also incorporate all the refined specifications that we will gather after testing of DER in Phase 4. The cybersecurity standards specifications for security would be made available to the industry at no cost to enable a foundational cybersecurity posture for DER.

YEAR 1 Phase 1: Assessment of the existing work in DER Security space by government and industry partners. Phase 2: Application of detail test plan on set of DER technologies in a lab environment.

YEAR 2 Phase 3: Determining the gaps in current DER security standards specifications after performing pen-testing Phase 4: Produce a document with refined set of cybersecurity


specifications and test plan

YEAR 3 Phase 5: Incorporation of the refined DER security specifications into the new standard. Phase 6: Making a detail certification process document based on the refined test plan.

In FY 2022, we will follow the UL standard process to make these security standards a certification procedure for all DERs. This means that any vendor needing to certify its DER product, he would follow the refined certification procedure which will be completed by the end of FY 2021.

Certification Procedures for Data and Communication...

Documents

Transcript of Certification Procedures for Data and Communication...