How does application control work?

Most administrators want to focus on what has changed — the “drift” or “delta”— compared to the computer's initially installed software. Application control is designed for this approach.

When you enable application control, the Deep Security Agent will either:

• Scan for an inventory of installed software and create an initial local ruleset, or
• Download the selected shared ruleset (if you have created a shared ruleset via API) Shared rulesets should be applied only to computers with the exact same inventory.

If you choose the first option (scan for installed software), application control assumes that any currently installed software is approved by you and it creates an initial set of rules to allow that software.

After that, the Deep Security Agent continuously monitors the computer for changes. 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. To determine if the software is new or has changed, it compares the file with the hashes of the initially installed software. Change includes differences in:

• File name
• Path or location
• Time stamp
• Permissions
• File contents

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

After application control is enabled (except during maintenance mode) all software changes will be logged. Events are generated when application control detects new or changed software on the file system, and each time that software tries to execute (unless you allow it). You can create rules to allow or block specific software when it tries to launch.

When application control finds new software, it must decide whether to allow or block it. To decide, application control compares the software file's:

• Hash
• File size
• Path
• File name

with entries in its allow or block rules. Three match results are possible:

• Allow rule (software is "known")
• Block rule (software is "known")
• No match is found (software is "unrecognized")

If the software is "unrecognized", the Reason column in the app control event logs explains why it didn't completely match any allow or block rule.

Unrecognized software (changes that you haven't specifically allowed in your rules) could be either harmless patch updates or a dangerous IT security policy violation. So depending on your security posture, you can configure how application control will handle unrecognized software:

• Allow execution
• Block execution

Whether due to a block rule or because the software is unrecognized, blocked software cannot launch. If the software can produce error messages in the OS, an error message will indicate that the software does not have permissions to run or that access is denied.

What does app control detect as software?

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), Linus 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.

Local vs. shared rulesets

For better performance or administrative workload, you can use local rulesets, shared rulesets, or both.

• Shared ruleset: Syncs all its rule data onto both agents and manager / (if enabled) relays. This increases network and disk space usage. However, it may be easier if you need to verify the rules from the initial inventory scan or maintenance mode, or if you manage a server farm with many computers that should be identical. For example, if you have a server pool of identical LAMP web servers, or if they are virtual machines (VMs) that are part of an auto-scaling group, shared rulesets can be useful. It can also reduce administrator workload.

  Don't use a shared ruleset if you enabled Block unrecognized software until it is explicitly allowed, and if computers are merely similar (but not identical). It will block all software on other computers that isn't in the first computer's ruleset. If those include critical files, it could break the OS. If that happens, you may be required to reinstall, revert to a backup, or use the OS recovery mode.
• Local ruleset: The default. Keeps some data locally, only on that specific computer. Allow or block rules configured via Deep Security Manager are sent to the agent; those rules are kept both places. But allow rules from the agent's initial inventory scan or maintenance mode are not uploaded to the manager or relay. This reduces network usage and database disk space usage. However, when you view a local ruleset on Deep Security Manager, the manager doesn't have any of the agent's local data, so it won't display those rules. It can also cause more administrator workload if computers are identical, and could use the same ruleset.