In-Depth
Solving the Patch Management Headache
Best practices in keeping the desktop secure
When it comes to PCs, some might say keeping them patched and secured is just another aspect of a company’s overall approach to desktop management. Especially if that company is Intel—a prodigious producer (and user) of computer components.
In fact, in the late 1990s, “Intel felt desktop management was important in the sense that managing the desktop was a barrier to companies investing more in PCs,” notes Tom Davis, vice president of engineering at desktop management software vendor LANDesk Software. As a result, Intel invested about $500 million over 12 years, creating now-well-known technology: Symantec’s antivirus engine, PC imaging technology, pre-boot environments, and what became the first version of Novell’s ZENworks management suite.
About two years ago, Intel spun off the division as LANDesk Software. Given the group’s desktop-centric vision, it's no surprise that Davis argues that a number of security problems will be better solved if integrated into the overall desktop management equation. Davis speaks with Security Strategies about future of patching and keeping desktops secure.
What are the benefits of viewing patching as a desktop management issue?
The day of the server being the attack space is over. The server might be important … but it’s the day of the PC. [So] with the explosion of the number of security issues running around out there, [patching] just begs to be an extension of desktop management.
Today we see attacks that are PCs on PCs, PCs on servers, attacks within a corporate, firewalled environment caused by desktops and mobile devices. And that’s right in our bailiwick. We’ve been managing these things for a number of years. We can solve that problem, keep that desktop secure.
Companies have difficulty staying patched, and getting patches in place quickly. How can they make the process less painful?
The first thing that you absolutely must do is: you have to find out what’s out there. But that can be very troublesome. The past 10 years, I’ve had IT administrators come up to me and ask … can you tell me what I don’t know? They’re saying they don’t even know all the systems in their environment, yet each one represents a potential vulnerability. Unless you know it exists, you don’t even know to go out and see what software is on it, which patches to apply.
So step one is inventorying the environment?
Yes … get a really clear inventory of [what’s on] each machine. Then the step after that is [to] research and investigate known vulnerabilities. This is what you’re seeing in the desktop management [software] space—they’re going out and getting content providers to tell them which vulnerabilities to look for. Then, do a threat assessment. Here are the vulnerabilities that exist, and [here’s] a threat assessment for the whole environment.
Then the next step is to download and put into play all those patches. Whether it’s Macintosh, Red Hat, [or] Solaris, you have to get those patches, put them in your environment, and do some validation. What we find in the IT space is there’s really a risk assessment that goes on at that point. They ask, is the consequence of not patching this so great that I don’t even do a cursory test and just deploy? Or … do I want to put it through a series of tests that see how it will affect my [PC rollout] image in our IT environment?
Then you deploy.
How difficult is deploying a patch?
For any size environment, between 1,000 and 80,000 nodes, deployment becomes an issue. Many times, you talk about sizes of 1,000 or 5,000—different offices, people attached to different servers—so how you roll out patches can become very cumbersome and complex.
But the longer it takes to patch, the more risk a company faces.
It’s all about time. If you had an infinite amount of time, it wouldn’t matter. You’d get to it when you get to it. But with security vulnerabilities now, the time between when they become known to when they become active is becoming increasingly short. So with time to analyze, patch, deploy, it’s … all about how quickly you can do this.
If you look at the number of vulnerabilities that have come out, in 1999 there were less than 500. In 2002 there were over 4000. You imagine what that does if a systems administrator tries to keep up; you have to automate the process.
What’s a good rule of thumb for patch-rollout time?
The data that we have right now says that the average time between virus-known to virus [in the wild] is not more than 60 days. IT person has to ask, can I execute … within that window? Many desktop management products cannot do a rollout within 60 days.
What sorts of technologies speed patch rollout?
Multicasting and … peer download. From an infrastructure standpoint, … the Microsoft Windows Update model doesn’t work for an IT manager. It may be fine for the home user, but no system administrator in their right mind is just going to allow machines to update without their having scrutinized the overall effect on the environment and needing all machines to be at the same level.
What’s peer download?
It’s one of the things we provide. It allows each individual PC, once it’s been patched, to ask whether another PC on the subnet has that patch. You know the difference if I’m downloading a 20MB file of patches over a 56K leased line to a satellite office … versus getting it from one of their peers. It’s lower cost and less time.
How do administrators deactivate the Microsoft auto-update?
Many administrators … have tweaked [their standard PC image] it to deactivate Microsoft’s Windows Update. Not everyone does though, particularly [understaffed] companies. They might [be] willing to take the risk.
Not all vulnerabilities, however, are patch-related. You might have a vulnerability on the machine where the administrator account doesn’t have a password, or system shares are enabled. No one issues a patch for that. So we have a database [in our product] that … lets a user enter their own vulnerability or patch information. So, for instance, if they have an internally developed app they want to patch, or if they view an administrator account with a password of “nothing” is a vulnerability, they can detect that, then remediate using our software.
Why not?
It’s not because the tool is inhibited. What IT administrators are often afraid of is doing a patch, and even though they’ve done some testing, they don’t exactly want to do 20,000 point-and-click downloads, because if something goes wrong they’ll flood the help desk. So typically they’ll do 500 here, 500 there. They don’t want to put their job on the line when they a patch.
[Also] we’ve built in the ability to do a rollback. If you deploy a patch, say from Microsoft, and find that it breaks your Lotus Notes, you have to be able to roll it back. And how fast can you do it?
About the Author
Mathew Schwartz is a Contributing Editor for Enterprise Systems and is its Security Strategies column, as well as being a long-time contributor to the company's print publications. Mr. Schwartz is also a security and technology freelance writer.