Of Windows patch management
Stay in control of updates
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
If there's a new patch available for Windows, you probably want it applied as soon as possible. It is unlikely, though, that you will want to roll out that update to users automatically because whether they contain new features, fix bugs or plug security holes, patches can break applications.
It makes more sense for IT to use Windows Server Update Services to deploy updates, test them and control how they are installed, rather than allowing users to download and install automatically, with all the potential for breakage that follows.
Ultimately, automating patching while retaining control is the goal.
Advance warning
Microsoft updates arrive predictably on Patch Tuesday (the second Tuesday of every month), which means you can plan ahead for testing. You can get advance notice by subscribing to the security bulletin, which comes out three business days before with details of the updates – think of it as Threatening Thursday.
Attackers also get details of the vulnerabilities that have been patched so there's no time for delay before the first attempts to circumvent the patch. Microsoft also occasionally releases important patches on other days besides Tuesday, and these too tend to require urgent attention.
If yours is an industry that is regulated or your organisation has to deal with compliance issues, you need a patching schedule to stay compliant.
Protecting the weak
Microsoft IT must keep 98 per cent of desktops up to date on patches. It is the IT department that has to cope with the patches, not the product teams, so the company has to figure out the impact on internal applications before it rolls them out.
Updates are not universally applicable, so you need to audit to see which systems will need to be patched for given vulnerabilities.
Not all patches are urgent either. New product features tend to be issued in the form of feature and service packs rather than patches but patches can include performance improvements.
In any case, they all need to be evaluated. And you have to take a view between being able to take longer to test less urgent updates and the impact on productivity if users have to reboot for a second batch of updates each month.
Anti-virus signature updates don't need testing and approval, especially for enterprise-grade anti-virus systems that update their definitions three times a day.
Dedicated enterprise anti-virus systems usually do this automatically. If you are managing Forefront Endpoint Protection through System Center Configuration Manager, the 2012 release will let you choose specific languages of definitions to approve automatically.
Race against time
Occasionally Microsoft deems patches so critical that it pushes them out sooner. Because they address significant problems, you need to evaluate them even though the time has not been allocated in advance.
Microsoft's security bulletin and third-party services will alert you to these unscheduled patches (and you may find the third-party advice on the impact of patches worth paying for).
Critical as it may be to deploy patches, a strategy for evaluating them is even more important. You may be tempted to rush out an urgent patch but you need to know if it will disrupt your business applications. The best advice is to keep software audits current so you know which systems will be affected.
Testing, testing
There are several ways to test patches. You can use test systems with scripts that cover system and application functionality or do it more informally by rolling patches out to a subset of users. If that lucky group is the IT team, make sure they have a good mix of production apps and the scripts to run through common tasks.
Larger businesses may want to stagger deployment to reduce the load on the network – and on the support team if updates cause problems.
You need to track which updates have been applied successfully. Even a small business needs a change management system to record patches and updates.
As well as dealing with Microsoft applications you will need a patching strategy for third-party apps and network devices. Third-party tools like App-DNA’s AppTitude and ChangeBase’s AOK help you track updates for multiple products, as well as providing guidance on what applications will be affected by Microsoft updates.
They won't lift the burden of understanding monthly updates, but at least you don’t have to approach the problem from scratch every time. ®
COMMENTS
emptiness
This article has a strange style.
It's title leads me to believe it addresses an area I am genuinely interested in,
I read the whole thing with anticipation.
In the end, all I have is an empty feeling.
Obviously it is an ad for "Get a free report and consultation with an Agile expert"
Even when it is just advertising, I expect something of interest.
Why would I read the report after an article like this?
Only to relieve my curiosity.
Can the report be as empty as the article?
Patch then test or test then patch?
I'm seeing a fascinating amount of pedantical statements here both in favor and against testing patches (and AV signatures) before rolling them out. This amuses me mostly because like all such scenarios, this really should be handled as a risk analysis problem. In some environments, the potential exposure to malicious attacks is rather low, while the impact to the enterprise from a bad patch can be so great, only someone with a total lack of understanding would even consider rolling out ANYTHING, patches, AV signatures, even a 1 line change to a configuration file without extensive testing. In other environments, the situation is the exact opposite - no individual machine (or set of machines) is going to hurt the environment that much if they go down for a short period of time, but an actual intrusion would be enormously disruptive - and there are numerous vectors for such to occur. Not surprisingly, most situations are somewhere between these extremes.
To me, it is obvious that an IT professional needs to evaluate the environment, and create a patching strategy that matches the situation at hand. To attempt to create "The One True Patching Strategy" and declare that it fits every environment you are going to walk into strikes me as naive at best.
-d
odd
we set sophos to quarantine, that way if it goes wrong then we add that "wrong" file to the "ok" signature list on the server, all the clients miraculously work again.
IT infrastructure monitoring strategies
What you need to know about cloud backup
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
