Appendix B: Principles of Cloud-Oriented Security Protections

As noted in this Report, the Federal Government has traditionally focused its Government-wide information security efforts on protecting network boundaries; however, instead of emphasizing physically consolidated security at the perimeter, such as in the current Trusted Internet Connections (TIC) model, a data-centric approach emphasizes placing protections closer to the services and information systems in which sensitive data is stored and accessed. This gives agencies flexibility in the approaches they choose. For modern services hosted in the cloud, agencies can place security protections directly in front of each service and allow direct connections from the public internet. For services hosted in legacy data centers, such capabilities may not be available, in which case the agency can still rely on perimeter security as they pursue options to modernize their system architecture.

There is no one right way for an agency to operationalize security protections in Cloud Service Providers (CSPs), and some features and approaches may need to be optimized for the particular cloud service provider in use. Agencies should ensure any CSP they choose meets the security capabilities outlined by FedRAMP. The approach in this appendix applies to cases wherein an agency is directly operationalizing software in a cloud-hosting environment. This does not apply to Software as a Service (SaaS) applications operated in full by vendors, as their security approaches will be vendor-specific.

Agencies could take the following approach to designing security protections in a cloud-based application stack:

An example diagram showing data-centric security in a cloud provider is shown in Figure 1.

ATC Networks - Cloud Moderate

Figure 1

This data-centric application security layer could be implemented directly by an application team, or it could be run by an agency as an internal shared service for all applications hosted within a particular cloud provider. It could also be possible for a sufficiently responsive agency team to provide this layer as a shared service to multiple agencies who utilize the same cloud provider.

To achieve centralized visibility for agency security teams, this data-centric application security layer should send logs and alerts in real time to centralized aggregation systems that process security information and events. These centralized aggregation systems could be co-located in the same cloud provider as the applications from which they are aggregating information. They could also aggregate logs and network flow information received from the cloud service provider itself. One operational approach for doing this is described in the Security Operations Center as a Service section of this report.

Government-Wide Visibility and Classified Indicators

Some Government-specific security functions, such as the intrusion detection and prevention capabilities of 6 U.S.C. § 151, currently offered as EINSTEIN, would not be automatically fulfilled by commodity solutions. Some needs, for example, can only be addressed with classified indicators. This produces a challenge for agencies, as these classified indicators can only be stored in data centers meeting very specific security requirements. For most systems, however, these Government-specific functions, such as EINSTEIN 1 and EINSTEIN 2, do not leverage classified indicators or need to be physically “on path” for network traffic and incoming requests. Instead, the virtual appliances in the data-centric security layer could create a copy of relevant traffic or logs and send a stream to a nearby location (perhaps operated by DHS as part of the intrusion detection and prevention capabilities of 6 U.S.C. § 151) where these Government-specific security functions can be performed in the background. The original copy of the traffic continues to flow to the cloud provider unless, depending on the capability at issue, an alert is generated from the intrusion prevention system. This achieves visibility and detection of classified threats without sacrificing the major benefits of adopting modern cloud architectures. A diagram of how this may look is represented in Figure 2.

ATC Networks - Cloud High

Figure 2

DHS should also consider evolving NCPS’s intrusion prevention capabilities program to include the ability to receive and act on additional application layer traffic. In its current form, EINSTEIN 3A does not process most web traffic, because it only examines email and domain name server.

The data-centric approach outlined above also allows a more nuanced approach to protection, allowing security teams to focus their efforts on the systems that need it most. For low-impact systems that only store public data, it is likely unnecessary to split off traffic for classified analysis. For high-sensitivity systems with very valuable private data, it may be useful to require more security measures, such as waiting for classified analysis to be complete before passing traffic along to the application.

Proportionate Security

While the protections described in this appendix can be useful to many applications, the Federal Government should focus its limited security resources on its highest-value assets. All security protections come with a cost: any security services “on path” can impact reliability and performance, add complexity to system operations, and could have vulnerabilities that would be used against the applications they are intended to defend. Even “off path” security services that do not process data in real time, such as classified indicators and services that provide Government-wide visibility, add complexity as well as oversight and compliance costs to system operation.

For the Government’s security protections to be most effective, they should be deployed on systems whose data is worth such a sustained and sophisticated defense, such as HVAs. Systems that contain information that would have a low impact if compromised should instead be optimized for agility and availability, thus freeing security resources for more sensitive systems.

An isolated system with no sensitive information therefore might merit a more streamlined architecture. Figure 3 shows how a low-impact system may serve requests directly:

ATC Networks - Cloud Low

Figure 3