The Immutable kBlog: thoughts on data integrity

It is common nowadays that banks offer different value-added services to their customers. Doing banking operations by phone or through the Internet is an everyday practice that obviously requires some kind of authentication; this matter is commonly addressed by -at the minimum- using some kind of password.

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.

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

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

The PCI Consortium is currently working on the new PCI DSS Standard, which will be version 1.2. While reviewing the 12 requirements we came out with a surprising point:

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.