RSA NetWitness Platform Automated Threat Detection uses preconfigured ESA Analytics modules to identify specific types of threats. An ESA Analytics module is a pipeline composed of activity objects that enrich an event with additional information through mathematical computations. ESA Analytics modules reside within ESA Analytics services. The ESA Analytics services use query-based aggregation (QBA) to collect filtered events for the modules from Concentrators. Only the data required by a module is transferred between the Concentrator and the ESA Analytics system.
There are two ESA services that can run on an ESA host:
- ESA Correlation (ESA Correlation rules)
- Event Stream Analytics Server (ESA Analytics)
The first service is the ESA Correlation service that creates alerts from ESA rules, also known as ESA Correlation Rules, which you create manually or download from Live. The second service is the ESA Analytics service, which is used for Automated Threat Detection. Because the ESA Analytics service uses preconfigured modules for Automated Threat Detection, you do not have to create or download rules to use Automated Threat Detection.
NetWitness Platform Automated Threat Detection currently has two Suspicious Domain modules available, Command and Control (C2) for Packets and C2 for Logs.
Because each ESA Analytics module has different data requirements, be sure that all module-specific requirements are met before you deploy a module for Automated Threat Detection.
Automated Threat Detection for Suspicious Domains
The Suspicious Domains modules examine your HTTP traffic to detect domains likely to be malware Command and Control servers connecting to your environment. After NetWitness Platform Automated Threat Detection for Suspicious Domains examines your HTTP traffic, it generates scores based on various aspects of your traffic behavior (such as the frequency and regularity with which a given domain is contacted). If these scores reach a set threshold, an ESA alert is generated. This ESA alert is forwarded to the Respond view. The alert in the Respond view is enriched with data that helps you to interpret the scores to determine what mitigation steps to take.
The Automated Threat Detection Suspicious Domain modules provide scoring to detect Command and Control communications. Command and Control communications occur when malware has compromised a system and is sending data back to a source. Often, Command and Control malware can be detected via beaconing behavior. Beaconing occurs when the malware regularly sends communications back to the Command and Control server to notify it that a machine has been compromised and the malware is awaiting further instructions. The ability to catch the malware at this stage of compromise can prevent any further harm from occurring to the compromised machine and is considered a critical stage in the "kill chain."
NetWitness Platform Automated Threat Detection solves several common problems that occur when searching for malware:
- Ability to use algorithms rather than signatures. Because many malware creators have begun using polymorphic or encrypted code segments, which are very difficult to create a signature for, this approach can sometimes miss malware. Because NetWitness Platform Automated Threat Detection uses a behavior-based algorithm, it is able to detect malware more quickly and effectively.
- Ability to automate hunting. Hunting through data manually is an effective but extremely time-consuming method of finding malware. Automating this process allows an analyst to use his or her time more effectively.
- Ability to find an attack quickly. Instead of batching and then analyzing the data, Automated Threat Detection analyzes data as it is ingested by NetWitness Platform, allowing for the attacks to be found in near real time.
Suspicious Domains Module Workflow
NetWitness Platform Automated Threat Detection works much like a filtering system. It checks to see if certain behavior occurs (or certain conditions exist), and if that behavior or condition occurs, it moves to the next step in the process. This helps to make the system efficient, and frees up resources so that events that are determined to be non-threatening are not held in memory. The following diagram provides a simplified version of the Suspicious Domains module workflow.
1.) Packets or logs are routed to the ESA. The HTTP packets or logs are parsed by the Decoder or Log Decoder and sent to the ESA host.
2.) Whitelist is checked. If you created a whitelist through the Context Hub, ESA checks this list to rule out domains. If a domain in the event is whitelisted, the event is ignored.
3.) The domain profile is checked. Automated Threat Detection checks to see if the domain is newly seen (approximately three days), has few source IP connections, has many connections without a referer, or has connections with a rare user agent. If one or several of these conditions is true, the domain is next checked for periodic beaconing.
4.) The domain is checked for periodic beaconing. Beaconing occurs when the malware regularly sends communications back to the command and control server to notify it that a machine has been compromised and the malware is awaiting further instructions. If the site displays beaconing behavior, then the domain registration information is checked.
5.) Domain registration information is checked. The Whois service is used to see if the domain is recently registered or nearly expired. Domains that have a very short lifespan are often hallmarks of malware.
6.) Command and Control (C2) aggregates scores. Each of the above factors generates a separate score, which is weighted to indicate various levels of importance. The weighted scores determine if an alert should be generated. If an alert is generated, the aggregated alerts appear in the Respond view and can then be investigated further from there. Once the alerts begin to appear in the Respond view, they continue to aggregate under the associated incident. This makes it easier to sort through volumes of alerts that can be generated for a command and control incident.
Analysts can view the alerts in the Respond view.
Suspicious Domains Automated Threat Detection on Packets vs. Web Proxy Logs
RSA NetWitness Platform provides you with the ability to perform Automated Threat Detection for Suspicious Domains using either packets or web proxy logs. While packet data can be streamed directly off of the wire into the NetWitness Platform installation and analyzed directly, if you have the ability to use a web proxy in your installation it may be beneficial to use it. Because some installations use network translation or SSL encryption, the true source IP of an outgoing connection may be masked if you are observing it at the packet level. By using a web proxy you gain the benefit of its ability to accelerate and decrypt SSL traffic as well as its ability to track the true source IP addresses of traffic it monitors.
Both Suspicious Domains for Packets (C2 for Packets) and Suspicious Domains for Logs (C2 for Logs) should produce the same results. From a results point of view, there is no real advantage to using one over the other.