A Cogent Example of Information Centricity
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
Even to a technical neophyte like myself, what you are describing, both the end goal and the task of getting there, is just mind-boggling. Have you considered that meta-tagging causes another security issue in itself?
What I don't really get though, is what is the problem that you are really trying to solve with all of this?
Didn't Rothman really sum it all up:
" In my world of information-centricity, we are focused on what the fundamental element of data can do and who can use it. It needs to be enforced anywhere that data can be used."
Classifying everything in sight so that one can then decide who has access to it is putting the cart before the horse, from our point of view.
It makes more sense from the business rule point of view to determine the relative trust you assign your user-roles, and then profile the relative data to be accessed by shaping the access boundaries for each role.
The trust rankings for users and the relative boundaries for user-role data access are more in tune with the business rules, are portable, are enforceable, and are much less complex than the method you are discussing.
@Rob:
I've always been fascinated by the reaction people have to metadata. I often find that folks who ask the question you did, "Have you considered that meta-tagging causes another security issue in itself?" tend to frame the argument as if there were no compensating controls that would protect the data described by the metadata.
If you follow the logic of what's being described by our example, the content would be encrypted at rest and in motion. Assuming you bypassed access control, unless you had the keys, you still couldn't read the INFORMATION. What have you gained by being able to read the metadata other than to know that certain information exists.
Yes, it's true, if I label something TOP SECRET, Financial, HR, etc…it advertises the contents of the "container" holding the data. My response to that, given the construct above, is "so what?" Does it perhaps make for easier targeting? Sure, I'll concede that, but I think that the benefits outweigh the downsides when you consider the ability to actually enforce policy, regardless of "domain."
Role based/user based access control simply does not scale when you look at exchanging data outside of your own castle or with the secondary re-use of data and decentralized consumption of said data. What happens when something other than a "user" accesses the data? How about service/system accounts in applications? How about distributed processes? Backups? Consolidated returns from 3-4 different databases?
If the data is portable outside of an arbitrary boundary, your trust is only as effective as your control over that boundary. If the data escapes (legitimately or otherwise) outside of that realm, "access control" based on user/role has already outlived its usefulness.
If you create a document that is "TOP SECRET" and the control mechanisms based on user/access control allow me to put that document on a thumb drive and remove it from the premises, what stops me from reading it? If you answer that by suggesting encrypting the data, your argument holds true until I decrypt that document and store it in plaintext somewhere. At that point, you haven't solved the problem, you've merely delayed its inevitable failure…
Look, TODAY internally it makes complete sense to try integrate IAM with access control and build policies that allow you to do your best to enforce them based upon role/user. I get that.
However, the problem we have today is that it's getting more and more difficult to separate "internal" from "external," and the granularity of what defines a "community of interest" has to be more than an IP address or a username, especially if you consider the worst case of a breach.
So yes, Rothman summed it up perfectly when he said "" In my world of information-centricity, we are focused on what the fundamental element of data can do and who can use it. It needs to be enforced anywhere that data can be used."
<– that fundamental element is the information itself. Once you define and describe the information, it defines how and "where" it can be used. This, in turn, can then be mapped to or even included in the attached policy of WHO or WHAT can use it.
The cart and horse, in my opinion, is reversed in your argument. Defining who can access data before you comprehensively profile and classify (at time of creation and throughout the lifecycle) information is asinine and exactly explains the problems we have today.
The only reason, I fear, that you think that it "…makes more sense from the business rule point of view to determine the relative trust you assign your user-roles, and then profile the relative data to be accessed by shaping the access boundaries for each role" is because this is the best we are capable of today.
If you choose to consider solving the problem rather than treating the symptom, then perhaps you would think differently?
The perimeter model doesn't work. You're basically just suggesting drawing arbitrary perimeters based on users/roles. If the information gets loose, this model breaks.
The business problem I'm trying to solve? Here's a basic example:
Take a laptop loaded with sensitive information stored on it. I want to assure that the information stored on and transmitted by this machine and exchanged/accessed by anyone, regardless of OS, protocol, application, storage medium or communication capability, conforms to policies which are self-described by the information itself.
I want to ultimately ensure that the right entities have the right access to the right data at the right time, but I want to do it in a manner consistent with enforcing business rules based on the stuff that matters to me most — the information itself.
/Hoff
I missed your question earlier. You are correct that the bullet point is confusing. What I meant to say is that the business application, email, is self evident. The email header remains as it would normally be. The information is self describing as it is tagged as encrypted content in the message body, or could be an attachment to the email message. Sorry about the word jumble.
Information Centric Security Example
What I want to do to take this one step further is provide a tangible example of this model. 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 …
Information Centric Security Example
What I want to do to take this one step further is provide a tangible example of this model. 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 …
I agree that the data should be protectable, despite marking the containers for potential targeted attacks. The risk I am referring to is that the metatags themselves are a potential covert channel. How do your protect the actual metatag itself from manipulation?
When you say "…if I label something TOP SECRET", you also point out another weakness, the discretionary option of labelling by the doc author. How many people are doing end-runs around policy now just to get their work done, and then stamping some label on at the end, if they remember to do it, and do it correctly? So metatagging still requires some sort of policy enforcement that takes those decisions out of the hands of the doc creator, if he is working at a classified level.
"Role based/user based access control simply does not scale when you look at exchanging data outside of your own castle or with the secondary re-use of data and decentralized consumption of said data. What happens when something other than a "user" accesses the data?"
Actually, it does scale. We are in the business of scalable multi-level security, across the enterprise, or across the grid. The use of a kernel-level policy enforcer means that anything that is recognizable by the kernel can be assigned user trust rankings, whether that be systems, devices, code, and they can all be rated for secrecy or integrity rankings. The policies for user role access can be pushed over the entire enterprise or confined to a trusted zone within the normal DAC environment. Whatever processes the data goes through, the policy about what user can access it will be consistent everywhere, and where there is not a specific rule to allow access, there is none allowed. It is only in a (discretionary) world that lacks internal controls that users have options to take liberty with all, and classified docs.
To use your example, by simply ranking devices at a lower ranking then the user-role access (arbitrarily top-secret in this case), then the USB can not be used in the context of that data access attempt. The same goes with network cards, burners, printers and so on, all of which can still be used with unclassified docs.
If it is someone who has access and the privilege of copying a top secret file to some device, for whatever reason, by ranking audit logs greater for integrity than for users, even the system admin or security officers, means that the audit logs will be permanent and tamper-proof, acting in real-time to flag someone if a questionable event is taking place. If you absolutely require containment though, you can now have a policy to disallow copying, and enforce it, period. Need to contain everything in-house before an IPO for the SEC?
This may be indeed the best we are capable of today, but if we are so capable, why are so few doing it? You have already answered that question:
"The perimeter model doesn't work. You're basically just suggesting drawing arbitrary perimeters based on users/roles. If the information gets loose, this model breaks.".
To do so requires a comprehensive solution to enforce access and audit controls (the boundaries) at the data file level, and to prevent privilege escalations, and making sure the info does not get loose.
It is much easier to define the user-role and least privilege access for a vendor partner then to attach an ACL list to every doc in the enterprise that he might happen to run across. He gets what he needs and nothing else, and you are dealing with the targeted data that he requires only. We can do this for a contractor in just a few rules.
Using your laptop example, our technology would first make sure that the user was allowed to load the data on that machine. Let's make sure that data sets that are not supposed to be carried out the door, are not. We offer a risk analysis engine that can set limits based on set value of the data, to what is allowed to be transferred, or not, to laptops. It might enforce a rule that the user has read-only privileges over a secure channel, when away from the enterprise, whatever the business rule….
To load classified docs, one of the conditions would be that the laptop would be trustified itself. At that point the security policies would kick in about any of the transactions from that laptop. All business rules/policies regarding use of the data would then have to be abided, including the rules for the release or transfer of information based on white list policies. Trustifier will even prevent data from being sent in an unencrypted state if that is the policy.
You want the data to be self-policing, but who sets the rules for that data? What are the rules going to be based on? Probably who can access the data. Since anyone can be compromised, even one's most trusted user, how does metadata deal with that? How do your tell 10 million pieces of data in the enterprise that a rogue employee has been bought off? Whereas, by utilizing user-roles, you can remove someone's access privileges in minutes. Perhaps a combination of approaches is neccessary. I guess the question is, how to you make changes to metadata, and how do you govern the reems of legacy data that already exists that do not have tags?
Not as eloquent as you Chris, but these are things that float around in my head between reading your posts and being bombasted by my technical guys. 🙂
Rob:
I've got to figure out a more effective way of:
1) Not turning this into comment 'pong' that nobody will see/benefit from
2) Preventing this from turning into a commercial
I think you're missing some important elements in your examples and given where you are and what you do, you are constraining the argument to fit the answer; that's not a slam, just an observation.
It's that old case of "when you're a hammer, everything looks like a nail" conundrum…
Bear with me…