Virtualization offers many advantages, but also creates unique challenges when it comes to security. Organizations that fail to revise their legacy IT security policy to account for virtualization are missing out on potential efficiencies and leaving themselves open to attack. In a previous Q&A, I talked with author and independent consultant Tom Howarth about VMware's security updates. In this Q&A, we take a broader approach and discuss how an organization should approach IT security policies in a virtual world.
What do you see as the biggest challenge to security in a virtual environment? Have those challenges changed over time?
Tom Howarth: Virtual security -- it has the ring of an oxymoron, like "military intelligence" and "unbiased opinion." Is it real security or just pretend?
There are plenty of well-known commentators that will give you advice on this particular subset of logical security management. However, the rules are effectively the same as for the physical world. One thing to note here is I am commenting on physical as in installed on bare metal, rather than bolted barn doors and metaphorical missing horses.
All that said, I feel the biggest challenge to security in the virtual world is not anything related to the technology, but incumbent security policies and, more specifically, those that protect those polices and enforce their enactment.
Security policy and enforcement tends to lag behind technology enhancements. Most, but not all, security professionals are still firmly based in the physical infrastructure world, where their incumbent policies are very virtual world antagonistic. Concepts like "white space" between security zones are preventing further inroads into data center consolidation by forcing virtual architects to create separate environments for different zones.
The technology is here and available now. Unfortunately, the security officers and IT security policies are still stuck in the last millennium.
How important is it to have a regular maintenance and security update policy? What is the problem with not having a formal maintenance schedule?
Howarth: A company's security policy should be a starting block. It should be the frame that you work to; consider it a tailor's mannequin. Too often, a company's security processes are rigid, and the policy becomes a rope to bind rather than principles to guide. This can easily lead to issues when attempting to introduce new technologies that, on the face, appear to conflict with incumbent policies. An example of this is software firewalls. They serve exactly the same purpose as hardware firewalls, but traditional IT security professionals do not like them. They ask how they can offer the same protection as a hardware firewall when they cannot give physical separation. The fact is that physical firewalls may use hardware, but they still use software to separate traffic by means of virtual local area networks and traffic control. More importantly, they use exactly the same methods that software firewalls do.
It is much more important to make sure that you regularly check and maintain your environment. Regular patching cycles and security baseline checks are better at keeping environments secure than stale IT security policies.
Do organizations need written IT security policies, and how should they go about designing such policies?
Howarth: There are plenty of sites on the Internet to help and guide companies on how to create a security policy. If you what to know how to create a policy, search the Internet and you will find pages of sage advice. What I want to concentrate on is the other main question: Why create a security policy?
Whether a company requires a written security policy is an interesting question. Written rules, if deemed onerous by those subject to them, will almost certainly be circumvented or ignored. Take a password policy, for example. A simple phase or memorable word is more secure than a policy that requires a minimum of eight characters, with least one of each type, numeric, uppercase and the blood of a unicorn sacrificed at dawn on the summer solstice. The plain fact is that complicated passwords will result in users writing down the password. This issue is further compounded when there is a password reset policy in place to require a new password every set number of days.
Issues like this can bring into question the entire need for a security policy. So how exactly should you tackle the question of creating a security policy? First, set principles, not boundaries. It is easier to guide than it is to force.
Remember that the weakest link in any security policy is people. Produce security principles aimed at making your environment more secure, but not so difficult, intrusive or onerous that it becomes difficult for employees to do their work.
Remember it is much easier to floor trawl for passwords under keyboards than it is to brute force a password hack.
Run a risk assessment on your company. Do not just concentrate on logical protection; you should include physical security too.