CHANNELS

Subscribe to the InfoTech eNewsletter

infoTECH Feature

May 24, 2018

SSH Key Management is Critical - But Whose Job Is It?

By Special Guest
Thomas MacIsaac, cybersecurity strategist, SSH Communications Security

Because the SSH protocol is nearly ubiquitous, most people don’t think of it when they go through their cybersecurity checklist. But they would be wrong. SSH poses a significant risk due to the lack of visibility that surrounds it because of poor or non-existent management. Now that the C-suite and board members can be held accountable for security failures, IT leaders are starting to feel the SSH heat.

For IT executives in many enterprises and government agencies who are trying to manage their digital infrastructure, there is one question that comes up often: Which functional group within IT should own SSH? The reason that this “unknown” is such a struggle 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.

They use the SSH protocol 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. 

Matching public and private key pairs must be created to use SSH 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 believe that it makes sense to assign SSH access management to 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 plums; 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 be inadvisable to assign the responsibility of SSH within this group.

The cryptography team is also mentioned as a possible steward for SSH management. It’s easy to see why, 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.

For these reasons, the identity and access management team is the best choice for SSH management. 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.

Though the on-boarding and off-boarding of SSH key access is strongly advised, it typically doesn’t happen. This is the inherent challenge to SSH, unlike identity and access management that applies to humans. Given all the complexities, providing safe and secure access via SSH, three things are needed: 

  1. SSH procedures and policies that are well-defined:
  1. First, determine clear roles and responsibilities so that SSH key management does not fall through the cracks again.
  2. Take inventory of SSH keys and track usage as part of your overall provisioning of users and accounts.
  3. Define usage procedures that include implementation of required IT controls and periodic access reviews, document and disseminate security policies and standards.
  1. Educate key employees
    1. Educate employees about the risks of SSH Access.
    2. Ensure that developers and your DevOps employees are clear about the defined security policies and procedures.
  2. Continuously monitor system and enterprise software to enforce compliance with the issuance, monitoring and revocation of SSH access.
    1. Confirm that any new key creation meets required security standards.
    2. Remove unused keys, and rotate keys on a regular basis.
    3. 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.

At the heart of many data breaches in which large amounts of data have been exfiltrated without detection or that went unnoticed for an extended period of time, it’s a safe bet that the hackers used SSH keys to gain access and do their dirty work. Because these keys enable this level of access to critical systems and data—and because they exist in almost every business and government agency in the world—protecting and managing them is a priority security issue. Use the recommended steps above to secure this vital infrastructure immediately.

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.




Edited by Maurice Nagle
FOLLOW US

Subscribe to InfoTECH Spotlight eNews

InfoTECH Spotlight eNews delivers the latest news impacting technology in the IT industry each week. Sign up to receive FREE breaking news today!
FREE eNewsletter

infoTECH Whitepapers