Solution for Cloud Security Authorization
The CaaS solution for Cloud Security Authorization enables agencies to meet the regulatory requirements of C&A Automation and Continuous Monitoring. The solution addresses the requirements of a stand-alone, cloud-based or a hybrid System. It fully addresses the challenges laid out earlier.
Let’s take the example of a ‘hybrid’ Information System shown in Figure 2, which utilizes say, the SaaS services of a Cloud Service Provider (Asset 3). The client Information System Owner relies on the SaaS provider to provide the security of the cloud service component (Asset 3) and inherit its controls as a component of the overall hybrid Information System. On his part, the SaaS Cloud Service Provider (CSP) has responsibility for all cloud components and shares the responsibility for the interconnection controls with the client utilizing the Provider cloud services.
The CaaS solution described next utilizes following key definitions: Systems and Subsystems, Type Authorization, Common Controls and Inheritance.
System and Subsystems
According to NIST 800-37 Rev.1, the best way to address the security certification of a ‘complex’ System is to decompose the System into more manageable ‘Subsystems’. It further states that, “Treating an information system as multiple Subsystems, each with its own Subsystem boundary, facilitates a more targeted application of security controls to achieve adequate security and a more cost-effective risk management process”. The Cloud Service layers and their components form the Subsystems.
‘Type’ Authorization
The Cloud Subsystems are certified using a ‘Type’ certification. A Type certification is applied to a system consisting of a common set of hardware, software, and firmware whose instances may be deployed at multiple locations. In such cases, the IA controls can be tested at one location and the certification and authorization (C&A) of this instance can be applied to identical instances deployed at other locations. The Type certification requires that the installation environment must be described in detail, including any interconnection controls with other systems or the datacenter. The Type authorization allows the Cloud environment to scale from single VM to 1000s of VMs across multiple installation sites, meeting the elasticity requirements of the cloud services. The Type certification can be applied to any cloud service type, IaaS, PaaS, or SaaS (such as in Figure 3).
Common Controls
The NIST RMF defines three types of Security Controls applied on an Information System: a. System-Specific controls; b. Common controls; and c. Hybrid controls (i.e. controls that have both System-specific and common control characteristics). It is ideal for organization to identify and implement as many ‘Common controls’ as possible. The Common controls enable a cost-effective and consistent application of information security controls and help simplify the risk management process.
Inheritance
When Common controls are used to support documentation of controls for a specific Information System, they are referred by that specific System as ‘inherited controls’. In the case of Cloud Computing infrastructure, each layer of the service can inherit controls from a lower layer as shown in Figure 3.
Figure 3: Cloud Services based on inheritance
In Figure 3, in the IaaS Service instance, Cloud Service Customer (CSC) inherits controls from the IaaS service from the Cloud Service Provider (CSP); while in the case of PaaS service instance, CSC inherits controls from both the IaaS and the PaaS service layers. Each ‘service’ specific controls are documented as a set of Common Control Profiles (CCPs) and can be inherited by Systems and Subsystems for authorization of a standalone or a hybrid Cloud-based System.
The System Security Plan (SSP) for the Information System documents the decomposition of the complex Information System into Subsystems. The SSP notes the type of certification, for example, ‘Type’ Certification applied to the Subsystems with description on each Subsystem’s asset boundary. It also notes the list of Common Controls based on the CCPs that will be ‘inherited’ from an underlying Subsystem or an external System with applicable interconnection controls and Service Level Agreements.
Compliance as a Service for Cloud Computing
The CaaS solution is embedded within the Cloud infrastructure and offered to the customers of the Cloud as a C&A automation and Compliance Monitoring Service. The CaaS, provides a highly scalable and cost effective solution for both the Provider Systems as well as the Customer Systems. For customer of SaaS services, the Cloud Service Provider, has the responsibility for the security of all the layers and can inherit applicable controls from the underlying layers. The inherited Common Controls and SaaS specific controls are combined to create the C&A certification package by the Cloud Service Provider including the SSP, Security Assessment Review (SAR) or the System Test and Evaluation (ST&E) documents plus other artifacts for consumption by the customer. We take a detailed look at the SaaS service provider package based on the key definitions for CaaS described earlier.
Figure 4: CaaS – C&A Package for Cloud-based SaaS
In Figure 4, the customer of SaaS services desires FISMA Certification package, PKG3. The customer, a US government agency, is subscribing to the SaaS based Human Resources application consisting of three application components, App1, App2 and App3.
The complex Human Resources SaaS can be broken into three Sub-Systems, matching each service layer. The SaaS service relies on the PaaS service components shown in the triangle with Java Virtual Machine (JVM), MySQL Database and local Identity Management System within a Linux Platform. The Linux platform is running on the IaaS components of hypervisor, rack-based server and associated storage provided by a Network Attached Storage or Storage Area Network, in a hosted facility. Each underlying IaaS and PaaS layer can have their own package, such as PKG1 and PKG2, based on a ‘Type’ certification and available to customers for direct consumption or by inheritance.
The Controls applicable to each component of the layers are grouped together in a layer specific CCP. The upper layer, as discussed in the previous section, can inherit the CCPs of the lower layers. In our example, the SaaS service provider inherits CCP2 from IaaS, CCP4 from PaaS services and documents application specific controls for the SaaS layer in the SYS1 profile.
The combined Security Certification package, PKG3, with all the associated artifacts such as the SSP, the SAR is generated by CaaS component and is made available by the provider to the agency for the agency DAA authorization.