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
Oldest First  |  Newest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
'BootHole' Vulnerability Exposes Secure Boot Devices to Attack
Kelly Sheridan, Staff Editor, Dark Reading,  7/29/2020
Out-of-Date and Unsupported Cloud Workloads Continue as a Common Weakness
Robert Lemos, Contributing Writer,  7/28/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 Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-4560
PUBLISHED: 2020-08-03
IBM Financial Transaction Manager 3.2.4 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.
CVE-2019-4589
PUBLISHED: 2020-08-03
IBM Cognos Analytics 11.0 and 11.1 is vulnerable to privlege escalation where the "My schedules and subscriptions" page is visible and accessible to a less privileged user. IBM X-Force ID: 167449.
CVE-2020-4328
PUBLISHED: 2020-08-03
IBM Financial Transaction Manager 3.2.4 is vulnerable to SQL injection. A remote attacker could send specially-crafted SQL statements, which could allow the attacker to view, add, modify or delete information in the back-end database. IBM X-Force ID: 177839.
CVE-2020-4377
PUBLISHED: 2020-08-03
IBM Cognos Anaytics 11.0 and 11.1 is vulnerable to an XML External Entity Injection (XXE) attack when processing XML data. A remote attacker could exploit this vulnerability to expose sensitive information or consume memory resources. IBM X-Force ID: 179156.
CVE-2020-4534
PUBLISHED: 2020-08-03
IBM WebSphere Application Server 7.0, 8.0, 8.5, and 9.0 could allow a local authenticated attacker to gain elevated privileges on the system, caused by improper handling of UNC paths. By scheduling a task with a specially-crafted UNC path, an attacker could exploit this vulnerability to execute arbi...