{"description":"Each weekly cycle is a recurring instance attached to the existing continuous security-monitoring Control item (domains: logging_monitoring_detection, control_type: detective, frequency: weekly) — the cycle enriches that standing Control with its operating record, never creating a duplicate control. It consumes the prior cycle's carry-forward (unresolved queue Issues, open watchlist entries, open corrective actions) and the documented continuous-monitoring strategy (a Policy item linked to the Control), and produces named deliverables: the deployment coverage-and-effectiveness assessment, the enriched central SIEM analysis queue, the maintained detection watchlist, and the signed cycle security-status report. In scope: verifying monitoring deployment and effectiveness, working the central SIEM threat-intel analysis queue, triaging flagged anomalies, maintaining the detection watchlist, reporting security status to the defined roles, and verifying continuous protection-service health and tuning across hosts, networks, and applications at both the perimeter and the interior. Out of scope: incident containment, eradication, and recovery — confirmed security events are handed off mid-cycle to the Security Incident Response workflow rather than duplicated here.","edges":[{"id":"e-analyze-flagged-anomalies-and-triage-report-security-status-and-route-findings","label":"False positive","source":"analyze-flagged-anomalies-and-triage","target":"report-security-status-and-route-findings","whenValue":"false_positive_close"},{"id":"e-analyze-flagged-anomalies-and-triage-maintain-detection-watchlist","label":"Watchlist","source":"analyze-flagged-anomalies-and-triage","target":"maintain-detection-watchlist","whenValue":"add_to_watchlist"},{"id":"e-analyze-flagged-anomalies-and-triage-escalate-to-incident-response","label":"Escalate","source":"analyze-flagged-anomalies-and-triage","target":"escalate-to-incident-response","whenValue":"escalate_to_incident_response"},{"id":"e-maintain-detection-watchlist-report-security-status-and-route-findings","source":"maintain-detection-watchlist","target":"report-security-status-and-route-findings"},{"id":"e-escalate-to-incident-response-report-security-status-and-route-findings","source":"escalate-to-incident-response","target":"report-security-status-and-route-findings"},{"id":"e-report-security-status-and-route-findings-close-and-archive","source":"report-security-status-and-route-findings","target":"close-and-archive"},{"id":"e-verify-protection-service-health-and-tuning-close-and-archive","label":"Healthy","source":"verify-protection-service-health-and-tuning","target":"close-and-archive","whenValue":"healthy_in_tolerance"},{"id":"e-verify-protection-service-health-and-tuning-log-tuning-and-corrective-actions","label":"Tuning","source":"verify-protection-service-health-and-tuning","target":"log-tuning-and-corrective-actions","whenValue":"tuning_gaps_identified"},{"id":"e-log-tuning-and-corrective-actions-close-and-archive","source":"log-tuning-and-corrective-actions","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-LOG-04","UC-LOG-05","UC-BCDR-13"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-security-monitoring-detection-operations","contentDigest":"sha256:2264ccb2a62c35b5cd25519eb830d768654f8034602856c3d593927ef0ebf28c","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:2264ccb2a62c35b5cd25519eb830d768654f8034602856c3d593927ef0ebf28c","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-security-monitoring-detection-operations"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-security-monitoring-detection-operations","source":"coworkcanvas-gallery","standards":["nist-csf-2","nist-800-53","iso-27001","soc2"],"teams":["it"]},"name":"Security Monitoring & Detection Operations","nodes":[{"data":{"decisionField":"anomaly_disposition","description":"Agent aggregates, correlates, and enriches the cadence window's logs and alerts into the central SIEM analysis queue and drafts a triage recommendation for each item; human decides the disposition of the batch","formData":{"fields":[{"key":"anomaly_disposition","label":"Anomaly Disposition","options":[{"label":"False positive, close","value":"false_positive_close"},{"label":"Indeterminate, add to watchlist","value":"add_to_watchlist"},{"label":"Confirmed event, escalate to incident response","value":"escalate_to_incident_response"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Aggregate this cadence window's logs and alerts into the central SIEM analysis capability, correlate and enrich them, and resolve the dominant disposition of the resulting anomaly batch — benign/false-positive, indeterminate (watchlist), or a confirmed security event to escalate. Owned by the SOC lead, whose call determines which findings reach incident response, which stay under observation, and which are closed as noise.\n\n**Inputs**\n- Internal log and alert sources for the cadence window: host, network, and application telemetry.\n- External cyber-threat-intelligence feeds and bulletins already on file — documents already linked in AssureSwarm, with the live feeds themselves in external systems.\n- The immutable original record set (the integrity baseline for this step) — read-only in the external SIEM/log store; AssureSwarm keeps only the hash/row-count confirmation.\n- The open detection watchlist (open Issue items, issue_type: observation, from prior cycles) and any unresolved queue carryover from the prior cycle.\n- Asset ownership and criticality plus prior-history records for the entities involved.\n- Runs from the workflow's initial inputs only — an independent entry, parallel to the monitoring-deployment and reporting path and the protection-service review.\n\n**Procedure**\n_Items 1–7 are agent-run (folded from the former \"Work the central SIEM analysis queue\" step, which carried no separate human touch-point); the human moment is the disposition call in item 8._\n1. Pull the correlated event set for the cadence window across internal host, network, and application sources plus external threat-intel feeds (NIST 800-53 AU-6, AU-7; NIST CSF DE.AE-02, DE.AE-03).\n2. Enrich each correlated cluster with threat-intel context (matched IOCs, campaign or actor tags) and with asset ownership and criticality.\n3. Run record-reduction and on-demand report generation against the immutable original record set to produce a prioritized analysis queue. Confirm the source records are read-only: capture a hash or row-count of the source set before and after and verify it is unchanged — nothing altered or overwritten.\n4. Create a queue item per correlated case cluster; link the supporting raw records to it; link any matched external threat-intel bulletins already on file.\n5. Fold unresolved carryover from the prior cycle's queue into this window so nothing is silently dropped, then attach the queue snapshot and the record-integrity confirmation.\n6. Correlate each queue item against IOC and threat-intel indicators, asset criticality, and prior-history records so the call rests on context rather than the raw alert, and classify each item with its supporting rationale.\n7. Scan open workflows to detect whether an item already belongs to an in-flight incident case, avoiding duplicate handling; draft the batch triage recommendation and attach it.\n8. The SOC lead reviews the enriched queue and the drafted recommendation and submits the batch disposition against the criteria below.\n\n**Decision criteria**\n- `false_positive_close` — The batch correlates to benign or expected activity: known-good administrative behavior, sanctioned scanning, or an already-tuned noisy rule, with no IOC match and no critical-asset concern. Close as noise.\n- `add_to_watchlist` — Findings are indeterminate: a weak or partial IOC match, anomalous but unconfirmed behavior, or activity that needs more observation before a call. Keep under continued, accountable observation with a review-by date.\n- `escalate_to_incident_response` — One or more findings is a confirmed security event: a strong IOC/threat-intel match, confirmed malicious behavior, or impact to a critical asset (NIST CSF DE.AE-06, DE.AE-07). Hand off to incident response with full context.\n\n**Record in AssureSwarm**\n- Submit the `anomaly_disposition` SELECT field with the chosen branch. Record the decision rationale and evidence references in the step result and the decision owner in the step's approver record.\n- Create one Issue per correlated case cluster (issue_type: observation, source: management_identified, severity per enrichment), linked to the anchor Control — AssureSwarm has no Security Event/Alert type, so alert clusters are recorded as Issues (item-create); link the supporting raw records (items-link); link the matched threat-intel bulletins already on file (document-link).\n- Query the correlated sources and the enrichment context (query-data); scan open workflows for an in-flight incident case (workflow-scan).\n- Attach the queue snapshot, the record-integrity confirmation (hash/row-count), and the batch triage recommendation as step documents — the raw telemetry and immutable record set stay in the external SIEM (document upload).\n\n**Exit criteria** — The queue reflects the full correlated, enriched record set for the window, every item links its raw evidence, and the original records are verified unaltered; the `anomaly_disposition` form is submitted with rationale and owner; every item carries its classification rationale; the branches not taken for this batch are prunable.","kind":"decision","label":"Analyze flagged anomalies and triage","performedBy":{"primitives":["coach-query-data","coach-workflow-scan","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"analyze-flagged-anomalies-and-triage"},{"data":{"description":"Agent packages the confirmed event and hands it to incident response with full context; human confirms the handoff was received and accepted","instructions":"**Objective** — Route each confirmed security event to the incident-response capability with full context so response starts immediately, without this operating cycle duplicating the containment, eradication, or recovery work that belongs to the incident-response workflow.\n\n**Inputs**\n- The confirmed-event queue items and their triage rationale from the anomaly-triage decision (escalate branch).\n- Correlated records, threat-intel matches, affected-asset context, and severity for each event.\n- The active incident-response workflow instance or its intake queue.\n\n**Procedure**\n1. For each confirmed event, package its correlated records, threat-intel matches, affected assets, severity, and triage rationale into a handoff brief.\n2. Create the incident-response intake record and link the supporting queue item and its evidence to it.\n3. Scan for the receiving incident-response workflow instance with coach-workflow-scan to confirm the handoff lands in an active case rather than creating an orphaned record; if none is active, request one be opened before handoff.\n4. Notify the authorized incident-response staff and response tooling per the escalation runbook and capture the acknowledgement.\n5. Attach the handoff brief and the receipt/acknowledgement confirmation.\n\n**Record in AssureSwarm**\n- Create the incident-response intake record as an Issue (issue_type: finding, source: management_identified, severity: high/critical) — the honest fallback absent a Security Event type — linked to its source queue Issue and its evidence (item-create, items-link).\n- Scan for the receiving incident-response case (workflow-scan); query the event package (query-data).\n- Attach the incident-response handoff brief and the receipt/acknowledgement as step documents — the handoff package consumed by the Security Incident Response workflow (document upload).\n\n**Exit criteria** — Every confirmed event has an incident-response intake record linked to its evidence; the receiving case is active and has acknowledged receipt; authorized staff and tools are notified. Containment and everything beyond it are owned by the incident-response workflow, not this cycle. Escalation outcomes feed the cycle status report.","label":"Escalate to incident response","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-workflow-scan","coach-document-upload"]}},"id":"escalate-to-incident-response"},{"data":{"description":"Agent updates the watchlist with new indeterminate findings and re-evaluates prior entries; human confirms no watchlisted item has quietly aged into a real event","instructions":"**Objective** — Keep indeterminate anomalies under continued, accountable observation until they resolve as benign or escalate to a confirmed event, so nothing quietly falls out of sight.\n\n**Inputs**\n- This cycle's indeterminate findings from the anomaly-triage decision (watchlist branch), with their rationale.\n- The existing detection watchlist: prior entries, observation criteria, review-by dates, and owners.\n- The latest correlated records and threat intelligence from the SIEM queue, for re-evaluation.\n\n**Procedure**\n1. Add each new indeterminate finding to the watchlist, capturing the observation criteria, the specific signal to watch, a review-by date, and an owner; link each to its source queue item.\n2. Re-query every existing watchlist entry with coach-query-data against the latest correlated records and threat intel to determine whether it has resolved as benign, aged past its review-by date, or accumulated evidence toward a confirmed event.\n3. For any entry whose status changed, draft a re-triage recommendation: resolve-and-close, extend observation with a new review-by date, or promote to a confirmed event for escalation.\n4. Attach the updated watchlist and the re-triage recommendation.\n\n**Record in AssureSwarm**\n- Create or refresh each watchlist entry as an Issue (issue_type: observation, source: management_identified, issue_owner set, target_remediation_date = review-by date), linked to its source queue Issue and to the anchor Control (item-create, items-link).\n- Re-query the records behind each entry (query-data).\n- Attach the updated detection watchlist and the re-triage recommendation as step documents (document upload).\n\n**Exit criteria** — Every watchlist entry has a current review-by date and a named owner; each new indeterminate finding is on the list and linked to its source; no entry has quietly aged into an unaddressed security event; any promoted entry is flagged for escalation. Watchlist status feeds the cycle status report.","label":"Maintain the detection watchlist","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"maintain-detection-watchlist"},{"data":{"description":"Agent computes deployment coverage and effectiveness against the documented monitoring strategy and compiles the cycle status report and routed finding list; human signs the status report and authorizes its distribution to the defined roles","instructions":"**Objective** — Establish that continuous monitoring is deployed and functioning under the documented strategy across hosts, networks, and applications, then report security status to the defined roles on the defined cadence and route this cycle's findings and adverse-event information to the authorized staff and tools accountable for acting on them; the SOC lead signs the status report and authorizes its distribution.\n\n**Inputs**\n- The documented continuous-monitoring strategy — a Policy item (policy_type: standard, domains: logging_monitoring_detection) linked to the anchor Control, with the governed strategy document attached: what is monitored, the metrics, their frequencies and thresholds, and the defined reporting roles, distribution list, and cadence (NIST 800-53 CA-7, SI-4; ISO 27001 A.8.16; SOC 2 CC7.2; NIST CSF DE.CM-01).\n- The current asset inventory — AssureSwarm has no Asset item type, so this lives in the external CMDB/asset tooling and enters as the reconciled inventory extract inside this step's assessment document: hosts, network segments, and applications, tagged perimeter vs. interior.\n- The deployed sensor/agent/log-source inventory — pulled from the external EDR/SIEM/firewall consoles and reconciled into that same assessment document: EDR and host agents, network IDS/IPS and netflow collectors, perimeter firewalls and proxies, application log integrations.\n- The prior-cycle operating record — the archived prior workflow instance plus the carry-forward Issue items it linked forward, for coverage gaps carried forward.\n- The triage outcomes from anomaly triage (false-positive closures), the escalation records from the escalation step, and the open entries from the detection watchlist.\n- This is a join: it needs the triage, escalation, and watchlist outcomes before it can report.\n\n**Procedure**\n_Items 1–5 are agent-run (folded from the former \"Verify monitoring deployment and strategy\" step, which carried no separate human touch-point); items 6–8 compile and route the report and the human moment is the sign-off and distribution in item 9._\n1. Reconcile the deployed sensor/agent/log-source inventory against the current asset inventory. For each segment (perimeter vs. interior; host / network / application), mark each asset monitored or unmonitored.\n2. Compute deployment coverage by segment and enumerate every gap: an unmonitored host, a missing log source, a sensor whose last-seen heartbeat is beyond its window, or an application with no log integration.\n3. Compute the control-effectiveness metrics the strategy defines — detection rate, mean time to acknowledge, false-positive rate, sensor uptime, log-ingestion completeness — against each metric's documented frequency and threshold. Flag any metric overdue for assessment or below threshold; never let one silently go unmeasured.\n4. Compare against the prior cycle's coverage gaps to confirm remediated gaps stayed closed and to surface any regression.\n5. Draft the deployment-and-effectiveness assessment stating, per segment, whether monitoring is deployed and functioning at perimeter and interior, and listing every open gap with a named owner.\n6. Compile the cycle status report: deployment coverage and effectiveness metrics; queue volume and triage outcomes (false positives closed, watchlisted, escalated); open watchlist and open escalation counts; and any metric below threshold.\n7. Export the routed finding list and route each finding and adverse-event record to its authorized owner and tool — asset owner, incident-response system, ticketing queue — confirming nothing is left unrouted.\n8. Build or refresh the coverage-and-effectiveness and security-status dashboard for the defined reporting roles.\n9. The SOC lead reviews the assessment and the compiled report, signs it, and authorizes distribution; distribute it to the defined roles on the defined cadence, confirm delivery, and attach the distributed report and the routing/distribution record.\n\n**Record in AssureSwarm**\n- Build or refresh the standing coverage-and-effectiveness and security-status dashboard for this Control and its defined reporting roles, refreshed each cycle rather than recreated (dashboard-create); query the strategy Policy item, the supporting metric records, and the source metrics (query-data).\n- Export the routed-finding list as a CSV (item-export); route each finding to its authorized owner and tool via item relationships and notification (items-link, notify).\n- Attach the deployment coverage-and-effectiveness assessment (PDF/XLSX), with every coverage gap and its named owner enumerated inside it — the asset and sensor inventories have no native AssureSwarm type, so their reconciled extracts live in that document — and the signed cycle security-status report (PDF) with its routing/distribution record (document upload).\n\n**Exit criteria** — Coverage is computed for every boundary segment and every gap is listed with a named owner; each strategy-defined metric is assessed on its frequency with none missed; the signed status report reached the defined reporting roles on cadence; every finding is routed to an authorized owner or tool with none left unrouted; monitoring responsibilities for the next window are communicated. The assessment and the distributed report become part of the closure record.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` — routes each finding and the status report to its authorized owner, tool, and the defined reporting roles, and captures delivery confirmation.","label":"Report security status and route findings","performedBy":{"primitives":["coach-query-data","coach-export-package","coach-items-link","coach-dashboard-create","coach-notify","coach-document-upload"]}},"id":"report-security-status-and-route-findings"},{"data":{"decisionField":"protection_health_status","description":"Agent checks malware defense, network/endpoint security, and the monitoring stack itself against accepted risk thresholds; human classifies the cycle as healthy or tuning required","formData":{"fields":[{"key":"protection_health_status","label":"Protection-Service Health Status","options":[{"label":"Healthy, within tolerance","value":"healthy_in_tolerance"},{"label":"Tuning gaps identified","value":"tuning_gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether the continuous protection services — malware defense, network and endpoint security tooling, and the monitoring stack itself — are operating within accepted risk levels (healthy) or need a tuning change (tuning gaps). Owned by the SOC lead.\n\n**Decision criteria**\n- `healthy_in_tolerance` — Every protection service is operating and keeping security risk within the accepted-risk thresholds set in the monitoring strategy: signatures and engines current, scans completing, agents healthy, sensor uptime and log-ingestion lag within tolerance, and no risk indicator over threshold (NIST CSF DE.CM-01; NIST 800-53 SI-4).\n- `tuning_gaps_identified` — At least one service needs a detection, threshold, or policy change to stay within tolerance: a rule generating excess noise, a threshold drifting from accepted risk, an overdue signature or policy update, an unhealthy agent fleet, or a chronically lagging log pipeline.\n\n**Agent preparation before the human picks:** (1) Query health and currency of malware-defense tooling (signature/engine currency, scan completion, quarantine backlog), network and endpoint security tooling (firewall/IPS rule currency, EDR agent health), and the monitoring stack itself (sensor uptime, log-ingestion lag, alert-pipeline health) with coach-query-data. (2) Compare each service's risk indicators against the accepted-risk thresholds. (3) Identify specific tuning candidates and build the health dashboard with coach-dashboard-create. (4) Draft the protection-service health summary and attach it with coach-document-upload.\n\n**Record in AssureSwarm** — Submit the `protection_health_status` SELECT field with the chosen branch. Record the decision rationale and evidence references in the step result and the decision owner in the step's approver record. Build or refresh the standing protection-health dashboard for this Control (dashboard-create) and attach the protection-service health summary as a step document (document upload).\n\n**Exit criteria** — The `protection_health_status` form is submitted with rationale and owner; the branch not taken is prunable; the health summary lists every service and its risk-indicator standing. This step runs from the workflow's initial inputs, independent of reporting, and drains to closure when healthy or to the tuning-and-corrective-actions step when gaps exist.","kind":"decision","label":"Verify protection-service health and tuning","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-document-upload"]}},"id":"verify-protection-service-health-and-tuning"},{"data":{"description":"Agent applies routine tuning changes and converts remaining gaps into owned corrective actions; human confirms every gap is owned and risk is back within tolerance","instructions":"**Objective** — Apply the routine tuning that keeps protection-service risk within accepted levels and convert every gap that needs more than routine tuning into an owned corrective action.\n\n**Inputs**\n- The protection-service health summary and its tuning candidates from the protection-service health decision (tuning branch).\n- The standing tooling change-request form and the change-management sign-off policy.\n- The corrective-action register.\n\n**Procedure**\n1. Parse the health summary into a list of tuning candidates, each with its root cause and the metric that surfaced it.\n2. Apply routine tuning directly — suppress a confirmed noisy detection rule, refresh a signature set, adjust an alert threshold — recording the change in the existing tooling change-management record and obtaining required native sign-off before it is applied; record each applied change.\n3. Create a corrective-action item for every gap that needs more than routine tuning (for example an understaffed malware-defense process, an EDR rollout gap, or a chronically lagging log pipeline), capturing owner, due date, and interim mitigation, and link it to the driving metric.\n4. Attach the tuning log and the corrective-action register.\n\n**Record in AssureSwarm**\n- Retain the existing tooling change-management record and native sign-off for each change that requires it, with its reference in the tuning log.\n- Create a corrective-action Issue for every gap beyond routine tuning (issue_type: deficiency, issue_owner, target_remediation_date, remediation_plan), linked to the anchor Control and its driving metric (item-create, items-link); applied routine changes are captured in the tuning log document.\n- Attach the tuning log and the corrective-action register as step documents (document upload).\n\n**Exit criteria** — Every tuning change is recorded; every remaining gap has a named owner and due date with an interim mitigation; protection-service risk is back within accepted levels or explicitly tracked to a corrective action. This record feeds the cycle closure.","label":"Log tuning and corrective actions","performedBy":{"primitives":["coach-form-fill","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"log-tuning-and-corrective-actions"},{"data":{"description":"Automatically archive the authorized cycle record and carry open actions into the next cycle.","instructions":"**Objective** — Automatically preserve the authorized cycle record and its carry-forward actions after the preceding decision.\n\n**Inputs**\n- The distributed cycle status report and its routing/distribution record from the reporting step.\n- The protection-service health outcome: either healthy (arriving directly) or the tuning log and corrective-action register from the tuning step.\n- Open watchlist entries, open corrective actions, and any escalation still awaiting incident-response closure.\n- The retention / evidence-repository Policy item (linked to the anchor Control) and the next-cycle cadence — the workflow's own recurrence.\n- This is the single sink and a join: it waits for the reporting path AND the protection-service-health path before the cycle can be declared closed.\n\n**Procedure**\n1. Export the full operating record with coach-workflow-export and archive it in the designated evidence repository under retention controls; record the archive location and reference.\n2. Create carry-forward items for open watchlist entries, open corrective actions, and any escalation still awaiting incident-response closure; link each to its source so it arrives as an explicit input to the next cycle.\n3. Update the control execution log with the cycle result, key metrics, and the reporting distribution record, and confirm the next weekly cadence review is scheduled.\n4. Attach the closure record.\n\n**Record in AssureSwarm**\n- Export the full operating record as the workflow-instance audit trail and archive the bundle (workflow-export).\n- Create carry-forward Issue items for open watchlist entries, open corrective actions, and any escalation still awaiting incident-response closure (item-create); link each to its source so it arrives as an explicit input to the next cycle (items-link).\n- Attach the workflow-export bundle and the closure record as step documents (document upload).\n\n**Exit criteria** — The archived record is immutable and retrievable under retention; the next cycle is scheduled with every open item carried forward under a tracked owner; the control execution log is updated; the authorized cycle record is complete. No downstream workflow follows this sink — confirmed events were already handed to incident response mid-cycle.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-item-create","coach-items-link","coach-document-upload"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:controls-security-monitoring-detection-operations"}