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 bi-directional 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

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, select the option to send unparsed data.
4. Select the Enable bi-directional alert sync checkbox.
   • 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.
5. 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}}]}

Bi-Directional Alert Sync

Bi-directional alert sync addresses the challenge of switching between security tools by enabling unified alert triage across your ecosystem. Enabling bi-directional alert sync allows Rapid7 to automatically close an alert in your third-party event source when it is closed in SIEM (InsightIDR). Conversely, closing the alert in your third-party event source automatically closes the alert in SIEM (InsightIDR). This ensures consistent alert status across tools and helps streamline your incident response workflow.

With bi-directional alert sync, you can:

• Automatically close alerts across systems:
  • Closing an alert in SIEM (InsightIDR) also closes the corresponding alert in Microsoft Security.
  • Closing an alert in Microsoft Security closes it in SIEM (InsightIDR).
  • Reopening an alert in SIEM (InsightIDR) will reopen the alert in Microsoft Security.
• Maintain consistent alert status across platforms to reduce context-switching and manual effort.

To enable bi-directional alert sync:

• Ensure the SecurityAlert.ReadWrite.All application permission is applied to the Microsoft Graph API in Microsoft Azure when configuring Microsoft Security.
• Click the Enable bi-directional alert sync checkbox when configuring the event source in SIEM (InsightIDR).