Windows Server 2003 : Security - Patch Management (part 1) - The Patching Cycle

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

Patches—everyone hates them, but they are an inescapable part of the everyday computing world. I hated them and complained about them when I was a UNIX system administrator some 20 years ago. And I still hate them now, even though the overall process of obtaining, testing, and applying them has gotten far better than it was back then.

Real World: Terminology

The first rule of patches is that Microsoft doesn’t like that word. It has several different terms it uses, each with a slightly different meaning, but the reality is that to the rest of the world, they’re still called patches. We call them patches, the magazines and newspapers call them patches, even most Microsoft employees call them patches, unless they’re giving a formal presentation. But Microsoft does have official terminology, and we should all be clear on what it is:

  • Critical Update . A generally available fix for a critical but non-security-related bug. A critical update has an accompanying Knowledge Base article.

  • Security Update . A generally available fix for a security vulnerability. Security updates have an accompanying Knowledge Base article and Security Bulletin.

  • Software Update . A broad term that covers Service Packs, hotfixes, update rollups, security updates, feature packs, and so on. A software update has an accompanying Knowledge Base article.

  • Service Pack . A generally available collection of fixes and feature enhancements. Service packs are cumulative and contain all currently available updates, update rollups, security updates, critical updates, and hotfixes, and they might contain fixes for problems that were found internally and have not been otherwise released. Service packs also sometimes add new features (Microsoft Windows XP SP2, for example).

  • Hotfix . A narrowly available fix for a specific issue. Hotfixes are generally available only through Microsoft Product Support Services and cannot be redistributed. Hotfixes have not had as thorough a test cycle as an update, update rollup, or service pack.

  • Update . A generally available fix for a specific, nonsecurity and noncritical problem. An update has an accompanying Knowledge Base article.

  • Update rollup . A generally available, tested collection of hotfixes, security updates, critical updates, and updates that are packaged together. An update rollup has an accompanying Knowledge Base article.

1. Why It’s Important

In the old days, when your network wasn’t connected to the Internet, when system administrators were the only people who installed software, and when users had only a green screen terminal, deciding when to apply a patch was a fairly straightforward decision. If there was a specific problem you were having and you wanted a bit of overtime on the weekend, you came in and applied a patch. If no one was complaining and you didn’t want to work on the weekend, you threw the tape (patches always came on tapes in those days) in the drawer and waited until you had to come in on the weekend for some other maintenance, or users started complaining about a problem that seemed related. Or you simply never got around to it at all.

Even in the more recent past it was possible to have a more considered and gradual approach to applying patches. When a vulnerability was identified, it often took months before there was any real risk to your network.

Today, that approach simply won’t work, as Code Red, Nimda, Slammer, and others have all too clearly demonstrated. Within hours or at most days of the release of a critical security update, there will almost certainly be sample exploit code posted on the Internet telling anyone and everyone how to exploit the vulnerability. If you ignore critical security updates, you place your entire network, and the data stored on it, at risk.

Applying patches is only one part of a defense-in-depth strategy to protect your network, but it’s a critical part. Don’t neglect it.

Real World: Patch Tuesday

In the old days, patches, especially security updates, were released whenever there was a new vulnerability identified and corrected. When that was happening a few times a year, it wasn’t a big problem, and the system administrator dealt with it as they came out. In most cases, you could just wait till the Service Pack came out, and deal with a whole bunch of them at once. But as more and more security updates and critical updates were released on an almost daily basis, it became increasingly difficult to properly test and identify all the patches that were necessary for your system and the whole process became a serious impediment to productivity.

In direct response to many, many complaints, Microsoft has moved to a monthly update release process. Unless there is a compelling and immediate need for a critical security update to be released off-cycle, all security updates are released once a month on the second Tuesday of the month. This change has greatly simplified the planning and deployment of patches.

2. The Patching Cycle

There are, or should be, four basic phases in the ongoing cycle of maintaining a well-patched and up-to-date network. The four phases are

  • Assess

  • Identify

  • Evaluate and plan

  • Deploy

Each of these phases is essential to the successful management of patches on your network. Depending on the size and complexity of your network, you might combine phases and even bypass them on occasion. However, it’s good to have an understanding of the phases and to think through the steps involved in each one even if you’re combining them.


The assess phase of patch management is all about understanding what your environment is, where and how it is vulnerable and can be attacked, and what resources and procedures are in place to ameliorate those vulnerabilities.

When a patch is released, you can’t make an informed decision about whether you need to install that patch unless you first know what software is present in your environment and what your critical business assets are that absolutely, positively must be protected. So the first step to an overall patch management process is to figure out what software you’re running in your environment. All of it, hopefully. Whether you build a big spreadsheet, have a fully relational database, or use a full-featured tool such as Microsoft Systems Management Server (SMS), you need to get your software environment audited and documented. One tool that can help with that auditing is Microsoft Baseline Security Analyzer (MBSA).

Identify your critical business assets. Is there confidential data that you couldn’t function without? Are there critical systems that must be available at all times? Are there individuals whose productivity is mission critical? All of these are business assets that you should factor into your overall patch management strategy.

The next part of the assessment phase is to understand what security threats and vulnerabilities you currently have. Do you have legacy Windows NT 4 systems that are no longer supported? Are there Windows 95 or Windows 98 machines on your network? Are you running old versions of software programs that can’t be easily updated or replaced? Do you have public-facing Web servers that are not behind your firewall? What are your security policies and how are they enforced? These and many, many more questions need to be asked, and answered.

Finally, you need to assess your patching infrastructure and resources. How do you deploy software and patches? Who is responsible for identifying, testing, and deploying patches? What resources do they have to help with that? How rapidly can you respond to a critical vulnerability that affects your systems? What steps can you take to improve your response time?


The identify phase is about finding out what software updates or patches are available, and how critical it is that they be deployed in your environment.

You need to

  • Discover the patch

  • Decide whether it’s relevant to your environment

  • Download the patch

  • Identify the patch’s criticality

There are many ways to discover patches, but for Microsoft products one of the best is to sign up for e-mail alerts. If you do this, Microsoft will send you notifications of security updates before they are actually released. The sign-up page is at: You can tailor the notification method and detail level to suit your environment.


The link above provides only alerts for security related patches.

Whatever method you use to discover patches, it’s important that you have a way to trust the source of the patch information. All Microsoft security update alerts are signed with a publicly available PGP key, for example. And it shouldn’t be necessary to say this, but just in case: Microsoft will never send a security update as an attachment to an email! Never.

Once you know about a patch, you need to decide whether it’s relevant to your environment. If all your client machines are running Windows XP Professional SP2 (and they should be!), a patch that applies only to Windows 2000 isn’t really relevant to your environment. However, if the patch is a critical security update for Microsoft Office 2003 and you run that in your environment, you’ll need to apply it.

When you determine that a patch is relevant to your environment, you need to obtain the patch from a known and trusted source. For a Microsoft patch, this generally means downloading it directly from Microsoft. Find the relevant Knowledge Base article for the patch, and then cut and paste the link to the download page directly into your browser. Do not click on the link in an e-mail to get your patch. Even when you have verified that the e-mail is really from Microsoft and is a legitimate e-mail, you shouldn’t click on the links in it. Get into the habit of always using cut and paste. When you use cut and paste to put a link into your browser, you greatly reduce the likelihood a "phishing" attack—that is, of being unknowingly redirected to a site that looks exactly like the site you expected to go to, but is actually a site designed to steal information from you or download unwanted spyware onto your computer.


Most e-mail clients today have the ability to force all e-mail to display as "plain text." This is a good thing, because it prevents unscrupulous people from hiding the real destination of a link. The giveaway for detecting a bogus link will usually be that it’s a link to an IP address, not the actual DNS domain name, or if it is a DNS name, it’s not exactly the one you think it is. If you make the change to only reading e-mail in plain text, your e-mail won’t be as pretty, but you’ll give yourself an additional layer of protection from phishing attacks.

To enable plain text e-mail handling in Outlook 2003, select Options from the Tools menu. Click the Preferences tab, and then click on E-Mail Options. Select the Read All Standard Mail In Plain Text and Read All Digitally Signed Mail In Plain Text check boxes. Click OK and restart Outlook.

Once you’ve downloaded the patch and read the associated Knowledge Base article, you are in a position to determine just how critical the patch is in your environment. Is this a patch that needs to be deployed immediately, with limited testing, or even with no testing? Or are there ameliorating factors that allow the patch to be deployed as part of a regular patching schedule after full testing?

Evaluate and Plan

The evaluate and plan phase of patch management flows naturally out of the identify phase, and in many ways is an extension of it. In this phase, you determine how to respond to the software update you’ve downloaded. Is it critical, or even necessary? How should it be deployed? And to whom? Should interim countermeasures be employed that will minimize your exposure to the vulnerability? What priority does the patch have?

The initial determination of need, suitability and priority is made during the identify phase, but in the evaluate and plan phase, you should take a closer look at the patch. What priority is the patch? If it affects a critical business asset, and there’s no easy or appropriate countermeasure except the patch, it will have a higher priority for testing and deployment than if there’s a simple countermeasure that you can implement until the patch can be deployed. If it targets critical business assets, it’s going to have a higher priority than if the only computers that are affected are several old Windows 98 machines that aren’t running any critical business applications.

Once you’ve identified the priority of the patch, you need to plan the actual deployment. Which machines need to have the patch deployed to them? Are there any constraints or issues that interfere with the deployment? Who needs to be notified, and what steps need to be taken so that the deployment minimizes the disruption to the environment? If this is an emergency release, will it go through a staged deployment, or is every affected machine going to have the patch deployed as soon as possible?


The deployment phase of patch management is in many ways the easiest. You’ve done all your preparatory work, now all you need to do is the actual deployment.

First and foremost, communicate. Let everyone who will be affected know that you will be deploying a patch, and what application or area of the operating system it affects. If you know the deployment will cause changes in behavior, tell your users before the deployment. You will have far fewer support calls if you’ve warned people that a certain behavior is expected than if you surprise them.

Depending on what the priority of the patch is and how many machines it affects, you should test your deployment on a subset of the machines or on your test network. If no problems are reported, you can extend the deployment to additional users.


The four phases of patch management are a circle, and when you’ve finished the last phase—deployment—it’s time to start the first phase—assessment—all over again. You should, at the very least, verify that the patch has been successfully deployed to the affected machines. Update your software map and database so that you know which machines have had the patch applied. Ensure that any nonpatch countermeasures have been successfully deployed as well. Verify that the patch hasn’t caused issues for your end users that were missed during the testing of the patch.

Top 10
Free Mobile And Desktop Apps For Accessing Restricted Websites
TOYOTA CAMRY 2; 2.5 : Camry now more comely
KIA SORENTO 2.2CRDi : Fuel-sipping slugger
How To Setup, Password Protect & Encrypt Wireless Internet Connection
Emulate And Run iPad Apps On Windows, Mac OS X & Linux With iPadian
Backup & Restore Game Progress From Any Game With SaveGameProgress
Generate A Facebook Timeline Cover Using A Free App
New App for Women ‘Remix’ Offers Fashion Advice & Style Tips
SG50 Ferrari F12berlinetta : Prancing Horse for Lion City's 50th
- Messages forwarded by Outlook rule go nowhere
- Create and Deploy Windows 7 Image
- How do I check to see if my exchange 2003 is an open relay? (not using a open relay tester tool online, but on the console)
- Creating and using an unencrypted cookie in ASP.NET
- Directories
- Poor Performance on Sharepoint 2010 Server
- SBS 2008 ~ The e-mail alias already exists...
- Public to Private IP - DNS Changes
- Send Email from Winform application
- How to create a .mdb file from ms sql server database.......
programming4us programming4us