The current QRadar version in use is 7.5.0 Update 13. We've observed that the EKS Worker nodes are not registering under the Linux OS source type. Instead, a significant percentage of their events are being categorized under SIM Generic. Additionally, we've noticed that some RHEL devices are storing data in the /store directory. Is this expected behavior? Given these findings, should we consider parsing each event individually or creating new source logs and custom rules to handle them appropriately? Does this suggest that QRadar may not natively support these types of events?

Hi Amber, what you described it could be describe as normal behavior. I'll try to answer your questions in more details:

1. EKS Worker not recognized as Linux OS. This completly depens of the event that the device it's sending to QRadar, in other words if the events the the EKS worker are _not_ events for the Linux OS itself, but for example logs from an application running on a pod, then all the OOTB parsing that comes within QRadar won't match the event id/event category. On those cases (that event can't be parsed and mapped) and there's no Log Source that can match the log source id, then the last place to store the events it's the SIM Generic.
2. You can manually create a log source of the Linux OS type for each Worker, so QRadar knows that there's a log source id for those events. The event should be store in that particular log source, but probably it won't be recognized so it will be store with the category "Stored".
3. All the events are saved on the Ariel DB on QRadar. The directory for the Ariel DB it's /store/ariel.
4. The normal procedure for your case should be create a customer DSM. On that DSM you should at least include the parsing of the "event category" and "event id" and the mapping, those two are required so the event are sent to a log source. 
5. QRadar natively support Linux OS events, the applications running within a pod are most probably considered customer events, so there're no parser OOTB for them.

Hope this will help you

The current QRadar version in use is 7.5.0 Update 13. We've observed that the EKS Worker nodes are not registering under the Linux OS source type. Instead, a significant percentage of their events are being categorized under SIM Generic. Additionally, we've noticed that some RHEL devices are storing data in the /store directory. Is this expected behavior? Given these findings, should we consider parsing each event individually or creating new source logs and custom rules to handle them appropriately? Does this suggest that QRadar may not natively support these types of events?

Hi Juan Paulo,

Yes, that makes sense, but I'm still unclear about one aspect. At one point, we saw around 50 EKS worker nodes being auto-discovered-some categorized under "Aruba Mobility" and others under "Linux OS." However, last week, only about 5 were auto-discovered. Could you help explain the reason behind this discrepancy? I understand the environment has been frequently recycled due to various factors, which might be contributing to the change. While manually creating the workers is straightforward and not time-consuming, the challenge lies in handling the ones that are no longer available-especially since their IP addresses and instance IDs have changed.

Many thanks in advance.

Amber

Hi Amber, what you described it could be describe as normal behavior. I'll try to answer your questions in more details:

1. EKS Worker not recognized as Linux OS. This completly depens of the event that the device it's sending to QRadar, in other words if the events the the EKS worker are _not_ events for the Linux OS itself, but for example logs from an application running on a pod, then all the OOTB parsing that comes within QRadar won't match the event id/event category. On those cases (that event can't be parsed and mapped) and there's no Log Source that can match the log source id, then the last place to store the events it's the SIM Generic.
2. You can manually create a log source of the Linux OS type for each Worker, so QRadar knows that there's a log source id for those events. The event should be store in that particular log source, but probably it won't be recognized so it will be store with the category "Stored".
3. All the events are saved on the Ariel DB on QRadar. The directory for the Ariel DB it's /store/ariel.
4. The normal procedure for your case should be create a customer DSM. On that DSM you should at least include the parsing of the "event category" and "event id" and the mapping, those two are required so the event are sent to a log source. 
5. QRadar natively support Linux OS events, the applications running within a pod are most probably considered customer events, so there're no parser OOTB for them.

Hope this will help you

The current QRadar version in use is 7.5.0 Update 13. We've observed that the EKS Worker nodes are not registering under the Linux OS source type. Instead, a significant percentage of their events are being categorized under SIM Generic. Additionally, we've noticed that some RHEL devices are storing data in the /store directory. Is this expected behavior? Given these findings, should we consider parsing each event individually or creating new source logs and custom rules to handle them appropriately? Does this suggest that QRadar may not natively support these types of events?

To add to what Juan Paulo explained pretty good...

QRadar has a feature called Traffic Analysis that basically serves to automatically detect & create new log sources and in the process tests and tries to match main content elements to a suitable log source type (DSM) - which is then associated with the log source. The process is (of course) not ideal or faultless, and thus it happens (not so rarely per my experience) that you get auto-created log sources of e.g. VMware type while logs were actually coming from a Juniper switch or so. 

By default it is global behaviour to do the autodetection (though this may be overridden). 

You may have a look through the DSM Editor > Configuration > Advanced configuration for your selected log source type (DSM) - e.g. Linux OS and see how many events from an unknown source must be successfully parsed and what is the minimum success rate in order for the log source to be created (these parameters are adjustable).  (It should also be possible to turn on and adjust this autodetection for your custom DSMs as well). 

Have a look at : 

https://www.ibm.com/support/pages/qradar-understanding-traffic-analysis-and-log-source-auto-detection

https://www.ibm.com/docs/en/qradar-on-cloud?topic=qradar-configuring-log-source-autodetection-log-source-types

Now, if you have systems sending logs that disappear and reappear, will they be covered again under the same lg source or not depends on the log source identifier; if that changes, you will have a new log source. I recall having a situation where a containerised application was sending logs and as the container would restart & change we would have new log sources since the the identifier would contain a new UID added to its identifier. in this case, we used Syslog redirect to override the log source identifier and keep the app logs under same log sources. 

Hi Juan Paulo,

Yes, that makes sense, but I'm still unclear about one aspect. At one point, we saw around 50 EKS worker nodes being auto-discovered-some categorized under "Aruba Mobility" and others under "Linux OS." However, last week, only about 5 were auto-discovered. Could you help explain the reason behind this discrepancy? I understand the environment has been frequently recycled due to various factors, which might be contributing to the change. While manually creating the workers is straightforward and not time-consuming, the challenge lies in handling the ones that are no longer available-especially since their IP addresses and instance IDs have changed.

Many thanks in advance.

Amber

Hi Amber, what you described it could be describe as normal behavior. I'll try to answer your questions in more details:

1. EKS Worker not recognized as Linux OS. This completly depens of the event that the device it's sending to QRadar, in other words if the events the the EKS worker are _not_ events for the Linux OS itself, but for example logs from an application running on a pod, then all the OOTB parsing that comes within QRadar won't match the event id/event category. On those cases (that event can't be parsed and mapped) and there's no Log Source that can match the log source id, then the last place to store the events it's the SIM Generic.
2. You can manually create a log source of the Linux OS type for each Worker, so QRadar knows that there's a log source id for those events. The event should be store in that particular log source, but probably it won't be recognized so it will be store with the category "Stored".
3. All the events are saved on the Ariel DB on QRadar. The directory for the Ariel DB it's /store/ariel.
4. The normal procedure for your case should be create a customer DSM. On that DSM you should at least include the parsing of the "event category" and "event id" and the mapping, those two are required so the event are sent to a log source. 
5. QRadar natively support Linux OS events, the applications running within a pod are most probably considered customer events, so there're no parser OOTB for them.

Hope this will help you

The current QRadar version in use is 7.5.0 Update 13. We've observed that the EKS Worker nodes are not registering under the Linux OS source type. Instead, a significant percentage of their events are being categorized under SIM Generic. Additionally, we've noticed that some RHEL devices are storing data in the /store directory. Is this expected behavior? Given these findings, should we consider parsing each event individually or creating new source logs and custom rules to handle them appropriately? Does this suggest that QRadar may not natively support these types of events?