Rational Survivability

IDS: Vitamins Or Prophylactic?

Ravi Char commented on Alan Shimel's blog titled "IDS - The Beast That Just Won't Die."

Ravi makes a number of interesting comments in his blog titled "IDS/IPS - is it Vitamins?"  I'd like to address them because they offer what I maintain is a disturbing perspective on the state and implementation of IDS today by referencing deployment models and technology baselines from about 2001 that don't reflect reality based on my personal experience.

Ravi doesn't allow comments for this blog, so I thought I'd respond here.

Firstly, I'm not what I would consider and IDS apologist, but I do see the value in being able to monitor and detect things of note as they traverse my network.  In order to "prevent" you first must be able to "detect" so the notion one can have one without the other doesn't sound very realistic to me.

Honestly, I'd like to understand what commercial stand-alone IDS-only solutions Ravi is referring to.  Most IDS functions are built into larger suites of IDP products and include technology such as correlation engines, vulnerability assessment, behavioral anomaly, etc., so calling out IDS as a failure when in reality it represents the basis of many products today is nonsensical.

If a customer were to deploy an IPS in-line or out-of-band in "IDS" mode and not turn on automated blocking or all of the detection or prevention capabilities, is it fair to simply generalize that an entire suite of solutions is useless because of how someone chooses to deploy it?

I've personally deployed Snort, Sourcefire (with RNA,) ISS, Dragon, TippingPoint, TopLayer and numerous other UTM and IDP toolsets and the detection, visibility, reporting, correlation, alerts, forensic and (gasp!) preventative capabilities these systems offered were in-line with my expectations for deploying them in the first place.

IDS can capture tons of intrusion events, there is so much of don't care events it is difficult to single out event such as zero day event in the midst of such noise. 

Yes, IDS can capture tons of events.  You'll notice I didn't say "intrusion events" because in order to quantify an event as an "intrusion," one would obviously have already defined it as such in the IDS, thus proving the efficacy of the product in the first place.  This statement is contradictory on face value.

The operator's decision to not appropriately "tune" the things he or she is interested in viewing or worse yet not investing in a product that allows one to do so is a "trouble between the headsets" issue and not a generic solution-space one.  Trust me when I tell you there are plenty of competent IDS/IPS systems available that make this sort of decision making palatable and easy.

To take a note from a friend of mine, the notion of "false positives" in IDS systems seems a little silly.  If you're notified that traffic has generated an alert based upon a rule/signature/trigger you defined as noteworthy, how is that a false positive?  The product has done just what you asked it to do!  Tuning IDS/IPS systems requires context and an understanding of what you're trying to protect, from where, from whom, and why.

People looking for self-regulating solutions are going to get exactly what they deserve.

Secondarily, if an attacker is actually using an exploit against a zero-day vulnerability, how would *any* system be able to detect it based on the very description of a zero-day?

It requires tremendous effort to sift through the log and derive meaningful actions out of the log entries.

I again remind the reader that manually sifting through "logs" and "log entries" is a rather outdated concept and sounds more like forensics and log analysis than it does network IDS, especially given today's solutions replete with dashboards, graphical visualization tools, etc.

IDS needs a dedicated administrator to manage. An administrator who won't get bored of looking at all the packets and patterns, a truly boring job for a security engineer. Probably this job would interest a geekier person and geeks tend to their own interesting research!

I suppose that this sort of activity is not for everyone, but again, this isn't Intrusion Detection, Shadow Style (which I took at SANS 1999 with Northcutt) where we're reading through TCPDUMP traces line by line...

There are companies that do without IDS, and they do just fine. I agree with Alan's assessment that IDS is like a Checkbox in most cases.  Business can run without IDS just fine, why invest in such a technology?

I am convinced that there are many companies that "do without IDS."  By that token, there are many companies that can do without firewalls, IPS, UTM, AV, DLP, NAC, etc., until the day they realize they can't or realize that to be even minimally compliant with any sort of regulation and/or "best practice" (a concept I don't personally care for,) they cannot.

I'm really, really interested in understanding how it is that these companies "...do just fine."  Against what baseline and using what metrics does Ravi establish this claim.  If they don't have IDS and don't detect potential "intrusions," then how exactly can it be determined that they are better off (or just as good) without IDS?

Firewalls and other devices have built in features of IDS, so why invest in a separate product.

So I misunderstood the point here?  It's not that IDS is useless, it's just that standalone IDS deployments from 2001 are useless but if they're "good enough" functions bundled with firewalls or "other devices," they have some worth because it costs less?

I can't figure out whether the chief complaint here is an efficacy or ill-fated ROI exercise.

IDS is like Vitamins, nice to have, not having won't kill you in most cases. Customers are willing to pay for Pain Killers because they have to address their pain right away. For Vitamins, they can wait. Stop and think for moment, without Anti-virus product, businesses can't run for few days. But, without IDS, most businesses can run just fine and I base it out of my own experience.

...and it's interesting to note the difference between chronic and acute pain.  In many cases, customers don't notice chronic pain -- it's always there and they adjust their tolerance thresholds accordingly.  It may not kill you suddenly, but over time the same might not be true.  If you don't ingest vitamins in some form, you will die.

When an acute pain strikes, people obviously notice and seek immediate amelioration, but the pain killer option is really just a stop-gap, it doesn't "cure" it simply masks the pain. 

By this definition it's already too late for "prevention" because the illness has already set in and detection is self-evident -- you're ill.  Take your vitamins, however, and perhaps you won't get sick in the first place...

The investment strategy in IDS is different than that of AV.  You're addressing different problems, so comparing them equliaterally is both unfair and confusing.  In the long term, if you don't know what "normal" looks like -- a metric or trending you can certainly gain from IDS/IPS/IDP systems -- how will you determine what "abnormal" looks like?

So, sure, just like the vitamin example -- not having IDS may not "kill" you in the short term, but it can certainly grind you down over the long haul.

Probably, I would have offended folks from the IDS camp. I have a good friend who is a founder of an IDS company, I am sure he will react differently if he reads my narratives about IDS.  Once businesses start realizing that IDS is a Checkbox, they will scale down their investments in this area. In the current economic climate, financial institutions are not doing well. Financial institutions are big customers in terms of security products, with the current scenario of financial meltdown, they would scale down heavily on their spending on Vitamins.

Again, if you're suggesting that stand-alone IDS systems are not a smart investment and that the functionality will commoditize into larger suites over time but the FUNCTION is useful an necessary, then we agree.

If you're suggesting that IDS is simply not worthwhile, then we're in violent disagreement.

Running IDS software on VMware sounds fancy.  Technology does not matter unless you can address real world pain and prove the utilitarian value of such a technology. I am really surprised that IDS continues to exist. Proof of existence does not forebode great future. Running IDS on VMware does not make it any more utilitarian. I see a bleak future for IDS.

Running IDS in a virtual machine (whether it's on top of Xen, VMware or Hyper-V) isn't all that "fancy" but the need for visibility into virtual environments is great when the virtual networking obfuscates what can be seen from tradiational network and host-based IDS/IPS systems. 

You see a bleak future for IDS?  I see just as many opportunites for the benefits it offers -- it will just be packaged differently as it evolves -- just like it has over the last 5+ years.

/Hoff

UPDATED: How the Hypervisor is Death By a Thousand Cuts to the Network IPS/NAC Appliance Vendors

Attention NAC vendors who continue to barrage me via email/blog postings claiming I don't understand NAC:  You're missing the point of this post which basically confirms my point; you're not paying attention and are being myopic.

I included NAC with IPS in this post to illustrate two things:

(1) Current NAC solutions aren't particularly relevant when you have centralized and virtualized client infrastructure and

(2) If you understand the issues with offline VM's in the server world and what it means to compliance and admission control on spin-up or when VMotioned, you could add a lot of value by adapting your products (if you're software based) to do offline VM conformance/remediation and help prevent VM sprawl and inadvertent non-compliant VM spin-up...

But you go ahead and continue with your strategy...you're doing swell so far convincing the market of your relevance.

Now back to our regular programming...

-- ORIGINAL POST --

From the "Out Of the Loop" Department...

Virtualization is causing IPS and NAC appliance vendors some real pain in the strategic planning department.  I've spoken to several product managers of IPS and NAC companies that are having to make some really tough bets regarding just what to do about the impact virtualization is having on their business.

They hmm and haw initially about how it's not really an issue, but 2 beers later, we're speaking the same language...

Trying to align architecture, technology and roadmaps to the emerging tidal wave of consolidation that virtualization brings can be really hard.  It's hard to differentiate where the host starts and the network ends...

In reality, firewall vendors are in exactly the same spot.  Check out this Network World article titled "Options seen lacking in firewall virtual server protection."  In today's world, it's almost impossible to distinguish a "firewall" from an "IPS" from a "NAC" device to a new-fangled "highly adaptive access control" solution (thanks, Vernier Autonomic Networks...)

It's especially hard for vendors whose IPS/NAC software is tied to specialty hardware, unless of course all you care about is enforcing at the "edge" -- wherever that is, and that's the point.  The demarcation of those security domain diameters has now shrunk.  Significantly, and not just for servers, either.  With the resurgence of thin clients and new VDI initiatives, where exactly is the client/server boundary?

Prior to virtualization, network-based IPS/NAC vendors would pick arterial network junctions and either use a tap/SPAN port in an out-of-band deployment or slap a box inline between the "trusted" and "untrusted" sides of the links and that was that.  You'd be able to protect assets based on port, VLAN or IP address.

You obviously only see what traverses those pipes.  If you look at the problem I described here back in August of last year, where much of the communication takes place as intra-VM sessions on the same physical host that never actually touch the externally "physical" network, you've lost precious visibility for detection let alone prevention.

I think by now everyone recognizes how server virtualization impacts network and security architecture and basically provides four methods (potentially in combination) today for deploying security solutions:

1. Keep all your host based protections intact and continue to circle the wagons around the now virtualized endpoint by installing software in the actual VMs
2. When available, take a security solution provider's virtual appliance version of their product (if they have one) and install in on a host as a VM and configure the virtual networking within the vSwitch to provide the appropriate connectivity.
3. Continue to deploy physical appliances between the hosts and the network
4. Utilize a combination of host-based software and physical IPS/NAC hardware to provide off-load "switched" or "cut-through" policy enforcement between the two.

Each of these options has its pros and cons for both the vendor and the customer; trade-offs in manageability, cost, performance, coverage, scalability and resilience can be ugly.  Those that have both endpoint and network-based solutions are in a far more flexible place than those that do not.

Many vendors who have only physical appliance offerings are basically stuck adding 10Gb/s Ethernet connections to their boxes as they wait impatiently for options 5, 6 and 7 so they can "plug back in":

5.  Virtualization vendors will natively embed more security functionality within the hypervisor and continue integrating with trusted platform models

6.  Virtualization vendors will allow third parties to substitute their own vSwitches as a function of the hypervisor

7. Virtualization vendors will allow security vendors to utilize a "plug-in" methodology and interact directly with the VMM via API

These options would allow both endpoint software installed in the virtual machines as well as external devices to interact directly with the hypervisor with full purview of inter and intra-VM flows and not merely exist as a "bolted-on" function that lacks visibility and best-of-breed functionality.

While we're on the topic of adding 10Gb/s connectivity, it's important to note that having 10Gb/s appliances isn't always about how many Gb/s of IPS traffic you can handle, but also about consolidating what would otherwise be potentially dozens of trunked LACP 1Gb/s Ethernet and FC connections pouring out of each host to manage both the aggregate bandwidth but also the issues driven by a segmented network.

So to get the coverage across a segmented network today, vendors are shipping their appliances with tons of ports -- not necessarily because they want to replace access switches, but rather to enable coverage and penetration.

On the other hand, most of the pure-play software vendors today who say they are "virtualization enabled" really mean that their product installs as a virtual appliance on a VM on a host.  The exposure these solutions have to traffic is entirely dependent upon how the vSwitches are configured.

...and it's going to get even more hairy as the battle for the architecture of the DatacenterOS also rages.  The uptake of 10Gb/s Ethernet is also contributing to the mix as we see customers:

• Upgrading from servers to blades
• Moving from hosts and switches to clusters and fabrics
• Evolving from hardware/software affinity to gird/utility computing
• Transitioning from infrastructure to service layers in “the cloud”

Have you asked your IPS and NAC vendors who are hardware-bound how they plan to deal with this Tsunami on their roadmaps within the next 12 months.  If not, grab a lifejacket.

/Hoff

UPDATE:  It appears nobody uses trackbacks anymore, so I'm resorting to activity logs, Google alerts and stubbornness to tell when someone's referencing my posts.  Here are some interesting references to this post:

• Mike Fratto - NWC NAC and Virtualization Immersion Center
• Dana Hendrickson - SecureAccessCentral

...also, this is right on the money:

• Chris Silva - Forrester

I think I'll respond to them on my blog with a comment on theirs pointing back over...

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

On Bandwidth and Botnets...

An interesting story in this morning's New York Times titled "Unlike U.S., Japanese Push Fiber Over Profit" talked about Japan's long term investment efforts to build the world's first all-fiber national network and how Japan leads the world's other industrialized nations, including the U.S., in low-cost, high speed services centered around Internet access.  Check out this illustration:

The article states that approximately 8 million Japanese subscribe to the fiber-enabled service offerings that provides performance at roughly 30 times that of a corresponding xDSL offering.

For about $55 a month, subscribers have access to up to 100Mb/s download capacity.

France Telecom is rumored to be rolling out services that offer 2.5Gb/s downloads!

I have Verizon FIOS which is delivered via fiber to my home and subscribe at a 20Mb/s download tier.

What I find very interesting about the emergence of this sort of service is that if you look at a typical consumer's machine, it's not well hardened, not monitored and usually easily compromised.  At this rate, the bandwidth of some of these compromise-ready consumer's home connectivity is eclipsing that of mid-tier ISP's!

This is even more true, through anecdotal evidence gathering, of online gamers who are typically also P2P filesharing participants and early adopters of new shiny kit -- it's a Bot Herder's dream come true.

At xDSL speeds of a few Mb/s, a couple of infected machines as participants in a targeted synchronized fanning DDoS attack can easily take down a corporate network connected to the Internet via a DS3 (45Mb/s.)  Imagine what a botnet of a couple of 60Mb/s connected endpoints could do -- how about a couple of thousand?  Hundreds of thousands?

This is great news for some as this sort of capacity will be economically beneficial to cyber-criminals as it reduces the exposure risk of Botnet Herders; they don't have to infect nearly the same amount of machines to deliver exponentially higher attack yields given the size of the pipes.  Scary.

I'd suggest that using the lovely reverse DNS entries that service providers use to annotate logical hop connectivity will be even more freely used to target these high-speed users; you know, like (fictional):

bigass20MbpsPipe.vzFIOS-05.bstnma.verizon-gni.net (7x.y4.9z.1)

As an interesting anecdote from the service provider perspective, the need for "Clean Pipes" becomes even more important and the providers will be even more so financially motivated to prevent abuse of their backbone long-hauls by infected machines.

This, in turn, will drive the need for much more intelligent, higher throughput infrastructure and security service layers to mitigate the threat which is forcing folks to take a very hard look about how they architect their networks and apply security.

/Hoff

HyperJackStacking? Layers of Chewy VMM Goodness -- the BLT of Security Models

So Mogull is back on the bench and I'm glad to see him blogging again. 

As I type this, I'm listening to James Blunt's  new single "1973" which is unfortunately where Rich's timing seems to be on this topic.  'Salright though.  Can't blame him.  He's been out scouting the minors for a while, so being late to practice is nothing to be too wound up about.

<If you can't tell, I'm being sarcastic.  I only wish that Rich was when he told me that his favorite TexMex place in his hometown is called the "Pink Taco."  That's all I'm going to say about that...>

The notion of the HyperJackStack (Hypervisor Jacking & Stacking) is actually a problem set that has been discussed at length and in the continuum of these discussions happened quite a while ago. 

To put it bluntly, I believe the discussion -- for right or wrong -- stepped over this naughty little topic months ago in lieu of working from the bottom up for the purpose exposing fundamental architectural deficiencies (or at least their potential) in the core of virtualization technology.  This is an argument that parallels dissecting a BLT sandwich...you're approaching getting to the center of a symmetric stack so which end you start at is almost irrelevant.

The good/bad VMM/HV problem has really been relegated to push-pin on the to-do board of all of the virtualization vendors and this particular problem has been framed by said vendors to be apparently solved first operationally from the management plane and THEN dealt with from the security perspective.

So Rich argues that after boning up on Joanna and Thom's research that they're arguing the wrong case completely for the dangers of virtualized rootkits.  Instead of worrying about undetectability of this or that -- pills and poultry be damned -- one should be focused on establishing the relative disposition of *any* VMM/Hypervisor running in/on a host:

Problem is, they’re looking at the wrong problem. I will easily concede that detecting virtualization is always possible, but that’s not the real problem. Long-term virtualization will be normal, not an exception, so detecting if you’re virtualized won’t buy you anything. The bigger problem is detecting a malicious hypervisor, either the main hypervisor or maybe some wacky new malicious hypervisor layered on top of the trusted hypervisor.

To Rich's credit, I think that this is a huge problem and one that deserves to be solved.  That does not mean that I think one is the "right" versus "wrong" problem to solve, however.  Nor does it mean this hasn't been discussed.  I've talked about it many times already.  Maybe not as eloquently...

The flexibility of virtualization is what provides the surface expansion of vectors for threat; you can spin up, move or kill a VM across an enterprise with a point-click.  So the first thing to do before trying to determine if a VMM/HV is malicious is to detect its presence and layering in the first place...this is where Thom/Joanna's research really does make sense.

You're approaching this from a different direction, is all.

Thom responded here, and I have to agree with his overall posture; the notion of putting hooks into the VMM/HV to allow for "external" detection mechanisms for the sake solely of VMM/HV rootkit detection is unlikely given the threat, but we are already witness to the engineered capacities to allow for "plug-ins" such as Blue Lane's that function "along side" the HV/VMM and there's nothing saying one couldn't adapt a similar function for this sort of detection (and/or prevention) as a value-add.

Ultimately though, I think that the point of response boils down to the definition of the mechanisms used in the detection of a malicious VMM/HV.  I ask you Rich, please define a "malicious" VMM/HV from one steeped in goodness. 

This sounds like in practice, it will come down to yet another iteration of the signature-driven IPS circle jerk to fingerprint/profile disposition.  We'll no doubt see anomaly and behavioral analysis used here, and then we'll have hashing, memory firewalls, etc...it's going to be the Hamster Wheel all over again.  For the same reason we have trouble with validating security and compliance state for anything more than the cursory checks @ 30K feet today, you'll face the same issue with virtualization -- only worse.

I've got one for you...how about escaping from the entire VM "jail" entirely...Ed Skoudis over @ IntelGuardians just did an interview with the PaulDotCom boys on this topic...

I believe one must start from the bottom and work up; they're trying to make up for the fact that this stuff wasn't properly thought through in this iteration and are trying to expose the issue now. In fact, look at what Intel just announced today with vPro:

New in this product is Intel Trusted Execution Technology (Intel TXT, formerly codenamed LaGrande). Intel TXT protects data within virtualized computing environments, an important feature as IT managers are considering the adoption of new virtualization-enabled computer uses. Used in conjunction with a new generation of the company's virtualization technology - Intel Virtualization Technology for Directed I/O - Intel TXT ensures that virtual machine monitors are less vulnerable to attacks that cannot be detected by today's conventional software-security solutions. By isolating assigned memory through this hardware-based protection, it keeps data in each virtual partition protected from unauthorized access from software in another partition.

So no, Ptacek and Joanna aren't fighting the "wrong" battle, they're just fighting one that garners much more attention, notoriety, and terms like "HyperJackStack" than the one you're singling out.  ;)

/Hoff

P.S. Please invest in a better setup for your blog...I can't trackback to you (you need Halo or something) and your comment system requires registration...bah!  Those G-Boys have you programmed... ;)

I Know It's Been 4 Months Since I Said it, but "NO! DLP is (Still) NOT the Next Big Thing In Security!"

Nope.  Haven't changed my mind.  Sorry.  Harrington stirred it up and Chuvakin reminded me of it.

OK, so way back in April, on the cusp of one of my normal rages against the (security) machine, I blogged how Data Leakage Protection (DLP) is doomed to be a feature and not a market. 

I said the same thing about NAC, too.  Makin' friends and influencin' people.  That's me!

Oh my how the emails flew from the VP's of Marketing & Sales from the various "Flying V's" (see below)  Good times, good times.

Here's snippets of what I said:

Besides having the single largest collection of vendors that begin with the letter 'V" in one segment of the security space (Vontu, Vericept, Verdasys, Vormetric...what the hell!?) it's interesting to see how quickly content monitoring and protection functionality is approaching the inflection point of market versus feature definition.

The "evolution" of the security market marches on.

Known by many names, what I describe as content monitoring and protection (CMP) is also known as extrusion prevention, data leakage or intellectual property management toolsets.  I think for most, the anchor concept of digital rights management (DRM) within the Enterprise becomes glue that makes CMP attractive and compelling; knowing what and where your data is and how its distribution needs to be controlled is critical.

The difficulty with this technology is the just like any other feature, it needs a delivery mechanism.  Usually this means yet another appliance; one that's positioned either as close to the data as possible or right back at the perimeter in order to profile and control data based upon policy before it leaves the "inside" and goes "outside."

I made the point previously that I see this capability becoming a feature in a greater amalgam of functionality;  I see it becoming table stakes included in application delivery controllers, FW/IDP systems and the inevitable smoosh of WAF/XML/Database security gateways (which I think will also further combine with ADC's.)

I see CMP becoming part of UTM suites.  Soon.

That being said, the deeper we go to inspect content in order to make decisions in context, the more demanding the requirements for the applications and "appliances" that perform this functionality become. Making line speed decisions on content, in context, is going to be difficult to solve. 

CMP vendors are making a push seeing this writing on the wall, but it's sort of like IPS or FW or URL Filtering...it's going to smoosh.

Websense acquired PortAuthority.  McAfee acquired Onigma.  Cisco will buy...

I Never Metadata I Didn't Like...

I didn't even bother to go into the difficulty and differences in classifying, administering, controlling and auditing structured versus unstructured data, nor did I highlight the differences between those solutions on the market who seek to protect and manage information from leaking "out" (the classic perimeter model) versus management of all content ubiquitously regardless of source or destination.  Oh, then there's the whole encryption in motion, flight and rest thing...and metadata, can't forget that...

Yet I digress...let's get back to industry dynamics.  It seems that Uncle Art is bound and determined to make good on his statement that in three years there will be no stand-alone security companies left.  At this rate, he's going to buy them all himself!

As we no doubt already know, EMC acquired Tablus. Forrester seems to think this is the beginning of the end of DLP as we know it.  I'm not sure I'd attach *that* much gloom and doom to this specific singular transaction, but it certainly makes my point:

  August 20, 2007

EMC/RSA Drafts Tablus For Deeper Data-Centric Security
The Beginning Of The End Of The Standalone ILP Market
by Thomas Raschke
with Jonathan Penn, Bill Nagel, Caroline Hoekendijk

EXECUTIVE SUMMARY

EMC expects Tablus to play a key role in its information-centric security and storage lineup. Tablus' balanced information leak prevention (ILP) offering will benefit both sides of the EMC/RSA house, boosting the latter's run at the title of information and risk market leader. Tablus' data classification capabilities will broaden EMC's Infoscape beyond understanding unstructured data at rest; its structured approach to data detection and protection will provide a data-centric framework that will benefit RSA's security offerings like encryption and key management. While holding a lot of potential, this latest acquisition by one of the industry's heavyweights will require comprehensive integration efforts at both the technology and strategic level. It will also increase the pressure on other large security and systems management vendors to address their organization's information risk management pain points. More importantly, it will be remembered as the turning point that led to the demise of the standalone ILP market as we know it today.

So Mogull will probably (still) disagree, as will the VP's of Marketing/Sales working for the Flying-V's who will no doubt barrage me with email again, but it's inevitable.  Besides, when an analyst firm agrees with you, you can't be wrong, right Rich!?

/Hoff

 

Quick Post of a Virtualization Security Presentation: "Virtualization and the End of Network Security As We Know It..."

"Virtualization and the End of Network Security As We Know It...
The feel good hit of the summer!"

Ye olde blog gets pinged quite a lot with searches and search engine redirects for folks looking for basic virtualization and virtualized security information. 

I had to drum up a basic high-level virtualization security presentation for the ISSA Charlotte Metro gathering back in April and I thought I may as well post it.

It's in .PDF format.  If you want it in .PPT or Keynote, let me know, I'll be glad to send it to you.  If it's useful or you need some explanation regarding the visual slides, please get back to me and I'll be more than glad to address anything you want.  I had 45 minutes to highlight how folks were and might deal with "securing virtualization by virtualizing security."

Yes, some of it is an ad for the company I used to work for who specializes in virtualized security service layers (Crossbeam) but I'm sure you can see how it is relevant in the preso.  You'll laugh, you'll cry, you'll copy/paste the text and declare your own brilliance.  Here's the summary slide so those of you who haven't downloaded this yet will know the sheer genius you will be missing if you don't:

At any rate, it's not earth shattering but does a decent job at the high level of indicating some of the elements regarding virtualized security. I apologize for the individual animation slide page build-ups.  I'll re-upload without them when I can get around to it. (Ed: Done.  I also uploaded the correct version ;)

Here's the PDF.

/Hoff

(As of 11pm EST -- 5.5 hours later 1:45pm EST the next day, you lot have downloaded this over 150 380 times.  Since there are no comments, it's either the biggest piece of crap I've ever produced or you are all just so awe stricken you are unable to type.  Newby, you are not allowed to respond to this rhetorical question...)

Oh SNAP! VMware acquires Determina! Native Security Integration with the Hypervisor?

Hot on the trails of becoming gigagillionaires, the folks at VMware make my day with this.  Congrats to the folks @ Determina.

Methinks that for the virtualization world, it's a very, very good thing.  A step in the right direction.

I'm going to prognosticate that this means that Citrix will buy Blue Lane or Virtual Iron next (see bottom of the post) since their acquisition of XenSource leaves them with the exact same problem that this acquisition for VMware tries to solve:

VMware Inc., the market leader in virtualization software, has acquired Determina Inc., a Silicon Valley maker of host intrusion prevention products.

...the security of virtualized environments has been something of an unknown quantity due to the complexity of the technology and the ways in which hypervisors interact with the host OS.  Determina's technology is designed specifically to protect the OS from malicious code, regardless of the origin of the attack, so it would seem to be a sensible fit for VMware, analysts say.

In his analysis of the deal, Gartner's MacDonald sounded many of the same notes. "By potentially integrating Memory Firewall into the ESX hypervisor, the hypervisor itself can provide an additional level of protection against intrusions. We also believe the memory protection will be extended to guest OSs as well: VMware's extensive use of binary emulation for virtualization puts the ESX hypervisor in an advantageous position to exploit this style of protection," he wrote.

I've spoken a lot recently  about how much I've been dreading the notion that security was doomed to repeat itself with the accelerated take off of server virtualization since we haven't solved many of the most basic security problem classes.  Malicious code is getting more targeted and more intelligent and when you combine an emerging market using hot technology without an appropriate level of security... 

Basically, my concerns have stemmed from the observation that if we can't do a decent job protecting physically-seperate yet interconnected network elements with all the security fu we have, what's going to happen when the "...network is the computer" (or vice versa.)  Just search for "virtualization" via the Lijit Widget above for more posts on this...

Some options for securing virtualized guest OS's in a VM are pretty straight foward:

1. Continue to deploy layered virtualized security services across VLAN segments of which each VM is a member (via IPS's, routers, switches, UTM devices...)
2. Deploy software like Virtual Iron's which looks like a third party vSwitch IPS on each VM
3. Integrate something like Blue Lane's ESX plugin-in which interacts with and at the VMM level
4. As chipset level security improves, enable it
5. Deploy HIPS as part of every guest OS.

Each of these approaches has its own sets of pros and cons, and quite honestly, we'll probably see people doing all five at the same time...layered defense-in-depth.  Ugh.

What was really annoying to me, however, is that it really seemed that in many cases, the VM solution providers were again expecting that we'd just be forced to bolt security ON TO our VM environments instead of BAKING IT IN.  This was looking like a sad reality.

I'll get into details in another post about Determina's solution, but I am encouraged by VMware's acquisition of a security company which will be integrated into their underlying solution set.  I don't think it's  a panacea, but quite honestly, the roadmap for solving these sorts of problems were blowing in the wind for VMware up until this point.

"Further, by using the LiveShield capabilities, the ESX hypervisor could be used 'introspectively' to shield the hypervisor and guest OSs from attacks on known vulnerabilities in situations where these have not yet been patched. Both Determina technologies are fairly OS- and application-neutral, providing VMware with an easy way to protect ESX as well as Linux- and Windows-based guest OSs."

Quite honestly, I hoped they would have bought Blue Lane since the ESX Hypervisor is now going to be a crowded space for them...

We'll see how well this gets integrated, but I smiled when I read this.

Oh, and before anyone gets excited, I'm sure it's going to be 100% undetectable! ;)

/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

Really, There's More to Security than Admission/Access Control...

Dr. Joseph Tardo over at the Nevis Networks Illuminations blog composed a reasonably well-balanced commentary regarding one or more of my posts in which I was waxing on philosophically about about my beliefs regarding keeping the network plumbing dumb and overlaying security as a flexible, agile, open and extensible services layer.

It's clear he doesn't think this way, but I welcome the discourse.  So let me make something clear:

Realistically, and especially in non-segmented flat networks, I think there are certain low-level security functions that will do well by being served up by switching infrastructure as security functionality commoditizes, but I'm not quite sure for the most part how or where yet I draw the line between utility and intelligence.  I do, however, think that NAC is one of those utility services.

I'm also unconvinced that access-grade, wiring closet switches are architected to scale in either functionality, efficacy or performance to provide any more value or differentiation other than port density than the normal bolt-on appliances which continue to cause massive operational and capital expenditure due to continued forklifts over time.  Companies like Nevis and Consentry quietly admit this too, which is why they have both "secure switches" AND appliances that sit on top of the network...

Joseph suggested he was entering into a religious battle in which he summarized many of the approaches to security that I have blogged about previously and I pointed out to him on his blog that this is exactly why I practice polytheism ;) :

In case you aren’t following the religious wars going on in the security blogs and elsewhere, let me bring you up to date.

It goes like this. If you are in the client software business, then security has to be done in the endpoints and the network is just dumb “plumbing,” or rather, it might as well be because you can’t assume anything about it. If you sell appliances that sit here and there in the network, the network sprouts two layers, with the “plumbing” part separated from the “intelligence.” Makes sense, I guess. But if you sell switches and routers then the intelligence must be integrated in with the infrastructure. Now I get it. Or maybe I’m missing the point, what if you sell both appliances and infrastructure?

I believe that we're currently forced to deploy in defense in depth due to the shortcomings of solutions today.  I believe the "network" will not and cannot deliver all the security required.  I believe we're going to have to invest more in secure operating systems and protocols.  I further believe that we need to be data-centric in our application of security.  I do not believe in single-point product "appliances" that are fundamentally functionally handicapped.  As a delivery mechanism to deliver security that matters across network I believe in this.

Again, the most important difference between what I believe and what Joseph points out above is that the normal class of "appliances" he's trying to suggest I advocate simply aren't what I advocate at all.  In fact, one might surprisingly confuse the solutions I do support as "infrastructure" -- they look like high-powered switches with a virtualized blade architecture integrated into the solution.

It's not an access switch, it's not a single function appliance and it's not a blade server and it doesn't suffer from the closed proprietary single vendor's version of the truth.  To answer the question, if you sell and expect to produce both secure appliances and infrastructure, one of them will come up short.   There are alternatives, however.

So why leave your endpoints, the ones that have all those vulnerabilities that created the security industry in the first place, to be hit on by bots, “guests,” and anyone else that wants to? I don’t know about you, but I would want both something on the endpoint, knowing it won’t be 100% but better than nothing, and also something in the network to stop the nasty stuff, preferably before it even got in.

I have nothing to disagree with in the paragraph above -- short of the example of mixing active network defense with admission/access control in the same sentence; I think that's confusing two points.   Back to the religious debate as Joseph drops back to the "Nevis is going to replace all switches in the wiring closet" approach to security via network admission/access control:

Now, let’s talk about getting on the network. If the switches are just dumb plumbing they will blindly let anyone on, friend or foe, so you at least need to beef up the dumb plumbing with admission enforcement points. And you want to put malware sensors where they can be effective, ideally close to entry points, to minimize the risk of having the network infrastructure taken down. So, where do you want to put the intelligence, close to the entry enforcement points or someplace further in the bowels of the network where the dumb plumbing might have plugged-and-played a path around your expensive intelligent appliance?

That really depends upon what you're trying to protect; the end point, the network or the resources connected to it.  Also, I won't/can't argue about wanting to apply access/filtering (sounds like IPS in the above example) controls closest to the client at the network layer.  Good design philosophy.   However, depending upon how segmented your network is, the types, value and criticality of the hosts in these virtual/physical domains, one may choose to isolate by zone or VLAN and not invest in yet another switch replacement at the access layer.

If the appliance is to be effective, it has to sit at a choke point and really be and enforcement point. And it has to have some smarts of its own. Like the secure switch that we make.

Again, that depends upon your definition of enforcement and applicability.  I'd agree that in flat networks, you'd like to do it at the port/host level, though replacing access switches to do so is usually not feasible in large networks given investments in switching architectures.  Typical fixed configuration appliances overlaid don't scale, either.

Furthermore, depending upon your definition of what an enforcement zone and it's corresponding diameter is (port, VLAN, IP Subnet) you may not care.  So putting that "appliance" in place may not be as foreboding as you wager, especially if it overlays across these boundaries satisfactorily.

We will see how long before these new-fangled switch vendors that used to be SSL VPN's, that then became IPS appliances that have now "evolved" into NAC solutions, will become whatever the next buzzword/technology of tomorrow represents...especially now with Cisco's revitalized technology refresh for "secure" access switches in the wiring closets.  Caymas, Array, and Vernier (amongst many) are perfect examples.

When it comes down to it, in the markets Crossbeam serves -- and especially the largest enterprises -- they are happy with their switches, they just want the best security choice on top of it provided in a consolidated, agile and scalable architecture to support it.

Amen.

/Hoff

My IPS (and FW, WAF, XML, DBF, URL, AV, AS) *IS* Bigger Than Yours Is...

Interop has has been great thus far.  One of the most visible themes of this year's show is (not suprisingly) the hyped emergence of 10Gb/s Ethernet.  10G isn't new, but the market is now ripe with products supporting it: routers, switches, servers and, of course, security kit.

With this uptick in connectivity as well as the corresponding float in compute power thanks to Mr. Moore AND some nifty evolution of very fast, low latency, reasonably accurate deep packet inspection (including behavioral technology,) the marketing wars have begun on who has the biggest, baddest toys on the block.

Whenever this discussion arises, without question the notion of "carrier class" gets bandied about in order to essentially qualify a product as being able to withstand enormous amounts of traffic load without imposing latency. 

One of the most compelling reasons for these big pieces of iron (which are ultimately a means to an end to run software, afterall) is the service provider/carrier/mobile operator market which certainly has its fair share of challenges in terms of not only scale and performance but also security.

I blogged a couple of weeks ago regarding the resurgence of what can be described as "clean pipes" wherein a service provider applies some technology that gets rid of the big lumps upstream of the customer premises in order to deliver more sanitary network transport.

What's interesting about clean pipes is that much of what security providers talk about today is only actually a small amount of what is actually needed.  Security providers, most notably IPS vendors, anchor the entire strategy of clean pipes around "threat protection" that appears somewhat one dimensional.

This normally means getting rid of what is generically referred to today as "malware," arresting worm propagation and quashing DoS/DDoS attacks.  It doesn't speak at all to the need for things that aren't purely "security" in nature such as parental controls (URL filtering,) anti-spam, P2P, etc.  It appears that in the strictest definition, these aren't threats?

So, this week we've seen the following announcements:

• ISS announces their new appliance that offers 6Gb/s of IPS
• McAfee announces thei new appliance that offers 10Gb/s of IPS

The trumpets sounded and the heavens parted as these products were announced touting threat protection via IPS at levels supposedly never approached before.  More appliances.  Lots of interfaces.  Big numbers.  Yet to be seen in action.  Also, to be clear a 2U rackmount appliance that is not DC powered and non-NEBS certified isn't normally called "Carrier-Class."

I find these announcements interesting because even with our existing products (which run ISS and Sourcefire's IDS/IPS software, by the way) we can deliver 8Gb/s of firewall and IPS today and have been able to for some time.

Lisa Vaas over @ eWeek just covered the ISS and McAfee announcements and she was nice enough to talk about our products and positioning.  One super-critical difference is that along with high throughput and low latency you get to actually CHOOSE which IPS you want to run -- ISS, Sourcefire and shortly Check Point's IPS-1.

You can then combine that with firewall, AV, AS, URL filtering, web app. and database firewalls and XML security gateways in the same chassis to name a few other functions -- all best of breed from top-tier players -- and this is what we call Enterprise and Provider-Class UTM folks.

Holistically approaching threat management across the entire spectrum is really important along with the speeds and feeds and we've all seen what happens when more and more functionality is added to the feature stack -- you turn a feature on and you pay for it performance-wise somewhere else.  It's robbing Peter to pay Paul.  The processing requirements necessary at 10G line rates to do IPS is different when you add AV to the mix.

The next steps will be interesting and we'll have to see how the switch and overlay vendors rev up to make their move to have the biggest on the block.  Hey, what ever did happen to that 3Com M160?

Then there's that little company called Cisco...

{Ed: Oops.  I made a boo-boo and talked about some stuff I shouldn't have.  You didn't notice, did you?  Ah, the perils of the intersection of Corporate Blvd. and Personal Way!  Lesson learned. ;) }

 

Security: "Built-in, Overlay or Something More Radical?"

I was reading Joseph Tardo's (Nevis Networks) new Illuminations blog and found the topic of his latest post ""Built-in, Overlay or Something More Radical?" regarding the possible future of network security quite interesting.

Joseph (may I call you Joseph?) recaps the topic of a research draft from Stanford funded by the "Stanford Clean Slate Design for the Internet" project that discusses an approach to network security called SANE.   The notion of SANE (AKA Ethane) is a policy-driven security services layer that utilizes intelligent centrally-located services to replace many of the underlying functions provided by routers, switches and security products today:

Ethane is a new architecture for enterprise networks which provides a powerful yet simple management model and strong security guarantees.  Ethane allows network managers to define a single, network-wide, fine-grain policy, and then enforces it at every switch.  Ethane policy is defined over human-friendly names (such as "bob, "payroll-server", or "http-proxy) and  dictates who can talk to who and in which manner.  For example, a policy rule may specify that all guest users who have not authenticated can only use HTTP and that all of their traffic must traverse a local web proxy.

Ethane has a number of salient properties difficult to achieve with network technologies today.  First, the global security policy is enforced at each switch in a manner that is resistant to poofing.  Second, all packets on an Ethane network can be attributed back to the sending host and the physical location in which the packet entered the network.  In fact, packets collected in the past can also be attributed to the sending host at the time the packets were sent -- a feature that can be used to aid in auditing and forensics.  Finally, all the functionality within Ethane is provided by very simple hardware switches.       

The trick behind the Ethane design is that all complex functionality, including routing, naming, policy declaration and security checks are performed by a central controller (rather than in the switches as is done today).  Each flow on the network must first get permission from the controller which verifies that the communicate is permissible by the network policy.  If the controller allows a flow, it computes a route for the flow to take, and adds an entry for that flow in each of the switches along the path.       

With all complex function subsumed by the controller, switches in Ethane are reduced to managed flow tables whose entries can only be populated by the controller (which it does after each succesful permission check).  This allows a very simple design for Ethane       switches using only SRAM (no power-hungry TCAMS) and a little bit of logic.    

I like many of the concepts here, but I'm really wrestling with the scaling concerns that arise when I forecast the literal bottlenecking of admission/access control proposed therein.

Furthermore, and more importantly, while SANE speaks to being able to define who "Bob"  is and what infrastructure makes up the "payroll server,"  this solution seems to provide no way of enforcing policy based on content in context of the data flowing across it.  Integrating access control with the pseudonymity offered by integrating identity management into policy enforcement is only half the battle.

The security solutions of the future must evolve to divine and control not only vectors of transport but also the content and relative access that the content itself defines dynamically.

I'm going to suggest that by bastardizing one of the Jericho Forum's commandments for my own selfish use, the network/security layer of the future must ultimately respect and effect disposition of content based upon the following rule (independent of the network/host):

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. 

 

Deviating somewhat from Jericho's actual meaning, I am intimating that somehow, somewhere, data must be classified and self-describe the policies that govern how it is published and consumed and ultimately this security metadata can then be used by the central policy enforcement mechanisms to describe who is allowed to access the data, from where, and where it is allowed to go.

...Back to he topic at hand, SANE:

As Joseph alluded, SANE would require replacing (or not using much of the functionality of) currently-deployed routers, switches and security kit.  I'll let your imagination address the obvious challenges with this design.

Without delving deeply, I'll use Joseph's categorization of “interesting-but-impractical”

/Hoff

Clean Pipes - Less Sewerage or More Potable Water?

Jeff Bardin over on the CSO blog pitched an interesting stake in the ground when he posited "Connectivity As A Utility: Where are My Clean Pipes?"

Specifically, Jeff expects that his (corporate?) Internet service functions in the same manner as his telephone service via something similar to a "do not call list."  Basically, he opts out by placing himself on the no-call list and telemarketers cease to call. Others might liken it to turning on a tap and getting clean, potable water; you pay for a utility and expect it to be usable.  All of it.

Many telecommunications providers want to charge you for having clean pipes, deploying a suite of DDoS services that you have to buy to enhance your security posture.   Protection of last mile bandwidth is very key to network availability as well as confidentiality and integrity. If I am subscribing for a full T1, shouldn’t I get the full T1 as part of the price and not just a segment of the T1? Why do I have to pay for the spam, probes, scans, and malicious activity that my telecommunications service provider should prevent at 3 miles out versus my having to subscribe to another service to attain clean pipes at my doorstep?

I think that most people would agree with the concept of clean pipes in principle.  I can't think of any other utility where the service levels delivered are taken with such a lackadaisical best effort approach and where the consumer can almost always expect that some amount (if not the majority) of the utility is unusable. 

Over the last year, I've met with many of the largest ISP's, MSSP's, TelCo's and Mobile Operators on the planet and all are in some phase of deploying some sort of clean pipes variant.  Gartner even predicts a large amount of security to move "into the cloud."

In terms of adoption, EMEA is leaps and bounds ahead of the US and APAC in these sorts of services and will continue to be.  The relative oligopolies associated with smaller nation states allows for much more agile and flexible service definition and roll-outs -- no less complex, mind you.  It's incredible to see just how disparate and divergent the gap is between what consumers (SME/SMB/Mobile as well as large enterprise) are offered in EMEA as opposed to the good-ol' U S of A.

However, the stark reality is that the implementation of clean pipes by your service provider(s) comes down to a balance of two issues: efficacy and economics, with each varying dramatically with the market being served; the large enterprise's expectations and requirements look very, very different from the SME/SMB.

Let's take a look at both of these elements.

ECONOMICS

If you ask most service providers about so-called clean pipes up to a year ago, you could expect to get an answer that was based upon a "selfish" initiative aimed at stopping wasteful bandwidth usage upstream in the service provider's network, not really protecting the consumer. 

The main focus here is really on DDoS and viri/worm propagation.  Today, the closest you'll come to "clean pipes" is usually some combination of the following services deployed both (still) at the customer premises as well as somewhere upstream:

• DoS/DDoS
• Anti-Virus
• Anti-Spam
• URL Filtering/Parental Controls
• Managed Firewall/IDS/IPS

What is interesting about these services is that they basically define the same functions you can now get in those small little UTM boxes that consolidate security functionality at the "perimeter."  The capital cost of these devices and the operational levies associated with their upkeep are pretty close in the SME/SMB and when you balance what you get in "good enough" services for this market as well as the overall availability of these "in the cloud" offerings, UTM makes more sense for many in the near term.

For the large enterprise, the story is different.  Outsourcing some level of security to an MSSP (or perhaps even the entire operation) or moving some amount upstream is a matter of core competence and leveraging the focus of having internal teams focus on the things that matter most while the low hanging fruit can be filtered out and monitored by someone else.  I describe that as filtering out the lumps.  Some enormous companies have outsourced not only their security functions but their entire IT operations and data center assets in this manner.  It's not pretty, but it works.

I'm not sure they are any more secure than they were before, however.  The risk simply was transferred whilst the tolerance/appetite for it didn't change at all.  Puzzling.

Is it really wrong to think that companies (you'll notice I said companies, not "people" in the general sense) should pay for clean pipes?  I don't think it is.  The reality is that for non-commercial subscribers such as home users, broadband or mobile users, some amount of bandwidth hygiene should be free -- the potable water approach.

I think, however, that should a company which expects elevated service levels and commensurate guarantees of such, want more secure connectivity, they can expect to ante up.  Why?  Because the investment required to deliver this sort of service costs a LOT of money -- both to spin up and to instantiate over time.  You're going to have to pay for that somewhere.

I very much like Jeff's statistics:

We stop on average for our organization nearly 600 million malicious emails per year at our doorstep averaging 2.8 gigabytes of garbage per day. You add it up and we are looking at nearly a terabyte of malicious email we have to stop. Now add in probes and scans against HTTP and HTTPS sites and the number continues to skyrocket.

Again, even though Jeff's organization isn't small by any means, the stuff he's complaining about here is really the low-hanging fruit.  It doesn't bear a dent against the targeted, malicious and financially-impacting security threats that really demands a level of service no service provider will be able to deliver without a huge cost premium.

I won't bore you with the details, but the level of high-availability, resilience, performance, manageability, and provisioning required to deliver even this sort of service is enormous.  Most vendors simply can't do it and most service providers are slow to invest in proprietary solutions that won't scale economically with the operational models in place.

Interestingly, vendors such as McAfee even as recently as 2005 announced with much fanfare that they were going to deliver technology, services and a united consortium of participating service providers with the following lofty clean pipe goals (besides selling more product, that is):

The initiative is one part of a major product and services push from McAfee, which is developing its next generation of carrier-grade security appliances and ramping up its enterprise security offerings with NAC and secure content management product releases planned for the first half of next year, said Vatsal Sonecha, vice president of market development and strategic alliances at McAfee, in Santa Clara, Calif.

Clean Pipes will be a major expansion of McAfee's managed services offerings. The company will sell managed intrusion prevention; secure content management; vulnerability management; malware protection, including anti-virus, anti-spam and anti-spyware services; and mobile device security, Sonecha said.

McAfee is working with Cable and Wireless PLC, British Telecommunications PLC (British Telecom), Telefónica SA and China Network Communications (China Netcom) to tailor its offerings through an invitation-only group it calls the Clean Pipes Consortium.

http://www.eweek.com/article2/0,1895,1855188,00.asp

Look at all those services!  What have they delivered as a service in the cloud or clean pipes?  Nada. 

The chassis-based products which were to deliver these services never materialized and neither did the services.  Why?  Because it's really damned hard to do correctly.  Just ask Inkra, Nexi, CoSine, etc.  Or you can ask me.  The difference is, we're still in business and they're not.  It's interesting to note that every one of those "consortium members" with the exception of Cable and Wireless are Crossbeam customers.  Go figure.

EFFICACY

Once the provider starts filtering at the ingress/egress, one must trust that the things being filtered won't have an impact on performance -- or confidentiality, integrity and availability.  Truth be told, as simple as it seems, it's not just about raw bandwidth.  Service levels must be maintained and the moment something that is expected doesn't make its way down the pipe, someone will be screaming bloody murder for "slightly clean" pipes.

Ask me how I know.  I've lived through inconsistent application of policies, non-logged protocol filtering, dropped traffic and asymmetric issues introduced by on-prem and in-the-cloud MSSP offerings.  Once the filtering moves past your prem. as a customer, your visibility does too.  Those fancy dashboards don't do a damned bit of good, either.  Ever consider the forensic impact?

Today, if you asked a service provider what constitutes their approach to clean pipes, most will refer you back to the same list I referenced above:

• DoS/DDoS
• Anti-Virus
• Anti-Spam
• URL Filtering/Parental Controls
• Managed Firewall/IDS/IPS

The problem is that most of these solutions are disparate point products run by different business units at different parts of the network.  Most are still aimed at the perimeter service -- it's just that the perimeter has moved outward a notch in the belt.

Look, for the SME/SMB (or mobile user,) "good enough" is, for the most part, good enough.  Having an upstream provider filter out a bunch of spam and viri is a good thing and most firewall rules in place in the SME/SMB block everything but a few inbound ports to DMZ hosts (if there are any) and allow everything from the inside to go out.  Not very complicated and it doesn't take a rocket scientist to see how, from the perspective of what is at risk, that this service doesn't pay off handsomely.

From the large enterprise I'd say that if you are going to expect that operational service levels will be met, think again.  What happens when you introduce web services, SOA and heavy XML onto externally-exposed network stubs.  What happens when Web2/3/4.x technologies demand more and more security layers deployed alongside the mechanics and messaging of the service?

You can expect issues and the lack of transparency will be an issue on all but the most simple of issues.

Think your third party due diligence requirements are heady now?  Wait until this little transference of risk gets analyzed when something bad happens -- and it will.  Oh how quickly the pendulum will swing back to managing this stuff in-house again.

This model doesn't scale and it doesn't address the underlying deficiencies in the most critical elements of the chain: applications, databases and end-point threats such as co-opted clients as unwilling botnet participants.

But to Jeff's point, if he didn't have to spend money on the small stuff above, he could probably spend it elsewhere where he needs it most.

I think services in the cloud/clean pipes makes a lot of sense.  I'd sure as hell like to invest less in commoditizing functions at the perimeter and on my desktop.  I'm just not sure we're going to get there anytime soon.

/Hoff

*Image Credit: CleanPipes

Breaking News: SOA, Web services security hinge on XML gateways!

Bloody Hell!

The article below is dated today, but perhaps this was just the TechTarget AutoBlogCronPoster gone awry from 2004? 

Besides the fact that this revelation garners another vote for the RationalSecurity "Captain Obvious" (see right) award, the simple fact that XML gateways as a stand-alone market are being highlighted here is laughable -- especially since the article clearly shows the XML Security Gateways are being consolidated and bundled with application delivery controllers and WAF solutions by vendors such as IBM and Cisco.

XML is, and will be everywhere.  SOA/Web Services is only one element in a greater ecosystem impacted by XML.

Of course the functionality provided by XML security gateways are critical to the secure deployment of SOA environments; they should be considered table stakes, just like secure coding...but of course we know how consistently-applied compensating controls are painted onto network and application architectures. 

The dirty little secret is that while they are very useful and ultimately an excellent tool in the arsenal, these solutions are disruptive, difficult to configure and maintain, performance pigs and add complexity to an already complex model.  In many cases, asking a security team to manage this sort of problem introduces more operational risk than it mitigates. 

Can you imagine security, network and developers actually having to talk to one another?!  *gasp*

Here is the link to the entire story.  I've snipped pieces out for relevant mockery.

ORLANDO, Fla. -- Enterprises are moving forward with service oriented architecture (SOA) projects to reduce complexity and increase flexibility between systems and applications, but some security pros fear they're being left behind and must scramble to learn new ways to protect those systems from Web-based attacks.

<snip>

"Most network firewalls aren't designed to handle the latest Web services standards, resulting in new avenues of attack for digital miscreants, said Tim Bond, a senior security engineer at webMethods Inc. In his presentation at the Infosec World Conference and Expo, Bond said a growing number of vendors are selling XML security gateways, appliances that can be plugged into a network and act as an intermediary, decrypting and encrypting Web services data to determine the authenticity and lock out attackers.

"It's not just passing a message through, it's actually taking action," Bond said. "It needs to be customized for each deployment, but it can be very effective in protecting from many attacks."

Bond said that most SOA layouts further expose applications by placing them just behind an outer layer of defense, rather than placing them within the inner walls of a company's security defenses along with other critical applications and systems. Those applications are vulnerable, because they're being exposed to partners, customer relationship management and supply chain management systems. Attackers can scan Web services description language (WSDL) -- the XML language used in Web service calls -- to find out where vulnerabilities lie, Bond said.

<snip>

A whole market has grown around protecting WSDL, Bond said. Canada-based Layer 7 Technologies Inc. and UK-based Vordel are producing gateway appliances to protect XML and SOAP language in Web service calls. Reactivity, which was recently acquired by Cisco Systems Inc. and DataPower, now a division of IBM, also address Web services security.

Transaction values will be much higher and traditional SSL, security communications protocol for point-to-point communications, won't be enough to protect transactions, Bond said.

<snip>

In addition to SQL-injection attacks, XML is potentially vulnerable to schema poisoning -- a method of attack in which the XML schema can be manipulated to alter processing information. A sophisticated attacker can also conduct an XML routing detour, redirecting sensitive data within the XML path, Bond said.

Security becomes complicated with distributed systems in an SOA environment, said Dindo Roberts, an application security manager at New York City-based MetLife Inc. Web services with active interfaces allow the usage of applications that were previously restricted to using conventional custom authentication. Security pros need new methods, such as an XML security gateway to protect those applications, Roberts said.

<snip>

Another Virtualized Solution for VM Security...

I got an email reminder from my buddy Grant Bourzikas today pointing me to another virtualized security solution for servers from Reflex Security called Reflex VSA.  VSA stands for Virtual Security Appliance and the premise appears to be that you deploy this software within each guest VM and it provides what looks a lot like host-based intrusion prevention functionality per VM.

The functionality is defined thusly:

Reflex VSA solves the problem that traditional network security such as IPS and firewall appliances currently can not solve: detecting and preventing attacks within a virtual server. Because Reflex VSA runs as virtualized application inside the virtualized environment, it can detect and mitigate         threats between virtual hosts and networks.

Reflex VSA Features:
        • Access firewall for permission enforcement for intra-host and external network
           communication
        • Intrusion Prevention with inline blocking and filtering for virtualized networks
        • Anomaly, signature, and rate-based threat detection capability        
        • Network Discovery to discover and map all virtual machines and applications
        • Reflex Command Center, providing a centralized configuration and management
           console, comprehensive reporting tools, and real-time event aggregation and
           correlation   

It does not appear to wrap around or plug-in to the HyperVisor natively, so I'm a little confused as to the difference between deploying VSA and whatever HIPS/NIPS agent a customer might already have deployed on "physical" server instantiations.

Blue Lane's product addresses this at the HyperVisor layer and it would be interesting to me to have the pundits/experts argue the pros/cons of each approach. {Ed. This is incorrect.  Blue Lane's product runs as a VM/virtual appliance also.  With the exposure via API of the hypervisor/virtual switches, products like Blue Lane and Reflex would take advantage to be more flexible, effective and higher performing.}

I'm surprised most of the other "security configuration management" folks haven't already re-branded their agents as being "Virtualization Compliant" to attack this nascent marketspace. < :rolleyes here: >

It's good to see that folks are at least owning up to the fact that intra-VM communications via virtual switches are going to drive a spin on risk models, detection and mitigation tools and techniques.  This is what I was getting at in this blog entry here.

I would enjoy speaking to someone from Reflex to understand their positioning and differentiation better, but isn't this just HIPS per VM?  How's that different than firewall, AV, etc. per VM?

/Hoff

Blue Lane VirtualShield for VMWare - Here we go...

Greg Ness from Blue Lane and I have known each other for a while now, and ever since I purchased Blue Lane's first release of products a few years ago (when I was on the "other" side as a *gasp* customer) I have admired and have taken some blog-derived punishment for my position on Blue Lane's technology.

I have zero interest in Blue Lane other than the fact that I dig their technology and products and think it solves some serious business problems elegantly and efficiently with a security efficacy that is worth its weight in gold.

Vulnerability shielding (or patch emulation...) is a provocative subject and I've gone 'round and 'round with many a fine folk online wherein the debate normally dissolves into the intricacies of IPS vs. vulnerability shielding versus the fact that the solutions solve a business problem in a unique way that works and is cost effective.

That's what a security product SHOULD do.  Yet I digress.

So, back to Greg @ Blue Lane...he let me know a few weeks ago about Blue Lane's VirtualShield offering for  VMWare environments.  VirtualShield is the first commercial product that I know of that specifically tackles problems that everyone knows exists in VM environments but have, until now, sat around twirling thumbs at.

In fact, I alluded to some of these issues in this blog entry regarding the perceived "dangers" of virtualization a few weeks ago.

In short, VirtualShield is designed to protect guest VM's running under a VMWare ESX environment in the following manner (and I quote):

• Protects virtualized servers regardless of physical location or patch-level;
• Provides up-to-date protection with no configuration changes and no agent installation on each virtual machine;
• Eliminates remote threats without blocking legitimate application requests or requiring server reboots; and
• Delivers appropriate protection for specific applications without requiring any manual tuning.

VS basically sits on top of the HyperVisor and performs a similar set of functionality as the PatchPoint solution does for non-VM systems.

Specifically, VirtualShield discovers the virtual servers running on a server and profiles the VM's, the application(s), ports and protocols utilized to build and provision the specific OS and application protections (vulnerability shielding) required to protect the VM.

I think the next section is really the key element of VirtualShield:

As traffic flows through VirtualShield inside the hypervisor, individual sessions are decoded and monitored for vulnerable conditions. When necessary, VirtualShield can replicate the function of a software security patch by applying a corrective action directly within the network stream, protecting the downstream virtual server.

As new security patches are released by software application vendors, VirtualShield automatically downloads the appropriate inline patches from Blue Lane. Updates may be applied dynamically without requiring any reboots or reconfigurations of the virtual servers, the hypervisor, or VirtualShield.

While one might suggest that vulnerability shielding is not new and in some cases certain functionality can be parlayed by firewalls, IPS, AV, etc., I maintain that the manner and model in which Blue Lane elegantly executes this compensating control is unique and effective.

If you're running a virtualized server environment under VMWare's ESX architecture, check out VirtualShield...right after you listen to the virtualization podcast with yours truly from RSA.

/Hoff

Virtualization is Risky Business?

Over the last couple of months, the topic of virtualization and security (or lack thereof) continues to surface as one of the more intriguing topics of relevance in both the enterprise and service provider environments and those who cover them.  From bloggers to analysts to vendors, virtualization is a greenfield for security opportunity and a minefield for the risk models used to describe it.

There are many excellent arguments being discussed which highlight in an ad hoc manner the most serious risks posed by virtualization, and I find many of them accurate, compelling, frightening and relevant.  However, I find that overall, to gauge in relative terms the impact  that these new combinations of attack surfaces, vectors and actors pose, the risk model(s) are immature and incomplete. 

Most of the arguments are currently based on hyperbole and anecdotal references to attacks that could happen.  It reminds me much of the ballyhooed security risks currently held up for scrutiny for mobile handsets.  We know bad things could happen, but for the most part, we're not being proactive about solving some of the issues before they see the light of day.

The panel I was on at the RSA show highlighted this very problem.  We had folks from VMWare and
RedHat in the audience who assured us that we were just being Chicken Little's and that the risk is
both quantifiable and manageable today.  We also had other indications that customers felt that while the benefits for virtualization from a cost perspective were huge, the perceived downside from the unknown risks (mostly theoretical) were making them very uncomfortable.

Out of the 150+ folks in the room, approximately 20 had virtualized systems in production roles.  About 25% of them had collapsed multiple tiers of an n-tier application stack (including SOA environments) onto a single host VM.  NONE of them had yet had these systems audited by any third party or regulatory agency.

Rot Roh.

The interesting thing to me was the dichotomy regarding the top-down versus bottom-up approach to
describing the problem.  There was lots of discussion regarding hypervisor (in)security and privilege
escalation and the like, but I thought it interesting that most people were not thinking about the impact on the network and how security would have to change to accommodate it from a bottoms-up (infrastructure and architecture) approach.

The notions of guest VM hopping and malware detection in hypervisors/VM's are reasonably well discussed (yet not resolved) so I thought I would approach it it from the perspective of what role, if any, the traditional  network infrastructure plays in this.

Thomas Ptacek was right when he said "...I also think modern enterprises are so far from having reasonable access control between the VLANs they already use without virtualization that it’s not a “next 18 month” priority to install them." And I agree with him there.  So, I posit that if one accepts this as true then what to do about the following:

If now we see the consolidation of multiple OS and applications on a single VM host in which the bulk of traffic and data interchange is between the VM's themselves and utilize the virtual switching fabrics in the VM Host and never hit the actual physical network infrastructure, where, exactly, does this leave the self-defending "network" without VM-level security functionality at the "micro perimeters" of the VM's?

I recall a question I asked at a recent Goldman Sachs security conference where I asked Jayshree Ullal from Cisco who was presenting Cisco's strategy regarding virtualized security about how their approach to securing the network was impacted by virtualization in the situation I describe above. 

You could hear cricket's chirp in the answer.

Talk amongst yourselves....

P.S. More excellent discussions from Matasano (Ptacek) here and Rothman's bloggy.  I also recommend Greg Ness' commentary on virtualization and security @ the HyperVisor here.

Upchuck, Shrubbery, Bumps-in-the-wire & Alan does the "Shimmy"

Alan and I normally are close enough on our positions that I don't feel it necessary to argue with him.

I certainly don't feel compelled to come to the defense of a competitor that Alan's unloading on, but I'm really confused about his interpretation of what TippingPoint's Chief Architect, Brian Smith, is communicating and where Alan suggests that he and StillSecure's position lays.

To re-cap, Brian Smith was quoted in an SC Magazine Article as describing his views on how security ought to be positioned in the network thusly:

"Brian Smith, the chief architect of 3Com and a founder of TippingPoint, says his first-ever RSA keynote will focus on integrating solutions such as network access control, intrusion prevention and behavioral anomaly detection to create an intelligent network.

"I can do all of these sorts of synergies and when you trace it out, what ends up happening is you're able to debug network problems that you were never able to do before, get an unprecedented level of security, and also lower the total cost of ownership," Smith says. "They have to talk to each other. If we can pull all of these solutions together, I think that's going to be the trend over the next five to 10 years. It's a natural evolution in the technology cycle."

Smith says he also plans to emphasize the benefits of the bump-in-the-wire network approach to deploying security solutions. Rather than embedding solutions into switchers and routers, Smith plans to suggest overlaying solutions to allow for a more converged, cheaper way to add intelligence to the network."

Amen to that.  But lest you think I am intimating that we should all just toss appliances willy-nilly across the network (in fact, that's the opposite of what I think,) please read on...

Apparently it was the third (boldfaced) paragraph that got Alan's goat and provoked him into a state of up-chuckedness.  Specifically, it seems that it is repugnant to Alan that someone who works for a "switch" company could suggest that overlaying security can be facilitated as a "bump-in-the wire."  I guess that depends upon your interpretation of "bump-in-the-wire." 

I'm guessing that Alan thinks that means individual appliances being inserted between network segments with one "goesinta" and one "goesouta" cable and yet I can't figure out why  "...virtualizing some of this stuff and putting it on blades and so forth" has to be within the router or switch and not on an extensible services platform?

I have a feeling I'm going to hear the typical "not everyone can afford big iron" as a response...but if you can generalize to prove a point, I can become surgical and suggest that it's not fair to treat the Global 2000, Carriers, Service Providers and Mobile Operators as an exception rather than the rule when it comes to describing security trends and markets, either.

Summarily, it appears that the "convergence" of networking and security in Alan's eyes means that security functionality MUST be integrated into routers and switches in order to be successful and that adding security functionality on top of or in conjunction with the network is a lousy idea.

Strange comments from a guy whose company takes generic PC appliances  with security software on them and deploys them as bumps in the wire by sprinkling them across the network -- usually at the cursed perimeter and not at the core.  Confused?  So am I.

Alan goes on:

Most of the guys who do the bump in the wire are trying like hell to move up the stack and the network to get away from the edge to the core.  You may be able to do IPS as a bump in the wire at the core if you have the horsepower, but you are going to be forced to the edge for other security stuff if you insist on bump in the wire.  Single point of failure, scalability and cost are just working against you. Eventually you have to turn to the switch. I just don't get where he is coming from here.

So you're saying that your business model is already dead, Alan?

The final piece of irony is this:

Has selling big-ass, honking ASIC boxes to do IPS for so long totally blinded them to virtualizing some of this stuff and putting it on blades and so forth inside the switch and network.

Um, no. Again, not like I feel any inclination to defend Tippingpoint, but it's apparent that Alan is not aware of TippingPoint's M60 which is a huge multi-gigabit LAN switching platform (10-14 slots) with integrated IPS (and other functionality) that can either replace a typical switch or connect to existing switch fabrics to form an overlay security service.  It's about a year overdue from the last announcement, but the M60 is an impressive piece of iron:

Each blade in the M60 acts as a stand-alone IPS device, similar to TippingPoint's T-series appliances, in which network connectivity and IPS packet processing are done on the hardware. (The exception is with 10G interfaces; the M60 uses 3Com's 8800 dual-port 10G blades, which connect to TippingPoint IPS blades through the switch's backplane.)

The blades run 3Com's TippingPoint IPS device operating system and use the vendor's Digital Vaccine updating service, letting  the device identify the latest threat signatures and vulnerabilities.

This was one of the results of the Huawei joint venture with 3Com.  I believe that THIS is really what Brian Smith is talking about, not device sprinkling appliances.  It's  a switch.  It's an IPS.  That's bad, how?

What has me confused is that if Alan is so against hanging security services/functions OFF a switch, why did StillSecure do the deal with Extreme Networks in which the concept is to hang an appliance (the Sentriant AG) off the switch as an appliance instead of "inside" it like he suggests is the only way to effectively demonstrate the convergence of networking and security?

So, I totally get Brian Smith's comments (despite the fact that he's a competitor AND works for a switch vendor -- who, by the way, also OEM'd Crossbeam's X-Series Security Services Switches prior to their Tippingpoint acquisition!)

The model is valid.  Overlaying security as an intelligent service layer on top of the network is a great approach.  Ask me how I know. ;)

Chris

IDS is dead, NAC doesn't work...long live UTM? Welcome Back to the Vendor Cesspool, Mr. Stiennon...

I smell blood.  This will be a very fun next couple of months.  Why?

In case you haven't heard, Richard Stiennon has announced that after his provoking and inciteful rant (sorry, Mike) against Check Point, Ken Xie from Fortinet wooed him back to the darkside and he's going to join them as their newly-titled Chief Marketing Officer.  Timing is everything, eh?

The esteemed Mr. Stiennon is a really smart guy and I am honestly looking forward to seeing how and what he does @ Fortinet.  It will be thought-provoking for sure.

So much for the niceties...Richard's railed on me previously about how big honkin' UTM boxes aren't the answer to security but I reckon that's going to change -- or spin -- now that he works for a vendor that sells (amongst mostly SMB/SME solutions) big honkin' UTM boxes.

We really had a good time going at each other in regards to NAC and his Secure Network Fabric (SNF) positioning and it lead to a podcast debate on Martin McKeay's blog, also.  I am eager to see how, or if, Fortinet's strategy changes once Richard gets his hands on the positioning and messaging.

Fortinet really doesn't compete in the "...high-end enterprise, carrier and managed service provider" space, but their ATCA-based chassis products are certainly positioned to play there.  He's got his work cut out for him. 

I forecast that Fortinet's high-end ATCA-based product line will be the soapbox from atop which Richard continues to evangelize his SNF strategy -- but instead of "embedding" security in the switching fabric, it will be overlaid with big honkin' UTM boxes, despite his prior arguments to the contrary.  I further prognosticate that we'll see PR regarding relationships with switch vendors like what Shimmy @ StillSecure did with Extreme...

Either way, it's going to be entertaining.

Congrats on the job, Richard.  At least I don't have to listen to your "...I'd rather debate with independent analysts" comments anymore. ;)  Looking forward to our continued interaction.

Chris