VP of Worldwide Marketing
SSH Communications Security
OpenSSL was started in 1998 to encrypt websites and user information across the Web. OpenSSL is an open project—any coder or programmer can work on it—that aims to keep hackers from accessing personal data submitted to a website. Without OpenSSL, this personal information could be apprehended by cyber criminals. That would make Internet commerce and many other online interactions unprotected and unsafe, and therefore impossible.
OpenSSL arrived on the scene at just the right time, and has grown to become the encryption standard for two-thirds of all websites. Despite this massive growth, the OpenSSL project has a small budget and only one full-time employee. Ten others work part-time, some of them for free. However, 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 up to snuff.
For its part, Google has decided to create 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.
Google re-evaluated its use of open source software because it understood the critical threat such vulnerabilities could pose to its 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 Challenges of SSH Key Mismanagement
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.
Understandably, then, management of these keys is a critical security issue. In a recent report, IDC called out these specific identity and access management (IAM) risks within Secure Shell implementations:
- No visibility into the purpose of key pairs
- Limited 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
- Unused user keys that still grant access to critical hosts
- Secure Shell key usage that circumvents IAM controls
A well-considered and comprehensive security plan will address each of these risks. IAM control becomes increasingly important with the spike in popularity in machine-to-machine (M2M) activity.
M2M Transfers: A Case for Better IAM Controls
IAM solutions are part of an overall security strategy that helps organizations 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: the identities performing the bulk of operations.
A secure encrypted channel is needed for M2M data transfers. 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 what authorizations are in fact no longer needed.
As with Google, Heartbleed has been the trigger for many companies to re-evaluate how they use and manage open source technologies, both in their products and within their organization. And that’s a good thing. The point here is not that open source is bad. Rather, it is a call to action for 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.
Here are some fundamental questions to ask:
- Does either a vendor or internal resources properly support our open source software, or are we relying solely on someone’s good will?
- Are our enterprise open source technologies properly managed?
- Can we rapidly respond to vulnerabilities by rotating keys or updating to new versions?
- Do we know who is creating keys?
- Do we know who has access to what?
- Can we tell if someone has acted maliciously?
OpenSSL provides encryption for the vast majority of websites and provides a safe channel for sending sensitive information…for the most part. Vulnerabilities exist within any software, but if they are discovered in the software that encrypts your data, that vulnerability becomes a call to action. The volume of that call gets louder in light of hackers’ ability to steal Secure Shell keys by exploiting OpenSSL vulnerabilities like Heartbleed. Those keys grant unfettered and typically undetected access to the network.
Best practices for OpenSSL use and Secure Shell implementations include centralized provisioning, visibility into who is authorized to create keys and for what purpose, and strong IAM controls. Organizations that fail to adopt proactive encryption strategies are leaving themselves wide open to security threats that put their whole network at risk
VP of Worldwide Marketing
SSH Communications Security
Jason Thompson is vice president of worldwide marketing for SSH Communications Security. Mr. Thompson brings more than 12 years of experience launching new, innovative solutions across a number of industry verticals.
Prior to joining SSH, Mr. Thompson worked at Q1 Labs where he helped build awareness around security intelligence and holistic approaches dealing with advanced threat vectors. Mr. Thompson holds a BA from Colorado State University and an MA for the University of North Carolina at Wilmington.