Who should be responsible for SSH?

In my job at SSH, I meet with IT executives in many large businesses and government agencies.  Aside from their initial surprise that there is an actual company behind SSH, there is one question comes up most often, namely which functional group within IT should own SSH?  The reason that this 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, which administrators and application developers use extensively.

Some background, SSH is a protocol that is used by both system administrators and application owners to securely communicate, control machines or to 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.  SSH use requires the creation of matching public and private key pairs for authentication.  The public key is primarily used for automation and sometimes by system administrators for single sign-on 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.

There is a notion that the PKI management team should also manage SSH access.  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 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, we do not believe that SSH aligns to the function of PKI and would advise against assigning the responsibility of SSH within this group.

Another group often considered to manage SSH is Cryptography.  It’s easy to see why that’s the case 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.   Instead, it’s our view that the most logical group to own SSH is the identity and access management team.  Why?  Well, SSH Keys = 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.

The inherent challenge to SSH is that unlike identity and access management that applies to humans, there typically is no on-boarding and off-boarding of SSH Key access, which is something we strongly advocate.  Given all the complexities, providing safe and secure access via SSH we feel that three things are needed:  1. Well defined policies and procedures related to SSH 2. Training and education for key employees and 3. Continuous system monitoring and enterprise software to enforce that the issuance, monitoring, and revocation of SSH access is adhered to.

In conclusion, the SSH protocol is a vital technology that is used extensively throughout every business and government agency the world over which makes protecting and managing SSH access a Tier 1 security concern.  In fact, if you investigate the core of most major breaches that a. exfiltrated large sums of data undetected b. installed software or disabled systems or c. occurred over an extended period of time undetected, it’s likely an indication that SSH had been leveraged by the hackers.

SSH protocol – the inventor of the Secure Shell protocol have developed several thoughtful and purpose-built solutions that address the unique complex security and compliance requirements of SSH to compliment your existing security investments.  To learn more, or to schedule an SSH security risk assessment please feel free to contact me by filling out the contact form within this website.

Permanent link to this article: https://demystifyit.com/who-should-be-responsible-for-ssh/

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.