SC-3 Security Function Isolation (H)

NIST 800-53 (r4) Control:

The information system isolates security functions from non-security functions.

NIST 800-53 (r4) Supplemental Guidance:

The information system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains). Such isolation controls access to and protects the integrity of the hardware, software, and firmware that perform those security functions. Information systems implement code separation (i.e., separation of security functions from non-security functions) in a number of ways, including, for example, 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 serve to protect the code on disk, and address space protections that protect executing code. Information systems restrict access to security functions through the use of access control mechanisms and by implementing least privilege capabilities. While the ideal is for all of the code within the security function isolation boundary to only contain security-relevant code, it is sometimes necessary to include non-security functions within the isolation boundary as an exception. Related controls: AC3, AC-6, SA-4, SA-5, SA-8, SA-13, SC-2, SC-7, SC-39.

NIST 800-53 (r5) Discussion:

Security functions are isolated from non-security 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 non-security functions as an exception. The isolation of security functions from non-security 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)

38North Guidance:

Meets Minimum Requirement:

• Deploy security functions (i.e., tooling that provides for the centralized management of logging, monitoring, scanning, FIM, HIDS, SOAR, SIEM, etc.) and non-security functions in separate virtual networks (i.e., "Security Network" and "Operational Network").

• Deploy security tooling inside private subnets protected by Network Access Control Lists (NACLs) and/or firewalls. Restrict ingress/egress data flows by port, protocol, and source/destination IP address.

Best Practice:

• Deploy security functions (i.e., tooling that provides for the centralized management of logging, monitoring, scanning, FIM, HIDS, SOAR, SIEM, etc.) and non-security functions in separate virtual networks (i.e., "Security Network" and "Operational Network"). The Security Network should provide a set of shared security services for the rest of the environment.

• Deploy security tooling inside private subnets protected by Network Access Control Lists (NACLs) and/or firewalls. Restrict ingress/egress data flows by port, protocol, and source/destination IP address. Group assets in separate subnets based on business functions.

• Enforce a separate network access path and fine-grained access controls for the Security Network. CSP administrators should access the Security Network via a bastion host hardened to DISA STIG standards. All administrative activity and network connections within the Security Network should originate from the bastion host, require multi-factor authentication, and be subject to stronger auditing controls (e.g., keystroke logging, full-text recording of privileged commands, etc.).

• Create and assign specialized roles in accordance with the principle of least privilege for Security Network administrators.

• Ingress traffic flows to the Security Network should be restricted to CSP administrators and agent-based communications with centralized management servers (e.g., Nessus, Tanium, etc.).

• Implement Role-Based Access Controls (RBAC) within application User Interfaces (UI).

Unofficial FedRAMP Guidance:

• None

Assessment Evidence:

• Live demonstration showing that security and non-security functions are logically separated. Assessors want to observe individuals with and without permissions attempt to access services/resources inside the Security Network. Access should be granted to individual assigned the appropriate role(s) and permissions, and denied to those who are not. Assessors will conduct a penetration test to validate access controls and logical isolation between security and non-security functions (ex., attempting to access security tooling as a credentialed, non-privileged user, etc.).

• Documentation or screenshots showing firewall and/or NACL configuration settings.

• List of individuals with access to security functions.

CSP Implementation Tips:

• Amazon Web Services (AWS):

  1. Build isolated network segments using Amazon VPCs, Security Groups, and NACLs.

  2. Use AWS Security Groups to restrict network traffic to certain sources, destination, and ports between the management/security network and external connections.

  3. Use AWS IAM to create roles compatible with your organization.

• Microsoft Azure: TBD

• Google Cloud Platform: TBD