Controlling access to the registry base

This protection type makes it possible to control specific applications’ access to keys and values in the registry base. As such, access to particularly sensitive keys can be protected, as they are a prime target of malicious programs.

EXAMPLE
To prevent a malware program from disabling Windows security tools via the registry base, you can protect their registry keys so that they can only be modified by legitimate Windows applications.

Every registry path can be a full path or contain the generic characters "?" and "*".

Application identifiers must be created beforehand for applications that are allowed to access registry and for those that you want to block. For more information, refer to the section Creating application identifiers.

  1. Select the Security > Policies menu and click on your policy.
  2. Select a rule set.
  3. Click on the ACL resources > Registry tab.
  4. If you are in read-only mode, click on Edit in the upper banner.
  5. Click on Add > Rule (Registry).
    A new line is displayed.
  6. In the left-hand area, click on the icon to display the window for creating the identifier of the registry keys whose access you wish to control.
    - And/or -
    Click on the icon to display the window for creating the identifier of registry keys you wish to exclude from access control.
  7. Enter the ID name.
  8. Enter the path to the key.

    TIP
    The path to the key can be copied from the registry base and pasted in the Key field.


  9. Choose where to apply these rules:
    • Key and Values. These rules cater to the most frequent protection needs. If you do not enter a value, all the values of the key will be protected, including the key itself. If you enter a single value, the other values of the key will not be protected.
    • Key: These rules provide more advanced protection. Only the key is protected, but its values are not.
    • Values: These rules also provide more advanced protection. Only the values are protected, but the rule does not protect the key itself. Even if the values of a key are protected from deletion, if the deletion of the key itself is allowed, the values may be deleted together with the key.
  10. Click on OK to close the ID creation window. Scroll over the name of the ID to see a summary of the settings.
  11. In the Default behavior field, select a behavior from those available for this type of rule: :
    • Allow to allow the action by default,
    • Block to block the action by default,
    • Block and kill to block the action by default, and shut down the process that launched the action.
    • Block, kill and quarantine to block the action by default, kill the process that triggered the action, and quarantine suspicious files. For more information, see the section Managing file quarantine.
    • Ask for the user to be consulted.
    • Skip behavior to ignore the subrule if the behavior is detected and move on to the next behavior.
    • Skip rule to ignore the rule contained in this rule set and evaluate the next rule.
    • Skip rule group to ignore the rules contained in the rule group and evaluate the next rule group or rule.
    • Skip rule set to ignore all the rules contained in this rule set and evaluate the next rule set.
  12. Click on + Add specific behavior and choose the resource(s) that you want to exclude from the default behavior. Select the behavior for each case.

EXAMPLE
By default, block access to the registry keys of Windows security tools such as Windows Defender, Windows Firewall, etc. Allow only legitimate processes to perform these operations, e.g., Windows update and software installer, security solutions, etc.
Use case protection of the registry base

  1. In the upper banner in the rule, you can:
    • If necessary, rearrange the order of the rules by clicking on icon to reorder rules when the cursor hovers the rule. Each rule displays its line number in the banner.
    • Disable rule. For more information, refer to the section Disabling security rules.
    • Indicate the intent of the rule, according to predefined categories:
      rule intent drop-down list

      • Unclassified: unclassified rule.

      • Nominal: non-blocking rule conforming to nominal application behavior.

      • Protect: blocking rule with a high log severity level.

      • Protect silent: blocking rule with a severity level below the log thresholds displayed by default on the agent and console. Protects access to resources deemed sensitive, even if carried out by programs with no malicious intent. As there may be many such programs, a rule with too high a log severity could trigger massive log generation.

      • Detect: non-blocking audit rule or passive rule.

      • Context: rule used to build an attack graph.

      • Syslog: rule triggering logs sent exclusively to a Syslog server.

      • Watch: rule for monitoring behavior in order to fine-tune the security policy or gain a better understanding of technical events occurring in the pool.

      Selecting one of these categories has no influence on rule configuration. They simply enable the administrator to classify their security rules according to their purpose, and sort them using the dedicated Rule intent filter. The rule intent is also displayed in the log details.
    • Enter a description to explain what this rule aims to achieve.
    • Make the rule passive. Passive rules behave like standard rules but do not actually block any actions. The agent only generates logs that indicate which actions security rules would have blocked.
      Use this mode to test new restriction rules, determine their impact, and make the necessary adjustments before disabling Passive rule mode. For further information on testing rules and policies, refer to Testing security policies.
    • Indicate whether the rule must generate a context when it is applied. By default, if a rule generates Emergency or Alert logs, it will generate a context, but you can disable this feature. In case of mass generation of similar logs, the context is not generated. For more information on mass log generation, refer to the section Monitoring SES Evolution agent activity.
    • Adding a comment.
    • Select the log settings that this rule will send.
    • Specify whether an action must be performed when a log is sent for this rule. You can request that a script be run and/or that a Yara or IoC scan be triggered. You can also request that a notification be displayed on the agent, provided that it is associated with a an Alert or Emergency level blocking log.
    • Deleting the rule.
  2. Expand the Classification in logs part to indicate the intent of the suspected attack when the rule applies, along with the tags for associating the rule with the MITRE repository. This information is then visible in the logs generated by the rule. For more information, see Classifying attacks according to the MITRE repository.
  3. Click on Save at the top right of the window to save changes.