How to delete part of a message content in the EMS log file?

[Igor]

Hello,

I have a question about deleting content of EMS logs.
Sometimes just happened that <not ours-have no source code> application is just dumping track 2 from payment cards into EMS log. Of course we would like that appl-developers will remove or fix that issue at first place, but, you know, that could take a lot of time (if at all).

Perhaps you know, if there is any kind of official or unofficial tool, that would replace some characters, for example with zeros) in the EMS log, manually? We are not searching for automation tool, but a tool (program) that we can run it manually with command: replace those characters in this EMS message in specified address with zeroes or any other character.

I would be very appreciative for any kind of information!

Best regards & have a great weekend!
Igor

[Keith Dick]

Post by Igor
Hello,
I have a question about deleting content of EMS logs.
Sometimes just happened that <not ours-have no source code> application is just dumping track 2 from payment cards into EMS log. Of course we would like that appl-developers will remove or fix that issue at first place, but, you know, that could take a lot of time (if at all).
Perhaps you know, if there is any kind of official or unofficial tool, that would replace some characters, for example with zeros) in the EMS log, manually? We are not searching for automation tool, but a tool (program) that we can run it manually with command: replace those characters in this EMS message in specified address with zeroes or any other character.
I would be very appreciative for any kind of information!
Best regards & have a great weekend!
Igor

I do not know of a utility program that will do what you want to do. Maybe someone else knows of one.

The first idea I have that is close to what you request is that, if the application that is generating the log messages you do not want allows you to configure the EMS collector to which it sends events, you could:

1. start an alternate collector
2. have the application send its messages to that alternate collector
3. start a forwarding distributor to forward messages from the alternate
collector to your usual collector, using a filter that drops the messages that contain the information that you do not want to appear in the usual collector.

This assumes that it is possible to write an EMS filter that identifies just those messages that contain the information you do not want, and that you are willing to completely drop those messages (that is, the other information in those messages is not important for your situation). You did not give enough information in your question for me to tell whether both those conditions are true.

The EMS log files are just entry-sequenced Enscribe files, so it probably would be possible to write a program that looks at each record to find the ones that contain the data you want to suppress and overwrite just the information you want to suppress, but that would not be a simple program to write. I believe there is no customer documentation of the tokenized buffer format, so you'd have to work out how to navigate that yourself. Since you are interested in only one particular message type, that would simplify your task quite a bit, but I still would suggest not taking that approach.

Maybe someone else has a better alternate approach than I suggested here.

[JShepherd]

Post by Igor
Hello,
I have a question about deleting content of EMS logs.=20
Sometimes just happened that <not ours-have no source code> application is=
just dumping track 2 from payment cards into EMS log. Of course we would l=
ike that appl-developers will remove or fix that issue at first place, but,=
you know, that could take a lot of time (if at all).
Perhaps you know, if there is any kind of official or unofficial tool, that=
would replace some characters, for example with zeros) in the EMS log, man=
ually? We are not searching for automation tool, but a tool (program) that =
we can run it manually with command: replace those characters in this EMS m=
essage in specified address with zeroes or any other character.
I would be very appreciative for any kind of information!
Best regards & have a great weekend!
Igor

Is the info you want to 'fix' in the EMS message
in a specfic application defined token
or is the info in a text buffer as ZEMS_TKN_TEXT

[Bill Honaker]

Post by Igor
Hello,
I have a question about deleting content of EMS logs.
Sometimes just happened that <not ours-have no source code> application is just dumping track 2 from payment cards into EMS log. Of course we would like that appl-developers will remove or fix that issue at first place, but, you know, that could take a lot of time (if at all).
Perhaps you know, if there is any kind of official or unofficial tool, that would replace some characters, for example with zeros) in the EMS log, manually? We are not searching for automation tool, but a tool (program) that we can run it manually with command: replace those characters in this EMS message in specified address with zeroes or any other character.
I would be very appreciative for any kind of information!
Best regards & have a great weekend!
Igor

It would seem to me that you're trying to put patches on a leaky pipe, hoping you manage to catch all the liquid that has escaped the pipe.

The other alternative is to write a proxy program, to be opened instead of $0 by the application. It could filter those records, or mask them, and write the results to $0.

This is without question a PCI compliance failure. You actually only have two choices; one is to note this on your audits with a variance
(which will undoubtedly have a cost to it) or to spend the effort to fix the program. Your customers (and your CFO ) would probably choose the latter if given all of the facts.

Also,remember that 'deleting' a row from a file (in the case of an entry-sequenced file, it's actually 'rewriting' it with zero length) may, or may not, remove it from the storage media.
The EMS system was not designed to allow removal of records written to it. So any effort spent trying to do that would not pass an audit of PCI rules.

If this program was written in the past 20 years, it should not have passed code reviews and been installed. Any PII should be well know in the design and handled.
If your company paid an outside vendor for this program they should get their money back, along wtih damages.

Just my US$.02.

Bill

[Keith Dick]

Post by Bill Honaker

Post by Igor
Hello,
I have a question about deleting content of EMS logs.
Sometimes just happened that <not ours-have no source code> application is just dumping track 2 from payment cards into EMS log. Of course we would like that appl-developers will remove or fix that issue at first place, but, you know, that could take a lot of time (if at all).
Perhaps you know, if there is any kind of official or unofficial tool, that would replace some characters, for example with zeros) in the EMS log, manually? We are not searching for automation tool, but a tool (program) that we can run it manually with command: replace those characters in this EMS message in specified address with zeroes or any other character.
I would be very appreciative for any kind of information!
Best regards & have a great weekend!
Igor

It would seem to me that you're trying to put patches on a leaky pipe, hoping you manage to catch all the liquid that has escaped the pipe.
The other alternative is to write a proxy program, to be opened instead of $0 by the application. It could filter those records, or mask them, and write the results to $0.
This is without question a PCI compliance failure. You actually only have two choices; one is to note this on your audits with a variance
(which will undoubtedly have a cost to it) or to spend the effort to fix the program. Your customers (and your CFO ) would probably choose the latter if given all of the facts.
Also,remember that 'deleting' a row from a file (in the case of an entry-sequenced file, it's actually 'rewriting' it with zero length) may, or may not, remove it from the storage media.
The EMS system was not designed to allow removal of records written to it. So any effort spent trying to do that would not pass an audit of PCI rules.
If this program was written in the past 20 years, it should not have passed code reviews and been installed. Any PII should be well know in the design and handled.
If your company paid an outside vendor for this program they should get their money back, along wtih damages.
Just my US$.02.
Bill

Bill,

It seems to me that Igor would prefer that the offending program gets fixed, but believes that could not happen very quickly, and is looking for a temporary way to solve the problem until the offending program gets fixed.

Your suggestion is:

"The other alternative is to write a proxy program, to be opened instead of $0 by the application. It could filter those records, or mask them, and write the results to $0."

If you substitute "alternate collector" for "proxy program", and "forwarding distributor with EMS filter" for "It could filter those records", your suggestion is almost the same as mine, and mine does not require writing a new program, just an EMS filter to recognize the offending event messages.

It is true that what I suggested still puts the track 2 data into the alternate collector's log files, which is not ideal, but I believe the alternate collector's log files could be given security settings that prevent any but SUPER.SUPER from reading them. That might not be good enough for PCI compliance (I don't know the rules), so maybe the custom program approach would be necessary.

[Bill Honaker]

Post by Keith Dick

Post by Bill Honaker

Post by Igor
Hello,
I have a question about deleting content of EMS logs.
Sometimes just happened that <not ours-have no source code> application is just dumping track 2 from payment cards into EMS log. Of course we would like that appl-developers will remove or fix that issue at first place, but, you know, that could take a lot of time (if at all).
Perhaps you know, if there is any kind of official or unofficial tool, that would replace some characters, for example with zeros) in the EMS log, manually? We are not searching for automation tool, but a tool (program) that we can run it manually with command: replace those characters in this EMS message in specified address with zeroes or any other character.
I would be very appreciative for any kind of information!
Best regards & have a great weekend!
Igor

It would seem to me that you're trying to put patches on a leaky pipe, hoping you manage to catch all the liquid that has escaped the pipe.
The other alternative is to write a proxy program, to be opened instead of $0 by the application. It could filter those records, or mask them, and write the results to $0.
This is without question a PCI compliance failure. You actually only have two choices; one is to note this on your audits with a variance
(which will undoubtedly have a cost to it) or to spend the effort to fix the program. Your customers (and your CFO ) would probably choose the latter if given all of the facts.
Also,remember that 'deleting' a row from a file (in the case of an entry-sequenced file, it's actually 'rewriting' it with zero length) may, or may not, remove it from the storage media.
The EMS system was not designed to allow removal of records written to it. So any effort spent trying to do that would not pass an audit of PCI rules.
If this program was written in the past 20 years, it should not have passed code reviews and been installed. Any PII should be well know in the design and handled.
If your company paid an outside vendor for this program they should get their money back, along wtih damages.
Just my US$.02.
Bill

Bill,
It seems to me that Igor would prefer that the offending program gets fixed, but believes that could not happen very quickly, and is looking for a temporary way to solve the problem until the offending program gets fixed.
"The other alternative is to write a proxy program, to be opened instead of $0 by the application. It could filter those records, or mask them, and write the results to $0."
If you substitute "alternate collector" for "proxy program", and "forwarding distributor with EMS filter" for "It could filter those records", your suggestion is almost the same as mine, and mine does not require writing a new program, just an EMS filter to recognize the offending event messages.
It is true that what I suggested still puts the track 2 data into the alternate collector's log files, which is not ideal, but I believe the alternate collector's log files could be given security settings that prevent any but SUPER.SUPER from reading them. That might not be good enough for PCI compliance (I don't know the rules), so maybe the custom program approach would be necessary.

Keith,

I chose to suggest a probram so that the PAN is not written to disk. It avoids any potential error in securing all the files.
I beleive that securing the EMS Log files is different from static files or tables, so it might not be understood by all system admins.

As for access to the origianl program, as I understand it, PCI compliance requires that any programs with access to PAN data should be auditable
(that is, the source must be available for review). Spending an hour to review the source is money well spent.
And commenting out the offending line(s) shold not be an insurmountable task. And protecting PAN data should be a high priority to any company.

Just my US$.02.
Bill

[Igor]

Hi all!

thank you for all your hints!

I got this question from application admins, and I was not informed with a whole/complete story around this issue. Sorry if you were misguided! It turns out, that they know how to fix (mask the PAN) in application output, but at first the problem must be identified.
We very aware of PCI regulations. The PAN's are tokenized throughout the application database. That is why we are trying to solve this very rare issue where some application device handler doing dumps in the EMS log with clear PAN in it. And it happened couple of time this year (unfortunately they found this really late), and we would like to "fix" this old EMS records... somehow.

@JShepard: yes, it is in the ZEMS_TKN_TEXT token.

At this moment they are trying to use our tokenization product to "tokenized" this EMS record.

So, another our challenge at this moment is, how to identify a record with the PAN in the EMS log as quickly as possible. I was thinking to use Prognosis, but unfortunately it grabs only first 254 characters from ZEMS_TKN_TEXT token. We will use PAN Finder product to check for PAN's in EMS logs on daily basis. If we run into another such issue, appl-admins can fixed it for future records, but we also have to "fix" the EMS records which has already been written in the log files containing a PAN.

Now I have a complete overall picture, and, hopefully, so do you 😊

By the way, is it possible, maybe, with EMS filters (or any other methods) to grab some EMS messages (I know how to define EMS table filters) and send it to alternate EMS collector just part of ZEMS_TKN_TEXT field, let say only the remaining piece after 254 characters? With that I can monitor with Prognosis online for PANs.

Thank you again for your time and hints!
Igor

[Keith Dick]

Post by Igor
Hi all!
thank you for all your hints!
I got this question from application admins, and I was not informed with a whole/complete story around this issue. Sorry if you were misguided! It turns out, that they know how to fix (mask the PAN) in application output, but at first the problem must be identified.
We very aware of PCI regulations. The PAN's are tokenized throughout the application database. That is why we are trying to solve this very rare issue where some application device handler doing dumps in the EMS log with clear PAN in it. And it happened couple of time this year (unfortunately they found this really late), and we would like to "fix" this old EMS records... somehow.
@JShepard: yes, it is in the ZEMS_TKN_TEXT token.
At this moment they are trying to use our tokenization product to "tokenized" this EMS record.
So, another our challenge at this moment is, how to identify a record with the PAN in the EMS log as quickly as possible. I was thinking to use Prognosis, but unfortunately it grabs only first 254 characters from ZEMS_TKN_TEXT token. We will use PAN Finder product to check for PAN's in EMS logs on daily basis. If we run into another such issue, appl-admins can fixed it for future records, but we also have to "fix" the EMS records which has already been written in the log files containing a PAN.
Now I have a complete overall picture, and, hopefully, so do you 😊
By the way, is it possible, maybe, with EMS filters (or any other methods) to grab some EMS messages (I know how to define EMS table filters) and send it to alternate EMS collector just part of ZEMS_TKN_TEXT field, let say only the remaining piece after 254 characters? With that I can monitor with Prognosis online for PANs.
Thank you again for your time and hints!
Igor

Thanks for clarifying the situation you are trying to address.

In response to your question at the end of your post, the standard EMS products do not provide any way to send a partial EMS message to an alternate collector. At least I do not recall any features that could be used to do that.

What you could do pretty easily, assuming you have at least a little experience using the SPI/EMS programming interfaces, is write a program that uses a consumer distributor to look at the events that could potentially contain a clear-text PAN, extract the ZEMS-TKN-TEXT value, examine it to see whether it does contain a clear-text PAN, and if so, send either the whole event, or whatever information you find relevant from the event to help you address the problem, to an alternate collector.

If it is easy to write a pattern that the MATCH function in EMS filters could use to reliably match the value of a ZEMS-TKN-TEXT token that contains a PAN, you could use that with a forwarding distributor to send just the problem events to an alternate collector. In that case, you would not need to write a program of your own. However, I don't know whether the MATCH function's pattern matching can reliably match PAN values, or can recognize reliably something else in the string that always is present when a PAN value is included. If you have looked at the MATCH function (and possibly other features of EMS filters) and cannot decide whether it is possible to create such a filter, we probably could help you if you describe in some detail what the value of the ZEMS-TKN-TEXT looks like when it contains a clear-text PAN.

[Bill Honaker]

Post by Igor
Hi all!
thank you for all your hints!
I got this question from application admins, and I was not informed with a whole/complete story around this issue. Sorry if you were misguided! It turns out, that they know how to fix (mask the PAN) in application output, but at first the problem must be identified.
We very aware of PCI regulations. The PAN's are tokenized throughout the application database. That is why we are trying to solve this very rare issue where some application device handler doing dumps in the EMS log with clear PAN in it. And it happened couple of time this year (unfortunately they found this really late), and we would like to "fix" this old EMS records... somehow.
@JShepard: yes, it is in the ZEMS_TKN_TEXT token.
At this moment they are trying to use our tokenization product to "tokenized" this EMS record.
So, another our challenge at this moment is, how to identify a record with the PAN in the EMS log as quickly as possible. I was thinking to use Prognosis, but unfortunately it grabs only first 254 characters from ZEMS_TKN_TEXT token. We will use PAN Finder product to check for PAN's in EMS logs on daily basis. If we run into another such issue, appl-admins can fixed it for future records, but we also have to "fix" the EMS records which has already been written in the log files containing a PAN.
Now I have a complete overall picture, and, hopefully, so do you ?
By the way, is it possible, maybe, with EMS filters (or any other methods) to grab some EMS messages (I know how to define EMS table filters) and send it to alternate EMS collector just part of ZEMS_TKN_TEXT field, let say only the remaining piece after 254 characters? With that I can monitor with Prognosis online for PANs.
Thank you again for your time and hints!
Igor

That's good information, Igor. You said it occurred a couple of times during this year. Since EMS rotates through it's logs, it's possible that those events are no longer on the disk.
To verify this, you can use the EMSCINFO command.

EMSCINFO [<collector name>] [,DETAIL]

The default collector name is $0.
The Current Log File will show you the subvolume used for that collector .
You can issue a FUP INFO command on the event logs, for example:

FUP INFO $DATA01.ZLOG04.ZZEV*

This will show you the date of the oldest event file currently on disk.
You could use the EMSCCTRL command to alter the maximum number of files to keep, in order to delete older ones.
Runnning the program with no options will display help. Once they're deleted, you shiould probably change it back to the current value.

You should still follow Keith's guidelines to use a consumer distributor (or better yet, PANFINDER), to determine if new occurrences of this erroneous logging have occured.
Good hunting!

Bill