| name | SC-30(3)_change-processing-and-storage-locations |
| description | Change the location of [organization-defined] [organization-defined]]. |
| category | configuration |
| version | 5.2.0 |
| author | cyberstrike-official |
| tags | ["nist","sp800-53","rev5","sc-30-3","sc","enhancement"] |
| tech_stack | ["aws","azure","gcp","linux","windows","network"] |
| cwe_ids | ["CWE-311"] |
| chains_with | [] |
| prerequisites | ["SC-30"] |
| severity_boost | {} |
SC-30(3) Change Processing and Storage Locations
Enhancement of: SC-30
High-Level Description
Family: System and Communications Protection (SC)
Framework: NIST SP 800-53 Rev 5
Adversaries target critical mission and business functions and the systems that support those mission and business functions while also trying to minimize the exposure of their existence and tradecraft. The static, homogeneous, and deterministic nature of organizational systems targeted by adversaries make such systems more susceptible to attacks with less adversary cost and effort to be successful. Changing processing and storage locations (also referred to as moving target defense) addresses the advanced persistent threat using techniques such as virtualization, distributed processing, and replication. This enables organizations to relocate the system components (i.e., processing, storage) that support critical mission and business functions. Changing the locations of processing activities and/or storage sites introduces a degree of uncertainty into the targeting activities of adversaries. The targeting uncertainty increases the work factor of adversaries and makes compromises or breaches of the organizational systems more difficult and time-consuming. It also increases the chances that adversaries may inadvertently disclose certain aspects of their tradecraft while attempting to locate critical organizational resources.
What to Check
How to Test
Step 1: Review Documentation
Examine the System Security Plan (SSP) and related artifacts for SC-30(3) implementation details. Verify the organization has documented how this control is satisfied.
Step 2: Validate Implementation
# For cloud environments, use cloud-audit-mcp tools
# For on-premises, review system configurations directly
# Example: Check if account management policies exist
grep -r "account.management\|access.control" /etc/security/ 2>/dev/null
Step 3: Test Operating Effectiveness
Verify the control is actively functioning, not just documented. Check logs, configurations, and operational evidence.
Tools
