Skip to main content
banner image
venafi logo

Poor Privileged Access Management Poses Big Security Problems

Poor Privileged Access Management Poses Big Security Problems

July 22, 2015 | Christine Drake

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.

System Administrators SSH Keys

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:

  1. Centralize control and visibility for all SSH hosts in the data center and cloud to effectively enforce policies for all enterprise SSH keys.
  2. 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.
  3. Regularly rotate SSH keys using lifecycle periods similar to other credentials (e.g. 60-90 day password lifecycles) to increase their security.
  4. Continuously monitor SSH key usage across the network to identify and neutralize any rogue usage.
  5. 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 and Drop me a comment and let me know what other SSH security practices you’d recommend to other security professionals.

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

TLS Machine Identity Management for Dummies

TLS Machine Identity Management for Dummies

Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

Christine Drake
Christine Drake

Christine Drake writes for Venafi's blog and is an expert in machine identity protection.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud

Venafi Cloud manages and protects certificates

* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
* Please fill in this field
* Please fill in this field
* Please fill in this field

End User License Agreement needs to be viewed and accepted

Already have an account? Login Here

get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more