Per-Asset Software Authorization
Each software entry is associated with one or more specific assets from the Asset Inventory and includes the application name, version, purpose, authorization status, and business justification for its inclusion. Authorization status is explicit. Authorized, Pending Review, or Unauthorized. So any software on an in-scope system that is not actively authorized is immediately visible as a gap rather than silently included.
The catalog is reviewed periodically and each review cycle is dated and preserved in the history. When software is added, removed, or version-updated, the change is logged in the Activity Log with timestamp and user. This creates the actively maintained record that assessors distinguish from a one-time inventory taken during initial compliance effort.
Deny-by-Exception Policy Foundation
CM.L2-3.4.8 requires a policy that either denies all software execution by default and permits exceptions (allow-listing), or actively identifies and blocks prohibited software (deny-listing). Both approaches require a documented authorized software list as their foundation. The Software Catalog provides that list. Per asset, versioned, and with the business justification that supports enforcement decisions.
For assessors examining this practice, the catalog is the evidence that the policy has substance: a specific list of what is permitted, on which systems, and why. A policy that states software restriction procedures without a backing catalog is a documented intention, not a demonstrated control.
What You See Inside
- *Software entries with application name, vendor, version, and asset association
- *Authorization status: Authorized, Pending Review, or Unauthorized. Per application per asset
- *Business justification field. Documents why each application is authorized and what operational function it serves
- *Review history. Dated review cycles with reviewer name demonstrating active catalog maintenance
- *Change log. Additions, removals, and version updates captured with timestamp and user via Activity Log
- *Unauthorized software flag. Any software on an in-scope asset without an Authorized status is surfaced as a gap
- *Asset Inventory integration. Software entries link to the hardware asset they run on, keeping hardware and software inventories connected
- *SSP integration. Software catalog referenced in the SSP's system description and configuration management section
Practices Satisfied
| Practice ID | Description |
|---|---|
| CM.L2-3.4.6 | Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. |
| CM.L2-3.4.7 | Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. |
| CM.L2-3.4.8 | Apply deny-by-exception (blacklisting) policy to prevent use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow execution of authorized software. |
What this replaces
- *A policy that says software restrictions are in place with no catalog to show what is and isn't authorized
- *A spreadsheet software inventory created once during the initial compliance effort and never updated since
- *Organization-wide software list with no per-asset association. Can't verify least functionality on a specific system
- *No review history. Catalog exists but no evidence it is actively maintained or periodically reviewed
- *Software catalog disconnected from the asset inventory. Two separate documents that can't be cross-referenced during assessment
Related Modules
Every module ships on the 1TEN appliance. No configuration required. Schedule 30 minutes and see it running with your organization's data.