Deny-by-Default Software Execution

When a deny-by-default software execution policy is fully implemented, a managed computer will not be able to install or run any software or content (i.e., scripts, macros, ActiveX controls, etc.) not previously approved by the managing administrator. When developing a policy, it helps to understand the potential scope of the policy, the benefits, and the disadvantages.

Scope of Deny-by-Default Software Execution

Ultimately, a good security administrator wants to prevent any unapproved software program, script, macro, and set of instructions from being able to be installed and/or executed. Preventing normal software programs from being installed and executed is a large enough task, but today's interconnected Internet world requires much more. Here are the types of executions a global deny-by-default software policy would prevent if unauthorized:

• Installation and/or execution of normal software programs

• Downloading, installation, or execution of ActiveX controls and other executable content (e.g., Java applet) delivered through the browser

• Execution of scripts, macros, batch files, command files, and instructions

• Modification of existing programs

• Modification of existing data

• Manipulation of the operating system

• Initialization or inappropriate use of approved software

The first two bulleted points should be considered in any software restriction policy. The last point is particularly hard to enforce, but some restriction policies have varying amounts of success. For example, untrusted Java applets cannot manipulate local system resources. And Microsoft's ActiveX framework allows ActiveX controls to be initialized and manipulated only by their authorized parent routine, if so configured. Internet Explorer allows both of these content types to be configured on a per-security-domain basis. An ActiveX control might be allowed to run on any web located in the Trusted sites zone, but be denied execution in the Restricted sites zone. Internet Explorer zones will be covered in more detail in Chapter 10.

Benefits of Preventing Unauthorized Software Execution

Preventing untrusted software execution will prevent most malware programs, including viruses, worms, trojans, and spyware. Antivirus software vendors now report over 100,000 different malware programs. Nearly all would be prevented by implementing a strong software restriction policy. Besides preventing malware, an administrator preventing unauthorized execution can expect the following benefits:

• Higher performance

• Standardized computers

• Less staff support hours

• Less problems overall

• Less illegal licensing issues

Everyone knows that the more programs that are installed the slower the computer functions. Nearly every installed program installs one or more programs in one of Windows' auto-start areas. Fewer installed programs means faster computers, more free CPU cycles for existing programs, and more free hard drive space.

Every IT department support staff person knows that unapproved installed or misconfigured programs account for a large portion of their support calls. A standardized computer with standardized software applications lowers support costs and decreases the number of problems overall, for both the IT admin and the end user. Lastly, when unapproved software programs cannot be installed or executed, it results in less software piracy.

Disadvantages of Preventing Unauthorized Software Execution

If preventing unauthorized software execution has so many benefits why isn't deny-by-default software execution the rule today? Historically, the first issue involved with implementing a policy of this type was that it wasn't easy or inexpensive to do. Until the last few years, in order to implement a software restriction policy, IT had to purchase a third-party commercial program. Today, Windows XP and later computers support it.

The bigger issue is end user acceptance. End users don't like having their computing freedom curtailed. If the company provided them with a car, they would freely accept any terms the company might stipulate around the car, including when they can drive it, where they can drive it, and how they can drive. Put the same sort of restrictions on corporate computer end users for the first time and you're likely to see a lynch mob building for the IT team. When most network administrators are introduced to the concept of stopping all unauthorized software execution, they immediately think of the end user problems and hassles they would face if they implemented such a policy, and then discount it as unworkable. Instead, they prefer to fight security fires as they appear and have their staff deal with found security violations on a case-by-case basis. Having no configured software restriction policy may result in more overall work effort and vulnerabilities, but at least the users are not blaming IT for every program that doesn't work. And when a malware or hacker program does penetrate the less protected computers, the end users blame the hackers or the worm, not IT.

Implementing a software restriction policy requires a lot of up-front work and planning. Going from an environment where any program can be installed and executed to one in which freedom is restricted will absolutely cause a lot of problems — technical and otherwise. Many end users will lose their patience and regret their loss of freedom. It's inconvenient, if nothing else, to have to submit every new software program for IT approval.

Ultimately, it comes down to whether or not management finds great value in controlling which software runs on their owned assets versus the trade-off of employee freedom. Most corporations decide to accept the frequent infection of their computers by malicious software and hackers, but companies that need a higher-than-normal level of security will use a software restriction policy.

Note 

In my 19 years of experience, the corporate entities using a software restriction policy are among the most successful companies in preventing malware and hackers.

It is important to understand that even if your environment cannot implement a total software restriction policy, lessons can be learned and subsequent steps taken to minimize malicious attack.