Undo blocking or allowing software

Once rules and rulesets are created, you can view and manage them in the ruleset editor or decision log. To see what rules and rulesets are applied:

If the computer(s) using a ruleset are removed and new ones requiring that ruleset are unlikely to appear:

If software has been removed and isn't likely to return:

If a file should no longer be allowed/blocked:

For an overview of the application control module, see Lock down software with application control.

 

Depending on whether a ruleset is local (applies to one computer) or shared (applies to many computers), when you change a rule, it might affect many computers. However, each rule is a specific combination: hash, file name, path, and file size. So if a file has many different file names and hashes, then you may need to edit the action in many rules.

If you need to undo a complex change like this, or if you need to undo changes made by a specific person, it may be faster use the decision log (see Undo many new rules and rule changes with the decision log) instead of editing individual rules.

View application control rulesets

Initially, when a Deep Security Agent scans the computer's file system for installed software, the application control ruleset only contains this software inventory. (If you created a shared ruleset via the API, you can review this inventory in Deep Security Manager.) Later, you might use Deep Security Manager to add:

  • block rules to deny specific new software
  • allow rules for new or updated software

To view the list of application control rulesets, go to Policies > Rules > Application Control Rulesets.

application control rulesets

To view the application control ruleset or to edit the individual allow and block rules in a ruleset, double-click the ruleset.

"Local" rulesets store the inventory part of the ruleset locally on each computer. This includes inventory additions during maintenance mode. Agents don't transmit inventory to the remote Deep Security Manager, so it has better performance compared to "shared" rulesets, which transmit everything. However, since Deep Security Manager doesn't get local inventory data, it can't display a complete local ruleset — only the allow and block rules that you have added from the manager.

Global block rules aren't part of individual rulesets applied via policies, and don't appear in the ruleset list. To view them, use the API instead.

As you allow or block more software, more rules will be added to the application control ruleset.

Keep some older rules if you might downgrade the software, or if the shared ruleset is applied to a server farm where some computers haven't finished upgrading yet (and therefore some computers still need the older rules).

When the rules are not needed anymore, however, you can delete them to reduce the size of the ruleset. This improves performance by reducing RAM and CPU usage, and (for shared rulesets) reduces download time required when deploying a new computer. See Delete an individual application control rule.

Delete an application control ruleset

If an application control ruleset is not being used anymore, you can delete it.

If you delete an application control ruleset, this reclaims disk space. This can be especially useful to reduce system resource usage on Deep Security Relays that may be distributing multiple large shared rulesets.

To delete a ruleset, go to Policies > Rules > Application Control Rulesets, click a ruleset to select it, and click Delete.

Delete an individual application control rule

If you want to undo a rule that you created, go to Policies > Rules > Application Control Rulesets, double-click the ruleset that has the rule you want to delete, then click Delete.

If you want to deauthorize software, you will also delete the allow or block rule for the software. If you have selected Block unrecognized software until it is explicitly allowed for enforcement of unrecognized software, then you can delete all rules except the allow rules for your current software inventory. This will block all older, unpatched software versions that might have security vulnerabilities.

Because application control might need to evaluate all rules in the ruleset every time that a process tries to launch unrecognized software, you can reduce RAM and CPU usage and improve performance by keeping fewer rules.

If a software update is unstable, and you might need to downgrade, keep rules that allow rollback to the previous software version until you have completed testing.

To find the oldest rules, go to Policies > Rules > Application Control Rulesets, then click Columns. Select Date/Time (Last Change), click OK, and then click that column's header to sort by date.

If you delete a rule, application control will not recognize the software anymore. So if the software is installed again, it will appear again on the Actions tab.

Delete a global rule

To delete a global rule, use the API.

Change the action of one application control rule

If you want to allow a software that you previously blocked (or the opposite), you can edit the action in the rule. If the software has the same file name and file size regardless of where it is installed, then you can easily edit the actions for similar rules.

If you need to undo the rule so that the software is not recognized by application control (in other words, delete the rule, not only change its action), see Delete an individual application control rule instead.

  1. Go to Policies > Common Objects > Rules > Application Control Rulesets.

  2. Double-click to select the ruleset that contains the rule that you want to change.

    If you don't know where the rule is, but you remember when or how you changed it before, you can use the decision log to find the related ruleset.
  3. On the pop-up window that appears, go to the Rules tab.

  4. If you want to focus on software that was blocked (or allowed), then in the menu next to Application Control Rules, select By Action or By Path to group similar rules. Alternatively, you can use the search to filter the list.

    If you want to change the action for a software file, but it has multiple different file names or paths, select By File Name or By Path to group related rules.

    application control rules actions

  5. Find the row for the specific software that you want to allow or block.

  6. In the Action column, change the setting to allow or block, then click OK.

    The next time that the agent connects with Deep Security Manager, the rule will be updated, and the version number will increase. Time required varies by:

    • heartbeat interval and bidirectional communications (see Agent-manager communication)
    • 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)

Undo many new rules and rule changes with the decision log

Allowing or blocking software can result in a complex transaction that creates many new rules, possibly on many computers, each with different rulesets.

You can undo previous changes by using the ruleset editor to delete individual rules or change their actions. However, if you need to:

  • undo many rules and ruleset changes
  • undo multiple actions
  • undo another administrator's changes
  • know more (such as who made the changes, or when)
you can save time and receive more information by using the decision log.

  1. Go to Events & Reports > Events > Application Control Events > Decision Logs.

  2. If you want to focus only on software that was accidentally blocked (or allowed), then in the menu next to Application Control Decision Log near the top of the page, select By Operation to group rules with identical actions. Alternatively, you can use the search to filter the list. You can also search for rules changed by a specific administrator account, or during a specific time period.

  3. Find the row for the changes that you want to undo. If the File Name column contains Multiple, click the Preview icon to see which files the change affected.

    application control undo

    If the operation was Allow All or Block All, many paths and computers might be affected.
    If the Status is Lapsed, the configuration was later changed. Because the earlier decision is not being applied now, you don't need to undo a lapsed decision.

  4. Click Undo.

    You can't undo an undo transaction in the decision log. If you change your mind later, instead recreate the change in the Actions tab or ruleset editor.

    The Status column will change to Undone, and if you click the Preview icon, it will display a message indicating that "The changes for this decision have already been reverted." The next time that the agent connects with Deep Security Manager, the rule will be updated, and the ruleset version will increase. Time required varies by:

    • heartbeat interval and bidirectional communications (see Agent-manager communication)
    • 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)

    Depending on what type of change was undone:

    • creating a rule (Decision Origin column contains "Action Page")
    • changing its action (Decision Origin column contains "Security Event" or "Ruleset Editor")

    a matching rule might no longer exist for the software. If so, it will reappear on the Actions tab.