How Secure is Your Payment
Card Data?
PRESENTERS
Francis Tam, CPA, CISA, CISM, CITP, CRISC, PCI QSA
Managing Director, IT Security Practice PCI Practice Leader
Francis has practiced public accounting and consulting. He has extensive experience providing information
technology audit and internal control guidance to public and private companies. Francis’ expertise in technology consulting includes payment card industry security, IT governance, systems analysis, requirements analysis, systems selection and configuration, policy development, and more. He is the winner of 1992 AICPA Elijah Watt Sells Award with Highest Distinction in the Uniform CPA Examination.
Kevin Villanueva, CISSP, CISA, CISM, PCI QSA
Senior Manager, IT Security and Infrastructure Practice Leader
Kevin has been in information technology field since 1998 and leads the firm’s information security and
infrastructure practice. He is considered expert-level staff in the areas of information security, disaster recovery planning, and strategic technology planning. He has experience in technology security assessments, systems auditing and assessments, network and system design, disaster recovery planning, information systems
The material appearing in this presentation is for informational purposes only and is not legal or accounting advice. Communication of this
OBJECTIVES
You will leave this session with an understanding of:
• The background, history, compliance, and audit requirements of Payment Card Industry (PCI) Data Security Standards (DSS) • Leveraging PCI DSS audit to achieve audit efficiencies with
other compliance and/or regulatory audits
• Highlights of the changes from 2010 (v1.2) to 201 1 (v2.0)
POLLING QUESTION #1
How would you classify yourself?
1. A level 1 service provider or merchant
2. A non-level 1 service provider or merchant
3. Other
Background & History
: Trustwave’s Global Security Report 2011
CARD BREACHES ARE ON THE RISE
2011 Security Breaches
NOTABLE CARD BREACHES
•
TJX Companies – 2007 – Hackers compromised wireless
network to steal information on approximately 94 million
card transactions.
•
Heartland Payment Systems – 2008 – Hackers attacked
system used to process card transactions. Inserted
malware. Up to 100+ million transactions compromised.
•
Global Payments – 2012 – Hackers attacked GP network. 1.5
million card account numbers accessed. Resulted in Visa
dropping the card processor until they receive a new report
on compliance.
•
Sony PS Network – 2011 – Hackers accessed an old
PCI OVERVIEW
• Not a Federal regulation, but an industry regulation. Nevada, Minnesota and Washington have State PCI compliance laws.
• Purpose is to help prevent credit card fraud and maintain public confidence in payment cards.
• Applies to all entities that process, store, or transmit payment card information need to comply (Primary Account Number “PAN” is the deciding factor.)
• Card transaction players: card brands, merchants, service providers, acquirers, and issuers.
• Effective compliance dates varies depending on merchant level or service provider level and card brand. All deadline enforcement will come from the acquiring bank.
• Card brands have their own compliance programs and are
PCI OVERVIEW
• PCI Security Standards Council (PCI SSC or the Council) founded
in 2006 is responsible for the development, management, education, and awareness of the PCI Security Standards.
• PCI Data Security Standard (PCI DSS) is a comprehensive set of
international security requirements for protecting cardholder data. • Payment Application Data Security Standard (PA-DSS) is a set of
requirements for software vendors to develop secure payment applications.
• PCI PIN Transaction Security (PCI PTS) is a set of requirements for
device vendors and manufacturers for all personal identification
MOBILE COMMERCE
DEVELOPMENTS
•
Retail purchases made through mobile have gone from
6% to 15% of purchases – in only one year
•
25% of consumers engage in online shopping only via
mobile
•
Worldwide mobile payment transactions will surpass
$171.5 billion in 2012, up 62% from $106 million last
year
MOBILE COMMERCE & APPS
How does payment card security compliance apply to:
– Purchases made by consumers through your mobile app or mobile site? – Differences among payment card security at the store, on a computer, or
on a phone?
PCI-SSC has developed Mobile Payment Acceptance Application Categories • Category 1 - Payment application operates only on a PTS-approved mobile device.
• Category 2 - Payment application meets 3 criteria: (1) bundled with a
mobile device, (2) mobile device is purpose built for payment acceptance only, and (3) provides an environment that allows the merchant to meet and
maintain PCI-DSS compliance.
THE ACQUIRER’S ROLE
•
Acquirers (Merchant Bank) are responsible for:
– Ensuring their merchants are PCI DSS compliant
– Managing merchant communications
– Working with their Level 1 merchants until full
compliance has been validated.
• Merchants are NOT COMPLIANT UNTIL ALL REQUIREMENTS have been met and validated.
• Acquirer is responsible for providing Visa their merchants’ compliance status.
ROLES OF THE QSA & ASV
•
QSA – Qualified Security Assessor
– Certified to validate compliance with PCI-DSS
– Qualified Security Assessor companies have been qualified to have their employees assess compliance to the PCI-DSS standard
– Qualified Security Assessors are employees of these
organizations who have been certified to validate an entity’s adherence to the PCI-DSS
•
ASV – Approved Scanning Vendor
– Approved Scanning Vendors are organizations that validate adherence to certain DSS requirements by performing
MERCHANT LEVELS
Transaction volume is based on the aggregate number of Visa transactions (inclusive of credit, debit, and prepaid) from a merchant Doing Business As (DBA).
Merchant
Level Description
1 Merchants processing over 6 million Visa transactions annually (all
channels) or global merchants identified as Level 1 by any Visa region.
2 Merchants processing 1 million to 6 million Visa transactions
annually (all channels)
3 Merchants processing 20,000 to 1 million Visa e-commerce
transactions annually.
4 Merchants processing less than 20,000 Visa e-commerce
SERVICE PROVIDERS
* Level 2 service providers may choose to validate as a Level 1 service provider in order to be listed on Visa’s Global List of Validated Service Providers.
Service
Provider Level Description
Posted on Visa’s Global List of Validated Service
Providers
1 VisaNet® processors or any service provider that stores, processes, and/or transmits over 300,000 Visa transactions annually.
Yes
2* Any service provider that stores, processes, and/or transmits less than 300,000 Visa transactions annually.
VALIDATION REQUIREMENTS
*Network scanning is applicable to any internet facing system.
** Validation requirements are determined by the merchant’s acquirer.
Compliance Actions Group Level Comply with PCI-DSS On-Site Security Assessment Self-Assessment
Questionnaire Network Scan*
Merchant 1 Required Required
Annually
Required Quarterly
2 & 3 Required Required
Annually
Required Quarterly
4** Required Recommended Recommended
SELF-ASSESSMENT
QUESTIONNAIRES (SAQS)
SAQ Description
A
Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants.
B
Imprint-only merchants with no electronic cardholder data storage, or standalone, dial-out terminal merchants with no electronic cardholder data storage.
C-VT Merchants using only web-based virtual terminals, no electronic
cardholder data storage.
C Merchants with payment application systems connected to the
Internet, no electronic cardholder data storage. D
POLLING QUESTION #2
The Payment Card Industry (PCI) Security
Standards Council (SSC) is responsible for enforcing
PCI-DSS compliance.
Highlights of Changes: v1.2-v2.0
HIGHLIGHTS OF CHANGES: V1.2 TO
V2.0
• v1.2.1, which had been in effect since July of 2009, was superseded by v2.0 on October 28, 2010
• Aligned PCI-DSS better with PA DSS and other industry best
practices
• No new requirements; only added guidance or clarifications
HIGHLIGHTS OF CHANGES: V1.2 TO
V2.0
• Added guidance on test procedures and new technologies,
such as virtualization and private cloud adoption
• Recognition of small merchant environments – be more
flexible
HIGHLIGHTS OF CHANGES: V1.2
TO V2.0 EXAMPLES
• Virtualization – req 2.2.1
– In-scope and out-of-scope virtual machines can co-exist as long as there is only one primary function per virtual system component.
• Storage of Sensitive Authentication Data (SAD) - req 3.2
– V2.0 allows the storage of SAD if there is sufficient business justification and the data is stored securely. This is only for card issuers and
HIGHLIGHTS OF CHANGES: V1.2
TO V2.0 EXAMPLES
• Risk based approach for addressing vulnerabilities - req 6.2 & 12.1.2
– Assign risk ranking to vulnerabilities – Also impact reg 6.5.6 and 11.2
HIGHLIGHTS OF CHANGES: V1.2
TO V2.0 EXAMPLES
• Expansion of definition of personnel – req 9.2
– This requirement now applies to “on-site personnel” and not just “employees”
• Support centralized auditing – req 10.5
– Audit data must be able to be moved to a centralized log server, such as syslog-ng, Windows Event Logs.
POLLING QUESTION #3
In PCI DSS v2.0, for req 9 – “Restrict Physical Access
to Cardholder Data”, it was changed such that it
applies to:
1. Only card database administrators
2. Only employees
Key Compliance Tips
KEY COMPLIANCE TIPS
• If cardholder data is not needed, don’t keep it!
• Know what is on your network (run discovery tools: Cornell
Spider, PANbuster, Vericept)
• Maintain a central repository for security-related activities throughout the year (vulnerability scan results,
system/device reviews, diagrams, etc.)
KEY COMPLIANCE TIPS
•
Encrypt databases/files prior to committing them to
backup tape/removable media
•
Install A/V on your database servers that store
cardholder data (or document compensating controls)
•
Segment (“cocoon”) your CDE and use two-factor
authentication for remote access (internal pen testing
is not necessary)
KEY COMPLIANCE TIPS
• In virtualized environments, limit the number of mixed mode
servers (use separate partitions for each virtual host)
• Implement POS systems with point-to-point encryption (P2PE)
functionality (reduces scope)
• Conduct quarterly vulnerability scans and address vulnerabilities immediately
PREPARING FOR A PCI-DSS
ASSESSMENT
• Gather Documentation: Security policies, change control
records, operational procedures, network diagrams, PCI DSS letters, and notifications
• Schedule Resources: Obtain dedicated participation of a
project manager and key people from IT, business operations, human resources, and legal
• Describe the Environment: Organize information about the
POLLING QUESTION #4
Which of the following are ways I can reduce the
scope of a PCI-DSS compliance audit?
1. Use POS systems with point-to-point
encryption functionality
2. Segment the cardholder data environment
3. Delete primary account numbers from systems
4. 1 and 2 only
Leveraging PCI DSS Audit
LEVERAGING PCI DSS AUDIT
• Documentation collected for PCI-DSS requirements can
be repurposed for other audits:
• Test results completed for PCI requirements can be used or relied upon by SAS 70/SSAE16 auditors
• Policies and templates developed for PCI compliance such as information security policies and user request forms can be used for systems without cardholder data
LEVERAGING PCI DSS AUDIT
Description of Good Practices PCI-DSS v2 ISO 27002 HIPAA
COBIT (SOX)
Install and maintain a firewall configuration to protect data
1 11.4.5 § 164.312 (e) (1) DS5.11
Use and regularly update anti-virus software or programs
5 10.4 § 164.308 (a) (5) DS5.9
Assign a unique ID to each person with computer access
8 11.2.1 § 164.312 (a) (1) DS5.4
Regularly test security systems and processes
LEVERAGING PCI DSS AUDIT
• PCI requirements can be used to drive existing internal projects:
• In some areas, PCI requirements may be more stringent than existing practices and used to enforce stronger security. For
example, two factor authentication required for remote access and prohibited weak wireless encryption such as WEP.
LEVERAGING PCI DSS AUDIT
• Conversely, existing internal projects may be used to satisfy some PCI requirements:
• Adopting Cloud Computing (“eliminate” some of the requirements, such as Req. 10, 11.2 and 11.4).
• Safeguarding of private information initiatives, such as Personally Identifiable Information (PII) or Gramm-Leach-Bliley Act, may require Point-To-Point Encryption (P2PE), tokenization or two-factor authentication.
• PCI Website:
www.pcisecuritystandards.org
• PCI DSS v2.0:
www.pcisecuritystandards.org/documents/pa-dss_v2.pdf
REFERENCE MATERIALS
Guidelines for Managing and Securing Mobile Devices in the Enterprise
