Challenges and Solutions to enable compliance pci

Challenges and solutions to better enable compliance with PCI SSF:

The PA DSS was introduced to provide a guideline for the development of payment applications. Although software security and resilience could mean a lot more than the 14 requirements of the PA DSS, the PA DSS has been the go-to when it comes to certification and validation for software security.

Now the PA DSS substituted by the PCI SSF. What is PCI SSF? How will this transition affect your organization?

PCI SSF – In brief

PCI SSF stands for Payment Card Industry Software Security Framework. It provides the standard guidelines to be followed by software companies while designing and developing payment software.

It comprised of two independent standards

The PCI SSS -  Secure Software Standard: This defines a set of requirements to ensure integrity and confidentiality of payment transactions, data, and the payment software.

The PCI SLC -  Secure Software Lifecycle Standard: This defines the basis and guidelines to design and develop the payment software, additionally it also lays down the best practices to maintain the payment software securely throughout the software lifecycle.

Although the PCI SSF is an independent set of payment security standards, it can be said that the PCI SSF takes many of its elements of control from the PA DSS standard.

So, what’s new?

PA DSS vs PCI SSF - The transition in detail, challenges, and solutions

Multiple reasons like constant change in technology, advancements in software development techniques, emerging trends in cyber-attacks have led to this transition from PA DSS to PCI SSF. The new standards of PCI SSF have comprehensive elements which would be suitable for both traditional and modern software methodologies. It has been designed in a way where every organization validating to this standard will have control over every aspect.

Let us take a look at the various aspects of differences, similarities, challenges, and solutions… Is this a change or a chance, read through to find out:

Changes and Challenges:

• Change in Objective- Shifting to a comprehensive approach

The PA DSS was designed exclusively for the PCI DSS environment. It emphasizes majorly on cardholder information and sensitive authentication data. The PCI SSS standard mainly focuses on the integrity and confidentiality of the transaction data. The Secure Software Standard framework lays out core requirements and v1.1 has included applicability to terminal applications.

The PA DSS has certain software lifecycle and security requirements, security features of the software application within itself. The Secure Lifecycle standard focuses on how software development companies shall design their payment software.

The PCI SSF framework has prescribed clearly defined and comprehensive objective controls like Identifying dependencies between hardware and software compatibilities, providing provisions to secure the defaults, mandating a functionality within the software to retain the data securely as per payment industry methods. It evaluates how data is securely deleted. It demonstrates that the software must have a separate feature on how it is authenticating the users, how it provides role-based access control, whether it is tracking malicious activities and reporting the lags to the concerned team for analysis and prevention of lapses.

If PA DSS talks about password policy, several characters, expiry… PCI SSF ensures that these standards are not just given provision for but are implemented in the software and the customer is given awareness about the software, what kind of software it is, the user manual is provided for, the environment for usage, and the features supported, how compliant it is and how it is to be configured. Thus, making it a comprehensive approach.

• Change in Applicability- Increased Applicability

The intent or applicability of the PA DSS and PCI SSF are quite similar, and we can say that it is a point of similarity between these two standards. The PA DSS standard is strictly applicable only to an application developer or payment application integration service that stores, processes, or transmits cardholder data as part of authorization or settlement.

The PCI SSF is applicable to any software developing company that develops payment software that is sold, distributed, or licensed to third parties. It is to be noted that this includes payment software that might be installed on a customer’s system and payment software deployed to customers “as a service” over the internet. However, it is not applicable if a company is developing software in-house for its usage or the usage of any one single customer.

The PCI SSF supports existing ways in PA DSS to demonstrate good application security and also increases the applicability of a variety of new payment software and development processes.

• Change in the structure of the framework’s standard itself- Ensuring software security right from development:

There are currently no standards that provide a guarantee to the secure development process followed by the software companies developing software for payment industries. Although there are few requirements emphasized in the PA DSS standard on the best practices for software development, but the PCI SSF has implemented new standards in the SLC.

The PCI SLC incorporates threat identification, threat mitigation, and analysis of the risks involved, vulnerability detection and mitigation, avoiding security lapses as a part of its objective controls. SLC emphasizes on various aspects such as change management, data protection and how it is incorporated in the software, how to implement software in a specific environment, modes of third-party communication, how to reach out in case of updates to stakeholders.

Any organization implementing the SLC will give assurance to customers and stake holders of following best practices.

• Change in criteria- Objective oriented, increased and improved security:

The new standard has opened the criteria for eligibility to be certified to increased payment software types. It supports broader array of payment software types and all software methodologies.

There are new requirements added for Terminal software. The PCI SSS objective talk about separate and exclusive controls for Terminal software. The functions performed by the terminal application needs to be documented. The design of the security features must be defined. All types of attacks that can happen need to be mitigated with in-built mechanism within the terminal application. Security testing needs to be performed so that the lapses are identified, and vulnerabilities are not taken advantage by the hackers. An implementation guide needs to be given on how it integrates with backend.

To achieve its objective of integrity and confidentiality on whole transaction data, the PCI SSS has removed dependency on technology. Now any company can get their technology validated to this standard.

Listing  Eligibility - A unique opportunity:

The intent of both the standards is same which is, to set a standard for any software company which develops software for the payment industry. Here the PCI SSF brings with it, a unique and one-of-a-kind eligibility. Once an organisation gets the validation and certification of PCI SLC, they can list their company in the PCI SSF’s list of “SLC qualified vendors”.

Procedural changes- The transition timeline:

1. The PCI SSF was first published in Jan 2019.
2. The last acceptance for new PA DSS submissions was closed on 30th June 2021.
3. Companies which have not submitted ROV and AOV for their PA DSS certification yet, will have to opt for PCI SSF.
4. If you are already PA DSS certified, minor changes can be submitted till 28th October 2022.
5. When a product is already PA DSS certified i.e. It has been deployed to vendors the PA DSS will be acceptable for the pre-existing deployed versions of the already PA DSS certified applications.
6. The PA DSS program closes on 28th Oct 2022.
7. Any new application, software or updated new versions of the previously deployed applications, need to be compliant with PCI SSF.

• Change in the assessment process- Internal training and security education:

The PA DSS validation process consists of : selecting a PA QSA, reviewing the payment application, determining if it is PA DSS compliant, submission of the ROV and AOV to council, issuance of the acceptance letter to vendor and listing on the website.

The assessment process of PCI SSF is streamlined. Certain case studies suggest that the new standard assessment can identify lapses such as implementation of attack detection methods, anomalous behaviour, usage of random number generator, execution level vulnerabilities like cache timing, branch prediction, etc.

During such assessment and gap analysis, the importance of security education within software development community increases. Providing training and evaluating the effectiveness of training provided, matures the processes and makes the organisational output more effective.

Chances and Solutions:

• Conducting a deep interpretation of the PCI SSF framework:

It is of utmost importance to have a deep understanding of the new changes and to be prepared. The elements in the framework of the new standard might have an effect on the business factors, hence it is always better to take prior steps to facilitate necessary business operations. Having a copy of the PCI Council guide handy can go a long way in this transition. 

• Investigating the needs and analysing the standards

An analysis is the first step to achieving any goal. Be it a business goal or the PCI SSF standard. These standards demonstrate the best practices to be followed. Performing a comparative analysis on where the organization is currently with the standards prescribed by PCI SSF will bring you closer to achieving compliance. Once this analysis has been done, you can work on the requirements.

• Know it in-and-out :

The PCI Security Standard Framework consists of Secure Software Standard (SSS) and Secure Software Lifecycle Program (SLC). The standards prescribed the basis of validation and listing eligibilities vary completely. Although they are part of the same framework, they are designed to achieve different aspects of the objective which is Software Security.

It is significant to know these differences as the security of the payment software being designed and developed can be easily achieved.

• Staying abreast of the updates from PCI Council

Keeping a tab on updates must be kept as a constant activity during any transitions. A transition is the time announcements are made and staying prepared with updating policies and requirements can prevent last-minute lapses.

• Professional expertise

The importance and benefits of professional guidance during such transitions are self-evident. We at QRC can help you in preparing for this transition phase. We conduct a thorough audit of your software development process as per the Secure SLC defined scope and requirements. Post assessment, we provide you with AoV, ROV Report. With new Secure SLC standards in play, you can reap the benefit of Secure SLC Annual Maintenance Service that ensures full compliance of the SLC on Recertification Assessment. You can avail advisory services for risk identification, analysis, and management. We conduct impact analysis and provide end-to-end assistance from configuration and change management to establishing Quality Assurance Process. We also provide complete SSS Solution by reviewing, advising, security testing, conducting code review the payment software, training the development teams and helping in certification and listing in PCI SSC Secure Software Standard listing.