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

12/8/2014
12:30 PM
Matt Little
Matt Little
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
100%
0%

Open Source Encryption Must Get Smarter

When it comes to cryptography, there are quite a few myths in the age-old debate about proprietary versus open source application security.

Utter the words "open source" in an organization's tech circles, and you're just as likely to hear an application developer gush as to curse. The term is divisive, a rival sports team debate for the geeky set, but one that usually pushes developers and architects to be creative. When it comes to the debate about open source security development, however, there are more than a few myths and definite room for improvement, especially with respect to encryption.

Open source or proprietary: either/or?
Let's start by quickly spelling out benefits and holes in both proprietary encryption solutions and their open source alternatives. For proprietary, you've got something tested (to some degree) out of the box, nice and tidy. Ah, if only you could get it to work the same way the sales engineers described it… but that's part of the reason you signed an SLA for support. And it's why you'll get alerts of bugs and repeated notices to upgrade as you go along. With buy-in, you're given a handshake deal on data protection, someone for backup or blame, depending on where you sit along the chain of risk.

Users opt for open source encryption because of the persistent thoughts -- true or not -- that bringing in outside crypto is pricy and not as secure, because the source is closed. Rather than promises from an outside company that the software has been vetted, you can see a community of developers and a history of product fixes and flaws out in the open.

Open -- for attack
Battles over poorly crafted or badly executed proprietary solutions will be played out in the courts and press. Open source security issues, however, can linger beneath the surface or be confused with an attack on the community that created them. Recent notable incidents offer insight into ways open source security and crypto can get better.

First off, there was OpenSSL. The Heartbleed flaw compromised hundreds of thousands of sites, opening the door to hackers and frustration for anyone who has a password. Months on, there are bugs popping up on every type of website for various versions of this open security framework.

Closer to a traditional understanding of crypto, we were also saddled this year with ruinous problems in TrueCrypt, the open source security software that shut down "mysteriously" due to "unfixed" protection issues. Since the announced shutdown, TrueCrypt's torch bearers keep up the site as a means of migrating away… to a proprietary solution.

How can open source get smarter?
As someone who's spent time on both the proprietary and open community development sides of things, I can offer five factors to consider when making a decision about open source cryptography.

  • Take open to heart: The developers I work with always joke that the best developers "steal good code." It's much simpler to cut and paste if you can trust the source. It's flawed, however, to assume security code is good just because it's open. As simple as it seems, take your developer team to task on what they're using.
  • Born to die: When a bunch of people chip in to create something, it can be hard to pull the plug. If open source creations or iterations are woven throughout the enterprise software stack, it could be left to linger long after its useful life. (Shellshock, anyone?) Software needs to be kept up to date, especially where security is concerned. Companies force themselves to make decisions about which products to kill.
  • The pen is mightier: Any individuals or organizations that take information security seriously should do their own pen testing on an application before they add it to their arsenal. For enterprise customers, there are a number of providers that can provide product security assessments, including white box and black box testing, architecture design assessments, and even threat modeling.
  • You're not a cryptographer: I talked before about not kidding yourself with security. It comes down to this fact: You probably don't have a cryptographer on staff. Real, solid encryption involves more than cracking open a copy of Applied Cryptography by Bruce Schneier. You can do DIY reports or sales analytics, but when it comes to managing keys and implementing ECC (or not), some degree of expertise is in order. Also, open or closed, most crypto is based on a few, vetted standards.
  • Any way to get smarter. Be realistic about your in-house capabilities, user adoption/aptitude, and, most of all, appetite for risk. That training course or conference session could go a long way in terms of sizing up what you're able to pull off safely.

Reflecting on these issues, you'll be able to make a better determination about crafting a solution, bringing in proprietary protection, and strengthening what you've already invested in. With smarter open source security, we're all contributing toward designing the best ways to guard against today's data protection threats.

Matt is a technologist at heart with more than a decade of experience in the IT industry. In his role as Vice President of Product Development, he oversees planning, development, and lifecycle management for next-generation PKWARE offerings, including Viivo. He also plays a ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Matt_Little
100%
0%
Matt_Little,
User Rank: Author
12/18/2014 | 8:33:02 AM
Re: Good points - but what about the next generation?

I've followed the Snowden leaks closely. He's certainly done wonders for those outside of the InfoSec community when it comes to general knowledge about the necessity for encryption. As for how Snowden relates to not trusting proprietary encryption code, are you referring to the intentional weakening of RSA's DUAL EC? Something else? I ask because most of the other leaks detail exploiting vulnerabilities surrounding implementation, not actually breaking crypto. Have I missed something?

I do agree that "you have no idea who has been putting trapdoors into your software" but that applies to open source as well. How deeply must we inspect the code? What about the language used? The libraries that shipped with your OS? What about the compilers? The firmware? Hardware?

The rigor required to write good security software is more often found within established companies. They have processes in place that make the variables mentioned above as consistent as possible.  There's also more control over the team and the talent. A high degree of certainty in all of these areas are critical when it comes to building security applications.

At the end of the day, this game is about trust. We're all making decisions about which products to trust. Just because you can look at the code yourself doesn't mean you're capable of understanding it and just because a "security" expert said the code is fine, doesn't mean it is.

The Ada point is relevant. I don't think it's the solution but if anyone is intereted in more information about some of the security shortcomings of popular native languages and how Ada addresses them there's a free e-book you can grab from AdaCore: http://www.adacore.com/uploads_gems/Ada_Safe_and_Secure_Booklet.pdf

 

 

fustbariclation
50%
50%
fustbariclation,
User Rank: Apprentice
12/15/2014 | 4:15:12 AM
Good points - but what about the next generation?
These are good and important points to bear in mind.

Importantly, though, we now know, through Snowden, that proprietary code, particularly encryption code, can never be trusted - you have no idea who has been putting trapdoors in and it's highly unlikely the very best people you can hire will be able to find them.

It is sad that open source cryptography has been neglected. What you should demand of your encryption software is:

 

- It is open source

- It is easy to understand (if not, you'll find it difficult to spot trapdoors)

- The cryptographic method hasn't been approved by a dubious authority

- It doesn't have any strange, aribtrary blocks of numbers in it

- It is reliabe

 

Naturally, if you're using a proprietary system, like Microsoft Windows, then there's no point in bothering - you are compromised.

The open source community should be providing security software that satisfies these requirements.

To satisfy them all, it should be written in Ada.
Stratustician
50%
50%
Stratustician,
User Rank: Moderator
12/8/2014 | 3:38:55 PM
Great Points!
Some real great advice here, especially since I've seen some of the downsides to having folks in-house work with both out of box and open source software.  As stated here, one of the biggest things is to be honest with your security requirements.  If you don't have the in-house expertise to properly vet an application, getting an outside resource is going to be critical.  Just because open source comes with a nice price tag attached, it doesn't mean you don't have to do due diligence.  You need to make sure that you are aware of any limitations both in functionality AND in security and be honest about it.
Aviation Faces Increasing Cybersecurity Scrutiny
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/22/2019
Microsoft Tops Phishers' Favorite Brands as Facebook Spikes
Kelly Sheridan, Staff Editor, Dark Reading,  8/22/2019
MoviePass Leaves Credit Card Numbers, Personal Data Exposed Online
Kelly Sheridan, Staff Editor, Dark Reading,  8/21/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2016-6154
PUBLISHED: 2019-08-23
The authentication applet in Watchguard Fireware 11.11 Operating System has reflected XSS (this can also cause an open redirect).
CVE-2019-5594
PUBLISHED: 2019-08-23
An Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") in Fortinet FortiNAC 8.3.0 to 8.3.6 and 8.5.0 admin webUI may allow an unauthenticated attacker to perform a reflected XSS attack via the search field in the webUI.
CVE-2019-6695
PUBLISHED: 2019-08-23
Lack of root file system integrity checking in Fortinet FortiManager VM application images of all versions below 6.2.1 may allow an attacker to implant third-party programs by recreating the image through specific methods.
CVE-2019-12400
PUBLISHED: 2019-08-23
In version 2.0.3 Apache Santuario XML Security for Java, a caching mechanism was introduced to speed up creating new XML documents using a static pool of DocumentBuilders. However, if some untrusted code can register a malicious implementation with the thread context class loader first, then this im...
CVE-2019-15092
PUBLISHED: 2019-08-23
The webtoffee "WordPress Users & WooCommerce Customers Import Export" plugin 1.3.0 for WordPress allows CSV injection in the user_url, display_name, first_name, and last_name columns in an exported CSV file created by the WF_CustomerImpExpCsv_Exporter class.