#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

Gozi strikes again, targeting banks, cryptocurrency and more

3 min read - In the world of cybercrime, malware plays a prominent role. One such malware, Gozi, emerged in 2006 as Gozi CRM, also known as CRM or Papras. Initially offered as a crime-as-a-service (CaaS) platform called 76Service, Gozi quickly gained notoriety for its advanced capabilities. Over time, Gozi underwent a significant transformation and became associated with other malware strains, such as Ursnif (Snifula) and Vawtrak/Neverquest. Now, in a recent campaign, Gozi has set its sights on banks, financial services and cryptocurrency platforms,…

Vulnerability management, its impact and threat modeling methodologies

7 min read - Vulnerability management is a security practice designed to avoid events that could potentially harm an organization. It is a regular ongoing process that identifies, assesses, and manages vulnerabilities across all the components of an IT ecosystem. Cybersecurity is one of the major priorities many organizations struggle to stay on top of. There is a huge increase in the number of cyberattacks carried out by cybercriminals to steal valuable information from businesses. Hence to encounter these attacks, organizations are now focusing…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Unmasking hypnotized AI: The hidden risks of large language models

11 min read - The emergence of Large Language Models (LLMs) is redefining how cybersecurity teams and cybercriminals operate. As security teams leverage the capabilities of generative AI to bring more simplicity and speed into their operations, it's important we recognize that cybercriminals are seeking the same benefits. LLMs are a new type of attack surface poised to make certain types of attacks easier, more cost-effective, and even more persistent. In a bid to explore security risks posed by these innovations, we attempted to…