Because of the varying configuration-level possibilities and the wide range of applications NT can host, there is no cookie-cutter template for use across all installations. Some may need IIS, some may not. Some applications may require that NetBIOS be bound to the IP stack, others will not. For some organizations putting every service pack, hot fix and Registry tweak in place is a perfectly acceptable solution; for others, it introduces myriad problems that can negatively affect their production environments. The solution is to identify, test and apply the fixes and changes that are relevant to your environment. Half the battle is knowing your environment and applying simple risk-management principles to the practice of system administration. The other half requires you to keep up with service packs, hot fixes and security advisories. If you take the time not only to identify all the issues, but also to create a methodology for addressing them, you'll save yourself a lot of time in the long run.

You can achieve a secure NT environment by standardizing and implementing a secure NT Server "build" before deployment; creating an ongoing vulnerability identification effort; maintaining thorough monitoring of system and event logs; and adopting written policies surrounding the deployment and administration of the servers.

A Secure Build
The concept of standardization is not unique in the security field. The idea here is not to restrict configuration and NT server performance tuning, but to implement a common baseline build in which to run your enterprise. Creating such a build involves applying service packs and necessary hot fixes, as well as performing an assortment of Registry changes and configuration modifications. Again, there is no one-size-fits-all method of doing this--needs vary from organization to organization. What is common throughout, however, is the need to at least investigate all the surrounding issues.

Most organizations try to be at the current service-pack level, and evaluate whether they must implement any of Microsoft's post-service-pack hot fixes. An administrator's gut reaction may be to apply all the released hot fixes, but this is not always wise. Microsoft releases hot fixes in between service-pack releases. Hot fixes often are inadequately regression-tested and regular testing is rarely as thorough as on service packs. Before deploying a hot fix, take the time to see if that particular hot fix really solves your vulnerability problem. If possible, test it on nonproduction servers before deploying it. For a complete list of released hot fixes, check out Microsoft's FTP site at ftp:// ftp.microsoft.com/bussys/winnt/winnt-public/ fixes/usa/nt40.

After you've applied all relevant service packs and hot fixes that solve nearly 100 security problems by themselves, there are further changes to consider. For starters, many Registry modifications can help protect against null sessions, help restrict floppy access, block the possibility of using FPNW (File and Print services for NetWare) for Trojan-based attacks, present legal warnings and protect key Registry components among an assortment of other issues not handled by basic patching (for additional Registry tweaks, see www.networkcomputing.com/1106/1106ws1side2.html). If you don't make these changes, the problems will remain.

After you decide what should be performed on your NT servers, the procedure for implementing these changes should be agreed upon, documented and deployed. Unless the lockdown procedures are agreed upon and standardized, it becomes difficult to assess overall organizational risk. For example, if you know that the servers in Chicago address a defined set of issues but the servers in St. Louis are patched in a haphazard manner, it's virtually impossible to gauge security.

After a base build is agreed upon and ratified, you need to address file and directory permission issues. NT lets administrators protect files on two levels: permission settings on the share points and permission settings on the actual files and directories themselves. Most system administrators choose to lock down files and directories first and then move on to the share permissions if further levels of control are desired.

The core of the NT OS resides in the %systemroot% directory, which is usually c:\winnt. If you look at the default permission for the \winnt directory you'll note that EVERYONE has full control to the directory itself; however, the files below the directory are more strictly controlled. Without exception, lock down \winnt\repair, which contains a copy of the NT SAM (unprotected) after emergency repair disks are created. Unfortunately, NT follows more of a "default allow" philosophy than other OSes, creating a dilemma for those striving for high-level security out of the box. Although some have spent months locking down and reassigning rights to NT system files, services and subsystems, it is a painful process often resulting in sleep disorders. And oh, it usually doesn't work.

Rather then trying to second guess what Microsoft developers were thinking when they wrote NT's various services--and what will break when you change things--we suggest a saner approach: Focus on protecting your valuable data. While no one likes the thought of any data being sacrificial, knowing where your higher-value data resides is useful. Contracts, client lists, financial data and general classified/confidential information usually qualify as high-value data. By starting your access-control efforts at the high-value data level and eventually working your way to the rest of your corporate data, the task becomes slightly less daunting.