SSH on the rise for remote access
Over the past weeks, remote access for employees has become the new standard and Secure Shell (SSH) is one of the most essential transports. Administrators use SSH to manage IT systems, developers use it to modify application settings and automation tools use it to orchestrate services. But has this increased usage of SSH also increased associated risks?
The concept of jump server
It is important that most critical SSH sessions should run outside VPN connections. Why you may ask? Because if the VPN fails, administrators will no longer have access to one of the most essential transports to administer VPN and they will be isolated from assets or applications. Now, to make SSH safe from the public internet, organizations often use a jump-server, proxy or simply said an intermediary host that shields their internal IT assets from the outside world. These “bastion” jump server technologies are offered in opensource as well as commercially formats. One of the most know is of course OpenSSH and this suite of secure networking utilities has been adopted by most Linux distributions as well Microsoft Windows 10.
What about SSH keys?
The jump server deployment model indeed shields traffic, but it also comes with some challenges. One of them is around implementation and usage of SSH keys. These seemingly small critters—in the form of a public private file—are often created by asset owners or developers and enable automated connections. Their purpose is to help the user to save time and provide security without too much dependencies on Identity and Access Systems. Now, when poorly managed keys inadvertently grow legs and fall in the wrong hands, bad guys may use them to get access to your critical assets. Now more than ever, SSH keys need to be managed and hygiene in their usage has essentially become mandatory.
Risk insights from our experts
Over the past year Venafi machine identity experts have executed dozens of SSH risk assessments. These stories can be very sobering. Here are some of the biggest challenges and risks that we uncovered:
- Key Sprawl: Number of keys deployed is ten to fifty times the number that organizations estimate and no one knows why.
- Love for Root keys: Administrators often give themselves root keys where they may not be needed.
- Orphaned keys: Simply said, the public part of the key is still around even after the private one is gone. Yes, it may be on that laptop lost on the plane ride back from Las Vegas or could it also have been left on that USB backup drive forgotten in that coffee shop. The point is that if you don’t know where the private key parts are, others may use them to get access.
- No concept of zones: Modern teams split their systems into different zones: development, test and production are most common. But what about the keys? Often, they have been deployed in abundance without this concept of zones. This may accidentally allow adversaries to pivot from environment to environment to find the most succulent customer data using a key from a developer, for example.
To defend against some of this bad new, here a set of simple best practices for SSH key usage and security. If you want more detailed info, you may wish to peruse a free download of NIST IR 7966.
- Own all keys between jump server and asset: One of the foremost practices is to have a solid inventory of all assets and their keys used from the jump host. These are your prime routes to and from, so they need to be inventoried and each key pair must be unique. Keys pointing to other assets outside the zone should be known and if their specific purpose can’t be determined, they should be removed.
- Monitor key deployment: Remote users will and should deploy new keys on the jump server. It is critical to monitor this at all times and get insights into when and where keys are generated and by whom. It may also be a good practice to regularly clean up keys from the remote users to the jump server, as their exposure there is very high. Also, any new key installed on the jump server from a suspicious location (i.e. a geo where company is not active) should be detected, removed and investigated.
- Eliminate unused or orphaned keys: Any key inside the “perimeter” not in use for a certain time period (let’s say 90 days) or keys where the private part is unknown should be removed. Full stop.
- Rotate: Rotation is part of a cybersecurity defense mechanism and reduces the risk that when a key part gets into the wrong hands, it may fall victim of nefarious use after the rotation. During these challenging times, SSH keys inside the perimeter should be rotated on a higher frequency. Weekly for “root” or highly privileged keys, monthly for all others looks acceptable practice
- Report and Communicate: Just as any part of the IT infrastructure, SSH usage should be reported on. Regularly. Building a set of metrics and sharing them with peers (Risk, InfoSec) helps create a mindset and perhaps an incentive to building out stronger SSH policies.
Where do I look for a solution?
The above guidelines can be intimidating, especially if you are new to the concept of SSH keys and other machine identities. For those interested to learn more, Venafi offers a solution called SSH Protect that can give you the visibility, intelligence and automation you need to protect your SSH keys. For more info, visit www.venafi.com/ssh.