Windows Security in the era of Windows 7 ®
An FUSD Perspective    

A Brief History of Windows Security

Revised Local Administrator model for FUSD

Delegation in Systems Center Configuration Manager (SCCM)

Summary

A Brief History of Windows Security

Windows 7 has finally eliminated a long standing security vulnerability within Windows XP and NT that has existed for "centuries" in web-time (about 10 years.) This improvement should result in significant productivity improvements for Enterprise IT staff everywhere. Although most people never followed the 'best practice' account setup recommendations from Microsoft for Windows XP--even those who knew better--everyone really should have. If everyone had done so, the result would have been a world with dramatically less malware sloshing through both users' computers and the Internet. Antivirus companies wouldn't have a billion dollar market niche, you wouldn't see those "speed up your PC now!" commercials on late night TV, Apple would have to come up with new material for their commercials, and global IT-based productivity would have been a lot higher over the last decade.

What was this best practice? It had to do with a very simple issue: how you login to your computer for day-to-day work. The most secure way to use Windows XP was to have, at a minimum, two accounts: one, the "Administrator" account, that had full privilege to the machine to allow software to be installed and system changes to be made, and the second, a "user" account, with "standard" privileges, with which one did day-to-day work. The "Administrator" account was only to be used at those infrequent times when one was installing a new device or a new software package.

For system administrators, the rationale behind enforcing this practice was that you didn't want your users to do all of their daily work using an "Administrator" level privileged account. That is, if you, the user, always did your "work" as a normally-privileged user, malware would have less of a means to gain a foothold and take control of your computer (and spread across the network to other computers, a Rolaids® swigging moment for your network administrators.)

Of course, doing things this way was a major inconvenience: people didn't want to have to log off, log on as an Administrator, do some software or peripheral installation task, log off again, and then log back in as a standard user. Especially when it took 20-30 seconds for each logoff/logon. So naturally, people decided to just assign their day-to-day user account full Administrator privileges, so as not to be bothered with all of the account switching back-and-forth, and go on their merry way. Of course, Microsoft didn't make it easy, at least until recent years, to quickly switch to "Administrator" context from a standard user account, so most people took the path of least resistance. And malware, of course, went on its merry way, infecting millions of computers as a result.

In a large enterprise IT environments, out of a desire to contain the malware side effects of this practice, it became common practice to "lock down" managed Windows XP computers, and deny ordinary users the ability to login as an Administrator-level user. This made life for the system administrators much easier -- fewer "virus spill in aisle 9, bring your mop" calls to deal with. But it also made life more difficult for the user population, who now could not install software or add peripherals without an IT staff member assisting. This model of "Administrator user lock down" does not scale at all well for large enterprises, because it places a heavy burden on IT support, particularly in an environment that lacks remote assistance technology. At FUSD, with computer to technician ratios exceeding 1000:1, it creates massive service bottlenecks, with or without remote assistance tools.

With Vista and Windows 7, the execution model is different than it is in Windows XP from a security standpoint. In Windows XP, if your user account was configured an "Administrator", then you ran all of your programs, all day long, as a highly-privileged user (including when you clicked those email links that make your IT staff cringe.) That presented lots of opportunities for malware to "leak" into your computer undetected.

In Windows 7, by contrast, even if your user account has been granted elevated "Administrator" privileges, you still run day-to-day programs as a standard user, only switching to "Administrator" on demand, e.g. to install software or make some significant system change. When you run something that requires elevated rights, a window pops up on your screen, and you can only click "OK, proceed" from the local keyboard (In Windows 7, "OK" can't be clicked by remote control, which helps to prevent malware attacking your computer across the network from elevating its own privileges without your knowledge.)

This is the reason for those "security popups" that Apple's marketing campaign took amusing aim at in its negative TV commercials against windows Vista. It is a great idea, in concept: alert the user anytime a "significant" change is being made to the computer, so that the user is aware of the change and has the ability to reject unexpected changes made maliciously.

With Windows Vista, however, the default settings were too "sensitive", with the result that security popups were appearing much too frequently for comfort. What should have been a welcome security improvement became viewed as a major annoyance and distraction (and great fodder for Apple.) In later revisions of Vista, and in Windows 7, the "noisiness" was dialed down to a more acceptable level, and there are now far fewer such security prompts.

With Windows 7, one can therefore "unlock" the desktop in an Enterprise environment, relax the draconian policies, and allow the user to have "Administrator" rights to his or her own PC, without running at an unreasonably elevated risk level. It is still true that users may make changes to their computers that IT Staff would rather they did not, and they can still ignore the security popup after clicking on a suspicious link in their email, but at least a reasonable balance can be struck between providing a more friendly "unfettered" user experience and implementing a stringent lock down policy that causes productivity to fall and support costs to skyrocket. Although there are still vulnerabilities, the balance results in significant reductions in time lost to battling virus outbreaks, but the remaining malware cleanup work must be weighed against higher user productivity that results from users having more control over their own workstations.

Revised Local Administrator model for FUSD

The new Local Administrator model for FUSD, which is made possible with Windows 7, is summarized as follows:

• All computers belonging to the District must be domain joined. This is the cornerstone to central management.
• All local user accounts with Administrative privileges (and arguably, ALL local user accounts) should be deleted on domain joined PCs*, and only Domain credentials should be used (certain Servers may be exempted.)

  This practice:

1. Eliminates "anonymity" and makes it possible to audit who actually did what as a privileged user. If the log files only say "User Administrator performed the following action at <timestamp>" its impossible to know who was logged on as the Administrator and who actually did the deed.
2. Allows a password complexity/expiration policy to be enforced.
3. Removes a vector for malware to spread easily between machines that have the same username\password combinations for local user accounts.
4. Allows Enterprise-wide revocation of access when an employee leaves, and his or her account is disabled in Active Directory.
5. Can be implemented easily through Active Directory Group Policy using Restricted Groups.
6. Allows Credential cache expiry to be controlled through GP, which can remove easy access to disabled or unauthorized users after a certain period of time has elapsed without the computer "checking in" with Active Directory (the current setting is 30 days.)

* Caveat: in our current environment, some users login to their PCs every day with the username "Adminstrator", "Teacher", "Student", or some other local account name instead of using Domain Credentials. The desktop profiles for these users need to be migrated to their domain user profiles before the local account is deleted, so that their personal files are not lost.

• The Builtin\Administrators group on domain-joined PCs should contain an AD Security Group whose members are to be assigned Local Administrator rights to the PCs in specific Organizational Units (OUs). (These groups have already been built.)

  For instance, suppose that there are both Staff and Student computers at Addams Elementary. Then the AD Group "Addams Local Administrators" is included by Group Policy in Builtin\Administrators group for all machines at Addams Elementary in either the STAFF or STUDENTS domain, so that a member of this AD group has administrative rights to all of these PCs.

• The domain login for the user who "owns" the PC should be added to the Builtin\Administrators group.

This allows the user to install software and peripherals as desired on his or her computer, which improves user experiences and reduces unnecessary support calls. This privilege could, of course, be remotely "revoked" for non-compliant users who deliberately and repeatedly ignore anti-malware recommendations (clicking willy-nilly on links in suspicious emails, visiting tainted web sites, etc.)

Delegation in Systems Center Configuration Manager (SCCM)

The system of AD Groups that have been created to support this new Local Admin model (example: "Addams Local Admins") can also be used to assign IT staff delegated rights to groups of computers in SCCM (whether the computers are grouped by OU, or by some other grouping method.)

As mentioned earlier, placing IT staff in these AD Groups makes it very easy to revoke privileges from users who should no longer have the ability to administer FUSD computers, and it allows rights to be "managed" so that service personnel only have unrestricted access to computers at certain sites, instead of providing them with difficult-to-revoke access to all computers everywhere, as is the current practice in that it relies on the use of a "standard" Administrator account that all support staff (and most tech savvy students) know.

The existence of this "micros" account is also exploited by malware to rapidly spread between sites, because it too has a time-invariant password that does not meet complexity requirements and confers Administrative rights to the account.

Summary

Microsoft made a wise decision to study the habits of its users, the vulnerabilities of its OS products, and the techniques used by malware writers, and to then modify the ways in which it handles privilege escalation in Windows 7 based upon the lessons it found. Looking back a decade from now, we may be able to say "Windows 7: that was the decision that changed everything for us, and made the Internet safer to use and our IT infrastructure easier to support."