In my last blog, I talked about how cloud enables business agility. How cloud-first organizations can focus on the app without worrying too much about all of the tech that enables the app. In other words, realize the business benefit without the effort (cost) of using it. And so that was the focus of the blog – how to realize 90% of the benefits of securing your apps with 10% of the effort.
Here, we will discuss another aspect of learnings from recent customer conversations – the security side. What we found is failing to go cloud-first in security for cloud apps not only has significant ops impacts, but also makes for poor security. There are a couple of dimensions to this:
- Understanding the identity and context of apps
- For network security, which capabilities are key and where are they located (we’ll talk about this in the next blog)
For this blog, we’ll focus on the first piece. Understanding the identity and context of apps and services is critical for visibility and control (aka security) – and always has been. If you don’t understand what the workload is, the value to the organization, and the environment it operates in, you cannot have the right security wrapped around that app.
The app’s identity (what is it?) and context (what is the importance to the business? what business or technical environment does it operate in?) is critical to enforcing security. You cannot enforce the right policy without understanding what it is you are securing. A customer example – for egress, the application “A” (identity) may access github for updates from the non-prod VPC (context), but not from the prod VPC (context).
In the old, infrastructure-centric world, you could depend on physical location/point of origin, protocol, and IP address. An analogy might be: where the car came from and the license plate can be used as a proxy for the identity of the driver. In the cloud, app-centric world, physical location is irrelevant, and IP address is ephemeral. To extend our analogy – let’s now add car sharing and ride sharing – the car/license plate can no longer be used as a proxy for the “driver”. In many cases, using old on-prem tech that assumes an IP address is a good proxy for a workload’s identity in the cloud means you don’t know what you don’t know.
These landscape-scale shifts happen. Past transitions for network security include stateful inspection moving to NGFW/App-ID for Internet apps that defied port/protocol conventions, and Secure Web Gateway (SWG)->SASE for users. In both cases, organizations had to change the way they determined identity and context, or else give up control of their apps and users, respectively. As custom apps move from datacenter to cloud, we see new requirements for cloud-first network security – requirements that move away from those previous schemes to identify and contextualize apps.
So what do we mean when we say cloud-native or cloud-first? In most cases, we’ll assume cloud infrastructure and automatic ops. But the most cloud-first thing you can do is to focus on the app. But enough with lofty-sounding principles – what does that actually mean for security?
App Identity and Context – Cloud-First Requirements
For app identity, we’re answering the question, “what is the app?” Cloud-first organizations will typically use a method developers are already populating – tags. Security visibility and control capabilities need to consume tags as a primary policy object and associate policies with tagged resources regardless of org/control model/origin/IP address. For app context, we’re looking at the business and technical environment in and around the app. Sensitive data, customer facing, regulated, vulnerable, prod/non-prod, etc., can be additional information derived from tags, or from the logical infrastructure they operate in (e.g., VPC, host OS/build).
As I mentioned, security capabilities need to use that identity and context as primary policy objects – across all of security (in our parlance – Discover, Deploy, Defend) – understand landscape, make access decisions, encryption decisions, decisions about additional controls (e.g., threat scanning), and logging decisions.
According to Gartner, this is a practical way of implementing Zero Trust. The pragmatic model they suggest: allow app components to communicate with each other (east-west), or with external services (egress), all else deny. This is what security folks can do when they understand context. It’s the least privilege/Zero-trust model that is best practice when you can do it.
All of this ability to consume identity and context depends on a way of determining identity and context of apps and workloads that doesn’t require another system to maintain – if organizations have to maintain additional infrastructure to identify and contextualize apps, it has two negative impacts.
First, it impacts security – errors and time lag increase risk to apps.
Second, it reduces agility, inserting latency into the development or deployment of apps, and raises ops costs and effort.
To be clear, schemes that have agent-based implementations or custom network signatures cause these impacts, requiring changes in org model, control model, and/or deployment pipeline that slow down the business. Often, these approaches won’t work for all app architectures (e.g. PaaS services) anyway. They might be appropriate for an individual app or workload, but not for widespread use.
Increased Security with Cloud Agility
Back to our analogy for a minute, instead of using the license plate or point of origin to guess at the driver’s/rider’s identity and context, we’re advocating RFID scanning the identification of the rider/driver of the car as they drive by. This enables us to derive a far higher resolution of identity and context. After which we can then be very confident about making access and control decisions – which increases security. Furthermore, we’re getting that increased security without slowing the driver or the car – they’re still going 65mph. And so is your app.
The bottom line is that visibility, segmentation, and security controls based on identity and context have always been the requirement. The thing that has changed (again), is how we must identify and contextualize apps in the cloud era. Clumsy, generalized, schemes that require maintaining separate classification dictate too many requirements of the organization, especially when there are ready-made capabilities at hand.
