The Immutable kBlog: thoughts on data integrity

We are still about a month and a half before the official 1.2 version of the PCI Data Security Standard is officially published. A couple of days ago a summary of the changes was published in the official PCI Security Standards Council, and so far (this is just a summary) no dramatic changes were presented.

Whenever a new version of this kind of standards is published, different questions appear. For example, what happens with companies that are currently on the certification process? Well, these companies have nothing to worry about, since the PCI Security Standards council states that if a company is under the assessment process they can use the v.1.1 of the standard, even if they finish the assessment process after the official publication of version 1.2 in October.

For us working in the security area, in a snapshot some changes seemed rather obvious, some clarified “blurry” aspects of the standard, but it seems (can’t really say until the official 1.2 is published) to be still some ambiguity out there. I must say that I’m personally disappointed that -in this summary- no changes were mentioned about the needed integrity of the logs. The previous 1.1 version of the standard mention that logs “should be protected against unauthorized modifications”, which makes me wonder: what kind of authorized modification should be done to a log file? Aren’t log files meant to be logging exactly what happened?

More comments will be done as soon as the official PCI-DSS v.1.2 is released.

Public Health Records (PHR) allow individual to save, post, manage and share all their health record information via the Internet. Advantages associated to the use of this kind of tools are rather obvious: forget about trying to remember if you are allergic to this or that medication; don’t bother walking all the way to the doctor with your new test results, just to realize when it’s your turn to go talk to the doctor that you forgot home the previous results. Everything will be available online, but only for the people that you allowed to, and under the conditions that you stated.

Or at least in theory.

The adoption of PHR has been slower than assumed, mainly due to lack of trust in the protection of that data, according to Zöe Baird, president of the Markle Foundation. As a response, a group formed by technology companies, providers, health insurers and consumer groups released last June a common framework that will help consumers gain trust in these technologies. It is expected that this joint effort will boost its acceptance and use.

The framework consists of nine consumer policies that rely on seven different support technologies. It is no surprise that one of these technologies (CT3) is Immutable Audit Trails, and four of these nine consumer policies are based on the immutability of the audit trails. This, in other words, means that audit trails -files that track the use, access, modification or deletion of any data- must have integrity and be tamper evident: the integrity of this audit trails must be evident.

Security concerns have been shifting over the years: first on availability, later -in recent years- to confidentiality, and we totally agree with what David Lacey, one of the leading authorities in Information Security Management thinks.

As final users, we see the importance of data integrity only after an attack has occurred, or data has been tampered with. The impact of any change -be it malitious or accidental- is huge. Today, data integrity is percieved more as a “nice to have” than a “must have”… rarely enough stress is put in this.

Gradually people and enforcers are realising the potencial danger associated to “false proofs”. We in Kinamik believe that data integrity will be, quoting Mr. Lacey, “the next big threat”.