Security Function Isolation
LOW MODERATE ✓ HIGHRequirements NIST SOURCE
Isolate security functions from nonsecurity functions.
Discussion (NIST Supplemental Guidance)
Security functions are isolated from nonsecurity functions by means of an isolation boundary implemented within a system via partitions and domains. The isolation boundary controls access to and protects the integrity of the hardware, software, and firmware that perform system security functions. Systems implement code separation in many ways, such as through the provision of security kernels via processor rings or processor modes. For non-kernel code, security function isolation is often achieved through file system protections that protect the code on disk and address space protections that protect executing code. Systems can restrict access to security functions using access control mechanisms and by implementing least privilege capabilities. While the ideal is for all code within the defined security function isolation boundary to only contain security-relevant code, it is sometimes necessary to include nonsecurity functions as an exception. The isolation of security functions from nonsecurity functions can be achieved by applying the systems security engineering design principles in SA-8 , including SA-8(1), SA-8(3), SA-8(4), SA-8(10), SA-8(12), SA-8(13), SA-8(14) , and SA-8(18).
Enhancements NIST SOURCE
SC-3(1) Hardware Separation LOW MODERATE HIGH
Employ hardware separation mechanisms to implement security function isolation.
Discussion
Hardware separation mechanisms include hardware ring architectures that are implemented within microprocessors and hardware-enforced address segmentation used to support logically distinct storage objects with separate attributes (i.e., readable, writeable).
SC-3(2) Access and Flow Control Functions LOW MODERATE HIGH
Isolate security functions enforcing access and information flow control from nonsecurity functions and from other security functions.
Discussion
Security function isolation occurs because of implementation. The functions can still be scanned and monitored. Security functions that are potentially isolated from access and flow control enforcement functions include auditing, intrusion detection, and malicious code protection functions.
SC-3(3) Minimize Nonsecurity Functionality LOW MODERATE HIGH
Minimize the number of nonsecurity functions included within the isolation boundary containing security functions.
Discussion
Where it is not feasible to achieve strict isolation of nonsecurity functions from security functions, it is necessary to take actions to minimize nonsecurity-relevant functions within the security function boundary. Nonsecurity functions contained within the isolation boundary are considered security-relevant because errors or malicious code in the software can directly impact the security functions of systems. The fundamental design objective is that the specific portions of systems that provide information security are of minimal size and complexity. Minimizing the number of nonsecurity functions in the security-relevant system components allows designers and implementers to focus only on those functions which are necessary to provide the desired security capability (typically access enforcement). By minimizing the nonsecurity functions within the isolation boundaries, the amount of code that is trusted to enforce security policies is significantly reduced, thus contributing to understandability.
SC-3(4) Module Coupling and Cohesiveness LOW MODERATE HIGH
Implement security functions as largely independent modules that maximize internal cohesiveness within modules and minimize coupling between modules.
Discussion
The reduction of inter-module interactions helps to constrain security functions and manage complexity. The concepts of coupling and cohesion are important with respect to modularity in software design. Coupling refers to the dependencies that one module has on other modules. Cohesion refers to the relationship between functions within a module. Best practices in software engineering and systems security engineering rely on layering, minimization, and modular decomposition to reduce and manage complexity. This produces software modules that are highly cohesive and loosely coupled.
SC-3(5) Layered Structures LOW MODERATE HIGH
Implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.
Discussion
The implementation of layered structures with minimized interactions among security functions and non-looping layers (i.e., lower-layer functions do not depend on higher-layer functions) enables the isolation of security functions and the management of complexity.
Implementation Guidance
Original engineering commentary written for this explorer — not NIST source text and not authoritative guidance.
No engineering interpretation has been authored for SC-3 yet. This section is architected to receive it — see the Requirements and Assessment sections above for the authoritative NIST source content in the meantime.
Assessment
Assessment Objectives
- security functions are isolated from non-security functions.
Examine
[SELECT FROM: System and communications protection policy; procedures addressing security function isolation; list of security functions to be isolated from non-security functions; system design documentation; system configuration settings and associated documentation; system audit records; system security plan; other relevant documents or records].
Interview
[SELECT FROM: System/network administrators; organizational personnel with information security responsibilities; system developer].
Test
[SELECT FROM: Separation of security functions from non-security functions within the system].
Overlays
STIGs & CCIs
No STIG checks or CCI mappings are currently loaded for SC-3. This section is architected to display, per product: STIG ID, Finding ID, Severity, Title, Description, Check, Fix, CCI, and NIST control mapping — but nothing is populated here until a real DISA STIG/CCI dataset is ingested.
Learn more about STIG/CCI integration →Evidence
Categorized from the SP 800-53A "Examine"/"Test" artifact list above by keyword — not an authoritative NIST evidence list.
Policy
- System and communications protection policy
- system security plan
Configuration
- system design documentation
- system configuration settings and associated documentation
Testing
- Separation of security functions from non-security functions within the system
Other Records
- procedures addressing security function isolation
- list of security functions to be isolated from non-security functions
- system audit records
- other relevant documents or records