Memory Protection SI-16

System and Information Integrity · Moderate baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds SI-16 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, System and Information Integrity family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

SI-16 (Memory Protection) is about stopping a system’s memory from being used to run code an attacker slipped in — the classic goal of a buffer overflow and similar exploits. The defense is a set of built-in protections that make memory harder to abuse: randomizing where things load, marking data areas as non-executable, and catching common overflow tricks. It sits in the Moderate baseline.

What good looks like

Turn on ASLR (Address Space Layout Randomization), which shuffles where programs and libraries load so an attacker cannot predict memory addresses.
Enforce NX (the No-eXecute bit, also called Data Execution Prevention), which marks data memory as non-runnable so injected code will not execute.
Build software with hardening on — stack protection and fortified library functions catch common overflows at run time.
Keep the kernel and toolchain current, because memory protections improve from version to version.
Verify the protections are actually on rather than assuming the defaults held.

Framework mapping

NIST CSF 2.0 — PR.DS-10 — The confidentiality, integrity, and availability of data-in-use are protected
CIS Controls v8 — Control 10 — Malware Defenses

How to move it toward Implemented

Confirm ASLR is at full strength — sysctl kernel.randomize_va_space should return 2; if not, set kernel.randomize_va_space = 2 in a file under /etc/sysctl.d/ and run sysctl -p.
Check the No-eXecute bit is active: grep -w nx /proc/cpuinfo should show the flag, and dmesg | grep -i 'nx (execute disable)' confirms the kernel enabled it.
Inspect a program’s protections with checksec --file=/path/to/binary (or hardening-check from the devscripts package) — look for a stack canary, NX, and PIE (Position Independent Executable) all enabled.
When you compile your own software, build with -fstack-protector-strong, -D_FORTIFY_SOURCE=2, and -pie -fPIE so these protections are baked in.
Attach the sysctl output and a checksec report as hardening evidence on the asset, naming SI-16 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.