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
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/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-16275
PUBLISHED: 2020-08-10
A cross-site scripting (XSS) vulnerability in the Credential Manager component in SAINT Security Suite 8.0 through 9.8.20 could allow arbitrary script to run in the context of a logged-in user when the user clicks on a specially crafted link.
CVE-2020-16276
PUBLISHED: 2020-08-10
An SQL injection vulnerability in the Assets component of SAINT Security Suite 8.0 through 9.8.20 allows a remote, authenticated attacker to gain unauthorized access to the database.
CVE-2020-16277
PUBLISHED: 2020-08-10
An SQL injection vulnerability in the Analytics component of SAINT Security Suite 8.0 through 9.8.20 allows a remote, authenticated attacker to gain unauthorized access to the database.
CVE-2020-16278
PUBLISHED: 2020-08-10
A cross-site scripting (XSS) vulnerability in the Permissions component in SAINT Security Suite 8.0 through 9.8.20 could allow arbitrary script to run in the context of a logged-in user when the user clicks on a specially crafted link.
CVE-2020-15139
PUBLISHED: 2020-08-10
In MyBB before version 1.8.24, the custom MyCode (BBCode) for the visual editor doesn't escape input properly when rendering HTML, resulting in a DOM-based XSS vulnerability. The weakness can be exploited by pointing a victim to a page where the visual editor is active (e.g. as a post or Private Mes...