In the early days of computing, use of private networks was more prevalent than it is now. Given that, the use of a network protocol (such as Telnet) that transmitted data in plain text was not cause for much concern. As the use of public networks increased, however, a more secure network protocol was needed. Offering encryption, authentication, and other security mechanisms, the Secure Shell (SSH) protocol has been adopted by organizations as a more secure means to connect remote servers to clients.
The security mechanisms offered by SSH are worthy of this widespread adoption. The use of SSH, however, has an element that requires consideration. For the typical Fortune 500 enterprise that has several million SSH keys granting access to its production servers, a substantial portion of them are unused. This large number of keys can be attributed to those with SSH keys having the ability to generate additional keys outside of the enterprise’s access management process. Also, weaknesses in an enterprise’s process for disabling SSH keys when administrators or developers separate from the enterprise or move into new roles can contribute to unneeded SSH keys. So, the bottom line is an environment may exist where new keys are being generated while existing keys are not being disabled.
As suspected, this proliferation of SSH keys introduces the risk that access is held by those who no longer need it and, perhaps more concerning, by those who should not have the access at all. Given this potential risk of SSH key proliferation, why isn’t SSH a more prominent subject of discussion? A possible reason is that the rights granted through SSH keys may not be fully appreciated or understood by those other than administrators and developers. Another possibility is that the enterprise knows that the access granted by SSH keys is required for administrators and developers to perform their duties and believes that there is little, if anything, that can be done to manage SSH keys.
SSH keys present a unique risk to manage. After all, how common are access management practices where users can grant themselves access without approval? Risky enough. But, add the attraction factor of SSH keys: SSH is widely used to manage servers, routers, firewalls, security appliances, and other devices through accounts with elevated privileges. This makes SSH keys a particularly attractive target for malicious actors. Elevated privileges can be attained through a single SSH key (that wasn’t approved in the first place) to allow a malicious actor access to a server from which elevated privileges can be used to create a new key that allows access to another server (transitive trust). So, the risk is real. But, the solutions are, too.
One of the first elements of the solution is to identify an owner of the enterprise’s SSH strategy and protocol. The lack of a person or group with the authority and the responsibility to manage SSH can leave the enterprise in a position where policies and practices either are not created or are created but not enforced.
The second element of the solution is to develop and enforce a strong key management program. If an enterprise has not addressed key management, it would be worthwhile first to perform an inventory of SSH keys, determine how many keys are enabled and who the users are. Using the results of the inventory, disable unneeded keys and assess whether the access that should remain is at the appropriate level. Lastly, implement and enforce a continuous monitoring program to ensure that the SSH key management practices remain aligned with the enterprise’s strategy.
So, yes, the risks associated with SSH keys are real. An enterprise’s performance of an SSH key inventory and implementation of consistent monitoring of its SSH key program, however, will go a long way toward mitigating that risk.
Editor’s note: ISACA’s new SSH protocol audit/assurance program is free to members and available for download.