Recently I posted about PCI’s new payment application mandate coming out. Today I was lucky enough to receive a draft version, a comment sheet, and the associated NDA (thus why I have not posted the documents here).
A quick review basically outlines what we expected. PCI is taking Visa’s PABP program, transitioning it into PCI standards and putting the screws to the application vendors via the merchants.
A quick run down:
- The new requirements apply to 3rd party developed applications that store, process, or transmit cardholder data as part of the authorization or settlement.
- Merchants can only use third party payment applications which are pre-approved or able to pass certain criteria. This basically means, use what is pre-approved and save yourself time. Note: Internally developed payment applications which are not sold or licensed to a third party are not in scope.
- For those applications not on a pre-approved list, the QSA must have a lab to test the application against the PA-DSS standards. PCI outlines new guidelines around testing and the lab requirements.
- The merchants are liable, thus they will affect the vendors compliance through purchasing decisions directed by PCI.
I applauded PCI for sending this out and providing a comment sheet so that the standards can be improved before going live. Over all most of what I have seen so far I expected, let’s just wait to see what the final release looks like.
One Comment (including trackbacks)
@Fernado
PCI already requires security standards for internally developed software, though I think we will see the two standards merge or at least align more closely in the future.
Without breaking my NDA, I can say that there are retest requirements and certification steps the software vendor must undergo if certain types of changes are made to the software.
For reference on the standards already in place from PCI-DSS:
“6.5 Develop all web applications based on secure coding guidelines such as the Open Web
Application Security Project guidelines. Review custom application code to identify coding
vulnerabilities. Cover prevention of common coding vulnerabilities in software development
processes, to include the following:…”
“6.6 Ensure that all web-facing applications are protected against known attacks by applying either of
the following methods:…”
“11.3 Perform penetration testing at least once a year and after any significant infrastructure or
application upgrade or modification (such as an operating system upgrade, a sub-network added
to the environment, or a web server added to the environment). These penetration tests must
include the following:
11.3.1 Network-layer penetration tests
11.3.2 Application-layer penetration tests.”
Leave a Reply
You must be logged in to post a comment.