Application Control Security Methods

In this section:

Implementing Application Control Security Methods

Application Control offers a number of security methods that you can implement to protect a system without complex lists and constant management. These include the following:

  • Trusted Ownership
  • Trusted Vendors
  • Digital Signatures
  • Allowlisting
  • blocklisting

To get the most value out of an Application Control configuration, you can use hybrid approach in which you combine the most suitable components from each security method to provide the optimum security model, while minimizing overall management and configuration overheads.

The Trusted Ownership approach enables new applications to be installed by Trusted Owners without any changes required to the Application Control configuration, yet still provides full security against unknown application and script content introduced by non-trusted end users. So it's recommended that this security method be used for the basis of most Application Control configurations. This is why this functionality is enabled by default in all new Application Control configurations.

The allowlist approach is the most secure but it is an administrative-intensive security model. If an enterprise does not use NTFS security on their file systems, the allowlist method is the recommended option because Trusted Ownership relies on the file owner information that is only found in NTFS.

Trusted Ownership is only appropriate for locally installed executable content; that is, applications that exist on local fixed drives in a computer. Any executable or script content that resides on network locations or on removable media, such as a CD or a DVDROM, is automatically considered untrusted, and is immediately blocked from executing. Any such application that must be executed by a user must be specifically added to the allowlist in the Application Control configuration, with a full UNC path to the relevant executable. It is possible to optionally disable Trusted Ownership checking on these items if necessary, or to optionally select to take a SHA-1, SHA-256 or Alder-32 signature to check the file at runtime. It is considered good practice to use digital signature checking for applications based on networks or removable media because these files tend to be outside of the control of the administrator responsible for the organization's endpoints.

Trusted Vendor checking is recommended for development and test environments where end users may need to constantly install and test different versions of company-owned application and script content. By signing the desired executables with a digital certificate, Trusted Vendor checking can be configured to allow all signed components to be executed as and when needed.

Finally, you should create a blocklist, preventing specific user access to applications that would typically be installed and therefore owned by Trusted Owners, including parts of the operating system such as registry editing tools, file sharing tools, and access to Control Panel components. This blocklist can also be used for application license management, when used in conjunction with allowlists and the Application Limits functionality.

Trusted Ownership

The following video provides an introduction to the concepts used in Trusted Ownership:

Trusted Ownership Why? What? How?

Application Control uses secure filter drivers and Microsoft NTFS security policies to intercept all execution requests. Execution requests go through the Application Control hook and any unwanted applications are blocked. Application entitlement is based on the ownership of the application, with default trusted ownership typically being for administrators. By using this method, current application access policy is enforced without the need for scripting or list management. This is called Trusted Ownership. In addition to executable files, Application Control also manages entitlement to application content such as VBScripts, batch files, MSI packages, and registry configuration files.

Application Control only supports PowerShell version 2.0 or later and must be installed in the endpoint. See also Scripted Conditions.

Trusted Ownership is the default method of controlling access to applications in Application Control. It uses the Discretionary Access Control (DAC) model. It examines the owner attribute of the file and compares it to a predefined list of trusted owners. If the owner of the file appears in the list then execution of the file is granted, otherwise it is denied. The decision is made independently of the user actually trying to execute the file.

An important feature of this security method is the ability to not consider the file contents itself. In this way, Application Control is able to control both known and unknown applications. Conventional security systems such as anti-virus applications compare file patterns against those in a known list to identify potential threats. So the protection it offers is directly proportional to the accuracy of the list that it uses for comparison. Many malware applications are either never identified, or at best, identified only after a period of time while systems are left vulnerable. Application Control, by default, allows ALL locally installed executable content to execute IF the owner of the executable is listed in the Trusted Owners list in the configuration. The administrator must then supply a list of applications that they do not want to execute from the local disk subsystem, which would typically be administrative applications such as mmc.exe, eventvwr.exe, setup.exe, and so on.

If this approach is taken, the administrator does not have to find out the full details of every piece of executing code required for the application set to function because the Trusted Ownership model allows / denies access as appropriate.

Although Application Control is able to stop any executable script based malware as soon as it is introduced to a system, Application Control is not intended to be a replacement for existing malware removal tools, but should act as a complementary technology sitting alongside them. For example, although Application Control is able to stop the execution of a virus, it is not able to clean if off the disk.

Application Control and Trusted Ownership

Application Control maintains a trusted owners list that is defined in the Trusted Owners dialog. This dialog is accessed from the Global Settings ribbon.

Users and groups can be deleted or added as required.

Do not remove all Trusted Owners. This would result in no application on the system being trusted and standard users unable to run anything.

In the NTFS system, a file can be owned by either a user or a group and therefore both may be added. When the check for Trusted Ownership is performed the System Identifier (SID) of the file owner is determined and this is checked against the list of SIDs in the trusted owner configuration. Application Control does not evaluate a group or determine users of a group. This ensures that Application Control continues to function correctly when machines are not connected to a network and this information is not available.

There are two options in the Trusted Owners dialog:

  • Enable Trusted Ownership checking - Select to switch on Trusted Ownership checking. If this is not selected Application Control does not perform any Trusted Ownership checking and other security methods must be configured to give the desired security.
  • Change a file’s ownership when it is overwritten or renamed - The default for certain operating systems is to retain file ownership when a file is overwritten or renamed. This can be seen as a security flaw as if NTFS permissions allow, a user may overwrite a legitimate file with a file that would otherwise be blocked. Select this option to ensure that if a legitimate file is compromised in this way, the ownership changes to that of the user and Trusted Ownership prevents the file from being executed.

Trusted Ownership Rule

Trusted Ownership does not need to take into account the logged-on user. It does not matter whether the logged-on user is a Trusted Owner, administrator, or not. Trusted Ownership revolves around which user (or group) owns a file on the disk. This is typically the user who created the file.

It is common to see the group BUILTIN\Administrators in the Application Control console as the file owner. It is also possible to find that the file owner is an individual administrator’s account. This results in the following situations:

  • The file owner is the group BUILTINAdministrators and this group is a Trusted Owner. Trusted Ownership allows the file to execute.
  • The file owner is an individual administrator and the individual administrator is a Trusted Owner. Trusted Ownership allows the file to execute.
  • The file owner is an individual administrator and the individual administrator is not a Trusted Owner, but the BUILTIN/Administrators group is a Trusted Owner. Trusted Ownership does not allow the file to execute.

In the last case, even though the administrator who owns the file is in the BUILTIN/Administrators group, the file owner is not trusted. The group is not expanded to find out whether the individual owner should be trusted. In this case, to allow the file to execute, the file’s ownership must be changed to that of the BUILTIN/Administrators.

Trusted Vendors

Trusted Vendors can be specified in each Application Control rule node. Trusted Vendors are used for listing valid digital certificates. A digital certificate is an electronic document that uses a digital signature to bind together a public key with an identity. This includes information such as the name of a person or organization, address, and so on. Digital certificates are issued by a certificate authority and used to verify that a public key belongs to an individual. Application Control queries each file execution to detect the presence of a digital certificate. If the file has a valid digital certificate and the signer matches an entry in the Trusted Vendor list, the file is allowed to run, and overrides any Trusted Ownership checking.

You can check whether a file has a digital certificate by displaying the Properties dialog. A file has a digital certificate if there is a Digital Signatures tab in which you can view details of the certificate including, signer information, advanced settings and an option to display the certificate.

Digital Signatures

Digital Signatures provide a means to accurately identify a file according to the actual contents of the file itself. Each file is examined and according to its contents, a digital hash, which may be likened to a fingerprint, is produced. Application Control makes use of the industry standard SHA-1, SHA256 and Adler-32 hashes. If the file is altered in any way, then the SHA-1 hash is also altered.

Other algorithms can be selected from the Signatures drop-down on the Advanced Settings dialog.

Digital hashing is seen as the ultimate security method because it is accurate. It identifies each file independently of all other factors other than the file itself. For example, an administrator takes a digital hash of all executables on a computer system and records them. A user then tries to execute an application. The digital hash of the application is calculated and then compared to the recorded values. If there is a match the application is granted execution, otherwise it is denied. This methodology also provides zero-day protection because not only does it stop new applications from being introduced, it also blocks any applications that have been infected with malware.

Although digital signatures provide a similar protection to Trusted Ownership, you must also consider the time and management involved with respect to maintaining the security systems in place. Applications are constantly being updated with service packs, bug fixes, and vulnerability patches. This means that all associated files are also constantly being updated. So if, for example, a service pack is applied to Microsoft Office then for the updated parts to work new digital hashes of the updated files must now be taken. Take care to ensure that these are available when the update is available to eliminate downtime. Additionally, it is recommended that you remove the old signatures.

Signature Wizard

Application Control has a Signature Wizard that allows you to apply digital signatures either to an individual file or a group. Digital signatures can be grouped in one of two ways, by means of scanning folders and subfolders, or by examining a running process.

The Signature Wizard is available from the Groups ribbon when you select a group beneath the Library > Group Management node.

The Search Folders option in the Signature Wizard scans all executable and script based files in selected folder and automatically calculates the digital hashes. The Examine a running process option allows you to select a process that is currently running. The process, along with all executable files it has currently loaded, is scanned and digital hashes calculated.

If a file is found for which the signature has already been calculated a notification of a duplicate is displayed. There is no need for a duplicate hash in a configuration. If the files are updated by means of, for example, a service pack, you can select the signature file group and choose to re-scan. All of the digital signatures are automatically updated and the new configuration can be deployed.


The allowlist approach dictates that every single piece of executable content must be predefined prior to the user making the request for the application on the operating system. Details of all the content identified in this way is kept on a allowlist that must be checked each time an execution request occurs. If the executable file is on the allowlist it is permitted; otherwise it is denied.

A small number of security technologies work in this way, but they often experience issues with the level of administration required once implemented. This is due to the necessity of adding and maintaining all patches, service packs, and upgrades to the allowlist.

Application Control fully supports this model of control, and adds significant steps to enable additional security in the model. One such addition is the ability to include SHA-1, SHA-256, and Adler-32 digital signatures, so that not only must the application name and file path match up, but so must the digital signature of that executable to that of a signature in the database. Furthermore, Application Control also adds the full path of the executable to the list to ensure that all three items match prior to application execution:

Filename - for example, winword.exe.

File Path - for example, C:\Program Files\Microsoft Office\Office\digital signature

To take the technology into the next stage of control, Application Control does not only take the details of the executables, but also requests that the administrator specify specific DLLs as well as all other executable content such as ActiveX controls, Visual Basic Scripts, and Command Scripts.

In Application Control, allowlists are as Allowed Items. Items in the Allowed Items list include:

  • Files
  • Folders
  • Drives
  • Signature Items
  • Network Connection Items
  • Windows Store Apps
  • Groups
  • Trusted Ownership
  • Access Times


In contrast to allowlists, blocklists are a potential low security measure. A list is generated and then maintained that contains the applications that are to be denied execution. This is the main failing of this method, as it presumes that all dangerous applications are actually known about. This is of little use in most enterprises, specifically with email and internet access and / or where the user can introduce files and applications without administrator intervention.

Application Control does not need to actively maintain a list of denied applications because any applications not installed, and therefore owned by the administrator, are denied by use of Trusted Ownership.

One of the main reasons prohibiting applications via a blocklist is to enable Trusted Ownership to be used for license management by not allowing even known (and therefore trusted and owned) applications to run, until the administrator can later explicitly allow access to that very same application by defining a certain user / group or client rule. This protection needs no configuration, except to allow an outside application. Additionally, a blocklist is useful for denying access to files owned by trusted owners that can be deemed security risks. For example, regedit.exe, ftp.exe, and so on.

Related Topics