In enterprise IT shops, system patching is a complicated process involving large numbers of test systems which mirror production systems so that each new patch arriving from operating system and software vendors can be tested in a real world environment to see how they interact with the hardware and software combinations available in the organization.\u00a0 In an ideal world, every shop would have a managed patching process that immediately responded to newly published patches, tested instantly and applied as soon as the patch was deemed safe and applicable.\u00a0 But the world is not an ideal one and in real life we have to make due with limited resources: physical, temporal and financial.<\/p>\n
Patches are generally released for a few key reasons: security, stability, performance and, occasionally, to supply new features.\u00a0 Except for the addition of new features, which is normally handled through a different release process, patches represent a fix to a known issue.\u00a0 This is not a “if it is not broken, don’t fix it” scenario but is a “it is broken and has not completely failed yet” scenario which demands attention – the sooner the better.\u00a0 Taking a “sit back and wait” approach to patches is unwise as the existence of a new patch means that malicious hackers have a “fix” to analyze and even if an exploit did not exist previously, it will very shortly.\u00a0 The release of the patch itself can be the trigger for the immediate need for said patch.<\/p>\n
This patch ecosystem creates a need for a “patch quickly” mentality.\u00a0 Patches should never sit, they need to be applied often as soon as they are released and tested.\u00a0 Waiting to patch can mean running with critical security bugs or keeping systems unnecessarily unreliable.<\/p>\n
Small IT shops rarely, if ever, have test environments whether for servers, networking equipment or even desktops.\u00a0 Not ideal but, realistically, even if those environments were available few small shops have the excess human IT resources available to run those tests in a timely manner.<\/p>\n
This is not as bleak as it sounds.\u00a0 The testing done for most patches is redundant with patching already tested by the vendor.\u00a0 Vendors cannot possibly test every hardware and software interaction that could ever happen with their products but they generally test wide ranges of permutations and look at areas where interactions are most likely.\u00a0 It is rare for a major vendor to cripple their own software with bad patches.\u00a0 Yes, it does happen and having good backups and rollback plans are important, but in day to day operations, patching is a relatively safe process that is far more important to do promptly than it is to wait for opportunities that may or may not occur.<\/p>\n
Like any system change, patches are best applied in frequent, small dosages.\u00a0 If patches are applied promptly then normally only one or a few patches must be applied at the same time.\u00a0 For operating systems you may still have to deal with multiple patches at one time, especially if patching only weekly, but seldom must you patch dozens or hundreds of files at one time when done in this manner.\u00a0 When done like this it is vastly easier to evaluate patches for adverse affects and to roll back if a patch process goes badly.<\/p>\n
The worst scenario for a small business lacking a proper patch testing workflow is to wait on patches.\u00a0 Waiting means that systems go without needed care for long periods of times and when patches are finally applied it is often in large, bulk patch processes.\u00a0 Applying many patches at once increases the chances that something will go wrong and, when it does, identifying which patch(es) is at fault and producing a path to remediation can be much more difficult.<\/p>\n
Delayed patching is a process that provides little or no advantage to either IT or a business but does carry substantial risk to security, stability and performance.\u00a0 Best practices for patching in a small environment is either to allow systems to self patch as quickly as possible or to schedule a regular patching process, perhaps weekly, during a time when the business is most prepared for patching to fail and patch remediation to be handled.\u00a0 Whether you choose to patch automatically or simply to do so regularly through a manual process, patch often and promptly for best results.<\/p>\n","protected":false},"excerpt":{"rendered":"
In enterprise IT shops, system patching is a complicated process involving large numbers of test systems which mirror production systems so that each new patch arriving from operating system and software vendors can be tested in a real world environment to see how they interact with the hardware and software combinations available in the organization.\u00a0 … Continue reading Patching in a Small Environment<\/span>