Security requirement
- a.Issue systems or system components with the following configurations to individuals traveling to high-risk locations: [Organization-defined: configurations].
- b.Apply the following security requirements to the systems or components when the individuals return from travel: [Organization-defined: security requirements].
Discussion
When it is known that a system or a system component will be in a high-risk area, additional security requirements may be needed to counter the increased threat. Organizations can implement protective measures on the systems or system components used by individuals departing on and returning from travel. Actions include determining whether the locations are of concern, defining the required configurations for the components, ensuring that the components are configured as intended before travel is initiated, and taking additional actions after travel is completed. For example, systems going into high-risk areas can be configured with sanitized hard drives, limited applications, and more stringent configuration settings. Actions applied to mobile devices upon return from travel include examining the device for signs of physical tampering and purging and reimaging the device storage.
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 System and Component Configuration for High-Risk Areas 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 (2)
- a.
systems or system components with the following configurations are issued to individuals traveling to high-risk locations: [Organization-defined: configurations].
- b.
the following security requirements are applied to the system or system components when the individuals return from travel: [Organization-defined: security requirements].
Examine
- configuration management policy and procedures
- configuration management plan
- procedures for the baseline configuration of the system
- procedures for system component installations and upgrades
- system component inventory
- system component installations or upgrades and associated records
- records of system baseline configuration reviews and updates
- system configuration settings
- system architecture
- change control records
- system security plan
- other relevant documents or records
Interview
- personnel with configuration management responsibilities
- personnel with information security responsibilities
- system administrators
Test
- processes for managing baseline configurations
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.