Rational Survivability

I don't know if it's art, but I like it.

What a great little security architecture planning diagram. Allows you to break your infrastructure into manageable parts, while still showing overlaps where strategies and technologies should converge.

Mind if I use this diagram in my presentations?

I think that the diagram tries to show how security should be handled, namely:

– Host Security + Storage Security by the O.S.

– Host Security + Network Security by well defined Protocols

– Network Security + Application Security by the Business Logic of applications

– Application Security + Storage Security by Metadata (ok, here it doesn't make much sense…)

Also showing that common/used data should be beneath all this layers. Just my $.02

Anyway, you'll figure it out eventually, just try to put yourself in the same state you were last year 🙂

This looks to me like a nice depiction of all the different types of data when you're talking about "data-centric" security, and how it's hard to get "centric" in terms of treating it all the same. That's my story, and I'm sticking to it.

(It's very nice, by the way. If you're not going to use it for the description I just posted, can I steal it, file the serial numbers off, and use it myself?)

I'll take a guess and say that it has to do with the need for a data-centric approach to security across multiple disciplines and in multiple technology areas. (Ooh, that sounds like I almost know what I'm talking about!)

The last two are right; obviously "data-centricity" is one key, but why? I think it has less to do with security and more to do with the cloud. I think you are trying to show that where all these security items overlap is date, but where is the data. For the customer it is the cloud. Multiple aspects of cloud security clustered around all that matters to the customer, the customer's data in the cloud.

Looks like you were trying to show how a significant subset of data which is network addressable has nothing to do with either the host or the application around which there are known and controlled interfaces, indirectly indicating that this data in the center of your map is not not logically located, probably unknown in nature and directly accessible from the network. Looks like the perfect map for the concerns of those doing data leakage protection programs.

As the sunlight passes through the cloud, it produces a colourful rainbow of security issues?

It kinda looks like what I see by Thursday afternoon after slamming my face onto my keyboard for the 20th time that week.

Only…this doesn't move around…

This is a nice diagram that I never would have dreamed of, but I like it. The thing I see from this diagram is that data is the most exposed attack surface. Rather than demonstrating defense in depth, which is the traditional recommended security model, this diagram demonstrates an organization's data (the most key asset) has the most accessible attack surface, reachable by multiple vectors (OS, Storage, App, Network). So if any particular security tier is breached (the weakest link) the attacker gets your data and wins.

IMO, the more typical diagram is concentric circles demonstrating the layers of security. I think this one is overall, more accurate demonstrating that any layer failing can lead to a critical breach.

This appears to be an Easter Egg planning project. Where data input is the egg, you can see that it stripes it pretty well. I wonder if you view this diagram on the vernal equinox if it "stands up on end" ?

Is it attempting to show how little you understand Application Security?

Lol. Ok, sorry. That was uncalled for. It was funny to me though if that helps.

Maybe it's attempting to show what a unrealistic emphasis is put on Host/Network/Storage security versus Data/Application Security?

I actually got this in my email way back when. It's a taxonomy of overlapping areas of responsibilities. You have a ton of people trying to manage their own little fiefdom and the part that really matters is the data, but they only partially touch on it.

It does look like a visual tool tying together the overlapping security domains a data centric security model, emphasizing data as the common element viewed in different ways. If not used for any other purpose it seems adequate but there are at least two flaws in how it relates storage and application security to the other domains. Storage security seems to assume a non-SAN environment. Application security doesn't reflect the close relationship between it and host security. Might be more accurate and less cluttered if it didn't include storage. Otherwise it's a good visual to get a point across.

To me it looks like the diagram is emphasising on the importance of protection of data under various forms, the value of data is more than the value of organisation and hence forth have to have defence in depth , multitier and multilayer Security.

for e.g.Host based Security is for OS, Data and few Protocols,Storage security for data & meta data, Application security for Metadata & data & bus. Logic, Network Secirity is for data, Bus.Logic and Protocols. in all three layers of security the common focus is protection of data , data in motion or data at rest or data travelling across all network or network of networks.

It's all about the data. Everything that we do is focused on protecting the data that we are the guardians of. We use the core layers of our environment and harden them and each of their protocols so that they are best suited to protect data at every touch point.

I like this, but… It gets an "almost there" from me. The thing is, there's a dimension that almost seems missing from this… Dunno. Let me try to articulate…

— each of the bubbles is a source of rulesets

— the sum of those rulesets is what defines the security of a given data entity

The thing I'm struggling with is that there's a source of rulesets that is missing, if the goal was to capture ALL of the rulesets that are needed to describe the security profile of a data entity — that source is the law (and things that resemble the law, like various regulatory and compliance rules).

Now, a counter-argument to my observation might go something like this, "No, you f**cking idiot! Legal, regulatory and compliance rules are completely orthogonal to this decomposition. This picture shows the four horsemen (oh, sorry, wrong post) that are needed to *implement* the rules that come from the legal, regulatory and compliance world." To which I would squirm, and say, "Yeah, maybe. Except there are rules inside those four bubbles that don't come from any particular legal, regulatory or compliance requirement, aren't there? Aren't there completely technical things being addressed in there, too? Things for which there are no explicit laws or regulations? IOW, things which you could, at best, trace back to a particular law or regulation by inference? And to the extent that this is true, it seems wobbly to to me… Dunno."

The thing I'm chewing on is that I'm increasingly obsessed by the need to decompose data entities along legal, regulatory and compliance fault lines — which is not how geeks like me decomposed data entities in the past. And so, although I (enthusiastically) like this picture, because it surfaces one part of my new obsession — "it's all about the data" — in a typically Hoffian (elegant) way, it leaves off the other part.

I think. But I'm not sure. 😉

Your overlaps are a bit odd. I'd have expected there to be an overlap between Application and Host.

Richard Stiennon recently mentioned his three laws of simple security:

1. Good end point security assumes the network is hostile.

2. Good network security assumes the end point is hostile.

3. Good data security assumes the user is hostile.

I added:-

4. Good user security assumes the data is hostile.

Which covers the need for user education.

But thinking about it, these "laws" also need

5. Good end point security assumes the data is hostile.

6. Good data security assumes the end point is hostile.

Since we have a chain

User — Data — End-point (or host) — Network

And each link in the chain should only trust those either side with great caution.

Your picture has similar links in what interface areas need protecting.

I think its a abstract view of Cloud Kernel – n/w,storage,applications and CPU(Host) and the data flow and security …

I know the prize has been awarded, but I want to chime in with a few things this conveys to me. This diagram also indicates that it takes a village to raise a child… er- it takes cooperation between many (often silo'd) disciplines to secure data. It's a good depiction of defense-in-depth at a technical level. This could also be a component of an Information Security Management System if all of the governance/procedural controls were to be linked with it.

Given the diversity of responses, I suppose it is also a Rorshock drawing for InfoSec folk.

/dan

If you make yourself go crosseyed and let your eyes get out of focus it turns into a 3d image of a 21 year old girl eating a banana while her roommate licks an icecream in the background.

Or maybe that's just me……..