Patching is critical. We all know that. 
We hear about it at least once a month when Microsoft
announces its monthly patches on “Patch Tuesday.”
We hear about it again a couple of more times a
month when Adobe releases yet another
update to Acrobat or Flash.
If we’re paying attention, we will also hear or read about
it several more times when our other critical
apps have new patches. When it’s time to create your patch management policy,
don’t forget these six steps in order to get the most for your efforts.
1.Management support is key
Without management support, your policy is just a bunch of words
on paper (or bytes in a file.) Your patch management policy needs
to include support from management to ensure that you are allowed
to scan systems and deploy patches to them as needed, or that you
can assign patching tasks to sysadmins and that they must patch as required.
2. Test, test, test
You can just enable automatic updates and hope for the best.
You can also drive the wrong way up a one way street.
I wouldn’t recommend either one though for your long-term prospects.
Your patch management policy should include testing of all patches
to ensure they don’t introduce new issues, crash systems, or cause other problems.
Sometimes the patch is worse than the workaround, and testing can help
you determine whether a given patch is safe in your environment,
or if you should focus on mitigations until a more stable update is available.
3.Patch all your operating systems and critical applications
Patching is something you need to do to maintain operating systems
and applications. Your patch management policy needs to address both,
and should be all-encompassing. Servers and workstations, Windows and
Macs and Linux, Office suites and media players… all of them need to be
patched. Make sure your patch management policy leaves nothing behind.
4.Update regularly
New vulnerabilities are discovered regularly, and new patches are released
by vendors both with a regular cadence and when critical vulnerabilities
become public knowledge. Your patch management policy needs to include
regular updates, both to the systems you are patching, and the solution
you use to patch them. Your policy should provide for monthly patching
to follow Microsoft’s monthly release cadence, but should also allow
time to deploy critical out of band patches to operating systems and
applications when a zero-day exploit is announced. Those aren’t scheduled…
you shouldn’t have to wait on a schedule to patch something actively being exploited.
5.Reporting
Make sure your patch management policy includes reporting, both to ensure all
systems are up to date and that you can report up to management the status of
your systems. You want to be able to tell at a glance whether all your systems
are fully patched or not, and to easily identify which systems need further remediation.
The ability to report up to management not only helps to justify costs and efforts,
but can work to your advantage when year-end reviews roll around!
Of course, patch management also requires the right application to help
you with all of the above. Look for a patch management application that
supports your policy, can handle all your critical operating systems
and applications, makes testing and rollbacks easy, and can provide all the reporting you need.
Author: Peter Walsh on behalf of GFI Software.
Find out more on how your business can benefit from a good patch management policy.
