Securing Windows NT

WINDOWS NT SECURITY is a combination of techniques that ensure a consistent level of protection against unwanted access. To implement security, you must protect your network, the operating system, and your data. You do so by using NT's logon authentication, object security, and user rights. To take advantage of NT's highest security capabilities, C2-level security, you need the correct software and hardware in the specified configuration. NT provides auditing tools to help you assess your NT security situation, but you also need to be aware of the security issues involved with communications over the Internet. So to ensure that you're protected on all fronts, you need to know about all the issues and techniques involved with NT security.

The Security Spectrum
Security breaks down into three main functional areas: over-the-wire network security, OS security, and data encryption.

Network security provides authentication (making sure the data server and the recipient are correct and secure) and ensures data integrity (making sure the data received is the same as the data sent). Achieving network security means implementing a network protocol, such as NetBEUI and TCP/IP, tailored to the data you're transmitting (for more information about network security, see John Enck, "Confronting Your Network Security Nightmares," page 81). On the Internet, security protocols, such as Kerberos, are mostly services that run on top of TCP/IP.

These protocols offer various levels of security, performance (mostly achieved by minimizing security protocol overhead), flexibility, and availability across multiple platforms. After the network infrastructure is in place, adding and extending a security protocol is theoretically straightforward. All you need is a consensus among the members of the networking community--a process like herding cats.

OS security must be integrated from the start. If basic security features aren't present, adding them later is almost impossible. For example, Microsoft was unable to add meaningful security to 16-bit versions of Windows after development. A new 32-bit OS, Windows NT, and a new programming model (the Win32 API) were necessary. NT has robust security features to control user access to objects such as files and directories, the system Registry, and printers.

NT also includes a security auditing system that lets administrators track access to files or other objects, logon attempts, system shutdowns or restarts, and so on (for more on security auditing, see Mike Reilly, "Find Holes in Your NT Security," page 87). In contrast, Windows 95 has only rudimentary logon security, no object security, and only limited logging capabilities.

Data encryption can work in several ways. Many applications have encryption built-in. Some protocols, such as Secure Simple Mail Transfer Protocol (SSMTP), support automatic encryption. Third-party encryption, such as Pretty Good Privacy (PGP), is also available. Microsoft has even added a basic encryption system, the Cryptography API (CAPI), to the Win32 API.

CAPI is a set of functions that let application and systems software developers access independent cryptographic services. NT has a base cryptographic service provider that lets you encode data for secure storage and transmission with a combination of public and private keys. The method of encryption is similar to PGP's method. (For more on data encryption, see Lawrence Hughes, "Secure Enterprise Email," May 1996, "Digital Envelopes and Signatures," September 1996, and "Exchange Email: Signed, Sealed, Delivered," page 103.)

The Facets of NT Security
NT provides security in three fundamental areas. These areas are logon authentication, object security, and user rights.

NT's Local Security Authority validates interactive and remote (via Remote Access Service--RAS) logons to both local and global (domain) accounts, checking them against the Security Account Manager (SAM) database of account names and passwords. The Local Security Authority also manages audit messages.

The Security Reference Monitor checks whether a user has permission to access an object and perform the requested action. It's also responsible for generating audit messages. With the Permissions dialog in NT's File Manager (or Explorer under NT 4.0), you can secure most objects. For example, NT 4.0's Distributed Component Object Module (DCOM) object server activation and access security is fully integrated into the NT security model (for more on DCOM, see my article, "NT 4.0's Distributed Component Object Model," September 1996).

Besides object security, NT lets you control an account's ability to perform system-related functions. With NT's User Manager (or User Manager for Domains), you can control which account or group can, for example, add workstations to a domain (for information about domains, see Mark Minasi, "Domains and Workgroups," April 1996, and Ed Tittel and Mary Madden, "Domains, Trust Relationships, and Groups," June 1996), back up or restore files and directories, change the system time, log on locally, manage auditing and security logs, and shut down the system. The Local Security Authority maintains the Account Policy.

Administering Accounts: Logon Authentication
NT manages both machines and users. So it must validate authorized users and provide them with the means to access the system.

At the highest level, an NT domain is a collection of machines that domain controllers administer as one and that share a security database. That database maintains information for all users with accounts in that domain and for groups (collections of users). An NT domain account--a global account--has the form domain\user. If you log on to an NT machine, you can use this style of reference in the Connect As option of the Map Network Drive dialog to connect to a resource as a different user--even in a different domain. (The system will prompt you for that user's password.)

Besides domain accounts, each machine can have a local security database containing information about users--and groups--that only that machine knows about. Local machines behave like standalone domains. Accounts on local machines have the form machine\user, but these accounts or groups are not available on other machines.

The primary tool for administering users and groups on a domain is usrmgr.exe, or User Manager for Domains, which ships with NT Server. A reduced-functionality version, musrmgr. exe or User Manager, ships with NT Workstation and displays information only for the local system. Screen 1 shows usrmgr.exe, which can display both domain and local information, depending on the commands you use to start it: usrmgr manages the domain the user is currently logged on to, usrmgr domainname manages a specific domain, and usrmgr \\machinename manages a specific machine.

Loading domains in organizations with thousands of domain users can take several minutes. The ability to start with a particular machine or domain can save an administrator time. usrmgr also lets administrators manage trust relationships with domains, so users in domain A can access resources in domain B as if those users were part of domain B.

A permanent unique value, a Security Identifier (SID), identifies individual users and groups. After the system assigns the SID, the system won't use that ID again. If you delete a user or group and then re-create it, that group or user must receive a new SID, and you have to reestablish any object access rights for the new SID.

Access Through APIs: Object Security
NT enforces object security by ensuring all object-related requests go through its built-in security mechanism. Many Win32 API functions have optional security-related parameters, and all programs running under NT must use these APIs to access objects. If you could shell out to a DOS prompt and copy, rename, or delete a file without using these functions, security would be pointless. In fact, the ability to directly manipulate hardware in 16-bit Windows and DOS--and the fact that Windows 95 provides complete 16-bit Windows and DOS support--is a major problem in trying to provide a secure system for those environments.

The security parameters in the Win32 API are optional, but NT usually requires them when a program accesses a systemwide resource (e.g., setting the system time). Some applications can implement security when working with user files or directories--the impact on performance is negligible--but most API calls don't specify security information.

Win95 doesn't know anything about security and ignores all security parameters. This blind spot can lead to some subtle differences in how a program that runs under both NT and Win95 behaves. (This is just one reason why testing software on both platforms is important.)

Implementing security at the API level has another subtle implication. In client/server applications, the server application usually controls object access. Because the client usually doesn't access security directly, the server often needs to act as the client's proxy. The server can either impersonate the client using the Impersonate...() APIs or log on as the client (if the server has the client's username and password).

Securing Objects
Besides files and directories, NT secures many other objects. The Win32 API implements five function groups that work with security descriptors and correspond to five kinds of objects.

• File and directory objects: NT stores their security information (including mail slots and named pipes) with the objects. Security for these objects is available only on NT File System (NTFS)-formatted volumes.
• User objects (window-management objects): These objects include windows station and desktop objects. All User objects are in memory and are never persisted (saved) to disk.
• Kernel objects: The Windows kernel uses these objects, which include processes, threads, and semaphores and mutexes (signaling objects that control access to objects and code). Like User objects, kernel objects are not persisted.
• Service objects: These objects, which include any Win32 service listed in the Control Panel, are under the control of the Service Control Manager and are not persistent.
• Private objects: Application programs can implement and must maintain their own security, and private objects let them interact with the Win32 security system. For example, a database system, perhaps SQL Server, might need to store security information internally and use NT's user domain validation. The Registry is a Win32 API implementation of private objects. Security information is stored inside the Registry.

A security descriptor (SD) describes the security attributes of each securable object. These attributes identify the object's owner and two access control lists (ACLs), one for object access and the other for auditing. The ACL for object access is the discretionary access control list (DACL). It contains several access-control entries (ACEs). Each ACE identifies an SID and its access permission (allowed or disallowed). The other ACL is the system access control list (SACL), which controls event auditing.

Very Important Privileges: User Rights
In addition to access rights, which are associated with objects, NT implements privileges. To assign object rights, you use File Manager or Explorer; to assign privileges, you use User Manager. Privileges become part of the access token that a user receives when successfully logged on to the system. The OS determines the set of privileges available; applications can't define their own. Table 1 shows the privileges NT 4.0 understands.

Privileges are a source of frustration. Have you ever added an account to a system, tried to log on to that account, and received the message, "The local policy of this system does not permit you to log on interactively?" By default, NT assigns new users to the group Users, but this group, also by default, doesn't have permission to log on locally.

With Microsoft's Internet Information Server (IIS), you can run into a similar problem. The pre-established Internet user account, iusr_machine, is a local account with few privileges, so you can't use it as the IIS anonymous-logon account if the user specifies Hypertext Transfer Protocol (HTTP) basic authentication.

If you explore usrmgr.exe, you find the Everyone group under Access this computer from the network, although the system doesn't appear to have this group. NT defines a few well-known SIDs, such as Everyone and Interactive, to help you work with common access rights.

In general, privileges override individual object security. An example of needing to override security is when a backup administrator must change the archive flag on every file on a volume. Without the corresponding privilege, the administrator has to add another ACE to each file to let the backup program touch the flag. If you add the SID for Everyone to a privilege or access right, NT security doesn't have to check any further, so some operations go faster.

C2 Security
According to the Trusted Computer System Evaluation Criteria (TCSEC) published by the National Computer Security Center (NCSC)--C2 security requires a specific combination and configuration of software and hardware. NT is not a C2-secure OS, but you can make it C2-secure. Microsoft designed this capability into NT's security model from the beginning. Here are some requirements of C2-level security.

• A resource's owner must control access to that resource.
• Each user must enter a unique logon name and password before that user can access the system.
• The system must track each user's activities.
• Systems administrators must audit security-related events, and access to audit data must be secure.
• The system must protect itself from external interference or tampering.

The Windows NT Resource Kit includes the c2config.exe (C2 Configuration Manager) utility, which tests a system for compliance with each C2 requirement as you see in Screens 2 and 3. (For more information about C2 security on NT, see Anne Fischer Lent, "C2 Clearance," and Roger Tachuk, "What Is C2 Security?" November 1995.)

Auditing Events
Auditing can disclose unauthorized access attempts. You have to balance the costs against the benefits of auditing. The costs include the impact on system performance and disk space and the effort required to sift through potentially large volumes of transactions, searching for meaningful information.

The primary auditing tool in NT is the Event Log. It lets you audit successful and failed object access and user rights events. The Auditing dialog in NT's Explorer, for instance, lets you audit Read, Write, Execute, Delete, Change Permissions, and Take Ownership file and directory events. Screen 4 shows the information the Event Log provides.

With usrmgr.exe, you can turn auditing on or off for logon and logoff, file and object access, use of user rights, user and group management, security policy changes, and restart, shutdown, and system-process tracking. Of course, if you don't enable the user rights to Manage auditing and security log (see Table 1 for a list of rights), you can't change anything.

Internet Security Framework
In contrast to NT's well-established security model, Microsoft's Internet security model is an evolving process that became apparent only with the company's major Internet push. The Internet Security Framework (ISF) is more a collection of related network protocols than a framework.

ISF provides several specialized network protocols on top of the CAPI and Microsoft's code-signing effort, Authenticode, which uses third-party certifying authorities to ensure that no one tampers with downloaded code and that the code has a known publisher. (For information on Authenticode, see www. microsoft.com/intdev/signcode.)

ISF's network protocols include:

• Point-to-Point Tunneling Protocol (PPTP), which establishes a secure network connection over unsecure network segments
• Secure Sockets Layer (SSL) and its enhanced version, Private Communications Technology (PCT), which provide server authentication, encryption, and data integrity
• SET (Secure Electronic Transaction), which provides authentication and confidentiality for cardholders, merchants, and acquirers. SET has wide industry support (e.g., Microsoft, Netscape, IBM) and the latest specification is available on both the Visa and MasterCard home pages (www.visa.com, www.mastercard.com)
• Personal Information Exchange (PFX), which transfers personal security information (for instance, Microsoft's proposed Wallet for keys, certificates, and credit card information) among computers and platforms

ISF encrypts all network packets. However, applications can have additional encryption. For instance, with code that Microsoft licensed from NorTel and RSA, Microsoft Exchange can protect email with end-to-end message signing/encryption. The North American version of Exchange can use either 56-bit Data Encryption Standard (DES) or 64-bit CAST encryption. Export restrictions limit other national versions to the 40-bit CAST encryption.

Accidents Waiting to Happen
NT uses a variety of technologies to handle security. The increasingly distributed nature of today's applications and the rapid rise of communications outside the organization--most important, over the Internet--complicates drawing a line around something and calling it secure. Although only a few security technologies are appropriate in any situation, you need to understand all that's available to ensure that systems do not become accidents waiting to happen.