{"description":"Standing operator workflow for anti-malware coverage, detection handling, spam and phishing filtering, and mobile-code and website-content control, run on a monthly cadence by the security operations malware defense lead. Each monthly run is a new workflow instance attached to the existing Process item \"Malware, Email & Web Content Defense Operations\" (process_type: security_process, frequency: monthly), with Item relationships to the Control items it operates — UC-VULN-05 (malicious code protection) and UC-NET-13 (mobile code) in the control library (framework: nist-800-53, iso-27001, pci-dss). In scope: every system component commonly affected by malicious software, the email and web filtering entry and exit points, the mobile-code technologies in use, and website category and reputation filtering. Out of scope: endpoint patching and vulnerability remediation, incident response beyond first-line quarantine and alerting, and network firewall rule management. No upstream workflow feeds it: the monthly scope, the in-scope component and channel list, the accountable owners, and the prior-cycle carryover — the previous instance's open Issue items and step documents — are its own initial inputs. It produces the coverage reconciliation report, the detection-and-response log, the mobile-code authorization list, the tuned email/web and website-content filtering packages, a capability-health dashboard, a signed readiness classification, and a corrective-action register. It is terminal by design: rather than hand off to a downstream workflow, the close-and-archive step preserves the signed operating record under retention and loops carry-forward Issue items into the next monthly cycle.","edges":[{"id":"e-reassess-not-commonly-affected-components-deploy-coverage-to-newly-scoped-components","label":"Scope expanded","source":"reassess-not-commonly-affected-components","target":"deploy-coverage-to-newly-scoped-components","whenValue":"scope_expanded"},{"id":"e-reassess-not-commonly-affected-components-review-enforcement-logs-and-classify-readiness","label":"Scope confirmed","source":"reassess-not-commonly-affected-components","target":"review-enforcement-logs-and-classify-readiness","whenValue":"scope_confirmed"},{"id":"e-deploy-coverage-to-newly-scoped-components-review-enforcement-logs-and-classify-readiness","source":"deploy-coverage-to-newly-scoped-components","target":"review-enforcement-logs-and-classify-readiness"},{"id":"e-review-enforcement-logs-and-classify-readiness-log-corrective-actions","label":"Gaps","source":"review-enforcement-logs-and-classify-readiness","target":"log-corrective-actions","whenValue":"gaps_identified"},{"id":"e-review-enforcement-logs-and-classify-readiness-close-and-archive","label":"Healthy","source":"review-enforcement-logs-and-classify-readiness","target":"close-and-archive","whenValue":"healthy"},{"id":"e-log-corrective-actions-close-and-archive","source":"log-corrective-actions","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-VULN-05","UC-NET-13"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-malware-email-web-content-defense-operations","contentDigest":"sha256:3d55f54b2fcd9c02bbcb99373843a2c850f589f699300583fd65d4ccef633e0e","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:3d55f54b2fcd9c02bbcb99373843a2c850f589f699300583fd65d4ccef633e0e","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-malware-email-web-content-defense-operations"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-malware-email-web-content-defense-operations","source":"coworkcanvas-gallery","standards":["nist-800-53","iso-27001","pci-dss"],"teams":["it"]},"name":"Malware, Email & Web Content Defense Operations","nodes":[{"data":{"decisionField":"component_scope_reassessment","description":"Agent re-evaluates the excluded-component list against current threat and usage data; human decides whether the exclusion list is confirmed or must expand","formData":{"fields":[{"key":"component_scope_reassessment","label":"Component Scope Reassessment","options":[{"label":"Exclusion list confirmed","value":"scope_confirmed"},{"label":"Component(s) added to scope","value":"scope_expanded"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether the not-commonly-affected exclusion list still holds or must expand, keeping anti-malware scope accurate as platforms, usage, and threats change. Owned by the malware defense lead. (UC-VULN-05)\n\n**Decision criteria**\n- **scope_confirmed** — every excluded component's justification remains valid: its platform is still absent from malware telemetry, its function and connectivity are unchanged, and its last-review date is within policy. Pick this when no excluded component newly appears in threat data or in vendor \"now-affected platform\" guidance.\n- **scope_expanded** — one or more excluded components must move into anti-malware scope: the platform now appears in malware telemetry, usage or connectivity changed (for example, a formerly air-gapped host is now networked), or the exclusion justification is stale. Pick this whenever any single component fails re-justification.\n\nAgent preparation before the human picks:\n1. Pull the current not-commonly-affected exclusion list with coach-query-data, including the justification and last-review date recorded for each component.\n2. Cross-reference each excluded component's platform, function, and connectivity against current threat intelligence and vendor guidance on newly affected platform classes.\n3. Flag any excluded component whose justification is stale, whose platform now appears in malware telemetry, or whose usage has changed since the last review.\n4. Draft the reassessment findings with a recommendation for each flagged component and attach them with coach-document-upload.\n\n**Record in AssureSwarm**\n- Submit the `component_scope_reassessment` SELECT (scope_confirmed or scope_expanded).\n- Record the rationale and evidence references in the step result and the decision owner in the step's approver record.\n- Attach the reassessment findings (coach-document-upload).\n\n**Exit criteria** — The SELECT is submitted with rationale and owner recorded; when scope_expanded, the flagged components are itemized for deployment; the unused branch is prunable.","kind":"decision","label":"Reassess not-commonly-affected components","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"reassess-not-commonly-affected-components"},{"data":{"description":"Agent stages anti-malware deployment and interim compensating controls for newly in-scope components; human confirms deployment before the component is treated as covered","instructions":"**Objective** — Bring each newly in-scope component under full anti-malware coverage without leaving a protection gap while deployment is in progress. (UC-VULN-05)\n\n**Inputs**\n- The reassessment findings from the scope decision listing the components moved into scope (this step consumes that reviewed output).\n- The standard fleet agent configuration (version, scan policy, tamper settings).\n- Available interim compensating controls (network segmentation, restricted execution, heightened log review).\n\n**Procedure**\n1. Create an Issue item for each newly in-scope component with coach-item-create (issue_type: observation, source: self_assessment, issue_owner, target_remediation_date set to the deployment window, remediation_plan capturing target agent version and any interim compensating control); link it to the reassessment finding, to Control UC-VULN-05, and to the anchor Process item with coach-items-link.\n2. Stage interim compensating controls while agent deployment is pending — network segmentation, restricted execution, or heightened log review — and record what was applied and the date by which full coverage must replace it.\n3. Track deployment tickets to completion with coach-workflow-scan; confirm each component reports into the central console with real-time protection, current signatures, and tamper protection enabled, matching the standard fleet configuration.\n4. Attach the deployment record and the updated in-scope list with coach-document-upload.\n\n**Record in AssureSwarm**\n- **Item create** — one Issue per newly in-scope component (issue_type: observation, source: self_assessment, issue_owner, target_remediation_date = deployment window, remediation_plan) with coach-item-create.\n- **Item relationship** — link each Issue to the reassessment finding, to Control UC-VULN-05, and to the anchor Process item (coach-items-link).\n- **Step document** — attach the deployment record and the updated in-scope list as an XLSX workpaper on this step (coach-document-upload); the component inventory has no native Asset/Component item type, so it lives here. Track deployment progress with coach-workflow-scan.\n\n**Exit criteria** — Every newly in-scope component is either fully deployed and protected or covered by active interim compensating controls with a firm deployment date; the malware defense lead has confirmed this before the component is treated as covered.","label":"Deploy coverage to newly scoped components","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-workflow-scan","coach-document-upload"]}},"id":"deploy-coverage-to-newly-scoped-components"},{"data":{"decisionField":"readiness_disposition","description":"Approve evidence-based email/web rule, awareness and active-content authorization changes and judge actual fleet coverage, detection alerting and enforcement readiness.","formData":{"fields":[{"key":"readiness_disposition","label":"Readiness Disposition","options":[{"label":"Healthy, within tolerance","value":"healthy"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Approve evidence-based email/web rule, awareness and active-content authorization changes and judge actual fleet coverage, detection alerting and enforcement readiness.\n\n**Inputs**\n- Email-gateway and web-proxy filtering logs (initial inputs, independent of anti-malware coverage): spam and phishing catch rates, false-positive reports, and any confirmed phishing message that reached a user inbox despite filtering.\n- The current malware-and-phishing user-awareness content (guidance, phishing-recognition examples, reporting instructions).\n- This cycle's real phishing samples.\n- The current acceptable and unacceptable mobile-code technology register (scripting languages, browser plugins, macro types, and active content in documents and email) with each entry's last-review date and rationale — an initial input.\n- Browser, document-handling, and email-gateway configurations.\n- Threat guidance on active-content abuse.\n- The web-filtering platform (an initial input): category and reputation block statistics, override requests, and any confirmed access to a malicious or newly categorized site despite filtering.\n- Current reputation-feed updates and threat intelligence.\n- The business justifications attached to override requests.\n- The confirmed in-scope component inventory for the cycle (endpoints, servers, and system components commonly affected by malicious software) — an initial input of this standing operation; it arrives as the \"updated in-scope list\" document attached to the prior instance's close-and-archive step (there is no native Asset/Component item type, so the inventory lives in a document, not items).\n- The central anti-malware management console: managed-agent list, scan schedules and results, signature and engine versions, and tamper-protection settings — an external system queried live with coach-query-data.\n- The vendor's current signature and engine release baseline (external system).\n- The prior cycle's coverage exception list (carryover) plus any open Issue items (issue_type: exception/deficiency, source: self_assessment) it raised, linked to the anchor Process and Control UC-VULN-05.\n- The anti-malware detection log for the full cycle window and the on-call or SOC alert queue (external systems, queried directly with coach-query-data).\n- The response-SLA and escalation policy — a Policy item in the policy library (policy_type: standard/procedure, policy_owner), read as the governing threshold for alerting and escalation.\n- The reviewed scope decision plus the filtering and mobile-code deliverables from the parallel steps.\n\n**Procedure**\n_This checkpoint absorbs “Tune spam and phishing filtering; refresh awareness content”, “Maintain mobile-code technology authorizations”, “Tune website category and reputation filtering”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Tune spam and phishing filtering; refresh awareness content: Query email-gateway and web-proxy filtering logs with coach-query-data for spam and phishing catch rates, false-positive reports, and any confirmed phishing message that reached a user inbox despite filtering.\n2. Analyze exit-point traffic for filtering gaps — data-bearing messages to newly flagged domains or categories — and compile entry-and-exit tuning recommendations, naming the specific rule or reputation-list change proposed for each.\n3. Review the current user-awareness content — guidance, phishing-recognition examples, and reporting instructions — against this cycle's real phishing lures, and refresh it wherever the content is stale or does not reflect current lures.\n4. Package the proposed filter-rule changes and the refreshed awareness content and attach them with coach-document-upload.\n5. Maintain mobile-code technology authorizations: Pull the acceptable and unacceptable mobile-code list with coach-query-data, including the last-review date and rationale per technology.\n6. Query browser, document-handling, and email-gateway configurations with coach-query-data for mobile-code execution settings; reconcile them against the authorized list and flag any technology enabled that is not on the acceptable list.\n7. Compile evidence that unauthorized active content is blocked at the browser, document, and email layers — macro-blocking, script-execution policy, and sandboxing — and list any endpoint or mailbox where enforcement is missing or overridden.\n8. Draft the updated authorization list and the enforcement-gap findings and attach them with coach-document-upload.\n9. Tune website category and reputation filtering: Query the web-filtering platform with coach-query-data for category and reputation block statistics, override requests, and any confirmed access to a malicious or newly categorized site despite filtering.\n10. Cross-reference the blocked and allowed category lists against current reputation-feed updates and threat intelligence; identify categories or specific domains that need reclassification.\n11. Compile override requests with their business justification and a recommendation to approve, deny, or time-box each one.\n12. Draft the proposed category and reputation filtering policy changes and attach them with coach-document-upload.\n13. Review enforcement logs and classify readiness: Pull the console's managed-component list with coach-query-data and reconcile it against the in-scope inventory; list every in-scope component with no agent or reporting unhealthy or disconnected.\n14. Verify real-time protection is enabled and periodic full scans completed on schedule for each managed component; flag any component whose last full scan is older than its policy interval (for example, a missed weekly scan).\n15. Confirm signature and engine versions are current against the vendor's latest release and that automatic update is enabled fleet-wide; flag any agent more than one signature generation behind or with auto-update disabled.\n16. Confirm tamper protection is enforced so end users cannot disable, uninstall, or reconfigure the agent; flag any component where tamper protection is off, overridden by local admin, or unsupported by the platform.\n17. Compile the coverage-and-tamper exception list — affected component, gap type (no agent, stale scan, stale signature, or tamper off), and age — rank it by exposure, and attach it with the coverage reconciliation report.\n18. Query the detection log with coach-query-data for the cycle window; compile every detection with component, malware classification, disposition (quarantined, blocked, or requiring manual action), and timestamp.\n19. Verify each detection generated a responder alert; reconcile alert receipt against the on-call or SOC queue and flag any detection with no corresponding alert — a silent detection is the highest-severity finding.\n20. Identify detections left in a manual-action or unresolved state beyond the response SLA; compile them with age and assigned owner.\n21. Spot-check a sample of quarantine and block actions to confirm the file was actually contained rather than merely logged — for example, a quarantined path is no longer executable, or a blocked hash is absent from a re-scan.\n22. Assemble the detection-and-response log with per-detection disposition, alert linkage, and the unresolved-item list.\n23. Query enforcement-action logs with coach-query-data across mobile-code blocking, website category and reputation filtering, and email and web spam-phishing filtering; confirm every enforcement action this cycle is logged with component, action taken, and reason.\n24. Compute cycle metrics: anti-malware coverage percentage, tamper-protection exceptions, detection-to-alert completeness, spam and phishing catch rate, mobile-code enforcement-gap count, and website-filtering override rate — drawing on items 13–23 and on the reviewed scope, filtering, and mobile-code outputs.\n25. Build a capability-health dashboard with coach-dashboard-create showing each metric against its threshold and the trend against prior cycles.\n26. List every breach or unresolved exception — coverage, tamper, unalerted or over-SLA detection, mobile-code and website-filtering gaps — with its owner and the evidence behind it, and attach the readiness summary with coach-document-upload.\n27. Classify the cycle against the criteria below and submit the SELECT.\n\n**Decision criteria**\n- **healthy** — every cycle metric is within tolerance and logging is complete: anti-malware coverage at target (for example, 100% of in-scope components), zero unresolved tamper-protection exceptions, detection-to-alert completeness at 100%, spam and phishing catch rate at or above threshold, zero mobile-code enforcement gaps, and every enforcement action logged. Pick this only when all pass.\n- **gaps_identified** — any coverage exception, tamper-protection gap, unresolved detection beyond SLA, mobile-code enforcement gap, website-filtering lapse, or logging gap exists. Pick this when even one metric breaches or any enforcement action is unlogged.\n\n**Record in AssureSwarm**\n- **Step document** — attach the proposed filter-rule changes (XLSX) and the refreshed user-awareness content (DOCX) on this step (coach-document-upload). Filtering rules and awareness content have no native item type, so they live as versioned step documents.\n- **Step document** — attach the updated mobile-code authorization list (XLSX) and the enforcement-gap findings (DOCX) on this step (coach-document-upload). The authorization register is a working allowlist maintained by this operation, not a governance Policy item, so it lives as a versioned step document carried instance to instance.\n- **Step document** — attach the proposed web-content category and reputation filtering policy changes and the override dispositions (approve/deny/time-box with justification) as a DOCX/XLSX document on this step (coach-document-upload). Web-filtering policy is operational configuration with no native item type, so it lives as a versioned step document.\n- Submit the `readiness_disposition` SELECT (healthy or gaps_identified).\n- Record the rationale and evidence references in the step result and the decision owner in the step's approver record.\n- **Step documents** — attach the coverage reconciliation report with its coverage-and-tamper exception list, and the detection-and-response log, as XLSX workpapers on this step (coach-document-upload). These are the AssureSwarm home for per-component coverage and per-detection disposition: there is no native Asset/Component item type, so the reconciliation lives here rather than as item records, and console and detection data are pulled with coach-query-data from the external systems rather than stored as items.\n- Build the capability-health dashboard (coach-dashboard-create) and attach the readiness summary (coach-document-upload).\n\n**Exit criteria**\n- Entry- and exit-point tuning recommendations are specific and evidence-backed; awareness content is refreshed against real samples with a delivery plan that reaches affected users before the next cycle; the malware defense lead has approved the changes.\n- The acceptable and unacceptable list is current with dated rationale; unauthorized active content is confirmed blocked fleet-wide across the browser, document, and email layers or is exception-listed; the malware defense lead has approved any addition or removal from the authorized list.\n- Category and reputation changes are specific and feed-backed; each override request has a disposition (approve, deny, or time-box) with justification; the malware defense lead has approved the updated web-content filtering policy.\n- Every in-scope component is accounted for on the console, with scanning, signature currency, and tamper protection each confirmed or exception-listed with age; every cycle detection is logged with disposition and alert linkage, no silent detection remains unexplained, and unresolved-beyond-SLA items are listed with owner; the dashboard and logged enforcement actions are reviewed; the SELECT is submitted with rationale and owner recorded; when gaps_identified, each gap is itemized for corrective tracking; the unused branch is prunable.\n\n> **⚡ Audit Artist accelerator:** `/coach-dashboard-create` builds the capability-health dashboard — each cycle metric against its threshold with prior-cycle trend.","kind":"decision","label":"Review enforcement logs and classify readiness","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-dashboard-create"]}},"id":"review-enforcement-logs-and-classify-readiness"},{"data":{"description":"Agent converts each identified gap into an owned corrective action; human confirms every gap is owned, dated, and escalated where required","instructions":"**Objective** — Convert every gap identified across coverage, detection handling, mobile-code enforcement, and web filtering into an owned, dated corrective action so nothing degrades the defense capability unaddressed.\n\n**Inputs**\n- The readiness summary and its itemized gap list (this step consumes the gaps_identified decision output).\n- Root-cause context from the coverage, detection, filtering, and mobile-code deliverables.\n- Escalation routing and the accountable owners.\n\n**Procedure**\n1. Parse the readiness summary to list each gap with its root cause and the metric, component, or log that surfaced it.\n2. Create an Issue item for each gap with coach-item-create (issue_type: deficiency for a control-operation gap, source: self_assessment, severity, root_cause, issue_owner, target_remediation_date, remediation_plan capturing the interim mitigation); link it to the Control it affects (UC-VULN-05 or UC-NET-13) and to the anchor Process item with coach-items-link.\n3. Raise capability-level improvement items for systemic gaps — a chronic tamper-protection override pattern, a stale mobile-code authorization list, or persistent unlogged enforcement actions — and escalate any gap with compliance exposure to the accountable owner.\n4. Attach the corrective-action register with coach-document-upload.\n\n**Record in AssureSwarm**\n- **Item create** — one Issue per gap (issue_type: deficiency; source: self_assessment; severity; root_cause; issue_owner; target_remediation_date; remediation_plan) with coach-item-create.\n- **Item relationship** — link each Issue to the Control it affects (UC-VULN-05 or UC-NET-13) and to the anchor Process item (coach-items-link).\n- **Step document** — attach the corrective-action register as an XLSX rollup on this step (coach-document-upload).\n\n**Exit criteria** — Every identified gap has a named owner, due date, and interim mitigation; systemic gaps have capability-level items; compliance-exposed gaps are escalated; the malware defense lead has confirmed nothing is left untracked before closure.","label":"Log corrective actions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"log-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 signed operating record for the cycle: coverage reconciliation, detection-and-response log, scope decision, filtering and mobile-code deliverables, readiness classification, and any corrective-action register (this step consumes the healthy-branch readiness output or the corrective-action output — both terminal paths drain here).\n- The designated evidence repository and its retention policy.\n- The monthly cadence schedule.\n\n**Procedure**\n1. Export the full operating record with coach-workflow-export and archive it in the designated evidence repository under retention controls, recording the archive location and reference.\n2. Create carry-forward Issue items with coach-item-create for open corrective actions, pending newly-scoped-component deployments, and open filtering-override reviews (issue_type: finding, source: self_assessment, issue_owner, target_remediation_date); link each to its source Issue, to the Control (UC-VULN-05 / UC-NET-13), and to the anchor Process item with coach-items-link so it arrives as an explicit open item for the next cycle.\n3. Record the cycle result and key metrics in the closure record document and preserve them in the workflow instance history — Control items have no execution-log or last-operated field, so there is no item-field home for a \"control execution log\" update — and confirm the next monthly cadence review is scheduled.\n4. Attach the closure record with coach-document-upload.\n\n**Record in AssureSwarm**\n- **Workflow instance** — export the full signed operating record with coach-workflow-export; the run itself is the audit-trail of record, archived under retention.\n- **Item create** — carry-forward Issue items for open corrective actions, pending deployments, and open override reviews (issue_type: finding, source: self_assessment, issue_owner, target_remediation_date) with coach-item-create.\n- **Item relationship** — link each carry-forward Issue to its source Issue, to the Control (UC-VULN-05 / UC-NET-13), and to the anchor Process item so the next instance inherits it (coach-items-link).\n- **Step document** — attach the closure record (archive location and reference, cycle result, key metrics) on this step (coach-document-upload); the cycle result and metrics live here and in the workflow instance history, since Control has no execution-log field.\n\n**Exit criteria** — The archived record is immutable and retrievable under retention; carry-forward items are created and linked; the next monthly review is scheduled; every open item has its tracked owner and the authorized cycle record is complete.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-export` exports the full signed operating record for archival under retention controls.","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-malware-email-web-content-defense-operations"}