In the November 2010 Assessor Update newsletter from the PCI SSC, there is a clarification of what constitute “minor changes” to PA-DSS certified applications. Based on my reading of this clarification, there is going to have to be more clarification done.
The first thing the clarification does is define a “minor change.” According to the PCI SSC, a “minor change” includes, but is not limited to, a change to the application that:
- Only impacts the aesthetics of the application such as GUI enhancements, movement of buttons, color updates or changes and marketing changes.
- Only impacts components of the application that do not relate to the authorization or settlement processes such as adding a field not related to cardholder data processing and updates to the Implementation Guide.
Changes that fall into these two categories do not require that the PA-QSA conduct a re-assessment of the application and file a new Report On Validation (ROV). Therefore, the application continues to hold its existing PA-DSS certification. However, the PA-QSA is required to prepare and file a Minor Update Attestation form with the PCI SSC. Should the PCI SSC reject the Minor Update Attestation form, the PA-QSA could be placed in remediation. So PA-QSAs will likely be very picky about signing off on any “minor” changes.
So what then are considered changes that require a new ROV? The PCI SSC defines the following changes as those requiring that an application be reassessed and a new ROV prepared and filed.
- Changes that directly impact components of the application, which performs the authorization or settlement of the payment transaction, such as any change that can be tied to a PA-DSS requirement.
- Changes made to how cardholder data is stored, processed, or transmitted such as adding a new authentication module or database.
- Changes that impact the approved underlying operating system or platform.
The first two points should not surprise anyone. However, the last point regarding changes to the operating system is interesting as I know a lot of vendors and my own clients that will now hide behind this as a way to keep from patching their systems. I do not think this is the effect that the PCI SSC desires, but I can tell you that is exactly the effect they will get. As a result, vendors and merchants alike will not patch because any patching other than the OS release certified will now invalidate their PA-DSS certification. This would seem to be in direct conflict with the PCI DSS, a situation that the PCI SSC told us would not happen under v2.0 as they were aligning the two standards to complement one another.
Under such a scenario, should Microsoft issue an emergency patch to SQL Server in response to a severe threat such as SQL Slammer, that patch would likely not be applied by merchants because that act will invalidate the application’s PA-DSS certification and the vendor would also likely not recommend that the patch be applied for support issues as well because of the PA-DSS certification issue. This will only lead to making applications less secure, not more secure. The PCI SSC will need to further clarify this point to make sure this is not the case.
I also have to question the change to the approved underlying platform. So, if a vendor only certified their application on Windows or Linux running on HP hardware, if they change to IBM hardware configured with exactly the same memory, processor, expansion slots, etc. the application must be reassessed? In this day of common Intel or AMD -based hardware, that seems a bit over the top even for the PCI SSC. However, in the case of going from an Intel to AMD or from Windows to Linux, I would agree that the AMD or Linux systems need to be assessed. I know what the PCI SSC is trying to accomplish with this definition, but they will have to clarify this as well. Just what constitutes a platform change? Is it the whole platform, CPU, memory, sub-components such as NICs, modems, SAN, NAS, etc.? How they answer will drive the costs of certification. I think they have opened a Pandora’s box that they should have discussed further with the PA-QSAs and application vendors before issuing this “clarification.”
Then there are those of you that develop in-house custom applications that are in-scope for the PCI DSS. Do not think that the PA-DSS does not apply to you. While it technically does not apply, as I point out to my clients that develop applications, the PA-DSS is a great framework for secure application development. I urge our clients’ application developers to use the PA-DSS standard as a reference and framework for their own secure development practices. Therefore, I would recommend that all custom application developers follow the aforementioned definitions.
