Skip to content
ControlVerdict
Sign in
SI.L2-3.14.6CMMC Level 2Level 2

Monitor Communications for Attacks

Submit your own example

Practice statement

Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.14.6.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(3)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    the system is monitored to detect attacks and indicators of potential attacks;

    1 example covers this

  2. [b]

    inbound communications traffic is monitored to detect attacks and indicators of potential attacks; and

    1 example covers this

  3. [c]

    outbound communications traffic is monitored to detect attacks and indicators of potential attacks.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    SI.L2-3.14.6Monitor Communications for Attacks
    Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.

    • [a]

      the system is monitored to detect attacks and indicators of potential attacks;

    • [b]

      inbound communications traffic is monitored to detect attacks and indicators of potential attacks; and

    • [c]

      outbound communications traffic is monitored to detect attacks and indicators of potential attacks.

    Inbound, outbound, and off-network telemetry with business-hours triage and on-call paging

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. No verdicts yet.

    Implementation

    AO coverage. Addresses all three Monitor Communications for Attacks objectives: the system is monitored, inbound traffic is monitored, and outbound traffic is monitored.

    System monitoring [a]. EDR telemetry from every managed endpoint and server, identity provider sign-in and audit logs, cloud control-plane audit logs, and application logs from the CUI applications all land in the SIEM. Detection content covers credential attacks, suspicious process ancestry, persistence creation, and privileged role activation outside change windows. Coverage is tracked as a source inventory so a system that stops sending is a ticket rather than a gap nobody notices.

    Inbound monitoring [b]. Firewall threat prevention runs in blocking mode at both edges with signature sets updated automatically, and its alerts forward to the SIEM. The reverse proxy in front of published applications logs requests and has web application firewall rules in blocking mode. Authentication failure patterns from the IdP — spray, password stuffing, impossible travel — are detections rather than dashboard-only reports.

    Outbound monitoring [c]. Outbound is treated as first-class, because that is where exfiltration and command-and-control show up. The enclave's default-deny egress policy means every blocked outbound attempt is a signal, and denied-egress spikes are alerted on. DNS filtering is applied to all managed devices whether on the corporate network or not, so a laptop at a coffee shop still has its resolution filtered and logged; newly registered domain and DNS-tunneling categories are alerted. EDR network telemetry covers off-network connections that never touch a corporate edge. Data-volume anomalies from the labeled store and from cloud storage are alerted through the SIEM.

    Indicators of potential attack. Beyond confirmed detections, the SIEM watches for precursors: reconnaissance-style internal scanning, first-time-seen administrative tool execution, disabled security agent, cleared audit log, and mass file access from a single account.

    Triage model, stated honestly. High-severity detections page the on-call engineer at any hour with a defined acknowledgment target. Medium and low severity are queued for business-hours triage the next working day. The organization does not claim continuous human monitoring; it claims continuous collection and detection with a defined paging path, and that distinction is written into the SSP rather than blurred.

    Maintenance. Weekly silent-source check against the source inventory. Monthly detection tuning review covering false-positive rate and any detection that has never fired. Quarterly purple-team style validation: run a small set of benign but detectable behaviors and confirm each produces the expected alert. Annual review of the paging thresholds against actual incident experience.

    Accepted gap. The shop-floor OT segment has no IDS sensor and cannot host agents. It is monitored only at its single upstream interface, has a deny-all policy toward every other segment, and carries no CUI. A sensor is on the roadmap tied to the next switch refresh, tracked on the exception register.

    What the evidence looks like

    • SIEM log-source inventory with the silent-source check history
    • Firewall threat prevention and WAF configuration showing blocking mode and alert forwarding
    • DNS filtering policy proving off-network coverage, with a sample alert
    • Detection catalog mapped to inbound, outbound, and host-based coverage
    • Quarterly detection-validation results and the on-call paging threshold definition

    Environment

    Two sites plus remote staff and a cloud enclave. No 24x7 SOC: business-hours triage with an on-call rotation for high-severity pages.

    Tools

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.