NORTH AMERICAN ENERGY STANDARDS BOARD RESPONSE To The SANDIA

north american energy standards board response to the sandia national laboratories surety assessment report of the naesb internet e

NORTH AMERICAN ENERGY STANDARDS BOARD RESPONSE
to the
SANDIA NATIONAL LABORATORIES
Surety Assessment Report of the
NAESB INTERNET Electronic TRANSPORT AND Related Standards
December 07, 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 is the NAESB response. The
NAESB responses indicate whether or not NAESB concurs with the Sandia
finding, analysis and recommendation. If the NAESB response is to
propose that a NAESB standard be updated or changed, the NAESB
response also contains information on how the change 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 actions to be taken by NAESB in lieu of
implementing a recommendation are described. 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, the
NAESB responses will be the basis for changes to the NAESB standards
that will be put in affect with the next release of the NAESB quadrant
standards
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 facilitator of 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 numerous benefits to
the North American energy industry, in the past as well and in the
improvements resulting from this report.
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: NAESB has determined that the Internet ET document
only contains version specifications for 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 Internet ET 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 (underlined denotes
addition to existing manual language; 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
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:
OpenPGP, defined by (IETF RFC 2440) with modifications described in
this specification
OR
PGP 2.6 (minimum) or higher (strongly encouraged), with RSA keys can
be used on a mutually agreed basis
NAESB WGQ QEDM MANUAL, VERSION 1.8, Page 87 (underlined denotes
addition to existing manual language; 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 Netscape®1 and Internet Explorer®3 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
Independent Computer Architecture (ICA®) 6 ‑ Protocol used for remote
control access to an application
Operating Systems:
Operating systems on a client workstation should be multithreaded, and
pre-emptive and should be the latest, stable version and service pack
available as allowed in NAESB WGQ QEDM Appendices B and C.
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 20 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
10.3.x26 The Internet ET manual should be reviewed and updated for
technology changes by the WGQ EDM and REQ/RGQ TEIS subcommittees,
prior to the publication of the WGQ Standards manual and the REQ/RGQ
Standards manual respectively. This review should be accomplished in
sufficient time for review by the respective Executive Committees
prior to publication.
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: NAESB 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 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
Appendix b – FREQUENTLY ASKED QUESTIONS
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 57 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
Q10: What does NAESB say about my organization’s security?
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.
7.1.3 Protection of Sensitive Information
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 Internet ET
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: NAESB agrees that private keys are sensitive
information. In addition to the changes indicated below, please 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:
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 20 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
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.
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 ___
-----------
ELECTRONIC DATA INTERCHANGE TRADING PARTNER AGREEMENT
-----------------------------------------------------
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)___________________________
Basic Authentication Password: __(to be sent separately)________________________
HTTP to/from Tag:
______________________________________________________
Is the “transaction set” supported in the HTTP envelope (Yes/No)?
________________
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)______________________________
Basic Authentication Password: (to be sent separately)___________________________
HTTP to/from Tag:
______________________________________________________
Is the “transaction set” supported in the HTTP envelope (Yes/No)?
________________
[Parties should execute a separate Exhibit for each different URL.]
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. 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 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.
7.1.5 Sharing of Keys
Sandia Finding: The Internet ET Standard is ambiguous about the
sharing of public keys.
Sandia Analysis: The Internet ET Standard states “The Private Key must
be known only to the company that generated it” (Internet ET 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: NAESB 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:
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 19 (underlined denotes
addition to existing manual language; 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 a secure
manner such as via postal or courier mail. Key policies, including key
exchange policies should be communicated to trading partners.
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 45 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
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 event
that a Private Key needs to be exchanged, the exchange should occur in
a secure manner such as postal or courier mail.
You should never divulge your Private Key to another party must use
the utmost care in protecting your Private Key. If an un-trusted party
has your Private Key, your security is compromised. It is 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 (Internet ET 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 partners. The following are the
recommended changes to the NAESB Internet ET manual:
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 13 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
If trading partners mutually agree to use signed Receipts, then the
application would additionally attach a digital signature to the
Receipt.
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 14 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
Non-Repudiation
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 include in the Internet ET package a digital signature that is
created using their Private Key. The Receiver knows the Sender is
legitimate by decoding the digital signature using the Sender’s Public
Key.
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 15 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
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).
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
*
Encrypts payload
*
Prepares digital signature if necessary
*
Uses browser to create Electronic Package multi-part HTTP Request
with header data elements and payload.
*
Uses HTTP POST to send the electronic package to the Receiver

*
Receives the HTTP Request on their Web/HTTP Server
*
Validates Sender information from HTTP Request Header data
elements and payload
*
**Decrypts payload file
*
Prepares Receipt
*
Checks digital signatures if necessary
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:
*
Envelope header. This section contains the envelope information
needed to communicate who the Sender and Receiver are, as well as
other envelope information.
*
Payload. This section contains the payload file. Internet ET
allows for only one payload file per package.
*
Digital Signatures. If used, the The package should contain a
section that is the digital signature.
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 23 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
If trading partners agree to implement signed receipts, then the The
sending party must include 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, the The Server
applies a digital signature to the ‘gisb-acknowledgement-receipt’ and
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 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
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 signedProduce a digital signature over the
‘gisb-acknowledgement-receipt’ created in step 5.
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 37 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
If signed Receipts are used, the The ‘gisb-acknowledgement-receipt’
including the ‘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)
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)
*
The first body part contains human readable content in HTML. The
second body part contains machine readable content in plain text.
Additionally, consenting trading partners can mutually agree to
digitally sign error notifications.
*
If digital signatures are used, the The multipart/report
containing the Error Notification is used to create a digital
signature body part, identified by a ‘content-type’ of
application/pgp-signature. Both the multipart/report Error
Notification and application/pgp-encrypted digital signature body
parts are combined in a multipart/signed envelope.
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.
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.
When digital signatures are applied, on a mutually-agreed-upon basis,
the The digitally signed HTTP Response received by the Sender of the
transaction may should be verified to ensure non-repudiation of
receipt of the transaction.
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” (Internet ET 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…” (Internet ET 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”
(Internet ET page 191 (see also Internet ET page 190), implying 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: 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:
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 24 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
Data Dictionary for Internet ET
Business Name
Definition
Format
Usage*
Condition
receipt-security-selection
used to request signed receipts
signed-receipt-protocol=required,pgp-signature;signed-receipt-micalg=required,md5
in Request;
MA
used in file transmittal and in posting error notifications
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:
1.
from
2.
to
3.
version
4.
receipt-disposition-to
5.
receipt-report-type
6.
input-format
7.
input-data
8.
receipt-security-selection
Mutually Agreed Upon Data Elements
9.
transaction-set
10.
receipt-security-selection
11.
refnum
12.
refnum-orig
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 51 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
Internet ET Standard Error Codes and Messages
Validation Code
Description
Data Element
Data Element Required or Mutually Agreed
EEDM100
Missing ‘from’ Common Code Identifier code
From
required
EEDM101
Missing ‘to’ Common Code Identifier
To
required
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 Identifier
From
required
EEDM106
Invalid ‘to’ Common Code Identifier
To
required
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 mutually agreed
receipt-security-selection
mutually agreed
EEDM113
Invalid ‘receipt-security-selection’
receipt-security-selection
mutually agreedrequired
EEDM114
Missing ‘receipt-disposition-to’
receipt-disposition-to
required
EEDM115
Invalid ‘receipt-disposition-to’
receipt-disposition-to
required
EEDM116
Missing ‘receipt-report-type’
receipt-report-type
required
EEDM117
Invalid ‘receipt-report-type’
receipt-report-type
required
EEDM118
Missing ‘receipt-security-selection’
receipt-security-selection
mutually agreedrequired
EEDM119
Mutually agreed element, refnum, not present
Refnum
mutually agreed
EEDM120
Mutually agreed element refnum-orig not present
refnum-orig
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 signature not matched
file itself
required - security
EEDM699
Decryption Error
required for general decryption errors not specifically identified by
OpenPGP or PGP messages or exit codes
EEDM701
Sending party not associated with Receiving party
required
EEDM702
Package file format not recognized by Receiving party
required when the file format is not recognized by the receiver (e.g.
not expecting 855 or not expecting Flat-File or XML)
EEDM703
Data set exchange not established for Trading Partner
required if the translator does not handle this exception
EEDM999
System error
required for general system errors to indicate severe errors in
processing at the receiving site
WEDM100
Transaction set sent not mutually agreed
transaction-set
mutually agreed
WEDM102
‘receipt-security-selection’ not mutually agreed
receipt-security-selection
mutually agreed
WEDM103
Missing ‘receipt-security-selection’
receipt-security-selection
mutually agreedrequired
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” (Internet ET 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: Please refer to proposed standards manual changes made
in Sandia response numbers 7.1.6, and 7.1.7.
7.1.9 Abnormal Error Notification Usage
Sandia Finding: The Internet ET Standard does not describe “abnormal”
Error Notification usage.
Sandia Analysis: The Internet ET 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.
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 normally used for decryption errors are detected after the Internet
ET Receipt has been sent.
7.1.10 Bogus Decryption Errors
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.
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, then the receipt of a 997 response will
indicate successful decryption. For other file formats, an explicit
http(s) response can be sent. In all cases, responses must be sent in
the timeframe specified in each quadrant’s standards, or less than 60
minutes from initial payload receipt.
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 20 ( underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
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.
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 Internet ET Standard (Internet ET 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 Internet ET
Standard.
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. Please
refer to standards manual changes made in the NAESB Response to Sandia
item number 7.1.6.
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” (Internet ET 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”
(Internet ET 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.
Sandia Recommendation: Revise all definitions to be consistent.
NAESB Response: NAESB agrees with the Sandia recommendation. The
following are the recommended changes to the NAESB Internet ET manual.
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 17 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
10.2.24 ‘Exchange Failure’. An exchange failure is when a sending
party’s NAESB Internet ET server has had three or more protocol
failures within a 30 minute period. and no more than two hours.
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 18 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
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” (Internet ET 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”
(Internet ET 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.
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 15 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
10.1.9 Trading Partners should mutually select and agree to either the
current, or the immediately previous, published use a version of the
NAESB Internet ET standards as a basis under which to operate, unless
specified otherwise by an applicable regulatory authority. government
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).
NAESB WHOLESALE GAS QUADRANT QUADRANT ELECTRONIC DELIVERY MECHANISM
MANUAL, VERSION 1.8, Page 28 (underlined denotes addition to existing
manual language; strike-through denotes deletion from existing manual
language)
4.1.39 Trading Partners should mutually select and utilize a agree to
use either the current, or the immediately previous, published version
of the NAESB WGQ QEDM standards as a basis under which to operate,
unless specified otherwise by an applicable regulatory authority.
government agencies. Trading Partners should also mutually agree to
adopt later versions of the NAESB WGQ EDM standards, as needed, again
unless specified otherwise by government agencies.
NAESB RETAIL ELECTRIC/GAS QUADRANT QUADRANT ELECTRONIC DELIVERY
MECHANISM MANUAL, VERSION 1.0, Page 64 (underlined denotes addition to
existing manual language; strike-through denotes deletion from
existing manual language)
RXQ.5.1.6 Trading Partners should mutually agree to select and use a
either the current, or the immediately previous version of the NAESB
RXQ model business practices under which to operate, unless specified
otherwise by the Applicable Regulatory Authority.
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.
Alternatively, the adversary could reuse Refnums.1 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” (Internet ET 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.
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 Internet ET 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 abuses described in paragraph 1 above,
users of these data elements should be aware of these conditions and
monitor for these abuses. For the 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.
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 language noting
the potential for abuse of these data elements, when used.
NAESB INTERNET ET MANUAL, VERSION 1.8, Page 28 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
Abuse of Refnum and Refnum-orig
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-orig for the
receipt and delivery functions.
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
First resend
223467890123457
123467890123456
New package
123467890123456
123467890123456
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?
NAESB Response: In the scenario defined by Sandia, a proper receipt
(including authentication and decryption) has been received by the
Sending Party. According to Internet ET standards, the package has
been sent. It appears that Sandia’s comments focus 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 the NAESB standards manuals for each Quadrant. The
Internet ET model focuses on the transfer of the package itself.
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…” (Internet ET page 159),
yet the Standard also states “RXQ.7.3.15 Trading partners should
implement all security features…via a commercially-available
implementation” (Internet ET 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.
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.3.15 Trading partners should implement all security features
(privacy, secure authentication, integrity, and non‑repudiation) using
a file‑based approach using via a commercially-available
implementation of:
*
An OpenPGP product as defined by IETF RFC 2440, or
*
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
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. However,
the recommendation that NAESB use both SSL encryption and a logon
authentication for the central address repository would 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 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.
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.
NAESB WHOLESALE GAS QUADRANT QUADRANT ELECTRONIC DELIVERY MECHANISM
MANUAL, VERSION 1.8, Page 92 (underlined denotes addition to existing
manual language; 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**
SMTP 25
Allowable UDP Ports (not TCP ports)
Secure ICA® 1604
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.
**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.
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. There are
no security benefits gained by using the specified ports. NAESB has
proposed removing additional ports within the implementation manual
per changes made in the NAESB Response to Sandia number 7.1.18. Any
additional security standards specifications could 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.
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 may be susceptible to replay attacks. NAESB has
implemented the same level of timestamp verification for all file
content formats, including Batch FF/EDM. 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”,,
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.
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 beneficial to refer to a
well-known standards organization such as SANS9 or NIST10 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
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
Internet ET Standard?
• What are “open standards” (I Internet ET page 155)? (Are open
standards the same as non-proprietary standards?)
• What is a “gisb-acknowledgement-receipt” (Internet ET page 164)?
• What is a “transaction set” (Internet ET page 174)?
NAESB Response: NAESB has reviewed the final version of the Internet
ET standards manunal and compiled the comments below regarding each
item:
*
“QEDM standards” are described in the Internet ET manual on page
5. The QEDM standards are those standards that are specific to
each of the industries that are using the Internet ET as their
transport mechanism.
*
“Open standards” – NAESB has a philosophy of not picking “winners
and losers” in regard to commercially available products and
technology. Where appropriate NAESB standards are written to
encourage market place participation and not vendor-specific
solutions. An unofficial definition of “open standard” is ‘a
standard that is publicly available and has various rights to use
associated with it.’
*
“gisb-acknowledgement-receipt” – is used as the acknowledgement
receipt for the Internet ET. It is described on page 37 of the
Internet ET manual. The name is actually a hold over from the
value given during the time NAESB was only developing standards
for the Natural Gas Industry - Gas Industry Standards Board
(GISB).
*
“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
corresponding 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 (underlined denotes
addition to existing manual language; strike-through denotes deletion
from existing manual language)
transaction-set
name of the document type being sent
8 character code; refer to NAESB REQ and WGQ Implementation Guides,
Related Standards Tab, Hypertext Transfer Protocol (HTTP) section,
HTTP transaction-set Code Values table.
in Request;
MA
used in file transmittal
7.3.2 Strange Numbering
Sandia Finding: Why are the RXQ items not numbered consecutively? They
start with 0.1.1 (Internet ET 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 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.
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” (Internet ET page 160).
Presumably this is not one of the numbered paragraphs (Internet ET
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: NAESB has conducted a thorough review of the Internet
ET standards and resolved and confirmed all referenced standard
numbers.
7.3.4 Multiple Definitions
Sandia Finding: Many items, such as the definition of Exchange Failure
(Internet ET 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
Internet ET, has similar problems.
NAESB Response: NAESB has conducted a thorough review of the Internet
ETstandards and clarified 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
declines to 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.
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 (Internet ET page 166). The same is true of HTTP (see
RXQ.0.2.92 (page 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.
1Netscape® is a registered trademark of Netscape Communications Corp.
3Internet® 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.
ICA® is a registered trademark of Citrix Systems Inc.
JAVA® is a registered trademark of Sun Microsystems, Inc.