Skip navigation
All Places > Products > RSA NetWitness Platform > RSA NetWitness Platform Online Documentation > Documents
Log in to create and rate content, and to follow, bookmark, and share content with other members.

Endpoint: Introduction

Document created by RSA Information Design and Development Employee on Apr 11, 2019Last modified by RSA Information Design and Development Employee on Nov 11, 2020
Version 25Show Document
  • View in full screen mode

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.

Note: In Version 11.1 and later, the Hosts and Files views provide a view into endpoint data. Earlier versions offer access to endpoint data using a standalone NetWitness Endpoint server.

For more information, see the NetWitness Endpoint Quick Start Guide, the NetWitness Investigate Quick Start Guide, and the NetWitness Investigate User Guide.

Endpoint Metadata

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 SystemScan CategoriesTracking Categories

file, service, dll, process, task, autorun, machine, kernel hook, image hook, registry discrepancies, and suspicious threads

  • Process event - Reports any process related activities, such as openprocess, openosprocess, createprocess, createremotethread, openbrowserprocess.
  • File event - Reports any file related activities by an executable, such as readdocument, writetoexecutable, renameexecutable, selfdeleteexecutable, openphysicaldrive.
  • Registry event - Reports activities that result in registry creation or modification, such as modifyservicesimagepath, modifyfirewallpolicy, createservicesimagepath, createsecuritycenterconfiguration, modifybadcertificatewarningsetting.
  • System event - Reports IP change and boot events.
  • Network event - TCP/UDP and incoming/outgoing.
    • Reports outbound and inbound network connections on all supported Windows platforms.

    • Reports IPv4 and IPv6 connections.
  • Console event (for Windows 8 and later) - User input that is entered into a console application, such as cmd.exe, powershell.exe, is captured and reported with the context console.local.

    Commands executed by cmd.exe, powershell.exe as a result of inter-process communication through anonymous pipes are captured and reported with the context console.remote.

    For example, Get-Item -Path Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\

Linux file, autrorun, loaded library, systemd, process, cron, initd, and machine-
Macfile, daemon, process, task, dylib, autorun, and machine
  • Process event - Reports any process related activities, such as openprocess, createprocess, openosprocess, openbrowserprocess, allocateremotememory, createremotethread.
  • File event - Reports any file related activities by an executable, such as writetoexecutable, renameexecutable, createautorun, deleteexecutable, selfdeleteexecutable, writetoplist, writetosudoers, createbrowserextension.
  • Network event - TCP/UDP and incoming/outgoing.
    • Reports outbound and inbound network connections on all supported Mac operating system.
    • Reports IPv4 and IPv6 connections.

For more information on metadata, meta keys, meta values, and meta entities, see the NetWitness Investigate User Guide.

Risk Score

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.

Note: If you have an Insights agent, you can view the risk score for files but not for hosts. To view the risk score for hosts, upgrade to the Advanced agent. For more information, see the NetWitness Endpoint Configuration Guide.

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.

    This figure is an example of a host with 2 Critical, 10 High and 12 Medium distinct alerts.
    Host with distinct alerts

    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.

    Host with distinct alerts

    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.

    Files with distinct alerts

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.

Note: When you whitelist a file or reset the risk score, the alerts that contributed to the risk score are not shown in the Host Details tab.

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.

Note: For the risk score calculation, the ESA Correlation server must be configured with an Endpoint Concentrator. The application rules are automatically deployed on installation. For an upgrade, you must deploy the application rules from RSA Live. For more information, see the NetWitness Endpoint Configuration Guide.

Note: For the accurate risk score calculation, the default multi-valued meta keys are required on the ESA Correlation service. For more information, see "Configure Meta Keys as Arrays in ESA Correlation Rule Values" section in the ESA Configuration Guide.

Severity of Alerts

The following table depicts the risk score range based on the associated alert severity:

SeverityColorRisk Score Range

The following is an example of alerts contributing to the risk score:

Aerts severity 

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.

For more information on the global and local risk score, see Investigating Files and Investigating Hosts.

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.

File Reputation

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:

MaliciousFile hash is labeled as malicious.
SuspiciousFile hash is suspected to be malicious.
UnknownFile hash is not known.
KnownFile hash information is known to the file reputation service and does not have any previous bad record.

Known Good

File hash information is known good, such as files signed by Microsoft or RSA.

InvalidFile 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.

Note: The File Reputation service supports maximum of 10 million files for a reputation of file hash.

File Status

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.

Network Isolation

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,, and
  • 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.

Note: If the agent is enabled for log or file collection, make sure that you add the Log Decoder IP addresses in the exclusion list while you isolate the host.

For more information, see Isolating Hosts from Network.

You are here
Table of Contents > Introduction