SC-39 Process Isolation

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Low, Moderate, High	System	2 (0 in a baseline)

Related controls: AC-3, AC-4, AC-6, AC-25, SA-8, SC-2, SC-3, SI-16

Control statement

Maintain a separate execution domain for each executing system process.

NIST discussion

Systems can maintain separate execution domains for each executing process by assigning each process a separate address space. Each system process has a distinct address space so that communication between processes is performed in a manner controlled through the security functions, and one process cannot modify the executing code of another process. Maintaining separate execution domains for executing processes can be achieved, for example, by implementing separate address spaces. Process isolation technologies, including sandboxing or virtualization, logically separate software and firmware from other software, firmware, and data. Process isolation helps limit the access of potentially untrusted software to other system resources. The capability to maintain separate execution domains is available in commercial operating systems that employ multi-state processor technologies.

Control enhancements

SC-39(1) Hardware Separation

Baselines: Not in a baseline

Implement hardware separation mechanisms to facilitate process isolation.

Discussion and assessment objectives for SC-39(1)

Hardware-based separation of system processes is generally less susceptible to compromise than software-based separation, thus providing greater assurance that the separation will be enforced. Hardware separation mechanisms include hardware memory management.

Determine if hardware separation is implemented to facilitate process isolation.

Examine: System and communications protection policy; system design documentation; system configuration settings and associated documentation; system architecture; system documentation for hardware separation mechanisms; system documentation from vendors, manufacturers, or developers; independent verification and validation documentation; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities; organizational personnel installing, configuring, and/or maintaining the system; system developers/integrators.

Test: System capability implementing underlying hardware separation mechanisms for process separation.

SC-39(2) Separate Execution Domain Per Thread

Baselines: Not in a baseline

Maintain a separate execution domain for each thread in [Assignment: organization-defined multi-threaded processing].

Discussion and assessment objectives for SC-39(2)

None.

Determine if a separate execution domain is maintained for each thread in [Assignment: organization-defined multi-threaded processing].

Examine: System and communications protection policy; system design documentation; system configuration settings and associated documentation; system architecture; list of system execution domains for each thread in multi-threaded processing; system documentation for multi-threaded processing; system documentation from vendors, manufacturers, or developers; independent verification and validation documentation; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities; system developer; organizational personnel installing, configuring, and/or maintaining the system; system developers/integrators.

Test: System capability implementing a separate execution domain for each thread in multi-threaded processing.

Assessment objectives (SP 800-53A)

Objectives and methods for SC-39

Determine if a separate execution domain is maintained for each executing system process.

Examine: System design documentation; system architecture; independent verification and validation documentation; testing and evaluation documentation; other relevant documents or records.

Interview: System developers/integrators; system security architect.

Test: Mechanisms supporting and/or implementing separate execution domains for each executing process.

Policy statement

• The System owner shall ensure the system maintains a separate execution domain for each executing system process. (SC-39)

From the System and Communications Protection Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

SC-39 asks the system to give each running process its own execution domain, so one process cannot read or change another’s memory or code except through controlled interfaces. NIST’s discussion says separate address spaces are the usual way, that sandboxing and virtualization are process isolation technologies too, and that the capability is available in commercial operating systems on processors with multiple privilege states. SC-39 is in the Low, Moderate and High baselines.

Common implementations. For most systems SC-39 is met by the platform: every current general-purpose operating system gives each process its own virtual address space, enforced by the processor’s memory management hardware, and hypervisors do the same for virtual machines. The work is in confirming it and in not undoing it:

• Run supported operating systems, hypervisors and container runtimes, patched, since isolation flaws are fixed by updates (SI-2).
• Do not turn off the isolation the platform provides, such as browser and hypervisor sandboxing, in the baseline configuration (CM-6). Address space layout randomization and data execution prevention, often set alongside it, are NIST’s examples for memory protection (SI-16), not SC-39; the baseline configuration standard requires them in every baseline under SI-16.
• In container platforms, do not run containers in privileged mode or let them mount sensitive host directories. NIST SP 800-190, Application Container Security Guide (September 2017), section 3.4.3, explains that a privileged container can access all devices on the host and act as part of the host operating system, affecting every other container on it. Section 4.4.3 recommends enforcing runtime configuration standards automatically, and mandatory access control such as SELinux or AppArmor for added isolation.
• Containers share the host kernel, so SP 800-190 section 3.5.2 notes their isolation is not as strong as a hypervisor’s; section 4.3.4 recommends that each host kernel run containers of a single sensitivity level, using separate virtual machines or clusters.
• Browsers and document readers that run untrusted content in their own sandbox, kept on.

Look closely at components that may not isolate processes: some embedded devices, appliances, industrial controllers and legacy systems run everything in one address space. Record those, with the compensating protections, in the system security plan.

Organization-defined parameters. SC-39 has no parameters. In the System and Communications Protection policy, the system owner ensures the system maintains a separate execution domain for each executing system process.

Evidence assessors ask for.

• The system security plan’s statement of how SC-39 is met for each component type, usually by the operating system, hypervisor or container platform
• The component inventory (CM-8), showing operating systems and versions are supported
• Baseline configuration or benchmark scan results showing the platform’s isolation features are on
• For container platforms, admission policy or scan results showing no privileged containers and no sensitive host mounts, and how workloads are placed by sensitivity
• The provider’s documentation for the hypervisor isolation it provides

Inheritance. SC-39 is usually inherited: from the operating system vendor’s design, and from the cloud provider for hypervisor isolation between virtual machines and tenants. Record it in the inheritance table of the system security plan, from the provider’s customer responsibility matrix, which is the typical answer to the SC decision worksheet’s question on inherited protections. The system still owns how it configures containers and which components it runs, so a container platform makes SC-39 a hybrid control.

Common findings.

• Containers running in privileged mode, or with the host’s file system or container runtime socket mounted, with no recorded need.
• An unsupported operating system or appliance firmware with known isolation flaws.
• SC-39 marked inherited with no statement of which component provides it, or for embedded components that do not.

Enhancements in the Moderate baseline. SC-39 has no enhancements in any baseline. SC-39(1) hardware separation and SC-39(2) separate execution domain per thread are in no baseline. NIST’s discussion of SC-39(1) names hardware memory management as a hardware separation mechanism, which current general-purpose processors provide.

Artifacts

• System and Communications Protection Decision Worksheet
• System and Communications Protection Policy