NetWitness Investigate provides data analysis capabilities in RSA NetWitness Platform, so that analysts can analyze packet, log, endpoint, and UEBA data, and identify possible internal or external threats to security and the IP infrastructure. This guide helps analysts perform investigations of endpoint data using NetWitness Investigate.
For more information, see the NetWitness Endpoint Quick Start Guide, the NetWitness Investigate Quick Start Guide, and the NetWitness Investigate User Guide.
Endpoint metadata is generated when hosts are scanned and when there are real-time activities on the hosts. You can view the following categories of sessions when metadata forwarding is enabled:
|Operating System||Scan Categories||Tracking Categories|
file, service, dll, process, task, autorun, machine, kernel hook, image hook, registry discrepancies, and suspicious threads
|Linux||file, autrorun, loaded library, systemd, process, cron, initd, and machine||-|
|Mac||file, daemon, process, task, dylib, autorun, and machine|| |
For more information on metadata, meta keys, meta values, and meta entities, see the NetWitness Investigate User Guide.
Analysts can use the risk score to begin an investigation on hosts and files. RSA uses a proprietary algorithm to calculate the risk scores ranging from 0 to 100. A subset of alerts associated with hosts and files contribute to the risk score calculation. Analysts can review critical and high alerts associated with a risk score to identify strong evidence of malicious activity and take required action.
The following factors contribute to the risk score:
Distinct Alerts. Any host or file activities that are suspicious or malicious generate alerts. Only the distinct alerts are used for risk score calculation.
Severity of Alerts. Severity of alerts, such as critical, high, and medium.
All the distinct alert shown in the above example can be for the same file or different files. For example, Configures Image Hijacking alert is triggered for files, such as malware4.exe and malware7.exe.
This figure is an example of files with distinct alerts. Each file can have a multiple distinct alerts. The files can have a same alert name being triggered by two different hosts as shown below.
Besides the above factors, the risk score is reset when you perform any of the following actions:
- Whitelist or blacklist a file after investigation. The risk score of a file is set to 0 on whitelisting and set to 100 on blacklisting.
- If the alerts or events triggered by the host or files on the host are false positive, you make changes to the Endpoint Application rules or ESA rules and reset the risk score.
The host risk score depends on the risk score of all the files on the host. When you change the file status or reset the file risk score, the host risk score is recalculated. For example, the score for all the hosts on which a blacklisted file is present is recalculated and becomes 100. If the host is not found to be infected, you can reset the host risk score. This deletes the alerts contributed to the risk score and does not impact the global file score. For more information on changing the file status, see Changing File Status or Remediate.
The following table depicts the risk score range based on the associated alert severity:
|Severity||Color||Risk Score Range|
The following is an example of alerts contributing to the risk score:
In the above example, there are three distinct critical alerts. For each alert type, associated events are displayed. You can see that the "Enables Cleartext Credential Storage" alert was triggered twice. The details of the two events are displayed with the metadata information. For more information on severity alerts and metadata information, see Analyze Hosts Using the Risk Score and Analyze Files Using the Risk Score.
Global and Local Risk Score
Analysts can get better context on file activities on hosts using the global risk score and the local risk score of a file.
Global Risk Score - The global risk score is an aggregate of all suspicious and malicious activities performed by the file across all hosts. This score indicates the potential threat posed by the file across the NetWitness Platform.
Local Risk Score - The local risk score is calculated on suspicious or malicious activities performed by the file on a specific host. The local risk score is used for the host risk score calculation.
Automated Incident Creation Based on Risk Score
By default, a threshold is set for the risk score to control the generation of incidents and alerts in NetWitness Respond. For more information on configuring the threshold limit, see the NetWitness Respond Configuration Guide.
The File Reputation service available on RSA Live checks the reputation of every file hash against an extensive database of known file hashes updated in real-time. The file reputation is displayed on the Investigate and Respond views.
The reputations for a file hash are:
|Malicious||File hash is labeled as malicious.|
|Suspicious||File hash is suspected to be malicious.|
|Unknown||File hash is not known.|
|Known||File hash information is known to the file reputation service and does not have any previous bad record.|
File hash information is known good, such as files signed by Microsoft or RSA.
|Invalid||File hash format is invalid.|
The suspicious or malicious files are available for further analysis in the Investigate > Navigate view and Investigate > Events view. For more information on the file reputation service, see the Live Services Management Guide.
To help analysts triage and focus on their investigation, NetWitness Platform provides capabilities to manage suspect and legitimate files. For example, you can whitelist files that are legitimate (such as security products), or blacklist files based on known threats and investigation.
A file can be classified as follows:
Blacklist: File that is marked suspicious, such as when ransomware is found by scan.
Graylist: File that is marked for a later review.
Whitelist: File that is legitimate and is not to be considered for risk scoring.
Neutral: Default status.
For more information, see Changing File Status or Remediate.
If a file is malicious or infected, you can block the file to prevent future execution on any host. Remediation helps to:
- Stop or reduce the spread of identified malware, such as viruses, trojans, rootkits, worms, spyware, and adware.
- Identify attempted breach points to aid in deeper analysis; all events are time-stamped allowing analysts to trace backward to identify the entry point.
- Remove unwanted software, such as adware, which can potentially mask real malware.
- Stop all actions possible by the loader.
You can block files with the following file extension: EXE, COM, SYS, DLL, SCR, OCX, BAT, PS1, VBS, VBE, and VB. For more information, see Changing File Status or Remediate.
If you suspect that a host is potentially compromised with the threat still being active, you can isolate the host from the network and safely investigate possible threats within the host. By isolating the host, you can control the spread of an attack and analyze the malware behavior. When a host is isolated, only connection to the following IP addresses are allowed:
- Endpoint Server, Relay Server, DNS, DHCP, Gateways, 0.0.0.0, and 255.255.255.255.
- Other IP addresses that you include in the exclusion list.
In the isolated state, all events are reported to the Endpoint Server retaining full visibility into activities on the host. You can continue investigation by requesting scans, downloading MFT, files, and so on. The following metadata is added to the network events:
- network.isolated - indicates that the host is isolated.
- network.connectallowed - indicates that the network connection is allowed as the IP address is included in the exclusion list.
- network.connectblocked - indicates that the network connection is blocked.
For more information, see Isolating Hosts from Network.