Skip to main content

Protocol Threat Modelling and Secure Boundaries

Competency Contract​

  • Primary competency: NC-NETWORKS-001
  • Mastery: explain, apply, develop, and evaluate as required by the semester assessment
  • Status: required evidence extension; budget 30–40 hours within the reconciled semester workload

Required Work​

Model assets, actors, trust boundaries, and protocol misuse; reason about TLS and authentication; capture adversarial network evidence; design secure service boundaries and recovery behavior.

Evidence Contract​

  • protocol threat model
  • packet trace
  • authentication failure test
  • least-privilege boundary
  • recovery proof.

Assessment Integration​

  • Project: produce the evidence in the semester repository rather than as detached prose.
  • Checkpoint: show the evidence exists and identify its highest-risk gap.
  • Cumulative review: connect the work to current, previous, and two-semesters-back knowledge.
  • Exam: evaluate a new case and reject an attractive but unsafe or unsupported alternative.
  • Rubric: every required evidence category must pass; strengths cannot average away a missing category.
  • Answer key: calibrate the shape of evidence without prescribing one implementation.

Oral Defense​

Walk one attack path from packet to process and defend the control and residual risk.

AI-Use Declaration​

Record tools and models used, material output accepted, rejected suggestions, and independent verification. Undeclared generated evidence fails the integrity gate.

Reading Route​

Start with the linked semester concepts and labs. Use local books selectively for conceptual depth and current official standards for normative requirements. Stop reading when you can produce and defend the required evidence.

Bounded service investigation​

Use the existing local semester service and disposable data. Draw client, TLS endpoint, request decoder, authentication check, authorization check, queue, worker and persistent storage. If TLS ends at a proxy, draw the proxy-to-process link separately. A secure channel and an authorized operation are different claims. Keep test credentials synthetic; redact them from logs and captures.

S1 — Protocol threat model (6–8 hours)​

Name assets (stored values, credentials, availability), actors and trust boundaries. Walk three concrete misuse paths: an oversized frame, a slow partial frame, and an authenticated caller targeting another caller's data. For each, name the input, vulnerable state, control, executable test and residual risk. A 1,024-byte message limit does not bound total memory if connection count or the work queue is unbounded. Calculate a conservative budget from concurrent connections, retained parser bytes, queued payloads and response buffers; list runtime overhead separately rather than claiming exact RSS.

S2 — Packet trace (6–8 hours)​

Capture only the local test exchange. Preserve capture command/filter, interface, endpoints, timestamps and tool versions. Annotate handshake, application traffic and close/reset where present; match these to application request identifiers and server logs. Explain which bytes are encrypted and which observations are still available. A TCP acknowledgment is evidence at transport level, not proof that a database commit happened. A socket-state snapshot may supplement but does not replace this strand's packet trace. Use the Wireshark guide below to choose a supported capture setup; if capture is unavailable, record the gap and complete it on an appropriate lab environment before passing S2.

S3 — Authentication failure test (8–10 hours)​

Using the service's chosen TLS library or local TLS terminator, demonstrate a successful verified connection and failures for an untrusted certificate and wrong server name. Preserve client error class and server observation; do not disable certificate validation to make the test pass. Then exercise missing credentials, invalid credentials, and valid credentials with insufficient permission for one operation. Assert rejected requests cause no protected state change; compare state before and after. Test valid authorized access as the positive control. Record where each failure occurs: handshake, identity check or operation authorization. If your implementation lacks an authorization policy, define the smallest explicit policy before testing it.

S4 — Least-privilege boundary (4–6 hours)​

Run the service under an unprivileged identity on a high local port with a dedicated data directory. Record identity and permissions. Demonstrate an allowed write inside that directory and a denied access to a separate test fixture owned or protected by a different boundary. Use disposable fixtures, not personal files. Ordinary Unix permissions do not confine access to all other readable files: explicitly document that residual exposure. If using a container, explain identity mapping and mounts; the label “containerized” alone earns no credit.

S5 — Recovery proof (6–8 hours)​

Reuse the Module 04 crash matrix, then add a real process-termination test of the service. Keep an external client observation log. For each selected cut, compare acknowledged operations with recovered state and classify unacknowledged operations as absent, present or unknown under the declared contract. Distinguish process termination from machine power loss; the kernel page cache can survive the former. Repeat recovery to check idempotence. Include a lost-response case and explain why retry may duplicate an effect without a durable request-identity policy. Do not claim real-device power-loss safety from the abstract redo lab or a killed process.

Calibration and repair​

Score S1–S5 separately using the progression contract. A list of security words, screenshot without interpretation, or disabled certificate verification is below level 2. Passing evidence links prediction, test, observation and a bounded conclusion. Strong evidence challenges a control with a fresh case and explains the remaining exposure.

For example, “TLS makes retries safe” fails. A passing explanation separates channel protection from application state and shows a request whose reply is lost after persistence. A stronger explanation proposes durable deduplication, names the atomicity requirement, and leaves its implementation for the database work rather than treating an in-memory set as crash-safe.

Use the two-hour semester defense to walk one misuse path from packet to process and one crash path from durable state to client uncertainty. After 48 hours, independently retest the weakest category. Keep an assistance declaration with accepted and rejected suggestions; generated logs presented as observed output fail integrity.

Selective primary resources​

  • OWASP Threat Modeling: use the four questions to structure S1; stop when each chosen threat has a testable control and residual risk.
  • TLS 1.3, RFC 8446: consult the protocol overview and authentication sections for the channel/identity explanation. Optional 0-RTT reading adds a replay-risk discussion; implementing TLS yourself is outside scope.
  • Wireshark User's Guide, introduction: follow the platform and capture guidance for S2. Learn filtering and packet interpretation, not every dissector.

Continue the semester's OSTEP, Computer Networking: A Top-Down Approach and Unix Network Programming selections for persistence and socket mechanics. These are supporting references, not three additional cover-to-cover assignments. No new purchase is necessary to start this strand.