SI-16 Memory Protection

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Moderate, High	System	None

Related controls: AC-25, SC-3, SI-7

Control statement

Implement the following controls to protect the system memory from unauthorized code execution: [Assignment: organization-defined controls].

NIST discussion

Some adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. Controls employed to protect memory include data execution prevention and address space layout randomization. Data execution prevention controls can either be hardware-enforced or software-enforced with hardware enforcement providing the greater strength of mechanism.

Assessment objectives (SP 800-53A)

Objectives and methods for SI-16

Determine if [Assignment: organization-defined controls] are implemented to protect the system memory from unauthorized code execution.

Examine: System and information integrity policy; system and information integrity procedures; procedures addressing memory protection for the system; system design documentation; system configuration settings and associated documentation; list of security safeguards protecting system memory from unauthorized code execution; system audit records; system security plan; other relevant documents or records.

Interview: Organizational personnel responsible for memory protection; organizational personnel with information security responsibilities; system/network administrators; system developer.

Test: Automated mechanisms supporting and/or implementing safeguards to protect the system memory from unauthorized code execution.

Policy statement

• The System owner shall implement the following controls to protect the system memory from unauthorized code execution: Fill in: controls to be implemented to protect the system memory from unauthorized code execution Typical: data execution prevention and address space layout randomization, enforced by the operating system and hardware. (SI-16)

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

How to apply it

SI-16 asks you to protect system memory from unauthorized code execution with the controls you name. NIST’s SI-16 discussion says some adversaries try to execute code in non-executable regions of memory or in prohibited memory locations, names data execution prevention and address space layout randomization as the controls, and says data execution prevention can be hardware-enforced or software-enforced, with hardware enforcement giving the greater strength. SI-16 is in the Moderate and High baselines, not Low.

Modern operating systems and processors provide both protections and turn them on by default, so SI-16 is mostly about keeping them on. That makes it a configuration control: the setting lives in the baseline configuration (CM-6), and the evidence is a scan showing no exceptions.

Common implementations. Data execution prevention enforced by the processor’s no-execute bit and the operating system, and address space layout randomization on for the system and for applications, both set in the secure configuration each component follows. Exploit protection settings managed centrally through endpoint management or group policy, so they cannot be turned off locally. Applications and libraries built with the compiler and linker options that support these protections. On Linux and in containers, the kernel’s defaults left in place and checked by the configuration compliance scan.

Organization-defined parameters. Typical value, from the System and Information Integrity policy, which your organization may set differently:

Parameter	Typical value
Controls to protect system memory from unauthorized code execution	Data execution prevention and address space layout randomization, enforced by the operating system and hardware

The baseline configuration standard makes these settings part of every baseline: its section 4 has each baseline keep the platform’s memory protections on, such as address space layout randomization and data execution prevention. Exceptions, such as an old application that fails with them on, go in its deviation register with an approval and a reason.

Evidence assessors ask for.

• The secure configuration settings for data execution prevention and address space layout randomization, by component type
• A configuration compliance scan showing the settings in force across the component inventory
• The approved deviations, each with its reason and approver
• For applications the organization builds, the build settings that enable these protections

Inheritance. The hardware and operating system provide the mechanism. Where the organization manages endpoints and servers centrally, the settings are usually a common control from the endpoint and server teams. For a cloud service, the provider covers its own hosts; the system covers the operating systems and images it runs. Record which is which in the system security plan.

Common findings.

• Data execution prevention set to apply only to some programs, or switched off for a legacy application with no recorded deviation.
• No scan evidence, only a statement that the operating system has these protections by default.
• Old applications or appliances running on platforms that do not support the protections, with no compensating control recorded.

Enhancements in the Moderate baseline. None. SI-16 has no enhancements. A related control, process isolation (SC-39), keeps each process in its own address space; the two are often implemented by the same operating system settings.

Artifacts

• System and Information Integrity Decision Worksheet
• System and Information Integrity Policy