Tackling Campus-Wide E-commerce

1. Tackling Campus-Wide E-commerce @ University of Richmond by Troy Boroughs Copyright Troy Boroughs 2007. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

2. Introduction • For years, the University of Richmond has endeavored to provide a centralized, consistent e-commerce platform for tuition, student fees, events, campus cards, online giving, dining, ticketing, etc. • In June 2005, Payment Card Industry Data Security Standards (PCI DSS) were put into effect to dictate effective management of credit card systems or risk severe penalties. • This presentation will discuss our university’s challenges and lessons learned in dealing with e-commerce issues such as centralized ownership and policy development, vendor selection, achieving PCI DSS compliance, and choosing a campus-wide compliance strategy. • This is designed as a collaborative session, so if your institution has developed an e-commerce best practice or solution, please share!

3. E-commerce: Our Definition • The University of Richmond initially defined e-commerce as: accepting, capturing, securing, storing, transmitting, processing, integrating, reconciling and supporting online payments that use credit cards, debit cards, electronic checks, or electronic fund transfers (EFT). • We later amended this definition to include all applications, systems, processes, or services—electronic, manual, or paper—that involve sensitive payment information. • We refer to all such systems as “payment systems” to reduce confusion and facilitate campus communication. • Regardless of how you define it, e-commerce is MUCH more than just a “Pay Now” button on a web page…

4. Behind the “Pay Now” button…

5. Challenges of E-commerce • Many groups, organizations and departments want to offer online credit card and check payments to their customers, yet their needs, resources, and business and system maturity sometimes differ greatly. • E-commerce is complex and requires the cooperation of many different groups, but it’s not always easy deciding who is “in charge”. • Credit card and banking industry security requirements require stricter controls and can result in large costs for merchants (e.g., universities). • We are held accountable for the security practices of our third-party vendors and many legacy payment vendors have difficulty keeping their software “up to code”. • Manual/paper payment processes are difficult to ferret out and control. • Centralized policies, education, management support and communication are required to get everyone singing the same tune.

6. Campus “Hot Spots” • Tuition and student fees • Admissions application fees • Campus Card (OneCard) • Donations/Giving to the University (e.g. Phone-a-thon) • Event registration (many areas on campus!) • Ticketing (athletics, theater, etc) • Dining, catering and retail operations • Bookstore • Student, alumni and academic organizations The University of Richmond consists of a single campus with a total population of ~6100 faculty, staff, and students. We utilize 11different payment systems, involving 55 people in 14 offices…

7. PCI DSS • In January 2005, VISA and MasterCard announced a Payment Card Industry Data Security Standard (PCI DSS) and fully implemented it as a universal requirement on June 30, 2005. Failure to comply with these standards can result in either or both of the following two penalties: • Fines of $50,000 to $500,000 per violation • Loss of credit card services for the entire organization • The PCI DSS is based on 12 industry security best practices. In order to maintain compliance with PCI DSS, merchants (e.g., universities) must: • Implement the 12 security best practices: (https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf) • Complete an annual self-assessment: (https://www.pcisecuritystandards.org/pdfs/pci_saq_v1-0.pdf) • Pay for and pass quarterly network vulnerability scans by a PCI-approved scanning vendor • These requirements are evolving to become even more restrictive (e.g., scanning for web and application vulnerabilities such as cross-site scripting and SQL injection, etc)

8. The 12 Requirements of PCI DSS • Build and Maintain a Secure Network • Install and maintain a firewall configuration to protect data • Do not use vendor-supplied default passwords/parameters • Protect Cardholder Data • Protect stored data • Encrypt transmission of cardholder data across networks • Maintain a Vulnerability Management Program • Use and regularly update anti-virus software • Develop and maintain secure systems & applications • Implement Strong Access Control Measures • Restrict access to data by business need-to-know • Assign unique IDs to each person with computer access • Restrict physical access to cardholder data • Regularly Monitor and Test Networks • Track and monitor all access to network resources and cardholder data • Regularly test security systems and processes • Maintain an Information Security Policy • Maintain a policy that addresses information security

9. Why is PCI DSS Compliance Important? Consider this scenario… • Your institution uses a payment system (regardless of whether it is hosted on campus or by a third-party vendor) • The payment system is breached and cardholder data is compromised • If your institution or your vendor is found not to be PCI DSS compliant, you may be liable for any or all of the following: • Fines imposed by acquiring bank and/or payment brand • Costs to notify cardholders • Credit card replacement and remediation services for impacted cardholders • Repayment of fraudulent charges that result from data breach • Onsite forensics audit by a PCI-Qualified Data Security Company • Level 1 merchant certification by a PCI-Qualified Data Security Company • A Forrester report details the cost per breached record from $90 to $305. A breach that exposes data for 10,000 cardholders could cost $900,000 to $3 million. • A “small” breach could cost your institution millions of dollars not to mention bad publicity, loss of reputation/trust…and your job!!!

10. What is PCI DSS Compliance? • To promote standardization and adoption of the PCI data security requirements, the PCI Security Standards Council (https://www.pcisecuritystandards.org) was established by the major payment brands (Visa, MC, Amex, Discover, JCB). This body enhances and promotes a common set of data security standards. However, PCI DSS compliance is enforced individually and differently by each payment brand. To make it even more interesting, the standards are administered by your individual acquiring bank and are interpreted by PCI Qualified Security Assessors (QSAs). For institutions of higher education, your acquiring bank is the key! • Visa’s requirements (known as the Cardholder Information Security Program or CISP) are the most thorough, best documented, and clearest to understand. Therefore, if you comply with CISP requirements, you will be in better shape than most. More information about Visa’s program can be found at http://www.visa.com/cisp. • Compliance requirements are defined under two categories: • Merchant – organization that captures, processes, stores, or transmits credit cards on its own behalf (e.g., a college or university) • Service Provider – organization that captures, processes, stores, or transmits credit cards on the behalf of others (e.g., your third-party payment vendor)

11. Visa-Defined Merchant Levels • Level 1 – Merchants processing more than 6 million Visa transactions per year, regardless of acceptance channel (online, retail outlets, etc); also merchants (of any size) that have suffered a cardholder data breach or are determined by Visa to be high risk. • Level 2 – Merchants processing 1 million to 6 million Visa transactions per year, regardless of acceptance channel • Level 3 – Merchants processing 20,000 to 1 million Visae-commerce (online) transactions per year • Level 4 – Merchants processing fewer than 20,000 Visae-commerce transactions per year; also merchants processing up to 1 million transactions per year, regardless of acceptance channel

12. Merchant Levels Explained • Not all payment brands (Visa, Mastercard, Amex, Discover, JCB) define merchant levels with the same criteria • Your acquiring bank is the institution that definitively determines your institution’s merchant level based on the number of transactions you conduct per payment brand. For example, your Visa merchant level is determined based on your number of Visa transactions, your Amex merchant level is determined based on your number of Amex transactions, etc • IMPORTANT: Regardless of level, all merchants and service providers are responsible for achieving and maintaining compliance with PCI data security standards. Your level simply determines how and when your compliance is validated. • For level 1-3 merchants, compliance validation requirements and timelines are determined by the payment brands. For level 4 merchants, compliance validation requirements and timelines are determined by your acquiring bank. • HINT: If you haven’t already done so, get to know your contacts at your acquiring bank as soon as possible!

13. PCI Validation Requirements * All merchants, regardless of level, are required to comply with PCI DSS! ** Newly identified merchants typically have 1 year to become compliant.

14. PCI DSS and Vendor Hosted Solutions • To protect your institution and its constituents, your university and all of its payment vendors should be PCI DSS compliant • If you have outsourced your payment systems to be hosted by a vendor, require them to provide you with either: • Annual proof of PCI DSS compliance as a “Service Provider”. This is usually in the form of a compliance certificate that the vendor should easily be able to provide you. Visa’s web site also contains a list of approved service providers. • Letter from an officer of the vendor’s company stating that they are pursuing and will achieve PCI DSS compliance as a “Service Provider” by an agreed upon date. • Insist on language in your contract with the payment vendor requiring the vendor to maintain PCI DSS compliance for the duration of their relationship with your institution.

15. PCI DSS and Payment Applications • Visa offers a PCI validation process called “Payment Application Best Practices (PABP)” for payment vendors to ensure that their software applications meet PCI standards. The PABP has been adapted into a new security standard (PA DSS) that will be released in 2008. Visa publishes a list of vendor products that have already met these standards and have achieved PABP status. More information can be found here: http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html • If you are about to purchase a payment solution that you will host on your campus servers, ask the following: • Is the vendor’s product and version listed on Visa’s list of CISP-validated payment applications (see website above)? • If not, is the vendor currently seeking PABP validation for their product? • If not, include language in the vendor contract requiring them to achieve PABP validation by an agreed upon date and to maintain PABP status for each product version they provide in the future. Otherwise, your organization is assuming full responsibility for the vendor’s coding and security practices (or lack thereof).

16. Who’s Responsible for E-commerce at your Institution? • E-commerce and PCI DSS compliance are shared responsibilities that affect many aspects of an organization—financial, technical, cultural, and political. • Recommendation: Form a steering committee consisting of Finance, Business, Audit and IT folks. Preferably, have the CFO and CIO involved. This is too big for just one group to handle.

17. University of Richmond’s Story (1 of 3) • In 2001-2002, the Finance, Business and IT departments were peppered with requests for new e-commerce systems and capabilities. • We formed an E-commerce Committee to centralize and prioritize payment system requests. • When we became aware of the new PCI DSS requirements in 2005, the E-commerce Committee developed a policy to specifically address campus payment systems and processes. This policy has been revised several times to evolve with changes in PCI DSS: http://controller.richmond.edu/guidelines/ecommercepolicies.pdf • We also performed a self-assessment that involved interviewing, auditing, documenting and educating every area and system on campus that handled credit cards. • We used the self-assessment exercise to identify and correct any critical issues as well as educate each of these areas about their responsibilities. • We contracted with an approved scanning vendor (ASV) to perform a network penetration test as well as a PCI security vulnerability scan. The PCI scan is performed every 90 days to maintain compliance.

18. University of Richmond’s Story (2 of 3) • We worked (and continue to work) with our third-party vendors to verify that they are either PCI DSS compliant as “Service Providers” or have achieved PABP validation for their payment systems. • Most of our payment vendors do not have particularly thorough or detailed documentation describing how their systems capture, process, store or transmit cardholder information in a secure manner. So, we spent many months grilling our vendors for information to be able to develop our own product and process diagrams and documentation. We were forced to become security forensic experts—trusting no one and verifying everything ourselves. We learned that the first response to a question was typically a stock answer and we had to keep asking until we learned “the truth”. We learned to be relentless (as though our jobs depended upon it). • Because of vendor and product changes, PCI changes, and personnel changes, we found that education and communication must be constantly reinforced. To facilitate this, we created a listserv to communicate with all payment offices across campus. In addition, we instituted an annual e-commerce workshop as well as an annual audit of each payment office. • We do not have personnel dedicated to supporting e-commerce—our E-Commerce Committee meets periodically to address needs as they arise.

19. University of Richmond’s Story (3 of 3) • We contacted our acquiring bank to find out what our merchant level would be. • Much to our surprise, our contacts at our acquiring bank knew less about PCI DSS than we did! Our acquiring bank had outsourced their PCI compliance administration to a Qualified Security Assessor with which our university had no relationship. Our acquiring bank had incorrectly assumed that the QSA was contacting its merchants. After several weeks, our acquiring bank informed us that they were still evaluating their database to determine level 3 and level 4 merchants and would communicate accordingly. Until then, “we shouldn’t worry about it.” (!!!) • We found that our acquiring bank, like other acquiring banks, had been focusing the majority of its efforts on its level 1 and 2 merchants. Why? After Sep 30, 2007, Visa began assessing banks fines of $5,000 per month for each level 1 and 2 merchant that continued to store prohibited cardholder data. After Dec 31, 2007, these fines increase to $25,000 per month per non-compliant merchant! • However, Visa mandated that all acquiring banks provide them with a prioritized list and plan of action by July 31, 2007 to validate all of their merchants for PCI DSS compliance. • Recently our bank informed us that we were a level 4 merchant and were considered “within compliance time frames.”

20. Where Richmond is now… • We are working with our acquiring bank, but we are not waiting on them. • We have several e-commerce systems of various ages, vendors, and technologies. • Our initial strategy was to outsource as many payment systems as possible. However, several of our legacy vendors do not offer hosted solutions or the payment office finds the costs prohibitive (but it’s cheaper than paying PCI fines!). This is an on-going “negotiation”.  • Our second strategy was to move all payment systems into a separate campus network. This involves 10% of our campus servers and requires considerable effort, but it allows us to more easily meet PCI DSS requirements and reduces our scope and risk. Lesson Learned: Make the outsourcing strategy work! • We haven’t yet discovered a one-size-fits-all vendor solution that meets all of our payment needs, but some are getting close. • Unfortunately, PCI requirements, vendor payment systems, and security vulnerabilities are continuously evolving, making compliance maintenance a never ending endeavor!

21. Payment Systems @ UR • Nelnet * (hosted solution that provides real-time online processing of student tuition and fees) • Kintera * (hosted solution for alumni event payments and donations) • ActiveNet * (hosted solution that provides online registration/payment for non-credit programs) • Tickets.com * (hosted solution for online athletic event ticket sales) • CommonApp * (hosted solution for undergraduate admission application fees) • Sallie Mae Solutions (real-time deposits to our OneCard system—home grown using SMS APIs) • POS Partners (batch processing for phoned in or mailed in credit card transactions) • Southern DataComm (POS for theater and cultural event ticket sales) • Nebraska Books (POS for Bookstore inventory and sales) • Micros (POS for campus dining and retail operations) • RuffaloCody’s CampusCall (captures credit card information for the annual fund phone-a-thon pledge drive) * Hosted externally by vendor

22. Recommendations • If you haven’t yet started a PCI DSS compliance project, start now! • Form a PCI compliance task force or committee (include both functional and technical folks). • Visit and interview all the payment offices on campus to learn as much as you can about the people and systems involved. • Identify “urgent” issues and remediate as best as you can. • Contact your acquiring bank to determine your merchant level so that you understand your compliance validation procedures and timelines. But, don’t wait on them to get started! • Develop a plan to achieve compliance. Do you need to re-architect your network or servers? Can you outsource systems? Do you need to develop policies or procedures? • Develop a plan to maintain compliance…vendors, products, personnel, vulnerabilities, and PCI requirements are always changing. • The onus to demonstrate PCI DSS compliance is on you, the merchant. Begin demonstrating that you are performing your due diligence and taking appropriate steps as soon as possible!

23. How About You? • Where is your institution on the PCI DSS compliance curve? • Do you have resources dedicated to supporting e-commerce? If not, how is it supported? Who’s running the show? • Do you have any best practices or experiences to share? If so, please get involved by contacting the Educause Security Task Force PCI DSS Working Group as follows: • Mark Welch, Co-Chair: mark.welch@nd.edu • Web Site: http://connect.educause.edu/term_view/PCI+DSS

24. Payment Brand Web Sites • Visa (http://www.visa.com/cisp) • MasterCard (http://www.mastercard.com/sdp) • AMEX (http://www125.americanexpress.com/merchant/oam/ns/USEng/FrontServlet?request_type=navigate&page=dataSecurityRequirements) • Discover (http://www.discovernetwork.com/resources/data/data_security.html)

25. Other PCI Web Resources • Educause Connect (http://connect.educause.edu/term_view/PCI+DSS) • Treasury Institute (http://www.treasuryinstitute.org/blog) • PCI Security Standards Council (http://www.pcisecuritystandards.org) • PCI Compliance Demystified (http://www.pcianswers.com) –respected blog, but includes some opinions, not all of which may be accurate • The PCI Forum (http://www.pciforum.us/pci)

26. Thank You! Troy Boroughs Director of Systems & Networks University of Richmond tborough@richmond.edu