Ensuring SSH Key Management Security

By Thomas macisaac, cybersecurity strategist, SSH Communications Security

When it comes to SSH (Secure Shell) access management, ignorance is anything but bliss. What you don’t know can seriously hurt your organization and its reputation.  In most major breaches that have exfiltrated large sums of data undetected, installed software or disabled systems, or occurred over an extended period of time undetected, it’s likely that SSH had been leveraged by cybercriminals.

But you would not know this  –  at least, not initially. That’s because SSH grants access to the very core of your network. SSH is a protocol that is used by both system administrators and application owners to securely communicate, control machines or facilitate 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. Massive data breaches ensue.

Who’s running the SSH show?

Strangely, though SSH is so important, which team should own SSH often remains a mystery. The reason is that, unlike other IT investments, Open SSH comes pre-installed on servers, networking, and storage gear. By default, it’s just there to be used, and administrators and application developers use it extensively. It’s a given that people end up forgetting to manage.

To use the Secure Shell protocol, an administrator or other authorized parties must create

Matching public and private key pairs for 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.

Some would argue that the public key infrastructure (PKI) management team should manage SSH access. Various 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 coconuts; 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, SSH does not align to the function of PKI,  and it would not be a good idea to assign the responsibility of SSH within this group.

Others suggest the cryptography team for the job of SSH management. This makes a certain kind of sense since SSH 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.

So, since neither the PKI or cryptography teams are a good fit, who should manage  SSH? The most logical group to own SSH is the identity and access management team. That’s because 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.

Elements of safe SSH access

Identity and access management, which applies to humans,  requires an onboarding and off-boarding process. Though this is strongly advised for SSH key access, it rarely happens.

This is the inherent challenge of SSH. Given all the complexities, three  things  are needed to provide safe and secure access via SSH:

1. Clearly define SSH policies and procedures:
   • Assign roles and responsibilities so that SSH key management does not get overlooked
   • Take stock of all keys and track usage as part of your overall provisioning of users and
   • Implement required IT controls and periodic access Document and disseminate security policies and standards.
2. Implement continuous system monitoring and enterprise software to enforce the issuance, monitoring, and revocation of SSH access:
   • Remove unused keys, and rotate keys on a regular
   • Ensure that any new creation of keys meets required security standards – key strength, allow from restrictions,
   • 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.

3. Train employees involved with SSH:
   • Teach all employees involved with SSH access about its inherent
   • Educate developers and your devlops employees about your SSH security policies and procedures.

In a sense, SSH has become a victim of its own success. It is so important that it has become ubiquitous, so readily available that it has become an afterthought.  But its power to access the network makes SSH a security priority. Make sure that there is a designated team to manage SSH key access, and use the recommendations above so that everyone who handles these keys knows your procedures and follows them.

About the Author

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.