NIST SP 800-167 日本語訳

Adam Sedgewick Murugiah Souppaya Karen Scarfone

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-167

Adam Sedgewick

Information Technology Laboratory

Murugiah Souppaya
Computer Security Division

Information Technology Laboratory

Karen Scarfone
Scarfone Cybersecurity
Clifton, VA

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-167

October 2015

U.S. Department of Commerce Penny Pritzker, Secretary

National Institute of Standards and Technology

Willie May, Under Secretary of Commerce for Standards and Technology and Director

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3541 et seq., Public Law 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-167 Natl. Inst. Stand. Technol. Spec. Publ. 800-167, 24 pages (October 2015) CODEN: NSPUE2

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-167

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST. Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. All NIST Computer Security Division publications, other than the ones noted above, are available at http://csrc.nist.gov/publications.

Comments on this publication may be submitted to: National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

An application whitelist is a list of applications and application components that are authorized for use in an organization. Application whitelisting technologies use whitelists to control which applications are permitted to execute on a host. This helps to stop the execution of malware, unlicensed software, and other unauthorized software. This publication is intended to assist organizations in understanding the basics of application whitelisting. It also explains planning and implementation for whitelisting technologies throughout the security deployment lifecycle.

access control; application control; application whitelisting; information security; software security; whitelisting

The authors, Adam Sedgewick and Murugiah Souppaya of the National Institute of Standards and Technology (NIST) and Karen Scarfone of Scarfone Cybersecurity, wish to thank their colleagues, in particular Eric Chudow from the National Security Agency, who contributed to this publication, as well as the reviewers who provided feedback.

All registered trademarks belong to their respective organizations.

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 apply application whitelists—to control which applications are permitted to install or execute on a host—are called whitelisting programs, application control programs, or application whitelisting technologies. Application whitelisting technologies are intended to stop the execution of malware and other unauthorized software. Unlike security technologies such as antivirus software, which block known bad activity and permit all other, application whitelisting technologies are designed to permit known good activity and block all other. The purpose of this publication is to assist organizations in understanding the basics of application whitelisting and planning for its implementation.

Implementing the following recommendations should facilitate more efficient and effective application whitelisting use for federal departments and agencies.

Consider using application whitelisting technologies already built into the host operating system.

Organizations should consider these technologies, particularly for centrally managed desktops, laptops, and servers, because of the relative ease in managing these solutions and the minimal additional cost. If built-in application whitelisting capabilities are not available or are determined to be unsuitable, then the alternative is to examine third-party solutions with robust centralized management capabilities.

Use products that support more sophisticated application whitelisting attributes.

Choosing attributes is largely a matter of achieving the right balance of security, maintainability, and usability. Simpler attributes such as file path, filename, and file size should not be used by themselves unless there are strict access controls in place to tightly restrict file activity, and even then there are often significant benefits to pairing them with other attributes. A combination of digital signature/publisher and cryptographic hash techniques generally provides the most accurate and comprehensive application whitelisting capability, but usability and maintainability requirements can put significant burdens on the organization.

Test prospective application whitelisting technology in monitoring mode.

It is highly recommended to test any prospective application whitelisting technology in a monitoring mode to see how it behaves before solution deployment. This testing should include a thorough evaluation of how the solution reacts to changes in software, such as installing an update. An application whitelisting technology might be considered unsuitable if, for instance, it had to be disabled in order to install security updates for the operating system or particular applications.

Address application whitelisting technology planning and deployment in a phased approach.

A successful deployment will require a clear, step-by-step planning and implementation process. The use of a phased approach for deployment can minimize unforeseen issues and identify potential pitfalls early in the process. This model also allows for incorporating advances in new technology and adapting the technology to the ever-changing enterprise. In addition to following the security recommendations presented in this publication, organizations implementing application whitelisting technologies should also follow the recommendations from NIST Special Publication (SP) 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations, which defines minimum recommended management, operational, and technical controls for information systems based on impact categories.

When evaluating the possibility of deploying application whitelisting, analyze the environment or environments in which the application whitelisting will be running.

It is more practical to implement whitelisting on hosts that are centrally managed and have a consistent application workload. Application whitelisting solutions are generally strongly recommended for hosts in high-risk environments where security outweighs unrestricted functionality. Suitability for typical managed environments depends on how tightly the hosts are managed and the extent of the risks that they face. Organizations considering application whitelisting deployment in a typical managed environment should perform a risk assessment to determine whether the security benefits provided by application whitelisting outweigh its possible negative impact on operations. Organizations should also be mindful that they will need dedicated staff managing and maintaining the application whitelisting solution depending on the scale and specifics of the solution implemented, similar to handling an enterprise antivirus or intrusion detection solution. An organization that can dedicate the necessary trained staff to solution maintenance and has built-in application whitelisting technology should generally implement application whitelisting at least in a monitoring mode.

The purpose of this publication is to assist organizations in understanding the basics of application whitelisting (also known as application control). All other forms of whitelisting, such as email, network traffic, and mobile code whitelisting, are out of the scope of this publication.

This document is intended for security managers, engineers, administrators, and others who are responsible for acquiring, testing, implementing, and maintaining application whitelisting technologies.

The remainder of this document is organized into the following sections and appendices:

▪ Section 2 examines the basics of application whitelisting.

▪ Section 3 explains planning and implementation for application whitelisting technologies throughout the security deployment lifecycle.

▪ Appendix A provides a mapping to existing standards and guidelines that support using application whitelisting technologies.

▪ Appendix B discusses considerations involved in applying application whitelisting technologies to mobile platforms.

▪ Appendix C defines selected acronyms and abbreviations used in the document.

▪ Appendix D provides a bibliography for the publication.

A whitelist is a list of discrete entities, such as hosts, email addresses, network port numbers, runtime processes, or applications that are authorized to be present or active on a system according to a well-defined baseline. A blacklist is a list of discrete entities that have been previously determined to be associated with malicious activity. A graylist is a list of discrete entities that have not yet been established as benign or malicious; more information is needed to move graylist items onto a whitelist or a blacklist. Whitelists, blacklists, and graylists are primarily used as a form of access control: permitting activity corresponding to the whitelist and not permitting activity corresponding to the blacklist. Graylist treatment depends on the type of entities it contains. An example of how a graylist might be handled is prompting the user to make a decision or notifying an administrator that the entity needs to have its security evaluated before use.

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. Application whitelisting technologies are intended to stop the execution of malware and other unauthorized software. Unlike security technologies such as antivirus software, which use blacklists to block known bad activity and permit all other, application whitelisting technologies are designed to permit known good activity and block all other.

This section examines the basics of application whitelisting. It first discusses the categories of threats that application whitelisting can mitigate and the types of application whitelisting. Next, it defines the types of operational runtime modes available for application whitelisting technologies. The section also explains the motivations for application whitelisting and discusses uses of application whitelisting technologies other than application access control. Finally, the section concludes by examining differences in deployment based on operational environment, as well as considerations for evaluating the relative effectiveness of application whitelisting solutions.

As previously discussed, application whitelisting software prevents installation and/or execution of any application that is not specifically authorized for use on a particular host. This mitigates multiple categories of threats, including malware and other unauthorized software.

Malware, also known as malicious code, refers to an application that is covertly inserted into another piece of software (e.g., operating system, application) with the intent to steal or destroy data, run destructive or intrusive programs, or otherwise compromise the confidentiality, integrity, or availability of the victim’s data, applications, or operating system.¹ Many of today’s threats are malware-based, attempting to infect hosts (install their malicious code) and execute on those hosts to steal their data or perform other harmful activities. When properly configured, application whitelisting technologies can stop most malware from being executed (and often from being installed in the first place). Application whitelisting technologies can be significantly more effective at stopping unknown malware threats than conventional antivirus software and other traditional antimalware security controls. This is important because today’s malware threats are increasingly customized and targeted, making traditional detection technologies largely ineffective.

The other major category of threats that application whitelisting technology can mitigate is other unauthorized software (unauthorized software besides malware). This software can pose multiple problems. For example, it can introduce unmanaged vulnerable software into the environment, which can then be used by attackers to exploit hosts and further compromise them. There can also be legal issues with the installation of unauthorized software, such as violations of licensing agreements.

Application whitelisting is most readily used to stop threats on managed hosts where users are not able to install or run applications without authorization. An example is a kiosk workstation where users are limited to running a web browser; installation and execution of all applications other than the selected web browser and authorized application-based security controls (such as antivirus software) would be prohibited. Another example is a laptop that has all authorized applications preinstalled for the user, and the user does not have the administrative privileges necessary to install additional applications or disable the application whitelisting software. Application whitelisting may also be beneficial on servers, particularly if there is concern about malware spreading to these servers from other hosts (e.g., administrator laptops).

This section discusses the types of application whitelisting. This includes the application file and folder attributes that can be analyzed; the types of application resources handled, such as executables, libraries, and scripts; and techniques for whitelist generation.

Application whitelisting can be based on a variety of application file and folder attributes, including the following:²

▪ File path. This is the most general attribute: 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. However, if the path is protected by strict access controls that only allow authorized administrators to add or modify files, this becomes a stronger attribute. Paths can be beneficial by not requiring each file within the path to be listed separately, which reduces the need to update the whitelist for every new application and patch.

▪ Filename. This attribute, for the name of an application file, is too general to be used on its own. 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. Also, an attacker could simply place a malicious file onto a host and use the same name as a common benign file. Because of these weaknesses, this attribute should not be used on its own; rather, it should be paired with other attributes. For example, it would be stronger to combine path and filename attributes with strict access controls or to combine a filename attribute with a digital signature attribute (described below).

▪ File size. This attribute is typically used only in combination with other attributes, such as filename. Monitoring the file size assumes that a malicious version of an application would have a different file size than the original; however, attackers can craft malicious files to have the same length as their benign counterparts. Other attributes, such as digital signature and cryptographic hash, provide substantially better unique identification of files than file size does, and should be used instead of file size whenever feasible.

▪ Digital signature or publisher. Application files are increasingly being digitally signed by their publishers. A digital signature provides a reliable, 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 are not yet signed by their publishers, so using only publisher-provided digital signatures as attributes is generally not feasible. Some application whitelists can be based on verifying the publisher’s identity instead of verifying individual digital signatures; this is based on the assumption that all applications from trusted publishers can themselves be trusted.³ This assumption may be faulty if the software vendor has multiple applications and the organization wants to restrict which of those applications can be executed. Also, relying on the publisher’s verified identity only would allow older software versions with known vulnerabilities to be executed. However, the benefit of basing a whitelist on publisher identities is that the whitelist only needs updates when there is a new publisher (i.e., software vendor) or when a publisher updates its signature key.⁴

▪ Cryptographic hash. A cryptographic hash provides a reliable, unique value for an application file, so long as the cryptography being used is strong and the hash is already known to be associated with a good file. Cryptographic 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; the patched version will have a different hash. In these cases the patch should be identified as legitimate through its digital signature, then its cryptographic hash should be added to the whitelist. Note that if the whitelist is not continuously updated with new hashes for new and updated applications, there is a significant risk of software not functioning correctly, and if the whitelist is not continuously updated to remove existing hashes for older software versions with known vulnerabilities, there is a significant risk of vulnerable software being allowed to run.

As the discussions above indicate, choosing attributes is largely a matter of achieving the right balance of security, maintainability, and usability. Simpler attributes such as file path, filename, and file size should not be used by themselves unless there are strict access controls in place to tightly restrict file activity, and even then there are often significant benefits to pairing them with other attributes. A combination of digital signature/publisher and cryptographic hash techniques generally provides the most accurate and comprehensive application whitelisting capability, but usability and maintainability requirements can put significant burdens on the organization.

Application whitelisting is most often associated with monitoring executables. However, most application whitelisting technologies also have the ability to monitor at least some other types of application-related files, such as libraries, scripts, macros, browser plug-ins (or add-ons or extensions), configuration files, and application-related registry entries (on Windows hosts). The granularity of this monitoring varies significantly among application whitelisting technologies; for example, some can only permit or block whole classes of scripts (e.g., JavaScript)⁵, while others can permit or block individual scripts within a class of scripts.

There are two primary methods of generating an application whitelist for a host. One is to use vendor-provided information on the characteristics of known good applications, supplemented with organization-generated information on the characteristics of organization-specific applications (i.e., in-house custom applications). The other method of generating an application whitelist is to scan the files on a clean host⁶ to build a good known baseline.⁷

Both of these methods are effective on their own, except when applications are updated (e.g., patched) or new applications are installed. If the vendor is providing the whitelist information, the vendor will have to acquire the patch or new application, record its files’ characteristics, and send the corresponding information to customers. If the organization is building its own whitelist information, it will have to: acquire each patch or new application, record its files’ characteristics, and update its whitelists with the new information; or, redo its known good baseline to serve as the new reference baseline. Any of these methods may cause problematic delays for organizations that apply patches quickly, especially automatically; patched software may be seen as unknown software and prohibited from running. Certain attributes, such as file path and publisher, generally do not change with each patch and so whitelists utilizing those attributes do not need to be updated as often and should cause fewer of these delays.

To avoid these problems with updates, most application whitelisting technologies offer maintenance options. For example, many technologies allow the administrator to select certain services (e.g., patch management software) to be trusted updaters. This means that any files that they add to or modify on a host are automatically added to the whitelist. Similar options are available for designating trusted publishers (i.e., software vendors), users (e.g., system administrators), sources (e.g., trusted network paths), and other trusted entities that may update whitelists.

Another option available with some application whitelisting technologies is the use of reputation services. These services determine if a service, publisher, or other external entity is generally associated with benign or malicious content. This allows application whitelisting software to make decisions about how to handle new or modified files based on the reputation of the associated service, publisher, etc., instead of simply adding them to a graylist for subsequent manual processing.

Most application whitelisting technologies offer two operational runtime modes:

▪ Audit mode allows items, including those not on the whitelist to be executed and logs their execution. This mode provides data for continuous monitoring processes to analyze.

▪ Enforcement mode automatically permits execution of whitelisted items and/or blocks execution of blacklisted items. There are different forms of enforcement mode, which are differentiated by how they handle items that are not whitelisted or blacklisted. These forms include the following:

○ Whitelist enforcement permits only whitelist items to be executed and blocks execution of all others;
○ User prompting asks the user (or, in some cases, the administrator) to accept or reject each attempt to execute a file that is not whitelisted or blacklisted; and
○ Blacklist enforcement blocks execution of blacklisted items but allows everything else to be executed.

An application whitelisting technology run in audit mode is strictly informative; it can log the execution of malware and other unauthorized executables, but it cannot do anything to stop them. Audit mode is primarily intended for use when first deploying an application whitelisting technology, to help an organization evaluate and fine-tune the technology before switching it to enforcement mode.

Many application whitelisting technologies have granular options for setting modes. Some features could be configured to run in enforcement mode while other features run in audit mode. For example, Windows registry changes might be permitted (audit mode) while operating system file changes would be prohibited (enforcement mode). Some products also support multiple enforcement modes and allow granular setting of those for different types of monitored entities.

As stated in the Section 2 introduction, the primary purpose of application whitelisting technologies is to provide application access control, i.e., to stop the execution of unauthorized software. However, most application whitelisting technologies can be used for other purposes as well, including the following:

▪ Software inventory. Application whitelisting technologies can keep an inventory of the applications and application versions installed on each host. This allows an organization to identify unauthorized applications—unlicensed applications, prohibited applications, etc.—as well as to identify “wrong” versions of software (both too old and too new). This software inventory capability is also useful for forensic investigations, such as finding modified applications, unauthorized applications, malware, unknown applications, etc. on a given host.

▪ 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, while other technologies cannot prevent changes but can immediately report when changes occur.

▪ Incident response. An organization responding to an incident on a host could capture the characteristics of the malicious files on that host (e.g., generate cryptographic file hashes) and use application whitelisting technologies to check other hosts for the same files, indicating that they have been compromised as well.

Some application whitelisting technologies may have additional capabilities, including the following:

▪ Access control for portable storage devices, such as restricting file reads, writes, and executes for all files on removable media; only permitting the use of encrypted devices; and only permitting the use of drives with particular serial numbers.

▪ Memory protection, primarily involving stopping certain attacks (e.g., buffer overflows) that directly affect files in memory, not files in storage. Most application whitelisting technologies only focus on the files in storage, but do not ensure that the files in memory are not altered or exploited.

▪ Software reputation services, such as reviewing what other software a particular application is often bundled with, and determining if an application is known to pose a substantial security risk.

▪ Anti-malware technology integration; for example, attempting to identify known malicious content by running graylisted files through an online scanner with many antivirus scanning engines or other types of malware analysis products. Malware analysis products can inform application whitelisting decision making processes.

As discussed in NIST SP 800-70 Revision 2, National Checklist Program for IT Products—Guidelines for Checklist Users and Developers,⁸ there are significant differences among operational environments. These differences are important in terms of selecting and deploying application whitelisting technologies. The major categories of operational environments are as follows:

▪ Standalone. Also referred to as Small Office/Home Office (SOHO), a Standalone environment refers to a small, informal computer installation that is used for home or business purposes. For technical and business (economic) reasons, Standalone environment hosts are generally not managed remotely. Standalone environments are typically the least secured.

▪ Managed. The Managed environment, also called an Enterprise environment, typically contains large organizational systems with defined suites of hardware and software configurations, usually consisting of centrally managed IT products (e.g., workstations and servers). The managed nature of these environments gives administrators centralized control over various settings on IT products. Because of the supported and largely homogeneous nature of the Managed environment, it is typically easier to use more functionally restrictive settings in Managed environments than in Standalone environments.

▪ Specialized Security-Limited Functionality (Custom). A Custom environment contains systems in which the functionality and degree of security do not fit the Standalone or Managed environments. Specialized Security-Limited Functionality (SSLF) is a Custom environment that is highly restrictive and secure; it is usually reserved for hosts that have the highest threats and associated impacts. Because hosts in an SSLF environment are at high risk of attack or data exposure, security takes high precedence over functionality.

The first step in evaluating the possibility of deploying an application whitelisting solution should be an analysis of the environment or environments in which the hosts will be running. Generally it is not feasible to implement whitelisting on Standalone environment hosts because of the lack of centralized management. Application whitelisting solutions are generally strongly recommended for hosts in SSLF environments because of the high risks that they face. Suitability for Managed environments depends on how tightly the hosts are managed and the extent of the risks that they face; organizations considering application whitelisting deployment in a Managed environment should perform a risk assessment to determine whether the security benefits provided by application whitelisting outweigh its possible negative impact on operations. Organizations should also be mindful that they will need dedicated staff managing and maintaining the application whitelisting solution, similar to handling an enterprise antivirus or intrusion detection solution.

Once it has been determined that application whitelisting technologies are merited for a particular environment, the next step is to consider which technologies might be feasible. Organizations should consider application whitelisting technologies already built into the operating system, particularly for centrally managed hosts (e.g., desktops, laptops, servers), because of the relative ease and minimal additional cost in managing these solutions. If built-in application whitelisting capabilities are not available or are determined to be unsuitable, then the alternative is to examine third-party solutions with robust centralized management capabilities. An organization that can dedicate the necessary trained staff to solution maintenance and has built-in application whitelisting technology should generally implement application whitelisting at least in a monitoring mode.

It is highly recommended to test any prospective application whitelisting technology in a monitoring mode to see how it behaves before solution deployment. This testing should include a thorough evaluation of how the solution reacts to changes in software, such as installing an update. An application whitelisting technology might be considered unsuitable if, for instance, it had to be disabled in order to install security updates for the operating system or particular applications.

This section describes additional considerations that organizations should examine when evaluating the likely effectiveness of potential application whitelisting technology solutions.

This section discusses considerations for planning and implementing application whitelisting technologies for end user devices. As with any new technology deployment, application whitelisting technology planning and implementation should be addressed in a phased approach. A successful deployment can be achieved by following a clear, step-by-step planning and implementation process. The use of a phased approach for deployment can minimize unforeseen issues and identify potential pitfalls early in the process. This model also allows for incorporating advances in new technology and adapting the technology to the ever-changing enterprise. The following is an example of planning and implementation phases:

This document does not describe the planning and implementation process in depth because the same basic steps are performed for any security technology. This section only highlights those considerations that are of particular interest for application whitelisting technologies.⁹ These considerations are not intended to be comprehensive, nor is there any implication that particular security elements not listed here are unimportant or unnecessary. In addition to following the security recommendations presented in this publication, organizations implementing application whitelisting technologies should also follow the recommendations from NIST Special Publication (SP) 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations¹⁰, which defines minimum recommended management, operational, and technical controls for information systems based on impact categories.

The purpose of this phase is to identify the current and future needs for application whitelisting and to determine how those needs can best be met. Requirements specific to application whitelisting that should be considered include the following:

The outcome of the organization’s requirements analysis should be a determination of the types of applications or application components (executables, libraries, registry entries, configuration files, etc.) that need to be monitored; the types of threats the application whitelisting should protect against (Section 2.1); and the types of application whitelisting that should be used to balance security, usability, and maintainability (Section 2.2). For example, the organization may decide to block execution of all unauthorized application components on higher-risk client systems, while monitoring (but not blocking) execution of unauthorized application components on lower-risk client systems. These decisions should be captured in policy.

Another outcome of the analysis is the documentation of the requirements for the application whitelisting technologies themselves, including security capabilities (e.g., authentication, cryptography, key management), performance requirements, management requirements (including reliability, interoperability, and scalability), the security of the technology itself, usability, and maintenance requirements (e.g., applying updates).

In many cases, a single application whitelisting product cannot meet all of the organization’s identified needs. For example, the organization may need to monitor applications on devices running several different OSs, yet no appropriate product can work on all those platforms. Also, some operating systems may have application whitelisting technologies built-in. Organizations can solve this problem in several ways, such as acquiring multiple products or replacing older devices. Organizations should ensure that effective solutions are identified for all the types of end user devices that need their applications monitored, if possible, and that a waiver and risk management process is created for unusual cases that cannot be addressed by the identified solutions.

Examples of challenging platforms for application whitelisting include mobile devices¹¹ and industrial control systems (ICS)¹². One of the main benefits of using mobile devices is being able to acquire a wide variety of applications easily, quickly, and cheaply (often free). Unfortunately, this philosophy makes it infeasible in many cases to implement whitelisting for mobile devices. If mobile devices are tightly managed, much like some desktops or laptops, and only allowed to acquire approved apps from an enterprise-sponsored app store, then whitelisting may be practical, but for user-controlled unmanaged mobile devices, whitelisting may not be an option as of this writing.

An ICS is a challenging platform for whitelisting in part because, unlike most other computing devices, ICSs strongly favor availability over confidentiality. It is critical that ICSs continue to function properly no matter what is happening to them, including cyber attacks. Because application whitelisting can inadvertently prevent benign applications from being executed, its use for ICSs must be carefully analyzed and tested for feasibility. Another problem with ICSs is that they often use atypical platforms, which may not be supported by any acceptable application whitelisting solutions. However, since ICSs are used for specific functionality and run only certain ICS software, in some cases they are actually easier to whitelist than more dynamic, heterogeneous environments.

Once the needs have been identified and the appropriate application whitelisting technologies have been chosen, the next phase is to design a solution that meets those needs. If these design decisions are incorrect, then the application whitelisting implementation will be more susceptible to compromise and failure. Major aspects of solution design that are particularly important for application whitelisting are as follows:

▪ Cryptography. Cryptography is used in at least three ways for application whitelisting technologies: 1) to generate and verify cryptographic hashes for files and other application components; 2) to validate digital signatures for files; and 3) to protect the confidentiality and integrity of communications between individual hosts and centralized management (for example, encrypting lists of installed applications and application versions). For all of these functions, Federal agencies must use Federal Information Processing Standard (FIPS) approved or NIST-recommended algorithms contained in validated cryptographic modules.¹³ Organizations should consider how easily the solution can be updated when stronger algorithms and key sizes become available in the future.

▪ Solution architecture. The architecture of the application whitelisting technology refers to the selection of devices and software to provide application whitelisting services and the placement of centralized elements within the existing network infrastructure, such as management servers. Most application whitelisting technologies can only operate as a centrally managed solution; there may be copies of whitelists on individual hosts, but enterprise management is centralized. Each end user device must have software that provides application whitelisting enforcement or auditing. Designing the architecture includes component placement, redundancy, reliability, and interoperability.

▪ Whitelist management. As discussed in Section 2.2.3, whitelist management can involve the establishment of trusted publishers, users, updaters, etc. Organizations should choose these trusted entities carefully because a compromise in a trusted entity could lead to the compromise of the application whitelisting technology, and consequently to the hosts it protects. However, failure to identify necessary entities as trusted will likely lead to operational problems, such as when files updated by patch installation are not automatically trusted by the application whitelisting technology.

After the solution has been designed, the next step is to implement and test a prototype of the design. Ideally, implementation and testing should first be performed on lab or test devices. Only solutions in the final phase of testing should be implemented on production devices. Aspects of the prototype solution that require evaluation include the following:

▪ Application control functionality. Basic functionality will need to be checked during the prototype testing. Examples include allowing the execution of whitelisted applications, blocking the execution of blacklisted applications, and detecting modifications to whitelisted applications. These functions should be verified by: installing patches and other updates; manually modifying executables; and making other changes to applications to confirm that the application control policies can be properly enforced and cannot be easily circumvented.

▪ Management. Administrators should be able to configure and manage all components of the solution effectively and securely. It is particularly important to evaluate the ease of deployment and configuration, including how easily the solution can be managed as the solution is scaled to larger deployments. Management concerns should include the effects of patching/upgrading the application whitelisting software, changing software settings (e.g., changing cryptographic algorithms or key sizes), and managing cryptographic keys. Another important management concern that needs special attention is whitelist generation and maintenance, such as how the whitelists accommodate software patching.

▪ Logging/alerting. The logging, alerting, and data management functions should work properly in accordance with the organization’s policies and strategies.

▪ Performance. The solution should be able to provide adequate performance during normal and peak usage. Testing should incorporate a variety of devices, OSs, and applications.

▪ Security of the implementation. The application whitelisting technology itself may contain vulnerabilities and weaknesses that attackers could exploit. Organizations with high security needs may want to perform extensive vulnerability assessments against the application whitelisting components.¹⁴

Before installing application whitelisting software on a host, organizations should scan the host for malware and either remove any malware that is detected or rebuild the host. The scan will ensure that malware files are not included in the whitelist generation process. Organizations should also ensure that the host’s OS is secured properly, including that it is fully patched and that other necessary security controls are installed and configured properly. If the OS is not secured properly, the host is more likely to be compromised, which could weaken the protection provided by the application whitelisting technology.

Once testing is complete and any issues have been resolved, the next phase of the planning and implementation model involves deploying the solution. When the components are being deployed into production, organizations should initially use application whitelisting on a small number of hosts. Deploying it to many hosts at once might overwhelm the management servers or identify other bottlenecks through loss of availability. Many of the problems that occur are likely to occur on multiple hosts, so it is helpful to identify such problems either during the testing process or when deploying the first hosts, so that those problems can be addressed before widespread deployment. A phased deployment provides administrators an opportunity to evaluate the impact of the solution and resolve issues prior to enterprise-wide deployment. It also provides time for the IT staff (e.g., system administrators, help desk) and users to be trained and to become accustomed to the operational lifecycle of the implementation.

Most of the issues that can occur during deployment are the same types of issues that occur during any large IT deployment. In addition to potential problems described earlier in this publication, another typical issue is end users discovering and disabling the application whitelisting software. Many products run in a stealth mode so that users cannot readily tell that they are running.

The last phase of the planning and implementation model is the longest lasting. Managing the solution involves operating the deployed solution and maintaining the application whitelisting architecture, policies, software, and other solution components. Examples of typical actions include:

▪ Updating the whitelist to include new or updated applications;

▪ Testing and applying patches to the application whitelisting software;

▪ Deploying application whitelisting to additional platforms;

▪ Performing key management duties;

▪ Adapting policies as requirements change;

▪ Monitoring the components for operational and security issues;

▪ Periodically performing testing to ensure that application whitelisting is functioning properly; and

▪ Performing regular vulnerability assessments.

Organizations should pay particular attention to the ongoing whitelist updates. Although many, if not most, whitelist updates can be automated, administrators should be prepared to make manual updates quickly when needed, in order to identify emerging threats and correct false positives or negatives. Organizations should also monitor any graylists and transfer their entries to whitelists or blacklists, as appropriate.

This appendix provides a mapping to selected standards and guidelines that support using application whitelisting technologies.

▪ Control CM-7 (Least Functionality), control enhancement 5 (Authorized Software/Whitelisting): “The organization:

(a) Identifies [Assignment: organization-defined software programs authorized to execute on the information system];

(b) Employs a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the information system; and

(c) Reviews and updates the list of authorized software programs [Assignment: organization-defined frequency].”

▪ Subcategory PR.IP-1:17 “A baseline configuration of information technology/industrial control systems is created and maintained.” This refers to determining which applications are authorized to be run on each system.

▪ Subcategory PR.PT-3:18 “Access to systems and assets is controlled, incorporating the principle of least functionality.” This refers to the enforcement of the whitelist established through subcategory PR.IP-1.

▪ Critical Control 2: Inventory of Authorized and Unauthorized Software: “Actively manage (inventory, track, and correct) all software on the network so that only authorized software is installed and can execute, and that unauthorized and unmanaged software is found and prevented from installation or execution.”

This appendix discusses considerations involved in applying application whitelisting to mobile platforms (e.g., smartphones, tablets). Typical standalone application whitelisting technologies are generally not available for mobile devices as of this writing. Instead, application whitelisting is achieved through one of two methods: mobile device management (MDM)/mobile application management (MAM) or an enterprise app store.

MDM²⁰ and MAM technologies are suites of security controls for protecting mobile devices from compromises. MDM and MAM technologies often have application whitelisting capabilities built in. Because MDM and MAM technologies are typically centrally managed, they offer a relatively easy way to deploy whitelisting capabilities to mobile devices. However, the disadvantage of relying on application whitelisting in this environment is that mobile applications are constantly changing and new applications are released all the time; it may be prohibitively difficult to maintain application whitelisting solutions with that much flux to be addressed.

An alternative to a client-based application whitelisting technology is an enterprise app store²¹. Many organizations, especially those with MDM deployed to their mobile devices, control the app stores from which their users may download and install apps. This effectively provides a form of application whitelisting, because only those applications that have been approved by the organization for inclusion in the app store may be accessed by the organization’s users. There is some maintenance overhead associated with relying on an app store for whitelisting, but it is centralized (approving an app once and posting it to the app store) instead of distributed (configuring thousands of managed mobile devices to recognize the latest apps and app updates).

Selected acronyms and abbreviations used in the guide are defined below.

The following publications were used when writing this guide.

▪ Council on CyberSecurity, The Critical Controls for Effective Cyber Defense, Version 5.1, [October 7, 2014], http://www.counciloncybersecurity.org/critical-controls/reports/ [accessed 8/28/2015].

▪ National Security Agency, Application Whitelisting Using Software Restriction Policies, Version 1.1, August 2010, http://www.nsa.gov/ia/_files/os/win2k/application_whitelisting_using_srp.pdf [accessed 8/28/2015].

▪ National Security Agency, MIT-006FS-2013, Application Whitelisting [from Top 10 Information Assurance Mitigation Strategies], [October 25, 2013], http://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/SlickSheet_ApplicationWhitelisting_Standard.pdf [accessed 8/28/2015].

▪ NIST, Framework for Improving Critical Infrastructure Cybersecurity, Version 1.0, February 12, 2014, http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf [accessed 8/28/2015].

▪ NIST, Special Publication (SP) 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations, April 2013 (updated 1/22/2015), http://dx.doi.org/10.6028/NIST.SP.800-53r4 [accessed 8/28/2015].

▪ NIST, Special Publication (SP) 800-70 Revision 2, National Checklist Program for IT Products— Guidelines for Checklist Users and Developers, February 2011, http://csrc.nist.gov/publications/nistpubs/800-70-rev2/SP800-70-rev2.pdf [accessed 8/28/2015].