Trackr.Live The landing site for Trackr Services
§ Trackr.Live

SI — System and Information Integrity

System and Information Integrity is where the SOC actually lives. AC and IA decide who gets in, AU records what they did, but SI is the family that asks the operational questions you answer on shift: is this box patched, is something malicious running on it, and would we even see it if it were. The family covers flaw remediation, malicious code protection, system monitoring, integrity verification, and a long tail of newer data-integrity controls. Most of the day-to-day defensive work in a federal environment maps here, which is also why SI is where an assessor finds the gap between the SSP narrative and the actual posture fastest.

Schematic of a system baseline drifting over time: a clean reference state on the left, a live system on the right slowly diverging, with sensors watching the gap and a remediation path pulling it back.

SI is a control catalog family in SP 800-53, not a phase of the RMF. The framework is the SP 800-37 process: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. The SI controls in your system got pulled in at Select from your 800-53B baseline, they get documented and stood up at Implement, and they get graded at Assess. Whatever fails lands in the POA&M and rides into continuous monitoring. The wrinkle with SI is that several of its controls (SI-2, SI-3, SI-4) are continuous-monitoring controls by nature, so the line between “implemented” and “monitored” is blurrier here than in most families. A patch SLA isn’t a thing you implement once; it’s a thing you either meet every month or quietly miss every month.

What’s in the family

In Rev 5 the SI family spans SI-1 through SI-23, and that range is not a continuous run of live controls. SI-9 (Information Input Restrictions) was withdrawn in Rev 5 and folded into AC-2, AC-3, AC-5, and AC-6; if your SSP still cites SI-9 by number, that’s a Rev 4 artifact someone forgot to retire, the same way a stale AC-15 reference gives away an un-updated Access Control narrative. Rev 5 also added a cluster of data-integrity and privacy controls on the back end (SI-17 through SI-23) that the Rev 4 roster never had.

The ones that carry the operational weight:

  • SI-2, Flaw Remediation. Patching, with a clock. This is the control most ATOs quietly fail. The SSP states a remediation SLA by severity (something like 30 days for high, 90 for moderate, often tighter under FedRAMP: 30/90/180 for high/moderate/low from the date the scan flags it). Then legacy systems slip, the air-gapped enclave can’t pull updates on schedule, and the POA&M fills with overdue items. SI-2 doesn’t live alone; it’s the downstream consumer of RA-5 scan output and it’s gated by CM-3 change control, because a patch is a change and the change board can be the thing that blows your SLA.
  • SI-3, Malicious Code Protection. AV and EDR. The catalog still reads like 2010 signature antivirus, but in practice this is your EDR agent (Defender, CrowdStrike, whatever the contract bought) and its definition currency, console coverage, and response actions. SI-3 and SI-4 overlap heavily and most shops implement them with the same tool, which is fine until an assessor asks you to draw the line between them.
  • SI-4, System Monitoring. IDS, IPS, EDR, the SIEM feed. This is detection: did we see it. It is not accountability, which is AU’s job: can we prove who did it. The two get conflated constantly because the same logs feed both, but they answer different questions and an assessor will press on the distinction. SI-4 is also where the most control enhancements pile up at Moderate and High, because “monitor the system” expands into individual requirements for inbound/outbound traffic, unauthorized connections, and alerting.
  • SI-5, Security Alerts, Advisories, and Directives. Subscribing to and acting on CISA advisories, and in DoD, the IAVA/IAVM feed. The control is small; the operational reality is a queue someone has to actually triage, with a compliance deadline attached to each directive.
  • SI-7, Software, Firmware, and Information Integrity. File integrity monitoring, secure boot, signature verification. More on the FIM noise problem below.
  • SI-10, Information Input Validation and SI-11, Error Handling. App-layer controls. SI-10 is the catalog’s home for the thing that stops injection attacks, and it ties straight into SA-11 developer testing and SC-5 denial-of-service protection. SI-11 is making errors fail safe and quiet, not dumping a stack trace with a connection string in it to the user.
  • SI-12, Information Management and Retention. How long you keep data and how you dispose of it. This overlaps AU-11 (audit record retention) and is the SI control most likely to wear a privacy hat, since the same retention decisions show up in the PT family.
  • SI-16, Memory Protection. DEP, ASLR, NX bit, stack canaries. This is specifically about stopping unauthorized code execution in memory, the OS-level mitigations against injection and overflow exploitation. It is not a generic “protect memory from access” statement, and an SSP that describes it that way has paraphrased the title instead of the control.

The back half of the range is real but lighter for most systems. SI-6 verifies that security and privacy functions actually work; SI-8 is spam protection; SI-13 is predictable failure prevention. SI-14 is Non-Persistence (deliberately refreshing components or services from a known-good state on a schedule, so an attacker’s foothold gets wiped on the next cycle and dwell time shrinks; it is not about avoiding storage in volatile memory). SI-17 through SI-23 are the Rev 5 additions: fail-safe procedures, PII quality operations, de-identification, tainting, information refresh, information diversity, and information fragmentation. Most Moderate systems won’t carry the SI-19-through-SI-23 cluster unless an overlay or a privacy requirement drags it in.

Baselines and where the controls come from

The baselines moved out of the catalog in Rev 5. SP 800-53B now holds the Low/Moderate/High allocations you tailor against. FIPS 199 sets your impact level, FIPS 200 sets the security floor, and 800-53B turns that into a starting SI control set. SI-2, SI-3, SI-4, and SI-5 show up early (they’re in the Low baseline), and the SI-4 enhancements and SI-7 land as you climb to Moderate and High. National-security systems use CNSSI 1253 instead; FedRAMP and DoD layer their own overlays on top, and the DoD overlay is where the IAVA cadence under SI-5 gets its teeth.

Deeper: why SI-2 is a baseline control but your SLA is an org decision.
The 800-53B baseline tells you SI-2 is in scope. It does not tell you that high-severity findings get patched in 30 days. That number comes from your organization-defined parameter, your overlay, or your AO, and it is the thing an assessor measures you against. The catalog control text is full of these ODP brackets (“within [Assignment: organization-defined time period]”), and SI-2 is the canonical case: the control is satisfied or not based entirely on a timeline you wrote into your own SSP. Write 15 days because it sounds rigorous and you have just handed the assessor a stricter yardstick to fail you against. Write 90 days for criticals and the AO may reject the SSP before it reaches assessment. The defensible number is the one that matches your overlay’s floor and your team’s actual capacity to ship patches through CM-3 change control, not the one that reads best on paper.

Control Typical first live at What an assessor actually checks
SI-2 Low Pulls the latest authenticated scan, compares high/critical findings against the SSP’s patch SLA dates and the POA&M. Overdue findings with no POA&M entry = finding.
SI-3 Low EDR/AV definition currency and console coverage against the asset inventory. Hosts with no agent reporting in are the gap.
SI-4 Low Sensor placement, agent coverage holes, and whether alerts actually reach an analyst (not just a dashboard nobody watches).
SI-4(2)/(4) Moderate Automated analysis and inbound/outbound traffic monitoring configured, not just licensed.
SI-5 Low A real subscription to CISA/IAVM feeds and evidence that directives get triaged on a clock.
SI-7 Moderate FIM/integrity tooling deployed, a defined baseline, and someone actually reviewing the drift alerts.
SI-12 Low Retention periods match policy and disposal actually happens (overlaps AU-11).
SI-16 Moderate DEP/ASLR/NX enabled at the OS level, verified in config, not asserted in prose.

Treat the “first live at” column as directional. Your overlay moves things, and a FedRAMP or DoD baseline pulls SI enhancements above the bare 800-53B set.

Where it actually goes wrong

SI-2 patch-SLA slip. The SSP says high-severity findings get remediated in 30 days. The latest scan says CVE-2024-whatever has been open on three RHEL 8 hosts for 71 days. There’s no POA&M entry, because the scan only started flagging it after the last assessment, and nobody wired the new findings into the tracker. This is the single most common SI finding, and it’s mechanical to catch: an assessor samples the most recent authenticated scan, sorts by severity, and walks the high findings against your SLA and your POA&M. The honest defense isn’t “we patch fast”; it’s a POA&M entry with a real milestone date for the systems that genuinely can’t meet the SLA (the legacy appliance whose vendor ships firmware twice a year, the air-gapped enclave that patches on a quarterly media drop). An overdue finding with a POA&M is a managed risk. An overdue finding with nothing is a hole someone missed.

SI-3 / SI-4 agent coverage holes. The console says 98% coverage. The asset inventory has 1,400 hosts. The EDR has 1,340 agents reporting. That 60-host delta is the whole game, and it’s never random: it’s the RHEL boxes where the agent won’t stay running, the network appliances that don’t take an agent at all, the build server somebody excluded to stop the agent from quarantining CI artifacts and never re-included. Coverage gaps don’t show up in the SSP narrative because the narrative describes the intended state. Reconcile the EDR console against the authoritative asset list and the holes fall out. Assuming the agent actually checked in, which on the appliance-class hosts I would not bet on.

SI-7 FIM noise. Here’s where I’ll plant a flag: on general-purpose servers, file integrity monitoring is mostly noise theater, and most of the real detection value in the SI family comes from SI-4, not SI-7. The premise of FIM (alert when a watched file changes) collides with the reality that a patched, configuration-managed Linux host changes files constantly and legitimately. Every dnf transaction, every Ansible run, every log rotation trips it. Tune the watch list down to what matters (boot loader, key binaries, critical config) and you get something useful. Leave it at the default “watch /etc and /usr/bin” and you get a firehose nobody reads, which is functionally no control at all, except now there’s a dashboard that makes it look covered. FIM earns its keep on locked-down, rarely-changing systems (a bastion, a hardened appliance image). On a busy app server it’s a check-the-box exercise more often than a detection.

SI-4 vs AU confusion in the SSP. Writers smear these together because the SIEM ingests the same logs for both. But SI-4 is “we detected the anomalous connection” and AU is “we can attribute the action to a named principal and prove it after the fact.” When the SSP describes SI-4 purely as log collection and retention, it has written an AU narrative under an SI heading, and a careful assessor reads that as a control the author didn’t understand. Keep detection (SI-4) and accountability (AU-6, AU-12) in their own lanes.

Artifacts

SI lands in the same three places everything else does. The SSP carries the control narrative, in specifics: this is the EDR product, this is the patch SLA, this is the FIM baseline and who reviews it. The SAR is the assessor’s verdict. The POA&M holds the overdue patches and the coverage gaps with remediation dates attached. The fastest way to fail an SI assessment is an SSP that paraphrases the catalog (“the organization remediates flaws in a timely manner”) instead of stating the actual timeline and showing the scan-to-POA&M pipeline that enforces it. The assessor has read the catalog. They want the timeline, the tool, and the evidence that the loop closes.

Sources

Adjacent material on this site