Rational Survivability

The Walls Are Collapsing Around Information Centricity

Since Mogull and I collaborate quite a bit on projects and share many thoughts and beliefs, I wanted to make a couple of comments on his last post on Information Centricity and remind the audience at home of a couple of really important points.

Rich's post was short and sweet regarding the need for Information-Centric solutions with some profound yet subtle guideposts:

For information-centric security to become a reality, in the long term it needs to follow the following principles:

1. Information (data) must be self describing and defending.
2. Policies and controls must account for business context.
3. Information must be protected as it moves from structured to unstructured, in and out of applications, and changing business context.
4. Policies must work consistently through the different defensive layers and technologies we implement.

I’m not convinced this is a complete list, but I’m trying to keep to my new philosophy of shorter and simpler. A key point that might not be obvious is that while we have self-defending data solutions, like DRM and label security, for success they must grow to account for business context. That’s when static data becomes usable information.

Mike Rothman gave an interesting review of Rich's post:

The Mogull just laid out your work for the next 10 years. You just probably don't know it yet. Yes, it's all about ensuring that the fundamental elements of your data are protected, however and wherever they are used. Rich has broken it up into 4 thoughts. The first one made my head explode: "Information (data) must be self-describing and defending."

Now I have to clean up the mess. Sure things like DRM are a bad start, and have tarnished how we think about information-centric security, but you do have to start somewhere. The reality is this is a really long term vision of a problem where I'm not sure how you get from Point A to Point B. We all talk about the lack of innovation in security. And how the market just isn't exciting anymore. What Rich lays out here is exciting. It's also a really really really big problem. If you want a view of what the next big security company does, it's those 4 things. And believe me, if I knew how to do it, I'd be doing it - not talking about the need to do it.

The comments I want to make are three-fold:

1. Rich is re-stating and Mike's head is exploding around the exact concepts that Information Survivability represents and the Jericho Forum trumpets in their Ten Commandments.  In fact, you can read all about that in a prior posts I made on the subjects of the Jericho Forum, re-perimeterization, information survivability and information centricity.  I like this post on a process I call ADAPT (Applied Data and Application Policy Tagging) a lot.
   
   For reference, here are the Jericho Forum's Ten Commandments. Please see #9:
   

   

2. As mike alluded, DRM/ERM has received a bad rap because of how it's implemented -- which has really left a sour taste in the mouths of the consumer consciousness.  As a business tool, it is the precursor of information centric policy and will become the lynchpin in how we will ultimately gain a foothold on solving the information resiliency/assurance/survivability problem.
3. As to the innovation and dialog that Mike suggests is lacking in this space, I'd suggest he's suffering from a bit of Shitake-ism (a-la mushroom-itis.)  The next generation of DLP solutions that are becoming CMP (Content Monitoring and Protection -- a term I coined) are evolving to deal with just this very thing.  It's happening.  Now.
   
   Further to that, I have been briefed by some very, very interesting companies that are in stealth mode who are looking to shake this space up as we speak.

So, prepare for Information Survivability, increased Information Resilience and assurance.  Coming to a solution near you...

/Hoff

What a Shocker, Stiennon & I Disagree: Arbor + Ellacoya Make Total Sense...

"Common sense has nothing to do with it. When I say he's wrong, he's wrong." -- Ethel Mertz, I Love Lucy.

What a surprise, I disagree totally with Richard Stiennon on his assessment of the value proposition regarding the acquisition of Ellacoya by Arbor Networks. 

Specifically, I find it hysterical that Richard claims that Arbor is "abandoning the security space."  Just the opposite, I believe Arbor -- given what they do -- is pursuing a course of action that will allow them to not only continue to cement their value proposition in the security space, but extend it further, both in the carrier and enterprise space.

I think that it comes down to what Richard defines as "security" -- a term I obviously despise for reasons just like this.

Here's we we diverge:

I was actually in Ann Arbor last week when news broke that Arbor Networks had acquired Ellacoya a so called “deep packet inspection” technology vendor. I was perplexed. That’s not security.

"That's not security." Funny.  See below.

First let me clear up some terminology.   “Deep Packet Inspection” was the term some Gartner analyst popularized to describe what content filtering gateways do. They inspect content for worms, attacks, and viruses. Somewhere along the line the traffic shaping industry(Ellacoya, Allot, Sandvine) co-opted the term to describe what their devices do: look at the packet header to determine what protocol is being transported and throttle the throughput based on protocol. In other words Quality of Service for network traffic. These devices do not look at payloads at all except in some rare instances when you have to determine if Skype-like programs are spoofing different protocols.

Firstly, Richard conveniently trivialized DPI.  DPI is certainly about inspecting the packet (beyond the header, by the way) and determining what protocol and application that is being used with precision and fidelity.   In a carrier network, that's used for provisioning, network allocation, bandwidth management and service level management.

These are terms every enterprise of worth is used to hearing and managing to!

Certainly a disposition once the packets are profiled could be to apply QoS which is often what one might do in DoS/DDoS situations, but there are multiple benefits of being able to apply policies and enact dispositions which are dependent on the use or misuse of a specific application or protocol.

In fact, if you don't think that this is "security" why do we see QoS/Rate limiting in almost every firewall platform today -- it may not show up in the GUI, but this is a fundamental way of dealing with attack.

Oh, by the way Richard, perhaps you ought to read your own product manuals as Fortinet provides QoS as a "security" function...perhaps not as robustly as Ellacoya...and soon Arbor:

FortiGate Traffic Shaping Technical Note

The FortiGate Traffic Shaping Technical Note, available on the Technical Documentation Web Site, discusses Quality of Service (QoS) and traffic shaping, describes FortiGate traffic shaping using the token bucket filter mechanism, and provides general procedures and tips on how to configure traffic shaping on FortiGate firewalls.

FortiOS v3.0 MR1introduced inbound traffic shaping per interface. For any FortiGate interface you can use the following command to configure inbound traffic shaping for that interface. Inbound traffic shaping limits the bandwidth accepted by the interface.

config system interface
   edit port2
      set inbandwidth 50
   end
end

This command limits the inbound traffic that the port2 interface accepts to 50 Kb/sec. You can set inbound traffic shaping for any FortiGate interface and for more than one FortiGate interface. Setting inbandwidth to 0 (the default) means unlimited bandwidth or no traffic shaping.

Inbound traffic shaping limits the amount of traffic accepted by the interface. This limiting occurs before the traffic is processed by the FortiGate unit. Limiting inbound traffic takes precedence over traffic shaping applied using firewall policies. This means that traffic shaping applied by firewall policies is applied to traffic already limited by inbound traffic shaping.

Lot of uses of the word "firewall" in the context of "traffic shaping" in that description...Here's a link to your knowledge base, just in case you don't have it ;)

Secondly, since availability is often a function of security, as an administrator I'd want to be able to craft a "security policy" that allows me to make sure that the stuff that matters to me most gets through and is prioritized as such and the rest fight for scraps.  Doing this with precision and fidelity is incredibly important whether you're a carrier or an enterprise.  Oh, wait, here's some more Fortinet documentation that seems to contradict the "that's not security" sentiment:

Traffic shaping which is applied to a Firewall Policy, is enforced for traffic which may flow in either direction. Therefore a session which may be setup by an internal host to an external one, via a Internal->External policy, will have Traffic shaping applied even if the data stream is then coming from external to internal. For example, an FTP ‘get’ or a SMTP server connecting to an external one, in order to retrieve email.

Remember CHKP's FloodGate?  Never particularly worked out from an integration perspective, but a good idea, nonetheless.  Cisco's got it.  Juniper's got it...

Further, there's a new company -- you may have heard about it -- that takes application specificity and applies granular policies on traffic that does just this sort of thing: Palo Alto Networks.  They call it their "next generation firewall."  Love or hate the title (I don't particularly care for it) I call it common sense.  Are you going to tell me this isn't security, either? 

The next, next-generation of security devices will extend this decision-making criteria from ports/protocols through application "conduits" and start making decisions on content in context.  This is the natural extension of DPI.

I won't argue with the rest of Richard's points about M&A risk and market expansion because he's right in many of his examples, but that wasn't the title of his post or the real sentiment.

I think that this deal enhances both the capabilities and applicability of Arbor's solutions which have been largely stovepiped and pigeonholed in the DDoS category based upon what they do today.  I hope they can execute on the integration play.

As to the notion of ignoring the enterprise and "doubling down on the carrier market," Arbor has a great DDoS product for both markets; this allows them now to take advantage of the cresting consolidation activity in both and start diversifying their SECURITY offerings in a way that is intelligently roadmapped.

Who knows.  Perhaps they'll re-market the combined products as a "multiservices security gateway" just like Fortinet does with their carrier products (here.)

I think your marketing slip is showing, Rich.

/Hoff

Thin Clients: Does This Laptop Make My Ass(ets) Look Fat?

Juicy Fat Assets, Ripe For the Picking...

So here's an interesting spin on de/re-perimeterization...if people think we cannot achieve and cannot afford to wait for secure operating systems, secure protocols and self-defending information-centric environments but need to "secure" their environments today, I have a simple question supported by a simple equation for illustration:

For the majority of mobile and internal users in a typical corporation who use the basic set of applications:

1. Assume a company that:
   ...fits within the 90% of those who still have data centers, isn't completely outsourced/off-shored for IT and supports a remote workforce that uses Microsoft OS and the usual suspect applications and doesn't plan on utilizing distributed grid computing and widespread third-party SaaS
2. Take the following:
   Data Breaches.  Lost Laptops.  Non-sanitized corporate hard drives on eBay.  Malware.  Non-compliant asset configurations.  Patching woes.  Hardware failures.  Device Failure.  Remote Backup issues.  Endpoint Security Software Sprawl.  Skyrocketing security/compliance costs.  Lost Customer Confidence.  Fines.  Lost Revenue.  Reduced budget.
   
3. Combine With:
   Cheap Bandwidth.  Lots of types of bandwidth/access modalities.  Centralized Applications and Data. Any Web-enabled Computing Platform.  SSL VPN.  Virtualization.  Centralized Encryption at Rest.  IAM.  DLP/CMP.  Lots of choices to provide thin-client/streaming desktop capability.  Offline-capable Web Apps.
4. Shake Well, Re-allocate Funding, Streamline Operations and "Security"...
5. You Get:
   Less Risk.  Less Cost.  Better Control Over Data.  More "Secure" Operations.  Better Resilience.  Assurance of Information.  Simplified Operations. Easier Backup.  One Version of the Truth (data.)

---

I really just don't get why we continue to deploy and are forced to support remote platforms we can't protect, allow our data to inhabit islands we can't control and at the same time admit the inevitability of disaster while continuing to spend our money on solutions that can't possibly solve the problems.

If we're going to be information centric, we should take the first rational and reasonable steps toward doing so. Until the operating systems are more secure, the data can self-describe and cause the compute and network stacks to "self-defend," why do we continue to focus on the endpoint which is a waste of time.

If we can isolate and reduce the number of avenues of access to data and leverage dumb presentation platforms to do it, why aren't we?

...I mean besides the fact that an entire industry has been leeching off this mess for decades...

---

I'll Gladly Pay You Tuesday For A Secure Solution Today...

The technology exists TODAY to centralize the bulk of our most important assets and allow our workforce to accomplish their goals and the business to function just as well (perhaps better) without the need for data to actually "leave" the data centers in whose security we have already invested so much money.

Many people are doing that with the servers already with the adoption of virtualization.  Now they need to do with their clients.

The only reason we're now going absolutely stupid and spending money on securing endpoints in their current state is because we're CAUSING (not just allowing) data to leave our enclaves.  In fact with all this blabla2.0 hype, we've convinced ourselves we must.

Hogwash.  I've posted on the consumerization of IT where companies are allowing their employees to use their own compute platforms.  How do you think many of them do this?

Relax, Dude...Keep Your Firewalls...

In the case of centralized computing and streamed desktops to dumb/thin clients, the "perimeter" still includes our data centers and security castles/moats, but also encapsulates a streamed, virtualized, encrypted, and authenticated thin-client session bubble.  Instead of worrying about the endpoint, it's nothing more than a flickering display with a keyboard/mouse.

Let your kid use Limewire.  Let Uncle Bob surf pr0n.  Let wifey download spyware.  If my data and applications don't live on the machine and all the clicks/mouseys are just screen updates, what do I care?

Yup, you can still use a screen scraper or a camera phone to use data inappropriately, but this is where balancing risk comes into play.  Let's keep the discussion within the 80% of reasonable factored arguments.  We'll never eliminate 100% and we don't have to in order to be successful.

Sure, there are exceptions and corner cases where data *does* need to leave our embrace, but we can eliminate an entire class of problem if we take advantage of what we have today and stop this endpoint madness.

This goes for internal corporate users who are chained to their desks and not just mobile users.

What's preventing you from doing this today?

/Hoff

Tell Me Again How Google Isn't Entering the Security Market? GooglePOPs will Bring Clean Pipes...

Not to single out Jeremiah, but in my Take5 interview with him, I asked him the following:

3) What do you make of Google's foray into security?  We've seen them crawl sites and index malware.  They've launched a security  blog.  They acquired GreenBorder.  Do you see them as an emerging force to be reckoned with in the security space?

...to which he responded:

I doubt Google has plans to make this a direct revenue generating  exercise. They are a platform for advertising, not a security company. The plan is probably to use the malware/solution research  for building in better security in Google Toolbar for their users.  That would seem to make the most sense. Google could monitor a user's  surfing habits and protect them from their search results at the same time.

To be fair, this was a loaded question because my opinion is diametrically opposed to his.   I believe Google *is* entering the security space and will do so in many vectors and it *will* be revenue generating. 

This morning's news that Google is acquiring Postini for $625 Million dollars doesn't surprise me at all and I believe it proves the point. 

In fact, I reckon that in the long term we'll see the evolution of the Google Toolbar morph into a much more intelligent and rich client-side security application proxy service whereby Google actually utilizes client-side security of the Toolbar paired with the GreenBorder browsing environment and tunnel/proxy all outgoing requests to GooglePOPs.

What's a GooglePOP?

These GooglePOPs (Google Point of Presence) will house large search and caching repositories that will -- in conjunction with services such as those from Postini -- provide a "clean pipes service to the consumer.  Don't forget utility services that recent acquisitions such as GrandCentral and FeedBurner provide...it's too bad that eBay snatched up Skype...

Google will, in fact, become a monster ASP.  Note that I said ASP and not ISP.  ISP is a commoditized function.  Serving applications and content as close to the user as possible is fantastic.  So pair all the client side goodness with security functions AND add GoogleApps and you've got what amounts to a thin client version of the Internet.

Remember all those large sealed shipping containers (not unlike Sun's Project Blackbox) that Google is rumored to place strategically around the world -- in conjunction with their mega datacenters?  I think it was Cringley who talked about this back in 2005:

In one of Google's underground parking garages in Mountain View ... in a secret area off-limits even to regular GoogleFolk, is a shipping container. But it isn't just any shipping container. This shipping container is a prototype data center.

Google hired a pair of very bright industrial designers to figure out how to cram the greatest number of CPUs, the most storage, memory and power support into a 20- or 40-foot box. We're talking about 5000 Opteron processors and 3.5 petabytes of disk storage that can be dropped-off overnight by a tractor-trailer rig.

The idea is to plant one of these puppies anywhere Google owns access to fiber, basically turning the entire Internet into a giant processing and storage grid.

Imagine that.  Buy a ton of dark fiber, sprout hundreds of these PortaPOPs/GooglePOPs and you've got the Internet v3.0

Existing transit folks that aren't Yahoo/MSN will ultimately yield to the model because it will reduce their costs for service and they will basically pay Google to lease these services for resale back to their customers (with re-branding?) without the need to pay for all the expensive backhaul.

Your Internet will be served out of cache..."securely."  So now instead of just harvesting your search queries, Google will have intimate knowledge of ALL of your browsing -- scratch that -- all of your network-based activity.   This will provide for not only much more targeted ads, but also the potential for ad insertion, traffic prioritization to preferred Google advertisers all the while offering "protection" to the consumer.

SMB's and the average Joe consumers will be the first to embrace this as cost-based S^2aaS (Secure Software as a Service) becomes mainstream and this will then yield a trickle-up to the Enterprise and service providers as demand will pressure them into providing like levels of service...for free.

It's not all scary, but think about it...

Akamai ought to be worried.  Yahoo and MSN should be worried.  The ISP's of the world investing in clean pipes technologies ought to be worried (I've blogged about Clean Pipes here.)

Should you be worried?  Methinks the privacy elements of all this will spur some very interesting discussions.

Talk amongst yourselves.

/Hoff

(Didn't see Newby's post here prior to writing this...good on-topic commentary.  Dennis Fisher over at the SearchSecurity Blog has an interesting Microsoft == Google perspective.)

I see your "More on Data Centralization" & Raise You One "Need to Conduct Business..."

Bejtlich continues to make excellent points regarding his view on centralizing data within an enterprise.  He cites the increase in litigation regarding inadequate eDiscovery investment and the increasing pressures amassed from compliance.

All good points, but I'd like to bring the discussion back to the point I was trying to make initially and here's the perfect perch from which to do it.  Richard wrote:

Christopher Christofer Hoff used the term "agile" several times in his good blog post. I think "agile" is going to be thrown out the window when corporate management is staring at $50,000 per day fines for not being able to produce relevant documents during ediscovery. When a company loses a multi-million dollar lawsuits because the judge issued an adverse inference jury instruction, I guarantee data will be centralized from then forward. "

...how about when a company loses the ability to efficiently and effectively conduct business because they spend so much money and time on "insurance policies" against which a balanced view of risk has not been applied?  Oh, wait.  That's called "information security." ;)

Fear.  Uncertainty.  Doubt.  Compliance.  Ugh.  Rinse, later, repeat.

I'm not taking what you're proposing lightly, Richard, but the notion of agility, time to market, cost transformation and enhancing customer experience are being tossed out with the bathwater here. 

Believe it or not, we have to actually have a sustainable business in order to "secure" it. 

It's fine to be advocating Google Gears and all these other Web 2.0 applications and systems. There's one force in the universe that can slap all that down, and that's corporate lawyers. If you disagree, whom do you think has a greater influence on the CEO: the CTO or the corporate lawyer? When the lawyer is backed by stories of lost cases, fines, and maybe jail time, what hope does a CTO with plans for "agility" have?

But going back to one of your own mantras, if you bake security into your processes and SDLC in the first place, then the CEO/CTO/CIO and legal counsel will already have assessed the position the company has and balance the risk scorecard to ensure that they have exercised the appropriate due care in the first place. 

The uncertainty and horrors associated with the threat of punitive legal impacts have, are, and will always be there...and they will continue to be exploited by those in the security industry to buy more stuff and justify a paycheck.

Given the business we're in, it's not a surprise that the perspective presented is very, very siloed and focused on the potential "security" outcomes of what happens if we don't start centralizing data now; everything looks like a nail when you're a hammer.

However, you still didn't address the other two critical points I made previously:

1. The underlying technology associated with decentralization of data and applications is at complete odds with the "curl up in a fetal position and wait for the sky to fall" approach
2. The only reason we have security in the first place is to ensure survivability and availability of service -- and make sure that we stay in business.  That isn't really a technical issue at all, it's a business one.  I find it interesting that you referenced this issue as the CTO's problem and not the CIO.

As to your last point, I'm convinced that GE -- with the resources, money and time it has to bear on a problem -- can centralize its data and resources...they can probably get cold fusion out of a tuna fish can and a blow pop, but for the rest of us on planet Earth, we're going to have to struggle along trying to cram all the 'agility' and enablement we've just spent the last 10 years giving to users back into the compliance bottle.

/Hoff

Does Centralized Data Governance Equal Centralized Data?

I've been trying to construct a palette of blog entries over the last few months which communicates the need for a holistic network, host and data-centric approach to information security and information survivability architectures. 

I've been paying close attention to the dynamics of the DLP/CMF market/feature positioning as well as what's going on in enterprise information architecture with the continued emergence of WebX.0 and SOA.

That's why I found this Computerworld article written by Jay Cline very interesting as it focused on the need for a centralized data governance function within an organization in order to manage risk associated with coping with the information management lifecycle (which includes security and survivability.)  The article went on to also discuss how the roles within the organization, namely the CIO/CTO, will also evolve in parallel.

The three primary indicators for this evolution were summarized as:

1. Convergence of information risk functions
2. Escalating risk of information compliance
3. Fundamental role of information.

Nothing terribly earth-shattering here, but the exclamation point of this article to enable a
centralized data governance  organization is a (gasp!) tricky combination of people, process
and technology:

"How does this all add up? Let me connect the dots: Data must soon become centralized,
its use must be strictly controlled within legal parameters, and information must drive the
business model. Companies that don’t put a single, C-level person in charge of making
this happen will face two brutal realities: lawsuits driving up costs and eroding trust in the
company, and competitive upstarts stealing revenues through more nimble use of centralized
information."

Let's deconstruct this a little because I totally get the essence of what is proposed, but
there's the insertion of some realities that must be discussed.  Working backwards:

• I agree that data and it's use must be strictly controlled within legal parameters.
• I agree that a single, C-level person needs to be accountable for the data lifecycle
• However, I think that whilst I don't disagree that it would be fantastic to centralize data,
  I think it's a nice theory but the wrong universe. 

Interesting, Richard Bejtlich focused his response to the article on this very notion, but I can't get past a couple of issues, some of them technical and some of them business-related.

There's a confusing mish-mash alluded to in Richard's blog of "second home" data repositories that maintain copies of data that somehow also magically enforce data control and protection schemes outside of this repository while simultaneously allowing the flexibility of data creation "locally."  The competing themes for me is that centralization of data is really irrelevant -- it's convenient -- but what you really need is the (and you'll excuse the lazy use of a politically-charged term) "DRM" functionality to work irrespective of where it's created, stored, or used.

Centralized storage is good (and selfishly so for someone like Richard) for performing forensics and auditing, but it's not necessarily technically or fiscally efficient and doesn't necessarily align to an agile business model.

The timeframe for the evolution of this data centralization was not really established,
but we don't have the most difficult part licked yet -- the application of either the accompanying
metadata describing the information assets we wish to protect OR the ability to uniformly classify and
enforce it's creation, distribution, utilization and destruction.

Now we're supposed to also be able to magically centralize all our data, too?  I know that large organizations have embraced the notion of data warehousing, but it's not the underlying data stores I'm truly worried about, it's the combination of data from multiple silos within the data warehouses that concerns me and its distribution to multi-dimensional analytic consumers. 

You may be able to protect a DB's table, row, column or a file, but how do you apply a policy to a distributed ETL function across multiple datasets and paths?

ATAMO?  (And Then A Miracle Occurs) 

What I find intriguing about this article is that this so-described pendulum effect of data centralization (data warehousing, BI/DI) and resource centralization (data center virtualization, WAN optimization/caching, thin client computing) seem to be on a direct  collision course with the way in which applications and data are being distributed with  Web2.0/Service Oriented architectures and delivery underpinnings such as rich(er) client side technologies such as mash-ups and AJAX...

So what I don't get is how one balances centralizing data when today's emerging infrastructure
and information architectures are constructed to do just the opposite; distribute data, processing
and data re-use/transformation across the Enterprise?  We've already let the data genie out of the bottle and now we're trying to cram it back in?  (*please see below for a perfect illustration)

I ask this again within the scope of deploying a centralized data governance organization and its associated technology and processes within an agile business environment. 

/Hoff

P.S. I expect that a certain analyst friend of mine will be emailing me in T-Minus 10, 9...

*Here's a perfect illustration of the futility of centrally storing "data."  Click on the image and notice the second bullet item...:

Profiling Data At the Network-Layer and Controlling It's Movement Is a Bad Thing?

I've been watching what appears like a car crash in slow-motion and for some strange reason I share some affinity and/or responsibility for what is unfolding in the debate between Rory and Rob.

What motivated me to comment on this on-going exploration of data-centric security was Rory's last post in which he appears to refer to some points I raised in my original post but still bent on the idea that the crux of my concept was tied to DRM:

So .. am I anti-security? Nope I'm extremely pro-security. My feeling is however that the best way to implement security is in ways which it's invisable to users. Every time you make ordinary business people think about security (eg, usernames/passwords) they try their darndest to bypass those requirements.

That's fine and I agree.  The concept of ADAPT is completely transparent to "users."  This doesn't obviate the fact that someone will have to be responsible for characterizing what is important and relevant to the business in terms of "assets/data," attaching weight/value to them, and setting some policies regarding how to mitigate impact and ultimately risk.

Personally I'm a great fan of network segregation and defence in depth at the network layer. I think that devices like the ones crossbeam produce are very useful in coming up with risk profiles, on a network by network basis rather than a data basis and managing traffic in that way. The reason for this is that then the segregation and protections can be applied without the intervention of end-users and without them (hopefully) having to know about what security is in place.

So I think you're still missing my point.  The example I gave of the X-Series using ADAPT takes a combination of best-of-breed security software components such as FW, IDP, WAF, XML, AV, etc. and provides you with segregation as you describe.  HOWEVER, the (r)evolutionary delta here is that the ADAPT profiling of content set by policies which are invisible to the user at the network layer allows one to make security decisions on content in context and control how data moves.

So to use the phrase that I've seen in other blogs on this subject, I think that the "zones of trust" are a great idea, but the zone's shouldn't be based on the data that flows over them, but the user/machine that are used. It's the idea of tagging all that data with the right tags and controlling it's flow that bugs me.

...and thus it's obvious that I completely and utterly disagree with this statement.  Without tying some sort of identity (pseudonymity) to the user/machine AND combining it with identifying the channels (applications) and the content (payload) you simply cannot make an informed decision as to the legitimacy of the movement/delivery of this data.

I used the case of being able to utilize client-side tagging as an extension to ADAPT, NOT as a dependency.  Go back and re-read the post; it's a network-based transparent tagging process that attaches the tag to the traffic as it moves around the network.  I don't understand why that would bug you?

So that's where my points in the previous post came from, and I still reckon their correct. Data tagging and parsing relies on the existance of standards and their uptake in the first instance and then users *actually using them* and personally I think that's not going to happen in general companies and therefore is not the best place to be focusing security effort...

Please explain this to me?  What standards need to exist in order to tag data -- unless of course you're talking about the heterogeneous exchange and integration of tagging data at the client side across platforms?  Not so if you do it at the network layer WITHIN the context of the architecture I outlined; the clients, switches, routers, etc. don't need to know a thing about the process as it's done transparently.

I wasn't arguing that this is the end-all-be-all of data-centric security, but it's worth exploring without deadweighting it to the negative baggage of DRM and the existing DLP/Extrusion Prevention technologies and methodologies that currently exist.

ADAPT is doable and real; stay tuned.

/Hoff