In the arms race between network admins and hackers, battles are fought
over the security holes in enterprise software. Your best defense is the
patches that vendors release to plug those holes.
Vendors are working to make patching easier and more trustworthy—like Microsoft and its monthly Patch Tuesday release—but you shouldn't necessarily deploy every patch to every system in your enterprise the day it's released. To best protect your network, you should develop a plan for patching that is based on best practices and tailored to your unique enterprise.
The hidden risks of patching
"Patches are becoming a routine thing. The odds that a patch will crash your critical system are decreasing," says Rafal Los, senior security strategist with HP Software. "It isn't such a hindrance because of automation, but the enterprise still needs controls. Too many enterprise apps could break."
Patching software holes is essential to network security, but it brings a set of operational challenges. You need to know how a patch will impact your existing systems, particularly legacy systems. Patching can expose major problems on your network, including brittle systems, home-grown, mission-critical software, and outdated hardware. As difficult as managing these systems can be, they become a security risk when they're not updated.
You also need to assess the urgency of the update. Does the patch fix a hole that is right now being exploited by hackers? If it's an emergency patch, deploy it immediately—but those are fairly rare. Assuming the patches are part of a vendor's regular patch release cycle, you should deploy them with the same careful, measured steps you take with any other software.
Best practices for patching
With each patch, you should weigh the impact it might have on your systems against the immediate threat level and the consequences to your enterprise if the hole is breached. If many patches are released on the same Patch Tuesday, figure out which ones are most important to your organisation and which pose the greatest security threat. Next:
1. Don't deploy the patch immediately (unless it's an emergency fix). As Los says, "You don't want to be the guy that gets hosed" when you install a patch that hasn't been fully tested. He recommends waiting a few days to install the patch, giving yourself time to learn from any mistakes other admins make and discuss online. Of course, if you wait too long, you risk falling prey to the security exploit the patch fixes.
2. Test the patch on a single system. First install the patch on a system that's in quarantine. Find out how the patch impacts any other applications it interacts with on your network. If you need to patch a business-critical system, create a duplicate system for testing if at all possible.
3. Monitor your systems when you roll out the patch. When you've deemed the patch safe for your systems, deploy it in phases, starting with the low-risk groups and moving on to the higher-risk groups across your enterprise. Monitor all of your systems through the deployment—you need to be able to pinpoint any failure as it happens. Also, you should have backups that you can revert to if a patch takes down any part of your network.
Part of IT's natural life cycle
Beyond the immediate need to patch—say, on next Patch Tuesday—your organisation should have a routine plan for patch deployment. You should establish a regular patch cycle that is in sync with your network's utilisation and employees' schedules. Patching should not be a fire drill!
Also, educate your users. Let them know when to expect patches so they can save their work, shut down their computers, and ready their systems as much as you need for the patch to roll out smoothly. Automate as much as you possibly can. If you have several patches to roll out to one thousand physical servers, you need to be able to push that patch out once automatically. Finally, work with trusted vendors that test their patches before they're released.
Your ability to fend off hackers' latest gambits often comes down to knowing what's changed, and what needs to be changed, on your network. When you make patching a central part of your organisation's change management plan, your network becomes more secure and reliable.
Vendors are working to make patching easier and more trustworthy—like Microsoft and its monthly Patch Tuesday release—but you shouldn't necessarily deploy every patch to every system in your enterprise the day it's released. To best protect your network, you should develop a plan for patching that is based on best practices and tailored to your unique enterprise.
The hidden risks of patching
"Patches are becoming a routine thing. The odds that a patch will crash your critical system are decreasing," says Rafal Los, senior security strategist with HP Software. "It isn't such a hindrance because of automation, but the enterprise still needs controls. Too many enterprise apps could break."
Patching software holes is essential to network security, but it brings a set of operational challenges. You need to know how a patch will impact your existing systems, particularly legacy systems. Patching can expose major problems on your network, including brittle systems, home-grown, mission-critical software, and outdated hardware. As difficult as managing these systems can be, they become a security risk when they're not updated.
You also need to assess the urgency of the update. Does the patch fix a hole that is right now being exploited by hackers? If it's an emergency patch, deploy it immediately—but those are fairly rare. Assuming the patches are part of a vendor's regular patch release cycle, you should deploy them with the same careful, measured steps you take with any other software.
Best practices for patching
With each patch, you should weigh the impact it might have on your systems against the immediate threat level and the consequences to your enterprise if the hole is breached. If many patches are released on the same Patch Tuesday, figure out which ones are most important to your organisation and which pose the greatest security threat. Next:
1. Don't deploy the patch immediately (unless it's an emergency fix). As Los says, "You don't want to be the guy that gets hosed" when you install a patch that hasn't been fully tested. He recommends waiting a few days to install the patch, giving yourself time to learn from any mistakes other admins make and discuss online. Of course, if you wait too long, you risk falling prey to the security exploit the patch fixes.
2. Test the patch on a single system. First install the patch on a system that's in quarantine. Find out how the patch impacts any other applications it interacts with on your network. If you need to patch a business-critical system, create a duplicate system for testing if at all possible.
3. Monitor your systems when you roll out the patch. When you've deemed the patch safe for your systems, deploy it in phases, starting with the low-risk groups and moving on to the higher-risk groups across your enterprise. Monitor all of your systems through the deployment—you need to be able to pinpoint any failure as it happens. Also, you should have backups that you can revert to if a patch takes down any part of your network.
Part of IT's natural life cycle
Beyond the immediate need to patch—say, on next Patch Tuesday—your organisation should have a routine plan for patch deployment. You should establish a regular patch cycle that is in sync with your network's utilisation and employees' schedules. Patching should not be a fire drill!
Also, educate your users. Let them know when to expect patches so they can save their work, shut down their computers, and ready their systems as much as you need for the patch to roll out smoothly. Automate as much as you possibly can. If you have several patches to roll out to one thousand physical servers, you need to be able to push that patch out once automatically. Finally, work with trusted vendors that test their patches before they're released.
Your ability to fend off hackers' latest gambits often comes down to knowing what's changed, and what needs to be changed, on your network. When you make patching a central part of your organisation's change management plan, your network becomes more secure and reliable.
