Upgrading to PCI DSS 3.0: Key Changes and Implementation Strategies
This document outlines critical updates from PCI DSS version 2.0 to 3.0, effective January 2014. It highlights key areas of change including penetration testing methodologies, system component inventory requirements, vendor relationship management, anti-malware strategies, and physical access controls. Notably, the importance of maintaining accurate documentation and compliance is emphasized. It also presents a case study from Sacramento State University, showcasing proactive measures taken to ensure compliance, enhance security frameworks, and mitigate risks within financial services.
Upgrading to PCI DSS 3.0: Key Changes and Implementation Strategies
E N D
Presentation Transcript
Riding the wave from PCI DSS Ver 2.0 to 3.0 Ed Hudson, Systemwide Director, Information Security Gina Curry, Director, Student Financial Services Center & University Bursar, CSU Sacramento
Summary Of Changes • Effective January 2014 • Change Types • Clarification • Additional Guidance • Evolving Requirement (20)
5 Key Areas • Penetration Testing • Inventorying of System Components • Vendor Relationships • AntiMalware • Physical Access and Point of Sale (POS)
Penetration Testing (11.3) • Penetration testing must follow “Industry Accepted Methodology” • Best Practice until June 30, 2015 • Why is this an issue?
Inventorying System Components (2.4) • “Maintain an inventory of system components that are in scope for PCI DSS • All hardware (Virtual or Physical) • Software (Commercial or custom) • Applications (off the shelf, external or internal) • Requires that assessors “verify a list of hardware and software components including a description of function • Authorized Wireless AP (11.1.1)
Vendor Relationships (12.8.5 & 12.9) • Requires explicit documentation • Which PCI requirements are managed by you, or by a vendor and which vendors (Matrix) • Matrix • Contractual requirements
AntiMalware(5.1.2) • Requires campuses to “identify and evaluate evolving malware threats for systems not commonly affected • Requires specific authorization from management to disable or alter antivirus and that is time limited
Physical Access and POS (9.3) • Control access for onsite personnel • Access be authorized and based on job function • Revoked immediately upon termination • Protect devices from tampering/substitution (9.9) • Consider non standard POS • Food Trucks, carts etc • Inventory and regular checking/inspection and policy
Building a plan • Partner on ownership • Engage senior executives • Plan • Communicate
Case Study: Sacramento State • Partner – SFSC partnered with the campus ISO • Plan – ISO and SFSC implemented required training, document gathering and periodic review • Developed tracking process • Engaged Administration • Imposed “penalties” for non-compliance (“Shut ‘er Down)
Case Study: Sacramento State • ICSUAM –Section 3102.05 http://www.calstate.edu/icsuam/sections/3000/3102.05.shtml • Write a Campus Policy to support the ICSUAM http://www.csus.edu/umanual/admin/ADM-0117.html
Case Study: Sacramento State • Report goes at least annually to Vice President for Administration and Business Affairs and the Vice President & Chief Information Officer • To date, 3 departments were “shut down” until they could come into reasonable compliance
Case Study: Sacramento State • You are welcome to copy our templates for your use • There is also a sample training presentation available • http://www.csus.edu/irt/is/pci/presentations/index.html
