Marci@BalaBit

In my previous posts I dig into the problem of preventing leak of sensitive data in an SSH connection using Shell Control Box (SCB). I was focusing on detecting access to credit card numbers as it is a fairly common request from customers. Tokenization or data masking are requests that we see not just around of SCB, but also in a logging context to remove or hide credit card numbers in syslog messages. Recently I was playing with the latest syslog-ng OSE release (3.4.1) and put together a small extension similar in goals to what I was doing with SCB. (The inpatients could jump to the syslog-ng specific part, though would loose my thoughts on masking logs in general.)

Removing that highly sensitive data is very important as it limits the systems where credit card numbers are processed and stored. By masking the messages, the log management and SIEM systems could be outside the PCI compliance scope, which could be great relief for the administrators and for security personnels. The PCI DSS 2.0 defines as it’s applicability:

“If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN (Primary Account Number), or are otherwise present in the cardholder data environment, they must be protected in accordance with all PCI DSS requirements except Requirements 3.3 and 3.4, which apply only to PAN.”

While requirements 3.3 and 3.4 is the following:

“3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).”

“3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography (hash must be of the entire PAN)

• Truncation (hashing cannot be used to replace the truncated segment of PAN)

• Index tokens and pads (pads must be securely stored)

• Strong cryptography with associated key-management processes and procedures”

Actually PCI requires PANs to be rendered unreadable in stored log messages, but never the less it is also a useful to remove PANs from logs during processing otherwise the analyzing system has to comply with PCI as well.

For log messages, where the actual PAN is usually not important for any forensics situation, truncation or a one-way hash seems to be the most usable and least error prone solution. It preserves the possibility to latter search for a PAN by searching for the truncated or hashed value, which could be important indeed. Also for reporting and statistical purposes both options give a sufficient results as the counts and distribution information is kept.

Using tokens or strong cryptography are probably not worth it for log messages. Both of these require a fairly complex infrastructure to run and having the PANs recoverable in case of logs is not really required in most cases. Tokens require a tokenization service to be available, while a proper key-management must be in place for cryptography, and even if those are available, linking it and using it in log management is not a trivial task. Of course your mileage may vary, but never the less it is actually a good idea to think about this and defining the goals with logs before selecting which approach to use to render PAN in logs unreadable.

An other interesting question is where to do the masking?

Probably the most logical place for removing or masking PANs is in the application which generates the logs. There is everything easily available to do so, though it is also the hardest to modify latter (if the app does not have it built-in) and the least flexible to choose which approach to follow.

An other interesting approach we saw is to do it in the logging subsystem of the application, one like log4j, log4net etc. Log4j provides many possibilities to add latter external “plugins” to modify the messages. Unfortunately in this case we have already lost the context and the ease what the application built-in approach had.

Both of these options are unfortunately not complete as PANs might get logged from other components besides the core application, like through database debug, a message queue log or any other middle-ware or backend messages. One might even not be aware of such a log source with PANs possibly appearing there as well. Turning on a bit more verbose debugging for troubleshooting could circumvent our application built-in filtering and leave us with PANs stored in the logs.

The other option we have is to leave the masking to the log management or log processing systems. We can choose where we want to do it, before sending the messages to a central log server, before our SIEM or before just storing the messages in files or in a database. Unfortunately in all of these cases we need to search for PANs in all of the messages which could be resource intensive depending on the amounts of events. (If we only remove PANs from a known list of messages we might be missing some special debug or even completely unrelated messages, which were not considered. This would leave us in the same situation that I explained above.)

Of course the above mentioned options could be combined. It might be a good idea to do the all message scanning just before storing the logs as a last safeguard. It could be less of a resource demanding action as certain filtering could drop irrelevant logs way before, therefore just a smaller portion of messages need to be searched.

What could syslog-ng do for us?

Syslog-ng is a very efficient tool in anyone’s log management inventory, especially when it comes to mangling log messages. Besides filtering logs, syslog-ng has a very powerful log rewrite subsystem that we could utilize to render credit card numbers unreadable. Also syslog-ng is used both on the sender side and as a central log server application, so we are fairly free to select where to do the masking. (It is also possible to store the messages encrypted directly with syslog-ng, so that could be an other option to go with.)

After the messages are received syslog-ng could apply multiple rewrite rule on the message. We could utilize a regular expression to detect the credit card numbers and replace them with something more PCI conform. (Of course regexps are somewhat limited in detecting credit card numbers as no proper luhn calculation could be done, but in a PCI network it’s recognition rate (false-positives) should be fine for us.) Now, what we need to do is just use a rewrite rule before forwarding or storing messages in the configuration.

Rewrite rules using regular expressions also gives as the freedom that we did not have to specify in advance which part of the message contains the PANs as regexps could match any part of the message. This is useful in cases we do not want to spend time on parsing messages or in case we want to use syslog-ng as a last safeguard to make sure no PAN gets past our other masking functions and no PAN is eventually stored. Of course it is also possible to parse messages by patterndb or work with structured messages, like ones received over IETF syslog protocol and mask PANs outside of the traditional message body.

(An interesting use case could be – with the latest syslog-ng – to collect transaction data, mask PANs and forward the events using advanced message queuing protocol (AMQP). This way the message broker and the event processors would receive a “clean” event to work with.)

With the latest 3.4.1 release syslog-ng received a set of powerful cryptographic hashing template functions. I will use these for hashing credit card numbers in my rewrite rules. To make administrators life easier, I have created a reusable rewrite configuration block in syslog-ng to replace credit card numbers with the first 16 digit sha1 hash of the number.

block rewrite hash_cc(value("MESSAGE"))
{
	subst("(?P<1>:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})",
	"$(sha1 --length 16 $1)",
	value(`value`),
	flags(global, store-matches),
	type(pcre));
};

Using this block is very easy, I just need to refer it in my logpath statement:

log {
	source(s_local);
	rewrite { hash_cc(); };
	destination(d_local);
};

I am using the following log message for testing purposes. (Obviously the number used in the example, is not a valid one. It was once, but than it was probably stolen so my bank revoked it. Anyhow it would do for testing.)

Transaction approved; checkout-id='46255763', amount='38.43', cc='5542043004559005'

As a result the PAN got hashed:

Transaction approved; checkout-id='46255763', amount='38.43', cc='986d97fc95435b22'

By default “hash_cc” hashes credit card numbers in the body of the logs ($MESSAGE), but it is very simple to do the same for “structured data” (SDATA) parts of the logs. An other example to clear PANs from the sdata → PAN part:

log {
	source(s_local);
	rewrite { hash_cc(value(“.sdata.pan”)); };
	destination(d_local);
};

Of course it is possible to mask the PAN instead of using hashing with syslog-ng. I have also created a rewrite configuration block for that scenario:

block rewrite mask_cc(value("MESSAGE"))
{
	subst("(?P<1>:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})",
	"$(substr $1 0 6)******$(substr $1 -4 4)"
	value(`value`),
	flags(global, store-matches),
	type(pcre));
};

Using it is very similar to the previous example, just this time I will use the “mask_cc” block in my logpath:

log {
	source(s_local);
	rewrite { mask_cc(); };
	destination(d_local);
};

The result using masking with the same example message is the following:

Transaction approved; checkout-id='46255763', amount='38.43', cc='554204******9005'

I hope I was able to provide some useful ideas on how credit card number handling could be done in log messages from the PCI point of view. syslog-ng is also a great tool that could help you – though I am a bit biased. Anyhow, with a simple configuration like the ones shown above it is very easy to get it done without much hassle. Of course one could even more fine tune the regexps or the way how masking or hashing is done.

Happy logging!