Lock down software with application control

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.

Application control will also download the global ruleset (if any).

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. Later, if you need to edit or delete rules, you can use the ruleset editor or decision log.

When application control finds new software, it must decide whether to allow or block it. To decide, application control first compares the hash with the global ruleset (if any). It has priority. Then application control compares the software file's:

• Hash
• File size
• Path
• File name

with entries in its allow or block ruleset. 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 vs. global rulesets

For better performance or administrative workload, you can use local rulesets, shared rulesets, a global ruleset, or a combination.

• 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 have identical software, and could use the same ruleset.

• Shared ruleset: Syncs all its rule data onto both agents and manager (and also relays, if enabled). 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.
• Global ruleset: Like shared rulesets, these are distributed to agents by the manager (and also relays, if enabled). This increases network and disk space usage. However, because they are global, you don't need to spend time selecting them in each policy.