How to test polling type log sources with QRadar

Author(s): László Czap | Created: 28 March 2020 | Last modified: 19 April 2024
Tested on: -

Testing polling type log sources

Log sources using syslog are very easy to test in QRadar. However, there are some device types that have only polling type (or file based) protocols as configuration options. Among others, Amazon AWS, IBM BigFix, IBM MaaS360, Cisco IPS are such examples. For these, firing a syslog event with the same format and the same logsourceid in the header is useless, because the log source configuration will not match.

The following workaround can be applied to generate test syslog events for these log sources. This is to be used only in test environments (you don't want to litter your production system with test events anyway).

Go to your console and get a psql connection:

psql -U qradar

The table sensordeviceprotocols contains the log source type and protocol associations. We add a row to this table such that our tested log source accepts syslog. This table works with identifiers, so you need to find the id of your log source type. For this, use the sensordevicetype table and look for the id column. The column devicetypedescription will help you find the right row. E.g. to find the MaaS360 log source:

select id,devicetypedescription from sensordevicetype where devicetypedescription like '%MaaS%';

This query returns

 id  | devicetypedescription
-----+-----------------------
 361 | IBM Fiberlink MaaS360
(1 row)

so we know the id we look for is 361. We also need the id of the syslog protocol, which is 0 (you can find it out from the table sensorprotocol).

Having this we insert a new row:

insert into sensordeviceprotocols values(361,0,1111,'f');

Here, the third value is just a unique identifier, whereas the last indicates that this is undocumented.

Now, if you go back to QRadar UI, and try to add a new log source of your selected type, in the drop-down menu a new item appears: Syslog (Undocumented). Select this, and all you need is to provide a logsourceid and save the new log source. You must use the same id as you provided here in your syslog header when sending in your test events.

After these changes, you need to restart the eventprocessing service. I did

service hostcontext restart

but maybe this is an overkill.

Hint: If you want that the test events look like they come from an existing real log source of the same type, you need to create a new log source of the same type, but with the new Syslog (Undocumented) protocol configuration. When creating this, use the same logsourceid as you have in the real log source and make sure that the parsing order prefers the real log source. This way the test log source will never receive any events, all your test events will seem to belong to your original log source.

Here is the list of log sources for which this workaround should come handy:

  • AhnLab Policy Center APC
  • Akamai KONA
  • Amazon AWS CloudTrail
  • Box
  • Cisco Cloud Web Security
  • Cisco Identity Services Engine
  • Cisco Intrusion Prevention System (IPS)
  • Fasoo Enterprise DRM
  • Flow Classification Engine
  • HP Tandem
  • IBM BigFix
  • IBM BigFix Detect
  • IBM Informix Audit
  • IBM Fiberlink MaaS360
  • IBM Lotus Domino
  • IBM Privileged Session Recorder
  • IBM Proventia Management SiteProtector
  • IBM Proventia Network Intrusion Prevention System (IPS)
  • IBM Security Identity Governance
  • IBM Security Identity Manager
  • IBM Security Privileged Identity Manager
  • IBM SmartCloud Orchestrator
  • Juniper Networks AVT
  • Juniper Security Binary Log Collector
  • Kisco Information Systems SafeNet/i
  • McAfee Application/Change Control
  • Microsoft Endpoint Protection
  • Microsoft Operations Manager
  • Microsoft SCOM
  • Microsoft Windows Defender ATP
  • Netskope Active
  • ObserveIT
  • Open LDAP Software
  • OpenStack
  • Oracle Audit Vault
  • Oracle BEA WebLogic
  • Oracle Enterprise Manager
  • Oracle Fine Grained Auditing
  • Pirean Access: One
  • Resolution1 CyberSecurity
  • Riverbed SteelCentral NetProfiler
  • Riverbed SteelCentral NetProfiler Audit
  • Salesforce Security Auditing
  • Salesforce Security Monitoring
  • Seculert Seculert
  • SOAP Webservice-based messages, pre-normalized
  • Sophos Enterprise Console
  • Sophos PureMessage
  • Sun ONE LDAP
  • Sybase ASE
  • Symantec Critical System Protection
  • Symantec System Center
  • Trend Micro Control Manager
  • Trend Micro Office Scan
  • VMware vCloud Director

The method above was tested on version 7.3.2., table structure might change without notice. You lose your support if you modify psql tables.