Lab 02 — FedRAMP Continuous Monitoring / POA&M SLA Engine

Difficulty: 3/5 | Runs locally: yes, standard library only

Pairs with the Phase 15 WARMUP Chapter 6 (continuous monitoring and the POA&M).

Why This Lab Exists (Purpose & Goal)

An ATO is not a finish line — FedRAMP makes the authorization conditional on continuous monitoring (ConMon), and the Authorizing Official can revoke it when ConMon lapses. The goal of this lab is to build the engine that computes the monthly compliance posture: are the required scans fresh, and is every finding being remediated within its severity-based SLA (honoring approved deviations)? This is vulnerability management with enforced, externally-audited timelines.

The Concept, In the Weeds

ConMon is just disciplined vuln management with non-optional SLAs (this is assess_conmon):

Scan cadence. Authenticated OS, web, and database scans run monthly; a scan older than ~30 days (or a missing scan type) is a deliverable failure.
Severity-based remediation SLAs (FedRAMP guidance): High = 30 days, Moderate = 90, Low = 180, from first detection. A finding past its SLA is overdue-<severity> — a compliance failure the AO sees.
Deviation requests. A finding may carry an approved deviation that stops the SLA clock — a False Positive, a Risk Adjustment (real risk lower than the scanner's rating), or an Operational Requirement (can't fix without breaking the service). Crucially, an expired or absent deviation does not help — the clock resumes.
Vendor dependency. A finding in inherited/provider scope is tracked separately and doesn't count against your SLA (though it must still be managed).

Why This Matters for Protecting the Company

ConMon is the mechanism that makes "we got certified once" into "we are continuously operating our controls." A lapse — stale scans, overdue High findings — is a compliance failure that can cost the ATO and the customers it unlocked. But it is also real security: the 30/90/180 SLAs force fast remediation of severe findings, which is exactly the behavior a good vulnerability-management program wants. An automated ConMon engine keeps the posture visible and honest month over month, so the company stays both authorized and actually patched.

Secure Implementation Patterns

The anti-pattern. Track findings in a spreadsheet, eyeball the dates, and let "we'll fix it eventually" or a stale deviation slide.

The secure pattern — enforce cadence + severity SLAs + deviations (mirrors solution.py):

SLA_DAYS = {"high": 30, "moderate": 90, "low": 180}
VALID_DEVIATIONS = {"false-positive", "risk-adjustment", "operational-requirement"}

def assess_conmon(scans, findings, deviations, *, today):
    issues = []
    latest = {}                                              # 1. SCAN CADENCE (monthly)
    for s in scans:
        latest[s.scan_type] = max(latest.get(s.scan_type, -1), s.completed)
    for required in ("os", "web", "database"):
        if required not in latest:           issues.append(f"scan-missing:{required}")
        elif today - latest[required] > 30:  issues.append(f"scan-stale:{required}")
    for f in findings:                                       # 2. SEVERITY SLAs + deviations
        if f.severity not in SLA_DAYS:       issues.append(f"{f.finding_id}:invalid-severity"); continue
        if f.vendor_dependency:              continue        # provider scope, not the customer's SLA
        dev = deviations.get(f.finding_id)
        if dev and dev.kind in VALID_DEVIATIONS and dev.expires >= today:
            continue                                          # APPROVED + UNEXPIRED deviation stops the clock
        if today - f.first_detected > SLA_DAYS[f.severity]:
            issues.append(f"{f.finding_id}:overdue-{f.severity}")
    return (not issues), tuple(sorted(issues))

The real-world equivalent (Phase 15 HITCHHIKERS): feed monthly scan results and the POA&M into this engine to produce the AO's monthly posture and a POA&M aging report.

Production practices to carry forward:

Enforce the cadence — a stale or missing required scan is itself a failure, before any finding.
Clock SLAs from first detection, by severity — High findings get 30 days, no exceptions without a deviation.
Deviations are approved and time-bounded — an expired deviation resumes the clock; an unjustified one never stops it.
Separate vendor-scope findings so inherited risk is tracked without distorting your SLA posture.

Validation — What You Should Be Able to Do Now

State the FedRAMP scan cadence and the 30/90/180 severity SLAs and apply them to dated findings.
Apply a deviation correctly — approved and unexpired stops the clock; expired/absent doesn't.
Separate vendor-dependency findings from the customer's SLA.
Compute a monthly ConMon posture and a finding-aging summary.

The Broader Perspective

This lab teaches time-bounded risk management as an enforced, auditable property — the recognition that a finding's age is itself a compliance and security metric, and that "we'll get to it" is not a strategy. The same instinct — clock from detection, enforce by severity, time-box exceptions — is the Phase 03 vulnerability-management workflow and the Phase 09 detection-coverage health check, here made non-optional by an external authority. Across the curriculum, mature security replaces "eventually" with measured, enforced, freshly-evidenced — and ConMon is that discipline applied to the entire authorization, continuously.

Interview Q&A

"Explain FedRAMP ConMon SLAs." — Monthly authenticated OS/web/DB scans (older than ~30 days is a deliverable failure); remediate by severity — High 30 days, Moderate 90, Low 180 from detection. An approved, unexpired deviation (FP / risk adjustment / operational requirement) stops the clock; an expired or absent one doesn't. The AO can revoke the ATO on a ConMon lapse.
"Is ConMon just paperwork?" — No; it's vulnerability management with enforced, audited timelines — exactly the behavior good security wants, made non-optional.

Extension (Stretch)

Ingest real scan output (e.g. an OpenSCAP/Nessus export), generate a POA&M aging report and an OSCAL assessment-results document, and model the deviation-request approval workflow.

References

FedRAMP Continuous Monitoring Strategy Guide; POA&M template; NIST SP 800-137 (ISCM); Phase 15 WARMUP Chapter 6.

Security Engineer