Data Centrism, De-Perimeterization, and Fanaticism
First, - yes, yes we know. Rothman went and dissed risk analysis. At least Mike was kind enough to mention FAIR. There may be a more reasoned response to that article may be coming in the next few days, but Mike does say one thing I’d like to address right now:
The reality is that nearly all risk-modeling approaches force you to make estimates based on assumptions that are in turn based on estimates.
Let me just say that I don’t think it’s uncommon or inappropriate, in scientific method, for one man’s posterior to be another man’s prior (a little statistician humor there for you).
BACK TO THE REAL WORLD (SORT OF)
The “Data Protection, Management and Leakage” Weblog asks, “Data-centric security: How far do you de-perimeter your perimeter?“. Which is a great question. Jack’s been working very hard for a couple of years on a means to create a quantitative scale that answers such a question, and I think we’re close to product/training/consulting based on this new framework. I’m not going to get into the details of an answer based on that framework now, but the 5000 foot answer is:
“To the extent at which you have the most ability to prevent, detect, and respond to loss events”.
Which seems obvious, doesn’t it? But when you think about (as the data-centric blog post does) the level to which we should “de-perimeterize” and gain the most efficiency doesn’t exactly jump out at you. There isn’t a flashingly obvious “de-perimeterize THIS much” sign, or a “best practice” you can take the lazy way out with.
So here’s Alex Hutton’s thumbnail guide to De-Perimeterization: De-Perimeterize to the extent that you are reducing risk and creating operational efficiencies to your greatest benefit.
Your key categories of metrics are:
- How well does this let me do my job better
and
- Given that increase in my ability to do my job, and the concept of data-centrism, how much is my risk then reduced?
Which then begs the question, how do I measure my ability to reduce risk? If you want to build an answer yourself, all the clues you need are in this blog. If not, a formalized approach and metrics program is available, delivered by yours truly and a former Fortune 100 CISO for just a modest consulting fee 
Rob Newby Dec 19
How far do you de-perimeterize your perimeter? That’s a very good question.
I have the same problem with centralization/decentralization and convergence/divergence. How far do you go before other issues arise? Is there a ‘critical mass’ in each case?
Whenever I’m talking de-perimeterization I get a vague fuzzy picture in my head of ‘a corporate network’. I strip away the perimeter security, putting in safeguards as I go, but there is always a point where the network is raw and exposed, or so cluttered with new security measures that it becomes unusable.
It is also no secret that I detest firewalls. They are a piece of kit that exists solely as a safeguard for weakness, not a strengthening of existing measures. However, turn this on its head and what happens without firewalls?
Back to square one and my fuzzy network disappears in a puff of confusion. Interesting topic, I may have to share…
Alex Dec 19
Rob-
Share? Please do!
Rob Lewis Jan 7
Your thumbnail guide is very pragmatic advice.
I see a few problems in the discussions regarding de-perimeterization, the first being that information-centric security is being attempted by moving network-centric solutions inward, to the endpoint, becoming incorporated into the network fabric, etc.. Network security was designed to work with infrastructure and plug holes. There is not much attempt to address the design flaws at the system level which are responsible for our security weaknesses in the first place. The holes are becoming more dispersed and we are trying to “granularize” network security to keep up.
Second, business rules do not map easily to security rules with these technologies, thus the security rules impede business data flow at some point Yet, it is the business rules that we intuitively need as our yardstick for such things as separation of roles and duties, least privileges etc.. Having business rules map directly to security rules are a requirement for information-centric security, which is in turn a requirement for de-perimeterization.
Alex Jan 8
Hey Rob Lewis!
“information-centric security is being attempted by moving network-centric solutions inward”
Amen. I’ve drunk the whole Jericho Kool-Aid - I think new solutions are needed. New solutions built on a new model.
RE: mapping rules to technologies, I’m also very much in agreement. The answer, I’m sure, lies in objects, meta-data and persistence - I’m just not smart enough to know how.
Rob Lewis Jan 9
Alex, you are very smart and I appreciate your thoughtful, well-expressed posts here and elsewhere to help me learn.
I am not smart enough to figure out these things either, bit I do have have a partner who IS smart enough to figure this stuff out.
He has taken a few different directions with the Trustifier security model and they seem sensible. I pass them on for you for consideration, as they demonstrate my comment and tie into your response.
Consider the following business rule:
“If Alex opens a doc > secret level 5, then deny Alex access to USB bus”
(The secret level and device are arbitrary for the example)
That rule is stated more or less in normal language syntax. This is also exactly the security rule. What is more, it translates directly into an integer value at the kernel level.
When business rules need to be converted by some kind of translation in the kernel, then one adds complexity and adds risk, I believe. I have also been told that to accomplish that business rule in SELinux or trusted Solaris might take about 2 pages of policies/rules, but I have to defer to my source on that point.
The main difference here is that the rule used is ownership-centric as opposed to object centric. What does that mean?
Trustifier rules-specification is owner-centric (user, group, roles) rather than object centric. Rationale: It is easier to specify security in terms of users, groups, or roles rather than in terms of objects owned by them. Example: “Disallow network sockets to Bob” vs. “for each executable object in the system that utilizes network sockets create ACL for Bob and clear its execution bit for Bob”.
By doing this, business and security rules become intuitive to the point that even a non-technical manager can understand them. The rules are written in the spoken language of the business. I would be interested in your interpretation of what this might mean in terms of reducing risk in a risk model.
Another very basic example is the simple enforcement of user group access. Trustifier simply enforces group access rules. If IT personnel are not in the human resources group, they do not get access to personnel files-period. Immediate base level least privileges.
How does Trustifier do this? It uses digital separation of data at the kernel level. This has huge implications in separation of duties and roles, data access, writing permanent records, etc, because it is done automatically without encryption. Thus, we avoid the approach of granularizing a network technology to provide information-centric security. Yet by simply grouping vendor partners, customers, staff, into whatever groups with the data they should access, there can be no further access beyond that group.
There is also ranking of users within groups and ranking between groups possible, and transferring data between groups only by an authorized person. Any change must be signed off on, and all transactions can be logged by a tamper-proof audit trail.Do you begin to see some possibities for enabling de-perimeterization?
That is not to say that Trustifier does not work with encryption. It works with every standard type and has tools to faciliate its use. What is more, it will enforce its use where required, as it is a kernel level policy enforcer of course. Likewise, it can work with meta-data if desired, but that is part of the whole object-centric type of rule setting which adds extensive labelling, classification and administrative overhead which makes such approaches costly, complex, and hence, riskier.
Do these notions seem reasonable to you?
Khurt Jan 26
I thank for this article. I think too much effort has been expended on the network centric view of security. Let the network does what is does best ( optimally delivering bits ) and provide secure access to it(NAC). Then put in controls around the data around its point of origin (DRM) and where is it stored.