As you review anomalies of interest, you can provide relevance feedback to the system, and train it to prioritize reporting certain types of anomalies over other less relevant anomalies. Relevance feedback is binary; an anomaly is either relevant or irrelevant . You do not have to provide relevance feedback, as the system's DRL algorithms can function independent of user feedback. However, providing this feedback improves the system's traffic model, and allows it to better report anomalies.
Relevance feedback is independent of
mitigations. You can choose to mark an anomaly as relevant, and not configure a
mitigation to address the anomaly. Similarly, you can choose not to assign relevance
feedback, yet still configure a mitigation for the anomaly. The system does not consider
the presence or absence of a mitigation as a proxy for relevance feedback.
The system continues to present non-relevant
anomalies for confirmation from the user that the anomalies are still not relevant.
If you create a whitelist rule, the system does not interpret that as relevance feedback. You can assign relevant feedback () or irrelevant feedback () to an anomaly, then subsequently configure a whitelist rule based on that anomaly. However, you can create a situation where you train the system to report a certain type of anomaly, then whitelist that type of anomaly. The system continues to report this type of anomaly, but the whitelist rule suppresses it from the anomaly inbox. This can severely impact system functionality.
You can assign relevance feedback either from
the anomaly inbox, or from the anomaly detail view. Because the inbox provides a summary
view of anomalies, assigning relevance feedback in the inbox is best for anomalies
obviously relevant or not relevant. For example, if several anomalies concern a file
server over an unexpected new edge at an unusual time, you can mark all of these as
relevant from the inbox view.
However, to modify the example, if the
anomalies are due to a large number of bytes downloaded from a file server, you can view
each anomaly's details to better determine whether the download traffic is legitimate or
malicious. You can then assign relevance feedback from the anomaly detail view.
After you assign relevance feedback, if new
information presents itself, you can change the assigned feedback. If you marked
anomalous download behavior from the example file server as relevant in the inbox, then
viewed the anomaly details and discovered the source host is located in a secure client
site, you can change the feedback to not relevant.
Relevance Feedback and Whitelist Rule Use
Relevance feedback allows the system to learn about what types of traffic you consider relevant and irrelevant. The system learns what types of anomalies to report and suppress based on the accumulated feedback.
Whitelist rules, on the other hand, direct the system to never report anomalies that match specific patterns, such as irregular traffic from a trusted host, and to allow that traffic. The system does not update its DRL algorithms as a result of whitelist rules. It can still report anomalies with similar behavior, originating from non-trusted hosts, or other types of irregular behavior from the trusted host.
Assign relevant feedback () if you find an anomaly's traits interesting and want to view more anomalies with similar traits. Assign irrelevant feedback () if you find an anomaly's traits uninteresting, and do not want to view any more anomalies with similar traits. For example, assume a trusted host sends a small number of bytes of HTTP traffic to an external HTTP server, and such behavior is irrelevant to your deployment for any host. If you:
assign irrelevant feedback () to this anomaly, and to similar anomalies, the system learns over time to not report similar anomalies. The anomalies presented in the inbox are overall more relevant to your deployment.
create a whitelist rule for this behavior, the system does not report an anomaly for this case, but does report anomalies for non-trusted hosts which send a small number of bytes of HTTP traffic to an external HTTP server. The anomalies presented in the inbox are overall less relevant to your deployment.
Create whitelist rules when you want to allow irregular behavior for a trusted host and do not want to see an anomaly, but that same behavior in non-trusted hosts would cause concern, and you want to see those anomalies. For example, assume a trusted host creates a long-lived DNS connection to a public HTTP server, and is authorized to do so. If you:
whitelist this host's behavior, the system no longer reports anomalies for the trusted host's long-lived DNS connections to that server. The system can still report anomalies if non-trusted hosts create similar connections. The anomalies presented in the inbox are overall more relevant to your deployment.
assign irrelevant feedback () to this and similar anomalies, over time, the system learns to not report similar anomalies for long-lived DNS connections created by hosts, trusted and non-trusted. The anomalies presented in the inbox are overall less relevant to your deployment.
While you do not have to create a whitelist rule and assign relevance feedback for an anomaly, you can use both in conjunction to enhance the anomalies reported to the inbox. In the previous example, if you whitelist the trusted host's behavior, and assign relevant feedback () to the anomaly, the system no longer reports anomalies for the trusted host's long-lived DNS connections, and learns to report non-trusted hosts' long-lived DNS connections to the external server.
For more information on whitelist rules, see Anomaly Whitelist Rules.