Overcoming the Double Vulnerability of Open Source Software and Poor Secure Shell Key Management

Featured article by Matthew McKenna, chief commercial officer, SSH Communications Security

Just a handful of years after the Internet became available to the public, the need for encryption became apparent. Without a way to encrypt user information and websites, private data could be stolen by hackers. That would make online interactions unsafe, which would render online shopping and important Web-based communications (with government agencies, for instance) impossible.

OpenSSL was an early answer to the encryption problem, and since its inception in 1998 it has become the encryption standard for two-thirds of all websites. OpenSSL is an open project; any coder or programmer can work on it, so it is not the proprietary property of a company that makes money from it. In fact, the OpenSSL project has a small budget, only one full-time employee and a handful of part-time workers and volunteers. Though the software enjoyed wide adoption, it has had very little supervision. This can lead to significant security issues, as the Heartbleed OpenSSL vulnerability made evident.

When it became clear that OpenSSL had security issues, organizations had to quickly decide what to do about it. Google, for instance, has decided to create an offshoot of the OpenSSL project, currently named BoringSSL. The company had been managing more than 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. By creating BoringSSL, 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.

When open source software entrusted with keeping your data safe has security vulnerabilities, it’s time to re-evaluate its use. 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 Consequences of Poor Key Management

Secure Shell keys encrypt connections and access the organization’s network. The protocol has become the standard and works unnoticed in most enterprises today. The 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 text files provide access to some of the most critical information within an organization.

These keys play a crucial security role, as does managing them well. In a recent report, IDC called out these specific identity and access management (IAM) risks within Secure Shell implementations:

– Lack of visibility into the purpose of key pairs

– Unused user keys that still grant access to critical hosts

– Lack of centralized control over the creation of Secure Shell keys

– Ease of copying and moving private keys

– Limited ability to identify and remove revoked, orphaned and unauthorized keys

– Secure Shell key usage that circumvents IAM controls

IAM control has become increasingly important due to the spike in popularity in machine-to-machine (M2M) activity. A well-considered and comprehensive security plan will address each of these risks.

More M2M Activity Requires Better IAM Controls

Organizations need to control access to cloud infrastructure, applications, servers and both structured and unstructured data, and IAM solutions are part of that security strategy. 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.

To transfer data from one machine to another, a secure encrypted channel is required. For this reason, most of the identities that enable M2M processes use Secure Shell for authentication and authorization. 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 which authorizations are in fact no longer needed.

Security Questions

Headline-making vulnerabilities have caused many organizations to re-evaluate how they use and manage open source technologies, both in their products and within their organization. That’s a good thing. The point here is not that open source is bad. Rather, it is a wake-up call for technology executives to take another look at the essential but frequently ignored infrastructure that their businesses rely on, especially when it is something as ubiquitous and critical as encryption technologies like SSL or Secure Shell.

Important questions to ask include:

– Do we know who is creating keys?

– Do we know which employees and contractors have access to what?

– Are our enterprise open source technologies properly managed?

– Can we quickly respond to vulnerabilities by updating to new versions or rotating keys?

– Can we tell if someone has acted maliciously?

– Does a vendor or internal resources properly support our open source software, or are we blindly hoping someone is in charge?

A Proactive Approach to Open Source Programs

When the world was in need of an encryption solution to secure the Web, OpenSSL came on scene and was quickly adopted by most websites. For almost 20 years, it has done a good job sending sensitive information. Vulnerabilities exist within any software, but if they are discovered in the software that encrypts your data, that vulnerability becomes an opportunity to re-examine your security processes. The opportunity gains urgency in light of hackers’ ability to steal Secure Shell keys by exploiting OpenSSL vulnerabilities like Heartbleed. As described above, those keys grant unfettered and typically undetected access to the network.

Organizations that want to ensure maximum security in their use of OpenSSL and Open Secure Shell protocol will take a closer look at just what’s going on behind the digital scenes. They will ask important questions regarding whether their current key management practices include centralized provisioning, visibility into who is authorized to create keys and for what purpose, and robust IAM controls. This proactive stance regarding encryption strategies will help organizations shut security “back doors” and safeguard their networks.

Matthew McKenna, chief commercial officer, SSH Communications Security