This is new in Deep Security 10.
Once application control is enabled, and logging or alerts are configured, you may receive notification that the Deep Security agent has detected unrecognized software changes. Then you can decide whether to allow or block that software, or simply continue monitoring.
To quickly find all software changes on all computers, and easily create allow / block rules for them, use the Actions tab.
- Go to Actions.
To show / sort only specific occurrences of unrecognized software:
- From the dropdown menu next to "Application Control: Software Changes", select a time range such as Last 24 Hours to omit all events that aren't in that period
In the pane on the left, select a computer group or smart folderUnlike the Computers tab, this pane usually does not show all computers. If application control has not detected unauthorized software changes, or if you have already resolved them by creating allow / block rules, then this pane's computer groups and smart folders will be empty.
- Enter search terms in the search filter field
- Select whether to Group by File (Hash) or Group by Computer
- In the pane on the right, click the file name or computer name in the details in order to add them to your search filter
- Click a bar in the graph that indicates a time when software changed to zoom in on that time period
Search results will show only incidents that match all criteria. If your search filter hides too much, to remove one of the search terms, click the X button next to it. If you need more information to decide whether to allow or block, click the software name, then use the details panel on the right side.
If the computer has too much software change, for performance reasons, application control will continue to enforce existing rules, but stop detecting and displaying software changes. To resolve this, see Reset application control after too much software change.
Click either Allow or Block to add an allow / block rule on that computer, for that software version, in that path.
(Alternatively, to allow or block the software in all file system paths and computers where it was detected, click Allow All or Block All. If you have accidentally selected the wrong action, see View your application control rulesets.)
When you change allow / block rules, this affects all computers that use the same ruleset.
If you want exactly the same rules to apply to many computers (even in the future), use shared rules created via API. 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. Each computer can have only one ruleset at a time, and Block unrecognized software until it is explicitly allowed will block all software that isn't in the ruleset, so you shouldn't use a shared ruleset if computers are merely similar (but not identical).
Shared rulesets increase the time required to deploy rulesets to new computers, so examine this setting if performance is an issue. Relays on your local network can help you to distribute shared rulesets more quickly.
The next time that the agent connects with Deep Security Manager (local ruleset) / Relay (shared ruleset), it will receive the new rules. (If a computer was using shared allow / block rules created via the API, the relay will also transmit those new rules to other agents that use the shared rules the next time they connect.) Until it succeeds, the status will indicate that the ruleset update is pending. Time required varies by:
- heartbeat interval and bi-drectional communications
- number of files
- computer's disk and CPU speed (local rulesets only)
- bandwidth (shared rulesets only)
- number of routers, firewalls, or proxies in between with limited system resources (shared rulesets only)
- ruleset deployment via relay (shared rulesets only)
To verify that your rule is working, try to run the software that you just blocked. To match the rule, software must be in the same location, and have the same hash, path, and file name.If software is accidentally blocked (or allowed) because you've selected Block unrecognized software until it is explicitly allowed and the software isn't being recognized, the Reason column in app control event logs can help you to troubleshoot the cause.
If blocked software is still installed, application control will still record logs and show alerts when it blocks software from running.
To reduce your attack surface and permission error logs on the computer, uninstall the software that app control is blocking. Once that is done, if you want to dismiss related alerts, either go to Alerts or go to Dashboard, and click the alert, and then click the Dismiss Alert button. Not all alerts can be dismissed. For more information, see Predefined alert definitions
Example: Allow All in application control
helloworld.py is detected on 3 computers with local rulesets, then when you click Allow All or Block All, this would affect 3 only computers. It won't affect future detections on other computers, because they have their own rulesets.
helloworld.py is detected on 3 computers with 3 different shared rulesets, and 297 other computers also use the same 3 rulesets, then when you click Allow All or Block All, Deep Security Manager would upload the rule change to a total of 300 computers. It would also affect future computers that use the same shared rulesets.
When you install patches, upgrade software, or deploy web applications, application control will detect them. Depending on your setting for how to handle unrecognized software, this could block that software until you use the Actions tab to create allow rules. For mission-critical software, this service interruption may not be acceptable. You also might not want to receive many alerts during expected, scheduled software updates such as Linux upgrades.
To avoid extra down time and / or alerts during deployment and maintenance windows, you can put application control into a mode designed for maintenance windows. While this mode is enabled, application control will continue to block blacklisted software, but it will allow new or updated software to run, and automatically add it to the allow rules.
You can enable or disable maintenance mode either through actions on the Computers tab or (if only for a few computers) each computer's computer editor.
In Deep Security Manager, go to Computers(not the Policy tab).
Select one or more computers, then click Actions > Turn On Maintenance Mode.
Select the duration of your maintenance window.
Maintenance mode will automatically disable itself when your maintenance window is scheduled to end. Alternatively, if you will manually disable maintenance mode when updates are finished, select the option to not automatically turn off ("Stay on indefinitely").If maintenance mode is set to Stay on indefinitely, don't forget to manually disable it once updates are complete. Failure to do this could allow users or attackers to install and run new software, including zero-day malware, and it will be automatically added to your allow rules.
Deep Security Manager will immediately try to send the command to the agent. You don't need to click Save. The status and / or maintenance mode dashboard widget indicates whether the command has succeeded yet or not.
- Install or upgrade software.
If that computer was using shared allow / block rules, then the next time that the agent connects with Deep Security Manager, it will upload the new rules. Deep Security Manager will transmit those new rules to the other agents the next time they connect. Time required varies by:
- If you selected to disable maintenance mode manually, remember to disable Maintenance Mode in order to start to detect software changes again.
If you made a security update, verify that all computers were updated (none have the old, insecure software).
If the computer uses a shared ruleset, go to Policies> Rules> Application Control Rulesets and double-click the ruleset. Find the allow rules for the old, insecure software and change their Action to Block. This will prevent the insecure software from running if it is accidentally re-installed.
If you have used the API to create shared allow / block rules, you can apply those rulesets to other computers. This can be useful if you have many identical computers (such as a load balanced web server farm).
Use the API to build a computer's shared allow / block rules. For more information, see the API documentation. If you want to examine the shared ruleset before you deploy it, see View your application control rulesets.
Go to Computer or Policy editorYou can change these settings for a policy or for a specific computer. To change the settings for a policy, go to the Polices page and double-click the policy that you want to edit (or select the policy and click Details). To change the settings for a computer, go to the Computers page and double-click the computer that you want to edit (or select the computer and click Details). > Application Control.
These settings are hidden until you use the API to create at least one shared ruleset. If you haven't created any shared rulesets, or if you keep the default settings, each computer will keep its own allow / block rules locally. Changes to local rules don't affect other computers.
The next time that the Deep Security agent on the computer connects with Deep Security Manager, the agent will apply those rules. Time required varies by:
- heartbeat interval and bi-drectional communications
- number of rules
- number of routers, firewalls, or proxies in between with limited system resources
- ruleset deployment via relay
If the computer is currently using shared allow / block rules created via the API, you can change it to use local rules. Application control will scan the file system for all currently installed software, and create an initial ruleset for it, similarly to when you first enabled application control.
The steps below configure a computer's agent to use a local ruleset. If you want all computers (such as a data center, where each server hosts different applications) to use local rules, edit the setting in the Policies tab instead.
In the Ruleset section, deselect Inherit settings (if necessary), and then select Use local ruleset initially based on installed software.
To verify the change, the next time the agent and Deep Security Manager connect, look for event log messages about building the application control ruleset. Time required varies by:
Application control is designed to assist your software change management process — not for unregulated computers with continuous, large numbers of software changes.
Too many changes can result in large rulesets that consume more RAM (unless you remove old rules each time). If you don't use maintenance mode during authorized software updates, too many changes can also result in high administrator workload because then they must manually create allow rules.
If unrecognized software changes exceed the maximum, application control will stop detecting and displaying all of the computer's software changes. This prevents accidental and / or malicious stability and performance impacts: consuming too much memory, disk space, and (for shared rulesets) network bandwidth.
Examine the computer's processes and security events. Verify that the computer has not been compromised.
If you are not sure, or do not have enough time, the safest and fastest way is to restore the system from backup / VM snapshot.If you don't remove any unauthorized software (including zero-day malware), application control will ignore it when you reset application control. It won't appear on the Actions tab anymore, and if its process has already executed and it is in RAM, application control won't log any events or alerts about it until you reboot the computer.
- If the computer was running software updates, including auto-updates such as browser, Adobe Reader, yum updates, disable them or schedule them so that they only occur when you have enabled application control's maintenance mode.
Reset application control. To do this, disable application control. Once the agent has acknowledged it and cleared the error status, enable application control again.
Local rulesets will be rebuilt; shared rulesets will be downloaded again.