The vast majority of organizations are mismanaging Secure Shell (SSH) in their IT environments, exposing critical systems and data to attack, according to new research from Venafi.
The certificate security vendor polled over 400 IT security professionals to better understand the level of security controls applied to SSH.
Organizations apply the cryptographic network protocol to secure and automate administrator-to-machine and machine-to-machine access to critical business functions.
However, despite being used to provide the highest privileged access to administrators, SSH is poorly managed by most respondents, Venafi found.
For example, 61% said they don’t limit or monitor the number of administrators who manage SSH, while only 35% enforce policies that prohibit SSH users from configuring their authorized keys. This could leave them wide open to attacks from malicious insiders, the vendor argued.
What’s more, 90% of respondents claimed they don’t have a complete and accurate inventory of all SSH keys, meaning there’s no way to find out if keys have been stolen, misused or should not be trusted.
Keys should also be rotated on a regular basis, in case any hackers have gained access. However, only 23% said they rotate on a quarterly or more frequent basis, and 40% don’t do so at all or rotate only occasionally.
Over half (51%) of IT security professionals polled said they don’t enforce any means to prevent port forwarding for SSH, a feature which could allow attackers to bypass firewalls to reach other parts of a targeted network.
Finally, 54% claimed they don’t limit the locations from which SSH can be used, potentially allowing attackers to use compromised SSH keys remotely.
Nick Hunter, senior technical manager for Venafi, argued that a compromised SSH key could be dangerous in the wrong hands.
“Cyber-criminals can use them to access systems from remote locations, evade security tools, and often use the same key to access more systems,” he added.
“Based on these results, it’s very clear that most organizations have not implemented SSH security policies and restricted SSH access configurations because they do not understand the risks of SSH and how it affects their security posture.”