Rational Survivability

Big Iron is Dead...Long Live Big Iron?

Over the last 5 years or so with the pronounced emergence of inexpensive multi-core COTS compute platforms and the rabid evangelism of virtualization, I have debated many times with folks who continue to suggest that "big iron" -- high performance equipment in the compute, network, security and storage domains -- is now "extinct" and that nobody buys bespoke equipment any more.

Many of them argued "All you need is a COTS PC, package up OS/Applications and voila!  Instant appliance!  Ready for the edge, ready for the core."

Not surprisingly, many of the networking/security/application delivery companies that these folks worked for ultimately introduced custom-engineered hardware solutions, melding their software with custom hardware and COTS elements to produce a piece of big iron of their own...

About a year ago, I wrote a blog on this topic highlighted by a post titled "All your COTS multicore CPU's with non-optimized security software are belong to us," in which I extrapolated some very interesting points regarding Moore's law and the hubris surrounding the gluttony of compute power offered by higher density chipsets without the corresponding software architecture to take advantage of it.

Update: I forgot that I wrote a really good post (this March!) on this same topic titled "I Love the Smell Of Big Iron In the Morning..."

This is a little tickler to that post.

I come from the land of servicing large enterprises, service providers, municipalities and nation states  and not the SME. 

While there are certainly exceptions to the "rule," and it's reasonable to suggest that my perspective is skewed, I've always been careful to ensure I framed my discussions this way, so debating/contrasting the architectural slants of an SME with a Fortune 10 doesn't really move the discussion along any.

So, sticking with the large enterprise theme, there are two interesting divergent themes emerging: the centralization of compute and storage with the distributed nature of connectivity and information.

Without muddying the water too much about how these scenarios are not all that mutually exclusive, let's stick with the "centralization" theme for a moment.

The mainstream adoption of virtualization as an enabler brings us full-circle back around to the centralized mainframe model* of compute, networking and storage.  Now that reasonably reliable, high speed and low latency connectivity is available, centralization of resources makes sense since people can generally get access to the assets they require and the performance to get from point A to point B is for the most part acceptable (and getting more so.)

Once again, the natural consolidation of functionality and platform architecture follows suit -- we're back to using big iron to deliver the balance of cost, resilience, performance and simplified management that goes along with squeezing more from less.

To wit, let's examine some recent virtualization-inspired, big iron plays:

Compute:

HP introduced [recently] the Proliant BL495c G5, the first blade designed to be a virtual machine-intensive host in a data center rack, along with other virtualization products to enhance the offerings of VMware and Citrix Systems.

As system administrators achieve savings by consolidating 8-10 virtual machines per server, HP is saying its new blade will host up to 32 virtual machines, based on each virtual machine needing a minimum of four Gigabytes of memory. When 16 of the blades are stacked in an HP C7000 enclosure, a total of 512 virtual machines can be run from a single rack, said Jim Ganthier, director of HP BladeSystem, its blade server division.

Network & Storage:

The Cisco Nexus 7000 Series is the flagship member of the Cisco Nexus Family, the first in a new data center class of switching products. The Nexus 7000 is a highly scalable modular platform that delivers up to 15 terabits per second of switching capacity in a single chassis, supporting up to 512 10-gigabits-per-second (Gbps) Ethernet and future delivery of 40- and 100-Gbps Ethernet. Its unified fabric architecture combines Ethernet and storage capabilities into a single platform, designed to provide all servers with access to all network and storage resources. This enables data center consolidation and virtualization. Key components of the unified fabric architecture include unified I/O interfaces and Fibre Channel over Ethernet support to be delivered in the future.

Security:

The Crossbeam X-Series is a carrier-class modular security services switch.  The X80 platform is Crossbeam's flagship high-end security services platform for complete network, security.  The X80 provides up to 40 Gigabit Ethernet ports and 8 x 10 Gigabit Ethernet ports or up to 64 Fast Ethernet ports and up to 40 Gbps of full duplex firewall throughput.  Each network processor module features an integrated 16-core MIPS-64 security processor, a high speed network processor and a custom-designed switch fabric FPGA.  The X80 supports up to 10 application processor modules which are based on Intel technology running a hardened version of Linux supporting best-in-breed security software from leading vendors in highly resilient, load-balanced configurations.

These are just a few examples.

Each of these solutions delivers the benefits of hefty amounts of virtualized service, but what you'll notice is that they do so in massive scale, offering consolidated services in high-density "big iron" configurations for scale, resilience, manageability and performance.

In this period of the technology maturity cycle, we'll see this trend continue until we hit a plateau or an inflection point -- whether it is triggered due to throughput, power, heat, latency, density or whatnot.  Then we'll start anew and squeeze the balloon once more, perhaps given what I hinted at above with clusters of clouds that define an amporphous hive of virtualized big iron.

But for now, until service levels, reliability, coherence and governance are sorted, I reckon we'll see more big iron flexing it's muscle in the data center.

What about you?  Are you seeing the return of big iron in your large enterprise.  Perhaps it never left?

I for one welcome my new blinking dark overlord...

/Hoff

* There's even a resurgence of the mainframe itself lately.  See IBM's z/10 and Unisys' ClearPath for example.

Security Will Not End Up In the Network...

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

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

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

Confused?

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

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

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

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

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

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

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

Why?

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

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

'Round and 'round we go.

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

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

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

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

/Hoff

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/Hoff

Pondering Implications On Standards & Products Due To Cold Boot Attacks On Encryption Keys

You've no doubt seen the latest handywork of Ed Felten and his team from the Princeton Center for Information Technology Policy regarding cold boot attacks on encryption keys:

Abstract: Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at operating temperatures and even if removed from a motherboard. Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access. We use cold reboots to mount attacks on popular disk encryption systems — BitLocker, FileVault, dm-crypt, and TrueCrypt — using no special devices or materials. We experimentally characterize the extent and predictability of memory remanence and report that remanence times can be increased dramatically with simple techniques. We offer new algorithms for finding cryptographic keys in memory images and for correcting errors caused by bit decay. Though we discuss several strategies for partially mitigating these risks, we know of no simple remedy that would eliminate them.

Check out the video below (if you have scripting disabled, here's the link.)  Fascinating and scary stuff.

Would a TPM implementation mitigate this if they keys weren't stored (even temporarily) in RAM?

Given the surge lately toward full disk encryption products, I wonder how the market will react to this.  I am interested in both the broad industry impact and response from vendors.  I won't be surprised if we see new products crop up in a matter of days advertising magical defenses against such attacks as well as vendors scrambling to do damage control.

This might be a bit of a reach, but equally as interesting to me are the potential implications upon DoD/Military crypto standards such as FIPS140.2 ( I believe the draft of 140.3 is circulating...)  In the case of certain products at specific security levels, it's obvious based on the video that one wouldn't necessarily need physical access to a crypto module (or RAM) in order to potentially attack it.

It's always amazing to me when really smart people think of really creative, innovative and (in some cases) obvious ways of examining what we all take for granted.

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

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

Follow-Up to My Cisco/VMWare Commentary

 

Thanks very much to whomsoever at Cisco linked to my previous post(s) on Cisco/VMware and the Data Center 3.0 on the Cisco Networkers website! I can tell it was a person because they misnamed my blog as "Regional Security" instead of Rational Security... you can find it under the Blogs section here. ;)

The virtualization.info site had an interesting follow-up to the VMware/Cisco posts I blogged about previously.

DataCenter 3.0 is Actually Old?

Firstly, in a post titled "Cisco announces (old) datacenter automation solution" in which they discuss the legacy of the VFrame product in which they suggest that VFrame is actually a re-branded and updated version software from Cisco's acquisition of TopSpin back in 2005:

Cisco is well resoluted to make the most out of virtualization hype: it first declares Datacenter 3.0 initiative (more ambitiously than IDC, which claimed Virtualization 2.0), then it re-launches a technology obtained by TopSpin acquisition in April 2005 and offered since September 2005 under new brand: VFrame.

Obviously the press release doesn't even mention that VFrame just moved from 3.0 (which exist since May 2004, when TopSpin was developing it) to 3.1 in more than three years.

In the same posting, the ties between Cisco and VMWare are further highlighted:

A further confirmation is given by fact that VMware is involved in VFrame development program since May 2004, as reported in a Cisco confidential presentation of 2005 (page 35).

Cisco old presentation also adds a detail about what probably will be announced at VMworld, and an interesting claim:

...VFrame can provision ESX Servers over SAN.

...VMWare needs Cisco for scaling on blades...

This starts helping us understand even further as to why Mr. Chambers will be keynoting at VMWorld'07.

Meanwhile, Cisco Puts its Money where its Virtual Mouth Is

Secondly, VMware announced today that Cisco will invest $150 Million in VMware:

Cisco will purchase $150 million of VMware Class A common shares currently held by EMC Corporation, VMware's parent company, subject to customary regulatory and other closing conditions including Hart-Scott-Rodino (HSR) review. Upon closing of the investment, Cisco will own approximately 1.6 percent of VMware’s total outstanding common stock (less than one percent of the combined voting power of VMware’s outstanding common stock).  VMware has agreed to consider the appointment of a Cisco executive to VMware's board of directors at a future date.

Cisco’s purchase is intended to strengthen inter-company collaboration towards accelerating customer adoption of VMware virtualization products with Cisco networking infrastructure and the development of customer solutions that address the intersection of virtualization and networking technologies. 

In addition, VMware and Cisco have entered into a routine and customary collaboration agreement that expresses their intent to expand cooperative efforts around joint development, marketing, customer and industry initiatives.  Through improved coordination and integration of networking and virtualized infrastructure, the companies intend to foster solutions for enhanced datacenter optimization and extend the benefits of virtualization beyond the datacenter to remote offices and end-user desktops.

If should be crystal clear that Cisco and EMC are on a tear with regards to virtualization and that to Cisco, "bits is bits" and virtualizing those bits across the app. stack, network, security and storage departments coupled with a virtualized service management layer is integral to their datacenter strategy.

It's also no mystery as to why Mr. Chambers is keynoting @ VMWorld now, either.

/Hoff

Cisco Responds to My Data Center Virtualization Post...

"...I will squash him like a liiiiittle bug, that Hoff!"

OK, well they weren't responding directly to my post from last night, but as they say in the big show, "timing is everything."

My last blog entry detailed some navel gazing regarding some interesting long term strategic moves by Cisco to further embrace the virtualized data center and the impact this would have on the current and future product roadmaps.  I found it very telling that Chambers will be keynoting at this year's VMWorld and what this means for the future.

Not 8 hours after my posting (completely coincidental I'm sure ;) the PR machine spit out the following set of announcements from Networkers Cisco Live titled "Cisco Unveils Plans to Transform the Data Center."    You can find more detailed information from Cisco's web here.

This announcement focused on outlining some of the near-term (2 year) proofpoints and touts the introduction of "...New Data Center Products, Services and Programs to Support a Holistic View of the Data Center." 

There's an enormous amount of data to digest in this announcement, but the interesting bits for me to focus on are the two elements pertaining to security virtualization as well as service composition, provisioning and intelligent virtualized service delivery.   This sort of language is near and dear to my heart.

I'm only highlighting a small subsection of the release as there is a ton of storage, data mobility, multiservice fabric and WAAS stuff in there too.  This is all very important stuff, but I wanted to pay attention to the VFrame Data Center orchestration platform and the ACE XML security gateway functions since they pertain to what I have been writing about recently:

If you can choke back the bile from the  "Data Center v3.0" moniker:

...Cisco announced at a press conference today its vision for next-generation data centers, called Data Center 3.0. The Cisco vision for Data Center 3.0 entails the real-time, dynamic orchestration of infrastructure services from shared pools of virtualized server, storage and network resources, while optimizing application performance, service levels, efficiency and collaboration.
...

Over the next 24 months, Cisco will deliver innovative new products, programs, and capabilities to help customers realize the Cisco Data Center 3.0 vision. New products and programs announced today support that vision, representing the first steps in helping customers to create next-generation data centers.

Cisco VFrame Data Center

VFrame Data Center (VFrame DC) is an orchestration platform that leverages network intelligence to provision resources together as virtualized services. This industry-first approach greatly reduces application deployment times, improves overall resource utilization, and offers greater business agility. Further, VFrame DC includes an open API, and easily integrates with third party management applications, as well as best-of-breed server and storage virtualization offerings.

With VFrame DC, customers can now link their compute, networking and storage infrastructures together as a set of virtualized services. This services approach provides a simple yet powerful way to quickly view all the services configured at the application level to improve troubleshooting and change management. VFrame DC offers a policy engine for automating resource changes in response to infrastructure outages and performance changes. Additionally, these changes can be controlled by external monitoring systems via integration with the VFrame DC web services application programming interface (API).

I think that from my view of the world, these two elements represent a step in the right direction for Cisco.  Gasp!  Yes, I said it.  While Chambers prides himself on hyping Cisco's sensitivity to "market transitions" it's clear that Cisco gets that virtualization across both the network, host and storage is actually a real market.  They're still working the security piecem however they, like Microsoft, mean business when they enter a space and it's no doubt they're swinging to fences with VFrame. 

I think the VFrame API is critical and how robust it is will determine the success of VFrame.  It's interesting that VFrame is productized as an appliance, but I think I get what Chambers is going to be talking about at VMWorld -- how VFrame will interoperate/interact with VMWare provisioning and management toolsets. 

Interestingly, the UI and template functionality looks a hell of a lot like some others I've blogged about and is meant to provide an umbrella management "layer" that allows for discovery, design, provisioning, deployment and automation of services and virtualized components across resource pools of servers, network components, security and storage:

Cisco VFrame Data Center components include:

• Cisco VFrame Data Center Appliance: Central controller that connects to Ethernet and Fibre Channel networks
• Cisco VFrame Data Center GUI: Java-based client that accesses application running on VFrame Data Center Appliance
• Cisco VFrame Web Services Interface and Software Development Kit: Programmable interface that allows scripting of actions for Cisco VFrame Data Center
• Cisco VFrame Host Agent: Host agent that provides server heartbeat, capacity utilization metrics, shutdown, and other capabilities
• Cisco VFrame Data Center Macros: Open interface that allows administrators to create custom provisioning actions

That's ambitious to say the least.

It's still a raucous debate with me regarding where a lot of this stuff belongs (in the network or as a service layer) and I maintain the latter.  Innovation driven by companies such as 3Tera demonstrate that the best ideas are always copied by the 800 pound gorillas once they become mainstream.

Enhanced Cisco ACE XML Gateway Software

The new Cisco Application Control Engine (ACE) Extensible Markup Language (XML) Gateway software delivers enhanced capabilities for enabling secure Web services, providing customers with better management, visibility, and performance of their XML applications and Web 2.0 services. The new software includes a wide variety of new capabilities and features plus enhanced performance monitoring and reporting, providing improved operations and capacity planning for Web services secured by the Cisco ACE XML Gateway.

I'd say this is a long overdue component for Cisco; since Chambers has been doing nothing but squawking about Web2.0, collaboration, etc., the need to integrate XML security into the security portfolio is a must, especially as we see XML as the Internet-based messaging bus for just about everything these days.

All in all I'd say Cisco is doing a good job of continuing to push the message along and while one shouldn't see this faint praise as me softening my stance on Cisco's execution potential, it's yet to be seen if trying to be everything to everyone will deliver levels of service commensurate with what customers need.

Only time will tell.

/Hoff

 

Cisco & VMWare - The Revolution will be...Virtualized?

During my tour of duty at Crossbeam, I've closely tracked the convergence of the virtualization strategies of companies such as VMWare with Cisco's published long term product direction. 

One of the selfish reasons for doing so is that from a product-perspective, Crossbeam's platform provides a competitively open, virtualized routing and switching platform combined with a blade-based processing compute stack powered by a hardened, Linux based operating system that allows customers to run the security applications of their choice. 

This provides an on-demand security architecture allowing customers to simply add a blade in order to add an application service component when needed.

Basically this allows one to virtualize networking/transport, applications/security contexts and security policies across any area of the network into which this service layer is plumbed and control the flows in order to manipulate in serial or parallel the path traffic takes through these various security software components.

So that's the setup.  Yes, it's intertwined with a bit of a commercial, but hey...perhaps liberty and beer are your idea of "free," but my blogoliciousness ain't.  What's really interesting is some of the deeper background on the collision of traditional networking with server virtualization technology.

While it wasn't the first time we've heard it (and it won't be the last,) back in December 2006, Phil Hochmuth from Network World wrote an article that appeared on the front page which was titled "Cisco's IOS set for radical pricing, feature changes."  This article quoted Cliff Metzler, senior vice president of the company’s Network Management Technology Group as saying these very important words:

Cisco’s intention is to decouple IOS software from the hardware it sells, which could let users add enhancements such as security or VoIP more quickly, without having to reinstall IOS images on routers and switches. The vendor also plans to virtualize many of its network services and applications, which currently are tied to hardware-specific modules or appliances.

This shift would make network gear operate more like a virtualized server, running multiple operating systems and applications on top of a VMware-like layer, as opposed to a router with a closed operating system, in which applications are run on hardware-based blades and modules. Ultimately, these changes will make it less expensive to deploy and manage services that run on top of IP networks, such as security, VoIP and management features, Cisco says.

“The way we’ve sold software in the past is we’ve bolted it onto a piece of hardware, and we shipped [customers] the hardware,” Metzler said. “We need more flexibility to allow customers to purchase software and to deploy it according to their terms.” 

IOS upgrades require a reinstall of the new software image on the router or switch — which causes downtime — or, “we say, not a problem, UPS will arrive soon, here’s another blade” to run your new service or application, Metzler said. “This adds months to the deployment cycle, which is not good for customers or Cisco’s business.”

The article above fundamentally demonstrates the identical functional software-based architecture that Crossbeam offers for exactly the right reasons; make security simpler, less expensive, easier to manage and more flexible to deploy on hardware that scales performance-wise.

Now couple this with the announcement that John Chambers will be delivering a keynote at VMWorld and things get even more interesting in a hurry.  Alessandro Perilli over at the Virtualization.info blog shares his perspective on why this is important and what it might mean:

Chambers presence possibly means announcement of a major partnership between VMware and Cisco, which may be related to network equipment virtualization or endpoint security support.

Many customers in these years prayed to have capability to use virtual machines as routers inside VMware virtual networks. So far this has been impossible: despite Cisco proprietary IOS relies on standard x86 hardware, it still requires a dedicated EEPROM to work, which VMware doesn't include in its virtual hardware set. Maybe Cisco is now ready to virtualize its hardware equipment.

On the other side VMware may have a deal in place with Cisco about its Assured Computing Environment (ACE) product: Cisco endpoint security solution called Network Admission Control (NAC) may work with VMware ACE as an endpoint security agent, eliminating any need to install more software inside host or guest operating systems.

In any case a partnership between VMware and Cisco may greatly enhance virtual infrastructures capabilities.

This is interesting for sure and if you look at the way in which the demand for flexibility of software combined with generally-available COTS compute stacks and specific network processing where required, the notion that Cisco might partner with VMWare or a similar vendor such as SWSoft looks compelling.  Of course with functionality like KVM in the Linux kernel, there's no reason they have to buy or ally...

Certainly there are already elements of virtualization within Cisco's routing, switching and security infrastructure, but many might argue that it requires a refresh in order to meet the requirements of their customers.  It seems that their CEO does.

I think that this type of architecture looks promising.  Of course, you could have purchased it 6 years ago -- as you can today -- by talking to these folks. But I'm biased. ;)

/Hoff

The 4th Generation of Security Devices = UTM + Routing & Switching or New Labels = Perfuming a Pig?

That's it.  I've had it.  Again.  There's no way I'd ever make it as a Marketeer.  <sigh>

I almost wasn't going to write anything about this particular topic because my response can (and probably should) easily be perceived as and retorted against as a pissy little marketing match between competitors.  Chu don't like it, Chu don't gotta read it, capice?

Sue me for telling the truth. {strike that, as someone probably will}

However, this sort of blatant exhalation of so-called revolutionary security product and architectural advances disguised as prophecy is just so, well, recockulous, that I can't stand it.

I found it funny that the Anti-Hoff (Stiennon) managed to slip another patented advertising editorial Captain Obvious press piece in SC Magazine regarding what can only be described as the natural evolution of network security products that plug into -- but are not natively -- routing or switching architectures.

I don't really mind that, but to suggest that somehow this is an original concept is just disingenuous.

Besides trying to wean Fortinet away from the classification as UTM devices (which Richard clearly hates
to be associated with) by suggesting that UTM should be renamed as "Flexible Security Platform," he does a fine job of asserting that a "geologic shift" (I can only assume he means tectonic) is coming soon in the so-called fourth generation of security products.

Of course, he's completely ignoring the fact that the solution he describes is and has already been deployed for years...but since tectonic shifts usually take millions of years to culminate in something noticeably remarkable, I can understand his confusion.

As you'll see below, calling these products "Flexible Security Platforms" or "Unified Network Platforms" is merely an arbitrary and ill-conceived hand-waving exercise in an attempt to differentiate in a crowded market.  Open source or COTS, ASIC/FPGA or multi-core Intel...that's just the packaging and delivery mechanism.  You can tart it up all you want with fancy marketing...

It's not new, it's not revolutionary (because it's already been done) and it sure as hell ain't the second coming.  I'll say it again, it's been here for years.  I personally bought it and deployed it as a customer almost 4 years ago...if you haven't figured out what I'm talking about yet, read on.

Here's how C.O. describes what the company I work for has been doing for 6 years and that he intimates Fortinet will provide that nobody else can:

We are rapidly approaching the advent of the fourth generation security platform. This is a device that can do all of the security functions that are lumped in to UTM but are also excellent network devices at layers two and three. They act as a switch and a router. They supplant traditional network devices while providing security at all levels. Their inherent architectural flexibility makes them easy to fit into existing environments and even make some things possible that were never possible before. For instance a large enterprise with several business units could deploy these advanced networking/security devices at the core and assign virtual security domains to each business unit while performing content filtering and firewalling between each virtual domain, thus segmenting the business units and maximizing the investment in core security devices.

One geologic shift that will occur thanks to the advent of these fourth generation security platforms is that networking vendors will be playing catch up, trying to patch more and more security functions into their under-powered devices or complicating their go to market message with a plethora of boxes while the security platform vendors will quickly and easily add networking functionality to their devices.

Fourth generation network security platforms will evolve beyond stand alone security appliances to encompass routing and switching as well. This new generation of devices will impact the networking industry it scrambles to acquire the expertise in security and shift their business model from commodity switching and routing to value add networking and protection capabilities.

Let's see...combine high-speed network processing whose routing/switching architecture was designed by the same engineers that designed Bay/Welfleet's core routers, add in a multi-core Intel processing/compute layer which utilizes virtualized, load-balanced security applications as a  service layer that can be overlaid across a fast, reliable, resilient and highly-available network transport and what do you get?

This:

Up to 32 GigE or 64 10/100 switching ports and 40 Intel cores in a single chassis today...and in Q3'07 you'll also have the combination of our NextGen network processors which will provide up to 8x10GigE and 40xGigE with 64 MIPS Network Security cores combined with the same 40 Intel cores in the same chassis.

By the way, I consider that routing and switching are just table stakes, not market differentiators; in products like the one to the left, this is just basic expected functionality.

Furthermore, in this so-called next generation of "security switches," the customer should be able to run both open source as well as best-in-breed COTS security applications on the platform and not constrain the user to a single vendor's version of the truth running proprietary software.

-----

But wait, it only gets better...what I found equally as hysterical is the notion that Captain Obvious now has a sidekick!  It seems Alan Shimel has signed on as Richard's Boy Wonder.  Alan's suggesting that again, the magic bullet is Cobia and that because he can run a routing daemon and his appliance has more than a couple of ports, it's a router and a switch as well as a multi-function UTM UNP swiss army knife of security & networking goodness -- and he was the first to do it!  Holy marketing-schizzle Batman! 

I don't need to re-hash this.  I blogged about it here before.

You can dress Newt Gingrich up as a chick but it doesn't mean I want to make out with him...

This is cheap, cheap, cheap marketing on both your parts and don't believe for a minute that customers don't see right through it; perfuming pigs is not revolutionary, it's called product marketing.

/Hoff

Security Application Instrumentation: Reinventing the Wheel?

Two of my favorite bloggers engaged in a trackback love-fest lately on the topic of building security into applications; specifically, enabling applications as a service delivery function to be able to innately detect, respond to and report attacks.

Richard Bejtlich wrote a piece called Security Application Instrumentation and Gunnar Peterson chimed in with Building Coordinated Response In - Learning from the Anasazis.  As usual, these are two extremely well-written pieces and arrive at a well constructed conclusion that we need a standard methodology and protocol for this reporting.  I think that this exquisitely important point will be missed by most of the security industry -- specifically vendors.

While security vendor's hearts are in the right place (stop laughing,) the "security is the center of the universe" approach to telemetry and instrumentation will continue to fall on deaf ears because there are no widely-adopted standard ways of reporting across platforms, operating systems and applications that truly integrate into a balanced scorecard/dashboard that demonstrates security's contribution to service availability across the enterprise.   I know what you're thinking..."Oh God, he's going to talk about metrics!  Ack!"  No.  That's Andy's job and he does it much better than I.

This mess is exactly why the SEIM market emerged to clean up the cesspool of log dumps that spew forth from devices that are, by all approximation, utterly unaware of the rest of ecosystem in which they participate.  Take all these crappy log dumps via Syslog and SNMP (which can still be proprietary,) normalize if possible, correlate "stuff" and communicate that something "bad" or "abnormal" has occurred.

How does that communicate what this really means to the business, its ability to function, deliver servce and ultimately the impact on risk posture?  It doesn't because security reporting is the little kid wearing a dunce hat standing in the corner because it doesn't play well with others.

Gunnar stated this well:

Coordinated detection and response is the logical conclusion to defense in depth security architecture. I think the reason that we have standards for authentication, authorization, and encryption is because these are the things that people typically focus on at design time. Monitoring and auditing are seen as runtime operational acitivities, but if there were standards based ways to communicate security information and events, then there would be an opportunity for the tooling and processes to improve, which is ultimately what we need.

So, is the call for "security application instrumentation" doomed to fail because we in the security industry will try to reinvent the wheel with proprietary solutions and suggest that the current toolsets and frameworks which are available as part of a much larger enterprise management and reporting strategy not enough? 

Bejtlich remarked on the need for mechanisms that report application state must be built into the application and must report more than just performance:

Today we need to talk about applications defending themselves. When they are under attack they need to tell us, and when they are abused, subverted, or breached they would ideally also tell us

I would like to see the next innovation be security application instrumentation, where you devise your application to report not only performance and fault logging, but also security and compliance logging. Ideally the application will be self-defending as well, perhaps offering less vulnerability exposure as attacks increase (being aware of DoS conditions of course).

I would agree, but I get the feeling that without integrating this telemetry and the output metrics and folding it into response systems whose primary role is to talk about delivery and service levels -- of which "security" is a huge factor -- the relevance of this data within the visible single pane of glass of enterprise management is lost.

So, rather than reinvent the wheel and incrementally "innovate," why don't we take something like the Open Group's Application Response Measurement (ARM) standard, make sure we subscribe to a telemetry/instrumentation format that speaks to the real issues and enable these systems to massage our output in terms of the language of business (risk?) and work to extend what is already a well-defined and accepted enterprise response management toolset to include security?

To wit:

The Application Response Measurement (ARM) standard describes a common method for integrating enterprise applications as manageable entities. The ARM standard allows users to extend their enterprise management tools directly to applications creating a comprehensive end-to-end management capability that includes measuring application availability, application performance, application usage, and end-to-end transaction response time.

Or how about something like EMC's Smarts:

Maximize availability and performance of mission-critical IT resources—and the business services they support. EMC Smarts software provides powerful solutions for managing complex infrastructures end-to-end, across technologies, and from the network to the business level. With EMC Smarts innovative technology you can:

• Model components and their relationships across networks, applications, and storage to understand effect on services.
• Analyze data from multiple sources to pinpoint root cause problems—automatically, and in real time.
• Automate discovery, modeling, analysis, workflow, and updates for dramatically lower cost of ownership.

            

...add security into these and you've got a winner.   

There are already industry standards (or at least huge market momentum) around intelligent automated IT infrastructure, resource management and service level reporting. We should get behind a standard that elevates the perspective of how security contributes to service delivery (and dare I say risk management) instead of trying to reinvent the wheel...unless you happen to like the Hamster Wheel of Pain...

/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

Evan Kaplan and Co. (Aventail) Take the Next Step

So Aventail's being acquired by SonicWall?  I wish Evan Kaplan and his team well and trust that SonicWall will do their best to integrate the best of Aventail's technology into their own.  It's interesting that this news pops up today because I was just thinking about Aventail's CEO today as part of a retrospective of security over the last 10+ years.

I've always admired Evan Kaplan's messaging from afar and a couple of months ago I got to speak with him for an hour or so.  For someone who has put his stake in the ground the ground for last 11 years as a leader in the SSL VPN market, you might be surprised to know that Evan's perspective on the world of networking and security isn't limited to "tunnel vision" as one might expect.

One of my favorite examples of Evan's beliefs is this article in Network World back in 2005 that resonated so very much with me then and still does today.  The title of the piece is "Smart Networks are Not a Good Investment" and was a "face off" feature between Evan and Cisco's Rob Redford.

Evan's point here -- and what resonates at the core of what I believe should happen to security -- is that the "network" ought to be separated into two strata, the "plumbing" (routers, switches, etc.) and intelligent "service layers" (security being one of them.)

Evan calls these layers "connectivity" and "intelligence."

The plumbing should be fast, resilient, reliable, and robust providing the connectivity and the service layers should be agile, open, interoperable, flexible and focused on delivering service as a core competency.   

Networking vendors who want to leverage the footprint they already have in port density and extend their stranglehold single vendor version of the truth obviously disagree with this approach.  So do those who ultimately suggest that "good enough" is good enough.

Evan bangs the drum:

Network intelligence as promoted by the large network vendors is the Star Wars defense system of our time - monolithic, vulnerable and inherently unreliable. Proponents of smart networks want to extend their hegemony by incorporating application performance and security into a unified, super-intelligent infrastructure. They want to integrate everything into the network and embed security into every node. In theory, you would then have centralized control and strong perimeter defense.

Yup.  As I blogged recently, "Network Intelligence is an Oxymoron."  The port puppets will have you believe that you can put all this intelligence in the routers in switches and solve all the problems these platforms were never designed to solve whilst simultaneously scale performance and features against skyrocketing throughput requirements, extreme latency thresholds, emerging technologies and an avalanche of compounding threats and vulnerabilities...all from one vendor, of course.

While on the surface this sounds reasonable, a deeper look reveals that this kind of approach presents significant risk for users and service providers. It runs counter to the clear trends in network communication, such as today's radical growth in broadband and wireless networks , and increased virtualization of corporate networks through use of public infrastructure. As a result of these trends, much network traffic is accessing corporate data centers from public networks rather than the private LAN, and the boundaries of the enterprise are expanding. Companies must grow by embracing these trends and fully leveraging public infrastructure and the power of the Internet.

Exactly.  Look at BT's 21CN network architecture as a clear and unequivocal demonstration of this strategy; a fantastic high-performance, resilient and reliable foundational transport coupled with an open, agile, flexible and equally high-performance and scalable security service layer.  If BT is putting 18 billion pounds of their money investing in a strategy like this and don't reckon they can rely on "embedded" security, why would you?

Network vendors are right in recognizing and trying to address the two fundamental challenges of network communications: application performance and security. However, they are wrong in believing the best way to address these concerns is to integrate application performance and security into the underlying network.

The alternative is to avoid building increasing intelligence into the physical network, which I call the connectivity lane, and building it instead into a higher-level plane I call the intelligence plane.                      

The connectivity plane covers end-to-end network connectivity in its broadest sense, leveraging IPv4 and eventually IPv6 . This plane's characteristics are packet-level performance and high availability. It is inherently insecure but incredibly resilient. The connectivity plane should be kept highly controlled and standardized, because it is heavy to manage and expensive to build and update. It should also be kept dumb, with change happening slowly.

He's on the money here again.  Let the network evolve at its pace using standards-based technology and allow innovation to deliver service at the higher levels.  The network evolves much more slowly and at a pace that demands stability.  The experientially-focused intelligence layer needs to be much more nimble and agile, taking advantage of the opportunism and the requirements to respond to rapidly emerging technologies and threat/vulnerabilities.

Look at how quickly solutions like DLP and NAC have stormed onto the market.  If we had to wait for Cisco to get their butt in gear and deliver solutions that actually work as an embedded function within the "network," we'd be out of business by now.

I don't have the time to write it again, but the security implications of having the fox guarding the henhouse by embedding security into the "fabric" is scary.  Just look at the number of security vulnerabilities Cisco has had in their routing, switching, and security products in the last 6 months.  Guess what happens when they're all one?   I sum it up here and here as examples.

Conversely, the intelligence plane is application centric and policy driven, and is an overlay to the connectivity plane. The intelligence plane is where you build relationships, security and policy, because it is flexible and cost effective. This plane is network independent, multi-vendor and adaptive, delivering applications and performance across a variety of environments, systems, users and devices. The intelligence plane allows you to extend the enterprise boundary using readily available public infrastructure. Many service and product vendors offer products that address the core issues of security and performance on the intelligence plane.

Connectivity vendors should focus their efforts on building faster, easier to manage and more reliable networks. Smart networks are good for vendors, not customers.

Wiser words have not been spoken...except by me agreeing with them, of course ;)  Not too shabby for an SSL VPN vendor way back in 2005.

Evan, I do hope you won't disappear and will continue to be an outspoken advocate of flushing the plumbing...best of luck to you and your team as you integrate into SonicWall.

/Hoff

Network Security is Dead...It's All About the Host.

No, not entirely as it's really about the data, but I had an epiphany last week. 

I didn't get any on me, but I was really excited about the -- brace yourself -- future of security in a meeting I had with Microsoft.  It reaffirmed my belief that while some low-hanging security fruit will be picked off by the network, the majority of the security value won't be delivered by it.

I didn't think I'd recognize just how much of it -- in such a short time -- will ultimately make its way back into the host (OS,) and perhaps you didn't either.

We started with centralized host-based computing, moved to client-server.  We've had Web1.0, are in the  beginnings of WebX.0 and I ultimately believe that we're headed back to a centralized host-based paradigm now that the network transport is fast, reliable and cheap.

That means that a bunch of the stuff we use today to secure the "network" will gravitate back towards the host. I've used Scott McNealy's mantra as he intended it to in order to provide some color to conversations before, but I'm going to butcher it here. 

While I agree that in abstract the "Network is the Computer," in order to secure it, you're going to have to treat the "network" like an OS...hard to do.   That's why I think more and more security will make its way back to the actual "computer" instead.

So much of the strategy linked to large security vendors sees an increase in footprint back on the host.  It's showing back up there today in the guise of AV, HIPS, configuration management, NAC and Extrusion Prevention, but it's going to play a much, much loftier role as time goes on as the level of interaction and interoperability must increase.  Rather than put 10+ agents on a box, imagine if that stuff was already built in?

Heresy, I suppose.

I wager that the "you can't trust the endpoint" and "all security will make its way into the switch" crowds will start yapping on this point, but before that happens, let me explain...

The Microsoft Factor

I was fortunate enough to sit down with some of the key players in Microsoft's security team last week and engage in a lively bit of banter regarding some both practical and esoteric elements of where security has been, is now and will be in the near future. 

On the tail of Mr. Chambers' Interop keynote, the discussion was all abuzz regarding collaboration and WebX.0 and the wonders that will come of the technology levers in the near future as well as the, ahem, security challenges that this new world order will bring.  I'll cover that little gem in another blog entry.

Some of us wanted to curl up into a fetal position.  Others saw a chance to correct material defects in the way in which the intersection of networking and security has been approached.  I think the combination of the two is natural and healthy and ultimately quite predictable in these conversations.

I did a bit of both, honestly.

As you can guess, given who I was talking to, much of what was discussed found its way back to a host-centric view of security with a heavy anchoring in the continued evolution of producing more secure operating systems, more secure code, more secure protocols and strong authentication paired with encryption.

I expected to roll my eyes a lot and figured that our conversation would gravitate towards UAC and that a bulk-helping of vapor functionality would be dispensed with the normal disclaimers urging "...when it's available one day" as a helping would be ladled generously into the dog-food bowls the Microsofties were eating from.

I am really glad I was wrong, and it just goes to show you that it's important to consider a balanced scorecard in all this; listen with two holes, talk with one...preferably the correct one ;)

I may be shot for saying this in the court of popular opinion, but I think Microsoft is really doing a fantastic job in their renewed efforts toward improving security.  It's not perfect, but the security industry is such a fickle and bipolar mistress -- if you're not 100% you're a zero.

After spending all this time urging people that the future of security will not be delivered in the network proper, I have not focused enough attention on the advancements that are indeed creeping their way into the OS's toward a more secure future as  this inertia orthogonally reinforces my point.

Yes, I work for a company that provides network-centric security offerings.  Does this contradict the statement I just made?  I don't think so, and neither did the folks from Microsoft.  There will always be a need to consolidate certain security functionality that does not fit within the context of the host -- at least within an acceptable timeframe as the nature of security continues to evolve.  Read on.

The network will become transparent.  Why?

In this brave new world, mutually-authenticated and encrypted network communications won't be visible to the majority of the plumbing that's transporting it, so short of the specific shunts to the residual overlay solutions that will still be present to the network in forms of controls that will not make their way to the host, the network isn't going to add much security value at all.

The Jericho Effect

What I found interesting is that I've enjoyed similar discussions with the distinguished fellows of the Jericho Forum wherein after we've debated the merits of WHAT you might call it, the notion of HOW "deperimeterization," "reperimeterization," (or my favorite) "radical externalization,"  weighs heavily on the evolution of security as we know it.

I have to admit that I've been a bit harsh on the Jericho boys before, but Paul Simmonds and I (or at least I did) came to the realization that my allergic reaction wasn't to the concepts at hand, but rather the abrasive marketing of the message.  Live and learn.

Both sets of conversations basically see the pendulum effect of security in action in this oversimplification of what Jericho posits is the future of security and what Microsoft can deliver -- today:

Take a host with a secured OS, connect it into any network using whatever means you find
appropriate, without regard for having to think about whether you're on the "inside" or "outside." Communicate securely, access and exchange data in policy-defined "zones of trust" using open, secure, authenticated and encrypted protocols.

If you're interested in the non-butchered more specific elements of the Jericho Forum's "10 Commandments," see here.

What I wasn't expecting in marrying these two classes of conversation is that this future of security is much closer and notably much more possible than I readily expected...with a Microsoft OS, no less.   In fact, I got a demonstration of it.  It may seem like no big deal to some of you, but the underlying architectural enhancements to Microsoft's Vista and Longhorn OS's are a fantastic improvement on what we have had to put up thus far.

One of the Microsoft guys fired up his laptop with a standard-issue off-the-shelf edition of Vista,  authenticated with his smartcard, transparently attached to the hotel's open wireless network and then took me on a tour of some non-privileged internal Microsoft network resources.

Then he showed me some of the ad-hoc collaborative "People Near Me" peer2peer tools built into Vista -- same sorts of functionality...transparent, collaborative and apparently quite secure (gasp!) all at the same time.

It was all mutually authenticated and encrypted and done so transparently to him.

He didn't "do" anything; no VPN clients, no split-brain tunneling, no additional Active-X agents, no SSL or IPSec shims...it's the integrated functionality provided by both IPv6 and IPSec in the NextGen IP stack present in Vista.

And in his words "it just works."   Yes it does.

He basically established connectivity and his machine reached out to an reachable read-only DC (after auth. and with encryption) which allowed him to transparently resolve "internal" vs. "external" resources.  Yes, the requirements of today expect that the OS must still evolve to prevent exploit of the OS, but this too shall become better over time.

No, it obviously doesn't address what happens if you're using a Mac or Linux, but the pressure will be on to provide the same sort of transparent, collaborative and secure functionality across those OS's, too.

Allow me my generalizations -- I know that security isn't fixed and that we still have problems, but think of this as a half-glass full, willya!?

One of the other benefits I got form this conversation is the reminder that as Vista and Longhorn default to IPv6 natively (they can do both v4&v6 dynamically,) as enterprises upgrade, the network hardware and software (and hence the existing security architecture) must also be able to support IPv6 natively.  It's not just the government pushing v6, large enterprises are now standardizing on it, too.

Here are some excellent links describing the Nextgen IP stack in Vista, the native support for IPSec (goodbye VPN market,) and IPv6 support.

Funny how people keep talking about Google being a threat to Microsoft.  I think that the network giants like Cisco might have their hands full with Microsoft...look at how each of them are maneuvering.

/Hoff
{ Typing this on my Mac...staring @ a Vista Box I'm waiting to open to install within Parallels ;) }

Network Intelligence is an Oxymoron & The Myth of Security Packet Cracking

[Live from Interop's Data Center Summit]

Jon Oltsik crafted an interesting post today regarding the bifurcation of opinion on where the “intelligence” ought to sit in a networked world: baked into the routers and switches or overlaid using general-purpose compute engines that ride Moore’s curve.

I think that I’ve made it pretty clear where I stand.   I submit that you should keep the network dumb, fast, reliable and resilient and add intelligence (such as security) via flexible and extensible service layers that scale both in terms of speed but also choice.

You should get to define and pick what best of breed means to you and add/remove services at the speed of your business, not the speed of an ASIC spin or an acquisition of technology that is neither in line with the pace and evolution of classes of threats and vulnerabilities or the speed of an agile business. 

The focal point of his post, however, was to suggest that the real issue is the fact that all of this intelligence requires exposure to the data streams which means that each component that comprises it needs to crack the packet before processing.   Jon suggests that you ought to crack the packet once and then do interesting things to the flows.  He calls this COPM (crack once, process many) and suggests that it yields efficiencies -- of what, he did not say, but I will assume he means latency and efficacy.

So, here’s my contentious point that I explain below:

Cracking the packet really doesn’t contribute much to the overall latency equation anymore thanks to high-speed hardware, but the processing sure as heck does!  So whether you crack once or many times, it doesn’t really matter, what you do with the packet does.

Now, on to the explanation…

I think that it’s fair to say that many of the underlying mechanics of security are commoditizing so things like anti-virus, IDS, firewalling, etc. can be done without a lot of specialization – leveraging prior art is quick and easy and thus companies can broaden their product portfolios by just adding a feature to an existing product.

Companies can do this because of the agility that software provides, not hardware.  Hardware can give you scales of economy as it relates to overall speed (for certain things) but generally not flexibility. 

However, software has it’s own Moore’s curve or sorts and I maintain that unfortunately its lifecycle, much like what we’re hearing @ Interop regarding CPU’s, does actually have a shelf life and point of diminishing return for reasons that you're probably not thinking about...more on this from Interop later.

John describes the stew of security componenty and what he expects to see @ Interop this week:

I expect network intelligence to be the dominant theme at this week's Interop show in Las Vegas. It may be subtle but its definitely there. Security companies will talk about cracking packets to identify threats, encrypt bits, or block data leakage. The WAN optimization crowd will discuss manipulating protocols and caching files, Application layer guys crow about XML parsing, XSLT transformation, and business logic. It's all about stuffing networking gear with fat microprocessors to perform one task or another.

That’s a lot of stuff tied to a lot of competing religious beliefs about how to do it all as Jon rightly demonstrates and ultimately highlights a nasty issue:

The problem now is that we are cracking packets all over the place. You can't send an e-mail, IM, or ping a router without some type of intelligent manipulation along the way.

<nod>  Whether it’s in the network, bolted on via an appliance or done on the hosts, this is and will always be true.  Here’s the really interesting next step:

I predict that the next bit wave in this evolution will be known as COPM for "Crack once, process many." In this model, IP packets are stopped and inspected and then all kinds of security, acceleration, and application logic actions occur. Seems like a more efficient model to me.

To do this, it basically means that this sort of solution requires Proxy (transparent or terminating) functionality.  Now, the challenge is that whilst “cracking the packets” is relatively easy and cheap even at 10G line rates due to hardware, the processing is really, really hard to do well across the spectrum of processing requirements if you care about things such as quality, efficacy, and latency and is “expensive” in all of those categories.

The intelligence of deciding what to process and how once you’ve cracked the packets is critical. 

This is where embedding this stuff into the network is a lousy idea. 

How can a single vendor possibly provide anything more than “good enough” security in a platform never designed to solve this sort of problem whilst simultaneously trying to balance delivery and security at line rate? 

This will require a paradigm shift for the networking folks that will either mean starting from scratch and integrating high-speed networking with general-purpose compute blades, re-purposing a chassis (like, say, a Cat65K) and stuffing it with nothing but security cards and grafting it onto the switches or stack appliances (big or small – single form factor or in blades) and graft them onto the switches once again.   And by the way, simply adding networking cards to a blade server isn't an effective solution, either.  "Regular" applications (and esp. SOA/Web 2.0 apps) aren't particularly topology sensitive.  Security "applications" on the other hand, are wholly dependent and integrated with the topologies into which they are plumbed.

It’s the hamster wheel of pain.

Or, you can get one of these which offers all the competency, agility, performance, resilience and availability of a specialized networking component combined with an open, agile and flexible operating and virtualized compute architecture that scales with parity based on Intel chipsets and Moore’s law.

What this gives you is an ecosystem of loosely-coupled BoB security services that can be intelligently combined in any order once cracked and ruthlessly manipulated as it passes through them governed by policy – and ultimately dependent upon making decisions on how and what to do to a packet/flow based upon content in context.

The consolidation of best of breed security functionality delivered in a converged architecture yields efficiencies that is spread across the domains of scale, performance, availability and security but also on the traditional economic scopes of CapEx and OpEx.

Cracking packets, bah!  That’s so last Tuesday.

/Hoff

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

Cisco as a Bellweather...where's all the commentary?

(Ed.: I wanted to clarify that issues external to security vulnerabilities and advanced technology most definitely caused the impact and commentary noted here -- global economic dynamics nothwithstanding, I'm just surprised at the lack of chatter around the ol' Blogosphere on this)

From the "I meant to comment on this last week" Department...

A couple of weeks ago, analyst reports announced that Cisco was indicating a general slow-down of their enterprise business and they were placing pressure on the service provider business units to make up the difference.  Furthermore, deep discounts to the channel and partners were crafted in order to incentivize  Q2 customer purchases:

Cisco is headed for a disappointing quarter, according to a cautionary research note issued Monday from a research analyst, reports Barron's Online.

Samuel Wilson, an analyst at JMP Securities writes that the slow down in U.S. enterprise business during Cisco's fiscal second quarter has continued into its current quarter, according to Barron's.

According to the Barron's story: "Wilson writes that 'according to resellers, top Cisco sales staff have recently expressed concerns about making their April quarter numbers.” He says that the company has apparently increased “partner-focused incentives' designed to shift business in from the July quarter. 'Based on the past three months, many resellers now believe that U.S. enterprises have begun to delay discretionary spending above and beyond normal seasonality typical of the [calendar] first quarter.'

Wilson also wrote that Cisco has cut headcount and expenses in its enterprsie switching business unit. He forecasts Cisco's fiscal third quarter revenue to be $38.1 billion, down from the consensus estimates of $39.4 billion, according to Barron's.

Given how Cisco is a bellweather stock for not only IT but in many case an indicator of overall enterprise spend trends, why isn't there more concern in the air?  Maybe it's just rumor and innuendo, but when analysts start press releases about Mr. Chambers' neighborhood, they're usually pretty conservative.

Rothman practically needed a Wet-Nap when he commented on Cisco's Q1 announcement (Cisco Takes it to the Next Level) but nary a word from the "All things including the kitchen sink will go into a Cat65K" camp on this news?  What, no gleeful prognostication on rebounds or doom?

Interestingly, from here, Goldman advises to buy ahead of Q3 announcement:

We believe that management will put concerns around slower U.S. large cap tech spending to rest. It represents only 13% of sales and we believe is seeing indications of a rebound. We believe management is likely to reaffirm positive longer-term trends in emerging markets, new technologies and the impact of video on networks as key drivers of sustained double-digit top-line growth.

We'll see.  Focusing on all the advanced technology projects and not focusing on core competencies can bite a company -- even Cisco -- when they least expect it.  Couple that with the continued vulnerabilities in their security products (another one today across Pix/ASA) and I'd say folks might start talking...

I wonder how the security products have weathered through all this?

...but that's just me.  Lash away, boys.

/Hoff

The Philosophy of Network Security Design

Thomas and I were barking at each other regarding something last night and today he left a salient and thought-provoking comment that provided a very concise, pragmatic and objective summation of the embedded vs. overlay security quagmire:

     "I think the jury is still out on how much security policy we   
     should be pushing to middleboxes, and how smart those   
     middleboxes should be. What I know right now is we spend
     way, way too much time, effort, and money on 19" rack
     mountable chasses that suck in packets and spit them back
     out again without providing any measurable impact on the
     security of our networks.  Not a fan."

I couldn't agree more.  Most of the security components today, including those that run in our little security ecosystem, really don't intercommunicate.  There is no shared understanding of telemetry or instrumentation and there's certainly little or no correlation of threats, vulnerabilities, risk or disposition.

The problem is bad inasmuch as even best-of-breed solutions usually require box sprawl and stacking and don't necessarily provide for a more secure posture, especially within context of another of Thomas' interesting posts on defense in depth/mesh...

That's changing, however.  Our latest generation of NPMs (Network Processing Modules) allow discrete security ISV's (which run on intelligently load-balanced Application Processor Modules -- Intel blades in the same chassis) to interact with and control the network hardware through defined API's -- this provides the first step in that common telemetry such that while application A doesn't need to know about the specifics of application B, they can functionally interact based upon the common output of disposition and/or classification of flows between them.

Later, they'll be able to perhaps control each other through the same set of API's.

So, I don't think we're going to solve the interoperability issue completely anytime soon inasmuch as we'll go from 0 to 100%, but I think that the consolidation of these functions into smaller footprints that allow for intelligent traffic classification and disposition is a first good step.

I don't expect Thomas to agree or even resonate with my statements below, but I found his explanation of the problem space to be dead on.  Here's my explanation of an incremental step towards solving some of the bigger classes of problems in that space which I believe hinges on consolidation of security functionality first and foremost.

The three options for reducing this footprint are as follows:

1. Proprietary Embedded security in routers/switches (Cisco, Juniper)
   
   Pros: Supposedly less boxes, better communication between components and good coverage
   given the fact that the security stuff is in the infrastructure.  One vendor from which you get
   your infrastructure and your protection.  Correlation across the network "fabric" will ultimately
   allow for near-time zoning and quarantine.  Single management pane across the Enterprise
   for availability and security.  Did I mention the platform is already there?
   
   Cons: You rely on a single vendor's version of the truth and you get closer to a monoculture
   wherein the safeguards protecting the network put at risk the very assets they seek to protect
   because there is no separation of "church and state."  Also, the expertise and coverage as well
   as the agility for product development based upon evolving threats is hampered by the many
   moving parts in this machine.  Utility vs Security?  Utility wins.  Good enough vs. Best of breed?
   Probably somewhere in between.

 

2. Proprietary Overlay security in a Consolidated Platform (Fortinet 5000, Tipping Point, etc.)
   
   Pros:  Reduced footprint, consolidated functionality, single management pane across multiple
   security functions within the box.  Usually excels in one specific area like AV and can add "good enough" functionality as the needs arise.  Software moves up and down the scalability stack depending upon performance needed.
   
   Cons:  You again rely on a single vendor's version of the truth.  These boxes tend to want to replace switching infrastructure.  Many of these platforms utilize ASICs to accelerate certain functions with the bulk of functionality residing in pure software with limited application or network-level intelligence.  You pay the price in terms of performance and scale given the architectures of these boxes which do not easily allow for the addition of new classes of solutions to thwart new threats.  Not really routers/switches.

 

3. Open Overlay security in a Consolidated Platform (Crossbeam)
   
   Pros:  The customer defines best of breed and can rapidly add new security functionality
   at a speed that keeps pace with the threats the customer needs to mitigate.  Utilizing a scalable and high-performance switching architecture combined with all the benefits
   of an open blade-based security application/appliance delivery mechanism gives the best of all
   worlds: self-healing, highly resilient, high performance and highly-available while utilizing
   hardened Linux OS across load-balanced, virtualized security applications running on optimized
   hardware.
   
   Cons: Currently based upon proprietary (even though Intel reference design) hardware for
   the application processing while also utilizing proprietary networking switching fabric and
   load balancing.  Can only offer software as quickly as it can be adapted and tested on the
   platforms.  No ASICs means small packet performance @ 64byte zero loss isn't as high as
   ASIC based packet-forwarding engines.  No single pane of management.

I think that option #3 is a damned good start towards solving the consolidation issues whilst balancing the need to overlay syngergistically with the network infrastructure.  You're not locked into single vendor's version of the truth and although the hardware may be "proprietary," the operating system and choice in software is not.  You can choose from COTS, Open Source or write your own, all in an scaleable platform that is just as much a collapsed switching/routing platform as it is a consolidated blade server.

I think it has the best chance of evolving to solve more classes of problems than the other two at a rate and level of cost-effectiveness balanced with higher efficacy due to best of breed.

This, of course, depends upon how high the level of integration is between the apps -- or at least their dispositions.  We're working very, very hard on that.

At any rate, Thomas ended with:

"I am a believer in freezing development of the core protocols and building new functionality on top of them. I like NAT. I like Paul Francis. I think the IETF has been hijacked by the leftovers from the OSI standards committees. I don't know what you call that philosophy, besides "end2end originalist".

I like NAT.  I think this is Paul Francis.  The IETF has been hijacked by aliens, actually, and I'm getting a new tattoo:

On Flying Pigs, DNSSEC, and embedded versus overlaid security...

I found Thomas Ptacek's comments regarding DNSSEC deliciously ironic not for anything directly related to secure DNS, but rather a point he made in substantiating his position regarding DNSSEC while describing the intelligence (or lack thereof) of the network and application layers.

This may have just been oversight on his part, but it occurs to me that I've witnessed something on the order of a polar magnetic inversion of sorts.  Or not.  Maybe it's the coffee.  Ethiopian Yirgacheffe does that to me.

Specifically, Thomas and I have debated previously about this topic and my contention is that the network plumbing ought to be fast, reliable, resilient and dumb whilst elements such as security and applications should make up a service layer of intelligence running atop the pipes. 

Thomas' assertions focus on the manifest destiny that Cisco will rule the interconnected universe and that security, amongst other things, will -- and more importantly should -- become absorbed into and provided by the network switches and routers.

While Thomas' arguments below are admittedly regarding the "Internet" versus the "Intranet," I maintain that the issues are the same.  It seems that his statements below which appear to endorse the "...end-to-end argument in system design" regarding the "...fundamental design principle of the Intenet" are at odds with his previous aspersions regarding my belief.  Check out the bits in red.

Here's what Thomas said in "A Case Against DNSSSEC (A Matasano Miniseries):

...You know what? I don’t even agree in principle. DNSSEC is a bad thing, even if it does work.

How could that possibly be?

It violates a fundamental design principle of the Internet.

Nonsense. DNSSEC was designed and endorsed by several of the architects of the Internet. What principle would they be violating?

The end-to-end argument in system design. It says that you want to keep the Internet dumb and the applications smart. But DNSSEC does the opposite. It says, “Applications aren’t smart enough to provide security, and end-users pay the price. So we’re going to bake security into the infrastructure.”

I could have sworn that the bit in italics is exactly what Thomas used to say.  Beautiful.  If, Thomas truly agrees with this axiom and that indeed the Internet (the plumbing) is supposed to be dumb and applications (service layer) smart, then I suggest he should revisit his rants regarding how he believes the embedding security in the nework is a good idea since it invalidates the very "foundation" of the Internet.

I wonder what that'll do internal networks? 

That's all.  CSI is on.

/Hoff

(Written @ Home drinking Yirgacheffe watching UFC re-runs)

If it walks like a duck, and quacks like duck, it must be...?

Seriously, this really wasn't a thread about NAC.  It's a great soundbite to get people chatting (arguing) but there's a bit more to it than that.  I didn't really mean to offend those NAC-Addicts out there.

My last post was the exploration of security functions and their status (or even migration/transformation)  as either a market or feature included in a larger set of features.  Alan Shimel responded to my comments; specifically regarding my opinion that NAC is now rapidly becoming a feature and won't be a competitive market for much longer. 

Always the quick wit, Alan suggested that UTM was a "technology" that is going to become a feature much like my description of NAC's fate.  Besides the fact that UTM isn't a technology but rather a consolidation of lots of other technologies that won't stand alone, I found a completely orthogonal statement that Alan made to cause my head to spin as a security practitioner. 

My reaction stems from the repeated belief that there should be separation of delivery between the network plumbing, the security service layers and ultimately the application(s) that run across them.  Note well that I'm not suggesting that common instrumentation, telemetry and disposition shouldn't be collaboratively shared, but their delivery and execution ought to be discrete.  Best tool for the job.

Of course, this very contention is the source of much of the disagreement between me and many others who believe that security will just become absorbed into the "network."  It seems now that Alan is suggesting that the model of combining all three is going to be something in high demand (at least in the SME/SMB) -- much in the same way Cisco does:

The day is rapidly coming when people will ask why would they buy a box that all it does is a bunch of security stuff.  If it is going to live on the network, why would the network stuff not be on there too or the security stuff on the network box.

Firstly, multi-function devices that blend security and other features on the "network" aren't exactly new.

That's what the Cisco ISR platform is becoming now what with the whole Branch Office battle waging, and back in '99 (the first thing that pops into my mind) a bunch of my customers bought and deployed WhistleJet multi-function servers which had DHCP, print server, email server, web server, file server, and security functions such as a firewall/NAT baked in.

But that's neither here nor there, because the thing I'm really, really interested in Alan's decidedly non-security focused approach to prioritizing utility over security, given that he works for a security company, that is.

I'm all for bang for the buck, but I'm really surprised that he would make a statement like this within the context of a security discussion.

That is what Mitchell has been talking about in terms of what we are doing and we are going to go public Monday.  Check back then to see the first small step in the leap of UTM's becoming a feature of Unified Network Platforms.

Virtualization is a wonderful thing.  It's also got some major shortcomings.  The notion that just because you *can* run everything under the sun on a platform doesn't always mean that you *should* and often it means you very much get what you pay for.  This is what I meant when I quoted Lee Iacocca when he said "People want economy and they will pay any price to get it."

How many times have you tried to consolidate all those multi-function devices (PDA, phone, portable media player, camera, etc.) down into one device.  Never works out, does it?  Ultimately you get fed up with inconsistent quality levels, you buy the next megapixel camera that comes out with image stabilization.  Then you get the new video iPod, then...

Alan's basically agreed with me on my original point discussing features vs. markets and the UTM vs. UNP thing is merely a handwaving marketing exercise.  Move on folks, nothing to see here.

'nuff said.

/Hoff

(Written sitting in front of my TV watching Bill Maher drinking a Latte)