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.

Operations

5/1/2018
08:00 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Are You Protecting Your DevOps Software 'Factory'?

New study highlights insecurities in DevOps toolchain implementations.

new study out today shows that DevSecOps could stand to use a healthier dose of OpSec, as many DevOps tools are left exposed on the public Internet with little to no security controls.

So much of the education about the intersection of DevOps and security focuses on application security testing and secure development practices. But DevSecOps is about more than just securing the software product itself. It's also crucial to protect the "factory" that produces those applications — namely, the development infrastructure and DevOps toolchain.

Unfortunately, according to a new study conducted by researchers with IntSights, a statistically significant number of DevOps organizations are falling down on that second part of the equation.

"Given DevOps tools sit in the cloud, they are more vulnerable to reconnaissance by hackers," says Alon Arvatz, co-founder of IntSights. "As opposed to traditional IT tools and servers that are still protected by the company network, a misconfigured DevOps tool will expose its data directly to the Internet, meaning hackers don't need to use any special hacking tools, just simple scanning tools that are available online."

Arvatz and his team examined nearly 26,000 URLs of different DevOps tools and servers from a range of organizations and did a simple test by trying to connect to them through a browser.

"No fancy attack tools, or port scanning, or any preliminary data, except for using open OSINT [open source intelligence] tools and websites to create the list," the report explains.

They found that more than 23% of those tested were accessible from the Web, with a range of access levels.

"Some were totally exposed without any user/password combination, exposing company data, user lists, internal server names, etc.," the report explained. "Most were protected with a simple login page, and a minority with a more robust cloud access security broker." 

The trouble is that even those tools and servers that did have nominal security controls in place still left enough breadcrumbs and openings to make it easier for attackers to gain entry. For example, many organizations used DevOps tool names for a Web-facing server — such as Jenkins, Kibana, Trello, Jira, and so on. Additionally, most tools don't have built-in multifactor authentication, leaving the security of the system up to a simple username and password combo.

Ideally, many standard technologies and practices of DevOps can be used advantageously for security purposes. For example, the use of infrastructure as code and automation of systems can provide a very efficient means for helping organizations consistently lock down their development and production application infrastructure. 

"Because we have this infrastructure as code, we're getting a lot of reuse," explains Paula Thrasher, director of digital services for General Dynamics, a large federal IT integrator, who says that prior to a DevOps-oriented pipeline, her teams could expect 60% reuse of design patterns and infrastructure. Now that number is pushing 90%. "Which basically means 90% of the stuff in our production is a reusable standard, and not a special-snowflake bespoke server. That's huge, because it just takes down the attack surface."

Of course, on the flip side, that means that one mistake is amplified across an entire organization. As an organization scales, a misconfiguration makes it into every single instance a team fires up rather than just the one in a single insecure bespoke server. So, the stakes are higher. 

Arvatz explains that DevOps can do a lot to help raise security posture in an organization and most of the tools involved have the capability to be used securely. But at the same time, organizations need security-conscious administrators in charge.

"Some [DevOps] tools do offer inherently higher security in their basic configuration, and most cloud platforms offers robust security defenses, but some tools rely entirely on their operator knowledge and expertise," he says. "The general shortage of experienced employees in the DevOps and security fields and the fact that most if not all tools are cloud-based make them prone to human errors."

In addition to renaming DevOps tools on Web-facing servers and implementing multifactor authentication, Arvatz and his team suggest a number of other best practices for these tools. These include using proxy servers, stopping the use of default ports, and meticulously keeping up on the patching of infrastructure. They also suggest blocking access to the servers altogether from the Web when feasible, though they acknowledge that may not always be practical.

Related Content:

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
5/2/2018 | 4:03:31 PM
Alarming
Its alarming to see that externally facing infrastructure is not even being password protected (a very weak form of protection). What is even more alarming is that these devops tools are utilizing company data instead of test data.
BradleyRoss
50%
50%
BradleyRoss,
User Rank: Moderator
5/2/2018 | 11:40:15 AM
Do You Believe in Magic
With Continuous Integration, DevOps says that you can install modified software as soon as it passes the test suite.  Even if you could have a test suite that would test every required function for the application, how can a test suite insure that you haven't added vulnerabilities.  Remember that many people think that Agile means no documentation (rather than don't write more documentation than you need) so you don't know what to test for.

There was a song entitled "Do You Believe in Magic".  I get the feeling that a lot of IT management feels that Agile, Scrum, DevOps, SecOps are magic wands and everything will go perfectly so long as you recite the proper incantations at your stand-up meetings.  They don't think that you need to think about anything else.  (And the product looks like they didn't think about anything.)  Before you expect them to understand the need for security, you need to get them to understand how to write software that works.
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19589
PUBLISHED: 2019-12-05
The Lever PDF Embedder plugin 4.4 for WordPress does not block the distribution of polyglot PDF documents that are valid JAR archives.
CVE-2019-19597
PUBLISHED: 2019-12-05
D-Link DAP-1860 devices before v1.04b03 Beta allow arbitrary remote code execution as root without authentication via shell metacharacters within an HNAP_AUTH HTTP header.
CVE-2019-19598
PUBLISHED: 2019-12-05
D-Link DAP-1860 devices before v1.04b03 Beta allow access to administrator functions without authentication via the HNAP_AUTH header timestamp value. In HTTP requests, part of the HNAP_AUTH header is the timestamp used to determine the time when the user sent the request. If this value is equal to t...
CVE-2019-19596
PUBLISHED: 2019-12-05
GitBook through 2.6.9 allows XSS via a local .md file.
CVE-2019-19590
PUBLISHED: 2019-12-05
In radare2 through 4.0, there is an integer overflow for the variable new_token_size in the function r_asm_massemble at libr/asm/asm.c. This integer overflow will result in a Use-After-Free for the buffer tokens, which can be filled with arbitrary malicious data after the free. This allows remote at...