Rational Survivability

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

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

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

Now back to our regular programming…

— ORIGINAL POST —

From the "Out Of the Loop" Department…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/Hoff

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

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

…also, this is right on the money:

• Chris Silva – Forrester

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

Besides the monthly BeanSec! gatherings, New England really needs a security conference to call its own.  Now we have one.

You can find a ton of detail about the show here, but if you’re impatient because you’re pahking the cah in the yahd and can’t get to your browsa, here’s the skinny:

The security convention is called SOURCE: Boston 2008, and it’s held
from March 12-14th, the W-F before St. Patrick’s Day weekend. The place
it’s being held is the Hyatt Regency Cambridge, right on MIT’s campus.

It’s the big step-shaped hotel with the neon framing right on the water. We have negotiated low room rates and are sporting quite a line-up of speakers and keynotes, including keynotes from Dan Geer of MIT Athena/Kerberos fame, Richard Clarke, and Steven Levy.

We will also have a panel with the members of the L0pht – speaking together for the first time in 10 years. We have some great evening activities such as a VIP reception and a Thirsty Thursday Pub Crawl.

The three tracks are application security, business and security, and new security technologies. It’s a professional conference and we’re having several CEOs speak, as well as other chief officers. However, it’s combining that professionalism and business component with the edginess and fun of some of the hacker conferences.

Rich Mogull and I are appearing on stage together as Click and Clack (or is it Wallace & Grommet?)  That ought to be worth the price of admission right there.

See you there.

/Hoff

I’m feeling old lately.  First it was my visceral reaction to the paranormal super-poking goings-on on Facebook and now it’s this news regarding Linden Lab’s Second Life that has my head spinning. 

It seems that the intersection between the virtual and physical worlds is continuing to inch ever closer.

In fact, it’s hitting people where it really counts, their (virtual) wallets. 

We first saw something like this bubble up with in-world gambling issues and now Linden announced in their blog today that any virtual "in-world banks" must be registered with real-world financial/banking regulatory agencies:

As of January 22, 2008, it will be prohibited to offer interest or
any direct return on an investment (whether in L$ or other currency)
from any object, such as an ATM, located in Second Life, without proof
of an applicable government registration statement or financial
institution charter. We’re implementing this policy after reviewing
Resident complaints, banking activities, and the law, and we’re doing
it to protect our Residents and the integrity of our economy.

Why?  It seems there’s more bad juju brewin’.  A virtual bank shuts down and defaults.  What’s next?  A virtual sub-prime loan scandal?

Since the collapse of Ginko Financial in August 2007, Linden Lab has
received complaints about several in-world “banks” defaulting on their
promises. These banks often promise unusually high rates of L$ return,
reaching 20, 40, or even 60 percent annualized.

Usually, we don’t step in the middle of Resident-to-Resident conduct
– letting Residents decide how to act, live, or play in Second Life.

But these “banks” have brought unique and substantial risks to
Second Life, and we feel it’s our duty to step in. Offering
unsustainably high interest rates, they are in most cases doomed to
collapse – leaving upset “depositors” with nothing to show for their
investments. As these activities grow, they become more likely to lead
to destabilization of the virtual economy. At least as important, the
legal and regulatory framework of these non-chartered, unregistered
banks is unclear, i.e., what their duties are when they offer
“interest” or “investments.”

There is no workable alternative. The so-called banks are not
operated, overseen or insured by Linden Lab, nor can we predict which
will fail or when. And Linden Lab isn’t, and can’t start acting as, a
banking regulator.

Some may argue that Residents who deposit L$ with these “banks” must
know they’re assuming a big risk – the high interest rates promised
aren’t guaranteed, and the banks aren’t overseen by Linden Lab or
anyone else. That may be true. But for all of the other reasons we’ve
set out above, we can’t let this activity continue.

Thus, as we did in the past with gambling, as of January 22, 2008 we will begin removing
any virtual ATMs or other objects that facilitate the operation or
facilitation of in-world “banking,” i.e., the offering of interest or a
rate of return on L$ invested or deposited. We ask that between now and
then, those who operate these “banks” settle up on any promises they
have made to other Residents and, of course, honor valid withdrawals.
After that date, we may sanction those who continue to offer these
services with suspension, termination of accounts, and loss of land.

Wow.  Loss of land!  I thought overdraft fees were harsh!?

Ed Felten from Freedom to Tinker summed it up nicely:

This was inevitable, given the ever-growing connections between the
virtual economy of Second Life and the real-world economy. In-world
Linden Dollars are exchangeable for real-world dollars, so financial
crime in Second Life can make you rich in the real world. Linden
doesn’t have the processes in place to license “banks” or investigate
problems. Nor does it have the enforcement muscle to put bad guys in
jail.

Expect this trend to continue. As virtual world “games” are played for
higher and higher stakes, the regulatory power of national governments
will look more and more necessary.

So far I’ve stayed away from Second Life; I’ve got enough to manage in my First one.  Perhaps it’s time to take a peek and see what all the fuss is about?

/Hoff

In December I made note of an interesting post on the virtualization.info blog titled "Patch Tuesday for VMware."  This issue popped up today in conversation with a customer and I thought to bubble it back up for discussion.

The post focused on some work done by Ronald Oglesby and Dan Pianfetti from GlassHouse
Technologies regarding the volume, frequency and distribution of patches across VMware’s ESX platform. 

When you combine Ronald and Dan’s data with Kris Lamb’s from ISS that I wrote about a few months ago, it’s quite interesting.

The assertion that Ronald/Dan are making in their post is that platforms like VMware’s ESX have to date required just as much care and feeding from a patching/vulnerability management perspective as a common operating system such as a Windows Server:

So why make this chart and look at the time between patches? Let’s take a hypothetical
server built on July 2nd of 2007, 5 months ago almost exactly. Since
being built on that day and put into production that server would have
been put into maintenance mode and patched/updated eight times. That’s
right eight (8) times in 5 months. How did this happen? Let’s look at
the following timeline:

Maybe it’s time to slow down and look at this as a QA issue? Maybe it’s
time to stop thinking about these platforms as rock solid, few moving
parts systems? Maybe it’s better for us not to draw attention to it,
and instead let it play out and the markets decide whether all this
patching is a good thing or not. Obviously patching is a necessary
evil, and maybe because we are so used to it in the Windows world, we
have ignored this so far. But a patch every 18.75 days for our
"hypothetical" server is a bit much, don’t you think?

I think this may come as a shock to some who have long held the belief that bare-metal, Type 1 virtualization platforms require little or no patching and that because of this, the "security" and availability of virtualized hosts was greater than that of their non-virtualized counterparts.

The reality of the situation and the effort and potential downtime (despite tools that help) have led to unexpected service level deviance, hidden costs and latent insecurity in deployed virtualized environments.  I think Ronald/Dan said it best:

If a client is buying into the idea of server virtualization as a piece
of infrastructure (like a SAN or a switch) only to see the types of
patching we see in Windows, they are going to get smacked in the face
with the reality that these are SERVERS. The reality that the vendors
are sticking so much into the OS that patches are going to happen just
as often as with Windows Servers? Or, if the client believes the
stability/rock solidness and skips a majority of general patches, they wind up with goofy time issues or other problems with iSCSI, until they catch up.

As a counterpoint to this argument I had hoped to convince Kris Lamb to extend his patch analysis of VMware’s releases and see if he could tell how many patched vulnerabilities existed in the service console (the big ol’ fat Linux OS globbed onto the side of ESX) versus the actual VMM implementation itself.  For some reason, he’s busy with his day job. 😉 This is really an important data point.  I guess I’ll have to do that myself ;(

The reason why this is important is exactly the reason that you’re seeing VMware and other industry virtualization players moving to embedded hypervisors; skinnying down the VMM’s to yield less code, less attack surface and hopefully less vulnerabilities.  So, to be fair, the evolution of the virtualization platforms is really on-par with what one ought to expect with a technology that’s still fairly nascent.

In fact, that’s exactly Nand Mulchandani, VMware’s Sr. Director of Security Product Management & Marketing in response to Ronald/Dan’s post:

As
the article points out, "patching is a necessary evil" – and that the
existence of ESX patches should not come as a shock to anyone. So let’s
talk about the sinister plan behind the increase in ESX patches.
Fortunately, the answer is in the article itself. Our patches contain a
lot of different things, from hardware compatibility updates, feature
enhancements, security fixes, etc.

…

We
also want customers to view ESX as an appliance – or more accurately,
as a product that has appliance-like characteristics.

…

Speaking
of appliances, another thing to consider is that we are now offering
ESX in a number of different form-factors, including the brand new ESX Server 3i.
3i will have a significantly different patch characteristics – it does
not have a Console OS and has a different patching mechanism than ESX
that will be very attractive to customers.

I see this as a reasonable and rational response to the issue, but it does point out that whether you use VMware or any other vendor’s virtualization platform, you should make sure to recognize that patching and vulnerability management of the underlying virtualization platforms is another — if not really critical — issue that will require operational attention and potential cost allocation.

/Hoff

P.S. Mike D. does a great job of stacking up other vendors against Microsoft in this vein such as Microsoft, Virtual Iron, and SWSoft.

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

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.
Map to the Enormous Room in Cambridge.

Enormous Room: 567 Mass Ave, Cambridge 02139.  Look for the Elephant
on the left door next to the Central Kitchen entrance.  Come upstairs.
We sit on the left hand side…

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 parking garage across the street and 1 block down or
you can try the streets (or take the T)

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

We’ve had some really interesting people of note attend lately (I’m
not going to tell you who…you’ll just have to come and find out.)  At
around 9:00pm or so, the DJ shows up…as do the rather nice looking
people from the Cambridge area, so if that’s your scene, you can geek
out first and then get your thang on.

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  

Something interesting just occurred to me as my (now) four year old and a couple of her friends were huddled around one of the computers in my office playing a Dragon Tales coloring game while my seven and eleven year old were in their respective rooms playing with the virtual pets in their virtual worlds of Webkinz.

Why is the fact that my kids are huddled around their Mac Mini’s on a cold day playing computer games in any way remarkable?  Because all of them were playing games which are hosted and presented via the Internet; no software except a browser required on this end.

So? 

Well, the really interesting thing was that my wife reminded me that we haven’t purchased ANY children’s software titles in the last two years because all of the games, learning applications and reference materials are all on-line.  Software as a, well, service.  And mostly free to boot!  The same usually can’t be said in the, um, "adult" realm.

This sounds like the kiddy version of GoogleApps.  How long until you don’t even have to buy a DVD for your XBox, PS3 or Wii…as high speed feeds continue to rise, it’s not that large of a stretch…

I think it’s a very interesting perspective on the more "mainstream" adoption of SaaS and a rather interesting way of monetizing it.  In the case of Webkinz, while the virtual world — replete with currency, domiciles, and social services — is free, one has to purchase a physical doll which has attached to it a "secret code" that one uses to register your pet in Webkinz World.  You then give it a name and choose a sex and start building rooms.

It’s basically second life for kids — without the job fairs (yet.)  My wife has now informed me that she’s going to get her own doll to play with the kids online.  I wonder if we’ll actually ever speak to one another in person any more!? 

Scratch that, she’s at this moment registering a bulldog named Waldo.

I’m hoping they start making 5’11 blonde Swedish nurse Webkinz soon…

…which reminds me, given the fact that since all this kid’s software is now on-line, how long until someone compromises it for unseemly reasons?   An interesting attack vector, no doubt.  I think I’ll call it SaaD – Software as a Disservice?

/Hoff

I don’t know what’s happening behind the scenes at Facebook.  Perhaps it’s the manifest evils of Beacon victimizing humanity coming back to haunt them, but there’s been a horrific breach over at Facebook.

I just don’t feel safe there any longer.

I joined FB as a number of groups to which I belong and enjoy monitoring decided to leverage the mass pandemonium that is social netgawking and make their information available only on this populist portal.

So I log on today, fully expecting to check my hatching eggs, play a round of scrabulous and explain to yet another aging filipino male "philanthropist" that I’m really not a 16 year old Catholic school girl trolling for a good time when I discovered the harrowing news:

I’d been SuperPoked!

That’s right. 

I was eFingered right after being attacked with a drive-by Vampire tea bagging knee-bar and an inverted trout slap…and some "friend" decided to curse me with a Thunder Pinch and send me a Pink Sock as a gift.

Seriously, what the hell!  When did we start talking like this?  I just mastered Snoop Dogg’s schizzle, yo!  I can’t keep up.

Most of the people that I am FB "friends" with are 30+ years old.  What possible reason would any self-respecting "old person" have for superpoking, trout-slapping or thunder-pinching me?  I’ve tried talking my wife into this stuff and it doesn’t work unless I liquor her up.  How do you think this is going to work on me?

Me!?

If you can’t figure out how to revert to good old-fashioned email or IM, and speak ‘murican, I don’t want to talk to you.

No more hatching Jack-a-lopes.  No more Roman Candles.  No more Romanian Turtle Wedgies.

Screw this Web2.0 crap.

I’m going to play bowling on my Wii now.

/Hoff

My dear friend Murray (sorry if that expression of warmth comes as a surprise, Murr…) sent me this story from the Register:

Polish teen derails tram after hacking train network

A Polish teenager allegedly turned the tram system in the city of
Lodz into his own personal train set, triggering chaos and derailing
four vehicles in the process. Twelve people were injured in one of the
incidents.

The 14-year-old modified a TV remote control so that it could be used to change track points, The Telegraph
reports. Local police said the youngster trespassed in tram depots to
gather information needed to build the device. The teenager told police
that he modified track setting for a prank.

"He studied the trams and the tracks for a long time and then built
a device that looked like a TV remote control and used it to manoeuvre
the trams and the tracks," said Miroslaw Micor, a spokesman for Lodz
police.

"He had converted the television control into a device capable of
controlling all the junctions on the line and wrote in the pages of a
school exercise book where the best junctions were to move trams around
and what signals to change.

"He treated it like any other schoolboy might a giant train set, but
it was lucky nobody was killed. Four trams were derailed, and others
had to make emergency stops that left passengers hurt. He clearly did
not think about the consequences of his actions," Micor added.

Transport command and control systems are commonly designed by
engineers with little exposure or knowledge about security using
commodity electronics and a little native wit. The apparent ease with
which Lodz’s tram network was hacked, even by these low standards, is
still a bit of an eye opener.

Problems with the signalling system on Lodz’s tram network became
apparent on Tuesday when a driver attempting to steer his vehicle to
the right was involuntarily taken to the left. As a result the rear
wagon of the train jumped the rails and collided with another passing
tram. Transport staff immediately suspected outside interference.

The youth, described by his teachers as an electronics buff and
exemplary student, faces charges at a special juvenile court of
endangering public safety. ®

Yes, yes.  I know, it’s not a SCADA system…as fun as that would be to bring up again, I don’t need any death threats, so I won’t mention it…directly.  But if you read about the recent security design debacle of the Boeing 787 Dreamliner and then look at this, it doesn’t take much of a logic jump to see why we should be worried about how command/control systems are implemented.

My next piece of chicanery is to steal one of Mogull’s Wii Guitar Hero controllers, hack it, and cause it to electrocute his cat every time he hits C# on Stairway to Heaven…

/Hoff

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

A few months ago, Pete Lindstrom shot me over the draft of a Burton paper on virtualization security.  We sputtered back and forth at one another, I called him names, and then we had beer later.

The title of the paper was the "Five Immutable Laws of Virtualization Security."

I must admit, I reacted to what he sent me in a combinational fit of puzzlement and apathy.   I really couldn’t put my finger on why.  Was it the "not invented here syndrome?"  I didn’t think so.  So what was it that made me react the way I did?

I think that over time I’ve come to the conclusion that to me, these aren’t so much "immutable laws" but more so derivative abstractions of common sense that left me wondering what all the fuss was about.

Pete posted the five laws on his blog today.  A more detailed set of explanations can be found on the Burton blog here. 

I dare you to read through these without having to re-read each of them multiple times and then re-read them in cascading sequence since (hint) they are recursive:

Law 1: Attacks against the OS and applications of a physical system
have the exact same damage potential against a duplicate virtual system.

Law 2: A VM has higher risk than its counterpart physical system
that is running the exact same OS and applications and is configured
identically.

Law 3: VMs can be more secure than related physical systems
providing the same functional service to an organization when they
separate functionality and content that are combined on a physical
system.

Law 4: A set of VMs aggregated on the same physical system can only
be made more secure than its physical, separate counterparts by
modifying the configurations of the VMs to offset the increased risk
introduced by the hypervisor.

Law 5: A system containing a “trusted” VM on an “untrusted” host has
a higher risk level than a system containing a “trusted” host with an
“untrusted” VM.

Ultimately, I’d suggest that for the most part, these "observations" are correct, if not oversimplified in a couple of spots.  But again, I’m left with the overall reaction of "so what?" 

Pete even mentions the various reactions he’s been getting:

I have been getting interesting reactions to these. Some say they
are wrong. Some say they are common sense. Some just don’t like the
word "immutable." I think they serve to clarify some of the confusion
that comes up when discussing virtualization by applying fairly
straightforward risk management principles.

I want to believe that somehow these "laws" will enable some sort sort of actionable epiphany that will magically allow me to make my virtualized systems more secure, but I’m left scratching my head regarding who the audience for this was?

I don’t think it clarifies any "confusion" regarding risk and virtualization and I’m puzzled that Burton suggests that these "laws" will enlighten anyone and dispel any confusion relating to whether or not deploying virtualization is more or less risky than not deploying virtualization:

In reality, we can apply traditional security practices to
virtualization to determine whether risk increases or decreases with
new virtualization architectures. It shouldn’t be surprising that the
increase or decrease in risk is predicated on the current architecture.
Here are five laws to live by when evaluating your virtualization
architectures.

…

When combining the standard risk principles with an understanding of
the use cases of virtualization, a set of immutable laws can be derived
to assist in securing virtual environments

So, I’m with the "common sense" crowd since most of these "laws" have been discussed — and some practical advice to go along with them — for quite some time before the "Burton Tablets" came down from the mountain.

So I don’t disagree, but I’m reminded of a couple of good lines from a bad movie wherein the nasty knight says to the good knight "you’ve been weighed, measured and found wanting…"

So, there we are.  My $0.02.  I think I’ll add a slide or two about this at the virtualization forum next month…

/Hoff