The document details the Payment Card Industry Data Security Standard (PCI DSS) and Payment Application Data Security Standard (PA DSS), outlining guidelines for securely processing and protecting cardholder data. It provides requirements for network security, vulnerability management, access control, and data protection, as well as changes in versions 3.2 and 3.2.1 of PCI DSS. Additionally, it emphasizes the importance of network segmentation, penetration testing, and data discovery for maintaining compliance and reducing risks of data breaches.

1. PCI DSS & PA DSS
By Kishor Vaswani – CEO, ControlCase

2. Agenda
• About PCI DSS & PA DSS
• Segmentation and Penetration Testing
• Card Data Discovery and Memory
• Q&A
1

3. About PCI DSS & PA DSS

4. What is PCI DSS?
Payment Card Industry Data Security Standard:
• Guidelines for securely processing, storing, or
transmitting payment card account data
• Established by leading payment card issuers
• Maintained by the PCI Security Standards Council
(PCI SSC)
2

5. PCI DSS Requirements
Control Objectives Requirements
Build and maintain a secure network 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
Protect cardholder data 3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public
networks
Maintain a vulnerability
management program
5. Use and regularly update anti-virus software on all systems
commonly affected by malware
6. Develop and maintain secure systems and applications
Implement strong access control
measures
7. Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
Regularly monitor and test networks 10. Track and monitor all access to network resources and
cardholder data
11. Regularly test security systems and processes
Maintain an information security
policy
12. Maintain a policy that addresses information security
3

6. PCI DSS 3.2
4
• PCI DSS 3.2 in place starting 2016
• Accommodate updated migration dates for SSL/early
TLS
• Support for display of PAN beyond first six / last four
• Incorporate some business as usual (BAU) requirements
• Expanded multi-factor authentication requirements

7. PCI DSS 3.2.1 – Summary of Changes
• Removal of notes referring to effective dates of
mandatory requirements
• SSL/early TLS is not considered strong cryptography and
may not be used as a security control, except by POS POI
terminals
• The updates in PCI DSS 3.2.1 do not affect the Payment
Application Data Security Standard (PA-DSS), which will
remain at v3.2
• Following are the links to PCI DSS v3.2.1 documents:
PCI DSS Documentation Guidelines:
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-
1.pdf?agreement=true&time=1527370368099
PCI DSS Summary of changes:
https://www.pcisecuritystandards.org/documents/PCI_DSS_Summary_of
_Changes_3-2-1.pdf?agreement=true&time=1527370368112
5

8. PA DSS Introduction
• Payment Application: A software application that stores, processes, or
transmits cardholder data as part of authorization or settlement, where
the payment application is sold, distributed, or licensed to third parties.
• Commercial Payment Applications that are typically sold and installed “off
the shelf” without pre-installation customization by Vendors.
› e.g. POS, Payment middleware, PG/Switch, Payment module
• PA-DSS Does Not Apply to:
• Operating systems onto which Payment Applications are installed.
• Database systems that store cardholder data.
• Back-office systems that store cardholder data (for example, for
reporting or customer service purposes).
6

9. PA DSS Requirements
7
Requirement 1: Do not retain full track data, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data
Requirement 2: Protect stored cardholder data
Requirement 3: Provide secure authentication features
Requirement 4: Log payment application activity
Requirement 5: Develop secure payment applications
Requirement 6: Protect wireless transmissions
Requirement 7: Test payment applications to address vulnerabilities and maintain payment application updates
Requirement 8: Facilitate secure network implementation
Requirement 9: Cardholder data must never be stored on a server connected to the Internet
Requirement 10: Facilitate secure remote access to payment application
Requirement 11: Encrypt sensitive traffic over public networks
Requirement 12: Secure all non-console administrative access
Requirement 13: Maintain a PA-DSS Implementation Guide for customers, resellers, and integrators
Requirement 14: Assign PA-DSS responsibilities for personnel, and maintain training programs for personnel, customers, resellers, and
integrators

10. Segmentation and Penetration Testing

11. What is Network Segmentation
• In the context of PCI DSS, Network Segmentation
is a process where you isolate the CDE systems
(Systems storing, processing & transmitting the
CHD) from non-CDE systems.
• Key thing to Note: Network Segmentation is not
mandatory requirement.
8

12. Network Segmentation & Scoping Guidelines
Store
Process
Transmit
CDE
Connected To
Impact Security
Provide
Security
Provide
Segmentation
People, Process and Technology
9

13. Flat Network Example
Users
Cardholder Servers
Infrastructure servers
Development Servers
Since there is no segmentation
done all the Systems will fall in PCI
DSS scope
10

14. Segmented Network Example
Other Users
Cardholder Servers
Infrastructure servers
Development Servers
Segmented network using Firewall/Core Switch, ensure that
traffic is limited to finance users and scope is reduces to only
finance users, cardholder servers and infrastructure servers
Finance Users
Firewall/Core
Switch
11

15. • A method of evaluating the security of a computer
system, network or application by simulating an
attack by a malicious hacker.
• Involves an active analysis of the system for any
weaknesses, technical flaws or vulnerabilities.
• Carried out from the position of a potential attacker,
and involves an active exploitation of security
vulnerabilities.
• Performed from outside the external perimeter or
from within the internal network.
What is a Penetration Test?
12

16. • To determine whether and how a malicious user
can gain unauthorized access to assets and
eventually sensitive data
• To confirm that the applicable PCI DSS controls,
such as configuration standards, vulnerability
management, and segmentation are in place
Why is it important?
13

17. • Entire CDE perimeter
• Any critical systems that may impact the security
of the CDE
• External perimeter (public-facing attack surfaces)
• Segmentation and scope-reduction controls
What should we include in the test?
14

18. • 11.3.4 - CDE Segmentation Verification
› Applicable if segmentation is used to isolate CDE from
other networks
› Verifies that segmentation methods are operational and
effective, and isolate all out-of-scope systems from in-
scope systems
› Must provide tester documentation of segmentation
technologies
› Testing against CDE systems from outside CDE
› Testing against out-of-scope systems within the CDE
Segmentation Verification
15

19. • Based on the best practices from Open-Source
Security Testing Methodology Manual (OSSTMM),
Open Web Application Security Project (OWASP) and
NIST SP800-115
• Includes coverage of the CDE perimeter and critical
systems
• Includes testing from both inside and outside the
network
• Includes testing from non CDE internal network to
CDE internal network
• Includes testing to validate any segmentation and
scope-reduction controls
Methodology
16

20. Example Segmentation PT Result
• Segmentation Failed
› If we note that firewall is configured to allow unrestricted
access (any ports and services) from the store/corporate
general network into the store POS Network (CDE)
› If firewall allows access from not-in-scope network to CDE
• Segmentation Passed
› If there is no access detected for any of the ports and
services from the store general network into the store POS
Network (CDE).
17

21. Best Practices to Pass Segmentation PT
• Rule-set review shall be done to verify the rules against the
business requirements.
• All unused rules shall be removed
• All ACLs shall be configured in a way that they do not allow
access from out of scope to CDE.
• All changes in network shall be done through change
management process and in line with the “Network
Segmentation” policy and procedure.
• If non-CDE segments have access into the CDE, either the
organization needs to restrict that access or a full network-layer
penetration test should be performed to characterize the access.
18

22. Card Data Discovery & Memory

23. What is Data Discovery
• Ability to identify and pinpoint sensitive data
across
› File Shares
› Servers
› Databases
› Email
› Log files
› Etc.
19

24. Why is it important
• CIA focuses on confidentiality, integrity and
availability
• Confidentiality is always focused on “Data”
• Data that is sensitive must be protected, however
the first step of that is to know where the data
resides
• Hence, it is important to identify where sensitive
data resides
20

25. Protect Stored Cardholder Data
You must ensure stored data is encrypted and
protected.
21

26. PCI Council Advisory…
• Importance of Updating Scope for PCI DSS Assessments
There have been a number of high profile data compromises in the
press recently. These reports serve as a daily reminder of the
damage caused by compromises and of the need to keep business
environments secure. Businesses evolve and change over time,
and the scope of an entity's cardholder data environment must be
reviewed and verified each time a PCI DSS assessment is
undertaken. As has always been the case, many compromises are
the result of businesses having data they weren't aware of. Please
remember that scoping an assessment includes verifying that no
cardholder data exists outside of the defined cardholder data
environment. By ensuring the scope of an assessment is
appropriate, the risk of data compromise is greatly reduced - a
benefit to everyone involved.
22

27. Methods for Data Discovery
• DLP Solutions (McAfee etc.)
• Card Data Discovery Solutions (ControlCase etc.)
• Manual Scripts and Regular Expressions
• Forensic Technology (EnCase etc.)
23

28. Data Discovery Planning Considerations
• Deployment and agents
› Can get expensive
› Technologically complicated
› Long deployment cycles
› Databases are a challenge
• False Positives
› Luhn’s formula narrows down but is not full proof
› Many schemes use Luhn’s formula to generate numbers
› Separators and delimiters change
24

29. Planning Considerations contd…
• Performance within production environments
› Database load
› Large number of records in databases
› Active directory scanning
› Emails storing cardholder data
• Tokenization
› Differentiation between tokens and real card numbers
• Exclusions
› Directories
› Files
› Extension types
› Tables/Columns
25

30. PA DSS and Card Data in Memory
• PA DSS has requirement around card data storage in
memory
› Coding techniques must include how PAN and sensitive data is
handled in memory per requirement 5
• Test for data in memory using memory dump tools
such as Winhex
• Cardholder Data in volatile memory must be handled
securely to avoid memory scraping attacks
• POS devices are primary targets
• Applications must rewrite memory with NULL once
the transaction authorization is completed
26

31. To Learn More About PCI Compliance…
• Visit www.controlcase.com
• contact@controlcase.com

32. Thank You for Your Time