System and Communications Protection Procedure

Approval #

Revision History #

Review cycle: Every year, under the Policy and Procedure Management Policy.

1. Purpose #

The people named in this procedure use it to carry out the SC control family policy (POL-SC). It covers every control in the system and communications protection family. The steps, the people responsible, and the evidence below show how the Organization meets those National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 controls. They also support the Inspector General (IG) Federal Information Security Modernization Act (FISMA) reporting metrics.

This general procedure covers every control in the SC family. A system that departs from it, or adds to it, has its own system-specific procedure for those controls.

2. Scope #

This procedure applies to every information system that the Organization operates, or that others operate for it, under the moderate security baseline.

2.1 CSF 2.0 Alignment #

The steps in this procedure support these NIST Cybersecurity Framework (CSF) 2.0 categories:

• PR.DS — Data Security (Protect function)
• PR.PS — Platform Security (Protect function)
• PR.IR — Technology Infrastructure Resilience (Protect function)

3. Controls Covered #

This procedure covers the following 31 controls in the SC family:

3.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the SC control family. They add to the NIST SP 800-53 control requirements that the Procedure section carries out.

OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles

• The organization must encrypt all data in transit and at rest using FIPS-validated cryptographic modules. DNS traffic must be encrypted (DoH or DoT) and all internal network traffic must be authenticated and encrypted. Deadline: FY 2024. (OMB M-22-09, §3(c)(i))
• The organization must segment networks by application and environment instead of relying on a flat network, with access controls and monitoring enforced in each segment. Deadline: FY 2024. (OMB M-22-09, §3(c)(ii))

NIST SP 800-207: Zero Trust Architecture

• The organization must encrypt all communication between resources end to end, even on internal networks presumed trusted, so that its security does not depend on network location. (NIST SP 800-207, §3.3)

CISA BOD 23-02: Mitigating the Risk of Internet-Exposed Management Interfaces

• The organization must implement network segmentation to isolate management interfaces from production traffic. Management plane access must be separated from data plane access. (CISA BOD 23-02, §2)

OMB M-23-02: Migrating to Post-Quantum Cryptography

• The organization must plan for migration to quantum-resistant cryptography, with the goal of mitigating quantum risk by 2035. The inventory must include cryptographic algorithm types, data lifecycle characteristics, and system ownership. Deadline: 2035. (OMB M-23-02, §II.B)

OMB M-19-03: Strengthening Cybersecurity through the High Value Asset Program

• The organization must isolate and segment High Value Assets from broader agency networks using boundary protections and architecture reviews so that compromise of general-purpose environments does not directly expose HVAs. (OMB M-19-03, §B)

CISA High Value Asset (HVA) Control Overlay v1.0

• The organization must protect HVA authorization boundaries with boundary protection devices (gateways, routers, guards, encrypted tunnels, firewalls, application proxies) at the boundary and at tiered points within it, per the overlay’s SC-7 selection rationale. (CISA HVA Control Overlay v1.0, SC-7)

OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography

• The organization must execute a prioritized migration of cryptographic systems in every information system the organization owns or operates, with the objective of mitigating as much quantum risk as feasible by December 31, 2030. Prioritize high-impact systems, High Value Assets, and any other system holding highly sensitive data or judged particularly vulnerable to attack by a cryptanalytically relevant quantum computer. Deadline: 2030-12-31. (OMB M-26-15, Action One)
• The organization must support TLS 1.3 with post-quantum or hybrid key exchange, adopt crypto-agility (algorithm choices in external configuration rather than compiled in; agile key management infrastructure), fold PQC upgrades into planned cloud migrations, development lifecycles, and hardware refreshes, and identify systems that cannot support PQC or hybrid cryptography for priority replacement or decommissioning. (OMB M-26-15, Action One and Appendix)

Executive Order 14412: Securing the Nation Against Advanced Cryptographic Attacks

• The organization must review the inventory of High Value Assets and high-impact systems, then move every one of them to PQC for key establishment by December 31, 2030, and to PQC for digital signatures by December 31, 2031. Deadline: 2030-12-31 (key establishment); 2031-12-31 (digital signatures). (EO 14412, §4(b)(i)-(iii); OMB M-26-15)

OMB M-15-13: Policy to Require Secure Connections across Federal Websites and Web Services

• The organization must serve every publicly accessible website and web service only over a secure HTTPS connection, with HTTP Strict Transport Security (HSTS) enabled. Deadline: 2016-12-31. (OMB M-15-13)

OMB M-19-26: Update to the Trusted Internet Connections (TIC) Initiative

• The organization must keep an accurate inventory of network connections, keep network and system boundary policies current with Trusted Internet Connections (TIC) 3.0, and name the TIC use cases the Organization allows. (OMB M-19-26)

CISA BOD 18-01: Enhance Email and Web Security

• The organization must serve all public websites and web services over HTTPS only with HTTP Strict Transport Security (HSTS), and identify domains that can be HSTS preloaded. (CISA BOD 18-01, Required Actions)
• The organization must disable SSLv2 and SSLv3, and the 3DES and RC4 ciphers, on all internet-facing web and mail servers. (CISA BOD 18-01, Required Actions)
• The organization must configure all internet-facing mail servers to offer STARTTLS. (CISA BOD 18-01, Required Actions)
• The organization must publish valid Sender Policy Framework (SPF) and DMARC records for every second-level domain, with CISA’s address among the DMARC aggregate report recipients. (CISA BOD 18-01, Required Actions)
• The organization must set a DMARC policy of reject (p=reject) for all second-level domains and mail-sending hosts. (CISA BOD 18-01, Required Actions)

NIST CMVP: FIPS 140-3 Transition Effort

• The organization must buy only cryptographic modules that hold an active FIPS 140-3 validation, because FIPS 140-2 certificates moved to the CMVP Historical list in September 2026. Deadline: September 2026. (FIPS 140-3; NIST CMVP FIPS 140-3 Transition; 40 U.S.C. § 11331)
• The organization must track each system that still uses a FIPS 140-2 module after September 2026 as a plan of action and milestones item until the module is replaced. (FIPS 140-3; NIST CMVP FIPS 140-3 Transition)

OMB M-21-07: Completing the Transition to Internet Protocol Version 6 (IPv6)

• The organization must keep an IPv6 implementation plan that moves at least 80 percent of IP-enabled assets on federal networks to IPv6-only. Deadline: End of FY 2025 (80 percent IPv6-only). (OMB M-21-07)
• The organization must list each system that cannot move to IPv6-only, with a schedule to replace or retire it. (OMB M-21-07)
• The organization must enable IPv6 on every new networked federal information system when it is deployed. Deadline: Starting in FY 2023. (OMB M-21-07)
• The organization must make sure every system that supports network operations or enterprise security, such as firewalls, intrusion detection, and logging, can operate in an IPv6-only environment. (OMB M-21-07)

NIST SP 800-52 Rev 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations

• The organization should configure servers for government-only applications to use TLS 1.2 or later, and never to use TLS 1.0, SSL 3.0, or SSL 2.0. (NIST SP 800-52 Rev 2, §3.1)
• The organization should support TLS 1.3 on servers and clients that use TLS. Deadline: January 1, 2024. (NIST SP 800-52 Rev 2, §3.1)

NIST SP 800-57 Part 1 Rev 5: Recommendation for Key Management: Part 1 - General

• The organization should document key management for each system, including a cryptoperiod for each key type and how keys are generated, distributed, stored, backed up, archived, and destroyed. (NIST SP 800-57 Part 1 Rev 5, §§5-8)
• The organization should keep a key compromise recovery plan that covers revoking and replacing affected keys and notifying the parties that rely on them. (NIST SP 800-57 Part 1 Rev 5, §6)

NIST SP 800-119: Guidelines for the Secure Deployment of IPv6

• The organization should detect and examine IPv6 traffic on every network, including networks meant to carry only IPv4, so that no device uses IPv6 unseen. (NIST SP 800-119)

4. Procedure #

4.1 General Implementation Approach #

The Organization implements the SC controls in two ways: as organization-wide common controls that systems inherit, and as system-specific implementations where a system needs them. The control-specific procedures below cover each control in the System and Communications Protection family.

The Common Control Provider (CCP) implements controls marked inherited for the whole Organization. The CCP and each System Owner share the work for controls marked hybrid. Each System Owner implements controls marked customer-configured for the system.

Responsible party: The Network Engineer / Information System Security Officer (ISSO) carries out the steps in this procedure unless a control-specific procedure names someone else. The System Owner is accountable for funding and completing the work. The CISO oversees the procedure and receives its performance measures. See the SC policy (POL-SC) for the role definitions.

4.2 Control-Specific Procedures #

SC-01 — Policy and Procedures #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security)

1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:

1. [Selection (one or more): organization-level; mission/business-process-level; system-level — to be defined] system and communications protection policy that:

1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the system and communications protection policy and the associated system and communications protection controls;

2. Designate an [Assignment: organization-defined official — to be defined] to manage the development, documentation, and dissemination of the system and communications protection policy and procedures; and
3. Review and update the current system and communications protection:

1. Policy at least every 3 years and following significant changes; and
2. Procedures at least annually and following [Assignment: organization-defined events — to be defined].

Procedure:

The CISO’s office keeps the master copies of POL-SC and PROC-SC and manages their review and distribution. When either document is issued or revised, the office sends it to the Authorizing Official, System Owners, ISSOs, and the stakeholders on the distribution list. The office records each distribution on the document’s distribution list.

The CISO’s office opens the review in the policy library in the document management system every 3 years. The office collects input from System Owners and ISSOs, checks both documents against current directives, and confirms that the named tools and interfaces still match the environment. The office opens the same review out of cycle when the Organization adopts a new cloud platform service or changes how the secure web gateway carries traffic. The CISO approves each revision. The approved version replaces the prior one, and the office records the change in the document’s change history.

Evidence: the approved policy and procedures with their change history, the distribution records, and the review records that show when each scheduled or event-driven review ran and what it changed.

SC-02 — Separation of System and User Functionality #

Baselines: Moderate / High / HVA overlay CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Separate user functionality, including user interface services, from system management functionality.

Procedure:

Cloud engineers build each workload in the cloud platform so that the components that serve users and the components that administer the system sit in different network segments. User-facing services end in public-facing subnets. Administrative interfaces sit in management subnets with their own access rules and no public exposure. Administrators reach the management interfaces through the zero trust network access (ZTNA) service, and the ZTNA service access policy admits only the administrator group. End users have no network route to those interfaces.

At design time, and at every architecture change, the System Owner submits the design through the change process in the ticketing system. The ISSO reviews the segmentation before the change is approved. If a design deviates from this pattern, the System Owner records a risk decision in the governance, risk, and compliance (GRC) system before the change is approved.

Evidence: architecture diagrams that show the separated segments, the cloud platform network rule exports, the ZTNA service access policy limited to administrators, and the ticketing system change records with the ISSO’s review.

SC-03 — Security Function Isolation #

Baselines: High / HVA overlay (applies to systems designated as High Value Assets, under Office of Management and Budget (OMB) M-19-03)

Isolate security functions from nonsecurity functions.

Procedure:

During design review, the Information System Security Officer (ISSO) identifies the security functions in each system and where each one runs. The System Owner places those functions in dedicated processes, service accounts, or network segments that ordinary application components cannot modify. In the cloud platform, administrators keep management interfaces on a separate network path from production workload traffic. Administrators limit changes to security function settings to privileged accounts. The ISSO verifies the separation before the system enters production and after any significant change. The ISSO records any function that cannot be separated, with its safeguards, in the system security and privacy plan. The Chief Information Security Officer (CISO) reviews and approves each recorded exception.

Evidence: design review records, network and account configuration records, ISSO verification results, and CISO-approved exceptions in the system security and privacy plan.

SC-04 — Information in Shared System Resources #

Baselines: Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Prevent unauthorized and unintended information transfer via shared system resources.

Procedure:

For infrastructure, the Organization relies on the isolation that the cloud platform provides between tenants and between released and reallocated resources. The Common Control Provider documentation records that inheritance, and System Owners cite it instead of building the mechanism again.

For the layers the Organization builds, engineers configure applications so that temporary files, caches, and message queues that hold sensitive content belong only to the session or process that created them. The application clears them on release. Design reviews for new services and significant changes include a shared-resource check, and the reviewer records the result in the ticketing system change ticket. Engineers fix each finding before release, or the System Owner accepts the risk with a documented rationale in the GRC system.

Evidence: the inheritance documentation, the design review notes in change tickets, and the remediation records for shared-resource findings.

SC-05 — Denial-of-service Protection #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security), PR.IR (Technology Infrastructure Resilience)

1. Protect against the effects of the following types of denial-of-service events: at a minimum: ICMP (ping) flood, SYN flood, slowloris, buffer overflow attack, and volume attack; and
2. Employ the following controls to achieve the denial-of-service objective: [Assignment: organization-defined controls by type of denial-of-service event — to be defined].

Procedure:

Engineers place every public-facing service in the cloud platform behind load-balanced, redundant infrastructure with capacity alarms. This design lets a service slow down under a traffic surge instead of failing completely. Engineers publish internal applications only through the ZTNA service, so they have no internet address and cannot be attacked directly.

When a capacity alarm or a user report suggests a denial-of-service attack, the responding administrator opens a ticketing system incident and notifies the ISSO. The team then follows the SANS-based playbook or the alternative the CISO approved. The team filters the attacking traffic at the managed interface, adds capacity, and works with the infrastructure provider when needed.

After the event, the System Owner records what was attacked, which protections held, and what changed as a result. Evidence: the architecture and capacity records, the alarm history, the incident tickets, and the post-event summaries.

SC-07 — Boundary Protection #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

1. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system;
2. Implement subnetworks for publicly accessible system components that are [Selection: physically; logically — to be defined] separated from internal organizational networks; and
3. Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture.

Procedure:

The network engineering team maintains the boundary architecture, with the cloud platform segments by application and environment and separate subnets for public-facing components. Every external connection ends on a managed interface. The team records each interface in the interface inventory with its approved Trusted Internet Connections (TIC) 3.0 use case. The team updates the boundary rules when the Cybersecurity and Infrastructure Security Agency (CISA) updates TIC guidance. The secure web gateway inspects, filters, and logs all outbound web traffic.

A request for a new external connection or a boundary rule change enters the ticketing system with its business justification and, for a temporary rule, an end date. Before a rule opens a system to the internet, the security operations team runs a credentialed scan of the target hosts and a web scan for web services. The team approves the rule only when no critical finding and no high finding past its remediation deadline remain. The team rejects any rule that allows cleartext administrative or file-transfer protocols at the perimeter. The CISO approves the request, and the engineering team makes the change and updates the inventory.

For High Value Assets, the team layers boundary protections at the perimeter and inside the environment. The ISSO reviews the interface inventory and the rule sets as part of ongoing monitoring.

Evidence: the interface inventory with TIC use cases, rule set exports from the cloud platform and the secure web gateway, pre-exposure scan results, change tickets with approvals, and architecture review records.

SC-07(3) — Access Points #

Baselines: Moderate / High

Limit the number of external network connections to the system.

Procedure:

The network engineering team keeps the number of external connections small. User and workload traffic to the internet goes through the secure web gateway service. Direct external links exist only where a recorded mission need requires them. The team lists each connection in the interface inventory with its justification and its owner. A request for a new connection goes through the ticketing system and carries the CISO’s approval. During boundary reviews, the ISSO checks the inventory and flags any connection whose justification has lapsed. The engineering team then removes that connection. Evidence: the interface inventory, the approval tickets, and the removal records.

SC-07(4) — External Telecommunications Services #

Baselines: Moderate / High

1. Implement a managed interface for each external telecommunication service;
2. Establish a traffic flow policy for each managed interface;
3. Protect the confidentiality and integrity of the information being transmitted across each interface;
4. Document each exception to the traffic flow policy with a supporting mission or business need and duration of that need;
5. Review exceptions to the traffic flow policy at least every 180 days or whenever there is a change in the threat environment that warrants a review of the exceptions and remove exceptions that are no longer supported by an explicit mission or business need;
6. Prevent unauthorized exchange of control plane traffic with external networks;
7. Publish information to enable remote networks to detect unauthorized control plane traffic from internal networks; and
8. Filter unauthorized control plane traffic from external networks.

Procedure:

The network engineering team maintains a flow policy for each managed interface that carries external telecommunications services and encrypts the traffic that crosses it. A person who needs an exception requests it through the ticketing system with the mission justification and an expiration date. The team adds each approved exception to the exception register. At least quarterly, and after any significant change, the ISSO reviews the register with the engineering team. The team removes at the interface any exception that no longer has a current justification, and updates the register. Filters at the managed interfaces block unauthorized routing and management exchanges with external networks. The team publishes routing information so that peer networks can recognize traffic that should not originate from the Organization. Evidence: the flow policies, the exception register with expiration dates, the quarterly review records, and the filter configurations.

SC-07(5) — Deny by Default — Allow by Exception #

Baselines: Moderate / High

Deny network communications traffic by default and allow network communications traffic by exception any systems.

Procedure:

Engineers build the cloud platform rule sets from an empty allow list. Only traffic named in an approved rule passes, and the rule set drops everything else. The secure web gateway policy applies the same rule to outbound web traffic: it permits categories and destinations by policy and blocks the rest. A new allow rule starts as a ticketing system request with its justification and its owner. After approval, an engineer implements the rule and tags it with the ticket number. During boundary reviews, the ISSO samples rules and traces each one back to its ticket. The ISSO orders the removal of any rule without a matching ticket. Evidence: the rule set exports, the tickets behind each rule, and the review records.

SC-07(7) — Split Tunneling for Remote Devices #

Baselines: Moderate / High

Prevent split tunneling for remote devices connecting to organizational systems unless the split tunnel is securely provisioned using [Assignment: organization-defined safeguards — to be defined].

Procedure:

Remote endpoints run the ZTNA client. Administrators configure the client centrally to carry all traffic through the service. They lock the setting so that users cannot open a side path to local networks or the internet. When a securely provisioned split tunnel is approved, administrators restrict it to managed, named destinations on a device with current endpoint protection. Administrators record the approval in the ticketing system. Administrators verify tunnel enforcement when they provision a device and after any configuration change. Evidence: the ZTNA client configuration, the approval records, and the provisioning checks.

SC-07(8) — Route Traffic to Authenticated Proxy Servers #

Baselines: Moderate / High

Route [Assignment: organization-defined internal communications traffic — to be defined] to any network outside of organizational control and any network outside the authorization boundary through authenticated proxy servers at managed interfaces.

Procedure:

The secure web gateway is the authenticated proxy between the enterprise and external networks. Each user and workload authenticates before the secure web gateway carries its traffic, and the routing leaves no other way out. The engineering team configures network paths so that all outbound flows go to the secure web gateway. The network drops and logs any attempt to reach an external network directly. The proxy logs record who sent what, and where it went. The ISSO uses those logs when investigating anomalies. The engineering team records each approved bypass exception in the ticketing system with its justification and expiration date. Evidence: the secure web gateway authentication and policy configuration, the egress routing records, the proxy logs, and the exception tickets.

SC-07(12) — Host-based Protection #

Baselines: Moderate / High

Implement Host Intrusion Prevention System (HIPS), Host Intrusion Detection System (HIDS), or minimally a host-based firewall at [Assignment: organization-defined system components — to be defined].

Procedure:

Administrators enable and configure host firewalls on designated components as part of the build baseline. Each firewall allows only the ports and flows that the component’s role requires. The baseline settings are under version control, and every change goes through a ticketing system ticket with System Owner approval. When an administrator must change a component’s firewall for troubleshooting, the change is temporary, has a ticket, and is reversed afterward. The ISSO samples components against the baseline during monitoring reviews. Evidence: the baseline configuration records, the change tickets, and the sampling results.

SC-07(18) — Fail Secure #

Baselines: Moderate / High

Prevent systems from entering unsecure states in the event of an operational failure of a boundary protection device.

Procedure:

Engineers configure boundary enforcement to fail closed. If the secure web gateway path is unavailable, endpoints do not fall back to direct internet access. If an enforcement component in the cloud platform fails, the rules for its segment continue to deny unmatched traffic. A boundary device failure raises an alarm. The responding administrator opens a ticketing system incident. The ISSO confirms that no uninspected traffic passed during the outage before the team declares service restored. Administrators run failover checks to confirm this behavior. Evidence: the fail-closed configurations, the incident tickets with the ISSO’s confirmation, and the failover check records.

SC-07(24) — Personally Identifiable Information #

Baselines: Privacy

For systems that process personally identifiable information: (a) Apply the following processing rules to data elements of personally identifiable information: [Assignment: organization-defined processing rules — to be defined]; (b) Monitor for permitted processing at the external interfaces to the system and at key internal boundaries within the system; (c) Document each processing exception; and (d) Review and remove exceptions that are no longer supported.

Procedure:

The System Owner writes the personally identifiable information (PII) processing rules from the privacy impact assessment and lists the approved data flows in the System Security and Privacy Plan (SSPP). Network engineers configure the secure web gateway and the network controls in the cloud platform to allow only those flows at the system boundary and between internal segments. The ISSO reviews the boundary logs for PII flows that the rules do not allow and opens an incident ticket for each one. The System Owner records each approved exception in the SSPP. The System Owner and the Privacy Officer review every exception when the privacy impact assessment is updated and remove the ones that are no longer justified.

Evidence: the PII processing rules, the approved flow list and exception register in the SSPP, boundary configuration records, monitoring logs, and incident tickets.

SC-08 — Transmission Confidentiality and Integrity #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.DS (Data Security)

Protect the confidentiality AND integrity of transmitted information.

Procedure:

Engineers configure each service endpoint in the cloud platform, including internal paths, for encrypted transport with Federal Information Processing Standards (FIPS)-validated modules. Engineers set every TLS server to NIST SP 800-52 Rev 2, with TLS 1.2 or later, TLS 1.3 support, and no Secure Sockets Layer (SSL), Rivest Cipher 4 (RC4), or 3DES. Each public website and web service redirects to Hypertext Transfer Protocol Secure (HTTPS) and sends an HSTS header. The ZTNA service brokers user connections to applications in encrypted tunnels. Domain Name System (DNS) resolution uses the encrypted DNS filtering service.

The ISSO treats a CISA Cyber Hygiene finding against these settings as a vulnerability with a due date. The CISO publishes the approved channels for sending sensitive data outside the Organization, such as encrypted email or an approved file-sharing service. The Security Operations Center runs data loss prevention on outbound email and web traffic and sends confirmed violations to incident handling.

When a legacy interface cannot meet the standard, the System Owner records the exception, the compensating control, and the retirement date in the GRC system for the CISO to review.

Evidence: the endpoint transport configurations, the TLS and HTTPS scan results, the approved channel list, the data loss prevention dispositions, and the exception records.

SC-08(1) — Cryptographic Protection #

Baselines: Low / Moderate / High

Implement cryptographic mechanisms to prevent unauthorized disclosure of information AND detect changes to information during transmission.

Procedure:

Engineers enforce transport encryption in configuration. The cloud platform endpoints and internal service paths negotiate approved, FIPS-validated cipher suites whose integrity mechanisms reveal tampering in transit. ZTNA tunnels protect user-to-application sessions the same way. Engineers apply the cipher standard at deployment. Configuration reviews compare endpoints against the standard, and an engineer opens a ticketing system ticket to correct each deviation. Evidence: the cipher configuration exports, the review results, and the correction tickets.

SC-10 — Network Disconnect #

Baselines: Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Terminate the network connection associated with a communications session at the end of the session or after no longer than ten (10) minutes for privileged sessions and no longer than fifteen (15) minutes for user sessions of inactivity.

Procedure:

The ZTNA service access policy holds the idle timeout. When a remote access session shows no activity for 10 minutes, the service disconnects it and releases the network connection. The applications and the access layer together end the connection when a session ends. A user whose session was dropped for inactivity reconnects only by authenticating again.

Administrators keep the timeout value in the ZTNA service configuration under change control. A request to change it enters the ticketing system and needs the System Owner’s approval and the ISSO’s concurrence. The ISSO checks the configured value during reviews.

Evidence: the ZTNA service policy export that shows the 10-minute setting, the change tickets for any adjustment, and the session logs that show the terminations.

SC-12 — Cryptographic Key Establishment and Management #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Establish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: In accordance with Federal requirements.

Procedure:

Administrators generate keys for cloud workloads inside the managed key services of the cloud platform. FIPS-validated modules there hold the secret and private keys, and cryptographic operations run without exporting key material. Access to key operations follows least privilege and separates the key owner from the administrators who use the key. Administrators distribute keys through platform access grants and never by copying key material. Administrators keep keys in the key service, apart from the encrypted data, and back up the keys needed to recover data.

The ISSO maintains the cryptographic inventory. It records each key’s owner, purpose, algorithm, cryptoperiod, and the data lifecycle notes that OMB M-23-02 requires. Administrators rotate each key before its cryptoperiod ends and destroy retired keys.

When someone suspects a compromise, the Incident Response Team leads the response. The key owner revokes and replaces the key, and administrators re-protect the affected data.

A request for a new key or a change to key access goes through the ticketing system with System Owner approval.

Evidence: the key service configuration and operation logs, the cryptographic inventory with cryptoperiods, the rotation and backup records, the compromise response records, and the approval tickets.

SC-13 — Cryptographic Protection #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

1. Determine the [Assignment: organization-defined cryptographic uses — to be defined]; and
2. Implement the following types of cryptography required for each specified cryptographic use: FIPS-validated or NSA-approved cryptography.

Procedure:

System Owners catalog where their systems use cryptography: data at rest, transmission, password storage, and mobile devices. For each use, they record the module and its FIPS 140-3 certificate number. Engineers configure the cloud platform services with FIPS-validated endpoints and modules, and ZTNA tunnels use the validated cipher standard.

When a new service or a change adds a cryptographic function, the ticketing system change ticket names the module and its certificate. The ISSO checks that the certificate is active under FIPS 140-3 before approval. When the program moves a cataloged module to its Historical list, the System Owner opens a plan of action and milestones (POA&M) item with a replacement date, and the Authorizing Official accepts the risk.

When someone finds unvalidated cryptography in operation, the System Owner opens a remediation ticket. The System Owner either replaces the implementation or records a risk acceptance with compensating protections in the GRC system for the CISO to approve.

Evidence: the cryptographic use catalog with certificate numbers, the change tickets, the POA&M items for historical modules, and the remediation records.

SC-15 — Collaborative Computing Devices and Applications #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

1. Prohibit remote activation of collaborative computing devices and applications with the following exceptions: no exceptions for computing devices; and
2. Provide an explicit indication of use to users physically present at the devices.

Procedure:

Administrators configure collaborative devices and applications, including cameras, microphones, room systems, and meeting software, so that remote activation is off by default and an in-use indicator is visible to anyone present. A request to allow remote activation enters the ticketing system and must attach the Chief Information Officer (CIO)’s written authorization that names the mechanism, the purpose, and the system. Without that authorization, the administrator denies the request. Administrators record each approved configuration and lock the settings against user change.

When equipment is installed, replaced, or reconfigured, the ISSO verifies the indicator and the remote-activation setting before the equipment enters service. Administrators recheck the settings later to confirm that they remain in place.

Evidence: the configuration records, the ticketing system requests with attached CIO authorizations, and the verification results.

SC-17 — Public Key Infrastructure Certificates #

Baselines: Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

1. Issue public key certificates under an [Assignment: organization-defined certificate policy — to be defined] or obtain public key certificates from an approved service provider; and
2. Include only approved trust anchors in trust stores or certificate stores managed by the organization.

Procedure:

An administrator who needs a certificate opens a ticketing system request that names the system and the use. The administrator obtains the certificate from the General Services Administration (GSA) or a CIO-approved provider, installs it, and records it with its expiration date in the certificate register. Administrators schedule renewal work from those records before each expiration date, so no service runs on a lapsed certificate.

Trust stores on managed systems hold the approved anchor set. Adding an anchor requires an approved ticket. The ISSO compares the store contents against the approved list and removes anything that the list does not include. Certificates that support digital signatures follow the same issuance path.

Evidence: the issuance and renewal tickets, the certificate register with expiration dates, the trust store exports, and the ISSO’s comparison results.

SC-18 — Mobile Code #

Baselines: Moderate / High / HVA overlay CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

1. Define acceptable and unacceptable mobile code and mobile code technologies; and
2. Authorize, monitor, and control the use of mobile code within the system.

Procedure:

The CISO’s office maintains the approved mobile code list: the technologies permitted, the technologies barred, and the conditions on each. The secure web gateway enforces the barred set at the web boundary. It blocks the active content categories the Organization does not accept and logs what it blocks. Administrators configure endpoint browser and application settings to match the approved list through the standard baseline.

A request to run a technology outside the list enters the ticketing system with its justification. The CISO decides the request, and the office records each approval with its scope. The ISSO reviews the secure web gateway block logs and baseline compliance for signs of unauthorized mobile code and opens a remediation ticket wherever it appears.

Evidence: the approved technology list, the secure web gateway filtering configuration and block logs, the baseline settings, and the decision tickets.

SC-20 — Secure Name/Address Resolution Service (Authoritative Source) #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

1. Provide additional data origin authentication and integrity verification artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and
2. Provide the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace.

Procedure:

DNS administrators host the Organization’s public authoritative zones in the cloud platform and keep them signed. The zone data carries the signatures and related records that external resolvers use to authenticate the origin and verify the integrity of each answer. Administrators publish delegation records for child zones, which extend the chain of trust where a child zone supports secure resolution. Administrators plan each signing key rollover, run it under a ticketing system change ticket, and verify it so that signatures never lapse during the rotation.

Administrators check signature validity as part of routine operations. A validation failure or an expiring signature raises a ticketing system incident. Administrators restore signing before external resolvers see a broken chain of trust.

Evidence: the signed zone configurations, the rollover change tickets with verification, the results of the operational checks, and the incident records for any validation failure.

SC-21 — Secure Name/Address Resolution Service (Recursive or Caching Resolver) #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Request and perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources.

Procedure:

Client and workload DNS queries resolve through the DNS filtering service. The resolution service requests the validation records from authoritative sources and verifies them before it returns an answer. The service discards any response that fails verification. Engineers configure endpoints and network egress so that DNS cannot take another path; the boundary blocks direct use of outside resolvers.

Administrators confirm the validation behavior whenever the resolution service changes. A resolution anomaly raises a ticketing system incident, and the ISSO reviews it. The ISSO documents each approved exception to the protected path with its scope.

Evidence: the resolver and DNS protection configuration, the egress rules that block bypass, the validation checks after changes, and the incident records.

SC-22 — Architecture and Provisioning for Name/Address Resolution Service #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Ensure the systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal and external role separation.

Procedure:

External authoritative zones run on redundant cloud platform infrastructure spread across separate availability locations, so the loss of one instance does not stop resolution. Internal name resolution runs on separate servers inside the boundary that external networks cannot reach. The external-facing servers hold no internal records. Client resolution uses the DNS filtering service, which is itself distributed.

The engineering team tests failover behavior whenever the architecture changes. Administrators handle a resolution outage as a ticketing system incident and record the root cause. The ISSO reviews the role separation and the redundancy at architecture reviews.

Evidence: the resolution architecture records, the redundancy and failover test results, the incident tickets, and the review notes.

SC-23 — Session Authenticity #

Baselines: Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Protect the authenticity of communications sessions.

Procedure:

Engineers build session protection into both the transport and the application configuration. The ZTNA service brokers and encrypts user connections, with the user authenticated to the session. Services in the cloud platform accept only encrypted sessions, and the session negotiation authenticates the server to the client. Application configurations protect the session itself: the application generates identifiers unpredictably, sends them only inside the encrypted channel, and invalidates them when the session ends.

Engineers apply these settings from the configuration standard. The ISSO examines session handling when a new service is approved and when a session-related anomaly appears. When a review finds a deviation, an engineer opens a ticketing system ticket and corrects it on the standard timeline.

Evidence: the transport and session configuration records, the review findings, and the correction tickets.

SC-28 — Protection of Information at Rest #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Protect the confidentiality AND integrity of the following information at rest: [Assignment: organization-defined information at rest — to be defined].

Procedure:

Engineers provision storage in the cloud platform with encryption at rest enabled, using FIPS-validated modules. This covers block volumes, object storage, database instances, and their backups. The standard build makes encrypted storage the default from creation. Platform configuration checks in the cloud platform flag any storage created without encryption. The owning administrator corrects each flagged resource under a ticketing system ticket with a remediation date.

System Owners record where sensitive PII, sensitive business identifiable information (BII), and moderate- and high-impact information resides. Those records let the ISSO check encryption coverage against the actual data locations. The ISSO samples storage configurations during monitoring reviews and tracks each finding to closure.

Evidence: the storage encryption configurations, the platform check results, the remediation tickets, and the data location records.

SC-28(1) — Cryptographic Protection #

Baselines: Low / Moderate / High

Implement cryptographic mechanisms to prevent unauthorized disclosure and modification of the following information at rest on all information system components storing Federal data or system data that must be protected at the High or Moderate impact levels: [Assignment: organization-defined information — to be defined].

Procedure:

Engineers enforce encryption at rest on the storage that holds the data. The cloud platform storage services encrypt volumes, objects, databases, and snapshots with FIPS-validated modules, and the standard build encrypts endpoint drives. Administrators verify the setting when they provision a component. Platform checks flag unencrypted resources, and the owning administrator corrects each one under a ticketing system ticket. Each exception carries a documented risk acceptance in the GRC system and an expiration date that the CISO sets. Evidence: the encryption configuration exports, the provisioning verification records, the remediation tickets, and the exception register.

SC-39 — Process Isolation #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Maintain a separate execution domain for each executing system process.

Procedure:

Process isolation operates in the platform layers the Organization builds on. The operating systems in the approved build keep each process in its own address space. The cloud platform separates workloads beneath the operating system, and the Common Control Provider records that inheritance in its documentation.

The Organization’s task is to keep that isolation intact. Build standards leave memory protection and process separation features enabled. Reviewers catch any configuration that would weaken those features during change review in the ticketing system. Where workloads of different sensitivity share infrastructure, engineers place them according to the segmentation architecture. The ISSO confirms the inheritance references and the build settings during reviews.

Evidence: the build standard settings, the inheritance documentation, and the change review records.

SC-45 — System Time Synchronization #

Baselines: Moderate / High

Synchronize system clocks within and between systems and system components.

Procedure:

Workloads in the cloud platform synchronize their clocks to the platform time service as part of the standard build. Administrators configure other managed components at build time to the same authoritative reference. The environment therefore keeps a single timeline for authentication, certificates, and audit records.

Administrators watch for drift. When a component’s clock drifts, an administrator corrects it under a ticketing system ticket. When the same component drifts again, the administrator investigates the underlying fault. Time configuration is part of the build standard. Administrators check it when they provision a system and check it again after any significant change, because many other controls depend on accurate time.

Evidence: the time configuration in the build standard, the provisioning check results, and the drift correction tickets.

SC-45(1) — Synchronization with Authoritative Time Source #

Baselines: Moderate / High

1. Compare the internal system clocks At least hourly with http://tf.nist.gov/tf-cgi/servers.cgi; and
2. Synchronize the internal system clocks to the authoritative time source when the time difference is greater than any difference.

Procedure:

Time synchronization runs as a background service on managed components. The client compares the local clock with the authoritative source at the configured interval and corrects the clock when the offset passes the configured threshold. Workloads in the cloud platform use the platform time service as that source. Administrators review the synchronization status to find components that fail to correct themselves. When a component fails repeatedly, an administrator opens a ticketing system ticket and works it to root cause. Evidence: the synchronization configuration, the status output that shows comparisons and corrections, and the tickets for failures.

5. Parameters (ODP Values) #

The following organization-defined parameters apply to controls in this family:

6. Evidence Artifacts #

Carrying out this procedure produces these records:

• Procedure execution records for SC
• Configuration documentation
• Periodic review records
• Evidence for IG FISMA metric CM.01
• Evidence for IG FISMA metric CM.02
• Evidence for IG FISMA metric CM.16
• Evidence for IG FISMA metric DPP.01
• Evidence for IG FISMA metric DPP.02
• Evidence for IG FISMA metric DPP.23

7. Performance Measurement #

The CISO measures this procedure with the indicators below, which meet IG FISMA Level 4 (Managed and Measurable). The ISSO collects the data, and the CISO trends and reports it. When a measure moves away from its target, the CISO starts corrective action through the POA&M process.

8. Training Requirements #

Before they carry out the steps in this procedure, and every year after, the people who perform them must complete:

• General security awareness training, which all personnel take under POL-AT.
• Role-based training on this procedure’s steps, tools, and evidence.
• Training on the technology platforms listed under Technology Implementation, matched to their duties.

Completion is a condition of continued access. The Agency Learning Management System (LMS) holds the completion records.

9. Governance References #

• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• OMB M-15-13: Policy to Require Secure Connections across Federal Websites and Web Services, June 8, 2015.
• OMB M-19-26: Update to the Trusted Internet Connections (TIC) Initiative, September 12, 2019.
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• OMB M-23-02: Migrating to Post-Quantum Cryptography, November 18, 2022.
• OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography, June 24, 2026.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• CISA BOD 18-01: Enhance Email and Web Security, October 16, 2017.
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• CISA High Value Asset (HVA) Control Overlay v1.0, November 1, 2017.
• Executive Order 14412: Securing the Nation Against Advanced Cryptographic Attacks, June 22, 2026.
• Superseded source, kept for its history: FIPS 140-2: Security Requirements for Cryptographic Modules, May 25, 2001. Replaced by FIPS 140-3.
• FIPS 140-3: Cryptographic Module Security Requirements, March 22, 2019.
• FIPS 140-3 Transition Effort, updated continuously.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, August 2019.
• NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management: Part 1 - General, May 2020.
• NIST SP 800-119: Guidelines for the Secure Deployment of IPv6, December 2010.
• NIST SP 800-207: Zero Trust Architecture, August 2020.
• OMB M-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.
• OMB M-21-07: Completing the Transition to Internet Protocol Version 6 (IPv6), November 19, 2020.
• Responsibilities for Federal information systems standards (40 U.S.C. § 11331).