Here’s a Release Note I wrote about a new feature we implemented this week into our production environments (some redacting performed – see items in brackets):
-------------------------------------------------
Put ‘request’, ‘response’ tranlog columns in new table:
In the test system implementation, the defined terminals mostly reference terminal profiles in which the ‘Audit’ flag is turned on (i.e., set to ‘Y’). Doing so provides [the OLS.Switch customer] with visibility to the raw, hexadecimal Store System request and response images in the transaction UI display. This level of detail is often vital while reviewing testing efforts. Behind the scenes, the OLS application stores this raw transactional data in the request and response columns of the tranlog as ‘varbinary’ objects.
In production, the Audit flags for the “in use” terminal profiles are by default set to ‘N’. However, there may be situations in which [an OLS.Switch implementer] is asked (for troubleshooting, fraud detection, etc. reasons) to temporarily track the raw request and response sequences from one or more targeted, production transaction origination points. This raises some ‘handling’ concerns:
- For financial transactions, the raw store system request may reveal the card number in the clear (if it is sent unencrypted). Taken alone, this isn’t a concern if undertaken inside a well-fortified PCI Zone with corresponding good practices. However…
- Once the exercise is concluded, to subsequently remove evidence of the raw request and response requires direct SQL-level action on the tranlog – either to delete specific rows (not recommended as we want the tranlog to be a faithful record of all attempted transactional activity) or to set the request and response columns to NULL. In general, manipulation of the production tranlog along these lines is a practice that should be avoided.
- Should the Audit exercise continue for more than one day, items are copied to the [historical repository] of the tranlog. Raw message information from the production system should not be perpetuated in the repository.
For these reasons, in this release we are moving the ‘request’ and ‘response’ columns out of the tranlog and into a new raw_message table. The structure of the table is as follows (this is the MS SQL Server version of the schema commands):
create table raw_message (
id numeric(19,0) identity not null,
txnid numeric(19,0) null,
type varchar(3) null,
messageData varbinary(MAX),
PRIMARY KEY (id)
);
Where:
- id is the auto-incrementing identity column
- txnid is a reference to the corresponding identity column in the tranlog
- type indicates whether the item is a raw request message (‘REQ’) or raw response message (‘RSP’)
- messageData is the binary representation of the raw message as received from (in the case of ‘REQ’) or delivered to (in the case of ‘RSP’) the transaction origination point
Additionally, OLS has introduced a new property (‘auditTrace’). This value must be set to ‘true’ in the TransactionManager in order for raw message logging to take place. [The value is actually engaged in ‘log_and_reply.inc’, a file that is referenced by all TransactionManager instances.]
After the implementation of this change, a production post-audit clean-up becomes a simpler, unencumbered exercise: raw data is not moved to [the historical repository]; and information logged to ‘raw_message’ table can be cleaned up via SQL without engaging the tranlog.
-------------------------------------------------
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. Here’s how I memorialized it in our SVN logs:
Set new auditTrace flag to 'false' in production so that we are "Secure By Default" (c) 2009, Dave Bergert
[See Dave’s follow-up to my piece here.]
Comments