Continuous is a frequency you choose

Ask what continuous monitoring means and most people describe a wall of live graphs. SP 800-53 Rev. 5 describes something smaller and more useful. The glossary defines continuous monitoring as “Maintaining ongoing awareness to support organizational risk decisions.” That’s the whole definition. It says nothing about seconds, streams or screens.

The CA-7 discussion spells out the part everyone skips. The terms “continuous” and “ongoing” “imply that organizations assess and monitor their controls and risks at a frequency sufficient to support risk-based decisions.” The next sentence matters just as much: “Different types of controls may require different monitoring frequencies.” Reachability of a core firewall and the quarterly review of its rule base are both continuous monitoring. They just run on different clocks, and the clocks are yours to set.

What CA-7 actually asks for

CA-7 opens with: “Develop a system-level continuous monitoring strategy and implement continuous monitoring in accordance with the organization-level continuous monitoring strategy.” The strategy then has seven parts:

  1. Metrics. The system-level measures you’ll track.
  2. Frequencies. Two sets: how often you monitor, and how often you assess whether controls work.
  3. Ongoing control assessments, run on that schedule.
  4. Ongoing monitoring of the metrics.
  5. Correlation and analysis of what assessments and monitoring produce.
  6. Response actions when the analysis finds something.
  7. Reporting security and privacy status to people you name, at a frequency you name.

Only one of the seven is the part a monitoring tool does on its own, the ongoing monitoring in item 4. The rest is decisions, analysis and people. A network team that shows an assessor a dashboard and calls it CA-7 has shown them one item out of seven.

PM-31 sits above your system strategy

The organization-level strategy CA-7 refers to is PM-31: “Develop an organization-wide continuous monitoring strategy.” It has the same shape as CA-7 (metrics, frequencies, analysis, response, reporting), one level up. PM controls are easy to miss when you work from a system baseline, because the family introduction says they “are not associated with the control baselines described in [SP 800-53B].” They won’t appear in your tailored list, but your system strategy still has to fit inside the organization’s. Before you pick a single frequency for network gear, find out what the organization-wide strategy already says about reporting cadence and risk tolerance.

Filling in the parameters for network gear

CA-7a and CA-7b are organization-defined parameters: the metrics, the monitoring frequencies and the assessment frequencies. The CA-7 discussion also points at monitoring requirements that live in other controls, among them CM-3f (reviewing configuration-controlled changes), CM-6d (monitoring changes to configuration settings) and SC-7a (monitoring communications at managed interfaces). For a network team, a first draft looks something like the worksheet below.

CA-7 worksheet · network devices (example values)
what you monitorfrequency you setevidencerelatedmanagement-plane reachabilityevery few minutesreachability log per deviceCA-7dconfiguration driftevery syncsnapshot diffs, attributedCM-3f, CM-6dunauthorized change reviewweeklyreconciled change listCM-3(7)rule-base hygienemonthly or quarterlyshadowed, redundant, broad rulesCM-7(1)effective access to critical segmentsafter each change, plus quarterlyeffective-access exportSC-7, AC-4privileged accounts on devicesat your AC-6(7) frequencyaccount list per deviceAC-6(7)status reportmonthlysummary to named rolesCA-7g
Every frequency here is an example an organization would choose and justify. None of them comes from NIST. What an assessor checks is that you set them, wrote down why, and kept to them.

The justification is the part that survives an assessment. “Every sync” for configuration drift is easy to defend when a single rule change can open a segment. “Quarterly” for a full rule-base review is easy to defend when drift is already watched between reviews. What doesn’t survive is a frequency nobody can explain, or one the team quietly stopped keeping. Our posts on change review under CM-3(7) and on checking deny by default cover two of those rows in detail.

Three kinds of monitoring, and which ones config data answers

CA-7(4) asks for risk monitoring built into the strategy, in three parts, and its discussion defines each one. Configuration data is strong on two of them and weak on the third.

CA-7(4) · what each kind of monitoring needs
compliancesettings match the standard, waivers tracked config data answers this
changewhat changed, where, when, by whom config data answers this
effectivenessdoes the measure actually reduce risk needs tests and traffic evidence
Compliance and change monitoring can be read from device state. Effectiveness is about whether the measure works, which needs testing and traffic evidence.

In NIST’s words, “Compliance monitoring verifies that required risk response measures are implemented,” and “Change monitoring identifies changes to organizational systems and environments of operation that may affect security and privacy risk.” Both are questions about state, which is exactly what configuration snapshots record. “Effectiveness monitoring determines the ongoing effectiveness of the implemented risk response measures.” A firewall rule that is present and correct can still fail to stop what it was meant to stop, and proving otherwise takes testing, traffic evidence or both.

Two more enhancements fit network work. CA-7(5), consistency analysis, exists because controls added over time can “fail to work together in a consistent or coordinated manner.” Its discussion gives a network example: “failing to consistently monitor all implemented network protocols (e.g., a dual stack of IPv4 and IPv6) may create unintended vulnerabilities.” Shadowed rules, and two sites whose rule bases disagree about the same segment, are consistency findings too. CA-7(6) asks you to “Ensure the accuracy, currency, and availability of monitoring results for the system” with automated mechanisms, which is the case for collecting device state by machine rather than by hand.

A dashboard is one item out of seven. The strategy is the other six.

Monitoring feeds the assessment, it doesn’t replace it

Good monitoring pays off at assessment time. CA-2 lets you reuse it: “To satisfy annual assessment requirements, organizations can use assessment results from the following sources,” and continuous monitoring is on that list. The same sentence adds a condition: results must be current, relevant and “obtained with the appropriate level of assessor independence.” For federal systems, CA-6 goes further: “Authorizing officials issue ongoing authorizations of systems based on evidence produced from implemented continuous monitoring programs.”

Independence is where teams overreach. CA-7(1) asks you to “Employ independent assessors or assessment teams to monitor the controls in the system on an ongoing basis,” and the independence discussion is blunt: assessors don’t “assess their own work.” Output from a tool the network team runs on its own network is evidence. It becomes part of an assessment when someone independent reviews it, not before.

Where SAMURAI fits, and where it stops

SAMURAI covers the monitoring rows that come from device state. It checks reachability of every device every two minutes, snapshots configuration on every sync and diffs it against the previous one, attributes each change to an admin, tracks compliance results with waivers, flags shadowed, redundant and overly broad rules, and exports all of it for the evidence file. That’s evidence for CA-7d ongoing monitoring and for the compliance and change parts of CA-7(4). The platform page shows how those pieces fit together. Before you write it into a strategy, know the limits:

  1. It doesn’t write the strategy. The metrics, the frequencies, the response actions and the reporting line are decisions for the organization, under PM-31 and CA-7.
  2. It reads configuration and state, not traffic or logs. Effectiveness monitoring and the monitoring half of SC-7a need other tools. For the logging side, see AU-9 and the logging configuration.
  3. It isn’t independent. Run by the network team, its findings are the team’s own evidence. CA-2(1) and CA-7(1) need someone else to assess.
  4. Snapshots are periodic. A change made and reverted between two syncs never appears in a diff. Set the sync interval as one of your CA-7b frequencies and say so in the strategy.

Write the frequencies down first, then point the tooling at them. An assessor will ask why you chose each number long before they ask what drew the graph.