Version
Cb Defense (current) - All Versions
Topic
Sometimes events may come across as unwanted notifications/alerts. Cb Defense system collects program activities (these are called events). The analytics process in the cloud collects these events for analysis and will generate notifications or alerts for system administrators. These alerts show up in the dashboard in the Alerts page. Depending on notification settings (found under Settings -> Notifications) these alerts may generate email notifications or SIEM / Syslog messages. The purpose of these alerts is to provide highlights of security events to the system administrators. However, some notifications (events that analytic process considers to be significant security events) may be considered by the customer as normal behavior. That is a condition that can be described as false positive (FP).
Important Note(s)
False positives are subjective and security best practices can widely vary from organization and industry, i.e. there is a valid technical reason for the product to present something as a (potential) security risk/threat; Yet the behavior is seen as normal by the user. If you receive a report of a false positive that is based on something that you suspect shouldn't have been detected by the product as a (potential) security risk/threat in the first place, all such cases should be escalated to Cb Technical Support for further investigation and escalation. The analytics logic used by Cb Defense is constantly maturing and evolving. We want customer feedback as it is essential to help continuous improvement of Cb Defense.
Methods:
Below are the common approaches to eliminate or reduce unwanted alerts & notifications (i.e. false positives and/or unwanted "noise")
- Add object hash to Company white list
Company white list is specific to the organization. Hash added to the company white list carries a significance to analytics process that it is a safe executable - this will reduce the likelihood that its activities being raised as security significant.
See How to whitelist or blacklist a hash for details.
- Dismiss activity and Apply for future instances (Bulk Dismiss)
When an alert is dismissed - system administrators can specify future instances of the same alert be automatically dismissed. This option is based on unique identifiers like hash and TTP. If even one identifier changes then you will receive the alert again. This approach differs from the above in that alerts are still created, but the notification emails are not sent.
The ability to dismiss with persistence has been added in CTP UI update. See more in CTP UI Update - What's New.
- Add path base permission rules to "allow" or "bypass"
From the policy page, a system administrator may specify a file path name based rule to "allow" or "bypass." Default behavior for the sensor software is "allow and log," which means "events" will be generated and reported to the cloud. When the permission rule is "allow," the activity will be permitted to proceed and events are NOT reported to the cloud. Bypass indicates to the sensor software to no longer hook into the API. In case of bypass , the sensor software will not monitor the executable (thus no report of the executable's activities). This is a workaround condition. It is important to report these corner cases to Customer Support so that Engineering cases can be logged and investigated. This is only one of many effective methods for Cb Defense analytics to evolve. We can take various opportunities for feedback from all types of organizations and enhance the analytics.
See more on setting up rules in How to create Policy Blocking & Isolation and Permissions Exclusions, Cb Defense: How to set up exclusions for AV products, Running Cb Defense (formerly Confer Sensor) on Software Developer's Workstation and Software Build S....
