Transcript Where worlds collide… PCI-DSS for OWASP Practitioners OWASP Day NZ July 2009

Where worlds collide…
PCI-DSS for OWASP Practitioners
OWASP Day NZ July 2009
Introduction
Dean Carter aka fosm
• Principal QSA and Senior Consultant
• Leader of the Security Advisory Services team
QSA, CISSP, CISM, GREM, CCNA, CCA, MCDBA,
MCSE, MCP+I, Dip. QA, Cert QA and BSC (Bronze
Swimming Certificate) etc etc etc
A multitude of exams does DO NOT prepare you for real life!
Real life background in Financial Services,
Telecommunications and Media, Government and other
Prior to IT spent 8 years in Quality Assurance
Why am I here?
 PCI applies if you store, process or transmit cardholder data
 OWASP is directly referenced in 6.5 of PCI-DSS
 56% of organisations fail PCI section 6
 “develop and maintain secure systems and applications”
 Every vendor wants to sell you a shiny solution to “fix PCI”
 I’m not here to sell you anything or baffle you with made-up statistics
 I will show you how OWASP can assist your PCI compliance efforts
Overview
High Level Overview of the PCI-DSS
Applying OWASP to PCI-DSS issues
Card breaches and exposures
Closing comments and questions
Pointing out the obvious…
Compliant does not equal secure!
High Level Overview of the PCI-DSS
Applying OWASP to PCI-DSS issues
Card breaches and exposures
Closing comments and questions
PCI – Welcome to Acronym City!
Here are just a few key acronyms for today:
 PCI-DSS = PCI Data Security Standard
 QSA = Qualified Security Assessor
 CHD = Card Holder Data
 PAN = Primary Account Number
 SAD = Sensitive Authentication Data
Card Holder Data (CHD)
Why do we need the PCI-DSS?
“Data breaches were a leading cause of financial fraud against
consumers in 2008 and were the source for much payment card
fraud, which was the most-common fraud type.”
Source: Gartner - 2008 Data Breaches and Financial Crimes Scare Consumers Away G00165825- Feb 2009
Evolution of attacks
PCI–DSS – Who does it affect?
 Anyone who transmits, processes or stores payment card data
 Yes, this include Debit Cards with Card Brand logos!
 For example…
 Merchants
 Trademe.co.nz
 1-day.co.nz
 Your local supermarket
 Paystations in parking buildings
 Service Providers
 Paymark aka ETSL (payment gateway)
 DPS (payment gateway)
 Datacom (IT services provider)
 Rivera (web hosting)
Source: PCI-SSC website – Asia-Pac Participating
Organisations
PCI intent - in one sentence…
Protect card holder data from
inappropriate disclosure
Show me the PCI-DSS…
The 12 Requirements of the PCI-DSS v1.2
1
Install and maintain a firewall configuration to protect cardholder data
2
Do not use vendor-supplied defaults for system passwords and other security
parameters
3
Protect stored cardholder data
4
Encrypt transmission of cardholder data across open, public networks
5
Use and regularly update anti-virus software or programs
6
Develop and maintain secure systems and applications
7
Restrict access to cardholder data by business, need-to-know
8
Assign a unique ID to each person with computer access
9
Restrict physical access to cardholder data
OWASP context…
The 12 Requirements of the PCI-DSS v1.2
1
Install and maintain a firewall configuration to protect cardholder data
2
Do not use vendor-supplied defaults for system passwords and other security
parameters
3
Protect stored cardholder data
4
Encrypt transmission of cardholder data across open, public networks
5
Use and regularly update anti-virus software or programs
6
Develop and maintain secure systems and applications
7
Restrict access to cardholder data by business, need-to-know
8
Assign a unique ID to each person with computer access
9
Restrict physical access to cardholder data
Is there a PCI silver bullet?
 No, there isn’t
 There is no Santa or Tooth Fairy either…. Sorry!
 No single product solution can solve your compliance issues
 BUT! As we will shortly see, use of OWASP initiatives is a key
ingredient to success
 You still need to read and comprehend the OWASP Development Guide
 You still need to read and comprehend the PCI-DSS v1.2
 I’m just here to convince you the value of reading both and applying the
knowledge you will gain!
High Level Overview of the PCI-DSS
Applying OWASP to PCI-DSS issues
Card breaches and exposures
Closing comments and questions
OWASP PCI Project
OWASP PCI Project Goal
“To build and maintain community consensus for managing
regulatory risk of web applications. For those with existing website
security programs, to ensure their activities uniformly meet PCI
requirements, and for those getting started - to aid in building a
website security strategy that also ensures sustainable PCI
compliance”
 Link: http://www.owasp.org/index.php/Category:OWASP_PCI_Project
Where PCI assessments fail…
PCI Requirement
% of
failures
3
Protect stored data
79%
11
Regularly test security systems and processes
74%
8
Assign a unique ID to each person with computer access
71%
10
Track and monitor all access to network resources and cardholder data
71%
1
Install and maintain a firewall configuration to protect cardholder data
66%
2
Do not use vendor-supplied defaults for system passwords and other security
parameters
62%
12
Maintain a policy that addresses information security for
employees and contractors
60%
9
Restrict physical access to cardholder data
59%
6
Develop and maintain secure systems and applications
Source: VeriSign, based on 112 assessments
56%
Applying OWASP…
% of
failures
PCI Requirement
3
Protect stored data
79%
11
Regularly test security systems and processes
74%
8
Assign a unique ID to each person with computer access
71%
10
Track and monitor all access to network resources and cardholder data
71%
1
Install and maintain a firewall configuration to protect cardholder data
66%
2
Do not use vendor-supplied defaults for system passwords and other security parameters
62%
12
Maintain a policy that addresses information security for
employees and contractors
60%
9
Restrict physical access to cardholder data
59%
6
Develop and maintain secure systems and applications
56%
4
Encrypt transmission of cardholder data across open, public networks
45%
Source: VeriSign, based on 112 assessments
Requirement 3
Protect stored cardholder data
 Rule 1– You must not store Sensitive Authentication Data (SAD)
 Principle 1 – if you don’t need it, DON’T store it!
 Principle 2 – if you must store PAN then first consider:
 Outsourcing
 Truncation
 Tokenisation
 The next option is encryption….
Tokenisation
 The PAN is replaced with a 16-character unique identifier called a
“Token.”
 Tokens are used to indirectly reference cardholder data that is stored
in a separate database, application, or offsite secure facility
 4000 0012 3456 7899 -> 2eh193a0362b351d
 Reduces scope but does not remove the need to be PCI compliant
Truncating
 If you don’t need, don’t store it!
 Truncation:
 eg: 4000 00XX XXXX 7899
 NB: When you truncate to “first 6, last 4” of the PAN, then you no
longer are storing CHD
Encryption – Golden Rules
 Encrypt data at the point of capture
 Only decrypt when required
 Use industry standard algorithms
 Protect your keys
Requirement 6
Develop and maintain secure systems and applications
Requirement 6.3
“Develop software applications in accordance with PCI DSS (for
example, secure authentication and logging) and based on industry
best practices, and incorporate information security throughout the
software development life cycle”
 Build security into your applications:
 Input validation
 Error handling
 Secure cryptographic storage
 Secure communications
 Role-based access control
Requirement 6.3.7
“Review of custom code prior to release to production or
customers in order to identify any potential coding vulnerability
Code reviews ensure code is developed according to secure
coding guidelines such as the Open Web Security Project Guide
(see PCI DSS Requirement 6.5).”
 Test that the application was built securely
 OWASP Testing Guide
Requirement 6.5
“Develop all web applications (internal and external, and including
web administrative access to application) based on secure coding
guidelines such as the Open Web Application Security Project
Guide. Cover prevention of common coding vulnerabilities in
software development processes, to include the following:”
 Check for the 10 most common vulnerabilities
 Yes! The OWASP Top 10…
6.5 – OWASP Top 10
PCI Requirement / OWASP Top 10
6.5.1
Cross-site scripting (XSS)
6.5.2
Injection flaws, particularly SQL injection. Also consider LDAP and
Xpath injection flaws as well as other injection flaws.
6.5.3
Malicious file execution
6.5.4
Insecure direct object references
6.5.5
Cross-site request forgery(CSRF)
6.5.6
Information leakage and improper error handling
6.5.7
Broken authentication and session management
6.5.8
Insecure cryptographic storage
Bonus Rant: 12.1.2
12.1 Establish, publish, maintain, and disseminate a security
policy that accomplishes the following:
12.1.2 Includes an annual process that identifies threats, and
vulnerabilities, and results in a formal risk assessment.
 Annual threat risk assessment
 The most under-rated , most overlooked aspect of the PCI-DSS
 Refer to OWASP section on Threat Risk Modeling
 Keep in mind that new threats will emerge targeting old code
High Level Overview of the PCI-DSS
Applying OWASP to PCI-DSS issues
Card breaches and exposures
Closing comments and questions
CHD – it gets everywhere!!!!
Just a few places I
have found CHD
recently!
Recent CHD exposures
Commentary on exposures
 So, what is my point? CHD is exposed by:
 Theft of documents
 Poor document disposal
 Skimming / fake PoS terminals
 WiFi attacks
 “Rogue” employees and careless “trusted” third parties
 Theft of computers laptops, desktops and servers
 Configuration errors
 Web site compromises
 Unencrypted data being stored
 Application of OWASP concepts reduces the attack surface!
High Level Overview of the PCI-DSS
Applying OWASP to PCI-DSS issues
Card breaches and exposures
Closing comments and questions
Fixing legacy systems
 If you find yourself fixing an existing PCI system….
 Ask yourself….Is it really fixed?
 Confirm, confirm, confirm!
 In my experience the storage of CHD may have been fixed at a point
in time….
 What about the historical data?
 Was it cleaned it up?
 Backups?
 Paper records?
 Have hard disks been scrubbed?
Real Life Example
 An example of how things can turn to cactus…
 So… you think you are compliant….
 You have invested a LOT of time and effort
 You read the PCI-DSS
 You convinced your developers to read the PCI-DSS and OWASP
 You hired a QSA
 What could possibly go wrong?
 Your QSA finds PANs on your system on the last day of assessment
 WTF?
 Yeah...sods law… a gateway failed so you failed back to an old piece
of code…
Parting Thoughts
 The challenge is to achieve, maintain AND validate compliance
 Secure application development is a key activity
 OWASP is great, free resource to assist you
 Reduce scope by reducing card holder data storage
 Complying to a standard is a minimum goal not an end goal
Useful Links









www.pcisecuritystandards.org
www.owasp.org
www.owasp.org/index.php/Category:OWASP_PCI_Project
www.aegenis.com
www.pcianswers.com
www.storefrontbacktalk.com
www.privacyrights.org/ar/ChronDataBreaches.htm
http://risky.biz
www.security-assessment.com
Thank you
Questions?
Email: [email protected]