pci compliance building a roadmap to success presented by: john a. otte, cissp, cisa, cfe, msia,...

PCI ComplianceBuilding a Roadmap to success

Presented by:

John A. Otte, CISSP, CISA, CFE, MSIA, MSCE

Senior Consultant

+ PCI Overview+ Merchants and PCI+ Merchant Validation Requirements+ Merchant Reporting Requirements+ The Digital Dozen - PCI Requirements+ Payment Application Best Practices (PABP)+ Compromise Trends – Why Companies Fail PCI Assessments+ What can organizations do better?

Agenda

PCI Overview

+ Started in 2001 as separate programs+ Cardholder Information Security Program (Visa USA)+ Account Information Security (Visa INTL)+ Site Data Protection (SDP) Program (MasterCard)+ Standards consolidated December 15, 2004 under the naming of the+ Payment Card Industry (PCI) Data Security Standard (DSS)

+ Standards include the “Digital Dozen” – 12 core requirements+ Predominantly based on the previous CISP requirements+ Some influence from SCP and input from other Card companies+ Quarterly Scanning Requirements mandated in 2004 for public facing

sites and systems

PCI Overview

+ Payment Application Best Practices Program launched in 2005 to target security

around payment applications

+ Everyone must comply with the standards

+ Based on what category you fall into determines what level of validation you

must provide (i.e. audits/scans)

+ Annual penetration tests are required, although not required to be submitted

Compliance Level Definitions - Merchants

Level Compliance Validation Onsite Annual Assessment

Quarterly Perimeter

Scan

Compliance Questionnaire

Due Date

1 • Any merchant, regardless of acceptance channel that processes greater than 6 M transactions

• Any merchant that has suffered a hack.

• Any merchant identified by any payment card brand as Level 1

• Any merchant regardless of channel processing 1 M to 6M transactions

• Any merchant 20K – 1M transactions

• <20K in transactions

Required

Highly Recommended

Highly

Recommended

Highly

Recommended

Required

Required

Required

Required

Not Applicable

Required

Required

Required

Sep 30, 2004

Sep 30, 2007

Jun 30, 2005

Not Applicable

2

3

______

4

PCI Data Security Standard – Merchant Validation Requirements

Level American Express

Discover JCB MasterCard VISA

1 • By QSA (or internal auditor if signed by officer of merchant company)

• Annual On-site review Quarterly network scan by ASV

• Quarterly network scan by ASV AND one of the following:

• Annual on-site review by QSA or internal auditor (if signed by officer of merchant company)

-OR-

• Annual Self-Assessment Questionnaire

•Annual on-site review by QSA•Quarterly network scans by ASV

•Annual on-site review by QSA (or internal auditor if signed by officer of merchant company)•Quarterly network scan by ASV

•Annual on-site review by QSA (or internal auditor if signed by officer of merchant company and pre-approved by acquirer)•Quarterly network scan by ASV

2 •Quarterly network scan by ASV

•Annual Self-Assessment Questionnaire•Quarterly network scan by ASV



3 •Quarterly network scan by ASV

N/A •Annual Self-Assessment Questionnaire•Quarterly network scan by ASV


4 N/A N/A At discretion of acquirer:•Annual Self-Assessment Questionnaire•Quarterly network scan by ASV

•Annual Self-Assessment Questionnaire recommended•Quarterly network scan by ASV recommended

PCI Data Security Standard – Merchant Reporting Requirements

Level American Express

Discover JCB MasterCard VISA

1 •If compliant, Exec Summary of QSA/Internal review and Quarterly Network Scan•If not compliant, Exec Summary of QSA/Internal review and Remediation Plan annually and Quarterly Network Scan and Scan Remediation

•Acceptable Reports (to be provided upon request from Discover):

–DISC attestation of compliance form

-OR-–Applicable SAQ attestation of compliance

-OR-–Discover currently accepts cross-certification and will accept reports of compliance submitted to the other payment brands

•No reporting requirements at this time

•Acquirers register compliant merchants in the MC Registration Program (MRP)•Acquirers Report Status of Merchants Quarterly

•Quarterly statement of merchant compliance/non-compliance•Annual confirmation of Report Accuracy Letter•Upon request, a copy of Report on Compliance (ROC)

2 •Quarterly network scan (and remediation plan if not in compliance)•Executive summary PCI SAQ

•No reporting requirements at this time

•Acquirers annually register compliant merchants in the MC Registration Program (MRP)•Acquirers Report Status of Merchants Quarterly

•Quarterly statement of compliance/non-compliance

3 •No Requirements •No reporting requirements at this time

•Acquirers annually register compliant merchants in the MC Registration Program (MRP)•Acquirers Report Status of Merchants Quarterly

•Quarterly statement of compliance/non-compliance

4 N/A •No reporting requirements at this time

No Requirements •Set by Acquirer

The Digital Dozen (PCI Data Security Requirements)

+ Build and Maintain a Secure Network

▪ Requirement 1: Install and maintain a firewall configuration to protect data.

▪ Requirement 2: Do not use vendor-supplied defaults for system passwords and other

security parameters

+ Protect Cardholder Data

▪ Requirement 3: Protect stored data

▪ Requirement 4: Encrypt transmission of cardholder data and sensitive information across

public networks

+ Maintain a Vulnerability Management Program

▪ Requirement 5: Use and regularly update anti-virus software

▪ Requirement 6: Develop and maintain secure systems and applications

The Digital Dozen (PCI Data Security Requirements) (con’t)

+ Implement Strong Access Control Measures

Requirement 7: Restrict access to data by business need-to-know Requirement 8: Assign a unique ID to each person with computer access Requirement 9: Restrict physical access to cardholder data

+ Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data

Requirement 11: Regularly test security systems and processes.

+ Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

Specific changes in PCI V1.2

+ Hosting Providers have specific requirements (2.4 & Appendix A)▪ Hosting providers must become compliant▪ Merchants/Service Providers that use hosting providers will fail assessments if

their providers do not meet requirements in Appendix A

+ Requirement 5.5.1 now requires that A/V software also detect and remove malicious software such as adware & spyware.

+ Requirement 6.6 requires application firewalls or code reviews for web-facing custom code (best practice until 6/30/2008)

+ Requirement 12.10 for service providers only, for management of “connected entities”

+ Self Assessment Questionnaire now has 5 different areas of compliance

+ Appendix A – For hosting providers

+ Appendix B – Compensating control worksheet

Payment Application Best Practices

+ Started in 2005 by Visa in response to application related compromises on the rise

+ Made part of the permanent standard in 2008 Many payment application vendors are using this as a differentiator This is the standard and now applies to companies that franchise

+ Top 5 Vulnerabilities related to payment applications Full track data and/or encrypted PIN block retention Default accounts Insecure remote access by software vendors and their resellers Compatibility issues with anti-virus and encryption SQL injection Random Access Memory Attack

Who must comply?

+ All merchants that process, store or transmit cardholder data

+ Payment Application Vendors

▪ Point of Sale (Micros)▪ Shopping Cart▪ Mobile Payment Providers

+ A web site at Visa and another at Master card lists applications that have passed PABP assessments

This creates a market for PABP compliant applications Applies market pressure on other application vendors to certify their

applications

Qualifying Questions

+ Do you or any of your business units:

▪ accept credit cards as a form of payment?▪ build software for the processing of credit cards?▪ allow customers to swipe credit cards?▪ accept payments online?▪ process payments on behalf of others?

+ Do you see future strategies around mobile payments?

+ Are you currently looking to expand into retail or non-strategic B2B?

Recent Changes and Proposed updates

Recent Changes to the PCI DSS Proposed updates

+ PCI V1.2!

▪ 1 October 2008 – New standard announced▪ Requires Code Review or Application layer firewall as of June 2008

+Wireless▪ WEP Encryption sunset June 2010

+ Payment Application Best Practices now part of the standard (PA-DSS)

+ Encryption still remains a core requirement although compensating control alternatives will be considered

+ Data Loss Prevention

+ E-Discovery and adherence to the Federal Rules of Civil procedure in the event of a security breach

Why are companies failing PCI assessments?

PCI Requirement Percentage of Failure

Requirement 3: Protect Stored Data 79%

Requirement 11: Regularly test security systems and processes.Requirement 8: Assign a unique ID to each person with computer access.

74%71%

Requirement 10: Track and monitor all access to network resources and cardholder data.

71%

Requirement 1: Install and maintain a firewall configuration to protect data.

66%

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.

62%

Requirement 12: Maintain a policy that addresses information security.

60%

Requirement 9: Restrict physical access to cardholder data. 59%

Requirement 6: Develop and maintain secure systems and applications.

56%

Requirement 4: Encrypt transmission of cardholder data and sensitive information across public networks.

45%

Source: VeriSign Business Services

+ Unsecured physical assets.

▪ Unencrypted data may be stored on backup tapes and other mediums that are prone to loss or theft

+ Point of sale (POS) application vulnerabilities.

▪ Applications may be creating logs that store card track data.▪ PCI requirements prohibit the storage of track data under any

circumstance.▪ Nefarious individuals who are interested in obtaining track data know

which applications store this data and where the information is typically stored.

Compromised Trends

+ Unencrypted spreadsheet data

▪ Users may be storing card data in spreadsheets, flat files, or other formats that are difficult to control as they are transferred to laptops, desktops, and wireless devices.

▪ A key source of PCI audit failure is storing unencrypted data in Excel® spreadsheets. (Data Leakage/Loss)

+ Poor identity management.

▪ Users and administrators may not be handling authentication properly.▪ Although password-based authentication is one of the easiest

authentication methods to implement, it is also the most prone to compromise, because passwords can be easily shared, stolen, or guessed.

Compromised trends…..continued

+ Network architecture flaws; flat networks.

▪ Many businesses did not develop their IT infrastructure with security in mind.▪ They often fail PCI assessment because they have very flat (non-partitioned)

networks in which card databases are not segmented from the rest of the network.

▪ The lack of a secure network enclave is a serious issue regardless of PCI implications, and can be very difficult to remediate.

+ Lack of log monitoring and intrusion detection system (IDS) data; poor logging tools.

▪ Without log information, it is difficult to determine whether processes and security systems are working as expected.

▪ In addition, insufficient data makes it more difficult to investigate compromises that do occur.

▪ For example, if there were no record of the timeframe of a compromise, it would be difficult to determine the number of credit cards exposed during the compromise.

Compromised trends……continued

+ Card numbers in the Demilitarized Zone (DMZ).

▪ POS terminals may be storing credit card numbers in the externally facing perimeter network.

▪ In some companies, the POS terminal acts as a card-present terminal that sits on the Internet.

▪ Because there is no firewall between the system accepting the card present transaction and the Internet, this arrangement does not comply with PCI requirements (and hackers can easily find credit card data).

▪ Frequently, these systems are also storing track data.

Compromised trends…..continued

Top Five failed requirementsTop Five failed Requirements Relevant Compromise Recommended Tactics

Requirement 3: Protect Stored Data Unencrypted spreadsheet data; unsecured physical assets

Store less data; understand the flow of data, encrypt data

Requirement 11: Regularly test security systems and processes

E-commerce application vulnerabilities; most data compromises can be attributed to a web application vulnerability

Rigorously test applications, scan systems quarterly

Requirement 8: Assign a unique ID to each person with computer access

Weak or easily guessed administrative account passwords

Improve security awareness

Requirement 10: Track and monitor all access to network resources and cardholder data.

Lack of log monitoring and intrusion detection data; poor logging tools

Install intrusion detection or prevention devices, improve log monitoring and retention

Requirement 1: Install and maintain a firewall configuration to protect data

Card numbers in the Demilitarized zone; segmentation flaws

Segment credit card networks and control access to them

Why Comply?

+ Penalties

▪ All FIVE major card brands reserve the right to fine acquiring banks for the non-compliance of their members

▪ ALL acquiring banks reserve the right to fine members for non-compliance.

▪ ALL major Card Brands have agreed on the following fine schedule:– $5,000 per month for 3 months– $25,000 for months 4-6– $50,000 for months 7-9– $100,000 per month after 9 months of non-compliance until compliant with

the PCI DSS or a “CEASE AND DECIST LETTER IS ISSUED”▪ In the case of a breach, if the vendor is found to be out of compliance,

damages can also be borne by the vendor– Fraud replacement– Damage control cost replacement

Why Comply?

+ Brand Security▪ Maintain stockholder value▪ Maintain consumer confidence+ Improve Internal Processes▪ Meeting such requirements improves overall operational security▪ Risk reduction+ Transference and Regulatory Overlap▪ Incrementally improve compliance with other regulatory requirements▪ PCI DSS based predominantly on ISO27002▪ Requirements of PCI substantially comply with– PIPEDA and Privacy Act Security Requirements– FFIEC Guidance Documents– GLBA (Safeguard Rule)– HIPAA (Safeguard Rule)– EU Data Directive Security Requirements

What can organizations do better?

+ Segregate your Cardholder Processing Environment▪ Companies have flat networks▪ The border of the cardholder environment is now the boundary for the scope

of the assessment▪ The perimeter controls are evaluated, rather than every server on the

network▪ It is equivalent to having an Internet accessible web application – the access

controls at the perimeter, and the controls in place when allowing access from an external source are important, but you don’t assess the system of everyone in the world.

+ Use a Translation Table▪ Separate table which translates an ID into a credit card number▪ Use this ID everywhere you would have normally used a credit card #▪ Still requires encryption of the card number within the table


+ Store Less Data

▪ Don’t store cardholder data unless there is a compelling business reason to do so

▪ There are no auditing, regulatory, or legal reasons for a merchant to store cardholder data

▪ Storing transaction history does not necessitate storage of the card number

+ Better Access Controls

▪ Utilize authentication between web servers, application servers, and database servers

▪ Lock database tables and restrict access by applications according to the principle of least privilege

▪ Don’t allow access to tables at all – use stored procedures.


+ Justify Storage of data

▪ Determine where credit card data exists in your organization, what it is used for, and whether it is needed there.

▪ In addition, be sure that legacy reports have been modified to remove data that is no longer needed.

+ Make the business prove they need access to and storage of card holder data

Explain the risks of storing cad holder data and the impact non-compliance could have on the organization

Include this type of review as part of a holistic risk assessment


+ Understand the Flow of Data

▪ Many companies have no diagrams or documentation showing how credit card data flows through their organization.

▪ Unless you have performed a system-wide audit of all data repositories and then continue to perform audits regularly, you have no way of determining where data lives and whether you’re complying with PCI standards.

▪ Companies can curtail many of the compromises discussed earlier by tracking the flow of data and then correcting the associated problem.

+ One Fishnet Security customer tracked data flows to over 25 locations within the enterprise with multiple copies of card holder data stored in flat files and unsecure databases. Forstyhe's consultants identified the card holder data repositories and assisted the organization with remediation efforts to mask, truncate or eradicate the data.


+ Document the flow of credit card data throughout your organization.

▪ Understand where data goes—from the point where you acquire it (either from a customer or third party) to the point where the data is disposed of or leaves your network.

+ Encrypt Data.

▪ Encryption is a key component of the “defense-in-depth” principle that the PCI attempts to enforce through its requirements.

▪ Even if other protection mechanisms fail and a hacker gains access to data, the data will be unreadable if it is encrypted.

▪ Unfortunately, many companies store credit card data on mainframes, databases, and other legacy systems that were never designed for encryption. For these companies, encrypting stored data (data at rest) is a key hurdle in PCI compliance.

▪ Typically, companies choose one of the following options in order to remediate encryption problems:


+ Retrofit all applications.

▪ With this approach, encryption is rolled into the coding of the payment application.

▪ Instead of writing the card number to a database, the payment application encrypts the number first.

▪ The database receives and stores the already-encrypted number.▪ This approach is popular with companies that outsource their payment

applications to other vendors, for example, small banks that provide online banking.

▪ In these cases, the vendor handles the encryption.


+ Use an encryption appliance.

▪ A new class of appliance sits between the application and the database. It encrypts the card data on the way into the database and decrypts the number on the way out.

▪ Most companies use this approach because the trade-off between expense and business disruption versus time to deployment is very good.

+ Use an encrypting database.

▪ An encrypting database offloads encryption to the storage mechanism itself, so companies don’t have to significantly modify their applications or buy an appliance.

▪ This product, which is new from Oracle, also provides fairly good key management. However, it is very expensive.

▪ In addition, it does not operate on IBM® mainframes and AS400®s, which financial institutions—especially card processing and fulfillment banks—tend to rely on.


+ Obfuscate without encryption.

▪ Another way around encryption is to not use it.▪ The PCI Data Security Standard calls for obfuscation—making the credit

card unreadable—not encryption.▪ One-way hashing, truncation, and other approaches are less costly to

implement than encryption, and in many cases, companies can still perform all necessary business functions related to credit card numbers.

+ Incorporate encryption at the development phase.

▪ Use an encryption framework during development instead of developing applications and then retrofitting them for encryption.


+ Have an overall encryption strategy.

▪ A typical company has multiple encryption requirements—for everything from VPN tunnels using IPSec, email secured by SMIME, and SSL certificates, to mainframe, database, and disk encryption (e.g., for users with laptops).

▪ To minimize costs and avoid problems associated with managing multiple keys, consider a strategy that encompasses not only PCI requirements but the entire range of encryption requirements within your organization.

▪ Then, consolidate key management to the fewest number of points possible.


+ Improve Your Systems Development Life Cycle (SDLC)

▪ Companies have long had a habit of considering security an add-on▪ When developing projects, ensure that security expertise (and don’t forget

Internal Audit) is engaged during the scoping, planning, and design stages of the project

▪ This will ensure that security is integral to the final product▪ This will reduce the costs of retrofitting or re-architecting a product or

reversing a project after it is nearing its deployment date▪ It will reduce risk acceptance where the justification is time to market▪ All stakeholders become more aware of regulatory and policy

requirements surrounding security▪ All the above benefits are applicable to a complete range of regulatory or

contractual security requirements, not just PCI

Want to really improve your PCI compliance?

Engage Fishnet Security as a Qualified Security Assessor (QSA) to assist with all of your PCI needs

Thank you!