By Miodrag Kondi, Project Manager, source.digital@outlook.

com

March 11, 2015

PCI DSS V 3.0 for CDE

Ecosystem of payment devices, applications, infrastructure and users

Requirements Scope
The cardholder data environment (CDE) is comprised of people, processes, and technology that
handle cardholder data or sensitive authentication data. System components include network
devices, servers and applications. Virtualization components, such as virtual machines, virtual
switches/routers, virtual appliances, virtual applications/desktops, are also considered CDE
system components within PCI DSS.
#
1

Objective
Secure network

Protect cardholder data

Vulnerability management

Requirement
-Install and maintain FIREWALL to protect
cardholder data
- All CDE locations of cardholder data are
identified and documented in diagram
-Do not used system stored passwords and
other security parameters alike
-Encrypt transmission of cardholder data
over public domain network - security
protocols such as SSL/TLS, SSH or IPSec
- Limit cardholder data storage and
retention time to that which is required for
business or legal
- Purge unnecessary stored data at least
quarterly.
- Regular update of anti virus and malware
software
- Prevent coding vulnerabilities in software
development processes
- Use secure coding techniques and APIs
- Guideline for coding how sensitive data is
handled in memory (OWASP Top 10, SANS
CWE Top 25, CERT Secure Coding)
-

Strong access control

APIs threat-modelling techniques

verified integrity of source code
strict versioning code management

-restrict access to card holder data by

businesses
- Implement two-factor authentication for
all remote network access that originates
from outside the system network
-each person accessing the computer must
have unique id assigned to it
1|P a ge

By Miodrag Kondi, Project Manager, source.digital@outlook.com

Information security policy

March 11, 2015

-all access to network resources and

cardholder data must be monitored
-regular PENT of system security, quarterly

The PCI Security Standards Council has released an updated version of the requirements and security
assessment procedures which took affect from Jan 2015. This update required all players in the
payment chain to certify and comply with Version 3.0 requirements.

Req 1 Payment system and Network Architecture

Must include cardholder data flows and implemented into Business-as-usual activities
Must include clear boundary showing PCI DSS CDE scope and segments

The new standard brings some very significant changes to PCI compliance - the good news for the
service providers is that merchants are tempted to outsource more of their payment businesses to
service providers than ever before.

Masking PAN
PAN (when displayed) first 6 and last 4 digits are the maximum number of digits displayed. Only
authorized people with a legitimate business are allowed to see the full PAN.

Encrypting PAN Make PAN unreadable anywhere it is stored including portable digital media, backup
logs, data received from or by wireless networks. Technology solutions for include strong one-way hash
functions of the entire PAN, truncation, index tokens with securely stored pads, or strong cryptography.

Req 2 Impact of new requirements

a) Business as usual function maintains PCI DSS compliant environment between assessments
b) Implement automated audit trails for all system components for these events:
individual user accesses to cardholder data, actions taken by individual with root or
administrative privileges, invalid logical access attempts;
changes to identification and authentication mechanisms (including creation of new accounts,
elevation of privileges), and all changes, additions, deletions to accounts with root or administrative
privileges, initialization, stopping or pausing of the audit logs, creation and deletion of system-level
objects.

Req 3 Integration of PA-DSS during application development process

PCI DSS Version 3.0, applicable since January 1st, 2015 favours traditional, hosted payment form APIs
over direct post or widget-based payment forms such as Stripe.js or Mastercards Simplify, due to the
integration and inclusion of secure coding practices in former ones.
Hosted payment APIs have traditionally been in alignment with following principles of software
development:
- OWASP, NIST, SANS secure coding practices
- application threat-modelling techniques,
2|P a ge

By Miodrag Kondi, Project Manager, source.digital@outlook.com

-

March 11, 2015

verified integrity of source code,

professional versioning code management system
periodic security reviews of APIs
release notes for all API updates

OS Command Injection, LDAP and XPath injection flaws in coding

Improper error handling that leak information via notification messages
Cross-site scripting (XSS): insecure direct object references, failure to restrict URL access or
directory traversals

Req 4 Vulnerability Management

-

Register and maintain all wireless access points, hardware and software components
Penetration testing MUST validate segmentation and prove that a compromise in non CDE
network will not result in a breach of the CDE environment
Changes to organization structure
Critical files must be checked weekly AND individual must evaluate any changes

Logging identification

Administration and root privilege credential upgrades must be logged

Changes, addition or deletion of root admin must be logged
Initialization of audit logs must be captured
Stopping or pausing of audit logs must be captured
Payment application does not require or use any group, shared, or generic accounts and
passwords.

If multiple users share the same authentication credentials, it becomes impossible to assign accountability for, or
to have effective logging of, an individuals actions, since a given action could have been performed by anyone that
has knowledge of the authentication credentials.

Req 5 Antivirus
Attempt to prevent malware in addition to viruses, in previous versions
Evaluate malware threats against systems (EVEN if it is not a system commonly affected by
viruses/malicious software, for e.g. AS/400, OS/2, IBM 3900, etc.)
Anti-virus should be running at ALL TIMES in active mode without disable option for standard
users
Payment application locks out user accounts after not more than six invalid logon attempts or
minimum of idle time of 15 minutes or less

Req 6 Application flaws, injections and error notifications

Test applications for broken authentication and session management flaws

Injection flaws, particularly SQL injection, are addressed by coding techniques that include:
Validating input to verify user data cannot modify meaning of commands and queries (utilize
parameterized queries)
Improper error handling that leak information via notification messages
Renamed Web Application Firewall to Automated Technical Solution to detect flaws
Coding techniques include documentation of how PAN and/or SAD are handled in memory.

3|P a ge

By Miodrag Kondi, Project Manager, source.digital@outlook.com

March 11, 2015

Req 7 Access control and user IDs

Provides for user flexibility of password controls - Minimum 7 characters/Alphanumeric.
The novelty is that Tokens and/or Certificates are also allowed as means of authentication
Payment Service Provider MUST ensure unique password per customer (after June 30, 2015).
Minimizing the exposure of PAN/SAD while in memory will help reduce the likelihood that it can be
captured by a malicious user or be unknowingly saved to disk in a memory file and left unprotected.

Req 8 Policies/Procedures
Third Party/Service provider requirements have been raised:
Keep registry of requirements which are dependent upon service provider
Written acknowledgement required from service providers attesting to PCI DSS
Third parties to provide PCI DSS certificate OR be willing to be a part of customers PCI DSS audit

Req 9 Physical security (no relevance for SAD)

Physical security access to sensitive areas must be implemented for onsite personnel
Data center
Computer room
Telecommunications room
Protect physical devices such as POS
Maintain updated inventory of devices
Periodically inspect for tampering with devices
Train personnel and be aware of suspicious behavior
Merchants and APIs are commonly found to be the weakest link in the payment security chain.
The PCI is raising the bar for the risks of data being exploited if a merchants and/or API payment
servers are attacked or hacked.
- merchants could outsource PCI compliance to a highly-secure and fully compliant and certified
PCI DSS Level 1 payment provider
New extended questionnaire SAQ mandates merchants to PENETRATION TESTING
- 140 questions (compared to 14 so far)
Major impediment for small merchants business development, both financially and operationally to:
Revisit segmentation of network and data objects within the APIs and system for adequacy
Identify technology for business as usual implementation (integration of the PCI in everyday
business)
Penetration and intrusion tests regularly executed and reported
Identify how to secure physical devices such as POS, ATM and Kiosks
However, widget-based payment pages are clearly the preferred choice of merchants, as they embed
naturally into a web shops and are much easier to integrate and customize.
Direct post payment forms also create more solid user experience, avoiding style breaks through use of
hosted iFrame payment forms, and responsive design across tablet, cell and PC devices. This in turn
creates trust, resulting in higher conversions for the merchant.
4|P a ge

By Miodrag Kondi, Project Manager, source.digital@outlook.com

March 11, 2015

SAQ
SAQ serves as a validation tool for service providers to report the results of their PCI DSS selfassessment, if they are not required to submit a Report on Compliance (ROC).

SAQ

Description

A Card-not-present merchants (e-commerce or mail/telephone-order) that

have fully outsourced all cardholder data functions to PCI DSS compliant
third-party service providers, with no electronic storage, processing, or
transmission of any cardholder data on the merchants systems or premises.
E-commerce merchants who outsource all payment processing to PCI DSS
validated third parties, and who have a website(s) that doesnt 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 merchants systems or premises.
Merchants using only:
Imprint machines with no electronic cardholder data storage; and/or
Standalone, dial-out terminals with no electronic cardholder data storage.
Merchants using only standalone, PTS-approved payment terminals with an
IP connection to the payment processor, with no electronic cardholder data
storage.
Merchants who manually enter a single transaction at a time via a keyboard
into an Internetbased virtual terminal solution that is provided and hosted
by a PCI DSS validated thirdparty service provider. No electronic cardholder
data storage.
Merchants with payment application systems connected to the Internet, no
electronic cardholder data storage.
Merchants using only hardware payment terminals that are included in and
managed via a validated, PCI SSC-listed P2PE solution, with no electronic
cardholder data storage.
SAQ D for Merchants: All merchants not included in descriptions for the
above SAQ types. SAQ D for Service Providers: All service providers defined
by a payment card brand as eligible to complete a SAQ.

A-EP

B-IP

C-VT

C
P2PE-HW

5|P a ge