You can configure the actions that MDR analysts can take in your environment by policy.
Note:
- This topic lists best practices for policy settings if you are using MDR and MTH. For instructions on how to create and modify policies, see Managing Policies.
- Always place systems into the appropriate policies and implement custom policy rules to provide the highest level of protection.
General Settings - MDR
For each policy, determine which containment actions you’d like to authorize the MDR analyst team to perform. By default, MDR analysts can ban hashes of malicious processes in your environment.
Target values are defined by the policy to which an asset belongs. The target value specified impacts the alert severity.
On the General tab of a policy, place all endpoints in a medium, high, or mission critical Device target value, with a minimum of medium, and avoid using the low target value.
Policies with high value systems include:
- AD controllers
- Servers that host sensitive data
- Production servers
General Settings
On the General tab of a policy, under Managed Detection and Response, select the following criteria:
- Quarantine assets: MDR analysts can quarantine any asset in this policy to quarantine a threat. To minimize business impact, quarantine is generally used as a last resort if analysts cannot contain the threat by banning the hash or modifying the policy.
For more information about quarantining assets, see Quarantining an Asset.
- Modify policy: MDR analysts can modify the contents of this policy. To minimize risk, the analyst first clones the policy, modifies the copy, and moves the impacted asset to the new policy.
Prevention Settings - MDR
For a comprehensive description of all Prevention settings, see Prevention Policy Settings.
In addition to the default rules, activate the Core Prevention rules and add the Blocking and Isolation rule on the Prevention tab to get the highest level of protection from Carbon Black Cloud Endpoint Standard and MDR. See Core Prevention and Set Blocking and Isolation Policy Rules.
Place sensors into a policy group that contains blocking rules, such as the Standard policy, or into a custom policy that has a comprehensive set of blocking rules.
Add any approved applications with ADWARE or PUP reputations to the Approved List before adding additional Adware or PUP blocking rules. See Adding to the Approved List.
We recommend that you test a new rule's settings before you apply it in your environment. Click Test rule for any setting. The system checks to see how the rule would affect your organization over the last 30 days. You can use this data to confirm or modify your settings.
You can perform a search query on the Investigate page to assess the impact of a rule to your environment before adding a new rule.
Sensor Settings - MDR
For a comprehensive description of all Sensor policy settings, see Sensor Policy Settings.
Activate the following:
- Delay execute for cloud scan to make sure that the sensor requests updated reputation data from the cloud before execution. This setting is effective against new and emerging threats.
- Run a background scan to make sure that the sensor scans the environment upon deployment and detects any malware, suspicious files, or PUPs resident on disk. However, in some VDI environments, this might not be a recommended option. Consult with your Technical Services Consultant if you have questions.
- Scan execute on network drives because many ransomware campaigns rely on network shares for file distribution. Activating this setting makes sure that all files are scanned when executing from a network share, thereby preventing any file with a malicious reputation from executing.
- Submit unknown binaries for analysis. This policy setting is effective against new and emerging threats and polymorphic attacks.
- Require code to uninstall sensor. This setting helps to protect against unauthorized removal of the Carbon Black Cloud sensor.
- Activate auto-delete known malware hashes after one weekday. Before activating this option, review all files flagged as
KNOWN_MALWAREby Carbon Black Cloud.
Important: Do not activate private logging because it reduces the MDR team's visibility and ability to identify malicious behavior. Private logging redacts command lines, filenames, IP addresses, and additional information that is important for the MDR team to fully investigate alerts and associated events. Private logging decreases the ability to assess events for possible malicious activity, and greatly reduces the level of insight that MDR analysts can provide.
