Lock down software with application control

You can enable application control for computers running Deep Security Agent 10.0 or higher. For a list of operating systems where application control is supported, see Supported features by platform.

Application control continuously monitors for software changes on your protected servers. Based on your policy configuration, application control either prevents unauthorized software from running until it is explicitly allowed (whitelisted), or allows unauthorized software until it is explicitly blocked (blacklisted). Which option you choose depends on the level of control you want over your environment.

Application control is intended for use on stable servers that are not updated frequently, and not for workstations or servers that undergo a lot of software changes.

Key concepts

Targeted protection state: One of the main decisions you need to make when setting up application control is deciding your targeted protection state. Do you want to prevent all new or changed software from running, unless you manually specify that it is allowed? Or do you want it to run by default unless you specifically block it? One approach is to initially allow unrecognized software to run when you first enable application control and there's a lot of unrecognized software. As you add application control rules and the volume of unrecognized software decreases, you could switch to block mode.

Application control rule: Rules specify whether software is allowed or blocked on a particular computer.

Inventory whitelist: Initial list of software that is installed on the computer. Make sure only software that you want to allow is installed on the computer. When you enable application control, all currently installed software is added to the computer's inventory whitelist and allowed to run. When a computer is in maintenance mode, any software changes made to the computer are added to the computer's inventory whitelist and allowed to run. A computer's software inventory whitelist is stored on the Deep Security Agent and is not displayed in Deep Security Manager.

Unrecognized software: Software that isn't in a computer's inventory whitelist and isn't already covered by an application control rule. See What does application control detect as a software change?

Maintenance mode: If you are planning to install or update software, we strongly advise that you turn on maintenance mode. In maintenance mode, application control continues to block blacklisted software, but allows new or updated software to run and adds it to the computer's inventory whitelist. See Turn on maintenance mode when making planned changes.

How does application control work?

Application control flow diagram corresponding to steps below

  1. You enable application control in a policy and assign the policy to a computer that is protected by a Deep Security Agent (see Turn on application control).
  2. When the agent receives the policy, it creates an inventory whitelist of all software installed on the computer. All software listed in the inventory is assumed to be safe and is allowed to run ("whitelisted") on that computer. This inventory whitelist is not visible from Deep Security Manager, which means you need to be absolutely certain that only good software is installed on a computer where you intend to enable application control.
  3. After the inventory is finished, application control is aware of any software changes on the computer. A software change could be new software that appears on the computer or changes to existing software.
  4. If the computer is in maintenance mode, the Deep Security Agent adds the software to its inventory whitelist and it is allowed to run. This change is not visible in Deep Security Manager. See Turn on maintenance mode when making planned changes.
  5. If the change was made by a trusted installer, the Deep Security Agent adds the software to its inventory whitelist and allows it to run. For example, when Microsoft Windows self-initiates a component update, hundreds of new executable files may be installed. Application control auto-authorizes many file changes that are created by well-known Windows processes and does not list these changes in Deep Security Manager. Removing the "noise" associated with expected software changes provides you with clearer visibility into changes that may need your attention.

    The trusted installer feature is available with Deep Security Agent 10.2 or later.

  6. If the computer's ruleset contains a rule for this exact piece of software, the software is allowed or blocked according to the rule that's in place. See What does application control detect as a software change?
  7. If software is not in the computer's inventory whitelist and is not covered by an existing rule, it's considered unrecognized software. The policy assigned to the computer specifies how unrecognized software is handled. Depending on the policy configuration, it's either allowed to run or is blocked. If the software is blocked and it is able to produce error messages in the OS, an error message on the protected computer indicates that the software does not have permissions to run or that access is denied.

    The unrecognized software appears on the Application Control - Software Changes page in Deep Security Manager. On that page, an administrator can click Allow or Block to create an allow or block rule for that piece of software on a particular computer. An allow or block rule takes precedence over the default action specified in the policy. See Monitor new and changed software.

A tour of the application control interface

There are a few places in Deep Security Manager where you can see changes related to application control:

Application Control: Software Changes (Actions)

The Application Control: Software Changes page is displayed when you click Actions in Deep Security Manager. It displays all unrecognized software (software that isn't in a computer's inventory whitelist and doesn't have a corresponding application control rule). Software changes are allowed or blocked at the computer level, so if a particular piece of software is installed on fifty computers, it will appear on that page fifty times. However, if you know that a certain piece of software should be allowed or blocked everywhere, you can filter the Actions page to sort the changes by file hash and then click Allow All to allow it on all computers where the software is installed.

The policy applied to a computer specifies whether it will allow all unrecognized software to run by default, or block all unrecognized software, but no explicit application control rule is created until you click "Allow" or "Block" on the Actions page. When you click Allow or Block, a corresponding rule appears in the ruleset for the computer. The rulesets are displayed on the Application Control Rulesets page.

Application Control Rulesets

application control rulesets

To see the ruleset for a computer, go to Policies > Common Objects > Rules > Application Control Rulesets. To see which rules are part of a ruleset, double-click the ruleset and go to the Rules tab. The Rules tab displays the pieces of software that have rules associated with them and enables you to change allow rules to block, and vice versa.

Security Events

Events & Reports > Events > Application Control Events > Security Events displays all unrecognized software that either has been run on a computer or has been prevented from running by a block rule. You can filter this list by time period and other criteria.

For each event (except aggregated events), you can click View rules to change the rule from Allow to Block or vice versa. Deep Security Agent 10.2 or later includes event aggregation logic to reduce the volume of logs when the same event occurs repeatedly.

What does application control detect as a software change?

Unlike integrity monitoring, which monitors any file, application control looks only for software files when examining the initial installation and monitoring for change.

Software can be:

  • Windows applications (.exe, .com, .dll, .sys), Linux libraries (.so) and other compiled binaries and libraries
  • Java .jar and .class files, and other compiled byte code
  • PHP, Python, and shell scripts, and other web apps and scripts that are interpreted or compiled on the fly
  • Windows PowerShell scripts, batch files (.bat), and other Windows-specific scripts (.wsf, .vbs, .js)

For example, WordPress and its plug-ins, Apache, IIS, nginx, Adobe Acrobat, app.war, and /usr/bin/ssh would all be detected as software.

Application control checks a file's extension to determine whether it's a script. Additionally, on Linux, application control treats any file with execute permissions as if it's a script.

On Windows computers, application control tracks changes on the local file system, but not on network locations, CD or DVD drives, or USB devices.

Application control is integrated with the kernel (on Linux computers) and file system, so it has permissions to monitor the whole computer, including software installed by root or administrator accounts. The agent watches for disk write activity on software files, and for attempts to execute software.

Differences in how Deep Security Agent 10.x and 11.x compare files

To determine whether software is new or has changed, Deep Security 10.x agents compare the file with the initially installed software's SHA-256 hash, file size, path, and file name (they have a "file-based" ruleset). Deep Security 11.x agents compare only the file's SHA-256 hash and file size (they have a "hash-based" ruleset). Because the rules created by Deep Security 11.x agents compare only the unique hash and file size, a rule will continue to be applied even if the software file is renamed or moved. As a result, using Deep Security 11.x agents reduces the number of software changes that you need to deal with.

A Deep Security 10.x agent continues to use a file-based ruleset until it is upgraded to Deep Security 11.0 or newer. When you upgrade an agent to version 11.0 or newer, its ruleset is converted to use hash-based rules. If there are multiple file-based rules for the same hash value, they are consolidated into one hash-based rule. If the rules being consolidated conflict with each other (one rule blocks the file and another allows it), the new hash-based rule will be an "allow" rule.