When it comes to security, only a total dope doesn’t understand firewalls, anti-virus and at least the basics of passwords.
But how many end users, indeed how many IT pros, truly get patching? Sure, many of us see Windows install updates when we shut down our PC and think all is well. It’s not. Our clients and especially our servers are exposed to all kinds of grief unless they are regularly and properly patched.
Even IT pros that understand patching too often hate it. Because of myriad systems involved, and the large number of patches, the process is not just constant, but can be extraordinarily complex. One can’t just install a patch and forget it, as with Windows Updates where the fixes are well vetted. On servers in particular, patches may need to be tested, then installed, and too often reinstalled due to a bad patch or software conflicts. All to defend against an attack that may or may not happen.
Unfortunately these attacks do happen all too often. The problem is two-fold. First, too few IT regularly patch. In fact, only 36% of small companies patch consistently according to a recent study by the UK-based Federation of Small Business. That leaves an awfully big hole, as some 90% of exploits that succeed are made against unpatched systems.
So why are hackers so keen on exploiting unpatched systems? Because it is so darn easy. You see patches fix holes, and in doing so actually identifies the hole. Knowing that not all people and shops will install the patches; hackers create exploits that attack these unpatched vulnerabilities.
The answer here is obvious: patch your clients and servers! The most obvious software to patch is from Microsoft as they are the most ubiquitous and used to be the most frequently attacked. This is no longer true. Bigger targets now include Adobe, Java and even Firefox. It not usual for Oracle to release dozens of Java fixes in a single month, and that number at times has hit well over 100.
The answer: patch well and often
Patching can be a complex process. There are more and more systems to patch and an ever increasing number of holes to fill. Some patching is fairly simple as Windows Update which pretty much installs the fixes itself. Other patches are less automated. And when patching complex systems such as server apps, these fixes can cause conflicts and instability requiring IT to perform conflict testing before rolling out the repair.
The whole affair is far too complex and time-consuming to be done manually. With an automated patching solution, the tool should be multi-platform, gather up the patches, set some priorities, and automatically install the patches properly.
Here are a few other tips to make patching easier and keep your systems safer:
Tip 1. Admit that you have a problem
With only 36% of small shops patching regularly, it is clear that most don’t think there is a problem. At the same time, these shops are most likely fixing security problems they don’t even realise came from a lack of patches.
Tip 2. Become a patch expert
By becoming a patch expert you can stop 90% of all successful hack attacks against you and your company. Articles like this are a good way to start, as are your key software vendors whose software you need to keep up to date anyway.
Tip 3. Pick tools and craft your processes
With your newfound patching knowledge, you should be ready to define proper processes and procedures. For larger shops this also means create a team responsible for patching.
Processes include inventorying systems, applications and operating systems, and their current patch status. An asset management system often built into patch management tools is helpful here.
The tool you pick should also be multiplatform, automated as much as possible, and able to install updates and vendor service packs.
Tip 4. Figure out how to test
Even if you have an automated patching solution this doesn’t mean you should 100% rely on automation. In many cases you don’t want to install a patch the moment it is released. Bigger patches can modify your operating systems and apps, and sometimes wreak havoc.
For these, you want a system that can handle conflict testing. Another approach is to set up a virtualized server that mimics your key systems, and roll the patch out against this lab system. One more way is to do a phased roll out so if the patch works fine on one machine you can install it on others.
Tip 5. Wrap your arms around reporting
How do you know what systems you have that need patching, what patches have been installed and whether the patch performs as intended? Solid reporting. Your tool must indicate what patches are working which is handled through acceptance testing, give you an overall view of patch status, and show what patches are missing.