Before 2013, the average person rarely thought about encryption. But that changed when Edward Snowden breached the National Security Agency (NSA) and disclosed information about PRISM. Since then, a series of events have helped keep encryption at the forefront of everyone’s minds. Most recently, WikiLeaks published a new document in its “Vault 7” data leak series involving the CIA. This new file contained information on “BothanSpy” and “Gyrfalcon,” two hacking tools which enable someone to steal a target’s SSH keys.
Adversaries and insiders have long known how to abuse the trust established by keys and certificates and use them as the next attack vector. Acknowledging that fact, I decided to work with Dimensional Research to understand how organizations were managing and implementing Secure Shell (SSH) in their environments. The researchcovered the responses of 411 security professionals with knowledge of SSH from the United States the United Kingdom and Germany.
What was very evident from the research was the fact that most organizations were inadequately prepared for or incapable of detecting a security incident related to the compromise or misuse of SSH keys. We break down these chilling results below.
A majority of organizations don’t have adequate visibility into their SSH keys. Significantly, 90 percent of security professionals surveyed by Venafi said that they lacked a complete and accurate inventory of all SSH keys. As a result, they had no means to determine whether someone had stolen or misused their organization’s keys.
The issue of key misuse doesn’t relate to only external attackers. Malicious insiders also constitute a threat if they have the ability to configure authorized SSH keys. Organizations can mitigate this risk by creating policies that prohibit such behavior. But according to survey participants, just 35 percent of organizations actually enforce these policies. 61% of respondents said that their organization doesn’t even limit or monitor the number of administrators who are authorized to manage SSH.
As most organizations fail to clarify who can manage their SSH keys, it’s no surprise that many also fail to stipulate how their SSH keys can be used. For instance, nearly half of respondents said that their organization doesn’t restrict port forwarding for SSH, limit the locations where SSH can be used or remove SSH keys when a user leaves the company at 48 percent, 49 percent and 42 percent, respectively. These oversights make it possible for someone to abuse SSH in order to evade other security mechanisms.
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.
Unfortunately, that’s not the case. Seventy-percent of survey respondents said that their organization does not rotate SSH keys regularly. This opens the possibility for an SSH key leak, such as what happened in a security incidentagainst FreeBSD’s infrastructure back in 2012.
Considering that SSH bypasses host-based controls and provides elevated privileges, every organization should make rotating keys a priority. 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.
This blog was originally posted by Gavin Hill on February 26, 2016.
Related posts
Lorem ipsum dolor sit amet, consectetur elit.
Thank you for subscription
Scroll to the bottom to accept
VENAFI CLOUD SERVICE
*** IMPORTANT ***
PLEASE READ CAREFULLY BEFORE CONTINUING WITH REGISTRATION AND/OR ACTIVATION OF THE VENAFI CLOUD SERVICE (“SERVICE”).
This is a legal agreement between the end user (“You”) and Venafi, Inc. ("Venafi" or “our”). BY ACCEPTING THIS AGREEMENT, EITHER BY CLICKING A BOX INDICATING YOUR ACCEPTANCE AND/OR ACTIVATING AND USING THE VENAFI CLOUD SERVICE FOR WHICH YOU HAVE REGISTERED, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ENTERING INTO THIS AGREEMENT ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT THAT YOU HAVE THE AUTHORITY TO BIND SUCH ENTITY AND ITS AFFILIATES TO THESE TERMS AND CONDITIONS, IN WHICH CASE THE TERMS "YOU" OR "YOUR" SHALL REFER TO SUCH ENTITY AND ITS AFFILIATES. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT AGREE WITH THESE TERMS AND CONDITIONS, YOU MUST NOT ACCEPT THIS AGREEMENT AND MAY NOT USE THE SERVICE.
You shall not access the Service if You are Our competitor or if you are acting as a representative or agent of a competitor, except with Our prior written consent. In addition, You shall not access the Service for purposes of monitoring its availability, performance or functionality, or for any other benchmarking or competitive purposes, and you shall not perform security vulnerability assessments or penetration tests without the express written consent of Venafi.
This Agreement was last updated on April 12, 2017. It is effective between You and Venafi as of the date of Your accepting this Agreement.
The Venafi Cloud Service includes two separate services that are operated by Venafi as software as a service, each of which is separately licensed pursuant to the terms and conditions of this Agreement and each of which is considered a Service under this Agreement: the Venafi Cloud Risk Assessment Service or the Venafi Cloud for DevOps Service. Your right to use either Service is dependent on the Service for which You have registered with Venafi to use.
This License is effective until terminated as set forth herein or the License Term expires and is not otherwise renewed by the parties. Venafi may terminate this Agreement and/or the License at any time with or without written notice to You if You fail to comply with any term or condition of this Agreement or if Venafi ceases to make the Service available to end users. You may terminate this Agreement at any time on written notice to Venafi. Upon any termination or expiration of this Agreement or the License, You agree to cease all use of the Service if the License is not otherwise renewed or reinstated. Upon termination, Venafi may also enforce any rights provided by law. The provisions of this Agreement that protect the proprietary rights of Venafi will continue in force after termination.
This Agreement shall be governed by, and any arbitration hereunder shall apply, the laws of the State of Utah, excluding (a) its conflicts of laws principles; (b) the United Nations Convention on Contracts for the International Sale of Goods; (c) the 1974 Convention on the Limitation Period in the International Sale of Goods; and (d) the Protocol amending the 1974 Convention, done at Vienna April 11, 1980.
In the meantime, please explore more of our solutions
In the meantime, please explore more of our solutions
This site uses cookies to offer you a better experience. If you do not want us to use cookies, please update your browser settings accordingly. Find out more on how we use cookies.