Imagine access that could be self-provisioned without oversight and that never expired. What's more, you had no way of knowing to whom that access belonged. Would you be concerned? Now, what if I told you that this access was touching the core of just about everything that kept your business running? And finally, that this had been going on for the last decade. Would you break out in a cold sweat and start to ask a lot of questions?
Well, that form of access exists in our networks today, and it 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. However, it is the source of the most critical form of access into our networks.
It is used by our IT administrators to remotely access operating systems, application databases and network devices. It is used by our developers to access systems and move code between various systems and into our cloud environments. It is used to securely move data between applications, both on premises and to our clouds. It is used by our vendors and outsourced managed service providers to maintain our systems.
"The fact of the matter is that we need to have accountability for all credentials providing access to our systems"
And probably most concerning, it is used by hackers and malicious insiders as their preferred method to move laterally throughout our networks.
The challenge is that security executives are insufficiently informed about the power and degree of access the SSH protocol provides. If we think about the likes of 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 ex-filtrate data.
On too many occasions, security executives and journalists have been reluctant to escalate the topic of SSH user key-based access. The most common response is, "Well, I need a smoking gun to act on this issue." Here is the point: the smoking guns and evidence are overwhelming. Common sense and our common objective as security professionals to continuously decrease risk should guide us first on this one.
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.
SSH remains the biggest blind spot in our security postures today. It provides 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.
It is not enough these days to say that our PKI team controls SSH keys or that our Privileged Access Management team has the lead on this. The fact is that they don't really have it under control. This issue encompasses all aspects of identity governance today within our environment.
• How is SSH user key-based access provided, de-provisioned and recertified for both human use and application-to-application connections?
• Do we have visibility and accountability of ownership for all SSH user key-based trusts in our environment both on premises, in our cloud and to our network devices?
• Are we aware of cross-platform connections between Windows, Unix and Mainframe where SSH user keys are being used?
• Are we monitoring SSH user key-based connections?
The fact of the matter is that we need to have accountability for all credentials providing access to our systems. SSH user keys equal credentials and that equals access. And when this access touches everything and is ungoverned, it becomes a blind spot that can no longer be quietly ignored.