pci dss for engineers

PCI DSS for Engineers: Adventures in PCI

Wonderland

Michele Chubirka [email protected] Postmodern Security

1

2 Postmodernsecurity.com 2014 PCI DSS for Engineers

Revision history

2014-06-21 First draft


Who Are You?

Michele Chubirka aka @MrsYisWhy Security architect, engineer,

analyst. Writer for Network Computing

and TechTarget Blogs and hosts a security

podcast, Healthy Paranoia, www.healthyparanoia.net

Researcher and pontificator on topics such as security architecture and best practices.

Hates the color brown.


The Bigger Picture: Security Webinars

Availability Live sessions Recordings of individual webinars Yearly subscription

Other options Customized webinars ExpertExpress On-site workshops

Inter-DC FCoE has very limited use and requires no bridging More information @ http://www.ioshints.info/Webinars

Security

Data Center Networking

PCI DSS for Engineers

DMVPN, IPv6 Security

Virtual Firewalls

Virtualization


Begin at the beginning, and go on till you come to the end: then stop.


Overview

Purpose and Background of PCI DSS Compliance vs. Non-compliance Basics of Standard Whats New in PCI 3.0 The Jabberwocky: Scoping and Compensating

Controls Common Myths Getting it Right


The time has come, the Walrus said, To talk of many things: Of PINs and POS and ASVs, And why the sea is boiling hot and whether QSAs have wings.


*This is one of Ivans filler slides. Who are these children and why are they so intrigued by network cables?

Please Ask Questions!


Will you, won't you, will you, won't you, will you join the dance?

PCI DSS applies to any entity that accepts processes stores transmits member-branded card data

Put in place to reduce credit card fraud. Compliance with standard is a binary yes | no.

Its like a game of cooties, if you touch credit card data, youre infected.


were all mad here. Im mad. Youre mad." "How do you know Im mad?" said Alice. "You must be," said the Cat, or you wouldnt have come here.

Should You Be In the Business of PCI?


Get out of the PCI business; youre not good at it, you havent (usually) applied the lessons learned and you will eventually lose. - Anonymous QSA


Proprietary framework released in 2004 by PCI Security Standards Council to ensure secure handling of credit card data. www.pcisecuritystandards.org

Founded by five global payment brands. Enforcement of compliance and penalties for non-

compliance determined by each brand, not the council.

Related standards include: Payment Application Data Security Standard (PA-DSS) and PIN Transaction Security (PTS)

PCI DSS: Payment Card Industry Data Security Standard


Why Does PCI DSS Matter?

2014 MILESTONES The PCI Data Security

Standard (DSS) turns ten years old

DSS 3.0 becomes effective and validation assessments start (January 1)

DSS 2.0 expires and compliance validation against version 3.0 becomes mandatory (December 31)

Verizon 2014 PCI Compliance ReportINTRODUCTION2014 will be a pivotal year for merchants and service providers looking to comply with PCI standards.

A DECADE ON, AND MORE IMPORTANT THAN EVER

Payment card data is becoming more important as cards supplant cash, and as our DBIR data shows, its a prime target for attackers. As we are putting the finishing touches to this report, the FBI has issued a warning to retailers to be wary of card-targeting malware thought to already be responsible for the breaching of over 100 million peoples card data.1

The PCI DSS is designed to standardize and assess how organizations are protecting the card data they hold from this and other threats. The PCI Security standards apply to all organizations that handle cardholder data. The core standard, the PCI DSS, has been around for nearly a decade; and service providers, merchants, and financial companies of all sizes and from around the world have adopted it. PCI DSS is the most widespread and established standard of its kind: its broadly accepted, widely discussed, and its not going away.

So its widespread. But is it effective in achieving security? Our evidence suggests that it is.

ORGANIZATIONS THAT ARE BREACHED TEND TO BE LESS COMPLIANT WITH PCI DSS THAN THE AVERAGE OF ORGANIZATIONS IN OUR RESEARCH.

As we enter the tenth year of PCI DSS, there has been important progress. With version 3.0, PCI DSS is more mature than ever, and covers a broad base of technologies and processes such as encryption, access control, and vulnerability scanning to offer a sound baseline of security. The range of supporting standards, roadmaps, guidance, and methodologies is expanding. And our research suggests that organizations are complying at a higher rate than in previous years.

After an uncertain start, many organizations now feel comfortable with and better understand what the DSS is about, and accept that complying with it is not only a necessary part of accepting card payments, but also a solid baseline of controls for protecting cardholder data.

Most analysts agree that, while the PCI standards are imperfect, they have evolved to clarify expectations and address feedback from the industry, and today they provide an increasingly mature framework for organizations to work toward.

So why is PCI compliance still worth talking, and indeed writing a major piece of research, about?

$10B

$12B

$0

$6B

$4B

$2B

$8B

Global Card Fraud Losses ($Billions)

00 01 02 03 04 05 06 07 08 09 10 11 12Data from The Nilson Report, August 2013Figure 2: The cost of card fraud; data from The Nilson Report, August 2013

5VERIZON 2014 PCI COMPLIANCE REPORT


Payment card data remains one of the easiest types of data to convert to cash, and therefore the preferred choice of criminals. 74% of attacks on retail, accommodation, and food services companies target payment card information. - Data from Verizon Data Breach Investigations Reports (DBIRs), 2011, 2012 and 2013


Whos Compliant?

Payment card data remains one of the easiest types of data to convert to cash, and therefore the preferred choice of criminals. 74% of attacks on retail, accommodation, and food services companies target payment card information.Data from Verizon Data Breach Investigations Reports (DBIRs), 2011, 2012 and 2013

COMPLIANCE REMAINS A MAJOR ISSUE

But our research also shows that the vast majority of organizations are still not sufficiently mature in their ability to implement and maintain a quality, sustainable PCI Security compliance program, and they continue to struggle to provide the required compliance evidence at the time of the annual compliance validation assessment.

Theres significant variation across the individual requirements, controls, and subcontrols; as well as across industries and regions. Despite a decade of discussion, clarification, and education, there are fundamental disagreements and misunderstandings around critical areas of security and compliance, including how to define the scope of compliance itself, and how compliance is assessed. Some even regard the DSS, even in its latest 3.0 guise, as taking fundamentally the wrong approach to security.

According to our research, only around one in ten organizations were fully compliant with PCI DSS 2.0 at the time of their baseline assessment. Despite the increasing maturity of the standard and organizations understanding of it, attaining compliance remains far from easy and so it should. Protecting cardholder data is important and the threats to it are very real.

And the drivers for investing in security and compliance are more pressing than ever. The very payment card data breaches that PCI DSS was designed to help avoid are growing in frequency and scale, with compromised records often numbering in the millions. As consumers and businesses continue to ditch cash and do more of their shopping online, the risk and impact of breaches is set to grow further. The related disciplines of security and compliance are, consequently, still a top business priority.

100%

0%

50%

25%

75%

Percentage of companies that passed

2 3 4 5 6 7 8 9 10 111Number of requirements

% co

mpa

nies

12

11.1%

95.6% 95.6%

77.8%

71.1%

60.0%

51.1%44.2% 42.2%

31.1%24.4%

100.0%

11.1% of companies passed all 12 requirements

Over half (51.1%) of companies passed 7 requirements.

Figure 3: Percentage of companies that passed; dataset 2013

6 VERIZON ENTERPRISE SOLUTIONS

Verizons 2014 PCI Compliance Report


Pass or Fail?

11.1% met all requirements of DSS 2.0 in 2013, an increase of 3.6 percentage points from 2012. In 2013, companies were compliant with an average of 85.2% of controls. one in five organizations came close to complying they passed 95%+ of controls. Of these organizations, more than half failed Requirement 11 [Regularly test security systems and processes]. - From Verizons 2014 PCI Compliance Report


Does PCI DSS Work?

Effectiveness is determined by the organizations implementation, not the auditor.

Considered a snapshot in time.


Compliance != Security

Venn diagram courtesy of @grecs


Off With Her Head!: The Consequences of Non-compliance


Lawsuits and countersuits Insurance claims Suspension of merchant status with processor

or in-depth assessments if breached. Payment card issuer fines Possible government fines (depending upon

where you do business) Damage to reputation and business


Example: Target Breach

Target CIO resigned after breach of 40 million credit card and debit records.

At least 80 100 lawsuits filed. Earnings down 46% in 2013 4th

quarter. Total losses could reach one billion. Reportedly validated as

compliant Targets QSA, Trustwave, is also in

litigation with banks.


Others Recent Breaches

Neiman Marcus - 350k Sally Beauty 282k Michaels 2.6 MM P.F. Changs 7MM (estimate) California DMV - ?


PCI DSS 101


Important Taxonomy Merchant any entity that accepts payment cards Payment Card card/device bearing logo of founding members of PCI SSC Issuer entity issuing payment cards or performs, facilitates or supports issuing services. Service Provider or Merchant Service Provider (MSP) - furnishes all or some of payment services for a merchant Payment Processor type of MSP Acquiring Bank connects to card brand network for payment processing QSA qualified security assessor SAQ self assessment questionnaire ASV approved scanning vendor PAN primary account number CVV card verification value CSC card security code POS point of sale CDE cardholder data environment ROC report on compliance AOC attestation of compliance AOV attestation of validation Scoping process identifying all system components, people and processes included in an assessment From PCI DSS and PA DSS Glossary of Terms, Abbreviations, and Acronyms V. 3.0, January 2014


Speak English! I don't know the meaning of half those words, and I don't believe you do either!


Typical Processing Chain

1. Cardholder

2. Merchant

3. Payment Processor

4. Acquiring

Bank

5. Card Brand

Customer with credit or debit card received from issuing bank

Accepts credit or debit card for goods/services

Provides payment service for merchant

Connects to card brand network for payment processing

Visa

MasterCard

Amex

Discover

JCB


Sometimes PCI is a hill, and sometimes its a mountain.

Six domains, 12 requirements The goal is to reduce risk of fraud Simple, right?


Validation Requirements

Compliance vs. validation, whats the difference?

Merchant and/or service provider status

Based upon volume of transactions.

Method of acceptance Whether the merchant has ever

been breached. Varies by payment card brand. Can change. Expect stricter

requirements in the future.


Merchant Levels

Level 1 processes > 6MM Visa, MC or Discover transactions annually, 2.5MM Amex, 1MM JCB

Level 2 1 to 6MM Visa, MC or Discover, 50k to 2.5MM Amex, < 1MM JCB

Level 3 20k to 1MM Visa or Discover card-not-present transactions, >20k MC ,


Service Provider Levels

Level 1 All 3rd party providers (TPP), all data storage entities (DSE) that store, transmit or process > 300k MC, >=2.5MM Amex, >300k Visa

Level 2 DSEs < 300k MC, 50k to 2.5MM Amex,


Validation Requirements

Level 1 ASV scan, QSA on-site assessment Level 2 ASV scan, Visa SAQ, MC QSA/ISA on-site

assessment or assisted SAQ. Level 3 ASV Scan, SAQ Level 4 ASV scan if requested, SAQ

Amex requirements differ slightly: https://www209.americanexpress.com/merchant/services/en_US/data-security Make sure you know your level, because it can impact your validation requirements!


Self Assessment Questionnaire (SAQ) Validation Types

Type A Merchants who keep only paper reports or receipts with cardholder data, do not store cardholder data in electronic format and do not process or transmit any cardholder data on their systems or premises. Does NOT apply to face-to-face merchants.

Type B - Imprint-only merchants with no electronic cardholder data storage, or standalone, dial-out terminal merchants with no electronic cardholder data storage.

Type C-VT - Merchants who process cardholder data only via isolated virtual terminals on personal computers connected to the Internet. This SAQ option applies only to merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution.

Type C Those with payment application systems (for example, point-of-sale systems) that are connected to the Internet (for example, via DSL, cable modem, etc.) either because: The payment application system is on a personal computer that is connected to the

Internet (for example, for e-mail or web browsing), or The payment application system is connected to the Internet to transmit cardholder data.

Type D All others


Caution: Make sure to carefully read the Self-Assessment Questionnaire Instructions and Guidelines document, not just the questionnaire itself.


PCI DSS Domains

1. Build and maintain a secure network. 2. Protect cardholder data. 3. Maintain a vulnerability management program. 4. Implement strong access control measures. 5. Regularly monitor and test networks. 6. Maintain an information security policy.


That Doesnt Seem So Bad


Requirements

1. Install and maintain a firewall configuration to protect cardholder data. 2. Do not use vendor-supplied defaults for system passwords and other

security parameters. 3. Protect stored cardholder data. 4. Encrypt transmission of cardholder data across open, public networks. 5. Protect all systems against malware and regularly update anti-virus

software or programs. 6. Develop and maintain secure systems and applications. 7. Restrict access to cardholder data by business need to know. 8. Identify and authenticate access to system components. 9. Restrict physical access to cardholder data. 10. Track and monitor all access to network resources and cardholder data. 11. Regularly test security systems and processes. 12. Maintain a policy that addresses information security for all personnel.


Curiouser and curiouser!

PCI DSS V3.0 is 112 pages. Every requirement has sub-

requirements, testing procedures and guidance (new in 3.0).

Requirement One has 23 sub-requirements.

Over 200 requirements in total.

That doesnt include the additional guidance documentation.


Payment Card Industry (PCI) Data Security Standard, v3.0 Page 24 2006-2013 PCI Security Standards Council, LLC. All Rights Reserved. November 2013

PCI DSS Requirements Testing Procedures Guidance 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.

1.3 Examine firewall and router configurationsincluding but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segmentand perform the following to determine that there is no direct access between the Internet and system components in the internal cardholder network segment:

A firewall's intent is to manage and control all connections between public systems and internal systems, especially those that store, process or transmit cardholder data. If direct access is allowed between public systems and the CDE, the protections offered by the firewall are bypassed, and system components storing cardholder data may be exposed to compromise.

1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

1.3.1 Examine firewall and router configurations to verify that a DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

The DMZ is that part of the network that manages connections between the Internet (or other untrusted networks), and services that an organization needs to have available to the public (like a web server).

This functionality is intended to prevent malicious individuals from accessing the organization's internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner.

1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.

1.3.2 Examine firewall and router configurations to verify that inbound Internet traffic is limited to IP addresses within the DMZ.

1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.

1.3.3 Examine firewall and router configurations to verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.

Examination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, as well as inspection and blocking of unwanted content, thus preventing unfiltered access between untrusted and trusted environments. This helps prevent, for example, malicious individuals from sending data they've obtained from within your network out to an external untrusted server in an untrusted network.


Say what you mean

The requirements seem simple, but the meaning is nuanced.

Sometimes interpreted differently by QSAs and ISAs. PCI DSS 3.0 adds a guidance column with more

detail to clarify intent of requirements. Best defense is to read the standard. Ignorance is not an acceptable excuse. If assessor and merchant disagree, an acquiring bank

may accept the risk and consider merchant compliant.


Whats New in 3.0: Highlights

Moved from 2 year to 3 year standards development lifecycle.

Requirements are the same, but with modifications to sub-requirements.

V2.0 active until Dec. 31, 2014, some new V3.0 requirements not mandatory until July 2015.

Clarifies scoping and reporting Focus on consistency, proactivity and best practices Addition of security policy/procedure into each

requirement. Clarifies handling of sensitive authentication data

(SAD).


When Should You Be Compliant with 3.0?

If youre filing an AOC on 12/01/14 for PCI-DSS 2.0 you could be considered non-compliant on 01/01/15.

Confirm with your acquiring back if they will accept the risk until the next annual reassessment.


Specific Requirement Additions

Req 1. Current diagram with cardholder data flows in addition to network diagrams. Req 2. Maintain inventory of in-scope system components and change default passwords on application/service accounts. Req 3. More options for secure storage of crypto keys. Clarification regarding dual control. Req 5. Evaluate evolving malware threats for systems not commonly affected by malware.


Requirement Additions Continued

Req 6. Update list of common vulnerabilities, align with OWASP, NIST, SANS for secure coding practices. Req 8. Security considerations for authentication mechanisms such as tokens, smart cards and certs. Enhanced guidance on good password practices. More flexibility to accommodate variations in secure implementations. Req 9. Protect POS terminals and devices from tampering or substitution. Req 10. Clarifies intent and scope of daily log reviews by focusing on identifying suspicious activity. Req 11. Implement pentesting method to validate segmentation. Req 12. Maintain info about status of PCI DSS for 3rd party providers.


Scope

According to PCI SSC, the CDE consists of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Firewalls Switches Access Points Network and Security Appliances Servers


Scoping

Anything included or connected to CDE is in scope. Isolating (segmenting), the CDE from the rest of the network

is not a requirement. Technique that shrinks the scope of the assessment, reducing

cost and difficulty. Reduces risk. Without scoping, entire network is in scope of the assessment. To be out of scope, the component must be properly

segmented from the CDE, so that if compromised it could not impact CDE.

Encryption can reduce scope, but it depends


Network Before PCI

Dev/QA/Lab

Prod/UAT

Backup MGMT

SOX

Users

Corp

DMZ

Database

Application

Services: SharePoint, file sharing email and web

DMZ

Database

Application

Users have access to everything, with minor restrictions based upon role. Data is segmented, but still flows freely between categories.


After PCI

Corp

Dev/QA/Lab

Prod/UAT

Backup

MGMT

PCINon-PCI

Non-PCI PCIUsers

Services: Sharepoint, file sharing, email

and web

Jumphosts and VDI

General Network and System

Services:DNS, RADIUS, NTP, LDAP,

Vmware Management, etc...

PCI debug and storage

database

application

DMZ

database

application

DMZ

database

application

DMZ

SOX

NOTE: Direction of arrows implies logical direction of data flow

Data/Network Segmentation

ESX Hosts

NMS App and DB support systems

ILO and Console Access


Reducing Scope with Point-to-Point Encryption (P2PE)

A P2PE solution encrypts data from the point-of-interaction (POI) until the data reaches a 3rd party solution provider.

Uses a PCI SSC P2PE-validated application Will only reduce scope if the devices and people

between the two encryption endpoints have no access to keys.

If the person or device can decrypt the stored or transmitted CHD, then its in scope.


Compensating Controls

Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls.

From Appendix B, PCI DSS, v3.0


Compensating Controls Must

Meet intent of original requirement. Provide similar level of defense. Go above and beyond. Be commensurate with additional risk. Be more work to implement, not less. Pass an audit.


PCI DSS Myths


1. I only process a small number of credit card transactions, so its not a big deal.

You MUST be compliant with PCI DSS, regardless of number of transactions processed.

If you outsource, you must verify that organizations PCI DSS compliance status in accordance with requirement 12.

Outsourcing simplifies your requirements by reducing scope, but doesnt eliminate the need to address them.


2. I only have to submit an SAQ, so all the requirements dont apply.

All requirements still apply. The questionnaire is misleading. There are fewer questions because the categories assume

reduced scope. Check the decision tree in the SAQ Instructions and

Guidelines document.


PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 17

Which SAQ Best Applies to My Environment?


3. Wireless requirements only apply if card data transits the WLAN.

Wireless is perceived as a vulnerable medium. You must still validate that wireless is out of scope to meet

fewer requirements. See requirements 1.2.3, 9.1.3, 10.5.4, 11.1


4. To reduce scope, I need to have physically separate networks.

You have to implement controls which segment and restrict access to the CDE.

Sometimes, it may be easier to make them physically separate.


5. Mixed-mode virtualized environments arent permitted From PCI DSS Virtualization Guidelines 2011 document: any VM or other virtual component that is hosted on the same hardware or hypervisor as an in-scope component would also be in scope for PCI DSS, as both the hypervisor and underlying host provide a connection (either physical, logical, or both) between the virtual components.... In order for in-scope and out-of-scope VMs to co-exist on the same host or hypervisor, the VMs must be isolated from each other such that they can effectively be regarded as separate hardware on different network segments with no connectivity to each other.Even if adequate segmentation between virtual components could be achieved, the resource effort and administrative overhead required to enforce the segmentation and maintain different security levels on each component would likely be more burdensome than applying PCI DSS controls to the system as a whole.


6. Supporting systems arent in scope.

REMEMBER: included in or connected to the cardholder data environment. Its just like a game of cooties.


7. Compliance requirements are based upon merchant or service provider level.

No, VALIDATION requirements differ. Everyone must comply with ALL of PCI DSS, regardless of level. This is not optional.


8. I can just use a compensating control to meet a requirement thats too difficult.

Compensating controls are stricter. The key phrase is above and beyond.


Getting It Right

Data inventory and classification. Data flow and inventory of CDE. Reduce scope wherever possible. Identify data custodians and stakeholders outside of IT. Embed ownership

in entire organization. Learn the language of your compliance peers. Get comfortable with the

PCI DSS taxonomy. Invest in audit and configuration reporting tools, especially for the

firewall. Many compliance people are not very technical, so this will help them (and you).

Avoid Compensating Controls, use as last resort. Remove CC data wherever possible. If you cant remove, tokenize. Encrypt, encrypt, encrypt. Point-to-point encryption (P2PE) can reduce

scope. If > level 4 merchant or SP and you qualify for SAQ D, consider using

QSA or auditor for initial assessment and/or occasional follow-up.


Final Advice

Get out of the PCI business: outsource to experts.


References

Chuvakin, Anton, Branden R. Williams, and Ward Spangenberg. PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance. Burlington, MA: Syngress, 2010. Print. "Documents Library." PCI Security Standards Documents: PCI DSS, PA-DSS, PED Standards, Compliance Guidelines and More. Payment Card Industry Security Standards Council, n.d. Web. 17 Mar. 2014. Van Oosten, Ciske. PCI Compliance Report. Rep. no. GL00648-17. Verizon, Feb. 2014. Web. .


Questions?


Where Can You Find Me?

Spending quality time in kernel mode practicing and refining my particular form of snark.

www.healthyparanoia.net www.postmodernsecurity.com Twitter @MrsYisWhy Google+ MrsYisWhy [email protected] [email protected] http://www.networkcomputing.com http://searchnetworking.techtarget.com http://searchsecurity.techtarget.com


Questions?

Paperwork issues

Follow-up by email Please fill in the evaluation form Recording available within 24 hours PDF materials always available for download Discount for future webinars use wlp10 discount code Upgrade to yearly subscription Help me spread the word!

Send them to [email protected] or @MrsYisWhy on Twitter and Google+