pci dss and pa dss l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
PCI DSS and PA-DSS PowerPoint Presentation
Download Presentation
PCI DSS and PA-DSS

Loading in 2 Seconds...

play fullscreen
1 / 39

PCI DSS and PA-DSS - PowerPoint PPT Presentation


  • 148 Views
  • Uploaded on

OWASP Education Computer based training. PCI DSS and PA-DSS. Nishi Kumar IT Architect Specialist, FIS Chair, Software Security Forum at FIS OWASP CBT Project Lead OWASP Global Industry Committee

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'PCI DSS and PA-DSS' - eman


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
pci dss and pa dss

OWASP Education

Computer based training

PCI DSS and PA-DSS

Nishi Kumar

IT Architect Specialist, FIS

Chair, Software Security Forum at FIS

OWASP CBT Project Lead

OWASP Global Industry Committee

Nishi.Kumar@owasp.orgContributor and Reviewer Keith Turpin Reviewer Kuai Hinojosa Christian Heinrich

objectives
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
pci payment card industry
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

dss in a nutshell
DSS in a nutshell
  • The PCI (Payment Card Industry) DSS (Data Security Standard) is:
    • A set of minimumbaseline controls for securing payments
    • Required (everyone in the payment lifecycle must comply)
    • A unified standard agreed to by all card brands
everyone must comply resistance is futile
Everyone must comply (resistance is futile)

Everyone must be compliant with the standard

lifecycle process for changes
Lifecycle Process for Changes
  • PCI change management process
pci payment card industry8
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

pa dss
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
pci dss
PCI DSS

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

pci payment card industry12
PCI – Payment Card Industry
  • Most of the time, it’s one or more of the “deadly half-dozen”:
  • If you can get past these, you’re in pretty good shape
enemy 1 inappropriate scope
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)
scoping example
Scoping Example
  • Red area denotes scope of PCI assessment
the solution zones enforcement of scope
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
enemy 2 inadequate documentation
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
the solution they have to document as well
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
enemy 3 apps
Enemy #3: Apps
  • Apps are hard, no matter how you slice it
  • The requirements for apps are pretty tough
    • OWASP Guide (OWASP “Top Ten”), CWE/SANS 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
solution apps
Solution : Apps
  • Read OWASP
  • The application requirements are verbatim from the OWASP Guide (OWASP Top 10), CWE/SANS 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
enemy 4 data storage
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
solution data storage
Solution : Data Storage
  • Limit what you keep
  • If there’s any way you can get away with it, try not to store the PAN
  • If we store the pan select a well-vetted algorithm that is currently considered to be strong (e.g., FIPS 140-2 (i.e. Triple-DES, AES, RSA) or an equivalent standard)
  • Consider a “data deletion” policy to govern storage of cardholder data
enemy 5 inadequate compensating controls
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
solution inadequate compensating controls
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
enemy 6 bad timing
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 thereNotes: QSA’s are required based on the tiers. You can get this information from http://whatlevelami.com/
solution bad timing pre assess and preplan
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”
owasp top 10 2010 cwe sans top 25 mapping33
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
cert secure coding standards
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
summary
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
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.

references38
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/