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.
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.
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:
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.
