Defender for Identity の TLS Syslog での SIEM (IBM QRadar) への連携（English follows）

[umesuisho]

お世話になっております。

Defender for Identity のログを TLS Syslog で SIEM (IBM QRadar on Cloud) へ連携を試みています。

QRoC側：https://www.ibm.com/docs/en/qradar-on-cloud?topic=overview-sending-tls-syslog-data-qradar-console

Defender for Identity側：https://learn.microsoft.com/en-us/defender-for-identity/notifications#syslog-notifications

Syslog ペイロード先頭に付与される、ホスト名/IPに該当するカラムにはセンサー名が入る認識ですが正しいでしょうか。

We're trying to send Microsoft Defender logs to QRadar on Cloud (SaaS) with TLS Syslog protocol.

QRadar on Cloud: https: //www.ibm.com/docs/en/qradar-on-cloud?topic=overview-sending-tls-syslog-data-qradar-console

Defender for Identity: https://learn.microsoft.com/en-us/defender-for-identity/notifications#syslog-notifications

We have to identify the strings which are in the column in the head of the payload, in which usually IP/hostname is filled.
I suppose “Sensor Name“ listed in the MS Defender for Identity dashboard will be the one. Is that correct?

[#2]

@umesuisho  This reference might help you :
https://learn.microsoft.com/en-us/defender-for-identity/cef-format-sa

[#3]

@Eli Ofek 

Thank you Eli, it seems like an IP address will be put in the column, right?

Where can we find the IPs to be put in the column for each Sensors?

2-21-2018 16:19:35 Auth.Warning 192.168.0.220 1 2018-02-21T14:19:27.540731+00:00 CENTER CEF 6076 AccountEnumerationSecurityAlert 0|Microsoft|Azure ATP|2.22.4228.22540|AccountEnumerationSecurityAlert|Reconnaissance using account enumeration|5|start=2018-02-21T14:19:02.6045416Z app=Kerberos shost=CLIENT1 suser=LMaldonado msg=Suspicious account enumeration activity using the Kerberos protocol, originating from CLIENT1, was observed and successfully guessed Lamon Maldonado (Software Engineer). externalId=2003 cs1Label=url cs1=https://contoso-corp.atp.azure.com/securityAlert/eb6a35da-ff7f-4ab5-a1b5-a07529a89e6d cs2Label=trigger cs2=new cs3Label=shostfqdn cs3=client1.contoso.com

[#4]

If you are looking for the host of the sensor then yes, it's the field marked in bold in the header of the message.

[#5]

Thank you Eli,
okay, so I'd like to specify the IP of the sensors.
We can see the names of the sensors in the dashboard of the Defender for Identity console.
Where can we locate the IP of the sensors then?

[#6]

The portal will only show names.
If you go to the machine profile it should allow you to see the last IP we saw it using.
But it's not displayed on the sensors list easily.

[#7]

Thank you Eli,
I understand that we can locate the IPs of the sensors at "the machine profile".
But I supposed that these IPs are not static right?
For receiving Syslogs in QRadar, we need to configure a parameter called "Log Source ID" in QRadar.
The parameter of "Log Source ID" should be the strings which is at the head of the payload and is usually hostname/IP address and should be static.
QRadar identify the consumed logs as the specific LogSourceName registered in QRadar by verifying that the registered "Log Source ID", which is mapped to the LogSourceName, and the head of the payload is the same.

[#8]

So my question is;
which strings should we register as Log Source ID?

[#9]

You can use the field that is between the timestamp and the "CEF" string.

[#10]

Thank you@Eli Ofek ,

You mean "CENTER" in the following sample log, right?

Could you kindly let me know what does this column mean?

2-21-2018 16:19:35 Auth.Warning 192.168.0.220 1 2018-02-21T14:19:27.540731+00:00 CENTER CEF 6076 AccountEnumerationSecurityAlert 0|Microsoft|Azure ATP|2.22.4228.22540|AccountEnumerationSecurityAlert|Reconnaissance using account enumeration|5|start=2018-02-21T14:19:02.6045416Z app=Kerberos shost=CLIENT1 suser=LMaldonado msg=Suspicious account enumeration activity using the Kerberos protocol, originating from CLIENT1, was observed and successfully guessed Lamon Maldonado (Software Engineer). externalId=2003 cs1Label=url cs1=https://contoso-corp.atp.azure.com/securityAlert/eb6a35da-ff7f-4ab5-a1b5-a07529a89e6d cs2Label=trigger cs2=new cs3Label=shostfqdn cs3=client1.contoso.com

[#11]

Yes, that would be the machine name that sent the syslog message (the designated sensor).

[#12]

@Eli Ofek Than equals to Sensor Name of the Defender for Identity Sensor which I mentioned at the begging of this thread right?

[#13]

You mentioned that you need to provide hostname or IP as source.
It makes sense to send the name of the designated sensor that sent the syslog message.
Note that it might not be the sensor that initially sourced the actual security alert, it will always be the same one which you selected as the designated sensor.

[#14]

Apologize for my late reply.
>You mentioned that you need to provide hostname or IP as source.
Yes, that's right.

Another question regarding the following notification.
https://learn.microsoft.com/en-us/defender-for-identity/notifications#syslog-notifications
>When working with Syslog in TLS mode, make sure to install the required certificates on the designated sensor.

QRadat on Cloud team had created .p12 for the TSL communication in the QRoC, for the sensor to be able to send data to the QRoC.

Documentation from IBM to send TLS Syslog data to QRadar: https://www.ibm.com/docs/en/qradar-on-cloud?topic=overview-sending-tls-syslog-data-qradar-console

And they asked us to do the following.
>On the device that is sending syslog events to QRadar on Cloud, ensure that the CA (Let's Encrypt) is added to the truststore.
You might need to add the CA root certificate when you configure some third-party log sources. Download the certificate from the CA site at https://letsencrypt.org/certificates/.

I think "addding the CA (Let's Encrypt) to the truststore in the sensor" is what the MS guide is pointing to in the following notification.
>When working with Syslog in TLS mode, make sure to install the required certificates on the designated sensor.
https://learn.microsoft.com/en-us/defender-for-identity/notifications#syslog-notifications

Do you think the same way?

[#15]

@umesuisho Yes, sounds like they mean the same thing.