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).
Communications protection requirements
Message type
Communications partitioning
Information Remnants
Denial-of-Service Protection
Resource Priority
Etc.
EiRegisterParty
Required
Required
optional
NA
EiRequestRegistration
Etc.
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