Tamper Resistance and Detection SR-9

Supply Chain Risk Management · High 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 SR-9 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, Supply Chain Risk Management 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

SR-9 (Tamper Resistance and Detection) asks you to run a tamper protection program for the system, component, or service. Tampering means someone secretly changing hardware, firmware, or software — in transit, in storage, or in place — to plant a weakness. The control wants you to make tampering harder to do and easier to notice. It is a High-baseline control, so it is reserved for systems where the stakes are highest.

What good looks like

Run a tamper protection program — a deliberate set of steps to resist tampering and to detect it if it happens.
Cover the whole life of hardware, firmware, and software: in transit, in storage, and while running.
Make tampering harder — sealed or locked hardware, controlled physical access, and signed firmware and packages.
Make tampering visible — file-integrity checks and package verification that flag anything that changed unexpectedly.
Investigate anything the checks flag — detection only helps if someone actually looks at the alerts.

Framework mapping

How to move it toward Implemented

Install a file-integrity tool such as AIDE (Advanced Intrusion Detection Environment): build a baseline with aide --init, then check for changes with aide --check on a schedule.
Verify that installed packages have not been altered — run dpkg --verify (Debian and Ubuntu) or rpm -Va (Red Hat family) and review anything that shows a changed file.
Lock down the physical and boot path where you can — enable Secure Boot, set a firmware or BIOS (Basic Input/Output System) password, and restrict who can physically reach the machine.
Attach the AIDE baseline report and a package-verification run as hardening evidence on the asset, naming SR-9 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.