SA-8, Security and Privacy Engineering Principles, asks the organization to apply a chosen set of systems security and privacy engineering principles in the specification, design, development, implementation and modification of the system and its components. The set is organization defined. You decide which principles, then you show they were used at each of those five points.
800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference. It is also where several withdrawn controls, such as SA-13 Trustworthiness, ended up.
What it means in practice
The guidance ties the principles to the development life cycle, SA-3. They apply to new systems and to upgrades. For existing systems you apply them to upgrades and modifications to the extent feasible given current hardware, software and firmware.
The examples in the record are a usable starter list: develop layered protections; establish policies, architecture and controls as the foundation for design; incorporate requirements into the life cycle; delineate physical and logical security boundaries; make sure developers are trained to build secure software; tailor controls to organizational needs; and perform threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns and compensating controls.
The record also says the principles can protect against certain supply chain risks, for example by incorporating tamper-resistant hardware into a design.
The enhancements list classic design principles: SA-8.1 Clear Abstractions, SA-8.2 Least Common Mechanism, SA-8.3 Modularity and Layering, SA-8.4 Partially Ordered Dependencies, SA-8.5 Efficiently Mediated Access, SA-8.6 Minimized Sharing, SA-8.7 Reduced Complexity and SA-8.8 Secure Evolvability. They continue in the catalog well past these. You do not need every one. You need the ones you name.
Evidence to collect
- A principles document that lists what you adopted and why.
- Design reviews that reference the principles, such as a checklist item in the design template.
- Threat models for significant systems.
- Developer training records on secure development.
- Architecture diagrams showing boundaries and layers.
- Examples of a change that was altered or rejected because it broke a principle.
Common gaps
A list of principles that nobody has read. Ask three engineers to name two and see.
Principles stated for design but not for modification. Five stages are named in the control, and changes to live systems are where drift lives.
No sample of application. Auditors will pick a recent design and ask where the principle shows.
Threat modeling done once for the launch system and never again.
How to implement it
- Choose a short list of principles you can actually follow, and write each in one sentence with an example.
- Add them to your design review template as questions.
- Require a threat model for systems that handle sensitive data or cross a trust boundary.
- Train developers and keep the completion record.
- At each design review, note which principles drove a decision.
- Review the list once a year and retire any that no longer help.
What an auditor may ask
- Which principles have you adopted, and where are they written?
- Show a recent design review that used them.
- How do you apply them to changes in live systems, not only new builds?
- How are developers trained?
Pick one real design and one real change and prepare a short walk through of each.
Quick check
At which stages does SA-8 expect principles to be applied?
Specification, design, development, implementation and modification.
Do you have to adopt every SA-8 enhancement?
No. The base control lets the organization choose the principles. Mappings to other frameworks vary, so check the mapping your auditor uses.
