IDG Contributor Network: 5 key observations on cloud-native security
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.
1. 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. Because of the shift, concerns about public cloud security erupted, ushering in the era of the cloud access security brokers (CASB), which 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.
2. 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:
Having IT teams go over the bill of material for every product update and validate its compliance
This doesn’t scale. The 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.
Having your IT team patch clean, update golden VMs and make sure everything is right with the environment that are in production
Again, the 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.
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.
Network segmentation
You might have tried to segment or microsegment 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 microsegmented, 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.
3. 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.
4. 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 who 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:
- 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).
- 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 nanosegmentation).
This will 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.
5. 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, and 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.
This article is published as part of the IDG Contributor Network. Want to Join?
Source: InfoWorld – Cloud Computing
Recent Comments