Category: Virtualization

Virtual Desktops and Security–Leverage, Control, Enable

First, IMHO, VDI is not like the virtualization of servers where I consolidate 100 servers into 10 boxes and come out being a hero to finance because I saved $70k in A/C and electricity. The cost savings are not as blatant (and easy) as that.

Instead, in my view, VDI is an enabling technology for governance, risk and compliance. Primarily because the desktop infrastructure is now off of desktop/laptop hardware and back under control of the datacenter. This infrastructure gives me unparalleled visibility into the goings on. I can more easily monitor traffic and actions, control access and respond to bad things. I can now protect my desktops with datacenter class security.

With other technologies like vShield, I can now group VM’s in a way that aligns with the business and apply/enforce policies accordingly. eng-finWith vShield’s new Data Security feature, you are now leveraging the RSA Data Loss Prevention engine to audit your virtual machines.

For example: I can assign policies at the group bases so that the Engineering group will be scanned for PCI data and if found, it will be reported. But the finance folks, because they are trained in PCI, will only be audited. As I add new VM’s to the groups, the VM’s will fall under the appropriate policies with no special configuration. Consistency!

Leverage

Last year I talked with a customer in a government agency about VDI and security. They had a requirement that every time an analyst logs into a desktop, that the desktop was “fresh”. With VDI, that’s easy.

  • The analyst logs into a fresh desktop cloned from a gold master.
  • At the end of the shift, the desktop is moved into a different pool for forensic analysis
  • A new desktop is provisioned.

All easily automatable/scriptable and orchestrated (and you know how much I like automating things!). Because it’s all automatable, you can now do things in a consistent manner. Inconsistent events and actions will be easier to spot and react. And because all of these events are logged and processed by a SIEM I’ve now got a step up on when things DO go wrong!

Control

What this also did for the customer was shrink their window of vulnerability. How so? Well, the desktop was fresh at every shift change. The timeframe for which malware could get a hold was shrunk from weeks/months/years to an 8 hour shift. With 88% of corporations having systems infected with trojan’s and not knowing about them, this can really help mitigate bad stuff lying around!

Enable

VDI is also an enabling technology in that I, as the IT guy, can embrace new trends quicker with less risk. Look how fast the iPad has become part of the enterprise? You only have to Google “iPad Enterprise Adoption” and see study after study on this increasing trend. For example, I was talking with a customer who wanted to replace all corporate laptops for their thousands of field people with an iPad + Virtual Desktop. The key driver for this was that customer data would never resided on the endpoint. If the iPad was lost or stolen, no worries. Go expense a new one and get back to work.

In terms of inter-office usability, consider the situation where your corporate laptop has been infected (don’t let your 15yr old son use it. EVER!) and now, instead of 2 days of re-imaging downtime, the IT guy hands you a thin client and you’re back to work in minutes.

What if you lost your laptop? Well, because your only access to sensitive data is through your virtual desktop and isn’t allowed on an endpoint device like a laptop, the loss of the laptop may not need to be reported to regulatory authorities. Google “Stolen Laptop Data Breach”. And for those that say “but our laptops are encrypted!”, well, only 30% of you are doing that according to a study at the Ponemon Institute funded by Intel.

Back to work in minutes, no regulatory reporting for a stolen laptop. How does Finance measure that productivity gain/potential corporate risk?

In closing

VDI isn’t for the faint of heart nor is it for everyone. However, with the capabilities available today, you can use it to really get back the control you had back in the timesharing days (I miss you VMS!) while being flexible to adopting new technologies in a more secure way.

I’m a huge fan of VDI. I’ve been using it now for well over a year and wouldn’t give it up. I have my personal MacBook Air laptop and the only corporate info on it is some non-NDA presentations. All other EMC “stuff” is done on my VMware View desktop. This keeps that nice separation between what’s mine and what EMC’s very clear. And yes, the SSD in the Air is encrypted with FileVault!

Finally, when it comes to security, it’s no longer sufficient to just run ON a virtual platform. For security to move to the next step, it has to leverage these inherent capabilities that are presented to it. You can start today by considering a virtual desktop strategy. Just don’t forget the security tools!

Thanks,

mike

The Palace of Harmonious Virtualization

Introduction

In my job, I get to think a lot about where things are going. I’m hearing day in and day out that security is a major stumbling block to fully virtualizing a datacenter and also for “cloud”.

In the case of the virtualized datacenter, what many call Private Cloud, this stumble usually happens when the security guy is brought in after the ball is already in motion and promptly puts a stop to things “until it’s secure”

A common reaction is to then stop, investigate and build a wall/secure the edge.

The issue I have with this is that a wall/edge solution is no longer good enough. An edge only solution is not going to help you deal with an insider and todays advanced persistent threats[Chuck Hollis’ blog]. It’s only a single layer of Defense in Depth [us-cert.gov]. Today’s threats go far beyond targeting the edge. In the virtual world, they take on a whole new level of importance.

In this article, I’ll endeavor to show you, based on the use of ancient and modern history, that building a wall around your virtual datacenter is only the first line of defense. Knowing what’s going on INSIDE the wall is critical to the protection of your data, your intellectual property and ultimately, your business.

Different cultures, common solutions

I’ve been traveling a lot lately. Just in the month of November I traveled to both China and Israel. In China I presented at the VMware vForum and RSA Conference events in Beijing. These three presentations were mostly on visibility into the virtual environment. While in Israel as the latest member of RSA’s Cross-Product Architecture Team we had meetings with our development teams there during which I got to have a number of great conversations around virtualization and security design.

Both countries were eye-opening experiences on a number of levels. China blew me away with its breath-taking rapid growth and the corresponding growth of my waistline from the excellent food (minus the scorpions on a stick)! Visiting China also helped set off a light bulb moment about defense in depth while walking through the Forbidden City. I mentioned this to my colleague Bob Griffin, one of the industry’s most accomplished security professionals. Out of that came his elegant blog posting [rsa.com] titled The Forbidden City and Defense in Depth. I’ll go into more detail about that in a moment.

Israel was amazing for its geo-political place in the world and shawarma! As I explained to a Jewish friend here in the US, to me, Jerusalem was a mix of bizarre, solemn and thought provoking all wrapped up in lafa bread with a dab of hummus. I loved every minute there and am very thankful to have experienced this wonderful place with my new Israeli friends.

(Have you figured out that I’m a foodie yet? I really need to get back to the gym after these trips….)

Both visits brought insight into history and how learning from history allows us to move forward into the future. You see, both countries have something to teach us about walls, perimeters and defense in depth and I’ll try to relate that to virtualization security and why you, as an IT professional need to involve your security team and why, as a Security Professional you need to jump in and get your hands dirty and not just build a wall.

 

China – The Great Wall and The Forbidden City

clip_image002[6]

China’s Great Wall was originally designed to keep out the invasions of nomadic peoples like the Mongols and according to Wikipedia; it’s over 5500 miles long. Like any good fortification or wall, it’s designed to keep out people or things you don’t want on the inside. It has controlled openings where only what/who you want to come through are allowed. Not unlike an IT Security firewall, eh?

clip_image004[6]

The Forbidden City was also designed to control access. Not access to a country, but to the Emperor and his entourage and ministers. As you can see by this photo, there are a series of walls and courtyards, all designed to limit access to only those allowed to specific places. Ultimately, ending up within an area just for the Emperor and his closest contacts. It was a fascinating walk through history and was what sparked this whole thinking about defense in depth and specifically how it relates to virtualization. I very much encourage you to read Bob Griffin’s blog post, referenced earlier. He goes into good depth on this topic.

Israel – Walls that separate

clip_image006[6]

Israel also has walls. These are walls surrounding the Old City of Jerusalem with controlled access points such as the Jaffa Gate, a narrow road that takes a 90-degree turn. It’s pretty amazing to see cars navigating this ancient road! The marks on the walls from bumpers scraping says it all!

In addition to ancient walls, there are the new walls separating regions, limiting and controlling access.

Defense in Depth and the Insider Threat

China

Each are examples of Defense In Depth. I was in China for two weeks and went to the Forbidden City over the weekend before Bob arrived. It struck me as I walked through the Forbidden City a few days before Bob and I did that I was clearly walking through a series of control points through thick walls. All designed to protect the Emperor and his family and not unlike the series of walls one must go through to get at data in the enterprise. For example, a VPN, an internal website and a download on that website. Each may have various levels of authentication needed to access information.

But what the walls didn’t account for was the insider threat. Security was deployed to control the checkpoints and was outward-facing to gauge risk to threats from the outside. But what if someone or something within the walls became a threat? Would security be able to react? Or after the fact would they be able to reconstruct what went wrong and adjust going forward?

Israel

In ancient Israel there were also walls and control points into the Old City. In modern day Israel, as I point out above, there are a number of newer walls. The difference is that there is also strong internal security. Intelligence is regularly gathered and acted upon. For example, as was related to me, internal intelligence sources acting on information, regularly change operations such as troop movement and transportation resources in order to mitigate potential threats. So, not only does the country look outward to its security but also inward. And when something does unfortunately happen, there is usually a pretty good amount of forensic information reconstructed to learn from so that it doesn’t happen again.

“Those who cannot remember the past are condemned to repeat it” – G. Santayana

So you are probably asking yourself now how this relates to virtualization and security? Well, every IT and security professional needs to begin to look inward to virtualization and private cloud. It’s not good enough to just build a wall around your virtualized datacenter.

One of the presentations I gave at the RSA Conference in Beijing was about visibility in the Private Cloud. My theory (a generalization, I’ll admit!), based on lots of discussions with customers, partners, sales people and community members, is that IT is pushing the use of virtualization and private cloud and the last people IT involves is Security. As was said by a gentleman at VMworld 2011 in Las Vegas during a security session: “I’m the security guy, I put the NO! in InNOvation”! (For the record, EVERY IT guy in the room agreed with him!)

Typically, when Security is presented with something to secure that they know little about, the first reaction is to build a perimeter or wall around it. But, as I laid out in the examples above and below, that’s just not good enough anymore. Visibility, or “intelligence” into the operations of virtualization is fundamentally important. You must now start to look inward to mitigate threats. You must be looking for the things that stand out and react accordingly. And finally, you need a way to reconstruct what happened when something DOES go bad (and it will!) and work to mitigate that failure in the future.

Examples of the insider threat

Many who have worked in IT have heard stories of a sysadmin gone bad. It’s someone in IT who gets ticked off and has the privileged role to do something destructive. In this case, because everything is virtualized, he has decided to copy the Domain Controller, Web App and Database virtual machines. No longer am I worried about just credit card data going out the door, I as a CIO/CISO have to be concerned with my intellectual property and the fully running application leaving my control!

Another example is one of not understanding the implications of virtualization and security. I encounter many people who haven’t quite connected the dots around protecting and monitoring privileged access to their virtualization environment. The number of ESX and vCenter servers that are unprotected is staggering! Just ask virtualization security expert Edward Haletky [virtualizationpractice.com]! He pointed me to some penetration testing that was specifically looking for vSphere components open on the Internet and the results were scary. Compromising these critical components is the analog equivalent of breaking the lock on your physical datacenter! You DO have a lock on your datacenter door and the racks inside, right? And you DO limit access to those resources?

So as we think about history, old and modern, and how they apply to different scenarios, we must reflect and ask some questions.

· Is it good enough for you to just build a wall?

· Is it good enough to be just looking outward, waiting for that nomadic hacker to cross over the hill?

· Who’s guarding inside the palace and can you trust them?

Plan, design, implement

The importance of good design should not be discounted. As an IT manager, when you are going through the process of the redesign your datacenter you bring in your network and storage teams and plan and design a solution that works for you. It should also be the time you bring in your security guy, get him up to speed and make him/her part of the team.

By working together to build strong controls of identity and access and leverage new capabilities of the virtual infrastructure you can provide the business potentially greater visibility and combine them with tools to manage the risk. Leveraging this kind of intelligence can protect your Palace of Harmonious Virtualization!

Bob said it best when he wrote, “Defense in depth is a valid idea, but the analogy needs to be with adaptive and responsive systems like those of human physiology.” After all, if history is any indication, the biggest threats will be when someone gets inside your infrastructure.

mike

—————————————————

I don’t call myself “a security guy”. It’s not my background. I’m an IT/Infrastructure guy who’s been involved with security at various times of his career. I’ve taken on as a mission during my time at RSA to bring IT and Security together because only together can we all fight these new and emerging threats.

The missing note from the vShield 5 docs

Every IT guy (or gal) has, at some point in their career called a friend for a lifeline when they’ve gotten stuck. And invariably, every one of us has had that friend look at our problem and say something like “Did you plug it in?”

I had one of those moments today.

You see, I’m rebuilding my lab with vSphere 5, vCloud 1.5 and vShield. I decided to go directly by the documentation (for a change!) as a learning exercise. I ran into a problem with vShield. It drove me batty. I couldn’t get VM’s to either talk to each other or to outside resources like DNS, gateway or DHCP.

Now, this was seriously getting on my nerves, I reviewed everything, I read docs, I read blog articles. I just couldn’t for the life of me find out what was wrong! What did I miss?

It was time to call in my lifeline, Rob Randell from VMware. Rob lives and breathes this product and I’ve worked closely with him on all sorts of security/VMware related stuff. If anyone could figure it out, it would be Rob.

We connected this afternoon over Webex. We stepped thru a few things, looking at settings and such. Then Rob asked me to bring up the vCenter client and asked me “Why are the vShield App VM’s not powered on?”

<facepalm><Homer D’oh!> Yea, I just go bitten by the bug we all run into. The inability to see the obvious. <insert excuse here> My schedule lately is so crazy that I’ve been doing this in fits and starts and not practicing my usually good troubleshooting skills. <\excuse>

After powering on the VM’s, network traffic started flowing and all was right with the world! I talked to Rob and said that there really should be a note in the documentation. Not a note saying “Did you power up the VM’s?” but to set the auto start settings on the ESXi hosts.

As best practices for vShield, I installed, and you should to, the vShield App and Edge VM’s to local storage on the ESXi hosts. But what I failed to do was set the VM’s to auto start on the host and after a reboot, I forgot to power on the VM.

So, click on the host in the vCenter client, click on Configuration and Start/Stop Settings. Ensure the VM is in the auto-start list. I also set the shutdown action to “shutdown” and not “power off”. I also set the power-on time from 120 seconds to 15 seconds to ensure my networking wasn’t out for some period of time after host power-on.

I’ll be sending a pointer to this blog to the vShield product management team in hopes that this one simple documentation note will help you not encounter the techie embarrassment of being asked “Did you plug it in?”

Thanks for reading.

mike