No Longer a Niche Issue: What C-Levels Need to Know About SSH User Keys

Featured article by Matthew McKenna, chief strategy officer, SSH Communications Security

In the long list of things C-level executives have to think about, SSH user keys is not likely to be among them. A niche infrastructure element hardly seems worth their notice or attention. But that would be a wrong conclusion.

Why? Because SSH equals access, and SSH user keys are the credentials that provide that access. All C-levels understand what passwords are, why they are important and why controlling them is even more important. Well, the main difference between SSH user keys and passwords is critical: The creation of a password is a controlled process. The creation of SSH user keys is not. This means someone can create access to your servers and data, creating credentials without oversight.

SSH is a reliable means of providing remote access securely for administrators and vendors and securely moves data in many cases from point A to point B. It has been doing its job quietly and efficiently in your businesses for the last 15 years. It’s what we can refer to as the known unknown.

SSH sits on 60 percent of the world’s Web servers and comes pre-installed at an operating system level on all Unix and Linux variants. It is the primary means of accessing and providing maintenance to servers as well as to your network devices, your routers, switches and firewalls – all the things that keep your business running.

Out of Control

With such an important function and near-ubiquitous presence, you would think SSH would be well controlled. But it hasn’t been, and there are reasons for that. First, in the majority of companies today, SSH is not centrally owned or governed by a particular group within the business. It has historically sat in the underworld of Unix administrators and local application owners for the last decade. Access has been provisioned on an ad hoc basis. Administrators are not bad guys; they are tasked with keeping your systems up and running in the middle of the night. They want to do their jobs quickly and efficiently.

In addition, regulatory bodies are only now beginning to understand what this form of access means. Until the release of the NIST-IR 7966, “the best practices on interactive and automated access for SSH key-based access,” there was no authoritative guidance on the topic. The major consulting houses are just starting to develop practices to help advise their customers on how to approach and manage the risk.

Another reason is that identity access management teams have not perceived it as part of their job to control this form of access. SSH keys are slowly but surely finding their way into projects related to privileged access management but are primarily being looked at from the perspective of “flesh and blood” users of the keys. Unfortunately, upwards of 80 percent of the SSH-related access is for machine-to-machine connections. On the other side of the coin, cryptography teams have only been asked to look at certificates and encryption keys. SSH user keys have traditionally not been in their remit, either.

Even though the SSH protocol is one of the largest uncontrolled access risks to their businesses, many executives, even at the world’s largest companies, don’t understand what it is. As they become educated about SSH, they raise a very logical question: “I have never heard of a breach related to SSH or SSH user keys – why should I be concerned about this?”

That’s the problem – you wouldn’t know if you’d had a breach related to SSH. Most companies today do not have inventories of the SSH user keys their administrators have created over the years. These key-based credentials are not monitored. You don’t know where they are being used from, how frequently or why. You are not able to associate them back to owners in your environment. The fact is, you wouldn’t know if a malicious actor had access to SSH user keys in your environment. You wouldn’t know if they were misusing this encryption to exfiltrate data out of your organizations. In essence, it is the perfect attack vector for malicious actors.

So, you end up with the frightening scenario of uncontrolled access to your trading systems, your payment processing systems, your databases where you hold credit card information or patient data, your routers and switches which keep information flowing efficiently, your file transfer systems which move that data. Imagine uncontrolled access to everything that keeps your business up and running. This is not only a question of risk and compliance; it is a question of resilience.

Keys Gone Wrong: A True Tale

Let’s imagine a situation ripped from the pages of everyday business life: Your company has just hired a new contractor to help with some IT-related work. They are put through an approval process with the human resource team and approved by the business owners whom they will work for. You onboard them into your identity access management system. They are provisioned a user name and password, given a computer and are able to begin their work.

As work progresses, the contractor begins to provision SSH user keys and gain access to test machines and maybe even leave some keys behind on production machines. Their contracting period comes to an end. They are removed from your identity access management systems, their user name and passwords are revoked, their computer collected. The system worked and all is well. Unfortunately, it isn’t. You forgot to revoke their key-based access. And unfortunately, you can’t because you never tracked or controlled the provisioning of this critical access. The contractor who has just left your organization still has access.

Getting SSH Back on Track

Given the impact that mismanaged keys can have, SSH user key-based access can no longer be ignored or swept under the carpet with the hope that upper-level executives or auditors don’t find out about it. To give a sense of the size of the issue: in a banking environment with 30,000 Unix/Linux servers, one can expect to find up to 4.5 million SSH user keys for application-to-application connections and 450,000 SSH user keys for system administrator- or database administrator-related access. That’s 4.5 million potential points of access to your most critical systems that you don’t have a strong degree of control over.

Security professionals and C-levels need to ask a few basic questions of their access management, cryptography and infrastructure teams in order to get a clear assessment of where they stand in terms of SSH user key management. They need to find out who’s responsible for controlling SSH user key-based access in the enterprise, as well as who provisions and de-provisions that access. They also need to ask if there’s currently a policy that controls this form of access and, on the off chance that there is, whether they can enforce it. The answers will help organizations know where they stand and where to start to create a more secure SSH environment.

Chief Strategy Officer

Matthew McKenna brings over 10 years of high technology sales, marketing and management experience to SSH Communications Security and is responsible for all revenue-generating operations. His expertise in strategically delivering technology solutions that anticipate the marketplace has helped the company become a market leader.

Prior to joining the company, Matthew served as a member of the executive management team of ADP Dealer Services Nordic and Automaster Oy, where he was responsible for international channel operations and manufacturer relations. In addition, he was responsible for key accounts including Mercedes Benz, General Motors, and Scania CV. Before this, Matthew played professional soccer in Germany and Finland.

Matthew holds a Bachelor of Arts degree in German from the University of South Carolina and an MBA from the Helsinki School of Economics and Business Administration.