An overview of PCI DSS 3.0 and how it applies to you and your business.

2. Why PCI!
• In August 2012 an employee of the South
Carolina Department of Revenue opened an
email enabling a malware attack.!
– Employee’s credentials were lifted.!
– Miscreants used credentials in remote login!
• 75GB of backups exfiltrated in September!
• Income tax returns of every SC citizen
exposing SSNs, bank account numbers, etc.!
• CC numbers exfiltrated but not exposed.!

3. PCI DSS
QSA ROC
AOCISA
SAQPA-DSS
P2PE
Acronym soup
ASV

4. The Acronyms!
• Payment Card Industry—the brands!
• Data Security Standard has requirements!
– Self Assessment Questionnaires have fewer!
• Approved Scanning Vendor—external scans!
• Qualified Security Assessor—test and report!
– Internal Security Assessor—home grown!
• Report On Compliance—requirements met?!
– Attestation Of Compliance—cross my heart!
• Payment Application-DSS—e.g. point of sale!

5. ATM
Security
Guidelines
Mobile
Payment
Acceptance
Security
Guidelines
for
Developers
v1.0
Mobile
Payment
Acceptance
Security
Guidelines
for
Merchants
v1.0
PCI
DSS
2.0
Cloud
CompuBng
Guidelines
PCI
DSS
2.0
eCommerce
Guidelines
PCI
DSS
2.0
Risk
Assessment
Guidelines
PCI
DSS
Applicability
in
an
EMV
Environment
Guidance
v1.0
PCI
DSS
TokenizaBon
Guidelines
PCI
DSS
v2.0
Wireless
Guidelines
PCI
DSS
VirtualizaBon
Guidelines
v2.0
ProtecBng
Telephone-­‐based
Payment
Card
Data
Requirement
11.3
PenetraBon
TesBng
v1.2
Requirement
6.6
ApplicaBon
Reviews
and
Web
ApplicaBon
Firewalls
Clarified
v1.2
Skimming
PrevenBon—Best
PracBces
for
Merchants
Understanding
the
SAQs
for
PCI
DSS
v3.0
Information Suppliments!

6. What’s on the card
Cardholder data (CHD) and SAD!
• Primary account number—PAN!
• Sensitive authentication data—SAD!
– Encoded into the magnetic track!
• Card Verification Code 1—CVV1!
– Encoded into “chip and PIN” cards—PIN!
– Printed on the front or back on the card!
• CVV2!
• Expiration date!
• Cardholder name!

7. Chiseled in STONE!
✽
—
Even
if
encrypted
✽
SensiBve
AuthenBcaBon
Data
—
Even
if
it’s
sound
1 2 3 4

8. Call Centers!
No !
PCI standard
calls for!
a clean desk!

9. Call Centers!
• No PCI standard calls for a clean desk.!
– Control physical media, e.g. paper, flash drive.!
– Restrict access to handheld devices.!
• Recordings of calls may hold CHD—encrypt.!
• But what about sensitive authentication data?!
– Avoid it by not collecting CVV2 et al, or pause
recording, or connect caller to Interactive Voice
Response (IVR) system; or,!
– Deploy a compensating control.!
• Protecting Telephone-based Payment Card Data!

10. What is a compensating control?
1 of 2!
• Described when the deployed controls are
not those specified in the requirement.!
• For each compensating control one must:!
– state the technical or business reason
compliance to the requirement as written is
not possible;!
– describe what the original control was
supposed to do and what the compensating
control does;!
– Identify risk cause by lack of original control;!

11. What is a compensating control?
2 of 2!
– Describe the control and how it addresses the
requirement and any increased risk;!
– The QSA must describe how the control was
tested to validate; and,!
– Describe how will the control be maintained.!
• A compensating control cannot be one that
is already mandated for the asset.!
– e.g. integrity checking on the server which
doesn’t have anti-malware software installed.!

12. Electronic Commerce!
• No physical presence so you don’t worry
about point-of-sale systems, skimmers, or
track data.!
• Instead, you’re on the friendly Internet
using hardy web browsers and servers.!

13. Store, process, and transmit!
• Your web server talks to your customer to
take order and collect CHD for payment.!
• To make purchases “easier” for your
customer, you save the CHD, but not SAD,
for subsequent purchases.!
• You communicate with your processor to
authenticate account and then make the
charge.!
• You have a lot of explaining to do.!

14. Your applications!
• May be bespoke—customized to your
business by you or third party.!
– This application must be evaluated by the QSA.!
• May be purchased commodity software.!
– Purchase PCI-certified Payment Applications
and follow Implementation Guide.!
– If not, QSA must evaluate.!
• May be a mélange, e.g. your web services
fronting purchased shopping cart software.!

15. Over there for payment please!
What if I get
someone else to
accept the CHD and
process the charge?!
I never see CHD.!
Do I still have to be
PCI compliant? !

16. That depends!
• The PCI DSS 2.0 eCommerce Guidelines
describes several scenarios.!
– Shared Management!
• Direct Post!
• iFrame!
• Redirect!
– Wholly outsourced!
• A new SAQ, A-EP, is available for version 3!

17. Embedded APIs with Direct Post!
• Use processor-provided
APIs to plug code into
customer’s browser
window.!
• When data is entered into
payment fields, it is sent
directly to the processor,
not to the merchant.!
• Merchant must ensure
that that its website is not
compromised.!

18. Inline iFrames!
• Processor’s web page is
embedded within the web
page of the merchant.!
• Data entered into iFrame
is sent directly to the
processor and not seen
by the merchant.!
• Compromise of merchant
website may result in a
compromise of iFrame.!

19. Hosted-payment page!
• Merchant’s page contains
link to payment processor
website.!
• Customer is redirected to
that site to enter payment
information.!
• If the merchant webpage
is compromised, the
customer could be
redirected to a bad-guy
site to enter CHD.!

20. Wholly outsourced!
• Customer connects directly to third-party
site for all functions, including payment.!
– Merchant can login to manage store content.!
• This is also a good solution for those
businesses who collect payment
information over the phone.!
– The CSR connects directly to the customer or
to the card processor to enter CHD and
amount to be charged.!

21. Oh No!
Not
Another
Version!

22. Version 3.0 !
• Three year development cycle!
• Available for compliance in 2014!
• Mandatory for compliance beginning 2015!

23. What did they want to fix!
• Divergent interpretations of the standard!
• Weak or default passwords!
• Slow detection of compromise!
• Security problems introduced by 3rd
parties!
• and various other areas!

24. Highlights!
• The twelve steps…errr…requirements remain!
• Some sub-requirements added!
• Policy and procedure requirements proximate
to items each policy and procedure addresses!
• Descriptions of tests are more precise!
– Aligned language of requirement and test !
– Clarified what to do to verify compliance!
• More rigor in determining scope of
assessment!
• More guidance on log reviews!
• More rigorous penetration testing!

25. No hiding documentation sins!
• Version 2 aggregates all policy and
procedure requirements in one location.!
– 12.1.1 Verify that the [security] policy
addresses all PCI DSS requirements. !
– 12.2 Verify that [daily operational security
procedures] are consistent with this
specification, and include administrative and
technical procedures for each of the
requirements.!
• Difficult to detect requirements not covered.!

26. Moved to relevant locations!
– 1.5
managing firewalls are
. !
– 2.5 managing vendor defaults and other
security parameters are !
– 3.7 protecting stored cardholder data are
– 8.8 identification and authentication are !
– 10.8 monitoring all access to network
resources and cardholder data are !

27. Eschew Ambiguity!
• Too much variance in interpretation among
QSAs!
– Clients get different interpretations.!
– PCI Counsel’s Quality Control sees too much
variance in the Reports on Compliance (ROC).!
• Version 3 removes ambiguities in the
specification that result in inconsistent
interpretations of a requirement.!

28. Guidance for each requirement!

29. V2 ROC Reporting Instructions!

30. V3 Report on Compliance Template!

31. Version 3 SAQs!
• Format and content changes!
– Expected Testing, a new column !
– the Special column has been replaced with
Yes with CCW (compensating control
worksheet) and N/A!
– sections reorganized to ensure that an entity’s
attestation encompasses all elements of the
SAQ and AOC!
• eligibility for, and requirements within,
each SAQ have been revised!

32. There’s some new SAQs in town!
• A-EP!
e-commerce merchants who outsource all
payment processing to 3rd parties, using a
website that doesn’t directly receive cardholder
data but that can impact the security of the
payment transaction!
• A-IP!
merchants using only standalone,
PTS-approved payment terminals with an IP
connection to the payment processor, with no
electronic cardholder data storage !

34. This is
me!
ENIAC!UNIVAC!

35. New authentication requirement!
• If you use identical credentials to
authenticate yourself to all your customers…!
• …a compromise of one of those customers
exposes all the other customers.!
• New Requirement 8.5.1!
Service providers with remote access to
customer premises (for example, for support of
POS systems or servers) must use a unique
authentication credential for each customer. !

36. Division of labor with 3rd party!
• New requirement, 12.8.5, mandates that
the assessed entity is aware of which DSS
requirements are managed by the service
provider and which are managed by the
entity.!
• How this division is documented and
agreed between the assessed entity and
the service provider is not specified.!

37. Service Provider Responsibility1 of 2!
New requirement,12.9, mandates that Service
providers acknowledge in writing to customers
that they are responsible for the security of
cardholder data the service provider
possesses or otherwise stores, processes, or
transmits on behalf of
the customer, or to the
extent that they could
impact the security
of the customer’s CDE.!

38. Service Provider Responsibility2 of 2!
• The exact wording of that acknowledgement
will depend on:!
– the agreement between the two parties;!
– the details of the service being provided; and,!
– the responsibilities assigned to each party.!
• The acknowledgement does not have to
include the exact wording provided in this
requirement.!
• Get your lawyers involved!

39. Service Provider Responsibility2 of 2!
• The exact wording of that acknowledgement
will depend on:!
– the agreement between the two parties;!
– the details of the service being provided; and,!
– the responsibilities assigned to each party.!
• The acknowledgement does not have to
include the exact wording provided in this
requirement.!
• Get your lawyers involved!

41. They’re getting serious about the CDE!
Clause 3.1.1 of the ROC requires documentation of how the assessor
validated the accuracy of the PCI DSS scope by describing:!
– The methods or processes (for example, tools, observations, feedback,
scans, data flow analysis) used to identify and document all existences
of cardholder data.!
– The methods or processes (for example, tools, observations, feedback,
scans, data flow analysis) used to verify that no cardholder data exists
outside of the CDE scope defined for this assessment.!
– How the results of the methods/processes were evaluated to verify that
PCI DSS scope is appropriate.!
– How the results of the methods/processes were documented (e.g. the
results may be a diagram or an inventory of cardholder data locations).!
– Why the methods used for scope verification are considered by the
assessor to be effective and accurate.!
– Provide the name of the assessor who attests that the scope of the
assessment has been verified to be accurate and appropriate.!

42. A Penetration Test Methodology!
• Based on industry-accepted approaches,
e.g. NIST SP800-115!
• A new clause 11.3!
– Test entire perimeter of CDE & all critical systems!
– Validate all scope-reduction controls—segmentation!
– Test from inside and from outside of the network!
– Test network-function components and OSs!
– As a minimum, perform application tests for the
vulnerabilities listed in Requirement 6.5!

43. Those vulnerabilities are!
• Injection flaws, particularly SQL injection. !
• Buffer overflow !
• Insecure cryptographic storage !
• Insecure communications !
• Improper error handling !
• Cross-site scripting (XSS) !
• Improper Access Control, !
• Cross-site request forgery (CSRF)!
• Broken authentication and session
management. !

44. If you develop!
• Requirement 6.5 mandates that programmers of
internally-developed and bespoke applications must
be trained in secure coding techniques, including how
to avoid common coding vulnerabilities, and
understanding how sensitive data is handled in
memory. !
• The QSA must identify the records of training that
were examined to verify that software developers
received training on secure coding techniques,
including how to avoid common coding vulnerabilities,
and understanding how sensitive data is handled in
memory. !

45. Authentication!
• Requirement 8.2–6 text recognizes methods
other than password, e.g. passphrases or
certificates!
– Authentication credentials!
• Minimum password length is still 7 characters!
– “Alternatively, the passwords/phrases must have
complexity and strength at least equivalent to the
parameters specified above.”!
• A service provider must use a different
password for each of its clients.!

46. Quicker detection of compromise!
• Deploy a integrity change-detection
mechanism to alert personnel to
unauthorized modification of critical
system files, configuration files, or content
files !
– configure the software to perform critical file
comparisons at least weekly. !

47. Quicker detection of compromise!
• Deploy a integrity change-detection
mechanism to alert personnel to
unauthorized modification of critical system
files, configuration files, or content files !
– configure the software to perform critical file
coparison at least weekly. !
• New requirement, 11.5.1, mandates the
implementation of a process to respond to
any alerts generated by that mechanism. !

48. How much work is this?!
• Greater effort to move from 2.0 to 3.0 than
from 1.2 to 2.0!
• PCI compliance should be continuous!
– No frantic preparation before the arrival of the
auditors and a round of drinks after they
leave.!
• More stringent testing procedures may find
that previously compliant elements are
now non-compliant.!

49. Some new requirements need not be in place until
30 June 2015!
– 6.5.11 Broken Authentication and Session
Management !
– 8.5.1 Use of unique authentication credentials for each
client of a service provider.!
– 9.9 Protect POS from physical tampering!
– 11.3 Penetration test methodology!
– 12.9 Written acknowledgement of 3rd party
responsibilities and compliance!
Some breathing room!

50. If your organization…!
• practices good information governance such
that it is aware of what types of data it has
and where it stores, processes, and sends
that data;!
• properly protects access to its information
and its processes; and,!
• defines appropriate policies implemented by
self-documenting processes that not only
comply with PCI requirements but also create
easily discoverable evidence that compliance
was continuous throughout the year; then!

51. Not only do you have…!
A good security and
risk posture!
You should be compliant
with little additional effort.!

52. One more thing!
• Organizations often spend much effort to reduce the
portion of the enterprise that will be subject to PCI
DSS audit.!
• The effort to protect CHD and SAD within the CDE
should also be applied to PII throughout the entire
enterprise.!
• Had South Carolina done so, it’s likely no PII would
have been exposed. !
• A tugboat may lead us to the answer. !

53. The T. J. Hooper!
• Towed barges and cargo lost in storm!
• Cargo owners sue claiming negligence!
– Radio was a readily available technology!
– Couldn’t receive broadcasts warning of storm!
• No other tugboat operators had radios—
!the standard of care for the industry!
• In a landmark decision Judge Learned
Hand found the tugboat owners liable!

54. “Indeed
in
most
cases
reasonable
prudence
is
in
fact
common
prudence,
but
strictly
it
is
never
its
measure.
A
whole
calling
may
have
unduly
lagged
in
the
adopBon
of
new
and
available
devices…Courts
must
in
the
end
say
what
is
required.
There
are
precauBons
so
imperaBve
that
even
their
universal
disregard
will
not
excuse
their
omission.”
—Judge
Learned
Hand,
1932

55. Custom is not based merely on old
standards. It also must be based
on adapting to new technology. The
duty of care is a relative concept
that changes.

56. ?Hoyt
L.
Kesterson
II
Senior
Security
Architect
hoyt.kesterson@tvrms.com
602
316
1985
Scobsdale,
Arizona