Secure Shell Key Management in the Wake of Open Source Vulnerabilities

June 26th, 2015 by · Leave a Comment

This Industry Viewpoint was authored by Matthew McKenna, chief commercial officer, SSH Communications Security

Telecoms rely on online capabilities to provide the customer service and offer the experiences that customers now expect. Customers can pay their bills online, take satisfaction surveys on their mobile devices and upgrade their plans on the company website. To ensure the safety of customer data, telecoms must adhere to Internet security standards, including encryption. And in light of current vulnerability scares, now is the perfect time to re-assess the encryption solutions in charge of guarding your website.

If you are like two-thirds of all organizations with a Web presence, you use OpenSSL to encrypt websites and user information across the Web. OpenSSL is an open source project that helps to make e-commerce possible by keeping hackers from being able to steal personal data submitted over the Internet. Its popularity is largely based on the fact that it was one of the first encryption solutions on the market, and it has worked quite well for almost 20 years.

However, for all its popularity, OpenSSL project has a small budget and only one full-time employee. Such a ubiquitously deployed software with so little supervision creates 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 software isn’t able to remain current.

Internet giant Google has taken matters into its own hands, creating an offshoot of the OpenSSL project, currently named BoringSSL. The company had been managing over 70 patches to OpenSSL with many more expected. This was making it difficult for Google to maintain consistency across multiple code bases and causing security concerns. The Internet giant is not trying to overthrow open source software, but rather to create an encryption solution that interfaces more securely and efficiently with its Chrome and Android products.

The dangers such vulnerabilities could pose to a telecom’s security are clear and present. This point is illustrated 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 Risks of Mismanaged Keys

What’s so dangerous about stealing a few SSH keys? They are truly the keys to your data kingdom. The Secure Shell protocol works behind the scenes in almost every enterprise without much notice to encrypt connections and access the organization’s network. Keys are simply text files that can be easily uploaded to the appropriate system. 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 authorizations. In the case of Secure Shell keys, those basic text files provide access to some of the most critical information within an organization.

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

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

Any security plan that hopes to withstand today’s online vulnerabilities needs to address each of these risks. IAM control becomes increasingly important with the spike in popularity in machine-to-machine (M2M) activity.

In an M2M World, IAM Controls Need Improvement

Telecom IT departments need to control access to cloud infrastructure, applications, servers and both structured and unstructured data, and IAM solutions can help with that. 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: the identities performing the bulk of operations.

Most of the identities that enable M2M processes use Secure Shell for authentication and authorization because a secure encrypted channel is needed for M2M data transfers. However, holes exist in IAM governance of identities that use Secure Shell. Instead of a centralized 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 authorizations. Without central management and visibility, enterprises cannot be sure how many Secure Shell identities have been created, what these identities are authorized to perform and what authorizations are in fact no longer needed.

Essential Questions

Many companies across all industries woke up to the real threat posed by vulnerabilities, thanks to Heartbleed, and are re-evaluating how they use and manage open source technologies, both in their products and inside their organizations. And that’s a good thing. The point here is not that open source is bad. Rather, it is a call to action for telecom technology executives to take another look at the critical but oft-forgotten infrastructure that their businesses are riding on, especially when it is something as ubiquitous and critical as encryption technologies like SSL or Secure Shell.

  • It is essential, in light of the security risks outlined above, to ask certain questions:
  • Do we know who is creating keys?
  • Do we know who has access to what?
  • Do either internal resources or a vendor properly support our open source software?
  • Are our enterprise open source technologies properly managed?
  • Can we tell if someone has acted maliciously?
  • Can we rapidly respond to vulnerabilities by rotating keys or updating to new versions?

Eyes on the Security Prize

For nearly two decades, OpenSSL has been the go-to resource for encrypting information on the Internet, making e-commerce and many other sensitive online transactions possible. For the majority of that time, it did a great job with just a few employees and a shoestring budget. All software is vulnerable in some way, but when a vulnerability is found in the software that provides your encryption, it’s time to stand up and take notice. It’s an especially urgent call to action when this vulnerability can lead to the theft of your Secure Shell keys.

To keep your assets secure, make sure to use best practices such as strong IAM controls, centralized provisioning and visibility into who is authorized to create keys – and why. Make sure you can answer all the essential questions about SSH key management. These steps will stand you in good security stead regarding current vulnerabilities and those yet to be discovered.

If you haven't already, please take our Reader Survey! Just 3 questions to help us better understand who is reading Telecom Ramblings so we can serve you better!

Categories: Security

Discuss this Post


Leave a Comment

You may Log In to post a comment, or fill in the form to post anonymously.





  • Ramblings’ Jobs

    Post a Job - Just $99/30days
  • Event Calendar