MDR Deployment Guide

This page outlines the deployment tasks for Managed Detection and Response (MDR).

Overview

For a successful InsightIDR deployment, you will need to complete the following tasks:

In addition to these required tasks, Rapid7 recommends that you also complete the following:

Pre-Deployment Tasks

Before configuring InsightIDR, you must complete the following pre-deployment tasks for all in-scope Windows Domains, locations, and assets for deployment:

Once you have completed these tasks, you are ready to start your InsightIDR deployment.

Required Deployment Tasks

The following tasks are required for MDR deployment.

1. Set Up Collectors

Insight Collectors collect log information from event sources and endpoint data from Insight Agents and send it to Rapid7's cloud platform for processing. InsightIDR Collectors are required for the collection of log data into InsightIDR. In addition, the Collectors can be used as a proxy for Insight Agent data.

For this step, you need to first determine how many collectors are needed and where to place them. Next, configure and activate all collectors needed for InsightIDR deployment.

MDR Requirements

You must add at least one Collector to collect log and endpoint data. The collector must meet the minimum specifications. Please note that Rapid7 recommends that you use a dedicated server for your Collector when possible. You should also install an Insight Agent to the Collector, as the Insight Agent is not installed as part of the Collector software package.

  1. Determine how many collectors are needed and where to place them. You will need at least one Insight Collector but may have more depending on your organization and infrastructure.
  2. Configure the collector. Collectors may be configured in local or cloud infrastructure and on Windows or Linux operating systems.

If you need additional guidance on Collector placement or sizing, please contact your Rapid7 Product Consultant, Project Manager, or Customer Advisor before proceeding.

2. Install Insight Agents

The Rapid7 Insight Agent is downloadable software that is installed onto supported assets. As explained in detail here, the Insight Agent runs a set of forensic jobs that allow it to monitor activity on the host and send this information back to InsightIDR through either a Rapid7 Collector or directly to the Rapid7 cloud. The Rapid7 Insight Agent is used to monitor activity on the endpoints where it is installed. You can view a subset of the detections that an agent is required for in the Rapid7 Detections Library.

MDR Requirement

Rapid7 MDR recommends full deployment of Insight Agents to all in-scope assets, including all workstations, laptops, and servers. Your team may elect to move your environment into monitoring before this threshold is reached; however, for a partial deployment of the Insight Agent to the environment your organization understands, agrees, and accepts the limitations and risk of service degradation. Specifically, the following aspects of the MDR service are unavailable to assets without the Insight Agent installed:

Detection Aspect

Limitation

Attacker Behavior Analytics

A significant portion of MDR’s threat detection power lies in the ability to detect specific events (file system changes, network connections, process start/stop) on each of the assets. This data can only be provided by the Insight Agent.

Manual Human Threat Hunting

The MDR monthly threat hunts rely on the endpoint agent to collect the data in scope for threat hunts. Assets without the Insight Agent will be excluded from threat hunts. Threat hunting requires deployment of the Insight Agent to at least 80% of the in-scope environment.

Threat Intelligence Matching

All executable processes run on any asset with the Insight Agent are matched against known threat intelligence. Assets without the Insight Agent will not have running processes matched against threat intelligence.

Alert validation and Remote IR investigations

MDR’s incident investigations rely on the Insight Agent to collect data for analysis. Assets without the Insight Agent will be out of scope for both the typical validation process conducted by the SOC team for an alert as well as any Remote IR investigation.

Local authentications and group membership changes

The Insight Agent is required to identify authentications using local accounts, such as a local administrator account, and is required to identify local group membership changes (for example, a user added to local administrators group). Assets without the Insight Agent will be excluded from local authentication and UBA, where UBA is the act of tracking per-user and per-system actions to build statistical models of user activity and identify anomalies.

Attacker ingress detection

The most common methods of compromise are via Phishing (malicious emails) and malicious web sites, both of which require end-user interaction to succeed. As the majority of internet browsing and email activity occurs on end-user workstations, Rapid7 is unable to identify initial method of compromise and lateral movement from those systems to servers and other critical assets without the Insight Agent.

In addition, while Rapid7 highly recommends configuring endpoint data collection by installing the Rapid7 Insight Agent on all endpoints in the organization, in order to receive the initial compromise assessment, MDR customers must install Insight Agents on at least 80% of their assets, including workstations, laptops, and servers. MDR customers should not use the Endpoint Scanning feature but must instead install the Insight Agent onto their assets.

Additional Information

You are responsible for downloading and installing the Insight Agent onto all of your endpoints -- including all workstations, laptops, and servers -- using your preferred packaging and installation software. You should whitelist the Insight Agent in any technology that will interfere with its ability to operate including malware/endpoint detection software, antivirus software, SSL encryption/decryption tools, SSL inspection products, etc. The Insight Agent must be able to communicate directly with a Collector or to the Rapid7 platform.

You can use the Agent Management page in InsightIDR to view installed agents that are communicating with the Rapid7 platform. If there is an issue with deploying the agent, Rapid7 can provide assistance with downloading the Insight Agent and with installation and functionality issues.

An optional feature of the Insight Agent is its ability to collect local log files. You can read more about this feature here. While these extra logs are not required by Rapid7 or the SOC, they are sometimes useful during an investigation. If you wish to collect these logs, you can enable this feature at any time by configuring the logging.json file as described in the documentation.

Event sources in InsightIDR are used to collect data from devices in your organization. The data collected is commonly logs and security events, but event sources can also be used to collect other information. The collection of logs is very important to the MDR service, as these logs are used for many of the pre-configured detections and also can provide additional information during investigations.

You should carefully review this information and add all available event sources to InsightIDR. The individual guides for adding all event sources can be found here.

Event Sources Used for User Attribution

If provided with LDAP, Active Directory, and DHCP events, InsightIDR can perform User Behavior Analytics on incoming events. If you are able to add these devices to InsightIDR, Rapid7 highly recommends that all be added. These event sources can also be used by the Rapid7 SOC for investigations.

The Rapid7’s MDR service heavily leverages InsightIDR’s full suite of User Behavior Analytics (UBA) alerts. The User Behavior Analytics (UBA) alerts are dependent upon ingesting and parsing events primarily from the Microsoft Active Directory and LDAP directory services. Limitations due to missing or non-supported directory services include, but are not limited to, those listed below:

Service

Limitation

Anomalous Account Activity Detection

Detections which look for anomalous activity associated with user accounts, such as account creation, disablement, lockout, and privilege escalation are unavailable without a supported directory service. Detections associated with local accounts are monitored by the Insight Agent and therefore remain available.

Credential Harvesting and Lateral Movement

UBA detections built to look for suspicious ingress authentications, brute force attempts, and lateral movement using non-local accounts are unavailable without a supported directory service. Detections associated with local accounts are monitored by the Insight Agent and are unaffected. Additionally, the MDR team can leverage additional event sources acquired via forensic job data can be leveraged to detect certain events in this category, but this requires manual action by the MDR team.

Deception Technology

Some deception technologies (e.g. the deployment of a honey user account) are reliant upon a supported directory service, and are therefore unavailable.

Investigation and Response

During the course of an investigation, the MDR team leverages tools which rapidly gather and parse logs from a range of event sources in order to quickly determine what activity occurred on any affected endpoints as well as the source and subsequent lateral movement associated with any compromised accounts. Should a non-supported directory service be used by the customer, investigation time may be hindered. While the team may be able to easily determine via Insight Agent process start events which accounts are associated with malicious activity (including non-local accounts), in the event that non-local accounts are used for ingress and/or lateral movement, the team cannot easily gather that information. Additionally, Active Response actions taken by the MDR team to remotely isolate compromised user accounts are unavailable without a supported directory service.

Active Response

If a customer opts in for the Active Response service and does not have Active Directory or LDAP, the Active Response service will not be able to perform user containment actions.

LDAP

Add the LDAP event source for each Windows Domain to pull user and group information from the domain into InsightIDR. Without this event source, InsightIDR cannot perform its User Behavior Analytics (UBA) functions as this event source is how InsightIDR learns about users for its attribution.

MDR Requirement

Rapid7 recommends that you add this event source if the supporting technology for it exists in your organization.

In order to add the LDAP event source, you must be using one or more of the following:

  • Traditional Windows domain with domain controllers, which is sometimes also called Active Directory Domain Services (AD DS)
  • Azure Active Directory Domain Services (Azure AD DS)
  • Self-managed Azure Active Directory Domain Services
  • Amazon Web Services Directory Services (AWS DS)

The event source called LDAP does not collect log data. Instead, it is an LDAP query to the domain in order for InsightIDR to learn about user accounts in the organization. You must add at least one LDAP event source for each Windows, Azure, or AWS domain.

Active Directory

The Active Directory event source is used for many of the pre-configured detections explained in the Detection Library. In addition, it is required for the User Behavior Analytics function of InsightIDR.

MDR Requirement

Rapid7 recommends that you add this event source if you have Windows domain controllers in your organization. The event source called Active Directory is the collection of the domain controller Security event log. You must have Windows domain controllers in order to add in this event source. You must add in one Active Directory event source for every domain controller in the in-scope environment.

Additional Information

InsightIDR has several ways that you can collect these events. Please see the Active Directory documentation for options on setting up this event source.

DHCP

The DHCP event source is used to determine what host is using IP addresses specified in the log data. InsightIDR must know what host is using an IP address in order to determine UBA activity for event data.

In order for InsightIDR to perform IP address to hostname attribution, it uses the following methods:

  • DHCP event sources

  • VPN event sources

  • Information supplied by Insight Agents when they are connected to InsightIDR via a Collector

  • Network sensors when they are able to monitor DHCP and related network traffic

  • Reverse DNS queries performed by the Collector (s) when Static IP Ranges have been configured The IP address to hostname attribution is a requirement for UBA. This information can also speed up investigations of suspicious activity.

MDR Requirement

Rapid7 recommends that you add this event source if the supporting technology for it exists in your organization.

You should add in one DHCP event source for each DHCP device/server that you have in your organization. There is a workaround that you can use for this if you have DHCP devices for which you are unable to collect the DHCP lease events.

For this workaround you must do all of the following:

  1. Install the Insight Agent on all workstations, servers, and laptops in the organization.
  2. Connect Insight Agents to a Collector to proxy their data to the Rapid7 cloud platform. Connecting directly to the platform is not acceptable for this workaround.
  3. Add in all network segments with endpoints to the Settings > Static IP Ranges section in InsightIDR.

Event Sources Heavily Leveraged in SOC Investigations and Detections

In addition to the event sources that are required for User Behavior Analytics, InsightIDR allows you to add in event sources that have high forensic value. These event sources are used in many of the pre-configured User Behavior and Attacker Behavior Analytics alerts. Additionally, these event sources provide particular value and added context when investigating an open alert. The event source types that are considered to be of high forensic value are DNS, Firewall, Web Proxy, VPN, and Cloud Services.

These types of event sources are particularly useful to the MDR SOC during the course of conducting investigations, assisting SOC analysts in uncovering the full scope and impact of an event or incident. For example, if during the analysis of an incident a remote command-and-control (C2) domain or IP address is identified (either through analysis of commands executed on a compromised host, or through static/dynamic analysis of malware or attacker tools), SOC analysts can query available DNS, Firewall, and/or Web Proxy logs to determine if the compromised host attempted connections to the C2 domain/IP, and whether those connections may have been dropped or blocked. The same logs are highly valuable when investigating phishing incidents for the same reasons, and in these investigations Web Proxy logs provide the additional ability to view the types of requests that were made to malicious infrastructure, potentially enabling analysts to determine whether or not a phished user may have actually input their credentials to a harvesting page vs. simply navigating to it.

This type of data provides additional context to enable analysts to adjust incident criticality (for example, what may have been a high criticality could be lowered to a medium or low criticality if network traffic was determined to have been blocked), and also allow them to query the associated IOCs to help determine if any additional users or assets may have been similarly compromised in a given environment. These event sources can also be leveraged by the Threat Intelligence and Detections Engineering (TIDE) team to create permanent as well as on-the-fly detections based on indicators curated during the course of a high-severity incident to enable additional alerting to quickly identify future potential compromises.

VPN and Cloud Services logs are exceedingly useful to enable the SOC to adequately detect and investigate potential user account compromise and Business Email Compromise (BEC). Attackers often harvest credentials which are then used to compromise corporate networks via VPN, or to compromise cloud service accounts and conduct data theft or BEC. VPN and Cloud Service event sources allow the MDR SOC to determine methods/modes of ingress into an environment, investigate activities performed by threat actors post-compromise, and enables the TIDE team to build detections to alert on suspicious ingress authentications and BEC-related activity.

Key takeaway: In many cases, feeding these relevant event sources into InsightIDR can mean the difference between timely alerting/investigation and the resultant use of a Remote Incident Response (RIR) engagement.

MDR Requirement

DNS, Firewall, Web Proxy, VPN, and Cloud Services event sources are highly recommended if you can add them.

4. Configure Settings Page in InsightIDR

The Settings page contains both required and optional configuration settings. Review these settings to verify that they are configured for the organization being monitored.

Configure Inactivity Alerts

Inactivity Alerts are used to notify you that an event source is no longer sending logs to Log Search. If you wish to be notified that an event source is down, then you should configure Inactivity Alerts.

To configure Inactivity Alerts:

  1. Select Log Search
  2. Select Add Alert from along the top of the page.
  3. Select Inactivity Detection Alert.
  4. Proceed through the wizard, filling out required fields and selecting the logs or Log Sets for which you wish to create the Inactivity Alert.

The most common way to create the alerts to create a separate alert for each log type so that you can be more granular with the “trigger settings”, or how long the source can be silent before generating an alert.

Credential Settings

The Credential Settings page lists all credentials added to the InsightIDR deployment for either log collection or endpoint scanning. If the password for these credentials needs to be deleted, modified, or changed, edit the credentials from this page.

Asset Settings (Optional)

Asset Settings has a configuration option that can be used with the Nexpose/InsightVM event source. This setting allows criticality tags to be used in Nexpose/InsightVM to automatically mark those assets in InsightIDR as Restricted Assets.

Configure Public IP Ranges

If public IP address ranges are used internally instead of private IP address ranges, enter those ranges on the Public IP Ranges page.

Note: This is not common.

Configure Static IP Ranges

The Static IP Ranges page is used to enter any IP address ranges of monitored assets that have their IP addresses statically assigned, such as workstations, laptops, and servers. In addition, this page has a special use to assist with IP address to hostname attribution. If InsightIDR is unable to determine the hostname associated with an IP address using other methods and the IP address range for the IP has been added as a Static IP Range, the Insight Collectors will do a reverse DNS lookup of the IP address to try to determine its hostname.

The Unknown IP Addresses page can be used to determine what ranges are in the organization that have IP addresses for which InsightIDR was not able to get a hostname. If these ranges are handed out by DHCP or VPN servers, add the corresponding event sources and ensure they are operational. Otherwise, these IP address ranges may need to be added as Static IP Ranges.

Note that if the IP address ranges listed are not of interest to InsightIDR because they are not used for endpoints or other assets monitored by InsightIDR, you can add these ranges to the Unmanaged IP Ranges page and they will be removed from the Unknown IP Addresses page.

Configure Network Zones and Network Policies (Optional)

On the Network Policies page, configure who should or should not be accessing any defined Network Zones. InsightIDR sends alerts if it identifies authentication activity to the zone outside of what is configured in the policy.

Configure Tagged Domains

If InsightIDR detects browsing activity to domains that are 'near misses' to your Tagged Domains, such as accessing 'rapid7.co' instead of 'rapid7.com', it sends an alert as this could be an indicator of a phishing attack. You should enter in all owned and managed web domains.

Configure S3 Archiving (Optional)

InsightIDR can be used to keep a copy of the log data in an owned and controlled Amazon S3 bucket. To configure this option feature, configure the AWS S3 bucket, then configure InsightIDR to place a copy of the log data into this bucket. When this option is configured, InsightIDR begins copying log data starting the day it is set up. It does not copy historical logs to the AWS S3 bucket. Therefore, you should configure this setting during your initial InsightIDR setup if you wish to have a copy of all of your log data in your own S3 bucket.

The following are additional deployment tasks for MDR.

1. Configure Additional Event Sources

In addition to the recommended event sources, InsightIDR supports the collection of logs, events, alerts, and related data from many other types of devices. Although these event sources are not required for the MDR service and are not used by the Rapid7 SOC for investigations, you may wish to use InsightIDR to collect these logs. While optional, these event sources allow the collected logs to be viewed in Log Search, Dashboards, and can be used as part of Custom Alerts. In addition, you can use the InsightIDR Custom Parsing Tool to parse these logs.

The Rapid7 SOC does not perform hunts or investigations on event sources other than those listed in the Recommended Event Sources. The Rapid7 SOC also does not monitor Custom Alerts; if you need the SOC to monitor activity based on Custom Alerts, please discuss this request with your Customer Advisor. Also, please note that Rapid7 does assist with the setup and configuration of these additional event sources. However, custom integrations are provided as part of a separate paid service and are not part of the standard MDR deployment.

2. Configure Additional Settings

InsightIDR has other configuration settings in addition to those configured on the Settings page. Review this list of optional settings and configure those that apply.

Platform Home Configuration Settings

Instructions for changing the Rapid7 Platform settings can be found here.

Platform Admins can configure settings on the Platform Home. While logged into InsightIDR, click the drop-down arrow next to the InsightIDR logo on the top bar of InsightIDR and select My Account to get to the Platform Home.

Access the Settings page to change the Company Profile, configure Multi-Factor Authentication Or Single Sign On, or change the password policy for Platform accounts. The User Management page can be used to change who can access InsightIDR or other Rapid7 Insight products. These users can also open Rapid7 technical support cases. When reviewing the list of users configured for InsightIDR, you may notice one or more accounts that start with svc_idr; do not delete these accounts as they are used by your Rapid7 Account Team.

Threats

Threats are used to monitor access to known or suspected indicators of compromise, such as known or suspected maliciously used IP addresses, URLs, domains, or hashes. These can be viewed in InsightIDR on the Settings - Alert Settings - Community Threats page. Rapid7 recommends that you not configure any threats without first discussing this feature with your MDR Customer Advisor.

Service Accounts

InsightIDR uses information pulled back by the LDAP event source to determine if an account is a Service Account. If InsightIDR identifies an account with Password Set to Never Expire and that the First Name and Last Name fields are blank or contain information that does not appear to be common first or last names, the account is marked by InsightIDR as a Service Account. This marking is only in the InsightIDR product and is used by the behavior analytics alerts. Some behaviors should not be observed on Service Accounts, such as authentication using VPN, which will generate alerts in InsightIDR.

Windows domain accounts marked as Service Accounts can be viewed on the Users & Accounts page. Select Non-Expiring Users, then use either the filters on the left or the columns on the right to view accounts InsightIDR marked as Service Accounts.

InsightIDR can incorrectly mark some regular users as Service Accounts or miss marking service accounts. After adding in the LDAP event source for a Windows Domain, review the Service Accounts listed on the Non-Expiring Users page to fix any accounts that did not get properly marked.

3. Configure Deception Traps

InsightIDR currently has four types of deception traps that can be configured to gain additional visibility into user behavior. Each deception trap monitors for a different kind of suspicious user activity that can be difficult to analyze and detect otherwise.

  • Honeypots are used to detect internal scanning. Consider setting up a Rapid7 honeypot on each major segment or location of the network. *Recommended for MDR
  • Honey Users are useful to detect improper user account snooping and authentication. Consider adding at least one honey user, keeping in mind that more may be needed. *Recommended for MDR
  • Honey Credentials are used to detect pass-the-hash attacks on Windows assets. To enable this feature, open a Rapid7 support case and ask to have the feature enabled.
  • Honey Files are used to catch ransomware or improper insider file snooping. This trap has more overhead than the others, so read the configuration details for it before proceeding.

4. Configure Orchestration and Automation

Automated workflows can be leveraged in InsightIDR using Rapid7's InsightConnect product. Some workflows are provided to InsightIDR users in the product and more can be added by purchasing the InsightConnect product. You can read more about automation with Rapid7 products.

To use most of the automated workflows, you must first configure a separate server called an Orchestrator. Follow the instructions in the documentation to configure and activate the Orchestrator. Next, depending on the needed workflow, configure connections to be used for automation. Test out the workflows by opening an investigation and selecting Take Action. If you are an MDR Elite customer and plan to use Active Response, please see the Active Response Deployment Guide.

5. Set Up File Monitoring

If monitoring file or folder access is required, consider configuring one of two options available in InsightIDR: File Integrity Monitoring or File Access Activity Monitoring.

File Integrity Monitoring uses native Windows auditing, which is enabled by configuring the Audit File System policy to monitor for file modifications. Use either Local Security Policy or Group Policy to enable the Audit File System policy, then specify which files or folders to monitor. The Rapid7 Insight Agent then collects these access events from the local Security log. File Integrity Monitoring is useful to meet regulatory compliance standards. It is intended to be configured for files that are not expected to change to ensure that no improper changes are made to them.

File Access Activity Monitoring uses native Windows auditing, which is enabled by configuring the Audit Detailed File Share policy. When this policy is enabled on a Windows system, access to all files and folders from a network share are tracked with the creation of events that go into the local security log. This is a system-wide change rather than one enabled on individual files and folders. Also, all file activity is tracked by the operating system. These events are collected by the Rapid7 Insight Agent from the security log. Enabling this level of auditing can cause the creation of a larger volume of events in the security log, which can impact the performance of the host. Enabling File Access Activity Monitoring is required for the Rapid7 Honey Files feature. It is also useful for systems that require all file sharing access to be monitored.

Neither of these file monitoring log sets are monitored by the Rapid7 SOC and none of the logs are used for pre-configured alerts. If you wish to monitor these events yourself, you can create Custom Alerts or Dashboards to do so.

6. Configure Dashboards and Custom Alerts in InsightIDR

A final common task is to configure desired Dashboards in InsightIDR. These are not used by the Rapid7 SOC, but can provide you a way to see your log data or to create reports. Your MDR Customer Advisor or Product Consultant can also suggest additional dashboards to you if desired.

In addition, you can also configure Custom Alerts in IDR. Custom alerts can be added at any time and allow you to create additional alerts for yourself or your team outside of the alerts monitored by the Rapid7 SOC.