3 Key Takeaways from NIST SP 800-167: Guide to Application Whitelisting

The National Institute of Standards and Technology (NIST) is a physical sciences laboratory and a non-regulatory agency of the United States Department of Commerce. NIST’s SP 800-167: Guide to Application Whitelisting provides a comprehensive overview of application whitelisting, including guidance to help organizations understand, evaluate, and implement application whitelisting technology 

In this blog, we’ll explore three key takeaways from NIST SP 800-167, and why they matter for your organization.

What is Application Whitelisting?

Before diving into the takeaways, here’s a quick introduction to application whitelisting as defined by NIST. Application whitelisting technologies are used to stop the execution of malware and other unauthorized processes. In many ways, application whitelisting is the opposite of security technologies like antivirus which use blacklists to block known–bad activity and permit all others. According to the NIST Special Publication 800-167 Guide to Application Whitelisting: 

An application whitelist is a list of applications and application components (libraries, configuration files, etc.) that are authorized to be present or active on a host according to a well-defined baseline. The technologies used to enforce application whitelists—to control which applications are permitted to be installed or executed on a host—are called whitelisting programs, application control programs, or application whitelisting technologies. 

Takeaway 1: Whitelisting Attributes Can Make or Break Your Security

Application whitelisting can be done in many ways using application file and folder attributes. NIST SP 800-167 lists five major types of attributes that are used to whitelist applications. Each of the five has pros and cons, and in most cases, it’s best to use two or more attributes to strengthen security.  

File Path: This is the most general attribute and is used to permit all applications contained within a particular path (directory/folder). Used by itself, this is a very weak attribute, because it allows any malicious files placed within the directory to be executed. 

File Name: This attribute is used to whitelist the name of an application file. However, if a file were to become infected or be replaced, its name would be unchanged, so the file would still be executed under the whitelist. 

File Size: This attribute assumes that a malicious version of an application would have a different file size than the original. But this assumption may not always hold true, which is why it’s typically used only in combination with other attributes, such as filename. 

Cryptographic Hash: A cryptographic hash provides a reliable, unique value for an application file. Hashes are accurate no matter where the file is placed, what it is named, or how it is signed. However, a cryptographic hash is not helpful when a file is updated, such as when an application is patched. 

Digital Signature or Publisher: A digital signature also provides a unique value for an application file that is to be verified by the recipient to ensure that the file is legitimate and has not been altered. Unfortunately, many application files aren’t signed by their publishers, so using this attribute may not always be possible. 

As mentioned above, each of the five whitelisting attributes has its limitations. NIST recommends using a combination of two or more of these attributes for better protection. But to ensure that whitelisting delivers the best possible security, it needs to be as granular as possible. This can be achieved when whitelisting is done at the kernel or the process level. Apart from the five types of whitelisting attributes stated by NIST, whitelisting solutions with process attributes ensure that no malicious process can execute on the host.  

However, even whitelisted processes can be exploited to infiltrate the network. To prevent this possibility, an additional layer of context-based authorization should be deployed, which basically means control over both parent and child processes. For example: If a whitelisted Microsoft Word process like winword.exe spawns a powershell.exe, it is likely malicious and must be prevented. Whitelisting solutions which provide context-based, process-level control can effectively secure applications from ransomware, fileless malware, zero-day attacks, and other modern-day threats. 

Takeaway 2: Application Whitelisting Mitigates Unknown Threats

Application whitelisting mitigates multiple categories of threats and is especially effective in protecting against unknown malware. Most malware infects the host by exploiting existing vulnerabilities in the host software or disguising itself as a legitimate application or process. If it has a known signature, traditional security solutions like antivirus detect it during scans and quarantine the malware file. However, new and unknown strains of malware keep emerging, and a large percentage of attackers use fileless malware, making it almost impossible for antivirus to detect and prevent threats.  

Application whitelisting takes a proactive approach by allowing only the known good and preventing all other unauthorized processes and applications from executing on the host. When properly configured, application whitelisting technologies can stop most malware from being executed and from being installed. Application whitelisting also prevents unauthorized and older versions of software from being installed. Such software introduces vulnerabilities into the host which could be exploited by attackers to compromise the host.  

Takeaway 3: Application Whitelisting Has Additional Security Benefits

Application whitelisting is primarily used to provide application control and protect applications from threats by limiting the host to running only the known good. However, NIST states that application whitelisting can have other operational benefits too. 

Software Inventory: Since application whitelisting technologies need to provide visibility into applications running on your endpoints and servers, they can be used to keep an inventory of all the applications and application versions installed. Organizations can use this information to identify unauthorized applications – unlicensed applications, prohibited applications, etc. – and to identify “wrong” versions of software that are still running. This information is also useful for forensic investigations. 

File Integrity Monitoring: Most application whitelisting technologies can perform frequent or continuous monitoring of attempted changes to application files. Some technologies can prevent files from being changed, or immediately report when changes occur. In both cases, any malicious behavior or attempts to breach can be detected sooner. 

Incident Response: When responding to an incident on an endpoint or server, the organization captures the characteristics – like cryptographic file hashes – of the malicious files on that host. Application whitelisting technologies can be used to check other hosts for the same files to detect and contain the spread of malware. 

See Application Whitelisting in Action

As attacks get more sophisticated and the number of unknown threats increases, securing applications that are critical for business can become challenging. The NIST Special Publication 800-167 Guide to Application Whitelisting provides a definitive framework highlighting the effectiveness of using application whitelisting as a security solution. When implemented properly, whitelisting is the most effective method of protecting your applications from known and unknown threats. 

ColorTokens Xprotect delivers powerful whitelisting capabilities to lock down endpoints and servers that host applications. It works at the kernel level to detect and prevent unauthorized processes, thereby protecting applications from breaches, malware, ransomware, and zero-day attacks. Schedule a 1-1 demo to see how it can help your organization defend against cyber threats.

About the Author: Vivek Biswas is a Product Manager at ColorTokens. He has been developing software products and services both as a developer and a product manager for the last 7 years. He has a B.Tech in Materials Engineering from IIT Roorkee and an MBA from the Indian School of Business.