SSH Keys: Managing the RisksNIST Urges Key Management, Monitoring, Termination
Organizations must carefully manage their SSH keys; otherwise, they'll pose a security risk. That warning comes from the National Institute of Standards and Technology, which has published a draft of new guidelines for the cryptographic network protocol known as secure shell, or SSH, which is widely used to create a secure channel for linking two systems over an otherwise insecure network.
See Also: LIVE Webinar | Stop, Drop (a Table) & Roll: An SQL Highlight Discussion
The draft NIST interim report 7966, "Security of Automated Access Management Using Secure Shell," is open for public comment until Sept. 26, after which it will be finalized based on feedback received. The report outlines the primary risks associated with managing SSH user keys and offers 118 techniques for mitigating those risks, in part, by actively managing SSH access tokens.
"Management of automated access requires proper provisioning, termination, and monitoring processes, just as interactive access by normal users does," the NIST report says. "However, the security of SSH-based automated access has been largely ignored to date."
But businesses ignore SSH tokens at their own peril. "What a lot of organizations are doing basically is issuing credentials and just completely ignoring them - for years and years those credentials are in use and they're never audited, they're never reviewed, the keys are not rotated - all those practices that we follow for passwords aren't being put in place for SSH," Karen Scarfone, head of Scarfone Cybersecurity and a co-author of the NIST report, tells Information Security Media Group.
What SSH Secures
That's in spite of SSH credentials being used to secure numerous types of services, ranging from file transfers and patch management to disaster recovery and database management. Furthermore, SSH keys often provide privileged-level access to those business-critical systems.
"Secure shell provides the mechanism for system-to-system authentication and encrypts the inter-system communications," says Jonathan Lewis, director of product marketing for Helsinki, Finland-based security vendor SSH Communications Security, in a blog post. "These inter-system connections are often highly privileged - one system gains access to a privileged account on another system. For example, a patch management application may get access to root accounts or a database application access to the Oracle account."
This isn't the first time NIST has detailed SSH security risks and related compliance requirements. "The report highlights how FISMA and NIST Special Publication 800-53 - mandatory minimum controls for federal agencies - already mandate proper management and control of SSH keys and their provisioning," SSH inventor Tatu YlÃ¶nen, who's CEO of SSH Communications Security, tells Information Security Media Group. "As a result, proper secure shell key management is absolutely essential to ensuring compliance with FISMA, SOX, PCI and other industry standards."
Such key management requires out-of-band practices - keeping key management systems separate from systems accessed using SSH keys - as well as tracking who's using which keys, for what purpose, and for how long. "Knowing who within the organization can access what data, and properly terminating access, requires taking secure shell key-based access into account, as the keys can be copied and may remain as backdoors even after a person has left," says YlÃ¶nen, who also co-authored the new NIST report.
But many enterprises are still failing to correctly manage secure shell credentials, says report co-author Scarfone. "A lot of organizations simply aren't aware of good practices for SSH management, so they make a lot of mistakes - they deploy SSH without properly securing it in the first place, and then they don't do any maintenance."
Once deployed, SSH can become easy to overlook. "There's a lot of automation behind the scenes that people have implemented and largely forgotten about," Scarfone says. "A lot of them are internal services or services between business partners, where you have sensitive information that you need to transfer in a set file format from one location to another."
Cybersecurity expert Karen Scarfone details common SSH management problems.
Treat SSH Keys Like Passwords
One essential technique for managing SSH keys is to protect them with the same rigor as passwords - especially passwords that grant all-rights, administrator-level access to systems. "An SSH key that's being used this way is the equivalent of a username and a password - it's another authentication credential that gets you access to a system," Scarfone says.
Also, beware how and where SSH keys get stored, and avoid storing private SSH keys in the cloud. "That's come to light lately with cloud technologies - there have been a lot of cautionary tales lately about organizations that encrypt their storage into the cloud, and also store their encryption keys in the cloud," she says. Doing that, however, means that if an internal or external attacker is able to access the encrypted data being stored in the cloud, then they'll also have access to the key required to decrypt the data, thus rendering the encryption worthless.
With these best practices in mind, organizations should create and enforce SSH policies before issuing a single key. "It's a lot harder to secure SSH keys after you've already got deployments out there," Scarfone says. "Unfortunately, we've heard of organizations that now have hundreds of thousands of SSH keys - and now we're asking them now to go audit and review these hundreds of thousands of keys."
Of course, getting a handle on the problem and minimizing related risks can become a time-consuming and expensive process. "There is certainly a manual side to it that can't be avoided, but no one is suggesting that you go and manually review hundreds of thousands of keys," she says. "There are tools available that help to automate what can be automated, but ultimately you have to get people in the loop and discussing these issues and doing key-issuance operations out of band."