How To Clean Up Your Cloud Environment Using Tenable Cloud Security

You must periodically review your cloud environments to remove old and unused resources because they can create security risks. But what is the right way to perform this task? Read on to learn about five best practices we employ internally to clean up our cloud accounts which we hope can help enhance your cloud security strategy.

Overview

At the start of the new year, it’s important to assess all of your cloud environments and see where you can remove old and unused resources. While your production accounts might have a few unused resources and services, accounts used for product testing and development typically contain a larger number of resources of varying ages and states. 

While there are tools for automatically deleting those resources, these solutions often arbitrarily remove resources that are still needed. In order to prevent that from happening, it’s better to use a solution that provides more comprehensive details on what’s active, what’s not in use, and what you might need to exclude. That way, your organization would be able to make more informed decisions. 

After launching our Cloud Security program, we used Tenable Cloud Security to review our cloud accounts for old and unused resources. Based on our experience, we identified five key best practices for cloud environment cleanup and created a process to carry out this task. In this blog, we’re sharing what we’ve learned, hoping that it will help your organization refine its cloud security strategy further.

The rationale behind account cleanup

Reviewing and cleaning up old and unused resources from cloud accounts is important for several reasons.

First, many resources can generate hourly charges, but terminating one resource may not stop all its costs. That’s because associated resources often have additional costs that may linger within your account. 

It’s also essential to monitor all public-facing instances and virtual machines that use Secure Shell (SSH) keys or that have local login credentials set up. These resources can be accessible to users long after they have left your organization, leading to increased security risks.

Moreover, reviewing data within public-facing Amazon S3 buckets, Amazon RDS instances, GCP storage buckets, and Azure storage accounts can help prevent the exposure of sensitive data such as personally identifiable information (PII), financial records, and other sensitive information. 

In addition, when cleaning up cloud accounts, reviewing access control is also important. Reviewing the status of all user identities and how they access your account can help improve account security. You may have active and inactive user accounts with access and permissions to resources that need to be removed. 

Below we explain how you can find these resources and why it’s important to review them for potential deletion. We also highlight additional security controls you should consider implementing in your cloud environment. You can apply these best practices selectively or comprehensively, regardless of your cloud platform or the account types that need to be reviewed.

Consideration 1: Age of resources

To determine the age of your resources, first select the account in-scope, then choose the service you want to review under the “Inventory” section of the console. You can review the existing resource counts to see if you need to focus your cleanup efforts on a specific service. 
 

Tenable Cloud Security provides several options to easily view when a resource was created. Using the “Created” column, you can filter results from oldest to newest, so you can see the older resources at the top of the list.
 

In the console, if you want to view the resources created more than 180 days ago, select the “Created” filter, then use the “Before the last” option to choose that filtering criteria. 
 

Results using this filter should give you an idea of the age of your resources and what might need to be deleted. We also recommend that you export results to a .csv file to get the complete list of resources within your account, so you can view all resources at-a-glance, including those that do not contain a “Created” date.

Consideration 2: Active vs inactive

Cloud accounts will contain a combination of both active and inactive resources. Checking a resource’s size may indicate whether it’s in use or not. Tenable Cloud Security lists the size of data resources such as buckets, databases, clusters, and snapshots, so you’re able to filter the resources list using that element. Results can show you resources with little to no data being stored. Depending on the “Last Modified” date or “Created” date listed, some of these resources may be a good candidate for deletion. 
 

To quickly find inactive identities within the Tenable Cloud Security console, select the “Inactive” label. You'll get a list of inactive identities that are overprivileged permissions, require key rotation, or have unused access keys and passwords that must be addressed.
 

When reviewing other services to see if they are active, it’s important to remember that not all cloud services will provide details on when the resource was last active. The Amazon EC2 service, for example, supports the “Launch Time” filter, which indicates when an instance was last rebooted. However, other services like Amazon S3 only provide a “Created” date. The S3 service does not provide direct information on when a bucket is being actively used or when it was last modified. 

Consideration 3: Access to accounts

When reviewing access to accounts, it’s important to determine how your team members are accessing them, what resources are being used, and when they were last active. If you have set up in Tenable Cloud Security an “Identity Providers” integration such as Okta, Microsoft Entra ID, or Google Workspace for example, you can view the status of your “Users”, when they last signed-in, and how long ago they were active.
 

Another important aspect to consider is how team members are accessing the account. For AWS accounts, the list of questions below can help you determine where you need to focus your efforts.

1. If you are using AWS Identity and Access Management (IAM) users to log into your account, do they employ access keys, passwords, or both? 
2. If AWS IAM roles are used to log into the account, and IAM users are also required, should permissions be restricted using access keys only?
3. Are there any inactive IAM user accounts that need to be disabled?
4. Are there any team members with access to an active IAM user account that may have recently left your company? 

From this list, you can determine if you need to take additional steps such as deactivating an identity, removing access, or updating how users are accessing your account. Lastly, you may need to consider implementing additional security controls like organizational policies or IAM permissions to prevent the creation of those resources. 

Consideration 4: Public resources

While it’s important to check on all identities, it’s also critical to review what type of public-facing resources you have in your account. Many non-production accounts often include resources such as public instances or public buckets. These resources may allow public access to known ports, provide public access to web applications, and grant remote access to these instances. It’s also important to check for running public instances and virtual machines that use SSH keys. Public instances with SSH keys could contain local user accounts and credentials that were set up, but need to be disabled.
 

If you plan to retain any public-facing resources, we also recommend reviewing public buckets or storage accounts for any sensitive data that might be stored. Using Tenable Cloud Security’s Data Protection feature, you can find scanned buckets and managed databases containing sensitive data. Within the “Data” section, you can select the “Public” labels filter to view resources with sensitive data being stored on publicly accessible resources. 
 

Scanned results will include the specific files or location within the resource under the Details column that should be reviewed.
 

We recommend that you review all public resources and data within your account, as a data breach could have a significant financial impact on your organization. These results can also be used to determine if data obfuscation and anonymization practices need to be improved. 

Consideration 5: Resource types and costs

In your cloud account, it’s critical that you review what resource types are running, what region it’s operating in, and the data being accessed.

Tenable Cloud Security allows you to easily filter your resources by “Region”, “Instance Type” and “Instance Class.” Running instances and virtual machines generate hourly costs, and can vary depending on the size of the resource and operating region. You can use those filters to find instance variants, instance family size, or specific types to help you find high-cost resources that could be scaled down or removed. 
 

Even if your instance is stopped or terminated, you can still incur additional costs for associated snapshots, backups, storage, and IP addresses. To avoid additional cloud costs, we recommend deleting all associated resources that are not in use.

Regarding cleanup efforts, it's crucial to evaluate whether additional security controls need to be implemented. You can optionally set up IAM policy restrictions to specific regions or permit only certain instance types within your account. Additionally, organizational policies can also be applied for more comprehensive coverage.

Other things to keep in mind

Before starting any cleanup efforts, it’s important to factor in any resources that need to be excluded from future deletion. Resources managed through infrastructure as code (IaC) are a good example of resources that can remain out of scope. To detect your IaC-managed resources, we recommend setting up Tenable Cloud Security’s IaC Security feature that will scan your IaC pipeline and highlight where your resources are managed in code. Once scanned, you should see the “IaC” label applied to that resource within the console.
 

Even if you don’t have IaC-managed resources in your account, using Labels provides a great option to easily identify resources managed by a specific team that need to remain out of scope. If you have resources with consistent tag key and value pairs applied, we recommend creating automatic labels for those resources. This feature will automatically label resources regardless of whether they need to be excluded. 

You can also apply manual labels to resources that may not have consistent tagging applied. For services that do not support tags, you can use this option to identify which team manages resources like Azure Roles or Okta Groups.

Determine what will be deleted

Once you have determined what you have, you can review what resources are in scope for deletion. Within the Tenable Cloud Security console, we recommend that you filter on the account and resources in scope and export those resources to a .csv file. This step will provide a compliance list of resources regardless of whether they have a “Created” date or not. 

If you have many resources that are in scope for deletion, you can optionally perform cleanup efforts in phases. Within the console, if you find that you have many EC2 instances and Lambda functions, for example, you can export that list to review those resources within each service.

In cases where all of your resources have a “Created” date listed, we recommend using the “Created” filter to highlight those resources created before a specified date. Some of the examples below provide different filter options you can use to identify those resources you want to target for deletion.
 

When determining whether a resource is active, be aware of a few things. Not all services support filters such as “Last Modified,” “Updated,” “Last Sign-In,” or “Last Activity” that highlight when a resource was last updated or when a user was last active.

Services like Amazon S3 do not support any information on whether the bucket is actively in use. There may be additional options available in AWS to determine that status through logs and enabling associated services. We highly recommend that you communicate this information to team members so they can check and confirm that nothing important is deleted. 

Lastly, if you determine that any retained resources need to be consolidated or reduced in size, you can implement security controls to retain data for a specific amount of time and then delete it. You can also resize or scale down the resource type to help reduce costs. 

Communicate cleanup efforts

Before you implement cleanup efforts, it’s important to communicate these changes to all team members. We recommend sharing the details listed below with those users who have access to your account. You can also use this list if you plan to perform future cleanup efforts within your account, either randomly or on a schedule.

1. Include the account(s) in scope.
2. Communicate why resources are being deleted.
3. Include the date when resources will be deleted.
4. Include the services and filter criteria in scope. Examples can include:
   • All virtual machine instances created more than 90 days ago
   • All SQL databases larger than 500GB
   • All resources with no “Created” date listed
   • All resources whose size is zero Bytes
   • All EC2 instances running *16xlarge instance types
5. If applicable, include what’s out of scope. Examples can include:
   • Resources managed through your CI/CD pipeline with the “IaC” label attached
6. If applicable, include important information that users should review or can request. Examples can include:
   • Ask users to review S3 buckets to confirm activity
   • Provide options for users to scale down resources
   • Explain how users can request exclusions

If team members already have access to review those resources within Tenable Cloud Security, we recommend including that information in your initial e-mail as a reminder. We’ve found that if you provide direct access to Tenable Cloud Security, teams can be more autonomous in managing resources within their account. You can also create an inventory report that can be e-mailed to team members who might not have access.

We also recommend notifying team members by e-mail at least 2-4 weeks in advance before any cleanup efforts are started. Also, send out a final reminder at least one week in advance to remind users that once resources are deleted, they cannot be restored. 
 

Conclusion

To maintain an efficient and secure cloud environment, it's important to run cleanup efforts quarterly or twice yearly, depending on the number of resources in your account. Start by determining what you plan to delete and when, and consider addressing specific cloud services in phases. Additionally, implement extra security controls and scale down resources to only what’s necessary. Be sure to include which resources or services are out-of-scope for your cleanup efforts.