This article will take you through my journey and share my experience & learning from the PCI SSF – Secure Software Standard (S3), readiness projects that I have undertaken. The session focuses on the incremental changes on PADSS compliance requirements, while transitioning to PCI S3.

There are different acronyms in the space for example 3S or SSP – Secure Software Program. I am referring Secure Software Standard as S3.

I am going to cover my approach for transiting to PCI S3, best practices I have learn from the process, and the walks to maintain the PCI S3 compliance.

The Approach

The key focus areas are listed below.

 This is not a linear process except for the first one to get management team onboard. 

Executive Management

An initial step is to educate higher management to make aware of the complexities, effort and cost required from the organisation. We are a creature of habit. We were doing PADSS for several years, so the rhythm was built into the software development practices. Number of those practices require to update/improve to fully absorb SSF.
One of the key challenges I found was to right use of terminologies, SSF, SSLC, S3 etc. I used to get asked ‘how is SSF audit going on’? Preparing to accommodate the agility of SSF framework is important. I explained and discussed how PCI SSLC and PCI S3 will impact the road-map of the organisation and the steps to take to absorb S3 and SSLC. The roadmap needs to be aligned and planned based on audit schedule. Changes in the application requires careful planning and be mindful on incremental updates on S3 Specifications.Delta changes are handled differently for SSLC certified vendor and non-SSLC certified vendors. This has direct impact on the software release methodology and the release cadences.
Strategy to get SSLC certification 1) Overarching 2) Standalone.
In large organisation where there for multiple teams there are number of ways to have SSLC certification. In one of the organisations, I worked for the decision was to do overarching SSLC certification and the other organisation I worked for the decision was to do standalone. Both have their pros and cons. The cons with overarching approach where governance process could be very complicated where there are 10’s of products following same SSLC. Standalone approach may be expensive.
All these required investment and priority from the business so getting management team on-board in the most important objective in the process.

Documentation

Documentation is the area that requires significant effort in order to transition from PADSS to PCI S3. I have broadly categorised documentation into 4 areas as:

== Gap Analysis

After I bring management onboard, this was the first step I have taken to create a meta plan. This is where I got QSA engaged and internal experts like Security Architect, product architect, SMEs engaged for the details gap analysis. We clearly marked where the impact is

• CAR
• Application
• Technical documentation i.e., orange book
• Software Vendor IG

Gap analysis documents was used as a funnel for project planning including resources and the timeline. Also, helped to ensure no control objectives were missed out to do gap analysis. During the analysis we confirm the modules that are applicable to the payment application.

CAR & Technical Guide will be covered shortly.

Software Vendor implementation guide – Approach was to start a baseline of PADSS implementation guide. The structure of the IG was more down to sequential flow of S3 Control objectives.

== Critical Assets Register (CAR)

CAR is centre of universe for PCI S3. As the scope definition changed from PADSS, scope of CAR included

• Sensitive data encompasses- SAD CHD, Keys, Certificates, Token, PII – Categorized based on Assets type.
• Sensitive functions are added to corresponding sensitive data and Sensitive resources are added to corresponding crypto function.
• Retention period of sensitive data and crypto monitoring are recorded.
• Added how data is protected At Rest, In Flight and In Transit.
• Crypto functions defined how encryption/decryption works, These are consolidated as similar mechanisms are extended to protect number of sensitive data. This means Crypto function may have 1 to many relationships with Sensitive data. IF you have multiple TLS and PGP keys, the process remains the same to generate these keys. This avoided the duplicate information of crypto function of Sensitive data.
• Class & Packages information added in the template to refer to the source code. It is convenient for the dev team to find the code easily and during the audit.
• Data classification – Sensitive Data, Confidential, Private, non-confidential
• Introduced a column to add test evidence to demonstrate the controls that is in place.

As an example, tTaking Password as sensitive data, then salted hash is used for Data at rest, TLS in transit. Sensitive function is Authentication and Sensitive resources is JVM. CAR listed the code snippet and class path of salted hash mechanism as crypto function. Confidential data.

== Orange Book

S3 specification states Examine, Interview and Test as Testing methods. Any information that is not part of User guide or Vendor IG to examine the objectives are documented in orange book. Target audience are QSA and Software Vendor- Not to be distributed and used as an internal playbook for PCI S3 compliance. Some examples from the Control objectives are, internal working of the encryption keys, certificates, authorisation, and access control of sensitive data etc.

Technical guide (Orange book) – Name is inspired from Trusted Computer System Evaluation Criteria (TCSEC) a criterion developed by the United States Department of Défense (DoD) in 1983 to evaluate the security of computer systems. This helps to clearly distinguish the guide of other technical guides within the documentation suite.

Application

The payment application I led were fairly matured from PADSS perspective however there were several changes that we had to do to meet control objectives.

• Entropy requirements is heavily emphasized in S3. These led to use appropriate Random number generator algorithms. As a result we changed random() method in Java to Secure Random() to be complaint.
  Encryption algorithm that requires IV e.g., AES cipher mode CBC, GCM.
• Payload production of 128 mega bytes
• Auditing had to extend to audit keys, token etc. Specific test cases are asked in CO to maintain the integrity of log file.
• Integrity check must be done once every 36 hours. Application may be terminated in case of failure. We introduced a flag for an action to indicate what to do when such failures occurs, for a business reason. The information was documented in Software Vendor Implementation Guide

Audit

I found PCI S3 audit are through and detailed. It must be due to the fact that we all are at the early stages in the PCI S3 audit process compared to PADSS. The interpretation of the control objectives and follow on discussion to be able to align was one of the important aspect of the audit.
Key here is to have patience and provide every support that QSA need in the process. QSA is there to help to strengthen the security controls in the application, not to make Software vendor life difficult. It is a collaborative process.

Maintenance

I am strong believer in continuous compliance. I aimed to check all boxes for compliance after every sprint within the software development process. Key here is not to keep compliance till the end. In order to achieve that:

• Embedded CAR and Orange book into SDLC process– Added a field in Change management tools like JIRA or Redmine, to indicate impact on security also added a field whether CAR is impacted of not, during grooming process by Product manager or owner or security architect.
• SSLC governance – Overarching SSLC for multiple products and standalone products.
• Proactive approach and be vigilant on the changes from PCI SSC on the standard. It is now more important that the PCI S3 has more agile and nimble approach in the standard. So far, MODULE A, B C are introduced by PCI SSC in the PCI S3 standard.

I hope this excerpt has been useful to get a view on PCI S3 practices. There are lot more to this to be PCI S3 compliance. If you need template, help or have a feedback, please contact Simplified Solutions using contact form.