(The following post covers some rather esoteric bits of security philosophy, or what Rich has affectionately called “Security Jazz” in the past. Unless you are into obscure data-centric security minutiae, you will probably not be interested).
Richard Bejtlich tweeted and posted on data integrity:
The trustworthiness of a digital asset is limited by the owner’s capability to detect incidents compromising the integrity of that asset.
This statement is absolutely correct and a really important point that is often overlooked. The problem is that most technologies which produce digital assets do not build tamper detection in, thus giving owners no way to detect integrity violtaions. And far too often people confuse interested party with owner of digital assets, as there can be many copies, each in the possession of a different person or group. It’s not that we can’t provide validation, because technology exists to provide assurance and authenticity.
Let’s look at an example: Who owns syslog
data? Is it the IT administrator? The security professional? An auditor? In my opinion, none of them do. The OS owns the syslog
, as it created the content. Much like you may think you own ‘your’ credit card number, but you don’t – it is something the issuing bank created and owns. They are the custodians of that number, and change it when they choose to.
syslog
has no way to verify the contents of the log it creates over time. We take it on faith that it is unlikely a log file was corrupted or altered. If we need to verify integrity in the future, too bad. If you did not build in safeguards and a method for validating integrity when you created the data, it’s too late. The trustworthiness of the digital asset is limited to the owner’s capability to detect a compromise, and for many digital assets like syslog
, that is nil.
For most digital assets, it is sufficient that we use them every day, as this provides sufficient confidence in their integrity. Encryption keys are a useful example. If the keys are corrupted, especially in a public-key situation, either the encryption or decryption operations fail. We may keep a backup somewhere safe to compare our working copy to, and while that can be effective in the most common problem situations, it’s only relevant for certain (common) use cases. Digital assets have an additional challenge over physical objects in terms of generations. Even if we can verify a particular iteration of a digital object, we can have infinite copies, so we need to be able to verify the most current iteration is in use.
For digital assets like encryption keys, account numbers, access tokens, and digital representations of self, the owner has a strong vested interest in not sharing the asset, keeping it safe, and possibly even keeping redundant copies against future emergencies or for verification. There are several technologies to prove integrity, they are just not used much. I posted a comment on Richard’s blog to this effect:
The trustworthiness of a digital asset is limited more by the trustworthiness of the owner than tamper detection. An owner with desire of privacy and data integrity has the means to protect digital assets.
Richard’s premise is an important one as we very seldom build in safeguards to validate ownership, state, authenticity or integrity. Non-repudiation tools and digital escrow services are nearly non-existent. There simply is not enough motivation to implement the tools we have which can provide assurance.
Gunnar Peterson blogged on this subject earlier this week as well, taking a slightly more applied look at the problem. His statement that these issues are outside the purview of DLP are absolutely correct. DLP is an outside-in model. This discussion has more to do with Digital Rights Management, which is an inside-out model. The owner must attest to integrity, and while a 3rd party proxy such as a DLP service could be entrusted with object escrow and integrity certification, it would require an alteration of the DLP’s “discover and protect” model. DRM is designed to be part of the application that creates the digital object, and while it is not often discussed, digital object ownership is part of that responsibility. Attestation to ownership is not possible without some form of integrity and state checking.
I have seen select DRM systems that were interested in high integrity, but none were commercially viable. Which answers Gunnar’s question:
Our ability using today’s technologies to deliver vastly improved audit logging is, I believe, a worthwhile and achievable goal. But it’s fair to ask – why hasn’t it happened yet?
There has been no financial incentive to do so. We have had excellent immutable log technologies for years but they are only used in limited cases. Web application audit trails are an interesting application of this technology and easy to do, but there is no compelling business problem motivating people to spend money on retrofitting what they have. I would like to see this type of feature for consumer protection, built into financial transactions where we really need to protect consumers from shoddy corporate record-keeping and failed banking institutions.
Reader interactions
3 Replies to “Which Bits Are the Right Bits?”
@Rob – This is not _just_ about log data. In fact, when I think of ‘Digital Assets’, a lot of things come to mind before log data. Probably because I have worked in DRM, so I consider my perspective to be skewed. Not many people think about virtual identities nor fathom the concept of digital property. Some people may think of music files as a digital asset, but not perceive motivation to alter or corrupt. Log files happen to provide a really good example of the issues at hand.
And I think most people know, those in security anyways, know that logs can be compromised …
Should we do a blog post on anti-forensics?
@David – Thanks for the link.
Adrian,
Perhaps it is not well understood that audit logs are generally not immutable. There may also be low awareness of the value of immutable logs: 1) to protect against anti-forensics tools; 2) in proving compliance due diligence, and; 3)in providing a deterrent against insider threats.
I don’t really recall seeing a comprehensive write-up of the benefits of immutable audit logs except for the Markle Foundation paper describing the need for them for secure data hand-offs and data sharing (silo busting).
If integrity and immutable logging were built into an OS, don’t you think they would be used?
We do provide integrity rankings for code, devices and users, and besides the obvious use cases of preventing tampering with assets (trade secrets) or sensitive information (smart grid, intelligence, financial transactions) this protection can prove useful in other ways.
For example, it becomes possible to separate system from administrator by ranking system files higher than personnel, the core system becomes read-only to all users. (prevents simple or “deliberate” accidents such as rm-rf/, {code dumps}, and code hostage/ransom events)
By giving block devices a ranking, critical devices are likewise immutable by system administrators; preventing changes to partition tables of a disc without proper authorization by a security officer would be an another example of protection against possible accidental or deliberate damage.
Speaking of detecting (or failure to detect) changes in assets:
https://financialcryptography.com/mt/archives/001195.html