Requirement text: RM.5.152: Utilize an exception process for non-whitelisted software that includes
mitigation techniques.
DISCUSSION FROM SOURCE: CMMC
Whitelist technologies allow an organization to lock-down their environment in such a way
that only allowed software will be able to run on end point and server systems. If a program
is not listed on the whitelist, then it is not authorized to run on a given system.
While this may help keep organizations secure, it is not realistic to expect a stringent
whitelist will meet all of the software needs. Most organizations of any size will need to
create a process for expanding the whitelist quickly, or create an exception process that will
allow individuals to get permission to run software that is needed for their job, but the
organization does not want to globally accept that software running on all endpoints.
While whitelist technologies provide a method for organizations to choose which software
packages can run in the overall enterprise, they require an organization to understand that
some of the users will require software outside of the whitelist (non-whitelist) to be
approved for use. A mature organization should have a procedure in place for determining
what software is placed on the whitelist for the organization. At the same time, the
organization should have a procedure for determining how software may run through an
exception process. The exception process will determine what software needs to be
authorized that is not within the whitelist. Part of this exception process may be a mitigation
strategy, such as placing a given machine in a quarantine zone while it is using the software
that is not whitelisted. Carefully controlling what software is authorized (whitelist) is a huge
benefit to an organization, but this approach may require whitelist exceptions from time to
time based on project and user needs. Having a well-defined process and documenting all
steps for determining exceptions are key for demonstrating the maturity of the organization
when determining what is safe and not safe to run on the enterprise environment.
An organization also needs to understand that each additional software package authorized
to run on their environment adds a level of risk to the organization’s enterprise.
CMMC CLARIFICATION
This practice defines and implements an explicit risk reduction process in the recognition
that some software will be installed as an exception to the whitelist policy. Standard
software packages that an organization trusts can easily be whitelisted based on risk and
need for the organization. Once the whitelist is established, an organization needs to create
a process that will allow software to be inspected and considered for operational use, even
if only for a short period of time. If an operational need arises for a software package that
adds too high of risk for the organization, the organization will need to decide if they will
allow the software to run and under what circumstances. Mitigation strategies can be as
extensive as only running software on a standalone system, or placing the software in a
protected virtual machine with limited access to corporate assets. The list of acceptable
mitigation strategies should be determined by the organization’s cyber professional. When
a user requests the right to use software that is not whitelisted, the organization should use
their documented exception process to determine whether or not they are going to allow
non-standard software to be executed on endpoints. If the whitelist technology allows, an
organization could associate exception software to a given asset on the enterprise. Another
option could be placing the software inside a container and controlling what access it has on
a system and on the enterprise.
Example 1
Your organization signs all executable software that runs on your endpoint Windows boxes.
It is the signing cert that the whitelist software is looking for when accepting a software
package to run. This not only makes it easier for the organization to add software to the list,
but it is easier than adding software packages to the whitelist as the organization expands.
A mechanical engineer needs to use a new CAD (computer aided design) software package
that is not standard for the organization. The team does not want to sign it and make it
standard across the enterprise. So, after analysis of the software, only the mechanical
engineer’s machine is authorized to run the software package. This allows the mechanical
engineer to use it for their job function, but it prevents blanket coverage across the
enterprise by refusing to sign the software to pass the corporate whitelist technology.
Example 2
Your medium size company has a whitelist technology installed on all end point systems.
Being a good steward of cyber security, your company has all allowed software listed in the
whitelist software. An HR representative needs to run a special software package to run
reports against timesheets for auditors. You run the software through your vetting process,
and don’t find any negative issues with it. You add the software to the whitelist of the HR
representative’s system only so they can perform the report capability for the auditors.
References
• CMMC