pci dss and pa-dss owasp education nishi kumar computer based training
DESCRIPTION
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 25TRANSCRIPT
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
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