Rational Survivability

Security Will Not End Up In the Network...

It's not the destination, it's the journey, stupid.

You can't go a day without reading from the peanut gallery that it is "...inevitable that network security will eventually be subsumed into the network fabric."  I'm not picking on Rothman specifically, but he's been banging this drum loudly of late.

For such a far-reaching, profound and prophetic statement, claims like these are strangely myopic and inaccurate..and then they're exactly right.

Confused?

Firstly, it's sort of silly and obvious to trumpet that "network security" will end up in the "network."  Duh.  What's really meant is that "information security" will end up in the network, but that's sort of goofy, too. You'll even hear that "host-based security" will end up in the network...so let's just say that what's being angled at here is that security will end up in the network.

These statements are often framed within a temporal bracket that simply ignores the bigger picture and reads like a eulogy.  The reality is that historically we have come to accept that security and technology are cyclic and yet we continue to witness these terminal predictions defining an end state for security that has never arrived and never will.

Let me make plain my point: there is no final resting place for where and how security will "end up."

I'm visual, so let's reference a very basic representation of my point.  This graph represents the cyclic transition over time of where and how we invest in security.

We ultimately transition between host-based security, information-centric security and network security over time. 

We do this little shuffle based upon the effectiveness and maturity of technology, economics, cultural, societal and regulatory issues and the effects of disruptive innovation.  In reality, this isn't a smooth sine wave at all, it's actually more a classic dampened oscillation ala the punctuated equilibrium theory I've spoken about before, but it's easier to visualize this way.

Our investment strategy and where security is seen as being "positioned" reverses direction over time and continues ad infinitum.  This has proven itself time and time again yet we continue to be wowed by the prophetic utterances of people who on the one hand talk about these never-ending cycles and yet on the other pretend they don't exist by claiming the "death" of one approach over another. 
 

Why?

To answer that let's take a look at how the cyclic pendulum effect of our focus on security trends from the host to the information to the network and back again by analyzing the graph above. 

1. If we take a look at the arbitrary "starting" point indicated by the "You Are Here" dot on the sine wave above, I suggest that over the last 2-3 years or so we've actually headed away from the network as the source of all things security.   
   
   There are lots of reasons for this; economic, ideological, technological, regulatory and cultural.  If you want to learn more about this, check out my posts on how disruptive Innovation fuels strategic transience.
   
   In short, the network has not been able to (and never will) deliver the efficacy, capabilities or cost-effectiveness desired to secure us from evil, so instead we look at actually securing the information itself.  The security industry messaging of late is certainly bearing testimony to that fact.  Check out this year's RSA conference...
    
2. As we focus then on information centricity, we see the resurgence of ERM, governance and compliance come into focus.  As policies proliferate, we realize that this is really hard and we don't have effective and ubiquitous data classification, policy affinity and heterogeneous enforcement capabilities.  We shake our heads at the ineffectiveness of the technology we have and hear the cries of pundits everywhere that we need to focus on the things that really matter...
   
   In order to ensure that we effectively classify data at the point of creation, we recognize that we can't do this automagically and we don't have standardized schemas or metadata across structured and unstructured data, so we'll look at each other, scratch our heads and conclude that the applications and operating systems need modification to force fit policy, classification and enforcement.
   
   Rot roh.
    
3. Now that we have the concept of policies and classification, we need the teeth to ensure it, so we start to overlay emerging technology solutions on the host in applications and via the OS's that are unfortunately non-transparent and affect the users and their ability to get their work done.  This becomes labeled as a speed bump and we grapple with how to make this less impacting on the business since security has now slowed things down and we still have breaches because users have found creative ways of bypassing technology constraints in the name of agility and efficiency...
    
4. At this point, the network catches up in its ability to process closer to "line speed," and some of the data classification functionality from the host commoditizes into the "network" -- which by then is as much in the form of appliances as it is routers and switches -- and always will be.   So as we round this upturn focusing again on being "information centric," with the help of technology, we seek to use our network investment to offset impact on our users.
    
5. Ultimately, we get the latest round of "next generation" network solutions which promise to deliver us from our woes, but as we "pass go and collect $200" we realize we're really at the same point we were at point #1.

'Round and 'round we go.

So, there's no end state.  It's a continuum.  The budget and operational elements of who "owns" security and where it's implemented simply follow the same curve.  Throw in disruptive innovation such as virtualization, and the entire concept of the "host" and the "network" morphs and we simply realize that it's a shift in period on the same graph.

So all this pontification that it is "...inevitable that network security will eventually be subsumed into the network fabric" is only as accurate as what phase of the graph you reckon you're on.  Depending upon how many periods you've experienced, it's easy to see how some who have not seen these changes come and go could be fooled into not being able to see the forest for the trees.

Here's the reality we actually already know and should not come to you as a surprise if you've been reading my blog: we will always need a blended investment in technology, people and process in order to manage our risk effectively.  From a technology perspective, some of this will take the form of controls embedded in the information itself, some will come from the OS and applications and some will come from the network.

Anyone who tells you differently has something to sell you or simply needs a towel for the back of his or her ears...

/Hoff

GooglePOPs - Cloud Computing and Clean Pipes: Told Ya So...

In July of last year, I prognosticated that Google with it's various acquisitions was entering the security space with the intent to not just include it as a browser feature for search and the odd GoogleApp, but a revenue-generating service delivery differentiator using SaaS via applications and clean pipes delivery transit in the cloud for Enterprises.

My position even got picked up by thestreet.com.  By now it probably sounds like old news, but...

Specifically, in my post titled "Tell Me Again How Google Isn't Entering the Security Market? GooglePOPs will Bring Clean Pipes..." I argued (and was ultimately argued with) that Google's $625M purchase of Postini was just the beginning:

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.

Here's where we are almost a year later.  From the Ars Technica post titled "Google turns Postini into Google Web Security for Enterprise:"

The company's latest endeavor, Google Web Security for Enterprise, is now available, and promises to provide a consistent level of system security whether an end-user is surfing from the office or working at home halfway across town.

The new service is branded under Google's "Powered by Postini" product line and, according to the company, "provides real-time malware protection and URL filtering with policy enforcement and reporting. An additional feature extends the same protections to users working remotely on laptops in hotels, cafes, and even guest networks." The service is presumably activated by signing in directly to a Google service, as Google explicitly states that workers do not need access to a corporate network.

The race for cloud and secure utility computing continues with a focus on encapsulated browsing and application delivery environments, regardless of transport/ISP, starting to take shape.   

Just think about the traditional model of our enterprise and how we access our resources today turned inside out as a natural progression of re-perimeterization.  It starts to play out on the other end of the information centricity spectrum.

What with the many new companies entering this space and the likes of Google, Microsoft and IBM banging the drum, it's going to be one interesting ride.

/Hoff

Of Course Defense-In-Depth, er, Defense-In-Breadth Works!

I don't know what the the hell Ptacek and crew are on about.  Of course defense-in-depth defense-in-breadth is effective.  It's heresy to suggest otherwise.  Myopic, short-sighted, and heretical, I say!

In support, I submit into evidence People's Exhibit #1, from here your honor:

...and I quoteth:

We use layers of security to ensure the security of the traveling public and the Nation's transportation system.

Each one of these layers alone is capable of stopping a terrorist attack. In combination their security value is multiplied, creating a much stronger, formidable system.  A terrorist who has to overcome multiple security layers in order to carry out an attack is more likely to be pre-empted, deterred, or to fail during the attempt.

Yeah!  Get some! It's just like firewalls, IPS, and AV, bitches!  Mo' is betta!

It's patently clear that Ptacek simply doesn't layer enough, is all.  See, Rothman, you don't need to give up!

"Twenty is the number and the number shall be twenty!"

How's that for a metric?

That is all.

/Hoff

Asset Focused, Not Auditor Focused

Gunnar Peterson wrote a great piece the other day on the latest productization craze in InfoSec - GRC (Governance, Risk Management and Compliance) wherein he asks "GRC - To Be or To Do?"

I don't really recall when or from whence GRC sprung up as an allegedly legitimate offering, but to me it seems like a fashionably over-sized rug under which the existing failures of companies to effectively execute on the individual G, R, and C initiatives are conveniently being swept.

I suppose the logic goes something like this: "If you cant effectively govern, manage risk or measure compliance it must be because what you're doing is fragmented and siloed.  What you need is a product/framework/methodology that takes potentially digestible deliverables and perspectives and "evolves" them into a behemoth suite instead?"

I do not dispute that throughout most enterprises, the definitions, approaches and processes in managing each function are largely siloed and fragmented and I see the attractiveness of integrating and standardizing them, but  I am unconvinced that re-badging a control and policy framework collection constitutes a radical new approach. 

GRC appears to be a way to sell more products and services under a fancy new name to address problems rather than evaluate and potentially change the way in which we solve them.  Look at who's pushing this: large software companies and consultants as well as analysts looking to pin their research to something more meaningful.

From a first blush, GRC isn't really about governance or managing risk.  It's audit-driven compliance all tarted up.

It's a more fashionable way of getting all your various framework and control definitions in one place and appealing to an auditor's desire for centralized "stuff" in order to document the effectiveness of controls and track findings against some benchmark.  I'm not really sure where the business-driven focus comes into play?

It's also sold as a more efficient way of reducing the scope and costs of manual process controls.  Fine.  Can't argue with that.  I might even say it's helpful, but at what cost?

Gunnar said:

GRC (or Governance, Risk Management, and Compliance for the uninitiated) is all the rage, but I have to say I think that again Infosec has the wrong focus.

Instead of Risk Management helping to deliver transparent Governance and as a natural by-product demonstrate compliance as a function of the former, the model's up-ended with compliance driving the inputs and being mislabeled.

As I think about it, I'm not sure GRC would be something a typical InfoSec function would purchase or use unless forced which is part of the problem.  I see internal audit driving the adoption which given today's pressures (especially in public companies) would first start in establishing gaps against regulatory compliance.

If the InfoSec function is considering an approach that drives protecting the things that matter most and managing risk to an acceptable level and one that is not compliance-driven but rather built upon a business and asset-driven approach, rather than make a left turn Gunnar suggested:

Personally, I am happy sticking to classic infosec knitting - delivering confidentiality, integrity, and availability through authentication, authorization, and auditing. But if you are looking for a next generation conceptual horse to bet on, I don't think GRC is it, I would look at information survivability. Hoff's information survivability primer is a great starting point for learning about survivability.

Why survivability is more valuable over the long haul than GRC is that survivability is focused on assets not focused on giving an auditor what they need, but giving the business what it needs.

Seminal paper on survivability by Lipson, et al. "survivability solutions are best understood as risk management strategies that first depend on an intimate knowledge of the mission being protected." Make a difference - asset focus, not auditor focus.

For obvious reasons, I am compelled to say "me, too."

I would really like to talk to someone in a large enterprise who is using one of these GRC suites -- I don't really care which department you're from.  I just want to examine my assertions and compare them against my efforts and understanding.

/Hoff

Welcome To the Information Survivability/Sustainability/Centricity Circus...

Forget "Security Theater."  The "Security Circus" is in town...

I wrote this some time ago and decided that I didn't like the tone as it just came out as another whiny complaint against the "man."  I'm in a funny mood as I hit a threshold yesterday with all the so-called experts coming out of the woodwork lately, so I figured I'd post it because it made me chortle. 

They Shoot Horses, Don't They?

To answer what seems to be a question increasing in frequency due to the surge in my blog's readership lately, as well as being cycled through the gossip mill, I did not change the name of my blog from "Rational Security" to "Rational Survivability" due to IBM's Val Rahmani's charming advertisement keynote at RSA.  ;)

One might suggest that Val's use of the mythological reference to Sisyphus wasn't as entertaining as Noonan's "security as the width of two horses' asses" keynote from a couple of years ago, but her punchline served to illustrate the sad state of Information Security, even if it also wanted to make me shoot myself.

Val's shocking admission that IBM was "...exiting the security business," that "...information security was dead," and that we should all celebrate by chanting "...long live [information] sustainability!" 

This caused those of us here at Rational Survivability HQ to bow our heads in a moment of silence for the passing of yet another topical meme and catchphrase that has now been "legitimized" by industry and thus must be put out of its misery and never used again.

You say "tomato," I say "tomato..."

Yeah, you might argue that "sustainability" is more business-focused and less military-sounding than "survivability," but it's really about the same concepts. 

I'm not going to dissect her speech because that's been done.  I have said most of what I have to say on this concept in my posts on Information Survivability and honestly, I think they are as relevant as ever. 

You can read the first one here and follow on with the some more, here. 

For those of you who weren't around when it happened, I changed the name of my blog over six months ago to illustrate what is akin to the security industry's equivalent of an introduction at an AA meeting and was so perfectly illustrated by Val's fireside chat. 

You know the scene.  It's where an alcoholic stands up and admits his or her weaknesses for a vice amongst an audience of current and "former" addicts.  Hoping for a collective understanding of one's failure and declaring the observed days of committed sobriety to date,  the goal is to convince oneself and those around you that the counter's been reset and you've really changed.  Despite the possibility of relapse at any moment, the declaration of intent -- the will to live sober -- is all one needs.

That and a damned good sponsor.

And now for something completely different!

That was a bloody depressing analogy, wasn't it?  Since this was supposed to be a happy occasion, I found myself challenged to divine an even worse analogy for your viewing pleasure.   Here goes.

That's right.  I'm going to violate the Prime Directive and go right with the patented Analog Of Barnum & Bailey's Circus:

What Information Security has become is the equivalent of a carnie's dancing poodle in the circus tent of industry. 

Secretly we want to see the tigers eat the dude with the whip, but we cheer when he makes them do the Macarena anyway. 

We all know that one day, that little Romanian kid on the trapeze is going to miss the triple-lindy and crash to the floor sans net, but we're not willing to do anything about it and it's the tension that makes the act work, despite the exploitative child labor practices and horrible costumes.

We pump $180 in tokens into the ring toss to win an $11 stuffed animal, because it's the effort that counts, not the price.

We're all buying tickets, suffering through the stupid antics of the clowns piling out of the tiny little car in the spotlight hoping that the elephant act at the end of the show is going to be worth the price of admission. 

At the end of the night, we leave exhausted, disappointed, broke and smelling like sweaty caramel apples and stale pretzels...wondering when they'll be back next year so we can take the kids.

See, I told you it was awful.  But you know what's much worse than my shitty little clown analogy? 

Reality.

Come one, come all.  Let Me Guess Your Weight!

So in today's time of crappy economics when money is hard to come by, it's now as consumers that we start to pay attention to these practices -- this circus.  It's now that we start to demand that these alleged predatory vendors actually solve our business problems and attend to our issues rather than simply recycle the packaging.

So when life hands vendors a lemon, they make marketingade, charge us $4.50 a pop and we still drink it.

Along those lines, many mainstream players have now begun to work their marketing sideshows by pitching the supposedly novel themes of sustainability, survivability, or information centricity.  It's a surreptitiously repentant admission that all the peanuts and popcorn they've been selling us while all along we ooh and ahh at the product equivalents of the bearded lady, werewolf children and the world's tallest man still climax at the realization that it's all just an act.

At the end of the night, they count their money, tear down the tents and move on.  When the bearded lady gets a better gig, she bails and they bring in the dude with the longest mustache.  Hey, hair is hair; it's just packaged differently, and we go to ogle at the newest attraction.

There's no real punchline here folks, just the jaded, bitter and annoyed comments of someone who's becoming more and more like the grumpy folks he always made fun of at bingo night and a stark realization of just how much I hate the circus.

/Hoff

Endpoint Security vs. DLP? That's Part Of the Problem...

Larry Walsh wrote something (Defining the Difference Between Endpoint Security and Data Loss Prevention) that sparked an interesting debate based upon a vendor presentation given to him on "endpoint security" by SanDisk.

SanDisk is bringing to market a set of high-capacity USB flash drives that feature built-in filesystem encryption as well as strong authentication and access control.  If the device gets lost with the data on it, it's "safe and secure" because it's encrypted.  They are positioning this as an "endpoint security" solution.

I'm not going to debate the merits/downsides of that approach because I haven't seen their pitch, but suffice it to say, I think it's missing a "couple" of pieces to solve anything other than a very specific set of business problems.

Larry's dilemma stems from the fact that he maintains that this capability and functionality is really about data loss protection and doesn't have much to do with "endpoint security" at all:

We debated that in my office for a few minutes. From my perspective, this solution seems more like a data loss prevention solution than endpoint security. Admittedly, there are many flavors of endpoint security. When I think of endpoint security, I think of network access control (NAC), configuration management, vulnerability management and security policy enforcement. While this solution is designed for the endpoint client, it doesn't do any of the above tasks. Rather, it forces users to use one type of portable media and transparently applies security protection to the data. To me, that's DLP.

In today's market taxonomy, I would agree with Larry.  However, what Larry is struggling with is not really the current state of DLP versus "endpoint security," but rather the future state of converged information-centric governance.  He's describing the problem that will drive the solution as well as the inevitable market consolidation to follow.

This is actually the whole reason Mogull and I are talking about the evolution of DLP as it exists today to a converged solution we call CMMP -- Content Management, Monitoring and Protection. {Yes, I just added another M for Management in there...}

What CMMP represents is the evolved and converged end-state technology integration of solutions that today provide a point solution but "tomorrow" will be combined/converged into a larger suite of services.

Off the cuff, I'd expect that we will see at a minimum the following technologies being integrated to deliver CMMP as a pervasive function across the information lifecycle and across platforms in flight/motion and at rest:

• Data leakage/loss protection (DLP)
• Identity and access management (IAM)
• Network Admission/Access Control (NAC)
• Digital rights/Enterprise rights management (DRM/ERM)
• Seamless encryption based upon "communities of interest"
• Information classification and profiling
• Metadata
• Deep Packet Inspection (DPI)
• Vulnerability Management
• Configuration Management
• Database Activity Monitoring (DAM)
• Application and Database Monitoring and Protection (ADMP)
• etc...

That's not to say they'll all end up as a single software install or network appliance, but rather a consolidated family of solutions from a few top-tier vendors who have coverage across the application, host and network space. 

If you were to look at any enterprise today struggling with this problem, they likely have or are planning to have most of the point solutions above anyway.  The difficulty is that they're all from different vendors.  In the future, we'll see larger suites from fewer vendors providing a more cohesive solution.

This really gives us the "cross domain information protection" that Rich talks about.

We may never achieve the end-state described above in its entirety, but it's safe to say that the more we focus on the "endpoint" rather than the "information on the endpoint," the bigger the problem we will have.

/Hoff

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

A Worm By Any Other Name Is...An Information Epidemic?

Martin McKeay took exception to some interesting Microsoft research that suggested that the similar methodologies and tactics used by malicious software such as worms/viri, could also be used as an effective distributed defense against them:

Microsoft researchers are hoping to use "information epidemics" to distribute software patches more efficiently.

Milan Vojnović and colleagues from Microsoft Research in Cambridge, UK, want to make useful pieces of information such as software updates behave more like computer worms: spreading between computers instead of being downloaded from central servers.

The research may also help defend against malicious types of worm, the researchers say.

Software worms spread by self-replicating. After infecting one computer they probe others to find new hosts. Most existing worms randomly probe computers when looking for new hosts to infect, but that is inefficient, says Vojnović, because they waste time exploring groups or "subnets" of computers that contain few uninfected hosts.

Despite the really cool moniker (information epidemic,) this isn't a particularly novel distribution approach and in fact, we've seen malware do this.  However, it is interesting to see that an OS vendor (Microsoft) is continuing to actively engage in research to explore this approach despite the opinions of others who simply claim it's a bad idea.  I'm not convinced either way, however.

I, for one, am all for resilient computing environments that are aware of their vulnerabilities and can actively defend against them.  I will be interested to see how this new paper builds off of work previously produced on the subject and its corresponding criticism.

Vojnović's team have designed smarter strategies that can exploit the way some subnets provide richer pickings than others.

The ideal approach uses prior knowledge of the way uninfected computers are spread across different subnets. A worm with that information can focus its attention on the most fruitful subnets – infecting a given proportion of a network using the smallest possible number of probes.

But although prior knowledge could be available in some cases – a company distributing a patch after a previous worm attack, for example – usually such perfect information will not be available. So the researchers have also developed strategies that mean the worms can learn from experience.

In the best of these, a worm starts by randomly contacting potential new hosts. After finding one, it uses a more targeted approach, contacting only other computers in the same subnet. If the worm finds plenty of uninfected hosts there, it keeps spreading in that subnet, but if not, it changes tack.

That being the case, here's some of Martin's heartburn:

But the problem is, if both beneficial and malign software show the same basic behavior patterns, how do you differentiate between the two? And what’s to stop the worm from being mutated once it’s started, since bad guys will be able to capture the worms and possibly subverting their programs.

The article isn’t clear on how the worms will secure their network, but I don’t believe this is the best way to solve the problem that’s being expressed. The problem being solved here appears to be one of network traffic spikes caused by the download of patches. We already have a widely used protocols that solve this problem, bittorrents and P2P programs. So why create a potentially hazardous situation using worms when a better solution already exists. Yes, torrents can be subverted too, but these are problems that we’re a lot closer to solving than what’s being suggested.

I don’t want something that’s viral infecting my computer, whether it’s for my benefit or not. The behavior isn’t something to be encouraged. Maybe there’s a whole lot more to the paper, which hasn’t been released yet, but I’m not comfortable with the basic idea being suggested. Worm wars are not the way to secure the network.

I think that some of the points that Martin raises are valid, but I also think that he's reacting mostly out of fear to the word 'worm.'  What if we called it "distributed autonomic shielding?" ;)

Some features/functions of our defensive portfolio are going to need to become more self-organizing, autonomic and intelligent and that goes for the distribution of intelligence and disposition, also.  If we're not going to advocate being offensive, then we should at least be offensively defensive.  This is one way of potentially doing this.

Interestingly, this dovetails into some discussions we've had recently with Andy Jaquith and Amrit Williams; the notion of herds or biotic propagation and response are really quite fascinating.  See my post titled "Thinning the Herd & Chlorinating the Gene Pool"

I've left out most of the juicy bits of the story so you should go read it and churn on some of the very interesting points raised as part of the discussion.

/Hoff

Update: Schneier thinks this is a lousy idea. That doesn't move me one direction or the other, but I think this is cementing my opinion that had the author not used the word 'worm' in his analog the idea might not be dismissed so quickly...

Also, Wismer via a comment on Martin's blog pointed to an interesting read from Vesselin Bontchev titled "Are "Good" Computer Viruses Still a Bad Idea?"

Update #2: See the comments section about how I think the use case argued by Schneier et. al. is, um, slightly missing the point.  Strangely enough, check out the Network World article that just popped up which says ""This was not the primary scenario targeted for this research," according to a statement."

Duh.

Security Today == Shooting Arrows Through Sunroofs of Cars?

In this Dark Reading post, Peter Tippett, described as the inventor of what is now Norton Anti-virus, suggests that the bulk of InfoSec practices are "...outmoded or outdated concepts that don't apply to today's computing environments."

As I read through this piece, I found myself flip-flopping between violent agreement and incredulous eye-rolling from one paragraph to the next, caused somewhat by the overuse of hyperbole in some of his analogies.  This was disappointing, but overall, I enjoyed the piece.

Let's take a look at Peter's comments:

For example, today's security industry focuses way too much time on vulnerability research, testing, and patching, Tippett suggested. "Only 3 percent of the vulnerabilities that are discovered are ever exploited," he said. "Yet there is huge amount of attention given to vulnerability disclosure, patch management, and so forth."

I'd agree that the "industry" certainly focuses their efforts on these activities, but that's exactly the mission of the "industry" that he helped create.  We, as consumers of security kit, have perpetuated a supply-driven demand security economy.

There's a huge amount of attention paid to vulnerabilities, patching and prevention that doesn't prevent because at this point, that's all we've got.  Until we start focusing on the the root cause rather than the symptoms, this is a cycle we won't break.  See my post titled "Sacred Cows, Meatloaf, and Solving the Wrong Problems" for an example of what I mean.

Tippett compared vulnerability research with automobile safety research. "If I sat up in a window of a building, I might find that I could shoot an arrow through the sunroof of a Ford and kill the driver," he said. "It isn't very likely, but it's possible.

"If I disclose that vulnerability, shouldn't the automaker put in some sort of arrow deflection device to patch the problem? And then other researchers may find similar vulnerabilities in other makes and models," Tippett continued. "And because it's potentially fatal to the driver, I rate it as 'critical.' There's a lot of attention and effort there, but it isn't really helping auto safety very much."

What this really means and Peter doesn't really ever state, is that mitigating vulnerabilities in the absence of threat, impact or probability is a bad thing.  This is why I make such a fuss about managing risk instead of mitigating vulnerabilities.  If there were millions of malicious archers firing arrows through the sunroofs of unsuspecting Ford Escort drivers, then the 'critical' rating is relevant given the probability and impact of all those slings and arrows of thine enemies...

Tippett also suggested that many security pros waste time trying to buy or invent defenses that are 100 percent secure. "If a product can be cracked, it's sometimes thrown out and considered useless," he observed. "But automobile seatbelts only prevent fatalities about 50 percent of the time. Are they worthless? Security products don't have to be perfect to be helpful in your defense."

I like his analogy and the point he's trying to underscore.  What I find in many cases is that the binary evaluation of security efficacy -- in products and programs -- still exists.  In the absence of measuring the effective impact that something has in effecting one's risk posture, people revert to a non-gradient scale of 0% or 100% insecure or secure.  Is being "secure" really important or is managing to a level of risk that is acceptable -- with or without losses -- the really relevant measure of success?   

This concept also applies to security processes, Tippett said. "There's a notion out there that if I do certain processes flawlessly, such as vulnerability patching or updating my antivirus software, that my organization will be more secure. But studies have shown that there isn't necessarily a direct correlation between doing these processes well and the frequency or infrequency of security incidents.

"You can't always improve the security of something by doing it better," Tippett said. "If we made seatbelts out of titanium instead of nylon, they'd be a lot stronger. But there's no evidence to suggest that they'd really help improve passenger safety."

I would like to see these studies.  I think that companies who have rigorous, mature and transparent processes that they execute "flawlessly" may not be more "secure," (a measurement I'd love to see quantified) but are in a much better position to respond and recover when (not if) an event occurs.  Based upon the established corollary that we can't be 100% "secure" in the first place, we then know we're going to have incidents.

Being able to recover from them or continue to operate while under duress is more realistic and important in my view.  That's the point of information survivability.

Security teams need to rethink the way they spend their time, focusing on efforts that could potentially pay higher security dividends, Tippett suggested. "For example, only 8 percent of companies have enabled their routers to do 'default deny' on inbound traffic," he said. "Even fewer do it on outbound traffic. That's an example of a simple effort that could pay high dividends if more companies took the time to do it."

I agree.  Focusing on efforts that eliminate entire classes of problems based upon reducing risk is a more appropriate use of time, money and resources.

Security awareness programs also offer a high rate of return, Tippett said. "Employee training sometimes gets a bad rap because it doesn't alter the behavior of every employee who takes it," he said. "But if I can reduce the number of security incidents by 30 percent through a $10,000 security awareness program, doesn't that make more sense than spending $1 million on an antivirus upgrade that only reduces incidents by 2 percent?"

Nod.  That was the point of the portfolio evaluation process I gave in my disruptive innovation presentation:

24. Provide Transparency in portfolio effectiveness

I didn't invent this graph, but it's one of my favorite ways of visualizing my investment portfolio by measuring in three dimensions: business impact, security impact and monetized investment.  All of these definitions are subjective within your organization (as well as how you might measure them.)

The Y-axis represents the "security impact" that the solution provides.  The X-axis represents the "business impact" that the solution provides while the size of the dot represents the capex/opex investment made in the solution.

Each of the dots represents a specific solution in the portfolio.

If you have a solution that is a large dot toward the bottom-left of the graph, one has to question the reason for continued investment since it provides little in the way of perceived security and business value with high cost.   On the flipside, if a solution is represented by a small dot in the upper-right, the bang for the buck is high as is the impact it has on the organization.

The goal would be to get as many of your investments in your portfolio from the bottom-left to the top-right with the smallest dots possible.

This transparency and the process by which the portfolio is assessed is delivered as an output of the strategic innovation framework which is really comprised of part art and part science.

All in all, a good read from someone who helped create the monster and is now calling it ugly...

/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

Thinning the Herd & Chlorinating the Malware Gene Pool...

Alan Shimel pointed us to an interesting article written by Matt Hines in his post here regarding the "herd intelligence" approach toward security.  He followed it up here. 

All in all, I think both the original article that Andy Jaquith was quoted in as well as Alan's interpretations shed an interesting light on a problem solving perspective.

I've got a couple of comments on Matt and Alan's scribbles.

I like the notion of swarms/herds.  The picture to the right from Science News describes the notion of "rapid response," wherein "mathematical modeling is explaining how a school of fish can quickly change shape in reaction to a predator."  If you've ever seen this in the wild or even in film, it's an incredible thing to see in action.

It should then come as no surprise that I think that trying to solve the "security problem" is more efficiently performed (assuming one preserves the current construct of detection and prevention mechanisms) by distributing both functions and coordinating activity as part of an intelligent "groupthink" even when executed locally.  This is exactly what I was getting at in my "useful predictions" post for 2008:

Grid and distributed utility computing models will start to creep into security
A really interesting by-product of the "cloud compute" model is that as data, storage, networking, processing, etc. get distributed, so shall security.  In the grid model, one doesn't care where the actions take place so long as service levels are met and the experiential and business requirements are delivered.  Security should be thought of in exactly the same way. 

The notion that you can point to a physical box and say it performs function 'X' is so last Tuesday. Virtualization already tells us this.  So, imagine if your security processing isn't performed by a monolithic appliance but instead is contributed to in a self-organizing fashion wherein the entire ecosystem (network, hosts, platforms, etc.) all contribute in the identification of threats and vulnerabilities as well as function to contain, quarantine and remediate policy exceptions.

Sort of sounds like that "self-defending network" schpiel, but not focused on the network and with common telemetry and distributed processing of the problem.
Check out Red Lambda's cGrid technology for an interesting view of this model.

This basically means that we should distribute the sampling, detection and prevention functions across the entire networked ecosystem, not just to dedicated security appliances; each of the end nodes should communicate using a standard signaling and telemetry protocol so that common threat, vulnerability and effective disposition can be communicated up and downstream to one another and one or more management facilities.

This is what Andy was referring to when he said:

As part of the effort, security vendors may also need to begin sharing more of that information with their rivals to create a larger network effect for thwarting malware on a global basis, according to the expert.

It may be hard to convince rival vendors to work together because of the perception that it could lessen differentiation between their respective products and services, but if the process clearly aids on the process of quelling the rising tide of new malware strains, the software makers may have little choice other than to partner, he said.

Secondly, Andy suggested that basically every end-node would effectively become its own honeypot:

"By turning every endpoint into a malware collector, the herd network effectively turns into a giant honeypot that can see more than existing monitoring networks," said Jaquith. "Scale enables the herd to counter malware authors' strategy of spraying huge volumes of unique malware samples with, in essence, an Internet-sized sensor network."

I couldn't agree more!  This is the sort of thing that I was getting at back in August when I was chatting with Lance Spitzner regarding using VM's for honeypots on distributed end nodes:

I clarified that what I meant was actually integrating a HoneyPot running in a VM on a production host as part of a standardized deployment model for virtualized environments.  I suggested that this would integrate into the data collection and analysis models the same was as a "regular" physical HoneyPot machine, but could utilize some of the capabilities built into the VMM/HV's vSwitch to actually make the virtualization of a single HoneyPot across an entire collection of VM's on a single physical host.

Thirdly, the notion of information sharing across customers has been implemented cross-sectionally in industry verticals with the advent of the ISAC's such as the Financial Services Information Sharing and Analysis Center which seeks to inform and ultimately leverage distributed information gathering and sharing to protect it's subscribing members.  Generally-available services like Symantec's DeepSight have also tried to accomplish similar goals.

Unfortunately, these offerings generally lack the capacity to garner ubiquitous data gathering and real-time enforcement capabilities.

As Matt pointed out in his article, gaining actionable intelligence on the monstrous amount of telemetric data from participating end nodes means that there is a need to really prune for false positives.  This is the trade-off between simply collecting data and actually applying intelligence at the end-node and effecting disposition. 

This requires technology that we're starting to see emerge with a small enough footprint when paired with the compute power we have in endpoints today. 

Finally, as the "network" (which means the infrastructure as well as the "extrastructure" delivered by services in the cloud) gains more intelligence and information-centric granularity, it will pick up some of the slack -- at least from the perspective of sloughing off the low-hanging fruit by using similar concepts.

I am hopeful that as we gain more information-centric footholds, we shouldn't actually be worried about responding to every threat but rather only those that might impact the most important assets we seek to protect. 

Ultimately the end-node is really irrelevant from a protection perspective as it should really be little more than a presentation facility; the information is what matters.  As we continue to make progress toward more resilient operating systems leveraging encryption and mutual authentication within communities of interest/trust, we'll start to become more resilient and information assured.

The sharing of telemetry to allow these detective and preventative/protective capabilities to self-organize and perform intelligent offensive/evasive actions will evolve naturally as part of this process.

Mooooooo.

/Hoff

The Seesaw CISO...Changing Places But Similar Faces...

...from geek to business speak...

Dennis Fisher has nice writeup over at the SearchSecurity Security Bytes Blog about the changing role and reporting structure of the CISO.

Specifically, Dennis notes that he was surprised by the number of CISOs who recently told him that they no longer report to the CIO and aren't a part of IT at all.  Moreover, these same CISOs noted that the skillset and focus is also changing from a technical to a business role:

In the last few months I’ve been hearing more and more from CEOs, CIOs and CSOs about the changing role of the CSO (or CISO, depending on your org chart) in the enterprise. In the past, the CSO has nearly always been a technically minded person who has risen through the IT ranks and then made the jump to the executive ranks. That lineage sometimes got in the way when it came time to deal with other upper managers who typically had little or no technical knowledge and weren’t interested in the minutiae of authentication schemes, NAC and unified threat management. They simply wanted things to work and to avoid seeing the company’s name in the papers for a security breach.

But that seems to be changing rather rapidly. Last month I was on a panel in Chicago with Howard Schmidt, Lloyd Hession, the CSO of BT Radianz, and Bill Santille, CIO of Uline, and the conversation quickly turned to the ways in which the increased focus on risk management in enterprises has forced CSOs to adapt and expand their skill sets. A knowledge of IDS, firewalls and PKI is not nearly enough these days, and in some cases is not even required to be a CSO. One member of the audience said that the CSO position in his company is rotated regularly among senior managers, most of whom have no technical background and are supported by a senior IT staff member who serves as CISO. The CSO slot is seen as a necessary stop on the management circuit, in other words. Several other CSOs in the audience said that they no longer report to the CIO and are not even part of the IT organization. Instead, they report to the CFO, the chief legal counsel, or in one case, the ethics officer.

I've talked about the fact that "security" should be a business function and not a technical one and quite frankly what Dennis is hearing has been a trend on the uptick for the last 3-4 years as "information security" becomes less relevant and managing risk becomes the focus.  To wit:

The number of organizations making this kind of change surprised me at the time. But, in thinking more about it, it makes a lot of sense, given that the daily technical security tasks are handled by people well below the CSO’s office. And many of the CSOs I know say they spend most of their time these days dealing with policy issues such as regulatory compliance. Patrick Conte, the CEO of software maker Agiliance, which put on the panel, told me that these comments fit with what he was hearing from his customers, as well. Some of this shift is clearly attributable to the changing priorities inside these enterprises. But some of it also is a result of the maturation of the security industry as a whole, which has translated into less of a focus on technology and more attention being paid to policies, procedures and other non-technical matters.

How this plays out in the coming months and years will be quite interesting. My guess is that as security continues to be absorbed into the larger IT and operations functions, the CSO’s job will continue to morph into more of a business role.

I still maintain that "compliance" is nothing more than a gap-filler.  As I said here, we have compliance as an industry [and measurement] today because we manage technology threats and vulnerabilities and don't manage risk.  Compliance is actually nothing more than a way of forcing transparency and plugging a gap between the two.  For most, it's the best they've got.

Once organizationally we've got our act together, compliance will become the floor, not the ceiling and we'll really start to see the "...maturation of the security industry as a whole."

/Hoff

And Now Some Useful 2008 Information Survivability Predictions...

So, after the obligatory dispatch of gloom and doom as described in my 2008 (in)Security Predictions, I'm actually going to highlight some of the more useful things in the realm of Information Security that I think are emerging as we round the corner toward next year.

They're not really so much predictions as rather some things to watch.

Unlike folks who can only seem to talk about desperation, futility and manifest destiny or (worse yet) "anti-pundit pundits" who try to suggest that predictions and forecasting are useless (usually because they suck at it,) I gladly offer a practical roundup of impending development, innovation and some incremental evolution for your enjoyment. 

You know, good news.

As Mogull mentioned, I don't require a Cray XMP48, chicken bones & voodoo or a prehensile tail to make my picks.  Rather I grab a nice cold glass of Vitamin G (Guiness) and sit down and think for a minute or two, dwelling on my super l33t powers of common sense and pragmatism with just a pinch of futurist wit.

Many of these items have been underway for some time, but 2008 will be a banner year for these topics as well as the previously-described "opportunities for improvement..."

That said, let's roll with some of the goodness we can look forward to in the coming year.  This is not an exhaustive list by any means, but some examples I thought were important and interesting:

1. More robust virtualization security toolsets with more native hypervisor/vmm accessibility
   Though it didn't start with the notion of security baked in, virtualization for all of its rush-to-production bravado will actually yield some interesting security solutions that help tackle some very serious challenges.  As the hypervisors become thinner, we're going to see the management and security toolsets gain increased access to the guts of the sausage machine in order to effect security appropriately and this will be the year we see the virtual switch open up to third parties and more robust APIs for security visibility and disposition appear.
    
2. The focus on information centric security survivability graduates from v1.0 to v1.1
   Trying to secure the network and the endpoint is like herding cats and folks are tired of dumping precious effort on deploying kitty litter around the Enterprise to soak up the stinky spots.  Rather, we're going to see folks really start to pay attention to information classification, extensible and portable policy definition, cradle-to-grave lifecycle management, and invest in technology to help get them there.
   
   Interestingly the current maturity of features/functions such as NAC and DLP have actually helped us get closer to managing our information and information-related risks.  The next generation of these offerings in combination with many of the other elements I describe herein and their consolidation into the larger landscape of management suites will actually start to deliver on the promise of focusing on what matters -- the information.
    
3. Robust Role-based policy, Identity and access management coupled with entitlement, geo-location and federation...oh and infrastructure, too!
   We're getting closer to being able to affect policy not only based upon just source/destination IP address, switch and router topology and the odd entry in active directory on a per-application basis, but rather holistically based upon robust lifecycle-focused role-based policy engines that allow us to tie in all of the major enterprise components that sit along the information supply-chain.
   
   Who, what, where, when, how and ultimately why will be the decision points considered with the next generation of solutions in this space. Combine the advancements here with item #2 above, and someone might actually start smiling.
   
   If you need any evidence of the convergence/collision of the application-oriented with the network-oriented approach and a healthy overlay of user entitlement provisioning, just look at the about-face Cisco just made regarding TrustSec.  Of course, we all know that it's not a *real* security concern/market until Cisco announces they've created the solution for it ;)
    
4. Next Generation Networks gain visibility as they redefine the compute model of today
   Just as there exists a Moore's curve for computing, there exists an overlapping version for networking, it just moves slower given the footprint.  We're seeing the slope of this curve starting to trend up this coming year, and it's much more than bigger pipes, although that doesn't hurt either...
   
   These next generation networks will really start to emerge visibly in the next year as the existing networking models start to stretch the capabilities and capacities of existing architecture and new paradigms drive requirements that dictate a much more modular, scalable, resilient, high-performance, secure and open transport upon which to build distributed service layers.
   
   How networks and service layers are designed, composed, provisioned, deployed and managed -- and how that intersects with virtualization and grid/utility computing -- will start to really sink home the message that "in the cloud" computing has arrived.  Expect service providers and very large enterprises to adapt these new computing climates first with a trickle-down to smaller business via SaaS and hosted service operators to follow.
   
   BT's 21CN (21st Century Network) is a fantastic example of what we can expect from NGN as the demand for higher speed, more secure, more resilient and more extensible interconnectivity really takes off.
    
5. Grid and distributed utility computing models will start to creep into security
   A really interesting by-product of the "cloud compute" model is that as data, storage, networking, processing, etc. get distributed, so shall security.  In the grid model, one doesn't care where the actions take place so long as service levels are met and the experiential and business requirements are delivered.  Security should be thought of in exactly the same way. 
   
   The notion that you can point to a physical box and say it performs function 'X' is so last Tuesday. Virtualization already tells us this.  So, imagine if your security processing isn't performed by a monolithic appliance but instead is contributed to in a self-organizing fashion wherein the entire ecosystem (network, hosts, platforms, etc.) all contribute in the identification of threats and vulnerabilities as well as function to contain, quarantine and remediate policy exceptions.
   
   Sort of sounds like that "self-defending network" schpiel, but not focused on the network and with common telemetry and distributed processing of the problem.
   
   Check out Red Lambda's cGrid technology for an interesting view of this model.
    
6. Precision versus accuracy will start to legitimize prevention as the technology starts to allow us the confidence to start turning the corner beyond detection
   In a sad commentary on the last few years of the security technology grind, we've seen the prognostication that intrusion detection is dead and the deadpan urging of the security vendor cesspool convincing us that we must deploy intrusion prevention in its stead. 
      
   Since there really aren't many pure-play intrusion detection systems left anyway, the reality is that most folks who have purchased IPSs seldom put them in in-line mode and when they do, they seldom turn on the "prevention" policies and instead just have them detect attacks, blink a bit and get on with it.
   
   Why?  Mostly because while the threats have evolved the technology implemented to mitigate them hasn't -- we're either stuck with giant port/protocol colanders or signature-driven IPSs that are nothing more than IDSs with the ability to send RST packets.
   
   So the "new" generation of technology has arrived and may offer some hope of bridging that gap.  This is due to not only really good COTS hardware but also really good network processors and better software written (or re-written) to take advantage of both.  Performance, efficacy and efficiency have begun to give us greater visibility as we get away from making decisions based on ports/protocols (feel free to debate proxies vs. ACLs vs. stateful inspection...) and move to identifying application usage and getting us close to being able to make "real time" decisions on content in context by examining the payload and data.  See #2 above.
   
   The precision versus accuracy discussion is focused around being able to really start trusting in the ability for prevention technology to detect, defend and deter against "bad things" with a fidelity and resolution that has very low false positive rates.
   
   We're getting closer with the arrival of technology such as Palo Alto Network's solutions -- you can call them whatever you like, but enforcing both detection and prevention using easy-to-define policies based on application (and telling the difference between any number of apps all using port 80/443) is a step in the right direction.
    
7. The consumerization of IT will cause security and IT as we know it to die radically change
   I know it's heretical but 2008 is going to really push the limits of the existing IT and security architectures to their breaking points, which is going to mean that instead of saying "no," we're going to have to focus on how to say "yes, but with this incremental risk" and find solutions for an every increasingly mobile and consumerist enterprise. 
   
   We've talked about this before, and most security folks curl up into a fetal position when you start mentioning the adoption by the enterprise of social neworking, powerful smartphones, collaboration tools, etc.  The fact is that the favorable economics, agility , flexibility and efficiencies gained with the adoption of consumerization of IT outweigh the downsides in the long run.  Let's not forget the new generation of workers entering the workf