Auditing and documenting
This topic might appear to be quite boring, but this does not make it any less important. While documentation has been a requirement for a long time, the RTS creates new challenges for anyone involved in payments. There are a number of new articles that are more demanding than previously referring to the documentation.
Article 3: Review of the security measures
To begin with, the implementation of security measures are now required to be documented, tested, and audited by independent auditors:
Article 3: The implementation of the security measures referred to in Article 1 shall be documented, periodically tested, evaluated and audited in accordance with the applicable legal framework of the payment service provider by auditors with expertise in IT security and payments and operationally independent within or from the payment service provider.
Article 1 and 2: Fraud Scenarios
Another new requirement is that the documentation is now supposed to take into account existing fraud scenarios and that the integrity and confidentiality of authentication tokens have to be proven. This can be seen in article 1, some of the requirements to be documented are the mechanisms which “protect the confidentiality and the integrity of the payment service user's personalised security credentials;”
Furthermore, according to article 2, you are supposed to take into account “(c) known fraud scenarios in the provision of payment services;”.
Article 3: General requirements
Yet another article that touches on documentation requirements is article 22, which states in paragraph 3: “Payment service providers shall fully document the process related to the management of cryptographic material used to encrypt or otherwise render unreadable the personalised security credentials.” This is of course particularly important when you are using a smartphone to do payments.
Okay and PROSA Security
The systems used for secure customer authentication (SCA) and transaction security are of course only a part of what is required to be documented, but as a software vendor that is the part that we are interested in. As a payment services vendor or merchant, it is important to be able to document the entire process, so we believe it is important to choose a vendor that can document even the stringent requirements listed above.
In our latest round of formal documentation evaluation, we did the following:
First, we cooperated with an expert on security analysis,PROSA Security. PROSA creates tools that enable formal proofs of integrity, authenticity, and confidentiality of protocols and complex computer systems. The tools can also do automatic and semi-automatic attack simulations so that we could easily see what would happen with e.g. a man-in-the-middle type attack on a part of the process.
In addition to the tools, Prosa helped us through the “Prosa process”, which is used for creating a model of the software solution, formalizing security requirements, analyzing threats and creating a complete risk analysis.
After completing the risk analysis the result was a report that was analyzed by an accredited evaluation institute, SRC Gmbh.
The end result was a successful evaluation
We believe this is the level of documentation and evaluation that payment service providers will have to provide in the future.
As a side note: Many software vendors rely on penetration testing today. We believe this is clearly insufficient to prove the security of a software solution. Penetration testing can show that the security is bad, but it is incapable of showing that the security is good, as you cannot assess whether the penetration testing is sufficient by itself. There is only one way to prove that a solution is actually secure: performing a formal analysis of the said solution.