Bringing Sanity and Clarity to SSH Management for Stronger Security

Poor to no visibility is a dangerous scenario for enterprise and government IT executives today. In trying to manage their digital infrastructure, they often are faced with one question: Which functional group within IT should be responsible for SSH management?

The reason this lack of visibility is such a struggle is that, unlike other IT investments, Open SSH comes pre-installed on servers and networking and storage gear. By default, it’s just there to be used, and administrators and application developers use it extensively.

Used by system administrators and application owners alike, SSH is a protocol that securely communicates, controls machines or facilitates secure file transfers. SSH works remarkably well, and the encryption is extremely effective at preventing man-in-the-middle eavesdropping attacks. However, in the wrong hands, this same SSH encryption can be leveraged to circumvent security controls.

To use SSH, matching public and private key pairs are created to ensure authentication. The public key is primarily used for automation and is sometimes used by system administrators for single sign-on; it is placed on the target machines and the private key is either placed on a connecting server (for machine-to-machine use) or is given to a user to facilitate human-to-machine interaction.

It’s assumed that those best equipped to manage SSH access are the members of the PKI management team. Some vendors add to this belief by claiming that SSH keys are similar to managing certificates. However, comparing certificates to SSH keys is actually more akin to comparing apples with watermelons; they both provide authentication, but the similarities end there. Unlike certificates, SSH keys are easily copied, easily shared and, by default, aren’t set to expire. Moreover, unlike certificates, SSH is also used extensively for machine-to-machine interaction. For all these reasons, it does not align to the function of PKI and it would be inadvisable to assign the responsibility of SSH within this group.

The cryptography team is also often suggested for the SSH management task. It’s easy to see why that’s the case, since it provides encryption. It seems reasonable that the encryption team should own it. While this is true, SSH also enables remote interactive command and control of machines extending well beyond the purview of just cryptography.

As it turns out, the identity and access management team is the most logical group to own it. Why? Well, SSH keys equal access. Therefore, granting, monitoring and revoking access to resources via SSH should adhere to the same, if not more process and rigor used to grant system access for employees, contractors, partners and suppliers.

There is an important difference here, though. Contrary to the identity and access management that applies to humans, there typically is no on-boarding and off-boarding of SSH key access, which is strongly advised. Given all the complexities, providing safe and secure access via SSH, three things are needed:

  • Policies and procedures must be well-defined:
    • Define roles and responsibilities so that SSH key management does not fall through the cracks again.
    • Create usage procedures that include implementation of required IT controls and periodic access reviews, document and disseminate security policies and standards.
    • Inventory keys and track usage as part of your overall provisioning of users and accounts.
  • Make training and education for key employees a must:
    • Train employees regarding the risks of SSH Access
    • Ensure that developers and DevOps employees are well versed in the defined security policies and procedures.
  • Deploy continuous system monitoring and enterprise software to ensure that the issuance, monitoring and revocation of SSH access are adhered to.
    • Make sure the creation of any new key meets required security standards—key strength, allow from restrictions, etc.
    • Inspect SSH traffic and use your existing SIEM, DLP and antivirus software to monitor and alert your security operations center and stop unauthorized transmission of data.
    • Rotate keys on a regular basis and remove unused keys.

The SSH encryption protocol is embedded in systems around the world. It has become a default that organizations have come to rely on—and to take for granted. But this ubiquitous deployment makes its access a top security threat and protecting and managing it a real challenge. The majority of large breaches that have exfiltrated large sums of data undetected or installed software most likely made use of SSH keys to gain unlawful access. Consider the above recommendations to improve your organization’s SSH management and strengthen your security stance.

Thomas MacIsaac

Avatar photo

Thomas MacIsaac

Thomas MacIsaac is a cybersecurity strategist and currently serves as VP Eastern US, Canada and Federal Markets for SSH. Thomas has spent over 22 years in the high-tech industry representing many of the foundational and cutting-edge technologies of our time. Thomas regularly consults with Fortune 500 businesses and government agencies in the area of security on topics of data at rest and in transit, identity and access management, APIs and SIEMS, and is a sought-after speaker for audit, compliance, and security events.

thomas-macisaac has 3 posts and counting.See all posts by thomas-macisaac