Fail Secure – Is typically used to describe door locks. When the power is on: the door remains unlocked, if power goes out: the lock ‘Fails Secure’ and remains locked when the power is off.
Payment System should also Fail Secure
One of the things that some developers do is log data in exception cases; Hell, I’ve also seen the log everything-you-might-never-know-when-you-need-it mentality. (with some scary looking DB Schemas) (I’ve even seen payment systems in the past that logged raw request and raw responses by default for all transactions, and also logged un-parseable messages in an exception file, all of which included binary representations of the underlying message format – yes it was binary, and sometimes even EBCDIC – but opposed to some popular beliefs – this isn’t encryption, and contains data elements that are prohibited to retain, applications like these will most likely be listed on Visa’s vulnerable payment application list. (A list of vulnerable payment applications is updated quarterly and is available on Visa Online at www.us.visaonline.com/us_riskmgmt/cisp.)
There are many valid reasons for doing this: why did the exception occur, is it repeatable, is it a software bug, an invalid message that can’t be parsed properly? etcetera. This is all good and fine in test and development environments, but this is particularly a concern when dealing with payment systems that are involved in processing, storing and retaining cardholder data and with this same type of exception logic in production system in the real world.
There may even be business reasons and good intentions to do so: under an exception the cardholder may have been charged (especially a debit transaction) and if the database or storage system was down, or a response message may not be parseable, the payment system may not have any record of this transaction. The cardholder may try again or with another card – and then end up with double-charging the cardholder. But if the raw data is retained – then one can troubleshoot, and re-create the appropriate transaction, or any returns or reversal and handle the exception cases.
Payment System should also Fail Secure – On an exception scenario – make sure that you are not logging or retaining prohibited data. PCI/PABP does have provisions to allow for troubleshooting these types of problems, but the procedures and controls around enabling detailed troubleshooting must very strict and require minimal data, and have similar controls around it to include initiation, authorization, access control, montiroing, secure storage and secure disposal of when it is no longer required. The process should also not be enabled by default. Config files, database config tables, etc that are used to enabled detailed troubleshooting – should be monitored (File Integrity, DB content checks) to make sure that this functionality is off when not needed.
Payment systems contain cardholder information and must be handled differently then other applications. Make sure that you and and payment systems developers understand this as well.