{"description":"Network Segmentation & Boundary Rule Management as a decision-aware operator workflow covering trust-zone maintenance, gated rule-change implementation, boundary threat monitoring, the quarterly segmentation and rule-set review, and cross-domain exchange-policy enforcement. This cycle runs on the EXISTING boundary-protection Control item (domains network_communications_security; framework NIST 800-53, NIST CSF 2.0, ISO 27001, SOC 2; frequency quarterly; the boundary control owner as control_owner) — each quarterly run is one workflow instance attached to and enriching that Control, never a new control record. In scope: the trust-zone model, the managed interfaces (firewalls, gateways, proxies) mediating traffic between zones, the external boundary and key internal boundaries, and the cross-domain interconnection points, all under a deny-by-default baseline (NIST 800-53 SC-7, SC-16, SC-46; NIST CSF 2.0 PR.IR-01; ISO 27001 A.8.22; SOC 2 CC6.6). No upstream workflow feeds this cycle; it self-seeds from its own prior-cycle carry-forward — open corrective-action Issue items linked to the Control plus the prior run's closure record and archived rule-change record log. Named deliverables: the reconciled trust-zone model, the verified rule-change record log, the boundary threat-monitoring summary, the cross-domain exchange-policy enforcement report, the quarterly segmentation & rule-set review report, the boundary-posture dashboard, and corrective-action Issues linked to the Control. Downstream, it hands off only to its own next cycle via the carry-forward closure record; a confirmed intrusion is escalated to the incident-response workflow (out of scope), as are host/endpoint controls.","edges":[{"id":"e-process-boundary-change-requests-implement-and-verify-rule-changes","label":"Approved","source":"process-boundary-change-requests","target":"implement-and-verify-rule-changes","whenValue":"approved_implement"},{"id":"e-process-boundary-change-requests-rework-rejected-change-requests","label":"Rework","source":"process-boundary-change-requests","target":"rework-rejected-change-requests","whenValue":"returned_for_rework"},{"id":"e-implement-and-verify-rule-changes-run-periodic-segmentation-and-rule-set-review","source":"implement-and-verify-rule-changes","target":"run-periodic-segmentation-and-rule-set-review"},{"id":"e-rework-rejected-change-requests-run-periodic-segmentation-and-rule-set-review","source":"rework-rejected-change-requests","target":"run-periodic-segmentation-and-rule-set-review"},{"id":"e-run-periodic-segmentation-and-rule-set-review-close-and-archive","label":"Healthy","source":"run-periodic-segmentation-and-rule-set-review","target":"close-and-archive","whenValue":"healthy"},{"id":"e-run-periodic-segmentation-and-rule-set-review-remediate-and-log-rule-set-gaps","label":"Gaps","source":"run-periodic-segmentation-and-rule-set-review","target":"remediate-and-log-rule-set-gaps","whenValue":"gaps_identified"},{"id":"e-remediate-and-log-rule-set-gaps-close-and-archive","source":"remediate-and-log-rule-set-gaps","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-NET-01","UC-NET-14","UC-DATA-11"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-network-segmentation-boundary-rule-management","contentDigest":"sha256:b3e7dfe095f4f6ac9eb3dee98f171c19585678c068d46b38bb7e5a009a0c80d3","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:b3e7dfe095f4f6ac9eb3dee98f171c19585678c068d46b38bb7e5a009a0c80d3","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-network-segmentation-boundary-rule-management"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-network-segmentation-boundary-rule-management","source":"coworkcanvas-gallery","standards":["nist-800-53","nist-csf-2","iso-27001","soc2"],"teams":["it"]},"name":"Network Segmentation & Boundary Rule Management","nodes":[{"data":{"decisionField":"change_disposition","description":"Agent reconciles assets against the trust-zone model and evaluates each queued rule-change request against the reconciled model and the deny-by-default baseline; human decides how the batch is disposed","formData":{"fields":[{"key":"change_disposition","label":"Change Disposition","options":[{"label":"Approved, implement","value":"approved_implement"},{"label":"Returned for rework","value":"returned_for_rework"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Reconcile the estate against the trust-zone model, then decide how the batch of queued boundary rule-change requests is disposed (implement or return for rework), so no firewall, gateway, or proxy change reaches a managed interface unless it is justified, scoped to a zone model that still matches current trust level, sensitivity, and function, and consistent with deny-by-default. Owned by the boundary control owner.\n\n**Inputs**\n- The anchor: the existing boundary-protection **Control** item this quarterly instance is attached to (control_owner, framework, and the SC-7/SC-16/SC-46 · PR.IR-01 · A.8.22 · CC6.6 citations carried in Control.framework and Control.description) — enriched, not recreated.\n- The trust-zone model register: zones, their sensitivity/function basis, and the zone-to-interface mapping showing which managed interface mediates each zone boundary — carried as a document (XLSX) on this step, latest version from the prior cycle's archive. There is no native Network Zone / Interface item type, so the register stays a step document.\n- The asset inventory, data-classification register, and system function/criticality tags — extracted from external CMDB/asset tooling and uploaded at this step. There is no native Asset item type, so these are step uploads rather than linked items.\n- Prior-cycle carry-forward: open corrective-action **Issue** items from the prior cycle (issue_type deficiency/finding, source self_assessment) still linked to the anchor Control, surfaced via the prior run's closure record and archived rule-change record log. No upstream workflow feeds this step — the cycle self-seeds.\n- The change-queue extract uploaded to this step (CSV/XLSX exported from the ticketing / firewall-change system — there is no native Change Request item type), plus the open rule-change record log.\n\n**Procedure**\n_Items 1–7 are agent-run (items 1–5 folded from the former \"Maintain the trust-zone model\" step); the human moment is the disposition call in item 8._\n1. Pull the asset inventory, data-classification register, and function/criticality tags, and join them against the current zone assignments in the trust-zone model.\n2. Flag drift in three categories: (a) assets whose sensitivity, function, or criticality changed since their last zone assignment; (b) newly deployed systems with no zone assignment; (c) decommissioned systems still occupying a zone.\n3. For each flagged asset draft a proposed zone reassignment stating the trust level, sensitivity, and function basis for the target zone. Do not co-locate assets of materially different sensitivity in one zone.\n4. Refresh the zone-to-interface mapping so every zone boundary names the managed interface (firewall, gateway, or proxy) that mediates its traffic; flag any boundary with no mediating interface (an unsegmented adjacency) as a finding.\n5. Assemble the drift report listing each flagged asset, its category, and the proposed reassignment, with a running count of unresolved items. This reconciled zone model is the baseline the requests below are judged against.\n6. From the change-queue extract, pull every open rule-change request with its requestor, business justification, source/destination zones, interface, requested rule (protocol, port, direction), and requested expiration/review date.\n7. Evaluate each request against the reconciled zone model and the deny-by-default baseline, flagging any request broader than the stated business need (an any-any or any-port rule), lacking an expiration date, or lacking a named business owner; cross-reference the open rule-change record log for duplicate or conflicting requests on the same interface.\n8. Dispose the batch against the criteria below and submit the SELECT.\n\n**Decision criteria**\n- Pick **approved_implement** when every request in the batch is justified, scoped no broader than the business need, carries an expiration/review date and a named owner, and is consistent with deny-by-default — and every flagged asset in the zone-model drift report is resolved to a confirmed zone or an owned reassignment action.\n- Pick **returned_for_rework** when any request needs tightening, an expiration date, or a named owner before it can proceed.\n- Standards: NIST 800-53 SC-7 (deny-by-default boundary protection); NIST CSF 2.0 PR.IR-01; ISO 27001 A.8.22; SOC 2 CC6.6.\n\n**Record in AssureSwarm**\n- Submit the `change_disposition` SELECT (approved_implement or returned_for_rework). In the step result record the specific concern noted against each flagged request plus evidence references; set the step's approver record to the approver.\n- Step document — attach the reconciled trust-zone model (the updated zone-model register plus the drift report with proposed reassignments, XLSX/PDF) and the disposition recommendation to this step. There is no native Network Zone or Asset item type, so zone reassignments are captured inside the register document rather than as item-to-item links; the durable anchor for the cycle stays the Control item this instance is attached to.\n\n**Exit criteria** — Every flagged asset is resolved to a confirmed zone or an owned reassignment action and the zone-to-interface mapping has no unmediated boundary left unflagged; the routing selector is submitted and the step result contains a rationale naming every flagged request; the unused branch is prunable.","kind":"decision","label":"Process boundary change requests","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"process-boundary-change-requests"},{"data":{"description":"Agent stages the approved changes into the rule-change record, coordinates implementation, and verifies deployed rules match what was approved; human confirms no unauthorized drift","instructions":"**Objective** — Turn approved change requests into deployed rules on the managed interfaces with a verifiable rule-change record and no drift between what was approved and what is live.\n\n**Inputs**\n- The approved batch and its per-request rationale from the change-disposition decision (approved_implement branch).\n- The confirmed trust-zone model and the deny-by-default baseline.\n- Live configuration read access to each affected firewall, gateway, or proxy.\n\n**Procedure**\n1. Add a rule-change record row for each approved request capturing interface, source/destination zones, rule detail (protocol, port, direction), approver, and expiration date, keyed to its originating request's ID.\n2. Package the approved rule set per interface and route it for implementation, recording the implementer and the implementation timestamp. Keep segregation of duties: the approver and the implementer should not be the same person.\n3. After implementation, re-query the live configuration of each affected interface and diff it line by line against the approved rule-change records.\n4. Verify the external boundary and key internal boundaries still deny by default outside the newly approved exceptions — confirm no broadened, out-of-band, or leftover temporary rule slipped in.\n5. Flag any deployed line with no matching approved record as unauthorized drift and stage it for immediate removal.\n\n**Record in AssureSwarm** — Step document: the verified rule-change record log (XLSX, one row per record — interface, source/destination zones, rule detail (protocol/port/direction), approver, implementer, implementation timestamp, expiration date) with the per-interface implementation diffs and drift-check evidence attached to this step. There is no native Rule-Change Record or Change Request item type, so each 'record' is a row in this log keyed to its request ID rather than a linked item — the log document is the change-governance evidence, hung off the anchor Control for the cycle.\n\n**Exit criteria** — Every deployed rule matches its approved record exactly; deny-by-default holds outside the approved exceptions; no unauthorized rule remains; the control owner has confirmed no drift before the change is closed.","label":"Implement and verify rule changes","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-query-data","coach-document-upload"]}},"id":"implement-and-verify-rule-changes"},{"data":{"description":"Agent routes returned requests back to requestors with the specific gap and tracks resubmission or withdrawal; human confirms none are left open without disposition","instructions":"**Objective** — Resolve every returned-for-rework request to a clean resubmission or a documented withdrawal so the change queue does not accumulate stale, ungoverned requests.\n\n**Inputs**\n- The returned batch and the per-request gap notes from the change-disposition decision (returned_for_rework branch).\n- The original change-request records and their requestors.\n\n**Procedure**\n1. Parse the disposition rationale into a list of each returned request with its specific gap: missing expiration date, no named owner, or scope broader than the stated business need.\n2. Notify each requestor of the specific gap and the corrected fields required; record the notification against the original request's ID in the rework log.\n3. Track resubmissions and withdrawals against a short deadline (for example 10 business days); compile the list of requests still unresolved past the deadline for escalation to the control owner.\n4. Confirm each resubmitted request is corrected before it re-enters the next disposition pass; record each withdrawal with its reason.\n\n**Record in AssureSwarm** — Step document: the rework log (XLSX) attached to this step — one row per returned request with its gap, the notification sent, and its resubmission-or-withdrawal status. There is no native Change Request item type, so requestor notifications are recorded as rows in this log keyed to each request's ID rather than as linked items.\n\n**Exit criteria** — Every returned request ended in a corrected resubmission ready for the next disposition pass or a documented withdrawal; none left open and undecided; any overdue item escalated to the control owner.","label":"Rework or close rejected requests","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-workflow-scan","coach-document-upload"]}},"id":"rework-rejected-change-requests"},{"data":{"decisionField":"boundary_posture","description":"Disposition real boundary threats and judge full rule-set, cross-domain label preservation and guard enforcement against the approved zone model.","formData":{"fields":[{"key":"boundary_posture","label":"Boundary Posture","options":[{"label":"Healthy, fully evidenced","value":"healthy"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Disposition real boundary threats and judge full rule-set, cross-domain label preservation and guard enforcement against the approved zone model.\n\n**Inputs**\n- Logs and alerts from every in-scope managed interface (firewalls, gateways, proxies) for the monitoring period, covering the external boundary and the key internal boundaries.\n- Current threat-intelligence indicators (known-bad destinations, malicious ports/protocols).\n- Open incident and rule-change records, and open workflows (to avoid duplicate cases). This is an independent standing duty that starts from these inputs, not from another checkpoint's output.\n- The inventory of cross-domain interconnection points: each guard, cross-domain solution, or gateway mediating exchange between security domains, with its configured guard rules and the information types it is authorized to pass — uploaded as an extract at this step (no native interconnection item type).\n- The mandatory exchange policy (authorized data types and permitted flow directions per interconnection) — held as a **Policy** item (policy_type standard, policy_owner, framework nist-800-53, domains network_communications_security, review_frequency + next_review_date), with the governing policy text attached to that Policy item.\n- The complete current rule set for every managed interface, the confirmed trust-zone model, the quarter's rule-change record log, and this cycle's boundary threat-monitoring summary.\n\n**Procedure**\n_This checkpoint absorbs “Monitor boundary traffic for threats”. 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. Monitor boundary traffic for threats: Query denied and permitted traffic from every in-scope managed interface for the period.\n2. Correlate against current threat-intelligence indicators; flag protocol/port anomalies, traffic to or from known-bad destinations, and patterns consistent with scanning, command-and-control, or exfiltration.\n3. Cross-reference each flagged event against open incident and rule-change records to determine whether it is already tracked or a new exposure; scan open workflows to avoid opening a duplicate case.\n4. For each flagged event decide a disposition: benign (documented), handled directly (record the action taken), or escalate to the incident-response workflow (record the ticket reference).\n5. Run periodic segmentation and rule-set review: Pull the cross-domain interconnection inventory with each guard's configured rules and authorized information types.\n6. For a sample of exchanged information at each interconnection point, verify the security/privacy attributes (labels) attached at the source are present and unaltered at the receiving domain; flag any interconnection where labels are stripped, downgraded, or missing.\n7. Test each guard's enforcement by comparing configured rules against the mandatory exchange policy: confirm only authorized data types and permitted flow directions are allowed and every other combination is denied (deny-by-default across domains).\n8. For any gap — label loss or an over-permissive guard rule — record the interconnection point, the specific failure, and the exposure for remediation.\n9. Pull the complete current rule set for every managed interface and compare it against the confirmed trust-zone model, flagging overly permissive rules (any-any, any-port), rules past their expiration/review date, rules with no linked rule-change record, and rules referencing decommissioned systems or zones.\n10. Reconcile the quarter's rule-change records against implemented changes so every deployed rule traces to an approved, evidenced record.\n11. Roll up this cycle's monitoring findings and the cross-domain results from items 5–8 alongside the rule-set findings, and build a boundary-posture dashboard showing findings by interface and severity against the prior-quarter trend.\n12. Classify the posture against the criteria below and submit the SELECT.\n\n**Decision criteria**\n- Pick **healthy** when the rule set is fully evidenced by rule-change records with no unauthorized-scope or stale rules, and cross-domain enforcement holds — label preservation and guard-rule enforcement confirmed at every interconnection point.\n- Pick **gaps_identified** when any overly permissive rule, untraceable rule, stale rule, label-preservation failure, or over-permissive guard rule exists.\n- Standards: NIST 800-53 SC-7; SC-16 (transmission of security/privacy attributes); SC-46 (cross-domain).\n\n**Record in AssureSwarm**\nStep document: the boundary threat-monitoring summary (XLSX/PDF) attached to this step, listing every flagged event and its disposition (benign / handled / escalated). Item create + relationship: for each event escalated to incident response, an **Issue** (issue_type finding, source management_identified, severity per event, identified_date, the incident-response ticket reference in Issue.description) linked to the anchor Control. There is no native Incident item type, so the escalation is tracked as a Control-linked Issue while the live case runs in the incident-response workflow.\n- Step form: submit the `boundary_posture` SELECT (healthy or gaps_identified), record findings and evidence references in the step result, and set the step's approver record.\n- Step document: attach the cross-domain exchange-policy enforcement report (XLSX/PDF listing each interconnection point with its label-preservation result and its guard-rule enforcement result against the exchange Policy) and the quarterly segmentation & rule-set review report (PDF/XLSX with full rule-set findings by interface and severity).\n- Dashboard: create/refresh the boundary-posture dashboard (findings by interface/severity vs prior-quarter trend).\n\n**Exit criteria**\n- Every flagged event investigated and closed as benign, handled directly, or escalated with a reference; the control owner has confirmed no open external threat is left untracked.\n- Label preservation and guard-rule enforcement are confirmed at every cross-domain interconnection point or every gap is captured for remediation; the routing selector is submitted and the step result contains a rationale referencing the rule-change record log; the unused branch is prunable.","kind":"decision","label":"Run periodic segmentation and rule-set review","performedBy":{"primitives":["coach-query-data","coach-workflow-scan","coach-item-create","coach-items-link","coach-document-upload","coach-dashboard-create"]}},"id":"run-periodic-segmentation-and-rule-set-review"},{"data":{"description":"Agent converts every finding into an owned corrective action and tracks it to closure; human confirms every gap is owned, dated, and closed or escalated","instructions":"**Objective** — Convert every gap the periodic review identified into a tracked, owned corrective action so no overly permissive rule, untraceable change, or cross-domain enforcement gap survives unaddressed into the next quarter.\n\n**Inputs**\n- The periodic review report (gaps_identified branch) with each finding's interface, zone, and root cause.\n- The rule-change record log and the corrective-action register.\n\n**Procedure**\n1. Parse the periodic review report into a list of findings, each with its interface, zone, and root cause.\n2. Create a corrective-action item for each finding capturing the required fix (tighten scope, add expiration, retire the rule, or correct guard configuration), owner, and due date; link it to the driving finding.\n3. For any finding involving an unauthorized or out-of-band rule, initiate immediate removal or restriction ahead of the standard remediation timeline and record the interim mitigation applied.\n4. Set due dates by severity (for example unauthorized-scope rules resolved immediately; stale or undocumented rules within the next cycle).\n\n**Record in AssureSwarm** — Item create + relationship: one **Issue** per gap (issue_type deficiency or finding, source self_assessment, severity by exposure, issue_owner, identified_date, target_remediation_date; remediation_plan = the required fix including any interim mitigation) linked to the anchor Control so open Issues self-seed the next cycle. Step document: the corrective-action register (XLSX) with per-finding tracking status attached to this step.\n\n**Exit criteria** — Every gap has a named owner and a due date; every high-risk gap has an interim mitigation already applied; the control owner has confirmed nothing is left unowned before close.","label":"Remediate and log rule-set gaps","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"remediate-and-log-rule-set-gaps"},{"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 full operating record: the rule-change record log, the monitoring summary, the cross-domain enforcement report, and the periodic review report and dashboard.\n- Open corrective actions and unresolved change requests, plus the next quarterly review date.\n\n**Procedure**\n1. Export the full operating record and archive it in the designated evidence repository under retention controls; record the archive location and reference.\n2. Create carry-forward items for any open corrective actions, unresolved change requests, and the next quarterly review date; link them to their source so they arrive as explicit inputs to the next cycle.\n3. Update the control execution log with the cycle result and key metrics (change volume, monitoring findings, cross-domain results, review outcome).\n4. Confirm the archived record is immutable and retrievable.\n\n**Record in AssureSwarm** — Workflow instance: export and archive the full operating record via workflow export as the durable audit trail (the run itself). Item relationship: the carry-forward items are the still-open corrective-action **Issue** items, kept linked to the anchor Control so they self-seed the next cycle. Step document: the closure record (listing open Issues, unresolved change requests, and the next quarterly review date) attached to this step and consumed by the next cycle's trust-zone-maintenance step as its handoff package.\n\n**Exit criteria** — The archived record is immutable and retrievable; every open item has a tracked owner carried into the next cycle; the authorized cycle record is complete.","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-network-segmentation-boundary-rule-management"}