The Three Pillars of Successful SSH User Key Management Projects

Featured article by Matthew McKenna, Chief Strategy Officer, SSH Communications Security

Whenever I visit customers who are seeking to get SSH user key and access management challenges under control, I see them approaching the issue from one of the three angles. The project is being led as an extension of a cryptography team, which may already be managing certificates and other PKI related issues, or the issue is being addressed as an extension of a privileged access management project or, in some cases, I see customers attempting to address the issue as part of their configuration management system processes.

So, who is right and who is wrong? The fact is that they are all right. However, each of them is missing critical components needed to gain comprehensive control and an understanding of the challenge at hand.

At the heart of it, SSH user keys grant access, either for interactive flesh-and-blood users or, even more frequently, for file transfers and application-to-application connections. Beneath this are important factors such as the usage of proper cryptographic standards, as well as proper controls of the SSH daemon configurations in our environment. When managed properly in unison, organizations can achieve the maximum effect of risk reduction, resilience and compliance. Let’s explore each of the areas further.

Best Practices for Key Management Projects

First, in order to tackle the SSH user key challenge in our environments, we need to understand first and foremost what access-related risks we are interested in addressing. At the end of the day, SSH is providing access to our most critical infrastructure, and risk reduction and resilience are of the highest priority. Here are three best practices, or pillars, to build successful key management projects upon.

Access. Obviously, we want to have control of what key-based access may have root access in our environment and, more importantly, how deep the transitive trust of this access extends. The question to be answered here is, “If I breach one root key, how deeply can I penetrate into the environment?” Next, we need to understand which key- based trusts are for interactive usage and which are related to service accounts. Each key- based trust, regardless of its usage, should be assigned back to an individual owner in the environment to establish accountability.

Then, an extremely important component related to access is to ensure the clear segregation of duties where SSH user key-based trusts are in use. This means having a clear understanding of what key-based connections may be running across development to production environments and re-establishing clear IP source and command restriction accountability of all key-based access within the production environment.

Cryptography. We should not underestimate the need for and usage of strong cryptographic standards and good practices in this area. The disconnect from those projects being run by PKI organizations is the idea that we need to manage SSH user keys in the same way that we manage certificates. The significant difference between SSH user keys and certificates is that SSH user keys have no expiration dates. And whereas a service may go down if a certificate is not rotated, SSH user keys provide access and will continue to exist if not removed after an application is decommissioned or an administrator leaves an organization.

The best practices in cryptography are more straightforward and can be better controlled through improved processes around provisioning and trust rotation. The essentials are key size, key algorithm and key age. Additional components for consideration are passphrase protections related to private key controls and the elimination or rotation of SSH1 keys regardless of status and use case. Once we have a baseline visibility of our environment in terms of the SSH user key based trust relationships that exist, getting cryptographic policies under control for remediation and future provisioning is easier to manage. Additionally, the remediation of cryptography-based policies poses a lower remediation risk and high security value versus access-related remediation, which has a higher remediation risk but the highest security value.

Configuration management. What’s this? What does configuration management have to do with SSH user key- and access-based controls? More than you think. Good, standardized SSH daemon configuration management is frequently overlooked in terms of how we can better lock down access in our environments and decrease risk. With good configuration management, we have the possibility to standardize key locations and ensure unified version management, but more importantly, control access-related controls such as which sub-channels of the protocol may or may not be used, deny root access and restrict deprecated SSH versions and algorithm usage, as well as control login restrictions and log how frequently and from where keys are being used. These controls, when implemented properly, already provide us a good baseline of control in our environment and SSH usage.

Managing Trust Relationships

The fact of the matter is that a successful SSH user key and access management project and program is driven by the establishment of what access controls we desire to have to mitigate risk, ensure resilience and achieve compliance. Only from there, and only after we have visibility of the SSH user key-based trust relationships in our environment and can effectively monitor their usage, can we go forward to remediate access and improve the way we provision, remove and rotate access. Strong cryptographic controls and strong configuration management practices are extremely important supporting roles to achieve our access-related objectives.

Ultimately, though, what we are really trying to achieve is that every SSH user key-based trust in our environment is understood, controlled, monitored, analyzed for anomaly detection and, most importantly, has an assigned owner, regardless of whether that key is for interactive administrative usage or for a service account. That is the only way we can be sure we are on the right track.

About the author:

Matthew brings over 10 years of high technology sales, marketing and management experience to SSH Communications Security and is responsible for all revenue-generating operations. His expertise in strategically delivering technology solutions that anticipate the marketplace has helped the company become a market leader.

Prior to joining the company, Matthew served as a member of the executive management team of Automaster Oyj, which was successfully acquired by ADP Dealer Services Nordic. Before this, Matthew played professional soccer in Germany and Finland.

Matthew holds a BA in German from the University of South Carolina and an MBA from the Helsinki School of Economics and Business Administration.