Developing a Software Restriction Policy

Implementing a software restriction policy involves several steps:

1. Get management's approval.

2. Decide on a default policy: deny-by-default or deny-specific software.

3. Decide which restriction methods to use.

4. Create a list of approved applications and publish to end users.

5. Publish and communicate the process of how applications get approved.

6. Review (and approve, if appropriate) new applications in a timely manner.

7. Communicate the software restriction policy to end users, including why it is needed.

8. Conduct a large testing phase to ensure rollout goes as planned.

9. Prepare IT support resources and staff accordingly for go-live.

10. Implement the software restriction policy.

11. Report successes and failures.

12. Adjust the software restriction policy as needed.

Besides appropriate planning and testing, the most important factor is to be responsive to end-user complaints and requests for new software installs. If you can minimize disruption and respond quickly to the resulting issues, a lot of end-user angst can be avoided.

A list of approved software must be created and communicated to management and end users. To create the list, begin by surveying computers for installed software. Ask the users what software is necessary to perform their job. Then create a list of approved software and ask management to approve it. Let management know that new software will need to be approved by end-user management and IT prior to its inclusion on the approved list. Record the default software folders and executables needed for each approved software program. Don't forget ancillary programs such as Adobe Acrobat Reader and Macromedia's Flash, which users might not think of but are probably installed and used on most systems.

Another key point to decide is whether the software restriction policy will prevent all unapproved software from running (i.e., deny-by-default policy) or whether you should just try to stop particular software from running. The latter policy is easier to implement initially, but doesn't have the security payback that the former stance does. With that said, some companies simply cannot implement the deny-by-default rule, even though it's better. End users would revolt and management won't approve it. Table 9-1 shows a list of executables that one company chose to block specifically instead of using a deny-by-default rule.

Table 9-1

Executable to Block	Software Program
Azureus*.exe	Azureus
Bitcomet.exe	BitComet
Bittornado*.exe	Bit Tornado
Blubstersetup.exe	Blubster
Bsinstall.exe	Bearshare
Bsliteinstall.exe	Bearshare
Cabos*.msi	Cabos
Dietk*.exe	Dietk
Edonkey.exe	EDonkey 2000
Grokster_installer.exe	Grokster
Imeshlight455re.exe	Imesh Client
Install_zultrax.exe	Zultrax
Kazaa_Setup.exe	Kazaa P2P File Sharing
Kutepp*.exe	KlRun
Limwirewin.exe	Limewire
Moodampinstaller.exe	Moodamp
Morpheous.exe	Morpheous
Mynap343.exe	MyNapster
P2psetup.exe	P2P Networking
Peanuts10.exe	Peanuts
Setupneonapster.exe	NeoNapster
Shareaza.exe	Sharea2a
Swappersetup.exe	Swapper
Winmx*.exe	Winmx
Xolox.exe	Xolox
Thanks to Chip Bendle for his personal block list.

The list contains many popular programs that are considered high risk or that install unwanted programs and spyware. Unfortunately, specific block lists (aka black lists) are difficult to maintain. The amount of unwanted software keeps increasing every day and a simple name change or update would allow the newer executable by. That's why, whenever possible, implement a deny-by-default (i.e., white-list) strategy.