News Stay informed about the latest enterprise technology news and product updates.

Patch testing may suffer due to zero-day fears

Windows users faced a breathtaking spike in zero-day threats last year and most security experts agree the problem is only going to get worse. Mark Shavlik, founder and CEO of Roseville, Minn.-based patch management firm Shavlik Technologies, is concerned that zero-day fears will cause people to rush through the patch testing process that is a critical part of vulnerability management. If the feedback from some of his customers is any indication, a lot of patch testing has already gone by the wayside. In this Q&A, he discusses the need for IT professionals to take a deep breath and press on with their testing, though he does see cases where quick and dirty patch deployment may be necessary.

In a recent interview with Information Security magazine, you expressed concern that people aren't testing patches like they used to because of the growing zero-day threat. Do you see this pattern developing among your customers?
Well, I'll put it this way: When Microsoft releases its monthly security updates, our lab runs hundreds of test scenarios on each patch to minimize network compatibility problems for customers. The whole process takes 24 hours or less, which is pretty fast. But customers are increasingly clamoring for a shorter process. If there's a zero-day threat, they want to deploy the patch in 24 minutes. This has me convinced there are enterprises out there that aren't testing like they used to. More urgency on the part of users to put in patches right away instead of spending time on regressions testing puts the pressure on patch vendors like us to test as thoroughly as possible since there's less chance of adequate testing on the other end. Is it OK for companies to stop doing their own testing if they use you or another patch management vendor?
Whenever possible, you should do your own testing against in-house applications. With so many patches going out, it's just a good practice to have a testing system in your environment. But if the zero-day threat is big enough, it's probably prudent to get them out faster and let us do our job for you. In the end, it's something individual companies have to figure out on their own. You have to judge what's necessary based on what your company does and what the individual risks are. Can you offer examples?
If the company is a bank, the IT professionals have to ask themselves what the greater risk is -- the Web server being unavailable for a few hours, or the network getting hit with a zero-day attack that exposes the company's sensitive data. In that case, it's better to patch quickly and risk the compatibility problems than to be unpatched and have an attack hit.
Patch testing:
Patch management techniques

Survey: Enterprises quicken patch processes

Are there any patch management products that track the patching process?

What tools are available to verify a patch's validity?

Book chapter: Curing the Patch Management Headache: Common Issues with Testing
Is Microsoft making better patches, thus enabling people to move faster on their testing?
I think Microsoft is very focused on testing their patches and companies like ours report issues back to them. Today the patches are well tested by Microsoft. In 2007 and beyond, the challenge for other vendors is to really develop the kind of system Microsoft now has. Does Shavlik do patch management for non-Microsoft shops, or shops with a mix of Windows and other operating systems?
We do mostly Microsoft shops, but we have a line of Unix patching products also. We work with Apache Web server patches, Adobe and RealPlayer. If a patch came out for iTunes, we would be on it immediately. We're looking at being able to do something with Oracle. But we don't know if that market is ready for automated remediation right now, since so much Oracle patching is still manual. We are looking at possibly being able to tell Oracle users what the status of a patch is and what it does. Where are the bad guys focusing most of their attention these days?
Internet Explorer has had so many patches it is starting to become stable. The same is true with Firefox. Attackers want easy targets so anything that touches the Internet and hasn't been through a lot of patching is good to them. So media players are where it's at. There's a lot of opportunity for zero-day attacks in that area. The technology was developed when security wasn't such an issue, so there are probably a lot of problems to be found. There's a lot of legacy software that won't be patched for a long time. There will also be more problems in dealing with peer-to-peer and gaming software. We help companies identify and remove that stuff. You can try and patch everything, but more companies are just saying 'hey, I don't want this on my network anymore.' If someone says they only want the Opera browser on their network, we'll help them find everything that isn't Opera and then we can help them do whatever they decide to do about it. Talk about what you see as best practices when it comes to patching.
You need to be able to do a full assessment of your network. Computers are coming and going and are not well managed at the desktop level. Then there are the portables devices. You need a plan to keep track of all this. There's also the challenge that some computers will run different operating systems in different languages or different versions. A company needs to figure out what they have and make a decision on how to prioritize their patching actions. You also need to be able to asses which patches are most critical to apply first based on your special risks and what the business does. You need to schedule patching appropriately and alert people of possible reboots. You should patch soon after a vendor patch is known and so you should have the resources in place for that, since people come up with exploits soon after a patch is released.

Dig Deeper on Web browser security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.