16
July
2014

The Importance of PADSS in mPOS

PADSS: An Overview

Data Security

PADSS or the Payment Application Data Security Standard is a universally acknowledged global security standard that has been introduced by the Payment Card Industry Security Standards Council (PCI SSC). The main objective behind introduction of the security standard is successfully delivering the authoritative data standard for software vendors in developing secure payment applications. Conventionally, the most frequently used methods for preventing third party payment applications from storing valuable data are, magnetic stripe, CVV2, or PIN. PADSS, in this context, fulfill the guiding role in terms of instructing software vendors to develop payment applications that must adhere with the policies laid down by the Payment Card Industry Data Security Standards (PCI DSS).

Subjects that Demand In-depth Explanation:

While evaluating the importance of PADSS in mPOS, there are several associative aspects that need to be understood. While the relationship between PADSS and PCI DSS is one point that needs specific explanation, on the other hand, the scope of PADSS should also be explained properly. The next important aspect that should comply with the aforesaid aspects, is the guide to PADSS implementation. 

The Scope of Compliance for Payment Processors with Legal and Regulatory Standards:

The scope of compliance for payment processors needs to extend beyond the specification related to government regulations, industry standards and operation related rules and regulations. The organizations also need to understand the policies and legal structures, followed by their clientele and partnering organizations. The best way to implement and reflect such holistic compliance can be attained only through close follow up of partners’ policies. In this way, it becomes easier for management of the payment processors to implement the same policies within their procedural structure as well.

In-Depth Security Analysis and Defense Planning:

Planning defense against unwanted breaches through in-depth security analysis is a must thing to do for payment processors. The analytical framework should take into consideration all possible vulnerabilities within their systems, databases, and networks. However, this analysis should be done with adequate consideration of the changing technological trends. Accordingly, the defense planning should also involve the latest strategic measures, aiming to ward off any form of threats, both external and internal. The main purpose of the in-depth security analysis is to make sure that in case any one of the control systems is compromised, it would not cause unwanted breach to the entire system. So, the security analysis should be planned in a manner that there are multiple security layers that successfully ensure the maximum protection to valuable data, system access and confidential information. The security framework should also contain the place for flexibility in terms of learning the arenas, from where newer threats against security may emerge. This facility will allow the management of payment processors in modifying and improving the security control infrastructure against all sorts of immediate threats and possible security vulnerabilities. Payment processors should also focus on improving the security standards of applications and their user interfaces. Sometimes such not-so-attended vulnerabilities are exploited by security abusers in a manner that they, in turn, become gateways to major security breaches. Monitoring these vulnerabilities on a regular interval with the latest tools help security managers to avert security breach, largely. The complicated task can be made easy with the help from resources provided by Open Web Application Security Project and several types of security sources. The security management personnel, appointed by the concerned payment process firms should use these sources for checking web applications before they are finally released. Some of the most common types of security breach efforts are injecting SQL, session hijacking, scripting cross-sites and buffer over-flow. Testing the web applications at every stage of production helps with elbowing out such efforts to breach the web security largely. Alongside, security management should also run the impact analysis only to identify the possible risks and exploits within the system. Furthermore, this step makes it easier for the security management department to initiate the plans of mitigating such risks or coming up with preventive actions against them. The system and network administrators should also be careful about testing every update or newer installations, prior to execution. Having discussed substantially about the associative aspects that provide the fusion of PADSS with mPOS with an extremely sensitive angle in the field of mobile payment security, now it is important to take an in-depth look at other aspects that are more directly relevant to the subject. In this section of the paper, attention will be provided on three important segments, namely:

  • The connection between PADSS and PCI DSS
  • The scope of PADSS, and
  • The guiding principles for PADSS implementation

The Connection between PADSS and PCI DSS:

The connection between PADSS and PCI DSS has been a confusion generating subject for quite some time now. However, the PADSS Requirement no. 13.1 clearly states that using an application reliant to PADSS does not necessarily make it PCI DSS compliant naturally. In order to achieve the PCI DSS compliant status, that application needs to be implemented within a PCI DSS compliant environment. The main point of confusion whether PADSS is an integral part of PCI DSS originates from the requirements that are resulted from the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Security Assessment Procedures. As per the document, any payment application that customers’ may use for payment processing should contain the necessary measures that will reflect their compliance with PCI DSS. Quite naturally, the requirements of PADSS are derived from PCI DSS requirements. Typically, PCI DSS necessarily cannot be applied to all payment application vendors as majority of them refrain from storing, processing or transmitting valuable data of cardholders. However, as customers use these apps, on many occasions, for storing or processing data as cardholders, in order to ensure security to cardholders, the applications need to PCI DSS compliant as well. In this way, the applications would reflect customers’ compliance with PCI Data Security Standard. However, only a very limited number of conditions are there that may empower payment applications from not complying with PCI DSS policies. Here follows the conditions:

  • Once authorized, the payment processing applications are free to store magnetic stripe data and/or any other data that is equivalent
  • If customers turn off PCI DSS requirements to make an application work as per the promise
  • If vendors choose to opt for unsecure methods for connecting with a payment processing application in order to provide customer support

The confusion surrounding the relationship between PCI DSS and PADSS receives more clarity from this discussion. It becomes clear that PADSS, despite being a separate entity, is dependent on PCI DSS when it comes to deriving the requirements of its implementation. This is the most important thread that connects PCI DSS and PADSS. While evaluating the importance of PADSS in mPOS, quite naturally, the connection between these two modules needs to be considered carefully and critically.

The Span of PADSS Application:

The scope, span or extent of applicability of PADSS reaches all software vendors and payment processing applications that have been authorized by customers to store, process and transmit card data. However, the scope should be adhered by vendors and payment applications when they are either sold, distributed or licensed to a third party. In order to understand the extent of PADSS implementation, the following points should be considered accurately:

  • PADSS adherence is a must for all those applications that are sold and installed directly without much modification from software vendors .
  • PADSS should be implemented to all those applications that are module based (having a basic scope for comparison, have included special modules as per customer requirement or made the necessary changes to add to customer convenience). PADSS may not be applicable to an entire application, except for the baseline module, if the module performs the functions related to payment processing. In this context it is important to remember that isolating all baseline modules involved in payment processing is considered a “best practice” that software vendors should carefully consider.
  • PADSS will not be applicable in case of SaaS-based payment applications, primarily for three reasons, namely –

    • Customers do not have the authority to manage neither the application nor the environment
    • The application comes under the scope of PCI DSS review, and the scope has been affirmed by customers
    • That the application has not been sold, distributed or licensed to any third party
  • PADSS cannot take non-payment applications, even though they comprise some parts of a payment application suite, within the purview of its regulatory execution. However, it is important to run one-time PADSS assessment for those payment applications that are parts of a suite, adhering with the PADSS requirements.
  • PADSS cannot take into account any payment application that has been developed to facilitate one specific customer.
  • PADSS cannot extend its scope to those applications that have been produced by merchants/service providers and for in-house use (payment processing) only.

In order to understand the limits of PADSS scope, it is important to find a few realistic examples. The list that follows may not be comprehensive to the truest sense but surely deliver an idea of the conditions where payment applications won’t be needing PADSS reviewing:

  • If the payment application is installed on operating platforms like Unix or Windows
  • If the payment applications uses a database system like Oracle for storing customers’ card data
  • Storing cardholders’ data for back-office (reporting or customer assistance) purpose doesn’t make the process accountable for PADSS reviewing

The incidents of data breach or hacking cardholders’ data may be quite frequent from payment processing applications but hardware terminals like Mobile Point of Sales (mPOS) may also function as an access point to cardholders’ data in vendors’ databank. Due to these reasons, it is important for the mPOS terminals to comply with PADSS requirements.

The Guide to PADSS Implementation on Hardware Terminals:

Guide to PA DSS Implementation

  • The resident payment application should meet all PADSS requirements and it should also be authenticated as per PADSS regulations
  • In case the resident application does not satisfy all requirements of PADSS, but the application uses PCI SSC guaranteed PIN transaction security (PTS), the best practice for the application would be combining PADSS and PTS controls and in this way it would satisfy the PADSS requirements.

Furthermore, while undergoing PADSS assessment process, the payment application should be validated as per the PAQST regulations. As the key role is played by PAQST, the module should fulfill several duties when it comes to successfully finalizing the validation, namely:

  • Clear documentation of the requirements that the application has fulfilled as per the PADSS regulation
  • Clear documentation of the requirements that have been met through PCI PTS
  • Providing a clear explanation of why a payment application has failed to meet PADSS requirements
  • Clear documentation of the steps that were run to determine whether or not the PADSS requirements have fully been satisfied through PCI PTS validation
  • Clearly listing PCI PTS validated hardware terminal as an essential dependency in the report on validation, especially in the executive summary section

While the hardware terminal should undergo a strict validation process, on the other hand, there is no relaxation for the resident application from undergoing a rigorous process, which combines both PA-DSS and PCI PTS controls:

  • Requires to be provided together to the customer (combining hardware terminal and application)
  • In case application and the hardware are provided separately, the packaging should be done ina a manner that the very hardware terminal should be the only platform to run the application
  • The application, by default, should support PCI DSS compliance of a customer
  • The application should include regular updating option in order to satisfy PCI DSS compliance
  • In case the application is sold, distributed or licensed separately then the vendor must ensure that they receive the necessary details of the dependant hardware, used for running the application as per PADSS validation listing

Conclusion:

Taking a deep delve in understanding the importance of PADSS in mPOS there are several factors that have drawn our attention. While the overview definitely suggests adding more security and governance to valuable data, on the other hand, from a more specific and objective way it shows how critical the data protection process has become. The paper also shows that PADSS and PCI DSS are two key instruments that have carefully and intricately laid down the entire process of data governance, whether in an application or through a stand-alone Mobile Point of Sales hardware. The paper provides a great deal of attention to the connection between PADSS and PCI DSS. While PCI DSS is the supreme determinant of security standardization, on the other hand, PADSS, despite deriving the regulations from the former one, plays a more specific role in determining that software vendors and applications that store, processes or transits cardholders’ data, should adhere with the carefully laid regulations in order to provide the best security to customers.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>