Harden security posture with cloud tagging

Cloud tags are foundational component of good cloud hygiene and can serve many different use cases such as governance, cloud cost, security, and compliance.

In this blog post, I'll provide a brief overview of the benefits of implementing a tagging policy and how to use Fix Inventory (our open-source offering) to automate monitoring and enforcement of your tagging policy.

What are tags?

Tags are metadata elements that you apply to your cloud resources.

They are key-value pairs that help you categorize and identify resources based on parameters relevant for your company. For example, let's assume you have three different deployment environments: production, staging, and test. To track resources by deployment environment, add a key named environment. To distinguish the resources deployed to your test environment, assign the environment key a value of test. The full key-value pair is environment = test.

Tags are created and consumed by both humans and machines. All cloud providers have functionality in their portals to assign tags to resources on a one-to-one basis (e.g., the AWS Tag Editor, the labels page in the Google Cloud Console, and the Azure Portal) as well as automated tooling through APIs. On a side note, AWS and Microsoft Azure use the term "tag," whereas Google Cloud uses the term "label."

Benefits of tagging

Tags help you organize your cloud resources so that your engineering teams can flexibly work with them and maintain a consistent structure as the complexity of your environment grows.

That consistent structure makes life easier for other teams in the company whose work is affected by developer activity, including DevOps (reliability, performance), Finance (cloud cost) and Security (compliance). Tags can be used as queryable annotations for resources—I can search through my cloud by filtering resources based on their tags.

Tags contain cloud resource information these teams need to perform their work; for example:

• Inventory management. Consistent tagging allows for easy filtering and searching of resources by e.g. specific regions, owners, environments, or workloads. That improves visibility and the speed at which DevOps can operate.

• Cost management. Cost-related tags match cloud spend to teams, workloads and applications. That helps business units model their margins, Finance and Accounting can track cloud cost and budgets.

• Governance, compliance, and security. Tags set consistent usage guardrails and help stay compliant with regulatory frameworks. Tags can also be used to classify data, govern access and ensure that your cloud operations are secure.

The above are just three short examples to illustrate how tags can help you govern your cloud better and also stay cost-efficient and secure.

Tagging use case examples

The clouds provide a lot of flexibility to create user-defined tags, which helps user implement their own organizational logic. Tags can be used to label resources with their owner, cost center, purpose, environment, application, data classification, lifecycle or any other attribute relevant to the organization.

How exactly you design your tagging policy is really up to you. Microsoft offers a resource naming and decision guide, to reflect it you want to align your tagging policy with IT or with the business.

It's not an either-or decision, however—you can do both. But as you add more types of tags, the complexity of managing them also goes up.

If you don't know where to begin, we recommend starting with two tags:

• Owner. The team or person who owns the resource.

• Expiration. The lifespan of the resource.

Assigning owner tags means you can always turn towards the team or person who deployed the resource for questions. In particular, security teams often don't have the context for why and how a resource was deployed.

Expiration tags and associated expiration data help identify resources that should no longer exist, which reduces both your cost (delete unused resources that you're still paying for) and risk exposure (delete unused resources that unnecessarily increase attack surface).

Using tags for cloud compliance

One of the biggest hurdles when implementing a tagging policy is not technology but human change. Defining a tagging policy is easy, but ensuring and knowing that it's also consistently applied throughout the organization not so much. Many times resources can be misconfigured or miss tags simply by mistake or lack of knowledge. But these missing tags can lead to other issues, through functional, cost and security-related consequences.

Finding untagged resources

A frequent concern we hear from DevOps teams and CISOs alike is the question about compute inventory and tag coverage: "How many EC2 resources do we have, how many of them are tagged, and how many are not?"

I'll show a quick example of you can use Fix Inventory to answer all three questions, and put automation in place to fix untagged or mislabeled resources in the first place. Fix Inventory unifies all inventory data in a single place. Let's assume that the tag I care about is the owner tag. I'll use EC2 as the AWS-specific example, but the same logic applies to Google Compute Engine and Azure Virtual Machines.

Fix Inventory is open source and self-hosted. I'm using Fix Inventory in this example because we're performing updates to the infrastructure, meaning we need write access. Our SaaS application Fix has read-only-access to your infrastructure. That means we can use Fix for analytics ("find untagged EC2 instances"), but not to directly perform updates.

Build an EC2 asset inventory

I'll use the Fix Inventory syntax to generate a list of all my EC2 instances:

> search is(aws_ec2_instance) | list

The query above will generate a list of all EC2 instances with predefined properties. See how to build an EC2 Asset Inventory to generate a list with custom properties.

Find untagged EC2 instances

Next, I want to find all EC2 instances without an owner tag:

> search is(aws_ec2_instance) and tags.owner = null

Rather than looking at my screen, I want the list in a CSV file so I can share it for remediation purposes:

search is(aws_ec2_instance) and tags.owner = null | list --csv | write untagged.csv

Before sending the file, I also want to perform a quick count of my untagged instances, let's say with the additional information of what account they're running in.

search is(aws_ec2_instance) and tags.owner = null | count /ancestors.account.reported.name

That's it—I now have a list of both my tagged and untagged EC2 instances, and I also have a count.

Automating resource tagging

As a CISO, I want to ensure compliance and security as much as possible without getting into the way of my developers. But I also don't want to chase them, so next up I'm putting incentives and automation into place to increase my tag coverage.

Fix Inventory offers automation capabilities that I'm going to use for that purpose. I am going to use three levels of automation, by let's call it "level of enforcement" to remediate the situation.

• Notify. Notify the team by posting the list of EC2 instances without an owner tag in a Slack channel once a month.

• Update. Apply an owner tag to all untagged EC2 instances in a particular cloud account (eng-sre).

• Clean. Remove untagged EC2 instances two hours within creation.

I start with a simple notification (Slack), then do the work myself (apply tag), and finally enforce non-compliance by removing the resource.

Send notifications to Slack

I'm going to use the job command to automate sending a notification to Slack, specifically on on the 1st of every month at 10am.

jobs add --id report_untagged-schedule"0101**" --wait-for-event collect_done 'search is(aws_ec2_instance) and tags.owner = null | slack --title "Found untagged instances" --webhook …'

Apply owner tag

If I happen to know that one account is only used by a specific team, I can automatically update the tags. In this case, the account is called eng-sre, and the corresponding tag is SRE.

search is(aws_ec2_instance) and tags.owner = null and /ancestors.account.reported.name = eng-sre | tag update owner SRE

Here, I use the tag command to update my resource tag.

Remove untagged resources

Maybe there is a high security account eng-high-security where I simply will not tolerate untagged resources. In that case, I will remove the resources automatically within two hours of deployment. I'm using the two hours as a simple example, and to show the flexibility Fix Inventory offers to build these automations.

search is(aws_ec2_instance) and tags.owner = null and age > 2h and /ancestors.account.reported.name = eng-high-security |
clean "Missing owner tag"

The query leverages the clean command for cleanup. If I want a safety net, I can use protect to prevent accidental cleanup of specific resources.

Cloud compliance and efficiency at scale

In the example above, I used EC2 and the owner tag as placeholders. We can apply the concept of finding untagged resources to any other resource and tag type, and also further differentiate by properties like age and usage.

As I introduce a new tagging policy and educate engineering about it, I can also choose between these levels of remediation (notify, update, clean), and gradually increase my compliance and security posture.

The point is that I can flexibly choose between different dimensions, which allows me to tailor my compliance program to my organization's needs. In particular the clean command can be used to clean up non-compliant, expired or unused / abandoned resources, benefitting both cloud cost and security.

Using Fix vs. Fix Inventory for tagging compliance

As I wrote above, I used Fix Inventory to demonstrate the remediation part. Since Fix Inventory is open source, you can self-host it and grant write access to your infrastructure. You'll have to be comfortable with using a CLI.

Fix, on the other hand, is our SaaS application with read-only access to your infrastructure, meaning we cannot help you perform the remediation part. However, our dashboard gets you most of the way there with the filters to find untagged EC2 instances (or any other resource kind), and further narrow down your search by property (e.g. age, account, user) and then download the list.

With our alerting integrations, you can also set up automatic notifications when a new non-compliant resources pops up in your inventory.

Conclusion

In this post, I showed how cloud tagging is an effective way to harden your compliance posture and reduce cloud cost at the same time. Building a consistent tagging policy is the first step. With a commitment to enforcing a tagging policy, organizations can achieve better visibility, more efficient cloud usage and higher security.