Organisations trying to gain control of their SSH user key and access management typically use one of three approaches. They may give the project to a cryptography team, or they may treat it as part of a privileged access management project. On occasion, they try to come at the problem via their configuration management system processes.
None of these approaches are wrong, per se. However, each of them is missing critical components needed to gain comprehensive control and an understanding of the challenge at hand.
It is critical to get SSH key management right because these 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, organisations can achieve the maximum effect of risk reduction, resilience and compliance. Let’s explore each of the areas further.
Key Management Projects: Doing it Right
What access-related risks are you interested in addressing? That’s the first thing to understand when tackling the SSH user key challenge in your environments.
At the end of the day, SSH is providing access to your 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.
The first order of business is to take control of what key-based access may have root access in your 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, you 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.
Make sure there is a clear segregation of duties where SSH user key-based trusts are in use; this is an extremely important component related to access. It 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.
The need for and usage of strong cryptographic standards and good practices in this area cannot be overstated. The disconnect from those projects being run by PKI organisations 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 organisation.
Cryptography standard procedures are clearer and can be better controlled through improved processes regarding 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 you have a baseline visibility of your 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.
3. Configuration management
You may be wondering what configuration management has to do with SSH user key- and access-based controls. More than you think. Good, standardised SSH daemon configuration management is frequently overlooked in terms of how you can better lock down access in your environments and decrease risk.
With good configuration management, you have the possibility to standardise 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 your environment and SSH usage.
What drives a successful SSH user key and access management project and program is the establishment of what access controls you desire to have to mitigate risk, ensure resilience and achieve compliance. Only from there, and only after you have visibility of the SSH user key-based trust relationships in your environment and can effectively monitor their usage, can you go forward to remediate access and improve the way you provision, remove and rotate access.
Strong cryptographic controls and strong configuration management practices are extremely important supporting roles to achieve your access-related objectives.
In the final analysis, trust is really what it’s all about. Build your SSH user key and access management on the three best practices listed above to ensure that every SSH user key-based trust in your environment is understood, controlled, monitored, analyzed for anomaly detection.
The pinnacle of that trust is to ensure that every key has an assigned owner, regardless of whether it is for interactive administrative usage or for a service account.
Matthew McKenna, Chief Commercial Officer, SSH Communications Security (opens in new tab)
Image source: Shutterstock/niroworld