Miss the “C” Word and be doomed

Secure SDLC in the PCI DSS Ver 3.2 Ambit: “Compliance Management ( the “C” Word)

I recently attended a conference where a discussion started on how the PCI DSS Standard meshed into the Software Development Life Cycle (SDLC) / process. The scope of the discussion was restricted in a broad way to any application that handles card data and our discussions were restricted to the requirements of the standard that are applicable to the SDLC / process.

If a simple question were to be asked to a group of people, as to what are the applicable controls from the PCI DSS Ver 3.2 Standard that apply to such an application – the response would be “Requirement No. 6” and this would be the end of the discussion (please refer Table No. 1 below).

Inadequate coverage of the requirements of the PCI DSS standard in the SDLC/ Process is a common mistake that is made by enterprises and the people associated with software development. This will lead to catastrophic results at a later stage of the development cycle. So how does one overcome this problem or oversight (if we may call it that)?

The solution to this problem/oversight is rather simple – after documenting the business and user requirements for the application, we need to map/identify all the applicable security requirements from the PCI DSS standard and have security embedded into the SDLC process starting from the design phase.

Organizations exhibit the inability to achieve this (seemingly complex task) due to several reasons viz. ignorance at various levels, lack of importance to security & compliance requirements, skimming over the requirements of the standard, lack of knowledge of the SMEs within the enterprise, lack of knowledge of the development team etc. Whatever the reason(s) maybe, the resultant application will NOT comply with the requirements of the PCI DSS Standard and WILL land the enterprise in a SOUP.

Unfortunately, there is no SILVER BULLET to solve all these problems and each one of them will have to be addressed separately. I recommend a consulting approach to address these complex issues – which would start with an As-Is Analysis, the defining a To Be State and also conduct a Root Cause Analysis phase to ascertain the causes of the various problem. The entire consulting approach shall address the People, Processes and Technology parts within the enterprise to ameliorate these problems.

Coming back to the standard response to our question – what requirements of the PCI DSS standard apply to the SDLC/ Process. Most people would respond “Requirement 6”. of the PCI DSS Standard.

This would generally be the response of a person who is NOT well versed or understands the PCI DSS Standard completely. In the conference too the response was more or less on similar lines and hence I thought of writing this article.

The correct response would unravel completely after you have done a deep dive into the requirements of the “PCI DSS standard” line by line.

As CONFIDENTIALITY of the cardholder data is the foremost concern addressed by the PCI DSS standard, it is pertinent that the standard is analyzed in its entirety and a list of the applicable requirements are distilled for use within the enterprise.

Having completed this exercise separately, I have tabulated the list of the applicable requirements in the table below:-

Please stay tuned for further discussions and tips on PCI DSS and other compliance standards like GDPR, HIPAA, ISO 27001, DPA etc.

I shall be covering aspects like Cloud, Data centers, infrastructures and networks as it pertains to these standards.