Prohibit remote activation of collaborative computing devices
📖 What This Means
This control requires organizations to disable the ability for collaborative computing devices (like video conferencing systems, smart whiteboards, or audio systems) to be turned on remotely. This means no one outside the physical location should be able to activate these devices, reducing the risk of unauthorized access or eavesdropping. For example, a hacker shouldn't be able to turn on your conference room camera without someone in the room pressing the power button. Another example: a Zoom Room system should not accept 'wake-on-LAN' commands from outside the network.
🎯 Why It Matters
Remote activation of collaborative devices creates a stealthy eavesdropping risk. Attackers could turn on cameras/microphones to spy on sensitive discussions (including CUI). In 2019, a US defense contractor had their conference room compromised via an unsecured VoIP system, leaking discussions about a classified project. The average cost of a corporate espionage incident exceeds $1 million. The DoD specifically calls out this control because collaborative devices are common in defense contractor facilities and often overlooked in security configurations.
✅ How to Implement
- 1. For cloud-managed devices (e.g., Microsoft Teams Rooms), disable 'remote wake' features in admin portals
- 2. In AWS/Azure/GCP, configure NACLs to block Wake-on-LAN (WoL) packets (UDP ports 7, 9, or vendor-specific)
- 3. Use Conditional Access policies (Azure AD) to block remote management of device power states
- 4. Enable device-specific controls (e.g., Cisco Webex Devices → disable 'Remote Power On' in settings)
- 5. Log all power state changes in cloud SIEM (e.g., Azure Sentinel alerts for unexpected activations)
📋 Evidence Examples
Network Switch Configuration
Collaborative Device Policy
SIEM Alert Logs
Physical Inspection Photos
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For SC.L2-3.13.12 ("Prohibit remote activation of collaborative computing devices"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe your network security architecture, including segmentation, encryption standards, VPN configuration, session management, key management, and monitoring capabilities. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"SC.L2-3.13.12 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to prohibit remote activation of collaborative computing devices. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"SC.L2-3.13.12 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to prohibit remote activation of collaborative computing devices. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"SC.L2-3.13.12 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Document network architecture with CUI boundary clearly marked
- • Identify all encryption mechanisms (at rest and in transit)
- • Specify network monitoring and IDS/IPS deployment
- • Ensure this control covers all systems within your defined CUI boundary where prohibit remote activation of collaborative computing devices applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 System and Communications Protection Policy
- 📄 Network architecture diagram
- 📄 Firewall rule documentation
- 📄 Encryption configuration documentation
- 📄 Evidence artifacts specific to SC.L2-3.13.12
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will review network diagrams for proper segmentation, test encryption settings, verify VPN split tunneling is disabled, and check FIPS 140-2 validation of cryptographic modules.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do all collaborative computing devices have physical/network controls preventing remote activation?
Question 2: Is there a written policy explicitly prohibiting remote activation?
Question 3: Are logs reviewed quarterly for unauthorized activation attempts?
Question 4: Have all relevant staff been trained on this requirement?
⚠️ Common Mistakes (What Auditors Flag)
1. Assuming 'off' means disabled
2. Missing secondary control channels
3. No monitoring for bypass attempts
4. Incomplete documentation
📚 Parent Policy
This practice is governed by the System and Communications Protection Policy