If there was ever a time when integrating security into DevOps was strictly optional, that time is long past. These days, it’s a necessity. DevOps must also be DevSecOps.
For most organizations, the easiest and most reliable way to move to full DevSecOps is by means of a container security provider. This allows you to draw on the experience, knowledge, and resources of a service dedicated to container security, while at the same time freeing your engineering staff to take care of your company’s core mission.
But what should you look for in a container security provider? It isn’t always easy to understand or recognize the basic requirements of container security—Where the key vulnerabilities lie, or what the most effective strategies are for protecting containers.
Following is a basic checklist for choosing a container security provider to undergird your DevSecOps strategy.
When it comes to online security, prevention is an absolute necessity. Reactive security by itself isn’t much better than closing the barn door after the horses have escaped and the barn has burned to the ground.
What are the key elements of preventive security? Detailed vulnerability scans of container images are crucial, along with visibility into specific, component-level vulnerabilities. Scanning for infrastructure vulnerabilities at all levels is equally important. Preventive security includes application of security policies and a flexible system for alerts when vulnerabilities are detected.
Security Across Your Continuous Delivery Chain
Container security isn’t really security unless it covers the entire development and deployment lifecycle—If one part of your pipeline has inadequate security, the entire system is vulnerable. One of the most fundamental principles of DevSecOps is that protection—and in particular, preventive security—needs to be baked in at all phases, from development through continuous integration and deployment. This includes container images, registries, and all infrastructure tools and code.
The runtime environment presents its own set of security challenges. A container security system needs to monitor and protect the host OS, and it needs to be aware of security issues specific to the deployment platform.
A comprehensive container security solution should provide protection across the entire runtime infrastructure, including network connections, firewalls, and the host OS. It should be flexible enough to protect your containers across platforms, and it should have a high level of integration with each platform. It should include a high level of automation, both in threat detection and defense, in order to provide real-time protection in a highly fluid runtime environment.
In highly scalable platforms such as Docker and Kubernetes, A container security solution should scale automatically, so that it provides full image-level protection, no matter how large the deployment.
Once again, DevSecOps means full integration of security into DevOps, which means that, ideally, the security solution should be automatically included as a part of each pod or cluster, so that it is fully integrated not only into the deployment platform, but also into each functional unit of containers.
Aggregated Threat Information
By its nature, information on threats is fluid, and is likely to come from a variety of sources. A container security provider should aggregate information from the best, most reliable, and most up-to-date sources, integrating that information with its own proprietary data.
Proprietary threat information is more likely to include in-house analytics, and tie in to the provider’s fundamental security technology, while aggregated information is more likely to bring in the most current set of threats. Since the latest malware and break-in strategies are often based on earlier code and exploit techniques, integrating proprietary and multi-source threat intelligence frequently lead to the most rapid and effective response to brand-new threats.
Vulnerability Analysis and Prioritization
Every application, every website, and every online service is different, and is likely to have its own unique combination of vulnerabilities. A good container security service should include tools for detecting and analyzing your operation’s vulnerabilities, allowing you and your security service provider to map out a coherent strategy for tailored, comprehensive protection.
A key element of a full DevSecOps-oriented protection strategy should be prioritization, targeting both the most vulnerable entry points and the most sensitive data for the highest levels of monitoring and protection.
Benchmark-Based Security Compliance
For many applications and websites, regulatory compliance is a necessity. If you are involved in finance, banking, healthcare, or government contracting (to name just a few general areas), your software must comply with often very strict security requirements.
Even when you are not legally required to follow a formal security policy, your container security provider should be in compliance with widely recognized standards, such as the CIS benchmarks. You should be able to apply standards such as HIPAA, GDPR, NIST SP 800-190, and PCI, and be able to import custom policies or those from other sources.
A compliance analytics dashboard is also extremely valuable, and depending on the compliance regime(s) which apply to your software, it may be a practical necessity.
Hot Tip: Prepare a Compliance Roadmap
As part of the process of looking for a container security provider, lay out a roadmap for your application, working with the administrative or project management personnel who are responsible for compliance in your organization. Such a roadmap can also serve as the core of your basic DevSecOps strategy. At the very least, it should cover the following points:
- Which regulatory agencies have authority over your software? These may include multiple governments, multiple agencies within a single government, international bodies, and non-governmental industry organizations.
- Which parts of your software do the various agencies have authority over? Typically, security regulations are concerned with specific areas (user data, financial transactions, etc.), so the actual compliance requirements may be fairly focused.
- Which formal standards do the agencies require? You should be able to map specific compliance regimes to specific types of data and specific functions of your software.
At first glance, regulatory requirements may appear to be a formidable hurdle, particularly if your software is involved in such things as international sales, banking, or travel authorization documents. But by setting up a roadmap ahead of time, you can usually reduce the compliance tangle to a manageable set of formal requirements covering limited areas of your software’s activities.
At that point, you can look for a container security provider that is capable of applying such standards, or better yet, has readymade templates for the necessary compliance regimes.
The above is just a short checklist, of course—There are likely to be other areas that you need to consider (a high level of AWS integration, for example, or security for serverless deployments), but it does cover most of the key areas of concern regarding container security for the majority of developers. You can regard it as a starting point in your own search for the best container security provider.
But whatever you do, please take container security seriously, because it is at the core of DevSecOps—And more than anything, because it matters to you, and to your customers.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Twistlock Releases Serverless Runtime Defense
A few months ago, we wrote a piece on “The Continuum of Cloud Native...
Why DevSecOps is No Longer Optional
DevSecOps has been a hot topic within tech conversations for a few yea...
Better Together: Announcing The Twistlock Advantage Program
It’s been about three years since we exited stealth with the first g...
My Security Toolset Today Vs 10 Years Ago
It can be easy to forget how sophisticated IT security tools are today...
How to crash the Linux Kernel with a CDROM interaction – CVE-2018-11506
I’ve recently discovered and reported a buffer overflow vulnerabilit...