About Executable Control
In this section:
Trusted Ownership
During the rule matching process, Trusted Ownership checking is performed on files and folders to ensure that ownership of the items is matched with the list of trusted owners specified in the default rule configuration.
For example, if a match is made between the file you want to run and an allowed item, an additional security check ensures that the file ownership is also matched with the Trusted Owners list. If a genuine file has been tampered with or a file that is a security threat has been renamed to resemble an allowed file, trusted ownership checking identifies the irregularity and prevents the file execution.
Network folders/shares are denied by default. So, if the file resides on a network folder, the file or folder must be added to the rule as an allowed item. Otherwise, even if the file passes Trusted Ownership checking, the rule will not allow access.
Trusted ownership checking is not necessary for items with file signatures because these cannot be imitated.
Owners trusted by default are:
- SYSTEM
- BUILTIN\Administrators
- %ComputerName%\Administrator
- NT Service\TrustedInstaller
This means that, by default, Application Control trusts files owned by the BUILTIN\Administrators group and the local administrator. Application Control does not do group lookups for Trusted Owners – users who are members of the BUILTIN\Administrators are NOT trusted by default. Other users, even if they are members of the Administrators group, must be explicitly added to become Trusted Owners. You can extend the list above to include other users or groups.
Technology
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.
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.
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.
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 BUILTIN\Administrators 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 a trusted owner, for example a domain or local admin.
Security Levels
Application Control rules allow you to set security levels to specify how to manage requests to run unauthorized applications by the users, groups, or devices that a rule matches.
Self Authorization
In some environments it's necessary for users to add new executables to a computer, for example, developers who constantly update or test internal software, or power users who require access to new or unknown applications. Self-Authorization allows nominated power users to execute applications they have introduced into the system. These power users can add applications to a secured endpoint while outside the office without relying on IT support. This provides development teams, power users and administrators the flexibility to install and test software while still offering a high level of protection against hidden malware and executables.
Any user configured as self-authorizing will have the option of allowing an untrusted executable to run, either once, every time during the current session, or always. Comprehensive auditing details information such as application name, time and date of execution, and device. What's more, a copy of the application can be taken and stored centrally for examination.
Allowed and Denied Items
Allowed Items
The allow list 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 an allow list that must be checked each time an execution request occurs. If the executable file is on the allow list 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, product levels, and upgrades to the allow list.
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, allow lists are as Allowed Items. Items in the Allowed Items list include:
- Files
- Folders
- Drives
- File Hashes
- Rule Collections
Denied Items
In contrast to allow lists, deny lists 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 deny list 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 deny list 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.