PR.PS-05 says installation and execution of unauthorized software are prevented. The aim is to shut the easiest door for malware and risky tools: someone, or something, installing code you never approved. That includes the packages your developers pull into builds.
CSF is voluntary guidance. There is no CSF certification.
What good looks like
Endpoints and servers install only approved software. Where the risk justifies it, execution is limited to permitted products. New software is checked for source and integrity before it goes in. Devices use approved DNS that blocks known malicious domains.
How to implement it
- Publish an approved software list and a simple request path for additions.
- Remove local admin rights from ordinary users, and use device management to restrict installs.
- Use application allowlisting on servers and high risk endpoints first. Expand when it proves manageable.
- Verify downloads: use official repositories, check signatures or hashes, and pin versions.
- For code dependencies, use a private registry or proxy and scan new packages before they enter builds. A free in browser dependency scan at https://gold.safeguard.sh/scan shows what a manifest pulls in and which versions carry known issues.
- Configure managed devices to use a filtering DNS service.
- Review alerts for blocked installs and tune the list.
A worked example
A developer needs a convenient file converter and installs a free desktop tool from a search result. It bundles an unwanted component that collects browser data. Under an approved software model, the install would have been blocked by the device policy, and the developer would have filed a request. The security owner would check the publisher and license, and either add an approved alternative or decline.
The same logic applies to code. A build pulls a newly published package with a name close to a popular library. With a private proxy and an allowlist of approved sources, the build fails and someone reviews it before anything runs.
Controls in order of effort
Start with the cheap ones: remove local administrator rights, use the operating system's built in application control features, and point devices to a filtering DNS service. Next, add device management rules that allow installs from approved catalogs. Then, for servers and sensitive endpoints, add allowlisting that permits only listed programs to run. Throughout, make requests easy. If getting a tool approved takes two weeks, people will work around you.
Software supply chain angle
Unauthorized software also arrives as dependencies. Pin versions, use lock files, and review new dependencies like any other new tool. Scanning a manifest before merge shows what a change adds and whether any version carries a known vulnerability.
Handling exceptions and unusual teams
Developers, data teams, and designers often need tools that do not fit a locked catalog. Offer a documented path: a sandboxed machine or virtual machine for experiments, with no access to production credentials, and a review step before a tool moves to a normal device.
Evidence to collect
- Approved software list and request records.
- Device management policy exports showing install restrictions.
- Allowlisting configuration for covered systems.
- DNS filtering settings.
- Samples of blocked install events.
Common gaps
Everyone has local admin. Shadow tools adopted by teams without review. Unpinned dependencies fetched straight from the internet in builds. No source check on downloaded installers.
Quick check
Do we need allowlisting on every device?
Not necessarily. NIST says when risk warrants it. Start with servers and sensitive endpoints, and rely on install controls elsewhere.
Sources
- NIST Cybersecurity Framework 2.0 (NIST CSWP 29), PR.PS-05 and its implementation examples.
