Implementing CCM: Infrastructure Security Controls

The Cloud Controls Matrix (CCM) is a framework of controls that are essential for cloud computing security. You can use CCM to systematically assess and guide the security of any cloud implementation. CCM contains 197 control objectives structured into 17 domains that cover all key aspects of cloud technology:

 

CCM Domains

 

 

Today we’re looking at implementing the twelfth domain of CCM: Infrastructure & Virtualization Security (IVS). This domain applies to both cloud service providers (CSPs) and cloud service customers (CSCs). It covers the protection of hardware, software, networks, and facilities essential for delivering IT services. It also covers the virtualization technologies that abstract hardware resources into virtual environments.

The IVS domain consists of 9 control specifications:

1. Infrastructure and Virtualization Security Policy and Procedures
2. Capacity and Resource Planning
3. Network Security
4. OS Hardening and Base Controls
5. Production and Non-Production Environments
6. Segmentation and Segregation
7. Migration to Cloud Environments
8. Network Architecture Documentation
9. Network Defense

 

IVS Shared Responsibilities

One of the interesting aspects of the IVS domain is how it splits the responsibilities between the CSP and CSC. This division changes depending upon the type of cloud model.

CSPs are generally in charge of securing the underlying infrastructure, including platform technologies (like hypervisors and virtual machines) and network virtualization. This includes properly segmenting the network. CSPs also provide capabilities for capacity and resource planning.

CSCs are typically responsible for securing their allocated resources within the virtualized environment. They must make sure to deploy the appropriate security patches. Their job also involves disabling any unnecessary services which may introduce a security risk. Finally, CSCs must effectively manage access to the platform and control plane user interfaces. 

However, these responsibilities change slightly depending upon the form of cloud. For example, with Infrastructure as a Service (IaaS), the CSP gives hardware to the CSC. The CSC puts their own operating systems on top of that, whether they're virtualized or non-virtualized. On the other hand, with Virtual Machines as a Service, the CSP provides the CSC with a hypervisor.

 

Breaking It Down by Control

 

Infrastructure and Virtualization Security Policy and Procedures

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for infrastructure and virtualization security. Review and update the policies and procedures at least annually.

Shared Responsibility: Dependently shared between the CSP and CSC for IaaS. Owned by the CSP for PaaS and SaaS. While the CSP provides tooling to support the VM lifecycle, the governance and enforcement of such belong to the CSC.

IVS policies should include provisions on the following:

• The scope of the policies
• Industry standards and regulatory requirements applicable to the CSP
• Capacity planning requirements
• Network security baselines that define acceptable physical and virtual network configurations for computer network devices, applications, and operating systems
• Security baseline configurations for all guest/host operating systems, hypervisors, and VMs
• Requirements for the separation of production and non-production environments
• Network physical and/or logical segmentation and segregation requirements
• Intra-tenant access requirements
• Requirements for the establishment of secure channels for data migration to cloud environments
• Documentation of the cloud network architecture
• Monitoring metrics and key performance indicators (KPIs) related to infrastructure and virtualization security
• Approval requirements and senior management involvement to ensure alignment with the organization's strategic goals and risk appetite
• Effective communication of the policy and procedures to all relevant cloud stakeholders

 

Capacity and Resource Planning

Plan and monitor the availability, quality, and adequate capacity of resources in order to deliver the required system performance as determined by the business. 

Shared Responsibility: Owned by the CSP. The responsibility for this control is the same across all cloud architectures. A CSC may demand a particular service or resource capacity. However, it is the responsibility of the CSP to ensure that they deliver the required system performance.

The CSP should develop a resource planning framework to assess the usage of the infrastructure, platform, or application. The engineering and infrastructure teams should use the framework to determine if the growth of the service meets CSC demands. The CSP should also maintain an internal operational level agreement (OLA) and SLA with the CSC. This may include service penalties for situations where the CSP is unable to deliver capacity and availability.

 

Network Security

Monitor, encrypt and restrict communications between environments to only authenticated and authorized connections, as justified by the business. Review these configurations at least annually, and support them by a documented justification of all allowed services, protocols, ports, and compensating controls.

Shared Responsibility: Dependently shared between the CSP and CSC for IaaS and PaaS. Owned by the CSP for SaaS. The CSP is responsible for communications security at the infrastructure, platform, and orchestration level. The CSC is responsible for communications security above the provisioned infrastructure/platform, or when connecting different environments together.

 

Implementation best practices for cloud network security include:

 

• Comprehend and articulate principles guiding network design, such as security, resource scalability, performance, and regulatory compliance
• Establish and maintain an inventory of authorized services, protocols, and ports permitted for communication between the cloud network environments
• Implement network security baselines as part of a change management framework that encompass parameters for network virtualization and network security configurations
• Define guidelines for network segmentation, access control, and traffic management
• Configure network devices to enforce strong encryption for specific protocols and ports
• Deploy firewalls at key points within your network architecture to act as gateways between internal and external network connections

 

OS Hardening and Base Controls

Harden host and guest OS, hypervisor or infrastructure control plane according to their respective best practices, and supported by technical controls, as part of a security baseline.

Shared Responsibility: Independently shared between the CSP and CSC for IaaS. Owned by the CSP for PaaS and SaaS. With IaaS, the CSP is responsible for the host's hardening (OS and/or hypervisor). The CSC is responsible for the guest VM and OS hardening.

 

For PaaS and SaaS the responsibility shifts to the CSP only. The hardening of the OS, hypervisor, and underlying infrastructure are not part of the CSC’s cloud stack.

 

Implementation best practices for cloud platform hardening include:

• Create and utilize secure configuration baselines using industry vendors and benchmarks to ensure consistency across all platforms
• Utilize and implement a minimal installation, using pre-configured secure templates according to the baseline and having only essential system services/processes enabled
• Configure strong authentication (e.g., complex passwords, MFA) for accessing the hypervisor/VM/OS management interfaces
• Enable security features such as firewalls, anti-malware, and system logging
• Use network segmentation to isolate VMs from each other and the rest of the network infrastructure
• Implement access controls to restrict access to VMs based on the cloud IAM access control policy
• Implement change management processes to control and track changes made to VMs
• Regularly conduct vulnerability scans to identify and remediate security weaknesses
• Encrypt VM disks before decommissioning to protect sensitive data from unauthorized access
• Remove decommissioned VMs from the inventory and tracking systems

 

Production and Non-Production Environments

Separate production and non-production environments.

Shared Responsibility: Independently shared between the CSP and CSC. Best practice is to separate production and non-production environments. This ensures that changes in the non-production environment do not influence the production environment. It also ensures that test data never enters into the production environment.

The CSP should maintain a non-production environment that is completely separate from the production environment. The non-production environment should be running in an architecturally similar environment that is both logically and physically separated from the production environment. Exclusively use the non-production environment with test data instead of actual CSC/business data.

 

Segmentation and Segregation

Design, develop, deploy and configure applications and infrastructures such that CSP and CSC (tenant) user access and intra-tenant access is appropriately segmented and segregated, monitored and restricted from other tenants.

Shared Responsibility: Dependently shared between the CSP and CSC for IaaS and PaaS. Owned by the CSP for SaaS.

 

Implementation best practices include:

 

• Physically and logically separate and isolate multi-tenant environments to prevent unauthorized access between different tenants
• Enforce network segmentation at various levels, including virtual private clouds (VPCs), subnets, and security groups
• Establish robust IAM practices to control access to cloud resources and enforce segregation
• Continuously monitor and review CSP and tenant access activities to provide visibility into potential security breaches or unauthorized access attempts

 

Migration to Cloud Environments

Use secure and encrypted communication channels when migrating servers, services, applications, or data to cloud environments. Such channels must include only up-to-date and approved protocols.

Shared Responsibility: Dependently shared between the CSP and CSC.

When migrating servers, services, applications, or data to cloud environments, CSPs should implement secure and encrypted communication channels to safeguard sensitive information. This ensures the protection of data throughout the migration process and during its subsequent operation in the cloud.

 

Network Architecture Documentation

Identify and document high-risk environments.

Shared Responsibility: Dependently shared between the CSP and CSC for IaaS and PaaS. Owned by the CSP for SaaS. The SaaS CSP is responsible for identifying and documenting high-risk environments within the SaaS application. Data flow diagrams should clearly define boundaries between zones having different data classifications, trust levels, or compliance requirements.

Implementation best practices for network architecture documentation include:

• Adopt a consistent and standardized set of terminology and definitions that extends to network diagrams, architectural models, and other documentation elements
• Conduct thorough risk assessments to identify potential vulnerabilities and high-risk areas in the network topology
• Create accurate and up-to-date architecture diagrams that visualize the entire network topology
• Document a detailed description of all security controls implemented in the network
• Define a change management process for network modifications and updates

 

Network Defense

Define, implement and evaluate processes, procedures and defense-in-depth techniques for protection, detection, and timely response to network-based attacks.

Shared Responsibility: Dependently shared between the CSP and CSC for IaaS and PaaS. Owned by the CSP for SaaS. In SaaS, CSPs manage and secure network security controls for the CSC as part of the software's core offering.

Defense-in-depth techniques to consider include:

• Deploy firewalls at each layer of the cloud network to filter traffic based on security rules
• Implement IDS/IPS solutions to monitor network traffic for suspicious activity and identify potential intrusions or attacks
• Utilize NTA tools to gain deeper insights into network traffic patterns and identify anomalies that may indicate malicious activities
• Encrypt sensitive data in transit to protect it from interception and unauthorized access
• Utilize threat intelligence feeds to stay informed about emerging network threats, vulnerabilities, and attack methods
• Enforce secure configuration standards for cloud network resources
• Integrate a variety of network and system components from different vendors

 

Mitigation Best Practices

The following is a quick list of the various risks that IVS controls address, and the specific mitigations that can help.

• Risk: Unauthorized access to cloud environment
• IVS controls that can help:
  • Ensure network security controls are appropriately in place
  • Implement controls such as firewalls for Virtual Private Networks (VPNs)
  • Segment and segregate the network, limit access, and prevent lateral movement
• Risk: Data breaches and data loss
• IVS controls that can help:
  • Implement good governance policies and procedures
  • Segment production and non-production environments
• Risk: Insecure configuration management
• IVS controls that can help:
  • Harden your OS
• Risk: Resource exhaustion
• IVS controls that can help:
  • Use capacity and resource planning to prevent overloading of systems
• Risk: Unpatched vulnerabilities at the infrastructure and base OS level
• IVS controls that can help:
  • Harden your OS to ensure secure configuration standards 
• Risk: Data loss during cloud migration
• IVS controls that can help:
  • Implement appropriate planning procedures ahead of time so that there are no surprising challenges during the migration
• Risk: Security oversights and gaps
• IVS controls that can help:
  • Implement good governance policies and procedures
  • Use network architecture documentation to support reviews and audits

Make sure to check out the CCM and CCM Implementation Guidelines documents on CSA’s website. Many other publications are available as well, free to download and use. Learn how to implement the other CCM domains by reading the rest of the blogs in this series. Be on the lookout for the next installation: Logging and Monitoring.