Methods of Restricting Registry Access As was already mentioned, Windows GUI was always oriented towards beginners who may need protection from human errors. Starting with Windows 2000, Microsoft began to introduce additional protective measures, practically each of these are also present in Windows XP and products of the Windows Server 2003 family. One such feature is known as "protected operating system files"(which shouldn't be edited, or even seen, by an ordinary user). These files are sometimes called "super hidden". Actually, there's no such attribute. The files simply have a combination of Hidden and System attributes. By default, Windows Explorer doesn't display these files. You may set Hidden and System attributes for the tools that ordinary users should not run, including networking tools, resource kit utilities and, of course, registry editors. Thus, you'll "hide" them from beginners, who may be afraid of command lines such as dir /a. N ote Did you place the Regedit shortcut on the desktop or on the Start menu (just for convenience)? Well, don't forget to remove all such shortcuts, otherwise users will be able to find them with the Search command. Also, don't forget that the Start menu contains the Run command, and setting the Hidden and System attributes won't prevent the user from starting Regedit.exe using this command. Some other methods of preventing users from running potentially dangerous programs include the following approaches:  Removing executable files from users' workstations  Using Software Restriction Policies  Protecting executable files by using file system permissions  Editing access rights to registry keys Removing Executables One of the most common ways to prevent users from running undesirable tools is to remove the executables that you don't want them to run. For example, some authors recommend that one "delete Regedit.exe from all workstations". This, of course, will prevent beginners from running it. But what about convenience? A better solution would be to rename the file and move it to another directory. Of course, if you decide to do so, don't forget where you moved the file and what you named it. Besides this, there are other problems associated with this approach:  First, Windows File Protection (WFP) might make it difficult to remove tools that are considered part of the OS and thus protected. Furthermore, patches, system updates, and additional Windows components might reinstall the removed executable without warning.  Second, savvy users and skilled attackers can still provide their own copies of a tool that you want to restrict, not to mention other unauthorized programs, including software pranks, spyware, and keystroke loggers that could enable them to capture passwords or other sensitive information. This has become a primary concern with the arrival of pocket-sized ultra-portable storage media, such as USB Flash drives, which can hold 8 Mb - 1 GB of data that can be instantly accessed from any PC with a USB port. As was outlined in Chapter 2 , the introduction of these devices into corporate networks offers users a convenient alternative to floppy disks and ZIP drives. At the same time, however, these devices present several security challenges to network administrators. Besides the introduction of harmful software, the threat of data theft is also a possibility. Note that any unattended and unlocked PC with a USB port can become an ideal target for attackers or disgruntled employees. N ote In order to protect one's computer against the risks posed by ultra-portable USB media, several steps can be taken. First of all, you must educate your users and establish a corporate policy for taking data out of the office and bringing files from home. In order to foil attempts at data theft, it is recommended that you configure all workstations to lock automatically when left unattended for a few minutes. Usually this interval is set from 10 to 20 minutes, but for those desktops holding sensitive data the recommended value is 5 minutes or less. Also notice that recently USB Flash drives with built-in security features have become available. Thus, if you don't want to completely eliminate such a device from being used, consider using only secure devices. Finally, you might wish to restrict USB ports on all desktops. Although USB devices can't be managed using Group Policy, you can use third-party tools such as SecureNT (which can be downloaded from http://www.securewave.com/products/securent/secure_nt.html ). This software can control access to all I/O devices such as floppy drives, PDAs, USB external storage, CD-ROM, and many other PnP devices. Using Software Restriction Policies The ability to use Software Restriction Policies is a new feature of Windows XP and Windows Server 2003. Software Restriction Policies provide a completely new method of preventing unauthorized usage of system tools and other potentially dangerous software. It also helps you to restrict users by allowing them to run only approved software, and prevents attackers from using system tools in an attack on the system. When using Software Restriction Policies, the system administrator can choose one of the following two approaches:  Create a policy that prohibits all software, then create unrestricted rules, which allow only approved software to run.  Create a policy that allows all software to run, then create a set of rules which prevents specific programs from running. Software Restriction Policies are based on the following types of rules:  Path - Rules of this type explicitly identify a program path; can be bypassed if the user places a copy of the restricted program in a different location.  Hash - When a program is selected, a cryptographic hash is built. Any attempt to run the program will result in a check of the hash, and the program will be allowed to run or prohibited from doing so according to the policy type. In contrast to the previous type, rules of this type are not so easy to bypass, since the program can reside anywhere, and the action taken will be the same.  Certificate - Rules of this type are built based on the presence of a code publishers' software-signing certificate. Certificate rules apply to scripts and MSI files only. To use them, a code-signing certificate is used to sign the files. Certificate rules are used to identify the code-signing certificates that are valid on this computer or on the computers within the Group Policy Container (GPC) of this GPO.  Internet zone - This option enables the administrator to prevent users from running software from a particular Internet Explorer (IE) zone. However, this type of rule cannot prevent users from running software that has already been downloaded from that zone. To create, examine, or manage local Software Restriction Policies, proceed as follows: 1. Click Start, select Run, and type secpol.msc in the Open field, then click OK, or, alternately, open the Control Panel window, and select Administrative Tools | Local Security Policy. 2. Select the Software Restriction Policies container. If no policy exists, right-click the container, and select the Create New Policies command (Fig. 9.1 ). Figure 9.1: Creating a new Software Restriction Policy N ote To create or manage Software Restriction Polices for a site, domain, or organizational unit (OU), open the Group Policy Object (GPO) for the appropriate container. The Software Restriction Policy container is located under Computer Settings | Security Settings. 3. After you create a new Software Restriction policy, the console window will look as shown in Fig. 9.2 . Enforcement properties include or exclude DLLs and identify whether the policy applies to members of the Administrators group (Fig. 9.3). By default, policies apply to all users and program files except library files such as DLLs. Additional settings include the Designated File Types option (Fig. 9.4) that allows you to edit the list of so-called designated file types, which includes files that by default are considered to be in executable code. Using this option, you can add new file types to that list as well as delete specific files from the list of executables. Finally, the Trusted Publishers option opens the Trusted Publishers Properties window (Fig. 9.5 ), where you can determine whether users, computer administrators, or enterprise administrators can select the trusted publishers of the software. Figure 9.2: Newly created Software Restriction Policies Figure 9.3: The Enforcement Properties window Figure 9.4: The Designated File Types Properties window Figure 9.5: The Trusted Publishers Properties window 4. Using the Software Restriction Policies, you can easily create a policy restricting the use of specific software tools. To do so, you have to determine the list of tools that need to be restricted and the type of rule that will be used. Notice that it is up to you to compose the list of restricted tools (as was already mentioned, this list would normally include various networking tools, resource kit utilities, registry editors, and other potentially dangerous tools). N ote N o t ice that Software Restriction Policy is itself a potentially dangerous tool that can easily allow you to create such a policy that can wreak havoc on your organization by prohibiting users from running applications they really need or even preventing client systems from running. As a result, it is advisable that you first create a test policy using the Local Security Policy MMC snap-in on a standalone workstation running Windows XP, and then test it on a single machine first. Having created the policy, test it by applying it to a single OU that represents a test computer or computers to make sure that the test policy satisfies your requirements without having a negative impact on other software. After that, you can enforce the policy in multiple systems in your production environment. 5. The best way of creating your first software restriction policy is by starting up with all software allowed to run and then creating rules that prevent individual programs from running. To illustrate this approach, let us create a simple Software Restriction Policy that will prevent the following tools from running: o All software located in the D:\Program Files\Resource Kit and E:\Olga\TOOLZ folders o Regedt32.exe and Regedit.exe tools (no matter where registry editors are located) o LC3.exe password-auditing tool (no matter where it is located) o Software on sites included in the IE Restricted Sites security zone o Solitaire game (sol.exe - no matter where it is located) The completed software restriction policy is shown in Fig. 9.6 . Figure 9.6: The completed software restriction policy, which lists the policy type and basic information 6. Since this policy should not restrict administrators, the first step to take is to set the policy so that it will only affect ordinary users. To do so, double-click the Enforcement object at the root of the Software Restriction Policy container. In the resulting window (see Fig. 9.3 ), set the All users except local administrators option, then click OK. 7. Next, create a new rule for each tool that should be restricted. For example, in order to create a new path rule, right-click the Additional Rules container, and select the Create new path rule command from the context menu. The New Path Rule window will open (Fig. 9.7 ). Enter the path (for example, E:\OLGA\TOOLZ), leave the Security level option at Disallowed and click OK. Proceed the same way to create path rules for all the software that you want to restrict using path rules. . Methods of Restricting Registry Access As was already mentioned, Windows GUI was always oriented. the arrival of pocket-sized ultra-portable storage media, such as USB Flash drives, which can hold 8 Mb - 1 GB of data that can be instantly accessed from