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 low 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 15 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-05 — Denial-of-service Protection #

Baselines: Low / Moderate / High 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 zero trust network access (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 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(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 CSF 2.0: PR.DS (Data Security)

Protect the [Selection (one or more): confidentiality; integrity — to be defined] 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 governance, risk, and compliance (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 [Selection (one or more): prevent unauthorized disclosure of information; detect changes to information — to be defined] 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-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 Office of Management and Budget (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-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-28 — Protection of Information at Rest #

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

Protect the [Selection (one or more): confidentiality; integrity — to be defined] 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.

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).