Organizations are faced with more cybersecurity threats than ever before. Breach conscious shareholders, board members, and changing compliance regulations are forcing management to act swiftly on something they might not fully understand or don’t have time to research. Many vendors are pushing one size fits all solutions to a unique and invasive SSH Key Management problem. The problem with this is that SSH Keys are not like any other access credential. SSH Keys present their own unique challenges and difficulties when it comes to assessing and managing complex trust relationships.
Below is an actual SSH key transitive trust map from a Fortune 500 production environment:
The key observation is that the inter-connected privileged access provided by SSH keys across the numerous servers (physical or virtual) is nearly impossible to remediate in one fell swoop. This goes back to the fact that most enterprises are not even aware of how the SSH keys have been deployed over time and they have no way of discovering, managing, or correcting the privileged access issue in a systematic way.
The nature of SSH key access allows users to create their own access as needed. This can include duplicate credentials such as public and private SSH keys creating complicated many to many relationships. SSH key access does not expire and there is no built-in way to control 3rd party access. Unlike with certificates, there is no Certificate Authority to verify or to revoke access.
Not to fret! The good news is that you can undo years of uncontrolled access with a single button click without breaking your important business access! This complicated mess that took years to create, can surely be fixed with a single button. Sound too good to be true? Well the button you can use to fix everything is big and red with various letters often tied to frustration!: (I will let you fill in the word of your choice)
The simple fact of the matter is that SSH credentials are more complicated to discover, manage, and monitor than certificates or passwords. On its face, the idea that something so complicated can truly be fixed with a few button clicks is a nice dream but, in the end it is a fantasy. SSH credentials have complex differences with certificates and passwords that take years to fully master and understand. Anyone that has told you otherwise does not fully understand the problem.
Lucky for you we at SSH invented the protocol and have spent many years working with Fortune 500 business to help them fully mitigate their SSH access and compliance gaps without disrupting their business process.
“No one was ever fired for hiring SSH experts to fix their SSH key problem!” -Happy Customer
A solution that addresses the problem incorrectly will ultimately cost you and your business money. Your ultimate goal should be to mitigate the most risk, but do this in the least invasive way that will not break or disrupt your critical business processes. This will save you money and headaches over the life of the project.
In order to mitigate the most risk and to avoid headaches down the road, you should consider the following when selecting an SSH Key management solution:
Avoid burdensome privileged access management systems that lock up your SSH keys in a digital vault
- Administrators or privileged users have been known to drop in new SSH keys (yes, they can) to bypass privileged access management solutions to make their own jobs easier
- Vaulting of SSH Keys creates a central point of failure for your critical business processes
Require Continuous discovery of new SSH key deployments
- Without this capability any solution you deploy can be bypassed by privileged users when the user drops in new SSH keys
- If an attacker is able to steal the SSH key an IT admin deployed to make their own job easier, then the attacker can easily bypass the entire privileged access management system
Avoid solutions that are purchased for business reasons only and go against technical user recommendations
- The technical user has the most security knowledge and they know what is needed to mitigate the most risk
- It is often the case said offerings will not be implemented if the technical users think they will break production servers
- This is a situation where simply checking the box could break the box
Understand that a button or a few clicks didn’t create the problem and in the end won’t be able to fix the problem
- It takes process and expertise to truly fix this problem in a way that will not hinder your business
Require NFS support and demand support of all operating systems your business runs on, such as Windows, Linux, UNIX, and z/OS (no, not dead yet)
- If the answer to either of these is “no”, then all of your SSH based access is not under control
Vendors that do not fully understand the critical details and intricacies of the SSH protocol have developed solutions with fundamental flaws in their infrastructure and architecture. These solutions do not understand how to fully gather all the critical information about a particular SSH key relationship before any changes are made. The nature of the SSH protocol allows users to create their own authorizations (sometimes duplicate access), with no expiration dates and no oversight. This has led to an overly complicated web of SSH authorizations across critical business environments. Trying to clean up these environments without the proper skills or expertise leads to broken business processes and downtime.
Our SSH experts come with Fortune 500 experience from across the globe. We have seen many customers choose to not implement a solution that was the result of an upsell because the technical engineers quickly realized it would break their production environment and possibly get the engineer fired.
Don’t be upsold on an inferior solution. Take inventory of complicated SSH trust maps and manage them. Continuous discovery and management of SSH keys is essential to limiting the spread of any potential breach.
Want to learn more? Join me for a webinar on the topic by REGISTERING TODAY!
This is a Security Bloggers Network syndicated blog post authored by John Walsh. Read the original post at: SSH Blog