#ThinkAppSec – Top Application Security Questions Answered (Week 7)

We’re coming up on January 1, 2014, the day that the new PCI DSS (Payment Card Industry Data Security Standard) and PA DSS (Payment Application Data Security Statand) 3.0 are active. This week’s questions were inspired by PCI.

1. What is the difference between PCI DSS and PA DSS? 

Short answer: Every organization that handles credit cards needs to comply with PCi DSS, only vendors that make and sell payment applications need to meet PA DSS.

The PCI DSS is a standard that ALL organizations that store, process and/or transmit credit card data must be compliant with.

The PCI Data Security Standard is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. The PCI Data Security Standard is comprised of 12 general requirements designed to:

  • Build and maintain a secure network;
  • Protect cardholder data; Ensure the maintenance of vulnerability management programs;
  • Implement strong access control measures; Regularly monitor and test networks; and
  • Ensure the maintenance of information security policies.

No matter how large or small, if your organization handles credit card data, it must be PCI DSS compliant. However, the number of card transactions that your company handles can impact the compliance validation requirements to PCI DSS. Only your acquiring bank or payment brand (ex: MasterCard) can specify the exact compliance requirements because although PCI DSS is an agreed on standard, each of the five PCI card brands (MasterCard, VISA, Discover, AmEx and JCB) maintains its own program for compliance, validation levels and enforcement.

Entities that have limited scope in their cardholder data environment (ex: retailers that use imprint only or process all card data with an online provider and have no electronic storage of cardholder data at their sites or on their networks) may not be required to submit a Report on Compliance (ROC) and can use the self assessment questionnaires (SAQs) for PCI DSS compliance. If you’re not sure what your compliance requirements are, check with your acquirer or card brand. However, before you speak with them, you can find a lot of useful background information at the PCI Security Standards Council (SSC) site. The SSC Quick Reference Guide provides an excellent overview to help companies get started with their PCI journey.

The PA DSS is the standard for makers/developers and integrators of payment applications that use credit card information for payment authorization and settlement. To require PA DSS compliance these applications must be sold, distributed or licensed to third parties. In other words, if you wrote your own payment application that you use in your organization, it has to be PCI DSS compliant but not PA DSS compliant. If you are a payment vendor that sells your payment application to customers, it has to meet PA DSS. Card brands encourage organizations to use only PCI SSC validated applications. The SSC keeps a current list of validated payment applications.

2. If I’m not a payment application vendor, what value does the PA DSS have for me?

Even though you don’t have to comply with PA DSS, don’t overlook the information in it whether or not you’re developing your own payment applications or buying one form a vendor. Here’s why:

  • PA DSS can be used by your internal assessment team to validate a provider’s or partner’s payment application. Although the SSC keeps a list of validated payment apps, you may find that a partner payment app isn’t on the list. Or you may want to perform your own independent audit of the payment app. In these use cases, the PA DSS is a great audit and assessment guide.
  • PA DSS is a deep dive on developing secure payments apps and can/should be used by your internal development and security teams to ensure that the apps your developing are architected and deployed with card data protection in mind.

The PCI DSS covers the entire cardholder data environment eco-system which addresses security of payment apps but doesn’t go into the detail that PA DSS does. Using the PA DSS as a guide, even for internal apps, gives your dev team additional guidance.

One example is Requirement 5.1.5 of the PA DSS: Secure source-controls practices are implemented to verify integrity of source code during the development process.  Source code control is an important part of a secure SDLC and is called out in standards like NIST 800-64 (A concept of operations document for secure development should be established for the environment and a contingency plan should be in place for the code repository as source code is the predominant work product of software and system development and should be preserved in the event of interruption to the development environment.) and ISO 27002 (12.4.3: Control access to program source code) but it is not mentioned in the PCI DSS.

Another example is Requirement Coding techniques include documentation of how PAN and/or SAD are handled in memory. Again, an important aspect of payment application security, but not explicitly called out in the Requirement 6 (the one that addresses applications) in the PCI DSS.

There are many more examples in the PA DSS – but I hope that these have helped to convince you that even if you’re not developing a payment application for resale, if your developing one at all, the PA DSS is a valuable document for your coding, security and test teams to review and use in secure payment application development.

Previous Weeks

Week 1- What is the importance of software security in supply chain management?

Week 2 – Who Should be Responsible for Application Security Testing?

Week 2 – Can “generated code” be tested?

Week 3 – How do we secure application vulnerabilities and code development, particularly for mobile and social applications that are built by business units or reside on the cloud?

Week 3 – As a CISO, how can I control my organization’s testing methodologies, change management and deployment processes, without compromising on quality and project timelines?

Week 4 – Will the legal landscape change if software vendors can be sued without damages or loss being proven?

Week 4 – What is PII – How much can the definition expand?

Week 5 – Which apps are more secure: Android or iOS?

Week 5 – Are mobile application reputation services valuable to enterprises?

Week 6 – Does IoT (Internet of Things) “change everything” for Application Security?

Week 6 – What can I do now to get ready for IoT?

More from Application Security

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

Backdoor Deployment and Ransomware: Top Threats Identified in X-Force Threat Intelligence Index 2023

Deployment of backdoors was the number one action on objective taken by threat actors last year, according to the 2023 IBM Security X-Force Threat Intelligence Index — a comprehensive analysis of our research data collected throughout the year. Backdoor access is now among the hottest commodities on the dark web and can sell for thousands of dollars, compared to credit card data — which can go for as low as $10. On the dark web — a veritable eBay for…

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

Detecting the Undetected: The Risk to Your Info

IBM’s Advanced Threat Detection and Response Team (ATDR) has seen an increase in the malware family known as information stealers in the wild over the past year. Info stealers are malware with the capability of scanning for and exfiltrating data and credentials from your device. When executed, they begin scanning for and copying various directories that usually contain some sort of sensitive information or credentials including web and login data from Chrome, Firefox, and Microsoft Edge. In other instances, they…