Ease Security Headaches

Balance your policies against usability and flexibility

Executive Summary: Security administrators should integrate security into their system or application design rather than letting it be an afterthought that is difficult to implement later on. This article reviews some common security aggravations—such as ad-hoc wireless networks, Internet Explorer’s password AutoComplete feature, UAC improvements, third-party application updates, and application virtualization—and offers suggestions for how to handle them.

Many users, and even some IT administrators, would rather not have to deal with security. But like it or not, security is becoming more important than ever in today’s compliance-focused companies. Let’s review some common security aggravations and learn how to handle them.

Ad Hoc Wireless Networks

By default, Windows Vista and Windows XP can connect to different types of wireless networks. Infrastructure networks are networks in which computers are connected to a wireless router; this is the most common type of network. Ad hoc networks, which are set up to provide a quick and temporary wireless network for collaboration purposes, have computers directly connected to one another rather than via a router.

Because no special hardware is necessary to set up an ad hoc network, a hacker with only a laptop and a wireless network card can easily create an ad hoc network in a public place (e.g., a coffee shop) and give the network a name that’s similar to an official infrastructure wireless network, thus luring users into connecting to the ad hoc network. This type of social engineering is effective because despite Vista’s shield logo that alerts users to ad hoc networks, many users will still take advantage of a free Wi-Fi connection.

You can use Group Policy to remove the ability to connect to ad hoc networks. If you don’t have an Active Directory (AD) domain, you can use Netsh from the command line as follows:

1. Log on to Vista.

2. From the Start menu, enter cmd in the Start Search box and press Ctrl+Shift+Enter. Enter your administrator credentials to start the command-line session.

3. Run the following command: netsh wlan add filter permission=denyall networktype=adhoc

4. To check whether the filter was added successfully, run the following command: netsh wlan show filters

5. Under Block list on the system (user), the text SSID: “”, Type: Adhoc will display.

Windows Server 2008 and Vista Group Policy added support for controlling connection to ad hoc networks. You can back-port this functionality to Windows Server 2003 and Windows XP SP3 by updating the AD schema. For information about applying this update, go to TechNet’s “Active Directory Schema Extensions for Windows Vista Wireless and Wired Group Policy Enhancements” website (technet.microsoft.com/en-gb/library/bb727029.aspx). To use Group Policy to restrict ad hoc networks in Server 2008, follow these steps:

1. Log on to a Server 2008 DC as domain administrator.

2. Open Group Policy Management Console (GPMC) from the Administrative Tools menu.

3. Expand the forest, Domains folder, and domain.

4. Right-click Group Policy Objects and select New from the menu to create a new Group Policy Object (GPO). Name it “Wireless” and click OK.

5. Make sure that the Group Policy Objects container is selected in the left-hand pane, then right-click the “Wireless” GPO on the Contents tab and select Edit from the menu.

6. In Group Policy Management Editor, select Policies, Windows Settings, Security Settings under Computer Configuration.

7. Right-click Wireless Network (IEEE 802.11) Policies and select Create A New Windows Vista Policy from the menu.

8. In the Properties dialog box for the new policy, select the General tab and give the policy a name and description.

9. Select the Network Permissions tab, then select the Prevent connections to ad hoc networks check box. Click OK.

10. Close the Group Policy Management Editor window. In GPMC, link the “Wireless” GPO to the desired domain, site, or organizational unit (OU).

Password AutoComplete

Internet Explorer’s (IE’s) AutoComplete feature, which can “remember” usernames and passwords, seems attractive. However, IE’s AutoComplete or “remember me” functionality, which is often built in to web applications, has two major caveats. First, web browsers are notoriously insecure and are common targets for data and ID theft. Allowing IE (or any browser) to store your passwords increases the risk that your electronic ID(s) could be compromised. Second, users who rely on IE’s AutoComplete feature will run into problems if they move from one machine to another but can’t recall the multiple passwords that IE stored for them. This problem might not affect you if your organization uses roaming profiles. But for small shops, AutoComplete is not only a potential security risk but also a major annoyance, often resulting in time-consuming calls to the Help desk for logon assistance.

Fortunately a simple solution exists for IE’s AutoComplete “feature.” You can configure Group Policy to prevent IE from prompting for AutoComplete of forms and from storing passwords. Under User Configuration, Administrative Templates, Internet Explorer, set the Do not allow AutoComplete to save passwords option to Enabled.

Continue on Page 2

For websites with built-in “remember me” features, you must disable the ability to store cookies. You can edit Group Policy to configure IE’s privacy settings to block all first- and third-party cookies, permitting only session cookies. Under User Configuration, Windows Settings, Internet Explorer Maintenance, Security, set cookie handling as part of the Security Zone and Content Ratings configuration. Importing the security zone settings of the machine in use as a baseline configuration will include any cookie-handling configuration that was set on the Internet Options Control Panel applet’s Privacy tab.

Restricting all first-party cookies might limit some web applications’ functionality. To work around this problem, you can click the Sites button on the Privacy tab and enable the Per Site Privacy Actions option.

UAC Improvements

Because Vista’s User Account Control (UAC) implementation has caused such frustration, many IT administrators have disabled it. However, certain features such as file and registry virtualization and IE’s Protected Mode depend on UAC being enabled. Vista SP1’s UAC has some key improvements to let both home and enterprise users take advantage of its benefits.

First, the number of UAC prompts for creating or renaming files is reduced from four in Vista to one in Vista SP1. Another problem is that when you use Remote Assistance in Vista, if the person providing help needs to enter credentials on a UAC prompt, Secure Desktop doesn’t display in the Remote Assistance window. A new Group Policy setting in Vista SP1 lets User Interface Access (UIA) applications running from secure locations bypass Secure Desktop, essentially allowing remote administrators to enter elevated credentials on the user’s behalf. To access this setting, select Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, Security Options from Vista SP1’s Group Policy. The setting is called User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop. Despite introducing a security risk, allowing UIA applications to bypass Secure Desktop is preferable to disabling Secure Desktop completely for the sake of one application.

Vista SP1’s UAC improvements might seem minor. However, the additional Group Policy settings let you configure UAC to behave in a manner that’s suitable for users’ needs without completely disabling this valuable feature.

Updating Third-Party Applications

Windows has great built-in patch management in the form of Microsoft Update and Windows Server Update Services (WSUS). However, third-party client applications (e.g., Adobe Flash Player, RealNetworks RealPlayer) can introduce significant security risks if they aren’t kept up-to-date. Some programs have auto-update capabilities, but many don’t. Therefore, keeping such programs patched across a network is difficult without using a third-party tool.

You can use Group Policy software distribution to install patches and updates, but this solution isn’t ideal because it has almost no reporting facilities. In addition, you must distribute everything as a Windows Installer package (i.e., .msi file). Repackaging installer routines is time consuming if an .msi file isn’t supplied by the vendor.

For midsized and large organizations, System Center Essentials (SCE) and Microsoft System Center Configuration Manager (SCCM) hook into Windows Update and let you distribute software and patches without having to repackage into MSI format. Small organizations have more limited third-party options.

Application Virtualization

The more you secure a system, the less flexible it becomes. Security inevitably means a trade-off in usability for end users, as well as convenience for systems administrators. New application virtualization technologies can help secure host OSs by letting you run applications on demand without adversely affecting the host system’s security and configuration.

Developers and administrators have been using virtual machines (VMs) for a long time to test software. The use of desktop VMs, however, has been hindered by the need to license a second copy of an OS, as well as the lack of integration with the host environment.

Vista Enterprise was the first Microsoft OS release that includes a license to run as many as four additional copies of the OS in a VM. Further blurring the division between VM and desktop, the latest incarnations of VMware Workstation and VMware Player include the Unity view, which lets an application running inside a VM appear in a window as if it’s running on the host system. Although this solution doesn’t provide a fully seamless experience, you can configure applications to access the host’s drives so that you can work with the application as if it’s running locally.

Microsoft’s Application Virtualization (App-V) technology goes a step further and provides a completely seamless experience to the end user, with the ability to stream applications from an App-V server to users on demand and deploy those applications without any special privileges. App-V’s SystemGuard technology sandboxes changes made to the registry, file system, and other resources and captures requests between the application and the virtualized components. SystemGuard isolates applications from one another, and no system-level changes are made to the host system.

App-V opens up the possibility of installing many applications side-by-side without having to worry about potential conflicts. In addition, App-V reduces the severity of any security flaws introduced to the host system. Application virtualization will be increasingly important; ideally, a future version of Windows will include App-V technology to provide an integrated application virtualization layer.

Plan for Security

You need to include security as part of your system or application design from the beginning. Too often, security is simply an afterthought that becomes difficult to implement once a system is in place. Deploy single sign-on (SSO) technologies wherever possible so that users can use one set of credentials to access corporate systems. You should balance the need for security against usability and flexibility, because if security becomes too complicated users will find ways to circumvent it.

Russell Smith

([email protected]) is an independent IT consultant. He has been working in IT since 2000, specializing in systems management and security.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.