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:
51% of organizations have already been compromised via SSH
60% cannot detect new SSH keys on their networks or rely on administrators to report new keys
74% have no SSH policies or are manually enforcing their SSH policies
54% of organizations using scripted solutions to find new SSH keys were still compromised by rogue SSH keys on their networks in the last 24 months
Global financial impact from one SSH-related security incident was between US $100,000 to $500,000 per organization
Operational versus vulnerability view
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% have inadequate SSH security policies
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.
51% are already compromised
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.
A never-ending nightmare
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!
Time to respond
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.