Response Policies: Overview

Introduction

This article provides an overview of Active Response’s response policies, a brief overview of Active Response for cloud services, and a breakdown of each response policy with examples. To learn how to configure a response policy in the Field Effect MDR Portal, see Configuring an Active Response Policy.

Overview
Customizing a Response Policy
Response Policies for Cloud Accounts
- Understanding the Standard and Limited policies
Response Policies
Policy Categories

Overview

A response policy shapes the way Active Response is allowed to react to the threats and vulnerabilities Field Effect MDR detects in your environment. It's important to note that all detections will still take place, and Field Effect MDR will report all detected threats as an ARO. Setting a response policy allows your organization to allow/restrict response actions (block a process, isolate a host, etc.), based on your organization's tolerance for risk or potential downtime.

All of our policy categories are loaded on the endpoint and will not change based on the Active Response level (limited, balanced, aggressive). Essentially, response actions do not dictate what Field Effect will detect, but rather, how Field Effect will respond to all of these detections.

Choosing the Limited response policy, for example, would not change the amount of AROs you would receive, but it would change the way Field Effect can respond to them - you will still be alerted, but Field Effect would not intervene with a response action that is reserved for the Aggressive policy.

To learn more about how each separate response policy would treat common attack scenarios, see Active Response: Example Scenarios.

Setting a response policy will:

Inform Field Effect and our analysts of the level of intervention your organization accepts, and only allows the “limited” response actions to trigger.

Setting a response policy will not:

Change the way Field Effect monitors your organization’s network and endpoints. A client with a Limited policy will receive the same level of monitoring and detection that a client with the Aggressive policy would receive.
Allow Field Effect to perform response actions that affect your deployment. If an endpoint agent is required to initiate a response action, Active Response will not intervene by automatically installing the endpoint agent required to perform the response action.

Customizing a Response Policy

While setting up a response policy, you can customize these policies further by including exclusions and modifications. If you have an endpoint device or service that is absolutely critical to your business operations, you can exclude it from the policy. You can also work with our team to create more granular modifications if required.

Example exclusions for a response policy may include:

“Do not isolate IMPORTANT-SERVER (1.1.1.1) without our approval”
“Isolate any infected workstation, except this workstation(s)”
“Please contact if more than 3 servers require a response action”

To learn more about how to customize a response policy, see Configuring an Active Response Policy

Response Policies for Cloud Accounts

Active response must be enabled and configured before leveraging it for cloud services. See Configuring an Active Response Policy.

Once Active Response is enabled and a response policy is configured, it can be enabled for select cloud accounts. When enabled, Active Response can trigger response actions on cloud accounts. Responses vary from case-to-case, but an example of a cloud response action would be to lock an account that may be compromised.

Understanding the Standard and Limited policies

The main differentiation between the Standard and Limited policies for cloud accounts come down to the nuances and details of your Microsoft Entra Enterprise license; P1 or P2.

Limited Policy	Standard without P1 or P2	Standard with P1 or P2
- No Active Response - No integration with Defender for Cloud - No account risk details	No risk account information (no listing of which devices an account has registered for MFA)	All Active Response features will be enabled

Response Policies

This section introduces the available response policies but note that they can be adjusted with exceptions and exclusions. The following response policy descriptions represent each response policy without any custom exclusions or modifications added to them.

Note that if the DNS Firewall is enabled, DNS requests made to URLs that are known to be malicious, or added to you custom blocklist, will still be blocked, regardless of your organization’s chosen response policy.

Off (Default Policy)

Field Effect will passively monitor the environment and notify you of threats and vulnerabilities via AROs, but no response actions will be taken.

Limited

This policy gives our analysts permission to perform manual responses on your organization’s behalf. Analysts will manually initiate a response action only in situations that are confirmed, or highly suspected, as being malicious.

This policy takes the infrastructure (server vs. desktop) and potential business impact (vulnerability vs. active threat) into significant consideration when triggering a response action.

Example response actions for the Limited policy include:

Isolating a host that’s been infected with malware.
Blocking specific process(es) known to be malicious with a high degree of certainty.
Locking a cloud account showing strong indications of compromise.

Balanced (Recommended Policy)

This policy has all the characteristics of the Limited policy, only with more response actions available for use. This policy takes the infrastructure (server vs. desktop) and potential impact (vulnerability vs. active threat) into consideration when triggering a response action.

Example response actions for the Balanced policy include:

Isolating a server showing strong indicators of compromise.
Automatically locking a cloud account highly suspected of being compromised.
Blocking a compromised host within a network (example: suspicious use of PowerShell on a Windows host).

Aggressive

When this policy is set, Field Effect will, wherever possible, block any activity observed in your environment that could be seen as malicious or posing a threat to your organization’s cyber security. Less consideration is taken for potential business impact or host-level actions.

Example response actions from the Aggressive policy include:

Blocking anomalous processes and activity.
Locking an email account suspected of being compromised.
Disabling, or limiting the use of, tools and features known to be abused by attackers
- Blocking the use of PowerShell.
- Blocking the use of Remote Administration Tools (RATs).

Policy Categories

Our Security Services team brings a vast experience base to Field Effect, and this expertise has contributed to the creation of a robust and comprehensive set of detection polices for both known and theorized threats. Detection policies are categorized according to common malware and threat actor behavior.

Threat actors typically employ techniques across several of these categories and overlapping these detection policies provide a more in-depth defense. Tools and behavior-specific malware are included in our detection policies, but the focus is on restricting more general activities that are associated with, or are required to perform, malicious actions. This approach protects against known malware, as well as malware that has not previously been seen.

The following examples include activities that could trigger a response from the endpoint agent, when enabled and appropriate. These protection measures could include automated blocking and process termination by the endpoint agent. Analysts will also be alerted to assess the event and consider a host-based response. Actions taken depend on the level of confidence associated with the detection, and on your response policy.

All policies are always On, except for Endpoint Agent Protection, which is user selectable. Exceptions can be made to your response policy from within the MDR Portal.

Policy	Status	Description	Behaviors that would trigger Active Response
Endpoint Agent Protection	User Selectable	Keeps the endpoint agent running and stops any user (including admins) from tampering with the endpoint agent.	- Trying to stop the agent from running - Trying to uninstalll the agent
System Tampering Protection	Enabled	Threat actors may try to change system settings to avoid being discovered or allow activity that would otherwise be blocked.	- Attempts to disable crash and error reporting. - Attempts to lower security and authentication restrictions. - Attempts to disable security software. - Attempts to modify certificates and certificate chains.
Ransomware Protection	Enabled	Attempts to exfiltrate data from a network, delete or disable backups, and encrypt files.	- Suspicious use of commands and third-party tools commonly associated with ransomware attacks. - Encryption attempts by restricting expected software behavior.
Office Macros Protection	Enabled	Delivered via documents containing malicious macros, or other attached automation. This is often seen in phishing campaigns.	- Software from various office suites attempting to execute or modify other processes (beyond normal use). - Software attempting to gain file access other than the file type’s relevant editor and viewer.
Persistence Protection	Enabled	Threat actors typically install malware in ways that make it difficult to stop or remove. Operating systems allow software to be made persistent, but Field Effect blocks untrusted software from modifying any persistence mechanisms.	- Registry keys used to designate software for automatic start. - Boot record changes. - Addition/modification of scheduled tasks.
Privilege Escalation Protection	Enabled	Threat actors often need administrative privileges to access a system’s restricted functions and directories. This is often accomplished by exploiting software vulnerabilities.	- Common elevation techniques used by known malware. - Exploitation tools often bundled with elevation capabilities. - Suspicious commands used to test account permissions and access. - Suspicious commands typically necessary for elevation.
Propagation Protection	Enabled	After compromising a system, threat actors will try to spread across other systems within the network.	- Attempts to remotely execute commands or modify persistence mechanisms on another system. - Attempts to run suspicious commands on another system. - Suspicious use of Remote Management Tools (Tools for Remote Administration). - Attempts to install and start web shells and common web shell activity associated with propagation.
General Malware Protection	Enabled	Many techniques are seen across multiple categories of malware. This is a broad category designed to consider more general behavior that could be malicious.	- Attempts to download and execute code from a remote source. - Attempts to modify software, injecting new code into it or replacing running software in memory. - Attempts to load or execute untrusted libraries or other modules. - Suspicious actions being attempted by unsigned or untrusted software. - Suspicious use of scripting interpreters, such as PowerShell. - Code execution techniques, such as proxy execution by signed Microsoft script engines. - Suspicious web browser actions. - Techniques associated with known malware and threat actors. - Activity associated with known exploitations tools (Cobalt Strike, Mimikatz, etc.).