By Matthew McKenna, Chief Strategy Officer, SSH Communications Security
Word is starting to get out that things can go very wrong if SSH user keys are not managed properly.
Some industry experts theorize that Edward Snowden abused SSH keys to breach the NSA and steal its documents – and no organization wants a situation like that on their hands.
So then, organizations are addressing SSH user key and access management challenges in one of three ways.
A cryptography team, which may already be managing certificates and other PKI related issues, is leading the project, or the challenges are addressed as part of a privileged access management project.
The third option is that, in some cases, organizations try to address it as part of their configuration management system processes.
Which way is the best way? Actually, any of these approaches can work.
However, each of them is missing critical components needed to gain comprehensive control and an understanding of the challenge at hand.
For both individual users and M2M transactions, SSH user keys grant access. 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.
Key Management: Best Practices
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.
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.
Here are three best practices, or pillars, to build successful key management projects upon.
Who gets in?
Of course, a primary concern is taking 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.
Next, the clear segregation of duties where SSH user key-based trusts are in use is an extremely important component related to access.
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.
Jamming the signal.
The need for and usage of strong cryptographic standards and good practices in this area cannot be underestimated.
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.
Improved processes around provisioning and trust rotation can be used to better control cryptography best practices.
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.
Locking down access.
Configuration management has more to do with SSH user key- and access-based controls 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.
Establishing an Environment of Trust
Determining which access controls we desire to have to mitigate risk, ensure resilience and achieve compliance will drive a successful SSH user key and access management project and program.
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.
The goal is for every SSH user key-based trust in our environment to be understood, controlled, monitored, analyzed for anomaly detection and, most importantly, to have an assigned owner.
(Learn more from Matthew McKenna, courtesy of SSH Communications Security and YouTube)
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.