Share via

Understanding AppLocker Policy Design Decisions

  • Article

Applies To: Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012

This topic for the IT professional lists the design questions, possible answers, and ramifications of the decisions when planning a deployment of application control policies by using AppLocker within a Windows operating system environment.

Before you begin the design and planning process, you should understand the ramifications of your design choices. The resulting decisions will affect your policy deployment scheme and subsequent application control policy maintenance.

You should consider using AppLocker as part of your organization's application control policies if all the following are true:

  • You have deployed or plan to deploy Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7 in your organization. For specific operating system version requirements, see Requirements to Use AppLocker.

  • You need improved control over the access to your organization's applications and the data it accesses.

  • The number of applications in your organization is known and manageable.

  • You have resources to test policies against the organization's requirements.

  • You have resources to involve Help Desk or to build a self-help process for end-user application access issues.

  • The group's requirements for productivity, manageability, and security can be controlled by restrictive policies.

The following questions are not in priority or sequential order but should be considered as appropriate to your targeted environment for deploying application control policies.

Which applications do you need to control in your organization?

You might need to control a limited number of applications because they access sensitive data, or you might have to exclude all applications except those sanctioned for business purposes. There might be certain business groups that require strict control and others that promote independent application usage.

Possible answers Design considerations

Control all applications

AppLocker policies control applications by creating an allowed list of applications by file type. Exceptions are also possible. AppLocker policies can only be applied to applications installed on computers running Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7. For specific operating system version requirements, see Requirements to Use AppLocker If versions of Windows operating systems earlier than Windows Server 2008 R2 or Windows 7 are deployed, you can use Software Restriction Policies (SRP) with AppLocker.

Control specific applications

When you create AppLocker rules, a list of allowed applications is created. All applications on that list will be allowed to run (except those on the exception list) and those not on the list will be prevented from running. AppLocker policies can only be applied to applications installed on computers running Windows Server 2012, Windows Server 2008 R2, Windows 8 or Windows 7. For specific operating system version requirements, see Requirements to Use AppLocker.

Control only classic apps, only Windows 8 apps, or both

AppLocker policies control applications by creating an allowed list of applications by file type. Because Windows 8 apps are categorized under the Publisher condition, desktop and Windows 8 apps can be controlled together. AppLocker policies for Windows 8 apps can only be applied to applications installed on computers running Windows Server 2012 or Windows 8, but desktop applications can be controlled with AppLocker on Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7. The rules you currently have configured for classic desktop applications can remain, and you can create new ones for Windows 8 apps.

For a comparison of desktop applications and Windows 8 apps, see Comparing classic desktop applications and Windows 8 apps for AppLocker policy design decisions in this section.

Control applications by business group and user

Similar to SRP, AppLocker policies can be applied through a Group Policy Object (GPO) to computer objects within an organizational unit (OU). Individual AppLocker rules can be applied to individual users or groups of users. SRP policies can be used without modification for Windows operating systems earlier than Windows Server 2008 R2 and Windows 7, but there are special considerations when they are used in the same GPO as AppLocker policies.

Control applications by computer, not user

AppLocker is a computer-based policy implementation. If your domain or site organizational structure is not based on a logical user structure, such as an OU, then you might want to set up that structure before you begin your AppLocker planning. Otherwise, you will have to identify users, their computers, and their application access requirements.

Understand application usage but no need to control any applications yet

AppLocker policies can be set to audit application usage to help you track which applications are used in your organization. You can then use the AppLocker event log in the future to create AppLocker policies.
Important
The following list contains files or types of files that cannot be managed by AppLocker:

  • AppLocker does not protect against running 16-bit DOS binaries in a NT Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or higher when there is already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the Executable rule collection for NTVDM.exe.

  • You cannot use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32 subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem. For more information, see Disabling the POSIX Subsystem.

  • AppLocker can only control VBSCRIPT, JScript, .bat files, .cmd files and Windows PowerShell scripts. It does not control all interpreted code that runs within a host process, for example Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (*.bat) run within the context of the Windows Command Host (cmd.exe). To control interpreted code using AppLocker, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision returned by AppLocker. Not all host processes call into AppLocker and, therefore, AppLocker cannot control every kind of interpreted code such as Microsoft Office macros.

    Important
    You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.

  • AppLocker rules either allow or prevent an application from launching. AppLocker does not control the behavior of applications after they are launched. Applications could contain flags passed to functions which signal AppLocker to circumvent the rules and allow another exe or dll to be loaded. In practice, an application that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must follow a process that best suits your needs to thoroughly vet each application before allowing them to run using AppLocker rules.

    For more information, see Security Considerations for AppLocker.

Comparing classic desktop applications and Windows 8 apps for AppLocker policy design decisions

AppLocker policies for Windows 8 apps can only be applied to applications that are installed on computers running Windows Server 2012 or Windows 8, but desktop applications can be controlled on Windows Server 2012, Windows Server 2008 R2, Windows 8, and Windows 7. The rules for desktop applications and Windows 8 apps can be enforced together. The differences you should consider for Windows 8 apps are:

  • All Windows 8 apps can be installed by a standard user, whereas a number of classic desktop applications require administrative privileges to install. So in an environment where most of the users are standard users, you might not need numerous Exe rules, but you might want more explicit policies for Packaged apps.

  • Desktop applications can be written to change the system state if they run with administrative privileges. Most Windows 8 apps cannot change the system state because they run with limited privileges. When you design your AppLocker policies, it is important to understand whether an app that you are allowing can make system-wide changes.

  • Windows 8 apps can be acquired through the Microsoft AppStore, or they can be side-loaded through Windows PowerShell cmdlets. A special Enterprise license is required if you use Windows PowerShell cmdlets to acquire Windows 8 apps. Desktop applications can be acquired through traditional means, such as software vendors or retail distribution.

AppLocker controls Windows 8 apps and desktop applications by using different rule collections. You have the choice to control the Windows 8 app, the desktop application, or both.

For more information, see Packaged apps and Packaged app installer rules in AppLocker.

How do you currently control application usage in your organization?

Most organizations have evolved application control policies and methods over time. With heightened security concerns and an emphasis on tighter IT control over desktop use, your organization might decide to consolidate application control practices or design a comprehensive application control scheme. AppLocker includes improvements over SRP in the architecture and management of application control policies.

Possible answers Design considerations

Security polices (locally set or through Group Policy)

Using AppLocker will require increased effort in planning to create correct policies but will result in a simpler distribution method.

Specific SRP polices

Using AppLocker will require rewriting SRP rules for computers running Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7 but existing SRP rules can remain in place for earlier versions of Windows operating systems.

Non-Microsoft application control software

Using AppLocker will require a complete application control policy evaluation and implementation.

Managed usage by group or OU

Using AppLocker will require a complete application control policy evaluation and implementation.

Authorization Manager or other role-based access technologies

Using AppLocker will require a complete application control policy evaluation and implementation.

Other

Using AppLocker will require a complete application control policy evaluation and implementation.

What are the desktop and server Windows operating systems in your organization?

If your organization supports multiple Windows operating systems, application control policy planning becomes more complex. Your initial design decisions should consider the security and management priorities of applications installed on each version of the operating system.

Possible answers Design considerations

Your organization's computers are running a combination of the following operating systems:

  • Windows 8

  • Windows 7

  • Windows Vista

  • Windows XP

  • Windows Server 2012

  • Windows Server 2008 R2

  • Windows Server 2008

  • Windows Server 2003

AppLocker rules are only applied to computers running Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7, but SRP rules can be applied to all versions of Windows beginning with Windows XP and Windows Server 2003. For specific operating system version requirements, see Requirements to Use AppLocker

Note
If you are using the Basic User security level as assigned in SRP, those privileges are not supported on computers running Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7.

AppLocker policies as applied through a GPO take precedence over SRP policies in the same or linked GPO. SRP policies can be created and maintained the same way as in earlier versions on computers running Windows Server 2012 or Windows 8.

Your organization's computers are running only the following operating systems:

  • Windows Server 2012

  • Windows Server 2008 R2

  • Windows 8

  • Windows 7

Use AppLocker to create your application control policies.

Are there specific groups in your organization that need customized application control policies?

Most business groups or departments have specific security requirements pertaining to data access and the applications used to access that data. You should consider the scope of the project for each group and the priorities to deploy application control policies for the entire organization.

Possible answers Design considerations

Yes

For each group, you will need to create a list of these groups along with their application control requirements. Although this may increase the planning time, it will most likely result in a more effective deployment.

If your GPO structure is not currently configured so that you can apply different policies to specific groups, you can alternatively apply AppLocker rules in a GPO to specific user groups.

No

AppLocker policies can be applied globally to applications that are installed on computers running Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7. Depending on the number of applications to control, managing all the rules and exceptions might be challenging.

Does your IT department have resources to analyze application usage, design policies, and manage policies?

The time and resources available to you to perform the research and analysis can affect both the detail of your plan and processes for continuing policy management and maintenance.

Possible answers Design considerations

Yes

Invest the time to analyze your organization's application control requirements and plan a complete deployment that uses as simply constructed rules as possible.

No

Consider a focused and phased deployment for specific groups by using a small number of rules. As you apply controls to applications in a specific group, learn from that deployment to plan your next deployment.

Does your organization have help desk support?

Preventing your users from accessing known, deployed, or personal applications will cause an increase in end-user support initially. It will be necessary to address the various support issues in your organization so security policies are followed and business workflow is not hampered.

Possible answers Design considerations

Yes

Involve the support department early on in the planning phase because your users may inadvertently be blocked from using their applications, or they may seek exceptions to use specific applications.

No

Invest time in developing online support processes and documentation before deployment.

Do you know what applications require restrictive policies?

Any successful application control policy implementation is based upon your knowledge and understanding of application usage within the organization or business group. In addition, the application control design is dependent upon the security requirements for data and the applications that access that data.

Possible answers Design considerations

Yes

You should determine the application control priorities for a business group and then attempt to design the simplest scheme for application control policies.

No

You will have to perform an audit and requirements gathering project to discover the application usage. AppLocker provides the means to deploy policies in Audit only mode, and tools to view the event logs.

How do you deploy or sanction applications (upgrade or new) in your organization?

Any successful application control policy implementation is based upon your knowledge and understanding of application usage within the organization or business group. In addition, the application control design is dependent upon the security requirements for data and the applications that access that data. Understanding the upgrade and deployment policy will help shape the construction of the application control policies.

Possible answers Design considerations

Ad hoc

You will need to gather requirements from each group. Some groups might want unrestricted access or installation, while other groups might want strict controls.

Strict written policy or guidelines to follow

You will need to develop AppLocker rules that reflect those policies, and then test and maintain the rules.

No process in place

You will need to determine if you have the resources to develop an application control policy, and for what groups.

Does your organization already have SRP deployed?

Although SRP and AppLocker have the same goal, AppLocker is a major revision of SRP.

Possible answers Design considerations

Yes

You cannot use AppLocker to manage SRP settings, but you can use SRP to manage application control policies on computers running Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7. In addition, if AppLocker and SRP settings are configured in the same GPO, only the AppLocker settings will be enforced on computers running Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7. For specific operating system version requirements, see Requirements to Use AppLocker.

Note
If you are using the Basic User security level as assigned in SRP, those privileges are not supported on computers running Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7.

No

AppLocker-configured policies can only be applied to computers running Windows Server 2012, Windows Server 2008 R2, Windows 8 or Windows 7, but SRP is also available on these operating systems.

What are your organization's priorities when implementing application control policies?

Some organizations will benefit from application control policies as shown by an increase in productivity or conformance, while others will be hindered in performing their duties. Prioritize these aspects for each group to allow you to evaluate the effectiveness of AppLocker.

Possible answers Design considerations

Productivity: The organization assures that tools work and required applications can be installed

To meet innovation and productivity goals, some groups require the ability to install and run a variety of software from different sources, including software that they developed. Therefore, if innovation and productivity is a high priority, managing application control policies through an allowed list might be time consuming and an impediment to progress.

Management: The organization is aware of and controls the applications it supports

In some business groups, application usage can be managed from a central point of control. AppLocker policies can be built into a GPO for that purpose. This does shift the burden of application access to the IT department but it also has the benefit of controlling the number of applications that can be run and controlling the versioning of those applications.

Security: The organization must protect data in part by ensuring that only approved applications are used

AppLocker can help protect data by allowing a defined set of users access to applications that access the data. If security is the top priority, then the application control policies will be the most restrictive.

How are applications currently accessed in your organization?

AppLocker is very effective for organizations with application restriction requirements whose environments have a simple topography and the application control policy goals are straightforward. For example, AppLocker can benefit an environment where non-employees have access to computers connected to the organizational network, such as a school or library. Large organizations also benefit from AppLocker policy deployment when the goal is to achieve a detailed level of control on the desktop computers that they manage for a relatively small number of applications, or where the applications are manageable with a small number of rules.

Possible answers Design considerations

Users run without administrative rights

Applications are installed by using an installation deployment technology

AppLocker can help reduce the total cost of ownership for business groups that typically use a finite set of applications, such as human resources and finance departments. At the same time, these departments access highly sensitive information, much of which contains confidential and proprietary information. By using AppLocker to create rules for specific applications that are allowed to run, you can help limit unauthorized applications from accessing this information.

Note
AppLocker can also be effective in helping create standardized desktops in organizations where users run as administrators. However, it is important to note that users with administrator privileges can add new rules to the local AppLocker policy.

Users must be able to install applications as needed

Users currently have administrator access and it would be difficult to change this

Enforcing AppLocker rules is not suited for business groups that must be able to install applications as needed and without approval from the IT department. If one or more OUs in your organization has this requirement, you can either choose not to enforce application rules in those OUs by using AppLocker or to implement the Audit only enforcement setting through AppLocker.

Is the structure in Active Directory Domain Services based on the organization's hierarchy?

Designing application control policies based on an organization structure that is already built into Active Directory Domain Services (AD DS) is easier than converting the existing structure to an organizational structure. Because the effectiveness of application control policies is dependent on the ability to update policies, consider what organizational work needs to be accomplished before deployment begins.

Possible answers Design considerations

Yes

AppLocker rules can be developed and implemented through Group Policy based on your AD DS structure.

No

The IT department must create a scheme to identify how application control policies can be applied to the correct user or computer.

Summary

You should consider using AppLocker as part of your organization's application control policies if all the following are true:

  • You have deployed or plan to deploy Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7 in your organization. For specific operating system version requirements, see Requirements to Use AppLocker.

  • You need improved control over the access to your organization's applications and the data it accesses.

  • The number of applications in your organization is known and manageable.

  • You have resources to test policies against the organization's requirements.

  • You have resources to involve help desk or build a self-help process for end-user application access issues.

  • The group's requirements for productivity, manageability, and security can be controlled by restrictive policies.

Record your findings

The next step in the process is to record and analyze your answers to the preceding questions. If AppLocker is the right solution for your goals, then the next step is to set your application control policy objectives and plan your AppLocker rules. This process culminates in creating your planning document. For information about setting your policy goals, see Determining Your Application Control Objectives. For information about creating your planning document, see Creating Your AppLocker Planning Document.