The OWASP Foundationhttp://www.owasp.org

OWASP EducationComputer based

training

PCI DSS and PA-DSSNishi Kumar

IT Architect Specialist, FISOWASP CBT Project Lead

OWASP Global Industry CommitteeNishi.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-DSSFormerly 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 scope2. Insufficient documentation3. Application issues4. Unnecessary (or inappropriate) data storage5. 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 scopeThis 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 it

If 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 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”

26

PCI DSS Requirements

Build and Maintain a Secure NetworkRequirement 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 DataRequirement 3

Protect stored cardholder data

Requirement 4

Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management ProgramRequirement 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)

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 dataRequirement 2 Protect stored cardholder dataRequirement 3 Provide secure authentication featuresRequirement 4 Log payment application activityRequirement 5 Develop secure payment applications (5.2 - OWASP Guide, SANS CWE

Top 25, CERT Secure Coding)Requirement 6 Protect wireless transmissionsRequirement 7 Test payment applications to address vulnerabilitiesRequirement 8 Facilitate secure network implementationRequirement 9 Cardholder data must never be stored on a server connected to the

InternetRequirement 10 Facilitate secure remote software updatesRequirement 11 Facilitate secure remote access to payment applicationRequirement 12 Encrypt sensitive traffic over public networksRequirement 13 Encrypt all non-console administrative accessRequirement 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 25The 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 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

34

Summary Most issues are preventableMost 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

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