Process Hash Anomaly Detection

As the name suggested, this feature detects process hash anomalies by assessing the consistency of process binary hashes across the system. The motivation of this feature is as follows. Imagine that you have a farm of Apache web servers that are cloned from the same setup configuration (for example, those servers are deployed from the same automation scripts). You can expect that the hashes of httpd binaries on all servers are the same. If there is a mismatch, it is an anomaly and might worth a further investigation.

Formally, we define a process group as the set of processes across workloads in the same rootscope that have the same combination of executable binary path, OS version, and package info (if applicable)1.

Package information is included since 3.4 release; in the previous releases, the process group is defined based on the combination of executable binary path and only the OS version.

In the above example, if all Apache web servers are running httpd 2.4.43 on CentOS 7.7 and in the same rootscope, then the corresponding process group is the set of processes (across all servers) that have the same combination: binary path of /usr/sbin/ httpd & OS version of CentOS-7.7 & package version of httpd-2.4.43. It is expected that the hashes of all binaries in the same process group are the same, and an anomaly will appear if any mismatch is detected.

Besides detecting anomalous process hashes, this feature also detects process hashes that appear in a Flagged list File Hashes that are uploaded. The motivation is that you may have a list of known malware hashes, and want to know if a process associated with any of these hashes is run.

To reduce false alarms, we use the National Software Reference Library’s Reference Data Set (RDS) provided by NIST, also called NIST RDS dataset as a Benign list; a benign hash is considered “safe” (see the Analyze Threat Intelligence Reports section on how to enable NIST RDS dataset). Also, you can see the File Hashes section to upload from your own hash Benign list.

In addition to the NIST RDS dataset, we also curate Secure WorkloadHash Verdict service. When you enable the service, if any known malware hash shows up, it is detected as a malicious hash. However, if the hash is known and legit, then it is also marked as benign in the anomaly analysis. Due to the large dataset and fast updates that cover all known and legit process hashes that can be used to either approve or red flag processes running on a workload, Secure WorkloadHash Verdict is only available through Secure Workload Cloud. To ensure that Secure WorkloadHash Verdict service is accessible from your appliance, see Automatic Threat Intelligence Updates.

Output of this feature is a security score known as process hash score. This score is calculated and output hourly. Like all other security scores, a higher process hash score is better. In particular, for a process hash:

• Hash score of 0 means that the hash is flagged or malicious.

• Hash score of 100 means that the hash is either benign, or consistent across workloads (no mismatch)

• Hash score from 1-99 means that the hash is considered anomalous (that is, there is some mismatch)

The process hash score of a workload is the minimum process hash score of all hashes observed in that workload, with 0 meaning there is a flagged or malicious process hash in the system, and 100 meaning there is no hash anomaly observed in the system.