req rgq teis ir wgq edm111307w1 by zn4qok8

VIEWS: 4 PAGES: 36

									   NORTH AMERICAN ENERGY STANDARDS BOARD RESPONSE
                               TO THE

                SANDIA NATIONAL LABORATORIES
                 SURETY ASSESSMENT REPORT OF THE
 NAESB INTERNET ELECTRONIC TRANSPORT AND RELATED STANDARDS


                      June October 310, 2007

                            Prepared by

    NAESB WGQ Electronic Delivery Mechanisms Subcommittee
NAESB Retail Gas and Retail Electric Quadrant Information Requirement
                                and
       Technical Electronic Implementation Subcommittees
Executive Summary:
This document was prepared by the North American Energy Standards Board (NAESB) Wholesale Gas
Quadrant (WGQ) Electronic Delivery Mechanisms (EDM) Subcommittee and the Retail Electric Quadrant
(REQ)/Retail Gas (RGQ) Information Requirements (IR) subcommittee and Technical Electronic
Implementation Subcommittee (TEIS) of NAESB in response to the surety assessment prepared by the
Sandia National Laboratories in 2006.


Many thanks go to the chairs of the above subcommittees and contributors to this report, without whose
contributions, this report would not be possible.
   George Behr             Energy Services Group
                            Chair, RGQ TEIS Subcommittee
   Christopher Burden      Williams Gas Pipeline
                            Co-Chair, WGQ EDM Subcommittee
   Jesse Cline             EC Power
                            Contributor, WGQ EDM Subcommittee
   Julie Fortin            MidAmerican Energy
                            Contributor, WGQ EDM Subcommittee
   Dan Rothfuss            Duke Energy
                            Contributor, RGQ TEIS Subcommittee
   Leigh Spangler          Latitude Technologies
                            Co-Chair, WGQ EDM Subcommittee
   Mike Stender            El Paso Pipe Line Company
                            Contributor, WGQ EDM Subcommittee
   Barbara Wise            Baltimore Gas and Electric
                            Contributor, REQ TEIS Subcommittee



Sandia National Laboratories (Sandia), under a project funded by the U.S. Department of Energy,
performed a surety assessment of the NAESB Internet Electronic Transport (Internet ET) standards,
version 1.8. The surety assessment was undertaken as an independent analysis of the NAESB Internet
ET standards and related NAESB documents, by the Sandia Information Design Assurance Red Team
(IDART). The assessment provided recommendations on the security of the electronic commerce
guidelines for conducting business with emphasis on the use of the Internet.

The surety assessment had 27 findings, categorized in the surety assessment as:
    7.1   Recommendations to address areas of opportunity for an attacker within the guidelines set forth
          by the security standards (20 findings)
    7.2   Recommendations for NAESB principles (1 finding)
    7.3   Recommendations for miscellaneous and format/ layout of NAESB manual/material (6 findings)

In reading the NAESB response to the Sandia surety assessment, the individual responses refer to the
specific findings as cited in the Sandia surety assessment, (for example: Sandia Finding No. 7.1.1, 7.1.2,
etc.). For each Sandia finding, there is a description of their finding, their analysis and their
recommendation. In some instances the text from the Sandia surety assessment report are abbreviated.
Immediately following each Sandia finding the 3 Sandia categories is the NAESB response. The NAESB
responses indicate whether or not NAESB concurs with the Sandia finding, the analysis and the
                                   NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                            Date Prepared: October 31, 2007
                                                                                                      Page 2
recommendation. If the NAESB response is to propose that a NAESB standard is recommendeds need
to be updated or /changed, the NAESB Rresponse will also contains information on how the change
recommendation is to be implemented. If the NAESB response is to decline or defer the actions proposed
in the Sandia recommendation, the rational for the response is included and any In addition, actions to be
taken by NAESB in lieu of implementing a recommendation are also described. in this segment.
Moreover, recommendations declined by NAESB can be classified either as a recommendation restating
an existing standard or a recommendation for which a low cost commercially available and commercially
viable, WGQ/REQ/RGQ specific, solution does not exist.



If accepted by the Executive Committees of the REQ/RGQ and WGQ, tOf the 27 findings, NAESB agreed
                                                           1
with the findings and analysis for ???%, (?? findings .) Moreover, NAESB supported ??18 of the
recommendations provided by Sandia in total, and an additional seven of the recommendations in part
(71%). These NAESB responses recommendations will be the basis for these changes to the NAESB
standards that will be put in to be in affect withfor implemented the next either in version 1.9 or future
                                            2
releases of the NAESB quadrant standards , by quadrant. For those recommendations that NAESB is not
planning to implement in a future release, they can be classified either as a recommendation restating an
                  3
existing standard or a recommendation for which a low cost commercially available and commercially
                                                         4
viable, WGQ/REQ/RGQ specific, solution does not exist .

NAESB appreciates the effort that Sandia through its representatives (David Duggan, Phillip Campbell,
Annie McIntyre, Aura Morris and Charles Marrow) and the Department of Energy (Christopher Freitas)
expended to improve the NAESB standards used by the North American Energy industry to move
information across the Internet. Our industry relies on the Internet as key a major way to facilitator ofe
communication between trading partners. The standards that govern NAESB’s communication protocols
are critical to ensuring security, performance, reliability and interoperability. The public-private partnership
forged between NAESB and the Department of Energy has provided numerousseveral benefits to the
North American energy industry, both in the past as well and in the improvements resulting from this
report.as this report, and the actions that NAESB has taken as result.




1 For finding 7.2.6, GISB did not agree with the finding, the analysis or the recommendation.             GISB     Formatted: Highlight
agreed with all other findings and analysis.
2 The formatting recommendations for findings 7.4.1, 7.4.2 and 7.4.3 will be evaluated for inclusion in
future versions.
3The “restatement of a standard” recommendations for findings 7.2.3, 7.2.4, 7.2.7, 7.3.6 and 7.3.7 were
not supported by GISB.
4 A low cost commercially available solution is unavailable for the recommendations for findings 7.1.4
7.1.11, 7.1.12, 7.3.5 and 7.4.3 and the recommendations were not supported by GISB.

                                     NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                              Date Prepared: October 31, 2007
                                                                                                        Page 3
                  NAESB Response to the 2006 Sandia Surety Assessment


7.1.1 Versioning of software and protocols
       Sandia Finding: Recommended versions of software and protocols are addressed in several
       places in the standard. For example, Standard 4.3.61 states “Data communications for Customer
       Activities Web sites should utilize 128-bit Secure Sockets Layer (SSL) encryption. There are also
       specific technical requirements for workstations listed in Appendix B.

       Sandia Analysis: Specifically requiring versions of software or protocols creates the risk that
       these versions may become outdated or ineffectual before the standard is revised. It also leaves
       open the possibility that some necessary applications or protocols may not be addressed. If either
       of these occurs, vulnerable versions of software or protocols may be allowed by the standard. An
       attacker could take advantage of these vulnerabilities, or an insider could negotiate using a
       vulnerable version of an application and then exploit that vulnerability.

       Sandia Recommendation: Where required versions must be specifically noted, it should be
       stated that the most current versions of applications and protocols are required, along with the
       latest patches. NAESB standards do not enumerate specifics. Refer to a well-known standards
       organization such as SANS6 or NIST7.

       NAESB Response: We concur with the Sandia finding, analysis and recommendation.NAESB
       has determined that the The Internet ET document only contains version specifications for the
       PGP and HTTP. The version of PGP is a minimum version set in order to ensure compatibility
       with the OpenPGP product specified as the primary encryption product to be used. A note will be
       added that newer versions of the PGP proprietary product are encouraged. In addition, we will
       add a standard instructing the Technical subcommittees of the RXQ and WGQ to review and
       update the IET specification prior to each publication. The following are the recommended
       changes to the Internet ET manual:


NAESB INTERNET ET MANUAL, VERSION 1.8, Page 13 (yellow, underlined denotes
addition to existing manual language; yellow, strike-through denotes deletion from
existing manual language)

Security

NAESB Internet ET establishes several security measures as standards to ensure a minimum
level of confidence in conducting business over the Internet, and to provide uniformity in the
implementation of security. Four security concepts, often referred to by the acronym PAIN, are
vital to protecting Internet ET packages:
     Data Privacy
     Authentication
     Data Integrity
     Non-repudiation
                                                                                                              Formatted: No underline
Data Privacy and Encryption

Privacy is the assurance to an entity that no one can read a particular piece of data except the
receiver(s) explicitly intended. Data privacy is accomplished by encrypting payload files.
Internet ET allows encryption using:
                                  NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                           Date Prepared: October 31, 2007
                                                                                                     Page 4
                    NAESB Response to the 2006 Sandia Surety Assessment


                                                          PGP 2.6 (minimum) or higher (strongly               Formatted: Not Highlight
 OpenPGP, defined by (IETF RFC 2440) with
                                                    OR    encouraged), with RSA keys can be                   Formatted: Not Highlight
 modifications described in this specification
                                                          used on a mutually agreed basis


NAESB WGQ QEDM MANUAL, VERSION 1.8, Page 87 (yellow, underlined denotes
addition to existing manual language; yellow, strike-through denotes deletion from
existing manual language)



Appendix B - MINIMUM TECHNICAL CHARACTERISTICS AND GUIDELINES FOR
THE DEVELOPER AND USER OF THE CUSTOMER ACTIVITIES WEB SITE

Browser Characteristics (includes defined NAESB WGQ current versions):
      Features as supported by the latest Generally Available (GA) versions of both
                  5                        3
      Netscape® and Internet Explorer® within 9 months of such GA version becoming
      available, including -
              Frames & Nested Frames
              Tables & Nested Tables
              HTML
              Cookies
              JavaScript
              SSL 128-bit RSA Encryption
              Style Sheets

       Plug-ins (GA versions within 9 months of such GA versions becoming available)
              JAVA®
              ActiveX® 4 (Plug-in for Netscape®)
              Adobe Acrobat Reader® 5
              Systems Incorporated
                                                         6
              Independent Computer Architecture (ICA®) - Protocol used for remote control
              access to an application

Operating Systems:



       5   Netscape® is a registered trademark of Netscape Communications Corp.

       3   Internet® Explorer is a registered trademark of Microsoft Corporation.

       4   ActiveX® is a registered trademark of Microsoft Corporation.

       5   Adobe®, Acrobat®, and Reader® are registered trademarks of Adobe.

       6   ICA® is a registered trademark of Citrix Systems Inc.

                                  NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                           Date Prepared: October 31, 2007
                                                                                                     Page 5
                    NAESB Response to the 2006 Sandia Surety Assessment

        Operating systems on a client workstation should be multithreaded, and pre-emptive                      Formatted: Not Highlight
        and should be the latest, stable version and service pack available as allowed in NAESB                 Formatted: Not Highlight
        WGQ appendices B and C.                                                                                 Formatted: Not Highlight



NAESB INTERNET ET MANUAL, VERSION 1.8, Page 20 (yellow, underlined denotes
addition to existing manual language; yellow, strike-through denotes deletion from
existing manual language)
10.3.x26 The Internet ET manual should be reviewed and updated for technology changes by                        Formatted: Not Highlight
         the WGQ EDM and REQ/RGQ TEIS subcommittees,priorsubcommittees, prior to the                            Formatted: Underline, Not Highlight
         publication of the WGQ or the REQ/RGQ Standards manual. This review should be
         accomplished in sufficient time for review by the respective Executive Committees
         prior to publication.
                                                                                                                Formatted: No underline




7.1.2 General Network and System Security
        Sandia Finding: Minimum required security controls are discussed throughout the standards and
        vary in topic. There is no concise list of minimum network and security controls listed for trading
        partners.
        Sandia Analysis: Without minimum required controls, an unsecured system or network at a
        trading partner site can affect all parties engaged in transactions with that partner and effect
        transaction outcomes. According to NAESB standards, most security aspects are left up to the
        trading partner. However, the standards aim to create a secure process and environment for
        transactions. To accomplish this, minimum security for trading partners must be defined in a
        comprehensive manner. Unsecured systems and networks allow for a large variety of negative
        consequences such as altered or lost data, access to systems, denial of service, and altered
        transactions. These consequences can have measurable business effects such as loss of
        business, negative public opinion, loss of strategic partners, downtime, and divulged corporate
        information.
        Sandia Recommendation: A standard should be created that requires trading partners to use an
        accepted set of security guidelines, such as those developed by SANS or NIST, to secure their
        systems and network. Currently-stated NAESB security controls offer only minimal protection if
        basic system and network security are not addressed. Established guidelines exist today and can
        be used as a reference and recommendation for trading partners in securing their systems. These
        guidelines are regularly updated and maintained to reflect changing threats found in the Internet.
        NAESB should require adherence to these guidelines in the security portion of NAESB’s
        standards.
        NAESB Response: We concur with the Sandia finding, analysis and recommendation.
        WeNAESB will add additional text in the manual that suggests using the SANS and NIST
        guidelines for reference material. The following are the recommended changes to the NAESB
        Internet ET manual:



NAESB INTERNET ET MANUAL, VERSION 1.8, Page 55 (yellow, underlined denotes
addition to existing manual language; yellow, strike-through denotes deletion from
                                    NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                             Date Prepared: October 31, 2007
                                                                                                       Page 6
                         NAESB Response to the 2006 Sandia Surety Assessment


existing manual language)


APPENDIX B – FREQUENTLY ASKED QUESTIONS
Q1: How many times do I attempt to send an Internet ET package unsuccessfully before I notify my                                             Formatted: Underline
     partner? ............................................................................................. Error! Bookmark not defined.55
Q2: Do I send my ‘gisb-acknowledgement-receipt’ before or after I decrypt the Internet ET package?Error!
     Bookmark not defined.55
Q3: What cryptographic algorithms should we use or not use?................ Error! Bookmark not defined.55
Q4: Use of ‘time-c-qualifier’ across quadrants. We understand that the retail quadrants require the ‘time-
     c-qualifier’ for ‘gisb-acknowledgement-receipt’, while the WGQ does not require this data element. If
     we participate in multiple quadrants, which standard do we use? .... Error! Bookmark not defined.56
Q5: NAESB EDM / AS2 Compatibility. What is the status of NAESB compatibility with AS2? ............ Error!
     Bookmark not defined.56
Q6: Atomic Clock Synchronization. How often do we need to synchronize our system clocks with an
     atomic clock? .................................................................................... Error! Bookmark not defined.56
Q7: Internet Continuous Connection. As an end user, do I need a continuously-connected internet Web
     server to participate in the Internet ET in the energy industry, or can I just use a dial-up connection to
     my ISP and my favorite shrink-wrapped browser software? ............. Error! Bookmark not defined.56
Q8: Use of ANSI X12.58. If we use ANSI X12.58 encryption do we still need to use OpenPGP or PGP
     encryption? ........................................................................................ Error! Bookmark not defined.56
Q9: What does NAESB recommend for the OpenPGP/PGP descriptive text?Error!                                               Bookmark       not
     defined.56
Q10:What does NAESB say about my organization's security?..................................................................57


 NAESB INTERNET ET MANUAL, VERSION 1.8, Page 57 (yellow, underlined denotes
addition to existing manual language; yellow, strike-through denotes deletion from
existing manual language)


Q10: What does NAESB say about my organization’s security?                                                                                   Formatted: Not Highlight

        A: NAESB Internet ET participants are encouraged to maintain their system security in such a
        manner that reduces the risk of unauthorized/malicious activity. However, NAESB does not dictate
        overall security requirements for individual companies. For further information on general security
        guidelines please reference the SANS (www.SANS.com) or NIST (www.NIST.com) websites.                                                 Formatted: Not Highlight
                                                                                                                                             Formatted: Not Highlight
                                                                                                                                             Formatted: Not Highlight
7.1.3 Protection of Sensitive Information                                                                                                    Formatted: Not Highlight

          Sandia Finding: Protection of sensitive information such as PGP private keys, other private keys,
          the Trading Partner Agreement (TPA), and Technical Exchange Worksheets does not appear to
          be addressed by the standard.
          Sandia Analysis: In the Internet Electronic Transport (IET) document (page 194[sic page 45]), it
          is stated that “utmost care” is needed in the protection of private keys. The phrase is not
          actionable and is interpreted differently at each organization.
          Sandia Recommendation: Each trading partner should protect these sources of information as
          company proprietary. Destruction of these documents and electronic information should also be
          addressed in the standard.
                                              NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                                       Date Prepared: October 31, 2007
                                                                                                                 Page 7
                  NAESB Response to the 2006 Sandia Surety Assessment

       NAESB Response: We concur with the Sandia finding, analysis and recommendation. NAESB
       agrees that private keys are sensitive information. In addition to the changes indicated below,
       please r Refer to Sandia 7.1.5 NAESB Response for changes relating to private key distribution
       and sharing. The following are the recommended changes to the NAESB Internet ET manual:
                                                                                                              Formatted: Font: 10 pt



NAESB INTERNET ET MANUAL, VERSION 1.8, Page 20 (yellow, underlined denotes addition to
existing manual language; yellow, strike-through denotes deletion from existing manual language)
                                                                                                              Formatted: Font: 10 pt, Not Highlight
10.3.x27 The information contained in the Technical Exchange Worksheet and Trading Partner
         Agreement as well as trading partner digital signature and encryption keys should be secured
         and considered ‘company proprietary’ or ‘company confidential’ information...                        Formatted: Font: 10 pt
                                                                                                              Formatted: Indent: Left: 0"
                                                                                                              Formatted: Font: 10 pt
NAESB WGQ TRADING PARTNER AGREEMENT, VERSION 1.8, Exhibit Section, Page 2 (
underlined denotes addition to existing manual language; strike-through denotes deletion from
existing manual language)

                                            EXHIBIT ___
                                                                                                              Formatted: Font: 10 pt


           ELECTRONIC DATA INTERCHANGE TRADING PARTNER AGREEMENT
                                                                                                              Formatted: Font: 10 pt

DATED ___________________
TO BE EFFECTIVE ____________________ (date)


3.     Communication Specifics:
       Company Name: ________________________________________________________
       EDI Contact Phone Number: ______________________________________________
       Provider Name: _________________________________________________________
       Receipt Computer URL (include host name or IP address, any non standard port, directory         and
program name as necessary): __________________________________
       Basic Authentication Userid: __(to be sent separately)___________________________                      Formatted: Font: 10 pt, Underline

       Basic Authentication Password: __(to be sent separately)________________________                       Formatted: Font: 10 pt

       HTTP to/from Tag: ______________________________________________________                               Formatted: Font: 10 pt, Underline
                                                                                                              Formatted: Font: 10 pt
       Is the “transaction set” supported in the HTTP envelope (Yes/No)? ________________


       Company Name: ________________________________________________________
       EDI Contact Phone Number: ______________________________________________
       Provider Name: _________________________________________________________

                                  NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                           Date Prepared: October 31, 2007
                                                                                                     Page 8
                             NAESB Response to the 2006 Sandia Surety Assessment

       Receipt Computer URL (include host name or IP address, any non standard port, directory                                                           and
program name as necessary): __________________________________
            Basic Authentication Userid: (to be sent separately)______________________________                                                                    Formatted: Not Highlight

            Basic Authentication Password: (to be sent separately)___________________________                                                                     Formatted: Font: 10 pt

            HTTP to/from Tag: ______________________________________________________                                                                              Formatted: Not Highlight
                                                                                                                                                                  Formatted: Font: 10 pt
            Is the “transaction set” supported in the HTTP envelope (Yes/No)? ________________


[Parties should execute a separate Exhibit for each different URL.]
                                                                                                                                                                  Formatted: Indent: Left: 0"




7.1.4 Standards Compliance
            Sandia Finding: Throughout the standard, “should” is currently used as a directive for
            requirements. “Should” implies a recommendation as opposed to a requirement; Cambridge
            Online Dictionary states that “should” is used to indicate “what is the correct or best thing to do.”
            Sandia Analysis: Stating that something “should be done” is comparable to stating that it “is
            recommended,” not that it is required. This allows users to ignore the recommendations if they so
            choose. The word “should” is properly used in the Principles, where it is expected to be used. Use
            of the word “should” in standards suggests that “should” is used as though it denotes “must.”
            Sandia Recommendation: Language throughout the standard should be precise. If a particular
            action is required to be compliant to the standard, it should be stated that it is required, that a user
            “must” conform to it. Definitions of the terms “should”, “must”, “required”, “may”, and other
            associated words should be developed, documented, and implemented within the standards
            documents.
            NAESB Response: Over the past several years NAESB has discussed the usage of the
            subjective words “should”, “may”, etc has been discussed. In 2006, the WGQ received an official
            request asking for the interpretation of these words. In agreement with the WGQ EC, the Internet
            ET manual will post a reference (link) to the FAQ document posted on the WGQ NAESB website.
            The following is the actual text from that documentNAESB’s Certificate of Incorporation - Article II,
            Section 1 states, “The objectives and purpose of NAESB are to propose and adopt voluntary
            standards and model business practices designed to promote more competitive and efficient
            natural gas and electric service.” NAESB’s use of terms like “should” reflects NAESB’s objective
            to adopt voluntary standards and model business practices. Additional references to the meaning
            of these particular words may be found on the NAESB website.
            :
                                                                                                                                                                  Formatted: Font: 10 pt
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 55 (yellow, underlined denotes addition to
existing manual language; yellow, strike-through denotes deletion from existing manual language)


APPENDIX B – FREQUENTLY ASKED QUESTIONS

Q1: How many times do I attempt to send an Internet ET package unsuccessfully before I notify my                                                                  Field Code Changed
    partner? ............................................................................................................................................... 55
                                                     NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                                              Date Prepared: October 31, 2007
                                                                                                                        Page 9
                             NAESB Response to the 2006 Sandia Surety Assessment

Q2: Do I send my ‘gisb-acknowledgement-receipt’ before or after I decrypt the Internet ET package? ..... 55
Q3: What cryptographic algorithms should we use or not use?.................................................................. 55
Q4: Use of ‘time-c-qualifier’ across quadrants. We understand that the retail quadrants require the ‘time-
     c-qualifier’ for ‘gisb-acknowledgement-receipt’, while the WGQ does not require this data element. If
     we participate in multiple quadrants, which standard do we use? ...................................................... 56
Q5: NAESB EDM / AS2 Compatibility. What is the status of NAESB compatibility with AS2? .................. 56
Q6: Atomic Clock Synchronization. How often do we need to synchronize our system clocks with an
     atomic clock? ...................................................................................................................................... 56
Q7: Internet Continuous Connection. As an end user, do I need a continuously-connected internet Web
     server to participate in the Internet ET in the energy industry, or can I just use a dial-up connection to
     my ISP and my favorite shrink-wrapped browser software? ............................................................... 56
Q8: Use of ANSI X12.58. If we use ANSI X12.58 encryption do we still need to use OpenPGP or PGP
     encryption? .......................................................................................................................................... 56
Q9: What does NAESB recommend for the OpenPGP/PGP descriptive text? .......................................... 56
Q10:What does NAESB say about my organization's security?..................................................................57
Q11: Why do NAESB WGQ Standards use discretionary verbs such as “should” instead of non-
discretionary verbs such as “shall”?............................................................................................................57


                                                                                                                                                                 Formatted: Font: 10 pt
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 57 (yellow, underlined denotes addition to
existing manual language; yellow, strike-through denotes deletion from existing manual language)


Q11: Why do NAESB WGQ Standards use discretionary verbs such as “should” instead of non-
discretionary verbs such as “shall”?
         A:     Please  see    the    following                          NAESB            WGQ           link      for       current         information.
         http://www.naesb.org/wgq/default.asp                                                                                                                    Field Code Changed



Note: For ease in reading of this report only, the following shows the content of the above referenced link.
(not to be included as text in any NAESB manual)


                             Frequently Asked Questions Concerning NAESB WGQ Standards                                                                           Formatted: Font: 10 pt

                              Q: Why do NAESB WGQ Standards use discretionary verbs such as “should”
                                 instead of non-discretionary verbs such as “shall”?


                              A: NAESB’s Certificate of Incorporation - Article II, Section 1 states, “The objectives
                                 and purpose of NAESB are to propose and adopt voluntary standards and model
                                 business practices designed to promote more competitive and efficient natural
                                 gas and electric service.” NAESB’s use of the term “should” reflects NAESB’s
                                 objective to adopt voluntary standards and model business practices.


                              Q: How do NAESB WGQ Standards become mandatory?


                              A: Entities regulated by a regulatory agency incorporating or adopting the “voluntary”
                                 NAESB standards into its regulations should realize that even though
                                                    NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                                             Date Prepared: October 31, 2007
                                                                                                                      Page 10
                     NAESB Response to the 2006 Sandia Surety Assessment

                          discretionary verbs such as “should” and “could” are in the standards, NAESB
                          standards, once incorporated/adopted, become standards required to be followed
                          by the applicable regulated entities. For example, the Federal Energy Regulatory
                          Commission (FERC) regulates interstate natural gas pipelines. Through the
                          regulatory process, FERC adopts some, but not all, NAESB WGQ Standards and
                          such pipelines are required to abide by these standards.


                      Q: How should discretionary verbs within NAESB WGQ Standards be interpreted for
                         non-regulated entities?


                      A: Non-regulated entities may voluntarily implement some or all of the NAESB WGQ
                         Standards.    In effect, such entities voluntarily decide to adopt NAESB’s
                         standardized business practices and incorporate them into their own processes
                         as business rules; however, non-regulated entities are expected to consistently
                         comply with the NAESB WGQ Standards to the extent necessary to ensure that
                         Transportation Service Providers are able to maintain compliance with the FERC
                         regulations mandating the NAESB requirements.

7.1.5 Sharing of Keys
          Sandia Finding: The Internet ET (IET) Standard is ambiguous about the sharing of public keys.
          Sandia Analysis: The IET Standard states “The Private Key must be known only to the company
          that generated it” (IET page 194, emphasis added), but in the next paragraph the Standard states
          “Private keys are not typically exchanged with trading partners. In the event that a Private Key
          needs to be exchanged, the exchange should occur in a secure manner such as postal or courier
          mail” (ibid, emphasis added). These two statements are inconsistent.
          Sandia Recommendation: These statements should be revised to display consistency. There
          should never be a reason to compromise a private key by exchanging it with another entity. If, for
          some business reason it is true that private keys need to be exchanged at some point, then the
          first statement should be updated to reflect that.
          NAESB Response: We concur with the Sandia finding, analysis and recommendationNAESB
          agrees that the private key should be protected. Please also refer to Sandia 7.1.3 NAESB
          Response for changes relating to private key protection. The following are the recommended
          changes to the NAESB Internet ET manual:
                                                                                                                 Formatted: Font: 10 pt
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 19 (yellow, underlined denotes addition to
existing manual language; yellow, strike-through denotes deletion from existing manual language)

10.3.17     Encryption keys should be self-certified. The exchange of Public keys should be completed
            electronically such as via email. The exchange of Private keys, if applicable, should be done in     Formatted: Font: 10 pt, Not Highlight
            a secure manner such as via postal or courier mail. Key policies, including key exchange             Formatted: Font: 10 pt
            policies should be communicated to trading partners.


                                                                                                                 Formatted: Font: 10 pt
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 45 (yellow, underlined denotes addition to
existing manual language; yellow, strike-through denotes deletion from existing manual language)



                                     NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                              Date Prepared: October 31, 2007
                                                                                                       Page 11
                    NAESB Response to the 2006 Sandia Surety Assessment

Understanding OpenPGP and PGP

Pretty Good Privacy (PGP) is the name of the chosen security application. OpenPGP is the Internet
Engineering Task Force (IETF) standard version of PGP that excludes all patented algorithms, allowing
free commercial use of the standard. Both OpenPGP and PGP use a Public Key/Private Key pair to
secure and sign files for transfer. The Private Key must be known only to the company that generated it.
The Public Key counterpart is shared with trading partners.

Each company must generate its Public Key and Private Key pair. The RSA key generation algorithm
should be chosen for versions of PGP that offer alternatives. Implementers of OpenPGP should choose
DSA and El Gamal when creating their key pair. The Public Keys should be distributed electronically to
the company’s trading partners. Private keys are not typically exchanged with trading partners. In the         Formatted: Font: 10 pt, Not Highlight
event that a Private Key needs to be exchanged, the exchange should occur in a secure manner such as
postal or courier mail.                                                                                        Formatted: Font: 10 pt
                                                                                                               Formatted: Font: 10 pt, Not Highlight
You should never divulge your Private Key to another partymust use the utmost care in protecting your
Private Key. If an un-trusted party has your Private Key, your security is compromised. It is                  Formatted: Font: 10 pt
recommended that a key size of 1024 be chosen when generating the key pair. This provides a
significantly secure transaction.

When a company wishes to send transactions to its trading partner, it will use the partner’s Public Key to
encrypt the file. Encryption provides data privacy. Only the Private Key counterpart can decrypt this file.

When the sending party encrypts the file, it also uses its own Private Key to ‘sign’ the transaction. The
receiving party can use the Sender’s Public Key to verify the signature. The digital signature provides
non-repudiation.




7.1.6 Receiver Non-Repudiation
        Sandia Finding: The Non-repudiation for the Receiver is optional.
        Sandia Analysis: A digital signature for the Sender is optional, according to the Standard (IET
        page 171 (see also RXQ.0.2.56, part C, page 163)). That is, trading partners may agree for the
        Sender to send a package without including a digital signature. As a result, the Receiver is unable
        subsequently to prove, based solely on the material provided by adherence to the Standard that a
        given package was sent by a given Sender.
        Sandia Recommendation: Require digital signatures on all documents transmitted between
        trading partners.
        NAESB Response: NAESB agrees with the recommendation and has updated the standards
        language to reflect support of digital signatures on all documents transmitted between trading
        partnersWe concur with the finding, analysis and recommendation. The following are the
        recommended changes to the NAESB Internet ET manual:The NAESB Internet ET manual has
        been modified to reflect support of Sandia’s research.
                                                                                                               Formatted: Font: 10 pt
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 13 (underlined denotes addition to existing
manual language; strike-through denotes deletion from existing manual language)                                Formatted: Font: 10 pt

                                                                                                               Formatted: Font: 10 pt, Font color: Black,
If trading partners mutually agree to use signed Receipts, then the application would additionally attach a    Strikethrough
digital signature to the Receipt.
                                   NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                            Date Prepared: October 31, 2007
                                                                                                     Page 12
                     NAESB Response to the 2006 Sandia Surety Assessment

                                                                                                                  Formatted: Font: 10 pt
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 14 (underlined denotes addition to existing                           Formatted: Font: 10 pt
manual language; strike-through denotes deletion from existing manual language)
                                                                                                                  Formatted: Font: 10 pt, No underline

Non-Repudiation
                                                                                                                  Formatted: Font: 10 pt
Non-repudiation is the assurance to an entity that a party cannot deny having engaged in the transaction,
or having sent the electronic message. It is like a Notary seal. The Sender of a file may optionally will         Formatted: Font: 10 pt, Strikethrough
include in the Internet ET package a digital signature that is created using their Private Key. The Receiver      Formatted: Font: 10 pt
knows the Sender is legitimate by decoding the digital signature using the Sender’s Public Key.
                                                                                                                  Formatted: Font: 10 pt, Underline
                                                                                                                  Formatted: Font: 10 pt

NAESB INTERNET ET MANUAL, VERSION 1.8, Page 15 (underlined denotes addition to existing                           Formatted: Indent: Left: 0"
manual language; strike-through denotes deletion from existing manual language)                                   Formatted: Font: 10 pt


Definitions:

10.2.1    ‘Internet ET Testing’. Testing electronic packages between trading partners includes testing of:
          A) Connectivity; B) Encryption/Decryption; and C) Digital signatures where appropriate (4.2.20).        Formatted: Font: 10 pt, Strikethrough
                                                                                                                  Formatted: Font: 10 pt
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 22 (underlined denotes addition to existing
manual language; strike-through denotes deletion from existing manual language)


ELECTRONIC TRANSPORT LIFE CYCLE

The life cycle of an Electronic Package using Internet ET is described below:

                     Sender                                                    Receiver

    Collects payload data to be sent                                                                             Formatted: Indent: Left: 0", Bulleted +
    Encrypts payload                                                                                             Level: 1 + Aligned at: 0.25" + Tab after: 0.5"
    Prepares digital signature if necessary                                                                      + Indent at: 0.5"
    Uses browser to create Electronic Package                                                                    Formatted: Bullets and Numbering
     multi-part HTTP Request with header data
                                                                                                                  Formatted: Strikethrough
     elements and payload.
                                                                                                                 Formatted: Indent: Left: 0", Bulleted +
     Uses HTTP POST to send the electronic
     package to the Receiver                                                                                     Level: 1 + Aligned at: 0.25" + Tab after: 0.5"
                                                                                                                  + Indent at: 0.5"
                                                             Receives the HTTP Request on their Web/HTTP
                                                              Server                                              Formatted: Bullets and Numbering
                                                             Validates Sender information from HTTP Request      Formatted: Indent: Left: 0", Bulleted +
                                                              Header data elements and payload                    Level: 1 + Aligned at: 0.25" + Tab after: 0.5"
                                                             **Decrypts payload file                             + Indent at: 0.5"
                                                             Prepares Receipt
                                                                                                                  Formatted: Bullets and Numbering
                                                             Checks digital signatures if necessary
                                                                                                                  Formatted: Strikethrough
                                                                                                                  Formatted: Indent: Left: 0"




If trading partners mutually agree to use signed Receipts, then the application would
                                      NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                               Date Prepared: October 31, 2007
                                                                                                        Page 13
                   NAESB Response to the 2006 Sandia Surety Assessment

additionally attach a digital signature to the Receipt.



NAESB INTERNET ET MANUAL, VERSION 1.8, Page 23 (underlined denotes addition to
existing manual language; strike-through denotes deletion from existing manual
language)


ANATOMY OF AN INTERNET ET PACKAGE

An Internet ET package consists of the following sections:
                                                                                                              Formatted: Indent: Hanging: 0.5", Bulleted +
      Envelope header.    This section contains the envelope information needed to                           Level: 1 + Aligned at: 0.25" + Tab after: 0.5"
       communicate who the Sender and Receiver are, as well as other envelope information.                    + Indent at: 0.5"
                                                                                                              Formatted: Bullets and Numbering
      Payload. This section contains the payload file. Internet ET allows for only one payload
       file per package.
                                                                                                              Formatted: Strikethrough
      Digital Signatures. If used, theThe package should contain a section that is the digital
                                                                                                              Formatted: Underline
       signature.

                                                                                                              Formatted: Font: Bold
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 23 (underlined denotes addition to
existing manual language; strike-through denotes deletion from existing manual
language)
                                                                                                              Formatted: Strikethrough
If trading partners agree to implement signed receipts, then the The sending party must include               Formatted: Underline
the ‘receipt-security-selection’ data element in the posted data. The receiving party must
digitally sign the ‘gisb-acknowledgement-receipt’ and encapsulate the ‘gisb-acknowledgement-
receipt’ and digital signature body parts within a MIME envelope with a ‘content-type’ of
‘application/pgp-signature’.


NAESB INTERNET ET MANUAL, VERSION 1.8, Page 30 (underlined denotes addition to
existing manual language; strike-through denotes deletion from existing manual
language)

Server Response

The Server will send a ‘gisb-acknowledgement-receipt’ in the HTTP Response to the Client
before dropping the Client’s connection. If the transacting parties agree to use signed receipts,             Formatted: Strikethrough
theThe Server applies a digital signature to the ‘gisb-acknowledgement-receipt’ and                           Formatted: Underline
encapsulates the entire package in a MIME envelope of ‘content-type: application/pgp-
signature’.


NAESB INTERNET ET MANUAL, VERSION 1.8, Page 35 (underlined denotes addition to
                                  NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                           Date Prepared: October 31, 2007
                                                                                                    Page 14
                  NAESB Response to the 2006 Sandia Surety Assessment


existing manual language; strike-through denotes deletion from existing manual
language)


RECEIVING INTERNET ET PACKAGES

General Flow

The following is an example of the steps necessary to receive an Internet ET package:
         1.      Parse multi-part form                                                                      Formatted: Bullets and Numbering
         2.      Validate HTTP Request data elements
         3.      If HTTP Request data elements in error, return appropriate Internet ET
                 standard error code in the HTTP Response data elements
         4.      Save data
         5.      Create ‘gisb-acknowledgement-receipt’
         6.      If using signed Sign receipts, produce a digital signature over the ‘gisb-                 Formatted: Strikethrough
                 acknowledgement-receipt’ created in step 5.                                                Formatted: Underline
                                                                                                            Formatted: Strikethrough
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 37 (underlined denotes addition to
existing manual language; strike-through denotes deletion from existing manual
language)
                                                                                                            Formatted: Strikethrough
If signed Receipts are used, the The ‘gisb-acknowledgement-receipt’ including the                           Formatted: Underline
‘multipart/report’ envelope, is digitally signed, producing an ‘application/pgp-encrypted’ body
part. Both the ‘multipart/report’ ‘gisb-acknowledgement-receipt’ and the ‘application/pgp-
signature’ body parts are placed in a ‘multipart/signed’ envelope and the entire package is
returned to the Sender.



NAESB INTERNET ET MANUAL, VERSION 1.8, Page 41 (underlined denotes addition to
existing manual language; strike-through denotes deletion from existing manual
language)
                                                                                                            Formatted: Strikethrough
Additionally, trading partners are permitted to use digitally-signed error notifications, if both
parties mutually agree to do so.



NAESB INTERNET ET MANUAL, VERSION 1.8, Page 42, last 2 bullet items (underlined
denotes addition to existing manual language; strike-through denotes deletion from
existing manual language)
                                                                                                            Formatted: Bullets and Numbering
      The first body part contains human readable content in HTML. The second body part
       contains machine readable content in plain text. Additionally, consenting trading                    Formatted: Strikethrough
       partners can mutually agree to digitally sign error notifications.

                                NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                         Date Prepared: October 31, 2007
                                                                                                  Page 15
                   NAESB Response to the 2006 Sandia Surety Assessment

                                                                                                               Formatted: Strikethrough
      If digital signatures are used, theThe multipart/report containing the Error Notification is
                                                                                                               Formatted: Indent: Hanging: 0.5", Bulleted +
       used to create a digital signature body part, identified by a ‘content-type’ of
                                                                                                               Level: 1 + Aligned at: 0.25" + Tab after: 0.5"
       application/pgp-signature.       Both the multipart/report Error Notification and                       + Indent at: 0.5"
       application/pgp-encrypted digital signature body parts are combined in a                                Formatted: Underline, Strikethrough
       multipart/signed envelope.
                                                                                                               Formatted: Underline
                                                                                                               Formatted: Bullets and Numbering

NAESB INTERNET ET MANUAL, VERSION 1.8, Page 46 (underlined denotes addition to
existing manual language; strike-through denotes deletion from existing manual
language)


Encryption and digital signatures are created using OpenPGP, or on a mutually agreed basis,
PGP version 2.6 or greater. Regardless of encrypting in a manual or automated fashion, it is
essential that the correct Public Key of the trading partner be used to encrypt and just as
essential that the correct Sender’s own Private Key be used to digitally sign the file.
                                                                                                               Formatted: Strikethrough
Digital signatures may also be applied, on a mutually-agreed-upon basis, to the HTTP
Response by the Receiver of the package.

Decryption / Digital Signature Verification

After a package is received and processed by the Receiving Program, it is ready to be
decrypted and have its digital signature verified. Given the correct userID for a trading partner,
OpenPGP/PGP uses the appropriate key pair to encrypt, sign and decrypt. Upon request for
signature verification, the OpenPGP/PGP will return a human-readable descriptive text such as
DUNS number or company name.
                                                                                                               Formatted: Strikethrough
When digital signatures are applied, on a mutually-agreed-upon basis, the The digitally signed
                                                                                                               Formatted: Underline
HTTP Response received by the Sender of the transaction mayshould be verified to ensure
non-repudiation of receipt of the transaction.                                                                 Formatted: Strikethrough
                                                                                                               Formatted: Underline


        – We appear OK – the TPA requires a digital signature – LS 10/02/07

7.1.7 Sender Non-Repudiation
       Sandia Finding: Non-repudiation for the Sender appears to be optional.
       Sandia Analysis: The Standard is not clear on whether or not a digital signature on a receipt
       and/or on an error notification for the Receiver is optional. The “Data Dictionary for Internet ET”
       notes that the value of the “receipt-security-selection” data element is not “Mandatory” but rather
       “Mutually-Agreed-To” (IET page 173). However, the data element does not appear to include an
       option not to use digital signatures (though page 175 suggests that if the partners agree not to use
       digital signatures for receipts, they simply do not include the receipt-security-selection” data
       element “in the posted data”). Elsewhere we read “If trading partners agree to implement signed
       receipts…” (IET page 175 (see also pages 161, 178, and 186)), suggesting that digital signatures
       are indeed optional for receipts. Meanwhile, we read “Additionally, consenting trading partners can
       mutually agree to digitally sign error notifications” (IET page 191 (see also IET page 190), implying

                                   NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                            Date Prepared: October 31, 2007
                                                                                                     Page 16
                      NAESB Response to the 2006 Sandia Surety Assessment

         that trading partners can agree not to digitally sign error notifications. If the Receiver’s use of
         digital signatures is in fact optional, then, as a result, the Sender is unable subsequently to prove,
         based solely on the material provided by adherence to the Standard, that a given receipt or a
         given error notification was sent by a given Receiver.
         Sandia Recommendation: Require digital signatures on all documents transmitted between
         trading partners.
         NAESB Response: We concur with the finding, analysis and recommendation. NAESB aggress
         with the Sandia recommendation. In addition to the proposed changes below, please refer to
         standards manual changes made in Sandia response number 7.1.6. The following are the
         recommended changes to the NAESB Internet ET manual:The NAESB Internet ET manual has
         been modified to reflect support of Sandia’s research. (CB added 7/15) Please refer to standards
         manual changes made in Sandia response number 7.1.6.
                                                                                                                    Formatted: Font: 10 pt
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 24 (underlined denotes addition to existing
                                                                                                                    Formatted: Font: 10 pt
manual language; strike-through denotes deletion from existing manual language)
                                                                                                                    Formatted: Font: 10 pt

Data Dictionary for Internet ET
Business Name       Definition          Format                      Usage*        Condition

receipt-security-   used to request     signed-receipt-             in Request;   used in file transmittal and in
selection           signed receipts     protocol=required,pgp-      MA            posting error notifications       Formatted: Underline, Strikethrough
                                        signature;signed-receipt-
                                        micalg=required,md5


                                                                                                                    Formatted: Highlight
signed-receipt-protocol=required,pgp-signature;signed-receipt-micalg=required,md5 – See
“Format” above – what does this mean?? LS 10/02/07 I believe that this is the actual value that
will be exchanged in the header. I question the need for this field since we are now requiring
signed receipts. To me, this data element indicates whether or not the party is requesting
signed receipts. ??CB 10/04/07 LS 10/18/07 ???




NAESB INTERNET ET MANUAL, VERSION 1.8, Page 30 (underlined denotes addition to
existing manual language; strike-through denotes deletion from existing manual
language)

(Move “receipt-security-selection” data element from ‘Mutually Agreed Upon Data Elements’
section to ‘Required Data Elements, Listed in the Required Order’.)



Required Data Elements, Listed in the Required Order:                                                               Formatted: List 3, Numbered + Level: 1 +
           1.       from                                                                                            Numbering Style: 1, 2, 3, … + Start at: 1 +
                                                                                                                    Alignment: Left + Aligned at: 0.63" + Tab
           2.       to                                                                                              after: 1.13" + Indent at: 1.13"
           3.       version
                                                                                                                    Formatted: Bullets and Numbering
                                      NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                               Date Prepared: October 31, 2007
                                                                                                        Page 17
                    NAESB Response to the 2006 Sandia Surety Assessment

           4.      receipt-disposition-to
           5.      receipt-report-type
           6.      input-format
           7.      input-data
           8.      receipt-security-selection                                                                            Formatted: Underline

Mutually Agreed Upon Data Elements
           9.      transaction-set                                                                                       Formatted: Bullets and Numbering
           10.     receipt-security-selection                                                                            Formatted: Strikethrough, Not Highlight
           11.     refnum                                                                                                Formatted: Underline, Strikethrough
           12.     refnum-orig
                                                                                                                         Formatted: Indent: Left: 0.63"



NAESB INTERNET ET MANUAL, VERSION 1.8, Page 51 (underlined denotes addition to
existing manual language; strike-through denotes deletion from existing manual
language)
                                                                                                                         Formatted: No underline
Internet ET Standard Error Codes and Messages
 Validation Code    Description                        Data Element           Data Element Required or Mutually Agreed

 EEDM100            Missing ‘from’ Common Code From                           required
                    Identifier code
 EEDM101            Missing ‘to’ Common Code           To                     required
                    Identifier
 EEDM102            Missing input format               input-format           required
 EEDM103            Missing data file                  input-data             required
 EEDM104            Missing transaction set            transaction-set        mutually agreed
 EEDM105            Invalid ‘from’ Common Code         From                   required
                    Identifier
 EEDM106            Invalid ‘to’ Common Code           To                     required
                    Identifier
 EEDM107            Invalid input format               input-format           required
 EEDM108            Invalid transaction set            transaction-set        mutually agreed
 EEDM109            No parameters supplied             Parameter string       required
 EEDM110            Invalid ‘version’                  Version                required
 EEDM111            Missing ‘version’                  Version                required
 EEDM112            ‘receipt-security-selection’ not   receipt-security-      mutually agreed                            Formatted: Strikethrough
                    mutually agreed                    selection
 EEDM113            Invalid ‘receipt-security-         receipt-security-      mutually agreedrequired                    Formatted: Strikethrough
                    selection’                         selection
 EEDM114            Missing ‘receipt-disposition-      receipt-disposition-   required                                   Formatted: Underline, Not Strikethrough
                    to’                                to                                                                Formatted: Strikethrough
 EEDM115            Invalid ‘receipt-disposition-to’   receipt-disposition-   required
                                                       to
 EEDM116            Missing ‘receipt-report-type’      receipt-report-type    required
 EEDM117            Invalid ‘receipt-report-type’      receipt-report-type    required
 EEDM118            Missing ‘receipt-security-         receipt-security-      mutually agreedrequired                    Formatted: Strikethrough
                    selection’                         selection
 EEDM119            Mutually agreed element,           Refnum                 mutually agreed                            Formatted: Not Highlight
                    refnum, not present                                                                                  Formatted: Strikethrough
 EEDM120            Mutually agreed element            refnum-orig            mutually agreed
                    refnum-orig not present

                                        NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                                 Date Prepared: October 31, 2007
                                                                                                          Page 18
                    NAESB Response to the 2006 Sandia Surety Assessment


 Validation Code    Description                        Data Element        Data Element Required or Mutually Agreed
 EEDM121            Duplicate refnum received          Refnum              mutually agreed
 EEDM601            Public key invalid                 file itself         required - security
 EEDM602            File not encrypted                 file itself         required - security
 EEDM603            Encrypted file truncated           file itself         required - security
 EEDM604            Encrypted file not signed or       file itself         required - security
                    signature not matched
 EEDM699            Decryption Error                                       required for general decryption errors not
                                                                           specifically identified by OpenPGP or PGP
                                                                           messages or exit codes
 EEDM701            Sending party not associated                           required
                    with Receiving party
 EEDM702            Package file format not                                required when the file format is not recognized by
                    recognized by Receiving                                the receiver (e.g. not expecting 855 or not
                    party                                                  expecting Flat-File or XML)
 EEDM703            Data set exchange not                                  required if the translator does not handle this
                    established for Trading                                exception
                    Partner
 EEDM999            System error                                           required for general system errors to indicate
                                                                           severe errors in processing at the receiving site
 WEDM100            Transaction set sent not           transaction-set     mutually agreed
                    mutually agreed
 WEDM102            ‘receipt-security-selection’ not   receipt-security-   mutually agreed                                      Formatted: Strikethrough
                    mutually agreed                    selection
 WEDM103            Missing ‘receipt-security-         receipt-security-   mutually agreedrequired                              Formatted: Strikethrough
                    selection’                         selection
                                                                                                                                Formatted: Not Highlight
                                                                                                                                Formatted: Underline




7.1.8 Receipts, Error Notifications, and Sender Non-Repudiation
        Sandia Finding: A digital signature for a receipt or an error notification may be insufficient to
        provide Sender non-repudiation.
        Sandia Analysis: If a Receiver digitally signs a receipt or an error notification, then the Sender
        can be assured that the receipt or the error notification did in fact come from the Receiver.
        However, it is not clear that the Sender can be assured that the Receiver cannot repudiate the
        particular payload that the Sender sent, to which the receipt and the error notification are
        responses. That assurance for the Sender depends on whether the receipt or error notification
        itself was in some way a function of the particular payload sent by the Sender. Even if the
        Receiver generates a digital signature for a receipt (or an error notification), it may be possible in
        the future for the Receiver to fraudulently claim that the receipt (or error notification) was for a
        different Sender payload. The receipt is a “gisb-acknowledgement-receipt” (IET page 173), but
        the format of that receipt does not appear to be defined in the Standard. The closest the Standard
        comes to defining the format is in the second, full paragraph on page 186: “…includes the HTTP
        Response data elements (time-c, time-c-qualifier for REQ/RGQ, request-status, server-id, and
        trans-id)”. There is no mention in that passage of the receipt including a function of the payload.
        There is even less information on the nature of the error notification.
        Sandia Recommendation: Require the object upon which digital signatures operate to be a
        function of the original payload sent from the Sender to the Receiver.
        NAESB Response: We concur with the finding, analysis and recommendation. The NAESB
        Internet ET manual has been modified to reflect support of Sandia’s research.(CB added 7/15)


                                        NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                                 Date Prepared: October 31, 2007
                                                                                                          Page 19
                    NAESB Response to the 2006 Sandia Surety Assessment

        Please refer to proposed standards manual changes made in Sandia response numbers 7.1.6,                 Formatted: Not Highlight
        and 7.1.7.

7.1.9 Abnormal Error Notification Usage
        Sandia Finding: The IET Standard does not describe “abnormal” Error Notification usage.
        Sandia Analysis: The IET Standard states “RXQ.0.2.69 ‘Error Notification’. Error Notification is a
        package from the Receiver of the original data to the Sender when errors are trapped after the
        Internet ET receipt sent. This is normally used for decryption errors detected after the Internet ET
        receipt has been sent” pages 164-5, emphasis added). “Normal” usage is described here but
        “abnormal” usage is not. The presumption is that abnormal usage is, like normal usage,
        legitimate. This allows an adversary to claim be following the Standard and simultaneously to use
        Error Notifications in any way the adversary chooses.
        Sandia Recommendation: Remove the word “normally” from the passage. If error notification is
        used for other purpose than relaying decryption errors, then modify the phrase “is normally used
        for decryption errors” to read “is only used for decryption errors”. If error notification is used for
        some purposes in addition to relaying decryption errors, then modify the wording to reflect that.
        NAESB Response: NAESB agrees with the Sandia recommendation. The following are the
        recommended changes to the NAESB Internet ET manual.
                                                                                                                 Formatted: Font: 10 pt
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 16 (underlined denotes addition to existing
manual language; strike-through denotes deletion from existing manual language)


10.2.14 ‘Error Notification’. Error Notification is a package sent from the Receiver of the original data to
the Sender when errors are trapped after the Internet ET Receipt is sent, for example, when. This is             Formatted: Font: 10 pt, Underline
normally used for decryption errors are detected after the Internet ET Receipt has been sent.                    Formatted: Font: 10 pt, Underline,
                                                                                                                 Strikethrough
        (CB added 7/15) 10.2.14 ‘Error Notification’. Error Notification is a package sent from
                                                                                                                 Formatted: Font: 10 pt, Strikethrough
        the Receiver of the original data to the Sender when errors are trapped after the Internet
                                                                                                                 Formatted: Font: 10 pt
        ET Receipt is sent. This is normally used for decryption errors detected after the Internet
        ET Receipt has been sent.                                                                                Formatted: Font: 10 pt, Underline
                                                                                                                 Formatted: Font: 10 pt
                                                                                                                 Formatted: Highlight
7.1.10 Bogus Decryption Errors                                                                                   Formatted: Indent: Left: 0"


        Sandia Finding: The Standard allows a Receiver to see the contents of a package while
        claiming otherwise based on decryption errors.
        Sandia Analysis: This problem arises when trading partners agree to decrypt after sending a
        Receipt. There are three aspects to this problem.
        First, the Standard does not appear to require a response when decryption succeeds. "Error
        Notification" (RXQ.0.2.69, IET page 164) appears to be for decryption failure only, not success.
        There is an Internet ET message code that announces decryption failure, namely EEDM699, but
        there does not appear to be a corresponding Message that announces decryption success.
        Second, even a response of decryption failure does not appear to be required within a given time.
        There is a time limit associated with an exchange failure, for example, but there does not appear
        to be a time limit associated with decryption failure.

                                    NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                             Date Prepared: October 31, 2007
                                                                                                      Page 20
                   NAESB Response to the 2006 Sandia Surety Assessment

       Third, the Standard and the TPA disagree on this matter. The TPA requires a response, even if
       decryption succeeds: If the Document [sent by the Sender] is verified and the decryption is
       successful, the receiving party shall transmit a Functional Acknowledgement in return. If the
       Document is verified and the decryption is unsuccessful, the receiving party shall send the
       applicable error message to the sending party. (RXQ.6.1, Section 2.2, page 2) Section 2.3.7
       (page 3) of the TPA requires that the trading partners agree to a time within which the Receiver is
       required to send a package to the Sender that informs the Sender of the results of the decryption.
       Sandia Recommendation: Require that the Receiver notify the Sender, within an agreed-upon
       time, of the results of decryption. Resolve the discrepancies between the Standard and the TPA.
       NAESB Response: NAESB agrees with the Sandia recommendation. The following are the
       recommended changes to the NAESB Internet ET manual.
       Regarding the decryption response of the payload, if the payload document is an EDI document,           Formatted: Font: Not Bold
       then the receipt of a 997 response will indicate successful decryption. For other file formats, an      Formatted: Font: Not Bold
       explicit http(s) response can be sent. In all cases, responses must be sent in thea timeframe as
       specified in each quadrant’s standards, or less than 60 minutes from initial payload receipt.           Formatted: Font: Not Bold
       (Really?) LS 10/02/07 OK - LS 10/18/07                                                                  Formatted: Font: Not Bold
                                                                                                               Formatted: Font: Not Bold
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 20 ( underlined denotes addition to existing                       Formatted: Font: Not Bold
manual language; strike-through denotes deletion from existing manual language)
                                                                                                               Formatted: Highlight
                                                                                                               Formatted: Font: 10 pt
10.3.x27 A decryption response should be sent no later than 60 minutes from the initial payload
receipt, or within a timeframe as specified in each quadrant’s QEDM standards.                                 Formatted: Not Highlight
       For the first question, there is no decryption successful response for transactions that are not X12.   Formatted: NAESB Para Default 2nd Indent,
       If the trading partners are using a non-X12 latfile method you will send                                Indent: Left: 0", First line: 0", Adjust space
                                                                                                               between Latin and Asian text, Adjust space
       Leigh Spangler’s comment:                                                                               between Asian text and numbers, Tab stops:
                                                                                                               0", Left
       The EDM Specification does not include a decryption notification by the Receiver because the
       specification envisions a deliberate separation between the computing resources used to receive         Formatted: Underline, Not Highlight
       the package (call it the “receipt computer”) and those used to decrypt and validate package             Formatted: Font: Not Bold
       content (call it the “content computer”). Specifically, the receipt computer must be directly
       connected to the Internet in order to accomplish its task of receiving and sending package-level
       acknowledgements to the Sender. The content computer, meanwhile, can be placed away from
       the “DMZ”, providing for higher security for this critical computing resource. This division also
       separates the slower decryption and format-level processing tasks from package receipt
       processing, allowing for quicker HTTP session-level receipt acknowledgements. Given this
       architecture, and given the EDM Specifications format-indifferent approach to package content, it
       follows that the definition of content-level messaging, including decryption errors or file format
       errors, be done in content-specific agreements, such as the TPA.
                                                                                                               Formatted: Indent: Left: 0"


7.1.11 IET Standard and TPA Conflict on Digital Signatures
       Sandia Findings: The Standard and the Trading Partner Agreement (TPA) do not agree on the
       optional nature of digital signatures.
       Sandia Analysis: A digital signature for the Sender is optional, according to the IET Standard
       (IET page 171 (see also RXQ.0.2.56, part C, page 163)). However, Section 1.5 of the TPA states
       that ‘Each party shall adopt as its signature private keys which shall be applied to each document
       transmitted by such party (“Digital Signature”)’ (RXQ.6.1, page 2, emphasis added). This
       contradicts the optional nature of digital signatures as expressed in the IET Standard.

                                   NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                            Date Prepared: October 31, 2007
                                                                                                     Page 21
                     NAESB Response to the 2006 Sandia Surety Assessment

          Sandia Recommendation: Require digital signatures on all documents transmitted between
          trading partners. Resolve the discrepancies between the Standard and the TPA.
          NAESB Response: NAESB agrees with the Sandia recommendation.We concur with the finding,
          analysis and recommendation. The NAESB Internet ET manual has been modified to reflect
          support of Sandia’s research. (CB added 7/15)    Please refer to standards manual changes
          made in the NAESB Response to Sandia item response number 7.1.6.


          (CB added 7/15) Text from the TPA that may need to be modified:
          2.2 Digital Signature Verification and Decryption.       Upon proper receipt of any
          Document, the receiving party shall attempt to decrypt the Document and verify the
          digital signature of the sending party. If the Document is verified and the decryption is
          successful, the receiving party shall transmit a Functional Acknowledgment in return. If
          the Document is verified and the decryption is unsuccessful, the receiving party shall
          send the applicable error message to the sending party. The sending party shall
          attempt to correct the error and promptly retransmit the Document or otherwise contact
          the receiving party.



7.1.12 Exchange Failure
          Sandia Finding: The Standard does not provide an unequivocal definition of “exchange failure.”
          Sandia Analysis: The Standard states “RXQ.0.2.79 ‘Exchange Failure’. An exchange failure is
          when a sending party’s NAESB Internet ET server has had three or more protocol failures over a
          period of time no less than thirty minutes and no more than two hours” (IET page 165, emphasis
          added). However, the Standard also states “RXQ.7.3.13 Three protocol failures within a 30-
          minute timeframe is an exchange failure” (IET page 168, emphasis added). This latter definition
          implies that the third protocol failure must occur before 30 minutes have elapsed since the first
          protocol failure. The two definitions are not in harmony. To add to the confusion, “exchange
          failure” is defined in at least three other places in the Standard: the relevant paragraph on page
          204 agrees with the statement on page 165; the relevant paragraph on page 156 agrees with part
          of the statement on page 165 but not all of it; and the relevant paragraph on page 154 does not
          mention time at all.
                                                                                                                 Formatted: Font: 10 pt
          Sandia Recommendation: Revise all definitions to be consistent.                                        Formatted: Font: 10 pt
          NAESB Response: NAESB agrees with the Sandia recommendation. The following are the                     Formatted: Underline
          recommended changes to the NAESB Internet ET manual.
                                                                                                                 Formatted: Font: 10 pt
                                                                                                                 Formatted: Font: 10 pt, Strikethrough
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 17 (underlined denotes addition to existing
manual language; strike-through denotes deletion from existing manual language)                                  Formatted: Font: 10 pt
                                                                                                                 Formatted: Font: 10 pt, Underline, Not
                                                                                                                 Strikethrough
10.2.24     ‘Exchange Failure’. An exchange failure is when a sending party’s NAESB Internet ET server           Formatted: Font: 10 pt
            has had three or more protocol failures within a 30 minute period. LS 10/18/07over a period of
            time no less more than thirty minutes and no more than two hours.                                    Formatted: Font: 10 pt, Strikethrough
                                                                                                                 Formatted: Font: 10 pt
                                                                                                                 Formatted: Font: 10 pt
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 18 (underlined denotes addition to existing                          Formatted: Font: 10 pt
manual language; strike-through denotes deletion from existing manual language)
                                                                                                                 Formatted: Font: 10 pt
                                     NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                              Date Prepared: October 31, 2007
                                                                                                       Page 22
                      NAESB Response to the 2006 Sandia Surety Assessment


                                                                                                                    Formatted: Font: 10 pt, Strikethrough
10.3.13     Three protocol failures within a 30-minute timeframe is an exchange failure.




7.1.13 Previous Version Acceptance
          Sandia Finding: The Standard supports any previous version of the standard, even insecure
          versions.
          Sandia Analysis: The Standard states “RXQ.7.1.9 Trading Partners should mutually select and
          use a version of the NAESB Internet ET standards under which to operate, unless specified
          otherwise by government agencies” (IET page 163, emphasis added). This allows for partners to
          be using any version of the Standard, even ones that have always been or have by now become
          insecure. In addition, the Standard states, “If either trading party does not agree to the inclusion of
          additional features, then the partners must allow for transmission and receipt of data using the
          minimum standards” (IET page 158, emphasis added). This could be read to mean that an
          adversary could insist on a victim agreeing to the use of an insecure version. If the victim refuses,
          the adversary can claim unfair business practice; if the victim acquiesces, the adversary can
          collude to make transactions public, subsequently claiming that the victim has leaked confidential
          information.
          There was a similar item in the previous assessment and the wording now reflects the changes
          suggested at that time. Due to increased threats on the Internet, a more stringent
          recommendation is being put forth.
          Sandia Recommendation: Sandia recommends that users be required to conform to the current
          version of the standard by some reasonable period of time after the publication of each new
          version. Previous versions of the standard should be deprecated (i.e., unacceptable for use) as
          soon as they become the third newest version or older. For example, when version 1.8 is
          published, version 1.7 then becomes the second newest version and thus continues to be
          acceptable only for some reasonable period of time, while version 1.6 joins older versions in
          becoming deprecated. It is contradictory to the purpose of a standard to permit users to negotiate
          use of an older version of the standard, particularly when evolving technology erodes the security
          value of older versions of the standard.
          NAESB Response: NAESB agrees with the Sandia recommendation. The following are the
          recommended changes to the NAESB Internet ET manual.

                                                                                                                    Formatted: Font: 10 pt
                                                                                                                    Formatted: Font: 10 pt, Strikethrough
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 15 (underlined denotes addition to existing                             Formatted: Font: 10 pt
manual language; strike-through denotes deletion from existing manual language)
                                                                                                                    Formatted: Font: 10 pt, Underline

10.1.9      Trading Partners should mutually select and agree to either the current, or the immediately             Formatted: Font: 10 pt, Not Highlight
            previous, published use a version of the NAESB Internet ET standards as a basis under which             Formatted: Font: 10 pt, Strikethrough
            to operate, unless specified otherwise by an applicable regulatory authority. government
                                                                                                                    Formatted: Font: 10 pt
            agencies. Trading Partners should also mutually agree to adopt later versions of the NAESB
            Internet ET standards, as needed, unless specified otherwise by government agencies (4.1.39).           Formatted: Font: 10 pt, Underline
                                                                                                                    Formatted: Font: 10 pt
                                                                                                                    Formatted: Font: 10 pt, Underline
NAESB WHOLESALE GAS QUADRANT QUADRANT ELECTRONIC DELIVERY MECHANISM                                                 Formatted: Font: 10 pt, Strikethrough
MANUAL, VERSION 1.8, Page 28 (underlined denotes addition to existing manual language; strike-
                                                                                                                    Formatted: Font: 10 pt
                                      NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                               Date Prepared: October 31, 2007
                                                                                                        Page 23
                     NAESB Response to the 2006 Sandia Surety Assessment

through denotes deletion from existing manual language)


4.1.39     Trading Partners should mutually select and utilize a agree to us either the current, or             Formatted: Strikethrough
           the immediately previous, published version of the NAESB WGQ EDM standards as a                      Formatted: Underline
           basis under which to operate, unless specified otherwise by an applicable regulatory                 Formatted: Not Highlight
           authority. government agencies. Trading Partners should also mutually agree to
                                                                                                                Formatted: Underline
           adopt later versions of the NAESB WGQ EDM standards, as needed, again unless
           specified otherwise by government agencies.                                                          Formatted: Underline
                                                                                                                Formatted: Strikethrough
NAESB RETAIL ELECTRIC/GAS QUADRANT QUADRANT ELECTRONIC DELIVERY
MECHANISM MANUAL, VERSION 1.0, Page ?? (underlined denotes addition to existing manual                          Formatted: Font: 10 pt
language; strike-through denotes deletion from existing manual language)                                        Formatted: Font: 10 pt
         Need exact standards language from Jesse, Dan, George, Barbara                                         Formatted: Highlight

         ??8.1.39 Trading Partners should mutually agree to use either the current, or the
         immediately previous, published version of the NAESB RXQ EDM standards as a basis
         under which to operate, unless specified otherwise by an applicable regulatory authority.

(CB added 7/15) NAESB INTERNET ET MANUAL, VERSION 1.8, Page 20 (yellow,
underlined denotes addition to existing manual language; yellow, strike-through denotes
deletion from existing manual language)
10.3.x27 The most recent version of the Internet ET standards is recommended except where earlier
version(s) are specified by state government, At a minimum, an Internet ET or NAESB EDM version
supporting 128-bit SSL is strongly encouraged.

7.1.14 Refnum & Refnum-orig
         Sandia Finding: The Standard does not check on a Sender’s abuse of Refnum & Refnum-orig.
         Sandia Analysis: An adversary, on a “first send”, could set Refnum-orig not equal to the current
         Refnum. The Receiver would then conclude that the Sender this was a resend—either first or
         second—and that the first send had been lost. Over time the adversary could claim unfair
         business practice on the part of the Receiver: the Receiver consistently drops the adversary’s first
         send, making the adversary resend and thus lose valuable time, giving other trading partners an
         unfair advantage.
                                                               1
         Alternatively, the adversary could reuse Refnums. For example, the adversary could send
         payload A, proposing a deal favorable to the adversary, followed, sometime later, with payload B,
         proposing a deal favorable to the Receiver—both payloads sent with the same Refnum. When the
         Receiver accepts payload B, the adversary proceeds, fraudulently acting as though the Receiver
         had accepted payload A. When the Receiver protests, the adversary claims that the Receiver
         changed the Refnum in payload B in an attempt to cheat the adversary.
         There may be other ways the adversary can use Refnum to their advantage. The point is that the
         Standard requires that the “refnum data element is always unique over time” (IET page 175) but
         there is no provision for confirming compliance by an implementation. Compliance capability
         would require some algorithmic way to detect reuse, or a capability to cross reference Refnum
         fields with prior transactions.



                                    NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                             Date Prepared: October 31, 2007
                                                                                                      Page 24
                     NAESB Response to the 2006 Sandia Surety Assessment

       Sandia Recommendation: A mechanism should be in place to prevent or detect the abuse and
       reuse of Refnum and Refnum-orig values.
       NAESB Response: We agree that there is potential for abuse for those parties that mutually-
       agree (MA) to use Renum and Renum-orig functionality. Given that these data elements are
       relatively recent additions to the IET Standards and their usage are MA, they are not used
       significantly in the REQ/RGQ/WGQ industries. To create mandatory standards for storage,
       tracking and usage of Refnum and Refnum-orig could generate a significant amount of work for
       the installed industry. For the aAbuses can occur as described in paragraph 1 above,. uUsers of        Formatted: Font: Not Bold
       these data elements should be aware of these conditions and monitor for these abuses. For the          Formatted: Font: Not Bold
       case in paragraph 2 above, receivers of ref-num and ref-num-orig, if used in conjunction with the
       trans-id and time-c, can detect and mitigate this particular abuse.                                    Formatted: Font: Not Bold
                                                                                                              Formatted: Font: Not Bold
       NAESB will continue to monitor the use of these data elements and consider changes where
       warranted, including the removal of this functionality, if necessary. See below for proposed           Formatted: Font: Not Bold
       language noting the potential for abuse of these data elements, when used.                             Formatted: Font: Not Bold
                                                                                                              Formatted: Font: Not Bold
                                                                                                              Formatted: Font: Not Bold
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 28 (underlined denotes addition to existing                       Formatted: Font: Not Bold
manual language; strike-through denotes deletion from existing manual language)
                                                                                                              Formatted: Font: 10 pt
                                                                                                              Formatted: Font: 10 pt
Abuse of Refnum and Refnum-orig
                                                                                                              Formatted: Underline

There is potential for abuse/error when using the functionality of these mutually-agreed data
elements. Parties should monitor for the re-use of numbers used with both refnum and refnum-                  Formatted: Not Highlight
orig for the receipt and delivery functions. [Need abuse example]                                             Formatted: Underline



                                                                                                              Formatted: Underline
       Example of Abuse by re-using Renum in “First resend”

               Package Send                         refnum                          refnum-orig

        First send                       123467890123456                   123467890123456

        First resend                     123467890123456                   123467890123456

       Example of Abuse by Sending Bogus Renum-orig in “First resend”

               Package Send                         refnum                          refnum-orig

        First send                       123467890123456                   123467890123456

        First resend                     223467890123457                   010101010101010

       Example of Abuse by re-use Refnum and Renum-orig in “New package”

               Package Send                         refnum                          refnum-orig

        First send                       123467890123456                   123467890123456


                                  NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                           Date Prepared: October 31, 2007
                                                                                                    Page 25
                  NAESB Response to the 2006 Sandia Surety Assessment


        First resend                      223467890123457                    123467890123456

        New package                       123467890123456                    123467890123456



                                                                                                               Formatted: Font: (Default) Bookman Old
                                                                                                               Style, Not Bold
      George Behr’s comments:
                                                                                                               Formatted: Indent: Left: 0"
      NAESB recommends adding a refnum-checksum data element that algorithmically ties the
      contents of the payload to the refnum-orig to mitigate the situation where payloads are switched.


      NAESB also recommends adding language to the Internet ET on best-practice handling of
      refnums, including proper tracking of used refnums.




7.1.15 Missing Functional Acknowledgement
      Sandia Finding: The Standard would support an adversary’s fraudulent claim to have sent a
      package that the adversary had in fact not sent.
      Sandia Analysis: The Trading Partner Agreement (TPA) states:
      If there has been a proper receipt pursuant to Section 2.1, verification and successful decryption
      pursuant to Section 2.2, and if the receiving party nevertheless fails to transmit a Functional
      Acknowledgement, the sending party’s records of the Document shall control, unless the sending
      party has retransmitted a Document pursuant to Section 2.3.7. (RXQ.6.1, Section 2.3.3, page 3)
      How is the receiving party to be protected from the sending party fraudulently claiming to have
      sent a given package when in fact the sending party never did send the package? How can the
      receiving party substantiate his case that he never received the package? If the sending party’s
      records of the Document shall control, then what is the purpose of the Functional
      Acknowledgement?
      Sandia Recommendation: One possibility is for NAESB to consider a more rigid protocol: (1)
      there are only two types of transmissions: a send of an “original” payload and a Receipt of an
      original payload; (2) all transmissions must be digitally signed; (3) all digital signatures must be a
      function of the original payload; (4) decryption must be performed prior to sending a Receipt, and
      (5) “force or effect” (TPA, Section 1.1) apply only to those original payloads for which the Sender
      has received an “ok” Receipt from the Receiver. Under this more rigid protocol the sending party
      has no grounds to make the fraudulent claim described above.
      Meanwhile, it seems unlikely that this type of attack is new with the advent of electronic trading. Is
      it possible for the TPA to incorporate the protection available prior to the advent of electronic
      trading?
      George Behr’s comments:
      NAESB Response: According to theIn the scenario defined by Sandia, a proper receipt (including
      authentication and decryption) has been received by the Sending Party. A so according to
      Internet ET standards, thea package has been sent. It appears that Sandia’s comments issue in
      7.1.15 focuses on the contents of that package not being acknowledged by the Receiving Party.
      Standards language for validation and notification regarding package content is contained in
                                  NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                           Date Prepared: October 31, 2007
                                                                                                    Page 26
                   NAESB Response to the 2006 Sandia Surety Assessment

       theother NAESB standards manuals for each Quadrant. of the industries represented.                    The
       Internet ET model focuses on the transfer of the package itself.


       Sandia’s analysis references section 2.3.3 and also 2.3.7. The lack of either the 997 or the
       Response Document should indicate to the Sending Party that their document has not been
       received. A properly receipted, decrypted Internet ET package might contain gibberish, for which
       the Receiving party cannot send the 997/Response Document. Even though the Receiving party
       has accepted the Internet ET package, the Document (ie the X12 EDI document) has not been
       acknowledged or accepted. The burden continues to remains on the Sending Party.



NAESB CONTRACTS STANDARDS AND MODELS MANUAL, VERSION 1.8, Page 27 (
underlined denotes addition to existing manual language; strike-through denotes
deletion from existing manual language)
        2.3.3 If there has been proper receipt pursuant to Section 2.1, verification and
successful decryption pursuant to Section 2.2, and if the receiving party nevertheless fails to
transmit a Functional Acknowledgement, the transmission should be considered incomplete,                             Formatted: Underline
and the sending party retains the burden for remediation of the transmission failure, sending                        Formatted: Underline, Not Highlight
party’s records of the contents of the Document shall control, unless the sending party has                          Formatted: Not Highlight
retransmitted a Document pursuant to Section 2.3.7.
                                                                                                                     Formatted: Strikethrough
       2.3.6 If the parties have mutually agreed to the use of a Response Document, and if
there has been proper receipt pursuant to Section 2.1, verification and successful decryption
pursuant to Section 2.2, and if the receiving party nevertheless fails to transmit a Response
Document, the transmission should be considered incomplete, and the sending party retains                            Formatted: Underline
the burden for remediation of the transmission failure, the sending party’s records of the                           Formatted: Strikethrough
contents of the Document shall control unless the sending party has retransmitted a Document
pursuant to Section 2.3.7.
       NAESB recommends that the trading partner language be revised to the following:


       2.3.3 If there has been proper receipt pursuant to Section 2.1, verification and successful decryption
       pursuant to Section 2.2, and if the receiving party nevertheless fails to transmit a Functional
       Acknowledgement, the transmission should be considered incomplete, and the sending party retains the
       burden for remediation of the transmission failure.


       2.3.6 If the parties have mutually agreed to the use of a Response Document, and if there has been proper
       receipt pursuant to Section 2.1, verification and successful decryption pursuant to Section 2.2, and if the
       receiving party nevertheless fails to transmit a Response Document, the transmission should be considered
       incomplete, and the sending party retains the burden for remediation of the transmission failure.


       NAESB also recommends that these scenarios be documented in quadrant-specific QEDM’s to
       assure the scenario is properly addressed, especially when technologies other than X12 EDI are
       used.
Please note that this is a change to the TPA – a legal document, and needs to be carefully examined for              Formatted: Highlight
accuracy.                                                                                                            Formatted: Indent: Left: 0"
                                                                                                                     Formatted: Highlight
                                    NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                             Date Prepared: October 31, 2007
                                                                                                      Page 27
                       NAESB Response to the 2006 Sandia Surety Assessment

7.1.16 In-House and Commercially-Available
          Sandia Finding: The Standard’s position on software development is not clear.
          Sandia Analysis: The Standard allows “any IT deployment model, including the use of in-house
          development…” (IET page 159), yet the Standard also states “RXQ.7.3.15 Trading partners
          should implement all security features…via a commercially-available implementation” (IET page
          168, emphasis added). Is this a contradiction or does it mean that “in-house development” can
          provide everything except for “security features”?
          Sandia Recommendation: Clarify these conflicting passages.
          NAESB Response: NAESB agrees with the Sandia recommendation. The NAESB Internet ET
          can be constructed using any IT deployment model, including the use of in-house,
          consulting/development help from a third-party, Commercial Off-The-Shelf (COTS) software, or
          an outsourced solution with a third-party. The best solution for each organization must be
          determined based on the assessment of specific needs and the resources available to that
          organization. Security features should be implemented using the security mechanisms specified
          in the Internet ET manual. The following are the recommended changes to the NAESB Internet
          ET manual.
                                                                                                                    Formatted: Font: 10 pt
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 16 (underlined denotes addition to existing
                                                                                                                    Formatted: Font: 10 pt
manual language; strike-through denotes deletion from existing manual language)
                                                                                                                    Formatted: Font: 10 pt


                                                                                                                    Formatted: Font: 10 pt
10.3.15     Trading partners should implement all security features (privacy, secure authentication, integrity,
            and non-repudiation) using a file-based approach via a commercially-available implementation            Formatted: Font: 10 pt, Strikethrough
            of:                                                                                                     Formatted: Font: 10 pt
              An OpenPGP product as defined by IETF RFC 2440, or
                                                                                                                    Formatted: Bullets and Numbering
              On a mutually agreed basis, PGP version 2.6 or greater using the RSA algorithm to generate
                 keys
            (4.3.15)




7.1.17 Central Address Repository (CAR)
          Sandia Finding: Standard 4.3.19 states that the CAR should make available a consolidated
          repository of the Transportation Service Providers' current URLs listed in Standard 4.3.18 in two
          ways: (1) a vehicle to link to sites and categories, and (2) a downloadable list. The CAR is
          available to any Internet user. Standard 4.3.20 states that a userID or password should not be
          required to access the Central Address Repository or the Transportation Service Provider's
          Informational Postings web site.
          Sandia Analysis: The CAR can be used as a target list for a malicious individual. Leaving the
          CAR unprotected and available to any Internet user can result in attacks being directed at the
          customers of a specific site. It is tailor-made for attacking using a denial-of-service type of attack.
          There was a similar item in the previous assessment. Due to increased threats on the Internet, the
          recommendation reiterated here.
          Sandia Recommendation: Protect the CAR using SSL and basic authentication. It is
          recommended that the standard be reworded to state that a userID and password be required to
          access the CAR for security purposes. The access password can be a single userID/password

                                      NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                               Date Prepared: October 31, 2007
                                                                                                        Page 28
                    NAESB Response to the 2006 Sandia Surety Assessment

       combination created, and changed yearly, by NAESB for the member organizations, but
       implemented locally by each member. The userID/password can be distributed securely by the
       NAESB office to members.
       NAESB Response: NAESB agrees with the Sandia recommendation. We concur with the finding                Formatted: Font: (Default) Arial
       and the analysis. However, for the central address repository, the recommendation that NAESB
       use both SSL encryption and a logon authentication for the central address repository would            Formatted: Font: (Default) Arial
       hinder the public from convenient and easy access, and possibly block access for legitimate
       users, while protecting against an unlikely risk. Several government agencies also make similar        Formatted: Font: (Default) Arial
       URL listings available for access and download without SSL encryption and logon authentication.
       Most, if not all, entities on the CAR could be located on the public FERC website. Because of the
       unlikely event of an attack, the cost to implement such security measures, and the barriers to
       easy access by the public, NAESB at this time will not implement the security measures of SSL
       encryption and logon authentication for the CAR.entral Address Repository.                             Formatted: Font: (Default) Arial

                                                                                                              Formatted: Tab stops: 3.93", Left
       Leigh Spangler’s comments:
       NAESB Response: NAESB concurs with Sandia’s analysis. However, as we responded to a
       similar item the last assessment, the recommendation for SSL security and basic authentication
       of users would hinder the public from convenient and easy access, and possibly block access for
       legitimate users, while mitigating an unlikely risk. Moreover, the information provided by the CAR
       is, by definition, public information and is available from the web sites of several government
       agencies. Additionally, encryption and authentication would present infrastructure and
       administration costs to NAESB. For these reasons, NAESB at this time will not implement SSL
       encryption and logon authentication for the Central Address Repository.




7.1.18 Open Ports
       Sandia Finding: In Appendix D of the NAESB WGQ Quadrant Electronic Delivery Mechanism
       Manual, it is suggested that ports 8001-8020 be left open for load balancing and other
       implementations such as DCE and IIOP.
       Sandia Analysis: Any open, unsecured port assists an attacker in gaining access and
       accomplishing port flooding. Open ports can be identified using readily available portmappers,
       which provide an attacker with a starting point for malicious activity. Once an attacker has located
       an open port, he or she can exploit software vulnerabilities to gain access to the system or flood
       open ports to halt a transaction, application, or the system as a whole. Since transactions are
       time-dependent, slowing, or halting system traffic could result in a measurable loss of business.
       Sandia Recommendation: Keeping unused, unsecured ports open poses a risk. Any ports not in
       use by an application as part of the transaction should be closed. Open ports should be protected
       by system and network security controls such as intrusion prevention systems, access control
       lists, current system patches, and an overall secure configuration. We recommend removing the
       statement in Appendix D referring to optional ports. Likewise, referencing a secure configuration
       be applied to the trading partner system would ensure ports cannot be enumerated and
       mitigations are in place to reduce the number of vulnerable ports.
       NAESB Response: NAESB agrees with the Sandia recommendation. The following are the
       recommended changes to the NAESB Internet ET manual.
                                                                                                              Formatted: Indent: Left: 0.3", First line: 0.2"

       Leigh Spangler’s comment:


                                  NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                           Date Prepared: October 31, 2007
                                                                                                    Page 29
                 NAESB Response to the 2006 Sandia Surety Assessment

      NAESB concurs with Sandia’s recommendation. The current port list in Appendix D of the WGQ
      QEDM Manual was compiled to support the numerous Customer Activities Web Site
      implementation technologies that have been utilized over the past several years. Many of the early
      Internet technologies, however, have been replaced with advances in Internet programming and it
      is allowable that some, if not many of the specified ports can be removed from Appendix D. The
      WGQ EDM Subcommittee is charged with annually reviewing the WGQ QEDM and will undertake
      in its 2007 evaluation to minimize the requirements for open ports.
                                                                                                             Formatted: Font: 10 pt
NAESB WHOLESALE GAS QUADRANT QUADRANT ELECTRONIC DELIVERY MECHANISM
MANUAL, VERSION 1.8, Page 92 (underlined denotes addition to existing manual language;                       Formatted: Font: 10 pt
strike-through denotes deletion from existing manual language)




APPENDIX D -               Minimum          Technical          Characteristics            for     EDM
Communications
The following ports may be used by EDM developers and should be made available in user
environments.

      Allowable TCP Ports (not UDP ports)
             HTTP HTTPS 80, 443, 5713, 6112, 6304, 6874, 7403
             ICA® 1494
             RMI(Java® ) 1099-1100
             Java® Telnet 31415
             TCP Optional 8001-8020**                                                                        Formatted: Strikethrough
             SMTP 25
        Allowable UDP Ports (not TCP ports)
             Secure ICA® 1604
                                                                                                             Formatted: Underline
      Trading partners may mutually agree to use ports other than those specified above.
      Only ports necessary to transaction-related traffic should be opened, and they should be
      protected by network and system security controls. All other ports should be closed.
      There are other technologies available that would require additional ports to be opened,
      such as FTP and Telnet. If and when NAESB WGQ approves such technologies, this
      list will be modified accordingly. The client-side firewall implementation and client
      browser settings should permit the downloading and installation of NAESB WGQ
      approved plug-ins and modules. Please refer to the NAESB WGQ defined Minimum
      Technical Characteristics for Accessing Customer Activities Web Sites for the listing of
      NAESB WGQ approved plug-ins and modules.




 ICA® is a registered trademark of Citrix Systems Inc.

 JAVA® is a registered trademark of Sun Microsystems, Inc.

                                 NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                          Date Prepared: October 31, 2007
                                                                                                   Page 30
                   NAESB Response to the 2006 Sandia Surety Assessment




                                                                                                                Formatted: Strikethrough
       **The reservation of 20 optional ports was to provide room for implementations such as
       DCE, IIOP, and load balancing implementations. TSPs should endeavor to minimize the
       usage of these ports.


                                                                                                                Formatted: Font: (Default) Bookman Old
                                                                                                                Style, Font color: Auto

7.1.19 Ports in Use
       Sandia Finding: Appendix D lists allowable TCP and UDP ports used as part the transaction
       process and required for specific applications. These include standard ports for HTTP and SMTP.
       This standard does not directly address the use of open ports, but lists required ports for specific
       applications.
       Sandia Analysis: While use of these required ports is necessary to complete the transaction, it
       may not be necessary to specify which ports are opened and closed. Moreover, any open port
       presents a risk. See subsection 7.1.18 for more details. Therefore, ports should be closed unless
       utilized in the transaction and protection of these open ports is necessary to reduce the chance for
       disruption. Knowing packet destinations and origins can assist an attacker in learning about the
       anatomy of a transaction, becoming man-in-the-middle, spoofing packets, sending bogus
       receipts, and generally altering a transaction.
       Sandia Recommendation: Do not address specific ports, but rather make a statement in the
       Appendix that only ports necessary to transaction related traffic should be opened, and they
       should be protected by network and system security controls. All other ports will be closed.
       Securing the network and system is addressed in subsection 7.1.2.
       NAESB Response: NAESB agrees with the Sandia recommendation.We concur with the finding
       and the analysis There that NAESB is using non-standard ports and that there are no security
       benefits gained by using the specified ports. NAESB appreciates Sandia's recommendation, and
       have has proposed removinged additional ports within the implementation manual per changes
       made in the NAESB Response to Sandia response number 7.1.18decided to place port
       specifications within the TPA. Any additional security standards specifications could work effort
       would require significant resources to implement the recommendation, and the risk assessed is
       minimal.



7.1.20 Message replay attacks
       Sandia Finding: Message replay is not addressed fully in the standards.
       Sandia Analysis: Currently there is not a complete mechanism in place that will disallow replay
       attacks. Both client and server mechanisms need to be in place to keep this from being a viable
       attack. Timestamps could be spoofed, if not digitally signed, altering the outcome of a transaction.
       There are timestamps in the EDI/EDM transfer of files, in the header for example, but it’s unclear
       if that is digitally signed, but we believe it is. That doesn’t seem the case for all methods however,
       such as Batch FF/EDM.


                                   NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                            Date Prepared: October 31, 2007
                                                                                                     Page 31
            NAESB Response to the 2006 Sandia Surety Assessment

There was a similar item in the previous assessment. The tools are available for mitigation of this
vulnerability and are readily available for use.
Sandia Recommendation: Ensure that all transaction methods include the timestamp in an area
of the transaction that is digitally signed. If the resolution of the timestamp is not fine enough to
ensure that only one transaction will be sent with that timestamp, an additional field containing a
sequence number will be required such that the combination of the timestamp and sequence
number field will always be guaranteed to be unique. This method will only work if the transaction
is digitally signed using an accepted cryptographic checksum. An example of such a
cryptographic checksum algorithm is the Secure Hash Algorithm defined in FIPS Pub 180-1. PGP
uses several accepted cryptographic checksum algorithms, such as IDEA, RSA, DSA, MD5, SHA,
and SHA-1. However, there have been demonstrated compromises for all but SHA-1 and as
computing power increases, these compromises will become feasible for an attacker to perform
within a few years.
NAESB Response: NAESB agrees with the Sandia recommendation. The NAESB Internet ET                      Formatted: Font: Not Bold
may be susceptible to replay attacks. NAESB has implemented the same level of timestamp                 Formatted: Font: Not Bold
verification for all file content formats, including Batch FF/EDM. We concur with the finding and
the analysis that NAESB Internet ET may be susceptible to replay attacks. However, the adoption
by NAESB of SSL encryption for Internet ET messages precludes the interception of the message
by a third party and replaying it repeatedly to a destination server – a “deep denial of service”
attack. While this technique does not preclude the possibility of a replay attack from a “man-in-
the-middle” (DNS spoofing), it does mitigate the most likely causes of replay attacks.
Furthermore, the “man-in-the-middle” attack is unlikely and would take significant resources to
prevent.
NAESB appreciates Sandia’s recommendation, but does not at this time, endorse changes to the
standard to mitigate the “replay attacks”,(CB added 7/15) endorse changes to the standard to
mitigate the “replay attacks”, over and above the existing 128-bit SSL requirements. The
resources required to implement the recommendation are significant, and the risk assessed is
minimal. As more cost effective solutions become commercially available, this response will be
revisited.
For Interactive Flat Files: The Interactive Flat File mechanism allows the user to construct a
comma-separated-value (CSV) file using software such as a spreadsheet and then upload it using
a Web browser. NAESB supports the use of 128-bit SSL encryption to protect this data from
viewing or alteration.
Because the uploaded transaction is in the form of a file, it is possible for the user to apply a
digital signature to the file after its creation. The same administrative issues as described above
in the discussion on the Customer Activities Web sites apply also to Interactive Flat Files. That is,
there is the potential to have to maintain a large number of OpenPGP/PGP public keys. However,
as a practical matter, there appear to be very few users of this particular Internet ET mechanism,
which reduces the administrative burden. Of course, the user would still be required to purchase
and install the OpenPGP/PGP client on the desktop, and there would still be a training
requirement. However, there appears to be little to be gained by having this capability for this
particular on-line user while most on-line users would not have the capability.
Checks and balances already exist for the natural gas transactions, such as scheduled quantities
after the nominations have been processed, and confirmations, both upstream and downstream –
so that the risk of foul play as a result of no digital signature is minimized. With NAESB
standards, the risk is of a commercial nature instead of physical impairment. If the digital
signature technology were readily available, NAESB would use it – but the exposure right now is
not great enough to warrant the expense and resources to implement digital signatures. For the
above reasons, NAESB appreciates Sandia's recommendation and has taken steps to implement


                            NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                     Date Prepared: October 31, 2007
                                                                                              Page 32
                   NAESB Response to the 2006 Sandia Surety Assessment

        the SSL 128-bit encryption, but does not at this time plan to implement digital signatures for
        interactive flat files.
        George Behr’s comments:
        NAESB recommends changing standards to require the digital signature of all payloads.
        NAESB recommends that QEDM standards be reviewed to assure that each method of document
        transfer (e.g. X12 EDI, Batch FF/EDM, etc) include timestamps so that timestamps cannot be
        spoofed.



7.2 Recommendations for NAESB Principles

7.2.1 Principle 4.1.15
        Sandia Finding: This recommendation references Principle 4.1.15 and provides suggested
        rewording of this principle.
        Sandia Analysis: Principle 4.1.15 states: “The NAESB should not set standards for site-level
        security. Individual organization security standards should be relied upon.”
        There was a similar item in the previous assessment. However, as system security has matured,
        we are modifying the recommendation to take advantage of the work of other standards bodies.
        Recommendation: Sandia recommends that the NAESB standards have minimum requirements
        for site security, but that they do not enumerate requirements for clients. Rather, it would be
                                                                                   9         10
        beneficial to refer to a well-known standards organization such as SANS or NIST and require
        that workstations conform to those standards for secure systems at some specific level. See the
        subsection 7.1.2 for additional information.
        NAESB Response: NAESB agrees with the Sandia recommendation. Please refer to standards
        manual changes made in the NAESB Response to Sandia response number 7.1.2.



7.3 Other Areas for Improvement


7.3.1 Missing Definitions
        Sandia Finding: Many items are left undefined.
             • What are the “QEDM standards” referred to on page 154 of the IET Standard?
             • What are “open standards” ( IET page 155)? (Are open standards the same as non-
               proprietary standards?)
             • What is a “gisb-acknowledgement-receipt” (IET page 164)?
             • What is a “transaction set” (IET page 174)?


      NAESB Response: NAESB has reviewed the final version of the Internet ET standards manunal                Formatted: Indent: Left: 0.4"
      and compiled the comments for the above. Please see bbelow for comments regarding each item:



                                   NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                            Date Prepared: October 31, 2007
                                                                                                     Page 33
                    NAESB Response to the 2006 Sandia Surety Assessment

                 “QEDM standards” are described in the Internet ET manual on page 5. The QEDM                  Formatted: Bulleted + Level: 1 + Aligned at:
                  standards are those standards that are specific to each of the industries that are using      0.8" + Tab after: 1.05" + Indent at: 1.05"
                  the Internet ET as their transport mechanism.                                                 Formatted: Bullets and Numbering
                 “Open standards” – NAESB has a philosophy of not picking “winners and losers” in              Formatted: Font: (Default) Arial, Not Bold
                  regard to commercially available products and technology. Where appropriate NAESB             Formatted: Font: Not Bold
                  standards are written to encourage market place participation and not n-vendor- specific
                  solutions. An unofficial definition of “open standard” is ‘a standard that is publicly        Formatted: Font: (Default) Arial
                  available and has various rights to use associated with it.’                                  Formatted: Font: (Default) Arial

                 “gisb-acknowledgement-receipt” – is used as the acknowledgement receipt for the               Formatted: Font: (Default) Arial
                  Internet ET. It is described on page 37 of the Internet ET manual. The name is actually       Formatted: Font: (Default) Arial
                  a hold over from the value given during the time NAESB was only developing standards
                                                                                                                Formatted: Font: (Default) Arial
                  for the Natural Gas Industry - Gas Industry Standards Board (GISB).
                                                                                                                Formatted: English (United States)
                 “transaction-set” – is a data element that is mutually agreed to by both trading partners
                  and used in the Energy industry to communicate an abbreviated business data set name
                  and the cororesponding X12 transaction set mapping. The accompanying QEDM
                  manuals for each of the quadrants specify the use of this mutually agreed data element.

NAESB INTERNET ET MANUAL, VERSION 1.8, Page 25 (yellow, underlined denotes
addition to existing manual language; yellow, strike-through denotes deletion from
existing manual language)
                                                                                                                Formatted: Indent: Left: 0"

transaction-set   name of the         8 character code; refer to   in Request;   used in file transmittal
                  document type       NAESB REQ and WGQ            MA                                           Formatted: Underline
                  being sent          Implementation Guides,
                                      Related Standards Tab,                                                    Formatted: Underline
                                      Hypertext Transfer
                                      Protocol (HTTP) section,
                                      HTTP transaction-set
                                      Code Values table.
                                                                                                                Formatted: Indent: Left: 0"



        George Behr’s Comments:
NAESB recommends a thorough review of the IET standard to identify and remediate any missing                    Formatted: Indent: Left: 0"
definitions.



7.3.2 Strange Numbering
        Sandia Finding: Why are the RXQ items not numbered consecutively? They start with 0.1.1 (IET
        page 163), proceed to 0.1.2, as expected, but then jump inexplicably to 7.1.1. (Meanwhile, on
        page 169 there is a paragraph numbered “7.3.50”. What is this?)
        NAESB Response: The NAESB manuals are numbered according to business function. Initially                Formatted: Font: Not Bold
        the Internet ET was envisioned to start at the number ‘0’ as there weren’t any NAESB standards
        developed with that number. At publication, the NAESB Internet ET manual standards all started
        with the number ‘10’. The ‘7.x.x’ number indicates that it is an official NAESB WGQ
        “interpretation” for an existing WGQ standard.
        George Behr’s comment:

                                    NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                             Date Prepared: October 31, 2007
                                                                                                      Page 34
                   NAESB Response to the 2006 Sandia Surety Assessment

       NAESB recommends a thorough review of the IET standard to identify and remediate any strange
       numbering scenarios.

7.3.3 Missing Principles
       Sandia Finding: Reference is made to “NAESB Internet ET Principle 4.1.x37” and “NAESB
       Internet ET 4.3.x70” (IET page 160). Presumably this is not one of the numbered paragraphs (IET
       pages 163-70) since the first digit of those paragraphs is either 0 or 7, but not 4. What, then, are
       Principles 4.1.x37 and 4.1.x70 and where are they found? Similarly, reference is made to the
       Internet ET Standard [10].3.3 and other related standards (p. 23). Where are these standards
       found?
       NAESB Response:
       George Behr’s comment:
       NAESB has conducted a recommends a thorough review of the Internet ET standards and
       resolved and confirmed all referenced standard numbers that are referenced to identify and
       remediate any missing principles..

7.3.4 Multiple Definitions

       Sandia Finding: Many items, such as the definition of Exchange Failure (IET pages 154, 156,
       165, 168, 204), are presented multiple times, lengthening the Standard and generating confusion
       when any two of the definitions differ. Information on timestamps, throughout the IET, has similar
       problems.
       NAESB Response:
       George Behr’s comment:
       NAESB recommends a has conducted a thorough review of the IET standards to identify and
       remediate any and clarified multiple definitions, including Exchange Failure and timestamps.

7.3.5 Definitive References

       Sandia Finding: The references should be definitive. For example, if the Standard recommends
       Dwight & Erwin’s book on CGI, then the reference should not read “A source on CGI is…” as it
       does now, using an indefinite article, but rather should use the definite article, as in “The source
       on CGI is…” or “The recommended source on CGI is…”
       NAESB Response: NAESB appreciates Sandia's recommendation, but declinesnot want to                       Formatted: Not Highlight
       specifically designate a single reference source for the each of technologies utilized in the Internet
       ET model. The resources noted in the appendices are intended to give a starting place for
       research and guidance, not exclusivity.
                                                                                                                Formatted: Indent: Left: 0"


7.3.6 Inconsistent References
       Sandia Finding: The references in the Reference Guide are not consistent with those in the
       body of the Standard. For example, the reference for PGP in the References Guide is different
       than the URL in RXQ.0.2.89 (IET page 166). The same is true of HTTP (see RXQ.0.2.92 (page


                                   NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                            Date Prepared: October 31, 2007
                                                                                                     Page 35
          NAESB Response to the 2006 Sandia Surety Assessment

166)). (Please also note that the URL for SSL in RXQ.0.2.88 (page 166), namely
http:deverloper.netscape.com/docs/manuals/security/sslin/contents.htm, is not found.)
NAESB Response: NAESB has conducted a thorough review of the Internet ET standards and
clarified these references.




                        NAESB Response to the 2006 Sandia National Laboratories Surety Assessment
                                                                 Date Prepared: October 31, 2007
                                                                                          Page 36

								
To top