The rise of Microsoft Windows NT as a platform for serious business computing is well-documented. Less well-documented is the dramatic increase in the number of people asking this question: "How do I install and administer Windows NT as a secure platform for serious business computing?" Unfortunately, Microsoft has done such a brilliant job of marketing NT that some people have no trouble believing that a complete answer to this question could fit into a single magazine article.

We hate to deflate great expectations, but the fact is, NT security just isn't that simple. Anyone who thinks it is, has a rude awakening in store, quite possibly some time after valuable data has been compromised. However, it is possible for a single article to provide a viable launch pad for your efforts to maximize NT security, complete with an accurate set of charts and a decent compass.

The Mists of Misperception
A ship's compass, guiding you through the fog, is a helpful image when embarking upon the journey to secure computing with NT, if you substitute security-savvy for magnetic north. Unfortunately, very few products come with security-savvy included, and NT is no exception. What is security-savvy? Equal parts paranoia and cunning, technical skill and human understanding, security-savvy is the ability to see security implications where others don't, to anticipate the ways in which other people will abuse, misuse, and subvert an information system. This is not a vague theoretical notion. When you analyze the long-running argument about which is more secure, UNIX or NT, you find that one of the main things UNIX has going for it is years of accumulated security-savvy.

Which brings us to the starting point for seekers of NT security, a clear perception of the product. NT is a powerful operating system with sophisticated security capabilities. But NT is not as mature as older operating systems, and at this point in time NT is "not locked down out of the box, especially on Windows NT Workstation." These are Microsoft's words, not ours. In other words, there are a great many security features in NT, and it has the potential to provide a relatively safe operating environment. But it will not achieve that potential unless it is installed and administered by well-trained, security-savvy personnel, who are realistic about both its strengths and weaknesses.

The next point to be clear on is that secure networking with NT means NT Server. NT Workstation is fine as a client operating system, but the peer-to-peer networking it supports should only be used within highly trusted environments with no outside connectivity (note that a highly trusted environment is one which is physically secure and populated by users you can count on to be as honest and diligent as yourself). What we are talking about here is appropriate security. This can only be determined after a proper assessment of the value of your network and the risks it faces. These will obviously vary between, for example, the accounting system at the local pet store and the reservation system for a major airline. After assessment comes policy, deciding who is allowed to do what, and how they should go about doing it. You cannot configure NT as a secure network server unless you have policies in place to guide you through its installation and configuration. Where to begin?

One of the basic considerations for safe networking with NT has to be the protocols you are going to network with. Running NetBIOS over TCP/IP on your internal network and then connecting that network to the Internet is inherently dangerous. The reason? When you run NetBIOS over TCP/IP, you open all your print, file, and application sharing services to any system that can run TCP/IP, that is, by definition, any computer on the Internet. The simplest solution is to disable NetBIOS over TCP/IP with the Network applet on the Control Panel, then run native Microsoft file, print, and application services with NetBIOS over either Internet Packet eXchange (IPX)/Sequenced Packet eXchange (SPX) or NetBEUI (which are much harder for a hacker to access over the Internet). Because you can run TCP/IP on your internal network without running NetBIOS over TCP/IP, all your systems can still access the usual TCP/IP and Internet services.

But what if design or political considerations prevent you from disabling NetBIOS over TCP/IP? This is where policy meets practical considerations. If you have to live with NetBIOS over TCP/IP, any connection between the internal network and the Internet needs to be firewalled to filter out traffic on the sockets used for NetBIOS traffic (UDP 137, UDP 138, and TCP 139). This will prevent NetBIOS traffic flowing between your network and the Internet (note that the firewall itself does not have to run NT, and it might be safer if it didn't -- using a different OS for the firewall adds a degree of defense-in-depth, not to mention the fact that NT firewalls have not done too well in recent tests).

Moving past the protocol issue to NT installation, you should choose NTFS (NT File System) over FAT (if you have already chosen FAT, you can choose retroactively with the CONVERT utility). NTFS volumes can apply access-control lists (ACLs) to files and directories. FAT cannot. NTFS is an essential part of implementing policies that maximize NT security. Once you have performed the initial installation of NT, you need to find out which service packs and security-related hotfixes you need to install. Review the associated Microsoft Knowledgebase articles for implementation details (see Table of Patches -- note some patches need to be installed in a specific sequence in order to work properly). While this is something of a pain, the fact is that NT vulnerabilities will continue to come to light and it is unlikely that the code on the CD you take out of the box will be completely up-to-date in this regard.

Safety Measures
Since your NT security efforts are going to be an implementation of your organization's security policy, one of the first things you will want to do is capitalize on NT's ability to notify potential users of their legally liability if they attempt unauthorized use of the network. You can display this warning in a custom dialog box that appears before log on. Assign the following Registry key values on the system to be protected (before editing the Registry be sure to back it up -- if you are not clear on how to do this, run and read regedit.hlp). You can also accomplish this particular task with the System Policy Editor in Windows NT 4.0 or the C2CONFIG.EXE program.

Key: HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon
Value: LegalCaption (REG_SZ):
Your message box title Key: HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon
Value: LegalNoticeText (REG_SZ): Your message box text

Another log on adjustment you should make is to the default setting the causes NT to display, in the logon dialog box, the username of the last user logged into the system. This reveals the username of a valid user to would-be intruders, and you don't want to give these folks the least bit of help. To hide the name of the last user, set the following registry key to 1 (you can set this key using the Microsoft C2 configuration utility within the Windows NT Resource Kit): HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\WinLogon\DontDisplayLastUserName

Still on the subject of logging in, make sure all users know to always press CTRL+ALT+DEL before logging on. This helps defeat password sniffing programs that present themselves as a waiting logon screen. By pressing CTRL+ALT+DEL you get the secure logon screen provided by Windows NT. Users should also be taught to either log off or lock their workstation whenever they are away from the computer for any length of time. Logging off is more secure because the password to a valid account is required to log back on. For automatic locking, enable a password protected 32-bit screen saver with a low timeout value, such as 5 minutes. On the subject of passwords, you will want to deter brute-force password-guessing attacks by using NT's User Manager to set an account-lockout policy. For example, the policy might specify that NT will lock out an account after five failed log-on attempts.

Policy and Policing
The next step is another policy issue: administrators should log off domain controllers as soon as they have completed any administrative tasks. This is because NBTSTAT.EXE can be used to determine the name of a user logged on interactively on a Windows system, including an administrator working on a domain controller. You might also consider performing administrative tasks remotely from another Windows NT system when feasible. Another admin policy: don't use admin accounts for general work. There is a natural tendency for people who do administrative work on the system to use the same account for general activity (like word processing or email). Make sure those users who need admin privileges also have, and use, a separate account for non-admin work. Apart from minimizing the exposure of admin privileges to session hi-jacking, this measure will avoid accidental changes to protected resources by people performing non-admin work while logged on with administrative privileges. As far as possible, keep the number of users with administrator privileges to a minimum.

Staying with administration, the name of the built-in Administrator account should be changed, as soon as possible after NT is installed, to something less obvious (using the User Rename menu choice in User Manager). Why? This account is a favorite target for interlopers attempting entry by repeatedly guessing passwords, because it is the one account that can never be locked out by repeated failed logon attempts. By renaming the account, you force attackers to guess the account name as well as the password (you might want to consider creating and maintaining a dummy account, with low privilege, called "Administrator" so that you can monitor it for patterns of attempted access -- this can reveal inappropriate activity by insiders as well as outside attackers). As a defense against intentional failed logons disabling all privileged accounts on a system, the Administrator Account, by default, cannot be locked out by failed logon attempts. However, you can foil such attacks with the PASSPROP utility from the NT Resource Kit. This enables account lockout on the Administrator account. The command is:
PASSPROP /ADMINLOCKOUT

Even if the Administrator account is locked out, it can still be used to logon interactively to any domain controller, which prevents total lockout of the system. Another account that needs attention is the Guest account, which you should prohibit from Writing or Deleting any files, directories, or Registry keys (with the possible exception of a separate Guest directory where information can be left). A better idea is to remove the built-in Guest (you can use C2CONFIG.EXE for this) and create a very limited access account for visitors, with a non-obvious name (for example, use Joe Higgins rather than Visitor).

Next comes auditing, which is a vital part of policing and maintaining the security of NT networks. Be sure you are auditing failed and successful security events, such as login and logoff attempts, file and object access, use of user rights, account management, security policy changes, restart and shutdown, and process tracking (do this via User Manager -- the Policies Audit menu choice leads to a screen that controls auditable events). A discussion of recommended system auditing settings is available on Microsoft's site (see "A Dozen NT Security Resources"). But whatever audit choices you make, be sure that you do two things with the audit logs: check them and protect them. There is no point auditing if you don't review the logs. Regular review of logs, especially of security related events, is vital to the protection of a system, detection of attempted compromise, and damage control of successful penetrations. And if you don't backup your audit logs to a secure location, it is possible that a successful intruder could alter them to cover her tracks.

Other Chores
Establish new users correctly. The system administrator, as with all systems, must determine the rights and access needed by new users and accounts. The user/group architecture of Windows NT, allows for the implementation of extremely granular access. The access for any user should be limited only to the access explicitly allowed that user, with all other access explicitly denied.

Brief new users and updating current users. It is important that users understand acceptable use policy, password guidelines, and general security issues in order to maintain the integrity of information systems.

Remove accounts and revise access rights. When an individual departs from an organization or changes roles, access information and accounts must be immediately updated or removed to meet new requirements. One of the potential weaknesses of any information system is poor communication between those who determine or control access and those who implement it. Also, periodically check for, and disable, inactive user accounts.

Finally, check regularly that all of NT's password control features have been implemented, including password strength, length, and freshness. Similarly check trust relationships to make sure users in all domains are abiding by your security policy.

Conclusions
The creation of secure implementations of Windows NT is a multistage process. First, a security policy must be defined for the organization. Next, systems must be evaluated for their current configuration, and updated to comply with organizational standards. Finally, systems must be regularly reviewed to assure continued compliance. Several tools exist to assist in testing the configuration of NT systems. For example, Kane Security Analyst for Windows NT (KSA) can help determine and audit the configurations of multiple systems on a recurring basis. Internet Security Scanner (ISS) and Ballista are two useful tools for evaluating TCP/IP based systems, including Windows NT, as well as firewalls and web servers.

Just as changes in specific users' access requirements change, the overall security requirements for a system can change as well. Not only compliance with policy, but also policy itself should be regularly reviewed. Recently we have seen rapid changes in the security posture of NT, along with a growing body of knowledge in the hacker and research community. The frequency of security advisories concerning NT has risen sharply, so systems must be kept aggressively up to date.

Finally, get ready to respond to security violations. A critical element in the your response will be the elimination of possible backdoors. When a tool such as KSA is available, use its digital signature features to ensure that system files have not been altered. Examine system and security logs to determine the level of compromise. Utilize tools such as DumpACL from Somarsoft to ensure the integrity of security settings and access control. If compromise is at an administrator level, and reasonable assurances cannot be made as to system integrity, reinstall system files from CDROM.