Ever since computers started connecting to each other, people have been thinking about how to keep information on them secure. As the Internet evolved, so did the need for security. Enter OpenSSL, an open project with the goal of creating a free set of encryption tools for the code used on the Internet. Without encryption, personal data submitted online becomes fair game for hackers and online fraudsters. With this layer of protection, e-commerce and other important online transactions are much more secure.
However, nothing is ever completely secure. Software changes are made over time, and unintended consequences result – even with the best supervision and staffing. OpenSSL, though used by two-thirds of all websites for encryption, has only one full-time employee and a small budget. It was only a matter of time until a chink in the armor like Heartbleed came to the surface. Heartbleed clued people into the plight of the OpenSSL project and the dangers of relying on critical software that isn’t adequately managed.
This vulnerability and the weaknesses of the OpenSSL project it revealed were a big deal to companies that relied on it. In response, Google created its own offshoot, 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, resulting in security concerns.
Because its use is so widespread and its maintenance so often underfunded, vulnerabilities in open source software can pose serious security threats. 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.
Key Mismanagement: What You Don’t Know Can Hurt You
Stolen Secure Shell keys are a significant issue. They are part of the security system in almost every enterprise, encrypting 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.
That is what’s so terrible about stolen Secure Shell keys – and why 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:
- Limited control over the creation of Secure Shell keys
- How easy copying and moving private keys is
- Lack of visibility into why key pairs exist
- Secure Shell key usage that bypasses IAM controls
- Unused user keys that still grant access to critical hosts
- Limited ability to identify and remove unauthorized, revoked or orphaned keys
Each of these risks needs to be dealt with as part of an overall security strategy.
This is part one of a two-part series. Part two will address holes in IAM governance, fundamental questions about open source technologies, and the importance of a strong security profile.
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.
Edited by
Stefania Viscusi
