Skip to main content

OpenSSL’s teachable moment: Secure Shell key management in light of open source vulnerabilities

Imagine an Internet without encryption. Credit card numbers would flow in the clear from point to point. Social Security numbers and other personally identifiable information would be sitting ducks for any cyber criminal to make off with. And government secrets wouldn’t stay secret for long.

Soon after the arrival of the Internet, it was understood that encryption would be needed to transmit any potentially sensitive information online. This is how the OpenSSL Project began. It was founded to create a robust, commercial-grade, full-featured and open source toolkit that uses strong, general-purpose cryptography. The software was much-needed and caught on quickly. Today, two-thirds of all webservers use OpenSSL.

This software has worked quite well for almost 20 years, at no cost to users. Its success has expanded beyond its resources, though – enjoying almost ubiquitous deployment with a budget of less than $1 million per year, one full-time employee and a handful of volunteers. The challenge with this approach is that so little supervision can lead to significant security issues. The Heartbleed OpenSSL vulnerability woke everyone up to the risks that open source software can pose if the management, development and design of the code isn’t up to par.

It has become clear that using open source code needs careful examination due to the threat such vulnerabilities could pose to security. This point is driven home by the four hackers who took up a challenge by Cloudflare and succeeded in exploiting the Heartbleed vulnerability to steal private Secure Shell (SSH) security keys. This is why an OpenSSL vulnerability can be so dangerous.

The critical nature of key management

Working quietly within the infrastructure of most enterprises, Secure Shell keys are text files that encrypt connections and access the organisation’s network. The keys can be easily uploaded to the appropriate system as needed. Associated with each key is an identity: either a person or machine that grants access to information assets and performs specific tasks, such as transferring a file or dropping a database, depending on the assigned authorisations. In the case of Secure Shell keys, those text files provide access to some of the most critical information within an organisation.

In a recent report, IDC called out these specific identity and access management (IAM) risks within Secure Shell implementations:

• Limited control over the creation of Secure Shell keys
• Ease of copying and moving private keys
• No visibility into the purpose of key pairs
• Unused user keys that still grant access to critical hosts
• Secure Shell key usage that circumvents IAM controls
• Limited ability to identify and remove revoked, orphaned and unauthorised keys

Organisations need a holistic security strategy that takes each of these risks into account.

Holes in IAM controls

As machine-to-machine (M2M) activity has gained in usage, IAM control has become increasingly important. IAM solutions are part of an overall security strategy that helps organisations control access to cloud infrastructure, applications, servers and both structured and unstructured data. These solutions manage the identities assigned to interactive human users well, but not so the larger number of identities assigned to the automated processes that drive much of the computing in large-scale data centers. As non-human identities continue to grow, IAM implementations are not addressing the majority of identities present in an enterprise: those automated M2M identities performing the bulk of operations.

M2M data transfers require a secure encrypted channel. That is why most of the identities that enable M2M processes use Secure Shell for authentication and authorisation. However, holes exist in IAM governance of identities that use Secure Shell. Instead of a centralised provisioning procedure, application developers, application owners and process owners may all have identity creation and assignation privileges. This often leads to a lack of proper control and oversight over creation of identities and their authorisations. Without central management and visibility, enterprises cannot be sure how many Secure Shell identities have been created, what these identities are authorised to perform and which authorisations are in fact no longer needed.

Reconsidering the ramifications

Heartbleed is just one example of the open source vulnerabilities that have given organisations pause to reconsider how they use and manage open source technologies, both in their products and within their organisation. That’s a good thing. The point here is not that open source is bad. Rather, it is a call for technology executives to take another look at the crucial but frequently forgotten infrastructure that underpins their businesses, especially when it is something as omnipresent and critical as encryption technologies like SSL or Secure Shell.

IT professionals should be able to answer these questions regarding key management:

  • Are our enterprise open source technologies properly managed?
  • Do we know who is creating keys?
  • Do we know who has access to what?
  • Can we rapidly respond to vulnerabilities by rotating keys or updating to new versions?
  • Can we tell if someone has acted maliciously?
  • Is our open source software properly supported by a vendor or internal resources, or are we relying solely on someone’s good will?

Best practices for a safer network

OpenSSL has been encrypting websites since 1998, and overall it has proven reliable and safe. While any software can have vulnerabilities, this particular software’s vulnerabilities have made headlines specifically because it is so popular and so critical to security. The fact that hackers can use such vulnerabilities to steal Secure Shell keys creates a sense of urgency to re-examine key management within the organisation.

Being able to answer the questions about key management listed above will help organisations take a proactive approach. Best practices for using OpenSSL, as well as Secure Shell keys, include visibility into key use and creation, careful attention to IAM controls and centralised provisioning. This will go a long way toward preventing vulnerabilities that could undermine all other security measures and seriously threaten the network.

Matthew McKenna, Chief Commercial Officer, SSH Communications Security

Image Credit: Shutterstock/Andrea Danti