Best Practices: A Better Way to Identify Workloads (and Their Context) in the Cloud

In the datacenter, the practice of workload and application security hasn’t changed much over the years and it all started with “identity” and context of the applications. To create security policy for a new application, you first have to identify the servers involved, which might even involve asking a 3rd party where the servers are located on the network. You’d consult an asset-management database or even an Excel spreadsheet. Policy was then created based on static IP addresses, which worked fine because the datacenter is a relatively static environment.   

But for workloads running in the public cloud, policy based on static IP addresses simply doesn’t work.  Why? Simple. The cloud is much more elastic in nature. The underlying servers and networks that run applications can and will change due to deployments and updates via automation (commonly called infrastructure as code – IaC) or auto scaling.  This means the IP address you used yesterday may not work tomorrow, and you cannot rely on a transitory IP address as the identity of a server.  As you might imagine, this causes all sorts of problems if you’re not prepared. 

Because you ultimately don’t control IP addresses in the cloud, you need something permanent to use as identity. So if IP addresses don’t work, what does?  The answer: Tags. 

A Tag is an object composed of two bits of text, a key, and a value, usually separated by a colon “:”(as in key: value). These tags are applied to cloud workloads, both infrastructure-as-service (IaaS) and platform-as-service (PaaS).  A few examples:

environment: production
AppOwner: eric.nelson
billing_org_id: 13795692 

As it turns out, tags are meta-data that have some very beneficial properties. 

1. You control tags – Unlike IP addresses in the cloud, you control the tags you create. Once you assign a tag to an object, it will remain that way unless you change it  This long-lived nature means you can create IT processes around tags, more on that down below.
2. Tags make cloud objects self-describing – Tags as metadata within an object means that you don’t have to consult a 3rd party database to get information about that object.  You don’t need to ask that asset management database anymore, you can query the object itself for information.
3. Tags are freeform – Outside of compositional rules (i.e., Tags cannot contain spaces, tags must be less than 256 characters, etc.) you are free to create any combination of key and value you want. This means you can use language that is relevant and meaningful to your organization. Where Company X might call a group of people working on an internal project a “team”. Company Y might call that a “pod”, and “team” at Company Y refers to an external group of people. The ability to use meaningful language is a very powerful tool for standardization.
4. Tags can enable context-specific policy – Tags not only describe the properties of an object (the environment, who owns it, etc.), but can also define business processes, application tier (web, db, app-tier3, backend), application type (CRM, ERP, internal, Sharepoint), and deployment stage (dev, test, prod, compliance). Tags can describe how often a database is backed up if a storage system needs to be encrypted, or what security policy an application needs. This type of automation extracts every last ounce of efficiency from the cloud.

Security Automation Using Tags

Because tags are a more descriptive identity of a workload, tags are an ideal way to automate the protection of those workloads. At Valtix, we see many companies embrace cloud methodologies (elastic consumption, automated deployment, pay-as-you-go billing) for compute, networking, and storage, but often not for security. There are two reasons for this.

1. Security offerings from the public cloud vendors are not mature. They lack the breadth and depth of data center security solutions. 
2. Companies are deploying virtualized versions of data center security solutions into public clouds to address the shortcomings of #1.

The result is that companies create special IT Ops processes to manage security in the cloud. This is less efficient and works against the reasons you embrace the cloud in the first place!  Valtix was founded specifically to solve this problem. Valtix is a Multi-Cloud Network Security Platform that is 100% cloud-native (no user-managed infrastructure, elastic consumption, automated deployment, pay-as-you-go billing) that gets you out of the business of managing/upgrading/patching virtual security appliances.

Using Valtix’s suite of security services (Network Firewalls, IDS/IPS, DLP, FQDN/URL Filter, Threat Intelligence, etc.) you can create specific and targeted protections for your cloud workloads, and automate their deployment.  Valtix brings cloud security inline with the rest of your cloud infrastructure, resulting in more efficient and secure Cloud Operations

The example below describes how Valtix uses tags to define a security policy:

Valtix uses tags to define security policy by defining what security policy (i.e., only allow inbound TCP/443, block known malware signatures, only allow outbound traffic to pre-defined FQDNs, etc) should be applied to any workloads with that tag. If that workload scales up to use more servers, Valtix automatically adjusts the policy to protect those new servers. This means workloads protected by Valtix are never exposed as their underlying cloud infrastructure changes. Security follows the application.

Valtix aligns SecOps with the rest of your cloud operations, which means you can extract more efficiencies from the cloud and decrease business risk at the same time.

To see Valtix and how we use Tags in action, take our product tour or signup for Free Tier.