Home > Security

Computerworld - Once again, I'm the bad guy.

A large-scale virtualization project was about to be deployed when the project team showed up seeking my sign-off. I can't approve anything without a proper assessment, so I told them I'd need two weeks. Naturally, the IT guys weren't too thrilled. But I've sent the word out to everyone before: Pull security into every project early on, or live with last-minute delays.

Because it had become clear to me that just delivering that message (even doing it dozens of times) wasn't enough, I managed a few months ago to have security embedded into the project life-cycle management process.

We even have a new online project management tool to ensure that every step of every project is properly completed. Unfortunately, several projects that were already in progress were "grandfathered" in and therefore weren't being tracked online. One of these was server virtualization.

This is a huge project, involving the virtualization of some 250 critical servers. You'd think I would have heard something about it before now. Well, chalk this lapse up to efficiency and competence. As big as the project is, very few meetings were needed. That's because IT had run a trial about a year and a half ago, virtualizing just a handful of servers. That went well, and so the team was able to just scale up that earlier effort to enter the virtualization big time.

So I have my two weeks, but at this point, I have no choice but to compromise on several issues. One problem is that moving to a virtual environment involves taking an image of each server. That precludes what would have been a great opportunity for increasing our security. A lot of our Windows servers aren't up to date with patches. That's because we lack development environments for many of our applications, and adding patches without testing first is just asking for trouble. The image-transfer method robs us of a chance to take care of the problem; once those virtual servers are up and running, they will be just as problematic to patch as the old physical servers.

Another opportunity lost: We could have used the move to virtualization to properly segment our network, which currently is basically flat. You don't get many windows to address a problem like that. Now, instead of improving the situation, I am left worried that by moving our servers to this new environment, we will be introducing new attack vectors.

These are the sorts of things we could have talked over if I had been involved earlier. At least the number of grand??fathered projects is shrinking; eventually, everything will be tracked online.

I don't really have time to do the assessment, what with my involvement in ensuring that our recent acquisitions meet our security requirements. Anyway, I'm not a VMware security expert, and I don't have the time to become one. Finally, for such a major infrastructure change, it's probably best to bring in a disinterested third party to provide an unbiased perspective.

Calling the Expert

With all that in mind, I gave a consultant a call. Every security manager should have on speed dial a couple of people he trusts who have expertise in certain core areas. During a recent M&A assessment, this consultant performed a thorough evaluation of an acquired company's virtualization infrastructure.

He assured me that his skills were updated and that he was ready to go. I briefed him on the scope of the assessment, and he prepared a statement of work. Within a week, he was on-site, conducting meetings, obtaining access to the various pieces of infrastructure and conducting tests to provide me with a meaningful review. I expect his report soon.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@ yahoo.com.

Join in

To join in the discussions about security, go to computerworld.com/blogs/security

Read more about Security in Computerworld's Security Topic Center.