Put ‘request’, ‘response’ tranlog columns in new table

My partner in crime,  Andy Orrock, writes a post about a feature (more of an enhancement) that we have implemented in our OLS.Switch product in a recent blog post titled: Put ‘request’, ‘response’ tranlog columns in new table, I wanted to add some of my own commentary on this change.  Please read Andy’s Post first before continuing.

As a Payment Switch there are times ( especially in development / testing ) that you will want to log or see what the switch is sent from a terminal or POS system, or sent and recieved from an authorization end-point. This feature is very handy during integration to new end-points, different message formats, changes with additional data elements and initial testing and certification efforts in test environments. In Production this is very, very bad, because raw messages contain card-numbers, Track Data, CVV2 Data, PIN Blocks, and all of the other “Bad” stuff one is prohibited to store according to PCI. OLS.Switch by default has this feature turned off, and recommends its use as a last resort for troubleshooting production problems.

Let me rip the introduction paragraph and a few bullets from our PABP Implementation Guide:

Secure Troubleshooting Procedures


OLS.Switch is configured to use various techniques to either protect or wipe sensitive cardholder and authentication data to prevent storage of prohibited data, or to use encryption to render the card number unreadable.


There may be instances in which sensitive cardholder information or sensitive authentication data needs to be viewed for troubleshooting purposes. Sensitive authentication information must only by collected when needed to solve a specific problem. The following are secure troubleshooting procedures designed to allow limited controlled access for troubleshooting purposes, all steps must be followed. You must be authorized and approved to make these system configuration changes.  Furthermore, it is recommended that your internal company’s Change Management and Problem Management policies and procedures are followed in conjunction with these procedures.

x.     Determine if troubleshooting can be performed on test environment with test card numbers.  Perform troubleshooting in that environment first.


x.     Only collect the limited amount of information needed to solve the specific problem. Only collect enough data in the troubleshooting log that is required to address the specific problem  

(There are lots of other steps and controls to verify that any changes are set back to default, appropriate destruction of captured data is handled, etc, etc, etc.)

Logging raw messages is a dangerous feature and much care needs to be taken with it, and is rightfully heavily scrutinized with knowledgeable PCI Auditors, while not an issue in a test environment using test card numbers, a system misconfiguration or human mistake or “forgotten” changed setting in production could prove disastrous. OLS has added some “controls” around this feature.
Previously there were columns in our TranLog that were called REQUEST and RESPONSE, in order to enable this type of logging an entity such as a store or specific terminal (Terminal ID) would need to be configured and enabled to do so, and would need to follow all of our “user controls” and recommended procedures (including preventive and detective controls) in our PABP guide. For the record non of our clients on our production system have any data in the REQUEST and RESPONSE columns of the TranLog in production environments. I’m happy that it is not a widely used feature in production.

With the new release we now have a single related table called raw_request that has a relationship with a transaction in the TranLog – a much cleaner and normailzed approach. In addition to this, there is a system-wide parameter called auditTrace for each OLS.Switch module that must be enabled by setting the value to true, it is defaulted to false. These system wide parameters are based off of configuration files, and we recommend that our clients use File Integrity Monitoring to detect and alert on any changes to application configuration files.  Once the system-wide parameter for the modules are enabled, a specific store or terminal needs to be configured and enabled; It is a two step process. In addition, This approch also makes it easier to detect if the system is configured in a “non-compliant” fashion – we have monitoring tasks and alerts that scan the raw_message table, and alerts if the row count is non-zero. Also if there is any Database replication or archiving, moving this data to a separate table, ensures that troubleshooting data remains and isn’t disseminated.

This feature is a necessary evil that most of our customers ask for or have in other Payment Switches (we do have the ability to remove the raw_message table and functionality completely). We hope that further adding preventive controls (Making it harder to enable, user controls to use dual control and have secure troubleshooting policies and detailed secure troubleshooting procedures to follow), detective controls (user controls to detect application configuration changes and monitor row counts of the raw_message table) ensure that it is an intentional change on the customer’s part to enable this functionality.

Also: the following paragraph by Andy shows off our different biases:

One follow-up to this Release Note:  I asked Dave how we should set ‘auditTrace’ in production – my thought was to set it to ‘true,’ thinking we’d be at the ready to turn on tracing without a service re-cycle.  Dave strongly disagreed and stated: OLS.Switch ought to be “Secure by Default” in production.  I really liked that.

Dave = Security Focused.
Andy = Operations and Timely Troubleshooting.

Leave a Comment.