Description: The Payment Card Industry Data Security Standard (PCI DSS) applies to whether cardholder data is stored, processed or transmitted. This presentation will examine the best practices in development of bespoke or custom written applications to be used within the cardholder data environment of the Payment Card Industry Data Security Standard (PCI DSS) to ensure the applications meet the compliance requirements of the standard.
The objective of the talk is to inform those who are developing applications of the PCI DSS requirements, review the testing procedures that an auditor would use to examine compliance with the requirements and highlight the evidence the auditor will be expecting to collect to prove the requirements are being met continually. The purpose is to help them develop applications securely to the requirements.
The presentation starts with an explanation of the applicability of the PCI DSS and how organisations may not be aware that they need to comply with the requirements, as they may not be directly involved with payment card transactions. Often, payment card details can be captured on expense tracking systems, corporate card management and other systems. Anywhere the PAN is captured, stored, processed or transmitted, even when not directly involved in a payment transaction, the PCI DSS still applies. For web applications such as shopping carts, although the checkout may redirect to a 3rd party, the application performing the redirect needs to be secure to prevent the redirection mechanism being manipulated to point to a malicious 3rd party site.
Version 3 of the PCI DSS standard mandates a number of key best practices to ensure applications used provide the minimal level of protection of cardholder data during processing, storing and transmission of cardholder data.
The key practices that will be covered are:-
• Secure software development lifecycle practices that ensure the inclusion of security during the requirements definition, design, analysis, and testing phases of software development.
• Requiring developers to understand how cardholder data is handled in memory, and how modern malware will scrape memory to retrieve sensitive data.
• The use of separate development, testing and production environments; including separation of duties for developers, testers and production administrators.
• The need to remove test account credentials and test data from application before it is released to the production environment.
• Prohibition of the use of 'live' data for testing or development purposes.
• The use of change control mechanisms to ensure all changes to system components are reviewed and authorised.
• Software developers are trained in secure coding techniques and develop applications on secure coding guidelines.
• The testing of applications to ensure they do not suffer from known vulnerabilities.
• Public facing web applications are protected against known attacks.
Each of these key practices will be examined from the point of view of a PCI Qualified Security Assessor. The author, who is a QSA, will look at how industry standards, such as those developed by OWASP, can be used by developers, testers and managers as part of the process of implementing a secure development lifecycle and used as evidence in meeting the PCI DSS requirements.
The authors view on the key practices will be given, including interpretation of the requirements and how a QSA could expect to see them implemented to meet the testing requirements of the PCI DSS.
The result should be that developers will understand when the PCI DSS could apply to applications they are developing and the best practices they will need to follow to ensure those application meet the requirements of the PCI DSS. This will enable those merchants and service providers using the applications in their operations to achieve compliance.
For More Information please visit : - https://2014.appsec.eu/
Tags:
Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying.