App for IBM QRadar - Troubleshooting v2.2.0
Frequently Asked Questions
• The "Last Contact" field under Settings > Data should contain a current timestamp within the span of the configured "Polling Interval". In this example, the timestamp should be updated every 60 seconds.
• If you go to Settings > Configuration requests are triggered to check the validity. If there is something wrong with the credentials, or the Device API or Alerts API at the current moment, validation errors will be shown.
• If you go to Settings > Configuration requests are triggered to check the validity. If there is something wrong with the credentials, or the Device API or Alerts API at the current moment, validation errors will be shown.
• Check that the API keys are of the correct key type.
• Check that the "Custom" Type API key has the necessary permissions.
• Make sure the "Custom" and "API" Type Credentials are not switched up.
• Check if Polling under Settings > Data sub-tab is enabled.
• Make sure the respective Alerts type(s) (CB Analytics Alerts, Device Control Alerts, Watchlist Alerts) under Settings > Data sub-tab are enabled.
• If you use the Built-in input, make sure "Minimum Successful Events for Autodetection" in the Log Source Type configuration is set low enough. Details on how to set it up are available in step 4. of the Installation & User Guide > Log Source Type Configuration.
• Once the app makes contact with the Carbon Black Cloud, it will start polling data. It might take a few minutes until QRadar starts recognising the incoming records as Carbon Black Cloud data. All data polled in the interim will be displayed in the Log Activity page as "Unknown log event" collected by "SIM Generic Log DSM-7".
• Check that the "Custom" Type API key has the necessary permissions.
• Make sure the "Custom" and "API" Type Credentials are not switched up.
• Check if Polling under Settings > Data sub-tab is enabled.
• Make sure the respective Alerts type(s) (CB Analytics Alerts, Device Control Alerts, Watchlist Alerts) under Settings > Data sub-tab are enabled.
• If you use the Built-in input, make sure "Minimum Successful Events for Autodetection" in the Log Source Type configuration is set low enough. Details on how to set it up are available in step 4. of the Installation & User Guide > Log Source Type Configuration.
• Once the app makes contact with the Carbon Black Cloud, it will start polling data. It might take a few minutes until QRadar starts recognising the incoming records as Carbon Black Cloud data. All data polled in the interim will be displayed in the Log Activity page as "Unknown log event" collected by "SIM Generic Log DSM-7".
• If you go to Settings > Configuration requests are triggered to check the validity. If there is something wrong with the credentials, or the Device API or Alerts API at the current moment, validation errors will be shown.
• Check if Polling is Enabled under Settings > Data sub-tab.
• If the above did not resolve the problem, check the network on the QRadar host to confirm connectivity to Carbon Black Cloud.
• Check if Polling is Enabled under Settings > Data sub-tab.
• If the above did not resolve the problem, check the network on the QRadar host to confirm connectivity to Carbon Black Cloud.
• To turn on Read Only access, configure your access level with only the "Read" permissions. This will result in certain functions becoming unavailable in the app.
1. Click on the menu icon with three horizontal lines.
2. Click on the star icon to add Carbon Black Cloud to the menu bar.
2. Click on the star icon to add Carbon Black Cloud to the menu bar.
• No, all of the Alerts, Audit Logs, and Events will be pulled in once the application is working again. However, depending on the downtime period, it might take some time for the app to catch-up.
• Yes, multiple Data Forwarders can push to the same S3 bucket. The Data Forwarder is creating a directory structure for each Org Key.
• Yes, 2.1.0. onwards supports multi-tenancy. More information is available here.
• Yes, the app lives in a docker container, and has its own logs separate from the QRadar logs. You can find more details about logging and troubleshooting them in the IBM's page for App Troubleshooting.
• Use the full dashboard URL of your Carbon Black Cloud Console. Full detail on the URLs for each environment are available here.
• The Data Forwarder is the recommended approach for ingesting Alerts and Endpoint Events into QRadar due to its reliability, scale, and low latency. This approach is only required to ingest Endpoint Event data.
• QRadar 7.3.3 Patch 6+
• QRadar 7.4.1 Patch 2+
• QRadar 7.5
• QRadar 7.4.1 Patch 2+
• QRadar 7.5
• Yes, 2500.
• Use the Developer Community Forum to discuss issues and get answers from other API developers in the Carbon Black Community.
• Report bugs and change requests to Carbon Black Support.
• View all API and integration offerings on the Developer Network along with reference documentation, video tutorials, and how-to guides.
• Report bugs and change requests to Carbon Black Support.
• View all API and integration offerings on the Developer Network along with reference documentation, video tutorials, and how-to guides.
• To view the full set of new features, visit the Release Notes section.
• Detailed information on app upgrades, requirements, and configuration changes is available here.
Yes, 10,000. If your organization has more than 10,000 alerts each polling interval, you can:
• Tune CB Analytics alerts that are known-good in your environment using the Dismiss all future alerts functionality.
• Follow recommendations from our Threat Research team here.
• Modify the configured Alert Input and increase the Minimum Alert Severity.
• Change the polling interval from the default of 180 seconds to 120 or 60 seconds.
• Switch to ingesting Alerts via the Data Forwarder input.
• Tune CB Analytics alerts that are known-good in your environment using the Dismiss all future alerts functionality.
• Follow recommendations from our Threat Research team here.
• Modify the configured Alert Input and increase the Minimum Alert Severity.
• Change the polling interval from the default of 180 seconds to 120 or 60 seconds.
• Switch to ingesting Alerts via the Data Forwarder input.
• No, but to be able to use the full set of features of the app, like assigning Policies, performing Right-click Actions, viewing Device information and more, we recommend adding them. This includes Product URL, Org Key, "API" Type Credentials, "Custom" Type credentials.
• Go to Devices Tab and filter by status:QUARANTINE.
• System Time is the current time of the QRadar console in the local time zone and Last Contact is in UTC time zone.
• When using the "Built-in" data input method, delays between the incoming data intervals can signify memory overload on the container. A combination of high bursts of Alerts for extended periods and low physical memory on the app container can cause a memory overload. As discussed in this thread, the app's memory is limited to 10% of the system's physical memory, and this can cause delays in Alert and general data processing. If you experience such symptoms, consider using the "Data Forwarder" input.
• Check whether Coalescing Events option for your syslog log source is enabled and the Event Count for Alerts is larger than 1.
• You may be hitting the default 4096kb TCP Syslog max payload size. To remediate this, increase the payload as some alerts exceed 4k, which prevents them from being logged correctly in QRadar. A step-by-step guide is available here.
• Check if you are hitting your QRadar Event Processor System (EPS) licensed limit. Detailed information can be found on the IBM support page.
• Update your app. A known issue in previous versions was causing a small percentage of Alerts not to be logged. This issue was resolved in v.2.2.0 of the app.
• You may be hitting the default 4096kb TCP Syslog max payload size. To remediate this, increase the payload as some alerts exceed 4k, which prevents them from being logged correctly in QRadar. A step-by-step guide is available here.
• Check if you are hitting your QRadar Event Processor System (EPS) licensed limit. Detailed information can be found on the IBM support page.
• Update your app. A known issue in previous versions was causing a small percentage of Alerts not to be logged. This issue was resolved in v.2.2.0 of the app.
Two new permissions are required for v2.2:
• Policies (org.policies) - READ
• Events (org.search.events) - READ.
• Policies (org.policies) - READ
• Events (org.search.events) - READ.
It is highly recommended to use version v2.2 or later of the app on QRadar 7.5 installations.
App Errors
• Go to Carbon Black Cloud > Settings > Actions to configure a watchlist.
• Enter valid query or leave field empty to bulk search.
• Fill out information under Settings > Configuration.
Although not required at the initial configuration of the app, once entered, the values under Settings > Configuration cannot be empty. To remediate this:
• Enter the necessary values.
• Click the "Close" button to revert to the previous configuration when you move away from the Settings page or after refresh.
• If the above options are not applicable in your situation, you can reset the configuration by clicking on Reset Configuration button (only available for admin users).
• Enter the necessary values.
• Click the "Close" button to revert to the previous configuration when you move away from the Settings page or after refresh.
• If the above options are not applicable in your situation, you can reset the configuration by clicking on Reset Configuration button (only available for admin users).
• "HTTPS" is the secure version of "HTTP", which is the primary protocol used to send data between a web browser and a website. If you need to configure a "Product URL" for your app, it is a requirement to use the full address.
• Polling Interval determines how frequently to pull data from the Carbon Black Cloud, in seconds. The minimum value is 60 seconds, and the maximum value is 600. Either choose a value within those boundaries, or click "Close" to revert the changes.
