Review of the publication NIST SP 800-167 "Guide to Application Whitelisting"

Ruslan Rakhmetov, Security Vision

When building effective information security management processes, one of the main tasks is so-called ‘hardening’, i.e. secure customisation of operating systems and applications with the use of inbuilt security functions. Such an approach is justified, for example, when it is impossible to purchase superimposed information protection means in the presence of budgetary, legislative and other restrictions, as well as when it is undesirable to use additional software in critical systems. For example, when protecting significant CII objects in accordance with FSTEC Order No. 239, priority should be given to in-house protective functionality. When building a system of technical protective measures with in-house tools to minimise cyber risks, one of the important and effective methods is the creation of allow lists (English: allow list / white list). When this concept is fully applied, a secure software environment is created that functions according to the principle of ‘everything that is not explicitly permitted is prohibited’ (Default Deny). This principle cuts off a significant number of potential threats, leaving attackers with a rather narrow attack surface and forcing them to resort to advanced attack methods (e.g., using system utilities ‘Living-off-the-Land Binaries’ or buying/stealing a digital certificate to sign code), which in turn increases the cost of the attack and therefore reduces the attractiveness of the target for attackers. Below we will look at NIST SP 800-167, ‘Guide to Application Whitelisting’, which provides suggestions for creating permissive lists of executables, libraries, configuration files by applying technologies built into the OS and using a variety of evaluation criteria (digital signature, hash, file location) .

So, NIST publication SP 800-167 defines the following concepts:

1. Whitelist - A list of individual entities (e.g., hosts, IP addresses, email addresses, process and application names) that can be present or active on a system according to predefined rules;

2. Blacklist - A list of entities that have been previously identified as being associated with malicious activity and their activity on the system should be excluded;

3. Graylist - A list of entities whose validity has not yet been assessed and requires additional information or resources.

An application whitelist is a list of applications and their components (libraries, modules, configuration files) that can be present or active on the system according to predefined rules (‘baseline’). These restrictions are implemented by application control programs or application whitelisting technologies.

Application whitelisting technologies are designed to protect against malware, including samples that are not yet known to anti-virus labs. Unlike antiviruses, they operate more strictly, allowing only predetermined software to run and blocking everything else. This technology is also designed to protect the company's infrastructure from unauthorised installation by users of software that may contain critical vulnerabilities, is not supported by the vendor, and carries legal risks for the company in the absence of a licence - these risks, known as ‘Shadow IT’, can cause a lot of headaches for large companies with extensive structures. It should also be considered that supporting permission list technology in distributed heterogeneous infrastructures will also require additional overhead to administer and quickly update permissions based on user requests.

NIST publication SP 800-167 lists the following types of application permission lists:

1. file and directory attributes:

1.1. file path. A common but not the most reliable option, as malware with permission to write to directories in the ‘permission list’ will be able to be run. However, the use of this attribute may be justified when strict directory access control lists (ACLs) are used.

1.2 File name. It is also a rather unreliable option, which is recommended to use only in combination with other attributes such as file path or digital signature.

1.3 File size. Also an unreliable option that can only be used in combination with other attributes.

1.4. Digital signature or publisher. The use of digital code signing certificates (code signing certificates) allow a hash sum from a particular executable file or library to be signed using the private key of the publisher - the development company or organisation that authorised the execution of that file on its devices. An authorisation list by publisher name can eliminate the extra effort of verifying and signing each file individually, but will allow users to run any software created by that publisher, including software that is outdated or not recommended by the company. The only disadvantage of this type of attributes, in addition to the labour costs of administering the list of publishers, is the fact that to this day not all software developers sign their software with digital signatures - this is partly due to the need to purchase certificates from commercial certification centres.

1.5 The value of the hash sum. Quite a reliable attribution method, but one should take into account the labour costs of regularly updating the hash list when software updates are released and removing hashes of old software versions containing vulnerabilities from the ‘white list’.

2. Application resources. As a rule, application monitoring technologies based on permission lists also allow to monitor various additional attributes in addition to executable files - these can be libraries, scripts, macros, extensions (plug-ins), configuration files, values of application registry keys. The granularity of monitoring and blocking depends on the specific application control technology.

3. Permission list creation and maintenance. Permission list creation can be performed based on vendor data (vendor-provided list of characteristics/file hashes) or by calculating hashes on a device in known good condition (not connected to the LAN, immediately after installation of the OS and software distribution from a trusted source). Both methods can result in additional administration overhead and false positives for software updates and untimely inclusion of new version file attributes in the permission list.

As a solution, some technologies offer options to include all files that have been updated by a trusted service (e.g. Microsoft SCCM client) in the permission list, as well as options to use reputation analysis, whereby an unknown new file is not blocked by default, but its attributes (publisher, installer service) are checked against reputation analysis systems to get a verdict (benign/malicious).

The modes of operation of technologies for creating application permission lists, according to NIST SP 800-167, can be as follows:

1. Audit mode: run all applications without restriction and collect information about their attributes for further analysis;

2. Blocking mode:

2.1. Run only allowed applications with other software blocked;

2.2. User (administrator) enquiry when attempting to launch an application not from the ‘white’ / ‘black’ list;

2.3 Block applications only from the banned list and allow all other applications.

In addition to directly allowing or disallowing specific applications, application control technologies can provide the following capabilities:

1. software inventory: version control, publisher control, licence compliance and internal regulations on software usage;

2. File integrity monitoring: monitoring file integrity or preventing unauthorised modification of files;

3. Cyber incident response: collecting data about files on a compromised host, identifying similar suspicious files on other devices in the company network;

4. Additional options that include monitoring applications downloaded to memory, reputation analysis of unknown files, checking grey list files through online malware scanners (e.g. VirusTotal).

When implementing an application control solution, the authors of NIST SP 800-167 recommend following the following steps:

1. Identify the current and possible future needs and functionality of the application control solution, describe security and performance requirements, and develop appropriate internal regulations;

2. Development of the solution architecture, including management of permission and denial lists, selection of hashing and digital signature algorithms for files, as well as encryption algorithms for the communication channel between the client and the management server where policies and white/black lists are stored;

3. testing the prototype of the selected solution in a test environment on selected devices, including verification of the technology of allowing and denying applications, management of the solution settings, logging, performance, security of the solution itself (control of the absence of vulnerabilities, etc.);

4. Deployment of the solution sequentially on different groups of devices with identification and elimination of problems;

5. Further management of the solution, including updating the white/black lists of applications, deploying the solution on different platforms and device types, updating policies in accordance with changing organisational requirements, updating the solution itself, periodic testing of the security functionality and checking the solution for vulnerabilities.