The OWASP Foundationhttp://www.owasp.org

OWASP EducationComputer based training

PCI DSS and PA-DSSNishi Kumar

IT Architect Specialist, FISChair, Software Security Forum at FIS

OWASP CBT Project LeadOWASP Global Industry Committee

Nishi.Kumar@owasp.org

Contributor and Reviewer Keith Turpin

Reviewer Kuai Hinojosa

Christian Heinrich

2

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

3

PCI – Payment Card Industry

“The PCI Data Security Standard represents acommon set of industry tools and measurementsto help ensure the safe handling of sensitiveinformation…the standard provides an actionableframework for developing a robust account datasecurity process - including preventing, detectingand reacting to security incidents.”

– PCI Standards Council

4

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

5

A unified standard

6

Everyone must comply (resistance is futile)

Everyone must be compliant with the standard 

7

Lifecycle Process for Changes

PCI change management process

8

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

9

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

10

PCI DSS

PCI DSS only applies if PANs are stored, processed and/or transmitted.

The most common PCI audit issues…

12

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

13

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 startsThis approach rarely (never?) leads to a clean

Report of Compliance (ROC)

14

Scoping Example Red area denotes scope of PCI assessment

15

The Solution: Zones (Enforcement of Scope)

Once you have defined the scope of the CDE, you need to enforce it usually with:

FirewallsPhysical separation (“air gap”)

If you don’t enforce the scope, again the assessor must evaluate the entire environment

Document itDocument how your zoning approach enforces the scopeDocument why you’ve chosen the approach you haveDocument who is responsible for maintaining the boundary

16

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

17

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?agreements=pcidss&assocation=PCI%20DSS

18

Enemy #3: Apps

Apps are hard, no matter how you slice it

The requirements for apps are pretty toughOWASP Guide (OWASP “Top Ten”), SANS/CWE Top 25,

CERT Secure CodingLifecycle requirementsRequirements 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

19

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

20

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 itIf you store the PAN, you’ll need to encrypt, truncate, or hashEncrypting the PAN is the only approved way to store it so you

can use it later

21

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

22

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

23

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

24

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/

25

Solution : Bad Timing Pre-assess and preplan

Read the documentation the assessor will be using to evaluate youPCI 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”

26

PCI DSS Requirements

Build and Maintain a Secure NetworkRequirement 1 Install and maintain a firewall configuration to protect cardholder

dataRequirement 2 Do not use vendor-supplied defaults for system passwords and

other security parametersProtect Cardholder DataRequirement 3 Protect stored cardholder dataRequirement 4 Encrypt transmission of cardholder data across open, public

networksMaintain a Vulnerability Management ProgramRequirement 5 Use and regularly update anti-virus software or programsRequirement 6 Develop and maintain secure systems and applications (6.5 -

OWASP Guide, SANS CWE Top 25, CERT Secure Coding)

27

PCI DSS Requirements

Implement Strong Access Control MeasuresRequirement 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 NetworksRequirement 10 Track and monitor all access to network resources and

cardholder data

Requirement 11 Regularly test security systems and processes

Maintain an Information Security PolicyRequirement 12 Maintain a policy that addresses information security

28

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

29

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

http://www.sans.org/top25-software-errors/http://cwe.mitre.org/top25/

A1: Injection [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 FunctionUse of Hard-coded Credentials

A4: Insecure Direct Object References [5] CWE-285:[6] CWE-807:[7] CWE-22:

Improper AuthorizationReliance on Untrusted Inputs in a Security DecisionImproper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

A5: Cross-Site Request Forgery (CSRF) [4] CWE-352: Cross-Site Request Forgery (CSRF)

OWASP Top 10 & 2010 CWE/SANS Top 25 mapping

30

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:

[21] CWE-732:

Improper Authorization (Also listed with OWASP A-4)Incorrect Permission Assignment for Critical Resource (CWE-732 covers a broader scope than OWASP A8)

A9: Insufficient Transport Layer Protection

[10] CWE-311:

[24] CWE-327:

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)

A10: Unvalidated Redirects and Forwards

[23] CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

OWASP Top 10 & 2010 CWE/SANS Top 25 mapping

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

32

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')

33

Cert Secure Coding StandardsEstablish 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

34

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

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