ABA PDI Seminar, May 2008

The American Bar Association
Section of Science & Technology Law and the

ABA Center for Continuing Legal Education
Present
The Legal Implications and Risks of the Payment Card
Industry (PCI) Data Security Standard

American Bar Association
Center for Continuing Legal Education
321 North Clark Street, Suite 1900
Chicago, IL 60610-4714
www.abanet.org/cle
800.285.2221, select option 2
CDs, DVDs, ONLINE COURSES, PODCASTS, and COURSE MATERIALS

ABA-CLE self-study products are offered in a variety of formats. To take advantage of our full
range of options, visit the ABA Web Store at www.abaclecatalog.org.
The materials contained herein represent the opinions of the authors and editors and should not be
construed to be the action of the American Bar Association, Section of Science & Technology Law or the
Center for Continuing Legal Education unless adopted pursuant to the bylaws of the Association.
Nothing contained in this book is to be considered as the rendering of legal advice for specific cases, and
readers are responsible for obtaining such advice from their own legal counsel. This book and any forms
and agreements herein are intended for educational and informational purposes only.
© 2008 American Bar Association. All rights reserved.
This publication accompanies the audio program entitled “The Legal Implications and Risks of the
Payment Card Industry (PCI) Data Security Standard” broadcast on April 29, 2008 (Event code:
CET8LIP).
Discuss This Course Online
Visit http:/www.abanet.org/cle/discuss to access the discussion board for this program.
Discussion boards are organized by the date of the original program,
which you can locate on the preceding page of these materials.
The Legal Implications and Risks of
the Payment Card Industry Data
Security Standard
Our Panelists
David Navetta, Esq., InfoSecCompliance, LLC,

djn@davidnavetta.com
Arshad Noor, StrongAuth, Inc. arshad.noor@strongauth.com
Alex Pezold, FishNet Security, Alex.Pezold@fishnetsecurity.com
The Legal Implications and Risks of the Payment Card Industry Data Security Standard
1
3
Roadmap
PCI Background
Hannaford Factual Summary
PCI Interpretative Variances
Legal Implications of PCI
Risk Mitigation Efforts
What is PCI?
Security standard for the protection of payment card data

(any card with a payment card brand logo – credit/debit)
Not a law – industry self regulation
Arose out of individual security programs developed by

payment card brands (e.g. VISA CISP, MasterCard SDP,
AMEX DSOP, Discover DISC)
Compliance: 1 PCI Standard; 5 payment card brand

security programs
2
5
Build and Maintain a Secure Network
1. Install and maintain a firewall
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 or programs
6. Develop and maintain secure systems and applications
Implement Strong Access Control Measures
7. Restrict access to cardholder data by the 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 and Information Security Policy
12. Maintain a policy that addresses information security
PCI Standard v. Payment Card Security Programs
PCI – minimum security controls, policies and procedures
vs.
Security Programs -- procedural in nature

merchant level definitions, procedures, deadlines and
documentation for validating PCI compliance, documentation
requirements for security assessment, security incident
response requirements and fines and penalties
3
7
PCI Standard v. Payment Card Security Programs
VISA CISP MasterCard SDP
PCI Standard
Discovery DISC AMEX DSOP
PCI Framework and Procedures
PCI Council: www.pcisecuritystandards.org/
Qualified Security Assessors and Approved Scanning

Vendors
Assessment and scanning processes and requirements –

Independent Assessment v. Self Assessment
Questionnaire
4
9
Merchant Levels
Level 1 Any merchant processing over 6 million VISA or MasterCard

transactions per year, or identified by any other payment card brand as
Level 1.
Level 2 Any merchant processing 1 to 6 million VISA or MasterCard

transactions per year.
Level 3 Any merchant processing 20,000 to 1 million VISA or MasterCard e-

commerce transactions per year.
Level 4 Any merchant processing fewer than 20,000 VISA or MasterCard e-

commerce transaction per year.
10
Assessment Actions
Level Assessment Actions Validated By
Annual On-Site Security Assessment Independent Assessor or Internal Audit if signed

by Officer of the Company
- AND -
1 Quarterly Network Scan Qualified Independent Scan Vendor
Annual Self-Assessment Questionnaire Merchant
2&3 - AND - Optional support from qualified vendor
Quarterly Network Scan Qualified Independent Scan Vendor
Annual Self-Assessment Questionnaire Merchant

Recommended
Optional support from qualified vendor
4 Network Scan Recommended Qualified Independent Scan Vendor
5
11
Validation Dates
Date Applies to
9/30/07 All Level 1 merchants identified from 2004-2006
12/31/07 All Level 2 merchants identified from 2004-2006
9/30/08 All Level 1 merchants identified in 2007. Up to one year from

identification.
12/31/08 All Level 2 merchants identified in 2007
12
Other Procedural Aspects
Fines and Penalties
Incident Response Requirements
Post-incident forensic audit
6
13
PCI Contract Chain
Payment Card Company (e.g. VISA, MasterCard, Discover, AMEX)
Merchant Bank (e.g. Chase, Citibank, 5th Third Bank, credit unions)
Payment Processing Org. (e.g. PaymentTech, First Data)
Merchant (e.g. any company that accepts payment cards for transactions)
Service Provider (e.g. any company that processes, transmits or stores payment card data)
14
PCI Contract Chain
Scope of PCI Obligations dictated contractually
No Direct Contractual Relationship between Merchants and Payment Card

Companies.
No Direct Duty for Service Providers to Comply with PCI or Security Programs
PCI Section 12.8 -- A Merchant’s Compliance with PCI is Directly Contingent on

Contractual Obligations Imposed on its Service Providers
Matching Upstream and Downstream Obligations and Risk.
Special problem: existing service provider relationships and PCI Compliance
7
15
Hannaford Brothers Grocery Breach

4.2 million cards; 1800 identity theft incidents; 21 Consumer class actions filed in Federal
Courts in 3 States
Servers in 300 stores across 3 states compromised at Point of Sale terminal – appears that
the data was not encrypted on internal networks or prior to transmitting for processing
December 7, 2007-- Data breach first began on – privacy policy stated PCI Compliant at the
time
February 27, 2008 -- Hannaford became aware of the breach
February 27, 2008 -- Hannaford recertified as PCI Compliant
March 10, 2008 -- Breach contained
March 17, 2008 -- Reported by Hannaford
Hannaford undergoing post-incident forensic audit
April 22. 2008 – Hannaford reports plans to spend millions on security, including
encryption of all card numbers during the entire time they are within the supermarket
chain's data network and intrusion detection
16
Section 3.4 – encryption of Primary Account Number while stored
Section 4.1 – encryption of sensitive cardholder data in transit

Open, public networks
“networks that are easy and common for a hacker to intercept, modify,
and divert data while in transit
Other potentially problematic sections
8
17
Section 3.2 – do not store sensitive authentication data

after authorization (even if encrypted)
Section 12.8 – service provider contractual obligation for

PCI compliance
“Compensating controls”
18
PCI Legal Link
Negligence – PCI as standard of care

TJX – Expert
TJX – Post-incident audit
Plastic Card Protection Laws
Minnesota Plastic Card Protection Law – PCI Section 3.2
Other states that have considered/are considering reimbursement
laws: Massachusetts, Illinois, Connecticut, Texas, Minnesota,
California, Michigan, Alabama, Iowa and Washington
9
19
Security Viewpoint v. Legal Viewpoint
Strict Interpretation (“to the letter”)
Looser; not strictest, but “reasonable interpretations”
Looser – “unreasonable”
“Loose-est” Interpretation -- Non-compliant
20
Resolving Ambiguities
Multiple Sources of Interpretation
Unclear Binding Effect
Unclear Authoritative Weight of Interpretations
10
21
Potentially Legally Risky Practices
QSA shopping
Rubber-stamping
Scoping Problems -- providing the full picture (where is the data?,

where is it being processed?)
SAQ -- check-box mentality (SAQ v. 1.0 does not map to 1.1

Standard; SAQ 1.1 – short versions; compliance with the
Standard)
22
Other Legal Risks
Reasonable security v. PCI Compliance
T.J. Hooper?
"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 adoption of new and available devices. . . . Courts must in
the end say what is required. There are precautions so imperative that
even their universal disregard will not excuse their omission."
-- Judge Learned Hand
11
23
PCI & False Sense of Security
PCI certification = point in time
Having policies and procedures to follow PCI v. actually implementing
How were ambiguities resolved? (e.g. PCI Council, payment card brand,
acquiring bank, business considerations, e-mails, etc.)
How was the process approached? (e.g. QSA shopping, rubber stamping,
check box mentality, proper personnel, etc.)
Existence/Scope of “Safe Harbor”?
24
Process-Oriented Adverse Admissions
Bad documentation/assessments during

assessment process
Future promises of PCI compliance (by merchant

or service providers)
Post-incident forensic assessments
12
25
Section 12.8 “Interpretative Variances”
12.8 If cardholder data is shared with service providers, then

contractually the following is required:
12.8.1 Service providers must adhere to the PCI DSS

requirements
12.8.2 Agreement that includes an acknowledgment that the
service provider is responsible for the security of cardholder
data the provider possesses
26
Section 12.8 “Interpretative Variances”

Narrow interpretation: contract language indicates that service provider must adhere to
the PCI Standard, which means that the minute the contract is effective the service provider
must be PCI-compliant and the merchant should confirm such compliance;
Middle-ground interpretation: contract language indicates that service provider agrees

that it must adhere to the PCI Standard, but the merchant does not need to confirm such
compliance, but rather can trust the service provider’s contractual representation that it is
compliant and responsible for cardholder data; and
Loose interpretation: contract language indicates that the service provider agrees that it
must adhere to the PCI Standard, but the merchant has discovered that the service provider
has some controls that need to be implemented to achieve full PCI compliance and
imposes a deadline after the effective date of the contract to achieve such compliance in
the future. Under this interpretation a merchant complies with 12.8.1 as long as the service
provider contractually promises to adhere to the PCI Standard during the contract term by a
certain reasonable date, even if not compliant at the inception of the contract.
13
27
Hannaford (Complete and Utter) Speculation
PCI Compliant and reasonably secure
PCI Compliant, but not reasonable security (PCI Standard itself is weak)
QSA or Hannaford misinterpreted PCI / ambiguity (or relied on a bad interpretation

provided by a different PCI Stakeholder)
Hannaford did not supply QSA with full information
Hannaford changed – PCI Compliant at point in time (Feb. 2007)
Hannaford did not follow its PCI policies and procedures after PCI compliance
assessed
28
What to do?
From a security standpoint….

Reasonable security is the goal
Segregate remediation and assessment.
Err on the side of caution for interpretations (stricter; to the
word)
Choose QSAs wisely
Draw your general counsel into the process at the beginning
14
29
What to do?
From a legal standpoint?
Contractually
Assess Upstream; Impose Downstream
Develop a service provider contracting strategy (current and future
vendors)
Incorporate “waivers” into the contract
Liability Mitigation
Reach out to the security team and get involved at the start (A.C.T.
awareness, communication, translation)
Use attorney-client privilege (e.g. remediation work)
Adverse admissions – look out for the creation of a paper trail (e.g.
audits, letters to merchant banks, etc.)
Strict compliance (and if not, anticipate litigation issues)
Get it in writing and have it confirmed by relevant stakeholders
30
Questions?
David Navetta, Esq., InfoSecCompliance, LLC,

djn@davidnavetta.com
Arshad Noor, StrongAuth, Inc.

arshad.noor@strongauth.com
Alex Pezold, FishNet Security,

Alex.Pezold@fishnetsecurity.com
15

ABA PDI Seminar, May 2008

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ABA PDI Seminar, May 2008

Hochgeladen von

Copyright:

Verfügbare Formate

The American Bar Association

Section of Science & Technology Law and the

The Legal Implications and Risks of the Payment Card

Industry (PCI) Data Security Standard

CDs, DVDs, ONLINE COURSES, PODCASTS, and COURSE MATERIALS

© 2008 American Bar Association. All rights reserved.

 David Navetta, Esq., InfoSecCompliance, LLC,

 Arshad Noor, StrongAuth, Inc. arshad.noor@strongauth.com

 Alex Pezold, FishNet Security, Alex.Pezold@fishnetsecurity.com

 Hannaford Factual Summary

 PCI Interpretative Variances

 Legal Implications of PCI

 Risk Mitigation Efforts

 Security standard for the protection of payment card data

 Not a law – industry self regulation

 Arose out of individual security programs developed by

 Compliance: 1 PCI Standard; 5 payment card brand

Build and Maintain a Secure Network

1. Install and maintain a firewall

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 or programs

6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

7. Restrict access to cardholder data by the 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

11. Regularly test security systems and processes

Maintain and Information Security Policy

12. Maintain a policy that addresses information security

PCI Standard v. Payment Card Security Programs

 PCI – minimum security controls, policies and procedures

 Security Programs -- procedural in nature

PCI Standard v. Payment Card Security Programs

VISA CISP MasterCard SDP

Discovery DISC AMEX DSOP

PCI Framework and Procedures

 PCI Council: www.pcisecuritystandards.org/

 Qualified Security Assessors and Approved Scanning

 Assessment and scanning processes and requirements –

Level 1 Any merchant processing over 6 million VISA or MasterCard

Level 2 Any merchant processing 1 to 6 million VISA or MasterCard

Level 3 Any merchant processing 20,000 to 1 million VISA or MasterCard e-

Level 4 Any merchant processing fewer than 20,000 VISA or MasterCard e-

 Annual On-Site Security Assessment  Independent Assessor or Internal Audit if signed

 Annual Self-Assessment Questionnaire  Merchant

2&3 - AND -  Optional support from qualified vendor

 Quarterly Network Scan  Qualified Independent Scan Vendor

 Annual Self-Assessment Questionnaire  Merchant

4  Network Scan Recommended  Qualified Independent Scan Vendor

9/30/07 All Level 1 merchants identified from 2004-2006

12/31/07 All Level 2 merchants identified from 2004-2006

9/30/08 All Level 1 merchants identified in 2007. Up to one year from

Other Procedural Aspects

 Fines and Penalties

 Incident Response Requirements

 Post-incident forensic audit

PCI Contract Chain

Payment Card Company (e.g. VISA, MasterCard, Discover, AMEX)

Payment Processing Org. (e.g. PaymentTech, First Data)

David Navetta, Esq., InfoSecCompliance, LLC,

Arshad Noor, StrongAuth, Inc. arshad.noor@strongauth.com

Alex Pezold, FishNet Security, Alex.Pezold@fishnetsecurity.com

Hannaford Factual Summary

PCI Interpretative Variances

Legal Implications of PCI

Risk Mitigation Efforts

Security standard for the protection of payment card data

Not a law – industry self regulation

Arose out of individual security programs developed by

Compliance: 1 PCI Standard; 5 payment card brand

PCI – minimum security controls, policies and procedures

Security Programs -- procedural in nature

PCI Council: www.pcisecuritystandards.org/

Qualified Security Assessors and Approved Scanning

Assessment and scanning processes and requirements –

Annual On-Site Security Assessment Independent Assessor or Internal Audit if signed

Annual Self-Assessment Questionnaire Merchant

2&3 - AND - Optional support from qualified vendor

Quarterly Network Scan Qualified Independent Scan Vendor

Annual Self-Assessment Questionnaire Merchant

4 Network Scan Recommended Qualified Independent Scan Vendor

Fines and Penalties

Incident Response Requirements

Post-incident forensic audit

Scope of PCI Obligations dictated contractually

No Direct Contractual Relationship between Merchants and Payment Card

PCI Section 12.8 -- A Merchant’s Compliance with PCI is Directly Contingent on

Matching Upstream and Downstream Obligations and Risk.

Special problem: existing service provider relationships and PCI Compliance

February 27, 2008 -- Hannaford became aware of the breach

February 27, 2008 -- Hannaford recertified as PCI Compliant

March 10, 2008 -- Breach contained

March 17, 2008 -- Reported by Hannaford

Hannaford undergoing post-incident forensic audit

Section 3.4 – encryption of Primary Account Number while stored

Section 4.1 – encryption of sensitive cardholder data in transit

Other potentially problematic sections

Section 3.2 – do not store sensitive authentication data

Section 12.8 – service provider contractual obligation for

Negligence – PCI as standard of care

Multiple Sources of Interpretation

Unclear Binding Effect

Unclear Authoritative Weight of Interpretations

Scoping Problems -- providing the full picture (where is the data?,

SAQ -- check-box mentality (SAQ v. 1.0 does not map to 1.1

Reasonable security v. PCI Compliance

PCI certification = point in time

Having policies and procedures to follow PCI v. actually implementing

Existence/Scope of “Safe Harbor”?

Bad documentation/assessments during

Future promises of PCI compliance (by merchant

Post-incident forensic assessments

Middle-ground interpretation: contract language indicates that service provider agrees

PCI Compliant and reasonably secure

QSA or Hannaford misinterpreted PCI / ambiguity (or relied on a bad interpretation

Hannaford did not supply QSA with full information

Hannaford changed – PCI Compliant at point in time (Feb. 2007)

From a security standpoint….

David Navetta, Esq., InfoSecCompliance, LLC,

Arshad Noor, StrongAuth, Inc.

Alex Pezold, FishNet Security,