Rational Survivability

From AndyITGuy who summed it up perfectly:

For everything else there’s karma

• DNS vulnerability being discovered – $0
• Working with vendors to fix the problem – $0
• Having details released "accidentally" – $0
• Having exploit written by WhiteHat – $0
• Your company being pwned by your exploit – PRICELESS

Per the article above "Now he’s one of the first victims of such an attack. "It’s funny," he said. "I got owned."*

Yeah, real funny. 

/Hoff

* There’s lots of thrashing going on as to the veracity of HD’s quote rearding being owned.  Regardless of the theatrics involved, it’s interesting food for thought when the result of exploit research might be turned against the researcher…

I wanted to make you aware of a "new" excellent budding resource for VMware infrastructure, VMware’s VI:Ops – Virtual Infrastructure Operations.  Steve Chambers of VMware pointed me over to the site which is growing in both content and contributors.

VI:Ops currently includes the following sections:

• Strategies and solutions using virtualization
• Building
  and managing virtual infrastructure with open, industry standards
• Securing virtual infrastructure against risk and for compliance
• Managing and operating virtual infrastructure in the enterprise
• Automate everything virtual to be agile and efficient

Check out the site and join the community!

/Hoff

One of my responsibilities as security cruise ship entertainment director is to distill the most complex things down into bite-sized digestible nuggets of chewy informative goodness whilst ensuring a good time is had by all.

It is in this spirit that I offer this gem regarding the release of PoC/Exploit code by supposed "whitehats" immediately after the disclosure of a nasty vulnerability.  This post is random, of course, and is in no way a reference to any current event.

This quip was brought to you via Twitter which managed to stay up and functional long enough for me to tweet it:

POC code for near-zero day ‘sploits is like SPAM advertising penis-extending drugs…the only dick it’s helping is the one writing it…

That is all.

/Hoff

Update: Check it out!  Leo Laporte and Steve Gibson read my poem on their Security Now podcast.  Thanks for the radio voice, Leo!

—

A few months ago
Kaminsky discovered a flaw.
It was with DNS,
It was nasty and raw

He decided than rather
to disclose all at once
he’d instead only tell people
who’d fix it in months

So some meetings were had
and work soon began
vendors wrote patches
coordinated by Dan

Fast forward some time
out the closet it came
some researcher types
got into the game

Dan’s rules were quite simple,
that in 30 days
he’d present during Blackhat
and we’ll all be amazed

A bunch of big egos
called Dan on a bluff
said his vuln was a copy
of 10 year old stuff

So Dan swore them on handshakes
and details were provided
and those same cocky claims
soon all but subsided

It seems that Dan’s warnings
weren’t baseless at all
Said the same skeptical hackers
"the risk isn’t that small!"

So Blackhat was nearing
the web didn’t break
then out came a theory
from our friend Halvar Flake

No sooner had he posted
and described the vuln’s guts
than Matasano’s blog surfaced,
kicked the web in the nuts

It said "Halvar’s right!"
we’ll no longer keep quiet.
The post’s ripple effect
caused a nasty ‘net riot

The blog quickly was pulled
but the cat’s out of the bag
the arms race began
since there’s no longer a gag

Meanwhile the issues of honor and trust
rehashed the debate
of when disclosure goes bust

So Dan’s days of thirty
we never did see
thirteen is OK
but I issue this plea

When researchers consider
how to disclose and thus when
will you think of the users?
How it might affect them?

This ego-fueled rush
to put your name on a vuln
has a much bigger impact
than you might have known

If the point here is really
to secure and protect
then consider what image
you really project

In this case the vuln.
is now in the wild
an exploit is coming
DNS soon defiled

The arms race has started
and the clock now is ticking
If you haven’t yet patched
you’ll soon take a licking

I’m not taking sides really
on the disclosure debate
but rather the topic
of patch early or late

What good is disclosure
if the world couldn’t cope
with the resultant attacks
if we’ve all got just hope?

There’s two sides to this issue
both deserve merit
but Dan’s rep has been smeared
I say let’s just clear it

—

Happy patching everyone! ;(

/Hoff

Hat tip to Rothman for this.

I don’t know if Stiennon is off his meds or simply needed to re-post something from 2001 to meet an editorial quota, but his Network World article titled "The Most Important Networking Trend of 2008" ties thus far with the "Evolution of Dance" as my vote for most entertaining Internet content.

Richard’s epiphany goes something like this:

• Multifunction network devices that have the ability to "route" traffic and combine security capabilities are the ‘next big thing’
• If a company offers a multifunction network device that has the ability to "route" traffic and combine security capabilities but have the misfortune of using Linux as the operating system, they will "…forever be pigeon-holed as SMB solutions, not ready for enterprise
  prime time."

• The Wall Street Journal issued "… the year’s most important article on networking" in an article titled "New Routers Catch the Eyes of IT Departments" which validates the heretofore undiscovered trend of convergence and commoditization!
   
• "Real" network security players such as Cisco, Juniper and Redback are building solutions to this incredible new trend and because of the badge on the box, will be considered ready for "…enterprise prime time."
   
• The WSJ article talks about the Cisco ASR1000 router as the penultimate representation of this new breed of converged "network security" device.
   
• Strangely, Stiennon seems to have missed the fact that the operating system (IOS-XE) that the ASR1000 is based on is, um, Linux.  You know, that operating system that dictates that this poor product will "…forever be pigeon-holed as SMB solutions, not ready for enterprise
  prime time."

Oh, crap!  Somebody better tell Cisco!

So despite the fact that Cisco ASR1000 is positioned as an edge device as are these crazy solutions called UTM devices, it seems we’re all missing something because somehow a converged edge device now counts as being able to provide a "secure network fabric?"

In closing, allow me to highlight the cherry on top of Stiennon’s security sundae:   

Have you ever noticed how industry "experts" tend to get stuck in
a rut and continue to see everything through the same lens despite
major shifts in markets and technology?

Yes, Richard, I do believe I have noticed this…

Funny stuff!

/Hoff

For the second time in some months, Amazon’s S3 (Simple Storage Service,) one of the most "invisibly visible" examples of the intersection of Web2.0 and cloud computing, has suffered some noticeable availability hiccups. 

Or, if you prefer to use Amazon’s vernacular "elevated error rates" 😉

Many well-known companies such as Twitter rely upon content hosted via Amazon’s S3 which is billed as offering the following capabilities:

Amazon S3 provides a simple web services interface
that can be used to store and retrieve any amount of data, at any time,
from anywhere on the web. It gives any developer access to the same
highly scalable, reliable, fast, inexpensive data storage
infrastructure that Amazon uses to run its own global network of web
sites. The service aims to maximize benefits of scale and to pass those
benefits on to developers.

It’s not realistic to think that infrastructure as complex as this won’t suffer service disruption, but one has to wonder what companies who rely on the purported resiliency of the "cloud" from a single provider do in cases where like it’s namesake, the skies open up and the service takes a dump?

I’ll go one further.  If today you happen to use S3 for content hosting and wanted like-for-like functionality and service resiliency with a secondary provider, would your app. stack allow you to pull it off without downtime?

What happens if your apps are hosted in a cloud, too?

Sounds like a high-pressure front to me…

Next up: "CPE Security Is Dead(?): All Hail Security in the Cloud(?)"

😉

/Hoff

I was having an interesting discussion the other evening at BeanSec with Jeanna Matthews from Clarkson University.  Jeanna is one of the authors of what I think is the best book available on Xen virtualization, Running Xen.

In between rounds of libations, the topic of Hypervisor-neutral, VM portability/interoperability between the virtualization players (see right) came up.  If I remember correctly, we were discussing the announcement from Citrix regarding Project Kensho:

Santa Clara, CA » 7/15/2008 » Citrix Systems, Inc.
(Nasdaq:CTXS), the global leader in application delivery
infrastructure, today announced “Project Kensho,” which will deliver
Open Virtual Machine Format (OVF) tools that, for the first time, allow
independent software vendors (ISVs) and enterprise IT managers to
easily create hypervisor-independent, portable enterprise application
workloads. 
These tools will allow application workloads to be imported
and run across Citrix XenServer™, Microsoft Windows Server 2008 Hyper-V™ and VMware™ ESX virtual environments. 

On the surface, this sounded like a really interesting and exciting development regarding interoperability between virtualization platforms and the VMs that run on them.  Digging deeper, however, it’s not really about virtualization at all; it’s about the delivery of applications and services — almost in spite of the virtualization layer — which is something I hinted about at the end of this post.

I am of the opinion that virtualization is simply
a means to an end, a rationalized and cost-driven stepping-stone along the path of
designing, provisioning, orchestrating, deploying, and governing a more agile, real time
infrastructure to ensure secure, resilient, cost-effective and dynamic delivery of service.

You might call the evolution of virtualization and what it’s becoming cloud computing.  You might call it utility computing.  You might call it XaaS.  What many call it today is confusing, complex, proprietary and a pain in the ass to manage.

Thus, per the press release regarding Project Kensho, the notion of packaging applications/operating environments up as tasty little hypervisor-neutral nuggets in the form of standardized
virtual appliances that can run anywhere on any platform is absolutely appealing and in the long term, quite necessary.*

However, in the short term, I am left wondering if this is a problem being "solved" for ISV’s and virtualization platform providers or for customers?  Is there a business need today for this sort of solution and is the technology available to enable it?

Given the fact that my day job and paycheck currently depends upon crafting security strategies, architecture and solutions for real time infrastructure, I’m certainly motivated to discuss this.  Mortgage payment notwithstanding, here’s a doozy of a setup:

Given where we are today with the heterogeneous complexity and nightmarish management realities of our virtualized and non-virtualized infrastructure, does this really solve relevant customer problems today or simply provide maneuvering space for virtualization platform providers who see their differentiation via the hypervisor evaporating?

While the OVF framework was initially supported by a menagerie of top-shelf players in the virtualization space, it should come as no surprise that this really represents the first round in a cage match fight to the death for who wins the application/service delivery management battle.

You can see this so clearly in the acquisition strategies of VMware, Citrix and Microsoft.

Check out the remainder of the press release.  The first half had a happy threesome of Citrix, Microsoft and VMware taking a long walk on the beach.  The second half seems to suggest that someone isn’t coming upstairs for a nightcap:

Added Value for Microsoft Hyper-V

Project Kensho will also enable customers to leverage the
interoperability benefits and compatibility between long-time partners
Citrix and Microsoft to extend the Microsoft platform.  For example,
XenServer is enhanced with CIM-based management APIs to allow any
DMTF-compliant management tool to manage XenServer, including Microsoft
System Center Virtual Machine Manager. And because the tools are based
on a standards framework, customers are ensured a rich ecosystem of
options for virtualization.  In addition, because of the open-standard
format and special licensing features in OVF, customers can seamlessly
move their current virtualized workloads to either XenServer or
Hyper-V, enabling them to distribute virtual workloads to the platform
of choice while simultaneously ensuring compliance with the underlying
licensing requirements for each virtual appliance.

Project Kensho will support the vision of the Citrix Delivery Center™
product family, helping customers transform static datacenters into
dynamic “delivery centers” for the best performance, security, cost
savings and business agility. The tools developed through Project
Kensho will be easily integrated into Citrix Workflow Studio™ based
orchestrations, for example, to provide an automated, environment for
managing the import and export of applications from any major
virtualization platform.

Did you catch the subtlety there?  (Can you smell the sarcasm?)

I’ve got some really interesting examples of how this is currently shaking out in very large enterprises.  I intend to share them with you, but first I have a question:

What relevance do hypervisor-neutral virtual appliance/machine deployments have in your three year virtualization roadmaps?  Are they a must-have or nice-to-have? Do you see deploying multiple hypervisors and needing to run these virtual appliances across any and all platforms regardless of VMM?

Of course it’s a loaded question.  Would you expect anything else?

/Hoff

* There are some really interesting trade-offs to be made when deploying virtual appliances.  This is the topic of my talk at Blackhat this year titled "The Four Horsemen of the Virtualization Apocalypse"

Edward Haletky wrote an interesting piece recently titled "CISecurity Guide to VMware Security Falls Far Short" in which he lays down some well-articulated criticisms of the first CIS benchmark for VMware.

Edward’s primary problem with the benchmark can be summarized well by this paragraph:

While the Benchmark was the first of its kind, it is nothing more than the Linux benchmark with some small changes for VMware ESX. Following these steps will increase security but it is by no means a panacea. Do not let it give you a false sense of security.

I think Edward set his expectations a little high prior to review, as I’m pretty sure the word panacea wasn’t used in the syllabus 😉

I don’t disagree with Edward that the flavor of the benchmark is very much a generic set of guidelines focused primarily on securing the underlying Linux-based service console and basic configuration for overall "system" hardening, but we need to realize a couple of things to keep the benchmark in perspective:

1. The benchmark was the first of its kind.  It’s almost 10 months old!  The second version is underway right now as a matter of fact.
2. In between when the benchmark was released and now, we’ve seen the emergence of the embedded version of VMware and much needs to change to address that.
3. The benchmark was designed to be generic and give virtual system administrators a baseline on basic security hardening, not serve as the end-all, be-all for some mythical security end-state.
4. The challenge for those of us who contributed (as I did) was that we had to keep the document vendor/tool agnostic which makes it difficult to frame solutions.
5. Lots of things have changed.

Keep in mind that this is a "level 1" benchmark whose settings/actions are as follows:

• Can be understood and performed by system administrators with any level of security knowledge and experience;
• Are unlikely to cause an interruption of service to the operating system or the applications that run on it; and
• Can be automatically monitored either by CIS Scoring Tools or by CIS Certified tools available from security software vendors. 

This isn’t about being defensive regarding the benchmark as I’ll agree that we could have done much, much more in terms of providing more meatier substance as it relates to how to better secure the ecosystem of mechanicals that a virtualized environment touches. 

However, the scope of a document that effectively addresses the security concerns across this immense landscape would be a huge undertaking.

One of the other difficulties in creating a guideline like this is the fact that those responsible for securing virtualized environments are not security professionals.  As I’ve spoken about previously, the operational realities of who is managing and securing our virtualized infrastructure is cause for concern.

Thus, when creating a guide like this, it’s best to start with the underlying basics and then branch out from there; involve the network and security teams as required.  As Edward himself wrote in this piece, "Good virtual security requires better IT teamwork," to properly secure your virtualized infrastructure, it’s going to take cooperation and expertise from many camps.    

Edward also has written a book titled "VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers."  Interestingly, I found the security sections weak for many of the same high-level reasons he listed in his review of the CIS benchmark.  Security is most definitely in the eye of the "bookholder." 😉

In the meantime, if you’re interested in some additional security/hardening guides and tools for VMware environments, check out the following:

• VMWare – Updated VI3 Security Hardening Guide (7/8/08)
• DoD/DISA – Security Technical Implementation Guide (STIG)
• NSA SNAC – VMware ESX Server 3 Configuration Guide
• Tripwire – ConfigCheck

/Hoff

Amrit turned me onto a Network World article titled "12 Ways to Visualize Network Security" in which his analog of security as a cheese grater is featured.

Yup, there’s castles and cars and…

In an attempt to annoy the crap out of everyone, I decided to start spewing out my candidates via twitter (beaker) so as to force as many un-follows as possible. 

Here are some of my off-the-cuffs [remember, these have to fit in < 140 characters]:

• Security is like Escargot. It’s crunchy on the outside, chewy on the inside, and like everything else, should be blamed on the French!
• Security is like Kimchee…to make it you have to slap it together, bury it and then dig it up when it smells to explain how special it is..
• Security is like Durian: It’s lousy in airports, stinks when exposed and looks oddly out of place no matter how you slice it…
• Security is like fertilizer, the more shit you spread around the worse it gets and watering it down only makes it worse
• Security is like a vibrator, the more you have to use it, the less fun the real business becomes…
• Security is like weed, homeopathy and faith healing; sometimes nothing beats cutting the tumor out, but faith in snake oils is more fun
• Security is like a pig; well, ’nuff said.
• Security is like your ’82 Ford Escort; you can keep telling everyone that it was your mom’s ride & gets good mileage, but everyone knows…
• Security is like a pomegranate; seriously, who the fuck thought it was a good idea to try THAT!
• Security is like balut; when crunchy on the outside, chewy in the middle doesn’t work, go crunchy everywhere?  Sweet Jesus.
• Security is like a vacuum cleaner; both have dirtbags and "suckage" is the primary metric.

Sadly, nobody un-followed and instead I got like 10 new TwitterBots following me instead.  Ain’t that a bitch?

/Hoff

P.S. My man Mogull flung back some fine satirical smackage…nicely played, sir!:

Yo!  BeanSec! is once again upon us.  Wednesday, July 16th, 2008.

PLEASE NOTE THE VENUE CHANGE BELOW!  THIS WILL BECOME PERMANENT.

BeanSec! is an informal meetup of information security
professionals, researchers and academics in the Greater Boston area
that meets the third Wednesday of each month. 

I say again, BeanSec! is hosted the third Wednesday of every month.  Add it to your calendar.

Come get your grub on.  Lots of good people show up.  Really.

Unlike other meetings, you will not be expected to pay dues, “join
up”, present a zero-day exploit, or defend your dissertation to attend.

Middlesex Lounge: 315 Mass Ave, Cambridge 02139.  We are moving locations due to better seating and the fact that the Enormous Room (our prior location) no longer serves food. ;(

Don’t worry about being "late" because most people just show up when they can. 6:30 is a good time to aim for. We’ll try and save you a seat. There is a plenty of parking around or take the T.

In case you’re wondering, we’re getting about 30 people on average per BeanSec! Weld, 0Day and I have been at this for just almost 2 years and without actually *doing* anything, it’s turned out swell.

The food selection is basically high-end finger-food appetizers and the drinks are really good; an attentive staff and eclectic clientèle make the joint fun for people watching. I’ll generally annoy you into participating somehow, even if it’s just fetching napkins. 😉

See you there.

/Hoff, /0Day, and /Weld