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

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
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
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
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27621
PUBLISHED: 2020-10-22
The FileImporter extension in MediaWiki through 1.35.0 was not properly attributing various user actions to a specific user's IP address. Instead, for various actions, it would report the IP address of an internal Wikimedia Foundation server by omitting X-Forwarded-For data. This resulted in an inab...
CVE-2020-27620
PUBLISHED: 2020-10-22
The Cosmos Skin for MediaWiki through 1.35.0 has stored XSS because MediaWiki messages were not being properly escaped. This is related to wfMessage and Html::rawElement, as demonstrated by CosmosSocialProfile::getUserGroups.
CVE-2020-27619
PUBLISHED: 2020-10-22
In Python 3 through 3.9.0, the Lib/test/multibytecodec_support.py CJK codec tests call eval() on content retrieved via HTTP.
CVE-2020-17454
PUBLISHED: 2020-10-21
WSO2 API Manager 3.1.0 and earlier has reflected XSS on the "publisher" component's admin interface. More precisely, it is possible to inject an XSS payload into the owner POST parameter, which does not filter user inputs. By putting an XSS payload in place of a valid Owner Name, a modal b...
CVE-2020-24421
PUBLISHED: 2020-10-21
Adobe InDesign version 15.1.2 (and earlier) is affected by a memory corruption vulnerability due to insecure handling of a malicious .indd file, potentially resulting in arbitrary code execution in the context of the current user. User interaction is required to exploit this vulnerability.