ERCOT Key Points - Introduction

1. RMGRR 042 – Mass Transition Process Necessary for PUCT Rule 31416Review of ERCOT Comments and TDTWG InputRetail Market SubcommitteeOctober 11, 2006Adam MartinezMgr, Market Operations DPO

2. ERCOT Key Points - Introduction ERCOT comments are focused on 5 key points. The Market and ERCOT should seek to implement a transport method that… • Implements a proven technology; • Maximizes the transport speed; • Minimizes risk of security breach; • Minimizes liability and risk of confidentiality breach; and • Strives to minimize impact to TX SET 3.0 timeline and budget • Page 1

3. ERCOT Key Points – Detail • Implement proven technology • NAESB provides a transport method for ERCOT and the Market that has already been proven in daily support of transaction processing. • All CRs and TDSPs in the market currently use NAESB to send and receive TX SET transactions to support customer choice. Included in these files are customer data. • New CRs are required to implement NAESB in order to become certified. • NAESB EDM 1.6 that is currently used in the market can support 3 files types – X12, XML and flat file. The Customer Billing information file will be flat file. • Secure FTP and CD/DVD-R are not proven in the market • Page 2

4. ERCOT Key Points – Detail • Maximize transport speed • ERCOT business supports the Market decisions to reduce the overall timeline during a mass transition event. • NAESB improves overall timeline and provides the greatest ability for ERCOT and the Market to respond to a Mass Transition event in expeditious manner. • There is a potential lag time associated with Secure FTP for pick up of data. • Higher chance of lengthening the timeline if information is sent via CD/DVD-R through a courier. • Page 3

5. ERCOT Key Points – Detail • Minimize security risk • ERCOT must follow security guidelines to ensure a minimal level of security against risks, threats, and vulnerabilities • ERCOT Security has identified that NAESB is the option that currently meets security guidelines for transmission of customer data • ERCOT Security has indicated that the framework needed to support Secure FTP may not be implemented under the timeline for TX SET 3.0, may require additional work after go live • ERCOT Security has indicated that the framework needed to support CD/DVD-R may not be implemented under the timeline for TX SET 3.0, may require additional work after go live • Page 4

6. ERCOT Key Points – Detail Data transport options – ERCOT security comparison • NAESB • Pro – Current market standard • Pro – Proven solution for infrastructure’s application, maintenance, and management • Pro – Strong authentication/encryption • Secure FTP • Pro – Strong pipe encryption • Neutral – Partially existing server infrastructure & mgmt infrastructure for static pswds • Con – No existing management infrastructure for ssh-keys • Con – Use of static pswds for authentication creates possibility pswd recovery via brute-force or disclosure at endpoints • Con – Reduced visibility from network security monitoring platform • Con – Additional implementation risk; Additional management/maintenance risk • CD-R / DVD-R • Pro – Easy • Con - Transportation via licensed/bonded couriers • Con – Still need to address encryption of data in transit • Con – Physical media destruction becomes an issue • Con – Need to develop operational procedures and physical infrastructure for media accept/process/store/destroy processes • Page 5

7. ERCOT Key Points – Detail 4. Minimize liability and risk of confidentiality breach • ERCOT Legal has indicated that ERCOT liabilities are minimized by using NAESB to send outbound the Customer billing contact information. • With Secure FTP – Higher liabilities as the data resides on ERCOT servers until MP pick up. • With CD/DVD-R - Higher liabilities when data placed onto a CD/DVD-R and sent out for delivery. • Page 6

8. Data Transport Options – ERCOT Clarification • Market to ERCOT File Transmissions • ERCOT prefers NAESB transport method but will support any of the three options proposed – why? See all 4 points. • If the Market decision is to support only one or two methods, ERCOT’s proposed language would need to be updated to reflect that decision • ERCOT to Market File Transmissions • ERCOT will only use NAESB to transmit outbound Customer Billing Contact Information – why? Minimizes ERCOT liability with respect to Customer Data. • All other response files will be sent from ERCOT to Market will utilize transport methods used for Semi-Annual – why? These files do not have Customer Data, only response of what was received. • Page 7

9. ERCOT CBA / IA Overview Original Slide Revision resulting from RMS input on Next Slide 5. Strive to minimize impact to TX SET 3.0 timeline and budget • Additional implementation costs • NAESB – no additional cost. • Secure FTP + NAESB – $100k to $250k • CD + NAESB – $50k to $100k • If all 3 – Implementation Cost is within bucket of $250k – $500k • Ongoing support • NAESB: no additional staff impact • Secure FTP – additional staff impact to the following groups • Retail Market Testing (1 FTE 30% utilization) • Commercial Operations (1 FTE 10% utilization) • System Engineering & Admin (1 FTE 25% utilization) • CD/DVD-R – additional staff impact to the following groups • Retail Market Testing (1 FTE 50% utilization) • Commercial Operations (1 FTE 10% utilization) • Page 8

10. ERCOT CBA / IA Overview Revised Slide Revision resulting from RMS Input 5. Strive to minimize impact to TX SET 3.0 timeline & budget • Implementation Cost • Base cost of $250k - $500k, addresses the Customer Information/POLR Class process, exclusive of transport method • Processes and reports/extracts to support receiving data, storing data, testing data, determining and reporting POLR customer class, reporting of total ESI ID and total MWh served, transmission of data to POLRS during Mass Transition event • Additional Cost associated with Transport Method • NAESB – no additional cost. • Secure FTP + NAESB – $100k to $250k • CD + NAESB – $50k to $100k • If all 3 transport methods are approved – Implementation Cost is estimated to be ~$625k • Ongoing Support • NAESB: no additional staff impact • Secure FTP – additional staff impact to the following groups • Retail Market Testing (1 FTE 30% utilization) • Commercial Operations (1 FTE 75% utilization) • System Engineering & Admin (1 FTE 25% utilization) • CD/DVD-R – additional staff impact to the following groups • Retail Market Testing (1 FTE 50% utilization) • Commercial Operations (1 FTE 10% utilization) • Page 8

11. TDTWG Review of RMGRR042 Data Transport

12. TDTWG Analysis • TDTWG has reviewed the three data transport options included in RMGRR042. • To ensure the most successful implementation of an option, TDTWG has defined minimum technical requirements in these slides. • While some technical requirements are being provided for each option, certain options may carry risk which may not be mitigated within the technical requirements. • This information should not be interpreted as TDTWG’s endorsement of all three options • Page 10

13. TDTWG Analysis of NAESB EDM v1.6 • Scope: NAESB EDM v1.6 • See: NAESB EDM v1.6 Standards • Update: TDTWG NAESB EDM v1.6 • Use of FF content type • Use of payload mime content header Application/EDI-Consent • Create test scripts, Market certification • Page 11

14. TDTWG Analysis of Secure FTP • Define standards for design, test, certification and implementation for ERCOT server side • Market Interoperability and implementation guidelines and testing • Dedicated Redundant Production Servers / Disaster recovery • Test and Certification Environments • Implement Processes for maintenance, Real-time monitoring & log management • Implement Receipt Acknowledgement (note: outside of the SFTP protocol) • SSH v2 protocol only SFTP Extensions to SSH protocol (no SCP) / SSH key for authentication (no static passwords) • Dedicated identity management process for SSH: • User Create/Update/Delete / Key management – create, expire, revoke / Identity/credential verification and audit • Define data expiration in queue (inbound, outbound) • Payload encryption process development (pgp vs gpg) • Deterministic audit plan for both market and internal audits • Defined availability requirements that can accommodate regular maintenance • Identify support resources to handle outages, interruptions, incidents, and maintenance • Regular external security assessments • Page 12

15. TDTWG Analysis of CD • CD or DVD ROM Not RW • Payload must be encrypted: Payload encryption process development (pgp vs gpg) • Ship 2 (reliable delivery) • Verification of integrity of data prior to shipment and upon receipt • Validated handling procedures for receiving and transmission to processing servers • Validated destruction procedures (CD will not be returned) • Handling procedures or filing, storage before processing • Labeling process for CD • Create test scripts, Market certification • Page 13

16. TDTWG Recap • This information should not be interpreted as TDTWG’s endorsement of all three options. • When asked to provide a recommendation, TDTWG did not. • Page 14

17. ERCOT Summary • Mass Transition Event • Due to security and legal input ERCOT will support NAESB transport method for customer file going from ERCOT to POLR. • All other events • ERCOT prefers NAESB; however, ERCOT will support the combination of the 3 options proposed by Market in RMGRR042 as outlined in the matrix. • Key Points • Implement a proven technology • Maximize the transport speed • Minimize risk of security breach • Minimize liability and risk of confidentiality breach • Strive to minimize impact to TX SET 3.0 timeline and budget • Page 15

18. Questions / Contact Adam D. Martinez Mgr, Market Operations Divisional Projects Organization ERCOT (512) 248-3883 amartinez@ercot.com