How to Avoid Security Issues in Your Data Connectivity Layer

A watchful eye and staying on top of the latest news and technology are essential to maintaining the data security of your organization.

Companies have a responsibility to make data security at every level a priority, and as headlines like the recent $10 million settlement Target is paying victims of a massive data breach attest, they have a real financial incentive to do so as well.

Security at the data connectivity layer is at increased risk from the growing number of new data sources being deployed in hybrid on-premise and cloud environments, including RDBMS, NoSQL, Big Data and SaaS. If you want to control security across the full breadth of data connectivity, you either have to build it yourself or turn to a trusted data connectivity partner that takes security seriously.

To illustrate this, let’s consider an example data connectivity layer that may include the following connectors:

1. Vendor's relational database connector
2. Open source Big Data connector
3. Third-party middleware to connect hybrid cloud to on-premise environments

When the next security vulnerability strikes, who do you contact first and how can you control patching the data connectivity layer across each of your connectors? Staying on top of data security requires constant vigilance across the full breadth of data sources within organizations, including big, small, cloud and on-premise.  

Chief ​Security ​Officer ​Manages Data ​Connectivity ​Vulnerabilities for You

Today, you’ll get to hear from Sven Skoog, Chief Information Security Officer at Progress, who is dedicated to providing security at the data connectivity layer, ensuring that your customers’ data is protected while in transit across multiple data sources. In this interview, you’ll get essential information about what you need to know when it comes to protecting your data connectivity layer and how Progress® DataDirect® stays ahead of the ongoing data security battle.

FAQs: Top ​Data ​Connectivity ​Concerns ​Interview with Sven Skoog

Q: First things first. Sven, what is TLS/SSL? What is OpenSSL?

A: Without some foolproof method of encrypting communications, it’s possible for an unauthorized third party—such as a malicious hacker—to access your sensitive data, read it or replay it in some second communication other than what you intended. It’s even possible for hackers to alter or corrupt the transmission so as to input incorrect or dangerous values to a communications endpoint. 

Transport Layer Security (TLS), like its predecessor Secure Sockets Layer (SSL), is a communications protocol. Initiated between a client (origin point) and server (destination/endpoint), TLS/SSL is used to encrypt transmissions such that they cannot be read or intercepted by any parties other than those who started the exchange. The 'padlock' icon on your web-browser typically signifies TLS/SSL being used.

As of 2014, 99.6% of the world's one million largest websites use some version of SSL and/or TLS. OpenSSL (www.openssl.org), built from contributors at RSA Security, is one very popular free (open-source) software implementation of the TLS/SSL protocol. SChannel (Microsoft's proprietary SSL implementation) is another such utility.

Q: Hang on. What's the difference between SSL and TLS? Are these the same as HTTPS?

A: Secure Sockets Layer (SSL) is, at this point, a somewhat-aged standard. Its late 1980s creation at the University of California at Berkeley dates back to the heyday of Netscape, who quickly adopted the protocol and guided it through its first revisions.

While any encryption is better than none, various limitations in SSL created a need for an upgraded standard. This led to the creation of Transport Layer Security (TLS 1.0) in 1999, which features a slightly different initial handshake and isn’t limited to web browsing, allowing it to “wrap” (encrypt) many different protocols—email, chat, etc. The newest version of TLS, TLS 1.2, is considered ”state-of-the-art” encryption, suitable for both commercial and government or military use.

HTTPS (Hyper-Text Transport Protocol, Secure) is simply the common HTTP standard used for web pages, wrapped with TLS/SSL encryption. You’ll commonly see it used on secure web pages for things like online banking.

Q: What's all the fuss about SSL, OpenSSL, and TLS? Why so many news headlines recently?

A: As a 20+ year old protocol, both benign security researchers ('good guys') and malicious attackers ('bad guys') have had plenty of time to find flaws in SSL (and OpenSSL in particular). A new SSL bug—whether minor or major—is discovered roughly every fifty days!

The most serious of these bugs concern the initial TLS/SSL handshake. The handshake is the beginning of a connection, when the encryption client and encryption server say to each other, "Okay, we're ready to communicate, send me the cryptographic keys we should use to establish our first secure connection."

Under certain conditions, an unusual (or malicious) client or server can trick the guy on the other side into rolling back to an earlier/weaker type of encryption because it can't handle the latest version. These outdated encryption methods are, at this point, weak and trivial to break; the attacker(s) can read such transmissions as if they were cleartext (never encrypted in the first place).

Q: Give us some examples of these types of rollback attacks.

A: POODLE, FREAK, and LOGJAM (publicized in October 2014, March 2015, and May 2015, respectively) are all attacks which make use of this "please roll back to the earlier/weaker encryption type" vulnerability. Wide swaths of the Internet were—and, in some cases, still are—vulnerable to these TLS/SSL rollback attacks.

The most serious of these, POODLE, was so serious and hard to fix that it basically killed SSL version 3. As of the time of this post, TLS 1.x is the only "reasonably safe" encryption protocol still available for use. In spite of this, only ~45% of the Internet uses TLS 1.x or newer. Clearly our global information network needs to do better.

Q: TLS is the only safe protocol? So SSL is no longer safe for use?

A: That's correct. SSL 3.0 and all previous versions should be considered dangerously unsafe (all transmissions potentially vulnerable to outside interception) as of September 2014. TLS 1.x is strongly recommended, and of these, only TLS 1.2 is "maximally bulletproof."

Q: How would an attacker use TLS/SSL flaws to 'hack' or compromise common services?

A: In the case of a Web (HTTPS) connection, the attack looks like:

CLIENT -----> (begin initial crypto handshake) -----> SERVER

CLIENT <----- ("hello, I accept crypto B, C, D") <----- SERVER

CLIENT -----> ("sorry, I can only do crypto A") -----> SERVER

CLIENT <----- ("okay, I'll roll back to crypto A") <----- SERVER

CLIENT -----> ("ha ha, sucker, we can break/read crypto A")

In the case of a database (JDBC/ODBC) connection, the attack is the same ("rollback to unsafe crypto"), but here, the database operations, contents and possibly the TLS/SSL cryptographic keys employed by users to read/access contents can be accessed as well.

Q: Are there other TLS/SSL flaws which don't involve this 'rollback to unsafe' behavior?

A: Yes, but not so many of them, and they don't tend to make huge headlines.

One notable case was HEARTBLEED (publicized April 2014), which employed a buffer over-read vulnerability in the affected versions of the OpenSSL library. In laymen’s terms, this allowed hackers to read more data than they should normally be allowed to. Around the time of its discovery, XKCD released an awesome comic explaining how it works:

Q: How do Progress and the DataDirect software suite protect against these TLS/SSL flaws?

A: The overwhelming majority of our products, including DataDirect drivers, are built using OpenSSL cryptographic libraries. We keep abreast of industry developments, including TLS/SSL weaknesses, and emergency patches originating therefrom. We subject these products to constant security-based scrutiny, including internal and external vulnerability-scanning, static analysis of pre-release source code and, as a last line of defense, real-time monitoring to detect malicious or anomalous traffic to and from our products ”in the wild.”

Security requires constant vigilance—we have re-released out-of-cycle DataDirect patches to deal with these specific SSL issues, once in 2014, twice (and counting) in 2015—but when dealing with customer data sources, and the potentially sensitive data stored within, there's simply no room for delays or compromise.

Q: Thanks, Sven, for your time. This was very enlightening discussion and a reminder for all of us to keep an eye on our data.

A: You’re welcome! I’d like to continue to urge you (and your downstream user base) to follow suit and exercise constant vigilance in your own data connectivity and associated dealings. Feel free to email me with any questions at sskoog@progress.com.

Comprehensive security for your data connectivity layer

At DataDirect, we make managing data security easy. We’re always here to talk if you have any questions about data connectivity or data security. Just drop us a line or reach out to us in the comments below.

And if you’re ready for the best data connectivity solution on the market, check out the full line of secure Progress DataDirect connectors across RDBMS, NoSQL, Big Data and SaaS.