Chapter 6 - Windows NT Security

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Computer security refers to the protection of all components—hardware, software, and stored data—of a computer or a group of computers from damage, theft, or unauthorized use. A computer security plan that is well thought out, implemented, and monitored makes authorized computer use easy and unauthorized use or accidental damage difficult or impossible.

Microsoft included security as part of the initial design specifications for Windows NT, and it is pervasive in the operating system. The security model includes components to control who accesses which objects (such as files and shared printers), which actions an individual can take on an object, and which events are audited.

This chapter provides an overview of both the security features and the Windows NT security model itself. It describes the components that make up the model, and explains how Windows NT tracks each user and each securable object. It shows how Windows NT validates access requests and how it audits activities performed on protected objects.

This chapter also describes three levels of security—minimal, standard, and high-level—with recommendations for both assessing your needs and for implementing the most appropriate security measures for your organization. It concludes with a section describing C2 security.

Windows NT Security Features

A number of features make it easy to customize permissions in Windows NT. Introduced briefly in this section, these features are described in detail in the documentation for Windows NT Workstation and Windows NT Server. Become familiar with theses features so that you can plan and implement the security configuration you desire.

Caution No operating system can provide physical security for your computers. External media drives (floppy disk, CD-ROM, and so on) provide the physical means for anyone to bypass Windows NT and gain access to your files. For information on physical security, see the "Physical Security Considerations" section in "High-Level Security" later in this chapter.

User Accounts

Windows NT security is based on the concept of user accounts. You can create an unlimited number of accounts, grouping them as appropriate. You then permit or restrict their access to any computer resource. User accounts are described in detail in Chapter 2 "Working with User and Group Accounts" in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

Passwords

In Chapter 2, "Working with User and Group Accounts" in Microsoft Windows NT Server Concepts and Planning, you'll also find a description of the password enforcement options, such as minimum password length, minimum and maximum password age, password "uniqueness" (how often a password can be reused), and controls over whether a user can—or must—change his or her password. For procedural information, see Help

File and Directory Protection

A range of file protections can be set on a per-file or per-directory basis. The protections can be on a per-user or per-group basis. This feature is described in Chapter 4, "Managing Shared Resources and Resource Security," in Microsoft Windows NT Server Concepts and Planning. Specific files to protect are described later in this Chapter, in the section "Protecting Files and Directories" under "High-Level Security." For procedural information, see Help.

Registry Protection

Because the Registry is the repository of all system configuration information, it is important to protect it from unauthorized changes. At the same time, individuals and programs that need to access or alter information in the Registry must be allowed to do so. Part V, "Windows NT Registry," describes the Registry and the Registry Editor, including information on protecting keys in the Registry. Specific keys to protect are described later in this book, in the "Protecting the Registry" sections under "Standard Security" and "High-Level Security." For procedural information, see Help.

Printer Protection

You can prevent specific users from printing to a system printer for all or part of the day. This feature is described in Chapter 4, "Managing Shared Resources and Resource Security," in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

Auditing

Auditing is built into Windows NT. This allows you to track which user account was used to attempt what kind of access to files or other objects. Auditing also can be used to track logon attempts, system shutdowns or restarts, and similar events. Auditing is described in Chapter 9 "Monitoring Events" of Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

Monitoring Performance

The Windows NT Performance Monitor not only helps administrators fine-tune performance, but it can also warn of approaching problems. Performance Monitor can also help you spot the activity of a virus (by spotting performance degradation) or an attempted break-in (by tracking logon attempts). Performance Monitor can be set to send an alert to one or more administrators when certain events occur. For more information, see Chapter 8, "Monitoring Performance," in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

For a thorough discussion of performance monitoring in Windows NT, see Part 3, "Optimizing Windows NT" in this book.

The Security Model

Chapter 5, "Windows NT Workstation Architecture," describes the overall architecture of Windows NT. As shown in Figure 6.1, the Windows NT security model includes the following components:

• Logon processes, which accept logon requests from users. These include the initial interactive logon, which displays the initial logon dialog box to the user, and remote logon processes, which allow access by remote users to a Windows NT server process.

• Local Security Authority, which ensures that the user has permission to access the system.

  This component is the center of the Windows NT security subsystem. It generates access tokens (described later in this chapter), manages the local security policy, and provides interactive user authentication services. The Local Security Authority also controls audit policy and logs the audit messages generated by the Security Reference Monitor.

• Security Account Manager (SAM), which maintains the user accounts database. This database contains information for all user and group accounts. SAM provides user validation services, which are used by the Local Security Authority. SAM is also known as the Directory database.

• Security Reference Monitor, which checks to see if the user has permission to access an object and perform whatever action the user is attempting. This component enforces the access validation and audit generation policy defined by the Local Security Authority. It provides services to both kernel and user mode to ensure the users and processes attempting access to an object have the necessary permissions. This component also generates audit messages when appropriate.

Figure 6.1 Windows NT Security Components 

Together, these components are known as the security subsystem. (Note that because it affects the entire Windows NT operating system, this is considered an integral subsystem rather than an environmental subsystem.)

The Windows NT security model is designed for C2-level security as defined by the U.S. Department of Defense. For more information about C2-level security, see "C2 Security" later in this chapter.

Users, Objects, and Permissions

The key objective of the Windows NT security model is to regulate access to objects. The security model maintains security information for each user, group, and object. It can identify access attempts that are made directly by a user, and it can identify access attempts that are made indirectly by a program or other process running on a user's behalf. Windows NT also tracks and controls access to objects that users can see in the user interface (such as files and printers) and objects that users can't see (such as processes and named pipes).

An administrator assigns permissions to users and groups to grant or deny access to particular objects. The ability to assign permissions at the discretion of the owner (or other person authorized to change permissions) is called discretionary access control. For more information, see Chapter 4, "Managing Shared Resources and Resource Security," in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

Security Information about Users

Users are identified to the system by a unique security ID (SID). Security IDs are unique, and there is no possibility of having two identical security IDs.

For example, suppose Sally, who has a Windows NT account, leaves her job at a company but later returns to a different job at the same company. When Sally leaves, the administrator deletes her account, and Windows NT no longer accepts her security ID as valid. When Sally returns, the administrator creates a new account, and Windows NT generates a new security ID for that account. The new security ID does not match the old one, so nothing from the old account is transferred to the new account.

When a user logs on, Windows NT creates a security access token. This includes a security ID for the user, security IDs for the groups to which the user belongs, plus other information such as the user's name and the groups to which that user belongs. In addition, every process that runs on behalf of this user will have a copy of his or her access token. For example, when Sally starts Notepad, the Notepad process receives a copy of Sally's access token.

Figure 6.2 illustrates the contents of an access token.

 

Figure 6.2 Access Token Contents 

Windows NT refers to the security IDs within a user's access token when he or she tries to access an object. The security IDs are compared with the list of access permissions for the object to ensure that the user has sufficient permission to access the object.

How Windows NT Creates an Access Token

Before a user can do anything on a Windows NT system, he or she must log on to the system by supplying a username and password. Windows NT uses the username for identification and password for validation. The following procedure illustrates the interactive logon process for Windows NT.

The initial logon process for Windows NT is interactive, meaning that the user must type information at the keyboard in response to a dialog box the operating system displays on the screen. Windows NT grants or denies access based upon the information provided by the user.

 

Figure 6.3 Windows NT Validation Process 

The following list details the steps included in the interactive logon and validation process, as illustrated in Figure 6.3:

1. The user presses CTRL+ALT+DEL to gain the attention of Windows NT. This key combination before logon protects against Trojan Horse-type programs that impersonate the operating system and trick users into disclosing their username and password.

2. When the user provides a username and a password, the logon process calls the Local Security Authority.

3. The Local Security Authority runs the appropriate authentication package.

   Note Windows NT can support multiple authentication packages that are implemented as DLLs. This flexibility gives third-party software vendors the opportunity to integrate their own custom authentication packages with Windows NT. For example, a network vendor might augment the standard Windows NT authentication package by adding one that allows users to log onto Windows NT and the vendor's network simultaneously.

4. The authentication package checks the user accounts database to see if the account is local. If it is, the username and password are verified against those held in the user accounts database. If it is not, the requested logon is forwarded to an alternate authentication package.

5. When the account is validated, the SAM (which owns the user accounts database) returns the user's security ID and the security IDs of any global groups to which the user belongs.

6. The authentication package creates a logon session and then passes the logon session and the security IDs associated with the user to the Local Security Authority.

7. If the logon is rejected, the logon session is deleted, and an error is returned to the logon process.

   Otherwise, an access token is created, containing the user's security ID and the security IDs of Everyone and other groups. It also contains user rights (described in the next section) assigned to the collected security IDs. This access token is returned to the logon process with a Success status.

8. The logon session calls the Win32 subsystem to create a process and attach the access token to the process, thus creating a subject for the user account. (Subjects are described in the section called "Subjects and Impersonation," later in this chapter.)

9. For an interactive Windows NT session, the Win32 subsystem starts the desktop for the user.

After the validation process, a user's shell process (that is, the process in which the desktop is started for the user) is given an access token. The information in this access token is reflected by anything the user does, or by any process that runs on the user's behalf.

User Rights

Typically, access to an object is determined by comparing the user and group memberships in the user's access token with permissions for the object. However, some activities performed by users are not associated with a particular object.

For example, you might want certain individuals to be able to create regular backups for the server. These people should be able to do their job without regard to permissions that have been set on those files. In cases like this, an administrator could assign specific user rights (sometimes called privileges) to give users or groups access to services that normal discretionary access control does not provide. (You can use the following dialog box—from the User Manager tool—to assign user rights.)

 

Backing up files and directories, shutting down the computer, logging on interactively, and changing the system times are all examples of user rights defined by Windows NT.

Note In the current release of Windows NT, the set of user rights is defined by the system and cannot be changed. Future versions of Windows NT might allow software developers to define new user rights appropriate to their application.

For more information about permissions and user rights, see "Software Security Considerations" in the "High-Level Security" section later in this chapter. Also, see Chapter 4, "Managing Shared Resources and Resource Security," in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

Subjects and Impersonation

One objective of the Windows NT security model is to ensure that the programs a user runs don't have greater access to objects than the user does.

A subject is the combination of the user's access token plus the program acting on the user's behalf. Windows NT uses subjects to track and manage permissions for the programs each user runs.

When a program or process runs on the user's behalf, it is said to be running in the security context of that user. The security context controls what access the subject has to objects or system services. To accommodate the client-server model of Windows NT, two classes of subjects exist within the Windows NT security architecture:

• A simple subject is a process that was assigned a security context when the corresponding user logged on. It is not acting in the capacity of a protected server, which might have other subjects as clients.

• A server subject is a process implemented as a protected server (such as the Win32 subsystem), and it does have other subjects as clients. In this role, a server subject typically has the security context of those clients available for use when acting on their behalf.

In general, when a subject calls an object service through a protected subsystem, the subject's token is used within the service to determine who made the call and to decide whether the caller has sufficient access authority to perform the requested action.

Windows NT allows one process to take on the security attributes of another through a technique called impersonation. For example, a server process typically impersonates a client process to complete a task involving objects to which the server does not normally have access.

In the scenario shown in Figure 6.4, a client is accessing an object on a Windows NT server.

 

Figure 6.4 Server Subject Security Context 

The first thread in the process is a control thread. It is waiting to receive remote procedure calls (RPCs) by means of a named pipe. This thread is not impersonating another process, so any access validation to which Thread 1 is subjected will be carried out against the process's primary token.

The second thread in the process is currently handling a call from a client. This thread handles the client's call by temporarily using the client's access token to run with that client's access permissions (that is, the client's security context). While impersonating the client, any access validation to which Thread 2 is subjected is carried out in the security context of the client.

The third thread in this scenario is an idle worker thread that is not impersonating any other process.

The following illustration shows an audited event in which impersonation was used. (Use the Event Viewer to see this type of information for your system.) Here, information for both the primary user and client user is recorded in the security log.

Security Information about Objects

All named (and some unnamed) objects in Windows NT can be secured. The security attributes for an object are described by a security descriptor. An object's security descriptor includes the following parts (as shown in Figure 6.5):

• An owner security ID, which indicates the user or group who owns the object. The owner of an object can change the access permissions for the object.

• A group security ID, which is used only by the POSIX subsystem and ignored by the rest of Windows NT.

• A discretionary access control list (ACL), which identifies which users and groups are granted or denied which access permissions. Discretionary ACLs are controlled by the owner of the object. (These are described later, in "Access Control Lists and Access Control Entries.")

• A system ACL, which controls which auditing messages the system will generate. (For more information about auditing objects, see "Auditing Security Events," later in this chapter.) System ACLs are controlled by the security administrators. 

 

Figure 6.5 Security Descriptor for a File Object 

Types of Objects

The type of permissions that can be granted or denied for an object are dictated by the object's type. For example, you can specify permissions like Manage Documents and Print for a printer queue, and for a directory you can specify Read, Write, Execute, and so on.

Another quality that affects the permissions of an object is whether that object is a container object or a noncontainer object. A container object is one that logically contains other objects; noncontainer objects do not contain other objects. For example, a directory is a container object that logically contains files and other directories. Files are noncontainer objects. This distinction between container and noncontainer objects is important because objects within a container object can inherit certain permissions from the parent container. For more information, see "Access Control Inheritance," later in this chapter.

Note NTFS supports the inheritance of ACLs from directory objects to file objects that are created within the directory. For more information about NTFS, see Chapter 17, "Disk and File System Basics" and Chapter 18, "Choosing a File System."

Access Control Lists and Access Control Entries

Each ACL is made up of access control entries (ACEs), which specify access or auditing permissions to that object for one user or group. There are three ACE types—two for discretionary access control and one for system security.

The discretionary ACEs are AccessAllowed and AccessDenied. Respectively, these explicitly grant and deny access to a user or group of users. The first AccessDenied ACE denies the user access to the resource, and no further processing of ACEs occurs.

Note There is an important distinction between a discretionary ACL that is empty (one that has no ACEs in it) and an object without any discretionary ACL. In the case of an empty discretionary ACL, no accesses are explicitly granted, so access is implicitly denied. For an object that has no ACL at all, there is no protection assigned to the object, so any access request is granted.

SystemAudit is a system security ACE which is used to keep a log of security events (such as who accesses which files) and to generate and log security audit messages.

Access Masks

Each ACE includes an access mask, which defines all possible actions for a particular object type. Permissions are granted or denied based on this access mask.

One way to think of an access mask is as a sort of menu from which granted and denied permissions are selected:

 

Figure 6.6 Access Control Mask 

Specific types include access options that apply specifically to this object type. Each object type can have up to 16 specific access types. Collectively, the specific access types for a particular object type are called the specific access mask. (These are defined when the object type is defined.) For example, Windows NT files have the following specific access types:

ReadData	WriteEA (Extended Attribute)
WriteData	Execute
AppendData	ReadAttributes
ReadEA (Extended Attribute)	WriteAttributes

Standard types apply to all objects and consist of these access permissions:

• SYNCHRONIZE, which is used to synchronize access and to allow a process to wait for an object to enter the signaled state

• WRITE_OWNER, which is used to assign write owner

• WRITE_DAC, which is used to grant or deny write access to the discretionary ACL

• READ_CONTROL, which is used to grant or deny read access to the security descriptor and owner

• DELETE, which is used to grant or deny delete access

Generic types are broad types of access whose exact implementation is determined by the application defining an object. These rights are used when protecting an object. For example, an application that defines a voice-annotation object might define specific access rights by using VOICE_PLAY and VOICE_EDIT for playing and editing the object. It might set up a generic mapping structure in which GENERIC_EXECUTE maps to VOICE_PLAY and GENERIC_WRITE maps to both VOICE_PLAY and VOICE_EDIT.

The following table shows the generic types that are mapped from specific and standard types:

Generic type	Mapped from these specific and standard types
FILE_GENERIC_READ	STANDARD_RIGHTS_READ FILE_READ_DATA FILE_READ_ATTRIBUTES FILE_READ_EA SYNCHRONIZE
FILE_GENERIC_WRITE	STANDARD_RIGHTS_WRITE FILE_WRITE_DATA FILE_WRITE_ATTRIBUTES FILE_WRITE_EA FILE_APPEND_DATA SYNCHRONIZE
FILE_GENERIC_EXECUTE	STANDARD_RIGHTS_EXECUTE FILE_READ_ATTRIBUTES FILE_EXECUTE SYNCHRONIZE

Specific and standard types appear in the details of the security log. Generic types do not appear in the security log. Instead, the corresponding specific and standard types are listed.

Access Control Inheritance

Objects can be classified as either container objects or noncontainer objects. Container objects (such as directories) can logically contain other objects; noncontainer objects (such as files) can't.

By default, when you create new objects within a container object, the new objects inherit permissions from the parent object. For example, in the following dialog box, D:\REPORTS\ANNM inherited permissions from its parent directory, D:\REPORTS.

In the case of files and directories, when you change permissions on a directory, those changes affect that directory and its files but do not automatically apply to existing subdirectories and their contents. They do, however, if you check the Replace Permissions On Existing Files check box. You can apply the changed permissions to existing subdirectories and their files by selecting the Replace Permissions On Subdirectories check box.

 

Access Validation

When a user tries to access an object, Windows NT compares security information in the user's access token with the security information in the object's security descriptor, as shown in Figure 6.7:

 

Figure 6.7 Access Validation 

A desired access mask for the subject is created based on what type of access the user is attempting. This desired access mask, usually created by a program that the user is running, is compared with the object's ACL. (All generic access types in the ACL are mapped to standard and specific access types.)

Each ACE in the ACL is evaluated in this way:

1. The security ID in the ACE is compared with the set of security IDs in the user's access token. If a match is not found, the ACE is skipped.

   Further processing is based upon the type of the ACE. AccessDenied ACEs are ordered (and therefore processed) before AccessAllowed ACEs.

2. If access is denied, the system checks to see if the original desired access mask contained only a ReadControl and/or WRITE_DAC. If so, the system also checks to see if the requester is the owner of the object. In this case, access is granted.

3. For an AccessDenied ACE, the accesses in the ACE access mask are compared with the desired access mask. If there are any accesses in both masks, further processing is not necessary, and access is denied. Otherwise, processing continues with the next requested ACE.

4. For an AccessAllowed ACE, the accesses in the ACE are compared with those listed in the desired access mask. If all accesses in the desired access mask are matched by the ACE, no further processing is necessary, and access is granted. Otherwise, processing continues with the next ACE.

5. At the end of the ACL, if the contents of desired access mask are still not completely matched, access is implicitly denied.

Four examples of this access validation process are described next.

Example 1: Requesting Read and Write Access

A user whose user ID is FredMgr tries to open and change a file G:\File1.txt. The file has the discretionary ACL as shown in the next figure. The FredMgr access token indicates that he is a member of the groups Users, Mgrs, and Everyone.

Note The order in which permissions are listed by the File Permissions dialog box doesn't necessarily reflect the order in which ACEs are processed by Windows NT. It is important to note, however, that the Permissions Editor (controlled by means of this dialog box) orders all AccessDenied ACEs first so that they are the first to be processed within each ACL.

 

In this example, Windows NT evaluates the ACL by comparing the desired access mask with each ACE and processes the desired mask as follows:

1. Windows NT reads FredMgr's desired access mask to see that he is trying to gain Read and Write access.

2. Windows NT reads the AccessAllowed ACE for FredMgr and finds a match to the Read permission requested in the desired access mask.

3. Windows NT reads the AccessAllowed ACE for Mgrs and finds a match to the Write permission requested in desired access mask.

At this point, processing of the ACL stops even though there is another ACE in the ACL. Processing stops, and access is granted because Windows NT found matches for everything in the desired access mask.

Example 2: When Access Is Denied

In this example, FredMgr wants Read and Write access to the file whose discretionary ACL is shown next. FredMgr is a member of the Users and Mgrs groups.

 

In Example 2, the ACL is evaluated as follows:

1. Windows NT reads FredMgr's desired access mask to see that he is trying to gain Read and Write access.

2. Windows NT reads the AccessDenied ACE, which denies all access (No Access) to Mgrs.

At this point, processing of the ACL stops even though there are other ACEs in the ACL that grant permissions to FredMgr.

Example 3: Requesting Read and Write Access as Object Owner

In this example, FredMgr is denied access to a file, but because he is the owner of the file he can change permissions so that he does have access. Windows NT knows by reading FredMgr's access token that he is a member of the Mgrs group. Processing of the ACL will stop as soon as Windows NT sees that NoAccess (None) is assigned to the Mgrs group, even though the other two ACEs allow Read, Write, and Execute access for FredMgr.

 

However, after failing to gain access by means of the discretionary ACL, Windows NT notices that FredMgr is the owner of the object. Because of this, he is granted ReadControl and WRITE_DAC automatically. Because this is all the access he is asking for, his request is granted.

If FredMgr had asked for any other access in addition to ReadControl and WRITE_DAC, the request would be denied even though Fred is the object's owner. In this case, FredMgr receives the following message:

G:\FILE2.TXT
You do not have permission to open this file. 
See the owner of the file or an administrator to obtain permission.

In this case, because FredMgr is the owner, he can change his own permissions to grant himself appropriate access to the file.

Example 4: When a Custom Application Assigns Permissions

Important The three preceding examples demonstrate discretionary access control for file and directory permissions that are applied using the Windows NT Permissions Editor, either directly or by inheritance. If your organization develops its own custom application that sets and changes permissions on files and directories, it needs to order ACEs in the same way that Windows NT Permissions Editor orders them, or the Windows NT Permissions Editor won't be able to handle the ACL.

The user BobMgr wants Read and Write access to the file object that has the discretionary ACL shown next. The access token for BobMgr indicates that he is a member of the groups Users, JnrMgrs, and Everyone.

 

In this example, a custom application has been used to update the ACL for a file, thus confusing the usual order in which the ACEs for this file are processed. Normally, all AccessDenied ACEs are processed first.

Windows NT evaluates this ACL as follows:

1. Windows NT reads BobMgr's desired access mask to see that he is trying to gain Read and Write access.

2. Windows NT reads the AccessAllowed ACE for BobMgr and finds a match to the Read permission requested in the desired access mask.

3. Windows NT reads the AccessAllowed ACE for Everyone and finds a match to the Write permission requested in the desired access mask.

BobMgr is granted Read and Write access to the file object, even though the third ACE explicitly denies JnrMgrs access to the file object.

If the Windows NT Permissions property sheet had been used to apply the same permissions to the file object, the AccessDenied ACE for JnrMgrs would have been evaluated first in the ACL, and BobMgr would have been denied access to the file.

Auditing Security Events

Windows NT includes auditing features you can use to collect information about how your system is being used. These features also allow you to monitor events related to system security, to identify any security breaches, and to determine the extent and location of any damage. The level of audited events is adjustable to suit the needs of your organization. Some organizations need little auditing information, whereas others would be willing to trade some performance and disk space for detailed information they could use to analyze their system.

Note Remember that when you enable auditing, there is a small performance overhead for each audit check the system performs.

Windows NT can track events related to the operating system itself and to individual applications. Each application can define its own auditable events. Definitions of these events are added to the Registry when the application is installed on your Windows NT computer.

Audit events are identified to the system by the event source module name (which corresponds to a specific event type in the Registry) and an event ID.

In addition to listing events by event ID, the security log in Event Viewer lists them by category. The following categories of events are displayed in the Security Log. (Those in parentheses are found in the Audit Policy dialog box of User Manager.)

Category	Meaning
Account Management (User and Group Management)	These events describe high-level changes to the user accounts database, such as User Created or Group Membership Change. Potentially, a more detailed, object-level audit is also performed (see Object Access events).
Detailed Tracking (Process Tracking)	These events provide detailed subject-tracking information. This includes information such as program activation, handle duplication, and indirect object access.
Logon/Logoff (Logon and Logoff)	These events describe a single logon or logoff attempt, whether successful or unsuccessful. Included in each logon description is an indication of what type of logon was requested or performed (that is, interactive, network, or service).
Object Access (File and Object Access)	These events describe both successful and unsuccessful accesses to protected objects.
Policy Change (Security Policy Changes)	These events describe high-level changes to the security policy database, such as assignment of privileges or logon capabilities. Potentially, a more detailed, object-level audit is also performed (see Object Access events).
Privilege Use (Use of User Rights)	These events describe both successful and unsuccessful attempts to use privileges. It also includes information about when some special privileges are assigned. These special privileges are audited only at assignment time, not at time of use.
System Event (System)	These events indicate something affecting the security of the entire system or audit log occurred.

See "Security Event Examples" later in this chapter for examples of most of these event categories.

Audit Determination

Windows NT has an audit determination process similar to its access determination process, described earlier in this chapter. After access determination, Windows NT evaluates the following information for possible auditing:

• The subject attempting the access (that is, the set of identifiers representing the subject)

• The desired accesses with all generic access types mapped to standard and specific access types

• The final determination of whether access is granted or denied

• The audit ACL associated with the target object

Each ACE in the audit ACL is evaluated as follows:

1. Windows NT checks to see if the type is SystemAudit. If not, the ACE is skipped.

2. Windows NT compares the identifier in the ACE to the set of identifiers representing the subject. If no match is found, the ACE is skipped.

3. The desired accesses are compared to the access mask specified in the ACE.

4. If none of the accesses specified in the ACE's mask were requested, the ACE is skipped. The SUCCESSFUL_ACCESS_ACE_FLAG and FAILED_ACCESS_ACE_FLAG flags of the ACE are compared to the final determination of whether access was granted or denied.

5. If access was granted but the SUCCESSFUL_ACCESS_ACE_FLAG flag is not set, or if access was denied but the FAILED_ACCESS_ACE_FLAG flag is not set, the ACE is skipped.

If Windows NT performs all of these steps successfully, an audit message is generated.

The following scenario illustrates this process. In this scenario, a system access ACL is being evaluated. Here, Write access to the file object is granted, and the SUCCESSFUL_ACCESS_ACE_FLAG is set in each ACE.

In this example, Windows NT evaluates the ACL by comparing the desired access mask with each ACE and processes the desired mask as follows:

1. Windows NT evaluates an ACE for SnrMgrs (of which FredMgr is a member). However, when the desired access is compared to the access mask of the ACE, no match is found, and the ACE is skipped.

2. Windows NT evaluates the ACE for FredMgr and finds a match.

3. Windows NT checks access flags and finds the SUCCESSFUL_ACCESS_ACE_FLAG is set. Processing stops, and an audit message is generated.

Managing the Security Log

One of the regular tasks of network administration is examining the security log to track significant events and monitor system usage and clearing the log as necessary. It is recommended that you routinely archive the log before clearing it. You can specify the maximum size for the security log and what happens when that size is reached.

Process IDs and Handle IDs of Audit Events

One of the most important aspects of security is determining who is actually behind operations of security interest, such as file writes or security policy change. Although a thread that requests access to a resource is identified by the user ID, the thread might be impersonating someone else. In this case, it would be misleading to log events by user ID and might not be useful in finding the perpetrator in the case of a security breach.

Windows NT auditing and the security log use two levels of subject identification: the user ID (also called the primary ID) and the impersonation ID (also called the client ID), as applicable. These two IDs show security administrators who are performing auditable actions.

In some cases, however, a security administrator wants to see what is happening with each process. To meet this need, auditing information also includes a subject's process ID.

When process tracking is enabled (through the Audit Policy dialog box of User Manager), audit messages are generated each time a new process is created. This information can be correlated with specific audit messages to see not only which user account is being used to perform auditable actions, but also which program was run.

Many audit events also include a handle ID, enabling the event to be associated with future events. For example, when a file is opened, the audit information indicates the handle ID assigned to the file. When the handle is closed, another audit event with the same handle ID is generated. With this information, you can determine exactly how long the file remained open.

The following list shows some of the information from the security access token that Windows NT uses for auditing:

• The security ID of the user account used to log on

• The group security IDs and corresponding attributes of groups to which the user is assigned membership

• The names of the privileges assigned to and used by the user, and their corresponding attributes

• Authentication ID, assigned when the user logs on

Security Event Examples

As described earlier, you can track several categories of security events. This section provides examples for most of these categories. This set of examples does not constitute a strategy for using the auditing capabilities of Windows NT; it merely serves as an introduction to show how to turn on auditing and to help you interpret these events when you enable auditing for your Windows NT system.

Example 1: Tracking File and Object Access

In this example, a user opens, modifies, saves, and closes a text file. Each of these actions generates an audit event. You must be logged on as an administrator, and make sure to enable auditing for file and object access in User Manager.

1. Create a .txt file using Notepad (it need not contain any text).

2. In Windows NT Explorer or in My computer, right-click on the .txt file icon, select Properties, and then click the Security tab.

3. Click Permissions, click Add, and then click Show Users.

4. Click to select the user, click Add to add the selected user to the list, and then click OK.

5. Give the user Full Control, and then click OK.

6. Click Auditing, click Add, and then click Show Users.

7. Click to select the user, click Add to add the selected user to the list, and then click OK.

8. Select the Read Success, Read Failure, Write Success, and Write Failure check boxes.

9. Click OK in both dialog boxes.

10. Have the user double-click the .txt file, write data to the file, save it, and then close the file.

This results in audit events, as shown in the following illustration:

 

From this view of the security log, you get a quick summary of security-related events that occurred. Double-click the first event to examine the details. (For example, details of this first event are shown in the Event Detail box.)

The data that needs to be interpreted is listed in the Description list box. The following table summarizes the audited events for this example, in the order they occurred:

Event ID and description	Analysis
Event 560: Object Open Event 561: Handle Allocated Event 562: Handle Closed	In this sequence of events, Windows NT is doing some internal checks, such as checking to see if the file exists and checking to see that there is no sharing violation.
Event 592: A New Process Has Been Created Event 560: Object Open Event 561: Handle Allocated Event 562: Handle Closed	In this series of events, a new process is created for Notepad.exe. This process opens the .txt file for reading. Next, the process allocates, then closes, a handle to the file. Note that from the security log it is clear that Notepad does not keep an open handle to the file; it simply keeps a copy of the file in memory.
Event 560: Object Open Event 561: Handle Allocated Event 562: Handle Closed	The process opens the file for reading and writing, and since the event is a successful audit, new data is written to the file. Next, the handle is allocated for the open file, then closed.
Event 593: A Process Has Exited	This event indicates that the process, whose process ID relates to Notepad.exe, has ended.

Example 2: Use of User Rights

In this example, auditing is enabled by using User Manager to enable auditing for Success and Failure of Use of User Rights.

Use of User Rights generates audit events when a process initiates an operation that requires special privilege. For example, in order to set the system time, a user first must be given the user right to "Change The System Time" in User Manager.

For more information about User Rights see "User Rights" in the "High-Level Security" section later in this chapter.

When the user tries to change the system time, only one event is generated, as shown in the following illustration:

 

This event indicates that a privileged service was called and that a server component named Kernel has called an audit check on the primary username of the user. The audit type is a Success Audit, meaning that the user successfully exercised the right to use the SeSystemtimePrivilege (that is, the right to change the system time).

Example 3: User and Group Management

In this example, a new user account is added to the user accounts database. Auditing is enabled in User Manager by specifying both Success and Failure of User and Group Management. This generates four audit events, as shown in the following illustration:

 

Event ID and description	Analysis
Event 632: Global Group Member Added Event 624: User Account Created	A new security ID (member) is created and added to the group represented by the target account ID. This is a default global group Domain Users. At this point, the security ID does not have a username allocated to it.
Event 642: User Account Changed	This event indicates that the account name of the security ID represented by the Target Account ID has been changed to the new user's.
Event 636: Local Group Member Added	This event indicates that the account represented by the new user's security ID is created. The new user is added to the local group represented by the security ID under Target Account ID (Users).

Example 4: Restart, Shutdown and System

In this example, auditing is enabled in User Manager for both Success and Failure of Restart, Shutdown and System.

In this example, seven events were generated. Note, however, that the number of events generated is related to the number of trusted systems that you start when the system is restarted. This number might vary if you replicate this scenario on your own Windows NT computer.

 

Event ID and description	Analysis
Event 512: Windows NT is starting up.	Identifies the date and time the system started.
Event 514: Authentication package loaded	The description of this event says An authentication package has been loaded by the Local Security Authority. This authentication package will be used to authenticate logon attempts. Authentication Package Name: msv 1_0 This is the standard authentication package shipped with Windows NT.

Events 515: Trusted logon process

The description for each of these events says A trusted logon process has registered with the Local Security Authority. This logon process will be trusted to submit logon requests. The logon process name is listed for each of these events, as follows: Winlogon Service Control Manager LAN Manager Workstation Service LAN Manager Server LAN Manager Redirector Each of these events is a successful audit in the category of system event. These events indicate that the respective logon processes have registered with the Local Security Authority and are now trusted to submit logon requests.

Establishing Computer Security

This section deals with the following topics on Windows NT security:

• Levels of security

• Off-the-shelf versus custom software

• Windows NT security features

• Performance monitoring

Levels of Security

Windows NT allows you to establish a full range of levels of security, from no security at all to the C2 level of security required by many government agencies. In this chapter we describe three levels of security—minimal, standard, and high-level—and the options used to provide each level. These levels are arbitrary, and you will probably want to create your own "level" by blending characteristics of the levels presented here.

Why not have maximum security at all times? One reason is that the limits you set on access to computer resources make it a little harder for people to work with the protected resources. Another is that it is extra work to set up and maintain the protections you want. For example, if only users who are members of the HR user group are allowed to access employee records, and a new person is hired to do that job, then someone needs to set up an account for the new hire and add that account to the HR group. If the new account is created but not added to HR, the new hire cannot access the employee records and therefore cannot perform his or her job.

If the security is too tight, users will try to circumvent security in order to get work done. For example, if you set the password policy so that passwords are hard to remember, users will write them down to avoid being locked out. If some users are blocked from files they need to use, their colleagues might share their own passwords in order to promote the flow of work.

The first step in establishing security is to make an accurate assessment of your needs. Then choose the elements of security that you want, and implement them. Make sure your users know what they need to do to maintain security, and why it is important. Finally, monitor your system and make adjustments as needed.

Off-the-Shelf vs. Custom Software

If you are using software made especially for your installation, or if you are using shareware that you aren't sure you can trust, and you want to maintain fairly high security, you might want to look at Appendix B, "Security In a Software Development Environment." This provides information on settings and calls that can support—or circumvent—security settings.

Minimal Security

You might not be concerned with security if the computer is not used to store or access sensitive data or if it is in a very secure location. For example, if the computer is in the home office of a sole proprietor of a business, or if it is used as a test machine in the locked lab of a software development company, then security precautions might be unnecessarily cumbersome. Windows NT allows you to make the system fully accessible, with no protections at all, if that is what your setup requires.

Physical Security Considerations

Take the precautions you would with any piece of valuable equipment to protect against casual theft. This step can include locking the room the computer is in when no one is there to keep an eye on it, or using a locked cable to attach the unit to a wall. You might also want to establish procedures for moving or repairing the computer so that the computer or its components cannot be taken under false pretenses.

Use a surge protector or power conditioner to protect the computer and its peripherals from power spikes. Also, perform regular disk scans and defragmentation to isolate bad sectors and to maintain the highest possible disk performance.

Minimal Software Security Considerations

For minimal security, none of the Windows NT security features are used. In fact, you can allow automatic logon to the Administrator account (or any other user account) by following the directions in Chapter 25 "Configuration Management and the Registry." This allows anyone with physical access to the computer to turn it on and immediately have full access to the computer's resources.

By default, access is limited to certain files. For minimal security, give the Everyone group full access to all files.

You should still take precautions against viruses, because they can disable programs you want to use or use the minimally secure computer as a vector to infect other computer systems.

Standard Security

Most often, computers are used to store sensitive and/or valuable data. This data could be anything from financial data to personnel files to personal correspondence. Also, you might need to protect against accidental or deliberate changes to the way the computer is set up. But the computer's users need to be able to do their work, with minimal barriers to the resources they need.

Physical Security Considerations

As with minimal security, the computer should be protected as any valuable equipment would be. Generally, this involves keeping the computer in a building that is locked to unauthorized users, as most homes and offices are. In some instances you might want to use a cable and lock to secure the computer to its location. If the computer has a physical lock, you can lock it and keep the key in a safe place for additional security. However, if the key is lost or inaccessible, an authorized user might be unable to work on the computer.

Standard Software Security Considerations

A secure system requires effort from both the system administrators, who maintain certain software settings, and the everyday users, who must cultivate habits such as logging off at the end of the day and memorizing (rather than writing down) their passwords.

Displaying a Legal Notice Before Logon

Windows NT can display a message box with the caption and text of your choice before a user logs on. Many organizations use this message box to display a warning message that notifies potential users that they can be held legally liable if they attempt to use the computer without having been properly authorized to do so. The absence of such a notice could be construed as an invitation, without restriction, to enter and browse the system.

The logon notice can also be used in settings (such as an information kiosk) where users might require instruction on how to supply a username and password for the appropriate account.

To display a legal notice, use the Registry Editor to create or assign the following Registry key values on the workstation to be protected:

Hive:	HKEY_LOCAL_MACHINE \SOFTWARE
Key:	\Microsoft\Windows NT\Current Version\Winlogon
Name:	LegalNoticeCaption
Type:	REG_SZ
Value:	Whatever you want for the title of the message box

Hive:	HKEY_LOCAL_MACHINE \SOFTWARE
Key:	Microsoft\Windows NT\Current Version\Winlogon
Name:	LegalNoticeText
Type:	REG_SZ
Value:	Whatever you want for the text of the message box

The changes take effect the next time the computer is started. You might want to update the Emergency Repair Disk to reflect these changes.

Examples

Welcome to the XYZ Information Kiosk

Log on using account name Guest and password XYZCorp.

Authorized Users Only

Only individuals currently assigned an account on this computer by XYZCorp may access data on this computer. All information stored on this computer is the property of XYZCorp and is subject to all the protections accorded intellectual property.

User Accounts and Groups

With standard security, a user account (username) and password should be required in order to use the computer. You can establish, delete, or disable user accounts with User Manager, which is in the Administrative Tools program group. User Manager also allows you to set password policies and organize user accounts into Groups.

Note Changes to the Windows NT computer user rights policy take effect when the user next logs on.

Administrative Accounts versus User Accounts

Use separate accounts for administrative activity and general user activity. Individuals who do administrative work on the computer should each have two user accounts on the system: one for administrative tasks, and one for general activity. To avoid accidental changes to protected resources, the account with the least privilege that can do the task at hand should be used. For example, viruses can do much more damage if activated from an account with Administrator privileges.

It is a good idea to rename the built-in Administrator account to something less obvious. This powerful account is the one account that can never be locked out due to repeated failed logon attempts, and consequently is attractive to hackers who try to break in by repeatedly guessing passwords. By renaming the account, you force hackers to guess the account name as well as the password.

The Guest Account

Limited access can be permitted for casual users through the built-in Guest account. If the computer is for public use, the Guest account can be used for public logons. Prohibit Guest from Writing or Deleting any files, directories, or Registry keys (with the possible exception of a directory where information can be left).

In a standard security configuration, a computer that allows Guest access can also be used by other users for files that they don't want accessible to the general public. These users can log on with their own user names and access files in directories on which they have set the appropriate permissions. They will want to be especially careful to log off or lock the workstation before they leave it. The Guest account is discussed in Chapter 2 "Working with User and Group Accounts" in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

Logging On

All users should always press ctrl+alt+del before logging on. Programs designed to collect account passwords can appear as a logon screen that is there waiting for you. By pressing ctrl+alt+del you can foil these programs and get the secure logon screen provided by Windows NT.

Logging Off or Locking the Workstation

Users should either log off or lock the workstation if they will be away from the computer for any length of time. Logging off allows other users to log on (if they know the password to an account); locking the workstation does not. The workstation can be set to lock automatically if it is not used for a set period of time by using any 32-bit screen saver with the Password Protected option. For information about setting up screen savers, see Help.

Passwords

Anyone who knows a username and the associated password can log on as that user. Users should take care to keep their passwords secret. Here are a few tips:

• Change passwords frequently, and avoid reusing passwords.

• Avoid using easily guessed words and words that appear in the dictionary. A phrase or a combination of letters and numbers works well.

• Don't write a password down—choose one that is easy for you to remember.

Protecting Files and Directories

The NTFS file system provides more security features than the FAT system and should be used whenever security is a concern. The only reason to use FAT is for the boot partition of an ARC-compliant RISC system. A system partition using FAT can be secured in its entirety using the Secure System Partition command on the Partition menu of the Disk Administrator utility.

With NTFS, you can assign a variety of protections to files and directories, specifying which groups or individual accounts can access these resources in which ways. By using the inherited permissions feature and by assigning permissions to groups rather than to individual accounts, you can simplify the chore of maintaining appropriate protections. For more information, see Chapter 4, "Managing Shared Resources and Resource Security" in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

In particular, make sure that users know that if they move rather than copy a file to a different directory on the same volume, it continues to have the protections it had before it was moved. If they copy the file, it inherits the protections (either more or less restrictive) from the directory it is copied to.

For example, a user might copy a sensitive document to a directory that is accessible to people who should not be allowed to read the document, thinking that the protections assigned to the document in its old location would still apply. In this case the protections should be set on the document as soon as it is copied, or else it should be first moved to the new directory, then copied back to the original directory.

On the other hand, if a file that was created in a protected directory is being placed in a shared directory so that other users can read it, it should be copied to the new directory; or if it is moved to the new directory, the protections on the file should be promptly changed so that other users can read the file.

When permissions are changed on a file or directory, the new permissions apply any time the file or directory is subsequently opened. Users who already have the file or directory open when you change the permissions are still allowed access according to the permissions that were in effect when they opened the file or directory.

Backups

Regular backups protect your data from hardware failures and honest mistakes, as well as from viruses and other malicious mischief. The Windows NT Backup utility is described in Chapter 6, "Backing Up and Restoring Network Files" in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help

Obviously, files must be read to be backed up, and they must be written to be restored. Backup privileges should be limited to Administrators and Backup operators—people to whom you are comfortable giving read and write access on all files.

Protecting the Registry

All the initialization and configuration information used by Windows NT is stored in the Registry. Normally, the keys in the Registry are changed indirectly, through the administrative tools such as the Control Panel. This method is recommended. The Registry can also be altered directly, with the Registry Editor; some keys can be altered in no other way.

The Registry Editor should be used only by individuals who thoroughly understand the tool, the Registry itself, and the effects of changes to various keys in the Registry. Mistakes made in the Registry Editor could render part or all of the system unusable.

Remote access to the Windows NT registry is supported by the Registry Editor. To restrict network access to the registry, use the Registry Editor to create the following registry key:

Hive:	HKEY_LOCAL_MACHINE
Key:	\CurrentcontrolSet\Control\SecurePipeServers
Name:	\winreg
Type	REG_DWORD
Value:	1

The security permissions set on this key define which users or groups can connect to the system for remote registry access. The default Windows NT Workstation installation does not define this key and does not restrict remote access to the registry. Windows NT Server permits only Administrators remote access to the registry.

The Backup utility included with Windows NT allows you to back up the Registry as well as files and directories.

Auditing

Auditing can inform you of actions that could pose a security risk and also identify the user accounts from which audited actions were taken. Note that auditing only tells you what user accounts were used for the audited events. If passwords are adequately protected, this in turn indicates which user attempted the audited events. However, if a password has been stolen or if actions were taken while a user was logged on but away from the computer, the action could have been initiated by someone other than the person to whom the user account is assigned.

When you establish an audit policy you'll need to weigh the cost (in disk space and CPU cycles) of the various auditing options against the advantages of these options. You'll want to at least audit failed logon attempts, attempts to access sensitive data, and changes to security settings. Here are some common security threats and the type of auditing that can help track them:

Threat	Action
Hacker-type break-in using random passwords	Enable failure auditing for logon and logoff events.
Break-in using stolen password	Enable success auditing for logon and logoff events. The log entries will not distinguish between the real users and the phony ones. What you are looking for here is unusual activity on user accounts, such as logons at odd hours or on days when you would not expect any activity.
Misuse of administrative privileges by authorized users	Enable success auditing for use of user rights; for user and group management, for security policy changes; and for restart, shutdown, and system events. (Note: Because of the high volume of events that would be recorded, Windows NT does not normally audit the use of the Backup Files And Directories and the Restore Files And Directories rights. Appendix B, "Security In a Software Development Environment," explains how to enable auditing of the use of these rights.)
Virus outbreak	Enable success and failure write access auditing for program files such as files with .exe and .dll extensions. Enable success and failure process tracking auditing. Run suspect programs and examine the security log for unexpected attempts to modify program files or creation of unexpected processes. Note that these auditing settings generate a large number of event records during routine system use. You should use them only when you are actively monitoring the system log.
Improper access to sensitive files	Enable success and failure auditing for file- and object-access events, and then use File Manager to enable success and failure auditing of read and write access by suspect users or groups for sensitive files.
Improper access to printers	Enable success and failure auditing for file- and object-access events, and then use Print Manager to enable success and failure auditing of print access by suspect users or groups for the printers.

High-Level Security

Standard security precautions are sufficient for most installations. However, additional precautions are available for computers that contain sensitive data, or that are at high risk for data theft or the accidental or malicious disruption of the system.

Physical Security Considerations

The physical security considerations described for minimal and standard security configurations also apply here. In addition, you might want to examine the physical link provided by your computer network, and in some cases use controls built in to certain hardware platforms to restrict who can turn on the computer.

Networks and Security

When you put a computer on a network, you add an access route to the computer, and you'll want that route to be secure. User validation and protections on files and other objects are sufficient for standard-level security, but for high-level security you'll need to make sure the network itself is secure, or in some cases isolate the computer completely.

The two risks from network connections are other network users and unauthorized network taps. If everyone on the network has the security clearance needed to access your secure computer, you will probably prefer to include the computer in the network to make it easier for these people to access data on the computer.

If the network is entirely contained in a secure building, the risk of unauthorized taps is minimized or eliminated. If the cabling must pass through unsecured areas, use optical fiber links rather than twisted pair to foil attempts to tap the wire and collect transmitted data.

If your installation needs access to the Internet, be aware of the security issues involved in providing access to—and from—the Internet community. Chapter 2, "Server Security on the Internet," in the Windows NT Server Internet Guide contains information on using network topology to provide security.

Controlling Access to the Computer

No computer will ever be completely secure if people other the than authorized user can physically access it. For maximum security on a computer that is not physically secure (locked safely away), follow all or some of the following security measures:

• If the computer has a floppy disk drive, set the Boot.ini time-out to 0. This disables the floppy disk drive on startup. If the computer doesn't require a floppy disk drive, remove it.

• The CPU should have a case that cannot be opened without a key. The key should be stored safely away from the computer.

• The entire hard disk should be NTFS.

• If the computer doesn't require network access, remove the network card.

Controlling Access to the Power Switch

You might choose to keep unauthorized users away from the power or reset switches on the computer, particularly if your computer's rights policy denies them the right to shut down the computer. The most secure computers (other than those in locked and guarded rooms) expose only the computer's keyboard, monitor, mouse, and (when appropriate) printer to users. The CPU and removable media drives can be locked away where only specifically authorized personnel can access them.

On many hardware platforms, the system can be protected using a power-on password. A power-on password prevents unauthorized personnel from starting an operating system other than Windows NT, which would compromise system security. Power-on passwords are a function of the computer hardware, not the operating system software. Therefore the procedure for setting up the power-on password depends on the type of computer and is available in the vendor's documentation supplied with the system.

High-Level Software Security Considerations

Some high-security options can be implemented only by using the Registry Editor. The Registry Editor should be used only by administrators who are familiar with the material in Part 5 of this book.

User Rights

There are several user rights that administrators of high-security installations should be aware of and possibly audit. Of these, you might want to change the default permissions on two rights, as follows:

User Right	Groups assigned this right by default	Recommended change
Log on locally. Allows a user to log on at the computer, from the computer's keyboard.	Administrators, Backup Operators, Everyone, Guests, Power Users, and Users	Deny Everyone and Guests this right.
Shut down the system. (SeShutdownPrivilege) Allows a user to shut down Windows NT.	Administrators, Backup Operators, Everyone, Power Users, and Users	Deny Everyone and Users this right.

The rights in the following table generally require no changes to the default settings, even in the most highly secure installations.

Right	Allows	Initially assigned to
Access this computer from the network	A user to connect over the network to the computer.	Administrators, Everyone, Power Users
Act as part of the operating system (SeTcbPrivilege)	A process to perform as a secure, trusted part of the operating system. Some subsystems are granted this right.	(None)
Add workstations to the domain (SeMachineAccountPrivilege)	Nothing. This right has no effect on computers running Windows NT.	(None)
Back up files and directories (SeBackupPrivilege)	A user to back up files and directories. This right supersedes file and directory permissions.	Administrators, Backup Operators
Bypass traverse checking (SeChangeNotifyPrivilege)	A user to change directories and access files and subdirectories even if the user has no permission to access parent directories.	Everyone
Change the system time (SeSystemTimePrivilege)	A user to set the time for the internal clock of the computer.	Administrators, Power Users
Create a pagefile (SeCreatePagefilePrivilege)	Nothing. This right has no effect in current versions of Windows NT.	Administrators
Create a token object (SeCreateTokenPrivilege)	A process to create access tokens. Only the Local Security Authority can do this.	(None)

Create permanent shared objects (SeCreatePermanentPrivilege)

A user to create special permanent objects, such as \\Device, that are used within Windows NT.

(None)

Debug programs (SeDebugPrivilege)	A user to debug various low-level objects such as threads.	Administrators
Force shutdown from a remote system (SeRemoteShutdownPrivilege)	Nothing. This right has no effect in current versions of Windows NT.	Administrators, Power Users
Generate security audits (SeAuditPrivilege)	A process to generate security audit log entries.	(None)
Increase quotas  (SeIncreaseQuotaPrivilege)	Nothing. This right has no effect in current versions of Windows NT.	(None)
Increase scheduling priority (SeIncreaseBasePriorityPrivilege)	A user to boost the execution priority of a process.	Administrators, Power Users
Load and unload device drivers (SeLoadDriverPrivilege)	A user to install and remove device drivers.	Administrators
Lock pages in memory (SeLockMemoryPrivilege)	A user to lock pages in memory so they cannot be paged out to a backing store such as Pagefile.sys.	(None)
Log on as a batch job	Nothing. This right has no effect in current versions of Windows NT.	(None)
Log on as a service	A process to register with the system as a service.	(None)
Log on locally	A user to log on at the computer, from the computer's keyboard.	Administrators, Backup Operators, Guests, Power Users, Users
Manage auditing and security log  (SeSecurityPrivilege)	A user to specify what types of resource access (such as file access) are to be audited, and to view and clear the security log. Note that this right does not allow a user to set system auditing policy using the Audit command in the Policy menu of User Manager. Also, members of the Administrators group always have the ability to view and clear the security log.	Administrators
Modify firmware environment variables (SeSystemEnvironmentPrivilege)	A user to modify system environment variables stored in nonvolatile RAM on systems that support this type of configuration.	Administrators
Profile single process (SeProfSingleProcess)	A user to perform profiling (performance sampling) on a process.	Administrators, Power Users
Profile system performance (SeSystemProfilePrivilege)	A user to perform profiling (performance sampling) on the system.	Administrators
Replace a process-level token (SeAssignPrimaryTokenPrivilege)	A user to modify a process's security access token. This is a powerful right used only by the system.	(None)
Restore files and directories (SeRestorePrivilege)	A user to restore backed-up files and directories. This right supersedes file and directory permissions.	Administrators, Backup Operators
Shut down the system  (SeShutdownPrivilege)	A user to shut down Windows NT.	Administrators, Backup Operators, Power Users, Users
Take ownership of files or other objects (SeTakeOwnershipPrivilege)	A user to take ownership of files, directories, printers, and other objects on the computer. This right supersedes permissions protecting objects.	Administrators

Protecting Files and Directories

Among the files and directories to be protected are those that make up the operating system software itself. The standard set of permissions on system files and directories provide a reasonable degree of security without interfering with the computer's usability. For high-level security installations, however, you might want to set directory permissions to all subdirectories and existing files, as shown in the following list, immediately after Windows NT is installed. Be sure to apply permissions to parent directories before applying permissions to subdirectories.

Directory	Permissions
\WINNT35	Administrators: Full Control CREATOR OWNER: Full Control Everyone: Read SYSTEM: Full Control
\WINNT35\REPAIR	Administrators: Full Control
\WINNT35\SYSTEM	Administrators: Full Control CREATOR OWNER: Full Control Everyone: Read SYSTEM: Full Control
\WINNT35\SYSTEM32	Administrators: Full Control CREATOR OWNER: Full Control Everyone: Read SYSTEM: Full Control
\WINNT35\SYSTEM32\CONFIG	Administrators: Full Control CREATOR OWNER: Full Control Everyone: List SYSTEM: Full Control
\WINNT35\SYSTEM32\DHCP	(Delete this directory)
\WINNT35\SYSTEM32\DRIVERS	Administrators: Full Control CREATOR OWNER: Full Control Everyone: Read SYSTEM: Full Control
\WINNT35\SYSTEM32\RAS	(Delete this directory)
\WINNT35\SYSTEM32\OS2	(Delete this directory)
\WINNT35\SYSTEM32\SPOOL	Administrators: Full Control CREATOR OWNER: Full Control Everyone: Read Power Users: Change SYSTEM: Full Control
\WINNT35\SYSTEM32\WINS	(Delete this directory)

Several critical operating system files exist in the root directory of the system partition on Intel 80486 and Pentium-based systems. In high-security installations you might want to assign the following permissions to these files:

File	C2-Level Permissions
\BOOT.INI, \NTDETECT.COM, \NTLDR	Administrators: Full Control SYSTEM: Full Control
\AUTOEXEC.BAT, \CONFIG.SYS	Everybody: Read Administrators: Full Control SYSTEM: Full Control

To view these files in File Manager, choose the By File Type command from the View menu, then select the Show Hidden/System Files check box in the By File Type dialog box.

Protecting the Registry

In addition to the considerations for standard security, the administrator of a high-security installation might want to set protections on certain keys in the Registry.

By default, protections are set on the various components of the Registry that allow work to be done while providing standard-level security. For high-level security, you might want to assign access rights to specific Registry keys. This should be done with caution, because programs that the users require to do their jobs often need to access certain keys on the users' behalf. For more information, see Chapter 24, "Registry Editor and Registry Administration."

In particular, you might want to change the protections of the following keys so that the group Everyone is only allowed QueryValue, Enumerate Subkeys, Notify, and Read Control accesses.

In the HKEY_LOCAL_MACHINE on Local Machine dialog:

\Software\Microsoft\RPC (and its subkeys)\Software\Microsoft\Windows NT\CurrentVersion

And under the \Software\Microsoft\Windows NT\CurrentVersion\ subtree:

Profile ListAeDebugCompatibilityDriversEmbeddingFontsFontSubstitutesGRE_InitializeMCIFontSubstitutesGRE_InitializeMCIMCI ExtensionsPort (and all subkeys)WOW (and all subkeys)Windows3.1MigrationStatus (and all subkeys)

In the HKEY_CLASSES_ROOT on Local Machine dialog:

\HKEY_CLASSES_ROOT (and all subkeys)

Remote access to the Windows NT registry is supported by the Registry Editor. To restrict network access to the registry, use the Registry Editor to create the following registry key:

Hive:	HKEY_LOCAL_MACHINE
Key:	\CurrentcontrolSet\Control\SecurePipeServers
Name:	\winreg
Type	REG_DWORD
Value:	1

The security permissions set on this key define which users or groups can connect to the system for remote registry access. The default Windows NT Workstation installation does not define this key and does not restrict remote access to the registry. Windows NT Server permits only Administrators remote access to the registry.

The Schedule Service (AT Command)

The Schedule service (also known as the AT command) is used to schedule tasks to run automatically at a preset time. Because the scheduled task is run in the context run by the Schedule service (typically the operating system's context), this service should not be used in a highly secure environment.

By default, only Administrators can submit AT commands. To allow System Operators to also submit AT commands, use the Registry Editor to create or assign the following Registry key value:

Hive:	HKEY_LOCAL_MACHINE \SYSTEM
Key:	\CurrentControlSet\Control\Lsa
Name:	Submit Control
Type:	REG_DWORD
Value:	1

There is no way to allow anyone else to submit AT commands. The changes will take effect the next time the computer is started. You might want to update the Emergency Repair Disk to reflect these changes.

Hiding the Last Username

By default, Windows NT places the username of the last user to log on the computer in the Username text box of the Logon dialog box. This makes it more convenient for the most frequent user to log on. To help keep usernames secret, you can prevent Windows NT from displaying the username from the last logon. This is especially important if a computer that is generally accessible is being used for the (renamed) built-in Administrator account.

To prevent display of a username in the Logon dialog box, use the Registry Editor to create or assign the following Registry key value:

Hive:	HKEY_LOCAL_MACHINE \SOFTWARE
Key:	\Microsoft\Windows NT\Current Version\Winlogon
Name:	DontDisplayLastUserName
Type:	REG_SZ
Value:	1

Restricting the Boot Process

Most personal computers today can start a number of different operating systems. For example, even if you normally start Windows NT from the C: drive, someone could select another version of Windows on another drive, including a floppy drive or CD-ROM drive. If this happens, security precautions you have taken within your normal version of Windows NT might be circumvented.

In general, you should install only those operating systems that you want to be used on the computer you are setting up. For a highly secure system, this will probably mean installing one version of Windows NT. However, you must still protect the CPU physically to ensure that no other operating system is loaded. Depending on your circumstances, you might choose to remove the floppy drive or drives. In some computers you can disable booting from the floppy drive by setting switches or jumpers inside the CPU. If you use hardware settings to disable booting from the floppy drive, you might want to lock the computer case (if possible) or lock the machine in a cabinet with a hole in the front to provide access to the floppy drive. If the CPU is in a locked area away from the keyboard and monitor, drives cannot be added or hardware settings changed for the purpose of starting from another operating system.

Allowing Only Logged-On Users to Shut Down the Computer

Normally, you can shut down a computer running Windows NT Workstation without logging on by choosing Shutdown in the Logon dialog box. This is appropriate where the computer's operational switches can be accessed by users; otherwise, they might tend to turn off the computer's power or reset it without properly shutting down Windows NT Workstation. However, you can remove this feature if the CPU is locked away. (This step is not required for Windows NT Server, because it is configured this way by default.)

To require users to log on before shutting down the computer, use the Registry Editor to create or assign the following Registry key value:

Hive:	HKEY_LOCAL_MACHINE \SOFTWARE
Key:	\Microsoft\Windows NT\Current Version\Winlogon
Name:	ShutdownWithoutLogon
Type:	REG_SZ
Value:	0

The changes will take effect the next time the computer is started. You might want to update the Emergency Repair Disk to reflect these changes.

Controlling Access to Removable Media

By default, Windows NT allows any program to access files on floppy disks and CDs. In a highly secure, multi-user environment, you might want to allow only the person interactively logged on to access those devices. This allows the interactive user to write sensitive information to these drives, confident that no other user or program can see or modify that data.

When operating in this mode, the floppy disks and/or CDs on your system are allocated to a user as part of the interactive logon process. These devices are automatically freed for general use or for reallocation when that user logs off. Because of this, it is important to remove sensitive data from the floppy or CD-ROM drives before logging off.

Note Windows NT allows all users access to the tape drive, and therefore any user can read and write the contents of any tape in the drive. In general this is not a concern, because only one user is interactively logged on at a time. However, in some rare instances, a program started by a user can continue running after the user logs off. When another user logs on and puts a tape in the tape drive, this program can secretly transfer sensitive data from the tape. If this is a concern, restart the computer before using the tape drive.

To allocate floppy drives during logon

• Use the Registry Editor to create or assign the following Registry key value:

Hive:	HKEY_LOCAL_MACHINE \SOFTWARE
Key:	\Microsoft\WindowsNT\CurrentVersion\Winlogon
Name:	AllocateFloppies
Type:	REG_SZ
Value:	1

If the value does not exist, or is set to any other value, then floppy devices will be available for shared use by all processes on the system.

This value will take effect at the next logon. If a user is already logged on when this value is set, it will have no effect for that logon session. The user must log off and log on again to cause the device(s) to be allocated.

To allocate CD-ROMs during logon

• Use the Registry Editor to create or assign the following Registry key value:

Hive:	HKEY_LOCAL_MACHINE \SOFTWARE
Key:	\Microsoft\WindowsNT\CurrentVersion\Winlogon
Name:	AllocateCDRoms
Type:	REG_SZ
Value:	1

If the value does not exist, or is set to any other value, then CD-ROM devices will be available for shared use by all processes on the system.

This value will take effect at the next logon. If a user is already logged on when this value is set, it will have no effect for that logon session. The user must log off and log on again to cause the device(s) to be allocated.

C2 Security

The National Computer Security Center (NCSC) is the United States government agency responsible for performing software product security evaluations. These evaluations are carried out against a set of requirements outlined in the NCSC publication Department of Defense Trusted Computer System Evaluation Criteria, which is commonly referred to as the "Orange Book."

Windows NT has been successfully evaluated by the NCSC at the C2 security level as defined in the Orange Book, which covers the base operating system.

In addition, Windows NT is currently under evaluation for its networking component of a secure system in compliance to the NCSC's "Red Book." The Red Book is an interpretation of the Orange Book as applies to network security.

Some of the most important requirements of C2-level security are the following:

• The owner of a resource (such as a file) must be able to control access to the resource.

• The operating system must protect objects so that they are not randomly reused by other processes. For example, the system protects memory so that its contents cannot be read after it is freed by a process. In addition, when a file is deleted, users must not be able to access the data from that file.

• Each user must identify himself or herself by typing a unique logon name and password before being allowed access to the system. The system must be able to use this unique identification to track the activities of the user.

• System administrators must be able to audit security-related events. Access to this audit data must be limited to authorized administrators.

• The system must protect itself from external interference or tampering, such as modification of the running system or of system files stored on disk.

Evaluation vs. Certification

The NCSC evaluation process does a good job of ensuring that Windows NT can properly enforce your security policy, but it does not dictate what your security policy must be. There are many features of Windows NT that need to be considered when determining how to use the computer within your specific environment. What level of auditing will you require? How should your files be protected to ensure that only the right people can access them? What applications should you allow people to run? Should you use a network? If so, what level of physical isolation of the actual network cable is needed?

To address the environmental aspects of a computing environment, the NCSC has produced a document called Introduction to Certification and Accreditation. In this document, "certification" is described as a plan to use computer systems in a specific environment, and "accreditation" is the evaluation of that plan by administrative authorities. It is this certification plan, and the subsequent accreditation procedure, that balances the sensitivity of the data being protected against the environmental risks present in the way the computing systems are used. For example, a certification plan for a university computing lab might require that computers be configured to prevent starting from a floppy disk, to minimize the risk of infection by virus or Trojan Horse programs. In a top-secret Defense Department development lab, it might be necessary to have a fiber-optic LAN to prevent generation of electronic emissions. A good certification plan covers all aspects of security, from backup/recovery mechanisms to the Marine guards standing at the front door of your building.

Additional C2 Evaluation Information

If you need to set up a C2-certifiable system, see Chapter 2, "Microsoft Report on C2 Evaluation of Windows NT." That chapter lists the hardware configurations in which Windows NT has been evaluated. Chapter 2 also specifies the set of features that were implemented for C2 evaluation so that you can duplicate them if necessary for your own C2-certifiable system. These features are essentially those recommended for high-level security in this chapter.

For your C2 certification, you will need to choose the combination of security features described in this chapter, in Chapter 2 of Windows NT Server Networking Guide, and in the Windows NT documentation that fits your particular combination of resources, personnel, work flow, and perceived risks. You might also want to study Appendix B, "Security in a Software Development Environment," especially if you are using custom or in-house software. This appendix also provides information on managing and interpreting the security log and technical details on special-case auditing (for example, auditing base objects).

Setting Up a C2-compliant System

To make it easier to set up a C2-compliant system, the C2Config application has been created and included in the Windows NT 4.0 Resource Kit. C2config.exe lets you choose from the settings used in evaluating Windows NT for C2 security, and implement the settings you want to use in your installation. For details, see the online Help included with the application.