pci version three and thee

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.!

PCI DSS

QSA ROC AOC ISA

SAQ PA-DSS

P2PE

Acronym soup

ASV

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!

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!

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!

Chiseled in STONE!

✽

—  Even  if  encrypted  ✽  SensiBve  AuthenBcaBon  Data  

—  Even  if  it’s  sound  

1 2 3 4

Call Centers!No !

PCI standard calls for!

a clean desk!

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!

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;!

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.!

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.!

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.!

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.!

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? !

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!

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.!

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.!

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.!

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.!

Oh No!

Not

Another

Version!

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

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!

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!

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.!

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 !

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.!

Guidance for each requirement!

V2 ROC Reporting Instructions!

V3 Report on Compliance Template!

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!

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 !

This is me!

ENIAC!UNIVAC!

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. !

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.!

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 ofthe customer, or to the extent that they could impact the securityof the customer’s CDE.!

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!

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!

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.!

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!

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. !

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. !

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.!

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. !

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. !

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.!

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!

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!

Not only do you have…!

A good security and risk posture!

You should be compliant with little additional effort.!

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. !

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!

“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      

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.

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