My buddy Adrian Lane over @ IPLocks wrote up a really nice example of an information centric security model that is based off the discussions Mogull has been having on his blog regarding the same that I commented on a couple of weeks ago here and here:
I want to provide the simplest example of what I consider to be an information centric security. I have never spoken with Rich directly on this subject and he may completely disagree, but this is one of the simplest examples I can come up with. It embodies the basic tenants, but it also exemplifies the model’s singular greatest challenge. Of course there is a lot more possible than what I am going to propose here, but this is a starting point.
Consider a digitally signed email encrypted with PGP as a tangible example.
Following Rich Mogull’s defining tenets/principles post:
- The data is self describing as it carries MIME type and can encrypt the payload and leave business context (SMTP) exposed.
- The data is self defending in both confidentiality (encrypted with the recipient public key) and integrity (digitally signed by the sender).
- While the business context in this example is somewhat vague, it can be supplied in the email message itself, or added as a separate packet and interpreted by the application(s) that decrypt, verify hash or read the contents. Basically, it’s variable.
- The data is protected in motion, does not need network support for security, and really does not care about the underlying medium of conveyance for security, privacy or integrity. The verification can be performed independently once it reaches its destination. And the payload, the message itself, could be wrapped up and conveyed into different applications as well. A trouble ticket application or customer relationship management application are but two examples of changing business contexts.
- The policies can work consistently provided there is an agreed upon application processing. I think Rich’s intention was business processing, but it holds for security policies as well. Encryption provides a nice black & white example as anyone without the appropriate private key is not going to gain access to the email message. Business rules and processes embedded should have some verification that they have not been altered or tampered with, but cryptographic hashes can provide that. We can even add a signed audit trail, verifiable to receiving parties, within the payload.
I might add that there should be independent ‘Brokerage’ facilities for dispute resolution or verification of some types of rules, process or object state in workflow systems. If recipients can add or even alter some subset of the information, who’s copy is the latest and greatest? But anyway, that is too much detail for this example.
I'm not sure what Adrian meant when he said (in boldface) "The data is self describing as it carries MIME type and can encrypt the payload and leave business context (SMTP) exposed." Perhaps that the traffic is still identified as SMTP (via port 25) even though the content is encrypted?
For this example Adrian used MIME Type as the descriptor. MIME types provide an established "standardized" format that makes for an easy transition to making decisions and enacting dispositions based on (at least) SMTP content in context easy, but I maintain that depending on where and when you make these decisions (in motion, at rest, etc.) we still need a common metadata format that is independent of protocol/application that would allow analysis even on encrypted data at rest or in motion.
Need versus ability to deliver is a valid concern, of course...
A note on DLP and Information Centric Security: Security that acts directly upon information, and information that embeds it’s security are different concepts. IMO. Under a loose definition, I understand how one could view Data Loss Prevention, in context Monitoring/IDS and even Assessment as a data centric examination of security. But this is really not what I am attempting to describe. Maybe we change the name to Embedded Information Security, but that is semantics we can work out later.
I would agree that in the end game, the latter requires less (or perhaps none) of the former. If the information is self-governing and enforcement of policy is established based upon controls such as strong mutual authentication and privacy-enforcing elements such as encryption, then really the information that has embedded "security" is, in an of itself, "...security that acts directly on information."
It's a valid point but in the interim we're going to need this functionality because we don't have a universal method of applying yet alone enforcing self-described policies on information.
/Hoff