The objective, of course, is to find out about the newly unearthed flaw, obtain a patch and implement it before any maliciously minded individual discovers your unpatched system. To do so would seem a daunting task requiring non-stop attention. In a sense, that's an accurate description.
At first look it seems like an excellent idea to have an automated mechanism for obtaining security patches for identified holes and exploits. Those who are in the best position to discover flaws and holes in an operating system are those who know it best; namely, its authors. There are mechanisms for security conscious system administrators to notify each other of holes, including NTBugTraq.
Details on NTBugTraq can be found at www.ntbugtraq.com. They operate a list service to which you can subscribe and through which system administrators can keep each other informed on Windows security issues (To subscribe: send a message to firstname.lastname@example.org; no subject; in the message area type subscribe ntbugtraq.) As the author of the Windows family of operating systems, Microsoft, among other things, keeps a close eye on NTBugtraq.
Automatic Updates can be found in the control panel in Windows 2000 and as a tab of System Properties in XP and 2003. There are four options available. It can be turned off, which is probably only really a reasonable option on a machine that is never connected to the Internet, or when there are several machines in a site, all of which will need the updates and you wish to conserve bandwidth by downloading only once.
When on, it can be set to notify you before downloading updates, to notify after downloading updates or to simply download updates and install them on a specified schedule.
The use of Windows Automatic Update to notify you of security patches is an excellent mechanism. If you only have a few systems to maintain, or if you don't believe bandwidth consumption will be an issue, then it is also a great method of obtaining updates. There may even be some circumstances in which it would be advisable to use the capability to install updates on a specified schedule, but be careful, however, because a second look at the subject can reveal a downside to this.
The problem with an automated system is that the administrator can lose track of changes that are being made to their systems when those changes don't actually require the administrator's intervention. This may seem relatively minor, but consider this example; a recent security update from Microsoft was presented to systems by the automatic update even though it had a prerequisite of a particular service pack level that had not been met on the subject system.
When installed, the patch caused an incompatibility with a core DLL resulting in a system that would halt with a Stop error on restart (see Q318533 & related articles.) Had the install been performed manually, the administrator would have been clued right into the cause of the problem. Automatically installed updates may have been put in place a few days prior to the restart and would not be immediately associated with the error in the mind of the administrator.
As I have said before, there are a lot of advantages to the automated system. My personal preference is to have automatic updates on systems that I am physically close to and are not in a critical setting. For more mission critical machines, I like to monitor for updates by subscribing to Microsoft's Product Security Notification Service and scheduling times to apply the fixes based on severity of threat, applicability, etc.
As the number of threats increase, it is becoming more and more critical that hotfixes be applied in a timely manner. The same holds true for service packs. It can be a risky proposition to allow time to go by before patching your system.
Remember that those with malicious intent also subscribe to the NTBugTraq and MS Notification services. To them, these services provide a list of new things to look for and try. If your system is already patched when they come looking, they'll just have to move on to the next one.