Log Source Onboarding in QRadar: A Practical Checklist
The Step Most Teams Rush — And Why It Creates Silent Detection Gaps
Every time a new device, application, or cloud service enters your environment, it needs to talk to your SIEM. In IBM QRadar, that conversation happens through log sources and DSMs (Device Support Modules). Getting this right is foundational — events that reach QRadar but are never parsed, categorized, or mapped to QRadar IDs cannot be used in any correlation rule. They show up in Log Activity, give you a false sense of coverage, and contribute nothing to detection.
The full onboarding checklist
Step | What to do | Common mistake |
1. Identify the log format | Syslog, LEEF, CEF, JDBC, API pull? | Assuming all Linux systems send identical syslog |
2. Check DSM availability | Does QRadar have a native DSM for this device? | Skipping this and using Universal DSM blindly |
3. Configure the source device | Enable logging, set correct facility/severity | Logging to wrong syslog facility (local0 vs local7) |
4. Set the log source in QRadar | Correct protocol, listener port, timezone | Timezone mismatch shifts all event timestamps |
5. Validate parsing | Check QRadar log activity — are events categorized? | Events showing as "unknown" — DSM not mapping fields |
6. Map to QID | Ensure events have QRadar Event IDs (QIDs) | Unparsed events cannot be used in any rule |
7. Test with a rule | Write a simple test rule and verify it fires | Assuming "I see events" means correlation works |
Understanding log protocols in QRadar
QRadar supports multiple collection protocols and choosing the wrong one is a common source of onboarding failures. Syslog (UDP/TCP) is the most common for network devices and Linux systems. LEEF (Log Event Extended Format) is IBM's own format, used by QRadar-aware products. CEF (Common Event Format) is used by many security products including Palo Alto, CrowdStrike, and others. JDBC is used for pulling logs directly from databases. Each protocol has specific listener port requirements and parsing behaviour in QRadar.
Protocol | Typical source | QRadar listener port |
Syslog UDP | Network devices, Linux, Unix | 514 |
Syslog TCP | High-volume or reliable delivery needed | 514 (configurable) |
LEEF | IBM products, QRadar-native integrations | 514 (via syslog) |
CEF | Palo Alto, CrowdStrike, ArcSight agents | 514 (via syslog) |
JDBC | Databases, Oracle, MSSQL audit logs | Custom per data source |
The Universal DSM trap
When QRadar does not have a native DSM for a device, teams fall back to the Universal DSM. It will accept the logs. Events will appear in Log Activity. Everything looks fine. But fields like username, source IP, and event category will not be parsed correctly. A correlation rule looking for "failed authentication from external IP" cannot fire if QRadar does not know which raw log field contains the username. The Universal DSM is a placeholder, not a solution.
The right fix: build a custom Log Source Extension (LSE) that maps your device's raw log fields to QRadar's normalized fields. This takes time, but it is the only way to make the events usable in correlation.
Timezone — the silent data quality killer
This one causes more confusion than almost anything else in QRadar onboarding. If the log source device is in UTC but QRadar is configured to expect IST, every event timestamp will be off by 5 hours 30 minutes. This makes time-based correlation rules unreliable and makes forensic timelines inaccurate. Always verify the timezone configuration of the source device and match it exactly in the QRadar log source settings.
Validating that onboarding actually worked
Seeing events in Log Activity is not enough. True validation means confirming that events are correctly categorized (not showing as "Unknown"), that key fields like username and source IP are populated in normalized form, and that a simple test rule built on those events actually fires. Only then is the log source truly onboarded. Add it to your SIEM documentation with the onboarding date, DSM version, and the name of the analyst who validated it.
Closing
Log source onboarding is unglamorous work, but it is the foundation of every detection that comes after it. A SIEM with 200 connected log sources but 40 percent of them unparsed is not a 200-source SIEM — it is a 120-source SIEM with a misleading dashboard. Take the time to do it properly, document what you did, and validate before you move on.
