Learn how to manage the security-hotfix process from notification through deployment
Software bugs are an inherent part of the software development process and plague all vendors. Even with the best developers working on a project, the number of software bugs typically increases as the amount of code increases. As a result, malicious users find many opportunities for exploits in OSs such as Windows.
Staying up-to-date with Windows hotfixes can overwhelm an IT department. Hotfixes come out so often that IT feels like a road-maintenance crew that's constantly filling potholes on a strip of heavily traveled highway. The key to keeping your systems safe is to develop an approach to learning about vulnerabilities as they're discovered, determining whether your installation is at risk, assessing the level of risk, deciding when to deploy the hotfixes, and having a plan for deploying them.
Vulnerability Notifications
Because of the frequency of hotfixes, you need a way to keep up with the latest patches. The mainstream media reports only what it considers to be hot stories—widespread propagation of a malicious new worm, for example. But information that helps you protect your systems doesn't sell newspapers or attract sponsors to TV news programs, and you can't rely on the mainstream media to keep you up-to-date.
So where should you turn? Windows & .NET Magazine's Security Administrator Web site (http://www.secadministrator.com) is a great place to start. In addition to requesting the Discoveries and Hot News sections, you can sign up for the free Security UPDATE email newsletter and free email Security Alerts. Another Web site for learning about security exploits is Russ Cooper's NTBugtraq (http://www.ntbugtraq.com), an open mail list for reporting reproducible vulnerabilities. You can get on the list with your own email address or have bulletins sent to a Microsoft Exchange Server public folder. One of my favorite security vulnerability resource Web sites is the SANS Institute's monthly Windows Security Digest (http://www.sans.org/newlook/digests/ntdigest.htm).
Another good resource is Microsoft's HotFix & Security Bulletin Service (http://www.microsoft.com/technet/security/current.asp). At this Web site, you can search for fixes by product and service pack level. Most Security Bulletins include technical details, a list of FAQs, a supporting Knowledge Base article, and the associated patch's URL. Microsoft has also established the Microsoft Security Response Center (MSRC) and designated an internal group to respond to security-related concerns. (For information about the MSRC, see the sidebar "Microsoft's Security Role.")
Evaluating the Vulnerability
After you learn of a security vulnerability, the first thing you need to do is evaluate the problem. Read the information that accompanies the vulnerability notification, and refer to the Web sites I mentioned to understand what the vulnerability involves. When reviewing a vulnerability, consider what the bug is affecting and in which situations the bug will be a problem for you. I strongly suggest that you also refer to sources such as Microsoft TechNet and the Microsoft Developer Network (MSDN) for background on the components affected.
Then, look at the various pieces of your environment to determine whether the vulnerability affects your systems. What affects one company's system might not affect all. This step ensures that you don't waste any time correcting vulnerabilities that don't threaten you. For example, if Microsoft releases a security patch for Microsoft SQL Server and your company doesn't use SQL Server, you don't need to act.
If the vulnerability affects your systems, you need to know to what extent. Addressing Microsoft IIS flaws is more urgent if you have an Internet-connected server than if you have only an internal IIS server. Determine who might take advantage of the bug and how much damage it could do in the worst case.
Often, administrators justify a decision not to promptly apply a hotfix by thinking, "I know and trust all my users. None of them would take advantage of a vulnerability." True, most users won't go out of their way to wreak havoc in your environment. However, there's always the risk posed by curiosity and intrigue as well as the occasional disgruntled worker. You need to rate how serious you consider the security flaw to be for your company. The more serious the vulnerability, the more attention it demands. For example, if you run SQL Server on a server that's exposed to the Internet, patching a Windows 2000 or Windows NT vulnerability should be a high priority.
To help in evaluating vulnerabilities and determining what steps to take, consider creating a security committee. The committee can consist of as many people as you think is appropriate. Ask members from your UNIX, database, and networking groups and from your internal audit teams to play an active role—their experience and expertise can be an asset in determining risk. The entire committee should meet at least once per month; the Windows staff on the committee should meet on a weekly or biweekly basis.
When vulnerabilities surface, the committee can make decisions about which fixes should be applied and how soon. Use the committee as a corporate tool for oversight while letting the individual groups implement the changes. When concerns arise, use the steps I give in this article as a basis for committee decision-making. When the security committee meets, you should also make a point of discussing whether the security review process is working as well as it could.
Now or Later?
After you determine how the vulnerability affects your company, decide how soon you need to take care of the problem. Microsoft typically posts several Security Bulletins per month for Win2K on its security Web site. But do you really need to reboot all of your company's Win2K servers two or three times every month to address security-related concerns? Rebooting Exchange servers and file servers requires downtime and can inconvenience users.
Prev. page
[1]
2
next page 
