Utilize an exception process for non-whitelisted software that includes mitigation techniques.
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.
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.