Trend Micro Deep Security 20 LTS Best Practice Guide 60
When Application Control is enabled for blocking executables, it 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)
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.
If your environment has an extension mentioned above but that is considered a safe file, add it to the allow list in
software inventory.
Beginning in Deep Security 11.0, Application Control was enhanced with a new Block by Hash feature that allows
administrators to submit known bad hash values to Deep Security for Application Control block list enforcement.
The control recognizes a new “Global rule set” that includes a list of hash values to be blocked. This rule set takes
precedence over any other rules from existing shared or local rule sets, and will be enforced by every Deep
Security Agent enabled with Application Control. This feature provides a simply way for users to block unwanted
or bad software from running at a global system-wide level. The design allows the workflow to be fully automated;
with APIs for creating the Global rule set, adding and deleting hash values.
Application Control creates a software change event log whenever new executable files are detected on
protected systems. Sometimes these changes are generated as part of the normal operation of trusted
software. For example, when Windows self-initiates a component update, thousands of new executable files may
be installed. Application control will now auto-authorize many of these file changes when created by well-known
Windows processes and no longer create corresponding change log events. By removing the “noise” associated
with expected software changes, users will have clearer visibility into changes that may require their attention.
Before you deploy this feature in customer environment, make sure you already checked the support matrix of
application control vs features in the Supported features by platform
article in the Deep Security Help Center.
Application Control continuously monitors your server and logs an event whenever a software
change occurs. It is not intended for environments with self-changing software or that normally creates
executables, such as some web or mail servers.
When using Application Control, if you create a golden image, update it with required patches,
create a shared ruleset, and then apply that shared ruleset to other computers. When you install those
same patches on the other computer, they will be allowed to execute because they are in the shared
ruleset. However, the patch updates will appear on the Software Changes page. To avoid this, Application
Control must be set to Maintenance Mode when applying patches.