NIST SP 800-137 defines Information Security Continuous Monitoring (ISCM) as "maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions." In practice, most federal programs treat Step 6 of the RMF as a documentation exercise — quarterly reports produced by manually pulling data from multiple sources, assembling it in a spreadsheet, and delivering it to the AO.
Manual continuous monitoring is not monitoring. It is periodic snapshot reporting. Actual continuous monitoring requires automated data collection, real-time alert thresholds, and a ConMon dashboard that reflects system security posture at any given moment — not as of last quarter.
What Continuous Monitoring Must Cover
NIST SP 800-137 and OMB Memoranda on FISMA reporting define the minimum scope of an ISCM program. For a cloud-based federal system, this translates to:
Configuration compliance. Are system components running configurations that satisfy the NIST 800-53 baselines in the SSP? This is evaluated through AWS Config rules mapped to specific controls, Checkov/OPA pre-deploy scanning results, and STIG compliance scores for container workloads.
Vulnerability management. Are known CVEs in deployed software and infrastructure being tracked, prioritized, and remediated within required timelines? FISMA requires vulnerabilities rated Critical or High to be remediated within 30 days; Moderate within 90 days.
Security events and anomalies. Is unauthorized behavior or threat activity being detected? GuardDuty findings, CloudTrail anomalies, and Security Hub aggregated alerts.
System availability and performance. Is the system meeting defined availability requirements? CloudWatch metrics against uptime SLAs.
Access control. Are privileged accounts and access rights reviewed on schedule? IAM Access Analyzer findings, unused access detection, credential age monitoring.
Architecture: Automated ConMon Pipeline
Rutagon builds ConMon pipelines that pull from AWS-native security services, normalize findings into a common schema, and deliver them to a ConMon dashboard and alerting system — without manual data collection.
┌──────────────────────────────────────────────────────┐
│ Data Sources │
│ AWS Config Rules → Security Hub │
│ GuardDuty Findings → Security Hub │
│ Inspector (container/EC2 CVEs) → Security Hub │
│ CloudTrail (API audit events) → Athena │
│ Checkov/OPA Results (pre-deploy) → S3 │
└──────────────┬───────────────────────────────────────┘
│ EventBridge
▼
┌──────────────────────────────────────────────────────┐
│ Normalization Lambda │
│ Maps findings to NIST 800-53 controls │
│ Calculates control compliance status │
│ Writes normalized findings to DynamoDB │
└──────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ ConMon Dashboard (QuickSight or custom React) │
│ Control family compliance percentages │
│ Open findings by severity and age │
│ POA&M status tracking │
│ Trend lines (30/60/90-day) │
└──────────────────────────────────────────────────────┘Mapping Findings to NIST 800-53 Controls
The normalization step — mapping AWS security findings to specific NIST 800-53 control IDs — is what transforms raw security events into compliance evidence. Rutagon's normalization Lambda maintains a mapping table:
const FINDING_TO_CONTROL_MAP: Record<string, string[]> = {
// Config rules → controls
'encrypted-volumes': ['SC-28', 'SC-28(1)'],
'vpc-flow-logs-enabled': ['AU-2', 'AU-12', 'SI-4'],
'cloudtrail-enabled': ['AU-2', 'AU-3', 'AU-12'],
'root-account-mfa-enabled': ['IA-2', 'IA-2(1)'],
'iam-password-policy': ['IA-5', 'IA-5(1)'],
's3-bucket-public-read-prohibited': ['AC-3', 'AC-6', 'SC-7'],
// GuardDuty finding types → controls
'UnauthorizedAccess:IAMUser/MaliciousIPCaller': ['SI-3', 'SI-4'],
'Recon:IAMUser/UserPermissions': ['SI-4', 'AC-6'],
'CryptoCurrency:EC2/BitcoinTool.B': ['SI-3', 'SC-7'],
// Inspector CVEs → controls
'CVE': ['SI-2', 'RA-5'],
};This mapping is the intellectual core of the ConMon pipeline — without it, security findings are unrelated to the control compliance posture that AOs and ISSOs need to assess authorization status.
POA&M Integration
A Plan of Action and Milestones (POA&M) documents known control deficiencies and the remediation timeline. In a manual ConMon process, POA&Ms are managed in spreadsheets that quickly go stale.
Rutagon's ConMon pipeline creates POA&M entries automatically when findings exceed defined age thresholds:
interface POAMEntry {
poamId: string;
findingId: string;
controlId: string;
weakness: string;
severity: 'Critical' | 'High' | 'Moderate' | 'Low';
discoveryDate: string;
scheduledCompletionDate: string; // 30d/90d/180d based on severity
milestones: POAMMilestone[];
status: 'Open' | 'In-Progress' | 'Completed' | 'Risk-Accepted';
responsibleRole: string;
}
// Auto-generate POA&M from aging finding
async function escalateToPOAM(finding: NormalizedFinding): Promise<POAMEntry> {
const completionDays = {
'Critical': 30,
'High': 30,
'Moderate': 90,
'Low': 180,
}[finding.severity];
const completionDate = addDays(new Date(), completionDays);
return {
poamId: generatePOAMId(),
findingId: finding.findingId,
controlId: finding.controlIds[0],
weakness: finding.description,
severity: finding.severity,
discoveryDate: finding.firstObservedAt,
scheduledCompletionDate: completionDate.toISOString(),
milestones: generateDefaultMilestones(finding, completionDate),
status: 'Open',
responsibleRole: 'System Owner',
};
}The ConMon dashboard surfaces POA&M entries approaching their scheduled completion dates, aging findings that have not been remediated, and control families with declining compliance trends — giving ISSOs actionable information rather than retrospective reports.
For CMMC-specific evidence collection using similar patterns, see How We Automate CMMC Evidence Collection. For the broader compliance reporting architecture, see Automated Compliance Reporting for Gov Systems.
AO Reporting
The ConMon pipeline produces the monthly and quarterly reports that AOs and program offices need without manual data assembly. Reports are generated from the same normalized finding data that drives the real-time dashboard — ensuring the report reflects actual system state, not manually compiled summaries.
Quarterly reports include: control compliance percentage by family, open finding counts by severity, POA&M status summary, significant security events and resolutions, and system change summary. These are generated as PDFs from the DynamoDB finding data on a schedule.
Working With Rutagon
Rutagon builds automated ConMon pipelines for federal programs — real-time compliance visibility, automated POA&M management, and AO-ready quarterly reports generated without manual data assembly.
Frequently Asked Questions
What is NIST RMF Step 6 continuous monitoring?
NIST RMF Step 6 (Monitor) requires maintaining ongoing awareness of the system's security posture after ATO is granted. This includes monitoring security controls for effectiveness, tracking security-relevant changes, conducting ongoing assessments, reporting findings to the AO, and maintaining the ATO through a continuous authorization process. Most programs satisfy this through a formal ISCM program that defines monitoring frequencies, data sources, reporting cadence, and thresholds that trigger ATO reconsideration.
What is the difference between continuous monitoring and periodic security assessments?
Continuous monitoring is real-time or near-real-time automated data collection on system security posture — control compliance, vulnerability status, security events. Periodic security assessments are point-in-time evaluations conducted on a defined schedule (typically annually) by an assessor. Both are required under RMF: Step 4 (Assess) produces the initial security assessment; Step 6 (Monitor) maintains ongoing visibility between assessments. Automated continuous monitoring generates the evidence that satisfies between-assessment requirements and can detect significant changes that warrant reassessment.
What AWS services support FISMA continuous monitoring?
AWS Security Hub is the central aggregation point — it collects findings from Config (configuration compliance), GuardDuty (threat detection), Inspector (vulnerability scanning), Macie (data classification), and IAM Access Analyzer (access findings). CloudTrail provides the API audit trail. EventBridge routes findings to processing functions. QuickSight or a custom React dashboard surfaces ConMon metrics. All services are available in AWS GovCloud and support the FedRAMP High baselines required for IL4/IL5 systems.
How do you handle POA&M management in an automated ConMon pipeline?
POA&M entries are created automatically when findings exceed defined age thresholds (findings not remediated within the required window become POA&M entries with completion dates based on severity). The ConMon dashboard tracks POA&M status, approaching completion dates, and aging open items. POA&M data is exported in OSCAL format for integration with agency compliance management systems. Automated escalation alerts notify responsible parties when POA&M milestones are approaching or overdue.
How often should continuous monitoring data be reviewed?
Minimum review frequencies under NIST SP 800-137 vary by control family and organization risk tolerance. Critical security events (GuardDuty Critical findings, S3 data exposure) should trigger immediate alerts and same-day review. Configuration compliance (Config rules) and vulnerability findings should be reviewed weekly by the ISSO. Control family compliance trends and POA&M status should be reviewed monthly. AO-level risk posture reports are typically quarterly. Automated alerting handles the high-frequency items; human review focuses on trends and significant findings.