HOW SECURE IS YOUR PAYMENT CARD DATA?

CARD BREACHES ARE ON THE RISE

2010 Security Breaches  Food and Beverage – 57%  Retail – 18% Hospitality – 10% Financial – 6% Government ‐ 6%  M O S S A D A M S L L P|  5  Source: Trustwave’s Global Security Report 2010   Education – 1% Construction ‐ 1%  Entertainment ‐ 1% 

NOTABLE CARD BREACHES

• TJX Companies – 2007 – Hackers compromised wireless  network to steal information on approximately 94 million card 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.   • Lush Cosmetics – 2010 – Ecommerce website hacked. 5,000  card transactions accessed. Led to shutdown of their

card transactions accessed. Led to shutdown of their  ecommerce operations.  

• PCI Security Standards Council (PCI SSC or the Council)  founded in 2006 is responsible for the development, 

PCI OVERVIEW

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  M O S S A D A M S L L P|  7  SLIDE7 q p payment applications.  • PCI PIN Transaction Security (PCI PTS) is a set of  requirements for device vendors and manufacturers for all  personal identification number (PIN) terminals, including POS  devices, encrypting PIN pads, and unattended payment terminals.  • Not a government regulation, but an industry regulation.  • Purpose is to help prevent credit card fraud and maintain public 

PCI OVERVIEW

p p p p 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.)  • CaArd transaction players: card brands, merchants, service providers,  acquirers, and issuers. 

• Effective compliance dates varies depending on merchant level orEffective compliance dates varies depending on merchant level or  service provider level and card brand. All deadline enforcement will  come from the acquiring bank. 

THE PAYMENT CARD TRANSACTION

Payment Payment  Brand  Network  Acquirer  (Merchant  Bank)  Issuer  (Consumer  Bank)  Service  Provider  M O S S A D A M S L L P|  9  Merchant  Cardholder 

THE ACQUIRER’S ROLE

•

Acquirers are responsible for:

Acquirers are responsible for:

o

Ensuring their merchants are PCI DSS compliant 

o

Managing merchant communications 

o

Working with their Level 1 merchants until full 

compliance has been validated: 

 Merchants are NOT COMPLIANT UNTIL ALL REQUIREMENTS  have been met and validated

have been met and validated

 Acquirer is responsible for providing Visa their merchants’  compliance status 

HIGHLIGHTS OF CHANGES 

V1.2 – V2.0 

M O S S A D A M S L L P|  17 

HIGHLIGHTS OF CHANGES –

V1.2 TO V2.0

HIGHLIGHTS OF CHANGES –

V1.2 TO V2.0

•

Added guidance on test procedures and new technologies,

Added guidance on test procedures and new technologies, 

such as virtualization and private cloud adoption 

•

Recognition of small merchant environments – be more 

flexible 

•

Eliminate redundant sub‐requirements 

M O S S A D A M S L L P|  19 

HIGHLIGHTS OF CHANGES –

V1.2 TO V2.0 - EXAMPLES

•

Virtualization – req 2.2.1

Virtualization   req 2.2.1

HIGHLIGHTS OF CHANGES –

V1.2 TO V2.0 - EXAMPLES

•

Risk based approach for addressing

Risk based approach for addressing 

vulnerabilities ‐ req 6.2 & 12.1.2 

o Assign risk ranking to vulnerabilities  o Also impact reg 6.5.6 and 11.2  o Implementation date – July 1, 2012 

M O S S A D A M S L L P|  21 

KEY COMPLIANCE TIPS 

M O S S A D A M S L L P|  23 

KEY COMPLIANCE TIPS

KEY COMPLIANCE TIPS (CONT.)

• Encrypt databases/files prior to committing them to backup yp / p g p 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  ) M O S S A D A M S L L P|  25  necessary)  • Institute a verification step for non‐face‐to‐face password  resets (e.g., employee ID) 

KEY COMPLIANCE TIPS (CONT.)

•

In virtualized environments, limit the number of mixed

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

Conduct quarterly vulnerability scans and address 

vulnerabilities immediately 

LEVERAGING PCI DSS AUDIT

•

Documentation collected for PCI‐DSS requirements can

Documentation collected for PCI DSS requirements can 

be repurposed for other audits: 

o Test results completed for PCI requirements can be used  or relied upon by SAS 70/SSAE16 auditors  

o Policies and templates developed for PCI compliance such  as information security policies and user request forms  can be used for systems without cardholder data

M O S S A D A M S L L P|  29  can be used for systems without cardholder data

o Security awareness training and acceptable use policies  can fill possible gaps in existing Human Resources polices 

LEVERAGING PCI DSS AUDIT

Description of Good Practices  PCI‐DSS v2  ISO 27002  HIPAA 

LEVERAGING PCI DSS AUDIT

Francis Tam, CPA, CISA, CISM, CITP, CRISC, PCI QSA 

QUESTIONS?

Managing Director, PCI Practice Leader 

(310) 295‐3852 

[email protected] 

 

Kevin Villanueva, 

CISSP, CISA, CISM, PCI QSA

 

Senior Manager IT Security Practice Leader

Kevin Villanueva, CISSP, CISA, CISM, PCI QSA 

Senior Manager, IT Security Practice Leader