If you work in DevOps, you’ve likely heard the mantra that DevOps success is all about the right people, tools and processes.

Below, we take a look at how you can address the “tools” part of that equation when it comes to security. Specifically, we’ll discuss which questions to ask and what features DevOps teams should look for when choosing a security tool for today’s cloud native infrastructures.

What is cloud native, and what does it mean for DevOps?

Our discussion about security tools and platforms is informed by two main considerations. First, we’re going to focus on the security challenges that arise in cloud native environments—which means those built with technologies that include, but are not limited to, containers, serverless functions and (of course) virtual servers.

Second, we’ll focus on the security needs of DevOps teams and the software development lifecycle. Although DevOps positions may not explicitly involve security, we now live in the age of DevSecOps, and everyone on the DevOps team has a role to play in keeping infrastructure and applications secure. DevOps security is here to stay, and is not only an accepted part of the software development process but is also a key aspect of modern software quality.

In this article, we’ll consider which types of tools are best suited to help DevOps teams deal with security issues while also promoting the visibility and collaboration that are essential parts of a healthy DevSecOps strategy.

So, those are our goals; now, let’s look at the questions you should ask as you evaluate cloud native security platforms for a DevOps organization.

What are you actually securing?

This question may seem obvious—so obvious that you may not give it much real thought—but because today’s infrastructures and environments vary so widely, it’s important to step back and figure out exactly what you need to secure if you want to successfully implement DevSecOps.

Are your workloads running in containers? Are you also using serverless functions, or do you plan to add them? How are you orchestrating your workloads? Are you orchestrating them with the native orchestrator provided by your cloud vendor, Kubernetes running as a service, your own Kubernetes build, or something else? Which new cloud native technologies does your DevOps team expect to adopt in the future?

Answering questions like these is important in order to ensure that you choose a security platform that can support all of your current and future cloud native environments as well as DevOps processes that focus on application security. In most cases, you’ll find that security platforms that are purpose-built to secure a range of environments (not just containerized ones, which are usually the focus of most self-proclaimed “modern” security platforms) are the best and safest fit for your DevSecOps needs.

What are your security threats (and how can you stop them)?

This is another question that might seem overly obvious to your DevOps team, but here again, the fast-changing nature of threats and the agile nature of software development means that it’s worthwhile to take some time to ask what your potential threats actually are. This may include communication with your security team, as well as a review of past data breaches and security flaws.

Keep in mind, too, that the threats faced by your development teams, or the app you deliver via continuous deployment, may be different from those that threaten other teams (e.g., InfoSec, operations teams). Again, this is one place where the DevOps principle of cross-organization communication is crucial for effective vulnerability management.

Which layers does the security platform secure?

Scanning container images for known vulnerabilities is good. On its own, however, it hardly amounts to a complete container strategy. The same could be said for setting up a firewall or locking down access control–these are good security practices, but to achieve true DevOps security, you need to secure all layers of your infrastructure (including those managed by teams other than your DevOps team) against all vectors of attack. For that reason, you want a cloud native security platform that is designed for holistic security, not merely a security tool that only secures one or two layers.

Where does the security platform get its vulnerability information?

When it comes to identifying vulnerabilities, security platforms can get their information from lots of sources. They could look at a public CVE database, or at a list supplied by the tool’s vendor.

The best security platforms, however, will pull vulnerability data from multiple sources. After all, if you’re only relying on one data source to figure out where the threats are, you are unlikely to catch them all—and just like in the world of Pokémon, catching them all is one of your main priorities for secure DevOps. You need a platform with security tools that pull data from multiple sources to identify threats and vulnerabilities.

How automated is the platform?

Automation is the mother of DevOps (or something like that).

What I mean is that without automation, you can’t do DevOps very effectively.

You also, incidentally, can’t do cloud security unless you rely heavily on automation. That’s because the highly dynamic nature of containerized, serverless and other cloud native environments means that trying to interpret all of the data they generate, identify vulnerabilities, and react to them manually just doesn’t work. That’s why you want a cloud native security platform that automates DevOps security tasks wherever and whenever possible–and minimizes human error.

You should still expect to have to perform some tasks manually, of course (which is actually a good thing—If we could automate everything, DevOps engineers wouldn’t need to exist anymore). But to the extent possible, your security platform should automate your security-related workflows. That is another key aspect of security best practices.

Interested in learning more? Check out these 7 Tips to Navigate Operationalizing DevSecOps.

  • Categories:
  • DevOps
← Back to All Posts Next Post →