Troubleshooting the SIEM agent (Microsoft)

This article provides a list of possible issues when connecting your SIEM to Defender for Cloud Apps and provides possible resolutions.

Recover missing activity events in Defender for Cloud Apps SIEM Agent

Before you proceed, check that your Defender for Cloud Apps license supports the SIEM integration you’re trying to configure.

If you received a system alert regarding an issue with activity delivery through the SIEM agent, follow the steps below to recover the activity events in the timeframe of the issue. These steps will guide you through setting up a new Recovery SIEM agent that will run in parallel and resend the activity events to your SIEM.

Step 1 – Configure a new SIEM Agent in parallel to your existing agent

1. In the Defender for Cloud Apps portal, go to Security Extensions page.
2. In the SIEM Agents tab, select add a new SIEM agent, and use the wizard to configure the connection details to your SIEM. For example, you can create a new SIEM agent with the following configuration:
   • Protocol: TCP
   • Remote host: Any device where you can listen to a port. For example, a simple solution would be to use the same device as the agent and set the remote host IP address to 127.0.0.1
   • Port: Any port you can listen to on the remote host device

    Note

   This agent should run in parallel to the existing one, so network configuration might not be identical.

3. In the wizard, configure the Data Types to include only Activities and apply the same activity filter that was used in your original SIEM agent (if it exists).
4. Save the settings.
5. Run the new agent using the generated token.

Step 2 – Validate the successful data delivery to your SIEM

Use the following steps to validate your configuration:

1. Connect to your SIEM and check that new data is received from the new SIEM agent that you configured.

1. If data is not received by your SIEM, then on the new SIEM agent device, try listening to the port that you configured to forward activities to see if data is being sent from the agent to the SIEM. For example, run netcat -l <port> where <port> is the previously configured port number.

1. If data is being sent by the agent but not received by your SIEM, check the SIEM agent log. If you can see “connection refused” messages, make sure that your SIEM agent is configured to use TLS 1.2 or newer.

Step 3 – Remove the Recovery SIEM agent

1. The recovery SIEM agent will automatically stop sending data and be disabled once it reaches the end date.
2. Validate in your SIEM that no new data is sent by the recovery SIEM agent.
3. Stop the execution of the agent on your device.
4. In the portal, go to the SIEM Agent page and remove the recovery SIEM agent.
5. Make sure your original SIEM Agent is still running properly.

General troubleshooting

Make sure the status of the SIEM agent in the Microsoft Defender for Cloud Apps portal isn’t Connection error or Disconnected and there are no agent notifications. The status shows as Connection error if the connection is down for more than two hours. The status changes to Disconnected if the connection is down for over 12 hours.

If you see one of the following errors in the cmd prompt while running the agent, use the following steps to remediate the problem:

After creating the agent, check the SIEM agent page in the Defender for Cloud Apps portal. If you see one of the following Agent notifications, use the following steps to remediate the problem:

Issue with new versions of Java

Newer versions of Java can cause problems with the SIEM agent. If you’ve installed Java Runtime Engine (JRE) update 291 or higher, follow these steps:

1. In an elevated PowerShell prompt, switch to the Java install bin folder.
   PowerShellCopy

   cd "C:\Program Files (x86)\Java\jre1.8.0_291\bin"
   

2. Download each of the four Azure TLS Issuing CA certificates.
   PowerShellCopy

   Invoke-WebRequest -Uri "https://www.microsoft.com/pkiops/certs/Microsoft%20Azure%20TLS%20Issuing%20CA%2001%20-%20xsign.crt" -OutFile "$env:temp\azuretls01.crt"
   Invoke-WebRequest -Uri "https://www.microsoft.com/pkiops/certs/Microsoft%20Azure%20TLS%20Issuing%20CA%2002%20-%20xsign.crt" -OutFile "$env:temp\azuretls02.crt"
   Invoke-WebRequest -Uri "https://www.microsoft.com/pkiops/certs/Microsoft%20Azure%20TLS%20Issuing%20CA%2005%20-%20xsign.crt" -OutFile "$env:temp\azuretls05.crt"
   Invoke-WebRequest -Uri "https://www.microsoft.com/pkiops/certs/Microsoft%20Azure%20TLS%20Issuing%20CA%2006%20-%20xsign.crt" -OutFile "$env:temp\azuretls06.crt"
   

3. Import each CA certificate CRT file to the Java keystore, using the default keystore password changeit.
   PowerShellCopy

   keytool -importcert -file "$env:temp\azuretls01.crt" -keystore ..\lib\security\cacerts -alias azuretls01crt -storepass changeit
   keytool -importcert -file "$env:temp\azuretls02.crt" -keystore ..\lib\security\cacerts -alias azuretls02crt -storepass changeit
   keytool -importcert -file "$env:temp\azuretls05.crt" -keystore ..\lib\security\cacerts -alias azuretls05crt -storepass changeit
   keytool -importcert -file "$env:temp\azuretls06.crt" -keystore ..\lib\security\cacerts -alias azuretls06crt -storepass changeit
   

4. To verify, view the Java keystore for Azure TLS issuing CA certificate aliases listed above.
   PowerShellCopy

   keytool -list -keystore ..\lib\security\cacerts
   

5. Start the SIEM agent and review the new trace log file to confirm a successful connection.

Source : Official Microsoft Brand
Editor by : BEST Antivirus KBS Team