#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 5.1.6.1 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

Containers, Security, and Risks within Containerized Environments

Applications have historically been deployed and created in a manner reminiscent of classic shopping malls. First, a developer builds the mall, then creates the various stores inside. The stores conform to the dimensions of the mall and operate within its floor plan. In older approaches to application development, a developer would have a targeted system or set of systems for which they intend to create an application. This targeted system would be the mall. Then, when building the application, they would…

Securing Your SAP Environments: Going Beyond Access Control

Many large businesses run SAP to manage their business operations and their customer relations. Security has become an increasingly critical priority due to the ongoing digitalization of society and the new opportunities that attackers exploit to achieve a system breach. Recent attacks related to corrupt data, stealing personal information and escalating privileges for remote code execution all highlight the new and varied entry points threat actors have taken advantage of. Attackers with the appropriate skills could be able to exploit…

Does Follina Mean It’s Time to Abandon Microsoft Office?

As a freelance writer, I spend most of my day working in Microsoft Word. Then, I send drafts to clients and companies across the globe. So, news of the newly discovered Microsoft Office vulnerability made me concerned about the possibility of accidentally spreading malware to my clients. I take extra precautions to ensure that I’m not introducing risk to my clients. Still, using Microsoft Office was something I did many times a day without a second thought. I brought up…

3 Reasons Why Technology Integration Matters

As John Donne once wrote, “No man is an island entire of itself.” With digitalization bridging any distance, the same logic could be applied to tech. Threat actors have vast underground forums for sharing their intelligence, while security professionals remain tight-lipped in a lot of data breach cases. Much like the way a vaccine can help stop the spread of infectious diseases, sharing threat intelligence and defense strategies can help to establish a more secure future for everyone.  So what…