Please note that a newer version of this post is available here. The information below pertains to PA DSS v1.2 that was retired in December 2011.
PA DSS requires vendors to ensure that the chain of trust is maintained for all installation and update files. These are primarily laid out in 7.2.a and 7.2.b PA-DSS 1.2 document. What this means is that customers should be able to verify that the files that they install/update are actually from you (authentication) and that they have not been modified (integrity).
This is something that trips up a lot of payment application vendors. Most payment application vendors post the software installation files on a website and have customers download them. This method is used by other software vendors too. A few times, vendors will also upload an HMAC (check-sum) of the file so that customers can verify that the files have not been modified.
Let’s say a hacker is able to break into the vendors download site, replace the original application installation/update files and also replace the HMAC to reflect the new file(s). When a customer downloads the files(s) and verifies the HMAC, it will check out, even though it is not the correct file. This is exactly what happened to WordPress in 2007 when a hacker replaced the installation package with one that had backdoor code in one of the files in the package.
So, how do we authenticate the files (to ensure that they come from the vendor) and also verify that the integrity is assured (to ensure that the files have not been modified by anyone else)? The easiest way would be digitally sign the files. Digital signatures serve will server both our purposes. The signature reliably authenticates that the files come from the vendor. They also contain a hash value that will not be valid if the files have been modified.
When customers download a signed installation/update package, they can check the digital signature and be sure that they are valid files. PA DSS requirement 7.2.b (v1.2) requires QSAs to replace the update files with arbitrary files and then verify that the update was not installed. This will require an automated way for checking the digital signature and verifying that it is valid before applying the update or patch.
Sometimes, vendors will say that their customers do not download the software themselves, but that the vendors’ personnel login remotely (that is a separate discussion in itself) and install the software and updates. Please note that this process will not meet the requirement. It does not matter who does the install or update, there has to be an automated way of authenticating and verifying the integrity of the packages.