Abstract
As the transition from National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Revision 4 to Revision 5 continues, two new security controls, AC-4(4) and SI-4(10), are being added to FedRAMP’s High-impact security control baseline to ensure thorough inspection of encrypted data flows. Changes introduced in NIST SP 800-53 Rev. 5 align with Executive Order 14028 as well as Executive Memorandums M-21-31 and M-22-09. EO 14028 emphasizes the importance of implementing zero trust architecture (ZTA) across all federal government agencies. ZTA addresses shortcomings of perimeter-based security models such as the lack of intra-zone traffic inspection and inflexibility in monitoring host placement. M-21-31 underlines the necessity to inspect encrypted data as it relates to cybersecurity investigative and remediation capabilities. M-22-09 further emphasizes the ZTA tenant of network visibility; any unencrypted or uninspected traffic is less trustworthy.
Scope of Control Changes
The introduction of two new security controls, AC-4(4) and SI-4(10), require that encrypted communications be inspected for potential threats, which is crucial for preventing tunneling attacks and evasion techniques employed by attackers.
| AC-4(4) | INFORMATION FLOW ENFORCEMENT | FLOW CONTROL OF ENCRYPTED INFORMATION Prevent encrypted information from bypassing [Assignment: organization-defined information flow control mechanisms] by [Selection (one or more): decrypting the information; blocking the flow of the encrypted information; terminating communications sessions attempting to pass encrypted information; [Assignment: organization-defined procedure or method]]. FedRAMP-Defined Assignment/Selection Parameters: AC-4 (4)-1 [intrusion detection mechanisms] |
| SI-4(10) | SYSTEM MONITORING | VISIBILITY OF ENCRYPTED COMMUNICATIONS Make provisions so that [Assignment: organization-defined encrypted communications traffic] is visible to [Assignment: organization-defined system monitoring tools and mechanisms]. |
AC-4(4) requires that CSPs prevent encrypted information from bypassing intrusion detection mechanisms by either decrypting information, blocking its flow, or terminating communication session attempting to pass encrypted information. SI-4(10) requires that CSPs ensure that encrypted traffic is visible to organization-defined system monitoring tools or mechanisms. The common denominator between these controls is that encrypted traffic must be inspected prior to entering, exiting, or traversing within the information system boundary; attempts to circumvent monitoring controls must be blocked. To achieve this, CSPs must inspect all traffic payloads, regardless of origin or destination. This includes decrypting, inspecting, and re-encrypting incoming customer and administrator traffic at load balancers, ingress gateways, or border firewalls. Additionally, host-based software should be deployed on all hosts within information system boundaries so that user activity is inspected outside of encrypted tunnels. It is essential that only trusted and secure traffic is permitted, while any traffic unable to be analyzed is dropped.
OSI Layer Filtering
Ideally, all traffic should be inspected at OSI layers 3 (network), 4 (transport), and 7 (application) to ensure that desired data flows are enforced. Traditional firewalls and network load balancers operate at layers 3 and 4 by filtering packets by IP address, source/destination port, or network protocol. Layer 7 monitoring capabilities are typically performed by proxies, next-generation firewalls, and web application firewalls where application payloads, such as query strings or uploaded files, are inspected for malicious signatures or behavior. To effectively implement AC-4(4) and SI-4(10), CSPs must inspect traffic at OSI layers 3, 4, and 7.
Monitoring Mechanism Placement
External Originating Traffic
To ensure comprehensive coverage of data flows, monitoring mechanisms should be placed throughout the information system. In accordance with FedRAMP’s Subnets white paper, external, untrusted traffic, such as customer data flows, should be routed to publicly accessible subnets, commonly known as demilitarized zones (DMZs), before accessing application or database servers on private subnets. Similarly, trusted traffic, such as administrative data flows, should route to a public subnet before accessing management interfaces. Public subnets are effective areas for traffic inspection tool interface placement so that external-to-internal data flows can be inspected for signs of malformed packets, risky function calls, or injection-based attacks.
Internal Originating Traffic
Internal outbound traffic should be inspected for signs of command and control traffic or data exfiltration. Common outbound traffic flows associated with software, firmware, and threat signature updates, also known as update sources, introduce supply-chain based risks. Additionally, communications between trusted sources should be subject to the same protections as communications between untrusted sources . Traffic can be inspected by routing to a Next-Generation Firewall (NGFW), proxy interface, or network-based intrusion detection/prevention systems. Host-based intrusion detection/prevention systems or firewalls are effective at monitoring communications between hosts throughout information system boundaries and serve to address shortcomings of perimeter-based defense models.
Implementation Pitfalls
Virtual Private Network (VPN) Architecture
VPN connections that terminate behind perimeter firewalls pose an increased risk as firewalls cannot decrypt the traffic that passes through them. Such deployments essentially introduce backdoors into an otherwise secure environment. To mitigate this risk, VPN tunnels should be terminated on public subnets where exiting traffic is routed to a NGFW, proxy, or load balancer for further inspection. Many NGFW solutions offer built-in VPN services and can easily support traffic decryption, inspection, and re-encryption.
Implicit Trust
Interconnections between implicitly trusted sources are often overlooked and do not receive as much monitoring attention. By definition, ZTA eliminates implicit trust relationships where all traffic needs to be secured and analyzed to develop an acceptable level of trust. CSPs must ensure that all communications, even between trusted sources, are able to be decrypted and inspected.
Passive Monitoring
CSPs who have deployed a system-wide monitoring system may only be passively detecting security violations. This often occurs with recently implemented system-wide monitoring solutions where CSPs are in the process of evaluating traffic flow patterns. Ideally, preventative measures should be enabled so that only trusted and secured traffic is permitted, while all other traffic is dropped.
Audit Coverage
Auditors will need to see evidence that encrypted communications within authorization boundaries are being decrypted and inspected for threats. This evidence may include configuration settings from strategically placed network interfaces, such as web application firewalls or NGFWs, to ensure that decryption and inspection capabilities are enabled. Auditors may also request alerts, logs, and/or reports from system-wide monitoring systems to demonstrate that traffic payloads are inspected for threats or anomalies. Common endpoint monitoring and data loss prevention solutions provide visibility into in-boundary host activity. NGFW products, as well as application-level load balancer solutions are common solutions for decrypting and inspecting network traffic, so long as they have access to the target website’s private keys supporting Hypertext Transfer Protocol Secure (HTTPS) encryption. Additionally, cloud-based service traffic between information system components and external cloud services can be inspected using cloud access security brokers (CASBs).
Conclusion
As the NIST 800-53 Rev 5’s rollout continues, CSPs are expected to implement the newly added AC-4(4) and SI-4(10) controls for those cloud service offerings at the High baseline. Part of this rollout will require CSPs to review their systems’ current data flows and ensure that all encrypted traffic is subject to inspection. To achieve this, it may be necessary to deploy agent or network-based monitoring software throughout information system subnets if not already in place. Fortreum is the fastest growing FedRAMP 3PAO in the marketplace and has collectively worked on FedRAMP engagement lifecycles since the inception of the program. Should you have questions about your transition to Rev 5, please reach out to us at Compliance@fortreum.com.
