OASIS Energy Interoperation TC

  • 1.  Comments from Cyber Security Working Group liaison to PAP 9

    Posted 12-21-2010 14:47
    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-trade
    rs-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




  • 2.  RE: Comments from Cyber Security Working Group liaison to PAP 9

    Posted 12-21-2010 15:26

    Thanks Tom,

    I’m sure this will generate some good discussion in the committee. I appreciate your input.

    David Holmberg

    From: Markham, Tom [mailto:Tom.Markham@honeywell.com]
    Sent: Tuesday, December 21, 2010 9:47 AM
    To: energyinterop-comment@lists.oasis-open.org
    Subject: [energyinterop-comment] 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).

    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