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

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

For Data to Survive, It Must ADAPT...

Now that I've annoyed you by suggesting that network security will over time become irrelevant given lost visibility due to advances in OS protocol transport and operation, allow me to give you another nudge towards the edge and further reinforce my theories with some additionally practical data-centric security perspectives. 

If any form of network-centric security solution is to succeed in adding value over time, the mechanics of applying policy and effecting disposition on flows as they traverse the network must be made on content in context.  That means we must get to a point where we can make "security" decisions based upon information and its "value" and classification as it moves about.

It's not good enough to only make decisions on how flows/data should be characterized and acted on with the criteria being focused on the 5-tupule (header,) signature-driven profiling or even behavioral analysis that doesn't characterize the content in context of where it's coming from, where it's going and who (machine and "user") or what (application, service) intends to access and consume it. 

In the best of worlds, we like to be able to classify data before it makes its way though the IP stack and enters the network and use this metadata as an attached descriptor of the 'type' of content that this data represents.  We could do this as the data is created by applications (thick or thin, rich or basic) either using the application itself or by using an agent (client-side) that profiles the data prior to storage or transmission.

Since I'm on my Jericho Forum kick lately, here's how they describe how data ought to be controlled:

Access to data should be controlled by security attributes of the data itself.

• Attributes can be held within the data (DRM/Metadata) or could be a separate system.
• Access / security could be implemented by encryption.
• Some data may have “public, non-confidential” attributes.
• Access and access rights have a temporal component.

You would probably need client-side software to provide this functionality.  As an example, we do this today with email compliance solutions that have primitive versions of this sort of capability that force users to declare the classification of an email before you can hit the send button or even the document info that can be created when one authors a Word document. 

There are a bunch of ERM/DRM solutions in play today that are bandied about being sold as "compliance" solutions, but there value goes much deeper than that.  IP Leakage/Extrusion prevention systems (with or without client-side tie-ins) try to do similar things also.

Ideally, this metadata would be used as a fixed descriptor of the content that permanently attaches itself and follows that content around so it can be used to decide what content should be "routed" based upon policy.

If we're not able to use this file-oriented static metadata, we'd like then for the "network" (or something in/on it) to be able to dynamically profile content at wirespeed and characterize the data as it moves around the network from origin to destination in the same way.

So, this is where Applied Data & Application Policy Tagging (ADAPT) comes in.  ADAPT is an approach that uses some new technology to profile and characterize content (by using signatures, regular expressions and behavioral analysis in hardware) to then apply policy-driven traffic "routing" functionality as flows traverse the network by applying an ADAPT tag-header as a descriptor to each flow as it moves around the network.

The ADAPT tag could be fed by interpreting metadata attached to the data itself (if in file form) or dynamically by on-the-fly profiling.

Think of it like a VLAN tag the describes the data within the packet/flow.

This ADAPT tag is user defined and can use any taxonomy that best suits the types of content that is interesting; one might use asset classification such as "confidential" or uses taxonomies such as "HIPAA" or "PCI" to describe what is contained in the flows.  One could combine and/or stack the tags, too.

Then, as data moves across the network and across what we call boundaries (zones) of trust, the policy tags are parsed and disposition effected based upon the language governing the rules.

Just like an ACL for IP addresses of VLAN policies, ADAPT does the same thing for content routing.

To enable this sort of functionality, either every switch/router in the network would need to be ADAPT enabled (which would be difficult since you'd need every network vendor to support the protocols) OR you could use an overlay UTM security services switch sitting on top of the network plumbing through which all traffic moving from one zone to another would be subject to the ADAPT policy.

Since the only device that needs to be ADAPT aware is this UTM security service switch, you can let the network do what it does best and utilize this solution to enforce the policy for you across these boundary transitions.  Said UTM security service switch needs to have an extremely high-speed content security engine that is able to characterize the data at wirespeed and add a tag to the frame as it moves through the switching fabric and processed prior to popping out onto the network.

I'm going to be self-serving here and demonstrate this "theoretical" solution using a Crossbeam X80 UTM security services switch plumbed into a very fast, reliable, and resilient L2/L3 Cisco infrastructure.  It just so happens to have a wire-speed content security engine installed in it.  The reason the X-Series can do this is because once the flow enters its switching fabric, I own the ultimate packet/frame/cell format and can prepend any header functionality I like onto the structure to determine how it gets "routed."

Take the example below where the X80 is connected to the layer-3 switches using 802.1q VLAN trunked interfaces.  I've made this an intentionally simple network using VLANs and L3 routing; you could envision a much more complex segmentation and routing environment, obviously.

This network is chopped up into 4 VLAN segments:

1. General Clients (VLAN A)
2. Finance & Accounting Clients (VLAN B)
3. Financial Servers (VLAN C)
4. HR Servers (VLAN D)

Each of the clients/servers in the respective VLANs default routes out to an IP address which belongs to the firewall cluster IP addresses which is proffered by the firewall application modules providing service in the X80. 

Thus, to get from one VLAN to another VLAN, one must pass through the X80 and profiled by this content security engine and whatever additional UTM services are installed in the chassis (such as firewall, IDP, AV, etc.)

Let's say then that a user in VLAN A (General Clients) attempts to access one or more resources in the VLAN D (HR Servers.) 

Using solely IP addresses and/or L2 VLANs, let's say the firewall and IPS policies allow this behavior as the clients in that VLAN have a legitimate need to access the HR Intranet server.  However, let's say that this user tries to access data that exists on the HR Intranet server but contains personally identifiable information that falls under the governance/compliance mandates of HIPAA.

Let us further suggest that the ADAPT policy states the following:

Rule  Source                Destination            ADAPT Descriptor           Action
==============================================================

1        VLAN A             VLAN D                    HIPAA, Confidential        Deny
          IP.1.1               IP.3.1

2        VLAN B             VLAN C                    PCI                                 Allow
          IP.2.1             IP.4.1

Using rule 1 above, as the client makes the request, he transits from VLAN A to VLAN D.  The reply containing the requested information is profiled by the content security engine which is able to  characterize the data as containing information that matches our definition of either "HIPAA or Confidential" (purely arbitrary for the sake of this example.) 

This could be done by reading the metadata if it exists as an attachment to the content's file structure, in cooperation with an extrusion prevention application running in the chassis, or in the case of ad-hoc web-based applications/services, done dynamically.

According to the ADAPT policy above, this data would then be either silently dropped, depending upon what "deny" means, or perhaps the user would be redirected to a webpage that informs them of a policy violation.

Rule 2 above would allow authorized IP's in VLANs to access PCI-classified data.

You can imagine how one could integrate IAM and extend the policies to include pseudonymity/identity as a function of access, also.  Or, one could profile the requesting application (browser, for example) to define whether or not this is an authorized application.  You could extend the actions to lots of stuff, too.

Furthermore, assuming this service was deployed internally and you could establish a trusted CA with certs that would support transparent MITM SSL decrypts, you could do this (with appropriate scale) with encrypted traffic also.

This is data-centric security that uses the network when needed, the host when it can and the notion of both static and dynamic network-borne data classification to enforce policy in real-time.

/Hoff

[Comments/Blogs on this entry you might be interested in but have no trackbacks set:

MCWResearch Blog

Rob Newby's Blog

Alex Hutton's Blog

Security Retentive Blog