Why your security teams are not ready for containers and Kubernetes, and what you can do about it

From a people perspective and an organizational standpoint, many CISOs have said that their security teams are not ready for containers and Kubernetes. This isn’t surprising, given the stark contrast between where we were less than a decade ago and where we are today in terms of systems architecture. I am of course referring to the cloud-native era, which has ushered in a whole new architectural approach.

With Kubernetes at the center asserting its domination, it’s time to start thinking about how we can best prepare security teams for this new era. To do that, let’s look at why they’re struggling in the first place (spoiler alert: it’s because organizations are struggling, too).

Security and organizational structure in the era of cloud-native computing

In the traditional software development and deployment model, things were quite static. We can think of the traditional model as a relay race where the baton was passed from the development team to the platform team to the security team. While this model works well for traditional application architectures, this type of organizational structure is less effective for new architectures for container orchestration and Kubernetes-native applications, where everything is dynamic and highly automated.

But perhaps the most immediate and urgent issue is that most organizations are struggling with change management. This is understandable, as there is a sort of muscle memory that has developed over the span of 20-–30 years about how development, platform, and security teams work with one another. Protocols, processes, and tools have been built around that, and so there is quite a bit of inertia.

Changing this way of working and moving to a modern software architecture (microservices and containers), development, and deployment model—one that relies on CI/CD pipelines—is more complex than just flipping a switch, and is difficult to pull off at scale. Additionally, designing and implementing a security model that aligns with this philosophy is a herculean task. Getting people to a common base level of knowledge about new technologies and processes, and establishing a common point of view across all the cross-functional teams in an organization of 10,000–20,000 people is no small feat.

So what can be done to break this inertia and overcome the challenges of organizational change management at scale? I have a few recommendations and best practices I’d like to share.

Effective organizational change management at scale

One effective way to approach a change management plan in this case would be to build a cross-functional team, which should have representation from the application, DevOps, platform, networking, security, and compliance teams, and set a common goal—let’s say the goal is to onboard two applications and push them to production. This unifies the team behind a single goal while defining a common framework and creating a structure. Even if these two applications are not mission critical, and even if the structure you have created is transient, you’ve already accomplished organizational change, which will build momentum within the organization. And then maybe the next milestone you shoot for is migrating 20 applications into production for Kubernetes, and so on.

To me, this is a much more pragmatic way of handling change management as opposed to the big bang approach of launching a massive Kubernetes initiative and moving all of your applications into Kubernetes at once. With this type of big bang approach, the plane gets so heavy it doesn’t take off at all.

Process changes

With so many different groups needing to work together using a common knowledge base, some process changes will be required. I suggest the following as best practices.

• Application design – Think about security up front and design security into the application itself. Security decisions should be made upstream when the applications are being built.
• Security automation – Hardwire security into the CI/CD pipeline itself, so there’s no manual process involved. This gives you the flexibility to move your applications to different Kubernetes infrastructure, since security is not hardcoded to a certain infrastructure.
• Collaborative security model – Use a tool that automatically empowers all teams to define security rules based on a tiered framework. This will enable you to empower dev teams to participate in the definition of security rules without giving them carte blanche privileges.

Tools and technologies

It’s important to realize that, at least for the next decade, not everything is going to move to Kubernetes, containers, and microservices. So we need to be pragmatic when thinking about our choice of technologies and tools.

Since introducing tools into the equation comes with an incredibly large operating cost burden, you should only introduce tools that are absolutely necessary (i.e. where traditional tools can’t compete).

There are four important considerations to keep in mind when you introduce new tools or technologies:

• You’re likely to have more success if new tools are equipped to handle not just Kubernetes workloads and modern platforms, but also traditional workloads and older platforms, since this aligns with the reality of having mixed workloads.
• Any tools you introduce must integrate or coexist with your existing tools. This should be a hard design requirement.
• Look for new tools driven by APIs—these are more powerful because you can integrate them into your existing processes. Since existing processes tend to have a lot of inertia around them, newer tools that can integrate into these processes make everything much easier.
• Any tools you introduce need to be able to accommodate a multi-platform landscape, since organizations continue to have workloads on Windows, Linux, on-premises, and in the cloud.

Summary

How can you make sure your security team is well equipped for containers and Kubernetes? Focus on change management. You need a practical plan that leverages what you have while incorporating new processes, tools, and technologies. But remember: tools and technologies are less important than change management itself—only effective organizational change management at scale will give security teams what they need to succeed.

Download our State of Cloud-Native Security 2022 market report for insights and recommendations to guide your organization’s cloud-native security journey.

This article originally appeared on Forbes.