This article originally appeared in The New Stack.
These days, you have no shortage of options and strategies to choose from when deploying an application. From bare-metal servers to local or cloud-based virtual machines, to containers and serverless functions and beyond (and I’m not even mentioning different operating system or cloud hosting choices), you can build your infrastructure and application environments in many different ways.
In most respects, this choice is a good thing. But this new freedom for application deployments has one major drawback from the perspective of security: the more types of deployment strategies you use (or the more often you switch from one to another), the harder it becomes to keep all of them secure.
That is why it’s useful to embrace the concept of a unified security strategy. This means putting in place the tools and processes you need to secure any and all environments.
This article explains why and how to implement a unified security strategy.
The Problem: Diverse Architectures and Environments
If you’re an organization of any size, you probably don’t use just one type of infrastructure or one software platform for hosting applications.
You instead might host some resources on on-premises bare-metal servers, while using cloud instances to host others. You may deploy some applications in virtual machines while others run in Docker containers — and perhaps connect them all to an event-driven serverless architecture for executing certain functions.
Also, even if your infrastructure and software environments are highly homogenous today, they may not stay that way forever. You may, for example, move some workloads to a different environment in the future — or at least have the flexibility to do so.
From a security perspective, all of the above creates a challenge. Different types of platforms and environments raise different security concerns and require different approaches. That’s not to say that no tool or process can work for all infrastructures (it can), but it does mean that the more diverse your application deployment strategy and hosting environment, the more variables and environment-specific factors you have to think of when securing applications and data.
For example, if you use containers, you have to think about a variety of special components, such as registries and orchestrators, that would not exist with a different type of infrastructure. Likewise, a cloud environment creates special firewall challenges, because traditional firewalls were not designed for highly distributed perimeter-less architectures.
The Solution: Unified Security
Unified security is the answer to this challenge. Unified security means what it sounds like — a security strategy that accommodates all types of infrastructure and environments.
Unified security is the opposite of building a strategy wherein you apply different tools and processes to each type of environment that you run. This approach leaves you with a siloed security workflow that makes it difficult to share security tools or information between different environments.
Implementing Unified Security
What does unified security look like in practice? Consider the following tips for getting started with a unified security strategy:
- Choose security tools that support a broad range of environments. This is the first and most obvious step in building a unified security strategy. Avoid tools that are designed to work only with one type of environment — like an on-premises data center or a public cloud — and instead choose those that can support whatever you throw at them;
- De-silo your team. Unified security requires not just unified tools, but also unified personnel. In other words, you need all team members to have visibility into all of your environments, and to collaborate with one another. This is what DevSecOps means, and it’s part of the reason why DevSecOps is so critical for securing modern environments;
- Build a multi-layered defense. A multi-layered security system is one that secures multiple types of components — like storage, networking and application runtimes. Not only is multi-layered security critical in today’s complex environments, but it’s the only way to build a broad, unified security architecture. Some of your environments or infrastructure may not have all of the layers you secure; for example, a bare-metal containerized environment won’t have a virtualization hypervisor for you to worry about. But you should still focus on securing all layers so that you cover all layers that exist in all of your environments;
- Secure all parts of the application lifecycle. Most people tend to think of security as something to worry about mainly for production, public-facing environments. But the reality is that the environments on which you depend are probably not all production environments. That’s why it’s important to accommodate testing or other non-production environments as well when creating a unified security strategy. Security tools that integrate with CI/CD pipelines can help you to do this;
- Think about the future. A key factor to keep in mind when designing a unified security strategy is that you should focus not just on securing the environments you have in place today, but also enable the flexibility to secure new types of environments tomorrow. I’ve noted this above, but I’m noting it again because if you don’t future-proof your unified security strategy, you deprive yourself of much of its value.
A unified security strategy is essential for keeping applications and data secure in the complex, heterogeneous environments that power organizations today. If you’re still relying on a siloed strategy that centers on different tools, processes and people for different types of environments; you undercut your ability to scale and adapt to the future.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
2019 Gartner Market Guide for CWPP: What You Need to KnowRead the Blog
Key Differences in Security, Management for Serverless vs. ContainersRead the Blog
Docker vs. KubernetesRead the Blog
How Cloud Workload Protection is Different than Application SecurityRead the Blog
Zero-Trust Security: What It Means and How to Achieve ItRead the Blog