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.
