Continuous Monitoring Under RMF

Achieving an Authority to Operate (ATO) under the Risk Management Framework (RMF) is a monumental milestone for any defense contractor or federal agency. It represents months of engineering, documentation, and rigorous assessment. However, the ATO is not the finish line; it is merely the starting line for operations.

An ATO is a snapshot in time. It declares that the system was secure on the day the Authorizing Official (AO) signed the paperwork. But in the modern threat landscape, a system that is secure on Tuesday can become highly vulnerable by Wednesday due to a new zero-day exploit, a misconfigured firewall rule, or a lapsed patch.

To ensure the system remains secure throughout its operational lifecycle, RMF mandates Step 6: Monitor, commonly referred to as Continuous Monitoring (ConMon). ConMon is the ongoing process of observing, analyzing, and reporting on the security posture of an information system. It is the mechanism through which the AO maintains ongoing visibility into the risk posture of the system they have authorized.

If a contractor fails to execute a robust ConMon program, the system's risk profile will inevitably degrade. When this happens, the AO has the authority to revoke the ATO, effectively shutting down the system and halting the mission. This guide details how to build and execute a defensible Continuous Monitoring program that keeps the ATO alive, the system secure, and the government's trust intact.

A successful ConMon program is not a passive activity; it requires active, daily engagement from the Information System Security Manager (ISSM), system administrators, and security engineers. The program is built on four core pillars.

1. Automated Vulnerability Scanning

You cannot secure what you cannot see. Continuous vulnerability scanning is the heartbeat of ConMon.

The Tools: In DoD environments, the Assured Compliance Assessment Solution (ACAS), powered by Tenable Nessus, is the mandated scanning tool for infrastructure-level vulnerabilities. For web application vulnerabilities, tools like Fortify WebInspect or OWASP ZAP are used. For code-level vulnerabilities in custom software, Static Application Security Testing (SAST) tools like Fortify SCA or Checkmarx are employed.

The Frequency: Scanning must be frequent and comprehensive. At a minimum, authenticated credentialed scans should be run weekly across all assets (servers, workstations, network devices, databases) within the authorization boundary. Credentialed scans—where the scanner logs into the target system with administrative credentials—are far more thorough than unauthenticated scans and are required by DoD policy.

The Output and Triage: Scans generate massive amounts of data. A single weekly scan of a medium-sized environment can produce thousands of findings. The ConMon team must have a rigorous triage process: filter out false positives, group related findings, and prioritize the true vulnerabilities based on their Common Vulnerability Scoring System (CVSS) scores and the specific context of the system (e.g., is the vulnerable service exposed to the internet, or is it on an internal, isolated network?).

2. Configuration Management (CM)

A system's security posture is heavily dependent on its configuration. A single unauthorized change—such as opening a new port on a firewall, adding a user to the Domain Admins group, or disabling multi-factor authentication for a single account—can invalidate the ATO.

The Secure Baseline: The system must be maintained against a documented, approved secure baseline, typically the Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs). The baseline defines the exact configuration of every component in the system.

The Change Control Board (CCB): Every proposed change to the system architecture, hardware, or software must be reviewed by a Configuration Control Board before implementation. The ISSM must sit on the CCB to evaluate the security impact of the change. Changes that introduce new risk must be assessed and, if significant enough, may require the AO's approval before implementation.

Automated Compliance Checking: ConMon involves continuously verifying that the system has not drifted from its secure baseline. Tools like Microsoft Endpoint Configuration Manager (MECM), Ansible, or specialized STIG compliance scanners are used to verify STIG compliance automatically and flag any configuration drift for immediate remediation.

3. Log Aggregation and Audit Review

Vulnerability scanning tells you what could happen; log review tells you what is happening.

The SIEM: All critical system logs must be forwarded to a centralized Security Information and Event Management (SIEM) system. This includes firewall traffic logs, Active Directory authentication events (successful and failed logins), antivirus/EDR alerts, VPN connection logs, privileged account activity, and database access logs.

Active Review: Logs cannot simply be stored for compliance purposes; they must be actively monitored. The ConMon team must configure alerts for anomalous behavior, such as multiple failed login attempts on a privileged account (potential brute force), access to CUI repositories outside of normal business hours, unexpected outbound traffic to unusual IP addresses (potential data exfiltration), or the creation of new administrative accounts.

Audit Artifacts: The ISSM must generate and retain weekly or monthly audit review reports as evidence for the AO that the system is being actively monitored. These reports should summarize the key security events reviewed, the alerts triggered, and the actions taken in response.

4. POA&M Management

The Plan of Action and Milestones (POA&M) is the living document that tracks all known vulnerabilities and non-compliant controls within the system. It is the primary tool the AO uses to gauge the health of the system.

The Vulnerability Lifecycle: When a new vulnerability is discovered (via an ACAS scan or a STIG check) and cannot be patched immediately, it must be added to the POA&M within a defined timeframe (typically within 72 hours of discovery for critical findings). The POA&M entry must include the vulnerability description, the affected asset, the risk level, the planned remediation action, the responsible engineer, and the target completion date.

Remediation Tracking: The ConMon team assigns the vulnerability to an engineer and tracks the progress against the milestone date. When the vulnerability is remediated, the engineer provides evidence (e.g., a new scan showing the finding is resolved), and the ISSM closes the POA&M item.

AO Visibility: A POA&M that is constantly growing with new findings, or where milestones are repeatedly missed, signals a failing ConMon program. The AO will lose confidence in the team and may impose additional oversight or revoke the ATO. A healthy POA&M shows a steady flow of new items being opened and closed, demonstrating active management.

To prevent ConMon from becoming an overwhelming burden, contractors must establish a predictable operational rhythm with clearly defined tasks at each cadence.

In complex federal IT environments, manual Continuous Monitoring is impossible. A system with 500 servers will generate thousands of vulnerabilities and millions of log events every week. Contractors must leverage automation to survive ConMon at scale.

Automated Patching: Routine OS and application patching should be automated using tools like Windows Server Update Services (WSUS) or Microsoft Endpoint Configuration Manager (MECM). Automated patching reduces the manual workload on system administrators and dramatically shrinks the vulnerability window between patch release and deployment.

Compliance as Code: Use automated scripts (e.g., Ansible playbooks, PowerShell DSC) to continuously enforce STIG configurations. When a server is deployed, the playbook automatically applies the STIG settings. If a setting drifts from the baseline, the playbook automatically remediates it. This eliminates the manual STIG application process and prevents configuration drift from ever becoming a finding.

Automated Reporting: Modern GRC tools (like eMASS) can ingest ACAS scan results directly via API, automatically updating the POA&M and generating the compliance dashboards required by the AO. This eliminates the hours of manual data entry that plague traditional ConMon programs.

During the lifecycle of an ATO, the system will inevitably require significant changes—a major software upgrade, a migration to a new cloud environment, the addition of a new user population, or the integration of a new third-party service.

Under RMF, a "significant change" can invalidate the current ATO. The ConMon program must identify these changes early via the CCB. If a change is deemed significant, the ISSM must notify the AO. The AO will determine if the change requires a partial or full re-assessment of the system before the change can be implemented in production.

Failing to report a significant change to the AO is a direct violation of the ATO conditions and can result in immediate ATO revocation. Contractors must train their engineering teams to always consult the ISSM before making any changes to the system architecture, even seemingly minor ones.

An ATO is a privilege, not a right. The government grants that privilege based on the trust that the contractor will maintain the security posture of the system throughout its operational lifecycle.

Continuous Monitoring is the mechanism for maintaining that trust. By establishing a rigorous rhythm of automated vulnerability scanning, strict configuration management, active log review, and disciplined POA&M remediation, defense contractors can ensure their systems remain secure, their ATOs remain valid, and their federal customers remain protected against an ever-evolving threat landscape.

The contractors who excel at ConMon are not just compliance-focused; they are genuinely mission-focused. They understand that a compromised federal system is not just a contract liability—it is a national security failure.

[1] NIST Special Publication 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. https://csrc.nist.gov/publications/detail/sp/800-137/final [2] Defense Information Systems Agency (DISA). Assured Compliance Assessment Solution (ACAS). https://www.disa.mil/

A mature ConMon program does not operate in isolation. It is connected to the broader threat intelligence ecosystem, allowing the team to proactively defend against known, active threats rather than simply reacting to vulnerabilities after they are exploited.

CISA Alerts and Advisories: The Cybersecurity and Infrastructure Security Agency (CISA) publishes regular alerts, advisories, and Known Exploited Vulnerabilities (KEV) catalog updates. The KEV catalog is particularly important: it lists vulnerabilities that have been actively exploited in the wild and carries a mandatory remediation deadline for federal agencies. Defense contractors should treat the KEV catalog as a priority remediation queue, addressing listed vulnerabilities before their standard patching cycle.

US-CERT and DIBNet: The DoD Cyber Crime Center (DC3) and the DIBNet portal provide threat intelligence specifically tailored to the Defense Industrial Base (DIB). Contractors who are registered on DIBNet receive classified and unclassified threat indicators that can be used to tune SIEM detection rules and prioritize vulnerability remediation.

Information Sharing and Analysis Centers (ISACs): The Defense Industrial Base ISAC (DIB-ISAC) allows member companies to share anonymized threat intelligence with each other. If a peer company in the defense sector is being targeted by a specific threat actor using a specific technique, the DIB-ISAC can distribute that intelligence so other members can proactively defend against the same attack.

Threat-Informed Defense: The most advanced ConMon programs use the MITRE ATT&CK framework to map known adversary tactics, techniques, and procedures (TTPs) to their detection capabilities. By analyzing which ATT&CK techniques are most commonly used against the DIB, the ConMon team can identify gaps in their detection coverage and prioritize investments in new monitoring capabilities.

The AO is the senior official who accepted the risk of operating the system and signed the ATO. They need regular, accurate visibility into the system's security posture to fulfill their ongoing risk management responsibilities.

Monthly ConMon Reports: The ISSM should provide the AO with a monthly ConMon status report. This report should include a summary of vulnerability scan results (total findings by severity, trend over time), POA&M status (items opened, items closed, items overdue), significant security events from the SIEM, any significant changes to the system, and any new or emerging risks.

The AO Dashboard: Modern GRC tools (such as eMASS or Xacta) can provide the AO with a real-time dashboard showing the system's security posture. This eliminates the need for monthly report generation and gives the AO on-demand visibility. Contractors who invest in these tools demonstrate a level of transparency and professionalism that builds lasting trust with the government customer.

Escalation Triggers: The ISSM must have clear escalation procedures for notifying the AO immediately—outside of the normal monthly reporting cycle—when specific events occur. These include: discovery of a critical vulnerability with active exploitation in the wild, a confirmed security incident, a significant unauthorized change to the system, or a POA&M item that will miss its milestone by more than 30 days.

The rise of cloud-based federal IT systems has introduced new dimensions to the ConMon challenge. Traditional on-premises ConMon tools and processes do not translate directly to cloud environments.

Shared Responsibility Model: In a cloud environment, security responsibilities are divided between the Cloud Service Provider (CSP) and the contractor. The CSP is responsible for the security of the cloud (the physical infrastructure, the hypervisor, the network). The contractor is responsible for the security in the cloud (the operating systems, the applications, the data, the access controls). The ConMon program must clearly delineate these responsibilities and ensure that both layers are being monitored.

Cloud-Native Security Tools: Cloud providers offer native security monitoring tools that integrate directly with the cloud environment. For AWS GovCloud, this includes AWS Security Hub, AWS GuardDuty, and AWS Config. For Azure Government, this includes Microsoft Defender for Cloud and Microsoft Sentinel. These tools provide continuous compliance monitoring, threat detection, and automated remediation capabilities that are far more effective in cloud environments than traditional on-premises scanning tools.

API-Driven Compliance: Cloud environments are defined by code (Infrastructure as Code, or IaC). This means compliance can also be enforced by code. Tools like AWS Config Rules or Azure Policy can automatically detect and remediate configuration drift in real time—for example, automatically re-enabling encryption on a storage bucket if it is accidentally disabled. This "compliance as code" approach provides a level of continuous enforcement that is impossible to achieve manually.

For contractors who are new to federal IT and are building a ConMon program for the first time, the following phased approach provides a practical roadmap.

Phase 1 — Establish the Baseline (Months 1–2): Deploy the vulnerability scanning infrastructure (ACAS/Nessus). Run the first credentialed scan across all assets in the authorization boundary. Triage the results and establish the initial POA&M. Identify and configure the log sources that will feed the SIEM.

Phase 2 — Automate the Rhythm (Months 3–4): Schedule automated weekly vulnerability scans. Configure SIEM alerting rules for the most critical threat scenarios. Establish the weekly and monthly ConMon task calendar. Assign ownership of each task to a specific team member.

Phase 3 — Integrate and Report (Months 5–6): Connect the scanning tools to the GRC platform (eMASS) to automate POA&M updates. Develop the monthly ConMon report template. Brief the AO on the ConMon program and establish the reporting cadence. Conduct the first tabletop exercise to test the incident response procedures.

Phase 4 — Mature and Optimize (Ongoing): Integrate threat intelligence feeds. Implement automated STIG compliance checking. Develop metrics dashboards for the AO. Continuously refine detection rules based on new threat intelligence and lessons learned from security events.

An ATO is a privilege, not a right. The government grants that privilege based on the trust that the contractor will maintain the security posture of the system throughout its operational lifecycle.

Continuous Monitoring is the mechanism for maintaining that trust. By establishing a rigorous rhythm of automated vulnerability scanning, strict configuration management, active log review, disciplined POA&M remediation, and proactive threat intelligence integration, defense contractors can ensure their systems remain secure, their ATOs remain valid, and their federal customers remain protected against an ever-evolving threat landscape.

The contractors who excel at ConMon are not just compliance-focused; they are genuinely mission-focused. They understand that a compromised federal system is not just a contract liability—it is a national security failure.

[1] NIST Special Publication 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. https://csrc.nist.gov/publications/detail/sp/800-137/final [2] CISA Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog [3] Defense Information Systems Agency (DISA). Assured Compliance Assessment Solution (ACAS). https://www.disa.mil/