Alerting: Work with Automated Threat Detection Results

Document created by RSA Information Design and Development on Apr 22, 2016
Version 1Show Document
  • View in full screen mode
 
  

This topic explains how to interpret and work with Automated Threat Detection results. 

When you view the Automated Threat Detection results in the Incident Manager, there are a number of different factors that are used to determine the overall score. This section is designed to help you understand how these scores are generated and what they mean. 

Understand Threat Detection Results

When you work with Automated Threat Detection, several scores are aggregated together to make up the Command and Control Detection score. To better understand how this score is triggered, it's a good idea to understand the elements that make up the final score. 

When you receive a Command & Control Detection alert, you can view the following detailed alert summary in the Incident Management module:

Each icon represents a different score that makes up the total risk calculated. Note that the scores are weighted, so each score represents a different proportion of the final score. For example, The beacon behavior score might be 20% of the final score, while the domain age might be 5%:

  1. Beacon Behavior. Command and control detection seeks to find highly regular periodic connections with a suspicious domain, so beaconing behavior has to do with how regularly the source IP is connecting to the domain server.  A high score means that connections between this source IP and the domain are highly regular. 
  2. Domain Age. Often, a Command and Control Server uses a new domain to create connections, so if a domain is new to the network, it means it is more likely to be a command and control domain. A high score indicates that this domain is relatively new on this network.  This score is derived from the Whois service. If your Whois service is not working, or if ESA cannot connect with it, the icon displays in gray.  If there is an issue with connectivity or the Whois service returns a null value or a value in an unexpected format, then a default value is used to estimate this score. This ensures that the overall scoring is more accurate. 
  3. Expiring Domain. Often a Command and Control server uses an expiring domain to create connections, so if a domain is soon to be expired, it is more likely to be a Command and Control domain.  This score is derived from the Whois service. If your Whois service is not working, or if ESA cannot connect with it, the icon displays in gray. If there is an issue with connectivity or the Whois service returns a null value or a value in an unexpected format, then a default value is used to estimate this score. This ensures that the overall scoring is more accurate. 
  4. Rare Domain.  A rare domain is one that that relatively few source IPs have been connected to on a given network in the most recent week.  If a domain is rarely used, the possibility of it being a Command and Control domain is higher than if it is a commonly used legitimate domain such as Google.com.
  5. No Referers. A referer is an HTTP field that identifies the address of the web page that linked to the resource being requested. For example, if I access my bank website from my work website, the work website would appear as the referer.  Because people frequently link to a site via a referer, a high score (meaning a low percentage of IPs connecting to this domain have used referers) indicates that a Command and Control communication is more likely. 
  6. Rare User Agent. User agents identifies the client software originating the request. A high score indicates that user agent associated with the IP address is not commonly used. Like the Rare Domain score, an uncommon user agent has a greater likelihood of being associated with a Command and Control domain.

 

The icons display in different colors, and the colors help to visually indicate the level of risk. See the table below for details.

                           
IconMeaning
Grey    No score was generated because no data was available. This may occur if the Whois service is disabled or there is no data available to generate a given score. 
Black     The score indicator is weak. 
Orange The score indicator is moderate.
Red       The score indicator is high. 

What to Do Next

There are three possible paths you may want to follow once you have viewed threat scores:

  • Drill down for more details.  For each score, there are multiple factors that make up a score. You can view these details on the Event Details page.
  • Investigate the domain in the Investigation module. You can go to the Investigations screen to get more details about the domain and related incidents.
  • Add domains to a whitelist. If you look at the details and determine that the domain in question is not a threat, it's a good idea to add it a whitelist. This will ensure the domain no longer triggers a Threat Detection score, and it helps to tune the accuracy of scoring.

Drill Down Into the Scores for More Details

Each event score is enriched with data to help you determine whether the communication with the domain is malware and the severity of the attack if it is. For each of the scores listed above, there are more details that are included in the details for each event.

To access these details:

  1. From the Incidents queue, double-click on an Incident to view the Incident Details.
  2. From the Alert Details section, double-click on an alert.
  3. The Event Details page opens.

 From there, you can view details for the event, and for each detail, there is hover-over text to help you interpret the data. You can see details such as the score range, the number of occurrences for each time of score, the beaconing period, the information available from the Whois registration data, etc. 

 For example, you can see from the following event details that the Rare Domain score was 100 (the highest score), but that there was only one IP associated with this domain, and there were 24 occurrences in the previous week.   

Investigate the Domain from the Investigation Module

From the Alert Details, you can also open the Investigations module to drill down into the domain details. To do this, from the Alert Details click ic-actns.png > Investigate Destination Domain. From there, you can search the days surrounding the event to see what else may have occurred, and view other details about the event. 

Reduce False Positives

 Sometimes, a domain you access regularly may trigger an Automated Threat Detection score. For example, a weather service might have the same beaconing behavior as a Command and Control communication, thus triggering an unwarranted negative score.  When this happens, it's called a false positive. If, after investigating the event, you discover it is a false-positive, you can mark it as a false-positive, which will add the domain to a whitelist. Once the domain is added to the whitelist, it will not trigger an Automated Threat Detection score. 

Note: If you use SecOps or another ticketing solution, you can manually add domains to the white list using the Context Hub service. See "Step 2: Configure a Whitelist" in Configure Automated Threat Detection

Procedure 

  1. From the Incidents Detail page, you can mark a particular incident as a false-positive which will automatically add it to the whitelist.  
    1. From the Incident Manager, select the incident which triggered a false-positive score. Click ic-actns.png > Edit Incident.
      The Edit Incident dialog box displays. 
    2. In the Edit Incident dialog box, click the Status field and select Closed-False Positive. This adds the domain to the whitelist and closes the incident.  Once the domain is added to the whitelist, it is ignored when Automated Threat Detection scoring occurs. 

 

You are here: Use Automated Threat Detection > Work with Automated Threat Detection Results

Attachments

    Outcomes