As the leader in Machine Identity Management, Venafi has been performing free SSH risk assessments for several years. Venafi SSH risk assessments provide organizations with an inventory of their SSH keys within a selected environment, as well as the risk levels of those keys, along with prioritized mitigation recommendations. One of the biggest take-aways from performing so many risk assessments is that most organizations are challenged with how to manage SSH in their enterprise.
SSH has been in use for over 20 years with little to no oversight and keys never expiring. So, it’s hard for organizations to have a complete handle on how SSH is being used throughout the business. Oftentimes, even when a policy is in place, it is loosely followed and the keys that predated the policy types are not rotated. This creates a compounding problem for organizations with no easy way to resolve it because they lack the enterprise-wide visibility to see how large the problem is.
SSH Machine Identity Management for Dummies
How much risk is inherent in your SSH environment? We’ve compiled a list of the five most common issues encountered with SSH usage in the risk assessments we’ve completed.
1. There are more SSH keys than you think
When we begin the initial phases of an SSH risk assessment we ask customers how many keys they expect us to find and all too often it’s a fraction of what actually exists in the environment. You may wonder how it could be possible that admins don’t have a good handle on their SSH inventory. But the fact of the matter is how could they without an enterprise tool to do it for them? With SSH being baked into the framework of applications and 20+ years of enterprise processes leveraging SSH, it's easy to see how SSH could have spiraled out of control, especially since these keys don’t expire.
Throughout the years, admins will come and go and it's likely there isn’t a formal process to clean up the keys that they leave behind or know where all of them might be. This leads to a problem when old admins leave and new admins come onboard likely not knowing what the old keys left behind are used for. So, out of fear of causing an SSH related outage, they don’t remove old keys and generate themselves new SSH keys to take care of their administrative tasks and build new keys into their own automated processes. On top of that, users can easily generate their own keys with the SSH keygen command and can simply place them throughout the environment.
Without continuous monitoring and policies that are actually enforceable, this approach can be a recipe for disaster. If these old SSH keys were to be compromised, there would be no quick way to remediate them without having a complete inventory of active SSH keys.
2. Vulnerable SSHv1 is likely still lingering in your environment
Since 1998 it has been known that there are vulnerabilities with SSHv1. With it being over 20 years since the first major vulnerability was discovered, one would think this wouldn’t persist in enterprises to this day, but it does. This may be a result of admins not upgrading to the latest version of OpenSSH, not disabling SSHv1 or possibly believing that legacy applications “need” it to function.
Whatever the reason may be, the fact remains that hackers are like water, there’s a lot of them and you can bet they’ll take the path of least resistance. With SSHv1 hanging around your environment, this could potentially be an easy path for them to take. Without visibility into the entire SSH estate, there is no way to be sure just how big of a problem this could be. Admins may stumble across SSHv1 keys or spot check servers, but without an enterprise tool like Venafi’s SSH Protect to tell you where these vulnerable keys are, you may be flying blind when it comes to this vulnerability.
3. You may be granting excessive root access
If there is any SSH usage at all in your enterprise, there is a high probability that root access is being granted for no other reason than having root access makes things easier. While some applications may require root access to function, the majority do not. This causes an unnecessary blind spot to who is doing what as the activities logged during this session are simply logged as root and not as the individual behind the keys.
This is a major problem when an incident arises, and the activity isn’t mapped to the specific individual responsible. In an ideal scenario, root access would be disabled in the sshd_config forcing individuals to use their own keys to access a host and sudo to root for privilege escalation.
All too often this is not the case, leaving admins with the insurmountable task of trying to track down the root access that has been granted in the environment. What can make this task even more challenging is when you have no visibility as to where the private key resides, resulting in an access orphan. Access orphans are especially concerning when they’re root access orphans, which leaves admins to wonder, “Is this access that can’t be tracked legit or a backdoor for someone with nefarious aspirations?”
4. There’s an issue with your build pipeline
For years the use of golden images has existed in enterprises. It’s a simple, easy process that gets machines created in a repeatable manner. All too often, however, during this process unique SSH keys are not being created for each new machine coming online, leaving you with duplicate SSH keys for every device built off of this golden image. This creates the potential for a Man in The Middle attack should one of these duplicate keys become compromised.
Ideally, the golden image has no SSH keys built into it and has unique keys generated upon being built or there is an automated process in place to rotate the key immediately when the device is spun up. Without an SSH Machine Identity Management solution like SSH Protect, admins are often left in the dark on this as there is no easy way to check for duplicate keys throughout the enterprise.
5. Your SSH policy isn't being followed
When we are configuring a risk assessment for a customer, we want to be sure we set the policies within Venafi to match the policies that are in place for SSH within their company. Once we have the assessment results back, all too often we are finding that the policies they have defined aren’t being followed throughout the enterprise. Some of this is due to keys being found that potentially predates the policy while others are just a blatant disregard for the in-place policy, leaving the admins holding the bag if something were to happen.
Needless to say that without having an enterprise-ready tool in-house there is no way for admins to have the visibility they need to see if the policies they’ve put in place are being followed, much less easily fix a problem should one arise.
Get your free SSH Risk Assessment Today
How does your organization’s SSH security posture compare to those of the top companies that we have evaluated? Get your free Venafi SSH risk assessment and find out. Or learn more about how you can manage your SSH keys and avoid SSH audit failures with SSH Protect.
Get a FREE & Confidential SSH Risk Assessment from Venafi!
Related posts
- 5 Steps that May Be Leading You toward a Ticking SSH Bomb
- Recent SSH Vulnerability Highlights the Importance of Automated Key Management
- Are Cyber Criminals Targeting Your SSH Keys? [in Python Libraries]
Machine Identity Security Summit 2024
Help us forge a new era of cybersecurity
☕ We're spilling all the machine identiTEA Oct. 1-3, but these insights are too valuable to just toss in the harbor! Browse the agenda and register now.