1. PCI DSS and PA-DSS OWASP Education Nishi Kumar Computer based training
IT Architect Specialist, FIS
Chair, Software Security Forum at FIS
OWASP CBT Project Lead
OWASP Global Industry Committee
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 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

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 only applies if PANs are stored, processed and/or transmitted.

11. 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
PCI DSS Prioritized Approach – 6 Milestones – Easier way to get through the audit

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 starts
This approach rarely (never?) leads to a clean Report of Compliance (ROC)

14. Red area denotes scope of PCI assessment
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:
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

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?

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

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 hash
Encrypting 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

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 (
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 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)
1. Build and Maintain a Secure Network
Firewalls are computer devices that control computer traffic allowed into and out of a company’s network, as well as traffic into more sensitive areas within a company’s internal network. A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria. All systems must be protected from unauthorized access from the Internet, whether entering the system as e-commerce, employees’ Internet-based access through desktop browsers, or employees’ access. Often, seemingly insignificant paths to and from the Internet can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.
Hackers (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known in hacker communities and easily determined via public information.
2. Protect Cardholder Data
Encryption is a critical component of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted s.
Sensitive information must be encrypted during transmission over networks that are easy and common for a hacker to intercept, modify, and divert data while in transit.
3. Maintain a Vulnerability Management Program
Many vulnerabilities and malicious viruses enter the network via employees’ activities. Anti-virus software must be used on all systems commonly affected by viruses to protect systems from malicious software.
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches. All systems must have the most recently released, appropriate software patches to protect against exploitation by employees, external hackers, and viruses. Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

27. PCI DSS Requirements Implement Strong Access Control Measures
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
4. Implement Strong Access Control Measures
This requirement ensures critical data can only be accessed by authorized personnel.
Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted.
5. Regularly Monitor and Test Networks
Vulnerabilities are being discovered continually by hackers and researchers, and being introduced by new software. Systems, processes, and custom software should be tested frequently to ensure security is maintained over time and with any changes in software.
Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.
6. Maintain an Information Security Policy
A strong security policy sets the security tone for the whole company and informs employees what is expected of them. All employees should be aware of the sensitivity of data and their responsibilities for protecting it.

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. OWASP Top 10 & 2010 CWE/SANS Top 25 mapping
Category:OWASP_Top_Ten_Project
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 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:

30. OWASP Top 10 & 2010 CWE/SANS Top 25 mapping
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
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')

31. 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
The mapping between the OWASP top 10 and the CWE/SANS top 25 is not a comprehensive or equivalent comparison.
OWASP defines ten risks, that in most cases are made up of several specific vulnerabilities that are not all discreetly called out.
The complete CWE list is made up of hundreds of specific application weaknesses (vulnerabilities) and the top 25 is only a fraction of that list.
A complete mapping of the OWASP Top 10 to all relevant CWEs would result in many CWEs being listed for each item on the OWASP list.
For this reason the mapping between the OWASP top 10 and the CWE/SANS top 25 should be used for general reference purposes only.

32. 2010 CWE/SANS Top 25
The following do not directly map to the OWASP Top
[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 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

35. References MITRE - http://www.mitre.org/ SANS - http://www.sans.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 -
SANS -
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.
MITRE
MITRE: The MITRE Corporation is a not-for-profit organization chartered to work in the public interest. Founded in 1958 to support a project for the Department of Defense, it now manages Federally Funded Research and Development Centers for a number of government agencies.
MITRE currently runs several IT security related projects including the Common Weakness Enumeration (CWE) project, which can be found here:
MITRE maintains and is the official source for the CWE/SANS Top 25 Most Dangerous Software Errors. MITRE partners closely with the SANS institute on the Top 25 and SANS helps promote the list.
The CWE is a database of common software weaknesses (vulnerabilities). Each entry contains several associated data elements including, but not limited to the following:
Description
Time of Introduction: When in the software lifecycle is the weakness introduced
Applicable Platforms: Lists languages or system components
Common Consequences: What can an attacker do with it
Likelihood of Exploit: How easy is it to find and exploit
Detection Methods: Discusses testing methods like dynamic and static analysis
Demonstrative Examples: Code examples in one or more languages
Observed Examples: Typically references to items MITRE's Common Vulnerability Enumeration (CVE) database. The CVE is a database of publically disclosed vulnerabilities in commercial software. The full CVE is located here:
Potential Mitigations: How to prevent the weakness
Relationships: Mapping to other related CWEs and the OWASP top 10 where applicable and known.
Related Attack Patterns: Typically references to items MITRE's Common Attack Pattern Enumeration and Classification (CAPEC) database. This database contains descriptions of common methods for exploiting software and can be found here:
References
SANS
The SANS (SysAdmin, Audit, Network, Security) Institute was established in 1989 as a cooperative research and education organization. SANS has several free resources including the Internet Storm Center, the weekly news digest (NewsBites), the weekly vulnerability digest and more than 1,200 information security research papers.
SANS is also well known for its commercial IT security training programs. Many courses are taught in person or on-line and target specific groups with security responsibilities including: Developers, Investigators, Managers, Auditors, Legal staff and IT security generalists.

36. References OWASP - www.owasp.org CERT - www.cert.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 -
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 CERT Secure Coding Practices -
OWASP
The Open Web Application Security Project (OWASP) Foundation started in 2001 and was established as a not-for-profit charitable organization in the United States in OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security.
OWASP is probably best known for some of its leading projects including the OWASP Top 10. OWASP projects typically fall into two broad categories: tools/software or documents/guides. Tool projects include things like security APIs, testing tools and training environments. Document projects include things like secure coding practices, secure coding guides, testing guides, verification standards and many others.
Owasp Projects are all supported by a large community of volunteers from across many industry segments. The list of projects is constantly evolving and growing. Projects can are listed in one of four stages of development:
Stable Quality Projects: Generally considered enterprise ready
Beta Status Projects: Stable and useable, but may be a little rough around the edges
Alpha Status Projects: Generally these are projects in development and range widely in completeness
Inactive Projects: Projects that are no longer being maintained. However some are later revived if adequate volunteers and purpose can be found.
OWASP is also known for the regional, national and international Application Security conferences it sponsors. The conferences are of particular interest to those involved in software security as every talk is focused on some aspect of that topic.
CERT
The CERT® Program is part of the Software Engineering Institute (SEI), a federally funded research and development center at Carnegie Mellon University in Pittsburgh, Pennsylvania. Following the Morris worm incident, which brought 10 percent of internet systems to a halt in November 1988, the Defense Advanced Research Projects Agency (DARPA) charged the SEI with setting up a center to coordinate communication among experts during security emergencies and to help prevent future incidents. This center was named the CERT Coordination Center (CERT/CC).
One of CERT's primary objectives is to analyze the state of internet security and convey that information to the internet community. The CERT/CC monitors public sources of vulnerability information and regularly receives reports of vulnerabilities. CERT manages the US-CERT Vulnerability Notes Database, which is a list of serious, publically disclosed commercial software vulnerabilities. The Notes Database can be found here:
As part of our work to influence vendors to improve the basic, as-shipped, security within their products, our analysts evaluate the root causes of vulnerabilities and establish secure coding practices, located here:
CERT also provides some useful tools and training material.