Safeguard
Compliance•

NIST 800-53 SI-4 System Monitoring: What to Show an Auditor

SI-4 asks you to monitor for attacks, unauthorized connections and misuse, analyze events and adjust as risk changes. Evidence and gaps.

Safeguard Security Team
5 min read

SI-4 is the monitoring control. It asks you to watch your systems for attacks and indicators of attack, detect unauthorized local, network and remote connections, identify unauthorized use, deploy monitoring in the right places, analyze what you see, adjust when risk changes, get a legal opinion on monitoring, and share monitoring information with defined recipients. NIST 800-53 binds US federal systems and, by contract, some others. For everyone else it is a reference that maps to the question every customer asks: how would you know?

What it asks

In summary, the statement requires you to:

  • Monitor to detect attacks and indicators of potential attacks against objectives you define.
  • Detect unauthorized local, network and remote connections.
  • Identify unauthorized use through techniques you choose.
  • Invoke internal monitoring or deploy devices, both strategically in the system and at ad hoc locations to track particular transactions.
  • Analyze detected events and anomalies.
  • Adjust the level of monitoring when risk changes.
  • Obtain legal opinion on your monitoring activities.
  • Provide defined monitoring information to defined personnel or roles, at a defined frequency.

What it means in practice

NIST describes external monitoring as observing events at the system's external interfaces and internal monitoring as observing events inside it. Tools named in the guidance include intrusion detection and prevention systems, malicious code protection, scanning tools, audit record monitoring software and network monitoring software.

The guidance also admits a tradeoff. Monitoring devices can add latency at key boundaries, so they are placed strategically: selected perimeter locations and near key servers that support critical applications, typically at managed interfaces. The same applies to cloud: you cannot log everything everywhere at the same depth, so decide where depth matters.

Two items catch people out. The first is adjusting monitoring when risk changes. A new vulnerability under active exploitation, or an incident, should raise the level of attention, and you should be able to show that it did. The second is the legal opinion. Monitoring employees and users carries privacy and employment law obligations that differ by jurisdiction, so get counsel's view and keep it.

SI-4 sits next to audit logging in the AU family. Logs are the raw material, and this control is about someone actually watching and analyzing them.

Evidence to collect

  • The monitoring objectives and the techniques chosen for each.
  • A diagram or list of where monitoring is deployed, including perimeter, key servers and cloud accounts.
  • Alert rules and the detections they cover.
  • Records of alerts triaged, with timestamps, analysis and outcome.
  • An example of monitoring raised after a risk change, such as an exploited CVE advisory.
  • The legal opinion or review note on monitoring.
  • Evidence of who receives monitoring reports and how often.

Common gaps

  • Logs collected and stored, but no one reviews them.
  • Coverage for production but not for build systems, identity providers or admin consoles.
  • No record that anyone analyzed an event, only that alerts fired.
  • Monitoring levels fixed, with no adjustment path.
  • Monitoring of staff with no legal review.
  • Monitoring data readable by anyone, though it can hold sensitive information.

How to implement it

List what you most need to detect. Credential misuse, unexpected outbound connections, privilege changes and malware alerts are a reasonable start for a small team.

Map each objective to a data source and an alert. Write the response in one line next to it. Keep the list short enough that every alert has an owner.

Send the alerts to a place with on call coverage. Triage outcomes get recorded in a ticket, including the benign ones, because those show analysis happened.

Define what raises monitoring. For example, a critical advisory for a component you run triggers a targeted hunt and a log of what you looked for.

The enhancements show the ladder: system wide intrusion detection (SI-4.1), automated tools for real time analysis (SI-4.2), tool integration (SI-4.3), inbound and outbound communications traffic (SI-4.4), system generated alerts (SI-4.5), restricting non-privileged users (SI-4.6), automated response to suspicious events (SI-4.7) and protection of monitoring information (SI-4.8). Protecting the monitoring data is the cheapest one to adopt.

Click through it at your own pace, or open it full screen.

Quick check

Is collecting logs the same as meeting SI-4?

No. The control requires analysis of detected events and anomalies, plus adjusting monitoring as risk changes. Collection is only the input.

Why does SI-4 mention a legal opinion?

Monitoring can touch employee and user privacy. The control asks you to get legal advice so your monitoring is lawful where you operate.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.