SI-16 asks you to implement controls that protect system memory from unauthorized code execution. NIST names two: data execution prevention, and address space layout randomization.
800-53 binds federal systems and contractors. For others it is a reference for hardening answers on questionnaires.
What it means in practice
Attackers try to run code from memory regions that should hold only data, or from locations that are off limits. Data execution prevention marks those regions non-executable. NIST adds that it can be hardware enforced or software enforced, and hardware enforcement is the stronger form. Address space layout randomization makes memory locations unpredictable.
Modern operating systems enable both by default. The work is proving it, and covering the software you build yourself.
Evidence to collect
- Operating system version and settings showing DEP or NX and ASLR are enabled.
- Compiler and linker flags for your own binaries, such as position independent executables.
- A hardening scan or benchmark report across servers.
- Exceptions with reasons.
Common gaps
Old operating systems and appliances without these protections. Legacy binaries built without the flags. Memory unsafe components with known vulnerabilities that keep the protections from mattering.
That last gap is where dependencies matter. A memory corruption bug in a library is the very thing these protections try to blunt. The vulnerability management demo shows how to prioritize those fixes.
Click through it at your own pace, or open it full screen.
How to implement it
Keep hosts on supported systems, build with hardening flags, and export a configuration report on a schedule.
Quick check
Which form of DEP is stronger?
Hardware enforced, according to NIST.
