In my last blog, I covered several important security risks related to SSH. If not addressed, SSH risks can open your systems up to a breach/compromise. Surprisingly, despite these risks, most organizations I’ve worked with don’t have strong processes and controls in place to mitigate them. Many don’t even have a complete inventory of all their SSH servers and keys, nor do they have good processes in place to review and approve the granting of SSH access. You may find yourself in this unenviable situation. My goal in the next few posts of this blog series is to equip you with the best practices and techniques you can use to address these risks and ensure that SSH is a security asset in your organization instead of a liability.
As you saw in my last post, there are quite a few SSH risks. Now you’ll see that there are a similarly large number of best practices for securing your SSH environment, especially for enterprise environments. Consequently, I plan on starting at a high level in this post and then drilling down into specific best practices in future posts.
Here is a high-level outline of the best practices that I suggest for mitigating SSH risks in enterprise environments:
- Establish Policies
- Define and communicate clear SSH policies and standards
- Keep SSH software up to date
- Provide SSH server configuration hardening guidelines, including:
- Ensure SSH servers don’t allow root login
- Prevent users from modifying authorized_keys
- Disable port forwarding on servers
- And a few other hardening guidelines we’ll get into in later posts
- Create a Comprehensive Inventory
- Inventory all SSH servers
- Inventory all SSH keys and configuration
- Map trust relationships (created by private/public keys)
- Remediate Vulnerabilities
- Identify and disable unauthorized SSH server use
- Identify and remove environment crossing (e.g., DEV --> Prod)
- Identify and replace weak keys
- Identify and remove unused authorized keys
- Identify and remove known_hosts keys orphans
- Identify and fix accounts with collocated private and authorized keys
- Identify and remove duplicated private keys wherever possible
- Rotate/replace old keys and continue to rotate regularly
- Implement source restrictions for automated process keys
- Implement forced commands for automated processes
- Implement session inspection for interactive user sessions
- Enforce dual control (approvals) for granting SSH access
- Ensure least privileged access for all SSH accounts
- Continuously Monitor
- Require regular reviews/approvals of SSH access
- Perform regular network and file scans
After looking at the list, you might think, “Wow! That’s a lot of things to do. Where do I start?” It is a long list that can be daunting. However, keep in mind that if SSH is compromised, the breach your organization experiences could be significant. Protecting your SSH requires a certain level of commitment at several levels in your organization. Many of our customers, because of typical resource and time constraints they face, find they need to prioritize SSH best practices they’ll tackle first for their environments. The first step they take is to establish a best practices roadmap. One approach that I’ve found valuable in creating a SSH security roadmap is mapping SSH risks and best practices, so you can understand which best practices address each SSH risk.
In the following mapping table, the checkmarks indicate that a best practice (on the left) addresses a risk (across the top):
As you can see from the table, there are several best practices that address more than one risk and can take you a long way toward rapidly improving your SSH security posture. For example, you can minimize virtually all SSH risks by making sure that your system administrators and business units clearly understand what must be done to secure SSH by defining and communicating clear SSH policies. I’ll discuss policies in more detail in my next post. Similarly, establishing an inventory of SSH servers, keys, and configuration gives you significant leverage in securing SSH by providing you the visibility needed to identify, prioritize, and address vulnerabilities. Requiring regular reviews of SSH entitlements (access) also addresses four critical SSH risks.
My experience is that every organization has different priorities and environmental factors. The goal of this mapping approach is to help you establish a roadmap for implementing SSH best practices that will best meet your organization’s needs.
I hope you find this mapping approach helpful in establishing a best practices roadmap for securing SSH in your organization. In future posts, I’ll dig into individual best practices to provide a more in-depth view into specific actions you can take to improve your SSH security.