How worried should you be?
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.