Suppose that you own a safety deposit box company. People leave their most precious possessions with you, lock their boxes and go on their way. Now, imagine discovering that each box actually has dozens of keys – and that you don’t know who has them. Strangers could be accessing your customers’ treasures at any time, and you would have no way of knowing.
Then you find out that someone has made hundreds of keys to your private office as well. Nefarious characters could sneak in at night, unlock your office and take whatever they want – including your computer and all its proprietary information. Now, imagine that this has been going on for the last 10 years. After the initial shock subsided, what lengths would you go to in re-establishing the security of your possessions and those of your customers?
This is essentially what is happening in corporate networks today. Instead of physical keys, the form of access is called SSH user keys. SSH user keys have largely been forgotten because really, who in your company is responsible for SSH? It is an encryption protocol that has existed for the last 20 years, quietly doing its job efficiently and effectively. And it is the source of the most critical form of access into our networks.
SSH user keys give IT admins remote access to operating systems, application databases and network devices. They are used by our developers to access systems and move code between various systems and into our cloud environments. They are used to securely move data between applications, both on premises and to our clouds. Our vendors and outsourced managed service providers use SSH keys to maintain our systems.
These uses are all appropriate and necessary. But like the nefarious characters breaking into your office at night, hackers and malicious insiders use SSH user keys as their preferred method to move laterally throughout your networks without detection.
A dangerous irony
If you think about the breaches related to Snowden, Sony and Target, in each of these cases, there is sufficient evidence pointing to the use of SSH user keys to gain access to critical systems and steal data. The challenge is that security executives are insufficiently informed about the power and degree of access the SSH protocol provides.
The fact is that a compromise in privileged credentials is what causes 100 per cent of breaches. Shouldn’t we, then, take particular notice of credentials like SSH user keys, which are the only form of access that can be provisioned without oversight, don’t expire and aren’t linked to an identity? However, because the impact is so pervasive and all-encompassing across our networks, it is something that we are reluctant to discuss with the C-suite: “Well, we somehow forgot about this issue over the last 15 years. Sorry.”
There had been a general reluctance within the security community to seriously discuss the topic of SSH user key-based access. The most common response is, “Well, I need hard evidence to act on this issue.” Here is the point: the hard evidence is overwhelming. Common sense and our common objective as security professionals to continuously decrease risk should guide us first in this situatio
A dangerous irony is at work here, in which legitimate access is used to perpetrate breaches – thus leaving no trace. How would enterprises know if SSH user keys were the privileged credential source that caused the data breach if they have no idea who these credentials belong to, don’t have an inventory of them, are not monitoring them and don’t have a governance process regarding their provisioning, de-provisioning and recertification? They wouldn’t, and they couldn’t.
Thus, SSH user keys represent the biggest security blind spot today. They provide access to our most critical systems and network infrastructure. Our traditional layered security concepts are blind to what goes on inside the encrypted sessions. It is a gap inside the majority of identity governance administration programs today.
What you can’t see can hurt you
This visibility gap can prove devastating; SSH tunnelling is an example of how badly things can go. SSH tunnelling (also called SSH port forwarding) is a method of transporting arbitrary networking data over an encrypted SSH connection. It can be used to add encryption to legacy applications. It can also be used to implement VPNs (Virtual Private Networks) and access intranet services across firewalls.
As useful a thing as SSH tunnelling is, it also includes risks that need to be addressed by corporate IT security teams. SSH connections are protected with strong encryption, which makes their contents invisible to most deployed network monitoring and traffic filtering solutions. This invisibility carries considerable risk potential if it is used for malicious purposes such as data exfiltration. Cybercriminals or malware could exploit SSH to hide their unauthorised communications, or to exfiltrate stolen data from the target network. SSH tunnelling attacks can also be used for hiding the source of the attack.
Immediate action is needed
The serious nature of this situation requires more than an assurance that our PKI team controls SSH keys or that our Privileged Access Management team is in charge of the keys. The fact is that these teams don’t actually have the key situation under control. This issue encompasses all aspects of identity governance today within our environment.
Therefore, it’s time to go beyond standard assurances and ask some important questions:
Just as you would need a complete and accurate list of all deposit box keyholders, you need to know who has the keys that grant access to your systems – and who has the power to create those keys. If you don’t know who has access to what and can’t immediately say who is monitoring, provisioning and controlling those keys, you are living with a huge blind spot that has the potential to allow unrestrained access and tremendous damage to your organisation.
Tatu Ylonen, founder, SSH Communications Security
Image Credit: Leolintang / Shutterstock