By Matthew McKenna, chief operating officer, SSH Communications Security
The Internet relies on OpenSSL. Created as an open source project 16 years ago, OpenSSL protects two-thirds of websites and their user information via encryption. Without the protection that OpenSSL provides, user information would be exposed and readily available for cyber criminals to make off with. E-commerce would not exist in its current form had it not been for the advent of this ubiquitous encryption protection.
The success of OpenSSL is particularly remarkable when one learns that the OpenSSL project has only one full-time employee and operate on a shoestring. However, the downside of this unlikely success is that the software has very little supervision. That has created major security risks, as the Heartbleed OpenSSL vulnerability has amply demonstrated. It’s a wake-up call to the reality that with open source software, sometimes you get what you pay for.
Remediation of this issue can take many forms. Google has taken the step of creating BoringSSL, an offshoot of OpenSSL. 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 security risk is highlighted by the four hackers who took up a challenge by Cloudflare and succeeded in exploiting the Heartbleed vulnerability to steal private Secure Shell security keys. This is why an OpenSSL vulnerability can be so dangerous – and why Google re-evaluated its use of open source software.
Protecting Critical Data
Secure Shell protocol works unobtrusively in the background of the majority of enterprises, encrypting connections and accessing 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 text files provide access to some of the most critical information within an organization.
With critical information at stake, key management becomes a security priority. 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
- Forgotten or unused user keys that enable access to critical hosts
- Limited ability to find and remove orphaned, unauthorized and revoked keys
- Lack of visibility into the purpose of key pairs
- Secure Shell key use that bypasses IAM controls
A holistic security strategy is one that takes each of these factors into account. IAM control becomes increasingly important with the spike in popularity in machine-to-machine (M2M) activity.
Current IAM Controls Miss the Mark
End users deploy IAM solutions to help them 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.
For data to be transferred from machine to machine, a secure encrypted channel is needed. 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.
Both in their products and within their organizations, end users are rethinking how they use and manage open source technologies. That’s a good thing. The point here is not that open source is bad. Rather, it is an opportunity for technology executives to take another look at the important but typically overlooked infrastructure that their businesses depend on, especially when it is something as ubiquitous and critical as encryption technologies like SSL or Secure Shell.
Below are key questions to consider:
- Does either a vendor that we work with or end-user resources properly support the open source software being used, or is it a matter of relying solely on someone’s good will?
- Are the end users’ open source technologies properly managed?
- Does the key management solution we provide enable rapid response to vulnerabilities by rotating keys or updating to new versions?
- Does our end user know who is creating keys?
- Does our end user know who has access to what?
- Can our end user tell if someone has acted maliciously?
Modern Safety Standards
Since 1998, OpenSSL has protected most of the Internet and done it with incredibly limited resources. As the Internet has evolved, though, the project was not able to keep up with all the needed management, resulting in vulnerabilities. This is natural within any software, but it becomes a serious risk. Multiple independent hackers proved that it’s possible to exploit a vulnerability, in this case Heartbleed, to steal Secure Shell keys – the keys to the end user’s network kingdom.
Open source software isn’t enough to protect critical data anymore. Providing end users with a Secure Shell protocol doesn’t instantly fix the problem, either. Current encryption standards require strong IAM controls in light of M2M transfers, centralized provisioning and visibility into who is authorized to create keys and for what purpose. If these standards are not met, end users are not fully covered and their entire network could be threatened.
About the Author:
Matthew brings over 10 years of high technology sales, marketing and management experience to SSH Communications Security and is responsible for all revenue-generating operations. His expertise in strategically delivering technology solutions that anticipate the marketplace has helped the company become a market leader.
Prior to joining the company, Matthew served as a member of the executive management team of Automaster Oyj which was successfully acquired by ADP Dealer Services Nordic. Before this, Matthew played professional soccer in Germany and Finland.
Matthew holds a BA in German from the University of South Carolina and an MBA from the Helsinki School of Economics and Business Administration.