SC.L2-3.13.2Security Engineering
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
[a]
architectural designs that promote effective information security are identified;[c]
systems engineering principles that promote effective information security are identified;[d]
identified architectural designs that promote effective information security are employed;[f]
identified systems engineering principles that promote effective information security are employed.
Reference architecture and landing-zone guardrails for an OSC that buys rather than builds
Implementation
AO coverage. Claims objectives [a], [c], [d], and [f] — identifying and employing architectural designs and systems engineering principles. Objectives [b] and [e] (software development techniques) are not claimed here: this organization develops no software that runs in or touches the enclave. Vendor software assurance is handled through purchasing requirements and the risk-assessment process, not through internal development practice, and the SSP records that determination rather than asserting a secure-SDLC.
Architectural designs identified [a]. A short written reference architecture fixes five patterns: the enclave is its own spoke with no shared admin plane; identity is the primary perimeter (SSO plus device compliance); CUI has one authoritative labeled store; management interfaces live on a separate network with their own credentials; and no enclave resource carries a public IP.
Systems engineering principles identified [c]. Least functionality (deploy the smallest service tier that meets the need), defense in depth (no single control is the only thing between the internet and CUI), fail-closed defaults, minimize trust relationships between systems, and design-before-deploy review for anything that touches CUI.
Employing the designs [d]. Terraform modules encode the patterns, so the default path produces a compliant resource. Landing-zone policy denies public IPs, unencrypted storage, and storage accounts without private endpoints. A deployment that needs to deviate fails policy and must carry an approved architecture review record.
Employing the principles [f]. The architecture review checklist is a required section of the change ticket for any new enclave system: what data class, what boundary it lands behind, what identity it uses, what happens when its dependency fails, and what is being removed rather than added. Reviews are signed by someone other than the requester.
Maintenance. Reference architecture reviewed annually and after any platform migration. Guardrail policy exemptions expire in 90 days. Rejected or deviated designs are kept so the reasoning is auditable.
Accepted gap. A legacy on-prem MRP system predates the reference architecture and cannot be re-platformed into the spoke pattern. It is documented as a standing deviation on an isolated VLAN with its own review date and a migration line item in the roadmap.
What the evidence looks like
- Enclave reference architecture document with version history
- Landing-zone policy definitions (deny public IP, require encryption, require private endpoint)
- Terraform module repository with peer-review history for enclave modules
- Two completed architecture review checklists, including one that forced a design change
- Standing deviation record for the legacy MRP system
Environment
Tools
Was this example useful?
Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.
Discussion(0)
No discussion on this example yet
Verdicts capture a conclusion. Use a thread when the interesting part is the argument.
Sign in to start a thread.