Security requirement
- a.Identify software programs authorized to execute on the system.
- b.Implement a deny-all, allow-by-exception policy for the execution of authorized software programs on the system.
- c.Review and update the list of authorized software programs [Organization-defined: frequency].
Discussion
If provided with the necessary privileges, users can install software in organizational systems. To maintain control over the software installed, organizations identify permitted and prohibited actions regarding software installation. Permitted software installations include updates and security patches to existing software and downloading new applications from organization-approved “app stores.” The policies selected for governing user-installed software are organization-developed or provided by some external entity. Policy enforcement methods can include procedural methods and automated methods. Authorized software programs can be limited to specific versions or come from specific sources. To facilitate a comprehensive authorized software process and increase the strength of protection against attacks that bypass application-level authorized software, software programs may be decomposed into and monitored at different levels of detail. These levels include applications, application programming interfaces, application modules, scripts, system processes, system services, kernel functions, registries, drivers, and dynamic link libraries.
Tailoring decisions required
Resolve these values through the governing organization’s approved tailoring and risk-management process before declaring the requirement implemented.
Implementation perspective
Treat Authorized Software – Allow by Exception as a CUI protection outcome that must be reflected in the system boundary, documented implementation, operational behavior, and assessment evidence. Pay particular attention to approved baselines, secure configuration, change control, inventories, and drift management within the CUI boundary.
- Confirm the requirement is in scope for the CUI system components, services, users, and external connections being assessed.
- Resolve every organization-defined parameter through an approved governance and tailoring process.
- Map each clause of the requirement to an accountable owner, implementation mechanism, and evidence source.
- Verify that inherited and shared implementations are supported by current provider evidence and responsibility boundaries.
- Collect evidence during normal operation and review changes, exceptions, and deficiencies on a risk-based cadence.
Questions to ask
- Which CUI assets, data flows, users, and services are protected by this requirement?
- Which portions are implemented locally, inherited, shared, or not applicable, and what evidence supports that determination?
- Do the system security plan, deployed configuration, operating process, and assessment evidence tell the same story?
- What change, incident, or threshold should trigger reassessment?
Evidence and validation
- approved baseline configurations
- change tickets and approvals
- configuration scan and drift reports
- software and hardware inventories
Common failure patterns
- baselines documented but not enforced
- emergency changes never reconciled
- cloud or ephemeral assets missing from inventory
- security impact analysis performed after deployment
Assessment objectives and methods
Assessment objectives (3)
- a.
software programs authorized to execute on the system are identified.
- b.
a deny-all, allow-by-exception policy for the execution of authorized software programs on the system is implemented.
- c.
the list of authorized software programs is reviewed and updated [Organization-defined: frequency].
Examine
- configuration management policy and procedures
- procedures for least functionality in the system
- configuration management plan
- system design documentation
- system configuration settings
- list of software programs authorized to execute on the system
- system component inventory
- records associated with the review and update of the list of authorized software programs
- common secure configuration checklists
- change control records
- system audit records
- system security plan
- other relevant documents or records
Interview
- personnel with responsibilities for identifying software authorized to execute on the system
- personnel with information security responsibilities
- system administrators
Test
- processes for identifying, reviewing, and updating programs authorized to execute on the system
- processes for implementing authorized software policy
- mechanisms for supporting or implementing authorized software policy
Source NIST SP 800-53 controls
These controls are referenced by the official SP 800-171 Rev. 3 OSCAL record. Open the corresponding control pages for complete control text, enhancements, D3FEND mappings, and related learning.
Authoritative sources
- NIST SP 800-171 Revision 3 official publication ↗
- NIST SP 800-171A Revision 3 official publication ↗
- NIST OSCAL Content release used for this import ↗
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. The official publications, the responsible federal agency, and the governing contract or agreement determine applicability, tailoring, assessment depth, and required implementation.