This post originally appeared in InfoWorld.
While the term “cloud” used to be the main topic of discussion in the technology industry, “cloud native” is taking its place — and with it, “cloud native security.” There are many elements to keep in mind as more organizations begin to build their IT and security in the cloud, but here are five key observations to consider as your organization seeks to understand the different elements.
Cloud native security has nothing to do with cloud access security brokers.
When people started focusing on working in the cloud, many organizations realized they needed to switch gears and start to consume software-as-a-service. As a result of the shift, concerns about public cloud security erupted, ushering in the era of the cloud access security brokers (CASB), who typically handled tasks like securing Salesforce data.
That may have been the case early in the cloud days, but it has very little to do with another theme that has evolved in recent years. Lately, more software development groups have started to produce cloud software, because their companies need to build great new software to engage customers and enable new business models. This all underscores the “every company is becoming a software company” and “software is eating the world” themes.
But if you built an application for your company’s customers, and you don’t want to be the next Equifax, you have to put several layers of security around it. This is cloud native security — and it’s fundamentally different from the role of a CASB. While both have to do with the cloud, they address two very different problems.
Cloud native security replaces existing application hygiene and active threat protection practices. When first faced with the question of how to secure your cloud native software, the initial response is to use the existing security tools.
That’s one option — but it’s not very efficient. You’d either have to automate a lot of manual practices, or risk security becoming the bottleneck of innovation in the company.
The following security concepts just don’t scale in a cloud native world:
1. Having IT teams go over the bill of material for every product update and validate its compliance. This doesn’t scale. Dev and Ops teams came together to build devops so they can move fast, but without incurring the risk of causing issues by frequent changes or fixes to the software.
2. Having your IT team patch clean, update golden VMs and make sure everything is right with the environment that are in production. Again, Dev and Ops teams built devops so they can own patching, and don’t have to wait for IT to complete the ticket on their behalf.
3. The role of WAFs. You used to synchronize between WAFs, whose purpose was to stop attacks between your workloads. The person running the WAF can’t keep track of all the micro workloads on top of all the changes going on.
4. Network segmentation. You might have tried to segment or micro-segment your network to segregate workloads to contain the day that a vulnerability might be introduced. While this is a good concept, it doesn’t work well in reality in a micro-segmented, agile workload. You quickly end up with people finding exceptions of why they need access between various parts, and once you can’t keep discipline, segmentation doesn’t really work.
Cloud native security, however, follows your application from cradle to scale. It has more information about the applications, and it uses them to automate all the elements mentioned above.
Automation enables you to get stronger, more granular security, and it allows you to focus on expressing a meta policy of security based on the applications, rather than manually configuring your security mechanisms every time the workloads change/get updated. It also allows you to integrate into modern deployment tools, which enables a direct discussion with the developer.
Cloud native security still requires multiple layers of defense. In traditional security terms, you’d think about multiple security layers. You’d think about things like code hygiene, package management, operating system patching, server endpoint security… the list goes on. I wish I could tell you that these are no longer needed. But it’s important to understand that using cloud native workloads doesn’t give you any shortcuts from this standpoint — you still need to wrap your software with all the required layers of security.
Cloud native security is end-to-end security. The devops movement changes the grouping of traditional expertise into two different categories. There’s the devops side of the house, which represents developers that want to deploy microservices; and there’s the infrastructure team, which represents the cloud. Often, even these two sides turn into a single “cloud” team, with multiple responsibilities.
If you think about security for this environment, it makes much more sense to break it into two groups as well:
1. Cloud native infrastructure: Including security that wraps services you consume from the cloud (e.g. L3-4 firewalling, server security, network encryption and storage encryption).
2. Cloud native application: Including any security element that needs to be application aware (e.g. L7 firewalling, security penetration tests, image security, application hygiene and application nano segmentation).
This will actually change the types of security offerings we see in the marketplace. Cloud vendors will add more traditional infrastructure capabilities into their cloud offering, enhancing their platform attractiveness, and providing an “all inclusive” offering, which covers all the infrastructure security needs. Security providers, on the other hand, will focus mostly on the application level security, and again would be required to provide end to end security solution — which will also be required to include multiple elements mentioned earlier.
Cloud native security is operated by the cloud team. Traditionally, the layers of security mentioned in the last sections have required expertise from different people or teams (e.g. endpoint, server, network, identity, PKI, storage, software development). You could have people manually adding these security layers as infrastructure was allocated and as applications were deployed, and then call in the right operational experts on your team to configure the necessary “cloud” concept. But allocating these resources needs to be instantaneous, and the security offerings need to improve.
Cloud native security is already fueling a major change. It’s dictating that a meta policy around security layers needs to be defined by the security and infrastructure architects — but on a daily basis, the security mechanisms that enforce them must attach automatically to the cloud and to the devops process. This rounds out the entire process, by allowing the devops or cloud teams to operate it as seamlessly as possible.
- Cloud Native
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Cryptomining Malware Emerges
I have been watching for the spread of malware that, primarily, uses c...
Calling the Twistlock API from PowerShell
The Problem This morning, a colleague was looking for situations where...
What Makes Distributed Security ‘Cloud Native’: Podcast Overview
I caught up with Scott Fulton III on this edition of The New Stack Mak...
Reflections on the 20th Anniversary of Open Source Technology
Exactly twenty years ago in February 1998, the term “open source” ...
Enhanced Syslog Data Streams: 2.3 Deep Dive
In each of our Twistlock releases, we publish some truly remarkable fe...