How does application control work?

This is new in Deep Security 10.

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)

If scanning for installed software, this is the baseline: a list of what is expected and normal on that specific computer. Application control assumes that currently installed software is approved by you. It creates an initial set of rules to allow the baseline software. (A shared ruleset is created when you use the API to upload it to Deep Security Manager, and convert the local inventory that an agent has already made. Shared rulesets should be applied only to computers with the exact same inventory.)

After that, the Deep Security agent continuously monitors the computer for change. Application control is integrated with the kernel 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 different:

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

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 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. Error messages in the OS (if any for that software) will report that the software does not have permissions to run.

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:

• .so Linux libraries (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)

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

How does application control determine the difference between a text file and a script? A text document does not have execute permissions. Even if a filedoesn'thave execute permissions, however, Deep Security application control will still detect it as software if it has a PHP, Python, or Java file extension:

• .class
• .jar
• .war
• .ear
• .php
• .py
• .pyc
• .pyo
• .pyz

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 either 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.