Feature
A recent film chronicled the downfall of the US subprime home loan market, and its parallels to the current state of Secure Shell (SSH) protocol and SSH user keys were astonishing.
The first parallel is the understanding of the problem – or lack thereof.
Second is the challenge related to oversight of the problem.
The third is how significant the impact or consequences are of not addressing the problem in our enterprises.
Understanding SSH Protocol
Just like the specialized, secretive world of the subprime loan market, the SSH protocol is something very few understand in sufficient detail. Neither do they understand the underlying critical access it is providing to our most important infrastructure.
In this case, however, ignorance is not bliss.
Secure Shell (SSH) protocol is a protocol for secure network communications designed to be relatively simple and inexpensive to implement. SSH keys are a way to identify trusted computers without involving passwords.
SSH gives more than 95 percent of enterprise administrators and developers an effective means of gaining encrypted access to critical infrastructure: operating systems, applications, payment processing systems, databases, human resource and financial systems, routers, switches, firewalls and other network devices.
The Problem With All Those Keys
SSH is a lifeline of traffic flow within our data centers, our cloud environments and how our third-party vendors and supply chain access our environments. It has done its job quietly and efficiently over the last two decades.
Unfortunately, the access that SSH has been providing, in particular the access SSH user keys provide, has gone largely unmanaged — to a huge degree.
How huge? It’s typical to find up to 4 million SSH user keys providing interactive and machine-to-machine-based access in a typical financial enterprise with 20,000 Unix/Linux servers.
In many cases, we will see that 10 to 20 percent of these keys provide root-level access and cannot be associated to an owner within the enterprise.
Root-level access is the highest level of privilege at an operating system level.
It is not just a compliance and risk issue. It is an issue of resilience that has the opportunity to impact the potential downtime of critical services within our operations.
Who Is Minding the Store?
It’s strange to think that a problem of this magnitude has gone undetected for so long.
It’s primarily a question of mindset. SSH has long been seen as an encryption protocol rather than a means of access and, as a result, has not been considered as a part of our access governance processes and frameworks.
In fact, until October 2015, there were no NIST guidelines related to the best practices associated with SSH user key-based access.
Access controls, such as least privilege and segregation of duties, are mentioned in many regulatory guidelines — including PCI, SOX and HIPAA — but none of them specifically address SSH user keys as a form of access that needs to be controlled.
Is this because of the lack of understanding of SSH or an unwillingness to wake the sleeping giant?
3 Technical Considerations About SSH Keys
There are three technical considerations regarding the lack oversight and governance of SSH user key-based access.
SSH user keys are the only form of access users can provision themselves without oversight or control
Unlike passwords, administrators, developers and third-party vendors can provision themselves access to your critical infrastructure or automate a process or file transfer. This process of provisioning, de-provisioning and recertification of SSH user key-based access is infrequently if never addressed in the IAM frameworks of enterprises.
Unlike certificates, SSH user keys don’t have expiration dates
This means that SSH user key-based access continues to exist, even after an application is decommissioned or a user leaves the company.
Learning Opportunities
Webinar
Apr
24
The State of Outsourcing: At the Crossroads of AI, Quality, and Cost Savings
Learn how companies can maximize the results from their outsourcing investments.
Register
Webinar
Apr
30
Supercharge Contact Center Efficiency with Generative AI
Learn practical strategies to reduce post-call documentation time by over 8 minutes.
Register
Conference
May
1
Qualtrics X4 Salt Lake City 2024
Register
Webinar
May
2
Unleash AI for Crisis Management: Transform Threats into Triumphs
Learn how Sprinklr Insights provides real-time insights on current events, trends, and brand crises to empower your team.
Register
Webinar
May
9
Driving Customer-Centricity in the Financial Services Industry
Discover how financial organizations are leveraging generative AI technologies.
Register
Conference
May
9
An Irish Roundtable in the Valley: The Economic Impact of AI on the World of Work Stanford 2024
Exploring the Impact of AI On the World of Work with Irish diaspora leaders and tech business champions from the North of Ireland
Register
SSH user keys do not need to be associated to a user account
This means a key will not necessarily establish the identity of the user associated with it. When an SSH user key is generated, the identity that is associated is not connected.
Now think about the ramifications of these three realities.
Users can provision SSH user key-based access themselves without oversight to my most critical infrastructure. This key-based access does not expire.
Does that mean it is not clear which identity it is associated with? Yes. And there are millions of these across my enterprise, which we don’t have an inventory of, and they are providing access to my most critical systems? Yes.
Serious Implications About SSH Keys
So we have a lack of regulatory oversight and governance of SSH user key-based access.
We have a lack of understanding of the technical aspects of the SSH protocol. These would be enough to contend with on their own, but we also have an additional concern.
SSH is the primary means by which malicious actors move laterally within an enterprise to gain access to new assets and further elevate privilege, as well as how they exfiltrate data and assets from an organization.
In fact, LightCyber’s Cyberweapons 2016 Report indicates that in over 50 percent of the cases, the SSH protocol is the tool of choice to gain this lateral movement across the assets of an enterprise.
SSH Keys Are Attractive to Cyber Criminals
Cyber criminals know SSH user keys are not being managed, so they go after private keys to gain access to assets. From there, they will often create new key pairs, which will generate them access to the outside directly or move those assets automatically to servers in the cloud.
This is all achieved using something called “port forwarding” via “SSH tunneling,” which would allow the malicious actor to extract this data via the encryption itself, rendering firewalls ineffective.
This activity can take place without our knowledge — as often as perpetrators like — because we don’t know who owns the keys to attain that encrypted access and because we are not able to look inside the encryption of those sessions.
The potential impact is clear.
- We lose our data – or worse, our customer’s data
- We lose our intellectual property
- We lose our reputation and, in turn, we lose revenue and shareholder value
The Added Problem of Downtime
As if the monetary drawbacks were not bad enough, there is also the drawback regarding operational resilience.
The potential downtime in critical systems, should SSH user key-based access to those systems be compromised, is a concern we need to consider seriously.
Our disaster recovery systems, which are failovers to our production systems, often share identical SSH user keys that ensure the processes of those systems fail over in an identical manner. This means that any compromised keys in production environments can also equally affect the failover to disaster recovery systems.
A Lesson from Wall Street
It should be clear by now that it’s not far-fetched to compare the state of SSH with the housing crash.
We have a lack of market understanding around the power of the SSH protocol and the criticality of the access it provides to our infrastructures.
We have a gap in regulatory and governing oversight of how this SSH user key-based access should be monitored, provisioned, de-provisioned and recertified.
We have an encrypted protocol, which malicious actors use as their tool of choice to extend their access and reach within our enterprises, create backdoors and exfiltrate data.
As a result, we have a potential financial, operational and brand impact that can conservatively be described as significant to our businesses.
For those who can see the writing on the wall, as a handful of Wall Street investors did in 2008, there is time to act based on the facts. It’s not too late for enterprises to gather all those involved with SSH use and security to create a plan that protects the keys to your kingdom.
Title image by Katy Belcher
