5-step IaaS security checklist for cloud customers
Get expert advice on patching, data encryption, and identity and access management responsibilities in this enterprise IaaS security checklist.
Many organizations have almost completely replaced virtual data centers, on-premises servers and appliances with IaaS. This widespread implementation requires a mobilization to secure IaaS environments to match this increased usage.
With IaaS, the customer has more security responsibilities than in PaaS or SaaS environments. The shared responsibility model stipulates that the lower one goes in the stack, the more operational security tasks the customer takes on. For example, with SaaS, OS-focused tasks, such as OS patching, are out of the customer's control. In the IaaS model, however, the responsibility stays with customers because they have control over the workload -- in this case, a virtual compute image.
With control comes responsibility. By taking on more control over the underlying infrastructure, IaaS customers also take on the burden of making sure it's secured. Since IaaS is lower in the stack, it is harder to get specific security guidance because best practices need to accommodate different usage. However, there is a selection of best practices for IaaS security that can be universally applied across cloud providers and usage scenarios.
Here are the five fundamental steps in the IaaS security checklist for customers.
1. Understand the provider's security model
Before employing an IaaS offering, infosec leaders need to make sure they understand the security model of the offering's provider. This is important for two reasons. First, providers use varying terminology for similar concepts. For example, users might organize assets using tags in AWS but organize them in a project in Google Cloud Platform (GCP). This affects how cloud security policy changes are implemented, so knowing the terminology can help prevent mistakes.
Second, it's important from an operational perspective. Users need to understand what security features are available, as well as the potential value or limitations of those features. With this context in mind, infosec leaders can identify any necessary changes to the operational profile to ensure the features are used effectively.
Services -- such as Amazon GuardDuty and Microsoft Defender for Identity (formerly Azure Advanced Threat Protection) -- are conceptually similar at a high level, but they're drastically different in how they operate and how users' operational staff receive value from them. Build out a control map with which to compare features between providers. This is particularly important in a multi-cloud context.
2. Encrypt data at rest
Most providers, particularly larger ones, offer the ability to encrypt the VMs created in their IaaS platform. This encryption capability is typically free or available at a low cost. Users can choose to manage their own keys or opt for their provider to do so.
Given the low financial and operational impact, making use of this encryption feature -- if it is not already on by default -- is a wise decision. Per the previous step of the IaaS security checklist, be sure to clarify whether -- or how -- at-rest encryption affects other provider-offered services, such as backup and recovery features.
3. Patch consistently
IaaS customers are primarily responsible for keeping workloads up to date. In most cases, this includes the OS itself and any software installed to those images. Just as on-premises servers need to be patched and maintained appropriately, use the same vigilance for cloud workloads. While this may sound like common sense, consistent patching can be more difficult than it seems. This is particularly true when cloud resources are managed within a different group or via a different operational process.
4. Monitor and inventory
Keeping an eye on any asset, cloud-based or otherwise, is common sense. However, like patching, monitoring functions can be located in different groups within an organization. Also, providers offer various monitoring mechanisms via different interfaces. These operational challenges will require significant planning and foresight to ensure consistent and efficient cloud monitoring. Thus, security leaders should set aside enough time to develop a monitoring strategy.
Additionally, keep an up-to-date inventory of images. The IaaS console will list what's there, but it won't necessarily include details about who in the organization is using a VM and for what. It's helpful to maintain inventory information in both an inventorying system and in the IaaS console via associated notes or tags. This enables security teams to cross-reference information, track workloads across providers and identify workloads at a glance in the IaaS console.
5. Manage access
In IaaS, there are multiple identity and access management (IAM) dimensions to consider as part of the IaaS security checklist. First, there is access to the OS and any applications and middleware installed on them. Second, consider privileged access -- including root or administrative access -- at the OS level. These IAM considerations for IaaS should be carefully managed and controlled.
Note that there are additional "layers" of access in IaaS that are unique. These include access to the IaaS console and other provider features that either offer information about or affect operation of cloud resources. These other features, such as backup and recovery, key management and auditing, all have a role to play in keeping a resource secure. Thus, it is critical to understand who has access to these areas of the provider's console and for what purpose.
Where it makes sense, use features such as just-in-time access so access is only provided when needed. Employ jump servers to consolidate access permissions centrally, ensure monitoring is uniformly enforced and minimize the workload attack surface.