The way logs aggregated/stored depends on the use-case which you have deployed your SIEM and the deployment architecture.

A typical SIEM will offer you following use cases:

1. Log Collection
2. Log Retension
3. Log Analysis
4. Event Correlation
5. Log Forensic
6. IT Compliance
7. Real-time Alerting
8. User Activity Monitoring
9. File Integrity Monitoring
10. Etc.

The deployment scenario could be also varied depend on the scale/scope of deployment and the way logs are aggregated also will depend on these scenario. For example following could be some scenarios:

• Deploying Log Collectors on the source locations and central log server to store logs. Then send only security related logs to SIEM database - only the required logs will be stored in SIEM database and rest will be in the log central log server

• Collect, store and process entire logs in SIEM database - where the entire logs will be stored in SIEM

A SIEM collecting logs and processing is unique to each SIEM supplier as most of them have their own Connectors/Templates (Or supported log formats) for the commonly available devices/log sources. All SIEM vendors will provide you a list of supported devices and any device not in this list to be connected manually, where the SIEM supplier might help you in drafting your own connector.

You may refer following links for a sample SIEM vendor supported device list (connectors are readily available):

https://www.scribd.com/document/60264371/LogRhythm-Supported-Products-List

Most of the SIEM suppliers have their own way of storing logs (data format to table structure may differ). Most of them will process the received logs and convert to the structure their core platform can understand.

The above mentioned connectors/templates are used to convert the native source format to the SIEM understandable format.

Hope this clarifies your concerns...

The way logs are aggregated/stored depends on the use-case which you have deployed your SIEM and the deployment architecture.

A typical SIEM will offer you following use cases:

1. Log Collection
2. Log Retention
3. Log Analysis
4. Event Correlation
5. Forensics
6. IT Compliance
7. Real-time Alerting
8. User Activity Monitoring
9. File Integrity Monitoring
10. Etc.

The deployment scenario could be also varied depending on the scale/scope of deployment and the way logs are aggregated also will depend on these scenarios. For example, the following could be some scenarios:

• Deploying Log Collectors on the source locations and central log server to store logs. Then send only security-related logs to SIEM database - only the required logs will be stored in SIEM database and rest will be in the log central log server

• Collect, store and process entire logs in SIEM database - where the entire logs will be stored in SIEM

A SIEM collecting logs and processing is unique to each SIEM supplier as most of them have their own Connectors/Templates (or supported log formats) for the commonly available devices/log sources. All SIEM vendors will provide you with a list of supported devices and any device not in this list to be connected manually, where the SIEM supplier might help you in drafting your own connector.

You may refer to the following links for a sample SIEM vendor supported device list (connectors are readily available):

https://www.scribd.com/document/60264371/LogRhythm-Supported-Products-List

Most of the SIEM suppliers have their own way of storing logs (data format to table structure may differ). Most of them will process the received logs and convert to the structure their core platform can understand.

The above-mentioned connectors/templates are used to convert the native source format to the SIEM understandable format.