When you deploy Application Control to protect an endpoint, it creates a whitelist of all executable binary and script files present on the endpoint. The whitelist lists all authorized files and is used to determine trusted or known files. In Enabled mode, only files present in whitelist are allowed to execute. Also, all files in the whitelist are protected and cannot be modified or deleted. An executable binary or script file that is not in the whitelist is said to be unauthorized and is prevented from running.
Authorizing files and programs
The whitelist is the most-common method to determine trusted or known files. You can authorize a program or file on a protected endpoint by using one of these methods:
1 By checksum
2 By certificate or publisher
3 By name
4 By adding to the whitelist
The order in which the methods are listed indicates the precedence the software applies to the methods. For example, if you ban a program based on its checksum value and it is present in the whitelist (and hence is authorized), the program is banned. Similarly, if a program is allowed based on its checksum value and is banned by name, the program will be allowed to execute and run.
Allowing changes to endpoints
Typically, most applications and executable files remain unchanged over prolonged periods of time. However, if needed, you can allow certain applications and executable files to create, modify, or delete files in the whitelist. To design a trust model and allow additional users or programs to modify a protected endpoint, you can use one these methods.
Getting started with Application Control Managing protected endpoints
Refers to an application permitted to update the endpoint. If a program is configured as an updater, it is allowed to install new software and update existing software. For example, if you configure Adobe 8.0 updater program as an updater, it can periodically patch all needed files.
NOTE:Updaters work at a global-level and are not application- or license-specific. After a program is defined as an updater, it can modify any protected file. If you are using both Application Updater
Control and Change Control, an updater defined via an Application Control policy will also be able to modify files protected by rules defined in a Change Control policy.
Note that an updater is not authorized automatically. To be authorized, an updater must be present in the whitelist or given explicit authorization (defined as an allowed binary via a policy). We recommend that you use caution and judiciously assign updater privileges to binary files. For example, if you set cmd.exe as an updater and invoke any executable from it, the executable can perform any change on the protected endpoints.
NOTE:To avoid a security gap it is not recommended to have a file configured as an allowed binary and updater concurrently.
Common candidates to set as updaters include software distribution applications, such as Tivoli, Opsware, Microsoft Systems Management Server (SMS), and Bladelogic and programs that need to frequently update themselves. Application Control includes predefined rules for commonly-used applications that might need to update the endpoints frequently. For example, rule groups are defined for the Altiris, SCCM, and McAfee products.
Refers to a publisher or trusted certificate (associated with a software package) that is permitted to run on a protected endpoint. After you add a certificate as a publisher, you can run all software Publisher
that is signed by the certificate. For example, if you add Adobe’s code signing certificate as a publisher, all software issued by Adobe and signed by Adobe's certificate will be permitted to run.
To allow any custom scripts and in-house applications to run on protected endpoints, you can sign the scripts and applications with an internal certificate and define the internal certificate as a trusted publisher. After you do so, all applications signed by the certificate are allowed. Also, all applications and binary files either added or modified on an endpoint that are signed by the certificate are automatically added to the whitelist.
When adding a publisher, you can also choose to provide updater privileges to the publisher. We recommend that you use this option judiciously because selecting this option will ensure that all the binary files signed by publisher acquire updater privileges. For example, if you set the Microsoft certificate that signs the Internet Explorer application as an updater, Internet Explorer can download and execute any application from the internet. In effect, any files added or modified by an application that is signed by the publisher (with updater privileges) will be added to the whitelist automatically.
Refers to an application installer identified by its checksum (SHA1) that is allowed to install or update software. When a program (or an installer) is configured as an authorized installer, it Installer
gets both the attributes - authorized binary and updater. Hence, regardless of whether the installer was originally present on the endpoint or not, it is allowed to execute and update software on the endpoint.
An authorized installer is allowed on the basis of the checksum (SHA1) value of the installer (specified while configuring the policy). This ensures that regardless of the source of installer (and how one gets this installer to the endpoint), if the checksum value matches, the installer will be allowed to run. For example, if you add the installer for the Microsoft Office 2010 suite as an installer, if the checksum matches the installer will be allowed to install the Microsoft Office suite on the protected endpoints.
Refers to a directory (local or network share) identified by its Universal Naming Convention (UNC) path. After you add a directory as a trusted directory, endpoints are permitted to run any software present on that directory.
Trusted Directory
When enabled, Application Control prevents protected endpoints from executing any code residing on a network share. If you maintain shared folders containing installers for licensed applications on the internal network in your organization, add trusted directories for such network shares.
Additionally, if needed, you can also allow the software located at that UNC path to install software on the protected endpoints. For example, when logging on to a Domain Controller from a protected endpoint, you will need to define \\domain-name\SYSVOL as a trusted directory (to allow execution of scripts).
Getting started with Application Control Managing protected endpoints
Refers to an authorized Windows user with privileges to dynamically add to the whitelist. For example, add the administrator as a trusted user to allow the administrator to install or update any software. While adding the user details, you must also provide the domain details. Trusted User
Of all the strategies available to allow changes to protected endpoints, this is the least preferred because it offers minimal security. We suggest that you define trusted users judiciously because after a trusted user is added, there are no restrictions on what the user can modify or run on an endpoint.
Refers to a time-window during which all changes are allowed on a protected endpoint. Place the protected endpoints in the Update mode to perform ad-hoc changes to the endpoints. Update mode
Use this method when none of the other strategies, such as trusted users, trusted directories, publishers, or installers meet you requirements. For example, define a time window to allow the IT team to complete maintenance tasks, such as install patches or upgrade software. For more information on the Update mode, see theUnderstanding Application Control modes section.