[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments from Cyber Security Working Group liaison to PAP 9
I have reviewed - Energy Interoperation Version 1.0, Committee Specification Draft 01, 26 November 2010. Here are my comments as the Cyber Security Working Group liaison to PAP 9. As I understand it, version 1.0 of the specification does not address security in any meaningful way and the goal of my review is to identify the security approach for version 2. Subsection 5.3 of version 1.0 states The information model in Energy Interoperation 1.0 is just that—an information model without security requirements. Each implementation must determine the security needs (outside the scope of this standard) broadly defined, including privacy (see e.g. OASIS Privacy Management Reference Model [ref]), identity (see e.g. OASIS Identity in the Cloud, OAISIS Key Management Interoperability, OASIS Enterprise Key Management Infrastructure, OASIS Provisioning Services, OASIS Web Services Federation TC, OASIS Web Services Secure Exchange and more) Here are thoughts for addressing security in version 2 of the document. The security for OpenADR/Energy Interoperation can be divided into two broad areas, Communications security and system security. Communications Security The messages exchanged must be protected by security services such as confidentiality, integrity, etc. Honeywell recommends creating a table with the following structure in order to identify the required security requirements for each message type. The communications protection requirements are those defined in the NISTIR 7628 subsection 3.24 - SMART GRID INFORMATION SYSTEM AND COMMUNICATION PROTECTION (SG.SC).
This table depicted above would identify each of the NISTIR communications protection requirements and each of the services/messages to be protected. For each pair the table would indicate: · Required · Optional · Not applicable In addition to the table above, a second table should be created which maps the NISTIR communications protection requirements to the set (potentially an empty set) of WS-SecureConversation mechanisms which are to be used to provide the required protection. This WS-SecureConversation profile would be one method of meeting the security requirements. Additional profiles may be created. System Security The following security concerns are related to OpenADR/Energy Interoperation although they may not be addressed directly in the Energy Interoperation specification. - Range limits: The specification does not contain any reference to limiting or characterizing how much power an entity can consume, shed or generate. This creates an opportunity for a hostile actor to disrupt the markets and possibly the grid by creating transactions that will not/cannot be satisfied. For example, a homeowner may be able to supply 3 KW of power to the grid from solar panels. What prevents the homeowner from tendering an offer to sell 3 MW instead of 3 KW? Larger power producers and consumers typically have trained IT security staff, monitored network intrusion detection and other cyber security mechanisms. Home owners are not expected to have these resources. Thus, an attacker could penetrate a relatively soft home owner system and use it as a conduit to tender offers which cannot be met. This will of course be detected, but not until after the attacker achieves their objective. - Black start: The specifications assume a steady state model. i.e. power and data communications are flowing such that producers and consumers maintain balance. Consider these 3 cases: o Both the power delivery and data networks are down o The power delivery is operational but the data network is not functioning (e.g. a denial of service) o The power delivery is down but the data network is operational (running on UPS) The system (and possibly the protocol) needs to address how the system handles each of the three events above. - Enron like manipulation: It is clear that Enron manipulated the energy market and may have even triggered blackouts. http://www.marketwatch.com/story/enron-caused-california-blackouts-traders-say What system level mechanisms exist to prevent this in the future? What, if any, protocol mechanisms are necessary to support the system level mechanisms. - Certificate revocation: A system as large as the smart grid, operating for many years will certainly experience cases in which certificates will need to be revoked. Where is this addressed within the system? - Grid wide clock synchronization: A significant portion of the market supported by energy Interoperation relies upon a consistent time across the system. What mechanisms exist to ensure that all entities have a consistent time source? What processes occur if an entity receives a message with a time stamp which is significantly different than the local time? Tom Markham Sr. Principal Engineer Technology Integration & Prototyping Honeywell Labs, MN10-112A 1985 Douglas Dr Golden Valley, MN 55422-3935 Desk 763 954-6840 Mobile 763 218-8354 tom.markham@honeywell.com | |||||||||||||||||||||||||||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]