I Introduction

A wise person once said that you can't audit something if you don't understand its architecture. (If you don't understand the architecture, then you can't tell where the control points are, much less how to evaluate them.) This article will show you how to audit the security of the Windows NT operating system, first by describing its architecture, then by providing the outline of an audit program. This audit program is based on the "Big 6 Questions Approach", which is described below, along with specific steps to take in carrying out the audit.

II NT Architecture --- Three Critical Features and Several Basic Concepts

To understand the architecture of the NT operating system you should understand three critical features on which its security is based as well as some basic concepts.

A) Three Critical Features

The NT security architecture has three characteristics which make it more robust than most platforms, when these three features are effectively utilized. Reviewing how these features are utilized in a given installation provides an effective way to audit or review NT security. The three features are:

A1) TCB or Trusted Computing Base

A2) Object-Oriented Architecture

A3) ACLs or Access Control Lists

A1) TCB or Trusted Computing Base

A Trusted Computing Base or TCB is a computer platform which uses hardware controls to prevent users from executing sensitive instructions and from accessing memory to which they are not authorized. The operating system, such as NT, takes advantage of such hardware controls to prevent users of the system from interfering with each other and with NT itself. Without such controls (as you may have noticed with MS/DOS or Windows), any user can alter the operating system with any editor. The idea of a TCB is an essential foundation to effective security, and is a pre-requisite for C2 certification from the Federal government. If the integrity of the TCB is violated, you cannot rely on the security of the system. When the TCB is intact, only the operating system (and certain users with the privileges of the operating system) can execute sensitive hardware instructions.

Operating systems without TCBs include MS/DOS, Windows, Novell Netware release 3, and DOS/VSE on IBM mainframes. Operating systems with TCBs include: Windows NT, Novell Netware release 4, OS/2, and both MVS and VM on IBM mainframes. The Windows 95 operating system has a TCB, but only when operating in 32-bit mode.

NT uses two hardware modes (User and Kernel) to distinguish between the instructions which ordinary uses can execute and those which the inner part of the operating system (the kernel) can execute.

A2) Object-Oriented Architecture

The design of the NT operating system is object oriented or OO. This means that it is based on the concept of objects, each of which can be referenced only by means of pre-defined methods (software routines).

Examples of objects include: files, directories, computers, users, printers, and other resources. Because all references to objects are through predefined methods, it is easy to ensure that every object is always protected by the security monitor. The security monitor is the part of NT which decides whether or not to allow an access. Methods are designed to invoke the security monitor and to fail access attempts which the security monitor denies. This means that it is impossible to access any object without the approval of the security monitor.

To put this in perspective, contrast the OO approach with the procedural approach seen in most COBOL, FORTRAN, and C programs. In the procedural approach, the steps to be followed are coded sequentially in the software without being rigorously associated with the data. There is no easy way to determine whether a programmer has forgotten to call the security monitor in one part of the program.

A3) ACLs or Access Control Lists

When the security monitor is invoked to determine whether to allow an access, it uses a data structure called an Access Control List or ACL. Each ACL is associated with one object. Each ACL contains entries. Each entry lists either a user or group and the privilege that user or group has over the associated object. For example, a file might have an ACL specifying that the ADMINISTRATOR userid has READ privilege over the file and the group EVERYONE has CHANGE privilege over it.

The ACL structure provides great flexibility and precision for NT access control, in contrast to other, bit-oriented systems. For example, UNIX files have bit-flags indicating which of three privileges (READ, UPDATE, and EXECUTE) are granted to each of: the owning user, the owning group, and the rest of the world. This limits UNIX access control to just one user, just one group, and only three possible privileges. NT can combine a large number of possible privileges to an unlimited number of users and groups in varying combinations.

B) Basic Concepts of the NT Architecture

NT comes in both workstation and server versions, executing standalone on a single computer or controlling many computers as part of a Local Area Network. In a LAN, NT computers are organized for security administration into domains.

B1) Domains, SAMs, and Security Policy

A domain is a collection of NT computers which are connected together and which share a common security accounts manager (SAM) database and a common security policy. Each domain has at least one server which is dedicated to answering security questions. This is called the Primary Domain Controller or PDC. Ideally there will be a second server called the Backup Domain Controller or BDC to be used if the PDC should fail.

The SAM contains the definitions of users, groups, and computers for security administration. The security policy specifies options such as how often users must changes passwords, how long passwords must be, and how many invalid passwords will cause a userid to be locked out (made unusable).

B2) Userids and Groups, Rights and Privileges

Users identify themselves to NT by means of userids (user identifiers). Userids are organized into groups to simplify security administration. An account is a record in the SAM which represents a user or a group or a computer.

Users and groups can be granted rights which give them the authority to do privileged operations. For example, there is an administrators group which has the rights to perform all security administration. Other rights include the ability to access a computer from the network and the ability to logon locally.

NT systems have built-in GUEST accounts designed to let casual users access the system with limited access. When the GUEST accounts do not require passwords, they can represent a security exposure if their accesses are not rigorously limited.

The EVERYONE group represents all users. Because the GUEST user is a member of EVERYONE, GUEST accounts can represent an exposure. If GUEST accounts do not require passwords, then anyone can use them to access any files and resources to which EVERYONE is permitted. As you will see below, many files and resources by default have ACLs which give EVERYONE the powerful FULL CONTROL privilege.

B3) Trusts

A trust is the ability of one domain to trust another domain to establish a user's identity. When trusts are defined between domains, security administration can be simplified for both userids and groups. On the other hand, if one domain trusts another domain, and the other domain defines GUEST accounts which don't require passwords, then the GUEST accounts on the trusted domain will be part of the EVERYONE group on the trusting domain. This can represent an unsuspected security exposure.

B4) Disks, Partitions, Directories, and Files

Disks are logically broken into partitions, each of which is a collection of contiguous locations on the disk. Each partition uses one and only one file system to organize the files it contains. NTFS, or NT File System, is the file system recommended for effective security.) Files on disk partitions which use file systems other than NTFS should be considered insecure, since the NT security mechanisms don't apply to them. (The FAT file system is the one most people are familiar with from MS/DOS, PC/DOS, and Windows.)

In the same way that users can be organized into groups, files are organized into directories. Directories are further organized into an inverted tree-like structure with sub- directories subordinate to other directories. The top of this inverted tree is referred to as the root directory. This directory structure will be familiar to anyone who has worked with directories on MS/DOS or Windows. With NT however, the directory structure has implications for security. Privileges can be granted to a directory, and automatically propagated to all its files, its sub-directories and their files.

The default ACL for the root directory on every NTFS partition is to grant EVERYONE the FULL CONTROL privilege. This ACL will be inherited by every subdirectory created in the root directory, as well as by every file, unless someone deliberately changes it.

When deciding whether or not to allow a user to access a file, NT makes these checks in this order:

a) Does the user have a right which allows the access (such as the right to make backups)? If so, allow the access.

b) If the access is across a network, does the user have sufficient privilege to the share? If not, fail the access.

c) If the file is on an NTFS partition, does the user have sufficient privilege to the file or to its directory? If not, fail the access.

B5) Resources

Resources include shares, printers, and the NT registry.

Shares are definitions of existing directories, printers, or other resources which make them available to other users. For example, assume that on a given hard drive I have an NTFS partition which is considered the D: disk. The root directory on D: has two subdirectories, TEST and PROD. I want to make the TEST subdirectory and all its subdirectories and files available to other users. I would define a share representing TEST. Since shares have ACLs, I would then need to update the ACL of the share to permit only those users or groups who should have the access.

Printers are printers which are made available to other computers and users on the network. Printers also have ACLs, to control who can print on them and who can administer them.

The NT registry is the database where NT maintains all the information it needs about its hardware, its users, and its software configuration. The security monitor uses ACLs to control access to the registry and to its components.

With these basic concepts under our belt, let's turn now to see how to conduct the security audit.

III The Audit Program --- Planning and the Big Six Questions

A) Planning Your Audit

To plan your audit of NT security, you will need to determine the size of the network you are addressing. Identify which computers are connected together and how they are organized.

We show you the mouse clicks you need to collect the data in [square brackets]. (For release 3.51 of NT, your first mouse clicks will usually be on [Main], followed by [Admin Tools]. For release 4 of NT, your first mouse clicks will usually be on [Start], followed by [Programs], followed by either [Admin Tools] or [Explorer]. Explorer is the program in release 4 which corresponds to the File Manager in release 3.51.)

__ List the domains and the workstations connected to them. Mark the purpose of each server (print, database, security administration, etc.). Ask the system administrator for this information or ask the system itself from an account with administrator privileges [The mouse clicks to do this are: Admin Tools; User Manager for Domains; User; Select Domains.]

__ List the PDC and BDC for each domain. Determine whether the procedures to handle failure of the PDC (by promoting the BDC to be the new PDC) are in writing and have been tested.

__ Determine whether your audit will address: access control, disaster recovery, data integrity, physical security, efficiency, effectiveness, or other audit objectives. This article concentrates on access control, with related attention directed to physical security.

B) The Big Six Questions

An easy way to organize your audit of Windows NT security is to break the analysis down based on the Big 6 questions described below. Each of these is a YES/NO question which can be understood by business people as well as by information processing specialists.

Answering all six of these questions will provide an excellent answer to the question: "How good is information security on our NT system?"

The six questions are:

Q1) Can anyone use the system without being explicitly authorized?

Q2) Can anyone on the system access files without being explicitly authorized?

Q3) Can anyone on our system access resources other than files (such as directories and print servers) without being explicitly authorized?

Q4) Can anyone change the access rules without being explicitly authorized?

Q5) Is there adequate separation of duties?

Q6) Is the integrity of the operating system's Trusted Computing Base (TCB) maintained?

Q1) Can anyone use the system without being explicitly authorized?

Control over access to the NT system consists of: user identification through the Winlogon and Netlogon standard logon processes, the user policy, rights, and trusts. You will need to determine how well the standard logon processes shut out unauthorized users.

You will also need to determine whether software and network connections have been added to the system which allow access to the system without going through these standard logon processes.

The standard logon processes require all users to signon with a userid and (usually) a secret password, controlled by a PDC. You will note that entering CTRL+ALT+DELETE will not reboot an NT computer. Instead it invokes the signon screen. This is to prevent "spoofing" or the use of a program which displays a fake logon screen in order to trap users' passwords.

A common way of weakening security is to define a GUEST account in one domain without requiring a password (or by making the password easy to guess). When a second domain trusts this first domain to verify user's identities, the GUEST account from the first domain is included in the EVERYONE group in the second domain. Unless there is rigorous control over delegation of authority, the EVERYONE group may be granted access to inappropriate data.

A second common way of weakening security is to configure GUEST accounts without passwords in trusted domains in such as way that the GUEST account can be used to guess passwords. For example, assume that a GUEST account has UPDATE authority to a directory where it also has the EXECUTE privilege. In such a case it is easy to write a program which invokes Winlogon to try to guess the Administrator's password.

Non-standard accesses (that is access to the system which does not go through the checking of Winlogon or Netlogon) are possible if someone has installed software (such as support for TCP/IP) which allows users to access the system without going through one of the standard logon processes. In these cases, the software (such as TCP/IP) is logged on through the standard logon processe and is described to NT as a service. The service has its own userid, which is often the privileged userid System. When a server permits access to the system without requiring standard logon processing, then we must rely on the server software to provide security. While non-standard accesses are outside the scope of this article, you can identify such paths into your system by reviewing the services which represent TCP/IP and other connectivity software.

__ Review physical security over all PDCs and BDCs, as well as over all wiring connecting workstations.

__ Map the trusts between domains. (A trust is the ability of one domain to trust another domain to verify a user's identity. This is in contrast to a share (described below), which is the ability of a user on one system to access resources on another.)

__ Review user accounts. [Admin Tools; User Manager; User; Properties]

__ Review the security policy. This specifies how soon passwords must be changed, how long passwords must be, whether blank passwords are permitted, how many invalid passwords are needed to lock an account out, and similar options.[Admin Tools; User Manager; Policy; User]

__ Verify that the Administrator's account has been renamed. (This is to prevent hackers from trying to break into the system by guessing the password to the Administrator's account.)

__ Determine whether the administrator accounts have been prevented from logging on through the network. (This requires the administrator to be physically at the server, making it more difficult for hackers to guess administrative passwords over the network. This works best when there is effective physical access control over the server.)

__ Determine whether all accounts with operating system privileges have been denied the right to logon via the network.

__ Review the on-screen greeting which accompanies the logon screen to be sure that it warns users not to use the system without authorization. (Consult with your legal department for appropriate wording. This greeting is specified in the NT Registry, which is described below.)

__ Review policy regarding use of sniffer programs. These are programs which can read every packet of information on a local area network. The NT Network Monitor is one such program. Hackers use sniffers to copy a user's logon request (userid and password) and then logon as that user. Sniffers are not native to NT; you can experience them on any local area network. Recognize that they may be on your system and assess the risk of the data on your system being accessed by a hacker who has "sniffed" a logon request and played it back. Sniffers are practically impossible to detect or prevent (unless you use physical controls and file controls to prevent anyone from adding any program to the system).

__ For non-standard accesses:

__ Identify software to support network connections which might bypass the standard signon process.

__ Consider disabling server, workstation, and NetBIOS services.

__ Consider using filtering for TCP/IP connections to block unauthorized packets.

A satisfactory answer to the Q1 question indicates that: all paths into your system are controlled by Winlogon or NetLogon or other reliable means; every user is reliably identified; and no one can reasonably expect to use the system by pretending to be someone else.

Q2) Can anyone on the system access files without being explicitly authorized?

Access control for files on NT systems consists of: physical controls, shares, and, for NTFS partitions, access control lists describing the privileges assigned to various userids and groups for each file. Physical controls restrict access to disk drives. Shares are resources such as directories which are shared across a network. Access control lists (or ACLs) are part of the security which is built into NT for files which use the NTFS file system.

Administration for file access controls is simplified by organizing users into groups. It is easier to grant a privilege to a single group account than to grant the privilege to each of several user accounts. A well-planned NT implementation will have a carefully defined group structure, consisting of groups such as "the group of users who can READ the payroll files", or "the group of users who can do things that Finance Department managers can do". This simplifies the granting of permissions. It also simplifies the delegation of authority, as we will discuss below under Q4.

When evaluating ACLs, remember that privileges are cumulative, with the exception of No Access. For example, suppose a user USER02 is a member of GROUPA, GROUPB, and GROUPC. You are examining the ACLs for a certain payroll file, and note that GROUPB has READ access and GROUPC has Full Control. You know then that USER02 has Full Control because she is a member of GROUPC. However, if GROUPA were added to the ACL with No Access, then USER02 would have No Access, since No Access overrides all the other privileges. If a user is not in the ACLs for a file, and none of her groups are either, then she has no access to the file.

__ Evaluate physical security to ensure that unauthorized users cannot access disk drives.

__ Determine whether it is possible for a user to IPL the system with a different operating system. For example, dual-boot configurations on the hard drive can permit IPL of several operating systems. If anyone can put a diskette into the A: drive of the computer and IPL off the A: drive, then non-NT operating systems can take control of the hardware. If someone can IPL MS/DOS or Windows on your NT hardware, they can then access NTFS files without the protection provided by NT. There are now available utilities which execute under MS/DOS to read files written in the NTFS format.

__ Identify disks and the partitions on each. Determine which disk partitions are formatted with NTFS, with FAT, or with other file systems. [Admin Tools; Disk Admin]

__ Review written security policy and ACLs for directories. Compare to written authorizations, strategy statements for directory structure, or formal risk assessments.

__ Review ACLs for files. Compare to written authorizations, strategy statements for directory structure, or formal risk assessments.[Main; File Manager; Security; Permissions]

__ Determine if there is a standard against which to compare ACLs. Are owners of applications identified and do they indicate in writing who should be permitted to their data? Do the ACLs match the written authorizations? (Mainframe installations often require annual recertifications or review by owners of the users who can access their data.)

A satisfactory answer to the Q2 question indicates that: all files and directories are protected by the NT security manager using NTFS; all files and directories are protected by ACLs which permit only the access authorized by appropriate parties after a formal, business-oriented risk assessment.

Q3) Can anyone on our system access resources other than files (such as shares and print servers) without being explicitly authorized?

__ Review shares between systems and the permissions for each. (Remember that a Share is the ability of one system to trust users on another to access its data. This is in contrast to a Trust in which one domain trusts another to verify a user's identity.) [Main; Control Panel; Server; Shares]

__ Review written security policy and ACLs to printers. [Main; Print Manager; Security; Permissions] Compare to written authorizations, strategy statements for printer access, or formal risk assessments.

__ Review security settings for the registry.

A satisfactory answer indicates that all sensitive resources have been identified and properly protected.

Q4) Can anyone change the access rules without being explicitly authorized?

Users can change security rules depending on their rights, privileges, and ownership of files and resources.

__ Review which users are members of administrator groups, the Power Users groups and other groups with authority to change accounts and ACLs.

__ Review which users have such authority from privileges and from ownership.

__ Compare these authorities to whatever standards exist specifying who should have them. If no such standards exist, then evaluate the risk to the organization of those users having those authorities.

A satisfactory answer indicates creation, change, and deletion of security rules (whether for users, datasets, resources, or other entities) can only be made by authorized persons.

Q5) Is there adequate separation of duties (of the three security functions: approve who should have access, execute the permission to allow the access, and review access approvals in the light of actually permitted accesses)

__ Determine how security decisions are made and by whom. Are authority and responsibility for each of three functions clearly assigned? To different people, in such a way as to create a standard against which ACLs can be compared? If a single person carries out all three functions, especially without formal, business- oriented risk assessment, evaluate the risk to the organization.

An effective answer to this question indicates that: owners have been identified for approving each access; the owners are people who best understand the associated business risk; the owners have indicated their approval in writing; the NT security rules correspond to the written approvals and are administered by staff which is independent of the owners; the rules are compared to the written approvals by someone independent both of the owners and of the security administrators.

Q6) Is the integrity of the operating system's Trusted Computing Base (TCB) Maintained?

On NT systems, userids can be granted a right which allows them to have the privileges of the operating system, that is to execute in kernal mode. In addition, accounts which are part of the Administrator or other powerful groups may have this privilege. Device drivers are software modules added to the system, usually supplied by the vendor of an input/output device to support its use with NT. Device drivers execute in kernel mode.

__ Evaluate change control procedures to determine who has the authority to alter the system. Are controls in place to ensure that all system software modifications are: authorized, documented, tested, and provided with a graceful fallback?

__ Determine if policy requires all software which executes in Kernel mode to be supported by a written guarantee from the vendor that the software does not violate the TCB's integrity. (Mainframe installations have been requiring such statements from vendors for decades. IBM provides such an integrity statement for the MVS mainframe operating system itself, assuring customers that MVS, as supplied by IBM, will not permit unauthorized users to obtain Supervisor state. Supervisor state is the MVS analogue to Kernel mode. Perhaps vendors of other operating systems will follow this example.)

__ Review physical security controls to prevent unauthorized users from IPLing (that is, booting or initializing the system) from a diskette supporting some other operating system.

__ Review which accounts have the right to obtain the privileges of the operating system. [User Manager; Policies; User Rights; Show Advanced Rights; look for the right named "Act as part of the operating system".]

__ Review which services can execute with the userid of the administrator or with any of the userids which can obtain operating system privileges.

Audit Trail

NT provides an audit trail as part of the EVENT LOG. You will want to review its option settings as well as the the audit data itself.

__ Review the Audit Policy which determines which types of event are logged. [Admin Tools; User Manager for Domains; Policies; Audit].

__ Review the current event log. [Admin Tools; Event Viewer]

__ Review procedures for reviewing and following up incidents in the log.

Summary

We have described the components of the NT security architecture and described how to review them in a systematic fashion to audit the security of an NT installation. You might want to consider use of automated audit tools such as the Kane Security Analyst, Bindview, and the DumpACL program from Somarsoft.