Virtually every enterprise uses Secure Shell (SSH) as the administrative protocol for secure, remote access to nearly all mission-critical systems. If it’s not Windows or a mainframe, then SSH is used to manage it—including Unix, Linux, routers, firewalls, network and security appliances, and more. SSH enables remote access by administrators as well as automated communications between systems.
All SSH access depends on the proper management and security of SSH keys. I cannot say this strongly enough: If your organization does not have an active SSH key management and security project, it is at risk.
SSH is quintessentially about access control. It secures machine-to-machine access in automated systems and user-to-machine access in interactive systems. In both cases, the level of access in which this technology specializes is privileged. For example, automated access enables organizations to spin up and provision virtual machines in cloud services. And interactive access allows IT administrators to remotely configure and manage network devices such as servers, routers, and firewalls.
With SSH being responsible for securely handling communications for your organization’s most critical and valuable digital assets, it’s little wonder that cybercriminals are motivated to steal, break, or otherwise compromise the cryptographic keys upon which SSH relies. The greater the value of your assets, the greater criminals' motivation—and the greater the impact on your organization if they succeed.
What should you do if you don’t have an active SSH key project in your organization? The National Institute of Standards and Technology (NIST) recently issued a new publication, Security of Interactive and Automated Access Management using Secure Shell (SSH), which addresses several critical aspects of SSH, including its underlying technologies, inherent vulnerabilities, and best practices for managing SSH keys throughout their lifecycle. This was an interagency effort and the Venafi CTO of Server Products, Paul Turner, was a coauthor of the paper.
The publication enumerates several vulnerabilities, including, but certainly not limited to, the following:
- Vulnerable SSH implementations, such as implementations that allow weak encryption keys or that use SSH version 1, which is no longer secure
- Improperly configured access controls, which can inadvertently allow unauthorized access to the root accounts that underpin your entire system
- Stolen, leaked, derived, and unterminated keys, which have obvious ramifications and can occur for a wide variety of reasons—including the practice of duplicating keys from device to device so employees can work from home or on the road, thus expanding cybercriminals' opportunities for theft
- Pivoting, which can occur when cybercriminals successfully compromise a key and then use the tainted key to introduce malware that travels throughout your entire system using SSH as its vehicle
I could name other vulnerabilities, many of which you can find in the publication. But by now, you are probably wondering what you can do to prevent criminals from exploiting vulnerabilities in your own SSH implementation.
This is precisely where having the aforementioned active SSH management project comes in. But implementing this type of project can meet resistance. To quote Paul Turner on this subject, “Despite the significant risk that unsecured SSH keys present, many organizations have not implemented an SSH key management and security program because of lack of SSH knowledge at the executive level and internal resistance. IT administrators are accustomed to managing their own SSH keys and individual departments believe other operational tasks take priority. Unfortunately, because many executives don’t understand the significant risk SSH poses if not properly managed, we’ve seen that many enterprises wait until they’ve experienced an SSH compromise before taking action.” To be effective, an SSH key management project needs to be conducted companywide with support from upper management.
The NIST publication outlines SSH management practices your organization should have implemented. For example, it should be maintaining a complete inventory of your organization's SSH keys, one that includes information such as the systems where they’re deployed, key lengths, encryption algorithms, and issue dates.
Your organization should also be using a policy-based system that manages each key's lifecycle, from access request to access termination. And it should be actively monitoring your lifecycle management system.
As for the type of SSH management approach you should use, NIST recommends automation as the only practical choice, especially considering the sheer scale of SSH deployments in most organizations, where many organizations can literally have hundreds of thousands of key instances. Implementing a manual system that keeps an accurate, up-to-date inventory, manages each key throughout its lifecycle, and provides continuous monitoring would take many man-years of effort every month. And it would introduce human error into the process—which is, ironically, one of the vulnerabilities the publication mentions by name.
I strongly suggest that you read Security of Interactive and Automated Access Management using Secure Shell (SSH) for yourself, and if you have any questions or comments about the paper or its content, I'd love to hear them.