Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

10/20/2017
10:45 AM
Simon Marshall
Simon Marshall
Simon Marshall
50%
50%

Contesting Control of Container Security

Who should control container security? It's a question that is gaining importance as containers become a favored mechanism for enterprise development.

Who should control container security?

In the 1995 movie Outbreak, Dustin Hoffman plays a virologist struggling valiantly to stop the spread of an ebola-like virus into the Western world. Once the virus enters the human "network" it becomes progressively harder to stop its lateral movement within the population. It's a plausible scenario, and for that reason, it really scared audiences on its release.

In the end, although Outbreak only scored 59% on Rotten Tomatoes, it posed a very valid question: who, really, is responsible for containing and eradicating the virus? The military, the government, the scientists or even civilians themselves?

As containers become the DevOps application development tool of choice, then keeping them secure creates a similar conundrum. Who is in charge? Is it DevOps, DevSecOps, security or even the compliance department?

Because containers are such a novel way of developing applications, securing them has grown up in parallel and there is no single standard answer to that question. This had led to quite a disparity from enterprise to enterprise about who wears the responsibility mantle.

"Databases were around before dedicated database security tools, the Internet was around before firewalls, PCs were around before anti-virus," Rani Osnat, VP marketing at Aqua Security told Security Now. "Security always follows the adoption, never precedes it. This is no different." And that's why there's such a perspective disparity in terms of who should be in control of securing containers.

Aqua Security helps enterprises in the nascent containers technology niche make informed security decisions, even though each and every business out there is sailing unchartered waters. According to a new study from Aqua, container security ownership currently breaks down by department into 43% DevOps, 36% security, 13% DevSecOps, with 8% falling elsewhere. One reading of this is that DevOps may have intimate container behavior knowledge, but they are likely not the security specialists. Vice versa with the security department.

Asked how this might change in the future, as containers head towards mainstream, 35% of survey respondents replied that security needs to head it all up. But there were almost equal smaller percentage responses for both DevOps and DevSecOps. So perhaps it should grow into a joint responsibility?

"If you look at future ownership by role, it's very clear that container security is not a 'hot potato' that each group is trying to pass on, but rather that groups prefer to either own it or share the responsibility," explained Osnat. So, instead of "one ring ruling them all," there will more likely be a sharing of responsibilities, logically constructed from the specialist experience pools of several departments.

Still, Osnat reckons that DevOps can teach security a trick or two. "While security teams desire sole governance of the topic, their familiarity with containers is lagging when compared with those with hands-on development and deployment experience," he said.

One big apparent advantage in using containers during the app development process is that their DNA makes it easier to apply security versus trying to secure the entire application itself.

"The applications that run in containers may have vulnerabilities, just as those that are non-containerized. But containers can provide better isolation, and due to the way they're developed, an earlier and more frequent detection of vulnerabilities," Osnat reckons.

How would that work? A good example is a theoretical vulnerability in an Apache server. That server, while running inside a container, is just as exposed as one running outside. The difference is that resolving a weakness in a containerized Apache instance is more easily and quickly done than fixing the server itself. That's because the container image can be updated, and a new container can be instantiated to replace the old one without any downtime.

Over time, firms will position their Dev and security teams to optimally deal with threats, but they know that running a DevOps environment, because of its cadence, will also reflect the need to keep evolving the security requirements at-pace.

"Security in the container age cannot be static -- it has to be dynamic and automated, just like the container deployment processes it tracks," said Osnat.

Related posts:

— Curtis Franklin is the editor of SecurityNow.com. Follow him on Twitter @kg4gwa.

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Browsers to Enforce Shorter Certificate Life Spans: What Businesses Should Know
Kelly Sheridan, Staff Editor, Dark Reading,  7/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-17366
PUBLISHED: 2020-08-05
An issue was discovered in NLnet Labs Routinator 0.1.0 through 0.7.1. It allows remote attackers to bypass intended access restrictions or to cause a denial of service on dependent routing systems by strategically withholding RPKI Route Origin Authorisation ".roa" files or X509 Certificate...
CVE-2020-9036
PUBLISHED: 2020-08-05
Jeedom through 4.0.38 allows XSS.
CVE-2020-15127
PUBLISHED: 2020-08-05
In Contour ( Ingress controller for Kubernetes) before version 1.7.0, a bad actor can shut down all instances of Envoy, essentially killing the entire ingress data plane. GET requests to /shutdown on port 8090 of the Envoy pod initiate Envoy's shutdown procedure. The shutdown procedure includes flip...
CVE-2020-15132
PUBLISHED: 2020-08-05
In Sulu before versions 1.6.35, 2.0.10, and 2.1.1, when the "Forget password" feature on the login screen is used, Sulu asks the user for a username or email address. If the given string is not found, a response with a `400` error code is returned, along with a error message saying that th...
CVE-2020-7298
PUBLISHED: 2020-08-05
Unexpected behavior violation in McAfee Total Protection (MTP) prior to 16.0.R26 allows local users to turn off real time scanning via a specially crafted object making a specific function call.