Chapter 28 — Security architecture and engineering: implementation I | Engineering Security architecture and engineering

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 28 — Security architecture and engineering: implementation I

Lesson map

Lesson 28 published. Map, example, EX082.

flowchart TD
  N0["Learning outcomes"]
  N1["28.1 From architecture to tasks"]
  N2["28.2 Configuration and secrets"]
  N3["28.3 Staying aligned"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX082"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["28.1 From architecture to tasks"]
  N2["28.2 Configuration and secrets"]
  N3["28.3 Staying aligned"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX082"]

[Learning outcomes]
    |
    v
[28.1 From architecture to tasks]
    |
    v
[28.2 Configuration and secrets]
    |
    v
[28.3 Staying aligned]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX082]

Learning outcomes

You will (1) translate architecture into implementation tasks; (2) apply secure configuration and secrets handling; (3) keep implementation aligned with the architecture.

28.1 From architecture to tasks

Sofia's team begins implementing the back-office ingestion component. She breaks the architecture into tasks: certificate-based device authentication, record schema validation, replay detection with a store of recent record identifiers, signed-record verification and structured logging. Each task references the requirement and control specification it implements and includes acceptance tests. This prevents the common drift in which developers implement what is easy and the architecture's harder controls are quietly postponed. Task references also let reviewers check coverage: every requirement should map to at least one completed task.

28.2 Configuration and secrets

The ingestion service needs a private key for its TLS server certificate and credentials for its database. Sofia ensures neither is stored in source code or container images. Secrets come from a managed secret store at runtime, readable only by the service's identity, and are rotated on a schedule. Configuration is version-controlled and reviewed, with security-relevant settings such as TLS versions and allowed certificate issuers checked automatically against the specification. She finds a test credential committed in an early branch, removes it from history and has it rotated, recording the incident.

28.3 Staying aligned

During implementation the team discovers that replay detection needs more memory than expected at peak load. A developer proposes skipping it during peaks. Sofia raises it as an architecture change, not a coding decision, because it weakens a requirement. The team instead uses a time-bounded store keyed by record identifier and validator, which fits memory limits. She updates the architecture record and the specification. Daniel stresses that implementation always teaches something; the discipline is to feed that learning back into the architecture rather than letting the built system silently diverge.

Worked example

Sofia maps ingestion requirements to five implementation tasks, moves secrets to a managed store, handles a committed test credential and routes a replay-detection change through architecture review.

Synthetic case. The ingestion component and incident are synthetic.

Errors and limits

Secret stores become critical dependencies needing high availability. Removing secrets from history does not undo exposure; rotation is still required.

Exercises

EX082 — Task references. Why does each task reference a requirement? Rubric: 3 = prevents postponing hard controls and lets reviewers check coverage;; 2 = coverage;; 1 = vague;; 0 = none.
EX083 — Committed credential. What steps followed finding a committed test credential? Rubric: 3 = removed from history and rotated, incident recorded;; 2 = both;; 1 = removed only;; 0 = none.
EX084 — Replay change route. Why was skipping replay detection treated as an architecture change? Rubric: 3 = it weakens a requirement, so it needs architecture review;; 2 = requirement;; 1 = coding choice;; 0 = none.

Synthesis

Implementation honours the architecture when tasks trace to requirements, secrets stay out of code and discoveries feed back into design.

Continue studying — chapter 28 of 50

← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →