MDR Deployment Guide
This page outlines the deployment tasks for Managed Detection and Response (MDR).
Prepare for Deployment
To ensure you get the most out of your first 90 days with InsightIDR, it’s important to understand your deployment tasks and create a plan for deployment.
Supported Browsers
Rapid7 supports InsightIDR in Google Chrome (latest stable release) and Mozilla Firefox (latest stable release).
Set up a service account
Before provisioning resources and deploying InsightIDR, you must set up a Service Account to collect log data for InsightIDR. You can either designate an existing user account, or create a Service Account.
Review the Service Account requirements and set up an account.
Review system requirements
Each component of InsightIDR requires specific resources. Navigate to each component's designated page for a full list of each components' requirements.
| Component | Required Resources |
|---|---|
| Collector | - 4 CPU cores with 2GHz+ on each core - 8 GB RAM required/ 16 GB recommended - 60 GB+ available disk space - Configured with a Fully Qualified Domain Name (FQDN) such as idrcollector23.myorg.com |
| Insight Agent | Required ports for Collector communication through TCP (Click here to review the full list in detail): - 5508 - 6608 - 8037 (TCP and UDP) |
| Service Account | If you have a Microsoft Windows domain or Microsoft DHCP/DNS, you can either designate an existing user account as a service account, or create a new account account as your service account, that meets all of the following requirements: - Active Directory Permissions - LDAP Permissions - Microsoft DNS Permissions - Microsoft DHCP Account Permissions See Setting Up a Service Account for more information. |
| Event Source | Designate a Setting Up a Service Account with correct permissions See Event Source requirements for more individual event source requirements. |
| Honeypot | - 1 CPU - 1GB RAM - 10 GB hard disk space |
| Insight Orchestrator | At least 1 Orchestrator is required for Active Response |
| Insight Network Sensor | Networks Sensors are optional, but recommended. Although the network sensor software itself runs in the form of a container, all physical or virtual network sensor hosts must run one of the following supported Linux operating systems. The version number shown for each one indicates the minimum supported version: - Ubuntu Server 20.04 and later - RHEL 7.2 and later - CentOS 8 and later - Fedora 30 and later - SUSE 15.0 and later - Debian 8.11 and later See Network Sensor Host Requirements for more information. |
Provision resources in your environment
We recommend provisioning specific resources as soon as possible to ensure a quick and easy deployment experience. And complete an inventory of the environment to identify all devices in-scope for deployment.
These core components require provisioning hardware (not limited to 1 and in many cases will be multiple):
- 1 server to install the InsightIDR Collector
- 1 server to install the Insight Orchestrator (needed for Active Response)
- A virtual or physical Linux host to install Insight Network Sensor software (Optional)
- A source of network traffic for the Insight Network Sensor
Log in to the Insight Platform
Already have an Insight Platform account?
If you already have a platform account from a trial or existing subscription to another Rapid7 solution, you’re all set! Use your existing email address to log in to https://insight.rapid7.com/login.
The Rapid7 Insight Platform is your base within the ecosystem of Rapid7 cloud products and services. It provides a centralized location for administrative functions and makes navigating the Insight product suite simple and easy.
To log in to the platform, you need a Rapid7 Insight Platform account.
To create an account:
- Check your corporate email inbox for an email from the Rapid7 Insight Platform team.
- Visit
insight.rapid7.com/login. - Select Haven’t activated your account?.
- Enter your corporate email address to receive an activation email with next steps. If you do not receive an activation email, reach out to your Customer Adoption Manager (CAM) or Customer Success Manager (CSM).
- Refer to the activation email and follow the instructions to create and activate your Insight Platform account
Configure daily data archiving
InsightIDR stores your log data for a retention period of 13 months. If you need to retain data for longer than that period, such as for security investigation or compliance purposes, we recommend that you set up daily archiving. Archiving allows you to retain a copy of your log data using the storage capabilities of Amazon S3.
To set up data archiving, see Data Archiving.
Daily Archiving versus Historical Data Archiving
If you do not configure daily archiving, you can download a backup of your data up to 2 times a year using InsightIDR's Historical Data Archiving feature. This process can take several days to complete.
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.
- 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.
- 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 Security Posture 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 configuration required for MacOS 15 or higher
If you are installing an Insight Agent on macOS 15 or higher, you must give the Insight Agent Full Disk Access (FDA).
Use an MDM for configuration
To configure the Insight Agent with MDM software, download the Insight Agent FDA.mobileconfig file. Depending on the MDM you are using, the following configuration may be required:
- Identifier:
/opt/rapid7/ir_agent/ir_agent- Note: if you have downloaded the installer to another file location, ensure you enter the correct path to the
ir_agent.
- Note: if you have downloaded the installer to another file location, ensure you enter the correct path to the
- Identifier type:
path - Code requirement:
identifier bootstrap and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists / and certificate leaf[field.1.2.840.113635.100.6.1.13] / exists */ and certificate leaf[subject.OU] = UL6CGN7MAL
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.
3. Add Recommended Event Sources
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:
- Install the Insight Agent on all workstations, servers, and laptops in the organization.
- 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.
- 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:
- Select Log Search
- Select Add Alert from along the top of the page.
- Select Inactivity Detection Alert.
- 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.
Recommended Deployment Tasks
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 basic detection rules in IDR. Basic detection rules 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.