After you have an inventory of the applications used on your network, you need to figure out how to run them using the least user access (LUA). Putting it another way, user applications should not require the user to be an administrator. Many applications will work just fine as non-administrator. For instance, if you only have the most recent version of Microsoft Office, maybe WinZip and Acrobat, you can almost certainly run those applications as a regular user. Throw older applications or more obscure ones into the mix and the answer is not so clear any more.
The need to run things as LUA is clear. If an exploit enters through an application, it has whatever access to the system that the user running the application has. As an example, take the case of spyware. While on one of our innumerable world speaking tours in 2004, one of the authors got a phone call from his wife complaining about a home computer acting up. The culprit seemed to be spyware installed on the computer. When we got home, both of us installed a couple of spyware detection tools and ran them to see how bad off we were. The following week, while on yet another continent , we compared notes. The one of us who got the call had found 162 separate pieces of spyware on the system. The other author? Zero. The difference? One of us gave in to domestic pressure and made the family (or at least some of it) administrators. The other is the bastard operator from hell (BOFH) and did not. (Of course, one of us was now able to act the hero while the other is still considered a mean bastard.) The lesson is clear, however: if software is not running as an admin, the damage it can do is significantly less.
Start out your quest for nonadmin with your inventory of software. Then designate a few guinea pigs to run them as LUA. These should probably be relatively technical people who can give good feedback on what breaks. Make them nonadmins and watch what happens. If things break, follow the procedure we lay out in Chapter 14, "Protecting Services and Server Applications," for how to unlock the system sufficiently to run these applications as nonadministrators. In many cases, you will find that with relatively few tweaks you can make the applications function perfectly fine without having to make users admins. Before you embark on this, however, you need to get manager approval and executive buyoff. Getting such buyoff is an entirely different story, however. Both of us went into IT primarily to avoid having to deal with people, so we are not experts at this by any stretch of the imagination . However, in Chapter 5, "Educating Those Pesky Users," we provide some hints based on things we have learned that work when dealing with users and management.