SC-3 Security Function Isolation. Isolate security functions from nonsecurity functions
Security Function Isolation. Isolate security functions from nonsecurity functions.
5
artefacts
1
held by a system
2
at each review
hard
to go live
Document repository
where the evidence lives
teal = a system already holds it · olive = produced at each review
system holds itEvidence a system already holds
- Configuration evidence that non-security code cannot access or modify security function state · Cloud console / configuration management
periodic reviewEvidence produced at each review
- Test or assessment results demonstrating the isolation holds · Document repository
- Evidence that interfaces crossing the boundary are minimal and defined · Document repository
governing documentDocuments that govern the control
- The list of security functions required to be isolated from non-security functions · Document repository
- Design documentation showing the isolation boundary and the mechanism enforcing it · Document repository
First move
Mostly documents and reviews. Pull the 1 system-held artefact from your Cloud console / configuration management on a schedule; put the documents under version control with an owner and review date, and log each review as a dated record with a named reviewer.
Common gaps auditors find
- Security functions running in the same address space or privilege level as application code, with isolation claimed from process separation alone
- Administrative tooling given access across the boundary, defeating the isolation for the highest risk accounts
- Boundary designed but never tested, so bypass paths are unknown
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheetSC-2 Separation of system and user functionality · SC-4 Information in shared system resources