With endless headlines touting the latest costly security breach, you would think that enterprises would be scrupulous about guarding the “keys to their kingdom.” Think again. The keys to the enterprise kingdom I’m talking about are secure shell, or SSH, keys. SSH is a cryptographic security protocol used to connect administrators and machines, allowing users or applications to gain secure remote access to another system. The kingdom, of course, is your valuable corporate IT assets. Users bearing SSH keys have the highest level of rights and privileges. But what if those users aren’t who they say they are? And, what if those users are bent on harm?
All enterprises rely on SSH keys to authenticate and provide privileged access for administrators, applications, and virtual instances in data centers and the cloud. But even though SSH keys provide root access to critical systems, they are treated with weaker policies than those tolerated for much lower levels of access, such as passwords. A recent survey by the Ponemon Institute canvassed over 2100 security professionals working in the U.S., U.K. Germany, and Australia—countries typically considered to be in the forefront of security practices. The results were disturbing.
Most organizations have an over-reliance on system administrators, not IT security, to self-police SSH keys. As a result, organizations are unable to identify how many SSH keys they have, who uses them, and what they access. In many companies, busy department administrators are charged with deploying and protecting SSH keys on the systems owned by their department. This creates a partitioned security structure with no ability to centralize visibility, policy enforcement, or incident tracking and remediation.
In the Ponemon Institute survey, 53% of organizations admitted they lack centralized control over their SSH key usage and access policies, and 60% are unable to detect the introduction of new SSH keys into their network. This lack of visibility hinders policy enforcement and detection of SSH key security issues.
SSH keys do not expire, creating a perpetual vulnerability if not rotated. But the Ponemon survey results show a surprising 82% change their SSH keys at best every 12 months—much longer than the 60-90 day policy for passwords which have less privileged access. This weak policy enforcement is resulting in dire consequences. Over half of organizations surveyed responded to a security incident related to SSH key misuse within the last 2 years. And those were the people willing to admit it. The sad reality is that the real percentage is likely much higher.
The manual approaches and customized scripts that enterprises are using to manage their SSH keys are not protecting their businesses. In the survey, of those that use homegrown scripted solutions to manage SSH keys, 54% were still compromised by rogue SSH keys on their networks—a clear indication that these solutions cannot detect anomalies in SSH key usage.
But there’s a silver lining to this storm cloud. A Forrester Research paper, Gaps in SSH Security Create an Open Door for Attackers, provides five steps you can take right now to regain control of your SSH-based privileged access management:
- Centralize control and visibility for all SSH hosts in the data center and cloud to effectively enforce policies for all enterprise SSH keys.
- Establish a baseline of normal key usage—including where keys are located, how they are used, who has access to them, and what trust relationships have been established within your network.
- Regularly rotate SSH keys using lifecycle periods similar to other credentials (e.g. 60-90 day password lifecycles) to increase their security.
- Continuously monitor SSH key usage across the network to identify and neutralize any rogue usage.
- Remediate vulnerabilities by ensuring that server and SSH key configurations adhere to common best practices, such as using 2048-bit key lengths or higher as recommended by NIST.
These 5 steps represent a good starting point, but there’s a lot more you can do. You can learn more on the Venafi solution webpages at Venafi.com/PrivilegedAccess and Venafi.com/SSHAudit. Drop me a comment and let me know what other SSH security practices you’d recommend to other security professionals.