Microsoft Security

The Microsoft Security Event Source collects data from the Microsoft Security product suite using the Microsoft Graph API. This event source creates events from all Microsoft Security products, including Defender for Endpoint, Defender for Cloud, Defender for Identity, Defender for Cloud Apps, Defender O365, and Defender for Vulnerability Management.

The event types that SIEM (InsightIDR) can parse from this event source are:

• Low-, medium-, and high-severity alerts (from the v2 Alerts API)

To set up Microsoft Security:

• Read the requirements and complete any prerequisite steps.
• Configure Microsoft Security to send data to SIEM (InsightIDR).
• Configure SIEM (InsightIDR) to collect data from the event source.
• Test the configuration.

You can also:

• Review sample logs.
• Learn more about bidirectional alert sync.

Requirements

Before you start the configuration, you’ll need:

• Global Administrator or Application Administrator permissions in your Azure portal.

Configure Microsoft Security to send data to SIEM (InsightIDR)

Before you can send events to SIEM (InsightIDR) from Microsoft Security products, you’ll first need to set up a Microsoft Azure application to access the Microsoft Graph API. The application needs a client secret attached to it in addition to the application permissions applied to the Microsoft Graph API :

• SecurityEvents.Read.All
• SecurityIncident.Read.All
• ThreatHunting.Read.All
• SecurityAlert.ReadWrite.All

After you add the required application permissions, you must grant admin consent  before the permissions take effect. Without admin consent, SIEM (InsightIDR) cannot access the requested data.

During setup, make sure to copy the following values to a secure location as they are used in the next section:

• Client ID: The Application (client) ID found in the App Registration overview.
• Tenant ID: The Directory (tenant) ID found in the App Registration overview.
• Client Secret: The secret created in the App registration.
  • When the secret expires, you are required to reconfigure the event source.
  • You are only able to view and copy this value immediately after creating the client secret. If you log out or leave this page, you will not be able to copy the client secret value and will need to create another one.
  • The Client Secret is a sensitive password. Please do not send it over unencrypted email. Use a secure password manager or another encrypted method to share these credentials.

Configure SIEM (InsightIDR) to collect data from the event source

After you complete the prerequisite steps and configure the event source to send data, you must add the event source in SIEM (InsightIDR).

Task 1: Select Microsoft Security

This task differs depending on which version of Microsoft Security you need to set up (Microsoft Security, Microsoft Security GCC, or Microsoft Security GCC High).

Task 2: Set up your collection method

You can send data from Microsoft Security products to SIEM (InsightIDR) through the cloud.

To add a Microsoft Security Event Source:

1. Name the event source. This will become the name of the log that contains the event data in Log Search.
   • If you’re transitioning from a legacy event source to a cloud-synced version of the same event source, you can reuse the original event source name to maintain continuity in Log Search. This allows newly ingested events to appear in the same log location as before.
2. Select an existing connection or click Add a New Connection.
   • If you decided to add a new connection:
     1. In the Create a Cloud Connection screen, enter a name for the new connection.
     2. In the Tenant ID field, enter the Directory (tenant) ID that you obtained in the previous section to send data to SIEM (InsightIDR).
     3. In the Client ID field, enter the Application (client) ID that you obtained in the previous section to send data to SIEM (InsightIDR).
     4. In the Client Secret field, select an existing credential or add a new one.
        1. If you decided to add a new credential:
           1. Click the field to display a drop-down menu.
           2. Click Add Credential.
           3. Name your credential.
           4. Describe your credential.
           5. Enter the Secret Key that you obtained in the previous section to send data to SIEM (InsightIDR).
           6. Select which other Rapid7 solutions are able to use the credential.
     5. Click Save Connection.
3. Optionally, enter a collection filter.
4. Optionally, select the option to send unparsed data.
5. Select Enable bidirectional alert sync.
   • Rapid7 recommends enabling this setting so SIEM (InsightIDR) can close your alerts in Microsoft Security when they are closed in SIEM (InsightIDR), and conversely close your alerts in SIEM (insightIDR) when they are closed in Microsoft Security.
   • This feature is not currently available for the Microsoft Security GCC or Microsoft Security GCC High event sources.
6. Click Save.

Test the configuration

Finally, you’ll need to test the configuration to ensure it is properly sending event data to SIEM (InsightIDR) from Microsoft. The event types that SIEM (InsightIDR) can parse from this event source are:

• Low-, medium-, and high-severity alerts (from the v2 Alerts API)

To test that event data is flowing into SIEM (InsightIDR):

1. From the Data Collection Management page, click the Event Sources tab.
2. Find the event source you created and click View raw log. If the Raw Logs modal displays raw log entries, logs are successfully flowing to the Collector.
3. Open Log Search.

If event data is coming into SIEM (InsightIDR), you’ll also want to ensure that log entries are appearing in Log Search.

To verify log entries are appearing in Log Search:

1. In SIEM (InsightIDR), navigate to Log Search.
2. In the Log Search filter panel, search for the event source you named in Configure SIEM (InsightIDR) to collect data from the event source. Microsoft Security logs should flow into the Third Party Alert log set.
3. Select the log sets and the logs within them.
4. Set the time range to Last 10 minutes and click Run.

The Results table displays all events that flowed into SIEM (InsightIDR) in the last 10 minutes. Pay attention to the keys and values that are displayed, which are helpful when you want to build a query  and search your logs .

Sample Logs

In Log Search, the log that is generated uses the name of your event source by default. The log appears under the Third Party Alert log set. Here is a typical raw log entry that is created by the event source:

{'id': '<id>',
 'providerAlertId': '<providerAlertId>',
 'incidentId': '<incidentId>',
 'status': 'new',
 'severity': 'high',
 'classification': None,
 'determination': None,
 'serviceSource': 'microsoftDefenderForEndpoint',
 'detectionSource': 'antivirus',
 'productName': 'Microsoft Defender for Endpoint',
 'detectorId': '<detectorId>',
 'tenantId': '<tenantId>',
 'title': "'EICAR_Test_File' malware was prevented",
 'description': 'Malware and unwanted software are undesirable applications that perform annoying, disruptive, or harmful actions on affected machines. Some of these undesirable applications can replicate and spread from one machine to another. Others are able to receive commands from remote attackers and perform activities associated with cyber attacks.\n\nThis detection might indicate that the malware was stopped from delivering its payload. However, it is prudent to check the machine for signs of infection.',
 'recommendedActions': 'Collect artifacts and determine scope\n•\tReview the machine timeline for suspicious activities that may have occurred before and after the time of the alert, and record additional related artifacts (files, IPs/URLs) \n•\tLook for the presence of relevant artifacts on other systems. Identify commonalities and differences between potentially compromised systems.\n•\tSubmit relevant files for deep analysis and review resulting detailed behavioral information.\n•\tSubmit undetected files to the MMPC malware portal\n\nInitiate containment & mitigation \n•\tContact the user to verify intent and initiate local remediation actions as needed.\n•\tUpdate AV signatures and run a full scan. The scan might reveal and remove previously-undetected malware components.\n•\tEnsure that the machine has the latest security updates. In particular, ensure that you have installed the latest software, web browser, and Operating System versions.\n•\tIf credential theft is suspected, reset all relevant users passwords.\n•\tBlock communication with relevant URLs or IPs at the organization’s perimeter.',
 'category': 'Malware',
 'assignedTo': 'john@test.com',
 'alertWebUrl': 'https://security.microsoft.com/alerts/<providerAlertId>?tid=<tenantId>',
 'incidentWebUrl': 'https://security.microsoft.com/incidents/<incidentId>?tid=<tenantId>',
 'actorDisplayName': None,
 'threatDisplayName': 'Virus:DOS/EICAR_Test_File',
 'threatFamilyName': 'EICAR_Test_File',
 'mitreTechniques': [],
 'createdDateTime': '2024-03-18T19:10:49.0966667Z',
 'lastUpdateDateTime': '2024-08-12T15:16:21.64Z',
 'resolvedDateTime': '2024-08-12T15:16:21.4761349Z',
 'firstActivityDateTime': '2024-03-18T19:09:48.947691Z',
 'lastActivityDateTime': '2024-03-18T19:09:48.947691Z',
 'systemTags': [],
 'alertPolicyId': None,
 'additionalData': None,
 'comments': [{'comment': None,
   'createdByDisplayName': 'john@test.com',
   'createdDateTime': '2024-08-12T15:16:21.4761349Z'}],
 'evidence': [{'@odata.type': '#microsoft.graph.security.deviceEvidence',
   'createdDateTime': '2024-03-18T19:10:49.37Z',
   'verdict': 'unknown',
   'remediationStatus': 'none',
   'remediationStatusDetails': None,
   'roles': [],
   'detailedRoles': ['PrimaryDevice'],
   'tags': [],
   'firstSeenDateTime': '2024-03-18T19:00:26.0724432Z',
   'mdeDeviceId': '<mdeDeviceId>',
   'azureAdDeviceId': None,
   'deviceDnsName': 'mde',
   'osPlatform': 'Windows10',
   'osBuild': 19045,
   'version': '22H2',
   'healthStatus': 'inactive',
   'riskScore': 'none',
   'rbacGroupId': 0,
   'rbacGroupName': None,
   'onboardingStatus': 'onboarded',
   'defenderAvStatus': 'unknown',
   'lastIpAddress': '<ipAddress>',
   'lastExternalIpAddress': '<ipAddress>',
   'ipInterfaces': ['<ipAddress>',
    '<ipv6Address>',
    '<ipAddress>',
    '::1'],
   'vmMetadata': None,
   'loggedOnUsers': [{'accountName': 'user', 'domainName': 'MDE'}]},
  {'@odata.type': '#microsoft.graph.security.fileEvidence',
   'createdDateTime': '2024-03-18T19:10:49.37Z',
   'verdict': 'suspicious',
   'remediationStatus': 'none',
   'remediationStatusDetails': 'Entity was pre-remediated by Windows Defender',
   'roles': [],
   'detailedRoles': [],
   'tags': [],
   'detectionStatus': 'prevented',
   'mdeDeviceId': '<mdeDeviceId>',
   'fileDetails': {'sha1': '<sha>',
    'sha256': '<sha256>',
    'fileName': 'New Text Document.txt',
    'filePath': 'C:\\Users\\user\\Desktop',
    'fileSize': 68,
    'filePublisher': None,
    'signer': None,
    'issuer': None}}]}

Bidirectional Alert Sync

Bidirectional alert sync keeps alert status consistent across Rapid7 SIEM (InsightIDR) and Microsoft Security without manual effort. When you close an alert in either system, the status change is automatically reflected in the other, reducing context-switching and helping streamline your incident response workflow.

To enable bidirectional alert sync:

• Ensure these application permissions are applied to the Microsoft Graph API in Microsoft Azure when configuring Microsoft Security:
  • SecurityAlert.ReadWrite.All
  • ThreatHunting.Read.All
  • SecurityIncident.Read.All
  • SecurityEvents.Read.All
• Select Enable bidirectional alert sync when configuring the event source in SIEM (InsightIDR).

Sync behavior

This table describes how alert status changes sync between SIEM (InsightIDR) and Microsoft Security, depending on whether an alert is part of an investigation.

Investigations and bidirectional sync

Whether an alert is part of an investigation affects how bidirectional sync behaves. Understanding this relationship is important for customers who triage alerts from Microsoft Security alongside SIEM (InsightIDR) investigations.

In SIEM (InsightIDR), alerts that are part of an open investigation cannot be closed individually, they can only be closed by closing the investigation itself. This applies regardless of what happens in Microsoft Security.

How investigations affect sync:

• If an alert in SIEM (InsightIDR) is part of an open investigation, closing that alert in Microsoft Security will not close it in SIEM (InsightIDR), and will not close the investigation.
• To close an investigation-linked alert in both systems, close the investigation in SIEM (InsightIDR). This will close the investigation and sync the alert closure to Microsoft Security.

Detection Rule Actions and Sync Readiness

Whether an incoming Microsoft Security alert is added to an investigation or created as a standalone alert in SIEM (InsightIDR) is controlled by the rule action setting on the corresponding third-party detection rule.

The default rule action for third-party detection rules in SIEM (InsightIDR) depends on your subscription:

• Customers with MDR SOC triage entitlements - Detection rules are automatically set to Create alert. Bidirectional sync works as expected for these customers without any additional configuration.
• Customers without MDR SOC triage entitlements (including both managed and unmanaged customers) - Detection rules default to Create investigation. Alerts from Microsoft Security that trigger these rules will be added to investigations in SIEM (InsightIDR), which means they cannot be closed through bidirectional sync until the investigation is closed.

If you want incoming Microsoft Security alerts to be created as standalone alerts in SIEM (InsightIDR), rather than added to investigations, you can change the rule action on the relevant third-party detection rules.

You can change the rule action:

• Through the UI - You can update up to 60 rules at a time. Go to Detection Rules in SIEM (InsightIDR), filter for the relevant rules, and update the rule action to Create alert.
• Through the API - You can update all rules at once using the SIEM (InsightIDR) REST API. See the SIEM (InsightIDR) REST API documentation for details.