PCI (Payment Card) Requirement for File Changes

[markscohen]

I'm trying to determine how BC could be used to meet a requirement set out by the Payment Card Industry (PCI). It calls for the use of change detection on log files to ensure that the ONLY allowed change from one file version to another is the addition of new data at the end, which is normal for logs. However, a change to existing older data would be a compromise in integrity and should trigger an alert. I am using file verification software to ensure that the checksum on a file has not changed but that does not take care of the specific case where appending data is OK. Thanks in advance.

[Aaron]

Hello Mark,

We do not have an automated method to indicate that appended data is Ok, but you could generate a report of only Orphan data (which has no matching line on the other side). If the report has content, then that would be the appended data. You can then generate another report of Differences-No-Orphans to find any changed lines.

To test these report types, use the Text Compare and load your two files, then use the Session menu -> Text Compare Report.

You can generate the same report on a selection of multiple files in the Folder Compare by using the Display Filters to show differences, Edit menu -> Expand All, Edit menu -> Select All Files, then the Actions menu -> File Compare Report. Different Display Filters can limit the selection of files.

Our trial is fully functional and available for testing. If you have any questions or run into any trouble generating the reports, please let us know and we'll try to get this set up. Purchasing the software is not required for any features.
http://www.scootersoftware.com/download.php

[dr_barnowl]

I think the trick here is to use a log format that includes a chain of SHA1 sums as a field.

Each log entry should end with the SHA1 sum of the whole log up to that point. Because that SHA1 then becomes part of the log, the next SHA1 will include it, etc, etc... you end up with a chain of SHA1 sums that depend on all the prior rows being intact.

Note that this is not in itself enough to tamper-proof your log - a smart hacker will be able to work it out and still rewrite the logs, but every SHA1 onward from the edited point would have to change. If you periodically archive the log (and create a cryptographic signature of the log file on another system) you should be able to produce an absolutely inviolate log history up to your last archive + signature. (Presuming your signing key is on a system that is separate to the logging system and that it's secure - you could just send the log hashes off site to a cryptographic notary to be signed).