Leaving any sight of sarcasm behind, this puts into focus a simple -and enormous- truth: the high costs of any e-discovery process, specifically when organizations are requested to search among their data to produce evidence. If Google claims the process is difficult and too costly, any other company should really stop for a second and think on how to tackle this issue.

The first solution that may come to mind would be to improve searching capabilities for finding exactly what is needed. This solution, though, may produce what is called  a  “false negative” if a relevant file is not found, or  a “false positive” if something that is not relevant for the case is found  - recent findings suggest that 70% of the total documents revised in an e-discovery process are false positive findings. This proves that the correct approach should be not just having a good searching tool, but -as the columnist mentions- also that  organizations should “take available technological measures to preserve documentation for legal proceedings”. Having “the ability to preserve new documents as they are created” is key to this.

This brings me to what we do at Kinamik… which is exactly that! We build a centralized, independent and Secure Audit Vault that serves as a safe for all the sensitive data -such as audit trails-, making  them tamper-proof in the process for a future proof preservation. And of course, search capabilities are also available in that audit vault. Well … maybe I should give Google a ring?

So if you go through life certain that your bank passwords are safe, and nobody can access that delicate piece of information… think again. As Bruce Schneider reports in his blog, this funny story has a bit of a worrying level underneath.

Summarizing the story up, Steve Jetley -a Lloyd’s TSB bank customer- decided to set his bank password as “Lloyd’s is pants”, just to find later that his password had been changed to “no it’s not” by a bank employee without Mr. Jetley knowing about this. The story gets worse when -after realizing the change- he tried to change it back to his original password or another similar such as “Barclays is better” on the grounds that it was “too long” (Barclays is a competitor of Lloyd’s). Even the password “censorship” wasn’t allowed.

Mr. Jetley received a full apology from the bank and the employee (I don’t know if the one that changed the password in the first place or the one that refused to accept the new ones given) was dismissed.

I think that leaving aside the possible comical side of this story, what worrying about this case is that banks are keeping their passwords in flat, non-encrypted forms in their databases. Why would an employee be able to see any client’s password? Or even further, why would an employee need to see any client’s password? So here for me there are two important issues:

1) confidentiality: makes me wonder how many of these important passwords that I have (banking, payment platforms, etc.) are still unencrypted, and

2) accountability: why would an employee see a client’s password?

I guess that the reason is that people (i.e. IT Managers, System Administrators, or even employees) access data for a plain and simple reason: because they can. If proper audit trails systems would be put in place, if there would be any kind of system that could serve as a “surveillance camera” that can prove irrefutably all the access and modification to data, there would be an automatic deterrance for this kind of behaviour. People would not be sniffing around information they shouldn’t be looking at if they knew that all their actions were being audited, that these audit trails could not be tampered with and consequently they can -and probably would- be held accountable for their actions.

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.

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 suprise 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.

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”.

Requirement 10.5.2 states that “Audit Trails files should be protected against unauthorized modifications”. We feel that there are is no case for an authorized modification of an audit trail file and hence the word “unauthorized” should be replaced with “all”. Audit trail files should be absolutely immutable to be of any use in a legal or regulatory context.

So, we hope that erasing this “unauthorized” term will happen in the new release. We’ll keep you posted.