© secureworks, inc. · pci standards overview common myths and misconceptions ... a-ep e-commerce...

© SecureWorks, Inc.

Payment Card IndustryPrimer

Jason Wikenczy

CISSP, CISA, QSA

May 8, 2018

2

© SecureWorks, Inc.3

Agenda

• Payment Card Industry Standards Overview

• Validation Levels and Reporting Requirements

• Scoping the Assessment

• Methods for Scope Reduction

• The Prioritized Approach

• Resources

• Question & Answer

TermsPayment Card Industry (PCI)

Data Security Standard (DSS)

Report on Compliance (ROC)

Self-Assessment Questionnaire (SAQ)

Qualified Security Assessor (QSA)

Approved Scanning Vendor (ASV)

Cardholder Data (CHD)

Cardholder Data Environment (CDE)

Point-to-Point Encryption (P2PE)


PCI Standards Overview

Entities Affected – Needs to Demonstrate Compliance

• Merchants, to name a few:

• Government Agencies

• Financial Institutions

• Retail, Healthcare, & Education

• E-commerce

• Service Providers

• Banks & Payment Processors

• Hardware / Device Manufacturers

• Software Developers

4

Any entity that stores, processes, or transmits cardholder data,

OR impacts the security of the cardholder data environment.



Common Myths and Misconceptions

• “We use compliant hardware and software, therefore we must be compliant”

• “We don’t take enough credit cards to need to worry about compliance”

• “Our vendor said one product was all we needed”

• “We passed this year, so we don’t have to think about it until next year”

• “We outsource so we don’t have to worry about being compliant”

• “The requirements are too vague, with a lot of room for interpretation”

• “We don’t store payment card information so we don’t have to be compliant”

5



The Truths: I

• $3.62M is the average cost of a data breach

• Potential for $100,000+ monthly costs / fines for non-compliance

• Rarely are self-assessing organizations actually compliant

• Greater than two years on average to become PCI compliant

• Compliance does not equal security, it should be a byproduct

6


PCI Standards Overview: Recent Breaches

Compliments of InformationisBeautiful.net

7



The Truths: II

• Requirements are the same globally, but legal supersedes PCI

• Organizations are NOT required to use compliant products and services

• Typically, being compliant helps secure more funding for IT security

• Merchants and service providers may use any assessing company of choice

• If you ask five QSAs the same question, you will get seven different answers

8



Multiple Standards for the Protection of Cardholder Data

• Covers security of the environments that store, process, or transmit account data.

• Environments receive account data from payment applications and other sources (e.g., acquirers).

PCI DSS

• Covers encryption, decryption, and key management requirements for point-to-point encryption solutions.

PCI P2PE

• Covers secure payment applications to support PCI DSS compliance.

• Payment application receives account data from PIN entry devices (PEDs) or other devices and begins payment transaction.

PCI PA-DSS

9

There’s more if you’re really bored…or suffer from insomnia.


The PCI DSS

Six Goals, Twelve Major Requirements

10

Goals Requirements

Build and Maintain a Secure

Network and Systems

• Install and maintain a firewall configuration to protect cardholder data

• Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data • Protect stored cardholder data

• Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability

Management Program

• Protect all systems against malware and regularly update anti-virus software or programs

• Develop and maintain secure systems and applications

Implement Strong Access

Control Measures

• Restrict access to cardholder data by business need-to-know

• Identify and authenticate access to system components

• Restrict physical access to cardholder data

Regularly Monitor and Test

Networks

• Track and monitor all access to network resources and cardholder data

• Regularly test security systems and processes

Maintain an Information

Security Program

• Maintain a policy that addresses information security for all personnel


The PCI DSS

Validation Levels

• Defined by the payment brands

• Based on transaction volume

• Transaction volume determined by the

acquirer (the merchant’s bank)

• Defined by the payment brands

according to transaction volume and/or

type of service provider

• Determined by the payment brands or

acquirer, or sometimes the service

provider

Merchant Levels Service Provider Levels

11

Compliance validation requirements vary by payment brand.


The PCI DSS

Validation Requirements Overview

12

Merchants

Level 1 Level 2 Level 3 & 4

Type of Assessment Onsite Assessment Self-AssessmentDetermined by Payment

Brand or Acquirer

Reporting RequirementsROC and ASV Scan

Report

SAQ and ASV Scan

Report

Determined by Payment

Brand or Acquirer

Service Providers

Level 1 Level 2 Level 3 (AMEX)

Type of Assessment Onsite Assessment Self-Assessment Self-Assessment

Reporting RequirementsROC and ASV Scan

Report

SAQ and ASV Scan

Report

SAQ and ASV Scan

Report


The PCI DSS: Reporting

The Self-Assessment Questionnaire (SAQ)

• The SAQ is a validation tool intended to assist merchants and service providers in

self-evaluating their compliance with the PCI DSS

• There are multiple versions of the PCI DSS SAQ to meet various scenarios

• The PCI DSS SAQ is a validation tool for merchants and service providers not

required to submit an on-site data security assessment Report on Compliance.

13

SAQ Description

A Card-Not-Present (e-commerce or MO/TO) merchants, all cardholder data functions outsourced to

PCI DSS compliant service providers. Not applicable to face-to-face channels.

A-EP E-commerce merchants who outsource all payment processing to PCI DSS validated third parties,

and who have a website(s) that doesn't directly receive cardholder data but that can impact the

security of the payment transaction. No electronic storage, processing, or transmission of any

cardholder data on the merchant's systems or premises. Applicable only to e-commerce channels.



The SAQ Continued

14

SAQ Description

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

merchants with no electronic cardholder data storage. Not applicable to e-commerce channels.

B-IP Merchants using only stand-alone, PTS-approved payment terminals with an IP connection to the

payment processor, with no electronic cardholder data storage. Not applicable to e-commerce

channels.

C Merchants with segmented payment application systems connected to the Internet, with no

electronic cardholder data storage. Not applicable to e-commerce channels.

C-VT Merchants using only web-based virtual payment terminals, with no electronic cardholder data

storage. Not applicable to e-commerce channels.

P2PE Merchants who have implemented a validated Point-to-Point Encryption Solution t hat is listed on the

PCI SSC website, with no electronic cardholder data storage. Not applicable to e-commerce

channels.

D Merchants: All merchants not included in the descriptions for other SAQ types.

Service Providers: All service providers identified by a payment brands as eligible to complete a

self-assessment questionnaire.



The SAQ – An Eye Opener Comparison

15

SAQ PCI DSS

Total

Requirements

A A-EP B B-IP C C-VT D (M) D (SP) P2PE V3.2

22 193 41 84 162 81 332 365 33 428

• Even when completely outsourced, merchants have PCI responsibilities.

• For e-commerce, an API vs. an iFrame could mean the difference of 170+

requirements even when outsourced.

• POTS vs. IP could mean the difference between 40+ requirements when

using standard swipe/dip terminals.

• The industry as a whole is really going towards P2PE.


The PCI DSS Assessment

How to Scope

PCI DSS security requirements apply to:

• Systems that store, process, or transmit cardholder data

• Systems that provide security services or may impact the security of the CDE

• Any other component or device located within or connected to the CDE

Scope includes:

• People

• Process

• Technology

The first step of a PCI DSS assessment is to accurately determine the scope.

At least annually and prior to the annual assessment the assessed entity:

• Identifies all locations and flows of cardholder data to verify they are included in the CDE

• Confirms the accuracy of their PCI DSS scope

• Retains their scoping documentation for assessor reference

The assessor validates that the scope of the assessment is accurately defined and documented

Scoping the Environment Scope Verification

16



How to Scope (Contd.)

• Understand the environment being assessed, including the system components and physical locations where card holder data is stored, processed, or transmitted.

• Data flow diagrams help identify where cardholder data could exist

• An inventory should be completed to document all in-scope systems

• Allow adequate time for discovery, testing, and remediation.

• If you don’t need, don’t store it !!!

• Outsource, preferably with PCI compliant service providers

• Segmentation and Separation

• Consider reporting against payment channels separately

Preparation Ways to Reduce Scope

17



Common Scoping Errors

• Not having a complete inventory of all systems that store, process, or transmit cardholder data

• Not identifying "unknown" data that has "leaked" out of applications and databases

• Not identifying all physical locations that store, process or transmit cardholder data

• Not identifying all connected networks and confirming network segmentation is in place and effective

• Not allowing enough time to interview all application, database, and system owners

• Not allowing enough time to perform thorough system testing

• Assuming encrypted data is out of scope

• Not taking into account the multiple layers of applicability

• Access and authentication mechanisms

• Non-console access

• Network, system, application, database

• Supporting systems

18

Classification: //SecureWorks/Confidential - Limited External Distribution:© SecureWorks, Inc.

Scope Reduction Techniques

19

Cardholder data.

If you don’t need it, remove it.



Concept of Separate Payment Channels

E-commerce

• Outsourced to PCI compliant service provider

• Uses iFrame

Retail

• Using P2PE solution, and;

• Using dial-out POIs

Call Center

• Leverages e-commerce site above

• Calls are recorded

Kiosks

• IP connected on airport network

20

What is the reporting requirements?

SAQ A

SAQ B &

SAQ P2PE

SAQ C

SAQ B-IP?

What if the merchant

network is separated?



Segmentation

• Network segmentation of, or isolating, the cardholder data environment from the remainder of the corporate network is not a PCI DSS requirement.

• Without adequate network segmentation (sometimes called a "flat network") the entire network is in scope of the PCI DSS assessment.

21

• Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technology that restricts access to a particular segment of a network.

• Any device that isolates the cardholder data environment from the rest of the network could be used for segmentation.

Segmentation = Separation =

No Connectivity

Pinholes = Controlled Access =

Still in Scope

Out of Scope = Untrusted =

Security not Reviewed



Segmentation (Cont.)

22

Graphic complements of the PCI Security Standards Council

PCI Network

Controlled Access

E-commerce?

Supporting Services

Access Control Lists

User Listings

Configuration Settings

Database Schemas


So you found out there’s some…issues.

23

1. It is more common than you think.

2. Work with a trusted advisor.

3. The bank (or payment card brand) likes a project plan.

Me! (shameless plug)


PCI DSS Gap Remediation

The Prioritized Approach

• Helps entities implementing PCI DSS to identify highest risk targets

• Enables entities to demonstrate progress

24

• Helps acquirers objectively measure compliance activities, and risk reduction efforts


Useful Resources

25

• Validated Payment Applications

• Validated P2PE Solutions

• Qualified Security Assessors

• Approved Scanning Vendors

• PCI Forensic Investigators

• Validated Service Provider Listing• Not all inclusive

• Entities pay $$$ for listing

• Center for Internet Security• Platform Benchmarks

• Platform Security Baselines

• PCI DSS v3.2

• Understanding SAQs for PCI DSS

• Prioritized Approach

• Document Library for Guidance on:• E-commerce

• Intro to PCI

• Logging

• Mobile

• Pentesting & Phishing

• Risk Assessment

• Security Awareness

• SSL/TLS

• Tokenization

• Virtualization and Cloud

The PCI Security Standards Council and Additional Resources

https://www.pcisecuritystandards.org/assessors_and_solutions/payment_applications?agree=true

https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_solutions

https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors

https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors

https://www.pcisecuritystandards.org/assessors_and_solutions/pci_forensic_investigators

https://www.visa.com/splisting/searchGrsp.do

https://www.cisecurity.org/

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf?agreement=true

https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf?agreement=true

https://www.pcisecuritystandards.org/documents/Prioritized-Approach-for-PCI_DSS-v3_2.pdf?agreement=true

https://www.pcisecuritystandards.org/document_library


Questions and Answers

26


Thank You

27

[email protected]

© secureworks, inc. · pci standards overview common myths and misconceptions ... a-ep e-commerce...

Documents