# Zones, conduits and trust boundaries

Review a fictional plant diagram using an actual local JSON model. Distinguish what DMZ, control and safety boundaries establish and what remains unproven.

Original AI-assisted SecNet educational content. Fictional local examples; not a standards provider publication, endorsement or compliance evidence. Page exercises do not create account progress.

Sources checked: 2026-10-21

## A layered drawing is not an access policy

Harbor contains a planning workstation, industrial DMZ jump host, operations station, controller and separate safety zone. Layered drawings help communication; no single topology is mandatory for every site. Define zones through shared security requirements and risk context. Devices drawn on the same layer need not share trust. Separately assess how network and identity controls implement each boundary. Reducing process and safety dependencies to IP subnets can conceal functional relationships and common failure risks. A tidy diagram is only one input to an engineering and security review.

## Conduit purpose and direction

A conduit expresses communication needs across zones in a controlled design. Record source/destination, purpose, initiating direction, required service, owner and review reference. An open port does not establish business need or trusted identity. Each arrow in the Harbor JSON exercise is a declared directed connection; response traffic is not inferred. The tool evaluates no real protocol, port, firewall order, route, NAT or state tracking. This deliberate scope lets learners examine a logical path without mistaking a drawing result for a device configuration assessment.

## Separate security levels from safety

Security level SL in the IEC 62443 context and functional-safety SIL are different concepts and cannot be converted into one another. Writing a level on a zone does not show its target requirements are satisfied. Record the target, scope and assessment evidence separately. Authorized safety engineering evaluates safety-system independence and the effect of connections. This original exercise reproduces no standard text or licensed requirements list and provides no conformity assessment, SL/SIL assignment or accredited-training claim. Real standards-based work also requires the relevant licensed edition.

## Interpret the local path review

Compare the two synthetic files: a declared DMZ route and an alternative with a direct shortcut. Across enabled arrows, the tool seeks the shortest path and the shortest path excluding DMZ assets per enterprise/external source and control target. It separately lists arrows lacking review references and safety-boundary connections. A reference does not verify a document. Finding no path is not proof of isolation; missing inventory and undeclared connections remain outside the model. The output is a set of questions and evidence IDs for an owner, not an instruction to disconnect a real process.

## Working sequence

1. Define zones by function and risk.
2. Record declared arrows with purpose and owner.
3. Compare both synthetic models in the local desk.
4. Explain bypasses, missing reviews and safety boundaries.
5. Record model limits and evidence needed for a real site.

## 1. Drawn boundary

A diagram establishes neither risk rationale nor implemented controls. Without flow ownership and authorized safety-boundary review, colored boxes remain architectural assumptions.

This code is a local policy model; it does not replace actual equipment, process or safety assessment.

### Weak implementation
```js
s => s.diagramExists === true
```

### Corrected implementation
```js
s => s.diagramExists === true &&
  s.riskRationale === true &&
  s.flowsOwned === true &&
  s.safetyBoundaryReviewed === true
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "documented-case",
      "input": {
        "diagramExists": true,
        "riskRationale": true,
        "flowsOwned": true,
        "safetyBoundaryReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-riskRationale",
      "input": {
        "diagramExists": true,
        "riskRationale": false,
        "flowsOwned": true,
        "safetyBoundaryReviewed": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "missing-safetyBoundaryReviewed",
      "input": {
        "diagramExists": true,
        "riskRationale": true,
        "flowsOwned": true,
        "safetyBoundaryReviewed": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "documented-case",
      "input": {
        "diagramExists": true,
        "riskRationale": true,
        "flowsOwned": true,
        "safetyBoundaryReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-riskRationale",
      "input": {
        "diagramExists": true,
        "riskRationale": false,
        "flowsOwned": true,
        "safetyBoundaryReviewed": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "missing-safetyBoundaryReviewed",
      "input": {
        "diagramExists": true,
        "riskRationale": true,
        "flowsOwned": true,
        "safetyBoundaryReviewed": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 2. From port to business need

A port list is insufficient. Scope communication purpose, initiating direction and review references; the presence of a model reference does not verify a real document.

This code is a local policy model; it does not replace actual equipment, process or safety assessment.

### Weak implementation
```js
s => s.portListed === true
```

### Corrected implementation
```js
s => s.portListed === true &&
  s.purposeDefined === true &&
  s.directionScoped === true &&
  s.reviewReference === true
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "documented-case",
      "input": {
        "portListed": true,
        "purposeDefined": true,
        "directionScoped": true,
        "reviewReference": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-directionScoped",
      "input": {
        "portListed": true,
        "purposeDefined": true,
        "directionScoped": false,
        "reviewReference": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "missing-reviewReference",
      "input": {
        "portListed": true,
        "purposeDefined": true,
        "directionScoped": true,
        "reviewReference": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "documented-case",
      "input": {
        "portListed": true,
        "purposeDefined": true,
        "directionScoped": true,
        "reviewReference": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-directionScoped",
      "input": {
        "portListed": true,
        "purposeDefined": true,
        "directionScoped": false,
        "reviewReference": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "missing-reviewReference",
      "input": {
        "portListed": true,
        "purposeDefined": true,
        "directionScoped": true,
        "reviewReference": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 3. SL is not SIL

A level label does not meet a security target and cannot be equated with a safety integrity level. Require scope and separate engineering assessments; this exercise assigns neither SL nor SIL.

This code is a local policy model; it does not replace actual equipment, process or safety assessment.

### Weak implementation
```js
s => s.levelNamed === true
```

### Corrected implementation
```js
s => s.levelNamed === true &&
  s.securityTargetDefined === true &&
  s.safetyDistinct === true &&
  s.assessmentScoped === true
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "documented-case",
      "input": {
        "levelNamed": true,
        "securityTargetDefined": true,
        "safetyDistinct": true,
        "assessmentScoped": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-safetyDistinct",
      "input": {
        "levelNamed": true,
        "securityTargetDefined": true,
        "safetyDistinct": false,
        "assessmentScoped": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "missing-assessmentScoped",
      "input": {
        "levelNamed": true,
        "securityTargetDefined": true,
        "safetyDistinct": true,
        "assessmentScoped": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "documented-case",
      "input": {
        "levelNamed": true,
        "securityTargetDefined": true,
        "safetyDistinct": true,
        "assessmentScoped": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-safetyDistinct",
      "input": {
        "levelNamed": true,
        "securityTargetDefined": true,
        "safetyDistinct": false,
        "assessmentScoped": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "missing-assessmentScoped",
      "input": {
        "levelNamed": true,
        "securityTargetDefined": true,
        "safetyDistinct": true,
        "assessmentScoped": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## Exit evidence

- Versioned zone/conduit draft and business needs.
- Path IDs, open questions and authorized review owners.

## References

- [NIST SP 800-82 Rev.3 · Final September 2023](https://csrc.nist.gov/pubs/sp/800/82/r3/final)
- [NCSC and partners · Maintaining a definitive view of OT architecture · October 2025](https://www.cyber.gov.au/sites/default/files/2025-10/ncsc-creating-and-maintaining-a-definitive-view-of-your-operational-technology-architecture.pdf)
- [NIST SP 800-82 Rev.4 · Initial public draft, NOT final · September 2026](https://csrc.nist.gov/pubs/sp/800/82/r4/ipd)