Last spring, the computer consulting firm GartnerGroup held a conference entitled "Windows NT: Strategies for Success." In an intriguingly titled session, "NT Security: When is 'Good Enough' Not Enough?" the group put forward its list of seven top NT security problems. As a security analyst specializing in NT, I found the session useful from a strategic viewpoint, but I question some of the technical details. After all, it's troublesome technical details that can make or break security. In this article, I'll analyze GartnerGroup's list. I'll tell you when I don't think GartnerGroup's concern is warranted, and I'll let you know what my top NT security problems are. Let's begin with GartnerGroup's List of Seven.
Problem 1: Domain Complexity
GartnerGroup recommends training administrators and avoiding domains to address the security concerns that NT's complex domain structure creates. This point is well taken: Using Microsoft's domain models to implement an existing organization can be difficult and confusing. Many administrators (and even some Microsoft engineers) lack a complete understanding of how various NT components (e.g., workstations, member servers, and domain controllers) cooperate in a single- or multidomain environment. This incomplete understanding often leads to a more complicated and costly computing environment than necessary. For example, suppose a department requires full control over who accesses the department's data. (Human resourcesHRdepartments commonly need such control.) Most IS departments meet these requirements by creating a new resource domain for the department, with trust relationships to the master domain. However, if you really understand NT security, you can meet these requirements without a second domain. With fewer domains, you enhance security and reduce costs because you have fewer trust relationships to manage and fewer domain controller systems to purchase and maintain, and you have less potential for inconsistent administration practices and policy between domains.
To plan secure NT environments, you must understand how a system's components work together within a domain and how to effectively use each component. You must also understand how NT groups and users relate to one another, and how an organization structures its users, administration, and resources. You can leverage NT's C2-compliant object ownership to enhance the security of your NT network (for more information about NT's C2 security rating, see Mark Russinovich, "Windows NT Security, Part 1," May 1998). Every object (e.g., a file) has an owner who is by default the user who created it. As an object's owner, you control access to the object with permissions. To reduce administrators' workload, some organizations put user departments in control of their own resources. Usually, an administrator grants a user access to a resource only after getting approval from the designated owner of that resource. For example, HR managers usually own the personnel database and make the final decision about who can access the database. This classic approach to access control loads the administrator with tasks that any trusted end user can perform. Some organizations designate a trusted clerical employee in each user department to be the owner of that department's resources. That clerical user then handles routine access control as the department manager directs, thereby lightening the administrator's load and simplifying access control.
Problem 2: Administrator Account Does Not Lock Out
GartnerGroup recommends three strategies to work around this problem. The first is to change the account name to a nonintuitive name and create a dummy account. The second strategy is to require a minimum 10-character alphanumeric password. The third strategy is to require Enable failure for log-on/log-off in auditing policies.
It's true that, out of the box NT never locks out the administrator account, even if account policies enable this feature. However, you can use PASSPROP, a command-line program in the Microsoft NT Server 4.0 Resource Kit, to enable account lockout for remote logons that use the administrator account. When you run the PASSPROP utility with /ADMINLOCKOUT, you make the administrator account subject to lockout policies, except for interactive logons. This way, you protect the administrator account from being attacked over the network.
GartnerGroup recommends renaming the administrator account so that this account is not an obvious target. Although that measure is a nice start, it's not a strategy for success by itself. To keep your system truly secure, you must stay up to date. More than a year ago, a program appeared that demonstrated how to discover a built-in administrator account name with nothing more than access to the target system via NetBIOS over TCP/IP. The program is called RedButton, and it exploits a capability in NT that lets anonymous logon users list domain usernames and enumerate share names. RedButton is one of the many hacker attacks that led to Service Pack 3's (SP3's) nickname of Security Pack 3. Microsoft issued a post-SP2 hotfix called sec-fix, which introduced a new Registry value called HKLM\SYSTEM\CurrentControlSet\Control\LSA: RestrictAnonymous. When you set this Registry value to REG_DWORD 1, you can defeat RedButton; however, there are usability considerations if your environment involves multiple domains and one-way trust relationships.
Take the master domain model, for example. Suppose an administrator in a resource domain tries to add users from a trusted master domain to a local object's access control list (ACL). Because a master domain does not trust resource domains, the administrator cannot use the current account to connect to the master domain controller and retrieve the list of users. By default, NT lets an administrator (and anyone else) log on as an anonymous user account. (For more information about anonymous user accounts, see Microsoft Support Online article Q143474, "Restricting Information Available to Anonymous Logon Users" at http://support.microsoft.com/support/kb/articles/q143/4/74.asp.) By restricting anonymous access, the administrator will either need an account on the master domain, or the master domain must trust the resource domain.
GartnerGroup recommends setting audit policy to log failed logon attempts. This practice is a good idea, but keep in mind the distributed nature of NT security. You can trap failed logons only on the system on which the attempted logons occur, and then only if you enabled the local audit policy. To get a complete picture of failed logons, you must set audit policy on and scan the Security Log of every NT system. However, you still won't know about failed logons that Windows 95 systems or other unknown NT systems, such as an intruder on the Internet, initiate. The LSA2-fix hotfix can improve the situation if you install it on all domain controllers. When you install this hotfix and enable auditing for successful User and Group Management, your domain controllers will log a new 644 event stating User Account Locked Out. You can then scan the Security Logs of all domain controllers to get a complete picture of lockout activity. For more information, see Microsoft Support Online article Q182918, "Account Lockout Event also Stored in Security Event Log on DC" at http://support.microsoft.com/support/kb/articles/q182/9/18.asp.
Problem 3: No Default Auditor Account; Administrators Can Alter Audit Logs
NT's implementation of C2 security doesn't distinguish between an administrator and an auditor. In an ideal system, all administrator and user actions would be logged for later review by an auditor, and no users, including administrators, could cover their tracks by altering the logs. Currently, NT can log administrator actions, but there are several ways administrators can hide those actions. For example, rogue administrators can clear the event logs, effectively covering up actions they want to hide. However, clearing the event logs leaves a trail of evidence. First, an absence of events in the event logs is a situation that invites suspicion. Second, clearing the event logs is an audited event (Event 517 specifies that the event logs were cleared and by whom). In other words, administrators can cover their tracks, but they can't cover up the fact that they covered their tracks. The situation is similar if an administrator turns off auditing.
GartnerGroup recommends creating an auditor account and reducing administrators' scope. Both recommendations will increase your system security. A widely held misconception is that an administrator is all-powerful within a domain and that no way exists to subdivide administrator responsibilities. Most default-configured environments make auditing administrators' actions difficult and often lead to the creation of additional domains to accommodate an organization's systems-administration structure. However, you can achieve a greater granularity of control over domains by creating custom administrative accounts that let administrators maintain effective control without allowing dangerous privileges.
Problem 4: NT Allows Remote Administration
You increase the risk to your system security when you let administrators connect to servers over the network. GartnerGroup therefore recommends a policy of not allowing remote NT administration. However, it's simply not realistic or practical to require administrators to be physically present at each computer they administer. In some circumstances, an administrator's presence is necessary, but I don't agree that allowing remote administration is a serious security risk. If you don't think remote administration is necessary or desirable, remove the Access this computer from the network from the Administrators group.
Problem 5: Poor Audit-Logging Capabilities
GartnerGroup recommends using third-party tools to overcome what the group perceives as a security weakness in NT. However, I don't believe NT's audit-logging capabilities are a problem. In fact, I haven't seen a more flexible and complete operating system (OS) audit component. The Security Reference Monitor, deep in the NT Executive, evaluates access to all objects, regardless of their type (to learn more about the Security Reference Monitor, see Mark Russinovich, "Windows NT Security, Part 1," May 1998 and "Windows NT Security, Part 2," June 1998). The Security Reference Monitor is the single point of control for all object access and the exercise of rights and privileges. The Security Log records events according to criteria the administrator sets. Getting information into the log is easy--the problem is getting the information back out in user-friendly, easy-to-interpret reports. The Event Viewer is not as flexible a report manager as administrators need. Moreover, in the distributed environment of an NT domain, activity is scattered among all member computers. NT has no native way to get a comprehensive view of network activity. Take, for instance, logon activity events. If you want to see all failed logons in your domain, you must look at the Security Log of every server and workstation.
Per GartnerGroup's recommendation, you can use third-party tools that merge the scattered logs of a domain into one database and then provide specialized reports for analyzing categories of security-related activity. You can also use dumpel.exe from the resource kit to convert event logs on remote computers to text files for subsequent merging into an Access database.
Problem 6: Default Guest Account
NT comes with a built-in guest account, and GartnerGroup questions whether this default guest account is necessary. This account lets users who do not have regular accounts log on. The bad news is that the guest account allows anonymous access. However, the guest account is disabled by default in NT Server, mitigating the account's inherent risks.
Problem 7: No Salt in the Password Mix
I suspect GartnerGroup means by no salt that NT doesn't enforce quality password policies. By default, NT has no password requirements. However NT has a rich set of password features that administrators can use to set strong password policies, which GartnerGroup recommends. User Manager's Account policies dialog box contains seven policies, six of which protect passwords. To provide comprehensive password protection, administrators need to use all six policies in well-planned combination. Such a strategy requires attention to three areas: password quality, password change frequency, and online guessing speed.
Password quality. To be secure, a password needs to be difficult for a system intruder to guess. To enhance this difficulty, passwords must be long and draw from a large range of characters. The basic control for password quality is Minimum Password Length, a policy in the Account policies dialog box. In addition, you can use PASSPROP to allow a combination of characters, including upper- and lower-case letters, numbers, and symbols.
NT lets you make your own password rules using a notification package. This is a simple .dll file that you implement; the .dll file must export three standard functions. After you compile the notification package, you tell NT to load it by adding the .dll filename to the NotificationPackages Registry value under HKLM\System\CurrentControlSet\Control\LSA. Then, whenever users change their password, NT calls PasswordFilter() in your .dll file. PasswordFilter() evaluates the password change according to whatever criteria you implemented and returns a value of either true or false. If your notification package returns false, NT rejects the password change, and the user must select another password. For detailed information about implementing notification packages, see Microsoft Support Online article Q151082, "How To: Password Change Filtering & Notification in Windows NT" (http://support.microsoft.com/support/kb/articles/q151/0/82.asp). The article includes source code for a sample notification package.
Change frequency. Users need to change their password regularly for two reasons. First, it is only a matter of time before a determined system intruder will guess even a high-quality password, particularly if the intruder uses a brute force program. The object of frequent password changes is to make user passwords moving targets--you change a password before an attacker has time to work through all the possible permutations. Second, regular password changes limit system exposure when an intruder discovers a password--the intruder can use the account only until the next password change.
To create a password policy that limits the security compromises uncooperative users can introduce, use the Maximum Password Age, Minimum Password Age, and Password Uniqueness policies. For example, if you set uniqueness at 24 (the maximum setting) and Minimum Password Age to at least 1 day, stubborn users must wait 24 days to cycle back to an old password while changing their password every other day. Keep in mind that you must select the User must log on in order to change password check box in the Account policies dialog box to maintain the integrity of Maximum Password Age. For example, if User must log on in order to change password is not activated, a user with an expired password can log on to the system. (A better name for this setting would be User may not change expired passwords.)
Online guessing speed. When an intruder tries to guess a password online, whether interactively or over the network, proper use of Account lockout settings can slow the attack to a crawl. For example, if you configure your system to lock out an account for an hour after three failed logon attempts within 1 hour, attackers can try only two or three passwords per hour, depending on how worried they are about the system reporting lockouts in the Security Log.
The foregoing three areas of password strategy are interconnected. If your policy or user base forces you to be weak in one area, you can compensate in the other areas. For example, if your users are strongly resistant to changing passwords regularly, you can relax the change frequency policy somewhat and compensate with longer lockout duration.
By hardening your systems against network password sniffing and Security Accounts Manager (SAM) attacks (for more information about these intruder strategies, see "Protect Your Passwords") and implementing strong password policies, you can be confident that you have a well-rounded password-protection scheme. For some excellent suggestions about picking the right policy values for your environment, see the password section of "Windows NT Security Guidelines," by Steve Sutton (http://www.trustedsystems.com).
NT and Security
During the past year, I've heard many times that the sky is falling as NT security breaches hit the news. But once the smoke cleared, it became apparent that, although the reported incidents were serious, most security breaches were possible because the intruders had local access to the affected computer or LAN. Microsoft responded to most of the emergencies with hotfixes and SP3. These fixes plug most of the holes, even though the fixes are difficult to deploy and can destabilize some environments. GartnerGroup's conclusion is that Microsoft is not in the security business and responds to security issues only to the degree and manner that fits the company's business model.
I agree that some fundamental OS problems are at the root of Microsoft's security weaknesses. However, I think these problems are much more generic than GartnerGroup's focused List of Seven.
Huge and young OS. As I write on my NT laptop, more lines of code are running on it than on an MVS mainframe. NT 5.0 will soon break the 20 million-lines-of-source-code mark. Couple this figure with the fact that NT is relatively young as large OSs go. Any OS of NT's success and youth will have security holes, and Microsoft's good-enough development methodology only exacerbates those weaknesses.
Fast rate of evolution.NT is changing rapidly. Microsoft originally intended its service pack program to be a quarterly cumulative bug fix leading to constantly increasing stability. However, in reality, each service pack introduces new functionality with new security holes. It's nice to have new functionality at no charge, but service packs aren't increasing OS stability and security.
Backward compatibility with LAN Manager. Here is NT's Achilles' heel: Backward compatibility with LAN Manager made possible some of NT's most notorious security breaches, such as password cracking, sniffing, and Server Message Block (SMB) man-in-the-middle attacks. NT has fairly well designed authentication and password protection techniques. However, NT renders these techniques pointless, because NT's default behavior is to use the corresponding LAN Manager techniques to provide backward compatibility with LAN Manager.
Default configuration is oriented to ease of use--not to security. NT has only one mode of installation, and it is oriented toward connectivity and ease of use. If administrators could install NT for low, medium, or high security, they could greatly reduce the number of steps they must take after installation to increase security.
Low awareness of security and stability among Microsoft developers. Although the situation is changing, it's evident that Microsoft's NT developers are still working from the premise that a single user will use a single dedicated computer. This mindset assumes that if a machine crashes or is compromised, that failure will affect only one user and one computer. The one-user, one-machine scenario used to fit word processors and spreadsheets, but the nature of enterprise computing has changed drastically. At least in situations in which security is concerned, we're not in Kansas anymore.
