Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP Effective Software Development in a PCI DSS Environment Bruce Ashton Senior Software Engineer Mako Networks Ltd

OWASP 2 Content  What is PCI DSS and where does it apply  How PCI DSS affects on software development  PCI DSS and company culture

OWASP 3 What is PCI DSS  Payment Card Industry Data Security Standard  A set of twelve requirements and 200-odd security assessment questions  A standard for protecting payment card data  An audit every year by the QSA  Documentation and red tape

OWASP 4 Where does it come from  The PCI Security Standards Council  An open global forum launched in 2006  Also responsible for PA-DSS and PTS  Founded by:

OWASP 5 What PCI DSS was designed to do  Encourage and enhance cardholder data security  Facilitate the broad adoption of consistent data security measures globally  Combat credit card fraud

OWASP 6 When does PCI DSS Apply  PCI DSS only applies if PANs (Primary Account Numbers) are stored, processed and/or transmitted.  PCI DSS applies wherever account data is stored, processed or transmitted.

OWASP 7 Account Data  Cardholder Data  Primary Acount Number (PAN)  Cardholder name  Expiration date  Service code  Sensitive Authentication Data  Full magnetic stripe or equivalent on a chip  CAV2/CVC2/CVV2/CID  PINs/PIN blocks

OWASP 8 Scope of PCI DSS  PCI DSS applies to all entities involved in payment card processing – including:  Merchants, processors, acquirers, issuers, and service providers  Any other entities that store, process or transmit cardholder data.  The PCI DSS security requirements apply to all system components

OWASP 9 System components and environment  System components  All network components, servers, or applications that are included in or connected to the cardholder data environment  Cardholder data environment  The people, processes and technology that store, process or transmit cardholder data or sensitive authentication data

OWASP 10 PA-DSS vs. PCI-DSS  PA-DSS applies to payment applications  PA-DSS does not apply to software provided as a service  PA-DSS does not apply to non-payment applications that are part of a payment application suite  PA-DSS does not apply to payment applications developed by merchants and service providers if used only in-house

OWASP 11 PCI DSS Requirements 1.Build and Maintain a Secure Network 2.Protect Cardholder Data 3.Maintain a Vulnerability Management Program 4.Implement Strong Access Control Measures 5.Regularly Monitor and Test Networks 6.Maintain an Information Security Policy

OWASP Build and Maintain a Secure Network 1.1. Install and maintain a firewall configuration to protect cardholder data  Business justification for use of all services, protocols, and ports allowed  A formal process for all changes  No direct connections to the internet  Stateful packet inspection on all traffic

OWASP Build and Maintain a Secure Network 1.1. Install and maintain a firewall configuration to protect cardholder data  Good solutions:  Set up required access at the start of a project  Physically separate R&D area  Virtual machines and host-only networks  Bad solutions:  hidemyass.com  Flash drives and sneakernet

OWASP Build and Maintain a Secure Network 1.2. Do not use vendor-supplied defaults for system passwords and other security parameters  Configuration for all system components consistent with industry-accepted system hardening standards  Enable only necessary and secure services  Remove all unnecessary functionality

OWASP Build and Maintain a Secure Network 1.2. Do not use vendor-supplied defaults for system passwords and other security parameters  Good Solutions  Consult development on necessary functionality  Push production configuration information out to test and development  Bad Solutions  Developers write their own mail server

OWASP Protect Cardholder Data 2.1. Protect stored cardholder data  Storage of account data is strictly limited  Not just databases – logs, even swap space  Access to production data and logs is restricted  Core/heap dumps can hold account data  Debugging code may not be safe in production

OWASP Protect Cardholder Data 2.1. Protect stored cardholder data  Good Solutions  Write logging code with PCI DSS rules in mind  Use separate debugging code in development  Collect general statistics where you can't obtain specific data  Unique keys that are not account data  Bad solutions  System administrators fix the bugs

OWASP Protect Cardholder Data 2.2 Encrypt transmission of cardholder data across open, public networks  Code gets treated as card data  Distributed development teams  Solutions:  VPNs  Encrypted  The other end of a VPN is in PCI DSS scope

OWASP Maintain a Vulnerability Management Program 3.1. Use and regularly update anti-virus software or programs  Only a problem if your anti-virus software is too aggressive  'Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.'

OWASP Maintain a Vulnerability Management Program 3.2. Develop and maintain secure systems and applications  All software must have the latest patches  Change control procedures for all changes – every new tool or library  Separation of duties between development, test and production  Develop based on best secure coding practices

OWASP Maintain a Vulnerability Management Program 3.2. Develop and maintain secure systems and applications  Good Solutions:  Repository manager for tools and libraries  Get the tools and libraries early in the project  OWASP Top Ten  Bad Solutions:  Developers re-inventing the wheel – it was easier...

OWASP Implement Strong Access Control Measures 4.1. Restrict access to cardholder data by business need to know  Limit access to system components  Principle of least privilege  Deny all by default  Privileges are based on job function  Documented approval for all privileges

OWASP Implement Strong Access Control Measures 4.1 Restrict access to cardholder data by business need to know  Good Solutions:  Clearly and fully define roles  Consult with employees on necessary access  Bad Solutions:  The shared root login  The secret server under my desk

OWASP Implement Strong Access Control Measures 4.2. Assign a unique ID to each person with computer access  Store all passwords using strong cryptography  Do not use group, shared, or generic accounts and passwords  Solutions:  Generate test accounts, don't store them in test data

OWASP Implement Strong Access Control Measures 4.3. Restrict physical access to cardholder data  Use video cameras and/or access control mechanisms to monitor sensitive areas  Restrict access to networking hardware  Maintain strict control over the internal or external distribution of any kind of media

OWASP Implement Strong Access Control Measures 4.3. Restrict physical access to cardholder data  Good Solutions:  Make video feeds available to everybody  Give each developer their own flash drive  Bad Solutions:  Developers ing databases to each other

OWASP Regularly Monitor and Test Networks 5.1. Track and monitor all access to network resources and cardholder data  Establish a process for linking all access to system components to each user  Audit trails for all access to code  Audit trails for access to all audit trails  Review logs for all components daily  Source control is 90% of the solution for code

OWASP Regularly Monitor and Test Networks 5.2. Regularly test security systems and processes  Internal vulnerability scans at least quarterly  External scans by an ASV at least quarterly  Penetration testing at least annually  Intrusion detection/prevention systems  Solutions:  Scan when you add new components  Choose IDS that can limit false positives

OWASP Maintain an Information Security Policy 6.1. Maintain a policy that addresses information security for all personnel  Educate employees on hire and at least annually  Personnel to acknowledge annually that they understand the security policy  Employee knowledge of policy is audited  List of company-approved products

OWASP Maintain an Information Security Policy 6.1. Maintain a policy that addresses information security for all personnel  Solutions:  Keep the policy as simple and plain as possible  Make sure employees know who the key PCI DSS people are  'Ask Bob the Security manager' is often a good answer  Do your own practice audits

OWASP 31 The Cost of working in a PCI DSS Environment  Development will be slower. Account for it in software estimation.  There is more process and documentation. Get the tools to manage it.  Teams get siloed. Encourage communication, guard against conflict.  Production environments get walled off. Make sure you have representative test environments.

OWASP 32 Inter-Team Relationships  Developers and Testers  Make the release process simple and repeatable  Bugs are fully defined  Developers and Operations  Keep developers informed of the production system architecture  Make the release process simple and repeatable  Developers and the business  Manage expectations. Development will be slower and developers will be blamed

OWASP 33 Old Employees and New Rules  Employees will lose access and privileges  Everybody gets extra responsibilities  Give employees new toys tools  Sell the value of having PCI DSS on the CV

OWASP 34 Summary  The benefits:  Security and discipline  The costs:  Red tape and slower development  The solutions:  Plan ahead and keep people communicating

OWASP 35 References  Payment Card Industry Data Security Standard Requirements and Security Assessment Procedures Version 2.0  Payment Application Data Security Standard Requirements and Security Assessment Procedures Version 2.0   Mako Networks Ltd [ ]

OWASP 36 Questions?