Point of Sale software vendors that have or are planning to go through the PA-DSS validation process are aware of the requirement detailed within the Payment Application standard. These requirements range from ensuring proper software development and testing processes and support procedures are in place to include detailed technical requirements around password and logging controls. In addition, many vendors are aware that at the end of their validation process there is an attestation document and a Vendor Release Agreement that must be executed in order for the PCI SSC to process any application submitted for PA-DSS validation. It is within these two documents that there is a key policy that a software vendor agrees to have in place and continue to follow.
This policy they agree to have in place is a “Vulnerability Handling Policy” that is consistent with industry best standards. This policy requires a software vendor to have a program and detailed processes in place regarding the detection, receipt, triage, prioritization and repair of or workaround for security issues that may be found in their software. For PA-DSS, a “security issue” is any defect or vulnerability of the software vendor’s listed application that has caused or allowed unauthorized access to account data. This means that a vendor must continue to evaluate their application for newly discovered vulnerabilities and also provide a process for customer and third-parties to report to them possible vulnerabilities. Once a vulnerability is reported the vendor must then take steps to confirm the suspected security issue is valid or not. The policy must also detail how the vendor will notify its customer base of the security issue. The Vendor Release Agreement that is executed by the software vendor also requires them to notify the PCI SSC of the issue in writing. The notice is to be provided to customers, and the PCI SSC must detail:
- the names, PCI SSC approval numbers and any other relevant identifiers of each Listed Product of Vendor that Vendor reasonably believes may be impacted by such a Security Issue;
- a description of the general nature of the Security Issue;
- a good faith assessment, to the software vendor’s knowledge at the time, as to the severity of the vulnerability or vulnerabilities associated with the Security Issue (via a “Severity Assessment” which uses CVSS scoring or an alternative industry-accepted standard that is reasonably acceptable to PCI SSC); and
- a good faith determination, based on the software vendor’s knowledge at the time, as to whether the Security Issue is a unique one.
Finally, the software vendor must provide a patch for addressing the security issue or a workaround while the patch is being developed.
This process is similar to that implemented by the likes of Microsoft or Oracle whereas security issues are discovered in the wild or by internal staff, and alerts are issued to their customer base along with or followed by a service pack or hotfix. For larger development companies, the implementation of a Vulnerability Handling Policy is not overly cumbersome, but for smaller development companies that at times sign the attestation and Vendor Release Agreement without much thought, the rigors of maintaining a Vulnerability Handling Policy may be an unexpected surprise.
