This article can also be found in the Premium Editorial Download "Information Security magazine: Why business managers are a breed of security professional."
Download it now to read this article plus other related content.
2. Restrict Privileges
Enterprises should consider getting serious about limiting the privileges granted to rank-and-file users.
Many organizations still give users local admin privileges. This is dangerous, because most users can be duped into running malicious programs. What's more, if you give users such access, they'll surf the Web and read e-mail with these accounts, likely exposing their systems.
Avoid this problem by assigning users to groups with limited privileges, especially on Windows machines. Assign user accounts to a limited-permission group, either the predefined "Restricted Users" group or a custom group.
However, to pull this configuration off in a Windows environment, security managers will have to alter their operations to support users with limited privileges. These operation changes include the following:
- Making sure clients have remote desktop management, such as Win-dows Remote Desktop, VNC or Dame-ware. This will allow the help desk to troubleshoot systems using administrator privileges.
- Deploying patch management and update control tools, such as Microsoft's Software Update Services (SUS), that let security teams push patches without user involvement.
- Installing by default various necessary browser add-ons, like Acrobat, Flash, Shockwave and QuickTime.
- Ensuring that AV updates can be deployed to desktops even when users
don't have admin rights.
Unfortunately, many older (and even some not-so-old) Windows applications require local admin privileges. Enterprises should test these apps to see which files, directories, registry keys and user rights users need to access, utilizing tools such as Filemon, Reg-mon and Tokenmon (available at www.sysinternals.com). Tweak the ACLs to devise a configuration that allows these resources to be run by users without admin privileges, or consider moving the client to a terminal services environment that you can harden and monitor.
Microsoft's free DropMyRights tool restricts the privileges granted to machines with administrative rights. In-stead of the cumbersome RunAs capability, it lets enter- prises create a shortcut to invoke Internet Explorer, Out-look or any other application with limited rights. Place that shortcut icon on the Start menu, and you have a much safer approach than running them as local admin.
Enterprises should upgrade their desktops to Windows XP SP2, which has far more configuration options and is more resilient to spyware than other Windows versions. It isn't perfect, but XP SP2 provides better isolation of browser security zones and includes Data Execution Prevention, which helps prevent some buffer overflows. A number of the exploits used by spyware simply don't work in XP SP2.
3. Leverage AD
Active Directory shops can utilize Group Policy Objects (GPOs) to fine-tune client systems across the enterprise to thwart spyware that exploits weak configurations.
First, add known spyware and other malicious sites to IE's Restricted Sites zone, which flags sites that could cause damage. Carefully configure this zone so all scripting, ActiveX and download functionalities are disabled.
You can formulate a list of potential spyware sites to populate this zone in a variety of ways. For example, you could use the DNS and host files from Bleeding Snort and Someonewhocares.org as a solid start. Alternatively, download the free Spybot-Search & Destroy tool to a lab system and activate the "Immunize" function, which will automatically populate the local browser's list of restricted sites. You can review and edit those sites in the lab system's browser configuration, which can eventually serve as the template you apply to other machines with GPOs.
Also, using GPOs, you can configure IE to deny all browser add-ons, except those that users actually need (such as Acrobat and QuickTime). You can also prevent users from enabling specific browser add-ons.
Instead of worrying that users will accidentally click "OK" on an installation screen for an ActiveX control, configure all XP SP2 versions of IE via GPOs so that they won't display ActiveX installation prompts at all.
For fine-grained access, Windows machines also support software restriction policies. You can restrict specific programs based on their file system path, digital signature, zone of origin and MD5 hash.
In a highly controlled environment where users need to run only a limited number of programs, software restric-tion policies can be used to enumerate a small number of allowed programs and deny everything else. Lists of known spyware DLLs, EXEs, Browser Helper Objects (BHOs) and other related spyware elements are available at the Spyware Data Web site and are also included in freeware version of Spybot-S&D.
4. Deploy Alternative Browsers
Some enterprises want to avoid the problems of IE altogether, opting to use a competing browser, such as Mozilla's Firefox. However, other browsers have security flaws as well that could lead to the installation of spyware.
If you plan such a transition, don't underestimate the cost of the change. Test your apps carefully to make sure they work in non-IE browsers. Many supposedly "browser-independent" Web apps crash and burn when rendered in non-IE environments, making for some expensive redevelopment work.
A few private enterprises and government agencies have implemented a two-browser solution, using Firefox for routine Web surfing with a more restrictive environment for IE. In this scenario, using GPOs, IE uses a specific Web proxy with draconian rules that limit access to only certain Web sites running those IE-specific applications with a defined business need. The main Web page of internal business apps would include a link that invokes IE, loading the appropriate start page. In a sense, IE is restricted via the proxy to a limited number of trusted sites.
Or, if you can move entirely off of IE, you can define the GPO setting for "Don't run specified Windows appli-cations." Add "iexplore.exe" to this list to prevent users from launching IE. In case your users mysteriously squirm around that setting, you could again use GPO to change the default home page for IE to an internal Web site that tells your users not to run IE and points them to the preferred alternative browser.
This was first published in June 2005