Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
3.14.6OFFICIAL STATEMENT BELOWDERIVED REQUIREMENTPENDING NIST SME REVIEW

3.14.6 — Attack monitoring

3.14 System and Information Integrity · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

The system is watched for attack and its precursors — inbound and outbound traffic included. Detection presumes attention: sensors, logs, and alerts someone actually triages, with outbound monitoring catching the compromise the inbound tools missed.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: Monitoring systems and communications traffic to detect attacks is this practice's whole outcome on the OT network: passive sensors baseline normal industrial traffic and surface deviations, on segments where passive detection is often the only safeguard production tolerates.

What this does not claim: May partially address the requirement, for the OT slice only and only where OT assets sit inside the assessed boundary. The requirement covers organizational systems broadly — the IT estate's monitoring is separate work — and a passive sensor sees the network, not the host: engineering workstations and historians still need endpoint-level visibility that many OT environments cannot safely run, which is a gap to record, not assume away.

Practice-side activities
  • Deploy passive network monitoring on OT segments via span or tap, never inline without qualification
  • Baseline normal traffic and alert on deviation
  • Route alerts to people who can distinguish a process anomaly from an attack
Evidence this produces
  • Sensor coverage map against OT network segments
  • Alert records with triage outcomes
  • Baseline documentation and tuning history

Where this holds: Holds for OT segments inside the CUI boundary; the practice contributes nothing to monitoring of the IT estate, which this requirement equally covers.

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Contextual relationshipModerate confidence

Why: Monitoring coverage is measured against the asset inventory: 'monitor organizational systems' presumes a list of the systems, and the reconciled inventory this practice maintains is what makes monitoring gaps visible at all.

What this does not claim: The inventory monitors nothing. It informs where sensors, agents, and log sources must exist without detecting a single attack indicator; the monitoring capability itself — tooling, alerting, triage, ownership — is entirely separate work evaluated on its own evidence.

Practice-side activities
  • Reconcile EDR, log-source, and sensor coverage against the inventory on a cadence
  • Flag unmonitored assets as findings with owners
Evidence this produces
  • Coverage-gap report comparing inventory to monitored assets

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Decide what monitoring exists at the boundary and on hosts, and route it somewhere with an owner — an unwatched SIEM is storage, not monitoring.
  • Give outbound traffic equal billing: beaconing and exfiltration patterns are how established compromises actually surface.
  • Scale honestly: a small organization's version may be EDR alerts plus firewall logs with a daily review, documented as exactly that.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • A monitoring architecture description: sources, tools, owners
  • Alert triage records for a sampled period

Suggested owners, derived from the mapped practices and artifacts: OT engineer · IT leader. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

MATRIX · REVIEW QUARTERLYLogging and Monitoring Coverage Matrix
The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated