How it is created — ENG-DES-033 Minimal Attack-Surface Design Plan

1. What this artifact decides

For every interface, service, port and protocol in the planned system: is it needed for the intended function, and if not, is it removed or merely disabled? The order matters — removed beats disabled, disabled beats undocumented. A product that ships a vendor demo task nobody linked out is carrying an obligation it never chose.

Doing this early is the difference between designing a small surface and trimming a large one later, which never fully succeeds.

2. Inputs

• The attack-surface inventory from the threat model (section 3 of that document) — this process consumes it rather than rebuilding it.
• The intended function, stated precisely enough to judge "needed" against.
• The vendor SDK's default services and the capabilities present in the chosen silicon, including the ones your product does not use.

3. Steps

1. One row per interface, service or protocol. Include what the silicon offers but the product does not use — an unused radio mode is part of the surface until it is provably absent from the firmware and the antenna path.
2. Answer "needed for the intended function?" in a single word, then pick the decision: keep, keep-constrained, disable by default, or remove.
3. Write an implementation rule per row, not an intention. "Compiled out of the production build, verified by a build-flag audit in CI" is a rule. "Should not be enabled" is not.
4. For everything kept, state the constraint: authenticated frames only, signed images only, a commissioning window opened by a physical button with a timeout, broadcast accepted only for an authenticated time-sync beacon.
5. Extract the architectural consequences and route them now. A commissioning button is an input to mechanical design. An end-of-line debug fuse lock is an input to the production test plan. Removing a radio affects the antenna layout — and makes accidental later enablement physically ineffective. These three sentences are why the artifact belongs in pre-development.
6. Make it enforceable in CI. A surface-audit stage that scans the production build for forbidden symbols and services and fails the build on a hit. A decision table that only humans check will erode.
7. Connect it to the release gate. The table is the normative source for the Attack Surface Document that ships with the technical documentation, and the secure-defaults checklist verifies the as-shipped unit against it.
8. Define what happens to new interfaces: any addition during development triggers a delta threat-model workshop before implementation.

4. Done when

• Every entry in the attack-surface inventory appears with a decision and an implementation rule.
• The consequences for mechanics and production have owners and dates.
• CI can fail on a violation.
• The Attack Surface Document is generated from this table, not written separately.

5. Common mistakes

Listing only the interfaces the product uses. Choosing "disable" where "remove" is possible, because disabling is one line of configuration away from being undone. Writing the table and then never wiring it to a build check or a release check, which leaves it as an aspiration.

6. In TRA Studio

The interfaces and their default states belong to the product model — conduits, components and the mitigations attached to them. The design decisions here become mitigations traceable back to the threats that motivated them, which is what an auditor follows.