Have you’ve finished collecting a complete inventory of SSH keys, access rights, and related hosts across your network? Congratulations on being one of few organizations to take this vital step to protecting your SSH machine identities! The work, however, does not end here. Now that you have the basics in place, you need to apply that intelligence to find and maintain high-risk connections. A lack of visibility into orphaned, shared, weak or root keys can lead to unauthorized access and must be immediately reported for analytic review. You should also be able to create your own rules to identify out-of-policy practices like cross environment key usage, improper key lengths or aged keys.
Information about who’s using an SSH key and which systems it can access will prove extremely valuable—especially if there’s a security event or audit. Some of the key usage details that you should discover about your SSH machine identities include
As business-critical SSH connections expand, uncontrolled oversight of the SSH keys, owners, access levels, and authorized assets often get lost, which results in a chaotic mesh of trusted connections. One common risk is having an abundance of unnecessary SSH root keys that violate data privacy policies and generate unwanted exposure.
Cybercriminals misappropriate poorly protected SSH keys to bypass security controls and gain privileged access to internal network resources and data. With SSH keys, attackers can appear to be legitimate administrators or trusted machines, enabling them to hide and move around on internal networks — often for extended periods of time without being detected.
Lack of insight and intelligence into ownership of keys, as well as orphaned, shared, weak, or root keys, can lead to unauthorized access — and should be reported immediately for review and corrective action.
All too often, administrators are stuck with the insurmountable task of trying to track down the root access that has been granted in each environment. What can make this task even more challenging is when you have no visibility as to where the private key resides, resulting in an access orphan. Access orphans are especially concerning when they’re root access orphans, which grant superuser privileges.
Duplicating unique host keys isn’t all that uncommon — especially when a specific virtual machine gets copied and used in identical ways. Identity keys shouldn’t be duplicated (copied to other systems) for interactive users and automated processes. While it’s not recommended, if you choose to allow duplication for interactive users, you should provide guidelines for the acceptable locations where keys can be copied and used.
Often, administrators may share their private keys out of convenience — perhaps when they’re on vacation or busy with other duties and need other staff members to assist them. If uncontrolled, this process could quickly spin out of control as private keys are shared, stored, and used without limit.
Many organizations leave themselves open to SSH-based lateral movement because they have no inventory of deployed SSH keys that enable persistent access between systems. You need to be able to monitor usage to prevent cybercriminals moving around and expanding their access on compromised systems. Monitoring helps you prevent a dense and uncontrolled environment of SSH key-enabled connections that allows attackers to move from asset to asset, using keys found in various user accounts.
Information about who’s using an SSH key and which systems it can access will prove extremely valuable — especially if there’s a security event or audit. Some of the key usage details that you should discover about your SSH machine identities include
SSH configurations can restrict the locations from which each authorized SSH key can be used. But many organizations fail to limit SSH key use by location. When access is limited to the known locations of administrators and machine-to-machine access, it helps to prevent malicious access from other locations.
One of the best ways to prevent the misuse of SSH machine identities is to understand who’s using them. Furthermore, your organization should assign ownership of all access granting SSH keys and monitor and analyze key-based access usage.
3. Protocol versions
Over time, SSH protocol has expanded its encryption algorithms. Also, support for public key certificates was added in SSH, version 2 (SSHv2). As vulnerabilities start to spike, especially for older unsupported versions like SSH, version 1 (SSHv1), and support is no longer guaranteed, information security teams will deal with many configuration variants and ensure exploitable deployments are rooted out.
Because of the security threats and operational risks connected with poorly managed SSH keys, auditors are becoming increasingly focused on those risks and the visibility and management of SSH keys. And the audits themselves evolve over time, generally becoming more dynamic and stringent. In recent years, the number of security frameworks and standards that require close inspection of SSH key risks have grown. The most noteworthy include the following:
Rather than wait for an auditor to check on the health of your organization’s SSH practices, you can be proactive about securing your SSH keys.
Use this checklist to gauge the likely outcome of your next SSH audit. If you’re lacking one or more of these controls to secure your SSH keys, the chance of passing your next SSH audit may be small. Check off these tasks:
You can also get a FREE risk assessment of your SSH keys with Venafi!