Tag: RSA-Authored

Would you pay for the TruCoat?

“I’m saying, that TruCoat, you don’t get it you get oxidation problems it’ll cost you a heck of a lot more than $500…”

For those of you playing along, you probably remember this line from the movie “Fargo”. William H. Macy, playing car salesman Jerry Lundgaard, is arguing with a couple about tacking on an unwanted option called “TruCoat” for $500. It’s one of those things that car dealers use to increase their margins. Watch the video here but be warned, there’s a part at the end that’s NSFW.

Jerry Lundgaard selling the TruCoat

So what’s all this got to do with virtualization and cloud security?

Well, in my talking with customers and cloud service providers, the topic of tiered offerings always comes up. You know, the “Gold, Silver & Bronze”. I’ve asked Cloud Service Providers about including security in those tiers and have been met with “Well, maybe, but it would have to re-coup the investment.” (It IS all about the Benjamin’s, isn’t it?)

That got me thinking about TruCoat. A product that Jerry Lundgaard is selling not because it adds value but because it’s got a GREAT profit margin. Not unlike doing the least amount of “security” (Checkbox Security) and charging the most for it. Not really bringing value but charging like you do. I’m not accusing anyone of doing that, but I wonder if maybe some less than reputable vendors (Joey’s Transmission and Cloud?) would head in that direction?

You see, this goes back to security being bolted on .vs. built in. If, in the Gold tier, you add in network packet monitoring and two-factor authentication, you as the cloud service provider are making a significant investment. You need to get that investment back and start to make a profit. How do you explain the TRUE value of the service you offer? Or, like Joey, you just upsell a little anti-virus and firewalling that you’d do anyways because, at scale, it’s not a big hit on the bottom line? Just like the TruCoat.

Clarification: AV and Firewalls are absolutely part of a good defense in depth story. But they are now, especially with the capabilities of vShield, a “commodity” item that is easy to set up and doesn’t impact the bottom line like other security products would.

Buying Value

Customers will pay money for something of value. I haven’t met many people who buy junk intentionally after all! That said, trying to meld security and value together in a cloud environment will be an interesting journey. Today I think it’s a bit of a chicken and egg. Many customer SAY they want secure clouds but how many are willing to pay for it? Cloud Service providers would like to offer security but, let’s face it, it’s not cheap and, as I said, how many are willing to pay for it?

What are your thoughts? Will customers start to demand things like GRC, packet inspection, two-factor authentication? Or will firewalls and anti-virus “check the box” for them?

For some, the response will be “Ya! You betcha!”

Software Defined Security

Got you with that title, huh? :)

Every couple of weeks, I join a number of other folks in the security business on Edward “Texiwill” Haletky’s Virtualization Security Podcast. Today’s episode, Sept 6th 2012, was a bit of a round-up of VMworld 2012 with a pretty good discussion on Big Data and Software Defined X, where X could be Datacenter, Network or Security.

Near the end of the podcast we were talking about what would Software Defined Security actually be. I chimed in with my thoughts. No surprise if you follow this blog, but for me it started with infrastructure.

SDx

First, for the purposes of this blog post, let me share my definition of Software Defined X. SDx is where everything (and I mean EVERYTHING) is programmatically accessible. Basically, everything is available and manipulated via API’s.

At VMworld, VMware talked about “Software Defined Security as vShield/vCNS (vCloud Networking and Security). Allwyn Sequeira from VMware had a great presentation on this here. They are doing an excellent job around the network portion of what one could call Software Defined Security and I’m sure they’ll knock it out of the park moving forward. But, as usual, I want more. Let me explain.

Here’s what I’d like to see from VMware

Today, the objects in vCenter (VM’s, network, storage, etc) can be controlled using the RBAC capabilities of vCenter. But I think it’s time to start thinking about more. What I’d like is an enabling technology. One that can enable a new/better way of managing, security and reporting objects in vCenter. I’d like to see the ability to add digitally signed meta-data to an object such as a VM, network or storage. Because it is signed it provides verification that it hasn’t been tampered with. This should work in hand in hand with a root of trust that starts from the hardware on up.

Why digitally sign? Why not just put stuff in the .VMX file? Because, any admin with enough privileges can manipulate that data. Signing the meta data would mean that the meta data would be invalidated or changed if the VM was copied for example. All this has to happen at the Hypervisor and control plane (vCenter) level.

For VMware vSphere 5.1, VMware has added Tagging, which, while useful, isn’t signed so it can’t be fully trusted. It’s a handy thing for IT guys but not good enough for security.

So, if we could digitally sign information it means we can now start to do interesting things like apply and enforce policy, generate reports and orchestrate actions. Here’s an example of what I’m thinking of.

  1. Create new VM
  1. VM meta-data added. I create a digitally signed tag of “PCI” using a “PCI” key.
  2. VM is also digitally signed to only run in a specific cluster
  • Upon creation, I choose to try and put the VM on a non-PCI network.
  1. The policy enforcement engine says only non-PCI VM’s are allowed on the non-PCI network and blocks that action.
  2. And sends a log to my SIEM and into my GRC solution!
  • Ok, I change the network to be PCI and the VM is ready to be powered up.
  • A disgruntled admin logs in but he doesn’t have PCI rights so he can’t change the VM. He also can’t copy the VM.
  • And because I’ve created a policy that PCI VM’s can only be managed via a VMware Orchestrator workflow that’s been signed with the PCI key, even *I* can’t delete the VM without going thru an approved PCI workflow in Orchestrator

As you can see, this type of ability would go a long way to managing LOTS of VM’s that fall under different regulatory compliance umbrellas. Working in concert with logging solutions and GRC solutions, you can be assured that only the right people are touching the right things and that workflows can be enforced at the infrastructure layer, ensuring compliance. Also, because everything is programmatically addressable, it becomes VERY easy to measure and report on all those actions and workflows, sending that information into a Governance, Risk and Compliance solution.

So what’s the downside?

The big downside is that you really, really need to architect the security of the control plane. With it all being in software, you need to be even more paranoid…er…diligent about securing all the logins, network, etc that these API’s will be running over. For example, you may want to run all the control plane parts in a separate, non-routable network to minimize exposure to the bad guys.

I want to hear from you!

I’d love to hear your thoughts on this line of thinking. As you can tell from the podcast, I got a number of the other participants to agree. What I’d really like to see is someone picking this apart. It’s how we’ll all learn. This blog entry is by no means complete. More of a stream of consciousness like most of my blog posts.

Disclaimer

This blog was written with NO advanced information from VMware, purely from my brain. VMware, if you are doing something like this then I can’t wait to see it! :)

Thanks,

mike