Security & Compliance

Major Frameworks Comparison

The table below maps the most commonly encountered federal cybersecurity frameworks. Each serves a distinct purpose, but they are designed to interlock and reference one another.

Key Acronyms Glossary

Compliance documentation is dense with acronyms. Master these first; they appear in every authorization package, audit report, and policy document you will read.

How the Frameworks Interlock

These frameworks are not independent silos. They form a layered compliance stack where each standard builds on or references the others.

The 6 Core Functions

CSF 2.0 organizes cybersecurity activities into six high-level functions. The new Govern function sits at the center, informing and connecting the other five. Together they describe the full lifecycle of managing cybersecurity risk.

Implementation Tiers

Tiers describe the degree to which an organization's cybersecurity risk management practices exhibit the characteristics defined in the Framework. Tiers are not maturity levels; they help organizations determine the appropriate rigor for their risk environment.

Framework Profiles

A Profile represents the alignment of the Functions, Categories, and Subcategories with the business requirements, risk tolerance, and resources of the organization. CSF 2.0 introduces clearer guidance on creating and using profiles for gap analysis.

Key Differences from CSF 1.1

CSF 2.0 is not a minor revision. It represents a structural rethinking of the framework, expanding both its scope and its practical utility.

CSF 2.0 Structure Summary

# CSF 2.0 Hierarchy
CSF Core
  Function (6 total)
    Category (22 total, e.g., GV.OC - Organizational Context)
      Subcategory (106 total, e.g., GV.OC-01)
        Implementation Examples (companion resource)
        Informative References (mappings to 800-53, ISO 27001, CIS, etc.)

Function Breakdown:
  GV  Govern    — 6 categories  (OC, RM, SC, RR, PO, OV)
  ID  Identify   — 4 categories  (AM, RA, IM, **)
  PR  Protect    — 5 categories  (AA, AT, DS, PS, IR)
  DE  Detect     — 2 categories  (CM, AE)
  RS  Respond    — 4 categories  (MA, AN, MI, CO)
  RC  Recover    — 2 categories  (RP, CO)

# The Govern function sits at the center of the wheel diagram,
# informing and being informed by all other five functions.

All 20 Control Families

SP 800-53 Rev 5 organizes 1,189+ controls into 20 families. Each family addresses a broad area of security or privacy concern. Controls within a family are numbered sequentially (e.g., AC-1, AC-2, ... AC-25).

Control Structure & Hierarchy

Every control in 800-53 follows a consistent structure. Understanding this hierarchy is essential for reading, implementing, and assessing controls.

# Control Numbering Convention
Family → Control → Enhancement

# Example: Access Control family, Account Management control
AC          # Family: Access Control
AC-2        # Control: Account Management
AC-2(1)     # Enhancement 1: Automated System Account Management
AC-2(2)     # Enhancement 2: Automated Temporary & Emergency Account Management
AC-2(3)     # Enhancement 3: Disable Accounts
AC-2(4)     # Enhancement 4: Automated Audit Actions
AC-2(5)     # Enhancement 5: Inactivity Logout

# Control Components
Control Section         Description
────────────────────    ─────────────────────────────────────
Control Statement       The requirement itself (what must be done)
Discussion              Context, rationale, and implementation guidance
Related Controls        Cross-references to other controls
References              Source publications (FIPS, SPs, etc.)
Control Enhancements    Additional requirements that extend the base

# Example Control: AC-2 Account Management
AC-2  ACCOUNT MANAGEMENT

Control:
  a. Define and document the types of accounts allowed and
     specifically prohibited for use within the system;
  b. Assign account managers;
  c. Require [Assignment: organization-defined prerequisites and
     criteria] for group and role membership;
  d. Specify:
     1. Authorized users of the system;
     2. Group and role membership; and
     3. Access authorizations (i.e., privileges) and
        [Assignment: organization-defined attributes] for each account;
  e. Require approvals by [Assignment: organization-defined personnel
     or roles] for requests to create accounts;
  f. Create, enable, modify, disable, and remove accounts in
     accordance with [Assignment: organization-defined policy,
     procedures, prerequisites, and criteria];
  g. Monitor the use of accounts;
  h. Notify account managers and [Assignment: organization-defined
     personnel or roles] within:
     1. [Assignment: organization-defined time period] when accounts
        are no longer required;
     2. [Assignment: organization-defined time period] when users
        are terminated or transferred; and
     3. [Assignment: organization-defined time period] when system
        usage or need-to-know changes for an individual;
  i. Authorize access to the system based on:
     1. A valid access authorization;
     2. Intended system usage; and
     3. [Assignment: organization-defined attributes];
  j. Review accounts for compliance with account management
     requirements [Assignment: organization-defined frequency];

# [Assignment: ...] = Organization fills in the specific value
# This parameterization makes controls adaptable to any environment

Control Baselines

NIST SP 800-53B defines four baselines that pre-select controls based on system impact level (as determined by FIPS 199). Organizations start with a baseline and then tailor it by adding or removing controls based on risk assessment.

Common, System-Specific & Hybrid Controls

Not every system implements every control from scratch. Controls are designated based on where they are implemented and who is responsible for them.

The distinction matters because common controls reduce duplication (one assessment covers many systems), but they also create shared risk: if a common control fails, every inheriting system is affected.

Overlays

Overlays are pre-built tailoring packages that address specific communities of interest, technologies, or operational environments. They modify the baseline by adding, removing, or refining controls and parameters.

The 7 RMF Steps

RMF follows a disciplined, seven-step lifecycle. Each step has defined tasks, responsible roles, and expected outputs. The process is iterative—monitoring findings feed back into earlier steps, creating a continuous authorization loop rather than a one-time event.

Key RMF Roles

RMF defines clear roles with distinct responsibilities. Separation of duties is critical—the person who builds the system should not be the same person who assesses it, and the person who assesses it should not be the same person who authorizes it.

Artifacts at Each Step

Each RMF step produces or updates specific documents. These artifacts form the authorization package and the ongoing evidence trail for continuous monitoring. Understanding which documents are created, updated, or reviewed at each step is essential for managing the process.

FIPS 199 System Categorization

FIPS 199 is the starting point for the entire RMF process. It defines how to categorize federal information systems based on the potential impact of a security breach across three security objectives. The categorization result determines which control baseline from SP 800-53B applies to the system.

For each information type processed by the system, determine the potential impact (Low, Moderate, or High) if there were a loss of confidentiality, integrity, or availability. NIST SP 800-60 provides default impact levels for common federal information types.

# FIPS 199 Categorization Format
System: [System Name]
Confidentiality: [Low | Moderate | High]
Integrity:       [Low | Moderate | High]
Availability:    [Low | Moderate | High]
Overall Impact:  HIGH-WATER MARK → [Result]

# Example: HR Management System
System: Enterprise HR Portal
Confidentiality: High     # PII, SSNs, salary data
Integrity:       Moderate # Data accuracy matters but not life-safety
Availability:    Low      # Temporary outage is tolerable
Overall Impact:  HIGH-WATER MARK → High

# Example: Public Website
System: Agency Public Information Portal
Confidentiality: Low      # All content is public
Integrity:       Moderate # Defacement would damage trust
Availability:    Low      # Brief outage is acceptable
Overall Impact:  HIGH-WATER MARK → Moderate

# The high-water mark is simply the HIGHEST individual rating.
# If any objective is High, the overall categorization is High.

Authorization Decision Types

After reviewing the authorization package, the AO issues one of the following decisions. Each carries different implications for system operations and ongoing requirements.

FedRAMP Authorization Levels

FedRAMP defines impact levels that align with FIPS 199 categorization. Each level requires a specific set of controls from NIST SP 800-53, with FedRAMP-specific parameters and additional requirements layered on top. The control count includes base controls plus FedRAMP-specific enhancements.

Authorization Paths

FedRAMP provides authorization paths for cloud service providers (CSPs) to obtain a government-wide authorization that can be reused by multiple agencies, avoiding redundant assessments.

Under the reuse model, once a CSP achieves FedRAMP authorization through any agency, the authorization package is listed in the FedRAMP Marketplace. Other agencies review the existing package, assess any agency-specific requirements, and issue their own ATO—significantly reducing time and cost compared to a full independent assessment.

FedRAMP 20x Modernization (2025–2026)

FedRAMP 20x is the most significant transformation of the program since its creation. Announced in early 2025, it shifts the authorization model from lengthy paper-based assessments toward automation-first, continuous assurance, dramatically reducing time-to-authorization.

Key Security Indicators (KSIs) are the cornerstone of FedRAMP 20x. Instead of assessing hundreds of individual controls through manual review, KSIs define a focused set of measurable security outcomes that can be verified through automated telemetry. The goal: authorization in approximately 3 months versus the 18+ months typical of the traditional process.

3PAO Assessments

Third Party Assessment Organizations (3PAOs) are independent, accredited entities that perform the security assessments required for FedRAMP authorization. They play a critical role as the objective evaluators of a CSP's security posture.

• Accreditation — 3PAOs must be accredited by the American Association for Laboratory Accreditation (A2LA) to ISO/IEC 17020, demonstrating competence and independence.
• Initial Assessment — A full assessment of all applicable controls prior to the initial authorization decision. Includes documentation review, personnel interviews, and technical testing (including penetration testing).
• Annual Assessment — Every year post-authorization, the 3PAO performs a reassessment of a subset of controls (typically one-third of the full control set, rotating annually to achieve full coverage over three years).
• Significant Change Assessment — When a CSP makes a significant change to their environment (e.g., new data center, major architecture change, new interconnections), a focused 3PAO assessment of affected controls is required.
• Independence — The 3PAO must be independent of the CSP. They cannot provide consulting services to the same CSP they assess. This separation ensures objectivity.

POA&M Management

The Plan of Action and Milestones (POA&M) is a living document that tracks known security weaknesses and the planned remediation actions. It is one of the three core authorization artifacts (along with the SSP and SAR) and is central to continuous monitoring.

FedRAMP enforces strict remediation timelines. Overdue POA&M items trigger escalation procedures and may jeopardize the authorization. The AO can accept risk for specific findings (documented as "Risk Accepted" with rationale), but this is intended for exceptions, not routine practice.

Authorization Boundary

The authorization boundary defines the scope of the FedRAMP assessment and authorization. Everything inside the boundary is directly assessed; everything outside is documented as an external connection or leveraged authorization. Getting the boundary right is one of the most critical early decisions in the FedRAMP process.

OSCAL — Open Security Controls Assessment Language

OSCAL is a NIST-developed suite of formats (XML, JSON, YAML) for expressing security control information in a machine-readable way. FedRAMP has mandated OSCAL-formatted authorization packages, with full enforcement planned by September 2026.

# OSCAL Layer Model
Layer 1: Catalog
  Machine-readable representation of SP 800-53 controls
  catalog.json / catalog.xml

Layer 2: Profile
  Baseline selection and tailoring (e.g., FedRAMP Moderate)
  profile.json / profile.xml

Layer 3: Component Definition
  Reusable security capabilities of a product or service
  component-definition.json

Layer 4: System Security Plan (SSP)
  Machine-readable SSP documenting control implementations
  ssp.json / ssp.xml

Layer 5: Assessment Plan (SAP)
  Assessment scope, methodology, schedule
  assessment-plan.json

Layer 6: Assessment Results (SAR)
  Findings from control assessments
  assessment-results.json

Layer 7: POA&M
  Machine-readable plan of action and milestones
  poam.json / poam.xml

# Benefits of OSCAL:
# - Automated validation of authorization packages
# - Machine-to-machine sharing of security posture data
# - Reduced manual effort in package creation and review
# - Foundation for continuous authorization automation

FedRAMP Security Inbox Requirement

Effective January 2026, FedRAMP requires all authorized CSPs to maintain a dedicated security inbox for receiving vulnerability reports, security inquiries, and incident notifications from federal agencies and FedRAMP PMO. This requirement formalizes a communication channel that was previously handled inconsistently across providers.

• Format — A monitored email address published in the CSP's SSP and FedRAMP Marketplace listing (e.g., fedramp-security@provider.com)
• Response SLA — Acknowledgment within 24 hours for all security-related communications; substantive response within 72 hours for vulnerability reports
• Staffing — Must be monitored by personnel with authority to initiate incident response and remediation activities
• Enforcement — Non-compliance may result in Significant Change Request triggers and POA&M entries during ConMon reviews

FISMA Overview

FISMA establishes the legal foundation for federal cybersecurity. It does not prescribe specific technical controls—instead, it delegates that responsibility to NIST, mandates agency compliance programs, and establishes reporting requirements to OMB and Congress.

FIPS 199 System Categorization — Detailed

FIPS 199 (Standards for Security Categorization of Federal Information and Information Systems) is the mandatory first step under FISMA. Every federal information system must be categorized before controls can be selected. The categorization determines the security baseline and drives the rigor of every subsequent step in the RMF process.

The three security objectives are defined in FIPS 199 with specific impact definitions:

# FIPS 199 Formal Notation
SC information type = {
    (confidentiality, [LOW | MODERATE | HIGH]),
    (integrity,        [LOW | MODERATE | HIGH]),
    (availability,     [LOW | MODERATE | HIGH])
}

# Example: Financial Management Information
SC financial data = {
    (confidentiality, MODERATE),
    (integrity,        MODERATE),
    (availability,     LOW)
}

# Example: Law Enforcement Investigation Records
SC investigation records = {
    (confidentiality, HIGH),
    (integrity,        MODERATE),
    (availability,     LOW)
}

# System categorization = HIGH-WATER MARK across all info types
# If ANY information type on the system has a High rating
# for ANY objective, the system is categorized as High.

FIPS 200 — Minimum Security Requirements

FIPS 200 (Minimum Security Requirements for Federal Information and Information Systems) defines 17 security-related areas that form the minimum standard for all federal systems. These areas map directly to the SP 800-53 control families and ensure baseline coverage regardless of system categorization.

Annual Reporting Requirements

FISMA mandates an annual reporting cycle in which agencies submit detailed metrics on their information security posture to OMB and Congress. These reports drive agency cybersecurity grades and influence budget decisions.

FISMA maturity is assessed on a five-level scale: Level 1: Ad Hoc Level 2: Defined Level 3: Consistently Implemented Level 4: Managed and Measurable Level 5: Optimized. Most agencies target Level 4 (Managed and Measurable) as the minimum acceptable posture.

Continuous Monitoring (ConMon) per NIST SP 800-137

NIST SP 800-137 (Information Security Continuous Monitoring for Federal Information Systems and Organizations) defines the ISCM program that transforms FISMA compliance from a periodic "snapshot" into an ongoing assurance posture. ConMon is the operational engine that keeps authorization relevant between formal reassessments.

ISCM (Information Security Continuous Monitoring) Strategy Components:

Monitoring Frequency Requirements by Control Type:

Not all controls need to be monitored at the same frequency. The monitoring strategy should define assessment schedules based on control volatility, risk, and operational impact.

ConMon Scanning Cadence

Continuous monitoring relies on a disciplined scanning cadence. The following table defines the minimum frequencies for common monitoring activities, aligning with FedRAMP ConMon requirements and NIST SP 800-137 guidance.

Dashboard Metrics and KPIs: Effective ConMon programs surface key performance indicators to authorizing officials and system owners through security dashboards. Common metrics include: percentage of systems with current ATO, average time to remediate critical vulnerabilities, POA&M aging analysis, patch currency rates, configuration compliance scores, and incident response times. These metrics enable data-driven risk decisions rather than relying on periodic assessment snapshots.

DISA STIGs Overview

Security Technical Implementation Guides are published by the Defense Information Systems Agency (DISA) and define configuration standards for all systems operating on DoD networks. STIGs are the authoritative source for how specific products must be hardened, and STIG compliance is a prerequisite for ATO in DoD environments.

Each STIG is structured as a collection of rules (also called findings or checks). Every rule has a unique identifier (e.g., V-254239), a description of the required configuration, a check procedure for auditing compliance, and a fix procedure for remediation. Rules are grouped into categories by technical area such as authentication, logging, network configuration, or file permissions.

Severity Categories: Each STIG rule is assigned a severity category (CAT) that reflects the potential impact of non-compliance.

Finding States: When evaluating a system against a STIG, each rule is assigned one of four states:

• Open — The system does not meet the STIG requirement. A finding exists and must be remediated or documented in the POA&M.
• Not a Finding — The system meets the STIG requirement. The check procedure confirms compliance.
• Not Applicable — The STIG rule does not apply to this system (e.g., a rule about IIS on a Linux system). Requires documented justification.
• Not Reviewed — The rule has not yet been evaluated. No compliance determination has been made.

Common STIGs

DISA publishes hundreds of STIGs covering virtually every product deployed in DoD environments. The following table lists the most commonly encountered STIGs with approximate rule counts and update cadences. Rule counts change with each release as new findings are added and obsolete ones are retired.

STIG Viewer & Workflow

STIG Viewer is DISA's official desktop application for browsing STIGs, creating checklists, and documenting compliance findings. It is the primary tool used by ISSOs, system administrators, and assessors to manage STIG compliance on a per-system basis.

STIG Viewer Workflow:

1. Import STIGs — Download the latest STIG Library from public.cyber.mil and import the relevant STIG XML files into STIG Viewer.
2. Create a Checklist — Generate a new checklist (.ckl file) for the target system. A checklist maps a specific STIG to a specific host.
3. Evaluate Rules — For each rule, run the check procedure against the target system and record the finding state (Open, Not a Finding, Not Applicable, or Not Reviewed).
4. Document Findings — For each Open finding, document the finding detail, severity override (if applicable), and any comments or compensating controls.
5. Import SCAP Results — Optionally import automated SCAP scan results (from SCC or OpenSCAP) to pre-populate finding states, reducing manual effort.
6. Export & Submit — Export the completed checklist as a .ckl file for inclusion in the authorization package. Multiple checklists are aggregated for the full system.

STIG Viewer supports bulk operations for large environments: you can create checklist templates, import/export multiple checklists, and merge SCAP results across many hosts. For automation at scale, many organizations use tools like Ansible, Chef InSpec, or Puppet to evaluate and remediate STIG findings programmatically.

CIS Controls v8

The CIS Critical Security Controls (version 8, released May 2021) are a prioritized set of 18 cybersecurity best practices developed by the Center for Internet Security. Unlike the NIST 800-53 catalog (which is comprehensive and technology-neutral), CIS Controls are prescriptive, actionable, and ordered by defensive priority. They answer the question: "What should we do first?"

Implementation Groups (IGs): CIS Controls are organized into three Implementation Groups that represent increasing levels of cybersecurity maturity and resource investment. Every organization should start with IG1.

CIS Benchmarks vs. STIGs

CIS Benchmarks are consensus-based secure configuration guides for specific technologies (operating systems, databases, cloud platforms, etc.). While they serve a similar purpose to STIGs, there are important differences in authority, audience, and implementation detail.

In practice, many organizations use both: STIGs for DoD compliance requirements and CIS Benchmarks for technologies not covered by STIGs or for non-DoD systems. The two standards overlap significantly for common platforms, though specific settings may differ.

CIS Hardened Images

CIS provides pre-hardened virtual machine images that are pre-configured to meet CIS Benchmark recommendations out of the box. These images are available on all major cloud marketplaces and are updated monthly to incorporate the latest benchmark revisions and security patches.

Using CIS Hardened Images as base images significantly accelerates compliance. Instead of hardening a vanilla OS post-deployment, you start from a compliant baseline and only need to manage application-specific configurations and any deviations required by your environment.

SCAP & OVAL

The Security Content Automation Protocol (SCAP) is a suite of specifications maintained by NIST that enables automated configuration checking, vulnerability assessment, and compliance verification. SCAP is the technical backbone that makes large-scale STIG and CIS compliance feasible.

SCAP Component Specifications:

• XCCDF (Extensible Configuration Checklist Description Format) — XML language for writing security checklists. Defines the rules, profiles, and remediation scripts. STIGs and CIS Benchmarks are published in XCCDF format.
• OVAL (Open Vulnerability and Assessment Language) — XML language for describing system state checks. Each XCCDF rule references OVAL definitions that describe exactly how to test for compliance.
• CVE (Common Vulnerabilities and Exposures) — Standard identifiers for publicly known vulnerabilities.
• CPE (Common Platform Enumeration) — Standard naming scheme for IT products and platforms.
• CVSS (Common Vulnerability Scoring System) — Standard for scoring vulnerability severity.
• CCE (Common Configuration Enumeration) — Standard identifiers for system configuration issues.

OpenSCAP is the most widely used open-source implementation of the SCAP standard. It provides command-line tools and libraries for scanning systems against XCCDF/OVAL content.

# Scan system against a STIG profile
oscap xccdf eval \
  --profile stig \
  --results results.xml \
  --report report.html \
  ssg-rhel9-ds.xml

# Generate a fix script from STIG profile
oscap xccdf generate fix \
  --profile stig \
  --output remediate.sh \
  ssg-rhel9-ds.xml

# List available profiles in a data stream
oscap info ssg-rhel9-ds.xml

# Validate SCAP content
oscap xccdf validate ssg-rhel9-ds.xml

SCAP Compliance Checker (SCC) is DoD's official scanning tool, developed and distributed by DISA. SCC provides a GUI and CLI for scanning systems against STIGs using SCAP content. It can scan local and remote hosts, supports Windows, Linux, Solaris, and network devices, and produces results in both .ckl (STIG Viewer) and XCCDF format. SCC is the standard tool used during RMF assessments and is available to DoD users from the DISA Cyber Exchange.

ATO Overview

An Authorization to Operate (ATO) is not merely a checkbox or a rubber stamp. It is a risk-based decision made by a senior executive (the Authorizing Official) who is personally accountable for the consequences of that decision. The ATO process produces a comprehensive authorization package that documents the system's security posture, the risks it carries, and the compensating controls and monitoring strategies in place to manage those risks.

Why ATO matters: Without an ATO, a federal information system cannot process, store, or transmit government data in a production environment. Operating without authorization is a federal policy violation that exposes the agency to regulatory action, audit findings, and unaccepted risk. Every system in the federal inventory — from a minor internal web application to a multi-billion-dollar weapons platform — requires an authorization decision.

Typical Timelines:

Authorization Package Components

The authorization package is the collection of documents submitted to the Authorizing Official for review. Together, they present a complete picture of the system, its security posture, its residual risks, and the plan for ongoing monitoring.

Authorization Decision Types

After reviewing the authorization package, the Authorizing Official issues one of the following decisions. The decision reflects the AO's assessment of residual risk relative to the organization's risk tolerance.

SSP Deep Dive

The System Security Plan (SSP) is the most important document in the authorization package. It is both the technical blueprint and the compliance narrative for the system. Assessors, auditors, and the Authorizing Official all use the SSP as their primary reference. A well-written SSP significantly accelerates the authorization process; a poorly written one guarantees delays.

Key Sections of a System Security Plan:

Continuous ATO (cATO)

Continuous Authorization to Operate (cATO) is an emerging approach that replaces the traditional three-year reauthorization cycle with an ongoing authorization posture based on real-time risk visibility. Instead of producing a massive paper-based authorization package every three years, cATO relies on continuous automated evidence collection, real-time security dashboards, and ongoing risk assessment.

Core Requirements for cATO:

• Automated Scanning — Continuous vulnerability scanning, configuration compliance checks, and asset inventory updates running on automated schedules (daily or more frequent).
• Real-Time Dashboards — Security posture dashboards accessible to the AO, ISSM, and ISSO that provide current risk metrics, vulnerability trends, compliance scores, and anomaly indicators.
• Continuous Evidence Collection — Automated collection and storage of compliance evidence (scan results, configuration snapshots, audit logs) that replaces manual evidence gathering.
• DevSecOps Pipeline Integration — Security testing integrated into CI/CD pipelines so that every code change and infrastructure modification is automatically assessed against security requirements.
• Defined Thresholds & Triggers — Pre-agreed risk thresholds that, when exceeded, trigger escalation to the AO for review. Replaces the subjective "significant change" determination.

DoD Adoption: The Department of Defense has embraced cATO through the DoD DevSecOps Reference Design and the Platform One initiative. DoD CIO guidance now explicitly supports continuous authorization for systems that can demonstrate ongoing risk visibility. Several DoD programs (including Platform One's Big Bang deployment and Iron Bank container registry) operate under cATO.

Common ATO Pitfalls

The following are the most frequently encountered issues that delay or derail the ATO process. Each represents a failure mode that experienced compliance teams learn to anticipate and prevent.

Vulnerability Lifecycle

Effective vulnerability management follows a structured lifecycle. Each phase builds on the previous one, and skipping phases leads to gaps in coverage, wasted remediation effort, or unaddressed risk.

Scanning Tools

The following table compares the most widely deployed vulnerability scanning platforms in federal and enterprise environments. Tool selection depends on deployment model, scale, and compliance requirements.

CVSS Scoring: v3.1 vs. v4.0

The Common Vulnerability Scoring System (CVSS) is the industry standard for rating vulnerability severity. CVSS v4.0 was released in November 2023 and introduces significant changes over v3.1. Both versions remain in active use during the transition period.

Metric Group Comparison:

Key Changes in CVSS v4.0:

• Scope metric retired — The confusing "Scope" metric from v3.1 is replaced by separate impact metrics for the Vulnerable System and Subsequent Systems, providing clearer modeling of blast radius.
• Attack Requirements added — A new metric that captures prerequisites beyond privileges and user interaction (e.g., specific network conditions, race conditions, or deployment configurations required for exploitation).
• Dual impact metrics — Separate C/I/A impact ratings for the vulnerable system and any subsequent systems affected, replacing the binary Scope model.
• Supplemental metrics — New optional metrics (Safety, Automatable, Recovery, etc.) that provide additional context without affecting the numeric score.

Severity Scale: The numeric scoring ranges remain the same across both versions.

BOD 22-01: Known Exploited Vulnerabilities

Binding Operational Directive 22-01 (Reducing the Significant Risk of Known Exploited Vulnerabilities) is issued by CISA and applies to all Federal Civilian Executive Branch (FCEB) agencies. It establishes a mandatory requirement to remediate vulnerabilities that are actively being exploited in the wild.

The CISA KEV Catalog: CISA maintains the Known Exploited Vulnerabilities (KEV) catalog — a continuously updated list of vulnerabilities with confirmed active exploitation. When a vulnerability is added to the KEV catalog, federal agencies must remediate it within the specified timeline. The catalog is publicly available and is widely used beyond the federal government as a prioritization input.

Remediation Timelines under BOD 22-01:

Although BOD 22-01 is legally binding only for FCEB agencies, CISA strongly recommends that all organizations (state, local, tribal, territorial, and private sector) use the KEV catalog to prioritize patching. Many private-sector organizations have adopted the KEV catalog as a supplement to CVSS-based prioritization, as it reflects real-world exploitation rather than theoretical severity alone.

Remediation SLAs

Federal agencies and their contractors are expected to meet defined remediation timelines based on vulnerability severity. The following SLAs represent common government standards, though specific agency policies may be more aggressive.

Scanning Best Practices

The quality and coverage of vulnerability scanning directly impacts the accuracy of your risk picture. Poor scanning practices create a false sense of security by missing vulnerabilities that are visible to attackers.

Authenticated vs. Unauthenticated Scans:

Scan Frequency and Coverage:

• Minimum frequency: Weekly vulnerability scans for all systems in the authorization boundary. Continuous scanning is recommended for high-value assets and internet-facing systems.
• Scan coverage: 100% of assets within the authorization boundary must be scanned. Assets that cannot be scanned (e.g., fragile legacy systems) must be documented with compensating controls.
• New assets: Any new system or device added to the boundary must be scanned within 24 hours of deployment.
• Post-patch verification: Re-scan within 72 hours of applying patches to verify remediation and detect regressions.

Example Nessus CLI Scan:

# Basic authenticated scan against a subnet
nessuscli scan \
  --policy "Federal Moderate" \
  --targets 10.0.0.0/24 \
  --credentials ssh:admin \
  --output results-$(date +%Y%m%d).nessus

# Export results in multiple formats
nessuscli report \
  --format html,csv,nessus \
  --input results-20260212.nessus \
  --output report-20260212

# List available scan policies
nessuscli policy --list

# Update plugins (required for latest vulnerability checks)
nessuscli update --plugins-only

Log Sources by Category

A comprehensive logging strategy must capture events from every layer of the technology stack. The following table organizes the most critical log sources by category, along with the key events each produces and the standard formats used.

SIEM Platform Comparison

The SIEM market includes both commercial and open-source platforms. Selection depends on organizational size, budget, existing infrastructure, cloud strategy, and query complexity requirements. The following comparison covers the platforms most commonly encountered in federal and enterprise environments.

Log Formats

Standardized log formats enable interoperability between disparate systems and SIEM platforms. The three most common formats in enterprise and federal environments are Syslog, CEF, and JSON structured logging.

# Syslog RFC 5424 example
<134>1 2026-02-12T09:15:32.123Z webserver01 nginx 12345 - -
  10.0.1.50 - admin [12/Feb/2026:09:15:32 +0000] "POST /api/login HTTP/1.1" 401 287

# CEF example
CEF:0|Palo Alto|PAN-OS|11.1|THREAT|url-filtering|7|
  src=10.0.1.50 dst=203.0.113.42 dpt=443 act=block-url
  cs1=malware cs1Label=Category msg=Blocked malicious URL

# JSON structured example
{
  "timestamp": "2026-02-12T09:15:32.123Z",
  "level": "WARN",
  "event": "authentication_failure",
  "source_ip": "10.0.1.50",
  "user": "admin",
  "reason": "invalid_password",
  "attempt_count": 4
}

NIST AU (Audit and Accountability) Control Family

The AU family in NIST SP 800-53 Rev. 5 defines the requirements for event logging, audit record content, review processes, and protection of audit information. These controls form the compliance foundation for all logging and SIEM activities. The following table highlights the most critical AU controls with implementation guidance.

Correlation Rules — Common Use Cases

Correlation rules are the intelligence layer of a SIEM. They combine events from multiple sources to detect patterns that individual log entries cannot reveal. The following are foundational correlation rules that every federal SIEM deployment should implement.

Log Retention Requirements by Framework

Retention requirements vary significantly by compliance framework. Organizations subject to multiple frameworks must meet the most stringent applicable requirement. Retention policies must address both the total retention period and the accessibility window (how quickly logs must be retrievable for analysis).

Why Compliance Must Shift Left

In a traditional model, compliance is a gate at the end of the development lifecycle. Security assessments happen months after code is written, findings require expensive rework, and authorization delays block deployment. DevSecOps inverts this model by embedding compliance checks throughout the pipeline, catching issues when they are cheapest to fix and generating evidence continuously rather than in periodic bursts.

Compliance-as-Code Tools

These tools encode security requirements as executable code, enabling automated compliance checking, continuous hardening validation, and machine-readable policy enforcement.

# Chef InSpec — test SSH configuration against STIG requirements
describe sshd_config do
  its('Protocol') { should cmp 2 }
  its('PermitRootLogin') { should eq 'no' }
  its('MaxAuthTries') { should cmp <= 4 }
  its('ClientAliveInterval') { should cmp <= 600 }
  its('ClientAliveCountMax') { should cmp 0 }
  its('PermitEmptyPasswords') { should eq 'no' }
end

# Run InSpec against a remote target
inspec exec rhel9-stig-baseline \
  -t ssh://admin@10.0.1.50 \
  --reporter cli json:results.json

# Ansible STIG role — automated hardening
- hosts: servers
  become: true
  roles:
    - role: ansible-lockdown.rhel9-stig
      rhel9stig_cat1_patch: true
      rhel9stig_cat2_patch: true
      rhel9stig_cat3_patch: true
      rhel9stig_gui: false

# OpenSCAP — scan against DISA STIG profile
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_stig \
  --results stig-results.xml \
  --report stig-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Pipeline Security Gates

A mature DevSecOps pipeline enforces security and compliance checks at every stage. Each gate acts as a quality checkpoint—failures block progression to the next stage, ensuring that non-compliant code never reaches production.

Automated Evidence Collection

The goal of compliance-as-code is not just to automate checks but to automatically generate the evidence artifacts that assessors need. Every pipeline run, every compliance scan, and every monitoring event becomes a timestamped, immutable record of control effectiveness.

• Continuous compliance dashboards: Aggregate results from all security gates into a single view. Track compliance posture over time with trend lines showing improvement or regression. Map dashboard panels to specific NIST 800-53 control families (e.g., RA-5 compliance score, CM-6 drift percentage).
• Automated control testing → compliance artifacts: Every InSpec or OpenSCAP scan produces machine-readable results (JSON, ARF/XML) that directly map to control assessment findings. These outputs replace manual evidence spreadsheets and can be versioned in Git alongside the code they validate.
• OSCAL integration for machine-readable SSPs: Convert traditional Word-document SSPs into OSCAL-formatted JSON/XML. Control implementations reference automated test results, creating a living SSP that updates as the system evolves. Tools like the NIST OSCAL Reference Toolchain and Trestle (by IBM) enable this workflow.
• Pipeline-generated POA&M entries: When a security gate fails, the pipeline automatically creates or updates a POA&M entry with the finding details, affected components, severity, and a remediation deadline based on organizational policy. This eliminates the lag between finding discovery and documentation.

Container Security for Compliance

Containers introduce unique compliance challenges. Traditional STIG and CIS benchmarks assume persistent, mutable infrastructure. Container environments require adapted approaches that address image provenance, runtime isolation, orchestrator security, and software supply chain integrity.

# Trivy — scan container image for vulnerabilities and misconfigurations
trivy image \
  --severity CRITICAL,HIGH \
  --exit-code 1 \
  --format json \
  --output scan-results.json \
  registry.example.gov/app:v2.1.0

# Syft — generate SBOM in CycloneDX format
syft registry.example.gov/app:v2.1.0 \
  -o cyclonedx-json=sbom.cdx.json

# Cosign — sign and verify container images
cosign sign --key cosign.key registry.example.gov/app:v2.1.0
cosign verify --key cosign.pub registry.example.gov/app:v2.1.0

Control Mapping Matrix

The following matrix maps key security domains across the major compliance frameworks. Use this crosswalk to identify equivalent controls when demonstrating compliance with multiple standards simultaneously. Satisfying the most stringent requirement in each row typically covers all others.

CMMC 2.0 Overview

The Cybersecurity Maturity Model Certification (CMMC) 2.0 is the DoD’s mechanism for verifying that defense contractors adequately protect Federal Contract Information (FCI) and Controlled Unclassified Information (CUI). CMMC streamlines the original 5-level model down to 3 levels and aligns directly with existing NIST standards.

Framework Reciprocity

Reciprocity reduces duplicative effort by allowing compliance evidence from one framework to satisfy requirements in another. Understanding these reciprocity relationships is critical for organizations operating across multiple compliance regimes.

Key Compliance Resources

The following authoritative sources should be bookmarked by every compliance practitioner. These are the primary references for current standards, vulnerability data, hardening guides, and assessment tools.

Certification Paths for Compliance Professionals

Professional certifications validate compliance expertise and are often required or preferred for federal security roles. The following certifications are most relevant to the frameworks and processes covered in this guide.

Key Acronyms — Master Glossary

A comprehensive alphabetical glossary of all acronyms used throughout this guide. This expands on the Section 01 quick reference and includes terms introduced in later sections.