Rational Survivability

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

"…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

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

[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

(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

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)

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)

Bloody Hell!

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

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

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

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

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

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

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

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

<snip>

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

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

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

<snip>

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

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

<snip>

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

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

<snip>

Infoworld ran an interesting article on John Thompson’s recent CeBIT keynote in which he took a shot at Microsoft by suggesting that there is an inherently "…huge conflict of interest for one company to provide both an operating platform and a security platform."

I suppose that opinion depends upon whether or not said company suggests that their security controls are all that are needed to secure said operating system or that defense in depth is not needed.

Here’s why I find this statement interesting and I am going to twist it by agreeing with the statement within the context of the same argument pertaining to Cisco as an extension to the many, many articles I have already written on this topic.

Given just the last rash of vulnerabilities in Cisco’s routing, switching and security products a few weeks ago, I believe it’s also a mistake (you can read "conflict of interest" if you desire) for Cisco (le fox) to protect the network (le chicken.)  That’s the same argument of the "operating system" and the "security platform."

I think it’s simply not relevant or appropriate to simply shrug off issues like this just because of Cisco’s size and the apparent manifest destiny associated with security "going into the switch" — just because it does and more than likely will — does not mean it should and does not mean that people will settle for "good enough" security when the network consistently fails to self-defend.

I don’t disagree that more and more security *will* make it’s way into the network switches, much like I don’t disagree that the sun will rise in the east and set in the west, but much in the same way that folks don’t just give up and go to sleep once the sun goes down, the lightbulb that goes on in my head suggests there is a better way.

/Hoff

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

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

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

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

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

Rot Roh.

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

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

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

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

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

You could hear cricket’s chirp in the answer.

Talk amongst yourselves….

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