With attempted cyberattacks on the rise, application whitelisting can be an important addition to your security infrastructure. It is a simple yet effective tool to prevent zero-day attacks and unknown malware from accessing applications. Application whitelisting takes advantage of a variety of application file and folder attributes to ensure that only vetted and whitelisted files/processes are allowed to run. Here are six types of application whitelisting attributes that can be used to secure applications.
File Path Whitelisting
File path whitelisting is a common type of whitelisting which allows all applications in a specified path to run. File path whitelisting has two variations: Directory-based whitelisting where every file in the directory and subdirectories are allowed, and complete file path whitelisting where only the specified filename matching the file path is allowed. To illustrate further, if you whitelist the entire directory, C:/windows/program files>, every file in the directory <program files> will be allowed to execute. However, if you specified the complete path, C:/windows/program files/hello.exe, then only the specified filename hello.exe from the directory <program files> will be allowed to run.
To make this attribute stronger, it is recommended to use directory-based whitelisting sparingly and use complete file path-based whitelisting whenever possible. The benefit of using file path whitelisting is that each updated version of the file within a particular path need not be listed separately, reducing the need to update the whitelist for every new patch or application. For example: If C:/windows/programfiles/hello.exe is whitelisted, even if hello.exe gets updated as part of a Microsoft update process, the whitelist would still work as long as the updated file still bears the same path and file name.
Using the filename as an attribute is also a possibility, but it, too, has many shortcomings. Should the file become infected or be replaced with a different file of the same name, it would still be allowed to execute. An attacker could also place a new malicious file and use the same name. These weaknesses are easily exploited by cybercriminals. For example: If the filename hello.exe is whitelisted, a hacker can create a malicious version of the file, rename it as hello.exe, and it would be allowed to run. This is why filename whitelisting should always be combined with cryptographic hash (explained below) to ensure greater security.
File Size Whitelisting
The use of file size is not a strong attribute in itself, but it can be used in combination with other attributes to protect the host. The assumption here is that the malicious version of an application will have a file size that is different from the original. However, this assumption does not always hold true, as attackers have been known to create malicious files that are the same size as whitelisted ones. To secure the host, this attribute should be used with other attributes like cryptographic hash and digital signature.
Cryptographic Hash Whitelisting
A cryptographic hash provides unique value to an application file. Whitelisting using this attribute will ensure that only hashed files are allowed to execute, regardless of the file name, file location, or signature.
While this is a strong attribute, using a cryptographic hash presents certain operational challenges. For example, it’s not helpful when a file is updated since the updated file will have a different hash value. So, every time an update or a patch is initiated, the updated cryptographic hash also needs to be included in the whitelist. Otherwise, the application may not run, and business continuity may be impacted. The whitelist should also be regularly updated to remove existing hashes for older software versions with known vulnerabilities.
Digital Signature or Publisher Whitelisting
The digital signature of an application file can be a unique whitelisting attribute. It can be used to verify the authenticity of the file and therefore, to conclude that the file has not been tampered. But since not all publishers digitally sign their application files, it’s not possible to rely exclusively on this attribute.
Publisher identity is another attribute that can be used for verification instead of individual file signatures. The assumption is that applications from trusted publishers can be trusted. However, if the publisher has multiple applications, the whitelist will not be able to differentiate between the ones that need to be executed from the ones that have to be restricted. Another drawback of using publisher identity is that it would allow older software versions with known vulnerabilities to be executed. The benefit, though, is that the whitelist needs updates only when there is a new publisher or when a publisher updates their signature key.
Whitelisting can also be done at the process level by selecting only those processes that are relevant to run specific applications. Using process as an attribute locks down systems by allowing legitimate processes to run while preventing the execution of all other processes. The advantage of using this type of whitelisting is that it is more granular and secures applications against all unknown threats. However, there is a possibility that a whitelisted process could be exploited to gain access to applications. To effectively deploy process whitelisting, it is essential to have context-based authorization capabilities. When using process as a whitelisting attribute, it is important to monitor and create access control for all parent and child processes.
For example: Even though Chrome.exe has been whitelisted, the processes it is allowed to spawn and not allowed to spawn must be specified. While another browser/chrome process could be spawned by Chrome, it should not be allowed to spawn powershell.exe. This should be deemed as suspicious behavior and the process must be immediately stopped. By the same logic, if the notepad program in your computer were to make random network connections to the internet, it may be safe to conclude that it has been compromised.
Sophisticated and new strains of malware have made it increasingly difficult to list all possible threats, making it harder to protect applications. Whitelisting helps security professionals by taking a different approach: It allows only the “known good,” thereby securing critical applications from ransomware, fileless malware, zero-day attacks, and other modern-day threats.
The effectiveness of any whitelisting attribute depends on how well it can prevent malware from exploiting files and applications running on your servers. Though all six attributes mentioned above have distinct advantages, using process whitelisting drives security to the kernel level to provide complete control of servers and endpoints that host applications. It aligns with the principles of zero trust, which in the case of applications means that only known and trusted processes should be allowed to execute.
The whitelisting types can be classified according to increasing levels of security as follows:
|Security Level||Description||Whitelisting Type|
|Good||File attribute-based whitelisting||File Path, File Name, File Size|
|Better||Unique identity-based whitelisting||Cryptographic Hash, Digital Signature|
|Zero Trust||Context-based, kernel-level whitelisting||Process|
While it is good to have file attribute-based and unique identity-based whitelisting in your security infrastructure, having context-based, kernel-level whitelisting provides security at the kernel level to provide complete control of servers and endpoints. ColorTokens Xprotectworksat the processlevel to detect, alert, and prevent unauthorized processes from running on your critical servers. It provides instant visibility into all running processes and files on your servers, as well as powerful whitelisting capabilities and context-based “allow” or “disallow” to prevent any malicious process from executing. Here’s how Xprotect can help your organization defend against cyber threats.