- English
- Contact Us
Before the Snowden breach, the average person rarely thought about encryption. Last year, however, encryption was at the forefront of everyone’s mind. People wanted to know what Edward Snowden disclosed about the National Security Agency (NSA) PRISM, how they could avoid being spied on, and how Snowden was able to compromise what’s believed to be one of the most secure networks in the world. Although not everyone has been paying attention, keys and certificates have actually been at the center of news for the last few years. Adversaries and insiders have long known how to abuse the trust established by keys and certificates and use them as the next attack vector.
One of the first projects I worked on this year with the Ponemon Institute was to understand how organizations are protecting themselves from a Snowden-like breach, resulting from vulnerabilities related to Secure Shell (SSH) keys. The research spanned four regions, which included responses from over 1800 large enterprises that ranged from 1000 to over 75’000 employees. What was very evident from the research is that most organizations are inadequately prepared for or incapable of detecting a security incident related to the compromise or misuse of SSH keys. Some chilling results:
More than half (53%) of organizations surveyed lack the ability to define and enforce SSH policies from a central view. As a result, they typically rely on individual teams or application administrators to secure their own keys. Because these organizations do not have visibility into how SSH keys are used within the enterprise network, detecting any security incident related to the misuse of SSH keys is very difficult. Organizations that view SSH key security as an operational problem are clearly missing the point: keys and certificates are fast becoming one of cyber-criminals’ preferred attack vectors because of the trust status they provide.
74% of organizations either have no SSH policies or are manually enforcing an SSH policies. Using the latest GitHub exposure of more than 600 SSH private keys as an example of application administrator behavior, you can see just how well manual processes are enforced—they’re not. If you are not familiar with this example, enhancements to the GitHub search functionality inadvertently exposed hundreds of application administrators’ private keys that had been stored in GitHub, many by simple mistake. You cannot rely on manual processes to secure and protect SSH keys; mistakes are inevitable.
Last year the Ponemon Institute published the 2013 Annual Cost of Failed Trust Report. In this report, the most alarming key and certificate management threat was SSH. In the SSH research conducted in 2014, Ponemon Institute found that 51% of organizations across four regions had a security incident related to the compromise or misuse of SSH keys. More alarming is that 50% of the compromised organizations used homegrown scripted solutions to manage SSH keys. This clearly shows that scripted solutions cannot detect the anomalous usage of SSH keys or rogue SSH keys used nefariously. Moreover, 60% of organizations surveyed rely on application administrators to manually detect rogue SSH keys.
As the research suggests, organizations have limited visibility into how SSH keys are used in the enterprise network and no ability to apply policies to SSH keys. However, you would think that even organizations using manual, disparate SSH key management would provide guidelines for rotating SSH keys. After all, SSH keys have no expiration date. According to Ponemon Institute research, 50% of organizations do not have an SSH key rotation plan in place. At Venafi we’ve encountered a number of organizations that have SSH keys assigned to ex-employees on critical servers, and these ex-employees left the organization more than five years ago. Considering that SSH bypasses host-based controls and provides elevated privileges, every organization should make rotating keys a priority!
When asked how quickly their organization could identify and respond to a security incident related to compromised or misused SSH keys, nearly half (45%) of the respondents could mitigate the threat in one day or more. The length of time it takes to respond to a security incident, directly increases the financial burden organizations need to bear from the security incident. The financial impact for United Kingdom, Germany, and Australia ranged from US $100,000 to $250,000. US-based organizations were more significantly impacted, ranging from US $500,000 to $1000,000.
By using a stolen SSH private key, an adversary can gain rogue root access to enterprise networks and bypass all the security controls. Because organizations have no policies, visibility into SSH vulnerabilities, or ability to respond to an SSH-related attack, cyber-criminals are turning to SSH as an attack vector at an ever-increasing rate. Every organization needs to stop viewing SSH keys and the management thereof as an operational matter that can be resolved with a few simple discovery scripts or relying on individual application administrators to self-govern. You wouldn’t do that with domain credentials, so why treat SSH keys—which enable elevated root privilege—any differently?
Every organization needs to have central visibility into the entire SSH key inventory, understand how SSH keys are used on the enterprise network, and apply SSH policies. Only then will an organization be able to quickly detect security incidents related to SSH and immediately remediate them.
In the meantime, please explore more of our solutions
