Appendix B - Security In a Software Development Environment

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.

Windows NT provides a number of different "environment subsystems," such as the Windows subsystem, the POSIX subsystem, and the OS/2 subsystem. Each of these subsystems presents a set of application programming interfaces (APIs). These subsystems are built using an underlying set of programming interfaces and mechanisms that are primarily used only in the development of the operating system and operating system components (such as device drivers and environment subsystems). These underlying mechanisms are not designed to be used in the development of applications, such as word processors or database server packages, and so generally are of little interest to a security administrator. However, this is not always the case, and in some circumstances these mechanisms are of vital interest to security administrators.

A typical shrink-wrapped product from a reputable manufacturer uses only the programming features explicitly provided for application development. However, what do you really know about a shareware program downloaded from a public network server? It might try to take advantage of some of the mechanisms in Windows NT that are not intended to be used by application programmers — either for beneficial uses, or maybe to introduce a Trojan Horse or virus program into your system. This might also be true if you purchase software from a company more interested in exploiting every bell and whistle, rather than producing quality products using published interfaces and mechanisms. Even your own developers, if your company does its own in-house software development, could use these mechanisms in their programs. As you can see, there are situations where understanding some of these underlying mechanisms and being able to monitor their use is vitally important.

This document helps you to understand some of Windows NT's underlying and internal APIs and mechanisms. It also provides information that can be used by a security administrator to monitor these mechanisms and to interpret the log files generated as a result of this monitoring. This information is, necessarily, quite technical in nature, being roughly equivalent to programmer documentation. In fact, the information in this document might also prove to be useful background for anyone wishing to write some automated security monitoring tools.

User Rights

Cc749970.spacer(en-us,TechNet.10).gif Cc749970.spacer(en-us,TechNet.10).gif

The following rights can be assigned to user accounts through the Windows NT Win32 application programming interface. Security event log entries that record the assignment and use of privileges refer to the privileges using the name shown in parentheses.

Create a token object (SeCreateTokenPrivilege) This right allows a process to create access tokens. Only the Local Security Authority can do this. By default, no account has this privilege. Use of this right is not auditable. For C2 certification, it is recommended that it not be assigned to any user. Debug programs (SeDebugPrivilege) This right allows a user to debug various low-level objects such as threads. By default, the Administrators account has this privilege. Use of this right is not auditable. For C2 certification, it is recommended that it not be assigned to any user, including system administrators. Generate security audits (SeAuditPrivilege) This right allows a process to generate security audit log entries. By default, no account has this privilege. Use of this right is not auditable. For C2 certification, it is recommended that it not be assigned to any user.

Audit Record Format

The format and contents of the audit event records are based on the design of Event Viewer. Event Viewer uses information from the Registry to locate message files and to determine how to present the information in an event record.

Event Viewer expects a number of event source modules to be defined as part of the security audit log information in the Registry. At least one event source module must be provided by each product that generates audit event records. For example, if a mail product is installed, that product's installation procedure needs to add its event source module information to the security log information in the Registry. A special event source module shipped with Windows NT contains default information, so that information does not have to be replicated in other event source modules.

The information defined for event source modules includes:

  • Event Message File. This file contains the displayable strings for each audit event record. It includes parameter substitution markers to be replaced at viewing time with Unicode strings logged in the event record.

    Only the event source module shipped with Windows NT should define an event message file. This single event message file serves as the default for other event source modules.

  • Category Message File. Categories are discussed in "Elements of an Event Record," later in this document. Only the security event source module shipped with Windows NT should define a category message file. This single category message file serves as the default for other event source modules. In Windows NT version 3.51, this file is not actually used for auditing.

  • Parameter Message File. The parameter message file is used to provide object type-specific access names. Each security event source module should (but does not have to) provide a parameter message file. If object type-specific access names are not provided by an event source module, then default names will be used (such as "Specific Access Bit 0").

When Event Viewer is asked to display an audit record, it uses the event source module name and event ID from the record to retrieve a message string for that event. This string can include parameter substitution markers and other format characters that are interpreted and acted upon by a call to FormatMessage(). For example, the string for a successful logon audit might look like:

Successful Logon: \n\t\tUser Name:\t%1 \n\t\tDomain:\t%2

Notice that this message string includes two parameter substitution markers (%1 and %2). These parameter strings are obtained from the event record. So, if Administrator logged on to a computer named ACCTG, an event record containing those two strings would be recorded. The corresponding event record in Event Viewer would look like this:

Successful Logon:
User Name: Administrator
Domain: ACCTG

Before Event Viewer formats the entire message string, it must format the individual parameter strings received in the event record. In the preceding example, the parameter strings needed no formatting. In the case of an audit generated when a file is opened for WRITE_DATA and WRITE_DAC, however, the event message might be:

Object Open:\n\t\tObject Type:\t%1\n\t\tObject Name:\t%2\n\t\tAccesses:\t%3 

and parameter strings received in the audit record might be:

  • Parameter string 1: "File"

  • Parameter string 2: "C:\accounting\payroll\hours_worked.dat"

  • Parameter string 3: "%%972\n\t\t\t\t%%1032"

The "%%" directive tells Event Viewer to look up and substitute the message specified by the number following the directive from the parameter message file for the event source module. Assuming message numbers 972 and 1032 in the message file are "Write DAC" and "Write Data" respectively, the third string will be changed to:

Write DAC\n\t\t\tWrite Data 

This would cause the resultant display by Event Viewer to look like:

Object Open:
Object Type: File
Object Name: C:\accounting\payroll\hours_worked.dat
Accesses: Write Dac
Write Data

(This example is for illustrative purposes only and does not correspond to an actual event-record type.)

Tight Security for Shared Objects

Cc749970.spacer(en-us,TechNet.10).gif Cc749970.spacer(en-us,TechNet.10).gif

As shipped and installed, Windows NT is configured to provide a high degree of ease of use. In some cases, this ease of use can be seen as a security threat. This is particularly true of "denial of service" attacks, in which a user is able to deny others the use of various parts of the system. There are a number of components of the underlying mechanisms of Windows NT that may be affected in this manner by anyone with the programming knowledge to locate and manipulate them.

A highly security-conscious system administrator might choose to trade this ease of use for added security. It is impossible to enumerate all the ways in which this tradeoff might be seen or experienced by each user or application. However, you can expect that the biggest area of impact will be for users that redefine system-wide resource attributes, such as the attributes of COM1: or of printers. In general, by tightening base security, you must accept that these shared resources will be administered only by system administrators.

To strongly protect shared objects, use the Registry Editor to create or assign the following Registry key value:

Hive:

HKEY_LOCAL_MACHINE \SYSTEM

Key:

\CurrentControlSet\Control\Session Manager

Name:

ProtectionMode

Type:

REG_DWORD

Value:

1

If this value does not exist, or is set to anything other than one (1), then standard protection is applied to these objects.

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

Auditing

Cc749970.spacer(en-us,TechNet.10).gif Cc749970.spacer(en-us,TechNet.10).gif

This section describes special cases of auditing that might be of interest to administrators of high-level security installations.

Auditing Backup and Restore Activities

When files are being backed up, Windows NT checks to ensure that the user performing the backup has the Back Up Files and Directories special right each time the backup program attempts to copy a file to the backup media. In the same way, Windows NT checks for the Restore Files and Directories right for each file that is being restored from backup media. Obviously, if Windows NT were to record an audit event each time those rights were invoked, thousands of events would be recorded during a routine backup. Because this would flood the security log with event records that most often would be of little value for maintaining system security, Windows NT does not normally record audit events for the use of these rights, even when success auditing of Use of User Rights is enabled in the system user rights policy.

To audit the use of these rights, use the Registry Editor to create or assign the following Registry key value:

Hive:

HKEY_LOCAL_MACHINE \System

Key:

\CurrentControlSet\Control\Lsa

Name:

FullPrivilegeAuditing

Type:

REG_BINARY

Value:

1

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

Note The use of the following rights is never audited, even when the FullPrivilegeAuditing Registry entry is set to 1. However, the assignment of these rights, during logon, is audited.

  • Bypass traverse checking (SeChangeNotify)

  • Generate security audits (SeAuditPrivilege)

  • Create a token object (SeCreateTokenPrivilege)

  • Debug programs (SeDebugPrivilege)

  • Create a new security context for a new logon (AssignPrimaryToken)

Managing Auditing of Particular Objects

In addition to letting you audit system-wide events (such as users logging on), Windows NT gives you the ability to record such events as whether a specific user fails to open a given object (such as a file or printer) for a particular type of access.

Note Only files and directories in NTFS partitions can be audited, and it is only access that is auditable, not intent. In other words, the audit log records will show that a particular user opened a specific file or directory; it will not tell you what the user's intent was. Copying a file, reading a file, or viewing a file's attributes all write the same set of audit records to the log.

To be able to audit object access in this way, you must first use the Audit Policy dialog of User Manager to enable auditing of file and object access events. You can enable auditing of success or failure events, or both. This establishes the global object-access auditing policy for the system. The global policy determines whether object-specific auditing will occur at all; to record access events for a particular object, you must also specify the type of auditing to be performed for that object. File Manager lets you set up auditing for files and directories, Print Manager lets you configure auditing for printers, and Registry Editor lets you specify auditing for Registry entries.

In a sense, object-access auditing works like a building's electrical system. You can turn on and off switches for lamps throughout the building, but if the master circuit breaker is off, no lamps will actually turn on. On the other hand, if the master circuit breaker is on, then only those lamps whose switches are in the on position will light up.

Because the security log is limited in size, and because a large number of routine audit records can make it difficult to find records that suggest a security problem, you should carefully consider how you will audit object access. Generating too many audit records might require you to review and clear the security log more often than is practical. On the other hand, judicious use of object-access auditing can be invaluable in helping you identify areas where your security policy should be tightened or even where a security breach has been attempted successfully or unsuccessfully.

For example, if you use permissions to control users' access to sensitive files and directories, you should enable auditing of those users' access to those files and directories to ensure that the permissions are working as expected.

If a directory has a list of users whose access to the directory is to be audited, a new file added to the directory will inherit the auditing list from the directory. You can ensure that Windows NT Workstation will record access to new files by making sure the new files are placed in directories with auditing lists.

Note Only new files and directories inherit auditing lists from the directory in which they are created. To ensure that access to existing files will be audited, be sure to select both Replace Auditing On Subdirectories and Replace Auditing On Existing Files in the Directory Auditing dialog box when creating a directory auditing list.

For procedures for managing access auditing for files and directories, see the "File Manager" chapter in the Windows NT Workstation or Windows NT Server System Guide. For procedures for managing access auditing for printers, see the "Print Manager" chapter in the Windows NT Workstation or Windows NT Server System Guide. For information about auditing access to Registry keys, see the online Help for Registry Editor and Part IV, "Windows NT Registry," in the Windows NT Resource Guide.

Base Object Auditing

In addition to Files, Registry Keys, and Printers, Windows NT has a number of objects that are not generally visible to or known by a typical user. Application programmers or people writing I/O device drivers might have learned about these objects in software development or device driver development kits. Normal interactive users, however, have no direct ability to affect these objects except as intended by Windows NT.

Generally speaking, these objects are used by Windows NT in a manner that makes auditing their use not very interesting. In fact, doing so can introduce so many audit entries into the security log that locating real security problems becomes considerably more difficult.

However, in some situations, it might be desirable to audit accesses to base objects. For example, where custom applications are being developed, the "users" are not just the people that interactively log on, but also the programmers who are developing applications. These programmers might be able to directly access the base objects.

Note It is only access that is auditable, not intent. In other words, the audit log records will show that a particular user opened an object; it will not tell you what the user's intent was.

To audit the use of base objects, first set your system's audit policy to audit successful and/or failed object accesses, and then use the Registry Editor to create or assign the following Registry key value:

Hive:

HKEY_LOCAL_MACHINE \SYSTEM

Key:

\CurrentControlSet\Control\Lsa

Name:

AuditBaseObjects

Type:

REG_DWORD

Value:

1

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

Accesses to shared base objects appear in the security log as Object Access events, like those for Files, Registry Keys, and Printers, but with different object type names and access names. For a full description of each of the base object types and their access types, refer to the Microsoft Software Developer's Network (MSDN). To receive MSDN level 2, call 800-759-5474.

When the Security Log Is Full

If you have set the security log either to "Overwrite Events Older than n Days" or "Do Not Overwrite Events (Clear Log Manually)", you might want to enable CrashOnAuditFail. The CrashOnAuditFail registry entry directs the operating system to crash (shutdown abnormally and display a blue screen) when the audit log is full. This assures that no auditable activities, including security violations, occur while the system is unable to log them. To enable CrashOnAuditFail, use the Registry Editor to create the following Registry key value:

Hive:

HKEY_LOCAL_MACHINE \SYSTEM

Key:

\CurrentControlSet\Control\Lsa

Name:

CrashOnAuditFail

Type:

REG_DWORD

Values:

1 Crash if the audit log is full.
2 (This value is set by the operating system just before it crashes due a full audit log. While the value is 2, only the administrator can log on to the computer. This value confirms the cause of the crash. To reset, change this value back to 1.)

The changes take effect the next time the computer is started. You might want to update the Emergency Repair Disk to reflect these changes. Note that there is no 0 value for this key. To disable CrashOnAuditFail, delete the key from the registry.

If Windows NT halts as a result of the security log becoming full, the system must be restarted and reconfigured to restore it to high-level security. When Windows NT restarts, the Security log is full and so no auditable actions are recorded until the Security log is cleared.

To recover when Windows NT halts because it cannot generate an audit event record
  1. Restart the computer and log on using an account in the Administrators group.

  2. Use Event Viewer to clear all events from the Security log, archiving the currently logged events. For details, see the "Event Viewer" chapter in the Windows NT Workstation or Windows NT Server System Guide.

  3. Use the Registry Editor to change the value of CrashOnAuditFail, to 1, under HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \Lsa (as described earlier in this section).

  4. Exit, and then restart the computer.

Interpreting the Security Log

Cc749970.spacer(en-us,TechNet.10).gif Cc749970.spacer(en-us,TechNet.10).gif

When you view the security log, you can use filters to specify criteria for the records you want to view. For example, you can choose to view events recorded by a particular source within a range of dates.

If you need a more complex analysis of the information in the security log, you can save the security log in one of two text formats. The information can then be imported into an analysis tool (such as a spreadsheet). See the "Event Viewer" chapter in the Windows NT Workstation or Windows NT Server System Guide for more information about using security log data archived in a text format.

Elements of an Event Record

All event-log records, regardless of type, consist of a header containing standard information, a description that varies depending on the event type, and (optionally) additional data. Most security log entries consist of the header and a description.

The event-record header contains the following information:

Date

The date the event occurred.

Time

The (local) time the event occurred.

User

The username of the user on whose behalf the event occurred. This is the client ID if the event was actually caused by a server process, or the primary ID if impersonation is not taking place. Where applicable, a security log entry contains both the primary and impersonation IDs.

Computer

The name of the computer where the event occurred. (Event Viewer can be used to view event logs on other Windows NT computers on a network.)

Event ID

A unique number identifying the particular event type. The first line of the description usually contains the name of the event type. For example, 562 is the ID of the event that occurs when a new object handle is created, and so the first line of the description of such an event is "Handle Allocated."

Source

The name of the system component that actually recorded the event in the security log. Usually, this is Security, indicating that it is the result of Windows NT security auditing. Applications can also define their own auditable events that can be recorded in the security log.

Type

Either Success Audit or Failure Audit, indicating whether the audit is a record of a successful or failed attempt. In Event Viewer's normal list view, these are represented by a key or a lock, respectively.

Category

A classification of the event by the event source. For security audits, this corresponds to one of the event types for which success or failure auditing can be enabled in the User Manager Audit Policy dialog.

The format and contents of the description that appears with these items vary with the event category. The various event categories are discussed later, under "Audit Categories."

Identifying the User Behind the Action

The security log identifies the user account that caused each recorded event to happen. In some cases, more than one account is actually involved because of the client-server design of Windows NT. This design makes it possible for one process (called a server process) to perform actions on behalf of another process (called the client process).

When the server process is acting on behalf of the client, Windows NT security treats it as though it were the client process. The server process is not allowed to access objects that are off limits to the client.

Also, the audit records for events performed by a server impersonating a client identify the "user" that "owns" the server process as the primary user (typically identified as SYSTEM), and the user responsible for starting the client process as the client user. When there is no impersonation taking place, the primary user is the actual user who started the process that caused the audited event to occur. Most often, this is the user who is actually logged on to the computer, although sometimes it can be SYSTEM.

Process IDs

Primary IDs and impersonation IDs provide enough information for many security administrators because they show who is performing auditable actions. However, in some cases, an operator might want to see what is going on at a process-by-process level of detail. If detailed tracking auditing is enabled, the security log shows when a new process is created (such as when an application program begins execution). Each process is assigned its own, globally unique process ID, which is included in all records of events caused by that process, to the point at which the process ends.

This information can be correlated with specific audit event records to see which user account is being used to perform auditable actions and which program was being run. Process IDs are included in audit event records regardless of whether process-level tracking is enabled. However, process IDs are useful only if process-level tracking is enabled.

Note Because of the way impersonation works, it is impossible to know what the process ID of a client is at audit time. In fact, a single access token can actually be used by several processes simultaneously. For this reason, process IDs can only be displayed by audits generated by the Kernel.

Handle IDs

When a particular operation consists of multiple actions, Windows NT assigns an operation ID to each so you can properly associate the separate actions with the operation. This operation ID is unique only to the process performing the operation. Furthermore, to help you track how a process accesses a particular object, each object is identified by a handle ID. Typically a new handle is allocated immediately after a file is opened, and then closed when the file is closed. If the handle ID refers to a Kernel object, the handle ID is unique only to the process to which the handle belongs. If the handle ID refers to an object managed by a protected server, the handle ID is unique across all processes.

The handle ID enables the audit to be associated with future audits. For example, when a file is opened the audit information indicates the handle ID assigned. When that handle is closed another audit event record is generated which also includes the handle ID. This allows you to determine the entire span of time the file was open, which can be useful when attempting to assess damage following a security breach.

There are two types of handle IDs, often called Kernel object handle IDs and protected server object handle IDs. Handle IDs to Kernel objects are unique only to the process to which the handle belongs. As a result, two processes can have a handle with an ID of 35, for example; they are distinguished by the process ID associated with them. Handle IDs to protected servers on the other hand, come from a single ID space and are unique across all processes.

Audit Event Record Contents and Meaning

This section describes the contents and meaning of each audit event record.

Common Event Record Data

Audit event records include header information that is present in all event records. The following list describes this common information.

  • The time the event was generated.

  • The SID of the subject that caused the event to be generated. If possible, Event Viewer translates this SID to an account name for display. The SID is the impersonation ID if the subject is impersonating a client, or the primary ID if the subject is not impersonating.

  • The name of the system component or module that submitted the event. For security audits this is always Security.

  • The module-specific ID of the specific event.

  • The event type, either Success Audit or Failure Audit.

  • The event category, used to group related events such as logon audits, object access audits, and policy change audits.

When an event is displayed in detail, this information is displayed at the top of that window. The following is an example of how this information is displayed:

Date: 8/12/96 Event ID: 172
Time: 10:32:11 AM Source: Security
User: Administrator Type: Failure Audit
Computer: ACCTG Category: Logon/Logoff
Audit Categories

Audit event records are divided into auditing categories. These categories are displayed by Event Viewer and allow a user to visually distinguish or automatically filter audit events of interest. These audit categories are listed in the following table, and discussed in detail in the Audit Categories Help file (Auditcat.hlp).

Category

Description

System Event

Events in this category indicate that something affecting the security of the entire system or of the audit log has occurred.

Logon/Logoff

Events in this category describe a single successful or unsuccessful logon or logoff. Included in each logon description is an indication of what type of logon was requested/performed (for example, interactive, network, or service).

Object Access

Events in this category describe both successful and unsuccessful accesses to protected objects.

Privilege Use

Events in this category describe both successful and unsuccessful attempts to use privileges. The Privilege Use category also covers a special case of informing when some special privileges are assigned. These special privileges are only audited when they are assigned, not when they are used.

Account Management

Events in this category describe high-level changes to the security account database, such as the creation of a user account or a change in group membership. There can also be a finer granularity of auditing performed at the object level under the Object Access category.

Policy Change

Events in this category describe high-level changes in security policy, such as the assignment of privileges or changes in the audit policy. There can also be a finer granularity of auditing performed at the object level under the Object Access category.

Detailed Tracking

Events in this category provide detailed subject tracking information, such as program activation, some forms of handle duplication and indirect object accesses, and process exit.

Cc749970.spacer(en-us,TechNet.10).gif