OWASP Education
The OWASP Foundation
Computer based training
http://www.owasp.org
PCI DSS and PA-DSS
Nishi Kumar
IT Architect Specialist, FIS
OWASP CBT Project Lead
OWASP Global Industry Committee
Nishi.Kumar@owasp.org
Contributor and Reviewer
Keith Turpin
Reviewer
Kuai Hinojosa
Christian Heinrich
Objectives
Understand PCI compliance
Know most common PCI issues
Understand PCI DSS and PA-DSS requirements
Understand the mapping between
OWASP Top 10 for 2010 and CWE/SANS Top 25
2
PCI – Payment Card Industry
“The PCI Data Security Standard represents a
common set of industry tools and measurements
to help ensure the safe handling of sensitive
information…the standard provides an actionable
framework for developing a robust account data
security process - including preventing, detecting
and reacting to security incidents.”
– PCI Standards Council
3
DSS in a nutshell
The PCI (Payment Card Industry) DSS (Data Security Standard) is:
A set of minimum baseline controls for
securing payments
Required (everyone in the payment lifecycle
must comply)
A unified standard agreed to by all card brands
4
A unified standard
5
Everyone must comply
(resistance is futile)
Everyone must be compliant with the standard
6
Lifecycle Process for Changes
PCI change management process
7
PCI – Payment Card Industry
There are two sets of standards developed based on the type of
payment application
PCI DSS – PCI Data Security Standard
PA-DSS – Payment Application Data Security Standard
Payment applications that are sold, distributed or licensed to third
parties are subject to the PA-DSS requirements
8
PA-DSS
Formerly known as -PABP (Payment Application Best Practices)
supervised by Visa
Goals
Develop secure payment applications that do not store
prohibited data, such as full magnetic stripe, CVV2 or PIN data
Ensure their payment applications support compliance
with the PCI DSS
The requirements for the PA-DSS are derived from the PCI DSS
9
PCI DSS
PCI DSS only applies if PANs are stored, processed and/or transmitted.
10
The most common
PCI audit issues…
PCI – Payment Card Industry
Most of the time, it’s one or more of the “deadly half-dozen”:
1. Inappropriate scope
2. Insufficient documentation
3. Application issues
4. Unnecessary (or inappropriate) data storage
5. Compensating controls (that don’t compensate)
6. Bad timing
If you can get past these, you’re in pretty good shape
12
Enemy #1: Inappropriate Scope
#1 most common assessment issue
Remember, the assessment scope applies only to the
Cardholder data environment (CDE)
Cardholder environment: systems that store, process, or
transmit cardholder data
The assessor must include everything in scope that is not
segmented from the CDE
No segmentation? Then the assessor must include
everything in scope
This is where everybody starts
This approach rarely (never?) leads to a clean
Report of Compliance (ROC)
13
Scoping Example
Red area denotes scope of PCI assessment
14
The Solution: Zones
(Enforcement of Scope)
Once you have defined the scope of the CDE, you need to
enforce it usually with:
Firewalls
Physical separation (“air gap”)
If you don’t enforce the scope, again the assessor must
evaluate the entire environment
Document it
Document how your zoning approach enforces the scope
Document why you’ve chosen the approach you have
Document who is responsible for maintaining the boundary
15
Enemy #2: Inadequate Documentation
Remember, the requirements aren’t “rocket science”
Chances are good you are already (mostly) compliant
But “if there’s no document, it doesn’t exist”
QSA(Qualified Security Assessor) must disregard ad-hoc or
informal processes
Which means you need to have documented policy and
defined procedures
You need to document – even if you’re pretty confident
that your process meets the requirement
16
The Solution: They have to
document as well…
“Forewarned is forearmed”
QSA’s must follow the defined assessment procedures. This
means everything they are going to do, look for, evaluate,
request, or sample is written down and can be found online
If you had the answers to a test ahead of time, wouldn’t you at
least glance at it while studying?
https://www.pcisecuritystandards.org/security_standards/documents.php?agreem
ents=pcidss&assocation=PCI%20DSS
17
Enemy #3: Apps
Apps are hard, no matter how you slice it
The requirements for apps are pretty tough
OWASP Guide (OWASP “Top Ten”), SANS/CWE Top 25,
CERT Secure Coding
Lifecycle requirements
Requirements for code review and “application-level
firewall” (this means “a web application firewall (WAF)”*)
Need to have a solid strategy for application security in place
18
Solution : Apps
Read OWASP
The application requirements are verbatim from the OWASP Guide
(OWASP Top 10), SANS CWE Top 25 and CERT Secure Coding
Assessor will be looking for a documented SDLC (software
development lifecycle) that incorporates specific application security
testing
Assessors will usually look at the process first, and only a sample of
specific apps
19
Enemy #4: Data Storage
You can’t store authorization data after authorization
Don’t ever store track (magnetic-stripe) data or CVV/CVC. No
matter who says to
There are good business reasons to store the PAN
“One click”
If you’re going to store it, you need to protect it
If you store the PAN, you’ll need to encrypt, truncate, or hash
Encrypting the PAN is the only approved way to store it so you
can use it later
20
Solution : Data Storage
Limit what you keep
If there’s any way you can get away with it, try not to store the PAN
Consider a “data deletion” policy to govern storage of cardholder
data
21
Enemy #5: Inadequate Compensating Controls
If you can’t meet particular controls, you attempt to apply
compensating controls
However, there are specific rules for compensating controls
that need to be followed
Not following the rules means your assessor can’t accept it
22
Solution : Inadequate Compensating Controls
Compensating controls need to meet the intent and the rigor
of the original requirement
Adding key management doesn’t help you meet an
authentication requirement
Compensating controls must be documented
Compensating controls are subjective, document them fully to
build your case
Even if you can’t meet a control, document why you can’t and
what else you are doing to address the issue
Assessor wants to agree with you. Thorough documentation
makes it easy for the assessor to agree
Compensating controls have a shelf life
They’re a “stop-gap”, not an “end state
Example: Lack of encryption on a mainframe would be accepted
for a certain period of time
23
Enemy #6: Bad Timing
There are times when you have a fantastic strategy for how to
solve an issue, but the QSA can’t use it because it’s not what’s in
production
A QSA (Qualified Security Assessors ) can’t validate to
what’s not in production
If it’s not in production now, it can’t be in or out of compliance –
it’s just not there
Notes: QSA’s are required based on the tiers. You can get this
information from http://whatlevelami.com/
24
Solution : Bad Timing
Pre-assess and preplan
Read the documentation the assessor will be using to evaluate you
PCI Assessment Procedures available from the PCI Standards
Council website (http://www.pcisecuritystandards.org)
PCI Standards Documentation
Pre-assess
Do the pre-assessment questionnaire (even if you don’t have to)
Go through a pre-assessment exercise (with or without a QSA) to
make sure you have everything in place before the assessment starts
Deploy compensating controls before use them for the “real deal”
25
PCI DSS Requirements
Build and Maintain a Secure Network
Requirement 1 Install and maintain a firewall configuration to protect cardholder
data
Requirement 2 Do not use vendor-supplied defaults for system passwords and
other security parameters
Protect Cardholder Data
Requirement 3 Protect stored cardholder data
Requirement 4 Encrypt transmission of cardholder data across open, public
networks
Maintain a Vulnerability Management Program
Requirement 5 Use and regularly update anti-virus software or programs
Requirement 6 Develop and maintain secure systems and applications (6.5 OWASP Guide, SANS CWE Top 25, CERT Secure Coding)
26
PCI DSS Requirements
Implement Strong Access Control Measures
Requirement 7
Restrict access to cardholder data by business need-to-know
Requirement 8
Assign a unique ID to each person with computer access
Requirement 9
Restrict physical access to cardholder data
Regularly Monitor and Test Networks
Requirement 10
Track and monitor all access to network resources and
cardholder data
Requirement 11
Regularly test security systems and processes
Maintain an Information Security Policy
Requirement 12
Maintain a policy that addresses information security
27
PA-DSS Requirements
Requirement 1
Do not retain full magnetic stripe, card validation 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 (5.2 - OWASP Guide, SANS CWE Top 25, CERT
Secure Coding)
Requirement 6
Protect wireless transmissions
Requirement 7
Test payment applications to address vulnerabilities
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 software updates
Requirement 11
Facilitate secure remote access to payment application
Requirement 12
Encrypt sensitive traffic over public networks
Requirement 13
Encrypt all non-console administrative access
Requirement 14
Maintain instructional documentation and training programs
for customers, resellers, and integrators
28
OWASP Top 10 & 2010 CWE/SANS Top 25
mapping
https://www.owasp.org/index.php/
Category:OWASP_Top_Ten_Project
A1: Injection
http://www.sans.org/top25-software-errors/
http://cwe.mitre.org/top25/
[2] CWE-89:
[9] CWE-78:
Improper Neutralization of Special Elements
used in an SQL Command
('SQL Injection')
Improper Neutralization of Special
Elements used in an OS Command
('OS Command Injection')
A2: Cross-Site Scripting
(XSS)
[1] CWE-79:
Improper Neutralization of Input During
Web Page Generation('Cross-site Scripting')
A3: Broken Authentication and Session
Management
[19] CWE-306:
[11] CWE-798:
Missing Authentication for Critical Function
Use of Hard-coded Credentials
A4: Insecure Direct Object References
[5] CWE-285:
[6] CWE-807:
[7] CWE-22:
Improper Authorization
Reliance on Untrusted Inputs in a Security
Decision
Improper Limitation of a Pathname to a
Restricted Directory ('Path Traversal')
A5: Cross-Site Request Forgery (CSRF) [4] CWE-352:
Cross-Site Request Forgery (CSRF)
29
OWASP Top 10 & 2010 CWE/SANS Top 25
mapping
A6:
Security Misconfiguration
[16] CWE-209:
Information Exposure Through an Error Message
(Only partially covers OWASP Risk)
A7:
Insecure Cryptographic
Storage
[10] CWE-311:
[24] CWE-327:
Missing Encryption of Sensitive Data
Use of a Broken or Risky Cryptographic Algorithm
A8:
Failure to Restrict URL
Access
[5] CWE-285:
Improper Authorization
(Also listed with OWASP A-4)
Incorrect Permission Assignment for Critical
Resource (CWE-732 covers a broader scope than
OWASP A8)
[21] CWE-732:
A9:
Insufficient Transport
Layer Protection
[10] CWE-311:
[24] CWE-327:
A10: Unvalidated Redirects
and Forwards
[23] CWE-601:
Missing Encryption of Sensitive Data
(Also listed with OWASP A-7)
Use of a Broken or Risky Cryptographic Algorithm
(Also listed with OWASP A-7)
URL Redirection to Untrusted Site
('Open Redirect')
30
OWASP Top 10 &
2010 CWE/SANS Top 25 mapping
Not a comprehensive or equivalent comparison
OWASP defines ten risks - made up of several specific
vulnerabilities
CWE/SANS Top 25 is only a fraction of the full CWE
list of weaknesses
Complete mapping will have many CWEs listed for
each item on the OWASP Top 10 list
Mapping should be used for general reference
purposes only
31
2010 CWE/SANS Top 25
The following do not directly map to the OWASP Top 10 2010
[3] CWE-120:
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
[8] CWE-434:
Unrestricted Upload of File with Dangerous Type
[12] CWE-805: Buffer Access with Incorrect Length Value
[13] CWE-98: Improper Control of Filename for Include/Require Statement in PHP
Program ('PHP File Inclusion')
[14] CWE-129: Improper Validation of Array Index
[15] CWE-754: Improper Check for Unusual or Exceptional Conditions
[17] CWE-190: Integer Overflow or Wraparound
[18] CWE-131: Incorrect Calculation of Buffer Size
[20] CWE-494: Download of Code Without Integrity Check
[22] CWE-770: Allocation of Resources Without Limits or Throttling
[25] CWE-362: Concurrent Execution using Shared Resource with Improper
Synchronization ('Race Condition')
32
Cert Secure Coding Standards
Establish coding guidelines for commonly used
programming languages that can be used to improve the
security of software systems under development Based
on documented standard language versions as defined
by official or de facto standards organizations Secure
coding standards are under development for:
The CERT C Secure Coding Standard, Version 2.0
The CERT C++ Secure Coding Standard
The CERT Oracle Secure Coding Standard for Java
33
Summary
Most issues are preventable
Most of the issues come down to planning and preparation
 Planning you do in advance of the assessment translates directly
into dollars for your organization
 Less time-consuming for the assessment (which means it’ll be
cheaper)
 A “clean” ROC means you don’t need to pay for do-overs
 Comprehensive documentation means less time your staff
spends answering questions
Act before the assessment
The time to find out that you have issues is before the assessment
Planning should be thorough – shoot for no surprises once the
assessment is underway
34
References
MITRE - http://www.mitre.org/
The MITRE Corporation is a not-for-profit organization that manages
several Federally Funded Research and Development Centers. Mitre
currently runs various IT security projects including the Common
Weakness Enumeration (CWE) and it is the official source for the
CWE/SANS Top 25 Most Dangerous Software Errors.
CWE Database - http://cwe.mitre.org/
SANS - http://www.sans.org
The SysAdmin, Audit, Network, Security (SANS) Institute operates as
a commercial research and education company. SANS is well known
for its Internet Storm Center, its comprehensive list computing security
training programs and its work with Mitre on the CWE/SANS Top 25
Most Dangerous Software Errors.
35
References
OWASP - www.owasp.org
The Open Web Application Security Project (OWASP) Foundation is a
not-for-profit organization whose goal is to improve the safety and
security of the world’s software. OWASP is probably best known for its
key projects, like the Top 10 Web Application Security Risks, and for
its application security conferences.
CERT - www.cert.org
The CERT® Program is part of the Software Engineering Institute
(SEI). CERT's primary objectives include analyzing and
communicating the state of internet security through its US-CERT
Vulnerability Notes Database and improving software security with its
secure coding practices publications.
US-CERT Vulnerability Notes Database - http://www.kb.cert.org/vuls/
CERT Secure Coding Practices - http://www.cert.org/secure-coding/
36
37