Navigating the Regulatory Maze: Notre Dame’s PCI DSS Solution

1. Navigating the Regulatory Maze:Notre Dame’s PCI DSS Solution EDUCAUSE Midwest Regional Conference March 17, 2008

2. Agenda • PCI DSS Background • Notre Dame’s Environment • Payment Card Environment Design • Networking Infrastructure • Deployment: Departments and Decentralized IT

3. Visa Cardholder Information Security Program (CISP) Mastercard Site Data Protection Program (SDP) American Express Data Security Standard (DSS) Discover Information Security Compliance Program (DISC) PCI DSS History Payment Card Industry Data Security Standard (PCI DSS)

4. Introducing the Digital Dozen

5. Who Must Comply? • “Payment Card Industry (PCI) Data Security requirements apply to all Members, merchants, and service providers that store, process or transmit cardholder data.” • “Additionally, these security requirements apply to all system components which is defined as any network component, server, or application included in, or connected to, the cardholder data environment.” That Probably Means You

6. Merchant Levels

7. Merchant Levels • All merchants, regardless of level, must comply with all elements of the PCI DSS standard! • Merchants at different levels have different validation requirements

8. Consequences • Reputational Risk • What will the impact be on your institution’s brand? • Mandatory involvement of federal law enforcement in investigation • Financial Risk • Merchant banks may pass on substantial fines • Up to $500,000 per incident from Visa alone • Civil liability and cost of providing ID theft protection

9. Consequences • Compliance Risk • Exposure to Level 1 validation requirements • Operational Risk • Visa-imposed operational restrictions • Potential loss of card processing privileges

10. Agenda • PCI DSS Background • Notre Dame’s Environment • Payment Card Environment Design • Networking Infrastructure • Deployment: Departments and decentralized IT

11. Notre Dame’s Environment, Circa 2006 • Over 70 merchant accounts, 15 applications • No central oversight • One day all of that changed…

12. 12

13. Notre Dame’s Approach • Conducted a risk assessment in conjunction with a PCI consulting firm • From that, launched a credit card security program • First Goal: Minimize on-campus card processing • Second Goal: Migrate existing systems to a dedicated, isolated network • First, reduce our footprint and then secure that footprint to the greatest degree possible

14. Agenda • PCI DSS Background • Notre Dame’s Environment • Payment Card Environment Design • Networking Infrastructure • Deployment: Departments and decentralized IT

15. Design: ND’s PCI Architecture 15

16. System and Security Components Firewall and VPN Two factor authentication to infrastructure Tripwire server integrity assurance Juniper IDS POS clients and servers Infrastructure – NTP, DC, ePO, monitoring, KVM, central logging, etc. Device configuration standards

17. Firewall and IDS design Firewall isolates all PCI traffic Single External Physical interface Single Internal interface with multiple VLANs Zones organized by function Some special zones for campus systems Remote Sites connected through VPN concentrator Passive IDS (tried IPS) monitors all internal traffic

18. Sidewinder Firewall Application Proxy firewall Default deny inbound and outbound Group based VPN, access restricted by job function Least privilege rule base All access explicitly controlled

19. Key Internal Zones

20. Key Internal Zones

21. Key Internal Zones

22. Isolating Systems

23. Isolating Systems

24. Agenda • PCI DSS Background • Notre Dame’s Environment • Payment Card Environment Design • Networking Infrastructure • Deployment: Departments and decentralized IT

25. Network Design From the PCI Standards Document: Encryption of data over open, public networks Follow change control procedures Review logs for all system components daily

26. Challenges Encryption of data over open, public networks. Required over ‘secure’ vlans?

27. Challenges Follow change control procedures. Initial design thoughts incorporated ‘secure’ vlans that we present at each endpoint on campus. This would have involved implementing change control on more than 150 network devices, including access layer switches. Review logs for all system components daily. On > 150 devices?

28. Devices requiring change control with ‘secure’ vlan

29. Our solution: Remote site VPN’s Utilizes Cisco 3015 VPN concentrator with Cisco 851 VPN routers for endpoints. Extends the PCI network where we need it. We provide user subnet space based on customer need: Stand-alone credit card terminals POS devices Single use computers

30. Additional Benefits of VPN The VPN tunnel provides a secure method of managing network devices. Provides a means of remote access for system administrators Fewer devices to manage. Provides for easier additions to the PCI network.

31. Agenda • PCI DSS Background • Notre Dame’s Environment • Payment Card Environment Design • Networking Infrastructure • Deployment: Departments and decentralized IT

32. Deployment: Departments and Decentralized IT

33. Two Types of Support • Central IT • Fewer technical users. • Existing payment solutions are often inherited. • Responsibility for payment system is often not clearly defined. • Departmental IT • Internal processes and procedures. • Often very small staff, broad responsibilities. • Payment solutions are often provided by external vendors. • Responsibility for payment system is often inherited.

34. Existing systems • Food Services • Many terminals • Other services blended in: vending machines, food service displays, and campus “Domer Dollars” • Many locations • Blend of commercial and custom software • Departmental IT • Theater Ticketing and Events • Single location • Mobile and static workstations • Web driven • Single commercial software package • Only standard transactions • Central IT

35. Deployment Steps • Review existing architecture • Design solution • Build required resources • Test • Migrate into production • Often in phases • Often unexpected hurdles due to legacy systems and applications

36. Challenges • Process: creating a controlled system for adding new systems and handling changes. • Lack of vendor documentation of protocols – many large high port groupings, reliance local broadcast for discovery, etc. • Split system administration • DR for systems designed without DR capabilities.

37. Lessons Learned • Review vendor documentation and current implementation. • Historic designs are often still in use. • Dataflow diagrams are crucial. • Provide a fast troubleshooting process and a defined support team. • Provide a single point of responsibility with backup for migrations.

38. Questions