The World’s Gone Virtual – So Have We.

Why and How We Decided to Protect the Virtual Environment.

Over the last dozen years in the IT industry all sorts has gone on, but in the main what happened was the blowing up, bursting, and blowing up again of bubbles. Thankfully, against this depressing backdrop there are several examples of how things should be done – stories of technologies passing through all the stages from conception to industrial mainstream. One of the most interesting examples of this is virtualization.

To start, as per tradition in these tech-themed posts, let me go over the basics. For those who already know the basics of the topic, you can skip this by clicking here.

The idea of virtualization is straightforward enough, and it’s in this simplicity where its genius lies. Now for one of my analogies… Imagine a bus with just one passenger seat. The driver busses folks one by one from point A to B. Nonsense, I know (why have a bus with all that space not being used? Why not install a full set of seats?). But before virtualization became widespread the situation with servers was just like that! Armed with just one server, a service provider could only rent it out as a whole unit – even if the customer didn’t need the server’s full power. It couldn’t be divided up into smaller units. As a result, prices ballooned, capacity was underused, and progress stalled. Bad.

Virtualization allowed to (virtually!) “cut” physical equipment into lots of virtual (and, importantly, equally functional) servers. For example, instead of renting an expensive physical server in a data center, a company can buy equally as much capacity (processing power, memory, disk space, network) as is needed for a specific task. Another example: for separate business applications like CRM, ERP, a website or e-mail gateway, there’s no longer any need to have dedicated physical servers; instead, each of the applications can be installed on virtual machines on a single physical piece of kit.

The benefit? The main one is higher efficiency of hardware use, and the consequential reduced expenditure on IT infrastructure (and the bigger the organization, of course, the bigger the savings), while maintaining an acceptable level of quality of services (sometimes quality can actually improve!). Other benefits come in areas of security (but this is a disputable point – see below), fail-tolerance, manageability and energy efficiency.

It’s no wonder this technology quickly became the standard: around 80% of companies virtualize their server facilities. Today it has not only established itself as the status quo way of going about things, it’s also an important driver of development for the industry on the whole; for example, with no virtualization there’d be no “clouds”.

Most business software developers rushed to come up with special versions of applications optimized for different virtual environments. The result was that deploying a virtual machine and installing software on it no longer required several minutes of the IT department’s time; it became doable almost instantaneously by any user with basic knowledge.

Accordingly, things were looking real rosy for virtualization. Everything was going its way. But then there started to crop up all sorts of unpleasant side-effects, some of which were security-based. Indeed there was plenty of debate regarding virtualization and security. A lot of it missed the point, while some of it was spot on. Anyway, here we’ll comment on one aspect of the issue: virtualization and protection against malware.

In principle, it is possible to manually install anti-malware software (an “agent”) on each virtual machine. But problems can arise if an organization has hundreds if not thousands of physical servers all being virtualized, which may lead ultimately to a corporate disaster. And let’s not forget that it is specifically large organizations that are the principal users of virtualization technology.

So what seems to be the problem with using a dedicated anti-malware “agent” for each virtual machine? Well, it’s not just a single problem – it’s a long list of them. Let me go over the main ones…

First, anti-malware agents use up system resources of each protected virtual machine. Second, simultaneous launching of tasks (for example, scheduled scans) on lots of machines can – not surprisingly – slow down, and in some cases even crash the physical server (the AV-storm effect). Third, a single action is repeated again and again and again across different virtual machines (for example, updating the anti-malware database – the I/O-storm effect); what a waste of effort! Fourth, there’s a major headache with managing the protected environment: how to keep track of virtual machines as they pop up like mushrooms after a storm? How to install and manage each separate anti-malware agent? How to deploy a unified security policy? How to transfer virtual machines from one physical server to another without loss of protection (without the so-called “instant-on gap”)?

Of course, all these difficulties (plus the unlisted ones) can be got around with labor-intensive manual adjustments – but they’re both costly and slow, and can cancel out completely all the benefits of virtualization. Of course, virtualization could be left unprotected, but that’s plainly daft. Yet with (agent-based) virtualization protection being such a pain in the butt, what is one to do? You can probably see this one coming!: Yep, we at KL decided to solve this conundrum once and for all. We developed KSV – a special solution for VMware, whose premiere was held at CeBIT recently.

I won’t bombard you with the details, but you can find a description of KSV here (pdf). And detailed reads on virtualization can be found here and here (pdf).

There are two main features of this product, which together cure all the above-listed problems of traditionally securing virtual machines. They are: agent-less malware protection, and fully centralized protection management.

Let’s start with the first.

As I’ve mentioned, anti-malware software used to be installed on every virtual machine, and with the resulting side-effects. With KSV, scanning of files can be performed on one dedicated virtual machine for all of them on that physical server! This is all thanks to integration with VMware vShield, which automatically offloads anti-malware scanning to KSV. Sweet.

That way, system resources of every protected machine aren’t needed; updates occur on just the dedicated virtual machine, and the AV-Storm effect becomes a thing of the past.

The second feature is integration with our centralized protection management system, KSC, which brings with it all sorts of different advantages.

First, with KSC we get rid of the muddle of management consoles all over the place for this, that and the other. Instead, anti-malware protection for all network objects – workstations, servers, mobile devices, and now virtual environments too – is managed from a single center. KSC gives sysadmin the full range of granular management controls, enables configuration and deployment of security policies, produces all reports, issues all alerts, shows the logical and physical structure of the network, and so on.

There’s more…

KSC keeps track of new and decommissioned virtual machines and automatically turns on/off protection. It optimizes the load among machines when resource-intensive tasks are performed. For every separate virtual machine, and also groups of them, it’s possible to develop custom security policies with individual protection settings. And should you decide to migrate a virtual machine to a different server using VMware vMotion, there’s no drop in protection, and KSC immediately shows the changes in the logical structure of the network.

But now for the fly in the ointment.

Yes, this may disappoint some a little – but it’s not all down to us! Since vShield is relatively new VMware has not been able to include all that’s been thought up into it just yet…

First, KSV supports only Windows for now. For an agent-less scenario with virtualization under Linux, Unix, etc., we’ll have to wait on VMware. But for the moment on these platforms it is possible to use local agents, and thanks to KSC’s centralized management this has been made considerably simpler, more reliable and safer.

Second, in KSV the quarantine function doesn’t work for files and infected virtual machines yet. That is, they can only be deleted, disinfected or signaled about to sysadmin.

Third, protection for the time being is not integrated with our cloud technology, KSN.

The second and third midges in the cream are down to the API from VMware. Both lacking features have been promised to be implemented ASAP, so expect to see them in the next incarnation of KSV soon!

To close, a video presentation of this new paradigm-shifting product of ours.